> I plan to wait for a new upstream version before uplaoding a new
> package, but I could provide you with an updated version if you want.
that's ok. It only affects the test rig, not production use.
Thanks for taking the time to look into it.
Cheers
Vince
--
To UNSUBSCRIBE, email to [EMAIL
forwarded 417396 johanATekenbergDOTse
tag 417396 + pending
tag 417396 + patch
thanks
Hi Vincent!
You wrote:
> I did some tests with real filesystems on block devices, instead of
> loopback devices, on an etch system that previously exhibited the bug.
> (nis 3.17-6, libc6 2.3.6.ds1-13)
I finally
just to folow up on this.
I did some tests with real filesystems on block devices, instead of
loopback devices, on an etch system that previously exhibited the bug.
(nis 3.17-6, libc6 2.3.6.ds1-13)
While the system still showed the bug with ext3 filesystem images mounted
via /dev/loopN, it did n
> > are in the same autofs+NIS environment as the etch boxes above.
> > On those hosts, quotatool (1.4.7-1) works.
>
> Ok, that's pretty weird. I'm particularly amazed that 1.4.7 does work,
> as the changes with 1.4.9 are very minor. So that really suggests some
> kind of glibc or yp bug. Could
Hi Vincent!
Thanks for your report!
You wrote:
> I was doing some tests of quotatool and found that on some combinations
> of package versions it would fail because it was trying to do a quotactl()
> call to a block device name with an extra octal byte appended, e.g.
> quotactl(Q_GETFMT|USRQUO
Package: quotatool
Version: 1.4.9-2
Severity: normal
*** Please type your report below this line ***
Hi,
this may need a retitle once we narrow down what is actually going wrong.
I was doing some tests of quotatool and found that on some combinations
of package versions it would fail because it
6 matches
Mail list logo
