On Sat, 2020-11-28 at 03:09 +0000, Ken Moffat wrote:
> Hi,
>
> Pierre, and probably some other people here, will know that I use my
> own buildscripts, and in many cases I drop recommended dependencies
> (with added switches where needed), or add optional dependencies
> (ditto), as well as other variations such as NOT building in
> /sources (for me, that is an nfs mount, I want to build on a local
> disk).
>
> It occurs to me that I can probably get another machine (ryzen
> based, separate question about nouveau on -chat) with plentiful
> processors and memory to mostly use for getting a step nearer
> towards continuous integration (i.e. as a first step build LFS for
> the machine, then try variations of desktop sysv systems to see what
> breaks). Whether I can diagnose the breakages is somewhat less
> likely, these days I'm usually late enough in testing a fresh build
> that often someone has already found the problem.
>
> However, the online documentation appears to be somewhat outdated
> (that is perfectly normal in linux, of course), so I'll start by
> asking three questions:
>
> 1. Can jhalfs reliably build desktop BLFS in chroot (things like
> JS78 and firefox) ? I used to almost-always build on the freshly
> booted system unless I was expecting problems, but nowadays I find
> it far more convenient to build most, or all, of my normal desktop
> in chroot because the build is so slow and if things break I'm naked
> without my browsers ;-) In the book we have notes on environment
> (SHELL=/bin/sh etc) but has anybody tried this or is it actually
> broken in jhalfs ?
>
Sorry, but for me, the answer to the "has anybody..." question
(translated to "have you...") is "no"... (and the answer to "actually
broken..." is probably "yes", since there is no provision for that in
jhalfs). The only packages that are built in chroot when I do a jhalfs
build are~:
libxml2
libxslt
DocBook DTD 4.5
lynx
sudo
wget
GPM
subversion
and their required and recommended dependencies (a dozen more
packages). When all that is built, I switch to the fresh system, using
lynx when I need a browser (not always easy, specially on sourceforge
or github).
> 2. Does jhalfs easily support -jN builds ? I could not see that
> mentioned in the svn docs, apologies if I've missed it. My plan
> would probably be to build a base LFS system (initially using my own
> scripts to tune it for the box in terms of things like firmware and
> kernel config), image that, then use it to build "minimal" Xorg
> (minimal in jhalfs terms, probably builds a lot of things that I
> currently ignore at that stage). Then image that and build
> different desktop environments.
-jN is implemented for make (through MAKEFLAGS, which is set in
envars.conf). I guess you can set NINJAJOBS in the environment (can be
added to envars.conf).
>
> Using -jN and only building one system at a time is important
> because of things like rust. I've spent a few days trying to use
> libcgroup on sysv (rust apparently accepts cpu restrictions from
> that) but given up in disgust (it's too hard to configure). So
> anytime I build rust it thinks it can use N+2 cores of my machine.
> That also means that a big machine will need a lot of memory.
As you might guess, there is nothing in jhalfs concerning either cargo
or libcgroup. I think I had once to use the
/sys/devices/system/cpu/{on,off}line files to allow building rust, but
I haven't done that lately (4-core haswell with HT and 16GB RAM, but
the rust problem could have come from building in a VM with not much
allocated memory).
>
> Of course, an alternative use for a build machine is to allocate N
> systems and build something on each of them using -j1 (just to test
> if it builds). Because of rust (and ninja in qtwebengine) I don't
> think I'll ever do that.
>
> 3. I recall that DejaVu is recommended as a runtime dependency for
> some things. I'm sort-of thinking about building desktops and then
> seeing if they seem to work - I suppose I'd have to provide my own
> extra scripts to install dejavu ? If so, I might cheat and just
> copy the TTFs from local storage into /usr/share/fonts.
That's what I do. When I need a ttf font, I just copy paste
instructions from the Xorg ttf page (using lynx...).
>
> At this point I have doubts about all of this, even about what will
> be a useful spec for the machine (even how much local storage will
> be useful, so I don't think this is going to happen very quickly.
I think the most storage consuming package is qtwebengine, which can go
up to more than 2GB per job (but how many jobs consume that? Bruce
seems to be able to build at -j22 with 32GB RAM). Other packages do not
seem to go much higher than 1GB per job.
>
> TIA
As a general warning about jhalfs (for BLFS): the book instructions are
for a first build, and there are not more than a dozen packages needing
editing the scripts in that case. But when rebuilding, there are many
more problems (one example is when a system group or user has already
been created, it cannot be created again, so the instructions for that
have to be commented out). Also, usually, you do not want to run the
configuration part again (specially instructions of the form:
"cat >> somefile << EOF", because then "somefile" would contain several
times the same stanza. Not usually a problem, but not clean). If you
wipe out everything that has been done after "minimal" Xorg, several of
those annoyances would disappear, though. Still, some packages do need
editing the scripts... Actually, kf5 and plasma scripts are among
those. Complete automation has not been reached yet (not enough
information in the book XML, I'd say).
Also, tests and documentation building do not work well with jhalfs,
unless optional dependencies are enabled, but even in that case, some
dependencies like sphinx are not in the book (and so are not built
unless a script is added). The problem with optional deps is that they
lead to a lot of circular deps, and jhalfs decision is not always sound
when that occurs.
BTW, jhalfs for LFS is Ok. CFLAGS and the like can be passed through
the "optimization" part (not very well documented), and -jN is an
option in one of the submenus.
Not sure I've helped you make your mind, let me(us) know how you
progress with that project.
Regards
Pierre
--
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
