Re: buildds screwed?
Geert Uytterhoeven dixit:
>I'm afraid I can't let high-profile debian-m68k hackers play dangerous sports.
Hahaha!
You’re lucky, too many people are missing anyway.
Christian T. Steigies dixit:
>Well, I had this example last week where during two builds different test
>cases failed, and the third build succeeded.
That is _precisely_ why I believe the toolchain is not at fault.
A buggy toolchain results in _consistent_ errors.
>> >Will your patches be available in the debian source package or somewhere
>>
>> Of course. But only in that in unreleased. But the packages need to
>> be built in the right order.
>
>I have the impression, this has become a lot more complicated.
Sure, but I’m still around and doing that, and once we switch
to gcc-4.8 it’s probably a non-issue.
>> No, I just build with DEB_BUILD_OPTIONS='nobench nocheck' when doing
>> manual builds.
>
>Ah, that will cut down the build time.
Definitely. And it makes me getting a .deb out of the process
more probable; in the resurrection process, it was sometimes
more important to get a .deb that somehow works a bit than to
not get a .deb at all.
>> Yes, that???s when a package gets ACCEPTed by mini-dak. After that,
>> it???s available in the ???incoming??? until it gets moved to the normal
>> pool locations.
>
>So what is in "unreleased" then?
unstable, unreleased and experimental are the three distributions
available in Debian-Ports, just like stable, testing, unstable and
experimental are in Debian. Think of unreleased as another experi‐
mental with similar semantics in dpo than in Debian (the unstable
and experimental in dpo are bin/porter upload only).
https://wiki.debian.org/DebianPorts/WhatIsUnreleased
One more thing that comes to mind is: do you have the “incoming”
directory enabled in your chroot sources.list? (If not or you’re
confused, please reply to me in private; this is not public in‐
formation, and only for buildd chroots, not to be used for regular
installations, because its intent is to get the just-build packages
available to the buildd for the next package “ASAP” and that won’t
scale if it’s accessed by too many systems.)
>> Did you try to see whether SSH connection multiplexing is active?
>
>Yesterday I had the impression it was not, but I saw some files. How can I
>check/set that again?
I’ll have to see how it’s done in buildd, this is investigation.
Geert Uytterhoeven dixit:
>On Mon, May 13, 2013 at 12:23 PM, Christian T. Steigies <cts@debian.org> wrote:
>>> Even GCC???s own ICE messages say so. It retries the compilation if it
>>> fails due to an ICE, automatically, and if it does _not_ fail again,
>>> the hardware is at fault. (Which may not necessarily be a problem
>
>Or the OS.
[…]
>Could be a kernel issue with '060s.
Right. But that’s “hardware” ;-)
bye,
//mirabilos
--
Sorry, I’m annoyed today and you came by as an Arch user. These are the
perfect victims for any crime against humanity, like systemd, feminism
or social democracy.
-- Christoph Lohmann on dev@suckless.org
Reply to: