Re: glibc patches

[Samuel Thibault]

Hello,

Thomas Schwinge, le Sat 28 Feb 2009 17:41:56 +0100, a écrit :
> I think I would base this on the official glibc git mirror and publish
> it again from the Hurd Savannah git repository

Mmm, shouldn't we rather maintain a patch queue?  That would make
(re-)submission/review easier.

> cvs-ECANCELED.diff: Should perhaps be renamed (or submitted again...),

No need to resubmit, Roland said he would commit the regeneration when
he would get on working on it again.

> local-atomic-no-multiple_threads.diff: FYI: I have an updated version for
> the conflict that arises when updating the file to the current CVS HEAD
> version.

Ok.  I'm really far from happy about this file.  Either we fork but will
have to track mainline improvements, or we add a completely unnecessary
multiple_threads field that would always be 1.

> local-gcc-4.1-init-first.diff: Perhaps rename submitted, as this, or
> variants of it, have actually been submitted, like, three times at
> least...

Mmm, IIRC Roland explicitely didn't like it, so I wouldn't call it
submitted.

> local-msg-nosignal.diff: Still needed?

Yes, as long as we do not have a hurd package rebuilt with MSG_NOSIGNAL
defined 

> local-net-headers.diff: Rename, as is in CVS?

Right.

> local-no-strerror_l.diff: Can be replaced with the following code

Ah, hadn't noticed it.

> local-pthread_types.diff: While functional equivalent, this change should
> rather go into a new file in sysdeps/mach/hurd/bits/.  (Tested.)

Right.

> local-tls-dtv-offset.diff: What about simply providing our own file in
> sysdeps/mach/hurd/i386/?

Again the same balance between tracking mainline updates or applying the
patch.  Again only because mainline assumes that i386 means NPTL...
Well, I guess we'll have to provide it anyway.

> As for a bunch of the other submitted-* patches, should we perhaps give
> it a last try and resubmit them?

Well, you can try.

Samuel