Re: [blfs-dev] Help?
Merell L. Matlock, Jr. wrote: Good evening! I'm not a programmer, and I have a better chance winning the lottery than deciphering/troubleshooting code. That said, is there anything I can volunteer to do to help with the upcoming BLFS-7.5 testing? I completed a (B)LFS-7.4 system, and was comfortable enough to dump everything else off of my HDD. I got a lot of information and insights from the archives, and would like to try to repay the previous hard work somehow. The best help you can give is to build LFS-7.5-rc1 when we release it and then continue with BLFS-7.5-rc1 when that is released. Then any feedback would be very helpful. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Help blfs
On 13.8.2012 0:38, 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? The last LFS I've built, 7.1 minus glibc 2.14 (I used 2.13 back then) was built in January this year. I used it as my production machine for at least 6 months or so untill I got back to Debian Sid few days ago (damn laptop and binary drivers). But, for package updates I used that system. I upgraded or added package on that one system, I had my package management, but no scripts. Everything was built manually. I also tend to build more or like everything from one source package, thus expanding far beyond blfs itself. If I get stuck, I consult either Debian's patch tracker or source files, ArchLinux's packages svn or Gentoo portage source files. I check for package dependencies either by reading autotools files or rather just ./configure output. I don't feel the urge to rebuild everything once in a while unless some big change happens. 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? Finally, how can I start contributing? What's the best approach with submitting write patches (or packages update)? Where can I submit? etc. There is an editors guide at http://www.linuxfromscratch.org/blfs/edguide/ Read it and if you like, send patches to the mailing lists. It can be anything. From package update, to instructions fixes and adding patches. You'll have to attach the patches for package seperately from patches for xml. 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. 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, -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Help blfs
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. Any help you can give would be appreciated. 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? For my normal system, I don't upgrade much. I generally only upgrade when there is a problem of some sort. That said, I recently did a complete upgrade. See my write-up of what I did: http://www.linuxfromscratch.org/~bdubbs/files/updating-lfs.html I do have another system dedicated to LFS development work. I do most of the development there via ssh, but can access the physical keyboard/monitor when needed. It may be surprising, but that's not required a lot. Generally it's needed to test a new kernel or an xorg build. Running an X based app over ssh works fairly well, but audio needs to be from the actual system. 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? Yes, but it would be helpful to use glibc-2.16. I'll have all the current tickets in LFS needed for LFS-7.2 done in a couple of days so it would be good if you could use that. 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? The Editor's Guide is useful, but limited. I generally use make DESTDIR=/tmp/packagename/install install when doing a test build and then look at the directory listing there. A plain 'make install' will put the files in place. This doesn't always work, so the package procedures have to be examined individually. I do keep scripts for each package. Each editor generally has his own preferences, but for an example, see the files attached to http://linuxfromscratch.org/pipermail/blfs-dev/2012-May/023334.html Finally, how can I start contributing? What's the best approach with submitting write patches (or packages update)? Where can I submit? etc. Either is good. Patches are better. After you get a good feel for what is needed, I can give you direct commit privileges. 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. Programming is quite helpful, but not required. Remember that scripts are programming too. I hope I can help and try contributing, as, since Andy gone, indeed BLFS staff is smaller. Thanks you for what you've done in the past. Any support you can give will be helpful. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Help blfs
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
Re: [blfs-dev] Help wanted
On Fri, Mar 23, 2012 at 1:33 PM, Bruce Dubbs bruce.du...@gmail.com wrote: Thanks. Note that it's a little counterproductive to compress a 2K file. -- Bruce I totally agree, but it was just easier for me to get it off of the computer that way at the time. Jonathan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Help wanted
Bruce Dubbs wrote: Which of the above scripts/related packages should be removed from the book? I suggest we remove the soprano bootscript. AFAIK it is only used by KDE4, which starts the soprano server as needed. -Ragnar- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Help wanted
Ragnar Thomsen wrote: Bruce Dubbs wrote: Which of the above scripts/related packages should be removed from the book? I suggest we remove the soprano bootscript. AFAIK it is only used by KDE4, which starts the soprano server as needed. The page has a note that it will be started by kde4. I'd recommend that we leave it for the user that might want to use it in a non-kde4 environment. We don't know of any apps that do that right now, but since it's there, I think we ought to leave it. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Help wanted
Bruce wrote: Mar 20 2008 gdm I'm pretty sure I already cooked one up for gdm, I'll check the machine tomorrow as I have some free time! -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Help wanted
Bruce wrote: I've been taking a look at the blfs bootscripts and note that several have not been updated for the LFS 7.0 bootscripts. Some have not been updated in a very long time: Mar 6 2008 autofs Feb 16 23:39 avahi Aug 1 2005 exim Aug 1 2005 fam- package removed Mar 20 2008 gdm Mar 20 2008 haldaemon - package removed Aug 1 2005 heimdal Aug 1 2005 kerberos Aug 1 2005 nas- package removed Sep 10 2006 openldap1 Sep 10 2006 openldap2 - commented out in book Aug 1 2005 postgresql Aug 1 2005 proftpd Apr 24 2006 qpopper Aug 1 2005 sendmail Jul 18 2011 soprano Jul 18 2011 virtuoso Aug 1 2005 winbind - samba Aug 1 2005 xinetd - package removed I can remove the fam, hal, nas, openldap2, and xinetd bootscripts from the repository and bootscripts Makefile, but would like some help with the others. In some cases we should probably remove the package and the associated bootscript. Some of the packages (e.g. virtuoso, postgresql) have been recently updated without the bootscript update. Which of the above scripts/related packages should be removed from the book? Does anyone want to volunteer to update some of these packages and bootscripts? I can take a look at soprano and virtuoso. -Ragnar -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Help wanted
On Mon, Mar 19, 2012 at 7:43 PM, Bruce Dubbs bruce.du...@gmail.com wrote: I've been taking a look at the blfs bootscripts and note that several have not been updated for the LFS 7.0 bootscripts. Some have not been updated in a very long time: Mar 6 2008 autofs Feb 16 23:39 avahi Aug 1 2005 exim Aug 1 2005 fam - package removed Mar 20 2008 gdm Mar 20 2008 haldaemon - package removed Aug 1 2005 heimdal Aug 1 2005 kerberos Aug 1 2005 nas - package removed Sep 10 2006 openldap1 Sep 10 2006 openldap2 - commented out in book Aug 1 2005 postgresql Aug 1 2005 proftpd Apr 24 2006 qpopper Aug 1 2005 sendmail Jul 18 2011 soprano Jul 18 2011 virtuoso Aug 1 2005 winbind - samba Aug 1 2005 xinetd - package removed I can remove the fam, hal, nas, openldap2, and xinetd bootscripts from the repository and bootscripts Makefile, but would like some help with the others. In some cases we should probably remove the package and the associated bootscript. Some of the packages (e.g. virtuoso, postgresql) have been recently updated without the bootscript update. Which of the above scripts/related packages should be removed from the book? Does anyone want to volunteer to update some of these packages and bootscripts? -- Bruce -- Funny enough, was about to give AutoFS for a whirl and give myself an automatically mounting /media/cdrom drive. (A dream I've had for about 8 years, but never made it happen for some reason) I was going to do some research on avahi, but no promises proftpd, I can take as well -- Nathan Coulson (conathan) -- Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Help wanted
Nathan Coulson wrote: Mar 6 2008 autofs Feb 16 23:39 avahi Aug 1 2005 exim Aug 1 2005 fam- package removed Mar 20 2008 gdm Mar 20 2008 haldaemon - package removed Aug 1 2005 heimdal Aug 1 2005 kerberos Aug 1 2005 nas- package removed Sep 10 2006 openldap1 Sep 10 2006 openldap2 - commented out in book Aug 1 2005 postgresql Aug 1 2005 proftpd Apr 24 2006 qpopper Aug 1 2005 sendmail Jul 18 2011 soprano Jul 18 2011 virtuoso Aug 1 2005 winbind - samba Aug 1 2005 xinetd - package removed Funny enough, was about to give AutoFS for a whirl and give myself an automatically mounting /media/cdrom drive. (A dream I've had for about 8 years, but never made it happen for some reason) I was going to do some research on avahi, but no promises proftpd, I can take as well Excellent! I did take a look at autofs a while back and found openldap to be required for 5.0.6. It may only be a build requirement. I don't know if there is a run time requirement or not. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
