rtheys a écrit :
> Aurelien Jarno wrote:
>> From my point of view the patch looks correct as it has been applied
>> upstream and is now in unstable. However, it looks like nobody has
>> really tried the glibc with this patch applied to make sure it fixes
>> *this* bug.
>
> Hi,
>
> I did rebuild t
Aurelien Jarno wrote:
> From my point of view the patch looks correct as it has been applied
> upstream and is now in unstable. However, it looks like nobody has
> really tried the glibc with this patch applied to make sure it fixes
> *this* bug.
Hi,
I did rebuild the etch glibc package with the
Martin Zobel-Helas a écrit :
> Hi,
>
> Glibc maintainers, what is your opinion on that?
>
>From my point of view the patch looks correct as it has been applied
upstream and is now in unstable. However, it looks like nobody has
really tried the glibc with this patch applied to make sure it fixes
Hi,
Glibc maintainers, what is your opinion on that?
Greetings
Martin
On Fri May 11, 2007 at 14:00:17 +0200, Steinar H. Gunderson wrote:
> On Fri, May 11, 2007 at 01:25:07PM +0200, Rik Theys wrote:
> > Is there any chance to get a fix for #423369 and #423108, a memory leak
> > in both libc6 an
Hi,
On Fri May 11, 2007 at 14:39:51 +0200, Julien Danjou wrote:
> At 1178878964 time_t, Thijs Kinkhorst wrote:
> > That is of "important" severity. Work has been done to mitigate the effects
> > of
> > that bug. Not resolved indeed, but worked around so it's not a critical
> > issue
> > anymo
At 1178882707 time_t, Rik Theys wrote:
> The libc6 bug causes nfs-kernel-server to leak a lot of memory on busy NFS
> servers that use netgroups (and other software that uses netgroups). In
> extremis this could be used as a denial of service by letting the NFS
> server run out of memory. I've a
At 1178878964 time_t, Thijs Kinkhorst wrote:
> That is of "important" severity. Work has been done to mitigate the effects
> of
> that bug. Not resolved indeed, but worked around so it's not a critical issue
> anymore: it will work for most systems and conflicts with environments that
> may be
On Fri, May 11, 2007 at 02:00:17PM +0200, Steinar H. Gunderson wrote:
>> Is there any chance to get a fix for #423369 and #423108, a memory leak
>> in both libc6 and nfs-kernel-server, into etch r1?
> FWIW, here is the proposed patch:
...against nfs-utils, that is. The glibc issue will of course
On Fri, May 11, 2007 at 01:25:07PM +0200, Rik Theys wrote:
> Is there any chance to get a fix for #423369 and #423108, a memory leak
> in both libc6 and nfs-kernel-server, into etch r1?
FWIW, here is the proposed patch:
--- nfs-utils-1.0.10/debian/changelog
+++ nfs-utils-1.0.10/debian/changelog
Dear SRM,
Is there any chance to get a fix for #423369 and #423108, a memory leak
in both libc6 and nfs-kernel-server, into etch r1?
The libc6 bug causes nfs-kernel-server to leak a lot of memory on busy
NFS servers that use netgroups (and other software that uses netgroups).
In extremis thi
On Friday 11 May 2007 07:20, Alexander Wirt wrote:
> Vincent McIntyre schrieb am Freitag, den 11. Mai 2007:
> > is it possible to have xlockmore included in the point release?
> > It had an RC bug that kept it out of etch but that seems to have
> > been resolved some months ago.
>
> #318123 isn't r
At 1178824838 time_t, Kevin B. McCarty wrote:
> Is there any chance to get in a fix for #422141, in which the viewcvs
> and cvs packages in Etch don’t play well together, into Etch 4.0r1?
>
> I don’t see a patch anywhere in the bug log, but since the problem is
> caused by a single extra line in C
12 matches
Mail list logo