Re: [lfs-dev] Final call for changes before LFS/BLFS 10.1 release

[Ken Moffat via lfs-dev]

On Wed, Mar 03, 2021 at 11:37:25AM +0800, Kevin Buckley via lfs-dev wrote:
> 
> I am aware that LFS expects the user to have all the sources unpacked,
> somewhere, and doesn't provide explict instructions for doing so, nor for
> changing into the package's source directory, at the package level, but I
> have found that doing something akin to

Pedantically, LFS and BLFS expect the user to have the source
packages (tarballs, or in BLFS occasionally zip files) somewhere.
Using /sources is conventional.

My point is that you should not unpack then until you build them,
and if you need to build them again you should remove the directory
and unpack again.

> 
> export SOURCE=`echo  | cut -d/ -f 3-`
> tar xf $LFSSRCS/$SOURCE
> cd dejagnu-
> 
> is a bit more explict and ties in nicely to the predefined Entities that
> the Book sources already proivde, so as to give a deterministic set
> of instructions.

You've benn spoiled!  In some cases (mostly in BLFS, but I expect
that LFS will also see this) the directory name does not match the
tarball name - e.g. unversioned directory name.

ĸen
-- 
RIGHT, he said, PESTILENCE, OPEN ANOTHER PACK OF CARDS. I'M GOING TO GET
TO THE BOTTOM OF THIS IF IT KILLS ME, FIGURATIVELY SPEAKING OF COURSE.
Rincewind grabbed Twoflower and pulled.  -- The Light Fantastic
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] High cpu usage for Xorg in xfce. Solved.

[Ken Moffat via lfs-dev]

On Sat, Feb 27, 2021 at 02:15:48AM +, Ken Moffat via lfs-dev wrote:
> I mostly only use xfce on my laptop, but before upgrading that I
> want to feel that the new build will be worthwhile.  The laptop is a
> zen1+ so I mostly test full xfce on a desktop zen1+ with 8 CPUs
> (technically, 4 + multi threading) which is similar to what is on
> the laptop, except faster and with more RAM.
> 
> I happened to be watching 'top' while building nss-3.62 with -j4 and
> noticed that Xorg was using around 115% CPU.  Later I thought that
> maybe this was overhead from xfce4-terminal which I was running with
>  2>&1 | tee mylog
> (I know xfce4-terminal is slow when starting, typing lags for a few
> seconds, and I assumed that the scrolling display might be
> involved.)
> 
> But I've just started xfce on my 4-core (no SMT) zen1 and again it
> is using around 115% CPU.
> 
> Colour me "disappointed".
> 

Oftentimes, describing the problem helps me to think of things to
google for.  There are a lot of posts about high CPU usage in xfce
over the years, for all sorts of reasons (e.g. binary display
drivers), but I found
https://forum.artixlinux.org/index.php/topic,980.0.html

and indeed the xfce calculator plugin WAS the problem.  With that
removed, Xorg is back to around 2% CPU usage.

ĸen
-- 
 When someone told me I lived in a
 fantasy land I nearly fell off my unicorn.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] High cpu usage for Xorg in xfce.

[Ken Moffat via lfs-dev]

I mostly only use xfce on my laptop, but before upgrading that I
want to feel that the new build will be worthwhile.  The laptop is a
zen1+ so I mostly test full xfce on a desktop zen1+ with 8 CPUs
(technically, 4 + multi threading) which is similar to what is on
the laptop, except faster and with more RAM.

I happened to be watching 'top' while building nss-3.62 with -j4 and
noticed that Xorg was using around 115% CPU.  Later I thought that
maybe this was overhead from xfce4-terminal which I was running with
 2>&1 | tee mylog
(I know xfce4-terminal is slow when starting, typing lags for a few
seconds, and I assumed that the scrolling display might be
involved.)

But I've just started xfce on my 4-core (no SMT) zen1 and again it
is using around 115% CPU.

Colour me "disappointed".

ĸen
-- 
 When someone told me I lived in a
 fantasy land I nearly fell off my unicorn.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Promote JS78.8.0 for 10.1 ?

[Ken Moffat via lfs-dev]

On Thu, Feb 25, 2021 at 02:55:50PM -0600, Douglas R. Reno via lfs-dev wrote:
> 
> On 2/24/21 12:13 PM, Ken Moffat via lfs-dev wrote:
> > On Wed, Feb 24, 2021 at 03:48:05AM +, Ken Moffat via lfs-dev wrote:
> > > On Wed, Feb 24, 2021 at 04:31:12AM +0100, Pierre Labastie via lfs-dev 
> > > wrote:
> > > > On Wed, 2021-02-24 at 02:02 +, Ken Moffat via lfs-dev wrote:
> > > > > I see that people have been busy tagging things whilst I've been
> > > > > offline.  One of those things is JS-78.8.0.
> > > > > 
> > > > > Technically, the JS build does not appear to contain any security
> > > > > fixes, just one or two lines of python got changed.  But
> > > > > firefox-78.8.0 does contain the usual crop of fixes rated as 'high'.
> > > > > 
> > > > > Firefox has not yet been tagged, so no problem.
> > > > > 
> > > > > I'd like to promote JS-78.8.0 for 10.1 so that we continue to use
> > > > > the same version of the tarball.  Although I have not yet built this
> > > > > version of firefox on 10.1, I have built and measured on a system
> > > > > from 6th February with various later updates, and I've now got JS
> > > > > 78.8.0 running on two machines which have not yet got as far as
> > > > > firefox.
> > > > FWIIW, js78 is a dependency of:
> > > > - polkit: tagged
> > > > - gjs: not tagged yet
> > > > 
> > > > According to Xi Ruoyao, nothing dependent on polkit uses js. I'd say we
> > > > need to test gjs (not tagged yet), and its dependencies (g-ir
> > > > (optional), gnome-shell, libsecret (optional), gnome-maps, and gnome-
> > > > weather)
> > > > 
> > > > Pierre
> > > > 
> > > I've built polkit as part of my normal builds, as well as
> > > gobject-introspection.  I normally build very little of gnome.
> > > 
> > Question: were those tested before JS78.7.1 was tagged ?
> > 
> > I see that Doug has been given the ticket for JS, I'll temporarily
> > separate the entities to keep JS at 78.7.1.
> > 
> > ĸen
> 
> Hi folks,
> 
> I've tested js78 with the following results:
> 
> [ js-78.8.0:
>     - gobject-introspection: GOOD
>     - gjs: GOOD
>     - libsecret: GOOD
>     - gnome-shell: GOOD
>     - gnome-maps: GOOD
>     - gnome-weather: GOOD
>     - polkit: GOOD (PASS: polkitbackendjsauthoritytest-wrapper.py)
> ]
> 
> 
> Everything looks good over here in that regard, so I'm going to proceed with
> backporting.
> 
> Here's my intentions for the rest of the day (and tomorrow):
> 
> - Tag x7driver-nouveau, x7driver-ati, x7-driver-synaptics, dovecot, lxdm
> 
> - Backport Node.JS and Nano to 10.1, and rebuild
> Firefox+Seamonkey+Thunderbird to verify no breakage.
> 
> 
> Please do not tag LXDM, it has been tested on systemd in several years now
> and I'd like to make sure that it functions properly.
> 
> ATI / Synaptics won't happen until tomorrow at the earliest, latest on
> Saturday. Nouveau might happen tonight, it depends on whether I want to go
> under my desk and chuck an NVIDIA card into my dev system tonight or not :-)
> 
> 
> - Doug
> 
I had held off tagging r600 in the belief it was maybe related to
the gnome/sysv ticket you've now pushed to 10.2.  But it's working
fine on my box which has an r600.  Could tag it if you want, and
maybe give you more time to look at lxdm on systemd if that still
concerns you ?

ĸen
-- 
 When someone told me I lived in a
 fantasy land I nearly fell off my unicorn.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Promote JS78.8.0 for 10.1 ?

[Ken Moffat via lfs-dev]

On Wed, Feb 24, 2021 at 03:48:05AM +, Ken Moffat via lfs-dev wrote:
> On Wed, Feb 24, 2021 at 04:31:12AM +0100, Pierre Labastie via lfs-dev wrote:
> > On Wed, 2021-02-24 at 02:02 +0000, Ken Moffat via lfs-dev wrote:
> > > I see that people have been busy tagging things whilst I've been
> > > offline.  One of those things is JS-78.8.0.
> > > 
> > > Technically, the JS build does not appear to contain any security
> > > fixes, just one or two lines of python got changed.  But
> > > firefox-78.8.0 does contain the usual crop of fixes rated as 'high'.
> > > 
> > > Firefox has not yet been tagged, so no problem.
> > > 
> > > I'd like to promote JS-78.8.0 for 10.1 so that we continue to use
> > > the same version of the tarball.  Although I have not yet built this
> > > version of firefox on 10.1, I have built and measured on a system
> > > from 6th February with various later updates, and I've now got JS
> > > 78.8.0 running on two machines which have not yet got as far as
> > > firefox.
> > 
> > FWIIW, js78 is a dependency of:
> > - polkit: tagged
> > - gjs: not tagged yet
> > 
> > According to Xi Ruoyao, nothing dependent on polkit uses js. I'd say we
> > need to test gjs (not tagged yet), and its dependencies (g-ir
> > (optional), gnome-shell, libsecret (optional), gnome-maps, and gnome-
> > weather)
> > 
> > Pierre
> > 
> 
> I've built polkit as part of my normal builds, as well as
> gobject-introspection.  I normally build very little of gnome.
> 

Question: were those tested before JS78.7.1 was tagged ?

I see that Doug has been given the ticket for JS, I'll temporarily
separate the entities to keep JS at 78.7.1.

ĸen
-- 
 When someone told me I lived in a
 fantasy land I nearly fell off my unicorn.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Promote JS78.8.0 for 10.1 ?

[Ken Moffat via lfs-dev]

On Wed, Feb 24, 2021 at 04:31:12AM +0100, Pierre Labastie via lfs-dev wrote:
> On Wed, 2021-02-24 at 02:02 +0000, Ken Moffat via lfs-dev wrote:
> > I see that people have been busy tagging things whilst I've been
> > offline.  One of those things is JS-78.8.0.
> > 
> > Technically, the JS build does not appear to contain any security
> > fixes, just one or two lines of python got changed.  But
> > firefox-78.8.0 does contain the usual crop of fixes rated as 'high'.
> > 
> > Firefox has not yet been tagged, so no problem.
> > 
> > I'd like to promote JS-78.8.0 for 10.1 so that we continue to use
> > the same version of the tarball.  Although I have not yet built this
> > version of firefox on 10.1, I have built and measured on a system
> > from 6th February with various later updates, and I've now got JS
> > 78.8.0 running on two machines which have not yet got as far as
> > firefox.
> 
> FWIIW, js78 is a dependency of:
> - polkit: tagged
> - gjs: not tagged yet
> 
> According to Xi Ruoyao, nothing dependent on polkit uses js. I'd say we
> need to test gjs (not tagged yet), and its dependencies (g-ir
> (optional), gnome-shell, libsecret (optional), gnome-maps, and gnome-
> weather)
> 
> Pierre
> 

I've built polkit as part of my normal builds, as well as
gobject-introspection.  I normally build very little of gnome.

ĸen
-- 
 When someone told me I lived in a
 fantasy land I nearly fell off my unicorn.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Promote JS78.8.0 for 10.1 ?

[Ken Moffat via lfs-dev]

I see that people have been busy tagging things whilst I've been
offline.  One of those things is JS-78.8.0.

Technically, the JS build does not appear to contain any security
fixes, just one or two lines of python got changed.  But
firefox-78.8.0 does contain the usual crop of fixes rated as 'high'.

Firefox has not yet been tagged, so no problem.

I'd like to promote JS-78.8.0 for 10.1 so that we continue to use
the same version of the tarball.  Although I have not yet built this
version of firefox on 10.1, I have built and measured on a system
from 6th February with various later updates, and I've now got JS
78.8.0 running on two machines which have not yet got as far as
firefox.

ĸen
-- 
 When someone told me I lived in a
 fantasy land I nearly fell off my unicorn.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Regression in top ?

[Ken Moffat via lfs-dev]

On Tue, Feb 23, 2021 at 02:30:38AM +, Ken Moffat wrote:
> Finally got a 10.1-rc1+ system booted.  But lookign at 'top' on this
> 8-thread machine it only shows the even-numbered cores (Cpu0 .. 2 ..
> 4 .. 6).  This is plain wierd, is it a regression in
> procps-ng-3.3.17 ?
> 
> I so, I guess I'll have to revert to 3.3.16.
> 
> ĸen

Scratch that.  I had not realised that the odd-numbered CPUs were
shown on the right on the screen.  Will be interesting to see how
well that works on a narrow screen (at the moment I have 160 columns
in a tty), but it saves rows so I guess all is good and that it will
help if ever I get a decent number of cores.

ĸen
-- 
 When someone told me I lived in a
 fantasy land I nearly fell off my unicorn.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Regression in top ?

[Ken Moffat via lfs-dev]

Finally got a 10.1-rc1+ system booted.  But lookign at 'top' on this
8-thread machine it only shows the even-numbered cores (Cpu0 .. 2 ..
4 .. 6).  This is plain wierd, is it a regression in
procps-ng-3.3.17 ?

I so, I guess I'll have to revert to 3.3.16.

ĸen
-- 
 When someone told me I lived in a
 fantasy land I nearly fell off my unicorn.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Lots of segfaults in libc-2.33.so.orig

[Ken Moffat via lfs-dev]

I built current -dev a couple of days ago, and it seems to be
running ok, so I gave linux-5.10.17-rc1 a try (this is a desktop
with the orc unwinder, I initially built it with patched 5.10.13
adding the fix Pierre identified).

Now that 5.10.17-rc1 is running, I took a look at dmesg and was
shocked to see that unbound had segfaulted.  Started it again,
segfaulted again.  I'm only running unbound as belt and braces
(picked that up from a FreeBSD list some time ago).

Looking back at the syslog, there have been quite a lot of segfaults
in 5.10.13:  Some of these are probably from gcc (various exe files
such as pr59667.exe and probably nothing to worry about).  But I've
also got a couple of segfaults from urxvt and gdbus, although I
didn't notice any problems related to those.  But unbound segfaulted
every time it was started.

What seems, to me, to be odd about these segfaults is that they
all reference the unstripped version of glibc, e.g.

Feb 16 01:56:58 origin klogd: [  515.115052] unbound[1890]: segfault at 100 ip 
7f3fc9406b83 sp 7fffc68510d0 error 4 in 
libc-2.33.so.orig[7f3fc935+16f000]

I had thought that the segfault would reference libc-2.33.so ?
Or should I expect it to fault in the .orig version ?  Maybe that is
something *I'm* doing wrong, -ENO_IDEA.

ken@origin ~ $ls -l /lib/libc-2.33*
-rwxr-xr-x 1 root root 1995192 Feb 12 00:12 /lib/libc-2.33.so
-rwxr-xr-x 1 root root  406584 Feb 12 00:12 /lib/libc-2.33.so.dbg
-rwxr-xr-x 1 root root 2394200 Feb 12 00:12 /lib/libc-2.33.so.orig

Hmm, at least for unbound Arch and gentoo are ahead of me (I do like
it when someone else hits and explains the problem first, but I'm
not entirely sure if this is the same problem as I'm seeing).

https://github.com/NLnetLabs/unbound/issues/418

https://sourceware.org/bugzilla/show_bug.cgi?id=27343

and suggested fix:

https://sourceware.org/pipermail/libc-alpha/2021-February/122364.html

which has apparently been committed as:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=c3479fb7939898ec22c655c383454d6e8b982a67

ĸen
-- 
Any attempt to brew coffee with a teapot should result in the error
code "418 I'm a teapot". The resulting entity body MAY be short and
stout. -- rfc 2324 (1st April 1998)

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Security Advisories

[Ken Moffat via lfs-dev]

The new pages of Security Advisories are now live.

To see the LFS advisories, go to
http://www.linuxfromscratch.org/lfs/read.html and follow the links
in the Current Stable paragraphs (svn, systemd).

For editors, the advisories are common to svn and systemd and are in
the www repo, at lfs/advisories. The consolidated listing is shared
by both LFS and BLFS and is blfs/advisories/consolidated.html.

ĸen
-- 
Any attempt to brew coffee with a teapot should result in the error
code "418 I'm a teapot". The resulting entity body MAY be short and
stout. -- rfc 2324 (1st April 1998)

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Possible binutils-2.36 problems

[Ken Moffat via lfs-dev]

On Fri, Feb 05, 2021 at 10:39:08AM -0600, Bruce Dubbs via lfs-dev wrote:
> On 2/5/21 6:48 AM, Ken Moffat via lfs-dev wrote:
> > While replying to Frans on -support re his inability to build
> > glibc-2.33, I glanced at the binutils bugs
> > https://www.mail-archive.com/bug-binutils@gnu.org/ and said that
> > 2.36 might be buggy.  At that time I hadn't read all the links
> > gurgle found for me.  One of them is
> > https://www.linuxquestions.org/questions/linux-from-scratch-13/binutils-2-36-strip-4175689760/
> > which looks *really* annoying.
> 
> I took a look at the above link, but I cannot reproduce the problem with LFS
> instructions.  In my test build in /mnt/lfs/lib I have:
> 
> 
> [ /mnt/lfs/lib ]$ ll libc*
> lrwxrwxrwx 1 root root   14 Feb  2 16:20 libcap.so.2 -> libcap.so.2.47
> -rwxr-xr-x 1 root root39440 Feb  2 17:44 libcap.so.2.47
> lrwxrwxrwx 1 root root   17 Feb  2 17:44 libcom_err.so.2 ->
> libcom_err.so.2.1
> -rwxr-xr-x 1 root root18776 Feb  2 17:44 libcom_err.so.2.1
> -rwxr-xr-x 1 root root43288 Feb  2 17:44 libcrypt-2.33.so
> lrwxrwxrwx 1 root root   16 Feb  2 16:10 libcrypt.so.1 ->
> libcrypt-2.33.so
> -rwxr-xr-x 1 root root  1835448 Feb  2 17:44 libc-2.33.so
> -rwxrwxr-x 1 root root 11946280 Feb  2 17:44 libc-2.33.so.dbg
> lrwxrwxrwx 1 root root   12 Feb  2 16:10 libc.so.6 -> libc-2.33.so
> 
> [ /mnt/lfs/lib ]$ file libc-2.33.so
> libc-2.33.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux),
> dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux
> 3.2.0, stripped
> 
> [ /mnt/lfs/lib ]$ file libcap.so.2.47
> libcap.so.2.47: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
> dynamically linked, stripped
> 
> So the book does what we want.  On the other hand, we do not do an
> unconditional strip on anything.  We start with find /lib /usr/lib -type f
> -name \*.so* ...  so that would skip symlinks.
> 
> We use the same structure in BLFS Section "Notes on Building Software".
> 
> On the other hand, doing an explicit strip on a symlink does replace the
> symlink with the stripped version of the link's resolved file.
> 
> I can confirm that running strip against a symlink on a system with
> binutils-2,25 does not affect the symlink.
> 
>   -- Bruce
> 
Hi Bruce,

thanks for looking at this. At the moment I don't have 2.36, I'm
just warning that some people are reporting enough
changed/unexpected behaviour that this might cause problems.

good to know that we are not directly affected by the stripping
change.

ĸen
-- 
Any attempt to brew coffee with a teapot should result in the error
code "418 I'm a teapot". The resulting entity body MAY be short and
stout. -- rfc 2324 (1st April 1998)

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Possible binutils-2.36 problems

[Ken Moffat via lfs-dev]

While replying to Frans on -support re his inability to build
glibc-2.33, I glanced at the binutils bugs
https://www.mail-archive.com/bug-binutils@gnu.org/ and said that
2.36 might be buggy.  At that time I hadn't read all the links
gurgle found for me.  One of them is
https://www.linuxquestions.org/questions/linux-from-scratch-13/binutils-2-36-strip-4175689760/
which looks *really* annoying.

ĸen
-- 
Any attempt to brew coffee with a teapot should result in the error
code "418 I'm a teapot". The resulting entity body MAY be short and
stout. -- rfc 2324 (1st April 1998)

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] sudo : CVE CVE-2021-3156

[Ken Moffat via lfs-dev]

On Wed, Feb 03, 2021 at 10:13:26AM -0800, Tree Davies via lfs-dev wrote:
> Hi Everyone,
> 
> Just wanted to mention according to the article BLFS is using a vulnerable
> version of Sudo (1.9.2).
> Although I haven't been able to repro it... Has anyone else been successful?
> 
> Cheers,
> Tree
> 
Hi Tree,

I'll mention in passing that blfs-dev is arguably a better place to
have asked this, although in practice I think we're all here and
could get by with just one -dev list for the two books. Anyway ...

> https://frontpagelinux.com/news/sudo-vulnerability-discovered-how-to-protect-your-system-from-baron-samedit/
> 
> http://www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/sudo.html
> 

That blfs link points to stable-systemd, i.e. 10.0 which was
released on 1st September. Once a book is released, it is set in
stone. Everything from then until the next release happens in the
development books. For systemd see
 http://www.linuxfromscratch.org/blfs/view/systemd/postlfs/sudo.html
which was updated to 1.9.5p2 on 26th January.

At the moment, security vulnerabilities for BLFS (but not for LFS)
are mentioned in the Errata (for 10.0) - follow the Errata links at
http://www.linuxfromscratch.org/blfs/read.html for BLFS Errata and
BLFS Systemd Errata.

I am hoping to separate the vulnerabilities into new Security
Advisory pages for both LFS and BLFS before we release 10.1. That is
currently work in progress (I'm nearly up to the end of November in
my local copy) - I've mentioned it on blfs-dev recently, some things
have changed a little since then.  I'll mention it more widely in a
day or two, and since I have not yet got as far as any updates for
sudo I won't provide the link here :)

ĸen
-- 
Any attempt to brew coffee with a teapot should result in the error
code "418 I'm a teapot". The resulting entity body MAY be short and
stout. -- rfc 2324 (1st April 1998)

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] cbindgen-0.16.0 and mozilla

[Ken Moffat via lfs-dev]

On Sun, Dec 27, 2020 at 07:18:33PM +, Ken Moffat via lfs-dev wrote:
> On Sun, Dec 27, 2020 at 07:28:33PM +0100, gabriele balducci via lfs-dev wrote:
> > hi
> > 
> > > I'm running into a problem with cbindgen-0.16.0 first identified by 
> > > renodr. Both Thunderbird and Firefox fail in the same way.
> > 
> > if this can be of interest to you: at least for FF, the working version
> > of cbindgen can be found in one or the other of these two files:
> > 
> > taskcluster/scripts/misc/build-cbindgen.sh
> > build/moz.configure/bindgen.configure
> > 
> > cheers
> > -g
> 
> From memory, the bindgen.configure specified the *minimum* version
> required (it's one of the places I look to see changed deps for new
> non-esr versions).  My impression of taskcluster is that it's part
> of mozilla's infrastructure for its build machines.
> 
> In any case, all configure-style tests for versions can only know
> about what was available at the time.  This sounds like a new
> cbindgen issue and I'll guess it should be reported to cbindgen's
> upstream.
> 
> Glad someone tested it ;-)
> 

So far, only Arch are using cbindgen-0.16.0.  They use it for
thunderbird 78.6.0 with rust-1.48.0 (and a patch to allwo that).

Fedora are also using rust-1.48.0, but in thunderbird-78.6.0 they
put cbindgen-vendor-0.14.3.tar.xz into the source and then build
with the bundled cbindgen, see
https://src.fedoraproject.org/rpms/thunderbird/blob/master/f/thunderbird.spec

Specifically, at line 377 (blank lines removed)

%if 0%{?use_bundled_cbindgen}
mkdir -p my_rust_vendor
cd my_rust_vendor
%{__tar} xf %{SOURCE4}
cd -
mkdir -p .cargo
cat > .cargo/config <http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] cbindgen-0.16.0 and mozilla

[Ken Moffat via lfs-dev]

On Sun, Dec 27, 2020 at 07:28:33PM +0100, gabriele balducci via lfs-dev wrote:
> hi
> 
> > I'm running into a problem with cbindgen-0.16.0 first identified by 
> > renodr. Both Thunderbird and Firefox fail in the same way.
> 
> if this can be of interest to you: at least for FF, the working version
> of cbindgen can be found in one or the other of these two files:
> 
> taskcluster/scripts/misc/build-cbindgen.sh
> build/moz.configure/bindgen.configure
> 
> cheers
> -g

From memory, the bindgen.configure specified the *minimum* version
required (it's one of the places I look to see changed deps for new
non-esr versions).  My impression of taskcluster is that it's part
of mozilla's infrastructure for its build machines.

In any case, all configure-style tests for versions can only know
about what was available at the time.  This sounds like a new
cbindgen issue and I'll guess it should be reported to cbindgen's
upstream.

Glad someone tested it ;-)

ĸen
-- 
(The Balancing Monks) use small brass weights, none of them bigger
than a fist. They work. Well, obviously they work. The world has not
tipped up yet. -- The Thief Of Time
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Odd new gdbmtool test failure.

[Ken Moffat via lfs-dev]

I'm currently building svn-20201223 sysv, the only 'variance' is
that the host is running a 5.10.1 kernel and in this build I'm using
5.10.2 headers.  I very much doubt that those are relevant.

We have not changed either gdbm or expect for a very long time, and
my last build (r12061 with a 5.9.8 kernel) passed the gdbm tests
when I ran them - that was on a different machine.

AFAICS the gdbm tests have not failed (on the builds where I ran
them) in the last 6 years, but today although all 30 of the main
tests still passed, one of the gdbmtool tests failed:

From gdbm-1.18.1/tests/gdbmtool.log -

Test run by root on Sat Dec 26 18:45:51 2020
Native configuration is x86_64-unknown-linux-gnu

=== gdbmtool tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/default.exp as tool-and-target-specific interface file.
Running ./gdbmtool/base.exp ...
spawn /building/gdbm-1.18.1/src/gdbmtool -q^M
^[[?2004hgdbmtool> status^M
^[[?2004l^MNo database name^M
Database is not open^M
define key string^M
define content string^M
^[[?2004hgdbmtool> PASS: status
version^M
^[[?2004l^MGDBM version 1.18.1. 27/10/2018 (built Dec 26 2020 18:45:49)^M
^[[?2004hgdbmtool> FAIL: version
quit^M
^[[?2004l^Mtestcase ./gdbmtool/base.exp completed in 10 seconds

=== gdbmtool Summary ===

# of expected passes1
# of unexpected failures1
runtest completed at Sat Dec 26 18:46:01 2020

 - - -

The last unexpected new test failure I had seems to have been a race
(I forget which package, but it failed twice, then I added '|| true'
and it passed) so since this is also a -j8 build (not sure if the
tests use all cores, some CMMI packages now seem to pick that up
from the build) I retried with the same error, then added '|| true'
to allow it to not stop my build.  This time all those builds
reported that failure so it doesn't look like a race.

Odd, because I cannot see any change which is liekly to have
triggered this.

ĸen
-- 
(The Balancing Monks) use small brass weights, none of them bigger
than a fist. They work. Well, obviously they work. The world has not
tipped up yet. -- The Thief Of Time
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Test failure in procps-ng

[Ken Moffat via lfs-dev]

Building current svn, I've now had a test failure in procps-ng:

Running ./pmap.test/pmap.exp ...
FAIL: pmap X with unreachable process

This initially surprised me because neither the package version nor
my script have changed recently.

I was half awake - first, I didn't realise it had run the tests,
only looked at the main log, saw nothing.  Retried, realised the
tests had failed (presumably the same failure both times).

Bruce commented on a similar issue in 2013 :
http://lists.linuxfromscratch.org/pipermail/lfs-dev/2013-April/067952.html

| That means that it can't find /proc/1.  If /proc is mounted, that
| should always be there, e.g. `cat /proc/1/cmdline`.

Attempted to cat /proc/1/cmdline in my script, but typo'd (missed
the '1/') and this time the tests all passed.

Will be interesting to see if this error recurs.

ĸen
-- 
Internal error in fortune program:
fnum=2987  n=45  flag=1  goose_level=-232323
Please write down these values and notify fortune program admin.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] eudev pkgconfig file

[Ken Moffat via lfs-dev]

On Mon, Nov 16, 2020 at 04:43:14PM +, Roger via lfs-dev wrote:
> eudev puts udev.pc in /usr/share/pkgconfig; all other packages
> use /usr/lib/pkgconfig.
> 

On a completed BLFS desktop system, you can have a lot more in
/usr/share/pkgconfig.  The are supposed to be
architecture-independent files, whereas those pkgconfig files in a
lib* directory are for a specific architecture (e.g. multilib might
use lib for 32-bit, lib64 for 64-bit).

> To put udev.pc in /usr/lib/pkgconfig change eudev's "make
> install" command to
> 
> make sharepkgconfigdir=/usr/lib/pkgconfig install
> 
> HTH

Probably does no harm on a non-multilib system, but not recommended.

ĸen
-- 
Internal error in fortune program:
fnum=2987  n=45  flag=1  goose_level=-232323
Please write down these values and notify fortune program admin.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Problems with scour

[Ken Moffat via lfs-dev]

On Thu, Oct 22, 2020 at 09:01:16PM +0100, Ken Moffat via lfs-dev wrote:
> Why are python packages so painful ?
> 
Sorry, wrong list.  I've forwarded it to blfs-dev.

-- 
The people next door oppress me all night long. I tell them: I work
all day, a man's got to have some time to learn to play the tuba.
That's oppression, that is.[ Guards! Guards! ]
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Problems with scour

[Ken Moffat via lfs-dev]

Why are python packages so painful ?

With scour-0.38.1, when I download it using firefox I get
scour-038.1.tar.gz instead of -0.38.1.  If I use wget it correctly
provides -0.38.1.  That is the reverse of the more common behaviour.

More annoyingly, since May I've only been building scour for python3
And I was still running testcss.py (and testscour.py) using python3
the last time I built it (for BLFS-10.0, using 0.37).

Now, that craps out - the files have been renamed to test_css.py
to test_scour.py.

I could change that, but I'm unclear why we still even mention
python2 for scour ?  AFAICS, only inkscape uses it, for Save As
optimized svg.

I've just gone back to 10.0 on another box and done some doodling in
inkscape-1.0, followed by saving as optimized svg (I note that when
I closed inkscape after that it mentioned that optimized svg could
involve data loss and offered to save as inkscape svg).

While I was doing that, current inkscape completed so I ran similar
tests on 1.0.1, with similar results.

But maybe I'm overlooking a reason why building with python2 would
be useful to someone ?

ĸen
-- 
The people next door oppress me all night long. I tell them: I work
all day, a man's got to have some time to learn to play the tuba.
That's oppression, that is.[ Guards! Guards! ]
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] LFS source md5sums

[Ken Moffat via lfs-dev]

On Mon, Sep 28, 2020 at 10:40:06AM -0500, Bruce Dubbs via lfs-dev wrote:
> On 9/28/20 10:13 AM, John Burrell via lfs-dev wrote:
> > I downloaded the SYSTEMD book and got the wget-list and md5sums files with:
> > 
> > make -j1 -f ${REPODIR}/Makefile -C $REPODIR BASEDIR=$SourceDir
> > ${SourceDir}/wget-list ${SourceDir}/md5sums
> > 
> > which produces the correct wget-list file but the md5sums file is for
> > the 'sysv" version of the book. e.g. no dbus and systemd files, viz:
> > 
> > fcafcecde5a380415b12e9c574e0b2  check-0.15.2.tar.gz
> > 022042695b7d5bcf1a93559a9735e668  coreutils-8.32.tar.xz
> > e1b07516533f351b3aba3423fafeffd6  dejagnu-1.6.2.tar.gz
> > 4824adc0e95dbbf11dfbdfaad6a1e461  diffutils-3.7.tar.xz
> > 
> > 6d906edfdb3202304059233f51f9a71d  sed-4.8.tar.xz
> > 4b05eff8a427cf50e615bda324b5bc45  shadow-4.8.1.tar.xz
> > c70599ab0d037fde724f7210c2c8d7f8  sysklogd-1.5.1.tar.gz
> > e11bc4b3eac6e6ddee7f8306230749a9  sysvinit-2.97.tar.xz
> > 
> > So is there a problem with my make command or a problem with the Makefile?
> 
> What does your package,ent file show.  It should be:
> 
> 
> 
>  "/libcheck/check/releases/download//check-.tar.gz">
> 
> https://libcheck.github.io/check;>
> 
> 
> 
> Somehow you are missing the leading 50 for check.
> 

(I think that was just a paste issue)

> To make the systemd book, use 'make REV=systemd'
> 
>   -- Bruce

Although the Makefile says it is producing consolidated wget-list
and md5sums (in ~/lfs-systemd for systemd, or ~/lfs-book for
sysvinit, controlled by REV as Bruce said), the md5sums are in fact
specific to the variant of the book.

ĸen
-- 
A really good hydrophobe has to be trained on dehydrated water from
birth.  I mean, that costs a fortune in magic alone.  But they make
great weather magicians.  Rain clouds just give up and go away.
-- The Colour of Magic
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Refcount bug in 5.7 and 5.8 kernels

[Ken Moffat via lfs-dev]

Pasting from oss-security, where Andy Lutomirski said that a CVE has
been requested.  Fixed in 5.8.7 (presumably also fixed in latest
5.7, but why would you be running that ?)

| Linux 5.7 and 5.8 have a bug in the reference counting of the struct
| page that backs the vsyscall page.  The result is a refcount
| underflow.  This can be triggered by any 64-bit process that is
| permitted to use ptrace() or process_vm_readv().  A creative attacker
| can probably achieve kernel code escalation by using this bug.
| 
| You can prevent the issue from triggering by booting with
| vsyscall=xonly or vsyscall=none.  You can also effectively hotpatch a
| kernel with suitable hardening options by running the updated test
| case noted below -- the test case will underflow the refcount past
| zero, preventing further use of the page.  (A real attacker would
| carefully underflow it exactly to zero but not past.)  Or you can fix
| your kernel.
| 
| (No one should be using vsyscall=emulate any more unless they have a
| very specific use case that requires it.  vsyscall=xonly is better in
| almost all cases.  For some reason, Fedora still seems to be using
| emulate mode, though.)
| 
| Fixed by:
| 
| commit 9fa2dd946743ae6f30dc4830da19147bf100a7f2
| Author: Dave Hansen 
| Date:   Thu Sep 3 13:40:28 2020 -0700
| 
| mm: fix pin vs. gup mismatch with gate pages

ĸen
-- 
I could not live without Champagne.  In victory I deserve it, in
defeat I need it.  -- Churchill
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Comments on the expected test results in the book

[Ken Moffat via lfs-dev]

I've now run the full set of tests on three different builds of
10.1-rc1, and I'm almost in agreement about the expected results.

Two builds were on ryzen.  Those used -O3 throughout, even in gcc
where I had stopped doing that because of failures I described as in
the torture tests.  Reinstated because on a semi-decent development
machine I want to build more quickly.  The other build was one my i3
skylake using -O2 - it's not a main development machine.

The following packages still cause me to query what the book says:

tcl: I still think that the line
 Files with failing tests: http.test httpold.test
should be mentioned in addition to the clock test (which exits with
errors).

gcc: I get two additional failures in libstdc++ on all three
machines,

FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
FAIL: 22_locale/numpunct/members/char/3.cc execution test

Totals for unexpected failures in my builds:
 -O2   -O3
 g++  1717 and 18
 gcc   721
 libstdc++ 8 8

So, using -O3 still breaks some more gcc torture tests (but the
build seems to work well).  But I think those two extra libstdc++
failures ought to be mentoned.

Python: for me, test_normalization passed on each build.  Not sure
if it still fails for you guys ?

coreutils: We say test-getlogin is known to fail, but in each of my
builds I have:
SKIP: test-getlogin

util-linux: we pass -k to make check without specifying any details.
For me, column/invalid multibyte failed on each of my builds.

Apart from these minor details of what to expect, this is now all
looking really good.  I'll also mention that for inetutils, where
libls _may_ fail, it failed on the O2 build and one of the O3
builds, but not on the other O3 build.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Perl privlib is putting core modules in /usr/share

[Ken Moffat via lfs-dev]

On Thu, Aug 13, 2020 at 11:40:34PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 8/13/20 11:32 PM, Kevin Buckley wrote:
> > On Fri, 14 Aug 2020 at 11:48, Bruce Dubbs via lfs-dev
> >  wrote:
> > > > 
> > > > I might have missed this in the email thread but why does the change,
> > > > which I've seen at r12020, hard-code the version number and not use
> > > > the entity  ?
> > > > 
> > > > ...
> > .34 later versions?
> > > 
> > > Probably an oversight.  I'll fix it, but when I make the change for -rc1
> > > on Saturday.
> > > 
> > 
> > One other thing I think I've spotted at, r12020, as regards that Perl fix 
> > then:
> > 
> > :BOOK$ grep -A8 Dprefix= chapter07/perl.xml
> >   -Dprefix=/usr   \
> >   -Dvendorprefix=/usr \
> >   -Dprivlib=/usr/lib/perl5/5.32/core_perl \
> >   -Darchlib=/usr/lib/perl5/5.32/core_perl \
> >   -Dsitelib=/usr/lib/perl5/5.32/site_perl \
> >   -Dsitearch=/usr/lib/perl5/5.32/site_perl\
> >   -Dvendorlib=/usr/lib/perl5/5.32/vendor_perl \
> >   
> > -Dvendorarch=/usr/lib/perl5/5.32/vendor_perl
> > 
> > :BOOK$ grep -A8 Dprefix= chapter08/perl.xml
> >   -Dprefix=/usr\
> >   -Dvendorprefix=/usr  \
> >   -Dprivlib=/usr/lib/perl5/5.32/core_perl  \
> >   -Darchlib=/usr/lib/perl5/5.32/core_perl  \
> >   -Dsitelib=/usr/lib/perl5/5.32/site_perl  \
> >   -Dsitearch=/usr/lib/perl5/5.32/site_perl \
> >   -Dvendorlib=/usr/share/perl5/vendor_perl \
> >   -Dvendorarch=/usr/lib/perl5/5.32/vendor_perl \
> >   -Dman1dir=/usr/share/man/man1\
> > 
> > where the vendorlib define is different between the two chapters ?
> 
> Yes, I'll address that too.
> 
>   -- Bruce
> 
Thanks.  And particular thanks to Kevin for noticig it.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] libcap-2.42 No rule to make target 'install-static'

[Ken Moffat via lfs-dev]

On Tue, Aug 11, 2020 at 06:20:16AM +0200, Pierre Labastie via lfs-dev wrote:
> On Tue, 2020-08-11 at 05:09 +0100, Ken Moffat via lfs-dev wrote:
> > Trying to build current svn, libcap install failed:
> > 
> > make -C libcap install
> > make[1]: *** No rule to make target 'install-static', needed by
> > 'install'.  Stop.
> > make[1]: *** Waiting for unfinished jobs
> > make[1]: Entering directory '/building/libcap-2.42/libcap'
> > mkdir -p -m 0755 /usr/include/sys
> > install -m 0644 include/sys/capability.h /usr/include/sys
> > install -m 0644 include/sys/psx_syscall.h /usr/include/sys
> > mkdir -p -m 0755 /usr/lib/pkgconfig
> > install -m 0644 libcap.pc /usr/lib/pkgconfig/libcap.pc
> > install -m 0644 libpsx.pc /usr/lib/pkgconfig/libpsx.pc
> > mkdir -p -m 0755 /lib
> > install -m 0644 libpsx.a /lib/libpsx.a
> > make[1]: Leaving directory '/building/libcap-2.42/libcap'
> > make: *** [Makefile:12: install] Error 2
> > 
> > I suspect that the sed to prevent the static lib being installed is
> > inadequate.  In libcap/Makefile at this point:
> > 
> 
> The sed has been slightly changed to prevent this. Have you noticed it?
> It was
> sed -i '/install.*STACAPLIBNAME/d' libcap/Makefile
> It is now
> sed -i '/install -m.*STACAPLIBNAME/d' libcap/Makefile
> 

Thanks, obviously "should have gone to specsavers!" (an optician
franchise in GB, that's their advertising slogan).

I see now that the changed version only deletes one line instead of
two.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] libcap-2.42 No rule to make target 'install-static'

[Ken Moffat via lfs-dev]

Trying to build current svn, libcap install failed:

make -C libcap install
make[1]: *** No rule to make target 'install-static', needed by 'install'.  
Stop.
make[1]: *** Waiting for unfinished jobs
make[1]: Entering directory '/building/libcap-2.42/libcap'
mkdir -p -m 0755 /usr/include/sys
install -m 0644 include/sys/capability.h /usr/include/sys
install -m 0644 include/sys/psx_syscall.h /usr/include/sys
mkdir -p -m 0755 /usr/lib/pkgconfig
install -m 0644 libcap.pc /usr/lib/pkgconfig/libcap.pc
install -m 0644 libpsx.pc /usr/lib/pkgconfig/libpsx.pc
mkdir -p -m 0755 /lib
install -m 0644 libpsx.a /lib/libpsx.a
make[1]: Leaving directory '/building/libcap-2.42/libcap'
make: *** [Makefile:12: install] Error 2

I suspect that the sed to prevent the static lib being installed is
inadequate.  In libcap/Makefile at this point:

install: install-shared install-static

Since I don't understand the details of libcap and I want to leave
the build running I've commented out the sed in my current build.

I will also remark that current 'make' seems to like runing multiple
jobs in the install, I've seen it before - in this case the command
was just
 make lib=lib PKGCONFIGDIR=/usr/lib/pkgconfig install
although I use make -j8 for the actual build.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Need help LFS 7.10 binutils failed in pass 2

[Ken Moffat via lfs-dev]

On Sat, Aug 08, 2020 at 11:06:35AM +0530, Vijayakumar Athithan via lfs-dev 
wrote:
> Dear Ken,
> 
> Thanks for your time and reply.
> 
> I tried this in Ubuntu VM. Please find details below on Ubuntu VM
>  uname -a Linux ubuntu 4.15.0-112-generic #113~16.04.1-Ubuntu SMP Fri Jul
> 10 04:37:08
> 
> UTC 2020 x86_64 x86_64 x86
> 
> Ubuntu GLIBC 2.23-0 and  gcc  5.4.0 20160609
> 
> I would like to create build scripts for a UTM appliance ISO that works in
> Intel x86_64 arch something like pfsense, Smoothwall that includes Squid,
> Firewall, IPS etc  I try to modify Smoothwall scripts that were written
> long back based on LFS way of doing things. I am able to follow many things
> in the process by reading LFS, various posts, and a number of my own
> mistakes in the process.
> 
> As you suggested for the recent version, I will try systemd version of 8.4.
> or 9.1.
> 
> Please advise me if I could try 8.4 first or I can go directly into 9.1 for
> my requirements.
> 
> Thanks,
> B.Vijayakumar Athithan
> 

Please note that I was trying to give you some pointers about what
was wrong, and that I suspect your machine is unusable.  I don't do
consultancy ;-)

Now that you say you are using a VM, perhaps that VM is miscompiled
or mismatched.  I don't have any recent experience of using VMs.

But the thing you have to get past is why the compiled test program
from configure (a.out) segfaults when it is run.

You might get other responses on lfs-support, but building LFS-7.10
or 8.4 are old history to most people.

Also, please do not top-post onf LFS lists.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Need help LFS 7.10 binutils failed in pass 2

[Ken Moffat via lfs-dev]

On Fri, Aug 07, 2020 at 09:39:14PM +0530, Vijayakumar Athithan via lfs-dev 
wrote:
> I have been working on resolving issues in build scripts that were built
> based on LFS a few years
> 

LFS has changed a LOT over the years, and for the next release
(10.0) it will change even more (see current version of the svn
book).  7.10 was a long while ago, I think those of us who were
around at that time have forgotten many of the details.

Some comments in line -

> back. I tried over the last week and tried multiple versions and solutions
> from different sites.
> 
> Learned a lot as I put more effort. I need your help as I couldn't get the
> reason behind the issue.
> 
> Based on LFS, pass 1 completed and dummy.c file execution was a success.
> Then I get the error in
> 
> binutils in pass 2.
> 
> http://www.linuxfromscratch.org/lfs/view/7.10-systemd/chapter05/binutils-pass2.html
> GCC 6.2.0 binutils
> 
> 2.27 glibc 2.24
> 
> train@ubuntu:~$ uname -a Linux ubuntu 4.15.0-112-generic
> #113~16.04.1-Ubuntu SMP Fri Jul 10 04:37:08
> 
> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux train@ubuntu:~$ gcc --version gcc
> (Ubuntu 5.4.0-
> 
> 6ubuntu1~16.04.12) 5.4.0 20160609 train@ubuntu:~$ ldd --version ldd (Ubuntu
> GLIBC 2.23-0ubuntu11.2)
> 
> 2.23
> 

Usually, building such an old version of LFS cannot be recommended
because of the many vulnerabilities which have been fixed in newer
versions.

In particular, trying to build LFS with never versions of binutils,
gcc, or glibc might give problems.  You will usually be able to build
the previous minor version of those packages, but going back any
further is uncertain.

> train@ubuntu:~$ gcc dummy.c train@ubuntu:~$ readelf -l a.out | grep linux
> [Requesting program
> 
> interpreter: /lib64/ld-linux-x86-64.so.2] train@ubuntu:~$
> /tools/bin/x86_64-tc-linux-gnu-gcc dummy.c
> 
> train@ubuntu:~$ readelf -l a.out | grep linux [Requesting program
> interpreter: /tools/lib64/ld-linux-
> 
> x86-64.so.2]
> 
> cd binutils-2.27-compile; CXXFLAGS="-O2 -m64 -fPIC" CFLAGS="-O2 -m64 -fPIC"
> CC=x86_64-tc-linux-gnu-gcc
> 

I've assumed your x86_64-tc-linux=gnu-gcc is your cross-compiler
from pass 1.  The FLAGS look ok (you have omitted -g, like I do, and
forced 64-bit with -m64 and -fPIC).
> AR=x86_64-tc-linux-gnu-ar RANLIB=x86_64-tc-linux-gnu-ranlib
> ../binutils-2.27/configure --prefix=/tools
> 
>  *** Contents from config log **
> configure:2297: checking build system type
> configure:2311: result: x86_64-pc-linux-gnu
> configure:2358: checking host system type
> configure:2371: result: x86_64-pc-linux-gnu
> configure:2391: checking target system type
> configure:2404: result: x86_64-pc-linux-gnu
> configure:2458: checking for a BSD-compatible install
> configure:2526: result: /usr/bin//install -c
> configure:2537: checking whether ln works
> configure:2559: result: yes
> configure:2563: checking whether ln -s works
> configure:2567: result: yes
> configure:2574: checking for a sed that does not truncate output
> configure:2638: result: /bin/sed
> configure:2647: checking for gawk
> configure:2663: found /usr/bin//gawk
> configure:2674: result: gawk
> configure:4121: checking for gcc
> configure:4148: result: x86_64-tc-linux-gnu-gcc
> configure:4377: checking for C compiler version
> configure:4386: x86_64-tc-linux-gnu-gcc --version >&5
> x86_64-tc-linux-gnu-gcc (GCC) 6.2.0
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> configure:4397: $? = 0
> configure:4386: x86_64-tc-linux-gnu-gcc -v >&5
> Using built-in specs.
> COLLECT_GCC=x86_64-tc-linux-gnu-gcc
> COLLECT_LTO_WRAPPER=/home/train/swe/distrib/tools/bin/../libexec/gcc/x86_64-tc-linux-gnu/6.2.0/lto-
> 
> wrapper
> Target: x86_64-tc-linux-gnu
> Configured with: ../gcc-6.2.0/configure --prefix=/tools
> --target=x86_64-tc-linux-gnu --prefix=/tools
> 
> --with-sysroot=/home/train/swe/distrib --with-newlib --without-headers
> --with-local-prefix=/tools --
> 
> with-native-system-header-dir=/tools/include --disable-nls --disable-shared
> --disable-multilib --
> 
> disable-decimal-float --disable-threads --disable-libmudflap
> --disable-libssp --disable-libatomic --
> 
> disable-libstdcxx --disable-libmpx --disable-libgomp --disable-libvtv
> --disable-libquadmath --enable-
> 
> languages=c,c++
> Thread model: single
> gcc version 6.2.0 (GCC)
> configure:4397: $? = 0
> configure:4386: x86_64-tc-linux-gnu-gcc -V >&5
> x86_64-tc-linux-gnu-gcc: error: unrecognized command line option '-V'
> x86_64-tc-linux-gnu-gcc: fatal error: no input files
> compilation terminated.
> configure:4397: $? = 1
> configure:4386: x86_64-tc-linux-gnu-gcc -qversion >&5
> x86_64-tc-linux-gnu-gcc: error: unrecognized command line option
> '-qversion'; did you mean '--
> 
> version'?
> x86_64-tc-linux-gnu-gcc: fatal error: no input files
> compilation terminated.
> configure:4397: $? = 1
> 

Re: [lfs-dev] Perl privlib is putting core modules in /usr/share

[Ken Moffat via lfs-dev]

On Thu, Aug 06, 2020 at 04:22:33AM +0100, Ken Moffat via lfs-dev wrote:
> On Thu, Aug 06, 2020 at 10:31:52AM +0800, Xi Ruoyao via lfs-dev wrote:
> > On 2020-08-05 22:03 +0100, Ken Moffat via lfs-dev wrote:
> > > On Thu, Aug 06, 2020 at 03:57:29AM +0800, Xi Ruoyao via lfs-dev wrote:
> > > > On 2020-08-05 19:53 +0100, Ken Moffat via lfs-dev wrote:
> > 
> > I prefer to put everything into /usr/lib/perl5, instead of using
> > /usr/share/perl5.  Like:
> > 
> > sh Configure -des \
> >  -Dprefix=/usr\
> >  -Dvendorprefix=/usr  \
> >  -Dprivlib=/usr/lib/perl5/5.32/core_perl  \
> >  -Darchlib=/usr/lib/perl5/5.32/core_perl  \
> >  -Dsitelib=/usr/lib/perl5/5.32/site_perl  \
> >  -Dsitearch=/usr/lib/perl5/5.32/site_perl \
> >  -Dvendorlib=/usr/lib/perl5/5.32/vendor_perl  \
> >  -Dvendorarch=/usr/lib/perl5/5.32/vendor_perl \
> >  -Dman1dir=/usr/share/man/man1\
> >  -Dman3dir=/usr/share/man/man3\
> >  -Dpager="/usr/bin/less -isR" \
> >  -Duseshrplib \
> >  -Dusethreads
> 
> Thanks!  After sending my previous post I realised I'd been looking
> at the wrong log and got myself confused - the plain perl in
> /usr/share started appearing in /usr/lib/perl5/5.32.0/ when the
> privlib define was removed, so obviously the old-style location is
> the default for that when perl is in /usr and it should NOT be in
> /usr/share.
> 
> So, I had independently come up with everything you have and was
> just about to try it.
> 

That works nicely.  As well as LFS (perl itself, XML-Parser) I've
manually installed a few modules (Try-Tiny, Module-Build,
Sub-Identify, SUPER, Test-Warnings, Test-MockModule, Archive-Zip)
and then I used cpan (used its automated setup option) to install
Parse::Yapp.

I've also install git using a sed to put the modules into
/usr/lib/perl5/5.32/site_perl..

All of perl itself is in /usr/lib/perl5/5.32/core_perl, all the
extra modules are in /usr/lib/perl5/5.32/site_perl).

I think we ought to change the book to do this, but I'm not sure
everyone has read htis thread - I'll raise a ticket.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Perl privlib is putting core modules in /usr/share

[Ken Moffat via lfs-dev]

On Thu, Aug 06, 2020 at 03:48:45AM +0100, Ken Moffat via lfs-dev wrote:
> On Wed, Aug 05, 2020 at 10:03:52PM +0100, Ken Moffat via lfs-dev wrote:
> 
> But by changing sitelib to
>  -Dsitearch=/usr/lib/perl5/5.32/site_perl
> I have ended up with plain perl modules in /usr/lib/prel5/5.32.0
> such as my old friend Test/More.pm.
> 
Wrong on two counts.  First, sitelib not sitearch.  Irrelevant to
the main problem and it probably did the job.

The main problem was that dropping
'-Dprivlib=/usr/share/perl5/core_perl' caused perl to use its
default.  From Config.pm when doing that :
privlibexp => '/usr/lib/perl5/5.32.0',

As I've just replied to xry111, using /usr/share for sitelib is not
at all like the defaults.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Perl privlib is putting core modules in /usr/share

[Ken Moffat via lfs-dev]

On Thu, Aug 06, 2020 at 10:31:52AM +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-08-05 22:03 +0100, Ken Moffat via lfs-dev wrote:
> > On Thu, Aug 06, 2020 at 03:57:29AM +0800, Xi Ruoyao via lfs-dev wrote:
> > > On 2020-08-05 19:53 +0100, Ken Moffat via lfs-dev wrote:
> > > > (I've changed the subject and cut down some of hte obsolete detail)
> > > > 
> > > > On Wed, Aug 05, 2020 at 04:22:49AM +0100, Ken Moffat via lfs-dev wrote:
> > [...]
> > > > False-ish alarm : the "missing" modules were installed in the
> > > > initial (chapter 7) build, but they are in
> > > > /usr/share/perl5/site_perl NOT /usr/lib/perl5/5.32/core_perl.
> > > > 
> > > > The items in /usr/lib/perl5/5.32/core_perl were either installed by
> > > > chapter 7 perl, as someone mentioned the other day, or (a few) were
> > > > installed in chapter 8 perl.  But all the items in /usr/share are
> > > > from chapter 7 and ;acking the 5.32 version.
> > > > 
> > > > At best, the location of the modules looks messy and I'm not happy
> > > > that they are in unversioned directories.
> > > > 
> > > > These are from the privlib.
> > > > 
> > > > The first useful match for privlib which I found was a bug from a
> > > > module developer (5.30 was doing somethign different from 5.26)
> > > > where the output from cpan mentioned privlib:
> > > >  Dprivlib=/usr/local/cpanel/3rdparty/perl/530/lib/perl5/5.30.0
> > > > 
> > > > https://www.nntp.perl.org/group/perl.perl5.porters/2019/10/msg256381.html
> > > > 
> > > > (Just pasting the link in case it is of any interest later)
> > > > 
> > > > I think that
> > > > 
> > > > https://stackoverflow.com/questions/54470275/what-is-the-difference-between-the-core-vendor-and-site-locations-in-perl
> > > > 
> > > > provides detailed explanations, and that from the UPDATE there we
> > > > should at least be using a version in the privlib i.e.
> > > > /usr/share/perl5/5.32/core_perl.
> > > > 
> > > > But until now we have managed without putting pure perl core modules
> > > > in /usr/share (although ISTR that when we used separate modules
> > > > related to git - perhaps Errno.pm - something did go into
> > > > /usr/share.
> > > > 
> > > > We did not used to have -Dprivlib, I guess that dropping that would
> > > > stop core modules being placed in /usr/share.
> > > > 
> > > > This leaves the items in /usr/lib/perl5/core_perl which were NOT
> > > > updated in chapter 8.  Looking at the times in ls -lR these are
> > > > either pure perl modules (*.pm), headers (in CORE) or else
> > > > directories.  I'm happy that those have not been changed between
> > > > chapter 7 and chapter 8.
> > > > 
> > > > I'll start a build WITHOUT Dprivlib later.
> > > 
> > > Is there any rationale to change the default Perl module directory, 
> > > besides
> > > to
> > > remove the Perl patch level from path?
> > > 
> > 
> > Som of the modules (.so libs) are in archlib, i.e.
> > /usr/lib/perl5/5.32/core_perl
> > 
> > > I suggest three alternatives:
> > > 
> > > (1) -Dprivlib=/usr/share/perl5/5.32/core_perl
> > > 
> > > It's like the status quo, but versioned.
> > > 
> > 
> > I am hopeful that not specifying privlib will do that.  If not, I
> > will go with that.
> 
> It's not.  The default is /usr/lib/perl5/5.32.0.
> 
> > > (2) -Dprivlib=/usr/lib/perl5/5.32
> > > 
> > > It's almost the default, but patch level (".0") removed.  -Darchlib will
> > > also
> > > need to be adjusted.
> > > 
> > I don't understand how you would change archlib ?  At the moment it
> > is /usr/lib/perl5/5.32/core_perl unless you mean to remove core_perl
> > which was one of the features of Thomas's original proposal for the new
> > layout :
> > http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-June/073877.html
> > 
> > The possibility that anything other than vendor modules (i.e. from
> > third parties) would end up in /usr/share was not apparent.
> > 
> > > (3) -Dprivlib=/usr/lib/perl5/5.32/core_perl
> > > 
> > > It matches the current -Darchlib.
> > > 
> > 
> > Another possibility.
> > 
> > > 

Re: [lfs-dev] Perl privlib is putting core modules in /usr/share

[Ken Moffat via lfs-dev]

On Wed, Aug 05, 2020 at 10:03:52PM +0100, Ken Moffat via lfs-dev wrote:
> On Thu, Aug 06, 2020 at 03:57:29AM +0800, Xi Ruoyao via lfs-dev wrote:
> > On 2020-08-05 19:53 +0100, Ken Moffat via lfs-dev wrote:
> > > 
> > > But until now we have managed without putting pure perl core modules
> > > in /usr/share (although ISTR that when we used separate modules
> > > related to git - perhaps Errno.pm - something did go into
> > > /usr/share.
> > > 
> > > We did not used to have -Dprivlib, I guess that dropping that would
> > > stop core modules being placed in /usr/share.
> > > 
> > > This leaves the items in /usr/lib/perl5/core_perl which were NOT
> > > updated in chapter 8.  Looking at the times in ls -lR these are
> > > either pure perl modules (*.pm), headers (in CORE) or else
> > > directories.  I'm happy that those have not been changed between
> > > chapter 7 and chapter 8.
> > > 
> > > I'll start a build WITHOUT Dprivlib later.
> > 
> > Is there any rationale to change the default Perl module directory, besides 
> > to
> > remove the Perl patch level from path?
> > 
> 
> Som of the modules (.so libs) are in archlib, i.e.
> /usr/lib/perl5/5.32/core_perl
> 
> > I suggest three alternatives:
> > 
> > (1) -Dprivlib=/usr/share/perl5/5.32/core_perl
> > 
> > It's like the status quo, but versioned.
> > 
> 
> I am hopeful that not specifying privlib will do that.  If not, I
> will go with that.
> 

I completed the chapter 7 build of perl, all the (plain) modules now
in /usr/lib/perl5/5.32/core_perl/ and /usr/lib/perl5/site_perl was
created.

It also created /usr/share/perl5 which will be needed if anything
ever uses vendor_perl.

But it also created /usr/share/perl5/site_perl (sitelib) - I missed
that.  And after another run to stop that directory getting created
I sat down to look at exactly what I had.

In the book, modules are variously in /usr/lib/perl5/5.32/core_perl
(good, as expected) and in /usr/share/perl5/core_perl (messy).

By not defining privlib, the modules from /usr/share moved to
/usr/lib/perl5/5.32/core_perl.

But by changing sitelib to
 -Dsitearch=/usr/lib/perl5/5.32/site_perl
I have ended up with plain perl modules in /usr/lib/prel5/5.32.0
such as my old friend Test/More.pm.

Note that I have NOT specified 5.32.0 in any of the defines.
The diff from my script is:
@@ -41,7 +41,7 @@ sh Configure -des \
  -Dprefix=/usr\
  -Dvendorprefix=/usr  \
  -Darchlib=/usr/lib/perl5/5.32/core_perl  \
- -Dsitelib=/usr/share/perl5/site_perl \
+ -Dsitelib=/usr/lib/perl5/5.32/site_perl  \
  -Dsitearch=/usr/lib/perl5/5.32/site_perl \
  -Dvendorlib=/usr/share/perl5/vendor_perl \

So apparently there is some weird interaction.  I guess I'll revert
that, live with the creation of /usr/share/perl5/site_perl and try
again.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] perl install options

[Ken Moffat via lfs-dev]

On Sat, Jun 20, 2020 at 03:49:07PM +0100, Ken Moffat via lfs-dev wrote:
> On Sat, Jun 20, 2020 at 07:05:24AM -0700, Joel Bion via lfs-dev wrote:
> > Upgrading Perl was the trigger for me building my own package dependency 
> > tracker utility. With tons of manual configuration, I am able to upgrade 
> > any subset of packages at one time. It tells me what I need to rebuild, in 
> > what order. Some packages trigger no or few rebuilds. Others, like OpenSSL, 
> > trigger a few dozen. Python 3 might trigger 100. Perl is crazy; it triggers 
> > 100s.
> > 
> > Each package has a build script I’ve written. If I ever get around to it, 
> > I’ll make it generate a super-script that involves unpacking the tar files, 
> > so I can just automate the whole build.
> > 
> > Sent from my iPhone
> > 
> I won't complain about top-posting in the light of that last line!
> 
> You must build a _lot_ more than I do: I've got several non-book
> perl modules which I sometimes build, and there are a few modules in
> the book which I never build, but in the perl directory of my
> scripts I only have 150 modules.
> 
I suppose it depends how you define a module, I was counting
tarballs.  Now that I've looked at the plain perl modules that are
now in /usr/share I found over 500 '*.pm' in site_perl.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Perl privlib is putting core modules in /usr/share

[Ken Moffat via lfs-dev]

On Wed, Aug 05, 2020 at 10:03:52PM +0100, Ken Moffat via lfs-dev wrote:
> 
> The possibility that anything other than vendor modules (i.e. from
> third parties) would end up in /usr/share was not apparent.
> 

In fact, Git.pm IS installed in /usr/share/perl5/ rather than e.g.
/usr/share/perl5/site_perl/ or /usr/lib/perl5/5.32/site_perl.

Hmm.  with perl there is _always_ another way for someone to do
something.  Now that I'm looking at /usr/share/perl5/ I see that as
well as our core_perl and site_perl (again, lots of the extra mdules
I've installed are in that site_perl) there are:
 FromCPAN (Error.pm and Mail/Address.om), Git/*/* and Git.pm
all of which come from it.

None of those match our current overrides and I don't see anything
like that in Config.pm nor in Config_heavy.pl.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Perl privlib is putting core modules in /usr/share

[Ken Moffat via lfs-dev]

On Thu, Aug 06, 2020 at 03:57:29AM +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-08-05 19:53 +0100, Ken Moffat via lfs-dev wrote:
> > (I've changed the subject and cut down some of hte obsolete detail)
> > 
> > On Wed, Aug 05, 2020 at 04:22:49AM +0100, Ken Moffat via lfs-dev wrote:
[...]
> > 
> > False-ish alarm : the "missing" modules were installed in the
> > initial (chapter 7) build, but they are in
> > /usr/share/perl5/site_perl NOT /usr/lib/perl5/5.32/core_perl.
> > 
> > The items in /usr/lib/perl5/5.32/core_perl were either installed by
> > chapter 7 perl, as someone mentioned the other day, or (a few) were
> > installed in chapter 8 perl.  But all the items in /usr/share are
> > from chapter 7 and ;acking the 5.32 version.
> > 
> > At best, the location of the modules looks messy and I'm not happy
> > that they are in unversioned directories.
> > 
> > These are from the privlib.
> > 
> > The first useful match for privlib which I found was a bug from a
> > module developer (5.30 was doing somethign different from 5.26)
> > where the output from cpan mentioned privlib:
> >  Dprivlib=/usr/local/cpanel/3rdparty/perl/530/lib/perl5/5.30.0
> > 
> > https://www.nntp.perl.org/group/perl.perl5.porters/2019/10/msg256381.html
> > 
> > (Just pasting the link in case it is of any interest later)
> > 
> > I think that
> > 
> > https://stackoverflow.com/questions/54470275/what-is-the-difference-between-the-core-vendor-and-site-locations-in-perl
> > 
> > provides detailed explanations, and that from the UPDATE there we
> > should at least be using a version in the privlib i.e.
> > /usr/share/perl5/5.32/core_perl.
> > 
> > But until now we have managed without putting pure perl core modules
> > in /usr/share (although ISTR that when we used separate modules
> > related to git - perhaps Errno.pm - something did go into
> > /usr/share.
> > 
> > We did not used to have -Dprivlib, I guess that dropping that would
> > stop core modules being placed in /usr/share.
> > 
> > This leaves the items in /usr/lib/perl5/core_perl which were NOT
> > updated in chapter 8.  Looking at the times in ls -lR these are
> > either pure perl modules (*.pm), headers (in CORE) or else
> > directories.  I'm happy that those have not been changed between
> > chapter 7 and chapter 8.
> > 
> > I'll start a build WITHOUT Dprivlib later.
> 
> Is there any rationale to change the default Perl module directory, besides to
> remove the Perl patch level from path?
> 

Som of the modules (.so libs) are in archlib, i.e.
/usr/lib/perl5/5.32/core_perl

> I suggest three alternatives:
> 
> (1) -Dprivlib=/usr/share/perl5/5.32/core_perl
> 
> It's like the status quo, but versioned.
> 

I am hopeful that not specifying privlib will do that.  If not, I
will go with that.

> (2) -Dprivlib=/usr/lib/perl5/5.32
> 
> It's almost the default, but patch level (".0") removed.  -Darchlib will also
> need to be adjusted.
> 
I don't understand how you would change archlib ?  At the moment it
is /usr/lib/perl5/5.32/core_perl unless you mean to remove core_perl
which was one of the features of Thomas's original proposal for the new
layout :
http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-June/073877.html

The possibility that anything other than vendor modules (i.e. from
third parties) would end up in /usr/share was not apparent.

> (3) -Dprivlib=/usr/lib/perl5/5.32/core_perl
> 
> It matches the current -Darchlib.
> 

Another possibility.

> And, -Dvendorlib should also be adjusted in the same manner.

I suppose that setting vendorlib the same as vendorarch, i.e.
/usr/lib/perl5/5.32/vendor_perl would make sense, but I don't have
anything (third-party?) that installs in vendor_lib.

Thanks for making me think about this a little more, even though my
brain is now on the edge of meltdown ;-)

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Perl privlib is putting core modules in /usr/share

[Ken Moffat via lfs-dev]

(I've changed the subject and cut down some of hte obsolete detail)

On Wed, Aug 05, 2020 at 04:22:49AM +0100, Ken Moffat via lfs-dev wrote:
> O Wed, Aug 05, 2020 at 01:54:44AM +0100, Ken Moffat via lfs-dev wrote:
> > I'm looking at perl module dependencies, and I can see a reference
> > to Test::More in a test, although I'm not sure if that test actually
> > gets run.  The reason I'm askng is that this used to be a core
> > module, but I cannot see it in my 5.32.0 builds, althought the man
> > page for Test::More.3 is still installed.
> > 
> > Looking at https://perldoc.perl.org/Test/More.html suggests it is
> > still part of core perl.
> > 
> > Does anyone have any knowledge of this, please ?
> > 
> > ĸen
> 
[...]
> It occurred to me that I could go to my backups and look at the
> files from the last old-style build I did.  That was for 5.30.3, so
> I expect some slight variation.
> 
> What I did in each of the core perl root directories was run
>  find . -name '*.pm' | sort >somefile
> 
> I'm attaching these (new-style-5.32.0 first), on the face of it I
> seem to have lost a phenomenal amount of modules.  But so far all my
> perl module builds and tests have worked, so I hope I'm missing
> something obvious.
> 

False-ish alarm : the "missing" modules were installed in the
initial (chapter 7) build, but they are in
/usr/share/perl5/site_perl NOT /usr/lib/perl5/5.32/core_perl.

The items in /usr/lib/perl5/5.32/core_perl were either installed by
chapter 7 perl, as someone mentioned the other day, or (a few) were
installed in chapter 8 perl.  But all the items in /usr/share are
from chapter 7 and ;acking the 5.32 version.

At best, the location of the modules looks messy and I'm not happy
that they are in unversioned directories.

These are from the privlib.

The first useful match for privlib which I found was a bug from a
module developer (5.30 was doing somethign different from 5.26)
where the output from cpan mentioned privlib:
 Dprivlib=/usr/local/cpanel/3rdparty/perl/530/lib/perl5/5.30.0

https://www.nntp.perl.org/group/perl.perl5.porters/2019/10/msg256381.html

(Just pasting the link in case it is of any interest later)

I think that

https://stackoverflow.com/questions/54470275/what-is-the-difference-between-the-core-vendor-and-site-locations-in-perl

provides detailed explanations, and that from the UPDATE there we
should at least be using a version in the privlib i.e.
/usr/share/perl5/5.32/core_perl.

But until now we have managed without putting pure perl core modules
in /usr/share (although ISTR that when we used separate modules
related to git - perhaps Errno.pm - something did go into
/usr/share.

We did not used to have -Dprivlib, I guess that dropping that would
stop core modules being placed in /usr/share.

This leaves the items in /usr/lib/perl5/core_perl which were NOT
updated in chapter 8.  Looking at the times in ls -lR these are
either pure perl modules (*.pm), headers (in CORE) or else
directories.  I'm happy that those have not been changed between
chapter 7 and chapter 8.

I'll start a build WITHOUT Dprivlib later.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Perl-5.32.0 : Has Test::More disappeared ?

[Ken Moffat via lfs-dev]

O Wed, Aug 05, 2020 at 01:54:44AM +0100, Ken Moffat via lfs-dev wrote:
> I'm looking at perl module dependencies, and I can see a reference
> to Test::More in a test, although I'm not sure if that test actually
> gets run.  The reason I'm askng is that this used to be a core
> module, but I cannot see it in my 5.32.0 builds, althought the man
> page for Test::More.3 is still installed.
> 
> Looking at https://perldoc.perl.org/Test/More.html suggests it is
> still part of core perl.
> 
> Does anyone have any knowledge of this, please ?
> 
> ĸen

I think wei may have a problem.  I just did a manual mostly-default
build, and installed to a user-writable location.  That is without
any of the defines we set, except I agreed to shared perl lib.
Uasing ls -R I coud see that I had files in Test/ but I do not have
that directory on the LFS install.  Unfortunately, things were moved
around (missing thread-multi etc) so the diff from the two ls -R
commands was unuseful.

Threw that away, retried with all the commands in the book, got a
result similar to the LFS install (a couple of extra libs from extra
dependencies, but no Test/ directory.

I'll need to try variations to see if I can identify why the Test/
items got lost, and also if anything else was lost.

>From what somebody said the other day, I'm starting to wonder if I
need to use a different prefix (like I did for my first run) to
avoid pickign up the old configure details.

It occurred to me that I could go to my backups and look at the
files from the last old-style build I did.  That was for 5.30.3, so
I expect some slight variation.

What I did in each of the core perl root directories was run
 find . -name '*.pm' | sort >somefile

I'm attaching these (new-style-5.32.0 first), on the face of it I
seem to have lost a phenomenal amount of modules.  But so far all my
perl module builds and tests have worked, so I hope I'm missing
something obvious.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
./attributes.pm
./B/Concise.pm
./B.pm
./B/Showlex.pm
./B/Terse.pm
./B/Xref.pm
./Compress/Raw/Bzip2.pm
./Compress/Raw/Zlib.pm
./Config.pm
./Cwd.pm
./Data/Dumper.pm
./DB_File.pm
./Devel/Peek.pm
./Devel/PPPort.pm
./Digest/MD5.pm
./Digest/SHA.pm
./DynaLoader.pm
./Encode/Alias.pm
./Encode/Byte.pm
./Encode/CJKConstants.pm
./Encode/CN/HZ.pm
./Encode/CN.pm
./Encode/Config.pm
./Encode/EBCDIC.pm
./Encode/Encoder.pm
./Encode/Encoding.pm
./Encode/GSM0338.pm
./Encode/Guess.pm
./Encode/JP/H2Z.pm
./Encode/JP/JIS7.pm
./Encode/JP.pm
./Encode/KR/2022_KR.pm
./Encode/KR.pm
./Encode/MIME/Header/ISO_2022_JP.pm
./Encode/MIME/Header.pm
./Encode/MIME/Name.pm
./Encode.pm
./Encode/Symbol.pm
./Encode/TW.pm
./Encode/Unicode.pm
./Encode/Unicode/UTF7.pm
./encoding.pm
./Errno.pm
./Fcntl.pm
./File/DosGlob.pm
./File/Glob.pm
./File/Spec/AmigaOS.pm
./File/Spec/Cygwin.pm
./File/Spec/Epoc.pm
./File/Spec/Functions.pm
./File/Spec/Mac.pm
./File/Spec/OS2.pm
./File/Spec.pm
./File/Spec/Unix.pm
./File/Spec/VMS.pm
./File/Spec/Win32.pm
./Filter/Util/Call.pm
./GDBM_File.pm
./Hash/Util/FieldHash.pm
./Hash/Util.pm
./I18N/Langinfo.pm
./IO/Dir.pm
./IO/File.pm
./IO/Handle.pm
./IO/Pipe.pm
./IO.pm
./IO/Poll.pm
./IO/Seekable.pm
./IO/Select.pm
./IO/Socket/INET.pm
./IO/Socket.pm
./IO/Socket/UNIX.pm
./IPC/Msg.pm
./IPC/Semaphore.pm
./IPC/SharedMem.pm
./IPC/SysV.pm
./lib.pm
./List/Util.pm
./List/Util/XS.pm
./Math/BigInt/FastCalc.pm
./MIME/Base64.pm
./MIME/QuotedPrint.pm
./mro.pm
./NDBM_File.pm
./ODBM_File.pm
./Opcode.pm
./O.pm
./ops.pm
./PerlIO/encoding.pm
./PerlIO/mmap.pm
./PerlIO/scalar.pm
./PerlIO/via.pm
./POSIX.pm
./re.pm
./Scalar/Util.pm
./SDBM_File.pm
./Socket.pm
./Storable.pm
./Sub/Util.pm
./Sys/Hostname.pm
./Sys/Syslog.pm
./threads.pm
./threads/shared.pm
./Time/HiRes.pm
./Time/Piece.pm
./Time/Seconds.pm
./Unicode/Collate/Locale.pm
./Unicode/Collate.pm
./Unicode/Normalize.pm
./AnyDBM_File.pm
./App/Cpan.pm
./App/Prove.pm
./App/Prove/State.pm
./App/Prove/State/Result.pm
./App/Prove/State/Result/Test.pm
./Archive/Tar/Constant.pm
./Archive/Tar/File.pm
./Archive/Tar.pm
./Attribute/Handlers.pm
./autodie/exception.pm
./autodie/exception/system.pm
./autodie/hints.pm
./autodie.pm
./autodie/Scope/Guard.pm
./autodie/Scope/GuardStack.pm
./autodie/skip.pm
./autodie/Util.pm
./AutoLoader.pm
./AutoSplit.pm
./autouse.pm
./base.pm
./B/Deparse.pm
./Benchmark.pm
./bigint.pm
./bignum.pm
./bigrat.pm
./blib.pm
./B/Op_private.pm
./bytes.pm
./Carp/Heavy.pm
./Carp.pm
./_charnames.pm
./charnames.pm
./Class/Struct.pm
./Compress/Zlib.pm
./Config/Extensions.pm
./Config/Perl/V.pm
./constant.pm
./CPAN/Author.pm
./CPAN/Bundle.pm
./CPAN/CacheMgr.pm
./CPAN/Complete.pm
./CPAN/Debug.pm
./CPAN/DeferredCode.pm
./CPAN/Distribution.pm
./CPAN/Distroprefs.pm
./CPAN/Distrostatus.pm
./CPAN/Exception/blocked_urllist.pm
./CPAN/Exception/RecursiveDependency.pm
./CPAN/Except

[lfs-dev] Perl-5.32.0 : Has Test::More disappeared ?

[Ken Moffat via lfs-dev]

I'm looking at perl module dependencies, and I can see a reference
to Test::More in a test, although I'm not sure if that test actually
gets run.  The reason I'm askng is that this used to be a core
module, but I cannot see it in my 5.32.0 builds, althought the man
page for Test::More.3 is still installed.

Looking at https://perldoc.perl.org/Test/More.html suggests it is
still part of core perl.

Does anyone have any knowledge of this, please ?

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] grub with uefi for LFS 10?

[Ken Moffat via lfs-dev]

On Sun, Aug 02, 2020 at 10:07:23PM +0200, Alexey Orishko via lfs-dev wrote:
> On Sun, Aug 2, 2020 at 6:46 PM Xi Ruoyao via lfs-dev
>  wrote:
> 
> > > Since majority of new laptops have EFI, it would really help to have
> >  The readers who don't need EFI will be annoyed.  meson/ninja already 
> > annoyed
> > the readers using sysvinit.
> 
> Quote from Linux From Scratch - Version SVN-20200721 / Preface / vi.
> Rationale for Packages in the Book:
> "As stated earlier, the goal of LFS is to build a complete and usable
> foundation-level system. ..."
> If LFS cannot be booted on modern pc, the statement above should be
> changed to "... usable foundation-level system on LEGACY computers
> only."
> Otherwise information in preface creates a false assurance that
> building LFS is enough to boot and continue with BLFS on some modern
> target system.
> 
> /alexey

Last year I bought a couple of new AMD desktop systems using APUs
and low-end motherboards.  With those LFS is sufficient to boot and
get a network connection (but only for 80x25, using the framebuffer
and later X requires firmware from BLFS).

Laptops, particularly those without a wired network, may be entirely
different.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] report: test build with glibc-development, and old updated packages

[Ken Moffat via lfs-dev]

On Sun, Aug 02, 2020 at 10:10:03PM +0200, Pierre Labastie via lfs-dev wrote:
> I've done a test build with git version of glibc, and all other
> packages updated. I've forgotten the beta version of autoconf.

I thought I was out on a limb with autoconf ;-)  So far, apart from
automake tests it looks good - but I have not (at this point) built
most of the packages I identified as using it.

> 
> The patch for gcc pass 2 is not needed anymore.
> 
> But the sed or the whole patch for binutils gold tests is (are)
> still needed. I haven't had the time to get to the exact
> requirements...
> 

Agreed.

> With the git version of glibc, one more test fails, besides misc/tst-
> ttyname (BTW, Ken, when this one does not fail, isn't it in the
> UNSUPPORTED list?): io/tst-lchmod.
> 

I'll need to find logs where it did not fail, so far I've only been
looking at the machine where I'm experimenting.

> I also have a lot of failures in gcc tests:
> 6 in libstdc++ (the usual locale/time_get/get_time failures
> 7 in gcc (gcc.dg/asan/pr80166.c in various conditions)
> 17 in g++ (all in g++.dg/coroutines/torture)
> 

Ooh.  I'll need to look at past (gcc-10.1) failures to see if those
match any of my past results.

> Also, as reported in ticket #4700, all pipeline tests fail with the new
> check version. I've proposed a sed, which I hope can be further
> simplified...
> 
> All in all, the build went ok. And the system boots (in a VM) without
> difficulty.
> 
> Pierre
> 

I'll try and follow-up in the next day or two.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] More observations on directory creations

[Ken Moffat via lfs-dev]

On Sat, Aug 01, 2020 at 04:20:54PM +0200, Pierre Labastie via lfs-dev wrote:
> 
> > 
> > Hoping there's something there for someone,
> 
> Sure! At least for me (and Thomas)
> 
> Pierre
> 
+1

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] grub with uefi for LFS 10?

[Ken Moffat via lfs-dev]

On Sat, Aug 01, 2020 at 03:10:54PM -0500, Timothy Russo via lfs-dev wrote:
> With efi being more the standard now, I'd like to ask if we could default
> grub to supporting uefi instead of having to use the uefi hint.
> 
> Or at last maybe formalize it and make it an option, where you can pick
> bios/mbr or uefi option.
> 
> Just a thought.
> 
> Thanks,
> 
> Tim Russo

After this week's problems with unbootable systems after updating
(at least fedora, maybe also debian and ubuntu) I'm relieved that we
haven't picked up this weeks "fixes for signed grub" and made uefi
support the default.  I agree that if uefi "just worked" without
requiring people to jump into holes would be nice, but
for an individual who owns his or her machine, signed booting is not
necessarily desirable.

ĸen
-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] rustc in BLFS-10.0 : stick with 1.42.0 :-(

[Ken Moffat via lfs-dev]

People may have noticed that I was hoping to propose that we update
rustc to 1.45.0 for our 10.0 release.  I've now dropped that hope.

For 1.45.0 my thinking was:

i) it's current.

ii) it might stop us having to upgrade for a while (from current
packages, librsvg will be what probaby forces that).

iii) it fixed a longstanding rust issue which could cause undefined
behaviour: https://blog.rust-lang.org/2020/07/16/Rust-1.45.0.html
(not bad for a compiler which claims to be safe except when using
items labelled as unsafe).

I also noted that thunderbird-78.0.1 failed to build for me using
gcc (an error from rust that a combination of clang flags were
incompatible) - people using clang had already hit that, and gentoo
had a sed for (I think) firefox.

So, on my current experimental build (same packages and
optimizations as last weekend except for kernel headers,
binutils-2.35, gcc-10.2.0, llvm-11.0.0RC1) I was expecting to look
at this.

But neither our current rustc-1.42.0, nor rustc-1.45.0, can be built
with that llvm rc.  The error from 1.42.0 started like this (and
1.45.0 looked similar):

running: "c++" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" 
"-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-march=native" 
"-fstack-clash-protection" "-D_FORTIFY_SOURCE=2" "-fstack-protector-strong" 
"-I/usr/include" "-std=c++14" "-fno-exceptions" "-D_GNU_SOURCE" 
"-D__STDC_CONSTANT_MACROS" "-D__STDC_FORMAT_MACROS" "-D__STDC_LIMIT_MACROS" 
"-DLLVM_COMPONENT_AMDGPU" "-DLLVM_COMPONENT_ASMPARSER" 
"-DLLVM_COMPONENT_BITREADER" "-DLLVM_COMPONENT_BITWRITER" 
"-DLLVM_COMPONENT_INSTRUMENTATION" "-DLLVM_COMPONENT_IPO" 
"-DLLVM_COMPONENT_LINKER" "-DLLVM_COMPONENT_LTO" "-DLLVM_COMPONENT_X86" 
"-DNDEBUG" "-o" 
"/scratch/working/rustc-1.42.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-b716d70709b7ebd7/out/../rustllvm/PassWrapper.o"
 "-c" "../rustllvm/PassWrapper.cpp"
cargo:warning=In file included from /usr/include/llvm/IR/Use.h:29,
cargo:warning= from /usr/include/llvm/IR/User.h:23,
cargo:warning= from /usr/include/llvm/IR/Constant.h:16,
cargo:warning= from /usr/include/llvm/IR/Metadata.h:29,
cargo:warning= from /usr/include/llvm/IR/TrackingMDRef.h:16,
cargo:warning= from /usr/include/llvm/IR/DebugLoc.h:17,
cargo:warning= from /usr/include/llvm/IR/Instruction.h:22,
cargo:warning= from /usr/include/llvm/IR/BasicBlock.h:22,
cargo:warning= from /usr/include/llvm/IR/IRBuilder.h:22,
cargo:warning= from ../rustllvm/rustllvm.h:9,
cargo:warning= from ../rustllvm/PassWrapper.cpp:6:
cargo:warning=../rustllvm/PassWrapper.cpp: In function 'T* 
unwrap(LLVMPassManagerBuilderRef)':
cargo:warning=../rustllvm/PassWrapper.cpp:43:1: error: call of overloaded 
'unwrap(LLVMOpaquePassManagerBuilder*&)' is ambiguous

From that I conclude that current versions of rustc with llvm-11
will need their shipped llvm, which is slow and large to build (on
this system, 1.42.0 with its shipped llvm took 40.8 SBU and
installed 394.3 MiB on this 8-thread machine, against 34.3 SBU and
250.8 MiB for a build from the beginning of June - both without
running the tests).

Meanwhile, rustc-1.45.1 is out, but the release notes
https://blog.rust-lang.org/2020/07/30/Rust-1.45.1.html do not
mention llvm-11.  The 1.46.0 release is expected to be after 15th
April and llvm-11 probably won't be released until September.  So I
doubt that anyone will fix rustc for building with sysllvm in the
near future.

Therefore, for our 10.0 release rustc-1.42.0 looks like the way to
go.

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Tcl failed soem tests

[Ken Moffat via lfs-dev]

On Thu, Jul 30, 2020 at 08:15:10PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 7/30/20 6:22 PM, Ken Moffat via lfs-dev wrote:
> 
> What I really think you need to do is do a full build without CFLAGS or
> CXXFLAGS set.  Then compare with a build with those settings.
> 

You really distrust CFLAGS and CXXFLAGS, don't you.  I take the view
that security is important, as is optimising (now that everything
builds so slowly).i  Yes, sometimes CFLAGS _do_ screw up occasional
packages.   Anyway, I don't think I've got a machine in a suitable
state to try a build without my flags.

In any case, it could be something else entirely, at this point I'm
only interested in whether my results are unusual or normal.  On my
previous two cross-chapter5 builds, and my one build in mid-June
where the new style was in trunk, I did not run tests for tcl (that
was added on 22nd June, r11981).

> My test logs are not complete, but if you really want me to, I can do a full
> build as of 20200721 with all tests.  I can upload the test files to anduin
> for you to compare.
> 
>   -- Bruce
> 

Thanks, but I don't think that will be necessary at the moment.  I'm
sure you've got better things to do.

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Tcl failed soem tests

[Ken Moffat via lfs-dev]

On my experimental build which is currently in progress, I managed
to log the results of tcl's tests.  At first I thought the tests had
died, but in the end they completed (2.9 SBU with make -j8, most of
the time obviously spent on tests which failed).  The results do not
look wonderful:

Tests ended at Thu Jul 30 21:10:12 + 2020
all.tcl:Total   24996   Passed  21606   Skipped 3336Failed  54
Sourced 150 Test Files.
Files with failing tests: http.test httpold.test
Number of tests skipped for each constraint:
9   !ieeeFloatingPoint
[snip]
2   xdev

Test files exiting with errors:

  clock.test


I see there were quite a lot of failures in the clock tests, several
in http, and 1 in httpold.  I've no idea if this is normal, but the
timing seems to be more than a bit different from what the book
says.  For now I'll just mention it and ask if anyone else sees
similar or better results.  I've got the full log, but it's 99K so I
won't bother uploading or attaching it for the moment.

The expect tests were fine, as were the tests for dejagnu.

As is normal, I'm using my normal CFLAGS and CXXFLAGS - they start
out as
 (CFLAGS) -O3 -march=native -fstack-clash-protection -fstack-protector-strong
 (CXXFLAGS) -O3 -march=native -fstack-clash-protection -fstack-protector-strong 
-D_GLIBCXX_ASSERTIONS
although I don't necessarily use all of those on all packages.  I'm
also using headers from linux-5.8.0-rc7 for this build (I said it
was experimental!) and running a 5.8.0-rc5 kernel which has help up
well for the past 4 days (sleeping some of the time) and for a few
days before that.

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Learning the new build system

[Ken Moffat via lfs-dev]

I like the new build system, the mostly improved test results are
very encouraging.  But I suspect I've still got a lot to learn about
how the combination of the new approach plus my own scripts can go
wrong.

I completed my normal build from last Saturday's books a day or so
ago, and almost everything was rosy, or else (in terms of tests) 'as
expected'.

But I was not happy about how I remind myself which
directories need to exist and be writable by the lfs user (I'm used
to creating a few extras for my approach, and binding or chowning,
but I can't remember what else is needed - it was more than 6 weeks
since my previous build :)

I also noticed that I had not logged the test results from tcl and
expect - they sailed through and obviously wrote to the screen, but
I had no idea what they said.

I've also got an interest in updated binutils, gcc, autoconf-beta as
noted, and llvm-1.0.0rc1 if I get that far (this is an
'experimental' system).  So, this afternoon I started a new build
(only those packages have changed since the previous build, to cut
down variations and/or identify what they break).

Things were going well until I ran the glibc tests.  I use pairs of
scripts: Top-level for everything done as user lfs, an intochroot
script, and a chroot script for everything done as root up to the
end of chapter 8.  These then invoke a series of scripts for
packages, each of which should exit if there is an unexpected error.

In glibc, I got the misc/tst-ttyname failure and the package script
exited without attempting to install.  Fine, I'd removed the '||
true' because recent builds had not had any failures in glibc.  Add
it back, restart the chroot script.  Or not:

/sources/scripts/lfs-dev/git/chroot.d/glibc: line 25: /bin/rm: No such file or 
directory
/sources/scripts/lfs-dev/git/functions: line 851: /usr/bin/awk: No such file or 
directory
/sources/scripts/lfs-dev/git/functions: line 851: /bin/date: No such file or 
directory

I was still in chroot, looking around all the items in $LFS/lib
seemed to be present and correct.  The nI tried exitign chroot and
trying to re-enter it:

chroot: failed to run command '/usr/bin/env': No such file or directory

Again, it was present and the items referenced by ldd seemed to be
there.  Ran 'strace -o trace chroot /mnt/lfs' but that just gave me
much the same:

execve("/bin/bash", ["/bin/bash", "-i"], 0x7ffc231e3600 /* 18 vars */) = -1 
ENOENT (No such file or directory)

And of course $LFS/bin/bash was present and again the libs seemed
ok.

Start over.  This time I backed up before entering chroot, then
temporarily put a stop after each package up to and including glibc.
Then a series of run, stop, exit chroot, remove the stop from the
controlling script, re-enter chroot, run the chroot script.

All good.  In glibc I got the same failed test, but the script now
continued and installed.  Exit chroot, remove the last stop,
re-enter chroot, continue.

So, I know *something* can go wrong with my script, but no idea
what.  Fun, isn't it ?  ;-)

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Expected package changes for LFS-10.0 ?

[Ken Moffat via lfs-dev]

On Tue, Jul 28, 2020 at 04:32:50PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 7/28/20 3:53 PM, Ken Moffat via lfs-dev wrote:
> 
> > I'll now mention that a new release of autoconf is being prepared.
> > 2.69b (i.e. beta) came out a few days ago.  Looking at gnu git,
> > there have been a few more fixes since then.
> 
> I'm on the autoconf mailing list and built the beta.
> 
> Parallel build is OK.  Tests are slow and don't seem to be parallelizable.
> 
Agreed.

> On a full system rhe tests pass with:
> 
> 479 tests behaved as expected.
> 44 tests were skipped.
> 

Yes, that matches what I said.

> Most of the skips were due to not having fortran, erlang, or go.  There were
> also four expected failures.
> 

As with all other skips and expected failures, we normally ignore
them.

> There are a fair number of issues on the list, but AFAICT, not for x86_64.
> 

Agreed

> The release will not be in time for LFS-10.
> 
>   -- Bruce

Do you mean "old, with a broken test suite, but released" should
always be preferred to "beta, but looks good" ?

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Expected package changes for LFS-10.0 ?

[Ken Moffat via lfs-dev]

On Mon, Jul 27, 2020 at 10:43:44PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 7/27/20 10:35 PM, Xi Ruoyao via lfs-dev wrote:
> > On 2020-07-28 03:30 +0100, Ken Moffat via lfs-dev wrote:
> > > On Mon, Jul 27, 2020 at 09:05:32PM -0500, Douglas R. Reno via lfs-dev 
> > > wrote:
> > > > As far as I know, we have another binutils as well (2.35). I think 
> > > > there's a
> > > > new version of Check as well, the kernel, and util-linux.
> > > > 
> > > Cheers.  I'm on check-0.15.0 at the moment (haven't looked at any
> > > LFS testsuite results yet).  Binutils is the sort of thing which
> > > might cause occasional breakage, util-linux less so in terms of
> > > building and testing packages (but potentially more so in terms of
> > > being able to run commands I usually run, of course).
> > 
> > Glibc-2.32 will be released on Aug 1st.  I suggest to wait for it since 
> > anyway
> > we'll have to rebuild everything for it.
> > 
> 
> That's my plan.
> 
>   -- Bruce

I'll now mention that a new release of autoconf is being prepared.
2.69b (i.e. beta) came out a few days ago.  Looking at gnu git,
there have been a few more fixes since then.

I've now found the release announcement at:
https://lists.gnu.org/archive/html/autoconf/2020-07/msg6.html

Quoting Zack Weinberg:

| We are pleased to announce beta release 2.69b of GNU Autoconf.
| 
| This release includes eight years of development work since the
| previous release, 2.69.  See below for the detailed list of changes
| since the previous version, as summarized by the NEWS file.
| 
| Because it has been such a long time, and because some of the changes
| potentially break existing Autoconf scripts, we are conducting a
| public beta test before the final release of version 2.70.  Please
| test this beta with your autoconf scripts, and report any problems you
| find to the Savannah bug tracker:
| 
|https://savannah.gnu.org/support/?func=additem=autoconf
| 
| Please also send general comments and feedback to .
| 
| Please also spread this announcement widely, so that as many Autoconf
| users as possible hear about it.
| 
| The final release of Autoconf 2.70 is tentatively scheduled for three
| months from now.  We may make more beta releases during this period.


I'm running a system using what's in the book as of Saturday (now in
BLFS, I've got as far as firefox), and still checking my logs re the
test results.  Got to autoconf, saw the breakage, and then
remembered that I'd seen a mention of a maintainer.

So, I can't say what will happen in chroot (maybe circular
dependencies), but in my completed system with 2.69b and make -j8
(haswell i7) I got:

## - ##
## Test results. ##
## - ##

479 tests behaved as expected.
44 tests were skipped.

For 2.69 in chroot I had:

ERROR: 450 tests were run,
137 failed (4 expected failures).
53 tests were skipped.

I'm usually reluctant to suggest beta versions for LFS, but perhaps
this might be valid ?  Clearly needs more testing, and it is
_possible_ that it might break something in BLFS.

I don't expect to finish this system for at least a week, probably
longer (will be looking at perl modules and rust), but I'll
certainly try 2.69b in my next build.

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] procps-ng: seds and rm for testsuite unnecessary

[Ken Moffat via lfs-dev]

I think the following modifications to the procps-ng testsuite are
unnecessary:

sed -i -r 's|(pmap_initname)\\\$|\1|' testsuite/pmap.test/pmap.exp
sed -i '/set tty/d' testsuite/pkill.test/pkill.exp
rm testsuite/pgrep.test/pgrep.exp

I dropped these a while ago, and now that I've completed a current
build the results for procps-ng look fine (attached)

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
check
check
make  check-recursive
Making check in include
make[2]: Nothing to be done for 'check'.
Making check in man-po
make[2]: Nothing to be done for 'check'.
Making check in po
make[2]: Nothing to be done for 'check'.
Making check in testsuite
make  check-DEJAGNU
make[3]: Entering directory '/building/procps-ng-3.3.16/testsuite'
Making a new site.exp file ...
make[3]: Leaving directory '/building/procps-ng-3.3.16/testsuite'
make[3]: Entering directory '/building/procps-ng-3.3.16/testsuite'
srcdir='.'; export srcdir; \
EXPECT=expect; export EXPECT; \
if /bin/sh -c "runtest --version" > /dev/null 2>&1; then \
  exit_status=0; l='pmap slabtop sysctl  free lib pgrep pkill ps pwdx uptime 
vmstat w'; for tool in $l; do \
if runtest --tool $tool --srcdir $srcdir  ; \
then :; else exit_status=1; fi; \
  done; \
else echo "WARNING: could not find 'runtest'" 1>&2; :;\
fi; \
exit $exit_status
WARNING: Couldn't find tool init file
Test run by root on Mon Jul 27 18:45:24 2020
Native configuration is x86_64-pc-linux-gnu

=== pmap tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./pmap.test/pmap.exp ...

=== pmap Summary ===

# of expected passes11
/building/procps-ng-3.3.16/pmap version 3.3.16

WARNING: Couldn't find tool init file
Test run by root on Mon Jul 27 18:45:24 2020
Native configuration is x86_64-pc-linux-gnu

=== slabtop tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./slabtop.test/slabtop.exp ...

=== slabtop Summary ===

# of expected passes8
WARNING: Couldn't find tool init file
Test run by root on Mon Jul 27 18:45:24 2020
Native configuration is x86_64-pc-linux-gnu

=== sysctl tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./sysctl.test/sysctl_read.exp ...

=== sysctl Summary ===

# of expected passes5
/building/procps-ng-3.3.16/sysctl version 3.3.16

WARNING: Couldn't find tool init file
Test run by root on Mon Jul 27 18:45:24 2020
Native configuration is x86_64-pc-linux-gnu

=== free tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./free.test/free.exp ...

=== free Summary ===

# of expected passes13
/building/procps-ng-3.3.16/free version 3.3.16

WARNING: Couldn't find tool init file
Test run by root on Mon Jul 27 18:45:25 2020
Native configuration is x86_64-pc-linux-gnu

=== lib tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./lib.test/fileutils.exp ...
Running ./lib.test/strutils.exp ...

=== lib Summary ===

# of expected passes8
WARNING: Couldn't find tool init file
Test run by root on Mon Jul 27 18:45:25 2020
Native configuration is x86_64-pc-linux-gnu

=== pgrep tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./pgrep.test/pgrep.exp ...

=== pgrep Summary ===

# of expected passes24
/building/procps-ng-3.3.16/pgrep version 3.3.16

WARNING: Couldn't find 

Re: [lfs-dev] Expected package changes for LFS-10.0 ?

[Ken Moffat via lfs-dev]

On Mon, Jul 27, 2020 at 09:05:32PM -0500, Douglas R. Reno via lfs-dev wrote:
> 
> As far as I know, we have another binutils as well (2.35). I think there's a
> new version of Check as well, the kernel, and util-linux.
> 
Cheers.  I'm on check-0.15.0 at the moment (haven't looked at any
LFS testsuite results yet).  Binutils is the sort of thing which
might cause occasional breakage, util-linux less so in terms of
building and testing packages (but potentially more so in terms of
being able to run commands I usually run, of course).

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Expected package changes for LFS-10.0 ?

[Ken Moffat via lfs-dev]

On Mon, Jul 27, 2020 at 09:00:55PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 7/27/20 8:45 PM, Ken Moffat via lfs-dev wrote:
> > I see that a newer gettext is now out, which probably allows
> > bison-3.7.0 to build.  Meanwhile, I'm hopeful that bison-3.7.1 will
> > be out soon, with tests to detect whether it can use the functions
> > added in 3.7 or must fall back to functions available in e.g.
> > gettext-0.20.2.
> > 
> > But meanwhile (and particularly re testing/measuring rust and its
> > users in BLFS) I'm trying to get my head around what else in LFS is
> > likely to change for LFS-10.0 - particularly toolchain packages.
> 
> > For the main toolchain, I think that gcc-10.2.0 will be in, and from
> > what Bruce said the other day on BLFS, a newer glibc.  AFAICS,
> > llvm-11 will not arrive until September and therefore llvm-10.0.1 is
> > as new as we'll be using.
> > 
> > Anything else, anyone, or anything wrong in what I've written here ?
> 
> All the tickets at 
> http://wiki.linuxfromscratch.org/lfs/query?owner=~=assigned=new=reopened=milestone=id=summary=status=owner=type=time=owner

Thanks, I think - pasting that into links ( still building firefox )
gives me tickets 1-100 of 4017 (highest priority defects, tickets
#13 to #517 ).

I'll look tomorrow when firefox is built.

But I'm more concerned about things that people who have been
following individual packages know are likely to be released soon
;-)

> 
> > Also, any thoughts on when we can start testing 10.0, and therefore
> > which kernel series to use (5.8.0 will either be released on Sunday,
> > or else a week later) - in my current build I've used what is in the
> > book (5.7.9) rather than 5.8-rc, but it feels "so old" ;-)
> 
> We will try to get everything that is current on Aug 15.  After that thee
> will only be very limited updates -- nothing major.
> 

OK, thanks for confirming that August 15 is the cutoff.

> > I'm trying to optimize my time for testing, and measuring, the
> > packages which use rust - hopefully to propose 1.45.0, but also to
> > measure their sizes and build-slowness with both gcc and clang.  For
> > example, with current rustc-1.42.0 I know that firefox using the
> > book's options builds faster with gccc than with llvm-10.0.0.  I'd
> > like to be able to offer gcc as an option for thunderbird (for
> > people who care about security - llvm is poor on security options).
> 
> I'll be updating everything that's open this weekend.
> 
>   -- Bruce

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Expected package changes for LFS-10.0 ?

[Ken Moffat via lfs-dev]

I see that a newer gettext is now out, which probably allows
bison-3.7.0 to build.  Meanwhile, I'm hopeful that bison-3.7.1 will
be out soon, with tests to detect whether it can use the functions
added in 3.7 or must fall back to functions available in e.g.
gettext-0.20.2.

But meanwhile (and particularly re testing/measuring rust and its
users in BLFS) I'm trying to get my head around what else in LFS is
likely to change for LFS-10.0 - particularly toolchain packages.

For the main toolchain, I think that gcc-10.2.0 will be in, and from
what Bruce said the other day on BLFS, a newer glibc.  AFAICS,
llvm-11 will not arrive until September and therefore llvm-10.0.1 is
as new as we'll be using.

Anything else, anyone, or anything wrong in what I've written here ?

Also, any thoughts on when we can start testing 10.0, and therefore
which kernel series to use (5.8.0 will either be released on Sunday,
or else a week later) - in my current build I've used what is in the
book (5.7.9) rather than 5.8-rc, but it feels "so old" ;-)

I'm trying to optimize my time for testing, and measuring, the
packages which use rust - hopefully to propose 1.45.0, but also to
measure their sizes and build-slowness with both gcc and clang.  For
example, with current rustc-1.42.0 I know that firefox using the
book's options builds faster with gccc than with llvm-10.0.0.  I'd
like to be able to offer gcc as an option for thunderbird (for
people who care about security - llvm is poor on security options).

TIA

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Bison: The tests are known to fail using multiple processors.

[Ken Moffat via lfs-dev]

Where tests for a past version have been known to fail using -jN, we
tend to carry forward a warning.  Perhaps it would be more useful
to say 'have been known to fail'.

For example, today I tested the bison dev version on a completed
system, and was reminded how tlong that takes at -j1.  So I retried
at -j8 and had no problems.  Then I did the same with the current
3.6.4 version and again had no problems.

Of course, YMMV.

ĸen
-- 
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
  - Hogfather
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] perl install options

[Ken Moffat via lfs-dev]

On Sat, Jun 20, 2020 at 02:42:03PM +0200, Thomas Trepl via lfs-dev wrote:
> Hi all,
> 
> this is about hte configuration options of perl.
> 
> Problem:
> whenever perl is upgraded to a newer version (for example 5.30.2 to
> 5.30.3), all perl modules needs to be reinstalled as the current
> configuration of perl forces a directory structure like
> 
> /usr
>   /lib
> /perl5
>   /5.30.2
> /...
>   /site_perl
> 
[...]
> 
> This will produce a directory structure:
> 
> /usr
>   /lib
> /perl5
>   /5.30
> /core_perl
>   /...
> /site_perl
>   /...
> 
In a few months time perl7 will be the next version, expected within
a year :

https://www.perl.com/article/announcing-perl-7/

(a follow-up to 5.32).  And at that time perl5 will go into long-term
maintenance.  I assume that any vulnerabilities in perl5 will
continue to get fixes for a while, but I'm not clear how long 7 is
intended to last (the web page mentions

"There will be compatibility modes to assist you in the transition
from Perl 5 to 7 (but not Perl 5 to 8). A pragma will set the knobs
and dials back to the old settings (but this is more of a one version
thing)"

OTOH, "Will there be a separate CPAN for Perl 7? No one has said
there can’t be, but in the jump to Perl 7, the developers don’t want
to redo what’s already working. This change should be manageable
with as few side quests as possible."

As I've said, I'll give this approach a go when I update my scripts,
and I'll hope it lasts.

ĸen
-- 
   He died at the console, of hunger and thirst.
   Next day he was buried, face-down, nine-edge first.
  - the perfect programmer
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] perl install options

[Ken Moffat via lfs-dev]

On Mon, Jun 22, 2020 at 10:13:19PM +0200, Thomas Trepl wrote:
> Am Samstag, den 20.06.2020, 14:53 +0100 schrieb Ken Moffat via lfs-
> dev:
> > On Sat, Jun 20, 2020 at 02:42:03PM +0200, Thomas Trepl via lfs-dev wrote:
> > > Hi all,
> > > 
> > > this is about hte configuration options of perl.
> > > 
> > > Problem:
> > > whenever perl is upgraded to a newer version (for example 5.30.2 to
> > > 5.30.3), all perl modules needs to be reinstalled as the current
> > > configuration of perl forces a directory structure like
> > > 
> 
> > > 
> > > All modules are installed under /usr/lib/perl5/5.30.2 . Now, when
> > > installing a newer patch-version by overwriting the existing one, the
> > > structure looks like
> > > 
> 
> > > 
> > > The 5.30.2-directory (which includes the modules) is more or less
> > > garbage as the new perl will use 5.30.3. Therefore, any installed
> > > module must be reinstalled to appear in the 5.30.3 structure.
> > > 
> > > This all is not really a problem as long as the system is completely
> > > built from scratch and all modules are installed freshly. For those
> > > who uses some kind of pkgmnr or upgrade the system package by package
> > > it might be a problem when perl is about to upgrade.
> > > 
> > 
> > Yes, for my own systems I have had to rebuild all the modules if
> > upgrading perl.
> > 
> > > Suggestion:
> > > The following is under the assumption that patch-versions of perl are
> > > compatible to each other. To solve the upgrade issue described above,
> > > add a few new options to the perl install command in the LFS book:
> > >  
> > > sh Configure -des \
> > > -Dprefix=/usr \
> > > -
> > > Dvendorprefix=/usr   \
> > > *   -Dprivlib=/usr/share/perl5/core_perl 
> > > \
> > > *   -Darchlib=/usr/lib/perl5//core_perl \
> > > *   -
> > > Dsitelib=/usr/share/perl5/site_perl \
> > > *   -
> > > Dsitearch=/usr/lib/perl5//site_perl \
> > > *   -
> > > Dvendorlib=/usr/share/perl5/vendor_perl \
> > > *   -
> > > Dvendorarch=/usr/lib/perl5//vendor_perl \
> > > -
> > > Dman1dir=/usr/share/man/man1 \
> > > -Dman3dir=/usr/share/man/man3 \
> > > -
> > > Dpager="/usr/bin/less -isR"  \
> > > -Duseshrplib  \
> > > -
> > > Dusethreads
> > > 
> > > assuming that we have in packages.ent:
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  > > minor;.">
> > > 
> > > This will produce a directory structure:
> > > 
> > > /usr
> > >   /lib
> > > /perl5
> > >   /5.30
> > > /core_perl
> > >   /...
> > > /site_perl
> > >   /...
> > > 
> > > where modules are installed under /usr/lib/perl5/5.30/site_perl/ . In
> > > this case, overwriting the installed perl with a newer one has no
> > > effect on the installed modules unless minor or even major version of
> > > perl > 
> > 
> > Sounds nice.  But just to be clear - under site_perl I have a
> > versioned directory (e.g. 5.30.2 for your current example).  I
> > assume, or hope, that will either be 5.30 or completely omitted.
> 
> This versioned subdir will be omitted completely. Files from
> XML::Parser are installed as
> 
> usr/lib/perl5/5.30/site_perl/auto
> usr/lib/perl5/5.30/site_perl/auto/XML
> usr/lib/perl5/5.30/site_perl/auto/XML/Parser
> usr/lib/perl5/5.30/site_perl/auto/XML/Parser/.packlist
> usr/lib/perl5/5.30/site_perl/auto/XML/Parser/Expat
> usr/lib/perl5/5.30/site_perl/auto/XML/Parser/Expat/Expat.so
> usr/lib/perl5/5.30/site_perl/XML
> usr/lib/perl5/5.30/site_perl/XML/Parser
> usr/lib/perl5/5.30/site_perl/XML/Parser/Encodings
> usr/lib/perl5/5.30/site_perl/XML/Parser/Style
> usr/lib/perl5/5.30/core_perl
> usr/lib/perl5/5.30/core_perl/perllocal.pod
> 
> net-ssleay installs as
> 
> ...
> usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/randomize.al
> usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/do_httpx2.al
> usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/put_https3.al
> usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/do_https3.al
> usr/lib/perl5/5.30/site_perl/Net
> usr/lib/perl5/5.30/site_perl/Net/SSLeay.pod
> usr/lib/perl5/5.30/site_perl/Net/SSLeay
> usr/lib/perl5/5.30/site_perl/Net/SSLeay/Handle.p

Re: [lfs-dev] Some comments on the test results.

[Ken Moffat via lfs-dev]

On Fri, Jun 19, 2020 at 07:46:54PM +0100, Ken Moffat via lfs-dev wrote:
> On Fri, Jun 19, 2020 at 06:58:42PM +0200, Pierre Labastie via lfs-dev wrote:
> > On Fri, 2020-06-19 at 16:26 +0100, Ken Moffat via lfs-dev wrote:
> > > I've now been through my test logs for the new build (on my i7
> > > haswell).
> > > 
> > > Here are a few comments (in order of testing)
> > > 

An update on ONLY my gcc test results.

> > > 
> > > gcc-10.1.0
> > > --
> > > 
> > > I seem to be getting rather more failures than the book implies,
> > > although I don't think they are either serious or unexpected.
> > > 
> > > First, 14 failures i nthe torture test, variants of
> > > FAIL: gcc.c-torture/compile/limits-exprparen.c
> > 
> > Isn't it the one that fails when ulimit is not increased?
> > 
> 
> Maybe.  I'm increasing the ulimit as root, then running the test as
> 'tester', which matches the book.  Again, my build of trunk from
> 20200603 didn't fail these, but cross-chap5 from that date did.
> 

Pierre later commented about CFLAGS.  That turned out to be the
cause of all the failures in the torture tests: with just -O3 in the
CFLAGS and CXXFLAGS that batch of tests fail.  With -O2 and
optionally -march=native -fstack-clash-protection
-fstack-protector-strong and (for CXX) -D_GLIBCXX_ASSERTION those
tests pass.

So, from now on I'm dropping back to -O2 for building gcc.  I've
uploaded a new Errata-2.txt to my tuning notes.
> > > 
> > > Second, as wel las the 6 locale/get_time test failures I also had
> > > FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
> > > FAIL: 22_locale/numpunct/members/char/3.cc execution test
> > 
> > Never seen those ones
> > 

On my limited series of gcc-10 builds (one from trunk which turned
out to not have any added CFLAGS because I'd borked the name of the
file containing them, three builds of cross-chap5 and new trunk)
the 20_util/unsynchronized_pool_resource/allocate.cc failure is not
consistent.

And on one build there was some other failure, whcih perhaps
implies the testsuite is "variable".

But 22_locale/numpunct/members/char/3.cc always fails for me.

Looking at the test,
libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc
it starts

// { dg-require-namedlocale "nl_NL.ISO8859-15" }

and a bit later it says

  // nl_NL chosen because it has no thousands separator (at this time).
  locale loc_it = locale(ISO_8859(15,nl_NL));

(apparently it was originally using an italian locale, then changed)

Now in theory I have all the locales on this system.  My log from
glibc for nl_NL shows:

nl_NL.ISO-8859-1... done
nl_NL.ISO-8859-15@euro... done
nl_NL.UTF-8... done

I have no idea how locales work in expect, but my normal quick test
for a locale is to use 'LC_ALL=someting date' and there I find that
only nl_NL and nl_NL.UTF-8 work, the rest give me english:

ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15@euro date
Sat Jun 20 13:12:21 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-1 date
Sat Jun 20 13:12:29 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15 date
Sat Jun 20 13:13:35 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15@euro date
Sat Jun 20 13:13:41 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL.UTF-8 date
za 20 jun 2020 13:13:53 BST
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL date
za 20 jun 2020 13:14:40 BST

Now, that seems to be the only nl_NL.ISO8859-15 test, but there are
a lot which require de_DR.ISO8859-15, several for fr_FR.ISO8859-15
and one for it_IT-ISO8859-15.

I wondered if some of these might now fall into 'unsupported' (there
doesn't seem to be any easy way of identifying what is in that), but
my number of unsupported tests seems consistent at 344 in al lthe
builds so I ended up clueless about why that test only fails for me.
The test data seems to get deleted during the run, but the test is
apparently comparing the result to an empty string, so probably a
thousands separator was returned.

Interestingly, wikipedia suggests that the Netherlands uses a dot
'.' as the separator https://en.wikipedia.org/wiki/Decimal_separator
(in Examples of use, the entry for 1.234.567,89) and
https://www.freeformatter.com/netherlands-standards-code-snippets.html#numericformats
agrees that the grouping character is the dot.  on that basis I
expect this test to fail for everyone!

if the test is to pass, I guess (from wikipedia) that de_DE might
work - but since it apparently doesn't fail for everyone I might
again be barking up completely the wrong tree.

ĸen
-- 
   He died at the console, of hunger and thirst.
   Next day he was buried, face-down, nine-edge first.
  - the perfect programmer
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] perl install options

[Ken Moffat via lfs-dev]

On Sat, Jun 20, 2020 at 07:05:24AM -0700, Joel Bion via lfs-dev wrote:
> Upgrading Perl was the trigger for me building my own package dependency 
> tracker utility. With tons of manual configuration, I am able to upgrade any 
> subset of packages at one time. It tells me what I need to rebuild, in what 
> order. Some packages trigger no or few rebuilds. Others, like OpenSSL, 
> trigger a few dozen. Python 3 might trigger 100. Perl is crazy; it triggers 
> 100s.
> 
> Each package has a build script I’ve written. If I ever get around to it, 
> I’ll make it generate a super-script that involves unpacking the tar files, 
> so I can just automate the whole build.
> 
> Sent from my iPhone
> 
I won't complain about top-posting in the light of that last line!

You must build a _lot_ more than I do: I've got several non-book
perl modules which I sometimes build, and there are a few modules in
the book which I never build, but in the perl directory of my
scripts I only have 150 modules.

For python, I haven't counted recently (they only should need to be
rebuilt when the minor version changes, I believe).

And for openssl I don't rebuild anything if the version (without the
letter) has not changed, e.g. 1.1.f to 1.1.1g.  But I do stop and
start anything which is running and linked to the old version.   I
normally echo this as one long line at the end of my script, with a
message to copy and paste it to see what needs to be bounced:

grep -l  -e 'libssl.*deleted' -e 'libcrypto.*deleted' /proc/*/maps |
 tr -cd 0-9\\\n | xargs -r ps u

ĸen
-- 
   He died at the console, of hunger and thirst.
   Next day he was buried, face-down, nine-edge first.
  - the perfect programmer
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] perl install options

[Ken Moffat via lfs-dev]

On Sat, Jun 20, 2020 at 02:42:03PM +0200, Thomas Trepl via lfs-dev wrote:
> Hi all,
> 
> this is about hte configuration options of perl.
> 
> Problem:
> whenever perl is upgraded to a newer version (for example 5.30.2 to
> 5.30.3), all perl modules needs to be reinstalled as the current
> configuration of perl forces a directory structure like
> 
> /usr
>   /lib
> /perl5
>   /5.30.2
> /...
>   /site_perl
> 
> All modules are installed under /usr/lib/perl5/5.30.2 . Now, when
> installing a newer patch-version by overwriting the existing one, the
> structure looks like
> 
> /usr
>   /lib
> /perl5
>   /5.30.2
> /...
>   /5.30.3
> /...
>   /site_perl
> 
> The 5.30.2-directory (which includes the modules) is more or less
> garbage as the new perl will use 5.30.3. Therefore, any installed
> module must be reinstalled to appear in the 5.30.3 structure.
> 
> This all is not really a problem as long as the system is completely
> built from scratch and all modules are installed freshly. For those
> who uses some kind of pkgmnr or upgrade the system package by package
> it might be a problem when perl is about to upgrade.
> 

Yes, for my own systems I have had to rebuild all the modules if
upgrading perl.

> Suggestion:
> The following is under the assumption that patch-versions of perl are
> compatible to each other. To solve the upgrade issue described above,
> add a few new options to the perl install command in the LFS book:
>  
> sh Configure -des \
> -Dprefix=/usr \
> -
> Dvendorprefix=/usr   \
> *   -Dprivlib=/usr/share/perl5/core_perl 
> \
> *   -Darchlib=/usr/lib/perl5//core_perl \
> *   -
> Dsitelib=/usr/share/perl5/site_perl \
> *   -
> Dsitearch=/usr/lib/perl5//site_perl \
> *   -
> Dvendorlib=/usr/share/perl5/vendor_perl \
> *   -
> Dvendorarch=/usr/lib/perl5//vendor_perl \
> -
> Dman1dir=/usr/share/man/man1 \
> -Dman3dir=/usr/share/man/man3 \
> -
> Dpager="/usr/bin/less -isR"  \
> -Duseshrplib  \
> -
> Dusethreads
> 
> assuming that we have in packages.ent:
> 
> 
> 
> 
> 
>  minor;.">
> 
> This will produce a directory structure:
> 
> /usr
>   /lib
> /perl5
>   /5.30
> /core_perl
>   /...
> /site_perl
>   /...
> 
> where modules are installed under /usr/lib/perl5/5.30/site_perl/ . In
> this case, overwriting the installed perl with a newer one has no
> effect on the installed modules unless minor or even major version of
> perl > 

Sounds nice.  But just to be clear - under site_perl I have a
versioned directory (e.g. 5.30.2 for your current example).  I
assume, or hope, that will either be 5.30 or completely omitted.

i.e. /usr/lib/perl5/5.30/site_perl/5.30/ or
/usr/lib/perl5/5.30/site_perl/ for the directory where 'top level'
modules SGMLS.pm and URI.pm live ?

> A note to "make install" might be required as perl refuses to
> overwrite an installation in case of an version mismatch (which makes
> sense in case of incompatible version, maybe when minor or major
> version changes). To overcome this, a
> mv /usr/bin/perl{,.old}
> can be executed before doing the install.
> 
> As far as i have seen, there is no change required for BLFS except one
> textual adjustment in the "Perl Modules" page. 
> 
> All comments, suggestions, tomatos and eggs are welcome!
> Is there something i have completely overseen?
> 

For plain perl modules in site_perl this sounds like a no-brainer.
A quick look at .so files installed under x86_64-linux-thread-multi
suggests that the site_perl files (e.g. from ImageMagick) do not
link to perl libs, so should be ok, and the many core .so files seem
(from a brief look at one or two) to only link to libc, vdso and
ld-linux - in any case, the core files will be overwritten by the
upgrade of perl.

If a module is dropped from core perl, I suppose that will leave the
old core module in place.

Overall, I think it might be worth trying (I've had so much pain
from perl over the years that I don't really believe there is such a
thing as a free lunch, and my first semi-supported version with this
would be LFS-10.0 so I won't actually find out for some months if
the approach lives up to expectations).

ĸen
-- 
   He died at the console, of hunger and thirst.
   Next day he was buried, face-down, nine-edge first.
  - the perfect programmer
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Some comments on the test results.

[Ken Moffat via lfs-dev]

On Fri, Jun 19, 2020 at 01:14:01PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/19/20 11:58 AM, Pierre Labastie via lfs-dev wrote:
> > On Fri, 2020-06-19 at 16:26 +0100, Ken Moffat via lfs-dev wrote:
> > > I've now been through my test logs for the new build (on my i7
> > > haswell).
> > > 
> > > Here are a few comments (in order of testing)
> 
> > > bison-3.6.3
> > > ---
> > > 
> > > Here, I strongly disagree that the tests need to be run with -j1.
> > > 
> > > On my i3 Skylake last December I had to use -j1 to get the package
> > > to compile, and therefore I also used -j1 on that machine if I ran
> > > the tests.  But on other machines I'm using -j8 both for the compile
> > > and for the tests (and no failures).
> > 
> > Could be changed I guess
> 
> I added that because at -j22 the tests failed but passed at -j1.
> 
> I suppose I could test again at -j8.  -j1 is slooow.  On my last test build
> bison was about twice as long as the next longest package.  I'll note that I
> did not run tests on most packages, but only the ones I was updating at the
> time, but is was still longer than gcc without tests.
> 
LOL.

ĸen
-- 
   He died at the console, of hunger and thirst.
   Next day he was buried, face-down, nine-edge first.
  - the perfect programmer
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Some comments on the test results.

[Ken Moffat via lfs-dev]

On Fri, Jun 19, 2020 at 06:58:42PM +0200, Pierre Labastie via lfs-dev wrote:
> On Fri, 2020-06-19 at 16:26 +0100, Ken Moffat via lfs-dev wrote:
> > I've now been through my test logs for the new build (on my i7
> > haswell).
> > 
> > Here are a few comments (in order of testing)
> > 
> > glibc-2.31.0
> > 
> > 
> > We say "misc/tst-ttyname is known to fail in the LFS chroot
> > environment."  But for me it was skipped (I'm running a 5.7.2
> > kernel, with 5.7.2 headers and 5.7 iproute2).
> > 
> > But my log says
> > 5102 PASS
> >   44 UNSUPPORTED
> >   16 XFAIL
> >2 XPASS
> > 
> > And misc/tst-ttyname is now among the unsupported -
> > UNSUPPORTED: misc/tst-ttyname
> 
> I have quite different results (was with 5.6.15 kernel and headers, and
> iproute2-5.6):
>   1 FAIL
>5177 PASS
>  22 UNSUPPORTED
>  17 XFAIL
>   2 XPASS
> 
> with
> FAIL: misc/tst-ttyname
> 
> I cannot tell why it has run more tests for me than for you (I mean the
> 22 less UNSUPPORTED cannot explain the 75 more PASS)
> 
> Note that in a VM with an old debian 8 system (kernel 3.16), I have 24
> UNSUPPORTED and 5175 PASS, otherwise identical.
> 

Strange, but I'll have to accept it does fail.  On this machine
using cross-chap5-2020513 I got the same results as in the current
build.  And on cross-chap5-20200603 on a ryzen.

BUT - on a different ryzen, using _trunk_ from 20200603 my results
match your.
> > 
> > I'm also now wondering about the comment on the rt/tst-cputimer
> > tests.  I don't have any systems running kernels older than 5.4, but
> > the detail suggests that "mid-period" 4.14 and 4.19 stable kernels,
> > as well as some or all of 4.20, failed here.  Could we not just say
> > that some kernels before linux-5.0 cause these tests to fail ?
> 
> Don't remember, so I trust you. This test passed on the 3.16 debian
> kernel, though. But some fixes may have been backported.
> 

I really don't remember either, but mentioning 4.20 kernels looks a
bit messy (they haven't been maintained in ages) and I think
less-specific wording should calm users who either build on very old
LFS versions where they have never updated their kernel, or on
ubuntu who I believe are doing their own maintenance for 4.15.
> > 
> > gcc-10.1.0
> > --
> > 
> > I seem to be getting rather more failures than the book implies,
> > although I don't think they are either serious or unexpected.
> > 
> > First, 14 failures i nthe torture test, variants of
> > FAIL: gcc.c-torture/compile/limits-exprparen.c
> 
> Isn't it the one that fails when ulimit is not increased?
> 

Maybe.  I'm increasing the ulimit as root, then running the test as
'tester', which matches the book.  Again, my build of trunk from
20200603 didn't fail these, but cross-chap5 from that date did.

Very strange, looks as if maybe _I_ lost something in the change
(well, I know I already lost several things in the change - fixes in
one branch of my scripts but not in the other, but most of those
were for BLFS).
> > 
> > Second, as wel las the 6 locale/get_time test failures I also had
> > FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
> > FAIL: 22_locale/numpunct/members/char/3.cc execution test
> 
> Never seen those ones
> 

I had both on the 20200603 cross-chap5 (along with a couple of
others I've not seen before or since), on the 20200603 trunk I also
had the 'numpunct' failure.

> Most often, I have only the 6 22_locale/get_time failures on the
> Haswell or 64 bit VM's.
> 
> On the i686 VM, I had 13 errors for libstdc++, but not the same as the
> ones you report.
> 
> > 
> > bison-3.6.3
> > ---
> > 
> > Here, I strongly disagree that the tests need to be run with -j1.
> > 
> > On my i3 Skylake last December I had to use -j1 to get the package
> > to compile, and therefore I also used -j1 on that machine if I ran
> > the tests.  But on other machines I'm using -j8 both for the compile
> > and for the tests (and no failures).
> 
> Could be changed I guess
> 
> > 
> > python-3.8.3
> > 
> > 
> > "The test named test_normalization fails because network
> > configuration is not completed yet."  I assume that the work on
> > /etc/hosts has solved this, I have:
> > 
> > 0:01:42 load avg: 6.94 [369/423] test_normalization passed --
> > running: test_concurrent_futures (1 min 38 sec),
> > test_multiprocessing_spawn (1 min 33 sec)
> &

[lfs-dev] Some comments on the test results.

[Ken Moffat via lfs-dev]

I've now been through my test logs for the new build (on my i7
haswell).

Here are a few comments (in order of testing)

glibc-2.31.0


We say "misc/tst-ttyname is known to fail in the LFS chroot
environment."  But for me it was skipped (I'm running a 5.7.2
kernel, with 5.7.2 headers and 5.7 iproute2).

But my log says
5102 PASS
  44 UNSUPPORTED
  16 XFAIL
   2 XPASS

And misc/tst-ttyname is now among the unsupported -
UNSUPPORTED: misc/tst-ttyname

I'm also now wondering about the comment on the rt/tst-cputimer
tests.  I don't have any systems running kernels older than 5.4, but
the detail suggests that "mid-period" 4.14 and 4.19 stable kernels,
as well as some or all of 4.20, failed here.  Could we not just say
that some kernels before linux-5.0 cause these tests to fail ?

gcc-10.1.0
--

I seem to be getting rather more failures than the book implies,
although I don't think they are either serious or unexpected.

First, 14 failures i nthe torture test, variants of
FAIL: gcc.c-torture/compile/limits-exprparen.c

Second, as wel las the 6 locale/get_time test failures I also had
FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
FAIL: 22_locale/numpunct/members/char/3.cc execution test


bison-3.6.3
---

Here, I strongly disagree that the tests need to be run with -j1.

On my i3 Skylake last December I had to use -j1 to get the package
to compile, and therefore I also used -j1 on that machine if I ran
the tests.  But on other machines I'm using -j8 both for the compile
and for the tests (and no failures).

python-3.8.3


"The test named test_normalization fails because network
configuration is not completed yet."  I assume that the work on
/etc/hosts has solved this, I have:

0:01:42 load avg: 6.94 [369/423] test_normalization passed -- running: 
test_concurrent_futures (1 min 38 sec), test_multiprocessing_spawn (1 min 33 
sec)

and at the end it reported SUCCESS before listing the skipped tests.

acl-2.2.53 (tested after coreutils)
--

In the past I'd assumed that the two failures I was seeing
[test/root/permissions.test and test/root/setfacl.test ] were because
I didn't use ACLs (although ext4 supports them), but that was
probably a mistaken assumption.  Anyway, now I don't have any
failures in acl.

util-linux-2.35.2
-

I have to admit that this is my first build with this version, I'd
managed to miss the change to it.  I see that we use 'make -k check'
in the expectation that things may fail.  And I do get one failure:

FAILED (column/invalid-multibyte)

ISTR that has happened in the past, and I had the impression that
the cross- changes had fixed it, but maybe I'm mistaken.

ĸen
-- 
   He died at the console, of hunger and thirst.
   Next day he was buried, face-down, nine-edge first.
  - the perfect programmer
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Stripping Again: loss of suid on some files

[Ken Moffat via lfs-dev]

On Wed, Jun 17, 2020 at 03:48:07PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/17/20 3:36 PM, Ken Moffat via lfs-dev wrote:
> 
> > On this build, after misreading 'stripping' earlier in the book (and
> > trashing the partial system by running it from within chroot) I had
> > to start over.  So, before trying 'stripping again' I exited,
> > unmounted, copied everything, then remounted before trying
> > 'stripping again'.
> > 
> > I guess that means I can look at the backup to confirm that
> > stripping again did change the perms.  Will do that later.
> > Meanwhile, thanks for the correction for wall.
> 
> Hmm.  You did do the backup as root, right.
> 
> Doing a tar or cp as a regular user can change permissions.
> 
>   -- Bruce
> 
Yes, I learned that a long while ago :)

This time, as root (I open a term and su so that I can mkfs, mount,
chown to lfs, then keep that open e.g. to copy the bzImage to the
host system's /boot) I umounted everything which mount|grep|awk
showed had /mnt/lfs as its third field, then I remounted only
/mnt/lfs and used cp -a.

After that I mounted the sources and logs, and then used my normal
(updated for cross) script to enter chroot, then tried adding
stripping-again to my chroot script and running that.

Now that I've looked at the copy, everything was good at that point
(only three listed, for brevity) -

~$ ls -l /scratch/lfs/bin/su /scratch/lfs/usr/bin/{newgrp,wall}
-rwsr-xr-x 1 root root 74128 Jun 16 23:34 /scratch/lfs/bin/su
-rwsr-xr-x 1 root root 45728 Jun 16 23:34
/scratch/lfs/usr/bin/newgrp
-rwxr-sr-x 1 root tty  43176 Jun 17 01:54 /scratch/lfs/usr/bin/wall

My eventual reply on -support showed that /bin/su had been updated
at a later time, and that time matched when I ran stripping again.

ĸen
-- 
   He died at the console, of hunger and thirst.
   Next day he was buried, face-down, nine-edge first.
  - the perfect programmer
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Stripping Again: loss of suid on some files

[Ken Moffat via lfs-dev]

On Wed, Jun 17, 2020 at 09:46:16PM +0200, Pierre Labastie via lfs-dev wrote:
> On Wed, 2020-06-17 at 19:55 +0100, Ken Moffat via lfs-dev wrote:
> 
> I just tried:
> sudo strip /bin/su.
> The size was reduced from 139512 to 41424 bytes, and it is still suid
> afterwards. Not sure what may explain what happened to you.
> 
> Do you have a special umask for root? (only thing I can think of; there
> is nothing about permissions in the man page for strip)
> 
> Pierre
> 
At this point, I don't think I have a special umask for root.

ĸen
-- 
   He died at the console, of hunger and thirst.
   Next day he was buried, face-down, nine-edge first.
  - the perfect programmer
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Stripping Again: loss of suid on some files

[Ken Moffat via lfs-dev]

On Wed, Jun 17, 2020 at 02:19:41PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/17/20 1:55 PM, Ken Moffat via lfs-dev wrote:
> > Bringing this here now that Scott Andrews has pointed me towards the
> > source of why users could not su on my new system: loss of suid.
> > 
> > In the past I have not usually run what was in 'Stripping Again'
> > because my CFLAGS drop debug information.  But I've now started to
> > allow that in elfutils (to get the tests to pass), so I know that at
> > least those libs could be stripped.
> > 
> > What has happened on this build is that all of the bin programs lost
> > the suid bit, i.e.
> > 
> > /bin/{mount,ping,ping6,su,umount}
> > /usr/bin/{chage,chfn,chsh,expiry,gpasswd,newgidmap}}
> > /usr/bin/{newgidmap,newgrp,newuidmap,passwd,wall}
> > 
> > Since nobody else has reported this for the moment, I'm merely
> > reporting iti, not attempting to fix the book.  In my own script for
> > Stripping Again I've now added
> > 
> > chmod -v 4755 /bin/{mount,ping,ping6,su,umount}
> > chmod -v 4755 /usr/bin/{chage,chfn,chsh,expiry,gpasswd}
> > chmod -v 4755 /usr/bin/{newgidmap,newgrp,newuidmap,passwd}
> > chmod -v 6755 /usr/bin/wall
> 
> All the files in the above match those permissions without doing anything
> different from the book on my system.  I did build the system manually.
> 
> One exception, wall, has permissions 2755 (-rwxr-sr-x with group tty).
> 
>   -- Bruce

I'm not at the desktops at the moment, I'll assume 2755 IS the
correct value: I was looking at a cross-chap5 system, the
highlighting (orange? background) was different from the others and
I noticed the gid.  Certainly, group tty.

On this build, after misreading 'stripping' earlier in the book (and
trashing the partial system by running it from within chroot) I had
to start over.  So, before trying 'stripping again' I exited,
unmounted, copied everything, then remounted before trying
'stripping again'.

I guess that means I can look at the backup to confirm that
stripping again did change the perms.  Will do that later.
Meanwhile, thanks for the correction for wall.

ĸen
-- 
   He died at the console, of hunger and thirst.
   Next day he was buried, face-down, nine-edge first.
  - the perfect programmer
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Stripping Again: loss of suid on some files

[Ken Moffat via lfs-dev]

Bringing this here now that Scott Andrews has pointed me towards the
source of why users could not su on my new system: loss of suid.

In the past I have not usually run what was in 'Stripping Again'
because my CFLAGS drop debug information.  But I've now started to
allow that in elfutils (to get the tests to pass), so I know that at
least those libs could be stripped.

What has happened on this build is that all of the bin programs lost
the suid bit, i.e.

/bin/{mount,ping,ping6,su,umount}
/usr/bin/{chage,chfn,chsh,expiry,gpasswd,newgidmap}}
/usr/bin/{newgidmap,newgrp,newuidmap,passwd,wall}

Since nobody else has reported this for the moment, I'm merely
reporting iti, not attempting to fix the book.  In my own script for
Stripping Again I've now added

chmod -v 4755 /bin/{mount,ping,ping6,su,umount}
chmod -v 4755 /usr/bin/{chage,chfn,chsh,expiry,gpasswd}
chmod -v 4755 /usr/bin/{newgidmap,newgrp,newuidmap,passwd}
chmod -v 6755 /usr/bin/wall

Which should ensure that all the suid binaries are correct after
stripping.

ĸen
-- 
   He died at the console, of hunger and thirst.
   Next day he was buried, face-down, nine-edge first.
  - the perfect programmer
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Future for LFS

[Ken Moffat via lfs-dev]

On Mon, Jun 15, 2020 at 09:25:04PM +0900, Akira Urushibata via lfs-dev wrote:
> On Sat, 13 Jun 2020 Pierre Labastie wrote:
> 
> > the problem is not lfs, but blfs. There are around 750 packages in
> > there. If those packages are all updated twice a year (some have
> > much more frequent updates...), it makes 4 updates per day, 7/7.
> > Updates mean: get the source, check it is right (gpg signatures,
> > whatever), update size and md5. Build and test it, analyze and
> > restart when something gets wrong (very often, the instructions for
> > one version have to be changed for the next one), measure and update
> > sbu and disk usage, do a "DESTDIR" install to check new installed or
> > not installed files and dirs. Update the xml, publish. Also check
> > that dependent packages still build (not always done, actually, but
> > it means that full builds of blfs must be run from times to
> > times). Most of this cannot be automated because of the diversity in
> > upstream sources and build systems.
> 
> I don't think all the above is necessary for ARM-BLFS.  Judging from
> Pi-LFS most packages should build without special adjustments.  There
> is no difference in the source package location, MD5 sum and
> dependencies.  There is little need for a separately measured
> SBU.
> 
> So for most packages I think that stating that the instructions
> have been tested on ARM in addition to x86-32 and x86-64 and are
> known to work would suffice.
> 

I have no experience of using Arm, and I don't know of any Arm
machines which would appeal to me for compiling software - I've seen
one recent review of an aarch64 machine configured as a desktop box at
phoronix, but it was expensive and mostly a lot slower than
similarly-priced x86_64 machines.  And I suspect that what works on
32-bit ARM might be different from what works on 64-bit.

But more generally - I don't think anyone deliberately breaks
packages for current releases, but strictly the "works on LFS-9.1"
tags are for the then-current version.

Tagging what parts of BLFS work on a different architecture is never
going to be up to date unless BLFS moves to support diverse
architectures - but then it would be like gentoo (various different
versions marked as 'stable' on different architectures) or CLFS
(my memory says that random packages in their wiki had
different versions or different instructions for different
architectures, but of course some of that was for multilib - was it
MIPS which had _three_ architectures?).

Needs a LOT of developers, and less churn of package versions (in
some ways that might be a good thing, with updates not public until
thoroughly tested, but a big problem when serious vulnerabilities
appear).

> A dependency matrix for BLFS and some amount of build automation would
> be nice.  The 750 packages are not equally important; there should be
> some mechanism to determine which ones have priority.
> 

But what I, you, and anyone else regard as high-priority will
inevitably be different things.  For example, on my home server I
only regard apache and its deps, git and the mail packages I use, as
high-priority.  Oh, and ssl/ssh.

And on desktops we try to support a wide range of packages - there
are many in the book which I have either never built, or have
stopped building.  But people who use gnome (in either book) or kde
will have very different cares from mine.

> By the way translation is a different story.  One person has been
> working on translating LFS and BLFS into Japanese and he says he
> can't keep up with BLFS.
> 

Arguably, it's the same story - needs more people.  The overriding
problem is the churn of new package versions, many of which end up
with modified instructions or dependencies.

I suppose that the (LFS) translators will not be overjoyed by LFS
moving to cross2, and will appreciate help when that happens.  But
everyone has limited time, and it's best to use time for what the
individual cares about.

ĸen
-- 
So it's not 'I think, therefore I am', it's 'The computer thinks,
therefore I think I am'.  I've never actually thought about that
before. -- Rimmer (a hologram), Red Dwarf, 'The Promised Land'
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Odd failure to make the book : sorted

[Ken Moffat via lfs-dev]

On Sat, Jun 13, 2020 at 02:05:12AM +0100, Ken Moffat wrote:
> On Fri, Jun 12, 2020 at 07:39:39PM -0500, Bruce Dubbs via lfs-dev wrote:
> > On 6/12/20 7:14 PM, Ken Moffat via lfs-dev wrote:
> > > I've been updating my local copy of cross2, and creating that book,
> > > without noticing any obvious problems.  But before I attempt to
> > > check my scripts agaisnt it I thought I'd better ensure that my copy
> > > of trunk (from which I update package versions etc) was up to date.
> > > 
> > > It seems to be, but buildign the book errors -
> > > 
> > > ken@llamedos ~/repos/LFS/trunk/BOOK $make
> > > Creating and cleaning /home/ken/tmp
> > > Processing bootscripts...
> > > Adjusting for revision sysv...
> > > Validating the book...
> > > Validation complete.
> > > Generating profiled XML for XHTML...
> > > Generating chunked XHTML files at ~/lfs-book/ ...
> > > Copying CSS code and images...
> > > mkdir: cannot create directory ‘/home/ken/lfs-book’: File exists
> > > make: *** [Makefile:41: book] Error 1
> > > 
> > > Any ideas, please ?
> > 

Local error.  Before I noticed that cross2 used its own BASEDIR, I
had set my symlink to the book to point to a cross2 directory in the
area from where I locally serve the books (similar to what I'd been
doing for cross-chap5).

I removed that directory because the symlink had the wrong name for
what is now in the BASEDIR of cross2, but I did not recreate the
(regular) symlink pointing to my normal LFS directory (I thought I
had done that).

So, BASEDIR was a dangling symlink to a non-existent directory.

Sorry for the noise.

ĸen
-- 
+++ OUT OF CHEESE ERROR. REDO FROM START +++
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Odd failure to make the book

[Ken Moffat via lfs-dev]

On Fri, Jun 12, 2020 at 07:39:39PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/12/20 7:14 PM, Ken Moffat via lfs-dev wrote:
> > I've been updating my local copy of cross2, and creating that book,
> > without noticing any obvious problems.  But before I attempt to
> > check my scripts agaisnt it I thought I'd better ensure that my copy
> > of trunk (from which I update package versions etc) was up to date.
> > 
> > It seems to be, but buildign the book errors -
> > 
> > ken@llamedos ~/repos/LFS/trunk/BOOK $make
> > Creating and cleaning /home/ken/tmp
> > Processing bootscripts...
> > Adjusting for revision sysv...
> > Validating the book...
> > Validation complete.
> > Generating profiled XML for XHTML...
> > Generating chunked XHTML files at ~/lfs-book/ ...
> > Copying CSS code and images...
> > mkdir: cannot create directory ‘/home/ken/lfs-book’: File exists
> > make: *** [Makefile:41: book] Error 1
> > 
> > Any ideas, please ?
> 
> You are in trunk, not cross2.
> 

Yeah, sorry if my wording was not clear - I came back to trunk to
check that what I was looking at i nthe local rendering was up to
date.

> I don't know where that mkdir is coming from.  All the instances in the
> Makefile use -p for mkdir.
> 
> The line after Copying CSS should be Running Tidy.
> 
> 
>@echo "Copying CSS code and images..."
>$(Q)mkdir -p $(BASEDIR)/stylesheets
>$(Q)cp stylesheets/lfs-xsl/*.css $(BASEDIR)/stylesheets
>$(Q)pushd $(BASEDIR)/ > /dev/null; \
> #   sed -i -e "s@../stylesheets@stylesheets@g" *.html; \
>popd > /dev/null
> 
>$(Q)mkdir -p $(BASEDIR)/images
>$(Q)cp images/*.png $(BASEDIR)/images
> 
>@echo "Running Tidy and obfuscate.sh..."
> 
> We probably should remove the three pushd...popd lines.
> 
> Is your Makefile different?
> 
>   -- Bruce

According to svn my Makefile appears to match the book (i.e. no
changes outstanding.)

The weird thing is that the Makefile in cross2 is almost identical,
and completes without error.  And my Makefile in trunk has not
changed since March 13th.

Will sleep on it.

ĸen
-- 
+++ OUT OF CHEESE ERROR. REDO FROM START +++
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Odd failure to make the book

[Ken Moffat via lfs-dev]

I've been updating my local copy of cross2, and creating that book,
without noticing any obvious problems.  But before I attempt to
check my scripts agaisnt it I thought I'd better ensure that my copy
of trunk (from which I update package versions etc) was up to date.

It seems to be, but buildign the book errors -

ken@llamedos ~/repos/LFS/trunk/BOOK $make
Creating and cleaning /home/ken/tmp
Processing bootscripts...
Adjusting for revision sysv...
Validating the book...
Validation complete.
Generating profiled XML for XHTML...
Generating chunked XHTML files at ~/lfs-book/ ...
Copying CSS code and images...
mkdir: cannot create directory ‘/home/ken/lfs-book’: File exists
make: *** [Makefile:41: book] Error 1

Any ideas, please ?

ĸen
-- 
+++ OUT OF CHEESE ERROR. REDO FROM START +++
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] User 'tester' : why is the uid 1000 ?

[Ken Moffat via lfs-dev]

On Sat, Jun 06, 2020 at 11:55:01PM +0100, Ken Moffat via lfs-dev wrote:
> On Sat, Jun 06, 2020 at 05:03:55PM -0500, Bruce Dubbs via lfs-dev wrote:
> > On 6/6/20 4:39 PM, Ken Moffat via lfs-dev wrote:
> > 
> > > Well, again thanks, but I'm not at all certain.  For example, the
> > > host system is the one where after its first boot I managed to run
> > > the 'check' tests without failures.  Now (normal desktop installed,
> > > but same kernel) the tests which raise sigfpe again fail.
> > 
> > You do a lot with different flags.  I only use them when absolutely
> > necessary.  I suspect your issues have something to do with that.
> > 
> 
> Seems likely - the host system, where sigfpe seemed to be raised ok
> when I tried it after the first boot, used -O2 in glibc (for glibc I
> drop the hardening flags), the current build(s) was/were partly
> intended to see if changing to '-O2 -march=native' was also ok.
> 
I've already replied on -support to the thread I started last month,
the root of the problem turns out to be rxvt-unicode which embeds
perl - and perl sets the SIGFPE handler to SIG_IGN.

On another machine, where I'm still using an older build with -O3 in
glibc, I've just installed xfce4-terminal.  If I run check's tests
in that, they all pass.  So, nothing to do with -O3 or hardening.

I'll add a note to rxvt-unicode in the book.

ĸen
-- 
+++ OUT OF CHEESE ERROR. REDO FROM START +++
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] User 'tester' : why is the uid 1000 ?

[Ken Moffat via lfs-dev]

On Sat, Jun 06, 2020 at 05:03:55PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/6/20 4:39 PM, Ken Moffat via lfs-dev wrote:
> 
> > Well, again thanks, but I'm not at all certain.  For example, the
> > host system is the one where after its first boot I managed to run
> > the 'check' tests without failures.  Now (normal desktop installed,
> > but same kernel) the tests which raise sigfpe again fail.
> 
> You do a lot with different flags.  I only use them when absolutely
> necessary.  I suspect your issues have something to do with that.
> 

Seems likely - the host system, where sigfpe seemed to be raised ok
when I tried it after the first boot, used -O2 in glibc (for glibc I
drop the hardening flags), the current build(s) was/were partly
intended to see if changing to '-O2 -march=native' was also ok.

But in general I'm much more interested in hardening, and I
typically force -O3 to try to cover some of the slowdown from that,
and -march=native to reduce overheads (i.e. use the best code for
the current CPU).

On a modern desktop there are always only-known-to-bad-guys
vulnerabilities, I prefer strength in depth (e.g. there have been
reports of vulnerabilities where some of the common hardening flags
mitigated the problem).

> Have you ever done any benchmarks comparing a build with and without your
> different flags?  If you are only changing installed space and/or execution
> time by a few percent then it seems that the benefit is not worth the
> effort.
> 

What I found when playing with variations of the flags last year was
that there seemed to be a large variation in build times, e.g. I
would expect a -O3 compile of a package to take longer than -O2, but
sometimes the converse was true (testing with one full build with
each set of flags, looking at build times for selected packages).

For some things, I agree that there is no time benefit (in fact
there is usually a time loss when comiling with higher
optimization).  But for reasonable hardware that is a price I'm
willing to pay (for my laptop and athlon 200ge used as a server, I
stick to -O2 with hardening).

> Even if a task takes two seconds and you have a 50% reduction to one second,
> is it really important?  A 10% reduction from an hour to 54 minutes is
> really not significant either unless you are doing that task continuously.
> 
>   -- Bruce

Time is no-longer the most important factor for me, although I'm
getting the impression that the current toolchains (both gcc and
clang) get slower with each release.

Thanks for the thoughts.

ĸen
-- 
+++ OUT OF CHEESE ERROR. REDO FROM START +++
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] User 'tester' : why is the uid 1000 ?

[Ken Moffat via lfs-dev]

On Sat, Jun 06, 2020 at 04:02:12PM -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/6/20 2:05 PM, Ken Moffat via lfs-dev wrote:
> > I can see that the tester user gets added by a command which uses
> >   ls -n $(tty)
> > and I now see that this results for me in a value of 1000.
> > 
> > What I don't understand is where that comes from.  On my systems
> > user 1000 happens to be the most important regular user (i.e. me)
> > and (after trying a build without noticing this would duplicate the
> > UID - I already set up my regular users on the way into chroot) I
> > eventually discovered that coreutils was trying to chown to ken.
> > 
> > So, before I try to use a number of my own choosing: is it important
> > to match $(tty) ?  I can see that /dev/tty1 where I'm logged in has
> > an id of 1000, as do the /dev/pts for the terms I'm using.
> 
> It is important for some tests.  Look at the permissions for
> 
> $ ls -l /dev/pts
> total 0
> crw--w 1 1000 tty  136, 0 Jun  6 15:51 0
> crw--w 1 1000 tty  136, 1 Jun  4 05:17 1
> 
> If the owner id doesn't match, then you can't read from the device.
> 

OK, thanks for that.  I've attempted to adapt my script to create my
normal user after chapter 6.  Emphasis on 'attempted' because a lot
of the changes I made in my scripts this week were botched.

> >  From memory, the book starts at user 1001 (some new-fangled change a
> > few years ago, too awkward to change all my files) - but would that
> > not mean that if I logged in as user 1001, ran startx (via elogind),
> > su, su lfs, the value would be 1001 in that case, and therefore I
> > would not be able to upload my user to /etc/passwd until LFS had
> > been completed ?
> 
> In the creating files section we have
> users:x:999:
> 
> And in shadow
> sed -i 's/1000/999/' etc/useradd
> 
> That sed makes /etc/default/useradd have 'GROUP=999'.  The combination makes
> the first user created by useradd have uid and gid values of 1000 instead of
> the default 1001.  Of course if 1000 is already in use, it uses the next
> numerical value not already used.
> 

Thanks, I must have mis-remembered that.

> > I'm increasingly starting to think that I'm not cut out for this.
> 
> Sure you are.  We are all continuously learning new things.
> 
>   -- Bruce
> 

Well, again thanks, but I'm not at all certain.  For example, the
host system is the one where after its first boot I managed to run
the 'check' tests without failures.  Now (normal desktop installed,
but same kernel) the tests which raise sigfpe again fail.

ĸen
-- 
+++ OUT OF CHEESE ERROR. REDO FROM START +++
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] User 'tester' : why is the uid 1000 ?

[Ken Moffat via lfs-dev]

I can see that the tester user gets added by a command which uses
 ls -n $(tty)
and I now see that this results for me in a value of 1000.

What I don't understand is where that comes from.  On my systems
user 1000 happens to be the most important regular user (i.e. me)
and (after trying a build without noticing this would duplicate the
UID - I already set up my regular users on the way into chroot) I
eventually discovered that coreutils was trying to chown to ken.

So, before I try to use a number of my own choosing: is it important
to match $(tty) ?  I can see that /dev/tty1 where I'm logged in has
an id of 1000, as do the /dev/pts for the terms I'm using.

From memory, the book starts at user 1001 (some new-fangled change a
few years ago, too awkward to change all my files) - but would that
not mean that if I logged in as user 1001, ran startx (via elogind),
su, su lfs, the value would be 1001 in that case, and therefore I
would not be able to upload my user to /etc/passwd until LFS had
been completed ?

I'm increasingly starting to think that I'm not cut out for this.

ĸen
-- 
+++ OUT OF CHEESE ERROR. REDO FROM START +++
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] A first new success in my cross-chap5 build

[Ken Moffat via lfs-dev]

On Tue, May 26, 2020 at 04:12:37AM +0100, Ken Moffat via lfs-dev wrote:
> On Tue, May 19, 2020 at 03:16:51AM +0100, Ken Moffat via lfs-dev wrote:
> 
> iproute2-5.6.0 -
> 
> We say: This package does not have a working test suite.
> 
> I do not yet have a view on whether or not that is correct.  It
> certainly requires libmna, so I have installed that on this build
> (but won't be installing it in the future), but then it failed
> because sudo was missing.  It wanted sudo to run 'rmmod'!
> 

Now that the new system has booted and is somewhat usable (built as
far as firefox), I have to admit that the testsuite does not work.

Trying first as my own normal user,

not allowed to execute /usr/bin/unshare -n tests/bridge/vlan/tunnelshow.t' as 
root on plexi.

That PASSed on failure

not allowed to execute '/bin/dmesg' as root on plexi.
make[1]: *** [Makefile:68: bridge/vlan/tunnelshow.t] Error 1
make: *** [Makefile:110: check] Error 2


Retrying as user root:

every test errors with   unshare: unshare failed: Invalid argument
but then reports PASS

ĸen
-- 
Do you not know that, what you belittle by the name tree is but the
mere four-dimensional analogue of a whole multidimensional universe
which - no, I can see you do not.  -- Druellae (a Dryad)
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] A first new success in my cross-chap5 build

[Ken Moffat via lfs-dev]

On Tue, May 19, 2020 at 03:16:51AM +0100, Ken Moffat via lfs-dev wrote:
> 
> But now I'm running in chroot I'm looking at each testsuite in the
> hope that I can get everything to complete (brief note - glibc no
> failures on my haswell).

And now, the full results of the testsuites - a couple of these seem
to have failures that I'm the only one seeing, or maybe everyone
else has just learned to keep quiet about failures ;-)

This build is nominally LFS from 20200513, on my i7 haswell.
Unfortunately, it is long.

Where we have noted problems with testsuites, I've tried to see if
they can be made to work.  Unfortunately, I did not always succeed.
If we say there is no testsuite, I accepted that.

Also, these are normally with my own CFLAGS,CXXFLAGS and hardening:
 -O3 -march=native -D_FORTIFY_SOURCE=2 -fstack-protector-strong
 -D_GLIBCXX_ASSERTIONS although where I was still getting failures
 (e.g. util-linux) I also tried without those, but no difference.

I suppose I'd better note that I seem to have been running a 5.7-rc2
kernel while doing at least the latter of these (accidentally
rebooted when waking up from suspend)

dejagnu-1.6.2 (chapter 5) - ok

glibc-2.31 (my host system was LFS-svn-20200307) - no failures
I see we claim that misc/tst-ttyname and net/tst-idna_name_classify
"are known to fail in the LFS chroot environment" which I interpret
as "are expected to fail".  If so, progress.

zlib-1.2.11 - ok

xz-5.2.5 - ok

file-5.38 - ok

m4-1.4.18 - ok

bc-2.7.2 - ok

binutils-2.34 - no reported failures, but the tests ended in error,
so here are the details:

=== binutils Summary ===

# of expected passes267
# of unsupported tests  2

Testsuite summary for gold 0.1

# TOTAL: 4
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


=== gas Summary ===

# of expected passes1358

=== ld Summary ===

# of expected passes2409
# of expected failures  57
# of untested testcases 1
# of unsupported tests  39

I see there have been comments about gold - all my gold tests claim
to have passed.

gmp-6.2.0 - ok

mpfr-4.0.2 - ok

mpc-1.1.0 - ok

attr-2.4.48 - ok

libcap-2.34 - ok

gcc-10.1.0 (from the summary, similar to the last few releases)

=== gcc tests ===


Running target unix
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O0  (internal compiler error)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O1  (internal compiler error)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O2  (internal compiler error)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O3 -g  (internal compiler 
error)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O3 -g  (test for excess 
errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  (internal compiler error)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (internal compiler error)
FAIL: gcc.c-torture/compile/limits-exprparen.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (test for excess errors)

=== gcc Summary ===

# of expected passes149088
# of unexpected failures14


=== libstdc++ tests ===


Running target unix
FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
FAIL: 22_locale/time_get/get_time/char/2.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
FAIL: experimental/net/internet/resolver/ops/lookup.cc execution test

=== libstdc++ Summary ===

# of expected passes14097
# of unexpected failures8

pkg-config-0.29.2 - ok

ncurses-6.22 - I agree the testsuite can only be run after
installing, but it doesn't see particularly useful (the tests need to
be individually invoked, and they don't produce any obvious pass or
fail output - some give coloured outputs, others ran for longer than

Re: [lfs-dev] test results with locale-archive symlink and vim-8.2.0814 (trunk book)

[Ken Moffat via lfs-dev]

On Mon, May 25, 2020 at 05:20:44PM +0200, Pierre Labastie via lfs-dev wrote:
> On Mon, 2020-05-25 at 16:14 +0200, Pierre Labastie via lfs-dev wrote:
> > 
> > Now this has been done with /dev/pts bind mounted. Let's try with
> > /dev/pts mounted normally...
> > 
> > Same, that is: no /dev/tty error...
> > 
> 
> But binding /dev/pts removes the failure in coreutils tests
> Pierre
> 
Pierre,

I take my hat off to you!  Very well done.

ĸen
-- 
  Remembering The People's Republic of Treacle Mine Road.
Truth!  Justice!  Freedom!  Reasonably priced Love!
 And a Hard-boiled Egg!
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] test results with locale-archive symlink and vim-8.2.0814 (trunk book)

[Ken Moffat via lfs-dev]

On Sun, May 24, 2020 at 10:16:34PM +0100, Ken Moffat wrote:
> On Sun, May 24, 2020 at 07:35:10PM +0200, Pierre Labastie via lfs-dev wrote:
> > On Sun, 2020-05-24 at 16:44 +0200, Pierre Labastie via lfs-dev wrote:
> > > Hi,
> > > Here are test results from a jhalfs run:
> > > [...
> > 
> > about vim test
> > > ===
> > > [...]
> > > ---
> > > vim: stops at test1:
> > >  test1 FAILED - terminal size must be 80x24 or larger
> > >  Executed: 0 Tests
> > >   Skipped: 0 Tests
> > >Failed: 0 Tests
> > 
> > For some reason, my gnome terminal had 80 columns and 23 lines.
> > Vim tests do not run if the number of lines is less than 24!
> > and the number of columns is less than 80.
> > 
> > Note that the in chroot the command "tty" returns "Not a tty", and that
> > may explains some test failures, specially with bash tests
> > 
> > Pierre
> > 
> Hi Pierre,
> 
> thanks for looking at this.
> 
> One of the reasons why my build has taken so long is that I'm trying
> to look at every failign testsuite, to see if there is a way around
> it.  For some things (e.g. iproute) we just say it doesn't work - at
> the moment I don't know if it can work (needs libmna, and then it
> wants sudo for rmmod), but in chroot I'm going to suggest it SHOULD
> NOT be run and therefore its missing deps can be ignored.
> 
> And in particular, I had not realised that tty fails like that.  It
> does indeed explain apparent failures in the bash tests.  I wonder
> if, instead of mounting dev/pts we should bind it ?

Or, better - because we bind /mnt/lfs/dev to /dev, perhaps NOT mount
/dev/pts in chroot ?  In theory, that should give us what is on the
host in /dev/pts, but then the group may be wrong if the host uses a
different group from LFS.

ĸen
-- 
  Remembering The People's Republic of Treacle Mine Road.
Truth!  Justice!  Freedom!  Reasonably priced Love!
 And a Hard-boiled Egg!
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] test results with locale-archive symlink and vim-8.2.0814 (trunk book)

[Ken Moffat via lfs-dev]

On Sun, May 24, 2020 at 07:35:10PM +0200, Pierre Labastie via lfs-dev wrote:
> On Sun, 2020-05-24 at 16:44 +0200, Pierre Labastie via lfs-dev wrote:
> > Hi,
> > Here are test results from a jhalfs run:
> > [...
> 
> about vim test
> > ===
> > [...]
> > ---
> > vim: stops at test1:
> >  test1 FAILED - terminal size must be 80x24 or larger
> >  Executed: 0 Tests
> >   Skipped: 0 Tests
> >Failed: 0 Tests
> 
> For some reason, my gnome terminal had 80 columns and 23 lines.
> Vim tests do not run if the number of lines is less than 24!
> and the number of columns is less than 80.
> 
> Note that the in chroot the command "tty" returns "Not a tty", and that
> may explains some test failures, specially with bash tests
> 
> Pierre
> 
Hi Pierre,

thanks for looking at this.

One of the reasons why my build has taken so long is that I'm trying
to look at every failign testsuite, to see if there is a way around
it.  For some things (e.g. iproute) we just say it doesn't work - at
the moment I don't know if it can work (needs libmna, and then it
wants sudo for rmmod), but in chroot I'm going to suggest it SHOULD
NOT be run and therefore its missing deps can be ignored.

And in particular, I had not realised that tty fails like that.  It
does indeed explain apparent failures in the bash tests.  I wonder
if, instead of mounting dev/pts we should bind it ?
-- 
  Remembering The People's Republic of Treacle Mine Road.
Truth!  Justice!  Freedom!  Reasonably priced Love!
 And a Hard-boiled Egg!
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Automake: skip tags-lisp-space.sh

[Ken Moffat via lfs-dev]

At the moment we have a known failure in automake-1.16.2,
tags-lisp-space.sh.  This fails because etags is not present.  The
test tagsub similarly wants to use etags, but for that the test is
skipped.

The difference is that tagsub has
 required=etags
whereas tags-lisp-space.sh has
 required=''

This has already been fixed upstream:

commit 77d39959511295f5a30332d5d03f0a6956bd9460
Author: Karl Berry 
Date:   Tue Mar 24 18:30:18 2020 -0700

tests: require etags for tags-lisp-space test.

* t/tags-lisp-space.sh (required): set to etags.

diff --git a/t/tags-lisp-space.sh b/t/tags-lisp-space.sh
index d0a940ba3568..44312b0b7ab7 100755
--- a/t/tags-lisp-space.sh
+++ b/t/tags-lisp-space.sh
@@ -18,7 +18,7 @@
 # if there are CONFIG_HEADERS.
 # See automake bug#38139.
 
-required=''
+required=etags
 . test-init.sh
 
 # some AC_CONFIG_FILES header is needed to trigger the bug.

I tend to come up with ugly seds, I'm using

sed -i "/required=/s/=.*/=etags/" t/tags-lisp-space.sh

Maybe there is a better sed variant ?  It is always nice to reduce
the number of test failures in LFS.

ĸen
-- 
Do you not know that, what you belittle by the name tree is but the
mere four-dimensional analogue of a whole multidimensional universe
which - no, I can see you do not.  -- Druellae (a Dryad)
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] A first new success in my cross-chap5 build

[Ken Moffat via lfs-dev]

I said I was going to try cross-chap5, and I'd intended to keep
quiet about it until I completed - as I said before, I don't think
that entering chroot in chapter 5 is a good idea - but that, and
various minor points can wait.

I'm continuing to set /etc/passwd and /etc/group on the way into
chroot, and then running everything in chroot from my chroot script.

This has taken me a long time because my method of logging got
really broken with the DESTDIRs in /tools (I used to log only
/tools), and then after that my 'intochroot' script for passwd and
group suddenly discovered /dev, /proc and /sys).  As Ryan would have
said: fun, fun, fun.

But now I'm running in chroot I'm looking at each testsuite in the
hope that I can get everything to complete (brief note - glibc no
failures on my haswell).  So I got to sed and the panic-tests
problem.

The only slightly-relevant posting I could find was:
From https://lists.gnu.org/archive/html/bug-sed/2018-01/msg6.html
and that got no reply so I'm guessing the cause was a local problem.
We've been skipping this test since LFS-8.0 (sed-4.4), but I think I
now understand the problem.

At the end of that reply is :

| Also, can you try the following commands in the same directory
| as 'sed', as a sanity check?
|
|  mkdir aaa
|  chmod a-w aaa
|  touch aaa/bbb
|
| The 'touch' command should fail with "permission denied"
| (this is esentially the sed test that fails).

When I run that as root after the failure, the touch succeeds - I
suppose because I'm root so I can shoot myself in the foot.

Trying variations on what we do for coreutils, the following seems
to work -

  chown -Rv nobody .
  su nobody -s /bin/bash \
-c "make check"

For my script I log this, and I have to chown the log to nobody, but
the book won't care about that.  I have every hope that Pierre's
approach is better than what we've been doing, but I guess this part
should work even in trunk (provided user nobody exists at this
point, I haven't looked at where we create that user in trunk).


Testsuite summary for GNU sed 4.8

# TOTAL: 178
# PASS:  157
# SKIP:  21
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


ĸen
-- 
Do you not know that, what you belittle by the name tree is but the
mere four-dimensional analogue of a whole multidimensional universe
which - no, I can see you do not.  -- Druellae (a Dryad)
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] CFLAGS in fixing up for gcc-10.

[Ken Moffat via lfs-dev]

On Thu, May 14, 2020 at 09:21:00AM +0200, Pierre Labastie via lfs-dev wrote:
> On Thu, 2020-05-14 at 05:33 +0100, Ken Moffat via lfs-dev wrote:
> > I notice that in some places people have overridden any existing
> > CFLAGS when adding -fcommon.  In most places, for those of us who
> > care the fix is obvious (CFLAGS="$CFLAGS -fcommon").  One or two
> > packages will turn out to be more painful.
> > 
> > The first I've found is freeglut, where the book uses
> >   -DCMAKE_C_FLAGS=-fcommon
> > 
> > For people without any existing CFLAGS, that does the right thing
> > and respects the -O3 etc from specifying a Release build (seen by
> > using 'make VERBOSE=1') but for people who have extra flags such as
> > "-march=native -D_FORTIFY_SOURCE=2" those just get thrown away.
> > 
> > I'd assumed I could add
> >  -DCMAKE_CFLAGS="$CFLAGS -fcommon"
> > 
> > but if I do that, cmake tells me that CFLAGS was not referenced.
> > 
> > In this case, I am getting the right results (testing on a gcc-9
> > system) with:
> > 
> > CFLAGS="${CFLAGS} -fcommon" \
> > cmake -DCMAKE_INSTALL_PREFIX=/usr  \
> >   -DCMAKE_BUILD_TYPE=Release   \
> >   -DFREEGLUT_BUILD_DEMOS=OFF   \
> >   -DFREEGLUT_BUILD_STATIC_LIBS=OFF \
> >   -Wno-dev ..
> > 
> > Can I ask people to at least *consider* not trashing a user's
> > specified CFLAGS ?
> 
> Sorry about that Ken. As you noted in another post, cmake semantics is
> not always easy to understand. I thought that doing like that was
> preserving user's CFLAGS... And for some reason I thought CFLAGS where
> not passed when doing the above (CFLAGS in the environment).
> 
> Will fix the book, and add "$CFLAGS" before -fcommon at other places I
> have put them.
> 
> Pierre
> 
Thanks!

I hope to get started on exploring your cross-chap5 soon.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] CFLAGS in fixing up for gcc-10.

[Ken Moffat via lfs-dev]

On Thu, May 14, 2020 at 08:53:18AM -0500, Douglas R. Reno via lfs-dev wrote:
> 
> On 5/14/20 1:33 AM, Xi Ruoyao via lfs-dev wrote:
> > On 2020-05-13 23:46 -0500, Bruce Dubbs via lfs-dev wrote:
> > > On 5/13/20 11:33 PM, Ken Moffat via lfs-dev wrote:
> > > > I notice that in some places people have overridden any existing
> > > > CFLAGS when adding -fcommon.  In most places, for those of us who
> > > > care the fix is obvious (CFLAGS="$CFLAGS -fcommon").  One or two
> > > > packages will turn out to be more painful.
> > > > 

> > > > Can I ask people to at least *consider* not trashing a user's
> > > > specified CFLAGS ?
> > > Yes, we can do that, but right now we are trying to just get everything
> > > to build with gcc10.  When that is done, we can probably review and do
> > > 'grep -r CFLAGS; in the book's xml top and do the right thing where we
> > > have had to make changes.
> > > 

No problem with prioritising getting the packages to build, but one
or two (a couple of the video drivers) already pick up the CFLAGS
before adding -fcommon.

> > > Also as new package releases address gcc10, we can probably remove a lot
> > > of the CFLAGS entries that we've been making.
> > I don't like -fcommon.  It's actually changing C semantics.  The correct 
> > thing
> > to do is to fix the code (like what we do for gdbm in LFS).
> > 
> > Though we can simply add this workaround for now...
> 
> Agreed here, I don't like it either. Most of these would be very simple
> fixes and may even be accomodated via sed instead of patch.
> 
> That's OK though, I'll go with what everyone else is doing for now...
> 
I've seen a comment from a fedora developer that he had to spend a
lot of time getting everything to build with gcc-10.  I'm sure some
of what they build is development versions, and they ignore some
other things we build, but fedora might be a place worth looking.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Libcap 2.34 will not install .pc files in correct location

[Ken Moffat via lfs-dev]

On Tue, May 05, 2020 at 07:41:58PM +0300, Firas Khalil Khana via lfs-dev wrote:
> Confirming an issue is top-posting?
> 

Any post where the reply comes before the item to which you are
replying or commenting is top posting.

> I didn't know that, and for that I apologize...
> 

So, here you have again top-posted by putting the text you are
replying to below your reply :

> On Tue, 5 May 2020, 7:39 pm Bruce Dubbs via lfs-dev, <
> lfs-dev@lists.linuxfromscratch.org> wrote:
> 
> > On 5/5/20 8:57 AM, Firas Khalil Khana via lfs-dev wrote:
> > > I can confirm this as well, and specifying
> > > "PKGCONFIGDIR=/usr/lib/pkgconfig" fixes the problem.
> >
> > Please stop top posting on the mailing lists.
> >
> >-- Bruce
> >

In long replies it is sometimes polite to include introductory text
*after* the "On some day at some time, someone wrote" header, but
most text (even things as minimal as '+1' or 'me too') should still
go after the text to which you are replying.

Unfortunately, gmail takes the microsoft approach and makes it
inconvenient to do this in its browser interface.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

On Mon, May 04, 2020 at 07:24:45PM +0100, Ken Moffat via lfs-dev wrote:
> 
> When I get back to my system where I was trying to fix this I'll try
> to remember to check that all 13 bison failures were locale-related.
> If they were, for my own builds I'll go back to expecting test
> failures in bison and man-db.
> 
Yes, all 13 failures were where ittried to use the en_US.utf8
locale.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Reduce Temporary System Components and Reorder Basic System Software

[Ken Moffat via lfs-dev]

On Mon, May 04, 2020 at 08:39:24PM +0300, Firas Khalil Khana via lfs-dev wrote:
> Hey there,
> 
> My name is Firas Khalil Khana, and I'm the creator of glaucus
> .
> 
> I'd like to salute your efforts for keeping this project awesome this whole
> time! The shear amount of information in a single place like LFS is truly
> impressive.
> 
> That being said, I'd like to propose a (somewhat) slight change regarding
> the amount of packages actually needed in the temporary system (Chapter 5,
> which I'll be referring to as the chroot environment).
> 

Skipping most of this, I assume you are talking about the
cross-build plans and I haven't had time to look at that book yet.

Just one objection:
> 
> 7- which  can be added
> after coreutils (some packages may depend on it in the format of using it
> inside scripts to fetch available binary versions (gcc with go support,
> coreutils?, the Linux kernel (for testing?), but it's pretty useful once
> you're in the chroot environment and in the final system as well).
> 

Bloatware ! ;-)

Seriously - 'type -pa' during an interrupted build, if I need to run
'which'.

I have not built the which package itself for many years, and use
"The 'which' Script" from BLFS's which page.

ĸen

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

On Mon, May 04, 2020 at 10:57:23AM -0500, Bruce Dubbs via lfs-dev wrote:
> On 5/4/20 3:22 AM, Pierre Labastie via lfs-dev wrote:
> > On Mon, 2020-05-04 at 06:51 +0100, Ken Moffat via lfs-dev wrote:
> 
> Does this pass after rebooting into the new LFS system?  If so, I think we
> should stop spending time on this and just add a statement like we have in
> glibc:
> 
>misc/tst-ttyname
>is known to fail in the LFS chroot environment.
> 
> We also do this in gzip, inetutils, and findutils.
> 
> Alternatively, we can just disable the test like we do in several places in
> BLFS.
> 

Fair comment, for our current build system.

When I get back to my system where I was trying to fix this I'll try
to remember to check that all 13 bison failures were locale-related.
If they were, for my own builds I'll go back to expecting test
failures in bison and man-db.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

On Mon, May 04, 2020 at 10:22:22AM +0200, Pierre Labastie via lfs-dev wrote:
> On Mon, 2020-05-04 at 06:51 +0100, Ken Moffat via lfs-dev wrote:
> > On Mon, May 04, 2020 at 12:51:34PM +0800, Xi Ruoyao via lfs-dev
> > wrote:
> > > > Doesn't really explain why man-db has sometimes failed, but
> > > > passed
> > > > other times (for various builders).  Maybe there is something
> > > > else
> > > > there.
> > > 
> > > In sysv book, there was no util-linux in chap. 5 (until Pierre
> > > added them to fix
> > > problems found by ICA).  So the tests using util-linux tools would
> > > be skipped.
> > 
> > That make sense.  I'll blame Pierre ! ;-)
> > 
> > No, obviously I won't blame Pierre, but this is still very much work
> > in progress.
> > 
> 
> I did blame myself :)
> http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-May/073696.html
> 
> so could it be that packages built in chap 5 look for locales in
> /tools/share?
> 
> A few experiments (the "toto" command is just to have bash printing an
> error message):
> root [ / ]# echo $LC_ALL
> fr_FR.UTF-8
> root [ / ]# exec /bin/bash
> root [ / ]# toto
> bash: toto : commande introuvable
> 
> root [ / ]# exec /tools/bin/bash
> bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.UTF-8)
> root [ / ]# echo $LC_ALL
> fr_FR.UTF-8
> root [ / ]# toto
> bash: toto: command not found
> 
> So /tools/bin/bash is not seeking locales in /usr/lib/locale/locale-
> archive (where compiled locales are stored, man localedef for details).
> 
> I guess it is the same for col from util-linux.
> 
> One possible fix is:
> mkdir /tools/lib/locale
> ln -s /usr/lib/locale/locale-archive /tools/lib/locale
> 
> with that:
> root [ / ]# export LC_ALL=fr_FR.UTF-8
> root [ / ]# exec /tools/bin/bash
> root [ / ]# toto
> bash: toto : commande introuvable
> 
> Another tweak needed because of a separate /tools...
> 
> Pierre
> 

Thanks for looking at this.  You've convinced me that your
cross-build will be the way to go.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

On Mon, May 04, 2020 at 12:50:12PM +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-04 04:12 +0100，Ken Moffat via lfs-dev wrote:
> > On Mon, May 04, 2020 at 03:34:53AM +0100, Ken Moffat via lfs-dev wrote:
> > > On Mon, May 04, 2020 at 09:53:04AM +0800, Xi Ruoyao via lfs-dev wrote:
> > > > On 2020-05-04 02:15 +0100, Ken Moffat via lfs-dev wrote:
> > > > > On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev 
> > > > > wrote:
> > > > > > I'm building with LFS as at 25th April.  My previous build was in
> > > > > > early April, and I think this is the first time I've seen a failure
> > > > > > in the man-db tests.  With man-db-2.9.1 :
> > > > > > 
> > > > > > FAIL: man-missing-locales
> > > > > > 
> > > > > > and src/tests/test-suite.log has:
> > > > > > 
> > > > > > FAIL: man-missing-locales 
> > > > > > =
> > > > > > 
> > > > > > col: failed on line 319: Invalid or incomplete multibyte or wide
> > > > > > character
> > > > > > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p 
> > > > > > -x
> > > > > > | sed
> > > > > > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > > > > >   FAIL: missing locales
> > > > > > FAIL man-missing-locales (exit status: 1)
> > > > > > 
> > > > > > Given that things have changed since my previous build, is anyone
> > > > > > else seeing this ?  I suspect the error might be "mine, all mine",
> > > > > > so I'm reluctant to add to the noise by reporting iti upstream
> > > > > > unless it really is common.  Looking at my glibc log I did
> > > > > > apparently install the en_US.UTF-8 locale.
> > > > > > 
> > > > > > ĸen
> > > > > 
> > > > > Update: I'm doing a fresh build to look at the test failures in this
> > > > > and in bison (and also to make sure I've fixed my own screw-up in
> > > > > removing the symlinked headers before rebuilding util-linux).
> > > > > 
> > > > > Got to bison, failures as before.  First is
> > > > > 
> > > > > 131. diagnostics.at:107: testing Warnings ...
> > > > > ./diagnostics.at:107: LC_ALL="$locale"  bison -fcaret --color=debug
> > > > > -Wall
> > > > > input.y
> > > > > --- experr  2020-05-03 23:20:06.028040360 +
> > > > > +++ /building/bison-3.5.4/tests/testsuite.dir/at-
> > > > > groups/131/stderr  2020-
> > > > > 05-03 23:20:06.057040734 +
> > > > > @@ -1,3 +1,4 @@
> > > > > +/bin/sh: warning: setlocale: LC_ALL: cannot change locale 
> > > > > (en_US.utf8)
> > > > >  input.y:9.12-14: warning: symbol FOO redeclared
> > > > > [-Wother]
> > > > >  9 | %token FOO FOO FOO
> > > > >|^~~
> > > > > 131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED
> > > > > (diagnostics.at:107)
> > > > > 
> > > > > So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
> > > > > variants.  The capitalized version is definitely installed, accoding
> > > > > to my log from glibc.
> > > > 
> > > > So I think the issue is: we are using chapter 5 bash for bison, and
> > > > chapter 5
> > > > util-linux for man-db.  Chapter 5 tools' locale archive is
> > > > /tools/lib/locale/locale-archive, which is not installed.
> > > > 
> > > > Maybe installing en_US.UTF-8 locale in chap. 5 glibc would solve this
> > > > problem.
> > > > -- 
> > > > Xi Ruoyao 
> > > > School of Aerospace Science and Technology, Xidian University
> > > > 
> > > 
> > > Sounds plausible.  Will give it a try.
> > > 
> > > ĸen
> > 
> > Came back to it to check that glibc had got through my additions,
> > then checked the logs.  In all three runs glibc seems to have
> > installed a LOT of locales in /tools/hare/i18n/locales/
> 
> They are "uncompiled" locale data.  Use:
> 
> install -vdm755 /tools/lib/locale
> /tools/bin/localedef -i en_US -f UTF-8 en_US.UTF-8
> 
> to make a /tools/bin/locale/locale-archive (which is necessary at runtime, to
> use locales) from them.
> 

What I added after make install was:

mkdir -pv /tools/lib/locale
localedef -i en_US -f UTF-8 en_GB.UTF-8

And since I was running as the lfs user, I don't think using a path
on localedef is necessary.

> > No longer hopeful, but will let it run.
> > 

13 failures, as before.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

On Mon, May 04, 2020 at 12:51:34PM +0800, Xi Ruoyao via lfs-dev wrote:
> > 
> > Doesn't really explain why man-db has sometimes failed, but passed
> > other times (for various builders).  Maybe there is something else
> > there.
> 
> In sysv book, there was no util-linux in chap. 5 (until Pierre added them to 
> fix
> problems found by ICA).  So the tests using util-linux tools would be skipped.

That make sense.  I'll blame Pierre ! ;-)

No, obviously I won't blame Pierre, but this is still very much work
in progress.

After the tests failed this time, I exited chroot and re-entered it.
Tried passing LC_ALL=en_US.UTF-8 ; date - again got the error
message about the locale.  Rebuilt bison anyway, tests similarly
failed.

Feeling old, going to bed! (see .sig:)

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

On Mon, May 04, 2020 at 03:34:53AM +0100, Ken Moffat via lfs-dev wrote:
> On Mon, May 04, 2020 at 09:53:04AM +0800, Xi Ruoyao via lfs-dev wrote:
> > On 2020-05-04 02:15 +0100, Ken Moffat via lfs-dev wrote:
> > > On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev wrote:
> > > > I'm building with LFS as at 25th April.  My previous build was in
> > > > early April, and I think this is the first time I've seen a failure
> > > > in the man-db tests.  With man-db-2.9.1 :
> > > > 
> > > > FAIL: man-missing-locales
> > > > 
> > > > and src/tests/test-suite.log has:
> > > > 
> > > > FAIL: man-missing-locales 
> > > > =
> > > > 
> > > > col: failed on line 319: Invalid or incomplete multibyte or wide 
> > > > character
> > > > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x 
> > > > | sed
> > > > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > > >   FAIL: missing locales
> > > > FAIL man-missing-locales (exit status: 1)
> > > > 
> > > > Given that things have changed since my previous build, is anyone
> > > > else seeing this ?  I suspect the error might be "mine, all mine",
> > > > so I'm reluctant to add to the noise by reporting iti upstream
> > > > unless it really is common.  Looking at my glibc log I did
> > > > apparently install the en_US.UTF-8 locale.
> > > > 
> > > > ĸen
> > > 
> > > Update: I'm doing a fresh build to look at the test failures in this
> > > and in bison (and also to make sure I've fixed my own screw-up in
> > > removing the symlinked headers before rebuilding util-linux).
> > > 
> > > Got to bison, failures as before.  First is
> > > 
> > > 131. diagnostics.at:107: testing Warnings ...
> > > ./diagnostics.at:107: LC_ALL="$locale"  bison -fcaret --color=debug -Wall
> > > input.y
> > > --- experr  2020-05-03 23:20:06.028040360 +
> > > +++ /building/bison-3.5.4/tests/testsuite.dir/at-groups/131/stderr  
> > > 2020-
> > > 05-03 23:20:06.057040734 +
> > > @@ -1,3 +1,4 @@
> > > +/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
> > >  input.y:9.12-14: warning: symbol FOO redeclared
> > > [-Wother]
> > >  9 | %token FOO FOO FOO
> > >|^~~
> > > 131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED
> > > (diagnostics.at:107)
> > > 
> > > So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
> > > variants.  The capitalized version is definitely installed, accoding
> > > to my log from glibc.
> > 
> > So I think the issue is: we are using chapter 5 bash for bison, and chapter 
> > 5
> > util-linux for man-db.  Chapter 5 tools' locale archive is
> > /tools/lib/locale/locale-archive, which is not installed.
> > 
> > Maybe installing en_US.UTF-8 locale in chap. 5 glibc would solve this 
> > problem.
> > -- 
> > Xi Ruoyao 
> > School of Aerospace Science and Technology, Xidian University
> > 
> 
> Sounds plausible.  Will give it a try.
> 
> ĸen

Came back to it to check that glibc had got through my additions,
then checked the logs.  In all three runs glibc seems to have
installed a LOT of locales in /tools/hare/i18n/locales/

No longer hopeful, but will let it run.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

On Mon, May 04, 2020 at 09:53:04AM +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-04 02:15 +0100, Ken Moffat via lfs-dev wrote:
> > On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev wrote:
> > > I'm building with LFS as at 25th April.  My previous build was in
> > > early April, and I think this is the first time I've seen a failure
> > > in the man-db tests.  With man-db-2.9.1 :
> > > 
> > > FAIL: man-missing-locales
> > > 
> > > and src/tests/test-suite.log has:
> > > 
> > > FAIL: man-missing-locales 
> > > =
> > > 
> > > col: failed on line 319: Invalid or incomplete multibyte or wide character
> > > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | 
> > > sed
> > > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > >   FAIL: missing locales
> > > FAIL man-missing-locales (exit status: 1)
> > > 
> > > Given that things have changed since my previous build, is anyone
> > > else seeing this ?  I suspect the error might be "mine, all mine",
> > > so I'm reluctant to add to the noise by reporting iti upstream
> > > unless it really is common.  Looking at my glibc log I did
> > > apparently install the en_US.UTF-8 locale.
> > > 
> > > ĸen
> > 
> > Update: I'm doing a fresh build to look at the test failures in this
> > and in bison (and also to make sure I've fixed my own screw-up in
> > removing the symlinked headers before rebuilding util-linux).
> > 
> > Got to bison, failures as before.  First is
> > 
> > 131. diagnostics.at:107: testing Warnings ...
> > ./diagnostics.at:107: LC_ALL="$locale"  bison -fcaret --color=debug -Wall
> > input.y
> > --- experr  2020-05-03 23:20:06.028040360 +
> > +++ /building/bison-3.5.4/tests/testsuite.dir/at-groups/131/stderr  
> > 2020-
> > 05-03 23:20:06.057040734 +
> > @@ -1,3 +1,4 @@
> > +/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
> >  input.y:9.12-14: warning: symbol FOO redeclared
> > [-Wother]
> >  9 | %token FOO FOO FOO
> >|^~~
> > 131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED
> > (diagnostics.at:107)
> > 
> > So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
> > variants.  The capitalized version is definitely installed, accoding
> > to my log from glibc.
> 
> So I think the issue is: we are using chapter 5 bash for bison, and chapter 5
> util-linux for man-db.  Chapter 5 tools' locale archive is
> /tools/lib/locale/locale-archive, which is not installed.
> 
> Maybe installing en_US.UTF-8 locale in chap. 5 glibc would solve this problem.
> -- 
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University
> 

Sounds plausible.  Will give it a try.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev wrote:
> I'm building with LFS as at 25th April.  My previous build was in
> early April, and I think this is the first time I've seen a failure
> in the man-db tests.  With man-db-2.9.1 :
> 
> FAIL: man-missing-locales
> 
> and src/tests/test-suite.log has:
> 
> FAIL: man-missing-locales 
> =
> 
> col: failed on line 319: Invalid or incomplete multibyte or wide character
> man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | sed 
> -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
>   FAIL: missing locales
> FAIL man-missing-locales (exit status: 1)
> 
> Given that things have changed since my previous build, is anyone
> else seeing this ?  I suspect the error might be "mine, all mine",
> so I'm reluctant to add to the noise by reporting iti upstream
> unless it really is common.  Looking at my glibc log I did
> apparently install the en_US.UTF-8 locale.
> 
> ĸen

Update: I'm doing a fresh build to look at the test failures in this
and in bison (and also to make sure I've fixed my own screw-up in
removing the symlinked headers before rebuilding util-linux).

Got to bison, failures as before.  First is

131. diagnostics.at:107: testing Warnings ...
./diagnostics.at:107: LC_ALL="$locale"  bison -fcaret --color=debug -Wall 
input.y
--- experr  2020-05-03 23:20:06.028040360 +
+++ /building/bison-3.5.4/tests/testsuite.dir/at-groups/131/stderr  
2020-05-03 23:20:06.057040734 +
@@ -1,3 +1,4 @@
+/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
 input.y:9.12-14: warning: symbol FOO redeclared 
[-Wother]
 9 | %token FOO FOO FOO
   |^~~
131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED 
(diagnostics.at:107)

So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
variants.  The capitalized version is definitely installed, accoding
to my log from glibc.

On the system completed on Sunday, from which I am building the new
test one, I can do things like:

ken@deluxe ~ $echo $LC_ALL
en_GB.UTF-8
ken@deluxe ~ $export LC_ALL=en_US.UTF-8  && date
Mon 04 May 2020 02:02:15 AM BST
ken@deluxe ~ $export LC_ALL=en_US.utf8  && date
Mon 04 May 2020 02:02:23 AM BST
ken@deluxe ~ $export LC_ALL=fr_FR.utf8  && date
lun. 04 mai 2020 02:02:50 BST

(that latter is just to prove that something changes)

BUT in chroot I can only set the locale to C or POSIX:

root in chroot /# locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

root in chroot /# export LC_ALL=en_US.UTF-8 && date
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such 
file or directory
Mon May  4 00:48:39 UTC 2020
root in chroot /# export LC_ALL=fr_FR.UTF-8 && date
bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.UTF-8): No such 
file or directory
Mon May  4 00:48:52 UTC 2020
root in chroot /# export LC_ALL=en_US.utf8 && date
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
Mon May  4 00:50:01 UTC 2020
root in chroot /# export LC_ALL=en_US.iISO-8859-1 && date
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.ISO-8859-1): No 
such file or directory
Mon May  4 00:50:46 UTC 2020
root in chroot /# export LC_ALL=C && date
Mon May  4 00:51:16 UTC 2020
root in chroot /# export LC_ALL=C.UTF-8 && date
bash: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8): No such file 
or directory
Mon May  4 00:51:27 UTC 2020
root in chroot /# export LC_ALL=POSIX && date
Mon May  4 00:51:37 UTC 2020

Puzzled.

From the test logs for the complited build I can see PASS against
'utf8' in grep, make, Python (and a fail in acl, but I expect acl to
fail).

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

On Sun, May 03, 2020 at 12:02:12PM +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-03 04:18 +0100, Ken Moffat via lfs-dev wrote:
> > I'm building with LFS as at 25th April.  My previous build was in
> > early April, and I think this is the first time I've seen a failure
> > in the man-db tests.  With man-db-2.9.1 :
> > 
> > FAIL: man-missing-locales
> > 
> > and src/tests/test-suite.log has:
> > 
> > FAIL: man-missing-locales 
> > =
> > 
> > col: failed on line 319: Invalid or incomplete multibyte or wide character
> > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | sed
> > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> >   FAIL: missing locales
> > FAIL man-missing-locales (exit status: 1)
> > 
> > Given that things have changed since my previous build, is anyone
> > else seeing this ?  I suspect the error might be "mine, all mine",
> > so I'm reluctant to add to the noise by reporting iti upstream
> > unless it really is common.  Looking at my glibc log I did
> > apparently install the en_US.UTF-8 locale.
> 
> I've seen this many times (almost each time I built LFS).

I'm surprised - as I just replied to Doug, this is the first time
this has hit me.  Will take a look on the completed system, to see
if it breaks there.

Thanks.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

On Sat, May 02, 2020 at 10:58:11PM -0500, Douglas R. Reno via lfs-dev wrote:
> 
> On 5/2/20 10:18 PM, Ken Moffat via lfs-dev wrote:
> > I'm building with LFS as at 25th April.  My previous build was in
> > early April, and I think this is the first time I've seen a failure
> > in the man-db tests.  With man-db-2.9.1 :
> > 
> > FAIL: man-missing-locales
> > 
> > and src/tests/test-suite.log has:
> > 
> > FAIL: man-missing-locales
> > =
> > 
> > col: failed on line 319: Invalid or incomplete multibyte or wide character
> > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | 
> > sed -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> >FAIL: missing locales
> > FAIL man-missing-locales (exit status: 1)
> > 
> > Given that things have changed since my previous build, is anyone
> > else seeing this ?  I suspect the error might be "mine, all mine",
> > so I'm reluctant to add to the noise by reporting iti upstream
> > unless it really is common.  Looking at my glibc log I did
> > apparently install the en_US.UTF-8 locale.
> > 
> > ĸen
> 
> Hi Ken,
> 
> I got that failure on my last build too (SVN-20200501):
> 
> renodr [ /mnt/lfs/jhalfs/test-logs ]$ grep FAIL 137-man-db-2.9.1
> FAIL: man-missing-locales
> 
> From what I gather, I have the same problem. My guess is that it's a bug in
> the test suite, but I'm not sure on that. I do use the en_US locale as my
> primary. I normally do a jhalfs build after Bruce does an update to LFS to
> verify that packages such as meson don't break systemd like they did in the
> past.
> 
> Looking back on it - I have this failure with man-db-2.9.0 as well, on my
> build on 20200201! I didn't review the test suite logs on that one :(
> 
> 
> - Doug
> 
Hi Doug,

that's interesting.  My previous build was for LFS 20200403 on a
different machine, but with 2.9.1, and that did not fail (I only
noticed because recently man-db tests have not failed for me, so any
new failure stops the build - on packages where I expect one or more
tests to fail I add ' || true').

Assuming that the new build boots, and allows me to get past the
current firefox-68.8.0 candidate (build 2), I'll look at this in the
completed system.  Similarly with bison which is still failing.

Oh well, it will make a change from looking at the details of fonts,
and maybe put off when I have to address cantarell in BLFS ;-)

[ Current cantarell also installs a -VF file which seems to contain
at least all the main variants, but breaks xelatex, and it no longer
includes cyrillic glyphs - Noto Sans UI was recommended as an
alternative, but Noto Sans Display seems to have replaced that -
available from debian, otherwise only git versions - and in any case
Noto fonts need overrides before fontconfig will use them if
preferred fonts such as DejaVu Sans, which is probably larger, are
present.  Supposedly, kde also prefers Noto, with a similar issue
for non latin/cyrillic/greek languages, but I've long since given up
on building kde. ]

Plus ça change!

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Test failure in man-db

[Ken Moffat via lfs-dev]

I'm building with LFS as at 25th April.  My previous build was in
early April, and I think this is the first time I've seen a failure
in the man-db tests.  With man-db-2.9.1 :

FAIL: man-missing-locales

and src/tests/test-suite.log has:

FAIL: man-missing-locales 
=

col: failed on line 319: Invalid or incomplete multibyte or wide character
man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | sed -e 
'/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
  FAIL: missing locales
FAIL man-missing-locales (exit status: 1)

Given that things have changed since my previous build, is anyone
else seeing this ?  I suspect the error might be "mine, all mine",
so I'm reluctant to add to the noise by reporting iti upstream
unless it really is common.  Looking at my glibc log I did
apparently install the en_US.UTF-8 locale.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Modified build of LFS using pure cross-compilation and sysroot

[Ken Moffat via lfs-dev]

On Fri, May 01, 2020 at 03:53:55PM +0200, Pierre Labastie via lfs-dev wrote:
> Hi,
> 
> I propose a new way to build LFS, which removes the need for the /tools
> symlink, and decreases the number of tweaks needed when building gcc.
> 
> The current build builds a cross-compiler in pass1, and uses it as a
> native compiler in pass2. This needs to use a non standard directory
> (/tools) to host the toolchain and insulate it from the build machine.
> 
> The modified build uses the cross compiler to cross compile packages
> that need themselves to be rebuilt, thus insulating them automatically
> from the host, without the need for a non standard directory layout.
> Chroot is entered as soon as possible, and the remaining chapter 5
> packages are built in chroot.
> 

If that happens, entering chroot ought to be after chapter 5.  At
the moment, we believe that up to the end of chapter 5 (apart from
when creating the filesystem and setting up the lfs user) you will
not trash the host system.  I'm worried about how people will
misinterpret what they should be doing if they come from our present
builds, particularly if they have created their own scripts.

> This is WIP: the text must be improved at several places, bison and
> flex may be moved to after chroot (to be tested). But the commands seem
> to produce an acceptable system, with almost clean ICA.
> 
> You can view it at [1], only for sys V since I have not tested systemd
> yet (I do not expect many changes).
> 
> There are pros and cons compared to the current method:
> 
>   pros: no /tools symlink, no need to tweak gcc sources, no need to
> build twice ld in binutils-pass2, no need to readjust the toolchain
> after chapter 6 glibc, no need to tweak the gcc specs, no need to
> reinstall kernel headers in chapter 6.
> 
>   cons: chroot is entered in the middle of chapter 5 (maybe chapter 5
> should be split), the debug sections of several packages reference
> x86_64-lfs-linux-gnu instead of x86_64-pc-linux-gnu, binutils-pass2
> needs "enable-shared".
> 

Not keen on that in the debug data, although I almost never use it.

> Another pro, not tried, is that some simple packages built in chapter 5
> may be built only once if testing them is not required.
> 

Based on experience from Pure LFS (5.0, where tests were introduced)
I don't regard that as a pro :)

> Comments and suggestions for improvement (there's a lot of room for
> improvement) welcome.
> 
> Regards
> Pierre
> 
> 
> [1] http://www.linuxfromscratch.org/~pierre/lfs-modified/index.html
> 

My main concern with making a change like this is not that we might
break the reliabilty, or the purity (ICA), but that we now
understand most of the things which can go wrong, and we try to
ameliorate them.

With a revised process, we might lose most of our past knowledge
about how breakage occurs (in the sense of "I saw this, I recall
that I'd done/omitted ...), and therefore how to fix it.

ĸen
-- 
 See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] e2fsprog depends optionally on udev

[Ken Moffat via lfs-dev]

On Sat, Apr 18, 2020 at 10:56:39PM +0200, Pierre Labastie via lfs-dev wrote:
> On Sat, 2020-04-18 at 21:03 +0100, Ken Moffat via lfs-dev wrote:
> > On Fri, Apr 03, 2020 at 07:15:28PM +0100, Ken Moffat via lfs-dev
> > wrote:
> > > On Fri, Apr 03, 2020 at 07:33:08PM +0200, Pierre Labastie via lfs-
> > > dev wrote:
> > 
> > At this point, I'd like to pass my congratulations to Pierre for
> > what he has established - understanding the final details of why
> > some things which had used to be ok now produced different code was
> > not something I ever managed.  I see Pierre has documented objdump
> > invocations in the tickets.
> > 
> 
> Thanks Ken. I hope you've seen that I was completely wrong with this
> message. It's not e2fsprog, but util-linux, which links against libudev
> on second pass. I thought I had sent a message about that, but I cannot
> find it now. Anyway, the ticket(s) is(now are) correct, which just
> means I have not found something wrong in them yet. But some of them
> are not solved...
> 
> Pierre
> 

Hi, Pierre,

I'd assumed that you might have gone to bed before I posted that.
Yes, not everything is currently solved, but as "A bear of very
little brain" (A.A. Milne, "Winnie the  Pooh") I have confidence
that my betters will eventually solve it.  If this was a job I would
have been promoted beyond my abilities (We're good at that in
Britain ;-)

«Tout est pour le mieux dans les meilleurs des mondes possibles.»

For those without the French tongue - 'Everything is for the best,
in the best of all possible worlds.' (Voltaire, Candide).

ĸen
-- 
He could send for Ptraci, his favourite handmaiden. She was special.
Her singing always cheered him up. Life seemed so much brighter when
she stopped.   -- Pyramids
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] e2fsprog depends optionally on udev

[Ken Moffat via lfs-dev]

On Fri, Apr 03, 2020 at 07:15:28PM +0100, Ken Moffat via lfs-dev wrote:
> On Fri, Apr 03, 2020 at 07:33:08PM +0200, Pierre Labastie via lfs-dev wrote:
> > I've reinstated the ICA system in jhalfs, in order to test the builds
> > with the sysroot/cross-compile system.
> > 
> > For those who haven't folowed lfs in the 200x years, ICA (iterative
> > comparison analysis) is a way to rebuild the system with itself, and
> > compare the results. There used to be another system, "farce", written
> > by Ken, which had to be removed from jhalfs for licensing problems. I
> > think this sytem is still accessible at Ken's home on 
> > www.linuxfromscratch.org.
> > 
> 
> Unfortunately, the problem with maintaining farce was that what I
> think was randomization of positioning in gcc caused the content of
> the binaries to not match.
> 
> I put farce under GPLv2 which is too restrictive for Pierre.
> 
> > Anyway, I found that e2fsprogs was linked against libudev on the second
> > build, and not on the first. The reason is that eudev is uilt after
> > eudev.
> > 
> > Maybe we could exchange eudev and e2fsprogs?
> > 
> > Of course, this is only valid for sysv. I do not know (yet) what
> > happens on systemd.
> > 
> > Pierre
> > 
> 
> Sounds like a good idea.
> 
> ĸen

At this point, I'd like to pass my congratulations to Pierre for
what he has established - understanding the final details of why
some things which had used to be ok now produced different code was
not something I ever managed.  I see Pierre has documented objdump
invocations in the tickets.

Good on you!

ĸen
-- 
He could send for Ptraci, his favourite handmaiden. She was special.
Her singing always cheered him up. Life seemed so much brighter when
she stopped.   -- Pyramids
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] /usr/lib/libc.a

[Ken Moffat via lfs-dev]

On Mon, Apr 06, 2020 at 10:51:57PM -0500, Bruce Dubbs via lfs-dev wrote:
> Can someone remind me why we keep /usr/lib/libc.a around?
> 
> I was rebuilding grep-3.4 with pcre and it was segfaulting.  Upon
> investigation I find I had:
> 
> [ /build/grep/grep-3.4 ]$ ldd src/grep
> linux-vdso.so.1 (0x7ffded18)
> libpcre.so.1 => /lib/libpcre.so.1 (0x7f38dd95e000)
> libsigsegv.so.2 => /usr/lib/libsigsegv.so.2 (0x7f38dd958000)
> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f38dd93e000)
> libc.so.6 => /lib/libc.so.6 (0x7f38dd77b000)
> /lib64/ld-linux-x86-64.so.2 (0x7f38dd9d4000)
> 
> I wondered why the heck libgcc_s.so.1 was there so I found that the build
> was linking in /usr/lib/libc.a.  Removing that fixed things up.
> 
>   -- Bruce

I think it might get used from time to time by tests, or when
building fully-static libraries.  Like most static libs mine is
normally renamed (libc.a.hidden in this case), but a quick look at
my current scripts doesn't find anything where I make it available.

For grep I've just run the following:

./configure --prefix=/usr --bindir=/bin
make

and
ken@origin /tmp/grep-3.4 $ldd src/grep
linux-vdso.so.1 (0x7ffe0a7b4000)
libpcre.so.1 => /lib/libpcre.so.1 (0x7fe15f089000)
libc.so.6 => /lib/libc.so.6 (0x7fe15ee96000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7fe15ee74000)
/lib64/ld-linux-x86-64.so.2 (0x7fe15f123000)

I don't have libsigsegv on this new system at the moment.

On a 9.0 system where I do have libsigsegv:

ken@deluxe /tmp/grep-3.4 $ldd src/grep
linux-vdso.so.1 (0x7ffe55ae7000)
libpcre.so.1 => /lib/libpcre.so.1 (0x7fec26b78000)
libsigsegv.so.2 => /usr/lib/libsigsegv.so.2 (0x7fec26b72000)
libc.so.6 => /lib/libc.so.6 (0x7fec2698)
libpthread.so.0 => /lib/libpthread.so.0 (0x7fec2695d000)
/lib64/ld-linux-x86-64.so.2 (0x7fec26c15000)

So I have no idea why your build linked to libgcc_s.  I didn't
install either version, but the tests seemed ok (7 skipped without
libsigsegv, only 6 skipped with it).

ĸen
-- 
The beauty of reading a page of de Selby is that it leads one
inescapably to the conclusion that one is not, of all nincompoops,
the greatest.-- du Garbandier
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page