Ok, I'll update the missing references on these components. ceph/centos/build_srpm.data devtools/qemu/centos/build_srpm.data openstack/openstack-ras/centos/build_srpm.data openstack/python-ceilometerclient/centos/build_srpm.data openstack/python-openstacksdk/centos/build_srpms.data Thanks. Erich On 6/18/18, 9:40 AM, "Scott Little" <scott.little@windriver.com> wrote: For patching purposes, it's required that either the package version, or the release number increment with every commit. TIS_BASE_SRCREV is part of a mechanism to automatically set the release number by counting commits from a reference commit. TIS_BASE_SRCREV is the reference commit. It should point to a valid sha on the current branch. A tag would also be acceptable, although I don't know if we've ever tested with a tag. TIS_SRC_REV should be reset every time the openstack component declares a new version. Scott Little On 18-06-18 10:12 AM, Dean Troyer wrote: > On Sun, Jun 17, 2018 at 9:13 AM, Cordoba Malibran, Erich > <erich.cordoba.malibran@intel.com> wrote: >> In preparation to open source, some components of StarlingX were squashed, this causes that the git >> history is different now. Therefore, the TIS_BASE_SRCREV variable is broken for several components >> as now points to missing commits, causing a broken build. > Erich, do you know why they were pointing directly at a commit and not > using a tag or branch? It sounds like that is a per-package variable? > If it was a global this could be fun to fix with the now-split repos. > >> My question is what to do with these variables, should we: >> >> - Update to a valid commit >> - Set the variable value to HEAD >> - Remove those variables, not sure if that's possible. >> >> What do you think is the best course of action. > We'll have to let WRS weigh in here as to the purpose and solution. > > dt > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss