bug-hurd
[Top][All Lists]
Advanced

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

Re: Time for another round of releases


From: Samuel Thibault
Subject: Re: Time for another round of releases
Date: Sun, 2 Oct 2016 19:53:12 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Hello,

David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote:
> On Sun, Oct 2, 2016 at 9:54 AM, Justus Winter <justus@gnupg.org> wrote:
> > Also, if anyone has some pet patches or
> > fixes that would be nice to include, feel free to speak up or send
> > patches.
> 
> Okay, here is my semiannual list of non-Debian glibc/libpthread
> problems (and also gnumach this time).

Thanks!

> glibc:
> 
> Add a GLIBC_2.22 { __mach_host_self_; } section to mach/Versions.

Alright, I forgot to cherry-pick the upstream commit for this. Note
however that in upstream, it got versioned to 2.23, so we are diverging
here, distributions will have to handle this.

> Fix closing a block in hurd/Versions.

Oops, bogus merge indeed.

> There were undefined symbol errors from pthread timer sysdeps.  I
> didn't look into a real solution to this one and just worked around it
> with `rm sysdeps/pthread/*timer*`.

I guess you need unsubmitted-timer_routines.diff from Debian. It still
needs some work. I'll commit that patch to topgit at least.

> libpthread:
> 
> Commit a87bf9a8eab3af79798131b60c1f7f92f995df8c breaks static linking
> (namely ext2fs.static) from missing pthread_setcancelstate.

Ah? I don't understand how: this commit only makes libpthread use its
own internal __pthread_setcancelstate symbol. A pthread_setcancelstate
alias is still defined from pthread/pt-setcancelstate.c, how is it that
you don't get it?

> gnumach:
> 
> The highmem patches left a conflicting definition of pmap_map_bd in
> linux/dev/glue/kmem.c.

I'll let that for Richard :)

> The panic update patches produce -Wformat-security warnings--errors
> with Fedora's CFLAGS.  Use a literal "%s" instead of a variable as the
> format string.

Could you be more precise?  A quick check didn't let me see where it was
a problem.

> And as a minor request:  Can the DDE branch be updated to apply the
> patch on current master?

Right, I've done it.

Samuel



reply via email to

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