Avoid updating to latest hurd package

2015-02-09 Thread Samuel Thibault
Hello, Oops, tests were fine on my box, but not on buildds: the latest hurd package with latest startup changes makes them unbootable, with a mere ../../startup/startup.c:712: launch_core_servers: Unexpected error: (ipc/mig) server died. I don't know why yet. Samuel

Re: Avoid updating to latest hurd package

2015-02-09 Thread Samuel Thibault
Samuel Thibault, le Mon 09 Feb 2015 11:15:22 +0100, a écrit : > Oops, tests were fine on my box, but not on buildds: the latest hurd > package with latest startup changes makes them unbootable, with a mere > > ../../startup/startup.c:712: launch_core_servers: Unexpected error: > (ipc/mig) server d

You can update to latest hurd package (Was: Avoid updating to latest hurd package)

2015-02-09 Thread Samuel Thibault
Samuel Thibault, le Mon 09 Feb 2015 11:47:34 +0100, a écrit : > Samuel Thibault, le Mon 09 Feb 2015 11:15:22 +0100, a écrit : > > Oops, tests were fine on my box, but not on buildds: the latest hurd > > package with latest startup changes makes them unbootable, with a mere > > > > ../../startup/st

Re: Bug#755295: Hurd term server (was: Hurd GCC ping)

2015-02-09 Thread Samuel Thibault
The latest Debian hurd package has a workaround to mimic Linux' behavior of never returning more than 4095 bytes for non-blocking pipe reads, which fixes the 'expect' behavior. gcc-5 is currently building on the mahler buildd with it, it'll take a few hours to complete, but by comparing the first

Re: Bug#755295: Hurd term server (was: Hurd GCC ping)

2015-02-09 Thread Samuel Thibault
Samuel Thibault, le Mon 09 Feb 2015 18:03:33 +0100, a écrit : > by comparing the first test passes, I can confirm that there are *WAY* > fewer failures with this workaround in place. And the few dozen failures I have seen so far also happen with the i386 build. Samuel

Re: Bug#755295: Hurd term server (was: Hurd GCC ping)

2015-02-09 Thread Samuel Thibault
Samuel Thibault, le Mon 09 Feb 2015 18:08:43 +0100, a écrit : > Samuel Thibault, le Mon 09 Feb 2015 18:03:33 +0100, a écrit : > > by comparing the first test passes, I can confirm that there are *WAY* > > fewer failures with this workaround in place. > > And the few dozen failures I have seen so f