Hello! Yesterday night I spent another hour with synchronizing patches between the Debian glibc repo, my own collection, and what is in upstream by now. (The latter part being the easiest to handle...) As Roland is obviously not interested in committing my dup3 et al. changes (doesn't even reply to emails anymore), as well as not applying many of the patches that you posted, what about going a different route and really go ahead and publish a glibc fork for Hurd use? I think I would base this on the official glibc git mirror and publish it again from the Hurd Savannah git repository -- a waste of disk space, but oh well. Then the Debian glibc could (for the Hurd) simply use this (or automatically create a diff against the official repo) instead of maintaining all the independent patches.
Nevertheless, for now, as I can't commit to the Debian glibc SVN repo, I send this to you, Samuel. Here are comments on some of the patches from [glibc]/trunk/debian/patches/hurd-i386/: cvs-ECANCELED.diff: Should perhaps be renamed (or submitted again...), as this change is actually not in CVS. It's a generated file whose source file indeed has been changed (manual/errno.texi; in mid-2007), but still not yet the generated file. 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. 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... local-msg-nosignal.diff: Still needed? local-net-headers.diff: Rename, as is in CVS? local-no-strerror_l.diff: Can be replaced with the following code (which might even already be included in the last Debian glibc snapshot -- I didn't check). 2008-11-25 Thomas Schwinge <tschwi...@gnu.org> * sysdeps/mach/strerror_l.c: New file. local-pthread_types.diff: While functional equivalent, this change should rather go into a new file in sysdeps/mach/hurd/bits/. (Tested.) local-tls-dtv-offset.diff: What about simply providing our own file in sysdeps/mach/hurd/i386/? (I didn't find a non-intrusive way for sharing the main i386 file, while doing the one needed modification.) (Tested.) As for a bunch of the other submitted-* patches, should we perhaps give it a last try and resubmit them? Regards, Thomas
signature.asc
Description: Digital signature