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 <[email protected]> >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 [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
