Hi!
Matthias Klose has recently re-enable the GCC testsuite for GNU/Hurd, and
while it now runs to completion (hooray!) there are a number of
unexpected test failures (search for »FAIL:«):
On Fri, 15 Aug 2014 14:32:01 +0200, Matthias Klose wrote:
> https://buildd.debian.org/status/fetch.php?pkg=
> Ok, so that will be something like this.
Yes.
Roland McGrath, le Tue 19 Aug 2014 13:26:25 -0700, a écrit :
> If we were starting from scratch, we'd use 64-bit types unconditionally.
> But given that we already have off_t that is sometimes 32 bits, we should
> be consistent with the other systems that have this distinction. That
> means F_GETL
If we were starting from scratch, we'd use 64-bit types unconditionally.
But given that we already have off_t that is sometimes 32 bits, we should
be consistent with the other systems that have this distinction. That
means F_GETLK64 should be a different value from F_GETLK in the ABI, and
F_GETLK
> Anatoly A Kazantsev writes:
[…]
> @@ -348,9 +349,17 @@ main(int argc, char *argv[])
>break;
> default: /* Parent. */
> - if (waitpid (pid, NULL, 0) == -1)
> + if (waitpid (pid, &status, 0) == -1)
> error (8, errno, "waitpid");
> + if (WIFSIGNA
On Tue, 2014-08-19 at 19:56 +0200, Samuel Thibault wrote:
> Svante Signell, le Tue 19 Aug 2014 17:45:25 +0200, a écrit :
> > On Tue, 2014-08-19 at 17:07 +0200, Samuel Thibault wrote:
> > > Svante Signell, le Tue 19 Aug 2014 16:23:05 +0200, a écrit :
> > > > I'll take a look. However, fixing this do
Samuel Thibault, le Tue 19 Aug 2014 20:36:35 +0200, a écrit :
> It creates thousands of threads, and it seems the stack addresses keep
> going up, so we apparently have a problem of stack reuse here, so
> something on the libpthread side, not the pulseaudio side.
That's possibly related with the E
Hello,
Felipe Sateler, le Mon 18 Aug 2014 00:47:10 -0400, a écrit :
> I am attempting to enable the pulseaudio test suite at package build
> time. After clearing a few hurdles with upstream the package has
> managed to build with tests everywhere except on the hurd[1].
So it's just once-test whic
Svante Signell, le Tue 19 Aug 2014 06:55:43 +0200, a écrit :
> On Mon, 2014-08-18 at 23:39 +0200, Samuel Thibault wrote:
> > Svante Signell, le Mon 18 Aug 2014 21:56:19 +0200, a écrit :
> > > The reason this is needed is that the MIG generated RPC for hurd/glibc
> > > currently does not support mix
Ah, a duplicate, thanks for the contribution anyway :)
Samuel
Svante Signell, le Tue 19 Aug 2014 17:45:25 +0200, a écrit :
> On Tue, 2014-08-19 at 17:07 +0200, Samuel Thibault wrote:
> > Svante Signell, le Tue 19 Aug 2014 16:23:05 +0200, a écrit :
> > > I'll take a look. However, fixing this does not solve the permission
> > > denied problem of fakeroot-hurd.
On Tue, 2014-08-19 at 17:07 +0200, Samuel Thibault wrote:
> Svante Signell, le Tue 19 Aug 2014 16:23:05 +0200, a écrit :
> > I'll take a look. However, fixing this does not solve the permission
> > denied problem of fakeroot-hurd.
>
> Sure, but at least it won't produce bogus binaries.
Attached i
On Tue, 19 Aug 2014 15:30:43 +0200
Samuel Thibault wrote:
> Hello,
>
> In short:
>
> youpi@exodar:~$ fakeroot-hurd false
> /bin/fakeauth: Error 1 for child 28735
> youpi@exodar:~$ echo $?
> 0
>
> It should be 1. That's the reason why the gnat-4.9 build failure went
> unnoticed.
>
> The source
Svante Signell, le Tue 19 Aug 2014 16:23:05 +0200, a écrit :
> I'll take a look. However, fixing this does not solve the permission
> denied problem of fakeroot-hurd.
Sure, but at least it won't produce bogus binaries.
Samuel
On Tue, 2014-08-19 at 15:30 +0200, Samuel Thibault wrote:
> Hello,
>
> In short:
>
> youpi@exodar:~$ fakeroot-hurd false
> /bin/fakeauth: Error 1 for child 28735
> youpi@exodar:~$ echo $?
> 0
>
> It should be 1. That's the reason why the gnat-4.9 build failure went
> unnoticed.
>
> The source i
Hello,
In short:
youpi@exodar:~$ fakeroot-hurd false
/bin/fakeauth: Error 1 for child 28735
youpi@exodar:~$ echo $?
0
It should be 1. That's the reason why the gnat-4.9 build failure went
unnoticed.
The source in hurd/utils/settrans.c, when chroot_command is given,
indeed forks and waitpid()s f
The following errors happened when building aegis with the testsuite
enabled. All failed tests point to the same error:
received broken pipe signal, see below.
On the contrary, in the buildd build (4.24.3-3+b1) all tests passed??
Strange.
aegis 4.24.3-3 test summary
===
Pa
Svante Signell, le Tue 19 Aug 2014 07:05:34 +0200, a écrit :
> On Mon, 2014-08-18 at 11:31 +0200, Svante Signell wrote:
> > Furthermore the following two large file system tests fail when building
> > manually:
> > (on the buildd they are skipped. How come, is that image not compiled with
> > -D_F
18 matches
Mail list logo
