please give-back atlas until it is successfully built everywhere

Hi, I don't know if Sebastien already sent this request: gb atlas_3.8.4-9.1 . armhf s390 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. Your new version has already failed on armhf and s390. > The core pr

Re: please give-back atlas until it is successfully built everywhere #2

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 -- To UNSUBSCRIBE, email to debi

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 +0

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.

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 possi

Re: please give-back atlas on wheezy-proposed-updates until it is successfully built everywhere

On 2013-05-28 20:35, Adam D. Barratt wrote: > On Tue, 2013-05-28 at 17:39 +0200, Andreas Beckmann wrote: >> (Is there another flag needed to denote the target "wheezy"? I don't see >> anything in http://release.debian.org/wanna-build.txt) > > See the first i

Re: please give-back atlas on wheezy-proposed-updates until it is successfully built everywhere

n sid over the last two years (but they produced failures as well), while "alwyn" and "antheil" usually failed. Andreas On 2013-05-28 17:39, Andreas Beckmann wrote: > We have to do it again. The last build of atlas didn't finish everywhere > in time for the release a

give-back flann on armel

gb flann_1.8.4-2 . armel that now builds cleanly against boost 1.54 (the failure was against 1.49) 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/

please give-back yade on amd64

gb yade_1.05.0-2+b1 . amd64 . (is that the correct syntax for retrying a binNMU?) I could not reproduce the ICE while rebuilding yade with the sid toolchain as of today. Andreas -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Cont

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.

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

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-grap

what is blocking nvidia-graphics-drivers/experimental [amd64, i386]?

Hi, nvidia-graphics-drivers/experimental [non-free] seems to be stuck somehow on amd64 and i386 - it's in Needs-Build state for nearly three months now ... https://buildd.debian.org/status/package.php?p=nvidia-graphics-drivers&suite=experimental Andreas -- To UNSUBSCRIBE, email to debian-wb-te

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

give-back itksnap on i386

Hi, please gb itksnap_3.2.0-3 . i386 I could successfully build it locally, some dependency must have been fixed in the meanwhile. Cheers, Andreas

give-back mapnik on kfreebsd-amd64

gb mapnik_3.0.9+ds-1 . kfreebsd-amd64 That failed 86 days ago with an ICE, let's hope a new compiler version fixed this inbetween. 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

gb mercurial-buildpackage on i386, kfreebsd-i386

gb mercurial-buildpackage_0.10.1 . i386 kfreebsd-i386 That build failed more than a year ago with [ "0.10.1" = ] /bin/sh: 1: [: =: argument expected I cannot reproduce that in a current sid i386 pbuilder environment. 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&suite=unstable 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 b

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 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 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&suite=unstable asterisk build-depends on missing: - kfreebsd-amd64:libvpb1 asterisk build-depends on missing: - kfreebsd-i386:libvpb1 but it has Build-Depends: libvp

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 r-cran-batchjobs

Hi, gb r-cran-batchjobs_1.6-1 . kfreebsd-i386 The failure was probably due to unlucky timing of a r-cran-checkmate upload. Andreas

dash is stuck on hurd-i386

Hi, could someone gently kick dash on hurd-i386 which is in "Building" state for a month now ... Thanks Andreas

reniced [all] is stuck in Uploaded state

Hi, the reniced arch:all build for sid is stuck in "Uploaded" state for more than a week now, please push it forward or give it back or do whatever is appropriate to unblock it :-) https://buildd.debian.org/status/package.php?p=reniced&suite=unstable Andreas

give-back mame:all on x86-csail-02

gb mame 0.173-6 . all Can this give-back be targeted to the x86-csail-02 buildd? There the package built successfully in the past, while it always failed on x86-bm-01. It usually times out while linking a (gigantic) binary, which probably needs tons of memory. Andreas

give-back kinect-audio-setup on kfreebsd

gb kinect-audio-setup_0.5-1 . kfreebsd-amd64 kfreebsd-i386 The missing libusb symbol is now provided by kfreebsd-libs. 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

give-back ant, proj on kfreebsd

Please give-back gb ant_1.9.7-3 . kfreebsd-amd64 kfreebsd-i386 gb proj_4.9.2-3 . kfreebsd-amd64 kfreebsd-i386 the FTBFS should have been fixed in openjdk-8. There are probably more packages to be given back if you have the possibility to quickly grep for GNU/kFreeBSD is not a supported OS pl

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

give-back google-perftools_2.2.1-0.3 on i386

Hi, I cannot reproduce the FTBFS locally, so please gb google-perftools_2.2.1-0.3 . i386 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 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

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 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

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

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,

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/fe

give-back ceph on armhf

gb ceph_10.2.5-7.1 . armhf The build on hartmann failed with objcopy: debian/ceph-mds/usr/bin/cephfs-journal-tool: unable to initialize compress status for section .debug_loc objcopy:debian/ceph-mds/usr/bin/cephfs-journal-tool: Input/output error Does this indicate it ran out of disk sp

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 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 in tpu

gb mariadb-10.1_10.1.23-9+deb9u1 . mips64el . stretch that picked again one of the problematic buildds ... Andreas

Re: give-back mariadb-10.1 in tpu

On 2017-06-09 10:39, James Cowgill wrote: > On 09/06/17 07:06, Andreas Beckmann wrote: >> gb mariadb-10.1_10.1.23-9+deb9u1 . mips64el . stretch >> >> that picked again one of the problematic buildds ... > > Done. Hopefully it will pick a good buildd this time. Unfor

give-back appstream-generator on armhf

gb appstream-generator_0.6.5-1 . armhf looks like the previous attempt got caught in the ldc transition 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: Unm

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 ne

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

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

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

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