berkeley db
lfs had 4.7.25 in 6.4, now removed blfs has 4.5.20. i suggest to copy the 4.7.25 instructions from lfs-6.4 to blfs, including the patch. tobias -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: berkeley db
On Fri, Jul 24, 2009 at 12:10:50PM +0200, Tobias Gasser wrote: > i suggest to copy the 4.7.25 instructions from lfs-6.4 to blfs, > including the patch. Tobias, we already have a ticket for this. http://wiki.linuxfromscratch.org/blfs/ticket/2533, as you can see there are some issues with this version that still need to be worked out. pgpPqS2ydeoTS.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: berkeley db
Guy Dalziel schrieb: > On Fri, Jul 24, 2009 at 12:10:50PM +0200, Tobias Gasser wrote: >> i suggest to copy the 4.7.25 instructions from lfs-6.4 to blfs, >> including the patch. > > Tobias, we already have a ticket for this. > http://wiki.linuxfromscratch.org/blfs/ticket/2533, as you can see there > are some issues with this version that still need to be worked out. > ok. but: http://www.openldap.org/software/download/ 2.4.16 is considered stable!! 2.4.17 is "release", thus should be fine too: http://www.openldap.org/faq/data/cache/226.html i've running a system with db 4.7.25 and openldap 2.4.16 for about 4 weeks without any issues. tobias -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: berkeley db
On Fri, Jul 24, 2009 at 01:45:58PM +0200, Tobias Gasser wrote: > i've running a system with db 4.7.25 and openldap 2.4.16 for about 4 > weeks without any issues. Thank you for the information, I'm sure that will help. However, the problem is a lot of programs compile against Berkeley DB and we must check them all. A quick grep of the book shows programs such as PHP, Python, Ruby, Subversion, and some KDE and GNOME stuff. The more popular a dependency the harder it is to upgrade, so I hope you'll forgive if we tread a little cautiously around this. pgpGUU8NH78tw.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: berkeley db
Guy Dalziel schrieb: > On Fri, Jul 24, 2009 at 01:45:58PM +0200, Tobias Gasser wrote: >> i've running a system with db 4.7.25 and openldap 2.4.16 for about 4 >> weeks without any issues. > > Thank you for the information, I'm sure that will help. However, the > problem is a lot of programs compile against Berkeley DB and we must > check them all. A quick grep of the book shows programs such as PHP, > Python, Ruby, Subversion, and some KDE and GNOME stuff. The more popular a > dependency the harder it is to upgrade, so I hope you'll forgive if we > tread a little cautiously around this. > as for php and python i can confirm it works fine. ruby i can't test as i currently can't compile due to errors. as i dont need ruby on this machine i didn't even try to get it running... with kde and gnome i can understand the problem. but for me it's no issue as i don't have an up-to-date system arround with x. tobias -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
proposal: new approach
as the current BLFS is quite outdated, i propose another approach to get the book up to date. i guess there are to many outdated packages which are dependencies for others. fixing one package requires to rebuild another bunch of packages where one or another can't be built as it depends on some more packages which themselfs require to update another one... in my humble opinion updating the complete blfs-book is almost impossible. *just start with a new EMPTY branch and RESTART FROM SCRATCH!!* first get the most common libraries (like berkeley-db, jpeg, png ...) up to a current version. next would be x, gnome, kde and the most used servers like apache, samba, ldap... just bare without anything on top of it. and now the packages which some of the authors/contributers use themselfs on top of kde / gnome or as an extension to one of the servers already built. but just step by step. example: just minimal php, no additional packages required which aren't built yet. getting a full blown php requires to much additional packages, but getting a minimal php is quite easy. i guess with this approach we will have a blfs 6.x very quick. not as complete as the current one, but the packages in the "new" book are well tested and fit to each other. whenever i wrote about a successull update of one of these packages (last was berkeley db) i get a similar replay: the package has some more dependencies which are not tested yet, thanks for the info, but no update possible now. i know i might have overseen some issues, but i'm really frustrated as every hint i put back to the community is not applicable due to some reasons which lead to a no-go for my commitment. everytime the arguments are quite reasonable and i can understand my input can't be implemented without any side effects. as i could see during the last months, almost every input from a user was rejected with "thanks for your input, but you didn't test package x, y and z". i myself have updated almost all packages i use from blfs (the few i didn't had no update since the last complete book!!). but i have not the complexity in dependencies as given by the COMPLETE book. when i started with LFS there was no real BLFS but a long list of really usefull hints. now we have a BLFS which is outdated and hints which are outdated too. for me a stipped down BLFS wich is current, and hints which are based on a book (hints should correspond to a given book version!!) would be much more desireable than the current status. 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] thanks for anyone haveing read 'til here!! 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
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
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 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: New BLFS Editor
Randy McMurchy wrote: > I'd like to announce that Wayne Blaszczyk has accepted a position as a > BLFS Editor. > Ouch...sorry for the late reply, got lost in the other thread. Welcome to the team. There is a ton of work to do, but try do to have fun with it. :-) -- 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
>> 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. -- 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. > > 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 Comment 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
Proposal
Hi, While translating blfs, I realize that for some packages, there are not instructions to have them in another language than English. It's right for OOo, and Mozilla. That's why I wanted to know if you're interested in an additional explanation about this point: "how getting an application in your language"? I would start with firefox, and probably thunderbird and other packages of the Mozilla suite included in blfs. I'm waiting for your feeling about such project. If you're interested I'll submit a patch soon. If not I'll think of letting such instructions for the French book, for French language settings, whereas if you accept the patch would stay more general about the languages. Sincerely, Jean-Philippe MENGUAL -- Jean-Philippe MENGUAL Vice-Président de l'association traduc.org Coordinateur du projet Linux From Scratch -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
