Simon Strandman posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 25 Jul 2005 23:34:19 +0200:
> Done! Bug #100289 > http://bugs.gentoo.org/show_bug.cgi?id=100289 > > Tell me if I need to provide any more information. For those following the thread here, but not keeping up with the bug, testing reveals that at least one app, nano, crashes (when searching), with the patches applied to glibc, until nano is remerged against the new glibc. Yes, that means that the issue goes away with a remerge, but there could be other apps similarly affected. There are two factors making this *VERY* serious. (1) nano just happens to be the text editor used in the config file editing examples in the installation handbook, so there are likely more Gentoo users for that particular app than in the normal Linux using population. (2) The crash /can/ mean it eats the file it was editing. Taken together, that makes the issue a critical one indeed, particularly since the users that are still using nano rather than having formed their own preferences (ignoring for the moment those that have actually made an informed decision to use nano, having tried other editors), are also likely the ones not to have backups of their critical config files. Additionally, where there's app crashing due to a change in glibc, there are bound to be more. Thus, integration of the patches is on hold for now, and likely will be for some time, until something a bit safer, either in strategy or in patches, can be devised. Thus, anyone hoping to run these in an official Gentoo glibc should be preparing to do their own glibc patching, with each new version, for awhile. Additionally, it could blacklist any further bugs you file, at least until your whole toolchain and any misbehaving apps have been remerged against the patched glibc. Do note that any issues that might exist would seem to disappear once the entire system is compiled against the patched glibc. That's why SuSE can get away with running the patch -- their entire amd64 release will have been compiled against the patched glibc. Thus, there are no known issues with doing a stage-1 bootstrap with these patches, since by the time the system is up and running, it'll all be compiled against the patched glibc. Likewise, there are no known issues at this time, should one decide to patch glibc, and then do an emerge --emptytree. In any case, however, doing your own glibc patching, regardless of what the patch is, is likely to blacklist any bugs you may file. That's something that may be worthwhile to keep in mind. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
