[blfs-dev] Help blfs
zarniwhoop at ntlworld.com
Sun Aug 12 18:27:30 PDT 2012
On Mon, Aug 13, 2012 at 12:38:56AM +0200, Jean-Philippe MENGUAL wrote:
> As you may know, I have helped this project since 2008, with
> translations. With Denis and other contributors, we translate into
> French LFS, BLFS books, and also others.
> But with Gnome3 and GUI evolutions, I start being fed up with
> traditional distros, especially I feel I cannot help them as their
> contribution processes are so complex. I feel I could use (I'm building)
> and help blfs now.
> But for that, I need methodological help. I wonder how editors can
> maintain up-to-date so much areas and packages. At every new LFS
> release, do you build again a new system? And do you re-install all
> packages you need? It's very, very long time. So do you use at least
> some scripts? Or some system to home a common workspace where you work
> beyond your own machine?
I assume that *everyone* who continues to use LFS and BLFS will
eventually develop their own scripts - without scripting, it is just
too painful. Usually, I build several new LFS systems each year,
then use them to build all of my current desktop. For my server, I've
tended to be in no hurry to update (e.g. it uses linux-3.0 headers,
unlike the book, with a 'stable' 3.0 kernel), but I'll probably try
building 7.2 on my server if I have time.
With the recent amount of change in BLFS, it isn't possible to keep
*everything* in my build up to date, so sometimes I just keep building
what I know worked on the previous build - even so, I often hit issues
caused by updates in LFS. Generally, we just do our best.
For example, I started to think about my next build about a week ago.
First, I added the updates from BLFS which I had noticed (ok, only
as far as when I build firefox - once I get there, I can look at
what has changed in the meantime, and also google for help on any
problems), then I started looking at the LFS revisions since my last
build [ r9882, in June ] - at the moment I'm still sorting out what
to do for glibc (the separation of tzdata makes a mess of my current
From time to time, I've updated my buildscripts at
http://www.linuxfromscratch.org/~ken/desktop-builds/ but the last
set were last November. I've done an updated build-order from this
April, but BLFS is now generally up-to-date and it doesn't seem a
valid use of my time to update these scripts - in any case, quite a
lot of what I do is subtly different from what is in the book
(principally, /sources is an nfs mount, so I don't build in it, and
also I have an aversion to static libraries :)
Some people upgrade everything on a current system, others of us
only upgrade if we think there are security or functionality issues,
but hopefully, those of us who do that will build new systems fairly
> I'm fixing my kernel panic issues and I'll have my LFS 7.1 done. And I
> plan to use it. Would it be enough to help? I plan helping because I
> imagine that in some areas, updating packages doesn't imply changing so
> much instructions. Moreover, what's your method to know packages
> contents? Does the edguide book say that? Or this provided with LFS?
If a package supports a DESTDIR install, I do that when I'm
editing, then try to find descriptions for any new programs or
libraries - sometimes, I have to pass on what they do, it often
comes down to whether I can find the right google search terms.
For QT and similar packages, INSTALL_ROOT,
I normally build and install a package, then test that it works,
before I worry if it has a testsuite, Potentially, this means that
I will miss packages where it needs to be installed before the
testsuite will run [ I found a few when I was merging Wayne's
gnome-3.2 stuff, but only because I don't normally use the affected
packages. I'm sure there will be others that need to be installed
before testing. ] Remember, I share the view that testsuites are
not generally important!
> Finally, how can I start contributing? What's the best approach with
> submitting write patches (or packages update)? Where can I submit? etc.
To -dev, as patches to the book's xml. Alternatively, for package
updates, anyone can try raising a ticket when they know the new version
exists, and adding any ocmemnts after they have built and used it.
> Once I've my LFS, I plan to install things to help in blfs-support, if I
> have the good level for that. Indeed, I know to build, but I do not know
> to program.
Mostly, it isn't about programming. If you are really at the
bleeding edge (typically, latest development LFS) you might hit new
problems, but mostly somebody has already encountered the problem,
and found a way to solve it. I suppose one could argue that turning
a patch into a sed command which does the same thing is programming.
With your experience in using the xml when translating, I suspect
you will have a head start on the rest of us! From experience, BLFS
editing can go ok for several weeks, then fall apart completely when
I make what I think is a minor change. Staring at 'svn diff' will
hopefully explain what I have done wrong, but I suspect you already
know that :)
> I hope I can help and try contributing, as, since Andy gone, indeed BLFS
> staff is smaller.
> Thanks for all your answers. I hope I'll help usefully. Otherwise, I'll
> be happy to have tried.
Your comments (when you have found issues while translating) have
been useful. I hope you will have more to contribute.
das eine Mal als Tragödie, das andere Mal als Farce
More information about the blfs-dev