Re: kdebase-3.4.0
Robert Connolly wrote: On April 14, 2005 02:47 am, Robert Connolly wrote: Hi. I noticed kdebase-3.4.0 installs ksysguarddrc and xdg/ to /usr/etc.. so it looks like --sysconfdir=/etc is needed for this package. xdg/ is from kdelibs, so --sysconfdir=/etc would be needed there too. Thanks for the heads up Robert. I'm jsut starting to work on KDE now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Book Reorganization
Jeremy Utley wrote: Here's how I solve that when following the BLFS book...keep in mind this is only one solution out of many possibilities, but this works quite well for me. Jeremy, What you are describing is a depth first search. That's what I do also. My technique is a little more complex because I have/create a subdirectory in /usr/src for each package that includes the source and a script for building, logging, and measuring the install. It takes a bit more effort, but I can go back and review exactly what I have done. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Acrobat 7
Jamie Bennett wrote: On Thu, 2005-04-14 at 14:08 -0500, Bruce Dubbs wrote: Just to try it out, I donloaded a copy of Acrobat Reader 7 for Linux and installed it. On my LFS 6.1 testing system it flashes the splash screen and exits without any error messages of any kind. ldd on the binary does not show any missing libraries and checking for permission problems I ran as root and got the same results. Has anyone else tried this out? Wrong list? Yup. Sorry. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Acrobat 7
Randy McMurchy wrote: Not to argue at all, but for the sake of my memory, I remember Xpdf uses a navigation TOC on the left side just like Adobe does. I would have to reboot into a different partition on the computer I'm on right now to get at Xpdf, but are you certain there's not a setup option that allows this navigation TOC on the left side? I'm almost positive I remember this. It depends on the pdf. If the document has a TOC, xpdf will display it in a panel on the left. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Acrobat 7
Jrg Billeter wrote: Some plugins of Acrobat 7 need libstdc++.so.5, i.e. the standard c++ library coming with gcc 3.3. So either install it or remove the Reader/intellinux/plug_ins directory... Renaming the plugins directory worked. I may consider installing libstdc++.so.5 in the future, but I've got better things to do right now. Thanks. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: SBUs
Bruce Dubbs wrote these words on 04/14/05 17:08 CST: These values really overspecify the point and the high precision is a bit misleading. I am presenting a suggestion for discussion: SBUs less then 0.1 should be specified as: Estimated build time: 0.1 SBU To me, the *lack* of precision in this example is much more misleading that what we have now. Let's say for the sake of roundness, binutils takes 2.5 minutes (two and one-half). Now 0.1 SBU would be 15 seconds. This would be way wrong for a package that compiles and installs in one, or two seconds. To the point it would look like we didn't know how to do elementary calculations. SBUs between 9.9 and 0.1 (inclusive) should be rounded to one decimal: Estimated build time: 6.7 SBU SBUs greater than 10 should be rounded to whole numbers: Estimated build time: 12 SBU This would work, though I don't see the harm in a decimal in all the SBU figures. Just my thoughts. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 17:18:00 up 12 days, 16:51, 3 users, load average: 0.11, 0.08, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: SBUs
Randy McMurchy wrote these words on 04/14/05 17:24 CST: Bruce Dubbs wrote these words on 04/14/05 17:08 CST: Estimated build time: 0.1 SBU To me, the *lack* of precision in this example is much more misleading that what we have now. Let's say for the sake of roundness, binutils takes 2.5 minutes (two and one-half). Now 0.1 SBU would be 15 seconds. This would be way wrong for a package that compiles and installs in one, or two seconds. To the point it would look like we didn't know how to do elementary calculations. I initially overlooked the less than sign in your example. With the less than sign, it now makes sense to me. It would work, for example, a machine that takes 10 minutes to do binutils, we are saying that a 0.1 SBU package would take under a minute. That would probably work, as SBU's are bit of a stretch to pinpoint accurately. Too many unknowns. It's not just CPU speed, but the speed of the disk, amount of RAM and other variables we can't account for. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 17:29:00 up 12 days, 17:02, 3 users, load average: 0.18, 0.18, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: SBUs
Randy McMurchy wrote: Randy McMurchy wrote these words on 04/14/05 17:24 CST: Bruce Dubbs wrote these words on 04/14/05 17:08 CST: Estimated build time: 0.1 SBU To me, the *lack* of precision in this example is much more misleading that what we have now. Let's say for the sake of roundness, binutils takes 2.5 minutes (two and one-half). Now 0.1 SBU would be 15 seconds. This would be way wrong for a package that compiles and installs in one, or two seconds. To the point it would look like we didn't know how to do elementary calculations. I initially overlooked the less than sign in your example. With the less than sign, it now makes sense to me. It would work, for example, a machine that takes 10 minutes to do binutils, we are saying that a 0.1 SBU package would take under a minute. That would probably work, as SBU's are bit of a stretch to pinpoint accurately. Too many unknowns. It's not just CPU speed, but the speed of the disk, amount of RAM and other variables we can't account for. Right. Perhaps to make it more obvious we should say: Estimated build time: less than 0.1 SBU -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: openoffice fun
Randy McMurchy wrote: I'm going to try to work out the FOP issues, as it may be some time before a new version is released. OpenOffice probably will contain fixes for the JDK-1.5 sometime soon. I'm not seeing any notes pointing towards a 1.1.5 at all...but looking to May for 2.0 last I heard. So, we could update BLFS to the new JDK and just put notes in the FOP and OpenOffice instructions that the 1.4.2 version of the JDK is required. Yes this should be fine for now...but why upgrade if it'll cause problems? AFAIK, the 1.4.2 is fine for everything right now. Only people that need 1.5.0 will be devs, and they can figure it out from the previous patches or just use the binary. I'll go back into the old OOo and see if I can figure out how dmake's patch command works again for the java code there (see -source below). Of course, I could just make deltas for testing and avoid dmake all together for the moment...assuming I can get a successful build. ooo-build is currently looking at src680 so not a lot of help there for OOo-1.1.4. I believe DJ is miles ahead of me on the JDK stuff, but I have been using the JDK-1.5 for some time now and haven't encountered any issues. Definately not miles ahead, especially now, but actually I think the majority of projects (baring OOo for now) should be able to be built with the option '-source 1.4' (or 1.3) passed to javac (source=1.4 in javac block of build.xml for projects that take advantage of ant). This was not the case with fop as I got it to build IIRC, but had test failures... OOo's big problem lies in my previous mis-understanding of dmake. Most others are 1.5 happy now anyway. Also, I apear to have an ant problem with src680 builds (OOo-1.9.x builds) claiming that it can't find the ant libs, while many other packages that use ant have no problem. Something is amiss there leaving me unable to test jdk-1.5.0 with OOo cvs. I'm quietly working on it in the background, though I must say that I do like the gtk only builds of OOo (which ofcourse don't need ant). Unfortunately, m88 was my last build. I'll grab a snap tonight and see if I can get passed the ant failures tomorrow, I'll also take a quick peek at fop now that I have a fresh and clean java environment to work with. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
