Re: Build fails for liboauth on all architectures because of the tests

[Julien Cristau]

On Fri, Apr 15, 2022 at 11:13:54AM -0400, Nicolas Mora wrote:
> Hello team,
> 
> I'm trying to figure out why libauth2's package build fail on all mandatory
> architectures when the same build and manual test run fine on my machine:
> https://buildd.debian.org/status/package.php?p=liboauth2=experimental
> 
> For what I see, a tcp socket bind fails at the beginning (a http server),
> then multiple test below depending on this http server fail in cascade.
> 
> The http server listens on port  and listens to INADDR_ANY, I don't know
> if one of these is the cause of the problem.
> 
> Do you have an idea on how to reproduce and solve this issue?

You shouldn't assume that port  (or any given port) is free.  Either
use a random high port, or let the kernel choose it for you.

(We don't currently isolate the build environment network from the
host's, and  is in use on those machines.)

Cheers,
Julien

Re: Fwd: buildd host x86-conova-01 - connections to localhost during build?

[Julien Cristau]

On Fri, Oct 23, 2020 at 09:35:09AM +0200, Kurt Roeckx wrote:

> Date: Thu, 22 Oct 2020 21:20:37 -0700
> From: Nicholas Breen 
> To: am...@buildd.debian.org
> Subject: buildd host x86-conova-01 - connections to localhost during build?
> User-Agent: Mutt/1.9.4 (2018-02-28)
> 
> Hello,
> 
> Part of the test suite for src:gromacs launches a MPI process that
> connects to localhost.  On the recently (?) added buildd x86-conova-01
> *only*, this fails:
> 
> 2: Test command: /usr/bin/mpiexec.mpich "-np" "2" "-host" "localhost" 
> "/<>/build/mpich/bin/testutils-mpi-test" 
> "--gtest_output=xml:/<>/build/mpich/Testing/Temporary/TestUtilsMpiUnitTests.xml"
> [...]
> 2: MPID_nem_tcp_init(373).: gethostbyname failed, localhost 
> (errno 0)
> 
> This test passes on the other amd64 buildd hosts and the hosts for other
> architectures.  The build logs don't narrow down the exact problem any
> further than that.  Can x86-conova-01 please be configured similarly to
> the other hosts in this regard, or alternatively, can gromacs be
> blacklisted on it?
> 
> I anticipate the same would happen on an i386 build, but it hasn't come
> up yet.
> 
That is probably related to x86-conova-01 not having a (non-loopback) ipv4 
address.

See https://lists.debian.org/debian-devel/2020/07/msg00070.html

Cheers,
Julien

Re: gokey mips build killed after too short timeout

[Julien Cristau]

On Mon, Jul 15, 2019 at 12:36:39 +0200, Benjamin Drung wrote:

> Upstream ask in this bug report if the buildd run on real hardware of
> virtualized. The builds run directly on the hardware, don't they? 
> https://db.debian.org/machines.cgi?host=mipsel-aql-01 doesn't say
> anything about virtualization.
> 
The mips* buildds are bare metal, yes.

Cheers,
Julien

Re: autopkgtest for security archive

[Julien Cristau]

On Wed, Mar 27, 2019 at 10:04:47 +0100, Philipp Kern wrote:

> Hi,
> 
> On 3/26/2019 10:23 PM, Paul Gevers wrote:
> > Kind ping for the question below.
> 
> I am not sure what you are asking. Yes, buildds for security have access
> to the embargoed queue and obviously that access cannot reasonably be
> shared. Technically I think it's in the purview of ftp-master to approve
> new credentials (in this case together with Security team) and for DSA
> to provision them. As far as I remember we rely on IP whitelisting today
> - at least 99builddsourceslist does not contain logic for passwords
> (anymore) and I'm pretty sure DSA autogenerates that list into
> ftp-master's apache config. Unfortunately I could not find that
> configuration in DSA's Puppet tree (nor on coccia, but this is about
> security-master) from a quick glance. I know I have seen it in the past,
> but I don't recall where. In any case those two teams are the ones to ask.
> 
The apache config uses the macro defined in
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/blob/master/modules/roles/templates/dakmaster/conf-builddlist.erb

Cheers,
Julien

Re: gokey mips build killed after too short timeout

[Julien Cristau]

On Mon, Jul 15, 2019 at 11:47:09 +0200, Benjamin Drung wrote:

> Am Montag, den 15.07.2019, 11:42 +0200 schrieb Julien Cristau:
> > On Mon, Jul 15, 2019 at 11:18:11 +0200, Benjamin Drung wrote:
> > 
> > > Hi,
> > > 
> > > The gokey package has a test suite that takes very long to execute
> > > on
> > > slow architectures. I had to set the golang test timeout to six
> > > hours,
> > > because the gokey tests takes 11408.183 s (= 190 min) on
> > > minkus.debian.org (mips porter box) [1].
> > > 
> > > The gokey 0.1.0-1 build on mipsel was killed after 150 minutes of
> > > "inactivity". [2] Can you trigger the build again and increase the
> > > kill-timeout?
> > > 
> > That doesn't seem appropriate, IMO.  That test should be made faster
> > or
> > disabled.
> 
> All tests take 72 seconds in total on amd64. My guess it that it
> somehow connected to entropy.
> 
The host has a decent amount of entropy, so I doubt it:
https://munin.debian.org/debian.org/mipsel-aql-01.debian.org/entropy.html

Cheers,
Julien

Re: gokey mips build killed after too short timeout

[Julien Cristau]

On Mon, Jul 15, 2019 at 11:18:11 +0200, Benjamin Drung wrote:

> Hi,
> 
> The gokey package has a test suite that takes very long to execute on
> slow architectures. I had to set the golang test timeout to six hours,
> because the gokey tests takes 11408.183 s (= 190 min) on
> minkus.debian.org (mips porter box) [1].
> 
> The gokey 0.1.0-1 build on mipsel was killed after 150 minutes of
> "inactivity". [2] Can you trigger the build again and increase the
> kill-timeout?
> 
That doesn't seem appropriate, IMO.  That test should be made faster or
disabled.

Cheers,
Julien

Re: Please gb ktexteditor/armhf

[Julien Cristau]

[cc += debian-arm]

On 09/09/2018 11:15 PM, Pino Toscano wrote:
> Hi,
> 
> the 5.49.0-2  build of ktexteditor failed because two unit tests
> SIGBUS'ed. OTOH, armel worked, and my tests on the abel armhf porterbox
> worked fine. (While on harris GCC ICEd really a lot, and I gave up
> after the 4 ICE in a row...).
> 
> So please giveback ktexteditor_5.49.0-2/armhf, hoping it was some kind
> of transient failure...
> 
I doubt it's transient failure (it failed again), more likely to be the
fact that arm-arm-01 is arm64 hardware.  You may want to try amdahl's
armhf chroot rather than abel.  The arm porters may be able to help too.

Cheers,
Julien

Re: Please give back geary on failed architectures

[Julien Cristau]

On 09/12/2018 03:05 AM, Jeremy Bicha wrote:
> On Tue, Sep 11, 2018 at 6:36 PM Philipp Kern  wrote:
>> On 10.09.2018 12:27, Jeremy Bicha wrote:
>>> There was a bug in libsoup2.4 that caused geary to FTBFS on several
>>> architectures. Please give it back there.
>>>
>>> And let's try libsoup2.4 again on alpha since the previous version built.
>>>
>>> dw geary_0.12.4-1 . alpha . -m 'libsoup2.4 (>= 2.64.0-2)'
>>> gb geary_0.12.4-1 . mips64el hppa powerpcspe sh4
>>> gb libsoup2.4_2.64.0-2 . alpha
>>
>> Done.
>>
>> Kind regards
>> Philipp Kern
> 
> Please clear the depwait for alpha. I didn't realize that it needed to
> be a binary package (instead of a source package). libsoup2.4 has
> built and been installed on alpha now.
> 
Done.

Cheers,
Julien

Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Julien Cristau]

Control: severity -1 wishlist

On 04/12/2018 02:10 PM, Guillem Jover wrote:

Control: reassign -1 buildd.debian.org

Hi!

On Thu, 2018-04-05 at 17:43:58 +0200, Jean-Michel Vourgère wrote:

On Friday, 30 March 2018 15:02:31 CEST Chris Lamb wrote:

[ https://lists.debian.org/debian-security/2017/05/msg00011.html ]


On Friday, 30 March 2018 20:15:33 CEST Sven Joachim wrote:

[ https://bugs.debian.org/843773 ]


Thanks a lot guys for pointing out that issue!

Basically, when doing bin-nmus, we really want to bump the mtime of the
distributed files. Not doing so results in some backups programs (rsync...) to
loose updates. Other programs restarting services on libraries updates
(needrestart...) would also be affected.


So, during compilation:
SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
because it breaks Multi-Arch:same on bin-nmu.

During dpkg-deb (:
SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
because it would break software relying on files mtime.

Doh!

In https://bugs.debian.org/843773#75 Ian Jackson propose to introduce a
BUILD_DATE_EPOCH (= time of sbuild binnmu invocation) be prefered over
SOURCE_DATE_EPOCH by dpkg-deb.

That would work, wouldn't it?


Please, see my reply at . This is
really a fundamental problem with binNMUs+multiarch-refcounting or how
they are being issued. :)

Indeed.  I suspect eventually we'll make no-change sourceful uploads 
less labor intensive and binNMUs will go away, but we're not there right 
now.


Cheers,
Julien

Re: multi-arch:same failures when bin-nmus changelog dates are not the same

[Julien Cristau]

On 03/29/2018 06:35 PM, Jean-Michel Vourgère wrote:
> Some thoughs:
> 
> On arm64 [1] the binnmu .buildinfo contains:
> Environment:
>  DEB_BUILD_OPTIONS="parallel=3"
>  LC_ALL="POSIX"
>  SOURCE_DATE_EPOCH="1522153653"
> 
> while on armhf [2] the binnmu .buildinfo contains:
> Environment:
>  DEB_BUILD_OPTIONS="parallel=4"
>  LC_ALL="POSIX"
>  SOURCE_DATE_EPOCH="154789"
> 
> /s/b/dpkg-buildpackage does not overwrite SOURCE_DATE_EPOCH if it is already 
> defined in the environment.
> Also, it looks like it does not parse the changelog.Debian.$arch that are bin-
> nmu specifics.
> 
It parses debian/changelog, which is where sbuild writes the binNMU info
in the unpacked source.  There's no changelog.Debian.$arch at that point
anywhere.

> Could it be that the wanna-build stack wrongly define the variable before 
> calling dpkg-buildpackage?
> 
Nope.

Cheers,
Julien

Re: multi-arch:same failures when bin-nmus changelog dates are not the same

[Julien Cristau]

On 03/29/2018 02:41 PM, Jean-Michel Vourgère wrote:
> Hello
> 
> My package rrdtool [1] got some multi-arch failures since last bin-nmu.
> 
> The problem is that pod2man uses the changelog date to generate the man 
> footer, and that date is no longer the same on all architectures !
> 
> /usr/share/doc/librrds-perl/changelog.Debian.arm64.gz contains
> rrdtool (1.7.0-1+b1) sid; urgency=low, binary-only=yes
>   * Binary-only non-maintainer upload for arm64; no source changes.
>   * Rebuild without ruby2.3 support.
>  -- arm Build Daemon (arm-conova-01)  conova...@buildd.debian.org>  Tue, 27 Mar 2018 12:27:33 +
> 
> 
> while /usr/share/doc/librrds-perl/changelog.Debian.armhf.gz contains
> rrdtool (1.7.0-1+b1) sid; urgency=low, binary-only=yes
>   * Binary-only non-maintainer upload for armhf; no source changes.
>   * Rebuild without ruby2.3 support.
>  -- armhf / armel Build Daemon (hoiby)  
>  
> Wed, 28 Mar 2018 08:13:09 +
> 
> 
> as a result, /usr/share/man/man3/RRDs.3pm.gz differs on arm64 architecture:
> .TH RRDs 3pm "2018-03-27" "perl v5.26.1" "User Contributed Perl Documentation"
> and on armhf architecture:
> .TH RRDs 3pm "2018-03-28" "perl v5.26.1" "User Contributed Perl Documentation"
> 
> Ultimately, this makes package librrds-perl is no longer co-installable. 
> Multi-arch hinter says:
> librrds-perl conflicts on /usr/share/man/man3/RRDs.3pm.gz on armhf <-> amd64, 
> arm64, armel, and 6 more
> 
> Please advise how to proceed!
> 
Make the manpage contents not depend on the build date?

Cheers,
Julien

Re: Python buildd (was Re: let me help you with progressing bikesheds)

[Julien Cristau]

On 03/27/2018 09:35 AM, Philipp Kern wrote:
> That all said: I'm happy to brainstorm and to implement proposed
> solutions. Right now that seems to require more infrastructural changes
> though and I'd rather focus on getting rid of buildd itself first.
> 
That's fair.

Cheers,
Julien

Re: Python buildd (was Re: let me help you with progressing bikesheds)

[Julien Cristau]

On 03/22/2018 10:31 PM, Aurelien Jarno wrote:
> To do more tests I agree that we should deploy it on more buildds. For
> *this phase*, I believe enabling lingering and deploying it by hand is
> the best. Is it something acceptable?
> 
Sounds ok to me, though I'd prefer if the buildd user (as in the user
the service runs as) didn't have write access to the deployed code or
configuration.  Maybe that's a later step though.

Cheers,
Julien

Re: request: check installability of Depends before building

[Julien Cristau]

On 12/03/2017 07:38 PM, Afif Elghraoui wrote:
> 
> 
> على السبت  2 كانون الأول 2017 ‫06:14، كتب Julien Cristau:
>> On Wed, Oct 18, 2017 at 00:40:12 -0400, Afif Elghraoui wrote:
>>
>>>
>>> ~~~https://anonscm.debian.org/cgit/debian-med/sga.git/tree/debian/control
>>> Priority: optional
>>> Build-Depends: debhelper (>= 10),
>>>dh-autoreconf,
>>>libsparsehash-dev,
>>>zlib1g-dev | libz-dev,
>>>libbamtools-dev,
>>>gawk,
>>>help2man,
>>> # Run-Time Depends
>>> # (to prevent building on architectures where it won't be installable)
>>>samtools,
>>>python,
>>>python-ruffus,
>>>python-pysam
>>> Standards-Version: 4.1.0
>>> ~~~
>>>
>>> ...which is an abuse of the build-depends field since those at the
>>> bottom are not actually needed for building the package.
>>>
>> I think this is actually a reasonable use of build-depends.
> 
> How? They are packages not needed during the build process. Do you think
> this needs a special build profile?
> 
No, I don't?  What problem are you actually trying to solve?

Cheers,
Julien

Re: buildd chroot creation: who should get notified of failures?

[Julien Cristau]

On Thu, Dec 21, 2017 at 10:45:52 +0800, Paul Wise wrote:

> Hi folks,
> 
> Occasionally the buildd (and porterboxen) fail to debootstrap updated
> chroots. Sometimes these are Internet problems, sometimes local network
>  problems, sometimes mirror problems, sometimes archive problems. These
> mails go to DSA but as far as I can tell, we always ignore them, I
> certainly do. I have included below a sample of the error messages
> since September so folks can get an idea of the errors.
> 
I think they should keep going to DSA and we should take care of them.

Cheers,
Julien

Re: Please give back golang-1.8 (1.8.3-1) on s390x

[Julien Cristau]

On Sun, Jun 25, 2017 at 08:42:17 -0600, Anthony Fok wrote:

> On Sat, Jun 24, 2017 at 2:58 PM, Aurelien Jarno  wrote:
> > On 2017-06-24 11:15, Anthony Fok wrote:
> >> Or, better yet, is there a way to find out what went wrong on
> >> zemlinsky?  Is it an older machine with an older CPU that does not
> >> support some newer CPU instructions?  (Sorry, I know nothing about
> >> s390x and I am likely completely wrong.)
> >
> > That is actually the problem. On s390x golang requires a higher ISA than
> > the one Debian targets. I have started to patch golang-1.7 to avoid these
> > new instructions a few months ago, but upstream is not interested by
> > supporting older CPUs and keep adding more usage of new instructions.
> 
> Thank you for your detailed explanation, and thank you for your
> efforts in trying to solve it.
> 
> But yeah, I guess golang users on s390x would just have to accept the
> fact that they need a newer CPU.  Thankfully, the majority of Debian's
> s390x machines (buildd and porterbox), 3 out of 4, support the newer
> instructions.  :-)
> 
I don't think that's acceptable.  We should not ship packages that won't
work on the baseline platform for each architecture.  We should either
fix those packages, stop shipping them, or raise the baseline.

Cheers,
Julien

Re: give-back request for aspectj-maven-plugin/1.10-1

[Julien Cristau]

On Wed, Sep  6, 2017 at 14:56:44 +0200, Emmanuel Bourg wrote:

> Hi,
> 
> The source upload of aspectj-maven-plugin/1.10-1 failed to build due to
> a bug in the Maven tool chain that is now fixed. Could you please give
> back the package to attempt a new build?
> 
>   gb aspectj-maven-plugin_1.10-1 . ANY . unstable . -m "Rebuild request after 
> fixing the Maven plugins"
> 
Two things:
- ANY is "every arch except all", so for an arch:all package it's not
  what you want
- gb doesn't take a changelog message since there's not actually a new
  version

Anyway, looks like this got given back and built 3 months ago.

Cheers,
Julien

Re: Please give-back lcalc on kfreebsd-*

[Julien Cristau]

On Tue, Sep  5, 2017 at 09:05:02 +0100, Tobias Hansen wrote:

> Hello,
> 
> lcalc failed to build on kfreebsd-* due to bug #833829 in gcc. Since the
> bug is fixed, please let's give it another go.
> 
>   gb lcalc_1.23+dfsg-6 . kfreebsd-amd64 kfreebsd-i386
> 
Given back.

Cheers,
Julien

Re: request: check installability of Depends before building

[Julien Cristau]

On Wed, Oct 18, 2017 at 00:40:12 -0400, Afif Elghraoui wrote:

> Hello,
> Currently, we have that packages don't build if any build-dependencies
> are not installable. I'd like to suggest that we do the same for
> run-time dependencies.
> 
> What ends up happening is that the package itself may build, but then it
> never migrates to testing because it's not installable on some of the
> architectures that it built on due to some run-time dependency being
> missing.
> 
> Examples of this that I know of offhand are canu (due to its indirect
> dependency on libssw via mhap) and sga.
> 
> If you look at d/control for sga, it looks like this:
> 
> ~~~https://anonscm.debian.org/cgit/debian-med/sga.git/tree/debian/control
> Priority: optional
> Build-Depends: debhelper (>= 10),
>dh-autoreconf,
>libsparsehash-dev,
>zlib1g-dev | libz-dev,
>libbamtools-dev,
>gawk,
>help2man,
> # Run-Time Depends
> # (to prevent building on architectures where it won't be installable)
>  samtools,
>  python,
>  python-ruffus,
>python-pysam
> Standards-Version: 4.1.0
> ~~~
> 
> ...which is an abuse of the build-depends field since those at the
> bottom are not actually needed for building the package.
> 
I think this is actually a reasonable use of build-depends.  The Depends
field in source packages can have a number of substvars that would make
any sort of pre-build parsing meaningless.

Cheers,
Julien

Re: Please give back simgear

[Julien Cristau]

On Wed, Nov  8, 2017 at 17:24:44 +0100, Dr. Tobias Quathamer wrote:

> Hi,
> 
> simgear FTBFS on armel/armhf. This is most likely due to the armel/armhf
> handling in openscenegraph-3.4, which should have been fixed now
> (bug #845054).
> 
>  gb simgear_1:2017.3.1+dfsg-2 . armel armhf
> 
Looks like this isn't actually fixed.

Cheers,
Julien

Re: Bug#872635: blacklisting util-linux on ARM Ltd hosted buildds

[Julien Cristau]

On 08/21/2017 03:05 PM, Andreas Henriksson wrote:
> On Mon, Aug 21, 2017 at 02:31:03PM +0200, Julien Cristau wrote:
>> Is it reproducible on abel? 
> 
> Just because I knew someone would ask I ran the test 100.000 times in
> a loop on the porter box last time it happened (arm64) and no it has
> not been reproduced anywhere outside ARM Ltd as far as I'm aware.
> 
You don't seem to be answering my question.  abel is a porterbox, and
it's on the exact same network as the buildds at ARM.

Cheers,
Julien

Re: blacklisting util-linux on ARM Ltd hosted buildds

[Julien Cristau]

On 08/21/2017 10:27 AM, Philipp Kern wrote:
> On 08/21/2017 10:11 AM, Andreas Henriksson wrote:
>> The util-linux test-suite detects (intermittent) problems when running
>> on buildds hosted at ARM Ltd. The issue has been investigated and
>> also discussed with responsible people via #debian-arm. Unfortunately
>> no solution in sight (as it seems the responsible people lost interest
>> in investigating what's happening at their end).
>>
>> I'm thus asking you to please blacklist all ARM Ltd hosted buildds
>> (for all (arm*) architectures) for building the util-linux package.
>>
>> Once that's done please consider closing #872635 which contains some
>> additional info about this problem about the issue.
>>
>> Right now I'm relying on give-backs and praying it doesn't end up
>> on ARM Ltd hosted or the doesn't trigger this build. It's annoying
>> and time-wasting. Unfortunately I don't have enough spare time or
>> motivation to continue enduring this.
> 
> I guess two other options would be:
> 
> a) Disable outbound network access altogether (likely hard)
> or
> b) Blackhole a.root-servers.net with a host firewall rule so that the
> test gets skipped
> 
or
c) disable tests that use the network in the package itself

Cheers,
Julien

Re: blacklisting util-linux on ARM Ltd hosted buildds

[Julien Cristau]

On 08/21/2017 10:27 AM, Philipp Kern wrote:
> On 08/21/2017 10:11 AM, Andreas Henriksson wrote:
>> The util-linux test-suite detects (intermittent) problems when running
>> on buildds hosted at ARM Ltd. The issue has been investigated and
>> also discussed with responsible people via #debian-arm. Unfortunately
>> no solution in sight (as it seems the responsible people lost interest
>> in investigating what's happening at their end).
>>
>> I'm thus asking you to please blacklist all ARM Ltd hosted buildds
>> (for all (arm*) architectures) for building the util-linux package.
>>
>> Once that's done please consider closing #872635 which contains some
>> additional info about this problem about the issue.
>>
>> Right now I'm relying on give-backs and praying it doesn't end up
>> on ARM Ltd hosted or the doesn't trigger this build. It's annoying
>> and time-wasting. Unfortunately I don't have enough spare time or
>> motivation to continue enduring this.
> 
> I guess two other options would be:
> 
> a) Disable outbound network access altogether (likely hard)
> or
> b) Blackhole a.root-servers.net with a host firewall rule so that the
> test gets skipped
> 
> I suppose DSA wouldn't be overly happy to do the latter but maybe it
> could be a compromise?
> 
Is there any more information on the issue beyond what's in the bug?  Is
it reproducible on abel?  How intermittent is it?

Cheers,
Julien

haskell binNMUs and buildd queues

[Julien Cristau]

Hi Joachim,

I was wondering if/how you're scripting the haskell-related binNMUs.  It
would be helpful, in the interest of not starving the other packages
that need building, to systematically reduce the build priority for
those binNMUs (by 100 or so, I would guess).  Is that something you
could integrate in your binNMU scheduling routine?

Thanks,
Julien

Re: gb: mpich 3.2-7 on sh4

[Julien Cristau]

On Mon, Jun  5, 2017 at 12:26:31 +0800, Drew Parsons wrote:

> Dear buildd keepers,
> 
> the build of mpich on sh4 has been broken, apparently due to
> inconsistent configurations or flags used in the toolchain.
> The error is
> /usr/bin/ld: MPIUI_Thread: TLS definition in 
> lib/.libs/libmpich.a(lib_libmpich_la-mpiu_thread.o) section .tbss mismatches 
> non-TLS reference in lib/.libs/libmpich.a(lib_libmpich_la-comm_rank.o)
> 
> There is no sh4 developer machine, so I can't investigate manually. 
> I'd therefore like request mpich be given back to build on sh4, to
> check if later updates to the toolchain have fixed the problem.
> 
>   gb mpich_3.2-7 . sh4
> 
Failed again in the same way.

Cheers,
Julien

Re: Please give back firefox-esr/experimental on i386

[Julien Cristau]

On 05/05/2017 01:58 PM, Mike Hommey wrote:
>   gb firefox-esr_52.1.0esr-1 . i386

Given back.

Cheers,
Julien

Re: Please give back firefox/unstable on i386

[Julien Cristau]

On Wed, Mar  8, 2017 at 17:01:52 +0900, Mike Hommey wrote:

> Hi,
> 
> Somehow the build failed with a crash of ld (a first on i386, for
> firefox ; it'd been limited to mips so far).
> 
>   gb firefox_52.0-1 . i386
> 
Given back.

Cheers,
Julien

Re: Please give back firefox-esr/unstable on arm64

[Julien Cristau]

On Wed, Mar  8, 2017 at 16:36:21 +0900, Mike Hommey wrote:

> Hi,
> 
> Somehow the build failed on arm64, but I was able to build succesfully
> on a porterbox...
>   gb firefox-esr_45.8.0esr-1 . arm64
> 
Done.

Cheers,
Julien

Re: Please give back sagemath on i386

[Julien Cristau]

On Wed, Jan 25, 2017 at 15:42:20 +, Tobias Hansen wrote:

> On 01/24/2017 11:08 PM, Julien Cristau wrote:
> > On Mon, Jan 23, 2017 at 23:23:15 +, Tobias Hansen wrote:
> > 
> >> Never mind, we did a binary-only upload.
> >>
> > Please don't do that...
> > 
> > Cheers,
> > Julien
> > 
> 
> Ok, may I ask why? Or is it just for the same reasons why source-only
> uploads are preferred?
> 
Yes, we need to be sure packages can actually build on buildds.

Cheers,
Julien

Re: Please give back sagemath on i386

[Julien Cristau]

On Mon, Jan 23, 2017 at 23:23:15 +, Tobias Hansen wrote:

> Never mind, we did a binary-only upload.
> 
Please don't do that...

Cheers,
Julien

Re: Please give back yade on arm64

[Julien Cristau]

On 01/22/2017 07:33 PM, Anton Gladky wrote:
> Dear wb-team,
> 
> yade_2017.01a-1 fails to build on arm64 due to some unclear
> reasons (probably build was terminated).
> 
> =
> 
> E: Caught signal ‘Terminated’: terminating immediately
> gui/CMakeFiles/_GLViewer.dir/build.make:113: recipe for target
> 'gui/CMakeFiles/_GLViewer.dir/qt5/OpenGLManager.cpp.o' failed
> debian/rules:7: recipe for target 'build-arch' failed
> make[3]: *** [gui/CMakeFiles/_GLViewer.dir/qt5/OpenGLManager.cpp.o] Terminated
> 
> =
> Please give back yade on that platform
> 
> gb yade__2017.01a-1 .  arm64
> 
first try:
Build killed with signal TERM after 151 minutes of inactivity
second try:
Build killed with signal TERM after 343 minutes of inactivity

Doesn't look unclear to me.

Cheers,
Julien

Re: New ssh key for mahler buildd

[Julien Cristau]

On Sun, Jan 22, 2017 at 15:11:02 +0100, Samuel Thibault wrote:

> Hello,
> 
> After some disk failure, we had to reinstall mahler, could some wbadm
> person install the new key, attached to this mail?
> 
> Thanks,
> Samuel

> ssh-rsa 
> B3NzaC1yc2EDAQABAAABAQCyzkIiN7CjfBQ+A/ojKlKeTsEmGiB2oEUSy+SXM2m0dwAKvfsrKyNX5CSvW+T8ugp5kGz43nc7UewsQDkT71ncBL6fh2/uXVn8VXcTBH64LGI4DXR2KQeNUAN6szci8u7dAAbN8AAP6sJbsF1Jc36IjXca7nzsB7ZVLOQyF5aJ7ws4CUiSW2SBikRllmNCND8Zf1xCcBl01ngJ7PX82bAMB9PkA/f0wDaY9nJBAB+GTfiBuQdnVwJcwhLojvLBlDEFfi77GQaWsPXTF5KPmqh7x9JQ/BofahsHgxFplEoU5fKILKktBGkVxRKUy58FSn4D/Q89/BwfjEcR6G6J3TH7
>  buildd@mahler

That's the kind of mail you may want to sign...

Cheers,
Julien

Re: Please update pbuilder environments on build daemons [Was: Source upload of r-cran-treescape does not build on any architecture - but why?]

[Julien Cristau]

On 12/21/2016 01:05 PM, Andreas Tille wrote:
> Hi Adam,
> 
> On Wed, Dec 21, 2016 at 11:47:38AM +, Adam D. Barratt wrote:
 as explained below auto builders should either have dpkg 1.18.15 or
 1.18.17 (see bug #848422).
>>>
>>> The chroots will be updated in a few hours.
>>
>> It's also generally safe to assume that the relevant teams are aware of
>> things like widespread dpkg and buildd breakage.
> 
> Yes, I did not intend to assume something else but I was a bit worried due
> to upcoming deadlines for packages that need to reach testing ...
>  
 Is bach.hen...@gmail.com the correct address for "contacting wanna-build
 people"?  If yesm Henrik is in CC - if not what's the proper contact?
>>
>> I have no idea who that is, but it's not an address I've ever seen
>> referenced in relation to wanna-build.
> 
> Its the only e-mail I've found at
> 
>https://wiki.debian.org/DebianWannaBuildInfrastructure
> 
> which was the first hit on site:debian.org for WannaBuild.
> 
https://www.debian.org/intro/organization#wanna-build

HTH,
Julien

Re: dpkg version in buildd chroots

[Julien Cristau]

On 12/20/2016 02:35 PM, Tobias Hansen wrote:
> Hi wanna-build team,
> 
> I have here a package [1] that keeps on trying to build on the buildds
> (~60 attempts so far) and fails most likely due to the dpkg bug #848413.
> The bug was fixed in dpkg 1.18.17 just 1.5 days ago.
> 
> I don't know how to check the dpkg version used in the chroots since it
> does not appear in the build logs. Are the buildds still using dpkg
> 1.18.16?

Yes.

> How frequently are the chroots updated?
> 
Twice a week.  They should get regenerated with dpkg 1.18.18 tomorrow.

Cheers,
Julien

Re: Should the kernel perf interface be available on autobuilders?

[Julien Cristau]

On Sun, Dec  4, 2016 at 07:52:40 +0100, Petter Reinholdtsen wrote:

> 
> Hi.
> 
> Lluís Vilanova (cc) and I maintain the coz-profiler package in Debian,
> and this package uses the perf kernel interface for profiling.  This
> subsystem has received strict access limitations in recent Debian
> kernels.  During build of the coz-profiler package it test itself to
> ensure it is working, and this work on all autobuilders except one, the
> x32 architecture.
> 
> Are the autobuilders expected to block access to the perf kernel
> interface, or is this a misconfiguration of the x32 build host?
> 
I think both are valid configurations, and your package shouldn't make
an assumption one way or the other.

Cheers,
Julien

Re: Give back qtwebchannel on mips, powerpc, hppa

[Julien Cristau]

On Sat, Oct 22, 2016 at 01:58:00 +0200, Sandro Knauß wrote:

> Hey,
> 
> after the issue is fixed in qtdeclerative, the test for qtwebchannel should 
> now 
> run successfully, so please give back.
> 
> gb qtdeclarative-opensource-src_5.6.1-1 . mips powerpc hppa
> 
The above seems to be confused as to which package it wants given back.
qtdeclarative-opensource-src is built, so can't be given back.  And
qtwebchannel doesn't seem to even exist.

Cheers,
Julien

Re: openbabel: FTBFS on mips,mips64el: internal compiler errors

[Julien Cristau]

On Thu, Sep 22, 2016 at 10:34:29 +0300, Niko Tyni wrote:

> @debian-wb-team: could you please give it back to see if it happens
> again on buildds?
> 
>  gb openbabel_2.3.2+dfsg-2.4 . mips mips64el
> 
Given back.

Cheers,
Julien

Re: Please give back givaro on i386

[Julien Cristau]

On Tue, Sep  6, 2016 at 13:16:12 -0400, Doug Torrance wrote:

> Hello!
> 
> Please give back givaro on i386:
> 
>  gb givaro_4.0.2-3 . i386
> 
> The previous build failed due to a randomly occurring bug in one of the
> tests which has been reported upstream.
> 
Given back.

Cheers,
Julien

Re: nordugrid-arc on i386 stuck in Uploaded for more than 5 days

[Julien Cristau]

On Mon, Sep 12, 2016 at 09:09:57 +0200, Mattias Ellert wrote:

> The missing build is blocking migration to testing.
> 
Poked the buildd to reupload.

Cheers,
Julien

Re: please give-back simgrid

[Julien Cristau]

On Thu, Jul 21, 2016 at 21:44:48 +0200, Lucas Nussbaum wrote:

> gb simgrid_3.13-1 . armel
> thanks!
> 
> I'm surprised by the failure and would appreciate a fresh log to make
> sure it wasn't a transient issue with the chroot.
> 
Looks like that was done, there's a failed build log from 2 days ago.

Cheers,
Julien

Re: Please give back swt4-gtk on ppc64el

[Julien Cristau]

On Fri, Apr 29, 2016 at 14:02:30 -0300, Fernando Seiti Furusato wrote:

> Hello.
> 
> The package swt4-gtk failed to build with javatools-0.54 due to archdir set
> to ppc64, instead of ppc64le (changed recently on openjdk).
> javatools has been fixed.
> 
> Could you please give back swt4-gtk with javatools-0.55 on ppc64el?
> 
>   gb swt4-gtk_4.5.0-2 . ppc64el
> 
Given back.

Cheers,
Julien

Re: Supporting armel/armhf in wheezy-lts

[Julien Cristau]

On Sat, Apr 23, 2016 at 14:41:30 +0200, Raphael Hertzog wrote:

> I have also been looking at ways to bring the "LTS funding" closer to Debian
> and to find a way to join all this in the Debian Partner program but we
> don't have many volunteers interested in this work. We discussed it a bit
> last year during Debconf with Luca Filippozi, Martin Krafft and Neil
> McGovern, but this never went further. And I obviously don't want to be
> leading this project due to the clear conflict of interest that I would
> have...
> 
I think one of the contentious points is how "Freexian raising funds to
work on Debian LTS" is already too close to calling itself "Debian LTS
fundraising", so I'm not sure bringing them closer would alleviate
anyone's concerns.

Cheers,
Julien

Re: chroots of some archs fail to take DST into account?

[Julien Cristau]

On Wed, Mar  2, 2016 at 08:06:46 +, Javi Merino wrote:

> Hi,
> 
> mercurial's testsuite has a test called "test-parse-date.t" that
> checks that mercurial works across timezones.  The test passes in
> chroots of some archs[0] but fails in others (e.g.[1] or [2]).
> 
As far as I can tell the tests pass on all 64bit archs, and fail on
32bit ones.  And I can reproduce the issue with your 'date' test case in
an i386 chroot, so it's not just the buildds.

Cheers,
Julien

Re: Please give back elk 3.99.8-4 on i386

[Julien Cristau]

On Sun, Feb 21, 2016 at 07:15:04 +, Julien Cristau wrote:

> On Sun, Feb 21, 2016 at 03:50:31 +, Ben Hutchings wrote:
> 
> > elk version 3.99.8-4 failed to build on i386 due to a test failure.  I
> > can't reproduce the test failure, and all other architectures passed,
> > so I think it's worth retrying.
> > 
> > gb elk_3.99.8-4 . i386
> > 
> Given back.
> 
It failed again
https://buildd.debian.org/status/fetch.php?pkg=elk=i386=3.99.8-4=1456039927

Cheers
Julien

Re: Please give back elk 3.99.8-4 on i386

[Julien Cristau]

On Sun, Feb 21, 2016 at 03:50:31 +, Ben Hutchings wrote:

> elk version 3.99.8-4 failed to build on i386 due to a test failure.  I
> can't reproduce the test failure, and all other architectures passed,
> so I think it's worth retrying.
> 
> gb elk_3.99.8-4 . i386
> 
Given back.

Cheers,
Julien

Re: Package uploaded but not installed for weeks

[Julien Cristau]

On Wed, Jan  6, 2016 at 12:43:22 +0100, Bálint Réczey wrote:

> Dear Wanna-build Team,
> 
> I'm wondering how I could trigger the Uploaded -> Installed transition for
> 
> xbmc-pvr-addons' armel build [1].
> 
> I have read about the wanna-build states [2], but I could not find any
> clue what could go wrong.
> 
First upload failed partway through.  Reuploaded now.

Cheers,
Julien

Re: Fwd: speech-dispatcher-contrib not building

[Julien Cristau]

On Mon, Nov 30, 2015 at 00:06:20 +0100, Samuel Thibault wrote:

> Hello,
> 
> TL;DR: speech-dispatcher-contrib does not get build on buildds,
> apparently because it depends on libttspico-dev which is in non-free. Is
> there a way to get it automatically built rather than having to build
> it for each and every architecture?
> 
No, I don't think we want buildds installing stuff from non-free.

Cheers,
Julien


signature.asc
Description: PGP signature

Re: Please give back erlang-p1-* on arm64

[Julien Cristau]

On Fri, Oct  9, 2015 at 10:44:20 +0100, Wookey wrote:

> +++ Julien Cristau [2015-10-09 08:37 +0200]:
> > On Thu, Oct  8, 2015 at 16:25:00 +0100, Wookey wrote:
> > 
> > > +++ Philipp Huebner [2015-10-07 13:13 +0200]:
> > > > Hello,
> > > > 
> > > > there was a bug in rebar that caused several erlang-p1-* packages to
> > > > FTBFS on certain architectures. Once that was fixed, the packages where
> > > > automatically and successfully built again, but for some unknown reason
> > > > the resulting binary packages for arm64 never appeared in the archive.
> > > 
> > > Yes something very odd has happenned here.
> > >  
> > As far as I can tell the packages were removed a month ago, so
> > give-backs were the wrong thing to do: bugs#796565, 796566, 796567,
> > 796568, 796569, 796646.
> 
> OK, but the underlying rebar bug is now fixed so having them back in
> the archive is correct. Give-backs seems to have achieved this. 
> 
> So what should/could have been done instead?
> 
A binNMU would have been better, since that would have avoided reusing
the same version number for a new build.

Cheers,
Julien


signature.asc
Description: PGP signature

Re: Please give back erlang-p1-* on arm64

[Julien Cristau]

On Thu, Oct  8, 2015 at 16:25:00 +0100, Wookey wrote:

> +++ Philipp Huebner [2015-10-07 13:13 +0200]:
> > Hello,
> > 
> > there was a bug in rebar that caused several erlang-p1-* packages to
> > FTBFS on certain architectures. Once that was fixed, the packages where
> > automatically and successfully built again, but for some unknown reason
> > the resulting binary packages for arm64 never appeared in the archive.
> 
> Yes something very odd has happenned here.
>  
As far as I can tell the packages were removed a month ago, so
give-backs were the wrong thing to do: bugs#796565, 796566, 796567,
796568, 796569, 796646.

Cheers,
Julien


signature.asc
Description: PGP signature

Re: Please binNMU soci (gcc5)

[Julien Cristau]

On Wed, Sep 23, 2015 at 15:56:51 +0200, Hector Oron wrote:

> Hello,
> 
> This is wanna build team list, I am forwarding to release team one
> which handles binNMU
> 
> 2015-09-22 21:52 GMT+02:00 Tobias Frost :
> > Dear Release-Team,
> >
> > please binNMU soci for the gcc5 transistion. See #799533 for details.
> >
> > Syntax should be:
> >
> > nmu soci_3.2.3-1 . ANY . -m 'Rebuild against gcc5'
> 
It would have helped to mention #791292, too, since all #799533 says is
that libsoci breaks ABI, which would normally mean a package name
change, not a rebuild.

Anyway, binNMUs scheduled.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Packages stuck in Built

[Julien Cristau]

On Mon, Jul 20, 2015 at 10:36:05 +0200, Joachim Breitner wrote:

 Hi,
 
 haskell-tagstream-conduit on powerpc is in Built since several hours,
 and a give-back did not help. Can someone have a look?
 
 Since this happens regularly: Is there some systematic monitoring and
 notification of such clear error conditions (i.e. packages in Built or
 Uploaded state for longer than, say, an hour or two)?
 
Try a day or two.  An hour or two can be perfectly normal.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Erlang is built on armhf but never uploaded

[Julien Cristau]

On Sat, Apr 11, 2015 at 21:08:55 +0300, Sergei Golovan wrote:

 Hi!
 
 The last erlang package for sid was built for all architectures, but
 has never been uploaded on armhf (see [1]). What can be done to
 actually upload it? It fixes an RC bug, so I'd like to see it in
 jessie very much.
 
 [1] https://buildd.debian.org/status/package.php?p=erlang
 
Looks like the previous upload attempt was interrupted.  dcut rm seems
to have helped, and it's now Installed.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Bug#768998: Bug#767010: kadu-dev: KaduTargets.cmake hardcodes amd64 path

[Julien Cristau]

On Sun, Nov 30, 2014 at 15:58:42 +0100, gregor herrmann wrote:

 On Sun, 30 Nov 2014 11:41:11 +0100, Mateusz Łukasik wrote:
 
  kadu-mime-tex should be rebuild by bin-nmu with kadu = 1.2-2 it fix that
  bug. For example now is build fine on armhf:
  
  dpkg-gencontrol: warning: File::FcntlLock not available; using flock which
  is not NFS-safe
  dpkg-gencontrol: warning: package kadu-mime-tex: unused substitution
  variable ${misc:Pre-Depends}
 dh_md5sums
 dh_builddeb
  dpkg-deb: building package `kadu-mime-tex' in
  `../kadu-mime-tex_1.0-2_armhf.deb'.
   dpkg-genchanges  ../kadu-mime-tex_1.0-2_armhf.changes
  dpkg-genchanges: not including original source code in upload
   dpkg-source --after-build kadu-mime-tex-1.0
  dpkg-buildpackage: binary and diff upload (original source NOT included)
 
 
 So, let's request a giveback on all arches except amd64 (where the
 package built):
 
 gb kadu-mime-tex_1.0-2 . ALL -amd64
 
Given back.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: please give back openldap on armhf

[Julien Cristau]

On Mon, Nov 24, 2014 at 10:31:16 -0800, Ryan Tandy wrote:

 Hi,
 
 Please give back openldap 2.4.40-3 on armhf. There were no code changes in
 this upload, only debconf messages, and it has succeeded on every other
 arch.
 
Given back.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: please give back openldap on mipsel

[Julien Cristau]

On Wed, Oct 22, 2014 at 16:34:49 -0700, Ryan Tandy wrote:

 gb openldap_2.4.40-2 . mipsel
 
Given back.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: please give-back pyzmq 14.4.0-1 on powerpc

[Julien Cristau]

On Wed, Oct 22, 2014 at 08:43:06 +0200, Julian Taylor wrote:

 hi,
 I couldn't reproduce the failure on the porterbox after running the
 tests several dozen times, so I'd like to request one give back to see
 how it behaves on the buildd.
 
Looks built now.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Builds for stable-security / iceweasel

[Julien Cristau]

On Thu, Oct 16, 2014 at 09:18:35 +0200, Moritz Mühlenhoff wrote:

 Hi wanna-build team,
 there haven't been any builds for iceweasel_31.2.0esr-1~deb7u1
 in stable-security so far. The package needed to go through NEW
 (since we're moving from the Firefox 24.x series to the new
 31.x line). It has been accepted by FTP masters yesterday, I
 suppose there's some cornercase related to NEW?
 
No, the package's build-deps are uninstallable in stable.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: gb telepathy-salut_0.8.1-3 . armel armhf sparc

[Julien Cristau]

On Wed, Jul 30, 2014 at 14:52:37 +0200, Julien Cristau wrote:

 On Tue, Jul 29, 2014 at 00:09:55 +0100, Simon McVittie wrote:
 
  Please give back telepathy-salut on armel, armhf, sparc:
  
  gb telepathy-salut_0.8.1-3 . armel armhf sparc
  
 Given back.
 
Looks like it failed in the same way.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please give back makefs on mips

[Julien Cristau]

On Sun, Jul 13, 2014 at 10:47:01 +, Thorsten Glaser wrote:

 gb makefs_20100306-4 . mips
 
because...

Cheers,
Julien


-- 
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/20140713104908.gv3...@betterave.cristau.org

Re: Please give back makefs on mips

[Julien Cristau]

On Sun, Jul 13, 2014 at 10:53:26 +, Thorsten Glaser wrote:

 Julien Cristau dixit:
 
 On Sun, Jul 13, 2014 at 10:47:01 +, Thorsten Glaser wrote:
 
  gb makefs_20100306-4 . mips
  
 because...
 
 … the new bmake upload should have fixed the FTBFS issue
 (makefs uses pmake as build system).
 
Given back.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: /dev/shm on kfreebsd buildds

[Julien Cristau]

On Wed, Jun  4, 2014 at 21:03:07 +0200, Aurelien Jarno wrote:

 On Sat, May 17, 2014 at 02:49:07PM +0200, Julien Cristau wrote:
  Hi,
  
  the latest version of libxshmfence failed during tests because trying to
  create a file in /dev/shm failed with ENOENT.  Is it possible that the
  sid chroots on fano and fils are missing /dev/shm, or that it's a
  dangling symlink?
 
 Since the /run transition, in the chroot case /dev/shm should be a
 symlink to /run/shm. It is like that on GNU/Linux. On GNU/kFreeBSD
 the scripts are correctly creating the symlink, but given /dev is
 a devfs filesystem, it is lost when exiting the chroot.
 
That /run transition is all broken, at least for shm.  It's also undone
with systemd, which doesn't do the /run/shm thing at all, AFAICT.  In my
/etc/schroot/sbuild/fstab here I have
tmpfs   /dev/shmtmpfs   defaults0   0

Could something similar be done on kfreebsd?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please gb subversion on kfreebsd-i386

[Julien Cristau]

On Fri, May 23, 2014 at 14:34:22 -0400, James McCoy wrote:

 Hi,
 
 Subversion's build on finzi failed because of a stale binutils (2.24-3,
 pre-triplet prefixed binaries) in the base chroot.  A gb on fils or an
 updated finzi should resolve the issue.
 
 gb subversion_1.8.9-1 . kfreebsd-i386
 
done:
jcristau@wuiet:~$ wb gb subversion . kfreebsd-i386 . --extra-depends 'binutils 
(= 2.24.51.20140411)'

Cheers,
Julien


signature.asc
Description: Digital signature

/dev/shm on kfreebsd buildds

[Julien Cristau]

Hi,

the latest version of libxshmfence failed during tests because trying to
create a file in /dev/shm failed with ENOENT.  Is it possible that the
sid chroots on fano and fils are missing /dev/shm, or that it's a
dangling symlink?

Thanks,
Julien


signature.asc
Description: Digital signature

Re: please give-back python-tornado on armel

[Julien Cristau]

On Sat, May  3, 2014 at 18:17:01 +0200, Julian Taylor wrote:

 hi,
 the test failure may have been caused by an overloaded buildd, I'd like
 to give it a second try before I relax the test requirements.
 
Given back.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: give-back gnat-4.9 on armel

[Julien Cristau]

On Fri, Apr 25, 2014 at 13:28:52 +0100, Ludovic Brenta wrote:

 gb gnat-4.9_4.9.0-1 . armel
 
On Fri, Apr 25, 2014 at 23:07:00 +0200, Ludovic Brenta wrote:

 dw gnat-4.9_4.9.0-1 . mipsel . -m gcc-4.9-source (= 4.9.0-1)
 
Set dep-waits for both.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: gb xdotool_3.20130111.1-3.1 . armhf

[Julien Cristau]

On Fri, Feb 14, 2014 at 17:20:24 +0100, Christian Hofstaedtler wrote:

 Dear wanna-build Team,
 
 xdotool failed to build on armhf, and it appears the test-suite is
 timing-sensitive.
 I just tried two builds on harris, where the first one failed with
 another error and the second one passed.
 
 Could you please try building xdotool again?
 
 Possible gb line:
 
   gb xdotool_3.20130111.1-3.1 . armhf
 
Given back (it's now built) and raised 740419 severity to important.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: give back openvdb on i386

[Julien Cristau]

On Sun, Jan 19, 2014 at 10:47:08 +0100, Mathieu Malaterre wrote:

 Hi,
 
   Please give openvdb another try, as I cannot reproduce the build
 issue from my i386 sid chroot here:
 
   gb openvdb_2.1.0-1 . i386
 
Given back.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: please give back boost1.54 on amd64 and sparc

[Julien Cristau]

On Sat, Dec 14, 2013 at 07:12:38 -0600, Steve M. Robbins wrote:

 Boost 1.54 failed to build on two architectures for 
 apparently sporadic reason: memory exhausted on amd64
 and ICE, but the bug is not reproducible on sparc.
 Can you try them again, please?
 
 gb boost1.54 1.54.0-4+b1 . amd64
 gb boost1.54 1.54.0-4 . sparc
 
Given back.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: gb pidgin-musictracker with dpkg-dev 1.17.1 (was: Re: Bug#727131: pidgin-musictracker: FTBFS: /bin/sh: 1: Syntax error: ( unexpected)

[Julien Cristau]

On Wed, Oct 23, 2013 at 10:22:08 +0200, Niels Thykier wrote:

 Dear build admins; please upgrade dpkg-dev in your chroots and then:
 
   gb pidgin-musictracker_0.4.22-3 . ALL -amd64 -armhf -i386
 
 (or schedule it now with an --extra-depends 'dpkg-dev (= 1.17.1)').
 
NAK.  The lack of versioned build-dependency is a RC bug in the package,
it needs to be fixed there.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please give-back python-apt 0.8.9.1 on armel

[Julien Cristau]

On Tue, Oct  8, 2013 at 21:51:49 +0200, Julian Andres Klode wrote:

 Hi,
 
 It seems there was some temporary issue; namely a .list file in the
 /tmp directory,
 which python-apt unfortunately uses as a sources.list.d directory
 during testing; and
 thus an unexpected source ended up in the test, causing it to FTBFS.
 
 gb python-apt 0.8.9.1 . armel
 
done

Cheers,
Julien


signature.asc
Description: Digital signature

Re: python-memprof needs python-matplotlib_1.3.0-1.1 to build on mips

[Julien Cristau]

On Sun, Oct  6, 2013 at 23:29:54 +0100, Javi Merino wrote:

 On Sun, Oct 06, 2013 at 01:55:46PM +0200, Julien Cristau wrote:
  On Thu, Oct  3, 2013 at 08:45:53 +0100, Javi Merino wrote:
  
   Hi,
   
   Please set python-memprof_0.3.1-1 to dep-wait on
   python-matplotlib_1.3.0-1.1 on mips.  python-matplotlib_1.3.0-1.1
   solves #719384.
   
   dw python-memprof_0.3.1-1 . mips . -m 'python-matplotlib (= 1.3.0-1.1)'
  
  matplotlib is still FTBFS though?
 
 Yes, but can this dependency be set so that python-memprof is rebuilt
 automatically when python-matplotlib builds in mips?  Or is this the
 wrong way of getting that?
 
No, you're right.  dep-wait set (well, when wb decides to reply, anyway).

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Request to give back myproxy 5.9-3 on kfreebsd-amd64

[Julien Cristau]

On Fri, Oct  4, 2013 at 05:28:58 +0200, Mattias Ellert wrote:

 Hi!
 
 I would like to ask for a giveback of myproxy 5.9-3 on kfreebsd-amd64
 
Given back.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please give back rdkit_201306-2 on mipsel/unstable

[Julien Cristau]

On Sun, Oct  6, 2013 at 12:06:13 +0200, Michael Banck wrote:

 Hi,
 
 I built rdkit in the unstable chroot on eder.d.o, and I could not
 reproduce the ICE from the buildd log, so please give it back:
 
That's the machine going OOM.  Given back, maybe it'll be picked up by a
machine with more ram...

Cheers,
Julien


signature.asc
Description: Digital signature

Re: python-memprof needs python-matplotlib_1.3.0-1.1 to build on mips

[Julien Cristau]

On Thu, Oct  3, 2013 at 08:45:53 +0100, Javi Merino wrote:

 Hi,
 
 Please set python-memprof_0.3.1-1 to dep-wait on
 python-matplotlib_1.3.0-1.1 on mips.  python-matplotlib_1.3.0-1.1
 solves #719384.
 
 dw python-memprof_0.3.1-1 . mips . -m 'python-matplotlib (= 1.3.0-1.1)'

matplotlib is still FTBFS though?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Update /srv/wanna-build/etc/buildd/buildd.yaml

[Julien Cristau]

On Fri, Sep 20, 2013 at 17:01:40 +0200, Hector Oron wrote:

 Hello,
 
   While trying to fix praetorius buildd, there was a problem
 connecting to wanna-build database, apparently due to a typo in
 /srv/wanna-build/etc/buildd/buildd.yaml which is only owned by 'aba'.
 I could not find this file in GIT either. So, please consider the
 following patch for fixing several typos and architectures for the
 armel buildds.
 
Your patch seems reversed...

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please give-back aces3/3.0.6-7+b1 on ia64

[Julien Cristau]

On Wed, Sep  4, 2013 at 22:34:08 +0200, Daniel Leidert wrote:

 Hi there,
 
 Seems the build of aces3 got killed after 150 minutes during running its
 test suite on an ia64 buildd. Can you please give it back on a machine
 with a longer inactivity timeout or build it using
 DEB_BUILD_OPTIONS=nocheck?
 
NAK.  There seems to be an issue with the new openmpi on ia64 affecting
a number of its reverse deps.  Shipping known-broken packages doesn't
seem like the way to go.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: package mgltools-sff BD-Uninstallable

[Julien Cristau]

On Sun, Aug  4, 2013 at 11:36:20 +0200, Thorsten Alteholz wrote:

 Hi Kurt,
 
 thanks for helping me.
 
 On Sat, 3 Aug 2013, Kurt Roeckx wrote:
 I assume that we only give the packages from main to check that,
 so that build-depends on packages from non-free will always have
 this effect.
 
 But there has been a successful build of mgltools-sff in 2012 [1].
 Have there been any changes since then? Obviously there have been,
 but would it be possible to revert them?
 
The fact that incoming had both main and non-free packages in the same
archive was a bug.  That has since been fixed.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: package mgltools-sff BD-Uninstallable

[Julien Cristau]

On Sun, Aug  4, 2013 at 14:29:40 +0200, Thorsten Alteholz wrote:

 
 On Sun, 4 Aug 2013, Julien Cristau wrote:
 But there has been a successful build of mgltools-sff in 2012 [1].
 Have there been any changes since then? Obviously there have been,
 but would it be possible to revert them?
 
 The fact that incoming had both main and non-free packages in the same
 archive was a bug.  That has since been fixed.
 
 Ok, but was does that mean for my package. Isn't it allowed to let a
 non-free package depend on another non-free package anymore?
 
It's allowed, it just won't be autobuilt.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please give-back libnice on kbsd-i386

[Julien Cristau]

On Tue, Jun 18, 2013 at 14:16:24 +0200, Laurent Bigonville wrote:

 Hi,
 
 Could you please give back libnice on kfreebsd-i386.
 
 For some reasons it FTBFS because it has been kicked after 150min of
 inactivity.
 
 It's the only architecture where this happen.
 
Did you try to reproduce on a porterbox?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please give-back libnice on kbsd-i386

[Julien Cristau]

On Fri, Jun 21, 2013 at 01:04:28 +0200, Laurent Bigonville wrote:

 Just tested and the build has succeeded.
 
Given back.

Cheers,
Julien


-- 
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/20130620230650.gj5...@betterave.cristau.org

Re: Please, give back gmsh on mips

[Julien Cristau]

On Sat, Jun  8, 2013 at 16:19:26 +0200, Anton Gladky wrote:

 Thanks, Adam, for that!
 
 Unfortunately it failed again on ball... Could you, please,
 try again? If it fails one more time, I will request removal of gmsh on
 mips: I am tired to struggle with it.
 
Trying builds again and again won't fix bugs.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: gb pymvpa2_2.2.0-3 . armel mipsel

[Julien Cristau]

On Fri, Jun  7, 2013 at 12:10:17 -0400, Yaroslav Halchenko wrote:

 gb pymvpa2_2.2.0-3 . armel mipsel
 
 Reasoning:
 
 failures 
 http://release.debian.org/migration/testing.pl?package=pymvpa2
 do not make much sense, so I assume that was just a random flux of the
 build boxes.
 
Looks like a debian/rules bug to me.  NAK.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please giveback crawl on sparc

[Julien Cristau]

On Sun, Jun  9, 2013 at 00:22:50 -0700, Vincent Cheng wrote:

 Dear wanna-build team,
 
 Please give back crawl on sparc, reason being that it hits an ICE only
 on sparc, not on any other arch. Thanks!
 
What makes you think that ICE will magically go away?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Request to give back globus-xio 3.3-2 on armel

[Julien Cristau]

On Wed, Jun  5, 2013 at 05:28:25 +0200, Mattias Ellert wrote:

 Hi!
 
 I would like to ask for a giveback of globus-xio 3.3-2 on armel
 
 According to the log the build failed due to a glitch in a call to
 doxygen:
 
 /bin/bash: line 10: 26994 Illegal instruction /usr/bin/doxygen Doxyfile
 
What makes you think SIGILL is a glitch?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: please give back scheme48

[Julien Cristau]

On Sun, May 26, 2013 at 19:12:04 +0200, Thorsten Alteholz wrote:

 Dear wb-team,
 
 for whatever reason the build of scheme48 on several architectures
 was killed by a bus error or manual kill. So can you please give
 back the package on:
 
 gb scheme48_1.9-2 . hurd-i386 ia64 mipsel sparc
 
NAK.  Bus error means package bug, they're not random.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: please give back pari on ia64

[Julien Cristau]

On Fri, May 24, 2013 at 19:47:24 +0200, Bill Allombert wrote:

 Dear Wanna-build admins,
 
 Please give back pari 2.5.4-1 on ia64. Pari FTBFS was caused by a bug in gmp
 #708264 which is fixed in gmp 2:5.1.2+dfsg-1.
 
 I hope this is the right incantation.
 
 dw pari_2.5.4-1 . ia64 . -m 'libgmp10 (= 2:5.1.2+dfsg-1)'
 
Done.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Request for binNMU for packages depending on gsoap

[Julien Cristau]

On Sat, May 18, 2013 at 20:19:54 +0200, Mattias Ellert wrote:

 Hi!
 
 Due to a soname bump in gsoap i would like to request a binNMU for
 dependent packages:
 
  - srm-ifce
  - gfal2
  - lcgdm
 
This is not the right place for binNMU requests.
http://release.debian.org/wanna-build.txt

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Temporary solution for changelog problem in binNMUs

[Julien Cristau]

On Fri, May 17, 2013 at 14:14:20 +0200, Thomas Preud'homme wrote:

 Also, it wouldn't help for the case of a binNMU on a subset of all arches 
 since only some of them would have the entry. The solution proposed by ansgar 
 cover this case.

No it doesn't.  dpkg will still refuse to install a m-a same package at
different versions.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Temporary solution for changelog problem in binNMUs

[Julien Cristau]

On Mon, May 13, 2013 at 13:14:51 -0700, Jonathan Nieder wrote:

 One problem that that doesn't solve is what to do when a package would
 be able to borrow its /doc/package directory from another package
 (using a symlink) but for the changelog and copyright (which gets even
 harder when binnmus are involved).  See http://bugs.debian.org/556015
 
Nobody said it solved that.  It solves the multiarch binnmu
co-installability issue, that's all anyone's said afaict.  I'm not sure
conflating that with another much older and much less severe issue helps
anyone.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Build time column via psql wanna-build

[Julien Cristau]

On Sun, Apr 21, 2013 at 23:51:57 +0200, Joachim Breitner wrote:

 Hi,
 
 I was about to harvest some data from the Build time that I can see at,
 for example, https://buildd.debian.org/status/logs.php?pkg=ghcarch=amd64,
 but it seems that I cannot access it using psql wanna-build on grieg:
 
 wanna-build= select * from log limit 1;
  package | distribution |version |  timestamp  | 
 architecture 
 -+--++-+--
  wmii| experimental | 3.10~20120413+hg2813-2 | 2013-04-21 21:47:43 | mips
 (1 Zeile)
 
 From what I can tell log is a view using pkg_history, which I do not
 have access to:
 
 wanna-build= select * from pkg_history limit 1;
 ERROR:  permission denied for relation pkg_history
 
wanna-build= select * from amd64_public.pkg_history where package = 'ghc' 
limit 1;
 package | distribution | version |  timestamp  | result | build_time | 
disk_space |  builder  
-+--+-+-++++---
 ghc | experimental | 7.0.1-1 | 2011-02-28 06:29:59 | failed |   3417 | 
2159128576 | barber.debian.org
(1 row)

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please, could you retry seed on ia64?

[Julien Cristau]

On Sun, Mar  3, 2013 at 12:26:02 +0100, Stephan Schreiber wrote:

 Please, could you retry seed on ia64?
 
Given back.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please, could you retry some xorg drivers for ia64?

[Julien Cristau]

On Sat, Jan 26, 2013 at 15:50:33 +0100, Stephan Schreiber wrote:

 Hello,
 please, could you retry some xorg drivers for ia64?
 
 Some xorg video drivers failed to build on ia64 due to bug#685750 in
 the xorg-server source code package last year.
 
 The bug is fixed, but there are still some debs missing.
 Please could you retry
 
 for Wheezy/sid
 xserver-xorg-video-apm | 1:1.2.3-3 | ia64
 xserver-xorg-video-chips | 1:1.2.4-2 | ia64
 xserver-xorg-video-cirrus |  1:1.4.0-2 | ia64
 xserver-xorg-video-rendition | 1:4.2.4-3 | ia64
 xserver-xorg-video-siliconmotion | 1:1.7.6-1 | ia64
 xserver-xorg-video-sis | 1:0.10.4-1 | ia64
 xserver-xorg-video-trident | 1:1.3.5-1 | ia64
 xserver-xorg-video-tseng | 1:1.2.4-3 | ia64
 
 additionally for sid:
 xserver-xorg-video-ark |  1:0.7.4-1+b1 | ia64
 xserver-xorg-video-i128 |  1:1.3.5-1+b1 | ia64
 xserver-xorg-video-i740 | 1:1.3.2-4+b3 | ia64
 xserver-xorg-video-qxl |   0.0.17-2+b1 | ia64
 xserver-xorg-video-s3 | 1:0.6.3-4+b3 | ia64
 xserver-xorg-video-vesa |  1:2.3.1-1+b1 | ia64
 xserver-xorg-video-vmware | 1:12.0.2-1+b1 | ia64
 
 
 I was able to build the Wheezy packages on ia64; I hope the ones for
 sid will do as well.
 
Given back all the above except vmware, because I don't think there are
any ia64 vmware guests...

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please give back icedove on mipsel

[Julien Cristau]

On Sat, Dec 15, 2012 at 18:48:21 +, Steven Chamberlain wrote:

  collect2: ld terminated with signal 9 [Killed]
 
That's typically OOM.

Cheers,
julien


signature.asc
Description: Digital signature

Re: [p-a-s/sid] Don't build wvstreams on armel.

[Julien Cristau]

On Thu, Nov 29, 2012 at 19:09:57 +0100, Anton Gladky wrote:

 Dear wb-team,
 
 first of all a short pre-story. I am running Debian Wheezy on Raspberry
 Pi (soft float, armel).  I realized, that there are no wvdial available.
 It is a little frustrating, because this tool is one of the most
 convenient for setting up an internet connection from command line
 through USB-modem (for me Raspberry works like a little server, so no
 GUI, no nm-applet).
 
 Wvdial cannot be built for armel, because wvstreams is not available for
 this platform (#521473) due to some problems in the past. So I decided
 to build packages of wvstreams and wvdial locally. After that wvdial was
 installed from those debs and runs just fine!
 
 So, I would like to ask wb-team to enable wvstreams for armel as, it
 seems, the problem with getcontext() is not relevant any more. I think
 many raspberry-users will be happy to get wvdial from official
 debian-repositories.
 
#369453 (lack of *context on arm) seems to have been fixed in
eglibc/2.13-31.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Wheezy freeze and squeeze-backports-sloppy

[Julien Cristau]

On Tue, Sep 11, 2012 at 14:17:27 +0200, Gerfried Fuchs wrote:

 Hi again.
 
 * Gerfried Fuchs rho...@deb.at [2012-07-30 09:05:09 CEST]:
  * Philipp Kern pk...@debian.org [2012-07-12 17:57:46 CEST]:
   I wasn't very happy back then either. It was sort of rushed through in
   some private IRC pings about me setting it up on the wanna-build side.
   All I'm saying is if it would be possible to review the arguments,
   having had the experience for one cycle.
  
   The arguments why it is wanted (and to some degree needed) didn't
  change since then.  There are still the two groups of people who expect
  backports to be upgradeable to the next release _without_ backports, and
  those who still want to have newer versions in _after_ the release.
  Both are valid concerns, and both have their userbase.
  
   It's sad that we do not currently scale on the buildd side, but that's
   how it is.[1]
   
   (And it's likely to take a month until all buildds have implemented it,
   given the current speed of any buildd updates needing to take place.)
  
   Is there anything we can help with that?  (and, ouch :( )
 
  I'd like to re-ask this question, it might went unseen.  Is there
 anything we can help with?  postgres-9.2 was one of the things that was
 asked about already, and I suspect that there are people wanting to
 provide other stuff too.
 
There's a lot you can do to help get wheezy out.  After which you can
put new stuff in backports again.  Everybody wins.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please build ogre_1.7.4-5 and k3d_0.8.0.2-18 on mipsel

[Julien Cristau]

On Sat, Jul 14, 2012 at 12:10:31 +0100, Manuel A. Fernandez Montecelo wrote:

 For one, GCC version is 4.6 instead of 4.7 (which I think, is the
 default in other archs.)... I guess that it's for a good reason?
 
4.7 is only the default on x86.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Please update dpkg to = 1.16.4 and reschedule goobox 3.0.1-5

[Julien Cristau]

On Mon, Jul  9, 2012 at 15:24:12 -0500, Jonathan Nieder wrote:

 (dropping sp maintainers from cc list)
 Hi Helge,
 
 Helge Kreutzmann wrote:
 
  Hello ia64 buildd admins,
  it would be great if you could upgrade the version of dpkg in your buildd
  environment to something = 1.16.4 (e.g. the version in testing
  (1.16.4.3) or in sid (1.16.7)) and reschedule goobox 3.0.1-5.
 
 I'm guessing the other message already went through and it's a matter
 of waiting for them to have a spare moment.
 
 Maybe the wb team (cc-ed) will know if there are alternatives.  E.g.,
 if it's only about goobox, it could make sense to remove the ia64
 binary for now or to upload with a build-depends.
 
Given back.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: gb ants_1.9.2+svn680.dfsg-4 . mips mipsel s390

[Julien Cristau]

On Thu, Jul  5, 2012 at 11:57:18 -0400, Yaroslav Halchenko wrote:

 
 On Thu, 05 Jul 2012, Mehdi Dogguy wrote:
  gb ants_1.9.2+svn680.dfsg-4 . mips mipsel s390
  I'm not sure that giving back ants on s390 would bring anything
  good. It has been failing to build there since a few revisions.
 
 and the sign is worrisome regarding my ability to overcome the problem:
 
 virtual memory exhausted: Cannot allocate memory
 
 that was on zappa -- is there any other build box with more VMEM avail?
 
No, virtual memory is independent of the particular machine, it's 31bit
on s390.

  For mipsel, -3 also failed with the same error. 
 
 it might indeed be a memory issue but message was a bit different:
 
 https://buildd.debian.org/status/fetch.php?pkg=antsarch=mipselver=1.9.2%2Bsvn680.dfsg-3stamp=1331621632
 c++: internal compiler error: Killed (program cc1plus)
 Please submit a full bug report,
 with preprocessed source if appropriate.
 
That means the machine went out of memory and the kernel killed your c++
process.

[...]
 but so far it just looks like insufficient resources on all of them... 
 
Or insane requirements from those packages.  I guess it depends on your
pov.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: apt 0.9.7 build failures

[Julien Cristau]

On Fri, Jun 29, 2012 at 03:03:09 +0300, Touko Korpela wrote:

 (I'm not maintainer, just curious)
 apt 0.9.7 failed to build like this on several architectures
 (armel,armhf,ia64,mipsel,powerpc,s390,s390x)
 I guess it was some toolchain issue that is now fixed?
 Should they be tried again on buildds?
 Freeze is coming, do you still want to upload new version before it happens?
 
Known sgml-base or dpkg bug, don't worry about it.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Dep-wait for tcc against kfreebsd-source-9.0 (= 0.82)

[Julien Cristau]

On Sat, Jun 30, 2012 at 11:31:29 +0200, Thomas Preud'homme wrote:

 Greetings Wanna Build team,
 
 dw tcc_0.9.26~git20120612.ad5f375-4 . kfreebsd-i386 kfreebsd-amd64  . -m 
 'kfreebsd-source-9.0 (= 0.82)'
 
kfreebsd-source-9.0 sounds unrelated to a userspace package.  So I'm
guessing you mean kfreebsd-kernel-headers.  Which is build-essential,
and thus a dep-wait is not enough to ensure it'll be installed on the
buildd.

Cheers,
Julien


signature.asc
Description: Digital signature