I changed the order of programs so shadow's su is installed before
coreutils, but this is not doing the right thing for the coreutils tests.
We not get "bash: make: command not found". It looks like we need to
either move make in Chapter 6 or set the 'nobody' PATH to i
On 2012-04-29 07:09, Matt Burgess wrote:
> On Sun, 2012-04-29 at 00:39 +0100, Ken Moffat wrote:
>
>> I'm assuming this is from gnulib-tests/test-getlogin.c. Not seen
>> this failure in my builds earlier this week, perhaps it's a one-off
>> or perhaps something in the 3.3.4 headers has changed.
>
On Mon, Apr 30, 2012 at 01:07:30PM +0100, Ken Moffat wrote:
> On Mon, Apr 30, 2012 at 08:12:10AM +0100, Matt Burgess wrote:
> > On Mon, 2012-04-30 at 04:59 +0100, Ken Moffat wrote:
> >
> > > As I said originally, this was a new failure for me. And also, the
> > > sed doesn't seem to fix it.
> >
On Mon, Apr 30, 2012 at 08:12:10AM +0100, Matt Burgess wrote:
> On Mon, 2012-04-30 at 04:59 +0100, Ken Moffat wrote:
>
> > As I said originally, this was a new failure for me. And also, the
> > sed doesn't seem to fix it.
>
> That's interesting. Would you be able to put some debugging output i
On Mon, 2012-04-30 at 04:59 +0100, Ken Moffat wrote:
> As I said originally, this was a new failure for me. And also, the
> sed doesn't seem to fix it.
That's interesting. Would you be able to put some debugging output into
the test-getlogin.c file to see where abouts it is failing, and why?
On Sun, Apr 29, 2012 at 06:01:08PM +0100, Ken Moffat wrote:
> >
> > There's a sed in the book to avoid the test failure. The sed is not the
> > right fix, but I'm working on-and-off with upstream to try and get to
> > the bottom of the issue.
> >
> > Regards,
> >
> > Matt.
> >
> Thanks - I th
On Sun, Apr 29, 2012 at 06:09:58AM +0100, Matt Burgess wrote:
> On Sun, 2012-04-29 at 00:39 +0100, Ken Moffat wrote:
>
> > I'm assuming this is from gnulib-tests/test-getlogin.c. Not seen
> > this failure in my builds earlier this week, perhaps it's a one-off
> > or perhaps something in the 3.3.
On Sun, 2012-04-29 at 00:39 +0100, Ken Moffat wrote:
> I'm assuming this is from gnulib-tests/test-getlogin.c. Not seen
> this failure in my builds earlier this week, perhaps it's a one-off
> or perhaps something in the 3.3.4 headers has changed.
There's a sed in the book to avoid the test fail
Ken Moffat wrote:
> Thanks. It wasn't known to me and it didn't fail from the same
> script, invoked in the same way, using the 20120419 or 20120425
> books, or indeed 7.1. Coreutils was one of those packages where
> it was hard to miss failures in the testsuite.
test-getlogin was not in coreu
On Sat, Apr 28, 2012 at 06:54:58PM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> >
> > I'm assuming this is from gnulib-tests/test-getlogin.c. Not seen
> > this failure in my builds earlier this week, perhaps it's a one-off
> > or perhaps something in the 3.3.4 headers has changed.
> >
> > O
Ken Moffat wrote:
> (resending, hopefully I've got the right list this time)
>
> I'm building the current book with the newer grep, man-pages,
> kernel-headers, and autofoo that Matt is working on. This is as a
> test of my hardware (looking good at the moment, but a few BLFS
> packages have ca
(resending, hopefully I've got the right list this time)
I'm building the current book with the newer grep, man-pages,
kernel-headers, and autofoo that Matt is working on. This is as a
test of my hardware (looking good at the moment, but a few BLFS
packages have caused me ICEs recently, so not
On 30/09/2011 00:44, Bruce Dubbs wrote:
> The help-version test is doing:
>
> for i in $built_programs; do
> v=$(env $i --version | sed -n '1s/.* //p;q')
> break
> done
>
> And failing with 'env: cd: No such file or directory'
>
> $built_programs is returning:
>
> cd ..&& /bin/sh ./config
On 30/09/2011 00:44, Bruce Dubbs wrote:
> Matthew Burgess wrote:
>> Hi,
>>
>> For a while now, I've had 2 test failures in coreutils, but have just
>> ignored them. With the latest version I saw a 3rd failure, which made
>> me relook at Coreutils' test suite. The failures I see are:
>>
>> misc/he
Matthew Burgess wrote:
> Hi,
>
> For a while now, I've had 2 test failures in coreutils, but have just
> ignored them. With the latest version I saw a 3rd failure, which made
> me relook at Coreutils' test suite. The failures I see are:
>
> misc/help-version
> misc/invalid-opt
> rm/many-dir-e
Hi,
For a while now, I've had 2 test failures in coreutils, but have just
ignored them. With the latest version I saw a 3rd failure, which made
me relook at Coreutils' test suite. The failures I see are:
misc/help-version
misc/invalid-opt
rm/many-dir-entries-vs-OOM
The 1st 2 tests pass if I
On Tue, 22 Nov 2005, Matthew Burgess wrote:
Yep, I ran into the same issue. Testing suggested that the /etc/passwd entry
for users you want to `su' to need a home dir. I therefore changed the
creation of the dummy user to:
echo "dummy:x:1000:1000::/root:/bin/bash" >> /etc/passwd
Have you
Ken Moffat wrote:
I'm running into problems with the "src/su dummy -c "make
RUN_EXPENSIVE_TESTS=yes check" tests on a new architecture - it's
telling me that user dummy doesn't exist with both 5.92 and 5.93, but
5.2.1 passes without errors.
Looking at my notes and scripts, this is the first
I'm running into problems with the "src/su dummy -c "make
RUN_EXPENSIVE_TESTS=yes check" tests on a new architecture - it's
telling me that user dummy doesn't exist with both 5.92 and 5.93, but
5.2.1 passes without errors.
Looking at my notes and scripts, this is the first time I've tried
e
19 matches
Mail list logo
