Re: please give-back atlas until it is successfully built everywhere #3
Third round, folding in second round: (armhf failed again) gb atlas_3.8.4-9.1 . armel armhf On 2013-04-30 09:50, Andreas Beckmann wrote: Second round: gb atlas_3.8.4-9.1 . armel On 2013-04-29 22:49, Kurt Roeckx wrote: On Mon, Apr 29, 2013 at 10:27:55PM +0200, Andreas Beckmann wrote: gb atlas_3.8.4-9.1 . armhf s390 Done s390 succeeded, armhf still building Andreas Andreas -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517fa1ca.7040...@debian.org
Re: please give-back atlas until it is successfully built everywhere #4
Let's try that again ... On 2013-05-01 20:38, Kurt Roeckx wrote: On Tue, Apr 30, 2013 at 12:49:46PM +0200, Andreas Beckmann wrote: Third round, folding in second round: (armhf failed again) gb atlas_3.8.4-9.1 . armel armhf gb atlas_3.8.4-9.1 . armel armhf Andreas -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51821e5d.2060...@debian.org
please give-back atlas on wheezy-proposed-updates until it is successfully built everywhere
Hi, gb atlas_3.8.4-9+deb7u1 . armel armhf kfreebsd-amd64 mipsel We have to do it again. The last build of atlas didn't finish everywhere in time for the release and therefore didn't migrate, so we are now going for wheezy r1 ... if sparc needs again 14 days and does not fail, this should be possible. (Is there another flag needed to denote the target wheezy? I don't see anything in http://release.debian.org/wanna-build.txt) On 2013-04-29 16:44, Sébastien Villemot wrote: Note that ATLAS is a complicated beast, and does not always compile at the first time. [...] The core problem is that the build system is not entirely deterministic (it runs time benchmarks, and if there is too much variance across benchmarks, then it fails). I hope to improve the situation for Jessie, but for Wheezy there is no other way than asking give backs until it compiles on all arches. Thanks Andreas -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a4cfcc.8020...@debian.org
please give-back gpsshogi on i386
Hi, gb gpsshogi_0.6.0-2 . i386 The failed build looks like a mixed boost1.49 + boost1.54 build that exploded somewhere. Maybe some dependency was not up-to-date yet. I cannot reproduce this in pbuilder, which will only install boost1.54 packages today and successfully builds for amd64 and i386. If this succeeds, #725626 can be closed. Andreas -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f42ed6.2080...@debian.org
give-back flush on armel
gb flush_0.9.12-3+b1 . armel the last build failed in November with statistics_window.cpp:214:1: fatal error: error writing to /tmp/ccyhmn3K.s: Read-only file system } ^ compilation terminated. Cannot create temporary file in /tmp/: Read-only file system make[4]: *** [flush-statistics_window.o] Aborted Andreas -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f57c45.1030...@debian.org
Re: please update sid chroots to patch (2.7.5-1)
On 2015-03-19 15:11, Andreas Beckmann wrote: Hi, please ensure that the buildd sid chroots have the latest version of patch (2.7.5-1) installed (there are some issues with 2.7.4), thereafter gb nvidia-graphics-drivers_340.76-1 . amd64 i386 gb nvidia-graphics-drivers_343.36-2 . amd64 i386 . experimental (patch should be updated on the buildds for all arches, these are just the two where I actually encountered problems) Thanks Are there any news on this issue? Andreas -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55192ddc.3070...@debian.org
gb insighttoolkit4 on i386
gb insighttoolkit4_4.8.2-3 . i386 Please give-back insighttoolkit4 on i386, I couldn't reproduce the ICE in a local rebuild. Compiler version is the same, so maybe something else caused it. Andreas
Re: check status of tsocks on !linux
Thanks for analyzing the problem! On 2016-02-27 22:12, intrigeri wrote: > Does this affect any release architecture? No I doesn't. I just filed #816136 against tsocks to document this problem, and #816137 against dpkg for creating the broken package in the first place. There should be another bug against wanna-build (or whatever else) for adding yet another state "Rejected", so packages don't stay at "Uploaded" forever if they cannot move on to "Installed". Andreas
check status of tsocks on !linux
Hi, could someone check the status of tsocks on hurd and kfreebsd, the packages are listed as "Uploaded" for "41 days". Something seems to need a little shaking to get them "Installed" :-) https://buildd.debian.org/status/package.php?p=tsocks=unstable Andreas
gb r-bioc-biostrings on mips
gb r-bioc-biostrings_2.38.0-1 . mips mips64el the package has an insufficiently versioned B-D on r-bioc-xvector (#815429), but now a sufficient version is available on all platforms, so a mips rebuild should succeed in sid. Andreas
give-back mosquitto
Hi, please gb mosquitto_1.4.8-1+b1 . mips64el sh4 These builds previously failed with /usr/include/libwebsockets.h:176:16: fatal error: uv.h: No such file or directory which should now be fixed in libwebsockets-dev. Andreas
give-back itksnap
Hi, let's retry itksnap, it builds fine for me on both architectures in pbuilder. gb itksnap_3.4.0-1+b1 . amd64 i386 Thanks Andreas
give-back kdiff3
Hi, please gb kdiff3_0.9.98-2 . i386 armhf armel I could not reproduce the make[3]: *** No rule to make target '/usr/lib/libsoprano.so', needed by 'src-QT4/kdiff3'. Stop. problem in a local i386 build. Andreas
give-back grep on amd64
Hi, please gb grep_2.24-1 . amd64 I cannot reproduce that test failure locally. Andreas
spurious BD-U for asterisk on kfreebsd-*
Hi, asterisk in kfreebsd-* is incorrectly in BD-Uninstallable: https://buildd.debian.org/status/package.php?p=asterisk=unstable asterisk build-depends on missing: - kfreebsd-amd64:libvpb1 asterisk build-depends on missing: - kfreebsd-i386:libvpb1 but it has Build-Depends: libvpb-dev [linux-any] so this unavailability shouldn't be relevant. The direct dependency problem on the library (instead of the -dev package) looks spurious, too. An 'apt-get build-dep asterisk' worked fine in a chroot on the kfreebsd-amd64 porterbox, the subsequent build was successful. Please push it a bit in the right direction s.t. it starts building again. Andreas
give-back karchive on kfreebsd-*
Hi, gb karchive_5.24.0-1 . kfreebsd-amd64 kfreebsd-amd64 The build should now succeed with the updated pkg-kde-tools. If there is an easy way to grep for similar errors in the failed build logs on kfreebsd-*, you could gb them as well: On 2016-08-11 19:49, Pino Toscano wrote: > Short story long: see changelog of pkg-kde-tools 0.15.22, and basically > just a giveback of the failed sources with errors like > "testdata ... could not be located!" > should bring successful builds again. Andreas
subversion got stuck on hurd-i386
Hi, subversion is in "Building" state for more than 2 months. Please kick it gently s.t. it moves forward. Thanks Andreas
Re: give-back rmysql
On 2017-01-20 17:57, Emilio Pozuelo Monfort wrote: > On 20/01/17 14:46, Andreas Beckmann wrote: >> On 2016-12-22 19:33, Emilio Pozuelo Monfort wrote: >>> On 19/12/16 00:00, Andreas Beckmann wrote: >>>> please try rmysql on mips64el, again >> >> and again, after we finally identified+fixed the bug in >> mariadb-connector-c that caused the FTBFS on mips64el. and again, mariadb-connector-c needed yet another fix for mips64el (this time I verified that it builds on a porter box) gb rmysql_0.10.9-3 . mips64el Andreas
Re: give-back rmysql
On 2017-01-24 22:55, Emilio Pozuelo Monfort wrote: >> gb rmysql_0.10.9-3 . mips64el > > Scheduled. Finally a new error that is out of my control, it built on eller without problems: Error: segfault from C stack overflow Execution halted ERROR: loading failed https://buildd.debian.org/status/fetch.php?pkg=rmysql=mips64el=0.10.9-3=1485299967=0 I think I'll give up here :-( Andreas
Re: give-back rmysql
On 2016-12-22 19:33, Emilio Pozuelo Monfort wrote: > On 19/12/16 00:00, Andreas Beckmann wrote: >> please try rmysql on mips64el, again and again, after we finally identified+fixed the bug in mariadb-connector-c that caused the FTBFS on mips64el. gb rmysql_0.10.9-3 . mips64el Andreas
give-back ruby-dataobjects-mysql
Hi, plese retry ruby-dataobjects-mysql with the latest mariadb-10.1: gb ruby-dataobjects-mysql_0.10.16-2 . armel armhf mips64el mipsel s390x dw ruby-dataobjects-mysql_0.10.16-2 . armel armhf mips64el mipsel s390x . -m "mariadb-server-10.1 (>= 10.1.21)" Thanks Andreas
give-back tar on kfreebsd
gb tar_1.29b-1 . kfreebsd-amd64 kfreebsd-i386 I cannot reproduce the test failure on both porterboxes. Andreas
give-back ceph
Hi, please give-back the ceph binNMU on all architectures where it failed with some spurious ncurses linking error. There is now a newer ncurses version available ... gb ceph_0.80.11-1.1+b1 . ANY Thanks Andreas
give-back dateutils
Hi, dateutils failed on several architectures with rather spurious errors and I can successfully build the package in my pbuilder setup for both amd64 and i386, so let's retry it: gb dateutils_0.4.0-0.2 . amd64 arm64 armel i386 s390x kfreebsd-amd64 and if you want to try ports, too, add m68k ppc64 sh4 Andreas
give-back rmysql
Hi, please try rmysql on mips64el, again, I cannot reproduce the problem in stretch on the porterbox. But wait for a newer dpkg since 1.18.16 in sid cannot install the B-D. gb rmysql_0.10.9-3 . mips64el dw rmysql_0.10.9-3 . mips64el . -m "dpkg (>> 1.18.16)" Thanks, Andreas
give-back ceph on mipsel
gb ceph_10.2.5-7.2 . mipsel This needs a lot of memory ... it built successfully in the past on mipsel-sil-01, mipsel-aql-03 - maybe it could be rescheduled on one of those. Thanks Andreas
give-back mariadb-10.1 on mips64el
gb mariadb-10.1_10.1.24-3 . mips64el that built successfully two times yesterday, but now it got killed with signal TERM after 150 minutes of inactivity while running the tests. Let's hope a different buildd does this better. Thanks Andreas
give-back opensaml2 on kfreebsd
gb opensaml2_2.6.1-1 . kfreebsd-amd64 kfreebsd-i386 seems to build fine with libxmltooling7 1.6.2-1, the failure was with 1.6.0-5. Andreas
give-back shibboleth-sp2 on kfreebsd
gb shibboleth-sp2_2.6.1+dfsg1-1 . kfreebsd-amd64 kfreebsd-i386 with the new opensaml2 built on kfreebsd, these should work now, too. Andreas
give-back xerces-c on hurd
gb xerces-c_3.2.0+debian-2 . hurd-i386 I cannot reproduce the FTBFS on exodar. Andreas
give-back elkcode on kfreebsd
gb elkcode_4.0.15-2 . kfreebsd-amd64 kfreebsd-i386 The /usr/bin/ld: cannot find crtfastmath.o: No such file or directory error is fixed with gcc-7. Andreas
please check node-d3-format/all
Hi, node-d3-format/all is hanging in "Uploaded" state for 47 days now ... Please check what happened there. Thanks Andreas
Re: Bug#903765: nmu: tvc_5.0.3+dfsg-2
On 2018-07-15 10:44, Emilio Pozuelo Monfort wrote: > On 14/07/18 14:25, Andreas Beckmann wrote: >> nmu tvc_5.0.3+dfsg-2 . ANY . experimental . -m "Rebuild against >> libbamtools2.5.1." > Scheduled. Several builds failed with: dpkg-checkbuilddeps: error: Unmet build dependencies: build-essential:native which sounds like a buildd problem. They will need a give-back after the buildds are fixed. I assume other packages will have been affected by that as well, therefore a bigger number of give-backs may be needed - can this be done automatically? Andreas
Re: give-back regina-normal
On 20/01/2020 21.50, Philipp Kern wrote: > On 1/16/2020 2:37 AM, Andreas Beckmann wrote: >> Please give back all failed binNMU builds of regina-normal, >> these have been transient failures. > Doesn't the failure look a little like a not tight enough > build-dependency? So I guess in theory the build-dep could've been > modeled within wanna-build. Alas done. The failed build was against libboost-python1.67.0 that had dropped python2.7 support temporarily (silently breaking rdepends), and regina-normal obviously needs the python2.7 boost bindings (which we know from the improved binary dependencies that we have now). But that's still impossible to express as build dependency. Andreas
node-yarnpkg is stuck in Uploaded state for 50+ days
Hi, please do the right thing to help node-yarnpkg out of the Uploaded state in sid where it is for 50+ days already. Should there be some process that automatically reports stale Uploaded packages after x days? Andreas
give-back regina-normal
gb regina-normal . ANY Please give back all failed binNMU builds of regina-normal, these have been transient failures. Is it possible to do such bulk give-backs with the new self-served give-backs? Doing this for a dozen architectures by hand is cumbersome. Andreas
give-back datovka, bppphyview
gb bppphyview . ANY gb datovka . ANY Please give back all failed binNMU builds of datovka and bppphyview, these have been transient failures. Also include hurd-i386 which is in 'Failed' state and could not be handled by self-served give-backs. Is it possible to do such bulk give-backs with the new self-served give-backs? Doing this for 2 packages x 15 architectures by hand is cumbersome. Andreas
clear extra-depends for pocl/mips64el
Hi, please clear the obsolete (and nowadays unsatisfiable) Extra-Depends: gcc-7 (>= 7.2.0-3) for pocl om mips64el. Thanks Andreas
