openSUSE Build Service February 2012

buildservice@lists.opensuse.org

55 participants
51 discussions

[opensuse-buildservice] Hermes installation: howto?

by Pascal Bleser

As we're (luckily) starting to get a few more contributors to Packman, it is about time for us to have a Hermes instance in order to get email notifications of SRs. Unfortunately, I couldn't find much information about how to install it. Can anyone help? cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf

9 years, 6 months

[opensuse-buildservice] submit request is not specific about content

by Robert Schiele

Hi all, I observed a situation where it turned out that it is not possible to specify exactly the version of sources to be submitted to a different project and wanted to hear your opinion whether this is intended behavior (with explanation please) or whether you agree that there is a problem that should be addressed in some way. In a submit request I can specify the exact revision to submit. For instance if I want to submit a package I tested to Factory, which is revision 42, I specify this revision in the submit request and can be sure that when it is accepted this tested version will go into Factory, even when I messed up the package in my project with revision 43. A problem exists though for linked (or branched) packages. This is because when I submit a tested revision 42 of a linked (or branched) package and the original package my package is based on changes (and potentially breaks my package) the modifications are merged automatically into my package without the revision number changing. There is no way (or at least I am not aware of one) to specify a specific srcmd5 though in a submit request to prevent this. An example of that behavior can be seen in my project home:schiele:linkrev on build.opensuse.org. In that project I just copied the plain zlib package from Factory and created another package zlib-link that is just a plain link to zlib. Both packages built with revision 1. Then I changed the zlib package and both packages rebuilt. While the revision of the zlib package obviously was increased for the second build, the revision number of zlib-link didn't change. Now if I had a submit request of this package to Factory pending and the change would have broken the package, the result would have been a submit request for a broken package, although the package was perfectly fine when I created the request. Robert -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

9 years, 6 months

[opensuse-buildservice] Please don't git-1.7.9(factory) for OBS development atm

by Adrian Schröter

JFYI, the git in Factory, version 1.7.9 seems to be highly broken atm. Sascha is currently updating it to 1.7.9.2 in the hope it is fixed. But please use the 1.7.7 (as in openSUSE 12.1) or former version for now for OBS work. It is the reason for the messed up history tree and also for the wrong mass emails on diff changes. thanks adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

9 years, 6 months

[opensuse-buildservice] What to backup ?

by Pascal Bleser

Which directories/files do I need to backup to be able to reconstruct an OBS instance ? (no, "everything" won't work, it's 71 GB atm ;)) db + info + projects + trees ? Thanks! cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf

9 years, 6 months

[opensuse-buildservice] gcc-4.6 internal compiler error, always, on Factory

by Pascal Bleser

In the Packman OBS instance, every single package build fails for Factory with GCC-4.6 crashing on an internal compiler error, e.g. like this: http://pmbs.links2linux.org/package/rawlog?arch=x86_64&package=MPlayer&proj… Known issue? Some problem on our side? (e.g. cached gcc package that has been replaced by a working one but hasn't been picked up ?) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf

9 years, 6 months

[opensuse-buildservice] macro to get current build project

by Ruediger Meier

Hi, is there a macro to get the current build project? I'd like to have a string like "SLE_11_SP1" available within spec file. cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

9 years, 6 months

[opensuse-buildservice] [PATCH] [BACKEND] fix aggregating of multiarch packages

by Dirk Müller

Aggregating a patchinfo does not work, as aggregate only copies a binary of particular name only once. patchinfos however contain usually binaries of multiple architectures, which means previously only one of the archs was aggregated, the others were skipped. --- src/backend/bs_sched | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/backend/bs_sched b/src/backend/bs_sched index 0875cf9..ac97006 100755 --- a/src/backend/bs_sched +++ b/src/backend/bs_sched @@ -4101,12 +4101,13 @@ sub rebuildaggregate { my $copysources; for my $abin (sort keys %$ajobrepo) { my $r = $ajobrepo->{$abin}; + my $binname = $r->{'name'} . "." . $r->{'arch'}; next unless $r->{'source'}; next if $abinfilter && !$abinfilter->{$r->{'name'}}; - next if $jobbins{$r->{'name'}}; + next if $jobbins{$binname}; # FIXME: How is debian handling debug packages ? next if $nosource && ($r->{'name'} =~ /-debug(:?info|source)?$/); - $jobbins{$r->{'name'}} = 1; + $jobbins{$binname} = 1; my $basename = $abin; $basename =~ s/.*\///; $basename =~ s/^upload:// if $cpio; -- 1.7.8 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

9 years, 6 months

[opensuse-buildservice] Getting binaries through linked project

by Ed Bartosh

Hi, In our local OBS instance we have two linked projects. One of them produces error: "400 remote error: unexpected EOF" for any build attempt. I digged a bit into the problem and here is what I've found: With working link I can get rpms in cpio format from the repository: wget "http://my.local.obs:81/public/build/link.to.good.obs:project/distro/arch/_r…" -O- -q |cpio -t foo.rpm 121 blocks With not working link the same attempt ends with empty ouput: wget "http://my.local.obs:81/public/build/link.to.bad.obs:project/distro/arch/_re…" -O- -q On the server side I see this error in src_server.log: 2012-02-23 17:15:17 [8319]: GET /build/link.to.bad.obs:project/distro/arch/_repository?binary=foo&view=cpio 2012-02-23 17:15:17 [8221]: GET /build/ link.to.bad.obs:project/distro/arch/_repository?view=cpio&binary=foo (AJAX) rpc_recv_stream_handler: illegal chunk size: 16175 In the code of BSWatcher.pm:rpc_recv_stream_handler I can see this: if ($cl < 0 || $cl >= 16000) { print "rpc_recv_stream_handler: illegal chunk size: $cl\n"; BSServerEvents::stream_close($rev, $ev); return; } Where this limit came from? How it at all can be possible that some obs server sends chunks bigger than this limit? How would you suggest to fix this? I'm using obs server 2.1.16 if it matters. (not related to the topic) What's the point of having two almost similar requests? GET /build/link.to.bad.obs:project/distro/arch/_repository?binary=foo&view=cpio and GET /build/ link.to.bad.obs:project/distro/arch/_repository?view=cpio&binary=foo (AJAX) Regards, Ed -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

9 years, 6 months

[opensuse-buildservice] Out-of-memory on OBS issue for Chromium

by Raymond Wooninck

Hi, As you know I am building updated for Chromium in network:chromium. Lately I have the situation where constantly Chromium is failing for the same target with memory issues. In this repo I am building the same Chromium release for openSUSE 11.4, 12.1, Factory and Tumbleweed for both 32bit and 64bit. Lately only the 64bit for Factory is failing with the following error during the last link process: [20815.308502] Out of memory: Kill process 8630 (ld) score 907 or sacrifice child [20815.309227] Killed process 8630 (ld) total-vm:2865340kB, anon-rss:968844kB, file-rss:0kB collect2: ld terminated with signal 9 [Killed] make: *** [out/Release/chrome] Error 1 It is strange for me that this only happens with building for 64bit Factory and all others are finishing normally. Is there anything that I can do to get this build ? Or am I constantly having bad luck with ending up on the wrong build node for this particular target ? Thanks Regards Raymond -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

9 years, 6 months

[opensuse-buildservice] RFC: patches for SB2 integration into OBS for better cross compilation,

by Carsten Munk

Hi all, I'd like to request comments and review on my upcoming patches which makes it possible to integrate SB2 (Scratchbox2, not related to Scratchbox1 in usage or code) into OBS for much cleaner, flexible and faster cross compilation approaches that can be utilized in multiple distributions. I'd like to emphasise that this approach is currently being used to cross compile entire Mer core in production (http://www.merproject.org), 300+ packages across X86, several ARM architectures and MIPS as well, with no visible drawbacks[1]. I've done private experiments that show it is entirely possible to accelerate OpenSUSE ARM with the same methods and the approach has been done in such a way it can be utilized in other OS'es besides Mer with ease as well. We currently accelerate cross builds as deepily as being able to do autoconf/automake/autoreconf accelerated without ill effects for normal perl scripts (30+ seconds down to 2 really helps), so a sample 'acl' for ARM build is down to 65 seconds accelerated with chroot setup, rpmbuild and rpmlint (19 native x86). What is Scratchbox2 [2] ? (from man page:), Scratchbox2 creates an environment with essential differences to the host OS environment: First, a virtual file system view is presented to the applications. In practise that means that the file names (paths) which an application uses may be modified before the OS does its operations; applications observe a different file system that what the real file system is. For example, common directories like /bin, /usr/lib and /lib can be changed to point to target-specific directories, which contain files for a different CPU architecture than what the host has. Second, scratchbox2 makes execution of foreign binaries completely transparent. Target's binaries can be executed on the host just as if they were host's binaries; scratchbox2 will start a CPU transparency method automatically whenever needed (Qemu is typically used for this). This is being done without the use or need for binfmt_misc setup. [see [3] for more technical info] SB2 is in use in many different projects such as Maemo SDK+, Tizen platform SDK and many other places and is solid and works. There has been developed specific 'modes' for OBS build usage, you can see some of these at http://maemo.gitorious.org/scratchbox2/scratchbox2/blobs/2.3_development/mo… as an example of such and how easy it is to add additional acceleration. Now, on to the patches -- I'm touching three components, osc, obs-build, open-build-service, with the most invasive patches in 'obs-build'. Please review the following commits: https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b6928991… https://github.com/stskeeps/open-build-service/commit/7fced08b7c2eecf93e82b… https://github.com/stskeeps/osc/commit/f0ba509e308d630345d0e064d7aa3856c5ae… To understand the logic/approach in these patches: * It has been a priority to not alter behavior of normal builds when SB2 is not in usage, as to not be too invasive a patch * SB2 deals with a host/tools directory and a target directory in it's mappings and the patches seek to make this division when SB2 is enabled. When running with SB2, the primary file system seen is the target, with accelerated tools from / used. * Instead of utilizing chroot command everywhere, a wrapper has been made, called enter_target, see https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b6928991… - It classifies chroot calls into three kinds, needroot, needuser and needscript. needroot implies that root is needed to run the command, needuser implies that we should 'su' to the user to run the command, and needscript is needed to run su to the user with '-s' parameter. - Most of the changes within the patch has been rewrites in order to switch from chroot calls to enter_target. When SB2 is not enabled, these are translated straight to chroot / su / su -s calls. * There has been introduced the concept of a 'target', and we split BUILD_ROOT contents into being under BUILD_ROOT and BUILD_TARGET. When SB2 is not enabled, BUILD_ROOT=BUILD_TARGET=BUILD_ROOT, in order to not change behavior. Most of the patches are related to putting some things under BUILD_TARGET instead of BUILD_ROOT * There has been a prjconf item "SB2install:" added for SB2-needed dependencies (like Preinstall) * There has been added a prjconf item "SB2flags:", which, if exists, will activate SB2 enablement in the 'build' script, and 'getsb2flags' script to extract this item from prjconf, https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b6928991… * If SB2 is enabled, the following behaviour change will happen: - If running in chroot mode, it will switch to 'sb2' VM type, and run a specific init script that sets up SB2, in order to share code better. https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b6928991… - enter_target will be utilizing SB2 in order to run commands instead of 'chroot'. At first initialization a SB2 target will be set up and sessions related to faster cross compilation - BUILD_TARGET will change to /target and /target will be made - Packages will get preinstalled/installed into /target, except SB2install: packages which will get preinstalled into / -- this will typically be X86 binaries - A SB2 'target' will be set up, with / as the host and /target as the sysroot/target, https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b6928991… - SB2flags setting will determine a number of things related to SB2 target configuration: https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b6928991… --toolchain -- the cross compiler from / which should be used for this build --installmode -- the SB2 mode that should be used to install RPMs with --defaultmode -- the SB2 mode that should be default (read: to do builds with) --mappingmethod -- we currently have three mapping methods, C, Lua and Both, this will get removed eventually and become C by standard --bootstrap -- don't pass sysroot=/ to the cross compiler, useful for bootstrapping a target --qemu -- what QEMU binary should be in use to run target binaries (qemu-arm, qemu-mips), MUST be a dynamic executable, not static --infologs -- request that info logs are being made, can be fetched from /home/abuild/sb2_logs afterwards. Intended to be able to be picked up like rpmlint.log is right now. These can be used to generate graphs like http://releases.merproject.org/~carsten/rpm.pdf and with process accounting, be able to say how much time was wasted running in QEMU, etc --debug -- full debug logs Known issues: * There is an issue with shell quoting in the chroot wrapper so RPMIDFMT handling won't work, this is being worked on, but it doesn't affect general building * We should be utilizing multiple dependancy trees as proposed by Daniel instead of SB2install, in order to have a sane way of cross installing packages * We can possibly move to a scenario where we have multiple /opt/cross/ targets with multiple dependancy trees, instead of one /target * Work to get SB2 working for Debian packages should be done Current implementation in Mer: * We have a qemu-usermode package built (http://gitweb.merproject.org/gitweb?p=mer-core/qemu-usermode.git;a=tree ) which is dynamically linked, not statically, binfmt_misc not enabled * We have scratchbox2 package built, http://gitweb.merproject.org/gitweb?p=mer-core/scratchbox2.git;a=tree * We have a standard cross compiler built, http://gitweb.merproject.org/gitweb?p=mer-core/gcc.git;a=blob;f=cross-armv6… * We have an injection package, sb2-tools which gets exported with baselibs.conf into target scheduler, http://gitweb.merproject.org/gitweb?p=mer-crosshelpers/sb2-tools-template.g… -- this practically is an RPM that contains a X86 root file system with qemu, cross compiler, sb2, autoconf, perl, etc. - Should be done in a cleaner way (is quite ugly at the moment) with multiple dependancy trees. These x86 binaries are -unmodified-, no patchelf involved. Enabling SB2 is as easy as: %if %{_cross_sb2_enabled} SB2install: sb2-tools-%{_my_port_arch}-inject SB2flags: --toolchain %{_my_port_crosscompiler} --qemu %{_my_port_qemu} --mappingmethod C --defaultmode obs-rpm-build+pp %endif Any reviews, questions, constructive criticism more than welcome. I want to do some more testing on top of my 'master' rebase, but my aim is to submit this merge request in middle of next week. [1] http://webui-ci.tspre.org , make account and peek at Core:armv6l, Core:armv7hl, Core:mipsel, Core:i586 [2] http://maemo.gitorious.org/scratchbox [3] http://maemo.gitorious.org/scratchbox2/scratchbox2/blobs/2.3_development/do… BR Carsten Munk Imogen Software -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

9 years, 6 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Build Service February 2012