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