Re: I think we need more editors
On Sat, 25 Jul 2009 19:57:42 -0500 William Immendorf wrote: > I think even with the new editors, they can't do the work fast enough > for the release date. > > You could make me or someone else a editor if you want to, Bruce. > > William If someone would remind me of my SVN and Trac passwords, I could help a bit. I really hate to bother anyone for a clue bat. My ability to contribute is a day to day thing. If someone rhas the time to restart me, please contact me. --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 DJ Lucas wrote: > Guy Dalziel wrote: > I've read previously that Wayne is interested in Gnome as well so he and I > can work together on that one. In fact, Wayne, if you are anxious to get > going on that, go ahead and take that ticket from me when you are ready to > make commits. I'll follow behind and provide verification as I pass > through. Conversely, where do you build X? I use the /opt/X11 prefix for > it, without the compatibility symlink (/usr/X11R6) and have previously > fixed a few of the configure checks upstream to account for this. > OK, I've taken the ticket. It might be up to a week before I start committing Gnome packages. ATM, I've only concentrated on the core section. The last few days, I've been fixing up my auto build scripts. Today I'll start to convert my Gnome build from 26.2 to 26.3. There are still a couple of niggling problems, but they should be fixed soon. One problem is that certain Gnome packages expect dbus to have the same 'sysconfdir' as Gnome, which leads me to a question. Why do we have Gnome 'sysconfdir' set to '/etc/gnome/'? Would there be people out there who would have more than one version of Gnome installed? It would be a lot simpler if 'sysconfdir' was set to /etc. Any thoughts? I have X install under /usr with the /usr/X11R6 symlink. I am also only testing Gnome under /usr. I will also be adding all the new dependency packages first. The one concern I do have however is policykit. Namely around how the daemon is set up (which I presume there is one). I just cannot find enough documentation on this. Are there any distributions out there that are currently using this? I get the impression that this is still in a beta stage. Finally thank you to everyone for their welcomes. Regards, Wayne. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKa63whfgHoRhX2wIRAgkDAJ9Ls+BpArU64lTHjrZFNIB2s977rwCfe5Kq XYYkf97KreA6jO5TV4PQk84= =ureI -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
I think we need more editors
I think even with the new editors, they can't do the work fast enough for the release date. You could make me or someone else a editor if you want to, Bruce. William -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ruby 1.9 problem
CC'ing BLFS-Support as this thread is more appropriate there, please respond in that forum. Thanks. Tobias Gasser wrote these words on 07/25/09 18:13 CST: > mod_ruby-1.3.0 states "supported ruby 1.9 experimentally" I don't use Ruby so I cannot help any. However, what did Google spit out? I'm trying to move this thread to -support as mod_ruby is not a BLFS program and trying to support it does not really fit the mold of this development forum. I'll try and help out over in -support. -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 18:18:01 up 19 days, 6:46, 1 user, load average: 0.06, 0.11, 0.07 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
ruby 1.9 problem
mod_ruby-1.3.0 states "supported ruby 1.9 experimentally" building mod_ruby 1.3.0 with ruby 1.9.1-p129 and apache 2.2.11 does not work here. apache segfaults. anybody out there having this combination up and running?? or any patch for mod_ruby ?? i'm using ruby 1.8.7-p174 and mod_ruby 1.3.0. this combination works fine here eruby runs fine with those two packages when applying the patch from debian you have to build 1.) ruby 1.8.7-p174 2.) eruby 1.0.5 with debian patch 3.) mod_ruby 1.3.0 http://modruby.net/en/index.rbx/mod_ruby/download.html http://modruby.net/en/index.rbx/eruby/download.html http://ftp.de.debian.org/debian/pool/main/e/eruby/eruby_1.0.5-2.diff.gz tobias -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Annotating LFS-6.5 compatibility
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 07/25/09 16:07 CST: > >> general.ent: >> >> This package is known to build and work properly >> using an LFS-6.5 platform." > > In fact, we may even need two entities for 6.5. One similar to the above > and another to indicate that the current version of the package will work > but the book has not been updated yet. > > I know I can help out a lot by building and testing. I just can't promise > time updating the book. This would allow me to insert the second entity > so at least folks know that we've tested a version of the package that > works. Does this make sense? Yes. Why don't you create and commit the entities and then the devs can start using it. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Gnome hint
This is mostly for the devs: As you update packages that come from the gnome repo, there is typically a major version in the directory string. It has been my experience that once a package catches up to the actual Gnome version in this major string, you can use the entity (&gnome-version;) instead of the hard-coded 2.26 or whatever it is. That makes it easier going forward with new versions of the package as once it catches up, like I said, they usually then stay with the Gnome major version. Then the URLs don't need to be updated at all. -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 17:28:01 up 19 days, 5:56, 1 user, load average: 0.00, 0.04, 0.07 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Annotating LFS-6.5 compatibility
Bruce Dubbs wrote these words on 07/25/09 16:07 CST: > general.ent: > > This package is known to build and work properly > using an LFS-6.5 platform." In fact, we may even need two entities for 6.5. One similar to the above and another to indicate that the current version of the package will work but the book has not been updated yet. I know I can help out a lot by building and testing. I just can't promise time updating the book. This would allow me to insert the second entity so at least folks know that we've tested a version of the package that works. Does this make sense? -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 17:15:00 up 19 days, 5:43, 1 user, load average: 0.05, 0.09, 0.13 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: consistency nitpick libogg, libvorbis
2009/7/25 Randy McMurchy : > > I do know that as Ken updates packages, he mentions in the "Command > Explanations" section that you can suppress installing the static libs > by doing --abc-xyz. He does that as a courtesy to those folks (like him) > that do not want any static libs on their system. > > Hope this helped. > Nice summary, thanks Randy. Note that there is nothing *intrinsically* wrong with static libs. It's all a question of getting on top of what to update *when* the next vulnerability surfaces. ĸen -- After tragedy, and farce, "OMG poneys!" -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Annotating LFS-6.5 compatibility
Bruce Dubbs wrote these words on 07/25/09 16:42 CST: > I thought we might have a series of entities: > > &lfs65checked; > &lfs70checked; > > And then turn them on or off as desired. Again, good plan. -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 16:55:01 up 19 days, 5:23, 1 user, load average: 0.06, 0.03, 0.13 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Annotating LFS-6.5 compatibility
On Sat, Jul 25, 2009 at 04:16:03PM -0500, Randy McMurchy wrote: > > &lfs65check; > > > > Package Information > > Good plan. Only thing I might do different is find a better name for the > entity. This might be something we want to do for 7.0 as well. I would probably go with a slightly unique name. If we want to say, "this was checked against 6.5", and later on say, "this was checked against 7.0", then we can't just change the value of the entity as all the pages would then say that they've been checked against 7.0. What if the entity contains the text, "This page was last checked against LFS", and the page itself contains the value, for example, '&lastchecked; 6.5'. That's just an idea of course. You can either have unique values (&checked65; &checked70;); you could have the same value for all the pages (&lastchecked;), and remove it from all the pages for reinsertion; or you can make the entity static and put the value on the page. pgpcwcFhf6jm2.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Annotating LFS-6.5 compatibility
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 07/25/09 16:07 CST: > >> general.ent: >> >> This package is known to build and work properly >> using an LFS-6.5 platform." >> >> Typical package, e.g. postlfs/security/openssl.xml: >> >> The OpenSSL package contains management >> tools and libraries relating to cryptography. These are useful for >> providing cryptography functions to other packages, notably >> OpenSSH, email applications and web browsers >> (for accessing HTTPS sites). >> >> &lfs65check; >> >> Package Information > > Good plan. Only thing I might do different is find a better name for the > entity. This might be something we want to do for 7.0 as well. So perhaps > something a bit more generic like &lfs_compatability_check; or whatever > else might be better. I thought we might have a series of entities: &lfs65checked; &lfs70checked; And then turn them on or off as desired. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Annotating LFS-6.5 compatibility
Bruce Dubbs wrote these words on 07/25/09 16:07 CST: > general.ent: > > This package is known to build and work properly > using an LFS-6.5 platform." > > Typical package, e.g. postlfs/security/openssl.xml: > > The OpenSSL package contains management > tools and libraries relating to cryptography. These are useful for > providing cryptography functions to other packages, notably > OpenSSH, email applications and web browsers > (for accessing HTTPS sites). > > &lfs65check; > > Package Information Good plan. Only thing I might do different is find a better name for the entity. This might be something we want to do for 7.0 as well. So perhaps something a bit more generic like &lfs_compatability_check; or whatever else might be better. Thoughts? -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 16:13:00 up 19 days, 4:41, 1 user, load average: 1.30, 1.12, 0.73 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Annotating LFS-6.5 compatibility
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 07/25/09 15:45 CST: > >> OK. How about an entity? You wouldn't need to change the book, but just the >> entity. > > Please explain. I am totally wiped out from staring at the screen all > day. I can't envision what you mean. LOL. general.ent: This package is known to build and work properly using an LFS-6.5 platform." Typical package, e.g. postlfs/security/openssl.xml: The OpenSSL package contains management tools and libraries relating to cryptography. These are useful for providing cryptography functions to other packages, notably OpenSSH, email applications and web browsers (for accessing HTTPS sites). &lfs65check; Package Information --- To remove the paragraph, just change the entity in general.ent to a null string. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Annotating LFS-6.5 compatibility
Bruce Dubbs wrote these words on 07/25/09 15:45 CST: > OK. How about an entity? You wouldn't need to change the book, but just the > entity. Please explain. I am totally wiped out from staring at the screen all day. I can't envision what you mean. -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 15:53:01 up 19 days, 4:21, 1 user, load average: 0.25, 0.23, 0.20 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: consistency nitpick libogg, libvorbis
Nathan Coulson wrote these words on 07/25/09 14:12 CST: > I noted that libogg/libvorbis install static libraries by default. Some of > the packages have the --disable-static keyword mentioned when you have the > option of not installing static libraries. > > In regards to not installing static libraries, was that a policy change? > or was it disabled on packages where other programs do not link to the .a > files? (Just wondering if this is something worth reporting) There's never been any policy about this. Typically, we install whatever the maintainer puts on the disk during 'make install'. If there is a package where we intentionally suppress installing the static libs, then there was some technical reason. I don't believe there are any packages that do it "just to do it". I do know that as Ken updates packages, he mentions in the "Command Explanations" section that you can suppress installing the static libs by doing --abc-xyz. He does that as a courtesy to those folks (like him) that do not want any static libs on their system. Hope this helped. -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 15:47:00 up 19 days, 4:15, 1 user, load average: 0.05, 0.06, 0.16 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Annotating LFS-6.5 compatibility
Randy McMurchy wrote: > Hi all, > > After thinking about this, and due to the community's desire to see > something about this, I am proposing the following: > > As BLFS packages are built on top of an LFS-6.5 system, insert the > following between the description of the package and the sect3 "Package > Information". > > This package is known to build and work properly using an LFS-6.5 > platform. > > Put appropriate blank lines as needed. > > As most of you have mentioned, this clearly identifies to the reader that > the package is current, and known to work. > > We can change the text if someone can think of a better statement, but > once we start, it must be the same exact text in every single package. > That way, once we go to release a BLFS-6.5, I can run a global sed and > remove all the statements. > > Sound agreeable? OK. How about an entity? You wouldn't need to change the book, but just the entity. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
consistency nitpick libogg, libvorbis
I noted that libogg/libvorbis install static libraries by default. Some of the packages have the --disable-static keyword mentioned when you have the option of not installing static libraries. In regards to not installing static libraries, was that a policy change? or was it disabled on packages where other programs do not link to the .a files? (Just wondering if this is something worth reporting) -- Nathan Coulson (conathan) -- Location: Brittish 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: Annotating LFS-6.5 compatibility
On Sat, Jul 25, 2009 at 02:22:18PM -0500, Randy McMurchy wrote: > As BLFS packages are built on top of an LFS-6.5 system, insert the > following between the description of the package and the sect3 "Package > Information". > > This package is known to build and work properly using an LFS-6.5 > platform. > Sound agreeable? Well, I'm perfectly happy to do it if it clarifies the issue. I know it will certainly be of use for packages that haven't had an update in a long time, but were last checked against who knows what platform. Libmad is a good example with -fforce-mem now being obsolete. It hasn't had an update in about 5 years, but it would, if I remember correctly, have worked perfectly well on LFS 6.3. I shall have to start writing these in once I get my 6.5 system up. I built my current base before the switch to GCC 4.4.1, so I have 4.4.0 at the moment. There shouldn't be much difference between the two, it's just a bugfix release afterall, but I'll sort out any issues that arise with the packages I've updated and put the note in. pgp8LZlUTUVBO.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Annotating LFS-6.5 compatibility
Hi all, After thinking about this, and due to the community's desire to see something about this, I am proposing the following: As BLFS packages are built on top of an LFS-6.5 system, insert the following between the description of the package and the sect3 "Package Information". This package is known to build and work properly using an LFS-6.5 platform. Put appropriate blank lines as needed. As most of you have mentioned, this clearly identifies to the reader that the package is current, and known to work. We can change the text if someone can think of a better statement, but once we start, it must be the same exact text in every single package. That way, once we go to release a BLFS-6.5, I can run a global sed and remove all the statements. Sound agreeable? -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 14:13:00 up 19 days, 2:41, 1 user, load average: 0.03, 0.07, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
Guy Dalziel schrieb: > I don't consider it that steep, a little bit of testing never hurt > anyone. The most basic test we do is to make sure that things compile > together, and we tend to leave things to people who actually use them, i had no problem with your statement. assuming an update can only be acceptet if ALL dependend packages are running, my commitment really was not very usefull. but for me it was frustrating, as i don't want to build ALL packages in blfs. with the new approach just to update packages that seem to be ok and fiddling arround for breakages later, i'll try to tell you about my results. i'll post my results as soon as available... tobias -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
Guy Dalziel schrieb: > Don't worry, you're not alone. I'm just about to finish building what > will, hopefully, be the 6.5 LFS release. I used Gawk 3.1.7 and all the > testsuites performed within expected parameters. 3 tests in 3.1.7 failed > during the temp build but they all passed during the permanent toolchain. > All in all this is starting to look like a very good build. > same here. the 3 tests should not worry, as in the log is stated "Starting tests that can vary based on character set or locale support". the test that fail here in the temp-build are lc_num1, mbfw1 and mbprintf1. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
On Sat, Jul 25, 2009 at 01:48:52PM -, DJ Lucas wrote: > behind. I've just started over _again_ with the addition of gcc-4.4.1. > Seeing that gawk has known breakage with some packages, I'm going to > rebuild gawk quick to account for that change as well (I'm sure a full LFS > build will occur by somebody with that change included). Don't worry, you're not alone. I'm just about to finish building what will, hopefully, be the 6.5 LFS release. I used Gawk 3.1.7 and all the testsuites performed within expected parameters. 3 tests in 3.1.7 failed during the temp build but they all passed during the permanent toolchain. All in all this is starting to look like a very good build. pgphR2VROC88M.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
> Randy McMurchy wrote: > > You're only talking about Matt, and he's had BLFS access for years. Oops, I thought that I had seen updates from Chris, Jeremy, and a couple of others recently. Seems my memory has failed. Reviewing LFS-Book, I see that does seem to be the case. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
Randy McMurchy wrote these words on 07/25/09 09:10 CST: > Please keep in mind that even though I've said I can't promise to do > any updates, doesn't mean I'm not building up a 6.5 box. I'll end up > adding more than 3/4 of the packages, as I always do. This tests the > majority of the book I will do this, however. As I install most recent packages onto my 6.5 box, if it works, I'll update the page to say so. This will take very little time on top of building the packages. Then, folks will know the recent version works, and when the book is updated, my little note will be removed. I can actually go through the book very fast if I don't have to stop and update each package in the book as I go, which is the way I've always done in the past. I don't think it will take that long to get BLFS in good shape. Actually, thinking about it, I believe there may have been some overreaction to the state of BLFS. It has only been 11 months since the last BLFS release. We've gone much, much longer than this between updates in the past. -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 09:39:00 up 18 days, 22:07, 1 user, load average: 0.00, 0.06, 0.34 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
Randy McMurchy wrote these words on 07/25/09 09:10 CST: > Please keep in mind that even though I've said I can't promise to do > any updates, doesn't mean I'm not building up a 6.5 box. But I'm going to wait until there is a real package freeze for 6.5. Which I believe means waiting until there is a released book. :-) -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 09:16:00 up 18 days, 21:44, 1 user, load average: 1.15, 1.30, 0.88 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
Randy McMurchy wrote these words on 07/25/09 09:03 CST: > Yes, I don't want to update pages in the book saying "it works with > such and such". Let's just use Trac. I will ensure each package is > accounted for. Please keep in mind that even though I've said I can't promise to do any updates, doesn't mean I'm not building up a 6.5 box. I'll end up adding more than 3/4 of the packages, as I always do. This tests the majority of the book I just don't think I'm going to have time to do actual book updates. I will if I can. It's not like we're going to be going blindly wondering if there is breakage in the book. If there is, we'll discover it. And then fix it, just like we've always done. -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 09:07:00 up 18 days, 21:35, 1 user, load average: 1.30, 0.98, 0.50 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
DJ Lucas wrote these words on 07/25/09 08:48 CST: > We absolutely need a way to track the pages that have been touched by a > quick glance approach. I disagree. I will go through every package and either update Trac or add packages to it as I discover they are out of date. We'll use the Trac system. If there is a ticket, the package needs updating. If there's no ticket, the package doesn't need to be touched. Why does the book need to be touched for this? I don't think we need to go through updating packages such as TCPWrappers (I used that as an example of a package that has not had an update in quite a long time) and add that "it works with LFS 6.5". We'll know soon enough if it doesn't. > Finally, in light of the amount of work needed to be done, current LFS > editors should be given access to BLFS (if they don't have it already). > Anything that anyone can contribute, after LFS-6.5 is out the door, will > be greatly appreciated. You're only talking about Matt, and he's had BLFS access for years. > Any objections to any of the above? Yes, I don't want to update pages in the book saying "it works with such and such". Let's just use Trac. I will ensure each package is accounted for. -- Randy rmlscsi: [bogomips 1003.25] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 08:56:00 up 18 days, 21:24, 1 user, load average: 0.07, 0.10, 0.04 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
Guy Dalziel wrote: > I don't consider it that steep, a little bit of testing never hurt > anyone. The most basic test we do is to make sure that things compile > together, and we tend to leave things to people who actually use them, > that way they'll be compiling them anyway. If we had more community > input then we could have people report to us what works or not, e.g., "I > use an LFS 6.5 system and Sendmail compiled and works > fine against Berkeley DB 4.7.25", or, "I use PHP and > this compiled and worked fine against Berkeley DB 4.7.25." Nobody said > it all has to be on the head of one editor, and it's a good way to > involve the community. Tobias has already got this model started by > saying, "I've used OpenLDAP 2.4.16 for 4 weeks with Berkeley DB 4.7.25 > and I've had no problems". Now perhaps this model isn't suitable right > _now_ as we're quite far behind, but I certainly think it's worth > considering. No, it's not worth considering...it's worth doing. We need a firm plan of attack and we need it now. As both you and Randy have already mentioned in this thread, and others have for countless threads, BLFS is grossly behind. I've just started over _again_ with the addition of gcc-4.4.1. Seeing that gawk has known breakage with some packages, I'm going to rebuild gawk quick to account for that change as well (I'm sure a full LFS build will occur by somebody with that change included). IMO, the book is not completely useless right now, but there is damn well a lot of breakage and tons of newer packages. If a package works in your stack, then just do the update and we'll fix what breaks with that update as it comes up. We absolutely need a way to track the pages that have been touched by a quick glance approach. Bruce's idea in the other thread will do the job perfectly. I don't know off the top of my head how to accomplish it, but I know it can be done pretty quickly. Add a "RELEASE" var to the makefile to ignore the 'class="dev"' parts, and we are good to generate a released book by 'RELEASE=1 make blfs'. As far as placement is concerned, immediately inside the first tag looks good to me. Finally, as we approach a release quality product, anything that hasn't been checked is considered fat, an abandoned package, and should be trimmed if nobody steps up to the plate to account for it. We'll have to cross that bridge when we get there, however. Finally, in light of the amount of work needed to be done, current LFS editors should be given access to BLFS (if they don't have it already). Anything that anyone can contribute, after LFS-6.5 is out the door, will be greatly appreciated. Accountability: Once package freeze is in place for LFS-6.5, which I think will be good once gawk goes in, I have planned for a full Gnome Desktop that I will use daily. Seeing as (due to hardware failure) I do not have a working LFS at all ATM, this will be my first goal. I believe I've read previously that Wayne is interested in Gnome as well so he and I can work together on that one. In fact, Wayne, if you are anxious to get going on that, go ahead and take that ticket from me when you are ready to make commits. I'll follow behind and provide verification as I pass through. Conversely, where do you build X? I use the /opt/X11 prefix for it, without the compatibility symlink (/usr/X11R6) and have previously fixed a few of the configure checks upstream to account for this. I also need to build a replacement for my server, which for lack of a better term ATM, is the Linux equivalent of an SBS box, it provides authentication, web, mail, printing, and samba file services. With these two projects in mind, I alone should be able to account for 75+% of the packages in the book by daily useas I imagine most of the current developers can. Sorry, only minimal help for the KDE guys from me. Any objections to any of the above? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: proposal: new approach
On Fri, Jul 24, 2009 at 05:44:29PM -0500, Randy McMurchy wrote: > Tobias has sent a personal apology via email to me. His apology is > accepted. He made good points in his post. In fact, the BDB rejection > may have been a bit steep by Guy. But let's get past all that. I don't consider it that steep, a little bit of testing never hurt anyone. The most basic test we do is to make sure that things compile together, and we tend to leave things to people who actually use them, that way they'll be compiling them anyway. If we had more community input then we could have people report to us what works or not, e.g., "I use an LFS 6.5 system and Sendmail compiled and works fine against Berkeley DB 4.7.25", or, "I use PHP and this compiled and worked fine against Berkeley DB 4.7.25." Nobody said it all has to be on the head of one editor, and it's a good way to involve the community. Tobias has already got this model started by saying, "I've used OpenLDAP 2.4.16 for 4 weeks with Berkeley DB 4.7.25 and I've had no problems". Now perhaps this model isn't suitable right _now_ as we're quite far behind, but I certainly think it's worth considering. > BLFS is indeed way behind. I suggest we just update to the newest > releases of packages and see what breaks. I can't promise I can help > build many packages, but I will review commits. I've already suggested this with libjpeg-7. There's no way I can test all of the packages that depend upon it by myself, but I have done some testing which makes me confident enough to "throw it out there". pgpSr89YB8vTc.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
