Re: A plan for the Hurd-specific glibc repository
I don't have anything to contribute about how you want to handle the Debian branches et al. As to your mainline-based repository branches, I can tell you that individual topic branches that I can review individually and then merge directly are what I will merge into mainline most efficiently. I understand it might be an unusual amount of hassle to tease interdependent changes out right now when there is such a backlog. For cases in the current backlog where such issues look like they'll be a big time-sink, we can just play it by ear and maybe do some chunkier merges. I hope we can before long catch up so that there aren't so many things floating around and individual topic branches will be easy enough to use. Thanks, Roland
A plan for the Hurd-specific glibc repository
Hello! While waiting for boarding at the Atlanta airport, I finally fleshed out a plan about how to begin populating and using our private Savannah Hurd-specific glibc repository / fork / whatever you name it. Can all of Roland, Samuel, other interested parties subscribe to that scheme? Some abbreviations: * R(libc) -- Savannah Hurd-specific glibc repository, http://git.savannah.gnu.org/cgit/hurd/glibc.git/ * D(libc) -- Debian libc package; this is these days based on eglibc, not glibc * P(D(x)) -- patches applied to D(x), compared to (upstream) x * P(y,D(x)) -- y-specific patches of P(D(x)) Objective, problems, some solutions: * R(libc) is to be based on glibc, not eglibc. eglibc shouldn't contain a lot of differences in the Hurd-specific parts, but yet, there may be differences. * R(libc) has to be usable for my own libc works, as well as other peoples' similar needs of course: (a) provide a stable basis for building cross toolchains, (b) general libc development. * R(libc) needs to automatically generate the P(hurd,D(libc)) files. There is no reason we should continue to maintain P(hurd,D(libc)) in parallel, manually. Preferrably, one patch file per topic should be generated, not a huge combined one. Usually, these generated patches should be equivalent to the (a) subset of R(libc), but: * There will be patches in R(libc) that are not wanted for P(hurd,D(libc)), because they're already being handled outside of P(hurd,D(libc)) in P(D(libc)), as they're needed for other non-Linux architectures (k*BSD), too, for example. There must be a way to exclude these. * There will be patches whose content is indeed wanted for P(hurd,D(libc)), but needs to be (slightly) frobbed before being usable in Debian's eglibc context. That can be taken care of by additional patches in P(hurd,D(libc)); these are not derived from R(libc), and are either prepended or appended (as appropriate) to the series derived from R(libc). * There will be patches that are really only relevant to Debian. We can either still keep them in R(libc) too, or these stay manually maintained in P(hurd,D(libc)) as they're now. * The versions of the upstream libc package / the version R(libc) is based on may be slightly different from what D(libc) is using. This shouldn't pose major problems, though, and can be handled as above, too. * All reasonable stuff from R(libc) should eventually be merged into the upstream glibc repository. Instead of staging stuff in R(libc), we could submit stuff upstream right from the beginning, but there are problems: * Upstream essentially only wants perfect patches. Not everything we have at the moment is ready for prime time. (Yet, unfinished patches are needed / used to base further work upon.) * Often, there is a huge delay between submission and acceptance (if at all). * One central repository for handling all stuff involving R(libc) is not sufficient, but a distributed one is needed. This needs to include all meta information (dependencies between different topic branches, for example). * Upstream glibc / eglibc repositories are not at all in a usable shape at the moment. Thus: simple topic branches which will eventually be merged into master are not possible; again, dependencies between topic branches. * Yet, for the usual reasons, maintaining stuff in topic branches is preferrable to a linearized structure (simply committing stuff in the appropriate order in one Git branch; which would inherently resolve all dependencies). There are like 30 topic branches at the moment. Possible solutions, and their problems: * One Git branch: not wanted, as above. * Many Git (topic) branches: possible, but problem of dependencies between topic branches. Possibly difficult to generated usable P(hurd,D(libc)) patches from that structure. * Quilt, http://savannah.nongnu.org/projects/quilt, http://www.suse.de/~agruen/quilt.pdf. Had a brief look at it. Instead of topic branches, has several (topic) patch files, which are automatically applied in the appropritate ordering. This is what D(libc) (and a lot of other packages) are doing right now. Problem: unwieldy for general development; doesn't integrate with Git, thus not easily distributable. * guilt (quilt on top of git), http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/man/. Had a brief look at it. Like Quilt; but does in a way integrate with Git, but not really in a distributed fashion, as I understand it. Might be feasible to be used, but so far didn't look at it in too much detail. * StGit (stacked Git), http://www.procode.org/stgit/. Had a brief look at it. Mostly like guilt, it seems.
Re: A plan for the Hurd-specific glibc repository
Thomas Schwinge, le Sat 23 Jan 2010 07:13:30 -0500, a écrit : * There will be patches that are really only relevant to Debian. We can either still keep them in R(libc) too, or these stay manually maintained in P(hurd,D(libc)) as they're now. I had a quick look at the Debian patches, local-enable-ldconfig.diff probably fits in that category, as the header mentions: « Upstream disagrees with this patch, but I'm putting it in so that we have expected Debian behaviour on the Hurd. » It seems to really be a Debian-specific patch. Others patches should be fine and it should be possible to just add them automatically, the header of the patch (lines before ^---$) being used as the git comment. About that git comment, it should probably be preserved, so it can be included automatically in patches in Debian and for submission. I guess TopGit supports that? Else it seems just fine, thanks. Samuel
Re: A plan for the Hurd-specific glibc repository
Hello! On 2010-01-23 13:16, Samuel Thibault wrote: Thomas Schwinge, le Sat 23 Jan 2010 07:13:30 -0500, a écrit : * There will be patches that are really only relevant to Debian. We can either still keep them in R(libc) too, or these stay manually maintained in P(hurd,D(libc)) as they're now. I had a quick look at the Debian patches, local-enable-ldconfig.diff probably fits in that category, as the header mentions: « Upstream disagrees with this patch, but I'm putting it in so that we have expected Debian behaviour on the Hurd. » It seems to really be a Debian-specific patch. Yep, stuff like that is what I had in mind for this category. Others patches should be fine and it should be possible to just add them automatically, the header of the patch (lines before ^---$) being used as the git comment. Yes. I'll (have to) examine each one individually, though -- I already have a bunch of them in my local Git glibc topic branches (from the last time I was trying to get this repository populated), and I hope / guess that I can simply convert these blobs into TopGit patches, and later diff them against the respective Debian patches to confirm that there are no functional differences. About that git comment, it should probably be preserved, so it can be included automatically in patches in Debian and for submission. I guess TopGit supports that? Right, that's how I understand it, and what I had in mind. Regards, Thomas pgpTJ7ysnHVEA.pgp Description: PGP signature
Re: A plan for the Hurd-specific glibc repository
On 24/01/10 00:17, Thomas Schwinge wrote: Hello! On 2010-01-23 13:16, Samuel Thibault wrote: Thomas Schwinge, le Sat 23 Jan 2010 07:13:30 -0500, a écrit : * There will be patches that are really only relevant to Debian. We can either still keep them in R(libc) too, or these stay manually maintained in P(hurd,D(libc)) as they're now. I had a quick look at the Debian patches, local-enable-ldconfig.diff probably fits in that category, as the header mentions: « Upstream disagrees with this patch, but I'm putting it in so that we have expected Debian behaviour on the Hurd. » It seems to really be a Debian-specific patch. Yep, stuff like that is what I had in mind for this category. For your reference, these are the minimal patches I had to apply to glibc-2.10.1 to get it building for a cross compiler and be able to cross-build a working Hurd: any/local-no-SOCK_NONBLOCK.diff any/local-stdio-lock.diff any/submitted-popen.diff any/submitted-sched_h.diff hurd-i386/local-atomic-no-multiple_threads.diff hurd-i386/local-check_native.diff hurd-i386/local-_dl_random.diff hurd-i386/local-gcc-4.1-init-first.diff hurd-i386/local-gscope.diff hurd-i386/local-tls.diff hurd-i386/local-tls-support.diff hurd-i386/local-unwind-resume.diff hurd-i386/submitted-dl-sysdep.diff hurd-i386/submitted-libc_once.diff hurd-i386/submitted-ptr-mangle.diff hurd-i386/submitted-stat.diff hurd-i386/submitted-strtoul.diff These are all from Debians eglibc package in Sid or their SVN. I had to adjust a couple of them in minor ways so that they would apply to glibc. Allan
