On Mon, Aug 13, 2012 at 12:38:56AM +0200, Jean-Philippe MENGUAL wrote: > Hi, > > 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 glibc-config script). 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 often. > 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. > > Regards, > Your comments (when you have found issues while translating) have been useful. I hope you will have more to contribute. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
