Re: [blfs-dev] Reverting my work
On 2/25/2014 2:20 PM, Pierre Labastie wrote: Rev 12783 has reverted what I had done for guile. I am curious why: I had suppressed instructions for building pdf docs (using texlive!), and simplified instructions to build and install html and txt doc, but had not changed anything else (I had tested that with a DESTDIR install). It is really curious to insist to put pdf doc installation instructions in the book, which almost nobody will use (you need X and a pdf reader to see them, and by the time you have that, you almost certainly have a browser and can read the html doc). Anyway, all the docs come from the same texinfo files, and building pdf docs is very standard anyway (once you have tex). Furthermore, it seems to me that it is more educational to show how to use the configure machinery to have the doc land into the correct dirs, instead of manually creating those and copying the files into them. Though I strongly disagree with your decision to remove the docs, the more important part of your commit is removing the work done by another editor without discussion. Another editor went to the trouble of adding the instructions to build and install the docs, and you just decide to remove it because you don't use pdf docs. Strange indeed! There is a whole slew of places in BLFS where extra docs are created and installed, but you remove the ones from the Guile instructions. You do realize the users have the option of not installing those docs, right? In fact, by removing those instructions you are reverting work that I did long ago. Makes no sense! -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Reverting my work
On 2/25/2014 5:26 PM, Armin K. wrote: On 25.2.2014 23:54, Randy McMurchy wrote: Though I strongly disagree with your decision to remove the docs, the more important part of your commit is removing the work done by another editor without discussion. Another editor went to the trouble of adding the instructions to build and install the docs, and you just decide to remove it because you don't use pdf docs. We have seen lot of that lately though and I really feel sorry. I'm not sure what Pierre was thinking. It could be that: 1) He doesn't realize that it was a block of instructions separate from the main body of instructions that readers can just elect not to perform. 2) He doesn't have a laTeX installation so he cannot test the instructions, and simply removed them. 3) He has a bit of dictatorship in him, and is adamant that folks use a browser to view HTML docs. What galls me the most is that I would never have said anything after I saw the commit removing my work, but then coming on to -dev and complaining that Bruce reverted his work, when in actuality it was Pierre who reverted a previous editor's work. Additionally, the work was deleted and not commented out. Ouch. Like a punch in the face! -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] discussion about sendmail
On 2/25/2014 10:43 AM, Bruce Dubbs wrote: That said, I don't have strong opinions about whether it is in the book or not. I would like to see it back in the book. As Bruce mentioned, Sendmail has a background unlike most other software. The current version still is usable and works fine. There is a reason that almost all other packages that do software emulation of Sendmail functionality installs a symlink to /usr/sbin/sendmail. Because it is the de facto standard. I do realize that life goes on and some software becomes obsolete, but Sendmail is not in that category and is still actively maintained. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Which one is dependency: libwww-perl-6.05 or LWP::Protocol::https?
On 1/20/2014 8:58 AM, Fernando de Oliveira wrote: I have installed LWP::Protocol::https, using cpan -i, then libwww-perl-6.05 got installed: snip But it is a dependency of libwww-perl-6.05, if you want the LWP installation to support the HTTPS protocol, so, I assumed, after it was installed, I could then install libwww-perl-6.05 with HTTPS support. In order words, it seems it was the other way round. IIRC, after libwww-perl is installed you can then install the LWP::Protocol::https (and CA certs) modules so that the libwww-perl installation supports the HTTPS protocol. Isn't that what the books says? -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Which one is dependency: libwww-perl-6.05 or LWP::Protocol::https?
On 1/20/2014 10:00 AM, Fernando de Oliveira wrote: May be it is difficulty from a non-English native. If you are saying that the sentence means to be installed after LWP, I would then rephrase it to: After the LWP installation, if you want HTTPS protocol support, install: ... But may be it is a particular problem of English non-proficiency. You could rephrase it like you have above if that is more clear to you; however, I thought the sentence in the introduction that says The dependencies should be installed in the order listed below. was enough to install them in the order listed. Your call if you want to change it. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libidn and dev note
On 1/14/2014 6:41 PM, Fernando de Oliveira wrote: The point (or the dumb question, forgive me for not knowing much about this) is: although it is easy to see whois is linked to libidn, I cannot notice any difference with or without. Would you an example, please? With an example, I would come to first above: being useful, should it not be recommended? I am of the opinion that the recommended dependencies are being used too often in recent updates to the book. Recommended used to be something that was used to indicate that future builds against the package would fail if the recommended package was not installed. Now it seems that if a package can use a dependency and that dependency provides something useful it is recommended. Why? Can't it be like it used to and just annotate it in the optional dependencies? If it really provides something useful, simply add the parameter in the command explanations with the explanatory text saying that adding it will provide xyz support to the package. I appreciate the work that you do for the book, Fernando, but I think that you need to let users decide for themselves what they need in each package. The Command Explanations section is used to provide information for users to decide if they need to install a package and add the necessary parameters to the configure command. My point being, let the users decide what they want. Recommended dependencies should be something that (well, this was just discussed in a previous thread) avoids failure in the future. For example, years and years ago, Gimp-Print was added as a recommended dependency to the Gimp instructions because the editor felt that you needed to print some image. I objected then and still feel the same way. A simple entry into the Command Explanations lets users know that if they don't install an optional dependency, then functionality will be lost. Let them decide. I hope this makes sense. I feel the users should be the ones that make decisions for their systems. Not BLFS developers. Additionally, making the users decide what they need (functionality-wise) is much better than developers blindly recommending packages because they feel users need it. JMHO -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Mesalib dependencies
Hi all, Listed as recommended dependencies for Mesalib is as such (current SVN book): Recommended elfutils-0.157 (required for radeon 3d drivers), libvdpau-0.7 (to build VDPAU drivers), LLVM-3.3 (required for radeon 3d drivers and also for llvmpipe which is intended to be the fastest of the three sw rasterizers, see http://www.mesa3d.org/faq.html#part3 ) Last year at about this time I wrote a message about the same thing, and the parenthetical information (nor the Note that is in the instructions now) was not included at that time. I wrote that it was confusing that packages are recommended, yet only applicable to certain hardware. I asked that there be some clarification. The parenthetical information and the Note was added. To me, it is still confusing. What I read from the quoted dependencies above is that the packages are recommended (there must be some features that are important) but are required if you have certain hardware. Though the libvdpau insertion is even more confusing (why is it recommended to build a particular driver among all the others?) So are the packages recommended because they can add important features, or they recommended because they support certain hardware? I think the ambiguity of this needs to be addressed. If it is determined that the recommended packages are there strictly to support certain hardware, then that needs to be identified. There is nothing wrong with a dependency section that explicitly says Required if you have xyz hardware. However, it needs to be in a section labeled required for xyz hardware. That way there is no ambiguity. It is either required for your hardware or it isn't. Recommended means that the editor that wrote the page thinks that the package provides enhancements that should be included, but not necessarily is mandatory. The current Mesalib instructions fail in the BLFS method of providing good information. I can fix this if the team thinks it is worth looking at. I just think it can be clarified much better. Reply if you agree or disagree. I think it is worthy of discussion. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Nitpick with Shadow Package
Hi all, Looking at the BLFS Shadow package instructions, there is a command and descriptive text for disabling the Korean and Chinese man pages. However, this is not done in LFS. Seems the two books would be consistent as far as which man pages are installed. Thoughts? -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Proposal of patch to correct bad URL
On 12/11/2013 3:47 AM, Igor Živković wrote: On 2013-12-10 21:15, Denis Mugnier wrote: Hi, For the french translation of BLFS, I check the URLs in the book. I found some bad URL, so I propose a patch to correct it. It is a first patch, another come when I have time ;o) Thanks, fixed at r12370. Could you send the next one as an attachment so it doesn't get wrapped by the mail client, please? IIRC, there is already an entry in the Makefile of the root BLFS tree that will check the validity of all the URLs. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Patch for wireshark [Was: ... r2748 - trunk/wireshark]
On 10/19/2013 8:45 AM, Fernando de Oliveira wrote: Added: trunk/wireshark/wireshark-1.10.2-packet_gluster_duplicate_enums-fix-1.patch First time I needed to add a directory for the patch. Please, tell me if there are more commands to do it in patches. It should all be fine. An automated routine copies the patch to any else working directory it needs to be in. However, the patch name is just a bit off according to policy. Should be s/enums-fix-1/enums_fix-1/ -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] NSS
On 4/4/2013 9:29 AM, Fernando de Oliveira wrote: I never noticed it, before. In make, there seems to be switches for system zlib to be used and linked. Is zlib a Required Dependency? Zlib is installed in LFS, so it is expected to be installed and no need to list it as a dependency. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-support] About audacious-plugins-3.3.3-libcdio_v0.90_fixes-1.patch
Thanos Baloukas wrote these words on 03/03/13 02:18 CST: On 03/03/2013 02:14 AM, Thanos Baloukas wrote: Hi IIRC, the last time I installed audacious-plugins-3.3.3, the dependency on libcdio-0.83 was enough for audacious to be able to play music CDs. Now on another system with libcdio-0.90, configure reported that the cdaudio-ng plugin would not be built because I lacked libcdio_cdda 0.70 or newer. After a research I found that I had to install libcdio-paranoia-10.2+0.90 which split from libcdio, if I got it right. I installed it, applied the patch, and make failed on src/cdaudio-ng/cdaudio-ng.c because it couldn't find 'cdio/paranoia/cdda.h'. On my system this file was installed from libcdio-paranoia-10.2+0.90 in /usr/include/cdio and not in /usr/include/cdio/paranoia. Looking at the patch I saw that it had: I believe it was me who introduced the patch. And I may have goofed because I recall symlinking the paranoia headers before/after creating the patch. I cannot recall the exact specifics, but I will revisit the instructions and make it right. -- Randy rmlscsi: [bogomips 1003.23] [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] 11:17:01 up 87 days, 21:16, 1 user, load average: 1.88, 1.60, 1.03 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] New package: DMD
Thomas Trepl wrote these words on 03/03/13 09:45 CST:
I've attached a patch which would add the page - you may want to have a look
to it and feedbacks would be appreciated.
The following is just my opinion and does not necessary reflect the ideas
of everyone. Just sort of how it's always been done
+ !ENTITY DMD-download-http
http://downloads.dlang.org.s3-website-us-east-1.amazonaws.com/releases/2013/dmd.dmd-version;.zip;
+ !ENTITY DMD-download-ftp
+ !ENTITY DMD-md5sumfd2211206532ab41a8aef764a9225d3c
+ !ENTITY DMD-size 31 MB
+ !ENTITY DMD-buildsize 225 MB
+ !ENTITY DMD-time 0.8 SBU
+]
+
+sect1 id=DMD xreflabel=DMD-dmd-version;
+ ?dbhtml filename=DMD.html ?
The entities and section id have almost always been in lower case as best
as I recall.
+paraPrepare the installation of applicationDMD/application by
+running the following commands:/para
+
+screenuserinputcase `uname -m` in
+x86_64) MODEL=64 ;;
+*) MODEL=32 ;;
+esac amp;amp;
+echo dmd-version; src/VERSION/userinput/screen
+
+paraInstall applicationDMD/application by running
+the following commands:/para
+
+ paraCompile the D compiler:/para
+screenuserinputcd src/dmd amp;amp;
+make MODEL=${MODEL} -f posix.mak/userinput/screen
+
+ paraCreate the D runtime:/para
+screenuserinputcd ../druntime amp;amp;
+make MODEL=${MODEL} -f posix.mak DMD=../dmd/dmd amp;amp;
+cd ../phobos amp;amp;
+make MODEL=${MODEL} -f posix.mak DMD=../dmd/dmd/userinput/screen
In almost all BLFS packages we try to encapsulate all the build commands
in one block to make cut and paste easier. Unlike the LFS book that has
a description for each command, BLFS tried to make it easy to have one
cut and paste for each block of commands, then a description of the
commands (if necessary) in the Command Explanations section.
+
+!--TODO: thats not true: --
+paraThis package does not come with a test suite./para
If it's not true, why is it there? :-)
+
+paraNow, as the systemitem class=usernameroot/systemitem
user:/para
+
+screen role=rootuserinputcd .. amp;amp;
+install -v -m755 dmd/dmd /usr/bin/ amp;amp;
+install -v -m644 druntime/lib/libdruntime-linux${MODEL}.a /usr/lib/
amp;amp;
+install -v -m644 phobos/generated/linux/release/${MODEL}/libphobos2.a
/usr/lib/ amp;amp;
+install -v -d /usr/include/d/druntime amp;amp;
+cp -v -r phobos/{*.d,etc,std} /usr/include/d/ amp;amp;
+cp -v -r druntime/import /usr/include/d/druntime//userinput/screen
+
+paraInstall the documentation with the following instructions
+as the systemitem class=usernameroot/systemitem user:/para
+
+screen role=rootuserinputcd .. amp;amp;
+install -v -d /usr/share/doc/d amp;amp;
+cp -v -r html /usr/share/doc/d/ amp;amp;
+install -v -m644 src/druntime/LICENSE /usr/share/doc/d/LICENSE amp;amp;
+
+install -v -d /usr/share/man/man1 amp;amp;
+for man in man/man1/*.1; do
+install -v -m644 $man /usr/share/man/man1/
+done amp;amp;
+install -v -d /usr/share/man/man5 amp;amp;
+for man in man/man1/*.5; do
+install -v -m644 $man /usr/share/man/man5/
+done amp;amp;
+
+install -v -d /usr/share/doc/d/samples amp;amp;
+cp -v -R samples/d/* /usr/share/doc/d/samples//userinput/screen
+
+paraCreate a configuration file which sets the default flags. This
+is used by default to set the search pathes for the D compiler:/para
+
+screenuserinputcat /etc/dmd.conf lt;lt;EOF
+[Environment]
+DFLAGS=-I/usr/include/d -I/usr/include/d/druntime/import -L-L/usr/lib
-L--no-warn-search-mismatch -L--export-dynamic
+EOF
+/userinput/screen
Again, cut and paste would be so much easier if this was all in one block
of instructions.
--
Randy
rmlscsi: [bogomips 1003.23] [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]
11:22:01 up 87 days, 21:21, 1 user, load average: 1.53, 1.53, 1.14
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
DJ Lucas wrote these words on 02/27/13 13:57 CST: Randy McMurchy ra...@linuxfromscratch.org wrote: If you did that as the root user, then the package is broken. They use their own install script as opposed to the system's install. I ran across this a long time ago, probably when system XUL patch went in. Replacing it broke stuff. But I don't intend to replace anything the xulrunner instructions do, I just intend to change the permissions of the files that are not installed root:root. -- Randy rmlscsi: [bogomips 1003.23] [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] 21:34:00 up 84 days, 7:33, 1 user, load average: 0.06, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
CC'd to BLFS-Dev On 2/24/2013 2:39 PM, Thanos Baloukas wrote: Hi I installed Xulrunner-18.0.1/Firefox-18.0.1 today. Xulrunner installed most directories and files under unprivileged user's ownership. If no one else has noticed that, then I must have done something wrong. You did nothing wrong. I just installed xulrunner (using the firefox-19.0 tarball) to DESTDIR and I see the same thing: root@rmlinux: /home/rml/build/mozilla-release find destdir ! -user root|wc -l 3983 root@rmlinux: /home/rml/build/mozilla-release find destdir|wc -l 4010 I will include commands to change ownership to root:root when I update the book to the 19.0 version. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
Ken Moffat wrote these words on 02/24/13 17:26 CST: On Sun, Feb 24, 2013 at 04:52:25PM -0600, Randy McMurchy wrote: I will include commands to change ownership to root:root when I update the book to the 19.0 version. Please fix my heinous if you have chosed (preferably, to ...chosen) when you do that. Thanks. No problem! -- Randy rmlscsi: [bogomips 1003.23] [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:27:00 up 81 days, 3:26, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
Bruce Dubbs wrote these words on 02/24/13 17:38 CST:
Randy, I 'm not 100% sure the problem is in the tarball. Many times I'll do
make DESTDIR=/tmp/pkgname install
and the user will be me, not root.
If you did that as the root user, then the package is broken. I see it very,
very, rarely. Berkeley DB comes to mind. However, my build script for
xulrunner (from a year and a half ago) contains commands to chown files.
Just like we are seeing now. Trust me, I performed 'make install' as the
root user and the installed files have ownership of the user that performed
the build. To me, this is broken behavior.
Copied file ownership depend on the
options. For instance 'cp -a source dest' preserves the owner. Yes, I
know that you know that, but generally my techniques are slightly
different. I'll do an unprivileged 'make install', check things out and
then a 'sudo make install'. My latest ff install (October) installed as
root.
After I do a 'make install DESTDIR=${PWD}/destdir' as an unprivileged user
(for packages I am unfamiliar with), I delete the DESTDIR directory and
then perform my installs as such:
sudo
date install_start.ts
make install DESTDIR=${PWD}/destdir install.log 21
date install_stop.ts
tail -20 install.log
After all ancillary installation tasks are done, I do 'exit' to return to
the unprivileged user. For all practical purposes, I perform 'make install'
as the root user. In fact, my scripts do 'chown -R rml:install destdir' as
the root user before I exit the sudo shell so that the unprivileged user
can clean up.
There are very few packages that install files with ownership other than
root:root when you run 'make install' as the root user. Firefox (xulrunner)
is one of the few. That is why I say it is an upstream issue. I have not
examined the Makefiles, as it doesn't matter, the files still are installed
with bad ownership and should be fixed as a post-installation task.
I do wonder; however, how your Firefox installation ended up with root:root
ownership. Mine doesn't, the original poster's doesn't and my build script
shows that I needed to change ownership before my latest installation.
It would be interesting to see other's findings for the installed xulrunner
files.
--
Randy
rmlscsi: [bogomips 1003.23] [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:46:00 up 81 days, 3:45, 1 user, load average: 0.00, 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
[blfs-dev] Question about lm_sensors
Hi all, In the lm_sensors instructions, there is a parameter that can be added to the make command to build sensord. Here is the description: PROG_EXTRA=sensord: This parameter enables compiling sensord, a daemon that can monitor your system at regular intervals. Compiling sensord requires RRDtool. Compiling RRDtool 1.4.6 requires a sed: sed -i '/ sv_undef/d' bindings/perl-shared/RRDs.xs. Does anyone know what the sed command is used for? It is not required to build RRDtool-1.4.7, and sensord builds fine without it. Is it required for run-time, or what? -- Randy rmlscsi: [bogomips 1003.23] [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] 21:47:01 up 79 days, 7:46, 1 user, load average: 0.31, 0.10, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] JSON-C commit
Wayne Blaszczyk wrote these words on 02/20/13 06:10 CST: It has been a while since I done an update to the book. I think I just did a commit to the book in relation to JSON-C, but something does not look right. It seems that the local version I have has missing entries in the changelog for February. Apologies if I did something wrong. If I do a svn update, it says its at revision 10963. Is this correct? No, you are using the repository on the old server. Please revert your commit as both of the files you committed have had changes not reflected in your commit. Do this: 1) Revert the commit 2) Rename your BLFS BOOK sandbox (if you want to preserve it) 3) do an svn checkout from svn.linuxfromscratch.org and ensure you are at revision 11026 4) apply and commit the changes that you intended the first time -- Randy rmlscsi: [bogomips 1003.23] [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] 06:32:00 up 76 days, 16:31, 1 user, load average: 0.63, 0.16, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] JSON-C commit
Randy McMurchy wrote these words on 02/20/13 06:37 CST: Wayne Blaszczyk wrote these words on 02/20/13 06:10 CST: It has been a while since I done an update to the book. I think I just did a commit to the book in relation to JSON-C, but something does not look right. It seems that the local version I have has missing entries in the changelog for February. Apologies if I did something wrong. If I do a svn update, it says its at revision 10963. Is this correct? No, you are using the repository on the old server. Please revert your commit as both of the files you committed have had changes not reflected in your commit. Do this: 1) Revert the commit Actually, you cannot revert the commit and put things as they were without checking out a new sandbox from svn.linuxfromscratch.org first. I'll fix the files now, and then you just do a new svn co to get things to the current revision. -- Randy rmlscsi: [bogomips 1003.23] [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] 06:42:00 up 76 days, 16:41, 1 user, load average: 0.35, 0.32, 0.19 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] JSON-C commit
Wayne Blaszczyk wrote these words on 02/20/13 06:10 CST: If I do a svn update, it says its at revision 10963. Is this correct? Sorry for my other posts as I am being stupid this morning. Please disregard. You indeed updated the repo on the old server, but nothing needs fixing as the new server has the current repo which you did not modify. Simply rename your old sandbox and do a fresh svn checkout from svn.linuxfromscratch.org and you will be at the current revision. -- Randy rmlscsi: [bogomips 1003.23] [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] 06:48:01 up 76 days, 16:47, 1 user, load average: 0.37, 0.29, 0.20 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] udisks-1.0.4
Hi all, Package udisks-1.0.4 lists LVM2 as a required dependency. However, using the BLFS instructions to build udisks1, after running ./configure the build will not include LVM2. You must add the --enable-lvm2 parameter to get the build to use LVM2. Is this something that changed has udisks1 was updated to recent versions, or just an oversight on BLFS' part? Seems to me the way things are right now that the LLVM2 package should be listed as optional for udisks1. -- Randy rmlscsi: [bogomips 1003.23] [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:46:00 up 73 days, 19:45, 1 user, load average: 0.02, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] udisks-1.0.4
Randy McMurchy wrote these words on 02/17/13 09:52 CST: Package udisks-1.0.4 [snip] Additionally, could anyone provide a log of make check. I do not see where 'sudo' comes into play (listed as a dependency for the tests), but there is a mention in the Makefile.am file; however, I cannot see that it does anything. In the tests/run script it says the script must be run by root, but nowhere is sudo called. Also, the tests require that /var/lib/udisks and var/run/udisks exist, these directories will not exist at the time make check is run. Lastly, it wants the SCSI_DEBUG kernel (builtin or module) to be available, which is unlikely for most folks as it is mentioned as used for developers and suggested that it not be built unless you know you need it (kernel help says this). I'm not going to bother with the SCSI_DEBUG kernel module so I would like to update the book about the tests. I think make check should be omitted as it is likely to fail for most folks. That's why I'd like to see a log of completed and PASSED tests as maybe it is worth keeping. -- Randy rmlscsi: [bogomips 1003.23] [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] 10:54:00 up 73 days, 20:53, 1 user, load average: 0.18, 0.09, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] udisks-1.0.4
Armin K. wrote these words on 02/18/13 11:11 CST: libdevmapper is part of LVM2. Yeah, I just saw that in configure.ac about devmapper. But thanks for the reply. -- Randy rmlscsi: [bogomips 1003.23] [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] 11:17:00 up 73 days, 21:16, 1 user, load average: 0.15, 0.07, 0.04 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] kdelibs
Hi all, If someone could confirm the following, it would be appreciated. I had to set LIBRARY_PATH=/xorg/prefix in order for kdelibs to perform make install. Without it the build fails right at the beginning with a bunch of message about cannot find -lSM, -lICE, -lX11, etc. make ran find without issues. Only make install has trouble. Note that my XORG prefix is in /opt. I've only had one or two other packages (not KDE packages) have trouble with X not being installed in /usr. -- Randy rmlscsi: [bogomips 1003.23] [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] 19:03:00 up 74 days, 5:02, 1 user, load average: 0.07, 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: [blfs-dev] kdelibs
Bruce Dubbs wrote these words on 02/17/13 19:23 CST: Randy McMurchy wrote: I had to set LIBRARY_PATH=/xorg/prefix in order for kdelibs to perform make install. Without it the build fails right at the beginning with a bunch of message about cannot find -lSM, -lICE, -lX11, etc. I've needed LIBRARY_PATH before to find the Xorg libraries for at least some packages, but my most recent script for kde-4.9.3 didn't need it. make install died immediately for me. With a LIBRARY_PATH setting, it ran fine. I'm not sure what to think of that. I was hoping someone else could confirm it, so I could update the book, but if I'm the only one that needs it, then perhaps it is something on my part. But how could that be as make ran fine? Very odd. -- Randy rmlscsi: [bogomips 1003.23] [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] 19:27:00 up 74 days, 5:26, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Minor Qca nitpick
Hi all, The Qca instructions fall back to using a bundled copy of CA Certificates because it looks for ca-bundle.crt in /etc/ssl/certs instead of the BLFS location /etc/ssl. Is there any reason we don't pass the --certstore-path parameter to configure so that the package uses the system-installed CA certificates? -- Randy rmlscsi: [bogomips 1003.23] [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] 11:29:01 up 71 days, 21:28, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Minor Qca nitpick
Ragnar Thomsen wrote these words on 02/15/13 11:43 CST: On Friday 15 February 2013 11:33:22 Randy McMurchy wrote: The Qca instructions fall back to using a bundled copy of CA Certificates because it looks for ca-bundle.crt in /etc/ssl/certs instead of the BLFS location /etc/ssl. Is there any reason we don't pass the --certstore-path parameter to configure so that the package uses the system-installed CA certificates? Not that I know of. I guess we should add the parameter... Thanks for the quick reply. I've already modified the XML to include running the test suite. I will add the CA parameter as well before committing. -- Randy rmlscsi: [bogomips 1003.23] [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] 11:45:00 up 71 days, 21:44, 1 user, load average: 0.09, 0.08, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libiodbc overwrites files from unixODBC
Armin K. wrote these words on 02/12/13 02:38 CST: There is none at the moment. All packages use pkg-config to get the CFLAGS/LDFLAGS. Archlinux does that too - --includedir --disable-iodbc and I appear to have used their instructions since nothing is overwritten on my system. Your suggestion works for the installation of libiodbc, thanks. However, I am a bit confused with the installation of the Virtuoso package. I am just now getting around to building KDE4 for the first time. Being one who likes to know the internals of the packages, I am being careful with the installation of the KDE packages. Now, back to Virtuoso. Contrary to what you say, Virtuoso does not use pkg-config to find out the location of the libiodbc headers. In fact, if you do not pass --with-iodbc=/usr to configure, it uses an internal copy of the iodbc headers located in the source tree. They probably do this because of the conflict with the unixODBC headers. Furthermore, once you pass --with-iodbc=/usr to configure, you can quickly see that it tries to use headers located in /usr/include and libs located in /usr/lib. So, I modified the one place in the configure script to add /iodbc to the cppflags section of the iodbc headers. Everything worked fine and the build was successful. So, what this means is that Virtuoso by default uses its internal copy of the headers (which are damn near exactly the same as the installed libiodbc versions). So it really makes no difference in the build, and there are only two packages (Soprano and Redland) that have Virtuoso listed as dependencies. And Soprano uses Virtuoso only at run-time according to the book. Here is what I see needs to happen in the book: 1) Add the stuff to libiodbc so that it doesn't conflict with unixODBC. 2) Change libiodbc from recommended to required in the Virtuoso instructions as the build will fail if the libiodbc libraries are not installed. 3) (optional, as it appears it doesn't matter) Add a sed command to the Virtuoso configure script to make it look in /usr/include/iodbc for the interface headers instead of using the internal copies. Can we agree on this? -- Randy rmlscsi: [bogomips 1003.23] [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:20:00 up 68 days, 19:19, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] errors in BIND page in BLFS svn
Waleed Hamra wrote these words on 02/12/13 04:44 CST: In the last batch of commands, to install the documentation, you start with a cd doc, but then, issue: install -v -m644 doc/arm/*.html \ /usr/share/doc/bind-9.9.2/arm this causes an error, and the right command is: install -v -m644 arm/*.html \ /usr/share/doc/bind-9.9.2/arm Instead, I just committed a change that removes the cd doc and added doc/ to the misc line. That way you are left in the root of the source tree instead of in the doc dir. Thanks for the report. I'll catch the broken link and typo in the bootscript as well. -- Randy rmlscsi: [bogomips 1003.23] [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:55:01 up 68 days, 19:54, 1 user, load average: 0.03, 0.20, 0.13 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Large commit
Hi all, I just ran my script that cleans up extraneous spaces from blank lines and at the end of lines in all the .xml files. The commit will probably not show up in -book as it is large. Editors (or anyone with a sandbox of current SVN trunk) ensure you do an 'svn up' before starting any edits so you won't have to worry about bad merges. Nothing was changed in any of the files other than removing extraneous spaces. -- Randy rmlscsi: [bogomips 1003.23] [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] 12:52:00 up 67 days, 22:51, 1 user, load average: 0.70, 0.36, 0.14 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Large commit
Randy McMurchy wrote these words on 02/11/13 12:55 CST: I just ran my script that cleans up extraneous spaces from blank lines and at the end of lines in all the .xml files. If you use Vim to edit the book's .xml, you can add the following lines to your /etc/vimrc file and it will show in red any extraneous spaces in the .xml. I find it handy as it makes it easy to keep the files clean. Catch trailing whitespace and highlight them highlight ForbiddenWhitespace ctermbg=red guibg=red match ForbiddenWhitespace /\s\+$\|\t/ Do not highlight spaces at the end of line while typing on that line autocmd InsertEnter * match ForbiddenWhitespace /\t\|\s\+\%#\@!$/ -- Randy rmlscsi: [bogomips 1003.23] [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] 12:59:00 up 67 days, 22:58, 1 user, load average: 0.03, 0.17, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Large commit
Bruce Dubbs wrote these words on 02/11/13 13:14 CST: Yes, its almost 500K. Do you want me to release it? Doesn't matter to me as there is really nothing to see. I can send a list of the files, but then you'll see that when you 'svn up'. I don't think it needs to be released, but let others have a say. -- Randy rmlscsi: [bogomips 1003.23] [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] 13:27:00 up 67 days, 23:26, 1 user, load average: 1.56, 1.18, 0.95 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Please use spaces and not tabs
Hi all, Grepping through the book I found about 35 files that had tabs used for indentation instead of spaces. Please do not use tabs for indentation. It appears most of them were from copy-and-paste operations (just because most of them were in the same spots in the files), so it appears it is really not an issue. Please consider this just a reminder. :-) Also, do another 'svn up' so merges don't get fouled up, though it should not be an issue as the tabs were all in oddball spots that probably would not affect anybody's edits. -- Randy rmlscsi: [bogomips 1003.23] [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:13:59 up 68 days, 4:13, 1 user, load average: 0.26, 0.16, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] libiodbc overwrites files from unixODBC
Hi all, Here's something that doesn't come up very often. It appears that the libiodbc package in BLFS overwrites files that are installed by the BLFS package unixODBC (or vice-versa, depending on how you view it). My script reports this when installing libiodbc after unixODBC is already installed: The following files will be overwritten: /usr/include/odbcinst.h /usr/include/sql.h /usr/include/sqlext.h /usr/include/sqltypes.h /usr/include/sqlucode.h /usr/lib/libodbc.so This is not good. If this has been discovered and discussed already, please excuse the noise, but I would like to know what resolution came from the issue. If it has not been discovered, then I think a discussion on how to proceed is warranted. Fortunately I converted to DESTDIR builds and an extensive logging mechanism years ago, otherwise I would have a very conflicting ODBC installation on my system (as I think others probably have). -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libiodbc overwrites files from unixODBC
Armin K. wrote these words on 02/11/13 19:15 CST: On 02/12/2013 02:12 AM, Randy McMurchy wrote: Here's something that doesn't come up very often. It appears that the libiodbc package in BLFS overwrites files that are installed by the BLFS package unixODBC (or vice-versa, depending on how you view it). My script reports this when installing libiodbc after unixODBC is already installed: The following files will be overwritten: /usr/include/odbcinst.h /usr/include/sql.h /usr/include/sqlext.h /usr/include/sqltypes.h /usr/include/sqlucode.h /usr/lib/libodbc.so Try --disable-libodbc when building libiodbc I will try this as libiodbc refers to the libiodbc library as extra (though it is odd that the package name refers to the library named after it as extra). If the library and the conflicting headers do not get installed, the problem is solved. I will report back. -- Randy rmlscsi: [bogomips 1003.23] [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] 19:33:00 up 68 days, 5:32, 1 user, load average: 0.02, 0.52, 0.75 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libiodbc overwrites files from unixODBC
Armin K. wrote these words on 02/11/13 19:15 CST: On 02/12/2013 02:12 AM, Randy McMurchy wrote: My script reports this when installing libiodbc after unixODBC is already installed: The following files will be overwritten: /usr/include/odbcinst.h /usr/include/sql.h /usr/include/sqlext.h /usr/include/sqltypes.h /usr/include/sqlucode.h /usr/lib/libodbc.so Try --disable-libodbc when building libiodbc This does disable the /usr/lib/libodbc.so symlink but does not prevent the installation (and overwriting) of the interface headers. We need to come up with some solution. At this point, it appears the libiodbc package is the one stepping on toes, though I would have to really dig into the history of the two packages to see who really came up with the header names first. Does anyone have a suggestion on how we should proceed? We simply cannot allow one package to overwrite header files from another package unless they were identical (which I have not checked, but is unlikely). -- Randy rmlscsi: [bogomips 1003.23] [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] 19:54:00 up 68 days, 5:53, 1 user, load average: 0.02, 0.06, 0.24 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libiodbc overwrites files from unixODBC
Armin K. wrote these words on 02/11/13 20:19 CST: Try --includedir=/usr/include/iodbc That would solve the problem with the overwriting of the headers (not tested), but what about the packages that expect them to be in /usr/include? Are we ready to modify the instructions for the couple of packages that have libiodbc listed as recommended? -- Randy rmlscsi: [bogomips 1003.23] [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] 20:23:00 up 68 days, 6:22, 1 user, load average: 0.18, 0.06, 0.06 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Higgs Server
Hi all, I cannot access BLFS SVN at http://www.linuxfromscratch.org/blfs/view/svn/. Can anyone confirm this? Also, the source code history in Trac has not made updates for 3 weeks. Is this because that area of Trac has not been merged? When it is fixed, will commits from the last 3 weeks show up? -- Randy rmlscsi: [bogomips 1003.23] [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:48:00 up 67 days, 47 min, 1 user, load average: 0.00, 0.01, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Does xterm work for UTF-8 ?
Ken Moffat wrote these words on 02/10/13 13:04 CST: configure:14508: checking for usable Xft/fontconfig package configure:14534: gcc -o conftest -g -O2 -D_GNU_SOURCE -DNARROWPROTO=1 -DFUNCPROTO=15 -DOSMAJORVERSION=3 -DOSMINORVERSION=8 -I/usr/include/freetype2 conftest.c -lXft -lXmu -lXt -lX11 -lXaw7 -lXt -lX11 -lSM -lICE -lXt -lX11 -lncurses 5 /usr/bin/ld: /tmp/cc2otVoJ.o: undefined reference to symbol 'FcPatternBuild' /usr/bin/ld: note: 'FcPatternBuild' is defined in DSO /usr/lib64/libfontconfig.so.1 so try adding it to the linker command line /usr/lib64/libfontconfig.so.1: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status that results in configure reporting: checking for usable Xft/fontconfig package... no I have version 287 installed and have the exact same error in my configure logs. -- Randy rmlscsi: [bogomips 1003.23] [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:51:01 up 67 days, 50 min, 1 user, load average: 0.29, 0.15, 0.06 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Higgs Server
Bruce Dubbs wrote these words on 02/10/13 15:02 CST: Randy McMurchy wrote: Hi all, I cannot access BLFS SVN at http://www.linuxfromscratch.org/blfs/view/svn/. Can anyone confirm this? Also, the source code history in Trac has not made updates for 3 weeks. Is this because that area of Trac has not been merged? When it is fixed, will commits from the last 3 weeks show up? Works for me. :) Actually, I was doing something a few minutes ago and inadvertently changed the permissions. What about the Trac updates to the source code? -- Randy rmlscsi: [bogomips 1003.23] [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:05:01 up 67 days, 1:04, 1 user, load average: 1.00, 0.71, 0.36 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Higgs Server
Bruce Dubbs wrote these words on 02/10/13 15:12 CST: Randy McMurchy wrote: What about the Trac updates to the source code? I don't understand your question. From the Trac Active Tickets (looking at the current bug list), click on the top toolbar where it says Browse Source. Then navigate to trunk and then BOOK. There you will see that the last update was 3 weeks ago. This is a very useful feature as it shows when, who, and what changes were made to every .xml file. -- Randy rmlscsi: [bogomips 1003.23] [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:13:00 up 67 days, 1:12, 1 user, load average: 2.08, 1.27, 0.73 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Inkscape build
Hi all, I'm not sure how many build Xorg outside of the /usr hierarchy, but I do and it really doesn't cause any issues. However, the build of inkscape choked at the very end when it links all the object files into the inkscape binaries with a cannot find -lX11 message (or something like that). All I had to do was put -L/usr/X11R6/lib on the LDFLAGS= line of /src/Makefile. Is this worth mentioning (to update /src/Makefile.in before starting) in the book? -- Randy rmlscsi: [bogomips 1003.23] [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:21:00 up 65 days, 18:20, 1 user, load average: 0.02, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Question about SANE
Hi all, On 10/30 of last year Bruce updated the SANE package and added the parameter --disable-latex to the configure command. There is no reason listed in the Command Explanations why. My tests show that if TeX is installed, the latex procedure does what it is supposed to. If TeX is not installed, no attempt at building docs is done. Can anyone recall this being discussed, or did you have an issue with this, Bruce? Also, the SANE instructions have a note that the user building the package should be a member of the scanner group. My tests show that the package is installed *exactly the same* if the builder is, or is not, a member of the group. Using the --with-group=scanner is enough to enable locking and the package will also then install /var/lock/sane. All files installed are root:root permissions, so I do not see where the need to be a member of the scanner group is needed to build the package. Again, can anyone recall a discussion about this, or am I just missing something here? Thanks for any help anyone can provide. -- Randy rmlscsi: [bogomips 1003.23] [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] 10:39:01 up 63 days, 20:38, 1 user, load average: 0.01, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Question about SANE
Randy McMurchy wrote these words on 02/07/13 10:48 CST: Also, the SANE instructions have a note that the user building the package should be a member of the scanner group. My tests show that the package is installed *exactly the same* if the builder is, or is not, a member of the group. Using the --with-group=scanner is enough to enable locking and the package will also then install /var/lock/sane. All files installed are root:root permissions, so I do not see where the need to be a member of the scanner group is needed to build the package. Please disregard this. For whatever reason, I missed it the first time around, but I see now that the locking feature is disabled if you are not a member of the scanner group. Sorry for the noise. -- Randy rmlscsi: [bogomips 1003.23] [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] 10:55:00 up 63 days, 20:54, 1 user, load average: 0.01, 0.08, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Question about SANE
Bruce Dubbs wrote these words on 02/07/13 11:13 CST: I do recall having a problem without the --disable-latex switch, but I don't recall the specifics. I will again hide my copies of the programs it looks for (latex and dvips) and run configure, make, and make install again. I know for a fact that it is fine if Tex *is* installed. If it doesn't barf when TeX is not found, I will remove the --disable-latex parameter. If it does barf, then I will add something to the Command Explanations. Thanks for the quick answer. -- Randy rmlscsi: [bogomips 1003.23] [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] 11:16:00 up 63 days, 21:15, 1 user, load average: 0.00, 0.00, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Support for old LFS versions
Hi all, Going through the book I noticed that many of the pkgconfig dependencies have been removed/commented out. I commented out the remaining ones. Armin brings up a good point about supporting past versions of LFS as well as current trunk. I think it would be difficult to support past versions (from so long ago) without some breakage. I'd like to discuss this. As far as pkgconfig goes, I know it was in and out of LFS for a period of time. What versions of LFS do not include pkgconfig? -- Randy rmlscsi: [bogomips 1003.23] [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] 13:39:00 up 63 days, 23:38, 1 user, load average: 0.55, 0.25, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Support for old LFS versions
Ken Moffat wrote these words on 02/07/13 14:46 CST: Like Armin said - 7.0 and 7.1. I don't regard those as so long ago. I wasn't sure and was not able to view the museum archives on the new server. However, the pkg-config page in BLFS has a good note on it that I just now saw. I will revert the changes made in the prior commit and find all the other places where a pkgconfig dependency was removed as well. -- Randy rmlscsi: [bogomips 1003.23] [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:52:00 up 64 days, 51 min, 1 user, load average: 0.08, 0.20, 0.28 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] DejaVu Fonts Instructions
Hi all, In the DejaVu Fonts installation instructions shown on the Xorg configuration page, the instructions seem to need an update. First, the fonts are now in a subdirectory of the source directory, so the installation of the TTF files do not work as shown in the book. However, the reason I'm asking is that there are .conf files shipped in the tarball that are designed to be installed in /etc/fonts/conf.d, yet there is no instruction to install them. Are they required, or do they help fontconfig in the use of the DejaVu fonts, or can these files be reasonably dismissed? -- Randy rmlscsi: [bogomips 1003.23] [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] 19:17:02 up 63 days, 5:16, 1 user, load average: 0.47, 0.13, 0.04 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] DejaVu Fonts Instructions
Bruce Dubbs wrote these words on 02/06/13 20:00 CST: Randy McMurchy wrote: However, the reason I'm asking is that there are .conf files shipped in the tarball that are designed to be installed in /etc/fonts/conf.d, yet there is no instruction to install them. Are they required, or do they help fontconfig in the use of the DejaVu fonts, or can these files be reasonably dismissed? I don't know the answer to your question, but there is /etc/fonts/conf.d/README. It indicates the .conf files go in conf.avail/ and conf.d/ should have links there. Which is actually contrary to what Fontconfig does on the initial installation. Fontconfig puts the .conf files in /usr/share/fontconfig/conf.avail (note that it is not /etc/fonts/conf.avail, which exists and is populated on my system) and then symlinks them in /etc/fonts/conf.d. Other packages install directly to /etc/fonts/conf.d. Here is what I have now in /etc/fonts/conf.d: randy@rmlinux: ~ ls -lrt /etc/fonts/conf.d total 36 -rw-r--r-- 1 root root 959 Dec 12 15:17 README lrwxrwxrwx 1 root root 50 Dec 14 14:12 90-synthetic.conf - /usr/share/fontconfig/conf.avail/90-synthetic.conf lrwxrwxrwx 1 root root 50 Dec 14 14:12 80-delicious.conf - /usr/share/fontconfig/conf.avail/80-delicious.conf lrwxrwxrwx 1 root root 48 Dec 14 14:12 69-unifont.conf - /usr/share/fontconfig/conf.avail/69-unifont.conf lrwxrwxrwx 1 root root 49 Dec 14 14:12 65-nonlatin.conf - /usr/share/fontconfig/conf.avail/65-nonlatin.conf lrwxrwxrwx 1 root root 54 Dec 14 14:12 65-fonts-persian.conf - /usr/share/fontconfig/conf.avail/65-fonts-persian.conf lrwxrwxrwx 1 root root 46 Dec 14 14:12 60-latin.conf - /usr/share/fontconfig/conf.avail/60-latin.conf lrwxrwxrwx 1 root root 46 Dec 14 14:12 51-local.conf - /usr/share/fontconfig/conf.avail/51-local.conf lrwxrwxrwx 1 root root 45 Dec 14 14:12 50-user.conf - /usr/share/fontconfig/conf.avail/50-user.conf lrwxrwxrwx 1 root root 50 Dec 14 14:12 49-sansserif.conf - /usr/share/fontconfig/conf.avail/49-sansserif.conf lrwxrwxrwx 1 root root 46 Dec 14 14:12 45-latin.conf - /usr/share/fontconfig/conf.avail/45-latin.conf lrwxrwxrwx 1 root root 49 Dec 14 14:12 40-nonlatin.conf - /usr/share/fontconfig/conf.avail/40-nonlatin.conf lrwxrwxrwx 1 root root 52 Dec 14 14:12 30-urw-aliases.conf - /usr/share/fontconfig/conf.avail/30-urw-aliases.conf lrwxrwxrwx 1 root root 55 Dec 14 14:12 30-metric-aliases.conf - /usr/share/fontconfig/conf.avail/30-metric-aliases.conf lrwxrwxrwx 1 root root 58 Dec 14 14:12 20-unhint-small-vera.conf - /usr/share/fontconfig/conf.avail/20-unhint-small-vera.conf -rw-r--r-- 1 root root 389 Dec 21 10:08 42-luxi-mono.conf -rw-r--r-- 1 root root 366 Jan 12 21:25 99pdftoopvp.conf Really doesn't matter, but why would the maintainers at DejaVu fonts put files into their tarball in the fontconfig directory if they were not meant to be installed? I'm more curious than anything. -- Randy rmlscsi: [bogomips 1003.23] [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] 20:09:02 up 63 days, 6:08, 1 user, load average: 0.32, 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: [blfs-dev] DejaVu Fonts Instructions
Ken Moffat wrote these words on 02/06/13 20:52 CST: Do the files from the tarball match what is already installed by fontconfig, or are they different/additional ? The .conf files in the DejaVu tarball are different than any shipped by Fontconfig. In fact, the README (or whatever it is I read in the DejaVu tarball) said they are cloned from the Vera fonts (which DejaVu forked). What that means is uncertain to me, but there are differences in any of the files installed by Fontconfig. Thanks for responding, Ken, as I am uncertain of the fontconfig/dejavu/whatever font system. I just install them and run with it. Tonight is the first time I ever really looked into the details of /etc/fonts/conf.d, et al. -- Randy rmlscsi: [bogomips 1003.23] [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] 21:02:00 up 63 days, 7:01, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Misc cache updates
Hi all, I added three new files to the xincludes directory to assist with adding update-desktop-database and gtk-update-icon-cache commands to packages. As these commands are not run by default if a package installs hicolor icons or desktop files, I thought it prudent that we remind readers that running these programs improves desktop performance. One file is just for update-desktop-database, one just for gtk-update-icon-cache and one that updates both. I've updated the following packages as they are the only ones that I have installed that install icons or desktop files: trunk/BOOK/multimedia/audioutils/audacious.xml trunk/BOOK/multimedia/videoutils/ffmpeg.xml trunk/BOOK/multimedia/videoutils/mplayer.xml trunk/BOOK/multimedia/videoutils/xine-ui.xml trunk/BOOK/networking/netprogs/wpa_supplicant.xml trunk/BOOK/pst/printing/cups.xml trunk/BOOK/xsoft/other/gimp.xml If your logs or memory shows that other packages need this update also, please jump in and update the files. Simply placing the following two lines at the end of the installation commands is all that is necessary. Most packages need to update both the icons and desktop files, but some just do one of the other: xi:include xmlns:xi=http://www.w3.org/2001/XInclude; href=../../xincludes/update-icons-and-desktop.xml/ -- Randy rmlscsi: [bogomips 1003.23] [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:29:00 up 58 days, 2:28, 1 user, load average: 0.03, 0.05, 0.04 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Misc cache updates
Randy McMurchy wrote these words on 02/01/13 16:38 CST: I've updated the following packages as they are the only ones that I have installed that install icons or desktop files: trunk/BOOK/multimedia/audioutils/audacious.xml trunk/BOOK/multimedia/videoutils/ffmpeg.xml trunk/BOOK/multimedia/videoutils/mplayer.xml trunk/BOOK/multimedia/videoutils/xine-ui.xml trunk/BOOK/networking/netprogs/wpa_supplicant.xml trunk/BOOK/pst/printing/cups.xml trunk/BOOK/xsoft/other/gimp.xml VLC was also updated to include the xinclude update. -- Randy rmlscsi: [bogomips 1003.23] [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:45:00 up 58 days, 2:44, 1 user, load average: 0.24, 0.16, 0.10 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Samba4
Thomas Trepl wrote these words on 01/31/13 12:39 CST: It turns out that this is no longer true. Seems so that AD-controller functionality is indeed only available when having Heimdal around. [snip] Currently, there seems to be no way to get AD-DC functionality with using any krb package except (the bundled?) Heimdal. I am just finishing up a Heimdal build. I will put it back into the book and maintain it going forward. Thanks for the great observations, Thomas. -- Randy rmlscsi: [bogomips 1003.23] [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:37:00 up 57 days, 36 min, 1 user, load average: 0.06, 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: [blfs-dev] krb5 + tcl,python
Thomas Trepl wrote these words on 01/28/13 00:58 CST: MIT-krb5 as Heimdal left the BLFS book. Yes you're right, Samba recommends Heimdal (i read that somewhere in their prerequisite wiki page) and indeed, there is something included in the source tree. But there is also a --with-system-mitkrb5 switch for configure. So i think MIT-krb5 should be supported too. I can put Heimdal back in the book and maintain it going forward. Like DJ, I have always used Heimdal for all of my Kerberos implementations. -- Randy rmlscsi: [bogomips 1003.23] [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] 07:16:00 up 53 days, 17:15, 1 user, load average: 0.24, 0.06, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] edguide
Thomas Trepl wrote these words on 01/25/13 00:54 CST: Q: svn repo lives on svn.linuxfromscratch.org from now on? The edguide names it at linuxfromscratch.org which actually points to quantum. That may be the reason for some misconfigured sandboxes. It sure explains mine. I followed the Guide and it got my sandbox messed up. Go figure. I have it all fixed now. As Bruce mentioned, I'm using svn.linuxfromscratch.org now for SVN. Thanks for fixing up the Guide. -- Randy rmlscsi: [bogomips 1003.23] [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] 06:23:01 up 50 days, 16:22, 1 user, load average: 0.98, 0.31, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] More BLFS Protocol
Hi all,
As long as we are on the track of discussing the book's protocol (see discussion
on -book), there is another thing I'd like to mention. The patches project for
years had a maintainer (hey Tushar, you out there?) who was fairly strict in how
the patches must be formatted and how there were named. I'd like to refresh
folks
on that protocol.
The patches must have the standard {,B}LFS header:
Submitted By:Your Name yourname_at_linuxfromscratch_dot_org
Date:2005-08-18
Initial Package Version: 2.0.47
Upstream Status: Not submitted (LFS specific) (put whatever is
applicable)
Origin: (put whatever is applicable)
Description: Fixes (put whatever is applicable)
The name of the patch also should conform to the following convention:
packagename-packageversion-name_of_the_patch-versionnumber.patch
which would look like this:
package-1.2.3-build_fixes-1.patch
Notice the dashes and the underscores. The underscores are used in the name of
the
patch, everywhere else is dashes. I've noticed many new BLFS patches use dashes
in
the name and not underscores. No big deal, but was the required convention for
years and years.
Last, the patch should apply using syntax of patch -Np1 -i nameofpatch
--
Randy
rmlscsi: [bogomips 1003.23] [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]
07:07:00 up 50 days, 17:06, 1 user, load average: 0.06, 0.06, 0.08
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] A good example why Command Explanations are important
Hi all, Earlier there was/is a discussion on why BLFS is adamant about describing the various commands/descriptions/parameters/options used in the instructions for BLFS packages. I would like to present a really good example why these trivial (to us Editors) blurbs in the book are important. Installing the Obexd package today I noticed: 1) There is a sed command that adds a header file to one of the .c files in the tarball before configure is run, there is no description of what it does in the Command Explanations, and without the sed command the package builds and installs with no problems. Shouldn't readers be advised to why they must run this command that apparently does nothing to help the build? 2) There is a --sysconfdir=/etc switch to configure, yet there are no files installed to /etc and no explanation why this must be passed during the configure phase of the build. It seems as though the original editor who installed the package used it 'just in case' there may be configuration files in /etc. We cannot guess about this. We must be certain when we put stuff in the book. Otherwise, we look like we are guessing at configuration options. 3) The --libexecdir= switch points to a non-standard location. libexecdir location has always been /usr/lib/packagename, yet in the Obexd instructions, the location varies from this. Is this because other packages expect it to be where the libexecdir switch points to it, or simply because the Editor who originally put the package in BLFS decided to go against the standards that we have created? 4) The packages is a simple CMMI installation that varies from the standards that BLFS has been using for years and years. Shouldn't there be some sort of explanation why the instructions vary from the standards? Sorry for the rant, it got longer than I wanted, but I wanted to point out that (as Bruce said) BLFS is not a linear installation process. We do not know where a reader will start his/her BLFS adventure. So, because of this, we must realize that a reader needs information as much as possible, as mundane and redundant that it may seem to us Editors. -- Randy rmlscsi: [bogomips 1003.23] [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] 21:43:01 up 51 days, 7:42, 1 user, load average: 0.00, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] More about the Higgs Syncronization
Hi all, First, let's stop all commits to BLFS until we get this worked out. There is definitely two repos out there. One has commits I've made (on Quantum), the other has commits Armin has made (on Higgs). Rendering of the book is still coming from the old repo (Quantum) as my changes are shown this morning after last night's rendering, and Armin's changes are not reflected. However, the patches I've committed are not reflected as they are going to Higgs. Let's get this fixed before any more commits. We have to decide which repo to use, and then everyone get synced to that one. I noticed in a message to LFS-Dev that Gerard has not got DNS fixed so that things all point at Higgs. Until then, we should probably wait and see where things fall. Can we agree on this? -- Randy rmlscsi: [bogomips 1003.23] [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] 07:16:00 up 49 days, 17:15, 1 user, load average: 0.14, 0.14, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Higgs Syncronization
Matthew Burgess wrote these words on 01/24/13 07:41 CST: On Thu, 24 Jan 2013 07:06:22 -0600, Randy McMurchy ra...@linuxfromscratch.org wrote: randy@rmlinux: ~/Books/BLFS/BOOK svn status -u Status against revision: 10962 randy@rmlinux: ~/Books/BLFS/BOOK svn up What does 'svn info' show for your URL. I wonder if you've got 'svn+ssh://quantum.linuxfromscratch.org/' in there, and not 'svn+ssh://svn.linuxfromscratch.org/')? I had 'svn+ssh://linuxfromscratch.org/' which unfortunately points to the quantum server. I know what is going on now. I just want to get the two repos synced together. -- Randy rmlscsi: [bogomips 1003.23] [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:20:00 up 49 days, 18:19, 1 user, load average: 0.23, 0.09, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Higgs Syncronization
Randy McMurchy wrote these words on 01/24/13 08:23 CST: I just want to get the two repos synced together. Done. I migrated all the changes I made to the repo on Quantum to the repo on Higgs. Sorry for the noise and trouble. It was confusing to me for a bit. -- Randy rmlscsi: [bogomips 1003.23] [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:01:00 up 49 days, 19:00, 1 user, load average: 0.25, 0.19, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] OpenOBEX
Hi all, The book lists the current version of OpenOBEX as 1.6 and available only from the Anduin server. The same (what appears to be) version of the package can also be downloaded from Sourceforge at http://sourceforge.net/projects/openobex/files/openobex/1.6/ Should the link in the book reflect the actual source, or has the package on the Anduin server been modified in some way (note that the filename of the source package is different)? If they are the same, I suggest we revert to using the Sourceforge link as it is much easier to look for updates using the maintainers hosting site. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Higgs Syncronization
Hi all, Somehow, my installation of the BLFS book in my sandbox doesn't point at the new server. I do not even want to think how it happened as I have been cloning my sandbox (BLFS repo) for years every time I have a new build. My most recent updates are not being reflected in the SVN BOOK, but the commit messages are coming through fine. The commit #'s conflict with some of the other recent commits, so I'm asking everyone to not commit until I fix this. I am working on it right now, but until I fix it, it will be more and more difficult to fix as long as others make updates. This is weird. I emailed Bruce about it yesterday, but didn't think too much about it; however, there has been recent commits that I see on the higgs server that I cannot see when I do svn update. Please hold off on any more BLFS BOOK updates until I get this fixed. Thanks. -- Randy rmlscsi: [bogomips 1003.23] [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] 20:44:00 up 49 days, 6:43, 1 user, load average: 0.02, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] [Fwd: Higgs Syncronization]
What makes it even more difficult is the half-hour delay from sending a message on the email list until it is delivered (commit messages are the same). Hopefully this will be corrected, soon. I did a fresh checkout of the BLFS BOOK and I'll try to sync my recent changes to it and then commit. I wish I knew how this got screwed up. The Patches repo synced up fine, but BLFS is really messed up on my end. Original Message Subject: Higgs Syncronization Date: Wed, 23 Jan 2013 20:51:31 -0600 From: Randy McMurchy ra...@linuxfromscratch.org To: BLFS Development List blfs-dev@linuxfromscratch.org Hi all, Somehow, my installation of the BLFS book in my sandbox doesn't point at the new server. [snip rest of message] -- Randy rmlscsi: [bogomips 1003.23] [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] 21:13:01 up 49 days, 7:12, 1 user, load average: 0.01, 0.02, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Persistent files/directories in /run
Hi all, Excuse my ignorance on this subject as the /run filesystem is new to me and I am curious how everyone is handling directories in /run that are expected to exist after a system reboot. Many packages create directories during their installation procedure in /run (or /var/run, which is the same due to the symlink). After a reboot, my understanding is that the tempfs filesystem mounted at /run is recreated. Those directories that are created during some package's installation procedure are then gone. Do these directories get created when the package is started at boot-time, or are they expected to be there? I realize that /etc/sysconfig/createfiles exists and can be used to create any directories required by packages before they are started at boottime. However, the book does not mention doing this. Again, my apologies for not being keen on the process. I would appreciate any guidance on how y'all are handling the creation of these directories that packages expect to exist, but do not after a system reboot. I have not rebooted my system after exiting chroot and starting in on base BLFS packages, so I do not know what will happen after a reboot. Currently in /run I have this: rml@rmlinux: ~/build ls -lrt /run total 48 drwxr-xr-x 2 root root 40 Dec 17 09:11 lock drwxr-xr-x 2 root root 60 Dec 17 09:11 mount -rw-r--r-- 1 root root 4 Dec 17 15:11 syslogd.pid -rw-r--r-- 1 root root 4 Dec 17 15:11 klogd.pid -rw-r--r-- 1 root root 5 Dec 17 15:11 crond.pid drwxr-xr-x 2 root root 60 Dec 18 09:40 var drwxr-xr-x 2 mysql mysql60 Dec 18 09:40 mysql drwxr-xr-x 2 root root 40 Dec 18 15:51 openldap -rw-r--r-- 1 root root 6 Dec 19 10:32 sshd.pid drwxr-xr-x 5 root root140 Dec 22 09:49 udev -rw--- 1 root smmsp44 Dec 22 14:24 sendmail.pid drwxr-xr-x 2 root root 80 Dec 22 17:01 dbus -rw-r--r-- 1 root root 4 Dec 28 04:46 authdigest_shm.3011 srwx-- 1 apache root 0 Dec 28 04:46 cgisock.3011 -rw-r--r-- 1 root root 5 Dec 28 04:46 httpd.pid drwxr-xr-x 2 root root 40 Jan 7 12:23 pulse drwxr-xr-x 3 root lp 80 Jan 9 19:33 cups -rw-r--r-- 1 root root 6 Jan 9 19:58 nmbd.pid -rw-r--r-- 1 root root 6 Jan 9 19:58 smbd.pid drwxrwxrwt 2 root root 40 Jan 17 14:07 shm drwxr-xr-x 2 root root 40 Jan 18 22:12 ConsoleKit drwx-- 2 root root 40 Jan 19 15:42 NetworkManager -rw-rw-r-- 1 root utmp 11136 Jan 21 09:15 utmp An example is the directory created by NetworkManager that has permissions of 700. Is this directory automatically recreated at system boot, and if not, does NetworkManager expect it to exist? Thanks for the help anyone can provide. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] ConsoleKit
Hi all, My apologies right here at the beginning if this subject has been discussed and I missed the discussion. I am curious about BLFS' view on the obsolete and deprecated package ConsoleKit. ConsoleKit is listed as a dependency for several BLFS packages, and recommended for at least one package. The issue is the package is unmaintained. We (BLFS) list ConsoleKit in the Security section of the book. It would seem to me that packages in the Security section would have a solid base behind it, and the package would be looked at closely. However, because ConsoleKit is now abandoned, deprecated, and apparently has been replaced by the systemd package (which BLFS doesn't support), it seems that this would be a security hole. I am not saying that the current BLFS situation with ConsoleKit is a security hole, I am just saying that it could turn in to one. I would like a discussion about the future of our direction toward the ConsoleKit deprecation, and the apparent move by most other distribution's move toward systemd. If anyone is interested in discussion, I encourage your participation. -- Randy rmlscsi: [bogomips 1003.23] [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] 20:35:00 up 44 days, 6:34, 1 user, load average: 0.78, 0.26, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Glib-networking make check
CC'd to BLFS-Dev, follow-ups should be made there, as this is now a -dev issue On 1/17/2013 2:55 PM, Armin K. wrote: Try: glib-compile-schemas-2.0 /usr/share/glib-2.0/schemas and re-run make check Thanks for the quick reply. I ran the command 'glib-compile-schemas /usr/share/glib-2.0/schemas' (note that there is no -2.0) and it created /usr/share/glib-2.0/schemas/gschemas.compiled I had already went ahead and installed glib-networking and after running the command above the make check works up to a point. I think the fix is running the command, and that command probably needs to be on the gsettings-desktop-schemas instructions. However, 'make check' still does not run to completion. The error was discovered on 11/17 last year and somebody emailed to BLFS-Support but it went unanswered. Here is that mail. I,m having trouble running make check on glib-networking-2.34.2 I recieve an error T: connection... (pid=18853) /tls/connection/basic: OK /tls/connection/verified: OK /tls/connection/client-auth: OK /tls/connection/client-auth-rehandshake: OK /tls/connection/no-database: OK /tls/connection/failed: OK /tls/connection/socket-client: OK /tls/connection/socket-client-failed: OK /tls/connection/simultaneous-async: OK /tls/connection/simultaneous-sync: OK /tls/connection/simultaneous-async-rehandshake: ** GLib-Net:ERROR:connection.c:300:run_echo_server: assertion failed (error == NULL): Error performing TLS handshake: An unexpected TLS packet was received. (g-tls-error-quark, 1) FAIL GTester: last random seed: R02S7be3a64a8d3d987836f32404cc10adc9 /bin/sh: line 1: 18849 Terminated gtester --verbose certificate file-database connection pkcs11-util pkcs11-array pkcs11-pin pkcs11-slot make[2]: *** [test-nonrecursive] Error 143 make[2]: Leaving directory `/home/spiky/Downloads/glib-networking-2.34.2/tls/tests' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/spiky/Downloads/glib-networking-2.34.2/tls/tests' make: *** [check-recursive] Error 1 I would like to get to the bottom of this, any advice on errors pls I get the same exact error. I am not sure if this is worth reporting upstream; however, we should probably mention it in the book. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Glib-networking make check
On 1/17/2013 3:46 PM, Armin K. wrote: However, gschemas.compiled should be createad by GTK+3 and gsettings-desktop-schemas (or any other packages that installs GSettings schemas) make install process unless you are using DESTDIR method. I see. That is the case. And because in some spots of the book where there is issues like this when using DESTDIR it is mentioned what to do, I think I'll add a little something to the gsettings instructions. Thanks for the tip, Armin. I think that it might be related to newer GnuTLS that BLFS has. I don't remember seeing that with 3.0 versions of GnuTLS. I will see if 'make -k check' runs to completion with just the one error. If so, a book update and a mention about the error is probably warranted. However, if more tests fail, it would probably be best to just update the book to say the tests do not run correctly and to not run them. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] spice (libvirt)
On 1/7/2013 9:38 AM, Tobias Gasser wrote: as spice-gtk 0.15 is dated 12/21 it is just a few days newer then gtk3 3.7.4 which is from 12/18. maybe i'll have to restart once again with gtk3 3.6.3 which is in the book (or try 3.6.4 which is avaiable now). so far i had no issues with 3.7.4 (xfce, firefox, openoffice, gimp) You do realize that the 3.7.x branch of GTK+ is developmental, right? Current stable is 3.6.x, and the 3.7.x branch is what will eventually become the stable 3.8.x branch. Though I personally have never used the developmental branch, others have and typically the results are not real good. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] QT Installation
Hi all, Noted in the log from the ./configure command at the beginning of my recent QT build is this: This target is using the GNU C++ compiler (linux-g++). Recent versions of this compiler automatically include code for exceptions, which increase both the size of the Qt libraries and the amount of memory taken by your applications. You may choose to re-run configure with the -no-exceptions option to compile Qt without exceptions. This is completely binary compatible, and existing applications will continue to work. I know my build script used to include the -no-exceptions flag to the configure command, but it has been removed from the book. I am not really sure what exactly it does, but it seems the passage above would indicate that -no-exceptions would be preferred. Thoughts? -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] FOP Hyphenation Patterns
Hi all, Can anyone recall why the instructions to install the FOP Hyphenation Patterns are commented out of the FOP instructions? The OFFO package is still available and works just fine using the instructions that are now commented out. It also allows the unit tests to complete without complaining about hyphenation patterns. -- Randy rmlscsi: [bogomips 1003.23] [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:44:00 up 30 days, 4:43, 1 user, load average: 0.01, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] LLVM Notes
Hi all, Does anyone recall why there are CC= and CXX= lines prefacing the configure command in the LLVM instructions? I am not certain they are required. My build was fine without them. Also, the docs are installed into /usr/docs instead of /usr/share/doc/llvm=3.1, we could probably use a docdir= line in configure or at least move them after the installation. Also, there appears to be additional dependencies, TCL, OCaml, and Valgrind were looked for during the configure phase. It did not find the TCL include files on my system, and I do not have OCaml installed, so I am not sure if it wants to build bindings for those languages or what. Package takes too long to build to simply get X installed. :-( -- Randy rmlscsi: [bogomips 1003.23] [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:00:00 up 15 days, 2:59, 6 users, load average: 0.05, 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: [blfs-dev] LLVM Notes
Armin K. wrote these words on 12/20/12 17:30 CST: On 12/21/2012 12:12 AM, Randy McMurchy wrote: Hi all, Does anyone recall why there are CC= and CXX= lines prefacing the configure command in the LLVM instructions? I am not certain they are required. My build was fine without them. If you have clang installed configure will fail with C compiler cannot create executables. Not here, worked fine. I had the clang installed, the executables and libraries were built with no trouble. I did not have the CC= or CXX= lines prefacing configure. Perhaps a review of this is in order? Also, the docs are installed into /usr/docs instead of /usr/share/doc/llvm=3.1, we could probably use a docdir= line in configure or at least move them after the installation. There is a ticket for that already. I think that Bruce used instructions from Archlinux when he updated LLVM (as I pointed him there), but I think that sed didn't work out and didn't set docdir right. Maybe newer pkgbuilds at Archlinux fix that? Dunno, but at least we could provide instructions to move the docs after the installation? Also, there appears to be additional dependencies, TCL, OCaml, and Valgrind were looked for during the configure phase. It did not find the TCL include files on my system, and I do not have OCaml installed, so I am not sure if it wants to build bindings for those languages or what. Not sure about TCL but there are OCAML bindings. The dependency should be listed. Package takes too long to build to simply get X installed. :-( Not required unless you have Radeon cards (r300 chips and later). Again, perhaps that should be noted in the instructions so that folks don't spend 2.5 hours building something that they don't need. It should only be a recommended dependency if you have a Radeon card. :-) -- Randy rmlscsi: [bogomips 1003.23] [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:33:00 up 15 days, 3:32, 6 users, load average: 0.45, 0.12, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] TCP-Wrappers
Hi all, Just out of curiosity, why are instances of the dependency TCP-Wrappers labeled as deprecated? As best as I can tell, it is still a valid utility to control access to system daemons and resources. Though I can see IPTables as a more robust package, Wrappers still works fine for small networks and is much easier to configure. No big deal, I was just trying to find out the reasoning. -- Randy rmlscsi: [bogomips 1003.23] [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] 20:12:00 up 10 days, 6:11, 1 user, load average: 0.02, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] TCP-Wrappers
Ken Moffat wrote these words on 12/15/12 20:39 CST: On Sat, Dec 15, 2012 at 08:16:12PM -0600, Randy McMurchy wrote: No big deal, I was just trying to find out the reasoning. Please see the BLFS-dev archives from June 2012 under the title 'TCP Wrapper'. I agree with your comments, but I've managed to get iptables configured to replace it and so I'm happy to live without it. Put the emphasis on 'IPTables [is] more robust'. But why can't we give users the choice? Wrappers still builds without errors and works as it was intended. There is no maintenance involved from a BLFS editor perspective. For these reasons I wonder why it was removed and marked as deprecated. Other distros still ship it, right? Again, I'm not arguing, just trying to discover the reasoning for removing a package that builds fine, is functional, and was written by one of the fathers of Unix and free software. The package (unlike most) has stood the test of time. :-) -- Randy rmlscsi: [bogomips 1003.23] [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] 20:43:00 up 10 days, 6:42, 1 user, load average: 0.02, 0.04, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] TCP-Wrappers
On 12/15/2012 8:47 PM, Randy McMurchy wrote: Again, I'm not arguing, just trying to discover the reasoning for removing a package that builds fine, is functional, and was written by one of the fathers of Unix and free software. The package (unlike most) has stood the test of time. :-) Actually, I had in my head that it was written by Bruce Perens; however, it was written by Wietse Venema, who is also a very renown programmer. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] TCP-Wrappers
Bruce Dubbs wrote these words on 12/15/12 21:23 CST: tcpwrappers just gets in the way. For -support issues, it causes more problems then it solves. What problems is it expected to solve? :-) (sarcasm) I suppose it is difficult to explain the syntax of the hosts.allow and hosts.deny files(/sarcasm). Just teasing Bruce. However, I simply cannot see how Wrappers would be difficult for one to set up (considering the BLFS user base and the requirement that one has a somewhat knowledgeable Linux background). -- Randy rmlscsi: [bogomips 1003.23] [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] 21:34:00 up 10 days, 7:33, 1 user, load average: 0.62, 0.25, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] TCP-Wrappers
Bruce Dubbs wrote these words on 12/15/12 21:52 CST: My point is to ask what benefits does it provide? How many untrusted users are on your network? How many systems on your network have servers facing the Internet? In those cases, iptables does a *much* more complete job of protecting your systems. Agreed on all counts about IPTables. I just feel that Wrappers still has a place for some users. Again, no big deal. -- Randy rmlscsi: [bogomips 1003.23] [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] 21:53:01 up 10 days, 7:52, 1 user, load average: 0.00, 0.05, 0.07 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] libtirpc
Hi all, I am a bit confused with the language in the libtirpc instructions. Paraphrasing, it says that /usr/include/rpc/rpc.h should not be installed by default if the version of Glibc is =2.14, but I just installed current LFS-Development that includes Glibc-2.16 and that header file *is* installed (following the LFS-Dev book). Is this something that was just overlooked, or did the Glibc instructions get modified to include installing this header file and BLFS was not updated? -- Randy rmlscsi: [bogomips 1003.23] [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] 22:01:00 up 10 days, 8:00, 1 user, load average: 0.02, 0.10, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libtirpc
Bruce Dubbs wrote these words on 12/15/12 22:29 CST: The glibc folks left it out for a couple of versions and then put it back after a lot of complaints. LFS 7.1 had the problem of leaving it out. Which means the text in the BLFS book should be modified ever so slightly. -- Randy rmlscsi: [bogomips 1003.23] [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] 22:32:00 up 10 days, 8:31, 1 user, load average: 0.06, 0.05, 0.04 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libtirpc
Bruce Dubbs wrote these words on 12/15/12 22:41 CST: Randy McMurchy wrote: Bruce Dubbs wrote these words on 12/15/12 22:29 CST: The glibc folks left it out for a couple of versions and then put it back after a lot of complaints. LFS 7.1 had the problem of leaving it out. Which means the text in the BLFS book should be modified ever so slightly. Which text? Would s/later/2.15/ do it? If so, I'd make the change without a change log entry. I don't think really minor changes need log entries. It is the opposite. The book says that versions *later* than (whatever is there now) does not include it. However, 2.16 *does* include it. So, the text as is, needs to be modified so that it reflects the Glibc versions that do not include the header file. Current Glibc *does* include it. I can fix it if you like. -- Randy rmlscsi: [bogomips 1003.23] [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] 22:45:00 up 10 days, 8:44, 1 user, load average: 0.03, 0.04, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Perl Modules
Ken Moffat wrote these words on 12/12/12 17:33 CST: On Tue, Dec 11, 2012 at 07:43:41PM -0600, Randy McMurchy wrote: rmlscsi: [bogomips 1003.23] [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] 19:32:00 up 6 days, 5:31, 1 user, load average: 0.20, 0.06, 0.02 I hope those aren't the versions you are using to _test_ any general changes you are making ;-) Gosh, if I were to use that box for testing, I'd have to give up. It is very slow. I only use it for email. In fact, I don't even need it as I have many machines available, but it has sentimental value. I've had it forever and it won't die. It is too slow to update to a current release of LFS, though I suppose I could fire up JHalfs and wait a few days! But then I would have to install X and Thunderbird. I shudder at the thought of doing that on this machine. It works fine as my LFS email client. :-) -- Randy rmlscsi: [bogomips 1003.23] [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:15:00 up 7 days, 4:14, 1 user, load average: 0.12, 0.06, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Perl Modules
Hi all, I've been working on updating the Perl Modules page. I really like how all the dependency links now point at a page where you can download the current version of the package instead of hard-coding a version into the BLFS instructions. This makes the upkeep of the Perl Modules page much more simple. I cannot see a reason why we do not point all Perl Modules to a development page where you can download it. This would make a zero maintenance environment for the Perl Modules from an editor standpoint. There really is no reason to hard code version numbers into the BLFS Perl Module instructions any longer now that individual pages exist on CPAN for each module. I would like to get rid of hard-coding version numbers for *all* Perl modules. It would be an easy task to do this. And then the BLFS editor staff never has to worry about updating the page or keeping links on Anduin current. It seems win-win to me. Thoughts? -- Randy rmlscsi: [bogomips 1003.23] [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:36:00 up 6 days, 4:35, 1 user, load average: 0.19, 0.05, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Perl Modules
Ken Moffat wrote these words on 12/11/12 19:28 CST: Sounds nice, but what about when a newer version of a module suddenly brings in a whole load of extra dependencies ? That would be the case in any update. Problem is that CPAN typically deletes old versions, and that requires users to find and install updated versions. I have extensive experience with Perl Modules and have found that they are very backwards compatible. What worked in the past typically works going forward. In the case of LWP (which you mentioned), I have made significant updates to that portion of the Perl Module page, and I am confident that the new instructions I will commit will work for some time. My point with this thread is hard-coded versions of Perl Modules may not exist (other than on Anduin), and this could allow for bugs to exist if users install old versions of Perl Modules. I feel good about using Perl Modules that are updated. There is typically no problems. I think we should consider using the most current versions of Perl Modules. When you run the command 'perl Makefile.PL', it will warn you if there are any dependency modules not installed. This should be enough. I do; however, appreciate your comments Ken, and will wait until the community provides some input about my idea. -- Randy rmlscsi: [bogomips 1003.23] [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] 19:32:00 up 6 days, 5:31, 1 user, load average: 0.20, 0.06, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] CA Certs
Hi all, I'd like to give some input about the CA Certs installation. First, why are the shell scripts installed in /bin and not /usr/bin? The wget program is not available and chances are networking is not enabled in single usr mode (why else would /usr not be mounted?) Also, the installation is not conducive to performing a DESTDIR installation. I modified the installation (including the scripts) to work with a complete DESTDIR installation. Would this be worth putting into the book? -- Randy rmlscsi: [bogomips 1003.23] [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:44:00 up 5 days, 2:43, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] cvs stray i
On 12/10/2012 5:36 PM, John Burrell wrote: in the last gray box at the bottom of the CVS page there is a stray i - first char in that box. Fixed, and will be committed in a couple of minutes. Thanks for the report. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Missing Gnome Files
On 10/21/2012 5:21 PM, Armin K. wrote: Dana 21.10.2012 20:04, Bruce Dubbs je napisao: OK, the files repo is now up-to-date. -- Bruce I took a look at anduin's blfs hieararchy and found lot of packages there that are not in the book anymore. If you desire, you can remove the following tarballs from anduin's blfs directory: But wouldn't it be possible that some folks want to use an older version of BLFS that uses these tarballs? Could be some have older hardware or whatever reason and do not want to install latest and greatest. Just a thought. Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Avoiding sourceforge
On 9/12/2012 11:30 AM, Bruce Dubbs wrote: I'd like to request that editors try to find alternative sites to sourceforge. If that's the only site available, please offer anduin as an alternate source. The only problem with that is everyone (including editors) do not know where the main hosting site for the package is, and makes it more difficult to find original source, updates, patches, etc. If we do this, I suggest we create an entity something like This package is hosted at Sourceforge and due to slow download speeds another URL is listed. You can find the package at. And then add .sourceforge.net. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Hurricane Issac
It looks as if the path of the hurricane is going to go right over my house. This really sucks. I'm sure power will be out for days. Wish me luck. -- Randy rmlscsi: [bogomips 1003.24] [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] 04:51:00 up 7 days, 15:55, 1 user, load average: 0.07, 0.04, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] samba's swat and xinetd
Bruce Dubbs wrote these words on 08/24/12 16:26 CST: Should I add xinetd back to BLFS? It's been saved in the archive directory so it wouldn't be hard. I think we should. It would be nice if we could support Samba's SWAT. I can add it back if you like, Bruce. -- Randy rmlscsi: [bogomips 1003.24] [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:48:00 up 4 days, 3:52, 1 user, load average: 0.02, 0.03, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg Chapter
Armin K. wrote these words on 08/20/12 18:28 CST: when running su -c make install, bash -e shell will exit on error because that command is incorrect - it would try to run make as user install ... It should be su -c make install. I am unsure tough if make install would do any harm if run like that with sudo or without any prefix command. You are correct about the syntax (having to quote the command). I have not looked at the instructions, but how is DJ handling root's password when using su? But since the MesaLib is not part of Xorg Release and it can be used by different versions, plus it is very well known that GL api hasn't changed for years, only DRI/Gallium drivers were improved, I suggest we install MesaLib, libdrm and Freeglut in /usr by default. I think that is probably a good idea, for the reasons you stated. 1) MesaLib is not part of Xorg 2) MesaLib can be used by different versions of Xorg 3) It breaks some packages if not in /usr These reasons are good enough for me to say the packages should be installed /usr. -- Randy rmlscsi: [bogomips 1003.24] [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] 07:07:00 up 1 day, 18:11, 1 user, load average: 0.19, 0.09, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Errata
If nobody has any objections, I would like to comment out the Errata page from the book. Because a development environment does not have errata (if something needs to be fixed, just change the book), there really is no need for it. Thoughts? -- Randy rmlscsi: [bogomips 1003.24] [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] 07:34:01 up 1 day, 18:38, 1 user, load average: 0.00, 0.02, 0.06 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Formatting for PDF Output
Hi all, There are a few places in the book where long extended commands inside screenuserinput tags are not legible in PDF output. Here are our choices: 1) Not worry about it and comment out the PDF generation from the Makefile. 2) Create files that can be downloaded instead of having to cut and paste from the book. 3) Split up the long screenuserinput sections into smaller chunks that would fit on PDF pages. This would not affect cut and paste ability. Examples of what I am talking about are the mozconfig files (which already are downloadable) and the commands to create an initramfs. My preference is to split the sections into smaller chunks, but I'd like to get everyone's take on the issue. -- Randy rmlscsi: [bogomips 1003.24] [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] 10:26:01 up 1 day, 21:30, 1 user, load average: 0.06, 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: [blfs-dev] Formatting for PDF Output
Ken Moffat wrote these words on 08/22/12 10:42 CST: I thought we stopped maintaining downloadable mozconfig files ? I'm not sure. You would know better than I. The list of UID/GID user/groups also needs to be fixed for proper PDF output as well. -- Randy rmlscsi: [bogomips 1003.24] [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] 10:48:01 up 1 day, 21:52, 1 user, load average: 0.08, 0.06, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Errata
Bruce Dubbs wrote these words on 08/22/12 11:08 CST: Randy McMurchy wrote: If nobody has any objections, I would like to comment out the Errata page from the book. Because a development environment does not have errata (if something needs to be fixed, just change the book), there really is no need for it. Yes, that's the right way to go. I'll take care of it. -- Randy rmlscsi: [bogomips 1003.24] [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] 11:21:01 up 1 day, 22:25, 1 user, load average: 1.01, 1.01, 0.77 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Formatting for PDF Output
Bruce Dubbs wrote these words on 08/22/12 11:13 CST: My thought is to skip pdf generation. I don't know that anyone uses it and the book changes virtually daily anyway. That was sort of my thoughts as well, but it would be easy to fix that is why I brought it up. It is more than 1500 pages and over 7 megabytes, so it is actually too large now for practical use. I do prefer leaving the files in the book as opposed to a downloadable file because it is a lot easier for a user to review what's going on. I do as well. And Ken mentioned we are not maintaining the mozconfig files for download any more, so there really is no reason to start doing it again. -- Randy rmlscsi: [bogomips 1003.24] [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] 11:22:01 up 1 day, 22:26, 1 user, load average: 1.68, 1.18, 0.84 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Introduction
Jeremy Huntwork wrote these words on 08/22/12 17:53 CST: I must really have stopped paying attention, I thought you were still leading the BLFS effort! I had been away for many, many months. Anyway, welcome back! I'm certain the various projects will benefit from your energy and enthusiasm again. Thanks, Jeremy. I will do my best to be a productive team member! -- Randy rmlscsi: [bogomips 1003.24] [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:57:03 up 2 days, 6:01, 1 user, load average: 0.17, 0.06, 0.15 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Little CMS version 2.x
Hi all, Could anyone get me up to speed on what packages have incompatibilities with the Little CMS version 2.x engine? Thanks! -- Randy rmlscsi: [bogomips 1003.24] [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] 11:43:01 up 22:47, 1 user, load average: 0.39, 0.10, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Favor
The attached file was too large to send via mail, so instead please download it from http://www.mcmurchy.com/ralcgm/ralcgm-3.50.tar.gz Original Message Subject: Favor Date: Tue, 21 Aug 2012 14:12:22 -0500 From: Randy McMurchy ra...@linuxfromscratch.org To: BLFS Development List blfs-dev@linuxfromscratch.org Hi all, I do not have access to my x86_64 partition right now, so if anyone could build the attached file, and then install it (to a temp directory using --prefix=whatever if you do not want it on your system) on your x86_64 system I would appreciate it. I just want to see if it builds correctly. There is also a make check if desired (10 seconds to run). TIA. -- Randy rmlscsi: [bogomips 1003.24] [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:15:00 up 1 day, 1:19, 1 user, load average: 1.25, 1.27, 0.77 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Little CMS version 2.x
Ken Moffat wrote these words on 08/21/12 13:09 CST: For things in the book, the last person to look was Andy. Google finds his comments on the gimp and poppler. Then he pointed to a debian patch for poppler. I think we've upgraded both since then, it looks as if poppler can now use lcms2. Thanks, Ken. I will do the legwork to see if the packages in BLFS that show a dependency for lcms1 have been updated to use lcms2. If so, I suppose we can ditch lcms1. I'll keep y'all updated. -- Randy rmlscsi: [bogomips 1003.24] [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:44:00 up 1 day, 1:48, 1 user, load average: 0.11, 0.12, 0.44 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
