Discussion:
[lfs-dev] LFS Package Currency Check - 2013-08-13
Bruce Dubbs
2013-08-13 02:31:23 UTC
Permalink
***@linuxfromscratch.org wrote:
> Package LFS Upstream Flag

> glibc 2.17 2.18 *
> perl 5.18.0 5.18.1 *

Two relatively important packages just changed. Looking at the change
logs, I didn't see anything that would change the book's instructions.
I'll try a full build tonight.

-- Bruce
Ken Moffat
2013-08-13 18:46:25 UTC
Permalink
On Mon, Aug 12, 2013 at 09:31:23PM -0500, Bruce Dubbs wrote:
> ***@linuxfromscratch.org wrote:
> > Package LFS Upstream Flag
>
> > glibc 2.17 2.18 *
> > perl 5.18.0 5.18.1 *
>
> Two relatively important packages just changed. Looking at the change
> logs, I didn't see anything that would change the book's instructions.
> I'll try a full build tonight.
>
> -- Bruce
>
Relase notes are at
http://article.gmane.org/gmane.comp.lib.glibc.alpha/34237

The pt_chown program is now disabled by default (CVE-2013-2207,
glibc bugzilla #15755 - incorrectly granting access to another
user's pseudo-terminal). I assume we can just remove it from the
list of programs installed ?

ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
Ken Moffat
2013-08-13 18:59:49 UTC
Permalink
On Tue, Aug 13, 2013 at 07:46:25PM +0100, Ken Moffat wrote:
> On Mon, Aug 12, 2013 at 09:31:23PM -0500, Bruce Dubbs wrote:
> > ***@linuxfromscratch.org wrote:
> > > Package LFS Upstream Flag
> >
> > > glibc 2.17 2.18 *
> > > perl 5.18.0 5.18.1 *
> >
> > Two relatively important packages just changed. Looking at the change
> > logs, I didn't see anything that would change the book's instructions.
> > I'll try a full build tonight.
> >
> > -- Bruce
> >
> Relase notes are at
s/Relase/glibc Release/
> http://article.gmane.org/gmane.comp.lib.glibc.alpha/34237
>
> The pt_chown program is now disabled by default (CVE-2013-2207,
> glibc bugzilla #15755 - incorrectly granting access to another
> user's pseudo-terminal). I assume we can just remove it from the
> list of programs installed ?
>
> ĸen
ĸ
--
das eine Mal als Tragödie, das andere Mal als Farce
John Burrell
2013-08-13 19:02:37 UTC
Permalink
>>
> Relase notes are at
> http://article.gmane.org/gmane.comp.lib.glibc.alpha/34237
>
> The pt_chown program is now disabled by default (CVE-2013-2207,
> glibc bugzilla #15755 - incorrectly granting access to another
> user's pseudo-terminal). I assume we can just remove it from the
> list of programs installed ?
>

Under 'The meaning of the configure options' in glibc would you provide a note about
this and mention that to install pt_chown add --enable-pt_chown

I don't know if things have changed, but I needed pt_chown to create the ptys for expect, which is installed for the test suites.

Thanks

jb.
Bruce Dubbs
2013-08-13 20:00:13 UTC
Permalink
John Burrell wrote:
>>>
>> Relase notes are at
>> http://article.gmane.org/gmane.comp.lib.glibc.alpha/34237
>>
>> The pt_chown program is now disabled by default (CVE-2013-2207,
>> glibc bugzilla #15755 - incorrectly granting access to another
>> user's pseudo-terminal). I assume we can just remove it from the
>> list of programs installed ?

Yes, I think so. We do use --libexecdir=/usr/lib/glibc, but the only
thing now there is 'getconf'.

> Under 'The meaning of the configure options' in glibc would you
> provide a note about this and mention that to install pt_chown add
> --enable-pt_chown
>
> I don't know if things have changed, but I needed pt_chown to create
> the ptys for expect, which is installed for the test suites.

I did a grep through the expect source and fond no hits for pt_chown.

I did find a few check errors in the build:


090-coreutils:FAIL: tests/df/skip-rootfs.sh
090-coreutils:FAIL: tests/df/skip-rootfs.sh (exit: 1)

103-automake:FAIL: t/primary-prefix-invalid-couples.tap 280 - ... and
with the same diagnostic of 'automake -a'
103-automake:# FAIL: 1

107-flex:Test test-bison-yylloc FAILED. See test-bison-yylloc/OUTPUT for
details.
107-flex:Test test-bison-yylval FAILED. See test-bison-yylval/OUTPUT for
details.

124-texinfo:FAIL: prove.sh

072-glibc:make[3]: *** [/sources/glibc-build/posix/tst-getaddrinfo4.out]
Error 1
072-glibc:make[3]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored)
072-glibc:make[3]: *** [/sources/glibc-build/rt/tst-cputimer1.out] Error 1
072-glibc:make[3]: [/sources/glibc-build/conform/run-conformtest.out]
Error 1 (ignored)

086-util-linux:make[1]: make[4]: *** [check] Error 2***
[check-local-tests] Terminated

089-e2fsprogs:make[2]: *** [test_post] Error 1

090-coreutils:make[5]: *** [tests/test-suite.log] Error 1

093-bison:make[4]: ***
[examples/calc++/examples_calc___calc__-calc++-scanner.o] Error 1

I'm investigating.

-- Bruce
Matt Burgess
2013-08-13 20:31:15 UTC
Permalink
On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:

> 086-util-linux:make[1]: make[4]: *** [check] Error 2***
> [check-local-tests] Terminated

Ah, good. I just hit that one in last night's build. It's in
misc/fallocate. I haven't had a change to look into it in any depth,
but it's always reassuring when somebody else has hit it too :-)

Regards,

Matt.
Matt Burgess
2013-08-13 21:50:01 UTC
Permalink
On Tue, 2013-08-13 at 21:31 +0100, Matt Burgess wrote:
> On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:
>
> > 086-util-linux:make[1]: make[4]: *** [check] Error 2***
> > [check-local-tests] Terminated
>
> Ah, good. I just hit that one in last night's build. It's in
> misc/fallocate. I haven't had a change to look into it in any depth,
> but it's always reassuring when somebody else has hit it too :-)

Looks like this may be an artifact of building on a filesystem created
some time ago. The command that is run by the testsuite is:

./fallocate -o 128 -l 256 <output file>

This fails ('Operation unsupported') if the output file is on the FS
mounted on /mnt/lfs, which it obviously will be within the chroot
environment in chapter 6. If I come out of chroot, run ./fallocate from
within the util-linux build directory and instead get it to output a
file to my hosts's FS, it works fine.

The features of /dev/sda3 (the device underlying /mnt/lfs) were:

has_journal ext_attr resize_inode dir_index filetype sparse_super
large_file

I've now just blatted it, and recreated the fs using 'mkfs -v -t
ext4 /dev/sda3' and now its features are:

has_journal ext_attr resize_inode dir_index filetype extent flex_bg
sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

I *think* the former feature set is for ext3, and the latter for ext4,
but I could have sworn I'd created an ext4 FS ages ago (my
host's /etc/fstab certainly tries to mount it as ext4
and /var/log/messages doesn't suggest it's falling back to ext3).

Another build is underway so hopefully I'll be able to report success at
some point tomorrow.

Regards,

Matt.
Bruce Dubbs
2013-08-13 22:19:53 UTC
Permalink
Matt Burgess wrote:
> On Tue, 2013-08-13 at 21:31 +0100, Matt Burgess wrote:
>> On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:
>>
>>> 086-util-linux:make[1]: make[4]: *** [check] Error 2***
>>> [check-local-tests] Terminated
>>
>> Ah, good. I just hit that one in last night's build. It's in
>> misc/fallocate. I haven't had a change to look into it in any depth,
>> but it's always reassuring when somebody else has hit it too :-)
>
> Looks like this may be an artifact of building on a filesystem created
> some time ago. The command that is run by the testsuite is:
>
> ./fallocate -o 128 -l 256 <output file>
>
> This fails ('Operation unsupported') if the output file is on the FS
> mounted on /mnt/lfs, which it obviously will be within the chroot
> environment in chapter 6. If I come out of chroot, run ./fallocate from
> within the util-linux build directory and instead get it to output a
> file to my hosts's FS, it works fine.
>
> The features of /dev/sda3 (the device underlying /mnt/lfs) were:
>
> has_journal ext_attr resize_inode dir_index filetype sparse_super
> large_file
>
> I've now just blatted it, and recreated the fs using 'mkfs -v -t
> ext4 /dev/sda3' and now its features are:
>
> has_journal ext_attr resize_inode dir_index filetype extent flex_bg
> sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
>
> I *think* the former feature set is for ext3, and the latter for ext4,
> but I could have sworn I'd created an ext4 FS ages ago (my
> host's /etc/fstab certainly tries to mount it as ext4
> and /var/log/messages doesn't suggest it's falling back to ext3).

I doubt that is my problem, I'm using an ext4 partition that I
just created about a month ago.

/dev/sdb2 on /mnt/lfs type ext4 (rw,relatime,data=ordered)

The error I'm getting is:

script: race conditions ...script: openpty
failed: Operation not permitted
make[1]: *** wait: No child processes. Stop.
make[1]: *** Waiting for unfinished jobs....
make[1]: *** wait: No child processes. Stop.
make[3]: *** [check-local-tests] Terminated
make: *** wait: No child processes. Stop.
make: *** Waiting for unfinished jobs....
make: *** wait: No child processes. Stop.
make[2]: *** [check-am] Terminated

It looks like this is due to the change in glibc because this passed
before I update to glibc-2.18.

-- Bruce
Bruce Dubbs
2013-08-14 01:25:23 UTC
Permalink
Bruce Dubbs wrote:
> Matt Burgess wrote:
>> On Tue, 2013-08-13 at 21:31 +0100, Matt Burgess wrote:
>>> On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:

>
> /dev/sdb2 on /mnt/lfs type ext4 (rw,relatime,data=ordered)
>
> The error I'm getting is:
>
> script: race conditions ...script: openpty
> failed: Operation not permitted
> make[1]: *** wait: No child processes. Stop.
> make[1]: *** Waiting for unfinished jobs....
> make[1]: *** wait: No child processes. Stop.
> make[3]: *** [check-local-tests] Terminated
> make: *** wait: No child processes. Stop.
> make: *** Waiting for unfinished jobs....
> make: *** wait: No child processes. Stop.
> make[2]: *** [check-am] Terminated
>
> It looks like this is due to the change in glibc because this passed
> before I update to glibc-2.18.

OK, I've confirmed that the test identified by

script: race conditions

fails with a non-root user and passes with a root user. We can change
this test to be ignored with:

sed -i -e "/^ts_init/a\
ts_skip_nonroot" tests/ts/script/race

or on one line

sed -i -e "/^ts_init/s/$/\nts_skip_nonroot/" tests/ts/script/race

-- Bruce
Bryan Kadzban
2013-08-14 05:35:38 UTC
Permalink
Bruce Dubbs wrote:
> Bruce Dubbs wrote:
>> script: race conditions ...script: openpty
>> failed: Operation not permitted
>> <...>
>>
>> It looks like this is due to the change in glibc because this passed
>> before I update to glibc-2.18.
>
> OK, I've confirmed that the test identified by
>
> script: race conditions
>
> fails with a non-root user and passes with a root user. We can change
> this test to be ignored with:
>
> sed -i -e "/^ts_init/a\
> ts_skip_nonroot" tests/ts/script/race

This seems odd; it used to be that pt_chown was only necessary when
/dev/pts was not mounted as a devpts filesystem, and if it was, then the
kernel would do the right thing automatically (that is, the grantpt()
call, while still a good idea, is not strictly necessary, and if called
would do nothing).

It's been way too long since I've done a chapter-6 build, but aren't we
using the host's devpts setup?

...

Yeah, looking at chapter06/kernfs.html from svn, we are. So I'd be
surprised if pt_chown was actually needed inside the chroot.

But maybe something else changed. What happens if you:

cat <<'EOF' >testpt.c
#define _XOPEN_SOURCE 600
#include <stdlib.h>
#include <fcntl.h>
#include <stdio.h>

int main() {
int masterfd;
char buf[1024];

masterfd = posix_openpt(O_RDWR | O_NOCTTY);

if (masterfd < 0) {
perror("posix_openpt");
return 1;
}

printf("posix_openpt succeeded\n");

if (grantpt(masterfd) < 0) {
perror("grantpt");
return 1;
}

printf("grantpt succeeded; stat the new file and hit enter\n");

fgets(buf, sizeof(buf), stdin);

return 0;
}
EOF
make testpts
ls /dev/pts
<note the files present>
./testpts
^Z
ls /dev/pts
stat /dev/pts/<new file>
fg
<enter>
rm testpts testpts.c

What are the permissions and ownership of the new slave pty file? On my
system, with /dev/pts mounted and pt_chown missing, I get:

File: `/dev/pts/6'
Size: 0 Blocks: 0 IO Block: 1024 character
special file
Device: ah/10d Inode: 9 Links: 1 Device type: 88,6
Access: (0620/crw--w----) Uid: ( 501/ <me>) Gid: ( 4/ tty)
Access: 2013-08-13 22:27:12.226312570 -0700
Modify: 2013-08-13 22:27:12.226312570 -0700
Change: 2013-08-13 22:27:12.226312570 -0700

But then, this is what I'd expect, as my user has permission to chgrp
the file to tty, but even without that, it starts out owned by <me>/tty
and 0620 before the grantpt() call happens. (Verified by comparing "ls
-l /dev/pts/" and "(ls -l /dev/pts/) </dev/ptmx". With the extra handle
open, the new file is definitely owned by me/tty, and 0620.)

This is also glibc 2.10.1 (I said it'd been too long... :-) ).
Bruce Dubbs
2013-08-14 16:12:48 UTC
Permalink
Bryan Kadzban wrote:

> But maybe something else changed. What happens if you:

> ls /dev/pts
> <note the files present>
> ./testpts

At this point as user nobody (in chroot), I get:

nobody:/tmp$ ./testpt
posix_openpt succeeded
grantpt: Operation not permitted

It works fine with user root or on a glibc-2.17 system as a regular user.

-- Bruce
Bryan Kadzban
2013-08-15 06:30:33 UTC
Permalink
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> But maybe something else changed. What happens if you:
>
>> ls /dev/pts
>> <note the files present>
>> ./testpts
>
> At this point as user nobody (in chroot), I get:
>
> nobody:/tmp$ ./testpt
> posix_openpt succeeded
> grantpt: Operation not permitted

That's not right. :-)

What happens if you try to ls -l the new slave char device?

ls -l /dev/pts
(ls -l /dev/pts) </dev/ptmx

The latter should show one more device than the former; the owner,
group, and permissions on that should be you, tty, and 0620, otherwise
(IIRC) pt_chown is necessary. (I should probably go dig through the
glibc sources for grantpt() to find out for sure though.)

...Wait, this might be the issue. chapter06/kernfs.html says:

mount -vt devpts devpts $LFS/dev/pts

but my fstab has:

devpts /dev/pts devpts gid=4,mode=620 0 0

The mount probably needs -o gid=4,mode=620 added. If you add that, do
both the tests start working?

...And now that I say that, I think I have a change hanging around in my
local svn repo that I never submitted, that adds this to this chapter 6
mount command. If it fixes this, I should probably submit it.
Bruce Dubbs
2013-08-15 14:10:10 UTC
Permalink
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> Bryan Kadzban wrote:
>>
>>> But maybe something else changed. What happens if you:
>>
>>> ls /dev/pts
>>> <note the files present>
>>> ./testpts
>>
>> At this point as user nobody (in chroot), I get:
>>
>> nobody:/tmp$ ./testpt
>> posix_openpt succeeded
>> grantpt: Operation not permitted
>
> That's not right. :-)
>
> What happens if you try to ls -l the new slave char device?
>
> ls -l /dev/pts
> (ls -l /dev/pts) </dev/ptmx
>
> The latter should show one more device than the former; the owner,
> group, and permissions on that should be you, tty, and 0620, otherwise
> (IIRC) pt_chown is necessary. (I should probably go dig through the
> glibc sources for grantpt() to find out for sure though.)
>
> ...Wait, this might be the issue. chapter06/kernfs.html says:
>
> mount -vt devpts devpts $LFS/dev/pts
>
> but my fstab has:
>
> devpts /dev/pts devpts gid=4,mode=620 0 0
>
> The mount probably needs -o gid=4,mode=620 added. If you add that, do
> both the tests start working?

You really need to keep up to date a little more. We changed tty to gid
5 quite a while ago (April 2012).

In any case, remounting /dev/pts with the proper options did work for
./testpt. Rerunning the util-linux tests with the /dev/pts mounted with
the proper options did indeed allow the non-root tests to pass.

> ...And now that I say that, I think I have a change hanging around in my
> local svn repo that I never submitted, that adds this to this chapter 6
> mount command. If it fixes this, I should probably submit it.

I'll go ahead and make the change to the book.

-- Bruce
Bryan Kadzban
2013-08-16 02:27:07 UTC
Permalink
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> ...Wait, this might be the issue. chapter06/kernfs.html says:
>>
>> mount -vt devpts devpts $LFS/dev/pts
>>
>> but my fstab has:
>>
>> devpts /dev/pts devpts gid=4,mode=620 0 0
>>
>> The mount probably needs -o gid=4,mode=620 added. If you add that,
>> do both the tests start working?
>
> You really need to keep up to date a little more. We changed tty to
> gid 5 quite a while ago (April 2012).

Ugh, I know I need to keep more up to date. Still on glibc 2.10.1 too.
I don't think I've rebuilt this system in something like 4 years. :-/

(The reason I haven't is that I use this as my main system, so
rebuilding LFS means also rebuilding a lot of BLFS, or at least enough
to get ff, thunderbird, and chrome (with nacl) working, and preferably a
bunch of games too.)

I should probably just make another LV to build recent books into and
use for this kind of investigation, leaving the main system to ... well,
shall we say, age. :-P

> In any case, remounting /dev/pts with the proper options did work for
> ./testpt. Rerunning the util-linux tests with the /dev/pts mounted
> with the proper options did indeed allow the non-root tests to pass.

OK, let me submit that change then.

>> ...And now that I say that, I think I have a change hanging around
>> in my local svn repo that I never submitted, that adds this to this
>> chapter 6 mount command. If it fixes this, I should probably
>> submit it.
>
> I'll go ahead and make the change to the book.

...Or let you do it. :-)

I had a couple of explanatory paragraphs on top of just adding the -o
flag, so I'll sync your change in and add them too.
Bruce Dubbs
2013-08-16 03:04:30 UTC
Permalink
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> Bryan Kadzban wrote:
>>> ...Wait, this might be the issue. chapter06/kernfs.html says:
>>>
>>> mount -vt devpts devpts $LFS/dev/pts
>>>
>>> but my fstab has:
>>>
>>> devpts /dev/pts devpts gid=4,mode=620 0 0
>>>
>>> The mount probably needs -o gid=4,mode=620 added. If you add that,
>>> do both the tests start working?
>>
>> You really need to keep up to date a little more. We changed tty to
>> gid 5 quite a while ago (April 2012).
>
> Ugh, I know I need to keep more up to date. Still on glibc 2.10.1 too.
> I don't think I've rebuilt this system in something like 4 years. :-/
>
> (The reason I haven't is that I use this as my main system, so
> rebuilding LFS means also rebuilding a lot of BLFS, or at least enough
> to get ff, thunderbird, and chrome (with nacl) working, and preferably a
> bunch of games too.)
>
> I should probably just make another LV to build recent books into and
> use for this kind of investigation, leaving the main system to ... well,
> shall we say, age. :-P

Well my main system aged quite well from 2005 to 2012. I finally
updated it because I needed to update glibc from 2.6.

>> In any case, remounting /dev/pts with the proper options did work for
>> ./testpt. Rerunning the util-linux tests with the /dev/pts mounted
>> with the proper options did indeed allow the non-root tests to pass.
>
> OK, let me submit that change then.
>
>>> ...And now that I say that, I think I have a change hanging around
>>> in my local svn repo that I never submitted, that adds this to this
>>> chapter 6 mount command. If it fixes this, I should probably
>>> submit it.
>>
>> I'll go ahead and make the change to the book.
>
> ...Or let you do it. :-)

That's already done.

> I had a couple of explanatory paragraphs on top of just adding the -o
> flag, so I'll sync your change in and add them too.

That would be fine.

-- Bruce
Matt Burgess
2013-08-14 18:18:50 UTC
Permalink
On Tue, 2013-08-13 at 22:50 +0100, Matt Burgess wrote:

> Another build is underway so hopefully I'll be able to report success at
> some point tomorrow.

Yes, success of sorts. The fallocate test now passes, but I'm now
hitting the same failure as Bruce is in the 'race conditions' script.

Regards,

Matt.
Ken Moffat
2013-08-13 21:53:04 UTC
Permalink
On Tue, Aug 13, 2013 at 09:31:15PM +0100, Matt Burgess wrote:
> On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:
>
> > 086-util-linux:make[1]: make[4]: *** [check] Error 2***
> > [check-local-tests] Terminated
>
> Ah, good. I just hit that one in last night's build. It's in
> misc/fallocate. I haven't had a change to look into it in any depth,
> but it's always reassuring when somebody else has hit it too :-)
>
> Regards,
>
> Matt.
>
That's the one package I'd mentally marked as "do not attempt to
test" (I've never recently used CONFIG_SCSI_DEBUG in my kernels,
and I didn't see any reason to add it - just wastes memory).

Guess I can do so if I sort out my problem with a bovine program.

ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
Ken Moffat
2013-08-13 21:46:41 UTC
Permalink
On Tue, Aug 13, 2013 at 03:00:13PM -0500, Bruce Dubbs wrote:
>
> 107-flex:Test test-bison-yylloc FAILED. See test-bison-yylloc/OUTPUT for
> details.
> 107-flex:Test test-bison-yylval FAILED. See test-bison-yylval/OUTPUT for
> details.
>
[...]
>
> 093-bison:make[4]: ***
> [examples/calc++/examples_calc___calc__-calc++-scanner.o] Error 1
>
> I'm investigating.
>
Good luck!

ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
Matt Burgess
2013-08-17 19:39:57 UTC
Permalink
On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:

> 103-automake:FAIL: t/primary-prefix-invalid-couples.tap 280 - ... and
> with the same diagnostic of 'automake -a'
> 103-automake:# FAIL: 1

I've just hit this one again. It looks like there's a patch for it at
https://lists.nongnu.org/archive/html/bug-automake/2013-07/msg00022.html. I'll test that in my next build, if you're happy for it to go into LFS-7.4-rc2 and to remove the comment about 1 test intermittently failing?

Ta,

Matt.
Bruce Dubbs
2013-08-17 21:16:38 UTC
Permalink
Matt Burgess wrote:
> On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:
>
>> 103-automake:FAIL: t/primary-prefix-invalid-couples.tap 280 - ...
>> and with the same diagnostic of 'automake -a' 103-automake:# FAIL:
>> 1
>
> I've just hit this one again. It looks like there's a patch for it
> at
> https://lists.nongnu.org/archive/html/bug-automake/2013-07/msg00022.html.
> I'll test that in my next build, if you're happy for it to go into
> LFS-7.4-rc2 and to remove the comment about 1 test intermittently
> failing?

I saw this earlier, but did not want to add a patch for one errant test
out of 3000. It's not the code, it's the test. Note that we recommend
not running the test at all, even in Chapter 6.

-- Bruce
Ken Moffat
2013-08-18 02:22:07 UTC
Permalink
On Sat, Aug 17, 2013 at 08:39:57PM +0100, Matt Burgess wrote:
> On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:
>
> > 103-automake:FAIL: t/primary-prefix-invalid-couples.tap 280 - ... and
> > with the same diagnostic of 'automake -a'
> > 103-automake:# FAIL: 1
>
> I've just hit this one again. It looks like there's a patch for it at
> https://lists.nongnu.org/archive/html/bug-automake/2013-07/msg00022.html. I'll test that in my next build, if you're happy for it to go into LFS-7.4-rc2 and to remove the comment about 1 test intermittently failing?
>
> Ta,
>
> Matt.
>
Doesn't apply for me. Not sure why, and I've got enough problems
already. Fixing it would be nice (or, heretically, we could tell
people not to bother with non-toolchain tests ;-)

ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
Ken Moffat
2013-08-18 15:20:00 UTC
Permalink
On Sun, Aug 18, 2013 at 03:22:07AM +0100, Ken Moffat wrote:
> On Sat, Aug 17, 2013 at 08:39:57PM +0100, Matt Burgess wrote:
> > On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:
> >
> > > 103-automake:FAIL: t/primary-prefix-invalid-couples.tap 280 - ... and
> > > with the same diagnostic of 'automake -a'
> > > 103-automake:# FAIL: 1
> >
> > I've just hit this one again. It looks like there's a patch for it at
> > https://lists.nongnu.org/archive/html/bug-automake/2013-07/msg00022.html. I'll test that in my next build, if you're happy for it to go into LFS-7.4-rc2 and to remove the comment about 1 test intermittently failing?
> >
> > Ta,
> >
> > Matt.
> >
> Doesn't apply for me. Not sure why, and I've got enough problems
> already. Fixing it would be nice (or, heretically, we could tell
> people not to bother with non-toolchain tests ;-)
>
Now that I've got that test build booted [still building bison by
hand :-( ] I've taken another look - whitespace differences (columns
offset by two places). Perhaps happened in pasting from the html
page. Fixed up, rediffed. Untested (although a user on the list
reported it fixed the problem) but attached in case anyone else
wants to take a look.

Äžen
--
das eine Mal als Tragödie, das andere Mal als Farce
Matthew Burgess
2013-08-18 16:30:27 UTC
Permalink
On Sun, 18 Aug 2013 16:20:00 +0100, Ken Moffat <***@ntlworld.com> wrote:
> On Sun, Aug 18, 2013 at 03:22:07AM +0100, Ken Moffat wrote:
>> On Sat, Aug 17, 2013 at 08:39:57PM +0100, Matt Burgess wrote:
>> > On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:
>> >
>> > > 103-automake:FAIL: t/primary-prefix-invalid-couples.tap 280 - ...
> and
>> > > with the same diagnostic of 'automake -a'
>> > > 103-automake:# FAIL: 1
>> >
>> > I've just hit this one again. It looks like there's a patch for it at
>> >
> https://lists.nongnu.org/archive/html/bug-automake/2013-07/msg00022.html.
> I'll test that in my next build, if you're happy for it to go into
> LFS-7.4-rc2 and to remove the comment about 1 test intermittently failing?
>> >
>> > Ta,
>> >
>> > Matt.
>> >
>> Doesn't apply for me. Not sure why, and I've got enough problems
>> already. Fixing it would be nice (or, heretically, we could tell
>> people not to bother with non-toolchain tests ;-)
>>
> Now that I've got that test build booted [still building bison by
> hand :-( ] I've taken another look - whitespace differences (columns
> offset by two places). Perhaps happened in pasting from the html
> page. Fixed up, rediffed. Untested (although a user on the list
> reported it fixed the problem) but attached in case anyone else
> wants to take a look.

Sorry Ken, I've been stuck at work all day today, but I've already got
a version tested and passed that I should have informed the list about.
I know there's a recommendation in the book to not run the tests, but
it's the only package that contains a test suite that has such a comment
against it. Yes, the tests take a long time, but they are not dangerous
(as far as I know) and therefore if a user has taken the decision to run
all chapter 6 tests, then these should be run too, IMO.

That said, I'll repeat *again* that I don't see the value in having the
autotools installed in LFS anyway, but I know that's flogging a dead horse.

Cheers,

Matt.
Bruce Dubbs
2013-08-18 19:03:37 UTC
Permalink
Matthew Burgess wrote:
> On Sun, 18 Aug 2013 16:20:00 +0100, Ken Moffat <***@ntlworld.com> wrote:
>> On Sun, Aug 18, 2013 at 03:22:07AM +0100, Ken Moffat wrote:
>>> On Sat, Aug 17, 2013 at 08:39:57PM +0100, Matt Burgess wrote:
>>>> On Tue, 2013-08-13 at 15:00 -0500, Bruce Dubbs wrote:
>>>>
>>>>> 103-automake:FAIL: t/primary-prefix-invalid-couples.tap 280 - ...
>> and
>>>>> with the same diagnostic of 'automake -a'
>>>>> 103-automake:# FAIL: 1
>>>>
>>>> I've just hit this one again. It looks like there's a patch for it at
>>>>
>> https://lists.nongnu.org/archive/html/bug-automake/2013-07/msg00022.html.
>> I'll test that in my next build, if you're happy for it to go into
>> LFS-7.4-rc2 and to remove the comment about 1 test intermittently failing?
>>>>
>>>> Ta,
>>>>
>>>> Matt.
>>>>
>>> Doesn't apply for me. Not sure why, and I've got enough problems
>>> already. Fixing it would be nice (or, heretically, we could tell
>>> people not to bother with non-toolchain tests ;-)
>>>
>> Now that I've got that test build booted [still building bison by
>> hand :-( ] I've taken another look - whitespace differences (columns
>> offset by two places). Perhaps happened in pasting from the html
>> page. Fixed up, rediffed. Untested (although a user on the list
>> reported it fixed the problem) but attached in case anyone else
>> wants to take a look.
>
> Sorry Ken, I've been stuck at work all day today, but I've already got
> a version tested and passed that I should have informed the list about.
> I know there's a recommendation in the book to not run the tests, but
> it's the only package that contains a test suite that has such a comment
> against it. Yes, the tests take a long time, but they are not dangerous
> (as far as I know) and therefore if a user has taken the decision to run
> all chapter 6 tests, then these should be run too, IMO.

The recommendation is because it takes too much time (over an hour on my
system) and the tests are pretty much valueless. I agree that, other
than time, they cause no harm. As a developer, I do run them (so users
don't need to).

> That said, I'll repeat *again* that I don't see the value in having the
> autotools installed in LFS anyway, but I know that's flogging a dead horse.

Well, for one thing, they are needed for Xorg (libxcb, mesalib, and
x7driver-glamor). I count 14 apps in BLFS that need autotools.

-- Bruce
Matt Burgess
2013-08-18 20:47:54 UTC
Permalink
On Sun, 2013-08-18 at 14:03 -0500, Bruce Dubbs wrote:

> The recommendation is because it takes too much time (over an hour on my
> system) and the tests are pretty much valueless.

No more lacking in value from other non-toolchain test suites, surely?
I understand that the time it takes to run them is disproportionate to
the value of the package, but there's already a warning about the length
of time that it'll take to run. All I'm saying is that I don't think
the explicit recommendation to avoid the test suite is required (user's
can make their own minds up based on the timing note on the page).

As an editor, I want users to be able to choose whether or not to run
the tests based on suitable information, but when they choose to run
them they shouldn't get any test failures if we have a) seen them before
and b) have a known fix.

The way the automake page is written at present, it will look really odd
if I add a patch that fixes the test suite, only for us to then
recommend that the tests aren't run. But, if I don't add the patch to
the book, folks that want to run the tests will hit the same failure
that we already have a fix for.

Regards,

Matt.
Bruce Dubbs
2013-08-18 23:52:15 UTC
Permalink
Matt Burgess wrote:
> On Sun, 2013-08-18 at 14:03 -0500, Bruce Dubbs wrote:
>
>> The recommendation is because it takes too much time (over an hour on my
>> system) and the tests are pretty much valueless.
>
> No more lacking in value from other non-toolchain test suites, surely?
> I understand that the time it takes to run them is disproportionate to
> the value of the package, but there's already a warning about the length
> of time that it'll take to run. All I'm saying is that I don't think
> the explicit recommendation to avoid the test suite is required (user's
> can make their own minds up based on the timing note on the page).
>
> As an editor, I want users to be able to choose whether or not to run
> the tests based on suitable information, but when they choose to run
> them they shouldn't get any test failures if we have a) seen them before
> and b) have a known fix.
>
> The way the automake page is written at present, it will look really odd
> if I add a patch that fixes the test suite, only for us to then
> recommend that the tests aren't run. But, if I don't add the patch to
> the book, folks that want to run the tests will hit the same failure
> that we already have a fix for.

OK, add the patch. We can leave off the recommendation. I think

Approximate build time: less than 0.1 SBU (34.1 SBU with tests)

says enough.

-- Bruce
Ken Moffat
2013-08-18 21:16:33 UTC
Permalink
On Sun, Aug 18, 2013 at 02:03:37PM -0500, Bruce Dubbs wrote:
>
> The recommendation is because it takes too much time (over an hour on my
> system) and the tests are pretty much valueless. I agree that, other
> than time, they cause no harm. As a developer, I do run them (so users
> don't need to).
>
If you have a multiprocessor machine (and if you don't, building
anything nowadays is horribly slow), the automake tests can be run
in parallel. Still takes quite a long time (towards 20 minutes on my
SandyBridge last night, I think), but it helps - at least on those of
my machines where the kernel sees 4 CPUs.

ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
Bruce Dubbs
2013-08-18 23:56:35 UTC
Permalink
Ken Moffat wrote:
> On Sun, Aug 18, 2013 at 02:03:37PM -0500, Bruce Dubbs wrote:
>>
>> The recommendation is because it takes too much time (over an hour on my
>> system) and the tests are pretty much valueless. I agree that, other
>> than time, they cause no harm. As a developer, I do run them (so users
>> don't need to).
>>
> If you have a multiprocessor machine (and if you don't, building
> anything nowadays is horribly slow), the automake tests can be run
> in parallel. Still takes quite a long time (towards 20 minutes on my
> SandyBridge last night, I think), but it helps - at least on those of
> my machines where the kernel sees 4 CPUs.

My system is a 3 GHz core2duo, but I always do the timing for the books
in a single thread for consistency and for the log to be coherent. Most
builds are in the 1 SBU range or less, but there are some really long
ones too.

-- Bruce
Ken Moffat
2013-08-19 02:36:03 UTC
Permalink
On Sun, Aug 18, 2013 at 06:56:35PM -0500, Bruce Dubbs wrote:
>
> My system is a 3 GHz core2duo, but I always do the timing for the books
> in a single thread for consistency and for the log to be coherent. Most
> builds are in the 1 SBU range or less, but there are some really long
> ones too.
>
> -- Bruce
>
Yes, a single thread to get timings for the book is the right thing
to do. But I only do that when making a substantive change, and for
chapter 6 and later I can run a single-threaded build of the package
in the finished system.

For me, most of my builds aren't doing much new in LFS so I can
run with -j4 and look at any details later.

ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
Loading...