December 2011 - openSUSE Build Service

[opensuse-buildservice] API server database migration fails (unstable upgrades)
by Mikhail Zabaluev 15 Dec '11

15 Dec '11

Hi, I've been working with an OBS installation from openSUSE:Tools:Unstable, and went through several upgrades. During each upgrade, I am instructed to run the database migration scripts. For the API server database, it always failed with this error. Mysql::Error: Table 'api_production.issue_trackers' doesn't exist: ALTER TABLE ` issue_trackers` ADD `kind` ENUM('bugzilla', 'cve', 'fate', 'trac', 'launchpad', 'sourceforge') AFTER `name` Finally, after updating to obs-api 2.2.107, I'm in a corner because the API server needs some new table to serve commit requests. Should I fix the database manually and how, or should the migration script account for earlier installations of unstable OBS? I'm attaching the output of 'rake db:migrate --trace'. Best regards, Mikhail

2 1

[opensuse-buildservice] Conversion of bz2 to tar.gz fails for debian builds
by Malcolm Fernandes 14 Dec '11

14 Dec '11

Hi, We have a local OBS instance (obs-server-2.1.11-4.5.x86_64) and trying to build a debian package in OBS which has a *.tar.bz2 source file. The conversion fails with this message: now finalizing build dir... running debian transformer... converting osc-plugins-bcm-0.1.6.tar.bz2 to osc-plugins-bcm-0.1.6.tar.gz shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory bzcat: Can't open input file osc-plugins-bcm-0.1.6.tar.bz2: No such file or directory. dpkg-source: warning: extracting unsigned source package (/usr/src/packages/SOURCES.DEB/osc-plugins-bcm_0.1.0-1.dsc) dpkg-source: info: extracting osc-plugins-bcm in /usr/src/packages/BUILD dpkg-source: info: unpacking osc-plugins-bcm_0.1.0.orig.tar.gz tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors dpkg-source: error: tar --no-same-owner --no-same-permissions -xf - gave error exit status 2 The source files are: osc-plugins-bcm-0.1.6.tar.bz2 debian.tar.gz osc-plugins-bcm.spec osc-plugins-bcm.dsc osc-plugins-bcm.changes I've checked our build rpm (build-2011.07.01-79.1.noarch) and it seems to have all the latest debtransform* changes in it. Is this supposed to work for OBS builds via the webui? If so, can somebody provide some guidance. This seems to work for command line 'osc' builds. Thanks, Mal -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

3 3

[opensuse-buildservice] RPM Versioning Information in OBS different from Repository
by James Ford 14 Dec '11

14 Dec '11

I'm wondering why the version numbers and rpm packages differ from the buildservice repository versus the OBS webui. I'm currently running obs-server 2.1.11-4.6 obtained via repository Index of /repositories/openSUSE:/Tools/openSUSE_11.4/i586 however if you browse to https://build.opensuse.org/package/binaries?package=obs-server&project=open… you will see package obs-server-2.2.95-3.5.i586.rpm listed which seems to have been built 12 days ago. Am I not understanding how the repository should work? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 1

[opensuse-buildservice] orafce package build failing on opensuse w/gcc46
by Darin Perusich 13 Dec '11

13 Dec '11

Hello, I'm running into an issue building a package on OpenSUSE 12.1, factory, and tumbleweed, which appears to be related to the version of the compiler. The package in question is orafce which is an implementation of some oracle functions in postgres. The package builds successfully on opensuse 11.3 and 11.4 which using gcc45 compared to gcc46 on the systems where the build fails. The compile options are slightly different between a successful and failed build, -fomit-frame-pointer on gcc45 and -Wformat-security on gcc46, yet when i attempted to build under gcc46 with the gcc45 options it still fails. Can anyone provide any insight into this? BuildLog: https://build.opensuse.org/package/live_build_log?arch=x86_64&package=orafc… Snip of the error: others.c: In function 'ora_decode': others.c:357:52: error: macro "InitFunctionCallInfoData" requires 6 arguments, but only 5 given others.c:357:4: error: 'InitFunctionCallInfoData' undeclared (first use in this function) others.c:357:4: note: each undeclared identifier is reported only once for each function it appears in gcc -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -fpic -I. -I. -I/usr/include/pgsql/server -I/usr/include/pgsql/internal -D_GNU_SOURCE -I/usr/include/libxml2 -c -o plvstr.o plvstr.c make: *** [others.o] Error 1 make: *** Waiting for unfinished jobs.... plvstr.c: In function 'plvstr_rvrs': plvstr.c:572:11: warning: variable 'aux' set but not used [-Wunused-but-set-variable] error: Bad exit status from /var/tmp/rpm-tmp.AMYyS6 (%build) Thanks! -- Later, Darin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 3

[opensuse-buildservice] [PATCH] [backend] copy missing tree meta data to linked projects
by Robert Schiele 13 Dec '11

13 Dec '11

In case of special meta data like after source service runs the current code does not always transfer the meta data to linked projects completely. This change copies missing meta data files to linked projects to fix this situation. --- src/backend/bs_srcserver | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/src/backend/bs_srcserver b/src/backend/bs_srcserver index b563266..acf6124 100755 --- a/src/backend/bs_srcserver +++ b/src/backend/bs_srcserver @@ -726,6 +726,13 @@ sub getrev { my $files = lsrev($lrev); copyfiles($projid, $packid, $lprojid, $packid, $files); addmeta($projid, $packid, $files) if $BSConfig::nosharedtrees; + my $treedir = $BSConfig::nosharedtrees ? "$treesdir/$projid/$packid" : "$treesdir/$packid"; + my $ltreedir = $BSConfig::nosharedtrees ? "$treesdir/$lprojid/$packid" : "$treesdir/$packid"; + if (-e "$ltreedir/$lrev->{'srcmd5'}-MD5SUMS" && ! -e "$treedir/$lrev->{'srcmd5'}-MD5SUMS") { + mkdir_p($ltreedir); + my $meta = readstr("$ltreedir/$lrev->{'srcmd5'}-MD5SUMS"); + writestr("$uploaddir/$$", "$treedir/$lrev->{'srcmd5'}-MD5SUMS", $meta); + } $lrev->{'originproject'} ||= $lprojid; $lrev->{'project'} = $projid; return $lrev; -- 1.7.7 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

3 2

[opensuse-buildservice] running source services on accepting requests or just copying results
by Robert Schiele 13 Dec '11

13 Dec '11

Hi all, As already mentioned as a side comment in a previous mail I found a regression with the new source services in 2.3 that asks for a solution. I realized that when accepting requests of packages using source services the services are not run on the accepted package. Michael mentioned that the idea might be to copy the results of the original package (to get accepted) instead of rerunning them. This makes sense to me but unfortunately this result copying neither takes place, thus leaving the accepted package in a broken state. Only a manual run of source services will bring it back to life. Thus two things needed to be done: 1. Discuss what is the intended behavior. I see the already mentioned options: a) source services are rerun b) source service results are copied from the originating package I personally don't have a very strong opinion which one is the better solution as long as at least one of them is implemented. Thus I would like to hear the opinion of those people that have a strong one plus the opinion of the people that did the original design. 2. Fix the issue in the direction that was the result of the previous discussion. I might be able to help if the relevant code is easy enough to understand to follow the semantic intentions that are behind it. You can see a broken example for this problem on build.opensuse.org in project home:schiele:treesbug_base, package zlib, which was modified in a branch and then submitted back. As you can see the source services were not run, nor their results copied from the branch. That's why it is currently still in failed state. I could fix this by triggering a source service run manually but I decided to leave it as such in case someone wanted to have a look into it for debugging. I will now start looking into the code myself and try to get a better idea on what is going on there. My current (still relatively uneducated) guess is that the code might be confused again about the difference between the srcmd5 of the package without source services run and those having them run and thus instead of copying the sources for the package with source services applied, copying the verbatim package. But better pointers are as usual always welcome! Thanks, Robert -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 3

[opensuse-buildservice] osc default setup locks out builds for openSUSE 11.1
by Hans-Peter Jansen 12 Dec '11

12 Dec '11

Hi, it looks like the current osc setup locks out builds for openSUSE 11.1: osc ci on BS requires osc-source_validator, osc-source_validator removes group fields from all but the main package in spec files (which is rather questionable in the first place...), but rpmbuild of openSUSE 11.1 requires group fields for all defined packages, hence created a catch 22. [Emotional excrements removed] See: https://build.opensuse.org/package/live_build_log?arch=i586&package=kdelibs… Glad, if somebody would show me, how to workaround this @#*$? Pete -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 1

[opensuse-buildservice] KDE:Distro:Factory priority
by Nico Kruber 11 Dec '11

11 Dec '11

is it possible, that the build priority of KDF has been reduced some time ago for all distros but openSUSE:Factory? it takes ages to fully build and publish, nowadays - and I still see lots of "scheduled" packages... even packages in my own home project get scheduled in more easily I'm asking because I'd like to get 4.7.4 since it fixes so many annoying bugs - and I saw, the packages went into the repo almost a week ago but didn't get build yet :( Regards Nico Kruber -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 1

[opensuse-buildservice] Feature request
by Robert Schweikert 09 Dec '11

09 Dec '11

Hi, We should automatically enable the new release branch as a build target for all projects that build against factory when we branch. Yes, one makes the assumption that a given project wants to support/build against the next release, but I think this may be more applicable than the assumption we make now, which is that people do not want to build against the new release. This avoids the hassle of maintainers having to go in and turning this on explicitly. My guess would be that there are fewer maintainers that do not want this behavior than there are maintainers that want this behavior. The other alternative would be to add yet another setting to the meta data of a project that says "build-new-target-on-release-branching" then maintainers can choose this depending on their preference. I don't think we need such a flag, but it gives control to project maintainers. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

7 14

[opensuse-buildservice] Kernel modules
by Roger Oberholtzer 09 Dec '11

09 Dec '11

I have a few kernel modules in OBS that are getting rebuilt just fine. I see that they were built for openSUSE 12.1, and for openSUSE Factory. The 12.1 builds seem to be for the kernel version released with 12.1, which makes sense. And Factory is whatever is in factory. My question is where kernel modules for 12.1 updates would be? In 11.2 (when I last did this) there was a 11.2_Update that could be selected for this. I wouldn't choose Factory as those are not required to be what is in the update. Am I missing something? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer(a)ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

3 2