From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1DzEmJ-0005Ca-1H for garchives@archives.gentoo.org; Sun, 31 Jul 2005 14:26:59 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j6VEObUQ006682; Sun, 31 Jul 2005 14:24:37 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j6VEOapA008839 for ; Sun, 31 Jul 2005 14:24:36 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DzEkr-0007Jd-OG for gentoo-amd64@lists.gentoo.org; Sun, 31 Jul 2005 16:25:29 +0200 Received: from ip68-230-97-182.ph.ph.cox.net ([68.230.97.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 31 Jul 2005 16:25:29 +0200 Received: from 1i5t5.duncan by ip68-230-97-182.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 31 Jul 2005 16:25:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: x86_64 optimization patches for glibc. Date: Sun, 31 Jul 2005 07:24:55 -0700 Organization: Sometimes Message-ID: References: <42E258A7.5080501@telia.com> <1122322081.12747.5.camel@cloud.outersquare.org> <42E55ADB.8030201@telia.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-182.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: 6212151e-09c9-4b17-a458-630b1b23f1df X-Archives-Hash: 674916fca3f769d7a16bf17fb4509f5c Simon Strandman posted <42E55ADB.8030201@telia.com>, 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 -- gentoo-amd64@gentoo.org mailing list