[blfs-support] Reducing my contributions

[Ken Moffat]

I find it hard to believe that I can ever happily run anything
except LFS (sysv), but I need to step further back.

The last time I took a real break (6.8 -> 7.0, I think), I recall
that the bootscript changes were pretty disastrous for my use cases.
But I've more-than overcommitted the time I spend on this and I
no-longer seem to be competent to fix things (e.g. chromium).

And current versions seem to be getting worse instead of better
(that is particularly prompted by keyboard problems in the past
hours which _might_ be down to libinput, but could equally be down
to bad changes in the kernel itself, and also to having an argument
with a harfbuzz maintainer). Python - avoid it if you can.

So, for my own sanity, I think it is necessary that I step back (a
bit). For the tickets I have taken, I intend to complete them with
the possible exception of libinput - depending on any responses on
the Xorg list.

I continue to use firefox, and to test -beta versions (because
discovering the necessary build changes from one release to the next
is a PITA if you have not looked at changes during the betas), so I
intend to maintain that (plus any updates it requires, if nobody
else does them), and also to keep an eye on texlive source (I
continue to believe that using the binaries now that we don't have
to use them to bootstrap the source is contrary to what BLFS is
about). But I don't expect to spend much energy looking at breakage
from new versions of poppler. If that breaks things such as texlive
again, not my problem until I want to build a new texlive
installation.

Oh, and while I'm mentioning firefox, there is bad news for Tim: the
option to disable stylo is no longer recognized in the current 61
beta, so clang will be required.

And whilst I continue to think that using system graphite2 and
harfbuzz in firefox is a good idea, if upstream continue to think it
is not important then I may drop that: upstream seem to think that
rust is the bee's knees, although debian have so far failed to make
reproducible builds of it on jenkins (required ports in use) and I
suspect they will find it is horribly variable.

We (the editors) have tried to encourage people to contribute. But
few people have stepped up, and they are currently MIA (real life -
it gets in the way). To anybody who is thinking about contributing,
but is scared of the xml (and yes, editing that *can* hurt), the
process is not as bad as it used to be: Pierre's template works
well for new packages, and errors are usually easy to spot if you
don't change much at a time, look at the first error message, and
perhaps use 'svn diff | less' to see what you changed in existing
pages.

As I have said before, docbook works if you build the following (and
any deps they require) in this order:

sgml-common
OpenSP
openjade
docbook31
docbook45
dsssl
SGMLSpm
docbook-utils
libxml2
libxslt
docbook-xml
docbook-xsl
xmlto

Are *all* those necessary ? Probably not - but this works for
building the book.


Tha tim, am fiadh, an coille hallaig (Somhairle MacGill-Eain)

(that *is* deliberately obscure, but just be grateful that I
didn't quote from Glac A' Bhàis)

ĸen

[Bruce Dubbs]

Post by Ken Moffat
I find it hard to believe that I can ever happily run anything
except LFS (sysv), but I need to step further back.

Thank you for the heads up. I completely understand and greatly
appreciate all you have contributed to this project.

I will also be away for a while starting June 27th. It will be about
five weeks. In that time I still plan to update LFS (system V only),
but for BLFS I will probably only only update the tickets as new package
versions are released.

When I get back in August, I intend to make major deletions in BLFS
including gnome, lxqt, chromium, in addition to other individual
packages I consider to be of marginal or infrequent use.

The next release of LFS/BLFS is scheduled for September, but unless
someone steps up, that will not include the systemd versions of the books.

-- Bruce

[Yang Bo]

Hello, Ken/the whole LFS community:

First I wanna say that I really appreciate your effort and the whole
LFS project, without which I wouldn't image I could build my own Linux
distribution. [1] But, I do wonder, can the burnout you feeled be avoided?

Sometimes I'm indeed surprised by the effort put into compiling a package
with system libraries instead of the bundled ones when reading BLFS,
will it be the end of world if one does the other way around? I know
it certainly isn't for me, since I never compile any package with the
`--with-system-*' flag, and I have been happily doing it this way for
the last couple years without any problem. But whether it's right or
not is really not the point here, many things in the BLFS book are
too opinionated, if one is determined enough to build his own Linux
distribution, one is probably also opinionated enough. And the worst is
that writing those opinions and details and keep them up to date will
drain you.

I wish BLFS could be more brief, more interesting, and less cumbersome.
I know it can since I only wrote 100+ lines of configuration to build an
entire Linux distribution [1], I really don't think it's necessary to give
detailed compiling instructions for every single package BLFS includes,
this repetitive task is the devil, it takes out all the pleasure and
makes you hate what you do, and as you put it, takes away one's sanity.

Instead of those detailed recipes, one could simply write about what
build system this package uses, which part of the README file contains
a description of the dependencies, what other files under the source
directory are worth reading, what're some interesting history/stories
about this package, how does this package connects to other packages,
what're some simple demonstrations of the things this package could
do. I think it's much more informative and interesting to write this way,
and this is creative instead of repetitive.

Finally, I don't know how the BLFS community feels about an official
package manager, I made a post to the LFS mailing list about the package
manager [1] I created to manage my own Linux distribution a couple month
ago, it uses the package by difference method and works with any package
without exception, I still think it's the perfect package manager for
BLFS, even (to my surprise) it got no response. It enables one to easily
create a binary package from compilation, remove a package, or restore a
removed package from the binary package created, incrementally rebuild
a system, transfer compiled packages to another machine. It makes BLFS
much easier and it saves much effort. For example, since it has complete
knowledge over what files are installed, elf binaries/shared libraries
could be automatically stripped, .la files could automatically be removed,
man pages could also be automatically be compressed, instead of giving
instructions to do these things mannually. BLFS could be much more with
it, it could be THE polymorphism Linux distribution of everyone that
wants to create his own.

I mentioned it again since there's now difficuly in the BLFS development,
I want to provide my input and potentially a new and interesting direction
for the development process. I still consider [1] as my contribution to
the BLFS community, even if it's not recognized or anticipated, and I
bet I'm not the only one, so you really shouldn't be sad that there're
few contributors, I'm sure there're many people inspired by BLFS and
created their own projects, just like I did, they're contributing,
just not directly, you should be proud of what you did.

[1] https://github.com/057a3dd61f99517a3afea0051a49cb27994f94d/rslinux

Sincerely,
Yang Bo.

[Paul Rogers]

Dang, well, good luck. You will be missed.

[Michael Shell]

On Mon, 25 Jun 2018 02:53:59 +0100

Post by Ken Moffat
I find it hard to believe that I can ever happily run anything
except LFS (sysv), but I need to step further back.

Ken,

Well, thanks so much for all your help. I've said it before, but I
believe that LFS/BLFS really is an important public service to the
world, and if it were possible, I think it would be fair for all
the people who contributed to the LFS/BLFS project would get some
type of (substantial) payment.

As far as Firefox goes, I sure hope someone either comes out with
a better/simplier/saner browser or that the existing alternative
browser project reach a point where they can replace it (well,
that does depend on the needs of each specific user).

Sometimes I've encountered bugs/changes in firefox in which I
suspect the developers are playing little jokes on us. Sure
seems that way sometimes.


Cheers and take care,

Mike