1 |
On Sunday 31 July 2005 16:24, Duncan wrote: |
2 |
> Simon Strandman posted <42E55ADB.8030201@×××××.com>, excerpted below, on |
3 |
> |
4 |
> Mon, 25 Jul 2005 23:34:19 +0200: |
5 |
> > Done! Bug #100289 |
6 |
> > http://bugs.gentoo.org/show_bug.cgi?id=100289 |
7 |
> > |
8 |
> > Tell me if I need to provide any more information. |
9 |
> Do note that any issues that might exist would seem to disappear once the |
10 |
> entire system is compiled against the patched glibc. That's why SuSE can |
11 |
> get away with running the patch -- their entire amd64 release will have |
12 |
> been compiled against the patched glibc. Thus, there are no known issues |
13 |
> with doing a stage-1 bootstrap with these patches, since by the time the |
14 |
> system is up and running, it'll all be compiled against the patched glibc. |
15 |
> Likewise, there are no known issues at this time, should one decide to |
16 |
> patch glibc, and then do an emerge --emptytree. In any case, however, |
17 |
> doing your own glibc patching, regardless of what the patch is, is likely |
18 |
> to blacklist any bugs you may file. That's something that may be |
19 |
> worthwhile to keep in mind. |
20 |
> |
21 |
As the reporter of the problem with nano, I'd like to make 1 correction to |
22 |
this report: Recompiling nano and its depencies did not fix the crashes. It |
23 |
just fixed the eating of the file. |
24 |
I did not recompile my entire system, but a crash of such a small and basic |
25 |
app as nano made me not want to do this outside of a chroot, which I |
26 |
currently do not have the means for. |
27 |
I reread my report, and I saw it was not clear that recompiling nano and its |
28 |
dependencies did not fix the crashes. Sorry for the confusion. |
29 |
|
30 |
Jan Jitse |