bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rolling new releases


From: David Michael
Subject: Re: Rolling new releases
Date: Tue, 6 Oct 2015 17:49:00 -0400

Hi,

On Mon, Oct 5, 2015 at 10:39 AM, Justus Winter
<4winter@informatik.uni-hamburg.de> wrote:
> as agreed earlier, we're trying to produce two releases a year.  We
> released GNU Mach 1.5, GNU MIG 1.5, and GNU Hurd 0.6 in April, hence
> it is time for our next release :)

If a new glibc+libpthread snapshot is going to be made for the next
release, can I suggest applying these patches to the
tschwinge/Roger_Whittaker branch?

This patch corrects a build failure:
https://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/unsubmitted-NO_HIDDEN.diff?view=co

This one automatically links libhurduser and libmachuser, which is
required to build a lot of things:
https://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/submitted-add-needed.diff?view=co

This one avoids problems with a symbol that is also provided by libpthread:
https://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/tg-libc_getspecific.diff?view=co

I haven't checked if there's a new Debian patch for this, but there is
an IS_IN macro from the future (build failure) since commit 8042775.
Use IS_IN_rtld instead:
http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/sysdeps/mach/hurd/cthreads.c?h=tschwinge/Roger_Whittaker#n23

Also, I believe either you or Samuel told me at some point that
task_notify should be built in libmachuser instead of the proc server.
I've been running a patch locally that makes the following edit, which
seems to work.  Maybe this change can be tacked onto the t/gnumach
branch and you can drop Debian's Hurd patch?  (Note to packagers that
this will make glibc install a new file, <mach/task_notify.h>.)
sed -i -e 's/ gnumach /&task_notify /' sysdeps/mach/configure{.ac,}

Finally, a question on a somewhat related note ... maybe for the next
release:  I haven't looked into it much yet, but I was thinking maybe
gnumach's new boot-time clock could be exported to provide real
CLOCK_MONOTONIC support for glibc.  Are you aware of any details in
its implementation that would make it inapplicable?  Linux apparently
uses time since boot as the return value for CLOCK_MONOTONIC as well.

Thanks.

David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]