Bugzilla – Bug 351606
osc build doesn't set %release to the proper value
Last modified: 2024-01-09 08:11:03 UTC
In kernel-syms.spec for the Kernel projects in the OBS we check for the proper release numbers of the BuildRequired binary kernel packages (kernel-default, etc) to be equal to the release number of the kernel-syms package. This fails when you try to build the kernel-syms package locally with osc build because the release number from the specfile is used instead. Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.7208 + umask 022 + cd /usr/src/packages/BUILD + export NO_BRP_NOEXECSTACK=yes + NO_BRP_NOEXECSTACK=yes + rm -rf /var/tmp/kernel-syms-2.6.24_rc6_git7-build + mkdir /var/tmp/kernel-syms-2.6.24_rc6_git7-build + /usr/src/packages/SOURCES/guards i586 IA32 ++ /usr/src/packages/SOURCES/guards i586 IA32 + for config in '$(/usr/src/packages/SOURCES/guards i586 IA32 < /usr/src/packages/SOURCES/config.conf)' + arch=i386 + flavor=default + rpm -q --quiet kernel-default ++ case $flavor in + set -- kernel-default default + /usr/src/packages/SOURCES/guards kernel-default default i586 IA32 + diff -q /usr/src/packages/BUILD/kernel-source.patches /usr/src/packages/BUILD/kernel-default.patches ++ rpm -q --qf '%{RELEASE}' kernel-default + set -- 0 40.1 + set -- 0 40 + '[' 0 '!=' 40 ']' + echo 'Release numbers 0 and 40 do not match' Release numbers 0 and 40 do not match + exit 1 error: Bad exit status from /var/tmp/rpm-tmp.7208 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.7208 (%install)
IMHO the basic problem is that the automatic modifications of the spec files on server side do not happen on local build at all. We seem not to have any api calls to POST the local spec file and get the modified version from the server. Michael, does it make sense to add this ? (despite of the fact that I personally think that the kernel*spec release number handling is not really a good design regards we handle release numbers with our build systems. I would check for the release numbers of installed packages and require them. This would also allow to update only on package and increase its Release number without a complete rebuild of all packages.).
Actually the buildinfo call does upload the spec file for inspection. The buildinfo return value even can contain a release tag. However the release tag is imply not included in the reply when uploading a spec file. By contrast, if not specifying a spec file the release is returned: home:lnussel:Factory/SuSEfirewall2 > osc buildinfo openSUSE_11.2 i586 > f home:lnussel:Factory/SuSEfirewall2 > osc buildinfo openSUSE_11.2 i586 SuSEfirewall2.spec > g dif[0] lnussel@tanana:/space/lnussel/bs/home:lnussel:Factory/SuSEfirewall2 > diff -u f g --- f 2009-12-01 14:20:49.000000000 +0100 +++ g 2009-12-01 14:20:54.000000000 +0100 @@ -1,13 +1,5 @@ <buildinfo project="home:lnussel:Factory" repository="openSUSE_11.2" package="SuSEfirewall2" downloadurl="http://download.opensuse.org/repositories"> <arch>i586</arch> - <srcmd5>7b4838c49e5d590e11a1338a0dfb1833</srcmd5> - <verifymd5>238e473d033c784cf7acb4210c879ba5</verifymd5> - <rev>3</rev> - <specfile>SuSEfirewall2.spec</specfile> - <file>SuSEfirewall2.spec</file> - <versrel>3.6_SVNr226-6</versrel> - <bcnt>1</bcnt> - <release>6.1</release> <debuginfo>0</debuginfo> osc does pass the value of the release tag down to build which in turn passes it to substitutedeps to replace it in the spec file. The value just needs to be actually returned by the api.
the api is not returning this block, because these are pure server side release numbers. We can't increase it on each local build and we won't trigger server side builds if someone runs a local build. IMHO we could always default to 0 or alike here for local builds, since you anyway need to install with --force or --oldpackages when you build multiple iterrations and install it.
(In reply to comment #3) > IMHO we could always default to 0 or alike here for local builds, since you > anyway need to install with --force or --oldpackages when you build multiple > iterrations and install it. Sure but if you default to something anyways why not default to the last used revision in the build service? Doesn't really matter for most but fixes the kernel corner case. Didn't autobuild do it that way too?
We could use this number as well, but it would force you also to use --force on installation. A 0 is maybe more obvious that it is not a number from a server side generated rpm (simply because it is not X.Y style). So it is more easily spotable that this is no "official" package.
Actually the api is supposed to return the block if it knows which package is meant, i.e. if you do a POST on the package name, not _repository. Fixing...
Another option (thanks to Ludwig) would be to extend the release number with a "m" for "modified" for example, similar to svn. that would mean that it is higher than the current one on the server, but lower than the next build one.
Regarding #6: hmm, not as easy as I thought because the cicount info is not available on the repo server.