Re: proposal: new approach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Berg wrote: Am Sonntag 26 Juli 2009 03:14 schrieben Sie: snip 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. I know of ArchLinux using PolicyKit for Gnome and KDE. There are a few patches for this package dealing with a newer D-BUS version (whatever this newever D- BUS version is; Arch uses 1.2.14 at the moment) and a configuration file for using PolicyKit together with PAM. Fine regards, Christoph Thanks you for the info. Regards, Wayne. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKeDWQhfgHoRhX2wIRArg8AJ48+g0KXEmu1h+Q36QOYr3pyESlWwCeLsNA OBD5aikDJWIVJvUjOEFh0/c= =Cp+H -END 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
Am Sonntag 26 Juli 2009 03:14 schrieben Sie: snip 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. I know of ArchLinux using PolicyKit for Gnome and KDE. There are a few patches for this package dealing with a newer D-BUS version (whatever this newever D- BUS version is; Arch uses 1.2.14 at the moment) and a configuration file for using PolicyKit together with PAM. Fine regards, Christoph signature.asc Description: This is a digitally signed message part. -- 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, 25 Jul 2009 09:03:13 -0500, Randy McMurchy ra...@linuxfromscratch.org wrote: DJ Lucas wrote these words on 07/25/09 08:48 CST: 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. And I probably have never used them! Anyway, now that my main barrier to entry of make sure all dependant packages work following a package update has been lifted, I may well go all gung-ho following LFS-6.5-RC2 and start actually (ab)using my commit privs :-) I'm also willing, of course, to revert any of my updates that cause breakage, or investigate any issues they cause. Regards, Matt. -- 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 whatever version compiled and works fine against Berkeley DB 4.7.25, or, I use PHP whatever version 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
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 whatever version compiled and works fine against Berkeley DB 4.7.25, or, I use PHP whatever version 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 sect2 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
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
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
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: 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
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
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
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 DJ Lucas wrote: Guy Dalziel wrote: snip 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/version'? 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
Re: proposal: new approach
Tobias Gasser wrote these words on 07/24/09 15:51 CST: [snip fairly useful, but nothing that we would do, information] i don't want to offend anybody, and i really appreciate the work all the authors are doeing. but the current state of the book is just [censored] And after this comment, I know I will dismiss anything more you have to say. You comment we are doing poorly, yet you won't contribute. Go away. -- 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:26:00 up 18 days, 4:54, 1 user, load average: 0.02, 0.02, 0.00 -- 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/24/09 16:28 CST: [snip getting ugly stuff] 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. 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. If updating BDB breaks OpenLDAP, then we'll address it then. If XYZ breaks ABC, we'll address it then. Otherwise, development will be stifled. That is that last thing we need right now. We need package updates. Lots of them. It's been my experience that there is a certain path one must go in building BLFS. This path has usually been effective in discovering breakage. Anyway, my recommendation is to just jump in and update as many packages to the latest and greatest as possible. We'll address breakage as we discover it. Does anyone disagree with this policy? When you think about it, what do we really have to lose? It's not like BLFS (even the dev book) is stable and ready to be used with LFS-6.5. Update, update, update. Let's everyone get on the ball. Send in patches and recommendations. Keep the flow of information coming. -- 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:36:00 up 18 days, 6:04, 1 user, load average: 0.00, 0.03, 0.02 -- 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: Update, update, update. Let's everyone get on the ball. Send in patches and recommendations. Keep the flow of information coming. My suggestion is to try to look at the base libraries first. They have the fewest dependencies, although there are cases of circular dependencies and are generally the easiest to build. Updating those may break older apps that depend on the libraries, but they will generally have newer releases pending that will fix those problems. I think we do need to mark each package with some sort of indication about when it was last reviewed. We do have a Last updated on: tag, but that's not always the best indication because it is automatically updated for things like whitespace changes. The exact method of doing this mark is not really important. I like the suggestion made earlier to add a line to each package with Last checked against LFS 6.5, possibly within the introduction of the package -- Bruce -- 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
Bruce Dubbs wrote these words on 07/24/09 18:03 CST: I think we do need to mark each package with some sort of indication about when it was last reviewed. We do have a Last updated on: tag, but that's not always the best indication because it is automatically updated for things like whitespace changes. The exact method of doing this mark is not really important. I like the suggestion made earlier to add a line to each package with Last checked against LFS 6.5, possibly within the introduction of the package I don't believe that adds any value. Our target is LFS-6.5. If a package was updated (that's what a changelog is for), then it is obvious what version it was checked against. Furthermore, how are we to distinguish which packages were checked against 6.3 and which were checked against 6.4? Answer: impossible to tell unless someone builds it and then it is 6.5. So, in essence, everything will be checked against 6.5, or it wasn't checked. So what is the point in adding the obvious? It was either checked against 6.5 (changelog points this out) or it wasn't checked at all. I'm against this idea. I don't want to release a stable book that says this package last checked against (some previous version other than the stable LFS we targeted). I think it would look amateurish. I think we're better off just continuing to update as we always have. If we find breakage we fix it. I'm against versioning the updates. -- 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:26:00 up 18 days, 6:54, 1 user, load average: 0.01, 0.02, 0.00 -- 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: Bruce Dubbs wrote these words on 07/24/09 18:03 CST: I think we do need to mark each package with some sort of indication about when it was last reviewed. We do have a Last updated on: tag, but that's not always the best indication because it is automatically updated for things like whitespace changes. The exact method of doing this mark is not really important. I like the suggestion made earlier to add a line to each package with Last checked against LFS 6.5, possibly within the introduction of the package I don't believe that adds any value. Our target is LFS-6.5. If a package was updated (that's what a changelog is for), then it is obvious what version it was checked against. Furthermore, how are we to distinguish which packages were checked against 6.3 and which were checked against 6.4? Answer: impossible to tell unless someone builds it and then it is 6.5. So, in essence, everything will be checked against 6.5, or it wasn't checked. So what is the point in adding the obvious? It was either checked against 6.5 (changelog points this out) or it wasn't checked at all. I'm against this idea. I don't want to release a stable book that says this package last checked against (some previous version other than the stable LFS we targeted). I think it would look amateurish. I think we're better off just continuing to update as we always have. If we find breakage we fix it. I'm against versioning the updates. I understand your point, but I was thinking of the future. It's true that any package we update now should be against 6.5. The absence of a line that says Last Reviewed means that it was before 6.5. In the future, if we get behind again, then the Last Checked line does provide some useful information. For the present, it gives a quick check (without searching through 200+ tickets) that a package was reviewed recently and doesn't need further review right now. I think its a reasonable approach, even if we want to remove it for a release. -- Bruce -- 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 4:44 PM, Randy McMurchy ra...@linuxfromscratch.org wrote: Randy McMurchy wrote these words on 07/24/09 16:28 CST: [snip getting ugly stuff] 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. 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. So as a total newbie to BLFS development, what would the best course of action be? Just get a recent LFS system running and start building the latest and greatest packages from the BLFS book (the base libraries were mentioned as a good starting point)? I've got some spare time I could commit to building packages but I'm unsure of what the proper testing procedures are. At this point are we worried about just the package itself building and not so much the repercussions of other packages that depend on it? Thanks, Eujon -- 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
Bruce Dubbs wrote: I understand your point, but I was thinking of the future. It's true that any package we update now should be against 6.5. The absence of a line that says Last Reviewed means that it was before 6.5. In the future, if we get behind again, then the Last Checked line does provide some useful information. For the present, it gives a quick check (without searching through 200+ tickets) that a package was reviewed recently and doesn't need further review right now. I think its a reasonable approach, even if we want to remove it for a release. It certainly should not be rendered in the finished book, however, a simple comment under the first block, for each package certainly wouldn't hurt anything. !-- Last checked against LFS-6.5. -- -- 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
DJ Lucas wrote: Bruce Dubbs wrote: I understand your point, but I was thinking of the future. It's true that any package we update now should be against 6.5. The absence of a line that says Last Reviewed means that it was before 6.5. In the future, if we get behind again, then the Last Checked line does provide some useful information. For the present, it gives a quick check (without searching through 200+ tickets) that a package was reviewed recently and doesn't need further review right now. I think its a reasonable approach, even if we want to remove it for a release. It certainly should not be rendered in the finished book, however, a simple comment under the first block, for each package certainly wouldn't hurt anything. !-- Last checked against LFS-6.5. -- Well my thought was to render it so you didn't have to look at tickets/source, but you did trigger an idea. How about putting in a temporary note with a para role='dev'Comment/para and then be able to make that render or not via the xsl. -- Bruce -- 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
Bruce Dubbs schrieb: I understand your point, but I was thinking of the future. It's true that any package we update now should be against 6.5. The absence of a line that says Last Reviewed means that it was before 6.5. In the future, if we get behind again, then the Last Checked line does provide some useful information. For the present, it gives a quick check (without searching through 200+ tickets) that a package was reviewed recently and doesn't need further review right now. looking at the php package i'd like some more details not only about which lfs was used for a sucessfull compile, but in addition what version of dependencies. as i mentionned in an earlier thread (RFC: BLFS-6.4, 09/07/20), something like last checked with lfs x.y, using libxslt-a.b, pcre-c.d..., including needed additional ./configure options. as soon as my current lfs-build is finished, i'll go on to build a new server with apache, mysql, php, samba, cups. when/if sucessfull, i'll post an example for php here. i know this can fill up the pages, as there will be quite a number of possible combinations... as i wrote, the wiki might be the right place for such additional information. as far as i understand, a blfs-book should match a lfs-book. the last checked makes sense in the dev/svn, but not in a final book. same for the additional dependencies as they should be consistent within a final book (i guess). tobias -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
