Re: [blfs-support] Gcr-3.10.1 need to set correct path for successful compilation
m...@pc-networking-services.com wrote: Hello, While I was attempting to compile Gcr-3.10.1 from the stable BLFS-7.5 book I was not able to do so until I did the following: XDG_DATA_HOME=/usr/share export XDG_DATA_HOME XDG_DATA_DIRS=/usr/share/ export XDG_DATA_DIRS I do not yet have KDE or GNOME fully installed, and was doing the compile from an xterm terminal. Can you post the error message? These are only set from the kde.sh script. In BLFS-7.5 the /etc/profile script has changed. XDG_DATA_DIRS is set there now. I'm not sure XDG_DATA_HOME is needed. That said, grepping though the gcr source shows no references to XDG_DATA. It is used in glib though. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Hello, The error that you get WITHOUT the XDG_DATA_DIRS set is: error: Package `GObject-2.0' not found in specified Vala API directories or GObject-Introspection GIR directories error: Package `Gio-2.0' not found in specified Vala API directories or GObject-Introspection GIR directories It is really misleading. I did quite a bit of research on the net and was only able to solve the installation by setting the XDG_DATA_DIRS and home dirs. It seems that I was using the 7.4 version of the /etc/profile. I added those paths to the profile file before I received your response. I always seem to encounter the obscure errors. At least if anyone else is getting this kind of error, if they check that the XDG path is set it should solve the problem. I have no idea why this solved it, if gcr is not even making a call to it, but it HAS solved it, for which I am very happy. Regards, Christopher -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Gcr-3.10.1 need to set correct path for successful compilation
Hello, While I was attempting to compile Gcr-3.10.1 from the stable BLFS-7.5 book I was not able to do so until I did the following: XDG_DATA_HOME=/usr/share export XDG_DATA_HOME XDG_DATA_DIRS=/usr/share/ export XDG_DATA_DIRS I do not yet have KDE or GNOME fully installed, and was doing the compile from an xterm terminal. These are only set from the kde.sh script. perhaps adding those instructions to the page may help others from getting the same result that I did initially, which was unable to find gio and gobject 2.0 in vala search path. It was rather misleading, as it was neither of those that was the actual problem but the lack of the XDG search paths. My apologies if all but me knew to set these, but when following a written guide line, it would be nice if those of us who do not deviate from it, can get something to install as per the instructions. Regards, Christopher -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Gcr-3.10.1 need to set correct path for successful compilation
m...@pc-networking-services.com wrote: Hello, While I was attempting to compile Gcr-3.10.1 from the stable BLFS-7.5 book I was not able to do so until I did the following: XDG_DATA_HOME=/usr/share export XDG_DATA_HOME XDG_DATA_DIRS=/usr/share/ export XDG_DATA_DIRS I do not yet have KDE or GNOME fully installed, and was doing the compile from an xterm terminal. Can you post the error message? These are only set from the kde.sh script. In BLFS-7.5 the /etc/profile script has changed. XDG_DATA_DIRS is set there now. I'm not sure XDG_DATA_HOME is needed. That said, grepping though the gcr source shows no references to XDG_DATA. It is used in glib though. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] PATH problem?
Cliff McDiarmid wrote: Hello I wonder if someone can shed some light on this problem which has developed? I'm running a recent build of LFS(7.3)with kde 4.10. I made some minor PATH changes in /etc/.profile and ~.bashrc which I have now deleted. But I'm left with a problem under user. Is this a typo? /etc/.profile is meaningless. It needs to be /etc/profile. I cannnot access the simplest of commands, e.g. ls, env, su, su -l, startx etc. Command not found. What's going on here, can't get into KDE now? What is `echo $PATH` ? I can get into root in another run level and these commands are found. You don't say what changes you made or what the contents of the files are. It's hard to help without details. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] PATH problem?
Cliff McDiarmid wrote: - Original Message - From: Bruce Dubbs Sent: 10/21/13 08:14 PM To: BLFS Support List Subject: Re: [blfs-support] PATH problem? Cliff McDiarmid wrote: Hello I wonder if someone can shed some light on this problem which has developed? I'm running a recent build of LFS(7.3)with kde 4.10. I made some minor PATH changes in /etc/.profile and ~.bashrc which I have now deleted. But I'm left with a problem under user. Is this a typo? /etc/.profile is meaningless. It needs to be /etc/profile Yes that's a typo I cannnot access the simplest of commands, e.g. ls, env, su, su -l, startx etc. Command not found. What's going on here, can't get into KDE now? What is `echo $PATH` ? I've corrected the prob. it's now: /usr/local/bin:/usr/bin:/opt/kde/bin:/sbin:/usr/sbin:/bin:/opt/jdk/bin:/opt/qt/bin:/opt/qt/include/QtCore I had the following in ~.bashrc '/opt/Adobe/Reader9/bin/acroread' which was overriding the other PATHS - but why? PATH needs to be updated with PATH=$PATH:new_path. Or you can make the pathappend function in /etc/profile persistent and use that. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] evince-3.8.3, gir files search path question
Greetings I am trying to install evince-3.8.3. I have gtk3 at /opt/gtk and a file such as /opt/gtk/share/gir-1.0/Gdk-3.0.gir for exmaple compiling evince-3.8.3 spews a line with :- could not find Gdk-3.0.gir search path [/usr/share/gir-1.0, /usr/share/gir-1.0, /usr/share/gir-1.0, /usr/share/gir-1.0 ..] I already have a /usr/share/gir-1.0 with stuff and doing something like /opt/gtk/share/gir-1.0/Gdk-3.0.gir /usr/share/gir-1.0/Gdk-3.0.gir seems a little ugly I have looked in the configure script of evince-3.8.3 but did not find any settings (for gir files ) available. The question is:- Are there envars ( eg GIR_PATH akin to PATH, PKG_CONFIG_PATH etc ) for gir files and/or the recommended way to have .gir files !-in /user/share found? thanks in advance sincerely luxInteg -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] evince-3.8.3, gir files search path question
lux-integ wrote: Greetings I am trying to install evince-3.8.3. I have gtk3 at /opt/gtk and a file such as /opt/gtk/share/gir-1.0/Gdk-3.0.gir for exmaple compiling evince-3.8.3 spews a line with :- could not find Gdk-3.0.gir search path [/usr/share/gir-1.0, /usr/share/gir-1.0, /usr/share/gir-1.0, /usr/share/gir-1.0 ..] I already have a /usr/share/gir-1.0 with stuff and doing something like /opt/gtk/share/gir-1.0/Gdk-3.0.gir /usr/share/gir-1.0/Gdk-3.0.gir seems a little ugly I have looked in the configure script of evince-3.8.3 but did not find any settings (for gir files ) available. The question is:- Are there envars ( eg GIR_PATH akin to PATH, PKG_CONFIG_PATH etc ) for gir files and/or the recommended way to have .gir files !-in /user/share found? I don't know, but try creating symlinks in /usr/share/gir-1.0 to the files in /opt/gtk/share/gir-1.0. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] evince-3.8.3, gir files search path question
On Friday 23 August 2013 13:15:31 Bruce Dubbs wrote: I don't know, but try creating symlinks in /usr/share/gir-1.0 to the files in /opt/gtk/share/gir-1.0 works thanks -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] LLVM lib path
On 01/06/2013 08:51 AM, Simon Geard wrote: A curious question, for anyone who might know. Why, in the LLVM instructions, do we go to such lengths to put all the libraries in a subdirectory of /usr/lib, only to add an entry to ld.so.conf to ensure everything can find them? I ask because I missed that last bit without noticing at the time, only to have some other package try and run clang and fail with library loading issues. And neither the book, nor the patch offers any explanation of why we want to fix installation paths for libraries. Note - I'm aware that the patch also fixes the locations of stuff in /etc and /usr/share/doc, no problem there. It's just the reasons for forcing everything into /usr/lib/llvm that has me puzzled. Simon. Well, I guess answer is simple. We didn't want to polute /usr/lib with ~100 static libraries which are only used by programs that use LLVM. Entry to ld.so.conf is added because there are few shared libraries, ensuring that they can be loaded at runtime. Some time ago, LLVM was installed into /opt/llvm by default because of mentioned reason, but we agreed to install it into /usr hierarchy - just changed the libdir. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Adjusting pkg-config path...
On 12/05/2012 12:11 AM, Henrik /KaarPoSoft wrote: I concur. I wanted gnome in /opt/gnome, but never managed to do so. So for now, I stick to gnome in /usr. /Henrik Last time when I tried installing GNOME into other prefix than /usr, I could build it, but at runtime it missed lot of functionality. Icons were missing, lot of env vars were needed to be set (and I hate setting them), namely python modules path, xdg env vars (don't know the right name), PATH, man path, info path and such ... With all of these, it still wasn't working. I can recommend looking at jhbuild or ostree and see if you can use them to install gnome into other prefix than /usr. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Adjusting pkg-config path...
On 12/04/2012 05:15 AM, Michael Robinson wrote: How do I adjust the path? I'm trying to install gnome specific packages to /usr/gnome, because I'm low on space and because I was hoping to be able to jerk gnome out easily if I need to. Please note that you will be on your own there. Last time I checked GNOME installation into some other prefix than /usr it didn't go very well. Lot of stuff didn't work as expected or didn't work at all. If you manage to get everything working as expected, please explain how you did it. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Adjusting pkg-config path...
On 12/04/12 14:40, Armin K. wrote: On 12/04/2012 05:15 AM, Michael Robinson wrote: How do I adjust the path? I'm trying to install gnome specific packages to /usr/gnome, because I'm low on space and because I was hoping to be able to jerk gnome out easily if I need to. Please note that you will be on your own there. Last time I checked GNOME installation into some other prefix than /usr it didn't go very well. Lot of stuff didn't work as expected or didn't work at all. If you manage to get everything working as expected, please explain how you did it. I concur. I wanted gnome in /opt/gnome, but never managed to do so. So for now, I stick to gnome in /usr. /Henrik -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Adjusting pkg-config path...
How do I adjust the path? I'm trying to install gnome specific packages to /usr/gnome, because I'm low on space and because I was hoping to be able to jerk gnome out easily if I need to. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Adjusting pkg-config path...
On 12/03/2012 11:15 PM, Michael Robinson wrote: How do I adjust the path? I'm trying to install gnome specific packages to /usr/gnome, because I'm low on space and because I was hoping to be able to jerk gnome out easily if I need to. See the BLFS page that describes what to do when installing any package to a non-standard prefix - http://www.linuxfromscratch.org/blfs/view/svn/introduction/beyond.html. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Libtool search path
On 08/03/2011 11:49 AM, ?? wrote: Excuse me. I am trying to build Gnome 3 in /opt/gnome. I've added /opt/gnome/usr/lib/pkgconfig to PKG_CONFIG_PATH and /opt/gnome/usr/lib to ld.so.conf. I get glib 2.24.7 installed to /opt/gnome and I am sure there is libgmodule-2.0.la file in /opt/gnome/usr/lib. But when I try to build GConf, error occurs and it seems that libtool keeps trying to find libgmodule-2.0.la file in /usr/lib. Here's the error message: /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -version-info 5:5:1 -no-undefined -o libgconf-2.la -rpath /opt/gnome/usr/lib gconf-internals.lo gconf-backend.lo gconf-changeset.lo gconf-error.lo gconf-listeners.lo gconf-locale.lo gconf-schema.lo gconf-sources.lo gconf-value.lo gconf.lo gconf-client.lo gconf-enum-types.lo GConfX-common.lo GConfX-skels.lo GConfX-stubs.lo -pthread -Wl,--export-dynamic -L/opt/gnome/usr/lib -lgio-2.0 -lgmodule-2.0 -lORBit-2 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 /bin/grep: /usr/lib/libgmodule-2.0.la: No such file or directory /bin/sed: can't read /usr/lib/libgmodule-2.0.la: No such file or directory libtool: link: `/usr/lib/libgmodule-2.0.la' is not a valid libtool archive How can I adjust the path? Thanks for your help. Tester He What version of LFS? If recent, did you remove the installed glib and pkgconfig file in /usr? -- DJ Lucas LFS 6.7 Yes I did remove the previous glib and pkgconfig files, thanks. Tester He -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Libtool search path
On 08/03/2011 11:49 AM, 高飛 wrote: Excuse me. I am trying to build Gnome 3 in /opt/gnome. I've added /opt/gnome/usr/lib/pkgconfig to PKG_CONFIG_PATH and /opt/gnome/usr/lib to ld.so.conf. I get glib 2.24.7 installed to /opt/gnome and I am sure there is libgmodule-2.0.la file in /opt/gnome/usr/lib. But when I try to build GConf, error occurs and it seems that libtool keeps trying to find libgmodule-2.0.la file in /usr/lib. Here's the error message: /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -version-info 5:5:1 -no-undefined -o libgconf-2.la -rpath /opt/gnome/usr/lib gconf-internals.lo gconf-backend.lo gconf-changeset.lo gconf-error.lo gconf-listeners.lo gconf-locale.lo gconf-schema.lo gconf-sources.lo gconf-value.lo gconf.lo gconf-client.lo gconf-enum-types.lo GConfX-common.lo GConfX-skels.lo GConfX-stubs.lo -pthread -Wl,--export-dynamic -L/opt/gnome/usr/lib -lgio-2.0 -lgmodule-2.0 -lORBit-2 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 /bin/grep: /usr/lib/libgmodule-2.0.la: No such file or directory /bin/sed: can't read /usr/lib/libgmodule-2.0.la: No such file or directory libtool: link: `/usr/lib/libgmodule-2.0.la' is not a valid libtool archive How can I adjust the path? Thanks for your help. Tester He What version of LFS? If recent, did you remove the installed glib and pkgconfig file in /usr? -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Libtool search path
On Thu, 2011-08-04 at 00:49 +0800, ?? wrote: Excuse me. I am trying to build Gnome 3 in /opt/gnome. I've added /opt/gnome/usr/lib/pkgconfig to PKG_CONFIG_PATH and /opt/gnome/usr/lib to ld.so.conf. why it is /opt/gnome/usr/lib ? Shouldn't it be /opt/gnome/lib instead ? What arguments are you passing to configure script ? ./configure --prefix=/opt/gnome/usr --sysconfdir=/opt/gnome/etc From my personal experience, you are better off using conventional paths i.e ./configure --prefix=/usr --sysconfdir=/etc.I have build gnome-2.30 two or three times and have found when using anything other than /usr, you are sure to run into trouble. /bin/grep: /usr/lib/libgmodule-2.0.la: No such file or directory /bin/sed: can't read /usr/lib/libgmodule-2.0.la: No such file or directory libtool: link: `/usr/lib/libgmodule-2.0.la' is not a valid libtool archive Does making a symbolic link in /usr/lib solves this ? To some extends it does, except some warning messages xxx.la seems to be move. I am afraid of that creating symbolic link will cause some potential problem in the future. Thanks for your help. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Libtool search path
On Thu, 2011-08-04 at 00:49 +0800, 高飛 wrote: Excuse me. I am trying to build Gnome 3 in /opt/gnome. I've added /opt/gnome/usr/lib/pkgconfig to PKG_CONFIG_PATH and /opt/gnome/usr/lib to ld.so.conf. why it is /opt/gnome/usr/lib ? Shouldn't it be /opt/gnome/lib instead ? What arguments are you passing to configure script ? From my personal experience, you are better off using conventional paths i.e ./configure --prefix=/usr --sysconfdir=/etc.I have build gnome-2.30 two or three times and have found when using anything other than /usr, you are sure to run into trouble. /bin/grep: /usr/lib/libgmodule-2.0.la: No such file or directory /bin/sed: can't read /usr/lib/libgmodule-2.0.la: No such file or directory libtool: link: `/usr/lib/libgmodule-2.0.la' is not a valid libtool archive Does making a symbolic link in /usr/lib solves this ? -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
font path error, and thanks
Continuing my gnome saga, I fired it up for the first time yesterday. Here are two consecutive entries into my project log: jamzen: 11:44 AM Sun, 14 Nov 2010 hamilton:/build/gn/gnome-user-docs-2.30.1 tags: gnome first run [1] The desktop comes up ok, but there's no text -- only an empty box for each character. root: 03:19 PM Sun, 14 Nov 2010 hamilton:/usr/share/fonts tags: fonts error solved There appears to have been an error in the BLFS book. I inadvertently propagated it into the softlinks in this directory. I've corrected them, and gnome is now fully literate. The error appears in the fourth graybox on the Xorg Fonts page in svn-20101016, and it's still there in svn-20101112: ln -svn $XORG_PREFIX/share/fonts/X11/fonts/OTF /usr/share/fonts/X11-OTF ln -svn $XORG_PREFIX/share/fonts/X11/fonts/TTF /usr/share/fonts/X11-TTF I'm installing into /opt/X11, and the fonts are in /opt/X11/share/fonts/X11 *not* /opt/X11/share/fonts/X11/fonts ** Anway, I figured you'd want to know. This is the first time I've taken an LFS / BLFS build this far. I'm blown away that I actually now have a working gnome on top of my Xwindow system. I figured I'd encounter some really insurmountable mess-up before I got this far. Congratulation and thanks to everybody in this BLFS group. I've learned a tremendous amount, and kept a pretty detailed log of what that included. I may put it up soon, somewhere where others can compare notes with what I experienced. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: font path error, and thanks
Jim Michmerhuizen wrote these words on 11/15/10 09:59 CST: The error appears in the fourth graybox on the Xorg Fonts page in svn-20101016, and it's still there in svn-20101112: ln -svn $XORG_PREFIX/share/fonts/X11/fonts/OTF /usr/share/fonts/X11-OTF ln -svn $XORG_PREFIX/share/fonts/X11/fonts/TTF /usr/share/fonts/X11-TTF I'm installing into /opt/X11, and the fonts are in /opt/X11/share/fonts/X11 *not* /opt/X11/share/fonts/X11/fonts I created a Trac ticket for this exact problem a week ago. I'm not really keen on the Xorg stuff, so I thought I'd let DJ review it. That's why I didn't just go ahead and make the change. -- Randy rmlscsi: [bogomips 1003.28] [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:00 up 13 days, 17:20, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: New PKG_CONFIG path?
On Tue, 2009-12-15 at 20:28 -0600, al...@verizon.net wrote: If no mistakes on my part on this subject, this will cause errors for some packages looking in the wrong place. Is this a trend? It's not a mistake on your part - it just seems to be that a small number of packages install their .pc files to /usr/share instead. Looking at what they are, I suspect the common factor is that they're not libraries. Most pkgconfig files are there to provide info on how to compile and link against libraries, but most of the examples I can see in /usr/share are data - databases for MIME types, for ISO codes, or USB device ids. Arguably xtrans too, since that package contains only headers, no binary content. If this is a standard though, it doesn't seem to be clearly documented anywhere. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: New PKG_CONFIG path?
On Wed, 2009-12-16 at 00:56 -0500, Chris Staub wrote: First, it doesn't matter what order, unless there are duplicate files in both directories. Second, as noted in the manpage, /usr/lib/pkgconfig and /usr/share/pkgconfig are both searched by default anyway so they don't need to be in PKG_CONFIG_PATH. Hmm... the man page does mention it, though a bit opaquely - you won't find any mention of /usr/share anywhere. It refers to the directories as 'libdir' and 'datadir' from the autotools variables - it'd be nice if the pkg-config build substituted the correct paths into the page. Wonder if they'd accept a patch for that? Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: New PKG_CONFIG path?
On 16/12/09 02:28, al...@verizon.net wrote: Hello, In the process of building Xorg-7.5 (from 7.4) I stumbled upon something odd. For a couple of packages their 'pc' files ended up in '/usr/share/pkgconfig' instead of the tried and true '/usr/lib/pkgconfig'. If no mistakes on my part on this subject, this will cause errors for some packages looking in the wrong place. Why? Can you give examples of these errors? For me, by default pkg-config looks in /usr/lib/pkgconfig and /usr/share/pkgconfig. I only need to set PKG_CONFIG_PATH if I do a test compile, installing things into my home folder. Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: New PKG_CONFIG path?
Hi guys:
Thank you very much for your comments.
Chris Staub wrote on Tue Dec 15 22:56:48 MST 2009:
unless there are duplicate files in both directories.
My original post:
xtrans-1.2.5 (of the Xorg-7.5 lib).
The previous xtrans (1.2.1 - of the Xorg-7.4)
was placed, together with all the others,
in '/usr/lib/pkgconfig/'.
[Alex: this phenomenon was what triggered my opening post]
Second, as noted in the manpage, /usr/lib/pkgconfig
and /usr/share/pkgconfig are both searched by default anyway
so they don't need to be in PKG_CONFIG_PATH.
I'll second Simon Geard's comments on Wed Dec 16 01:18:41 MST 2009:
... you won't find any mention of /usr/share anywhere ...
Ironically (and coincidentally), the otherwise pretty common
word share cannot be found anywhere in the manual.
Chris, for a more expanded (and verbose) treatment of your
... it doesn't matter what order ... and
,.. both searched by default anyway ... statements,
please refer to my answer to Andrew below.
Regarding Simon Geard's comment of Wed Dec 16 01:14:16 MST 2009
... most of the examples I can see in /usr/share are data ...
Arguably xtrans too, since that package contains only headers,
no binary content.
If this is a standard though, it doesn't seem to be clearly
documented anywhere.
The Udev developers, in their relentless quest for perfection
decided to join the crowd with their own pc file in 149.
cat /usr/share/pkgconfig/udev.pc
Name: udev
Description: udev
Version: 149
udevdir=/lib/udev
Doesn't look like data (although that's debatable and
frankly irrelevant here).
To me it appears like the beginning of a trend to
start a regular pc package for Udev too.
I can hardly wait for version 175 or so when we'll have
full fledged lines like Description and Cflags :)
In a standard directory, perhaps?
(BTW, for more of my words of wisdom on Udev, youse are
gracefully invited to thread
UDEV - Not Leaving Well Enough Alone
November 2009, lfs-support archive).
Andrew Benton wrote on Wed Dec 16 05:25:26 MST 2009
Alex had written:
For a couple of packages their 'pc' files ended up
in '/usr/share/pkgconfig' instead of the tried and true
'/usr/lib/pkgconfig'. ...
this will cause errors for some packages
looking in the wrong place.
Why? Can you give examples of these errors?
Yes [the trigger for my opening post].
Failure of 'xorg-server-1.7.1' (Xorg-7.5) on configure:
checking for XSERVERCFLAGS... configure: error: Package requirements
(randrproto = 1.2.99.3 renderproto = 0.11 fixesproto = 4.1
damageproto = 1.1 xcmiscproto = 1.2.0 xextproto = 7.0.99.3
xproto = 7.0.13 xtrans = 1.2.2 bigreqsproto = 1.1.0
fontsproto inputproto = 1.9.99.902 kbproto = 1.0.3
videoproto compositeproto = 0.4 scrnsaverproto = 1.1
resourceproto xineramaproto xkbfile xfont xau pixman-1 = 0.15.20
xdmcp openssl) were not met:
Requested 'xtrans = 1.2.2' but version of XTrans is 1.2.1
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix (sic).
Alternatively, you may set the environment variables XSERVERCFLAGS_CFLAGS
and XSERVERCFLAGS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details (sic).
-
Alex's words now:
PKG_CONFIG_PATH was
/usr/lib/pkgconfig:/usr/local/lib/pkgconfig:/opt/qt/lib/pkgconfig
cat /usr/share/pkgconfig/xtrans.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: XTrans
Description: Abstract network code for X
Version: 1.2.5
Cflags: -I${includedir} -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT
---
cat /usr/lib/pkgconfig/xtrans.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: XTrans
Description: Abstract network code for X
Version: 1.2.1
Cflags: -I${includedir} -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT
---
Note: It's not a fluke that the new (1.2.5) xtrans pc ends up in
the new directory (as opposed to the good, old '/usr/lib/pkgconfig')
An excerpt from the 'make install' shows this was deliberate:
test -z /usr/share/pkgconfig || /bin/mkdir -p /usr/share/pkgconfig
/usr/bin/install -c -m 644 xtrans.pc '/usr/share/pkgconfig'
i.e, even if Udev had not started the new, strange trend.
---
echo $PKG_CONFIG_PATH
/usr/local/lib/pkgconfig:/opt/qt/lib/pkgconfig
(i.e. without /usr/lib/pkgconfig)
results in the same server configure error.
---
echo $PKG_CONFIG_PATH
/usr/share/pkgconfig/:/usr/local/lib/pkgconfig:/opt/qt/lib/pkgconfig
(i.e. prepending the new path /usr/share/pkgconfig but implicitly
using the pkg-config manual default, /usr/lib/pkgconfig).
NO error, meaning that the default is brought into play sometime
(who knows when), AFTER the first component, /usr/share/pkgconfig/,
is searched! Who would've thunk it!
In direct contradiction with the manual - Excerpt:
By default, pkg-config looks in the directory
prefix/lib/pkgconfig for these files; it will
ALSO (my emphasis) look in the colon-separated
list
Re: New PKG_CONFIG path?
On 16/12/09 20:00, al...@verizon.net wrote: Andrew Benton wrote on Wed Dec 16 05:25:26 MST 2009 Why? Can you give examples of these errors? Yes [the trigger for my opening post]. Failure of 'xorg-server-1.7.1' (Xorg-7.5) on configure: checking for XSERVERCFLAGS... configure: error: Package requirements (randrproto= 1.2.99.3 renderproto= 0.11 fixesproto= 4.1 damageproto= 1.1 xcmiscproto= 1.2.0 xextproto= 7.0.99.3 xproto= 7.0.13 xtrans= 1.2.2 bigreqsproto= 1.1.0 fontsproto inputproto= 1.9.99.902 kbproto= 1.0.3 videoproto compositeproto= 0.4 scrnsaverproto= 1.1 resourceproto xineramaproto xkbfile xfont xau pixman-1= 0.15.20 xdmcp openssl) were not met: Requested 'xtrans= 1.2.2' but version of XTrans is 1.2.1 If I export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/local/lib/pkgconfig:/opt/qt/lib/pkgconfig and then configure xorg-server-1.7.3 it still finds xtrans.pc file in /usr/share/pkgconfig and configure completes successfully. Which version of pkg-config are you using and what options did you use when you compiled it? Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: New PKG_CONFIG path?
On Wed, 2009-12-16 at 14:00 -0600, al...@verizon.net wrote: The Udev developers, in their relentless quest for perfection decided to join the crowd with their own pc file in 149. Interesting... I'd not noticed that one (it's present as early as 146, btw). Going by the contents of /lib/udev, I guess that file is used by packages like DeviceKit-disks, NetworkManager, libgphoto, etc to work out where to install udev rules and helpers. It's a rather confused directory, actually - full of binaries like you'd expect for something under /lib, but also containing udev rules, keymap files, and template device nodes. I guess there's nowhere else to put them if you can't rely on /usr being present at boot... no equivalent of /usr/share... Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
New PKG_CONFIG path?
Hello, In the process of building Xorg-7.5 (from 7.4) I stumbled upon something odd. For a couple of packages their 'pc' files ended up in '/usr/share/pkgconfig' instead of the tried and true '/usr/lib/pkgconfig'. Specifically, in '/usr/share/pkgconfig' I now have: udev-149 (independently, of course) and xtrans-1.2.5 (of the Xorg-7.5 lib). The previous 'xtrans' (1.2.1 - of the Xorg-7.4) was placed, together with all the others, in '/usr/lib/pkgconfig/'. If no mistakes on my part on this subject, this will cause errors for some packages looking in the wrong place. Is this a trend? If I'm right, I have to add '/usr/share/pkgconfig' somewhere. What should be the order in PKG_CONFIG_PATH: /usr/lib/pkgconfig ... /usr/share/pkgconfig or /usr/share/pkgconfig ... /usr/lib/pkgconfig? Have I been doing something wrong all these years and all these hundreds of packages installed? Etc. I'd appreciate any comments/help. Thanks in advance, -- Alex (B)LFS, i686-pc-linux-gnu, 2.6.32 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: New PKG_CONFIG path?
On 12/15/2009 09:28 PM, al...@verizon.net wrote: Hello, In the process of building Xorg-7.5 (from 7.4) I stumbled upon something odd. For a couple of packages their 'pc' files ended up in '/usr/share/pkgconfig' instead of the tried and true '/usr/lib/pkgconfig'. Specifically, in '/usr/share/pkgconfig' I now have: udev-149 (independently, of course) and xtrans-1.2.5 (of the Xorg-7.5 lib). The previous 'xtrans' (1.2.1 - of the Xorg-7.4) was placed, together with all the others, in '/usr/lib/pkgconfig/'. If no mistakes on my part on this subject, this will cause errors for some packages looking in the wrong place. Is this a trend? If I'm right, I have to add '/usr/share/pkgconfig' somewhere. What should be the order in PKG_CONFIG_PATH: /usr/lib/pkgconfig ... /usr/share/pkgconfig or /usr/share/pkgconfig ... /usr/lib/pkgconfig? First, it doesn't matter what order, unless there are duplicate files in both directories. Second, as noted in the manpage, /usr/lib/pkgconfig and /usr/share/pkgconfig are both searched by default anyway so they don't need to be in PKG_CONFIG_PATH. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
David Kuntadi wrote: No. I am suggesting a chapter in BLFS to create complete desktop environement without x. David BLFS already has plenty of packages listed that don't need X. The main problem is that different users have different definitions of complete desktop environment. It's up to the users to pick and choose what they want - that's the whole point of BLFS. If you like, you can write a guide describing your own idea of a complete desktop environment without X and submit it to LFS Hints. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
On Tue, Oct 28, 2008 at 10:49 AM, Chris Staub [EMAIL PROTECTED] wrote: BLFS already has plenty of packages listed that don't need X. The main problem is that different users have different definitions of complete desktop environment. It's up to the users to pick and choose what they want - that's the whole point of BLFS. If you like, you can write a guide describing your own idea of a complete desktop environment without X and submit it to LFS Hints. What I have in mind is a desktop environment similar to gnome, but I do not know yet exactly what packages should be included. Now I am trying to install firefox without x (using frame buffer), hopefully it is working. So, may be we should have at least: Internet: Graphical web browser Graphical chat Office: Spreadsheet word processor Audio and Video: Video player Audio Player Accessories: Calculator And may be some games and utilities. And for login may be use Qingy instead of getty? Once login, it should fire up a desktop with menu of available software there. David -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Window manager without x server: follow INX path?
Recently I have managed to run links -g (graphical links) and I just allow read and write for all for /dev folder to all as work around. But when I tried INX, definitely it is a huge task for me to make similar setup on top of lfs: http://inx.maincontent.net/announce-inx-1.0.html I think blfs should be something like INX, window manager without the need to install x windows server. This is just my suggestion. Regards, David -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
Below is the list of packages to build INX. It looks like not so huge after all: http://inx.maincontent.net/1.0-versions-package-list abcde 2.3.99.6-1ubuntu2 antiword 0.37-2 bsdmainutils 6.1.10ubuntu2 calcurse 1.9-1 cdtool 2.1.8-release-1 ceni 1.41~inx1 cmatrix1.2a-2.1 console-freecell 1.0-0ubuntu1 console-terminus 4.20-6 cplay 1.49-10 dict 1.10.10.dfsg-1ubuntu1 dvtm 0.4.1-1.1~inx1 elinks 0.11.3-5ubuntu2 fbgrab 1.0.0-3 fbi2.06-2ubuntu1 figlet 2.2.2-1ubuntu1 gpm1.19.6-25ubuntu1 greed 3.4-2 htop 0.6.6+svn20070915-1 iftop 0.17-5 iptraf 3.0.0-6 irssi 0.8.12-3ubuntu3 jed1:0.99.18+dfsg.1-9 links2 2.1pre32-1 linm 0.7.9-2 mc 1:4.6.1-8ubuntu1 moc1:2.5.0~alpha2-2 mpg321 0.2.10.4 mutt 1.5.17+20080114-1ubuntu1 robotfindskitten 1.7320508.406-1 sc 7.16-2 screen 4.0.3-7ubuntu1 setcd 1.5-4 sl 3.03-15 sshfs 1.9-1 telnet 0.17-35ubuntu1 vifm 0.3-2 vim1:7.1-138+1ubuntu3 On Mon, Oct 27, 2008 at 1:27 PM, David Kuntadi [EMAIL PROTECTED] wrote: Recently I have managed to run links -g (graphical links) and I just allow read and write for all for /dev folder to all as work around. But when I tried INX, definitely it is a huge task for me to make similar setup on top of lfs: http://inx.maincontent.net/announce-inx-1.0.html I think blfs should be something like INX, window manager without the need to install x windows server. This is just my suggestion. Regards, David -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
On Mon, Oct 27, 2008 at 03:04:54PM +0700, David Kuntadi wrote: Below is the list of packages to build INX. It looks like not so huge after all: http://inx.maincontent.net/1.0-versions-package-list I have no interest in this, but it looks like the sort of thing that might have fitted into a hint, so perhaps you could put it in the wiki (dunno, maybe packages not in BLFS don't fit there). Among other things, to get into the book you need to engage an editor's interest. I find it hard to see why anyone would use a desktop without X nowadays. A few comments on packages: gpm1.19.6-25ubuntu1 gpm is in BLFS mc 1:4.6.1-8ubuntu1 mc is in BLFS, I think mpg321 0.2.10.4 I used to use mpg321, but now that mpg123 seems to be maintained again (I'm using 1.5.1 in my current build) I'm sure you can either use that or make a symlink to it. mutt 1.5.17+20080114-1ubuntu1 mutt is in BLFS screen 4.0.3-7ubuntu1 might be in BLFS telnet 0.17-35ubuntu1 I hope you won't be running the daemon vim1:7.1-138+1ubuntu3 *cough* vim is in LFS itself And please don't top post, and trim what you are replying to. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
On Mon, Oct 27, 2008 at 05:12:57PM +, Ken Moffat wrote: I have no interest in this, but it looks like the sort of thing that might have fitted into a hint, so perhaps you could put it in the wiki (dunno, maybe packages not in BLFS don't fit there). Among other things, to get into the book you need to engage an editor's interest. I find it hard to see why anyone would use a desktop without X nowadays. That should, of course, be to get it [INX] into the book. For the avoidance of doubt, I'm not up to speed on the wiki's operation. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
David Kuntadi wrote: Recently I have managed to run links -g (graphical links) and I just allow read and write for all for /dev folder to all as work around. Um, workaround for what? But when I tried INX, definitely it is a huge task for me to make similar setup on top of lfs: http://inx.maincontent.net/announce-inx-1.0.html I think blfs should be something like INX, window manager without the need to install x windows server. This is just my suggestion. BLFS is just a guide for installing packages beyond a base LFS system. I don't quite get what you're saying here. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
Below is my response to both Ken and Chris. On Tue, Oct 28, 2008 at 12:12 AM, Ken Moffat [EMAIL PROTECTED] wrote: Among other things, to get into the book you need to engage an editor's interest. I find it hard to see why anyone would use a desktop without X nowadays. That is what I differ. X is so bloated, we have to install so many packages. And yet, it still require DRI to launch compiz fusion. If we could have desktop without x, that would be marvellous. We could have very fast desktop that could run on very old hardware, and even faster on new hardware. On Mon, Oct 27, 2008 at 1:40 PM, Chris Staub [EMAIL PROTECTED] wrote: David Kuntadi wrote: Um, workaround for what? links -g do not have write access to /dev/fb0, and requires to run as root. BLFS is just a guide for installing packages beyond a base LFS system. I don't quite get what you're saying here. What I am saying is: 1. LFS is just linux, command line only. That would be great for servers. 2. LFS + INX (desktop without X), for super user of old hardware, or ease of administering servers. But it is also possible for normal user if the setup is very freindly. 3. X windows, for people like eye candys may be. DK -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
David Kuntadi wrote: Below is my response to both Ken and Chris. On Mon, Oct 27, 2008 at 1:40 PM, Chris Staub [EMAIL PROTECTED] wrote: David Kuntadi wrote: Um, workaround for what? links -g do not have write access to /dev/fb0, and requires to run as root. BLFS is just a guide for installing packages beyond a base LFS system. I don't quite get what you're saying here. What I am saying is: 1. LFS is just linux, command line only. That would be great for servers. 2. LFS + INX (desktop without X), for super user of old hardware, or ease of administering servers. But it is also possible for normal user if the setup is very freindly. 3. X windows, for people like eye candys may be. DK Maybe I'm just clueless, but can you explain specifically what it is you are proposing, and how this is any different from, say, building a standard LFS system and a few select packages from BLFS? I am fully aware (and, no doubt, so are all other LFS/BLFS editors and users) that not everyone needs or wants X. Those that don't can just use BLFS for alternative packages, or search the web. If you just want to have something like different customized BLFS books with select packages for the various system types you described above, you could easily just write up a hint, and/or take the existing BLFS svn source, modify it accordingly, and create your own branch. If you want to add more packages (or additions to existing packages about how to use them without X) to BLFS, open up a ticket in Trac for each new/modified package. If you're suggesting something else entirely, can you clarify exactly what that is? -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
On Tue, Oct 28, 2008 at 10:14 AM, Chris Staub [EMAIL PROTECTED] wrote: Maybe I'm just clueless, but can you explain specifically what it is you are proposing, and how this is any different from, say, building a standard LFS system and a few select packages from BLFS? I am suggesting a complete desktop package without X. May be just try INX livecd to get a clearer idea. But what I mean is more than just INX, but really a desktop package without X. Regards, David. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
On Tue, Oct 28, 2008 at 10:30 AM, Chris Staub [EMAIL PROTECTED] wrote: So, you're suggesting a new livecd, based on LFS, without X? No. I am suggesting a chapter in BLFS to create complete desktop environement without x. David -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Window manager without x server: follow INX path?
David Kuntadi wrote: If we could have desktop without x, that would be marvellous. We could have very fast desktop that could run on very old hardware, and even faster on new hardware. Hmm. Browser based management tools from server console is nice use of fb, but double clicking links would be a nice feature for my server toy given it's target audience...as if I'll ever find time to work on it again. links -g do not have write access to /dev/fb0, and requires to run as root. No. According to 55-lfs.rules, just add your user to the video group. If you slap together a writeup on the wiki, I'll try and give it a test run in a few weeks. Maybe it'll get into the book someday, but that is a big order to fill at this time. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
PATH=
Using-blfs-book-cvs-html-2006-10-12
After installing, linux-PAM-0.99.4.0 then re-installing Shadow-4.0.15
and following the book's configuration scripts. when I su to root,
root's PATH= /bin:/usr/bin.
When I login as root the PATH looks right; /usr/local/sbin:/usr/
local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin
Looking at all the files, I see that /etc/security/pam_env.conf is
entirely commented out except for one line at the end of the file;
PATHDEFAULT=/bin:/usr/bin OVERRIDE=${PATH}
Is this what is supplying the PATH? Can't figure out how this
happened. Where should I fix this?
also in the /etc/bashrc configuration there is this on the 7th line;
if [ -f /etc/profile.d/tinker-term.sh ]; then
source /etc/profile.d/tinker-term.sh
fi
the book doesn't have any tinker-term.sh script.
Thanks, Arden
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: PATH=
Alle 17:44, mercoledì 18 ottobre 2006, Arden ha scritto:
Using-blfs-book-cvs-html-2006-10-12
After installing, linux-PAM-0.99.4.0 then re-installing Shadow-4.0.15
and following the book's configuration scripts. when I su to root,
root's PATH= /bin:/usr/bin.
When I login as root the PATH looks right; /usr/local/sbin:/usr/
local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin
Looking at all the files, I see that /etc/security/pam_env.conf is
entirely commented out except for one line at the end of the file;
PATHDEFAULT=/bin:/usr/bin OVERRIDE=${PATH}
Is this what is supplying the PATH? Can't figure out how this
happened. Where should I fix this?
Hi, /etc/security/pam_env.conf is installed so by default.
You can use:
su -
(notice the minus sign after the su command) to obtain the same
environment you have at login.
Alessandro Alocci
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: PATH=
On 10/18/06, Arden [EMAIL PROTECTED] wrote: also in the /etc/bashrc configuration there is this on the 7th line; if [ -f /etc/profile.d/tinker-term.sh ]; then source /etc/profile.d/tinker-term.sh fi the book doesn't have any tinker-term.sh script. Whoops! Nice catch. I removed the script a few weeks back because it's not needed any more, but not the check in the profile script. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: PATH=
Alessandro Alocci napisał(a):
Alle 17:44, mercoledì 18 ottobre 2006, Arden ha scritto:
Using-blfs-book-cvs-html-2006-10-12
After installing, linux-PAM-0.99.4.0 then re-installing Shadow-4.0.15
and following the book's configuration scripts. when I su to root,
root's PATH= /bin:/usr/bin.
When I login as root the PATH looks right; /usr/local/sbin:/usr/
local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin
Looking at all the files, I see that /etc/security/pam_env.conf is
entirely commented out except for one line at the end of the file;
PATHDEFAULT=/bin:/usr/bin OVERRIDE=${PATH}
Is this what is supplying the PATH? Can't figure out how this
happened. Where should I fix this?
Hi, /etc/security/pam_env.conf is installed so by default.
You can use:
su -
(notice the minus sign after the su command) to obtain the same
environment you have at login.
Alessandro Alocci
To have proper path when you issue:
su
(without -)
you have to add the needed path to /root/.bashrc
for example:
export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
The book says that this in the last Note in chapter describing shadow.
Jerzy Goca (aka juras256)
-
Panorama Internetu - prognoza pogody, poczta e-mail z największym załącznikiem,
SMS, wyszukiwarki: Gooru, Anonser, serwisy: randki, ogłoszenia, wakacje,
program TV, Kina, muzyka, DVD, newsy, inne.
http://www.panoramainternetu.pl/ (http://www.epf.pl/)
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Upgrade Path for Xorg
I'm looking to upgrade to xorg-7 from xorg-6. I know this will be a challenge, but we have to find some sort of solution. Any pointers as to how to proceed? -- Esben Stien is [EMAIL PROTECTED] s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Upgrade Path for Xorg
On Thu, 2006-06-15 at 23:13 +0200, Esben Stien wrote: I'm looking to upgrade to xorg-7 from xorg-6. I know this will be a challenge, but we have to find some sort of solution. Any pointers as to how to proceed? The SVN book was pretty straightforward and easy enough to follow. I made some additional notes as I went along, mostly about figuring out dependencies, that I'd be glad to send you if you think they might help. One thing I did to save time was build and install both as root, so I could put configure make make install all into one script and save myself a lot of typing. I managed to get the whole thing done over one weekend, about 6 hours total. (any normal person could do it in an afternoon, but when you have a wife, two teenagers, and a dog underfoot you don't have so much time to tinker with the OS) -- Peter B. Steiger Cheyenne, WY -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gnome and libexec path
On Wed, 2006-06-07 at 09:24 -0600, Peter B. Steiger wrote: On Wed, 2006-06-07 at 22:45 +1200, Simon Geard wrote: Out of curiosity, do you have similar problems with the various calendaring functions? Absolutely - Any attempt to go into the calendar functions locks up all of Evolution, and I had to go to console and kill the process to regain control of my desktop. Ok, so maybe they didn't fix the problem in 2.6 and it's just gone away (for me) for no particular reason. That's worrying, since it means it could come back just as easily... For what it's worth, I build e-d-s with the following options: ./configure \ --prefix=/usr \ --libexecdir=/usr/sbin \ --sysconfdir=/etc \ --localstatedir=/var/lib \ --disable-gtk-doc \ --enable-debug \ --disable-static \ --disable-dependency-tracking And evolution itself with the same plus --enable-nntp --enable-nss. I don't recall changing any of these settings when I upgraded from Evo 2.4, but something must be different about the current setup... Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gnome and libexec path
On Tue, 2006-06-06 at 09:02 -0600, Peter B. Steiger wrote: Now all the icons appear correctly, but yet again my contacts list is gone! I cleaned out my test user's entire /home directory so there would not be any previous config files in place, started up again so Gnome could build whatever it wanted from scratch, and it still won't let me add contacts... the menu option is there, but does nothing when I click on it. And when it's working, an empty contact list comes up with a message in the contacts window saying there are no contacts; when it doesn't work, that window is blank when there is an empty contacts list. That's exactly the problem I used to have, but I've never had any such issues since upgrading to Evolution 2.6. Out of curiosity, do you have similar problems with the various calendaring functions? On Evolution 2.4 and most of the 2.5 series, selecting New - Meeting (or any similar command) was enough to lock the program completely - something I'd traced to thread locking while trying to connect to evolution-data-server. Logged a bug for it, but I've never had much luck dealing with the Evolution developers on bugzilla... Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gnome and libexec path
On Wed, 2006-06-07 at 22:45 +1200, Simon Geard wrote: Out of curiosity, do you have similar problems with the various calendaring functions? Absolutely - Any attempt to go into the calendar functions locks up all of Evolution, and I had to go to console and kill the process to regain control of my desktop. Latest update: Last night I rebuilt evolution-data-server and evolution 2.6 with various configure switches changed. Disabling NSS and SMIME didn't help (I thought it might not be handling my Firefox libraries correctly), but when I disabled dot-locking and file-locking, both calendar and contacts worked fine again. Next chance I get I'll narrow it down further to see if it's only one of the locking options or both that are causing the error. -- Peter B. Steiger Cheyenne, WY -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gnome and libexec path
On Mon, 2006-06-05 at 14:00 -0600, Peter B. Steiger wrote: To make a long story short (too late!) what I finally realized after blowing the weekend on this project was that for whatever reason, Evolution (and possibly the Gnome panel) doesn't like having libexec processes in the /bin folder. This week I'll rebuild again putting libexec into some other location and see if that fixes the erratic behavior (the program's, not mine). Interesting... I've always built Gnome with --libexecdir=/usr/sbin, and never had much in the way of problems. I *have* had some issues with Evolution and contacts, but thought that to be a bug in Evo, particularly since it doesn't occur with 2.6 (i.e Gnome 2.14). Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Gnome and libexec path
Finally the light dawned last night. I have tried to upgrade Gnome to 2.1x several times over the past six months and each time ran into missing icons or (the most frequent and annoying symptom) a broken address book that won't show my existing entries or allow me to add new ones. Somehow a couple of weeks ago I got everything working with 2.12 except the Evolution icons that seem to come and go at random, and when someone mentioned a possible problem with my path I thought I'd take a closer look at the paths I use. Now, unlike the instructions in the book I don't type a full ./configure command every time. I have a standard bash script called gconfig for Gnome installations that sends all the standard config parameters - prefix, libexecdir, etc. - to .configure so I can just type gconfig make on all 40 or 50 individual packages; I have the process streamlined to where I can install a whole new GTK/Gnome system in about four hours. When I looked at the paths from my last mostly-working installation I noticed that libexec was going to /usr/gnome/sbin, and I thought it's stupid to have yet another path for binaries that I have to add to my PATH environment, so I recompiled everything to put libexec files in /usr/gnome/bin . That's when I once again lost the use of my Evolution contacts. By replacing one program at a time from my working copy into my failed copy, I narrowed it down to those programs that launch child processes in the libexec directory. To make a long story short (too late!) what I finally realized after blowing the weekend on this project was that for whatever reason, Evolution (and possibly the Gnome panel) doesn't like having libexec processes in the /bin folder. This week I'll rebuild again putting libexec into some other location and see if that fixes the erratic behavior (the program's, not mine). Which leads me to my question for those who have had the patience to wade through my epic novel: Why did you (blfs authors) write the Gnome section so as to put the libexec functions in a separate directory (e.g., /usr/gnome/lib/gnome-applets, /usr/gnome/lib/bonobo, etc.) rather than just one big /usr/gnome/lib/libexec? -- Peter B. Steiger, learning my lesson about deviating from the recipe too much Cheyenne, WY -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gnome and libexec path
Peter B. Steiger wrote: Why did you (blfs authors) write the Gnome section so as to put the libexec functions in a separate directory (e.g., /usr/gnome/lib/gnome-applets, /usr/gnome/lib/bonobo, etc.) rather than just one big /usr/gnome/lib/libexec? There was a discussion about it and the decision was to put libexec files for PACKAGE in /usr/lib/$PACKAGE http://linuxfromscratch.org/pipermail/blfs-dev/2005-October/011808.html Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gnome and libexec path
On 6/5/06, Andrew Benton [EMAIL PROTECTED] wrote: Peter B. Steiger wrote: Why did you (blfs authors) write the Gnome section so as to put the libexec functions in a separate directory (e.g., /usr/gnome/lib/gnome-applets, /usr/gnome/lib/bonobo, etc.) rather than just one big /usr/gnome/lib/libexec? There was a discussion about it and the decision was to put libexec files for PACKAGE in /usr/lib/$PACKAGE http://linuxfromscratch.org/pipermail/blfs-dev/2005-October/011808.html The idea is that these are binaries that are not supposed to be run by users. That's why they go in $prefix/libexec by default. That's not in anyone's path. Where you decide to dump things is up to you, but you should probably keep it out of your PATH unless you know there's a binary you'll really need and can use. I like $prefix/lib/$packagename because it keeps things nice and clean and modular-ish. Also, a lot of the gnome packages already create that directory, so it makes sense to dump more of it's files there. For instance, we put the GConf files in libexecdir=$prefix/lib/GConf. That's convenient because it will be populated regardless. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gnome and libexec path
On Mon, 2006-06-05 at 22:44 +0100, Andrew Benton wrote: There was a discussion about it and the decision was to put libexec files for PACKAGE in /usr/lib/$PACKAGE http://linuxfromscratch.org/pipermail/blfs-dev/2005-October/011808.html Domo arrigato! Glad to know I wasn't the only one troubled by the /sbin location for libexec files. At the risk of reopening an issue that has already been settled by smarter people than I, I'm still gonna stick with $PREFIX/libexec rather than $PREFIX/lib/$package so I can continue to use the same one-word command to launch configure... or maybe I'll come up with a way to work `pwd` (without the version number) into the bash script so I can still use my one-word configure script and customize libexecdir for each package. -- Peter B. Steiger Cheyenne, WY -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ldconfig: wrong path
Alberto Hernando wrote: Hi. I have my LFS system and I've started installing some packages. At some point I must have made a mistake, because when I run ldconfig, it searches ld.so.conf in a wrong path that starts with /mnt/lfs. I guess I should recompile ldconfig again, but I can't find where it was compiled, or how to configure it. Right now I'm using symbolic links to make it work, but I don't think it's a good solution. It doesn't work very well. For example, I've installed glib under /usr, and now cairo, gtk+, and others can't find it. any help? Thanks Run ldd on several programs, and paste the output here. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ldconfig: wrong path
On 2/8/06, Alberto Hernando [EMAIL PROTECTED] wrote: Hi. I have my LFS system and I've started installing some packages. At some point I must have made a mistake, because when I run ldconfig, it searches ld.so.conf in a wrong path that starts with /mnt/lfs. I guess I should recompile ldconfig again, but I can't find where it was compiled, or how to configure it. Right now I'm using symbolic links to make it work, but I don't think it's a good solution. It doesn't work very well. For example, I've installed glib under /usr, and now cairo, gtk+, and others can't find it. any help? Thanks Is ldconfig looking for ld.so.conf in /mnt/lfs/* or does ld.so.conf have an entry starting with /mnt/lfs in it? The second case should require just removing the offending entry from ld.so.conf. -- LFS ID #12355 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ldconfig: wrong path
El Miércoles, 8 de Febrero de 2006 14:55, Chris Staub escribió: Run ldd on several programs, and paste the output here. Here it is. I got it chrooting to the LFS: [EMAIL PROTECTED]:Sarge:~# ldd /usr/X11R6/bin/xedit linux-gate.so.1 = (0xe000) libXp.so.6 = /usr/X11R6/lib/libXp.so.6 (0x4001c000) libXaw.so.8 = /usr/X11R6/lib/libXaw.so.8 (0x40025000) libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x40081000) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x40096000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x400e8000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x400f1000) libXpm.so.4 = /usr/X11R6/lib/libXpm.so.4 (0x40109000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x4011a000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x40128000) libm.so.6 = /lib/libm.so.6 (0x401f5000) libc.so.6 = /lib/libc.so.6 (0x40218000) libdl.so.2 = /lib/libdl.so.2 (0x40332000) /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED]:Sarge:~# ldd /bin/fuser linux-gate.so.1 = (0xe000) libc.so.6 = /lib/libc.so.6 (0x4001c000) /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED]:Sarge:~# ldd /usr/sbin/chroot linux-gate.so.1 = (0xe000) libc.so.6 = /lib/libc.so.6 (0x4001c000) /lib/ld-linux.so.2 (0x4000) This looks ok. Alberto -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ldconfig: wrong path
El Miércoles, 8 de Febrero de 2006 14:58, Robert Russell escribió: Is ldconfig looking for ld.so.conf in /mnt/lfs/* or does ld.so.conf have an entry starting with /mnt/lfs in it? This: [EMAIL PROTECTED]:Sarge:~# ldconfig ldconfig: Can't open configuration file /mnt/lfs/usr/etc/ld.so.conf: No such file or directory ldconfig: Can't create temporary cache file /mnt/lfs/usr/etc/ld.so.cache~: No such file or directory Making /mnt/lfs an appropiate symbolik link seems to solve the problem, but no. Configuring cairo: configure: WARNING: Could not find libpng in the pkg-config search path configure: WARNING: *** To run the tests and the following features: PNG functions: no I'm sure that ldconfig isn't working well, but perhaps I'm not configuring pkg-config properly. The instruction in the BLFS book are pretty simple, so I don't know what I'm having wrong. [EMAIL PROTECTED]:Sarge:/usr/lib/pkgconfig# ls blkid.pce2p.pc fontconfig.pc glib-2.0.pc gmodule-export-2.0.pc gobject-2.0.pc libpng12.pc ss.pc com_err.pc ext2fs.pc freetype2.pc gmodule-2.0.pc gmodule-no-export-2.0.pc gthread-2.0.pc libpng.pcuuid.pc Alberto -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ldconfig: wrong path
Alberto Hernando wrote: El Miércoles, 8 de Febrero de 2006 14:58, Robert Russell escribió: Is ldconfig looking for ld.so.conf in /mnt/lfs/* or does ld.so.conf have an entry starting with /mnt/lfs in it? This: [EMAIL PROTECTED]:Sarge:~# ldconfig ldconfig: Can't open configuration file /mnt/lfs/usr/etc/ld.so.conf: No such file or directory ldconfig: Can't create temporary cache file /mnt/lfs/usr/etc/ld.so.cache~: No such file or directory Making /mnt/lfs an appropiate symbolik link seems to solve the problem, but no. Configuring cairo: I'm sure that ldconfig isn't working well, but perhaps I'm not configuring pkg-config properly. The instruction in the BLFS book are pretty simple, so I don't know what I'm having wrong. [EMAIL PROTECTED]:Sarge:/usr/lib/pkgconfig# ls blkid.pce2p.pc fontconfig.pc glib-2.0.pc gmodule-export-2.0.pc gobject-2.0.pc libpng12.pc ss.pc com_err.pc ext2fs.pc freetype2.pc gmodule-2.0.pc gmodule-no-export-2.0.pc gthread-2.0.pc libpng.pcuuid.pc Alberto Then that probably means binutils is linked to the wrong libs. Run ldd on /usr/bin/ld. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ldconfig: wrong path
El Miércoles, 8 de Febrero de 2006 15:21, Chris Staub escribió: Then that probably means binutils is linked to the wrong libs. Run ldd on /usr/bin/ld. Here it is: [EMAIL PROTECTED]:Sarge:~# ldd /usr/bin/ld linux-gate.so.1 = (0xe000) libbfd-2.15.94.0.2.2.so = /usr/lib/libbfd-2.15.94.0.2.2.so (0x4001c000) libdl.so.2 = /lib/libdl.so.2 (0x40099000) libc.so.6 = /lib/libc.so.6 (0x4009d000) /lib/ld-linux.so.2 (0x4000) Now, let add something: if I do to the trick with the symlinks, ldconfig runs, so this info might be from a right run. The current /mnt/lfs doesn't exist. Does it help? anyway, I'm going to recompile binutils. Alberto -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ldconfig: wrong path
On 2/8/06, Alberto Hernando [EMAIL PROTECTED] wrote: El Miércoles, 8 de Febrero de 2006 15:21, Chris Staub escribió: Then that probably means binutils is linked to the wrong libs. Run ldd on /usr/bin/ld. Here it is: [EMAIL PROTECTED]:Sarge:~# ldd /usr/bin/ld linux-gate.so.1 = (0xe000) libbfd-2.15.94.0.2.2.so = /usr/lib/libbfd-2.15.94.0.2.2.so (0x4001c000) libdl.so.2 = /lib/libdl.so.2 (0x40099000) libc.so.6 = /lib/libc.so.6 (0x4009d000) /lib/ld-linux.so.2 (0x4000) Now, let add something: if I do to the trick with the symlinks, ldconfig runs, so this info might be from a right run. The current /mnt/lfs doesn't exist. Does it help? anyway, I'm going to recompile binutils. I hate to be the bearer of bad news, but if ldconfig is reporting that it's looking in /mnt/lfs, then glibc is your problem. And if parts of glibc think that the default path is in /mnt/lfs, then you may have some big issues. I don't think recompiling binutils will have any effect on your situation. In fact, if you were able to build all of LFS, then surely you can link at build time (binutils). You can try to rebuild glibc, but be careful. If you'd like to do this, I can help, but know that installing glibc over your running system could kill it. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ldconfig: wrong path
El Miércoles, 8 de Febrero de 2006 15:53, Dan Nicholson escribió: I hate to be the bearer of bad news, but if ldconfig is reporting that it's looking in /mnt/lfs, then glibc is your problem. And if parts of glibc think that the default path is in /mnt/lfs, then you may have some big issues. I don't think recompiling binutils will have any effect on your situation. In fact, if you were able to build all of LFS, then surely you can link at build time (binutils). You can try to rebuild glibc, but be careful. If you'd like to do this, I can help, but know that installing glibc over your running system could kill it. Oh, so I probably made a mistake when I compiled glibc for the second pass. Ok, let's try to rebuild it. If you say that you can help, I guess that the instructions in the book are not enough, right? So let's see if with your help I can fix this. After all, updating glibc should be safe, and I'do it inside a chroot. Alberto -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
