Re: [blfs-support] BLFS-Basic
Chey here, I'm willing to help Doug as he needs it until we get this next release out. Him and I rebuilt my machine today that I was going to originally use before we left, so I'm going to be building that machine out over the next several days. I'm willing to do whatever is necessary to help get one more release out with things as they are right now. On Wed, Jul 11, 2018 at 4:15 PM Paul Rogers wrote: > > > currently in there, for one more release at minimum. Consistency is > the > > > thing that is the most important to me, and one more release would > also > > > give people who use LFS in production the time to adapt their systems > > > for the new changes. > > I do understand the problem, but I forsee one pretty big hassle > forthcoming. The one thing to say about the existing book is: one is quite > certain all the packages are consistent with each other. Split in two, or > even more (networking & GUI stuff suggests themselves), the idea presents > itself: different release readiness for different sections, and separate > development tracks probably lead to package version inconsistencies. If > one decides to enforce keeping them in-step, what really have you gained? > > This is somewhat the situation I found when I came aboard with 4.1: BLFS > was still 1.0! It jumped from 1.0 to 5.x. > > Perversely, perhaps one should explode the book altogether! Have each > package separate, on its own development track, then have wget and make > files. Shift entirely to the sort of thing in the SVN versions. Granted, > everybody would likely have a unique system build, making support very > troublesone. > > -- > Paul Rogers > paulgrog...@fastmail.fm > Rogers' Second Law: "Everything you do communicates." > (I do not personally endorse any additions after this line. TANSTAAFL :-) > -- > http://lists.linuxfromscratch.org/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
> > currently in there, for one more release at minimum. Consistency is the > > thing that is the most important to me, and one more release would also > > give people who use LFS in production the time to adapt their systems > > for the new changes. I do understand the problem, but I forsee one pretty big hassle forthcoming. The one thing to say about the existing book is: one is quite certain all the packages are consistent with each other. Split in two, or even more (networking & GUI stuff suggests themselves), the idea presents itself: different release readiness for different sections, and separate development tracks probably lead to package version inconsistencies. If one decides to enforce keeping them in-step, what really have you gained? This is somewhat the situation I found when I came aboard with 4.1: BLFS was still 1.0! It jumped from 1.0 to 5.x. Perversely, perhaps one should explode the book altogether! Have each package separate, on its own development track, then have wget and make files. Shift entirely to the sort of thing in the SVN versions. Granted, everybody would likely have a unique system build, making support very troublesone. -- Paul Rogers paulgrog...@fastmail.fm Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
On 07/11/2018 09:07 AM, Ken Moffat wrote: On Wed, Jul 11, 2018 at 11:50:06AM +0100, Hazel Russman wrote: I have done editing before; I was a proofreader for the Open Document team for years. But I have *zero* experience of svn and I don't understand docbook/xml at all. Still, if there are any simple jobs that I could do to help, I would be willing. I've been using LFS for some years now and it's probably my favourite distro. Maybe it's time to give something back. I was going to point you, and anybody else who might be interested, to the BLFS editor's guide - but the online version is slightly out of date (I added a bit to chapter 6 a few months ago and I see that is not in the online version). I'll try to get that updated later today. Nevertheless, it gives the basics, including svn access, and is at http://www.linuxfromscratch.org/blfs/edguide/ For rendering the beastie, I build all of chapters 50 and 51 _except_ itstool. Let me describe here a summary of using svn and a very brief intro to rendering the book's dockbook sources. Overall svn consists of the commands: svn [operand] where the most useful arguments are checkout, commit, add, mv, and diff. The basic checkout is svn co svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK/ BLFS For editors with commit privileges, an account is needed on the server (ask me if you want that). IN that case the checkout argument is svn+ssh:// The above will create a directory BLFS and the source is there. To build the book look in the INSTALL file in the source. It documents the packages needed: libxml2 libxslt DocBook XSL Stylesheets-1.68.1 DocBook XML DTD-4.5 tidy To create a local copy of the html, just run 'make'. For the systemd version of the book run 'make REV=systemd'. The output, by default, will be $(HOME)/public_html/blfs-book or $(HOME)/public_html/blfs-systemd. - Editing Docbook sources is really pretty easy. Just use a text editor (please, do not embed tab characters. For vim, use ':set et'). If you've ever edited html, Docbook will be very easy. Just look at the current pages for examples. If you make changes and run into problems, just ask. That's the way to learn. For editing (mainly used when adding new pages, but a useful reference) there is a template/ directory in the book's XML source. Bruce: the online version is at /srv/www/www.linuxfromscratch.org/blfs/edguide : which repo has that, please ? I've updated the website now: http://www.linuxfromscratch.org/blfs/edguide/ -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
On Wed, Jul 11, 2018 at 11:50:06AM +0100, Hazel Russman wrote: > > I have done editing before; I was a proofreader for the Open Document > team for years. But I have *zero* experience of svn and I don't > understand docbook/xml at all. Still, if there are any simple jobs that > I could do to help, I would be willing. > > I've been using LFS for some years now and it's probably my favourite > distro. Maybe it's time to give something back. > I was going to point you, and anybody else who might be interested, to the BLFS editor's guide - but the online version is slightly out of date (I added a bit to chapter 6 a few months ago and I see that is not in the online version). Nevertheless, it gives the basics, including svn access, and is at http://www.linuxfromscratch.org/blfs/edguide/ For rendering the beastie, I build all of chapters 50 and 51 _except_ itstool. For editing (mainly used when adding new pages, but a useful reference) there is a template/ directory in the book's XML source. Bruce: the online version is at /srv/www/www.linuxfromscratch.org/blfs/edguide : which repo has that, please ? ĸen -- Keyboard not found, Press F1 to continue -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
On Tue, 10 Jul 2018 23:44:24 +0100 Ken Moffat wrote: > On Tue, Jul 10, 2018 at 02:23:38PM -0700, Jalus Bilieyich wrote: > > Having multiple parts of the book being split up and teams working > > on each part is a good idea in my opinion. > > > > Except at the moment we have one small team and in general people > pick things they think they can handle. In my case, a lot of the > things I care about are spread throughout the 'Basic' and 'Advanced' > parts, and I'm sure the other editors will say the same. So I'm not > convinced that separate teams is going to work. > > For the moment I'm mostly stepping aside, as previously noted. > > I hope to keep an eye on firefox (past experience suggests that > trying to pick up the new version only when it is released is too > painful), and almost every release has CVE fiexes, even 61.0 did > (although those were not initially in the Release Notes). > > Eventually I hope to be able to devote a bit more time to this, but > for the next few months that is now less likely. > > But the big problems as I see them are: > > · lack of people building the development book and finding issues > > · lack of people willing and able to edit > > And of those, the second is the greater problem. > > So, since we are now hopefully looking at longer-term changes, > anybody else got other suggestions for changed format/process ? > > Please ? > > ĸen I have done editing before; I was a proofreader for the Open Document team for years. But I have *zero* experience of svn and I don't understand docbook/xml at all. Still, if there are any simple jobs that I could do to help, I would be willing. I've been using LFS for some years now and it's probably my favourite distro. Maybe it's time to give something back. -- If any members of GCHQ are reading this, shame on you! I fought for your right to belong to a trade union and now you are taking away my right to privacy? Hazel Russman -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
On Tue, Jul 10, 2018 at 05:52:36PM -0500, Bruce Dubbs wrote: > On 07/10/2018 05:46 PM, Douglas R. Reno wrote: > > > Would this be the time to suggest a change in policy on tickets? I'd > > like to see tickets have the changelog for the package and security > > updates marked as such. It would make people's lives a lot easier. > > I'm not sure what you mean Douglas. Most of the time we add the release > notes or change log to the tickets. However some packages do not say what > changed (e.g. libinput). > > -- Bruce > Addressing only the security fixes - I usually skim through the security updates at lwn.net, looking to see if anything I use ought to be updated. Many of those turn out to be for old versions in debian (some versions - others can be bleeding edge), ubuntu, SuSe, Centos, and can be ignored. But from time to time I see things like firefox-61 : I kept the ticket open until the release notes were out, and at that time no CVE fixes were mentioned. Later Arch flagged it as a security update and the CVEs had been added to mozilla's Release Note. For examples like that, the options seem to be: 1. do nothing, svn has already been updated. 2. belatedly note the CVE fixes somewhere in the already-closed ticket. 3. set up a separate page on the website (it could be ongoing, i.e. keep details for a longer period than just the next release), also covering LFS, with details such as: firefox-61.0 : various CVE fixes FuBar-88.1 : various CVE fixes firefox-60.0.2 : various CVE fixes ... LFS-8.2 released (no point at the moment in looking back beyond that) For many packages, it is not just one CVE fix (or alternatively, e.g. openssl, curl, they have their own notifications which might be public before the CVE details), so maybe just describe the whole page as 'security fixes'. But there is also the question of whether a particular vulnerability is likely to affect our users. No doubt some people will say that in a rolling release we should just rebuild everything on our own system(s) in case it fixes vulnerabilities. But that seems like a waste of electricity, and therefore a contribution to global warming. ĸen -- Keyboard not found, Press F1 to continue -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
On Tue, Jul 10, 2018, 5:52 PM Bruce Dubbs wrote: > On 07/10/2018 05:46 PM, Douglas R. Reno wrote: > > > Would this be the time to suggest a change in policy on tickets? I'd > > like to see tickets have the changelog for the package and security > > updates marked as such. It would make people's lives a lot easier. > > I'm not sure what you mean Douglas. Most of the time we add the release > notes or change log to the tickets. However some packages do not say > what changed (e.g. libinput). > >-- > I have seen it with the most recent package updates. Most of the time, depending on the editor, the changes are listed. The samba, php, etc. updates that were recently completed were not listed with changes. Another thing - would it be worth adding a page to tell potential contributors how to contact you (Bruce) regarding contributions? I dont know if anyone here has heard of Discord, but there is a LFS discord ran unofficially there with lots of people who use it daily and could possibly contribute. I lurk there occasionally. It can be used over both a web browser or a desktop application. > -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
On 07/10/2018 05:46 PM, Douglas R. Reno wrote: Would this be the time to suggest a change in policy on tickets? I'd like to see tickets have the changelog for the package and security updates marked as such. It would make people's lives a lot easier. I'm not sure what you mean Douglas. Most of the time we add the release notes or change log to the tickets. However some packages do not say what changed (e.g. libinput). -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
On Tue, Jul 10, 2018, 5:44 PM Ken Moffat wrote: > On Tue, Jul 10, 2018 at 02:23:38PM -0700, Jalus Bilieyich wrote: > > Having multiple parts of the book being split up and teams working on > > each part is a good idea in my opinion. > > > > Except at the moment we have one small team and in general people > pick things they think they can handle. In my case, a lot of the > things I care about are spread throughout the 'Basic' and 'Advanced' > parts, and I'm sure the other editors will say the same. So I'm not > convinced that separate teams is going to work. > > For the moment I'm mostly stepping aside, as previously noted. > > I hope to keep an eye on firefox (past experience suggests that > trying to pick up the new version only when it is released is too > painful), and almost every release has CVE fiexes, even 61.0 did > (although those were not initially in the Release Notes). > > Eventually I hope to be able to devote a bit more time to this, but > for the next few months that is now less likely. > > But the big problems as I see them are: > > · lack of people building the development book and finding issues > > · lack of people willing and able to edit > > And of those, the second is the greater problem. > > So, since we are now hopefully looking at longer-term changes, > anybody else got other suggestions for changed format/process ? > > Please ? > > ĸen > -- > Keyboard not found, Press F1 to continue > -- > http://lists.linuxfromscratch.org/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > Would this be the time to suggest a change in policy on tickets? I'd like to see tickets have the changelog for the package and security updates marked as such. It would make people's lives a lot easier. > -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
On Tue, Jul 10, 2018 at 02:23:38PM -0700, Jalus Bilieyich wrote: > Having multiple parts of the book being split up and teams working on > each part is a good idea in my opinion. > Except at the moment we have one small team and in general people pick things they think they can handle. In my case, a lot of the things I care about are spread throughout the 'Basic' and 'Advanced' parts, and I'm sure the other editors will say the same. So I'm not convinced that separate teams is going to work. For the moment I'm mostly stepping aside, as previously noted. I hope to keep an eye on firefox (past experience suggests that trying to pick up the new version only when it is released is too painful), and almost every release has CVE fiexes, even 61.0 did (although those were not initially in the Release Notes). Eventually I hope to be able to devote a bit more time to this, but for the next few months that is now less likely. But the big problems as I see them are: · lack of people building the development book and finding issues · lack of people willing and able to edit And of those, the second is the greater problem. So, since we are now hopefully looking at longer-term changes, anybody else got other suggestions for changed format/process ? Please ? ĸen -- Keyboard not found, Press F1 to continue -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
Having multiple parts of the book being split up and teams working on each part is a good idea in my opinion. On 7/10/18, Bruce Dubbs wrote: > On 07/10/2018 07:46 AM, Douglas R. Reno wrote: > >> I'm of the opinion that we should do one more release of the book as it >> is and then discuss things after that. I'm willing to put in as much >> time as needs to be put in to keep everything in the book that is >> currently in there, for one more release at minimum. Consistency is the >> thing that is the most important to me, and one more release would also >> give people who use LFS in production the time to adapt their systems >> for the new changes. It's way too big of a change to make 1-2 months >> before release, this should really be done after. > >> I've got permission from those around me to contribute as much time as >> necessary. I'll test both sysvinit and systemd before release if >> necessary as well. >> >> I'm saying this as a person who used to work for a company (not to be >> named publicly) that used LFS in production on factory and CNC systems. >> I'm also saying this as one who uses it in PROD for weather modeling >> systems. We need more than 1-2 months for a huge structure change. > > I appreciate that. > > I did some playing around with the source yesterday and found that > Docbook supports multiple books in one system. The example from Docbook is: > > The Perl Series > >O'Reilly & Associates, Inc. > > > Learning Perl > .. > > > Programming Perl > .. > > > Advanced Perl Programming > .. > > > > > > I tried that and it works. > > On the other hand, we might be able to just reorganize the BLFS book > into two major sections. Basic and Advanced (or some other titles). > The point is that we need to be able to release BLFS with some packages > not being the latest versions and not necessarily tested with the > latest LFS (or just remove those packages). > > What we have been doing is a package freeze about two weeks prior to a > scheduled release. For me, that means spending an estimated 100+ hours > in that two weeks building against the new LFS and testing builds and > limited functionality. I just can't do that any more. > > In addition, the above assumes that the development version of BLFS is > reasonably current and I have most of the scripts needed for the current > packages in the development version of the book. Right now there are 84 > outstanding tickets even though Tim and Thomas and Ken have been doing > updates. Even if we magically got up-to-date today, there would > probably be another 100 or so needed updates before the scheduled > package freeze in mid-August. > > What I am looking for is a long term solution so we can continue to put > out a solid product within our constraints. > >-- Bruce > > -- > http://lists.linuxfromscratch.org/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
On 07/10/2018 07:46 AM, Douglas R. Reno wrote: I'm of the opinion that we should do one more release of the book as it is and then discuss things after that. I'm willing to put in as much time as needs to be put in to keep everything in the book that is currently in there, for one more release at minimum. Consistency is the thing that is the most important to me, and one more release would also give people who use LFS in production the time to adapt their systems for the new changes. It's way too big of a change to make 1-2 months before release, this should really be done after. I've got permission from those around me to contribute as much time as necessary. I'll test both sysvinit and systemd before release if necessary as well. I'm saying this as a person who used to work for a company (not to be named publicly) that used LFS in production on factory and CNC systems. I'm also saying this as one who uses it in PROD for weather modeling systems. We need more than 1-2 months for a huge structure change. I appreciate that. I did some playing around with the source yesterday and found that Docbook supports multiple books in one system. The example from Docbook is: The Perl Series O'Reilly & Associates, Inc. Learning Perl .. Programming Perl .. Advanced Perl Programming .. I tried that and it works. On the other hand, we might be able to just reorganize the BLFS book into two major sections. Basic and Advanced (or some other titles). The point is that we need to be able to release BLFS with some packages not being the latest versions and not necessarily tested with the latest LFS (or just remove those packages). What we have been doing is a package freeze about two weeks prior to a scheduled release. For me, that means spending an estimated 100+ hours in that two weeks building against the new LFS and testing builds and limited functionality. I just can't do that any more. In addition, the above assumes that the development version of BLFS is reasonably current and I have most of the scripts needed for the current packages in the development version of the book. Right now there are 84 outstanding tickets even though Tim and Thomas and Ken have been doing updates. Even if we magically got up-to-date today, there would probably be another 100 or so needed updates before the scheduled package freeze in mid-August. What I am looking for is a long term solution so we can continue to put out a solid product within our constraints. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-Basic
On Mon, Jul 9, 2018 at 3:09 PM Bruce Dubbs wrote: > As most of you know, BLFS is huge. If it is printed on paper, it would > take over 2000 pages. There are over a thousand individual packages in > the book. > > In addition, upstream changes are released often. The average is about > 3.5 packages every day, seven days a week. > > Since LFS/BLFS contributions are done completely by volunteers, the > upstream change rate is overwhelming our ability to keep up to date. > The problem is not LFS. That is doable. The problem is the size and > change rate of BLFS. > > To address this, I am proposing to split BLFS into two (or possibly > more) books. My tentative names are BLFS-Basic and BLFS-Advanced. > BLFS-Basic is primarily command line tools and programs plus the basic > Xorg section of BLFS. This would be updated regularly and a 'stable' > version released every six months with the LFS book. The BLFS-Advanced > book will be a 'rolling release'. We did this with BLFS between LFS > versions 6.3 and 7.4 (August 2008 until September 2014). > > With a rolling release, there is less consistency and a comprehensive > check against the current stable LFS is not done. Packages would be > frequently out of date. > > For BLFS-Basic I am attaching a straw man for the contents. I > anticipate that an experienced LFS builder could complete all the > packages in BLFS-Basic in a day or two. > > I am now looking for feedback. Are there other solutions? Is my list > for BLFS-Basic too large? Is there something missing? > >-- Bruce > -- > http://lists.linuxfromscratch.org/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > After spending hours attempting to come up with something, considering the amount of variations, I'll share what I have. I'm of the opinion that we should do one more release of the book as it is and then discuss things after that. I'm willing to put in as much time as needs to be put in to keep everything in the book that is currently in there, for one more release at minimum. Consistency is the thing that is the most important to me, and one more release would also give people who use LFS in production the time to adapt their systems for the new changes. It's way too big of a change to make 1-2 months before release, this should really be done after. I've got permission from those around me to contribute as much time as necessary. I'll test both sysvinit and systemd before release if necessary as well. I'm saying this as a person who used to work for a company (not to be named publicly) that used LFS in production on factory and CNC systems. I'm also saying this as one who uses it in PROD for weather modeling systems. We need more than 1-2 months for a huge structure change. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
