This one time, at band camp, Stephen Gran said:
> buxy: I've installed a version with this patch on alioth. I am going
> to revert the patched version of nss-updatedb in the morning, unless
> you have any objections.
And reinstalled the old version again. I spoke too soon - id user is
broken wit
This one time, at band camp, Raphael Hertzog said:
> On Sun, 27 May 2007, Guido Guenther wrote:
> > Yes it does, but that doesn't seem to be sufficient. If you look at
> > nss/files-XXX.c you see:
>
> Where's that from?
glibc.
> > Note that the group stays 112 until the buffer is large enough to
On Sun, May 27, 2007 at 11:10:32PM +0200, Raphael Hertzog wrote:
> On Sun, 27 May 2007, Guido Guenther wrote:
> > Yes it does, but that doesn't seem to be sufficient. If you look at
> > nss/files-XXX.c you see:
>
> Where's that from?
glibc
>
> > Note that the group stays 112 until the buffer is
On Sun, May 27, 2007 at 11:32:52PM +0200, Guido Guenther wrote:
> On Sun, May 27, 2007 at 11:10:32PM +0200, Raphael Hertzog wrote:
> > Sure, however it's not the latest upstream version in Debian and it might
> > not be completely relevant in that case.
> I'll reassign the bug anyway, care to add t
On Sun, 27 May 2007, Guido Guenther wrote:
> Yes it does, but that doesn't seem to be sufficient. If you look at
> nss/files-XXX.c you see:
Where's that from?
> Note that the group stays 112 until the buffer is large enough to fit
> the "huge" group 1 into it. This is something that must be h
This one time, at band camp, Guido Guenther said:
>
> Note that the group stays 112 until the buffer is large enough to fit
> the "huge" group 1 into it. This is something that must be handled
> by the nss modul internally. So the pgsql module should IMHO do
> somehting like:
>
> res =
On Sun, May 27, 2007 at 07:38:26PM +0200, Raphael Hertzog wrote:
> On Sun, 27 May 2007, Stephen Gran wrote:
> > It seems odd, but not impossible. I'll take another look at nss-pgsql
> > and let you know - if I can force it to set errno to ERANGE, and it
> > continues to break, then the problem is
On Sun, 27 May 2007, Stephen Gran wrote:
> It seems odd, but not impossible. I'll take another look at nss-pgsql
> and let you know - if I can force it to set errno to ERANGE, and it
> continues to break, then the problem is with updatedb. If it doesn't
> return ERANGE, then the problem is with t
This one time, at band camp, Guido Guenther said:
> Hi Stephen,
> On Sun, May 27, 2007 at 03:01:48PM +0100, Stephen Gran wrote:
> [..snip..]
> > And this is the output:
> >
> > gid_t: 10110 starting
> > gid_t: 10110 done
> > gid_t: 10800 starting
> > Enlarging buffer from 496 to 992
> > gid_t: 11
Hi Stephen,
On Sun, May 27, 2007 at 03:01:48PM +0100, Stephen Gran wrote:
[..snip..]
> And this is the output:
>
> gid_t: 10110 starting
> gid_t: 10110 done
> gid_t: 10800 starting
> Enlarging buffer from 496 to 992
> gid_t: 11197 starting
> gid_t: 11197 done
>
> Note that gid 10800 (the giant g
This one time, at band camp, Guido Guenther said:
> Hi Stephen,
> On Sat, May 26, 2007 at 11:51:33PM +, Stephen Gran wrote:
> > Which looks really good, until you spot the subtle flaw: the goto does
> > not actually retry the group that returned NSS_STATUS_TRYAGAIN, it tries
> > to grab the nex
Hi Stephen,
On Sat, May 26, 2007 at 11:51:33PM +, Stephen Gran wrote:
> Which looks really good, until you spot the subtle flaw: the goto does
> not actually retry the group that returned NSS_STATUS_TRYAGAIN, it tries
> to grab the next group off the list. getgrent always returns the next
> gr
Package: nss-updatedb
Version: 7-1.1
Severity: important
Hi there,
In updatedb.c, the logic is this:
status = vtable->setent();
if (status != NSS_STATUS_SUCCESS) {
return status;
}
tryagain:
do {
status = vtable->getent((void *)&re
13 matches
Mail list logo
