Re: OpenOffice 2.3.1 nitpick
Nathan Coulson wrote: Just wanted to note that I had to add --without-pam to build without the optional dependency pam. Thanks Nathan. I'll have this added to the default configure command and an explanation put in the book tomorrow. -- DJ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: firefox-2.x netscape symlink
Randy McMurchy wrote: thorsten wrote these words on 10/16/07 09:37 CST: sorry for the confusion, being no native english speaker I confused things here a bit I think. What I meant is: my Openoffice tries to open netscape when a link is being klicked on. And I didn't find an option to change this in the Openoffice Options-Menu. So if there really is no Option to tell Openoffice to use firefox, I need the second link to get firefox to work. Thanks for the clarification. It makes sense now. As I don't have Ooo installed, I'll simply take your word about it. I think what might be best is to provide an instruction to create the second link as you suggested. I don't see any real alternative. Thanks for the input. I haven't looked for it yet in OOo source, but with OOo-2.2.1 built against Firefox-2.0.0.4 in a gnome environment, clicking a link in Writer works as expected. Was this a recent change in the run-mozilla.sh script that I don't see because of the older version? Is there any chance that this comes from your window manager's default browser setting? As far as the netscape symlink, I think that is probably way outdated info. I haven't created that link in a long time, and haven't seen any problems with it. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
6.3 release schedule?
I've been away quite a bit lately, do we have an expected release date for 6.3 yet? Pretty much, as long as package freeze isn't in the next 3 weeks or so, I should be able to get to the couple of bugs I just opened. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Asterisk? [LONG]
Alan Lord wrote: I'm very happy with the results I've got and I wonder if I should write it up as a hint, stick it on the wiki, or even (he hesitates to suggest such a thing; such audacity!) try to get it in the book... Snip IMO, it's probably not for the book due to the limited audience and maintenance burden, however, there are a few packages in BLFS that remain in the book though similar. I might be wrong abut that, but I don't know (see below). I'm not the one to ask about inclusion anyway, I'm barely around anymore. Now, if it's not selected for the book, it is perfect material for the wiki or a hint. I prefer the wiki now days. I'd hate to see the time you put into the write-up just get lost in the archive of this list. Somebody *will* need to do the same or similar setup (else those projects wouldn't be around). Additionally, while wiki/hint/blfs material is directed at LFSers, that doesn't mean it's limited to an LFS only audience if written correctly. You can have the maintainers link to the document in it's final form if it will help somebody else down the line. As far as a full critique: Instructions and text look good overall, but I still have no idea what Zaptel or Asterisk is used for or does. I've made no attempt to look on my own as I'm reviewing potential instructions for BLFS. In the opening paragraph for zaptel, I only recognized T1, so I've made a blind assumption that this is some software to replace expensive telco equipment with inexpensive PC hardware (maybe less expensive is a more accurate description, or I'm completely off base). This description might be fine, if I knew that it was a support package for Asterisk. Keep in mind that if I'm a user reading BLFS, I'd have said no, I don't need this as soon as I seen 'T1' and moved on to the next package. Asterisk is completely lacking introductory text. Right now it's a package, I have no idea whether it would be useful to me. As far as the content of the instructions, I have two items to question (short of not knowing what I'm discussing). First, the 640 perms on /etc/asterisk/*. It seems to me that only the asterisk user needs access to those files. They do contain clear text passwords, so 600 seems more suitable unless read perms are absolutely needed by other users/daemons, or maybe make it a little more fine grained specifically for the secrets. The reasoning could be explained better in the surrounding text or in the 'Command Explanations' section for the page, which is also missing for the BLFS format. I've also never used the '=' parameter in a chmod, and it doesn't currently appear in BLFS AFAIK, so it should be explained. Second is the inconsistent formatting in this text version. Some instructions are indented while others aren't and line wrapping is not accounted for. Plan on 72 characters in an email and 80 characters for book instructions. For the wiki's command blocks, wrapping is not an issue, but I generally assume that wiki instructions will be used on a text console which is typically 80 characters. Otherwise it looks pretty good without actually using the package. And of course, for book inclusion, you'd need to provide descriptions of all executables. Again, as far as whether it's suited for BLFS, that's up to the more active editors. I hope that helps. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: dhcpcd not killed
DJ Lucas wrote:
DJ Lucas wrote:
David Olsson wrote:
This got lost, I think. So here it is again.
On my BLFS 6.2 system, the SysVinit script
/etc/rc.d/init.d/network stop
does not kill dhcpcd. Tracing it to the script
/etc/sysconfig/network-devices/services/dhcpcd
it turns out that if the dhcp lease time is infinite, the script believes
that dhcpcd exited after startup. Such is not the case, and I don't see in
the dhcpcd docs that it should be true. Is anyone familiar with these
scripts? The question is, shall we eliminate the check for infinite lease
time, and kill the running dhcpcd.
No...have to account for multiple interfaces. Also, this was the case,
it did exit at one time...I verified that it worked when the change was
made to the scripts...I almost always use RL1 to test service scripts.
Okay, my fuzzy memory sucks! The original analysis by David was
correct. Please ignore what I wrote about multiple interfaces in my
previous message. I was confusing some of the former dhclient problems
for dhcpcd. dhcpcd does create multiple instances...so sending TERM is
fine if DHCP_STOP is null, just set PIDFILE to
/var/run/dhcpcd-$INTERFACE.pid. And yes, the check for infinite lease
should go away since version 3, I guess...no mention of it in the changelog.
-- DJ Lucas
David, would you mind trying the patch below? It's exactly what you had
already mentioned (with the variable names fixed for 3.0.19), so you
probably already have the same or similar. I don't use the stock
scripts anymore as I've been working on lsb-v3, though the same logic,
mine use different functions so I can't easily test. Apply with -Np0
instead of -Np1 as you normally would (or manual) and then re-install
the script 'make install-service-dhcpcd'. This to anybody else who uses
it as well.
Thanks.
-- DJ Lucas
Index: blfs/sysconfig/network-devices/services/dhcpcd
===
--- blfs/sysconfig/network-devices/services/dhcpcd (revision 7090)
+++ blfs/sysconfig/network-devices/services/dhcpcd (working copy)
@@ -46,12 +46,12 @@
boot_mesg_flush
boot_mesgSubnet Mask:
$NETMASK
boot_mesg_flush
- boot_mesgDefault Gateway:
$GATEWAY
+ boot_mesgDefault Gateway:
$GATEWAYS
boot_mesg_flush
- boot_mesgDNS Server: $DNS
+ boot_mesgDNS Server:
$DNSSERVERS
boot_mesg_flush
else
- boot_mesg IP Addresss: $IPADDR
+ boot_mesg IP Addresss: $IPADDR
echo_ok
fi
else
@@ -63,43 +63,23 @@
down)
boot_mesg -n Stopping dhcpcd on the $1 interface...
- # Do nothing with the client daemon if we have an infinate
- # lease time as the client exits when started in this case,
- # just echo OK.
- if [ -e $LEASEINFO ]
+ if [ -z $DHCP_STOP ]
then
- . $LEASEINFO
-
- if [ $LEASETIME = 4294967295 ]
- then
- # do nothing, just echo ok
+ echo
+ killproc -p $PIDFILE /sbin/dhcpcd
+ else
+ /sbin/dhcpcd $1 $DHCP_STOP /dev/null
+ RET=$?
+ if [ $RET -eq 0 ]; then
echo
echo_ok
+ elif [ $RET -eq 1 ]; then
+ boot_mesg dhcpcd not running! ${WARNING}
+ echo_warning
else
- if [ -n $DHCP_STOP ]
- then
- /sbin/dhcpcd $1 $DHCP_STOP /dev/null
- RET=$?
- if [ $RET -eq 0 ]; then
- echo
- echo_ok
- elif [ $RET -eq 1 ]; then
- boot_mesg dhcpcd not running!
${WARNING}
- echo_warning
- else
- echo
- echo_failure
- fi
- else
echo
- killproc dhcpcd
+ echo_failure
Re: dhcpcd not killed
DJ Lucas wrote: David Olsson wrote: This got lost, I think. So here it is again. On my BLFS 6.2 system, the SysVinit script /etc/rc.d/init.d/network stop does not kill dhcpcd. Tracing it to the script /etc/sysconfig/network-devices/services/dhcpcd it turns out that if the dhcp lease time is infinite, the script believes that dhcpcd exited after startup. Such is not the case, and I don't see in the dhcpcd docs that it should be true. Is anyone familiar with these scripts? The question is, shall we eliminate the check for infinite lease time, and kill the running dhcpcd. No...have to account for multiple interfaces. Also, this was the case, it did exit at one time...I verified that it worked when the change was made to the scripts...I almost always use RL1 to test service scripts. Okay, my fuzzy memory sucks! The original analysis by David was correct. Please ignore what I wrote about multiple interfaces in my previous message. I was confusing some of the former dhclient problems for dhcpcd. dhcpcd does create multiple instances...so sending TERM is fine if DHCP_STOP is null, just set PIDFILE to /var/run/dhcpcd-$INTERFACE.pid. And yes, the check for infinite lease should go away since version 3, I guess...no mention of it in the changelog. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: dhcpcd not killed
David Olsson wrote: This got lost, I think. So here it is again. On my BLFS 6.2 system, the SysVinit script /etc/rc.d/init.d/network stop does not kill dhcpcd. Tracing it to the script /etc/sysconfig/network-devices/services/dhcpcd it turns out that if the dhcp lease time is infinite, the script believes that dhcpcd exited after startup. Such is not the case, and I don't see in the dhcpcd docs that it should be true. Is anyone familiar with these scripts? The question is, shall we eliminate the check for infinite lease time, and kill the running dhcpcd. No...have to account for multiple interfaces. Also, this was the case, it did exit at one time...I verified that it worked when the change was made to the scripts...I almost always use RL1 to test service scripts. Why hasn't anyone noticed this, you ask? Because shutdown sends dhcpcd a terminate signal and dhcpcd is well-behaved, that being what it expects. However, if you telinit 1 then telinit 3 you get a nasty error message that interrupts the SysVinit sequence and tells you you'd better track down the problem and report it. So I did. If the interface was downed correctly, then there should be no address assignment, doesn't matter if dhcpcd is already running. Seems like something might have been broken in newer dhcpcd. Quick thought, does the lease info file still exist in RL1? If the lease info file is removed, does it then work correctly jumping back into 3? Additional Point: If the scripts DO kill dhcpcd, they do it with dhcpcd -k which does NOT seem to be the recommended way to stop dhcpcd. With '-k' dhcpcd destroys the ip info cache, so that next time it will request a new ip address, rather than first trying to reestablish the old one. dhcpcd EXPECTS to receive a terminate (SIGTERM) signal, in which case the cache is preserved. It looks to me like if we do not set DHCP_STOP in Bad assumption. SIGHUP, or the -k switch, *is* the preferred way to terminate a lease provided by dhcpcd for the majority of users (LANs). The current manpage doesn't mention it, but IIRC, with the -k switch you can release by interface. When using -k (or if SIGHUP is received), then a DHCP_RELEASE is sent to the DHCP server, as should almost always be done unless you don't want the server to know you've gone. I'd much rather get a resolution failure right off the bat than to wait for a connection attempt to time out. The exception is usually cable modem users. IME, cable companies don't like to give static addresses on consumer packages...or if they do offer you one, it's be almost as cheap to get 5 addys in the business class package. But in most scenarios, it's the server's job to assign an address, not the client's job to make a suggestion to the server. I should also put out the disclaimer: This is the way dhcpcd *used* to behave...I haven't used it in a long time. I think it was me that added the check for the infinate lease after a bug report was submitted, but I can't remember how long ago, or how many versions ago that was...Hell, I'm not even positive that I made the change, but I do remember the conversations about it. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: jdk 1.6 update 2 build is failing
Randy McMurchy wrote: Well, the Xorg Libs page still says to create the /usr/include/X11 and /usr/lib/X11 links, so I did/do. Should we? Not sure, but I can say I have the two links I mentioned, and I built JDK 1.6 without any issues. Yes they should, for the same reason we now have the /usr/X11R6 link. Programs that have very slowly evolved over the years. The bin symlink is not in the book, and I'm not sure why. IIRC, all three of these were in the combined configuration section, but I think that got juggled around when the library installations choked early on in xorg-7.0's introduction to the book. I must have dropped the ball on that one, but FWIW, I've never seen anything that needed /usr/bin/X11. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [BLFS Trac] #2019: MPlayer-1.0rc1 (updated but still issues?)
BLFS Trac wrote: Updated BLFS to MPlayer-1.0rc1 I have not noticed any issues with DVD decoding. Seems okay to me. As far as libdvdread and mpdvdkit goes, libdvdread is used as the primary if it is found (libdv installed also), and mpdvdkit is the fallback. I did not disable RTC. As far as X Window prefix notes, I didn't see any. Was I supposed to add some? I'll keep the ticket open for a few days to see if DJ will comment. I think it was OK last time I built it. There was a paragraph about non-standard X Prefix some time ago...or at least I thought there was. The build used to die on can't find Xlib.h IIRC. Do you have /usr/X11 or /opt/X11 and _no_ /usr/X11R6 symlink? If so, then I suppose it's not needed now. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [BLFS Trac] #2019: MPlayer-1.0rc1 (updated but still issues?)
M.Canales.es wrote: El Sábado, 11 de Agosto de 2007 20:11, DJ Lucas escribió: Execute the following command to create the compatibility symlink: ln -s $XORG_PREFIX /usr/X11R6 = Except if XORG_PREFIX == /usr , I think. It wouldn't hurt anything, however I think we can deal with 1 conditional in comparison to our current 15. :-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [BLFS Trac] #2019: MPlayer-1.0rc1 (updated but still issues?)
M.Canales.es wrote: El Sábado, 11 de Agosto de 2007 20:11, DJ Lucas escribió: Execute the following command to create the compatibility symlink: ln -s $XORG_PREFIX /usr/X11R6 = Except if XORG_PREFIX == /usr , I think. BTW guys, if this is a go, then please do not remove any instructions that modify the search paths, just comment them out. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [BLFS Trac] #2019: MPlayer-1.0rc1 (updated but still issues?)
Dan Nicholson wrote: On 8/11/07, DJ Lucas [EMAIL PROTECTED] wrote: M.Canales.es wrote: El Sábado, 11 de Agosto de 2007 20:11, DJ Lucas escribió: Execute the following command to create the compatibility symlink: ln -s $XORG_PREFIX /usr/X11R6 = Except if XORG_PREFIX == /usr , I think. BTW guys, if this is a go, then please do not remove any instructions that modify the search paths, just comment them out. You mean like in Qt3 or something else? http://www.linuxfromscratch.org/blfs/view/svn/x/qt.html If the symlink is added, then the grep and sed is unnecessary. Just don't remove the text right awayjust comment it out in the xml. I also assume that we will continue to use XORG_PREFIX throughout the Xorg section, I also wonder if that'll affect Mesa or any of the other packages installed into the Xorg prefix that don't fall into the Xorg section directly. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: X11R6 compatibility symlink
Randy McMurchy wrote: Randy McMurchy wrote these words on 08/11/07 14:59 CST: I'll work on writing the paragraph unless somebody beats me to it. Thinking about it more, what about the paragraph we are already talking about, and for each page that we're now providing some X11R6 hack we put in a xinclude statement to a blanket file and comment out all the hacks. The blanket file would say something to the effect of: This package requires the X11R6 compat symlink created at the beginning of the X installation (provide xref link right to it) if your X is installed in any location other than /usr/X11R6. I'm not sure if at the very end of it, we can add or /usr. Seems most of the scripts looking for the X11R6 also fall back to /usr, but I can't say for sure. It would be nice if that was the case. For most, yes, but there are a couple, or at least there were around the time of the first release, that didn't look in /usr. In fact, IIRC there were a couple that had /usr/X11R6 in the source code. Anyway, I do like that better. Those interested can look at the XML sources to see exactly what we did before and none of those previous 'workarounds' are lost. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: X11R6 compatibility symlink
Randy McMurchy wrote: Randy McMurchy wrote these words on 08/11/07 14:08 CST: I am certainly guilty about not helping out on this one. I've made the symlink in every installation I've done because it just works. Seems anything else is just banging your head against the wall. This comes off poorly. What I should have said is: No it doesn't come off poorly. This is why I always argued against the symlink before. We've all sidestepped this one. The grep and seds in the book only help our readers, not the maintainer or anybody else outside of the project who might have the same problem. Just do it, and keep the explanation simple and not discuss the 'necessary evil'. Explain that it's an optional stopgap until upstream (the whole world?) gets their stuff together. It is our responsibility to make sure that it gets done, not our readers', unless of course they choose to. The experienced reader will know that it's bad when we he or she sees 'compatibility' or 'stopgap' and take on the task if they choose, as will our developers if/when they have the time to do so. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: dbus-python error
Randy McMurchy wrote: DJ Lucas wrote these words on 07/25/07 14:43 CST: Guys, I'm getting an error in dbus-python installation. I'm not seeing it. Compiles fine for me. Here's my stack: [EMAIL PROTECTED]: ~/build find Sources -name *py* Sources/GNOME2/gnome-python-desktop-2.18.0.tar.gz Sources/Non_BLFS/gnome-python-2.18.2.tar.gz Sources/Non_BLFS/pycairo-1.4.0.tar.gz Sources/Non_BLFS/pyorbit-2.14.3.tar.gz Sources/Non_BLFS/pygtk-2.10.6.tar.gz Sources/Non_BLFS/pygobject-2.12.3.tar.gz Sources/BLFS/dbus-python-0.82.0.tar.gz Thank you. Only the version of pyorbit differs. I wonder what the heck is up then. I thought maybe it was a naming change or something, but the older versions give me the same problem. Guess I can rip out /usr/lib/python-2.5 for the moment and do a completely clean installation and see what happens. I'm not really sure I understand the problem, not knowing python very well. Ahh...looking in site, it's only about 20, maybe 25 packages...but it'll have to wait for tomorrow. DJ, any chance you can fix the clock in your machine so that the emails come into my inbox somewhat orderly? You seem to be running about 5 hours wrong (UTC vs. your time zone, perhaps?). Oops. Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
dbus-python error
Guys, I'm getting an error in dbus-python installation. I originally had python-2.5.0, updated to python-2.5.1 (after removing the partial installation of dbus-python). Still get the same error. I've got a fairly small list of python modules, but they all checked out fine with the 2.5.1 update, so I don't think it's a local issue. Here is the error, maybe should goto support, but I think I remember something similar just before blfs-6.2, in dbus-0.62 (does that sound right??). Anybody seen this one yet? /sources/dbus-python-0.82.0/install-sh -c -m 644 'types.py' '/usr/lib/python2.5/site-packages/dbus/types.py' 'import site' failed; use -v for traceback Traceback (most recent call last): File string, line 2, in module File /usr/lib/python2.5/os.py, line 696, in module import copy_reg as _copy_reg File /usr/lib/python2.5/copy_reg.py, line 7, in module from types import ClassType as _ClassType File types.py, line 6, in module from _dbus_bindings import ObjectPath, ByteArray, Signature, Byte,\ ImportError: No module named _dbus_bindings make[3]: *** [install-nobase_pythondbusPYTHON] Error 1 make[3]: Leaving directory `/sources/dbus-python-0.82.0/dbus' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/sources/dbus-python-0.82.0/dbus' make[1]: *** [install] Error 2 make[1]: Leaving directory `/sources/dbus-python-0.82.0/dbus' make: *** [install-recursive] Error 1 [EMAIL PROTECTED] dbus-python-0.82.0]# FWIW, I have these python modules added (in order): [EMAIL PROTECTED] sources]# grep py /var/log/packages numpy-1.0.3 pyorbit-2.14.3 pygobject-2.12.3 pycairo-1.4.0 pygtk-2.10.4 gnome-python-2.18.2 gnome-python-desktop-2.18.0 Actually, I just looked at the gentoo ebuild and they list pyrex as a dep, but I still get the same error running make install. Just FYI, the error is correct! I see dbus_bindings.py but not _dbus_bindings.py. [EMAIL PROTECTED] dbus-python-0.82.0]# ls -R /usr/lib/python2.5/site-packages/*dbus* /usr/lib/python2.5/site-packages/_dbus_bindings.la /usr/lib/python2.5/site-packages/_dbus_bindings.so /usr/lib/python2.5/site-packages/_dbus_glib_bindings.la /usr/lib/python2.5/site-packages/_dbus_glib_bindings.so /usr/lib/python2.5/site-packages/dbus: bus.pydecorators.pygobject_service.py proxies.py connection.py exceptions.py__init__.py service.py dbus_bindings.py _expat_introspect_parser.py lowlevel.py types.py _dbus.py glib.py mainloop _version.py /usr/lib/python2.5/site-packages/dbus/mainloop: glib.py __init__.py [EMAIL PROTECTED] dbus-python-0.82.0]# Copying the file to the expected name simply brings more errors... dbus.exceptions.py is next. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK version 6
DJ Lucas wrote: Subversion, PDL, FreeTTS, Junit, Pilot-link, Graphviz, libidn, Apache-ant, java-access-bridge, KDE Base, KDE Bindings, Cyrus-sasl, cups, OpenSSH, Berkly DB, and OpenOffice. If anyone would like to lend their experience, remaining are PDL modules, Pilot-link, KDE Base, KDE Bindings, and cups. I plan on doing cups tomorrow, but the others are not something that I would normally build. Especially the dep list for the PDL Modules. Randy, I know you've been using JDK6, can you cross any of the remainder off this list? -- DJ Lucas:q -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK version 6
DJ Lucas wrote: Randy McMurchy wrote: 3. The GCC patch should probably be at a -2 revision level, indicating a difference in your original. It'll probably have to be rediffed anyway, I think they got the ' /dev/null' added in the compiler check when we get the new sources. Well they didn't, but it appears that the patch to vectornode.hpp is no longer needed. IIRC, that patch came from upstream, but they did it a little differently and icked some of the whitespace so it failed instead of saying already applied. Anyway, the new gcc4 patch is in the repo and links created for u2 for the other two patches. My local copy (and book patch) is updated on quantum. As far as the dependent packages, I have this list, but I don't know if I missed anything. It's the result of greping an export for 'jdk' and 'apache-ant': Subversion, PDL, FreeTTS, Junit, Pilot-link, Graphviz, libidn, Apache-ant, java-access-bridge, KDE Base, KDE Bindings, Cyrus-sasl, cups, OpenSSH, Berkly DB, and OpenOffice. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg wget download links
Randy McMurchy wrote: I wrote these words on 07/12/07 14:58 CST: I think there should be a list of links, and I suppose the Wiki would be best for it, with a mention on the X pages that it can be found at Wiki URL. That way, a person can do it either way they choose. Another thing we need to think about is the package updates. By creating a list of actual download links (wherever it may be decided it goes) it does create a bit of a burden on the Editor who does the Xorg updates as it means updating two lists of files. We need DJ and Dan to provide input as they've been the ones doing the Xorg work. I'm not really sure my name belongs in that context, Dan has pretty much taken the ball and ran with it long ago. As far as the wiki is concerned, and it's been a while since I put anything on the wiki, but it's at worst a 3 or 4 line script for formatting to update the wiki from the wget and md5 lists. The toughest part is remembering to do it when the file lists change. :-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: suggestion to use subversion 1.4.4 in blfs (a bit hacky still)
Randy McMurchy wrote: As far as the SVN bindings, I wanted to build JDK version 6 first. I did that today. I will test all of BLFS against it (except I can't promise I'll build Ooo). Sweet! I kinda got ticked when Update 2 was released. :-) Doh! Start over! I'm firing off a JDK build and using your new patch and seds in just a few minutes. Thanks. My local copy is being updated with your changes and I'll pass off a book patch with the textual changes. I wouldn't worry much about OOo if you don't need it, it should be Ok, but I'm still slow-pokin my way through the optionals when I don't have the kids at home. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK version 6
DJ Lucas wrote: http://www.linuxfromscratch.org/~dj/blfs-book-xsl/index.html or the book diff is also in my homedir. OOo-2.2.1 is there too. Oops...I should mention this is not an official release, hence the ea-b02 (early access). The official u2 is b05 which hasn't been uploaded to subversion yet either. It'll have a release jar name of fcs-b05-2?_jun_2007 IIRC. It's been a couple of weeks already, I'll bug em about it. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
X11R6 not tagged replaceable (was Re: XOrg-7.2 - libXcb)
Randy McMurchy wrote: Alexander E. Patrakov wrote these words on 07/03/07 21:01 CST: Randy McMurchy wrote: I install Xorg in /opt/X11R7.2. OK, my objection to $XORG_PREFIX is invalidated by this. Note that the *first* paragraph in the 'X Window System Components' 'Configuring The X Window System' says this (which could easily confuse folks): == If you've installed the X Window System in any prefix other than /usr, as the root user, add /usr/X11R6/lib to the /etc/ld.so.conf file and run ldconfig. Additionally, while still the root user, ensure /usr/X11R6/bin and /usr/X11R6/lib/pkgconfig are added to your PATH and PKG_CONFIG_PATH environment variables, respectively. Instructions for doing this are described in the section The Bash Shell Startup Files. === IMO, it's wrong. It references /usr/X11R6, when that directory path isn't previously mentioned or referenced. Why just indiscriminately add this path? If X isn't installed there (or appropriate symlinks added), why add it? The explanation should be more precise about guiding folks that don't use /usr for the installation path. That was my doing, and at the time it was deemed sufficient as both XFree86 and Xorg-6.8.2 (IIRC) referenced that path and it is in replaceable tags. I'm surprised that it's went unnoticed this long. I had thought that all other /usr/X11R6 paths had been replaced by PREFIX. But a quick grep shows that the gaim.xml, gnopernicus.xml, and profile.xml pages also have references to /usr/X11R6, not enclosed in replaceable tags. Also, the lesstiff page can probably use a rework to not include two sets of commands. I'll look into them tomorrow if somebody else doesn't get to them first. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: XOrg-7.2 - libXcb
Alexander E. Patrakov wrote: Randy McMurchy wrote: Only thing I can think of that I've seen in this thread is the decision to move the DRI directory to /usr instead of $XORG_PREFIX. If DRI stuff ships with Xorg, why would we want it somewhere other than $XORG_PREFIX? OK, $XORG_PREFIX/lib/dri. However, the question is whether we want to have $XORG_PREFIX at all. The book currently says that FHS permits only /usr and /opt/xorg. However, the blfs-support list mentions some packages (e.g., links and openexr) that assume that gcc -I/usr/X11R6/include will find X include files, and there might be problems installing proprietary drivers when X is in /opt. /usr is a matter of taste, and IMO is bad taste, but as I had mentioned before, the FHS leaves privilege separation to the admin's best judgment. Maybe I'm in the minority, but I'm perfectly capable of deviating if I choose to do so. Has anyone actually built a system with Xorg in /opt and with no deviations from the book in packages (at least Qt and links) that use it? If not, I would have to say that /usr is the only supportable prefix and that we should remove the $XORG_PREFIX variable, because it only creates an illusion of choice. I have previously installed Xorg in /opt/X11 with and without the /usr/X11R6 symlink. I am working on a system now without the symlink. In every package that I've installed so far, it's been fine (ordered list attached). I have used the --x-includes and the --x-libraries switches for Firefox and Thunderbird, and I really don't know if they were even required. The only other package I had supplied those flags with was ffmpeg and the --x* switches were sufficient to find xv. Again, I don't know if they were required as I'm just flying through a 2.18.2 Gnome build to test the assisted stuff with the latest JDK, but so far no probs to speak of that weren't already accounted for. While I admit $XORG_PREFIX is a little bit of a pain to maintain, I personally will never do a /usr build of Xorg. I simply _like_ it separate. If we were to ditch $XORG_PREFIX, I'd suggest /usr/X11R7 with a prominent note about the FHS violation. I'm sure that there are others besides Randy and myself that feel the same. Having said that, I still would like to see the /usr/X11R6 symlink in place so that we can rid ourselves of the seds in the book temporarily. As long as there is a mention of it being an FHS violation, I believe that is the best possible way to sidestep the BBLFS issues that might pop up during this 'transitional period'; a borrowed term taken directly from FHS-2.3. I would expect that the FHS would be extended sometime in the (near?) future as it specifically mentions the transition between X11R5 and X11R6 as justification for /usr/X11R6. It also might be nice if we could find some discussion about that instead of relying on speculation, I just don't know where to look yet. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Test Results for Xinerama and JDK6
M.Canales.es wrote: El Miércoles, 27 de Junio de 2007 09:01, DJ Lucas escribió: Also, anyone know if the pdf book is a go with the new FOP? Guess I could build and find out, or save if for tomorrow. With FOP-0.93 you must to use the stylesheets used in the new-xsl branch: svn://svn.linuxfromscratch.org/LFS/branches/new-xsl Also a small change is needed on the Makefile. Replace sed -i -e s/inherit/all/ blfs.fo by sed -i -e 's/span=inherit/span=all/' blfs.fo I'm using the pre-compiled binary from fop-0.93-bin-jdk1.4.tar.gz package, thus testing the source code compiled against current JDK will be very appreciated. Note: when rendering the BLFS PDF you will see some warnings about body and line overflows. They will be fixed when updating the books to use the new stylesheets. Cool. Thanks Manuel. Will take a stab at it this evening. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Test Results for Xinerama and JDK6
Dan Nicholson wrote: Thanks really goes to Alexander for digging into the test cases and solutions a bit further. Well then, thank you Alexander. So, if the source is OK with no fixes, then that's great. Funny that you should mention that...no fixes. I had forgotten about it until now, but I made a change in the awt project a long time ago so that mawt.gmk forces linking against the shared Xt, whereas the distribution (by default) is statically linked, dragging in Xt, SM, ICE...Of course the dependents should somehow include X11. In the binary distribution, that would be XFree86 libraries courtesy of RedHat AS 2.1. Wonder what version of X is installed in AS now with the latest and greatest service release? Hopefully that should shed some light on the why. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Test Results for Xinerama and JDK6
Bruce Dubbs wrote: DJ, Thanks for the work. I don't know enough to answer your question, but wanted to acknowledge your post. The lists have been *very* quiet lately. Well thanks for the reply. I've burried myself for the past week or so too, been sick. I figured getting going on the JDK and OpenOffice would be a great way to save the waste of time of illness. Both are done in the sandbox, but haven't been tested thoroughly...the 50 optional dependencies for OOo and pretty much all the packages in the book that depend on the JDK need to be built and rebuilt and tested. OOo is currently down to one patch to use the binary hsqldb, excluding the optional Seamonkey support which I haven't finished yet. I'll have to figure out how to hack that back in before I commit, but I suppose that most of the current libxmlsec patch will be reusable for that project. I'll put up a test copy in my home dir tomorrow in case anybody is bored and would like to assist with the testing. Also, anyone know if the pdf book is a go with the new FOP? Guess I could build and find out, or save if for tomorrow. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Test Results for Xinerama and JDK6
I don't know whether this is an xorg problem or a sun problem as I haven't reviewed it more than the simple test case that Dan had dug up. Anyway, the binary JDK failed, the source-built passed, or at least didn't display the assertion, I just realized I didn't check the return value...shouldn't matter. Below is the abridged version of the tests (minus ls/pwd to figure out where the heck I was, and missed tab completions) after I finally got Xinerama working with my POS Radeon. For the binary crowd, is it really OK to sed out Xinerama in the distributed one? Or, should I look at building a replacement libmawt? -- DJ Lucas [EMAIL PROTECTED] X11]# xdpyinfo name of display::0.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:7020 X.Org version: 7.2.0 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0xad, revert to PointerRoot number of extensions:30 BIG-REQUESTS DAMAGE DEC-XTRAP DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XAccessControlExtension XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XFree86-DGA XFree86-Misc XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number:0 number of screens:1not saying screen #0: print screen:no dimensions:2800x1050 pixels (640x240 millimeters) resolution:111x111 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x66 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0xd2001d KeyPressMask ButtonPressMask ButtonReleaseMask EnterWindowMask StructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals:8 default visual id: 0x23 visual: visual id:0x23 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x24 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x25 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x26 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x27 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x28 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x29 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x2a class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits [EMAIL PROTECTED] X11]# cd /home/dj [EMAIL PROTECTED] dj]# mkdir testcase [EMAIL PROTECTED] dj]# cd testcase [EMAIL PROTECTED] testcase]# echo $JAVA_HOME /opt/jdk/jdk [EMAIL PROTECTED] testcase]# echo $CLASSPATH .:/usr/share/junit-4.1/junit-4.1.jar:/usr/share/junit-4.1
Re: Non-standard X11 Paths
DJ Lucas wrote: we need to use '--mandir=$XORG_PREFIX/share/man' Whoops...n/m. We have already. I was looking at my $XORG_CONFIG from the host system of about a year ago. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Moz builds with non-standard Xorg location
DJ Lucas wrote: Guys, the line added to layout/build/Makefile.in in the Firefox instructions should be: EXTRA_DSO_LDOPTS += $(MOZ_XLIB_LDFLAGS) -lX11 -lXrender Whoops. That should have been $(XLDFLAGS) as Dan pointed out later in the thread. I use /opt/X11. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Non-standard X11 Paths
Dan Nicholson wrote: Currently there are a couple issues with packages finding X11 components when they are installed to non-standard locations. How many packages are we talking about? I'm not sure about the exact definition of non-standard, but it seems that widely accepted prefixes are /usr/X11R5, /usr/X11R6 and /usr/X11. /usr obviously works, too, since it's the standard toolchain search path. Here are the two problem areas I know about. As already mentioned in the book, /usr and /opt/whatever are currently the only acceptable prefixes for release 7, and I'm personally not so confident with /usr, but FHS leaves admin/user separation to the admin's taste. /usr/X11R6 was acceptable for release 6 and does have a specific mention in the current FHS (2.3). http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS9 1. Autotooled packages snip Randy had the idea that we should just make a symlink at /usr/X11R6 toprotect against these situations. I'd like to propose for Xorg that we do `ln -svnf $XORG_PREFIX /usr/X11' if your prefix isn't one of the standard locations I listed above. I'm not a fan of these kind of compatibility hacks, but I think it's gonna be necessary until pkg-config is used for X (a long ways off, if ever). There is convenient location for this here: I don't like them either, but unfortunately, something has got to give somewhere. As you mentioned, in an ideal world, everything that wants to take advantage of X11R7 uses pkg-config. That said, I can't agree with the symlinks unless you warn the user that they are violating the FHS, which is showing it's age anyway. http://www.linuxfromscratch.org/blfs/view/svn/x/x-setup.html For XFree86, I don't know what to do. We sort of say that you install to /usr/X11R6 or /usr and later make some symlinks like /usr/bin/X11 - /usr/X11R6/bin. I don't know the history behind those decisions. The history for those symlinks is in the FHS linked above. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Moz builds with non-standard Xorg location
Guys, the line added to layout/build/Makefile.in in the Firefox instructions should be: EXTRA_DSO_LDOPTS += $(MOZ_XLIB_LDFLAGS) -lX11 -lXrender My firefox build ends with this little bit without: make[4]: Entering directory `/sources/firefox-build/layout/build' rm -f libgklayout.so c++ -I/opt/X11/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O -fPIC -shared -Wl,-z,defs -Wl,-h,libgklayout.so -o libgklayout.so nsLayoutModule.o nsContentHTTPStartup.o nsContentDLF.o nsLayoutStatics.o -Wl,--whole-archive ../../dist/lib/libgkbase_s.a ../../dist/lib/libgkgeneric_s.a ../../dist/lib/libgkforms_s.a ../../dist/lib/libgkstyle_s.a ../../dist/lib/libgkprinting_s.a ../../dist/lib/libgktable_s.a ../../dist/lib/libgkxulbase_s.a ../../dist/lib/libgkconbase_s.a ../../dist/lib/libgkconcvs_s.a ../../dist/lib/libgkconevents_s.a ../../dist/lib/libgkconhtmlcon_s.a ../../dist/lib/libgkconhtmldoc_s.a ../../dist/lib/libgkconxmlcon_s.a ../../dist/lib/libgkconxmldoc_s.a ../../dist/lib/libgkconxbl_s.a ../../dist/lib/libgkconxulcon_s.a ../../dist/lib/libgkconxuldoc_s.a ../../dist/lib/libgkview_s.a ../../dist/lib/libjsdombase_s.a ../../dist/lib/libjsdomevents_s.a ../../dist/lib/libjsurl_s.a ../../dist/lib/libjsdomstorage_s.a ../../dist/lib/libgkxultree_s.a ../../dist/lib/libgkxulgrid_s.a ../../dist/lib/libgkconxultmpl_s.a ../../dist/lib/libinspector_s.a ../../dist/lib/libgkmathmlcon_s.a ../../dist/lib/libgkmathmlbase_s.a ../../dist/lib/libgkcontentxtf_s.a ../../dist/lib/libgkxtfbase_s.a ../../dist/lib/libgksvgbase_s.a ../../dist/lib/libgkconsvgdoc_s.a ../../dist/lib/libgkcontentsvg_s.a ../../dist/lib/libgksvgrenderercairo_s.a -Wl,--no-whole-archive -L../../dist/bin -L../../dist/lib -lgkgfx ../../dist/lib/libunicharutil_s.a -L../../dist/bin -lxpcom -lxpcom_core -L../../dist/bin -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -L../../dist/bin -lmozjs -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0-lcairo -Wl,--version-script -Wl,/sources/mozilla/build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic -lX11 -lXrender -ldl -lm /usr/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status make[4]: *** [libgklayout.so] Error 1 make[4]: Leaving directory `/sources/firefox-build/layout/build' make[3]: *** [libs] Error 2 make[3]: Leaving directory `/sources/firefox-build/layout' make[2]: *** [tier_9] Error 2 make[2]: Leaving directory `/sources/firefox-build' make[1]: *** [default] Error 2 make[1]: Leaving directory `/sources/firefox-build' make: *** [build] Error 2 I expect it would be the same with Thunderbird, but don't know about Seamonkey. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Organizing Xorg-7.2 external dependencies
Dan Nicholson wrote: DJ, how's the progress coming on jdk-6? Ummm, it's not. Sorry for the late reply. Things are a little hectic at home...well home has moved. But on the bright side, I'll have lots more time on my hands. Things should settle down for me around Tuesday or Thursday. I'll pass my patch set on to you soon as I find it again...gimme a few moments. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: MesaLib requires expat
Dan Nicholson wrote: On 5/29/07, DJ Lucas [EMAIL PROTECTED] wrote: I used the optional libxml2 with fontconfig, excluding the use of expat. MesaLib choked on me as a result. Ah, yes. I forgot about that one. In Mesa-6.5.2, expat is used in the intel dri drivers. I'll fix that up. -- Dan Also, I found in the xorg-server instructions '/full/path/toMesa-6.5.2'. And thank you very much for getting rid of that nasty sed! There is nothing wrong with the instructions as they are, but I skipped right over the word 'full' on the first run and gave a relative path. I don't know if it'd make a difference, but maybe 'absolute' instead of 'full' might draw a little bit more attention to it. Not a big deal, I messed up, but maybe it could save somebody else in the future. Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: MesaLib requires expat
DJ Lucas wrote: Dan Nicholson wrote: On 5/29/07, DJ Lucas [EMAIL PROTECTED] wrote: I used the optional libxml2 with fontconfig, excluding the use of expat. MesaLib choked on me as a result. Ah, yes. I forgot about that one. In Mesa-6.5.2, expat is used in the intel dri drivers. I'll fix that up. -- Dan Also, I found in the xorg-server instructions '/full/path/toMesa-6.5.2'. And thank you very much for getting rid of that nasty sed! There is nothing wrong with the instructions as they are, but I skipped right over the word 'full' on the first run and gave a relative path. I don't know if it'd make a difference, but maybe 'absolute' instead of 'full' might draw a little bit more attention to it. Not a big deal, I messed up, but maybe it could save somebody else in the future. Thanks. -- DJ Lucas And another...just a reminder for me unless you get to it first, this test needs to be fixed upstream and in the book: make[2]: Nothing to be done for `install-exec-am'. test -z /opt/X11/share/X11/xkb/compiled || mkdir -p -- /opt/X11/share/X11/xkb/compiled mkdir: cannot create directory `/opt/X11/share/X11/xkb/compiled': File exists make[2]: *** [install-dist_xkbcompiledDATA] Error 1 make[2]: Leaving directory `/usr/src/xc/xorg-server-1.2.0/xkb' make[1]: *** [install-am] Error 2 Oh great! What the heck did I destroy when I reacted to that directory without thinking? :-) grep of the log for xkb reveals libX11, xkbevd, and xkbutils. xorg-server wasn't logged. I'll reinstall those three and see if I can figure out where it came from. A grep for the term 'compiled' reveals nothing but a warning. So, possibly xkeyboard-config? I'm just here in user mode, but I should have logged all of it anyway. I'll smoke it and try to reproduce it a little later on less you get to it first. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: MesaLib requires expat
Dan Nicholson wrote: On 5/30/07, DJ Lucas [EMAIL PROTECTED] wrote: Also, I found in the xorg-server instructions '/full/path/toMesa-6.5.2'. And thank you very much for getting rid of that nasty sed! There is nothing wrong with the instructions as they are, but I skipped right over the word 'full' on the first run and gave a relative path. I don't know if it'd make a difference, but maybe 'absolute' instead of 'full' might draw a little bit more attention to it. Not a big deal, I messed up, but maybe it could save somebody else in the future. That's a good idea, thanks. It took me a long time to realize why I never needed the sed in my build. It never occurred to me that it was just because of the relative path even though it makes complete sense once you think about it. -- Dan I recognized it right away, and of course, it was followed by burying my head in my hands! Why didn't I catch that a few months ago?!?!?!?!? :-) I just saw the unused paths in the Makefile first I suppose. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: MesaLib requires expat
DJ Lucas wrote: DJ Lucas wrote: Dan Nicholson wrote: On 5/29/07, DJ Lucas [EMAIL PROTECTED] wrote: I used the optional libxml2 with fontconfig, excluding the use of expat. MesaLib choked on me as a result. Ah, yes. I forgot about that one. In Mesa-6.5.2, expat is used in the intel dri drivers. I'll fix that up. -- Dan Also, I found in the xorg-server instructions '/full/path/toMesa-6.5.2'. And thank you very much for getting rid of that nasty sed! There is nothing wrong with the instructions as they are, but I skipped right over the word 'full' on the first run and gave a relative path. I don't know if it'd make a difference, but maybe 'absolute' instead of 'full' might draw a little bit more attention to it. Not a big deal, I messed up, but maybe it could save somebody else in the future. Thanks. -- DJ Lucas And another...just a reminder for me unless you get to it first, this test needs to be fixed upstream and in the book: make[2]: Nothing to be done for `install-exec-am'. test -z /opt/X11/share/X11/xkb/compiled || mkdir -p -- /opt/X11/share/X11/xkb/compiled mkdir: cannot create directory `/opt/X11/share/X11/xkb/compiled': File exists make[2]: *** [install-dist_xkbcompiledDATA] Error 1 make[2]: Leaving directory `/usr/src/xc/xorg-server-1.2.0/xkb' make[1]: *** [install-am] Error 2 Oh great! What the heck did I destroy when I reacted to that directory without thinking? :-) grep of the log for xkb reveals libX11, xkbevd, and xkbutils. xorg-server wasn't logged. I'll reinstall those three and see if I can figure out where it came from. A grep for the term 'compiled' reveals nothing but a warning. So, possibly xkeyboard-config? I'm just here in user mode, but I should have logged all of it anyway. I'll smoke it and try to reproduce it a little later on less you get to it first. -- DJ Lucas Okay..sorry for spamming the list, but xkeyboard-config was the culprit. I didn't find it because this also was not logged. There is a problem however. xkeyboard-config creates this file $XORG_PREFIX/share/X11/xkb/compiled. It is a symlink to /var/lib/xkb, which does not exist. I moved the xorg-server version of this directory out of the way and re-installed xkeyboard-config to find that it pointed nowhere. So, only file there is now README.compiled which contains this: == The X server uses this directory to store the compiled version of the current keymap and/or any scratch keymaps used by clients. The X server or some other tool might destroy or replace the files in this directory, so it is not a safe place to store compiled keymaps for long periods of time. The default keymap for any server is usually stored in: Xnum-default.xkm where num is the display number of the server in question, which makes it possible for several servers *on the same host* to share the same directory. Unless the X server is modified, sharing this directory between servers on different hosts could cause problems. == This should be fixed in both places, assuming I can reproduce the error. Like I said, I'll smoke the whole thing and try to reproduce. FYI, I did a complete build (everything except the 2 deprecated items). -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
xkeyboard-config error [Was Re: MesaLib requires expat]
Dan Nicholson wrote: On 5/30/07, DJ Lucas [EMAIL PROTECTED] wrote: And another...just a reminder for me unless you get to it first, this test needs to be fixed upstream and in the book: make[2]: Nothing to be done for `install-exec-am'. test -z /opt/X11/share/X11/xkb/compiled || mkdir -p -- /opt/X11/share/X11/xkb/compiled mkdir: cannot create directory `/opt/X11/share/X11/xkb/compiled': File exists make[2]: *** [install-dist_xkbcompiledDATA] Error 1 make[2]: Leaving directory `/usr/src/xc/xorg-server-1.2.0/xkb' make[1]: *** [install-am] Error 2 Oh great! What the heck did I destroy when I reacted to that directory without thinking? :-) grep of the log for xkb reveals libX11, xkbevd, and xkbutils. xorg-server wasn't logged. I'll reinstall those three and see if I can figure out where it came from. A grep for the term 'compiled' reveals nothing but a warning. So, possibly xkeyboard-config? I'm just here in user mode, but I should have logged all of it anyway. I'll smoke it and try to reproduce it a little later on less you get to it first. Yeah, that's xkeyboard-config. I think some people posted an sed or such to the list a couple months ago to fix that. But actually, I can't figure what the problem is. Are you building with MAKEFLAGS set? There's often a race condition with mkdir and multiple jobs in make. It usually happens when a custom rule is added to an automaked Makefile. -- Dan No. Look at the error again from xorg-server's 'make install' . The issue there is that the test is needless in the Makefile. -z was passed a quoted non-zero argument, it'll never return false. Previously, however, xkeyboard-config installed a broken symlink to a non-existent directory which is why the command failed. If the symlink were correct, or if the directory existed previously, mkdir -p would have returned 0. [EMAIL PROTECTED] ~]# rmdir blah [EMAIL PROTECTED] ~]# mkdir blah2 [EMAIL PROTECTED] ~]# ln -s blah2 blah [EMAIL PROTECTED] ~]# mkdir -p blah [EMAIL PROTECTED] ~]# echo $? 0 [EMAIL PROTECTED] ~]# ls -l blah lrwxrwxrwx 1 root root 5 2007-05-30 16:52 blah - blah2 [EMAIL PROTECTED] ~]# rmdir blah rmdir: blah: Not a directory [EMAIL PROTECTED] ~]# rm blah [EMAIL PROTECTED] ~]# rmdir blah2 [EMAIL PROTECTED] ~]# -- DJ Lucas -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: MesaLib requires expat
Dan Nicholson wrote: Oh, now I see. I've been feeding --with-xkb-output=/var/lib/xkb to xorg-server, so it worked fine with that symlink. -- Dan Sweet..that gets it. Just add that switch to xorg-server and all should be well. I'll hopefully get to jump back in soon, sometime in the next couple of weeks and start contributing a little again. I'll also confirm your JDK results WRT XCB as soon as I get there. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
MesaLib requires expat
I used the optional libxml2 with fontconfig, excluding the use of expat. MesaLib choked on me as a result. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [BLFS Trac] #2319: JDK-1.5.0 Update 11
Updated BLFS to JDK-1.5.0.11 source and binary. Some notes: I listed the source download urls as it appears they are freely available without acknowloging a license agreement. Apparently, the license in the code is enough. You still must click on a link to agree to the binary download license. Cool, cool, cool. I was gonna update that because there are some JDK6 issues yet, see below. Added an instruction to delete the copy of the binary download. IIRC, the sed is not necessary anymore since we don't care which head program we use. The instructions that needed the modification have long since been removed (bypass the license agreement). I had completely forgotten the why and had missed it in last review. I do know for certain that it's not needed in the new version so they have already been removed from the pending JDK6u1 instructions. BTW, an update on that. JDK6 can't go in yet due to the JDBC4 changes WRT hsqldb (from OOo) and probably bdb too (haven't checked). Most upstream was building against b88 or b93 (can't recall), and Sun pulled the EOU features from derby (java db) shortly before release, so not much help yet from the package maintainers. Fop and Subversion build OK, as do a couple of other packages who's names slip my mind, but I haven't tested with any _real_ use other than the plugin and compiler. I did kick out a PDF BLFS book with FOP-93? and all looked well. Also, one of the test suites had to be run in a windowed environment, I think FOP but not sure. No time to check right now, but will get back soon. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
new package: ksh
Hey guys. A couple of quick questions. The new JDK build want's ksh, so it'll have to be added to BLFS. Problem is, it requires several other packages from ATT's open-ast project for the build of ksh only. I haven't looked into it too deeply (I'm seeking community approval for the alternative below), but I could add all of the packages to the book (ast-lib, nmake, pax, tw, sfio, INIT, and ksh). Debian provides a single source tarball (ksh_93r-orig.tar.gz) that includes INIT and ast-base (all of the above except INIT). Since the other ast open packages are used only for the build, does anyone have a problem with 1. using the Debian source tarball, and 2. calling the package ksh only since that is all that would be installed (or needed beyond build time)? That is unless anybody knows of an autotooled version of ksh that doesn't require ast-lib. Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: new package: ksh
Dan Nicholson wrote: I have no problem rolling them into one package. I'd kind of prefer that we pull all the downloads from upstream, but if it's too big of a PITA, then whatever. Looking at the fedora spec, it looks like they unpack all the tarballs and then just do `./bin/package read' then `./bin/package make'. Then they install the files by hand. http://cvs.fedora.redhat.com/viewcvs/devel/ksh/ksh.spec?view=markup That was exactly what I had planned using the debian package, I didn't realize it was that simple. If it's just two downloads, then that should be fine. Fedora link above shows three??? Also, I have not seen a need for a gcc patch. Another option would be to use pdksh. Apparently it's not as fully featured as ATT's ksh, but if all we're using it for is bootstrapping JDK, then maybe that's enough. http://web.cs.mun.ca/~michael/pdksh/ I think I'd prefer the original ATT ksh noting the read limitation in pdksh. I rarely use that syntax, prefering backtics or $(..), but I could see it causing problems for some. I'll give it a go anyway. JDK build is only 12 SBU now! Thanks for the links. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: new package: ksh
Dan Nicholson wrote: I actually started reading after I wrote that email. Let's try to use ATT's unless it's a huge pain. That pdksh is from 1999, and with the limitations... I wouldn't bother unless you're stuck. JDK in 12 SBU?! I may actually try to build it now. How did that happen? :-) JDK-6.0 (1.6.0_01). It was only 128 minutes on LFS-6.2 with 7:47 SBU time. It's now 93 minutes after pulling debug and fastdebug targets and the gcc29 plugin. I can put the patches in my homedir if you want to give it a go, but it's got a ways to go until it gets into the book. Fop and then OOo are next on my list. I'll probably stick with OOo-2.0.3 so JDK gets done as soon as possible, and then move on to OOo-2.1.x afterwards. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg-7.2 released
Dan Nicholson wrote: 7.2 is finally out. http://lists.freedesktop.org/archives/xorg-announce/2007-February/000254.html A few changes will need to be made, but for the most part it should be pretty straightforward. This also support Mesa-6.5.2 out of the box which has lots of improvements for the eye candy lovers. I also noticed this awesome page on their wiki that enumerates the module versions in each major release. This will make things easy for those that want to do piecemeal updates. http://wiki.x.org/wiki/ModuleVersionsInXorgReleases -- Dan I'm slowly crawling through the build. Updated to gcc-4.1.2, glibc-2.5 with update2 patch, libxml2, libxslt, freetype, fontconfig. Looks like we need to add 6 pages to the xorg section to account for libxcb. Also, I'm using the _official_ 7.2 versions (which required downgrading some of our current versions in the 7.1 build). I'm rolling through the rest of the libs now, but here are my current change notes: xorg-7.2 proto (leave alone except versions) xorg-7.2 utils (leave alone except versions) new package libpthread-stubs-0.1 (http://xcb.freedesktop.org/dist/) xtrans (moved from libs) libXau (moved from libs) libXdmcp (moved from libs) new package xcb-proto-1.0 (http://xcb.freedesktop.org/dist/) new package libxcb-1.0 (http://xcb.freedesktop.org/dist/ (dep libxslt, optional doxygen)) xorg-7.2 libs (minus xtrans,libXau, and libXdmcp change to updated versions) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Pciutils + zlib
Bruce Dubbs wrote: Well since update-pciids is a script, we could just modify that to unpack the pci.ids file. Another mark for the KISS method. :-) I like this best. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: FW: Some issues in BLFS
Randy McMurchy wrote:
-Original Message-
From: Äåì÷åíêîâ Àðòóð Ïåòðîâè÷ [mailto:[EMAIL PROTECTED]
Snip
I think it should be something like this (look at - xkb -):
mkdir $XORG_PREFIX/lib/X11/twm
ln -svt /etc/X11 \
$XORG_PREFIX/lib/X11/{twm,fs,lbxproxy,proxymngr} \
$XORG_PREFIX/lib/X11/{rstart,xdm,xinit,xserver,xsm} \
$XORG_PREFIX/share/X11/{app-defaults,xkb}
Is this same issue Ken reported in the 7.2 thread? This problem does or
does not affect 7.1?
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: testing dev list postings...
Bruce Dubbs wrote: DJ Lucas wrote: I can't see anything wrong, but I'm still having problems sending to LFS-Dev...checking the other lists I'm sub'd to as well. I know Bruce did something the other day to try to fix it and then I changed some things on my end as well that should have corrected it properly (I think). Bruce, if you (or any admin) get time, please review and see if you see anything funny as to why I can't post there now. I am not getting the not subscribed message as I was before. Subscribed address is [EMAIL PROTECTED] There were no messages from you being held from you. According to http://linuxfromscratch.org/pipermail/lfs-dev/2007-February/date.html#start you have not posted on lfs-dev this month. The only things I can think of is that the message never arrived or that the system somehow identified it as spam. I'm getting caught by SA? Weird, the BLFS ones are getting through but not LFS. I sent that last message to all 4 lists at the same time, only the 2 to BLFS lists got through. I'm sending this message now and tailing the mail log on quantum to see if there are any clues. No out of the ordinary records of '[EMAIL PROTECTED], mail.alwayson-line.net or lucasit.com in the spamd.log that I can see. -- DJ Lucas -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
testing dev list postings...
I can't see anything wrong, but I'm still having problems sending to LFS-Dev...checking the other lists I'm sub'd to as well. I know Bruce did something the other day to try to fix it and then I changed some things on my end as well that should have corrected it properly (I think). Bruce, if you (or any admin) get time, please review and see if you see anything funny as to why I can't post there now. I am not getting the not subscribed message as I was before. Subscribed address is [EMAIL PROTECTED] Thanks. -- DJ Lucas -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
test
test -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Dbus build error
Bruce Dubbs wrote: As I am working my way through the prerequisites for dbus on a clean LFS 6.2 system, I got an error building dbus: File /usr/lib/python2.4/site-packages/Pyrex/Compiler/ExprNodes.py, line 2936, in generate_result_code rhs = typecast(rhs, self.type, c_long_type) NameError: global name 'c_long_type' is not defined I comes from: running echo '#include dbus_h_wrapper.h '|cpp -I./.. -I.pyrexc ./dbus_bindings.pyx -I. -o ./dbus_bindings.c Traceback (most recent call last): I removed the --disable-python switch from configure since I do have Python and the latest Pyrex installed. I'm not going to stop now, but I'll go again with -disable-python, but has anyone seen this before? -- Bruce I'm having the same problem...been looking for the easy way out all night, but I haven't been able to find any relevant errors related to c_long_type and Pyrex. Dropped back to 0.9.4.1 with no change. I think I remember seeing some people working with dbus/hal recently when I was digging through my disaster of backlogged emails. Need to figure out what has changed since then. -- DJ Lucas -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: r6458 - in trunk: BOOK/introduction/welcome BOOK/x/installing auxfiles/xorg
[EMAIL PROTECTED] wrote: Author: dnicholson Date: 2007-01-23 12:00:33 -0700 (Tue, 23 Jan 2007) New Revision: 6458 Modified: trunk/BOOK/x/installing/x7app.xml -c94ea103e27e370e4e5030e50c5d5d69 xsetpointer-1.0.0.tar.bz2 +9e5bcbeda4aaf02bfa095e41d30baee4 xsetpointer-1.0.1.tar.bz2 Dan, this one is wanting xinputproto-1.4, currently at 1.3.2. I'm not entirely sure what has changed, so I've backed off to xsetpointer-1.0.0 locally to avoid rebuilding the deps. I'll dig through the buildlog and rebuild the dependent packages when I complete the scripted build. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
fontconfig build error
Hello. Anybody built fontconfig with docbook utils and not
SGMLSpm/JadeTeX? Seems the --disable-docs switch isn't doing what it
is supposed to do...
make[2]: Entering directory `/sources/fontconfig-2.3.2/fc-cache'
rm -f fc-cache.1
docbook2man ../fc-cache/fc-cache.sgml
Using catalogs: /etc/sgml/catalog
Using stylesheet:
/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#print
Working on: /sources/fontconfig-2.3.2/fc-cache/../fc-cache/fc-cache.sgml
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/htmltblx.mod:102:9:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/htmltblx.mod:110:9:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/htmltblx.mod:118:9:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/htmltblx.mod:125:9:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/htmltblx.mod:141:9:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/calstblx.dtd:100:15:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/calstblx.dtd:113:15:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/calstblx.dtd:145:15:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/calstblx.dtd:151:15:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/calstblx.dtd:158:15:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/calstblx.dtd:166:15:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/calstblx.dtd:183:15:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/calstblx.dtd:201:15:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/dbpoolx.mod:3762:24:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
nsgmls:/usr/share/sgml/docbook/sgml-dtd-4.4/dbpoolx.mod:3806:43:E:
character : invalid: only CDATA, ENTITIES, ENTITY, ID,
IDREF, IDREFS, NAME, NAMES, NMTOKEN, NMTOKENS, NOTATION,
NUMBER, NUMBERS, NUTOKEN, NUTOKENS and parameter separators allowed
/usr/share/sgml/docbook/utils-0.6.14/backends/man: line 11: sgmlspl:
command not found
make[2]: *** [fc-cache.1] Error 8
make[2]: Leaving directory `/sources/fontconfig-2.3.2/fc-cache'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/sources/fontconfig-2.3.2'
make: *** [all] Error 2
[EMAIL PROTECTED]:/sources/fontconfig-2.3.2 #
The QnD solution is passing HASDOCBOOK=no to configure. I'll throw up a
configure{,.in} patch in a day or so to bypass the test, actually I'll
first check upstream when I get the time, but just in case somebody else
runs across this, that'll work.
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: ALSA-*-1.0.13
Dan Nicholson wrote: In #2125, it was suggested to add, GROUP=audio for the sound devices. However, both udev-config-6.2 for LFS and udev-cross-lfs-1.0.3 set this GROUP for the sound devices already. So, I don't think we need that part anymore. CLFS also includes the `alsactl' command, but LFS needs it. Yeah, your own reply to the original bug has exactly what is needed. Even the forced group ownership is questionable and looks to be covered by the current LFS rules, excluding any odd device names that might show up in the future (I'm not aware of any). Really, all that is needed is the restore. For #2186, I think I'll leave it open until Ken comments on it. I'm pretty sure #2125 will fix it, but I want to make sure. Agreed. Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
OpenSSL and zlib
Hi guys. I'm using OpenSSL0.9.8d and I notice that we no longer link in zlib. Is there a reason for this change? A quick search of the archives revealed nothing. I do recall a while back, we had statically linked zlib, however, I thought that this was not a problem anymore. Anyway, looks like 'zlib-dynamic' is needed. Also, I believe we are missing a few optional deps (krb5 flavor, gmp, and camellia are output by config), but haven't verified more than just that output. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: some nit-picky stuff
Allard Welter wrote: Some things I came across blfs'ing ... Snip ooo doesn't compile with --with-cairo flag (does anyone know if ooo can utilise parallel compile?) I only remember vaguely something was up with OOo and system installed Cairo. Actually, I think it required an older version. I had thought I'd submitted a note before my recent disappearance (with the DB note), but obviously I did not. I haven't had much time at all recently, for LFS or otherwise, but hope to have some _me_ time very soon. jdk-1_5_0_08-linux-i586.bin works fine to compile jdk-src. Sweet. I didn't get a release message. I'll try to get to the update this weekend, but if I run into problems, _I_ can't do it until after the 1st, and that assuming that we have not entered package freeze by that time. Other editors are welcome to do it, but I don't think anybody else really likes messing with either package (OOo and JDK). Need more than just the two TTF in /usr/share/font as these don't include symbols. Try browsing maths page in wiki for instance. For the moment, regards, Allard. Thanks for the feedback. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [Fwd: Re: Luit status]
Alexander E. Patrakov wrote: Here is today's conversation between me and Thomas Dickey (the maintainer of xterm). Possibly it has some consequences for BLFS. Without looking too long, I think this is probably much for the better! It's why he still has xterm after 20? years (I don't recall how long and didn't take time to find it on his site). It might mean an additional note/link in BLFS and a change of luit's location, but should not be viewed as a bad thing (consequence usually implies 'bad' to me). -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0-07 nitpick
Simon Scheiwiller wrote:
Hi there
That part:
If your X Window System is installed in any prefix other than /usr/X11R6,
adjust as necessary and execute the following command:
find . -type f -exec sed -i 's@/usr/X11R6@/usr@g' {} \;
is quite confusing. Maybe it should rather be: If your X Window System is
installed in any prefix other than /usr, ...
Simon
I'm not sure I follow. The expected prefix is /usr/X11R6. If that is
not the prefix applied to your installation of the X Window System, then
you will need to execute the commands so that the build knows where to
find the X Window System. Although, the '/usr' needs to be changed to
'PREFIX' so the changed portion is more obvious and consistent with
the rest of the book.
If I've misunderstood the part that you find unclear, would you mind
suggesting a better way to state the entire message? I can get it in
the book in a matter of minutes so that others won't have trouble with
it in the future.
Thanks.
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: JDK-1.5.0-07 nitpick
Simon Scheiwiller wrote: Yes, that would be clear ;-) Simon Cool. Thanks for taking the time to explain. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
XFree86 libXt, libSM, libICE
Anyone have XFree86 handy? I need to see if it builds the libs above shared, static, or both. If nobody replies, I'll just go ahead and build it tomorrow as I've been meaning to anyway. The reason I ask, IIRC I should now combine the xorg patch with the motif patch for JDK source build. It's required for XFree86 now I believe. FYI, other than this problem, so far it looks to be pretty strait update using the current patches, or at least so far as none of the changes affect the patched code and it's building now. Thanks in advance. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: haldaemon bootscript
Randy McMurchy wrote: Thanks for the catch. I managed to update the script on my test box, but I never even once thought about the bootscript tarball. I fixed it just now. BTW, --daemon=yes is the default so only --use-syslog is needed. Cool. Updated locally and works AFAICT. I didn't see this in the man page. Anyway, I'm back to a full gnome desktop. Now I'm off to figure out the automounting intricacies of hal/dbus/gnome-mount etc. that I've never bothered to try and understand. It doesn't just work out of the box for me. I've probably already shot myself in the foot. I'll continue this on blfs-support I'm sure. :-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
default config for hal/gvm without pam_console/pam_foreground (Was: haldaemon bootscript)
Dan Nicholson wrote: This is a bit off the cuff, but here goes. 1. HAL needs to be told about a group or user that can invoke methods besides root and at_console. Look at /etc/dbus-1/system.d/hal.conf. There should be sufficient comments there to figure out how to add a group policy with whatever group you want. 2. gnome-volume-manager needs to be configured with --disable-multiuser. Otherwise it goes looking for the pam_console droppings in /var/run/console/`uid -un`. 3. Anything you want auto-mounted can't have an entry in /etc/fstab. HAL will ignore these for the purpose of auto-mounting. Gravy! It just works! Remove lines from /etc/fstab for usbstick, cdrom and dvdrom. Recompile gvm with the '--without-multiuser' switch. Without looking too hard, something similar might be good for the default configuration without pam_console or pam_foreground (need to review security precautions): groupadd -g 61 halusers cat /etc/dbus-1/system.d/halusers.conf EOF !DOCTYPE busconfig PUBLIC -//freedesktop//DTD D-BUS Bus Configuration 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd; busconfig !-- Allow anyone in halusers group (gid 61) to utilize HAL -- policy group=61 allow send_interface=org.freedesktop.Hal.Device.SystemPowerManagement/ allow send_interface=org.freedesktop.Hal.Device.LaptopPanel/ allow send_interface=org.freedesktop.Hal.Device.Volume/ allow send_interface=org.freedesktop.Hal.Device.Volume.Crypto/ /policy /busconfig EOF /etc/rc.d/init.d/haldaemon restart /etc/rc.d/init.d/dbus restart Add any users to the halusers group that should use dbus/hal/gvm/automount, and then logout and log back in to test. Everything should just work magically. Now..any pointers on how to tweak the mountpoints? Maybe use volname, volname-#, and then device name as a final fallback. Maybe just device name always. I'll have to play with it a bit to see what I like, but I have no idea where to start on that. Right now, everything comes up removable volume for my usb keys, audio cd for audio cds, and volume name for dvds. :-/ -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: default config for hal/gvm without pam_console/pam_foreground (Was: haldaemon bootscript)
DJ Lucas wrote: !-- Allow anyone in halusers group (gid 61) to utilize HAL -- policy group=61 allow send_interface=org.freedesktop.Hal.Device.SystemPowerManagement/ allow send_interface=org.freedesktop.Hal.Device.LaptopPanel/ allow send_interface=org.freedesktop.Hal.Device.Volume/ allow send_interface=org.freedesktop.Hal.Device.Volume.Crypto/ /policy Oops...didn't mean to paste the whole dang block. All that is needed is Device.Volume abovenot sure about Device.Volume.CryptoI don't know a thing about encryption devices (I'm assuming). -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Gaim problem (and workaround)
Well, I had started to send this to support, but then tried to dig in a little deeper. I only use msn and yahoo, but for both as soon as I send a message, gaim exits. I started gaim from the console with the -d option, and here is the last part of the output: util: Writing file prefs.xml to directory /home/dj/.gaim conversation: typed... Creating link /home/dj/.kde/socket-name1. can't create mcop directory dns[2765]: Oops, father has gone, wait for me, wait...! [EMAIL PROTECTED] ~]# dns[2763]: Oops, father has gone, wait for me, wait...! Seems a bit interesting being that I don't have 'kde' installed, but QT and Arts. Someone made a bad assumption somewhere. Doesn't look like an option to disable qt/kde in configure. Anyway, _a_ working solution is to create the directory before running gaim...now why this is required I'm not certain. 'mkdir -p $HOME/.kde/socket-$(hostname)' should do the trick for the book or wiki. Getting to the bottom of the problem, libao was linked against arts. This _might_ explain a little, however, without kdelibs or kdebase, I wouldn't expect to see any software looking for ~/.kde. This is an error someplace! 'Should it be using ~/.qt or ~/.arts?' and 'How _was_ the directory supposed to be created?' are the remaining questions that need to go strait to gaim...I think (libao?). I just wanted my little analysis to be verified and see if anyone else has seen this before I go bugging upstream maintainers. I think I'll remove the directory and install kdelibs next (and step my way up if needs be). I'll need it and base anyway for k3b. Looking at it now, I have a pretty good idea that this will turn out to be an arts error. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: dhcpcd bootscript not stopping the service
DJ Lucas wrote: 'ps -a | grep dhcpcd' Whoopse 'ps -e | grep dhcpcd' -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: dhcpcd bootscript not stopping the service
Chris Staub wrote: Hmmm, maybe it's not a problem with the dhcpcd service script...looks like it's been unchanged for months. Perhaps the issue is with the latest version of dhcpcd. I am using dhcpcd 2.0.5, with BLFS instructions. I'm currently using different bootscripts, but the logic is unchanged (only the print to screen statements) and it works fine here. I'm sure you've already checked, but can you double check (again) the service config files or maybe copy them from a previous installation? [EMAIL PROTECTED] dj]# dhcpcd --version DHCP Client Daemon v.2.0.5 Copyright (C) 1996 - 1997 Yoichi Hariguchi [EMAIL PROTECTED] Copyright (C) January, 1998 Sergei Viznyuk [EMAIL PROTECTED] -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gaim problem (and workaround)
Bruce Dubbs wrote: Do you know what package is Creating link /home/dj/.kde/socket-name1 ? I strongly suspect aRts which *is* tied pretty tightly to KDE. Installing aRts without kdelibs and kdebase is not common. No, but if aRts can (or is supposed to be able to) be used without KDE, then this is a bug. OTOH, if it's not intended to be used standalone, then we should add a note about the runtime dep...if that is the cause. Also, I wonder what else might be broken without (again assuming that is the problem). I didn't have the time to install kde parts yet, but am starting on them now. Coincidently, the .kde directory is created, just not the temp dir or 'link' as was in the error output. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: dhcpcd bootscript not stopping the service
Chris Staub wrote:
I compared it with the config file from a perfectly working system. As
far as I can tell, the only difference is the version of dhcpcd used.
Hmm. Nobody else has complained. Any editors besides me using it? Can
you test please and get back? I'm not seeing a problem, but I've been
modifying bootscripts to fit the LSB-3.1, so they are not identical to
stock {,B}LFS. Also, Chris, what are the parameters for your DHCP
scope? Did you change servers recently or anything, or is this an
otherwise unchanged environment. Do you mind posting the config file?
[EMAIL PROTECTED] kdebase-3.5.2]# cat
/etc/sysconfig/network-devices/ifconfig.realtek/dhcpcd
ONBOOT=yes
SERVICE=dhcpcd
DHCP_START=-Y -N
DHCP_STOP=-k
# Set PRINTIP=yes to have the script print
# the DHCP assigned IP address
PRINTIP=yes
# Set PRINTALL=yes to print the DHCP assigned values for
# IP, SM, DG, and 1st NS. This requires PRINTIP=yes.
PRINTALL=yes
[EMAIL PROTECTED] kdebase-3.5.2]#
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: Gaim problem (and workaround)
DJ Lucas wrote: DJ Lucas wrote: Also, I wonder what else might be broken without (again assuming that is the problem). I didn't have the time to install kde parts yet, but am starting on them now. Coincidently, the .kde directory is created, just not the temp dir or 'link' as was in the error output. Well, installing kde did not fix the problem. I haven't yet executed startkde. But I'd like to add the workaround to the book. Anyone have any objections to a note in the book? -- DJ Lucas WhoopsI meant to go back and revise that before I sent it. startkde did fix the problem (created the directory). Question stands, anybody object to a note in the book? The cause of the issue is using libao linked against aRts without running startkde. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gaim problem (and workaround)
Randy McMurchy wrote: I've found that it's better to say: I'd like to do [insert workaround] because [messed up stuff], and the affect on the book is [describe]. Anyone see any issues with this? This way you can get meaningful responses. Yes I see I've lost the meat of the thread. If you have installaled libao (required for sound in gaim) and have libao linked against aRts, without having run startkde, gaim will exit when you attempt to send messages. Think gnome-centric environment. The cause of the problem is that aRts expects to see a ~/.kde/socket-$(hostname) directory. Normally, this is handled somewhere in kdeinit. You can get around the problem by creating the directory manually with 'mkdir -p ~/.kde/socket-$(hostname)'. I'd like to add that to a note in the book. I'm assuming that most who install it must not be installing aRts, or have installed kde. I hope that is a little better description. :-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg-server compilation error: agpgart.h
Matthew Burgess wrote: Dan Nicholson wrote: Unfortunately, most people aren't going to rebuild glibc on a live system, so this is gonna need to be in for a while. I don't see why - BLFS svn assumes an LFS svn host, no? In which case I'd drop the patch and if anyone says xorg-server doesn't build then tell them to build on a sane host :-) That's why it was removed a second time. I figured enough time had passed. This note cannot carry into the release. If it goes back in, it should be removed once LFS goes to rc. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Corrections to Xorg7 dependencies
Chris Staub wrote: 1. Xorg-server says it depends on Xorg fonts and Xorg libs. However, Xorg fonts already needs Apps, which needs Libs, so the Libs dependency in server is redundant. 2. Same goes for the pkg-config dependency in xterm. It needs the Xorg-server, which needs Fonts, which need Apps, which need Libs, which need pkg-config. Actually, I'm not sure it even needs the server (except, obviously, to be able to start the program). Fixed. Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg7 dependencies
Randy McMurchy wrote: If you installed the MesaGlut package during the installation of MesaLibs in an Xorg-7.0 environment, you can disregard the Glut dependency, as it is already satisfied. And then comment out the mesalib dependency. If someone can come up with a better solution, please jump right in. Similar to what I had in mind... 'libglut (not needed if Xorg7 includes the optional MesaGLUT library).' Your addition is better. It's more descriptive for a potentially confusing situation. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: X Packages
Randy McMurchy wrote: Peter B. Steiger wrote these words in BLFS-Support on 05/23/06 20:06 CST: [Peter, if you're reading this, I'm using your message as an example, and nothing is intended by your example, other than to make a point about a different thread earlier today] Now, this is not a fair example! He's working ahead! :-) Not that I'm doubting the ammount of xorg questions are high, just being silly. There are many other examples to choose from. In my opinion, we cannot solely count on Xorg7.x until there isn't a support issue every day. The instructions are not yet where they need to be to support Xorg7 as the only X package. I'm working on that, but agree with your opinion above. Right now, nothing should be done with xorg-6.9. As I asked earlier, and is the most pressing questions, what are we going to do with Xorg6.9 when 7.1 comes out which has a different code base? I'm even thinking that if XFree must go because nobody will offer to install it as their primary X package, and continue to monitor issues with it (which is a perfectly legitimate reason to let it go), that keeping Xorg6.9 in the book is something we must consider. Personally, I'm not prepared to let either one go just yet. Xorg-7.1 is a new release, and will not be the same as the previously planned 6.9.x maintenance release. I don't know anything about the timeframe for the maintenance releases...anyone heard anything on them yet? -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg wget generation script
Matthew Burgess wrote: Hi folks, While I know DJ is hard at work doing the Xorg 7.1 update I thought I'd share a script that I just wrote to automatically generate the wget files for downloading all those packages. It's written in Python (the only scripting language I know, other than shell scripting which would have been painful to write this in, IMO). Also note that http://www.linuxfromscratch.org/blfs/view/svn/x/xorg7.html says you may need to download up to 280 files. There are indeed 280 files in the distribution but there are .tar.gz and .tar.bz2 versions of each package. Oh, and there's a separate copy of all modules in the 'everything/' folder on the FTP site too, just for good measure!. So, I'd suggest that the figure be changed to 140. Actually, there are 293 packages that can be downloaded in total (or 570 something if you look at available tar.gz files). The 7.1 release folders only contain the updated packages just to make things more difficult, but thanks for the script...it can be adapted to account for the other packages from the previous release. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg7 dependencies
Randy McMurchy wrote: Randy McMurchy wrote these words on 05/22/06 14:41 CST: No. A Glut library is only installed if you install FreeGlut or the new stand-alone Mesa package. At least that is my understanding and observation of logs. Can anyone confirm that the GLUT libraries are installed with the stand-alone Mesa package? If you choose to install them. The reason I ask is because the Xorg7 and Xorg6.9 packages are supposed to build the same code, yet it is being touted that the Mesa package (stand-alone, required by Xorg7.0) provides Glut libraries, yet 6.9 doesn't. No 6.9 does not include the glut libs or possibility to build them. This would seem to disprove the theory that Xorg7 and Xorg6.9 provide the same libraries, have identical code base and the only difference is the build method. MesaLib is the core package. MesaDemos is a recommened additional download, and MesaGLUT is an optional additional download. Previous versions of xfree86 and xorg (including 6.9) did not build GLUT, but it's always been available in the Mesa distribution. Without the optional download, xorg-6.9 and xorg-7.0 are the same. That is fixing to change within the next couple of days. The three packages weren't split until Mesa 6.x IIRC. I looked up the exact version back when the instructions first went in. I won't recommend it as it was never built before and only some need a libglut, plus there is a choice of which to use now. If you think a note is needed for Mesa to show the availibility of freeglut, just let me know and I'll get it in the 7.1 update. Hope that helps clarify it a bit. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg7 dependencies
Randy McMurchy wrote: The text in the book that says the code base is the same needs to be changed, unless BLFS is content on fibbing. :-) Okay...I'll remove it tomorrow or the next day. ;-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg7 dependencies
M.Canales.es wrote: There is few things with the Xorg7 dependencies listed in the book that I have not very clear. - Xorg Libraries isn't listed as a dependency for any other Xorg-* section, only for Mesa. Is true that any other Xorg7 package requires Xorg Libraries? Mesa was a required dep of apps and server not long ago. The libs need to be in place for apps and server for certain. - Mesa is a recommended dependency for Xorg Applications and optional for Xorg Server. I think that if the user want to use a third-part video driver like Nvidia, Mesa isn't needed at all. If that is true, maybe a note should be added. No, you'll still have to have a GL lib (and headers) in place to build glx, xprint, and drm in the xorg-server. I don't know about NVidia binary drivers and includes, but IIRC they do _replace_ one of the gl libs. Can somebody with the binary NV drivers, confirm what is actually installed please? ATI too (if necessary, I don't use the binaries). - Mesa is listed also as an dependency for libtiff, but libtiif have also an optional dependency on X, that already includes Mesa. Isn't that redundant? I guess that you've seen further in the thread by nowit needs an explanation. Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: LibTIFF [was: Re: Xorg7 dependencies]
Randy McMurchy wrote: DJ Lucas wrote these words on 05/22/06 20:36 CST: If you think a note is needed for Mesa to show the availibility of freeglut, just let me know and I'll get it in the 7.1 update. Hope that helps clarify it a bit. Actually, it doesn't clarify it a bit for me, as Xorg-7 does one thing and all other X installations do another thing. This must be identified, especially when there is text in BLFS that claims the installations are the same, only a build method separates them. They are the same _if_ built by the book (which includes all xorg packages and the recommended MesaDemos package). You can _optionally_ add a libglut. We will probably disagree compltely on that vantage point. :-) Fortunately, the difference is not worth discussing now, as the note *must* be removed with the update to Xorg-7.1 since they are not the same code anymore. OT: I'm working on the 7.1 update now. I've built all the packages except for the new server release (I used a CVS checkout last night of the 1.1 branch to complete the initial prep). I won't commit until I rebuild completely, which I probably will not finish tonight. At this point, and what the subject was all about, is that the LibTIFF instructions are wrong. I stand by that assertion. Oh, I don't disagree with that at all. I just tried to provide some background to the questions you had asked. Archaic had already answered the question. I'll see if I can add info at both locations when I update (probably tomorrow evening now). -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: libpng-1.2.10 pc file
DJ Lucas wrote: Anyway, this works since we have to modify it, and is consistant with libpng-config's result, but would the patch be the better option? Forgot to add: [EMAIL PROTECTED] ~]# ldd /media/lfs/usr/lib/libpng12.so.0.1.2.10 linux-gate.so.1 = (0xe000) libc.so.6 = /lib/libc.so.6 (0xb7df2000) /lib/ld-linux.so.2 (0x8000) [EMAIL PROTECTED] ~]# ldd /usr/lib/libpng12.so.0.1.2.8 linux-gate.so.1 = (0xe000) libz.so.1 = /lib/libz.so.1 (0xb7f59000) libm.so.6 = /lib/libm.so.6 (0xb7f34000) libc.so.6 = /lib/libc.so.6 (0xb7e13000) /lib/ld-linux.so.2 (0x8000) Just seems strange that the developers haven't fixed this, 5 revisions later. I think the libpng-config file (and pc file) is the correct place to handle this, at least as the developer had intended it to be. I'm not sure why they do it that way. Probably should ask the developers. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Two issues: udev and alsa-utils
Archaic wrote: On Sun, May 21, 2006 at 01:25:03AM -0500, DJ Lucas wrote: Looks like the devices are handled in 25-lfs.rules now...including ownership by the audio group. Shouldn't that become simply: That is a left over that will be removed after 6.2. After 6.2? It can be corrected in BLFS now if you wanted to get it to the default root:root in LFS...or is this dependent on the group being removed in LFS or something else? -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Two issues: udev and alsa-utils
Tony Kuneck wrote: Hi all, _First_ issue: In the current dev book svn-20060519, there is this section: Snip currently broken alsa rules Looks like the devices are handled in 25-lfs.rules now...including ownership by the audio group. Shouldn't that become simply: cat /etc/udev/rules.d/15-alsa.rules EOF # ALSA Devices # When a sound device is detected, restore the volume settings KERNEL==controlC[0-9]*, ACTION==add, RUN+=/usr/sbin/alsactl restore %n EOF chmod 644 /etc/udev/rules.d/15-alsa.rules -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: r6115 - in trunk/BOOK: introduction/welcome x/installing
Tushar Teredesai wrote: On 5/21/06, DJ Lucas [EMAIL PROTECTED] wrote: Wrong place. Dep info for individual packages is to be covered in the wiki. BLFS assumes all packages are installed. In addition to the fonts section, the lib section also mentions the which libs need to be installed first to meet the sub-section dependencies. Yes, I see that. IMO, both of those should be removed as well, even though it was I who put them there, they are leftover from the initial draft before the wget lists were ordered. Adding to the mix, utils also does this, but because of different instructions for config-files and imake. Lets move this to dev for discussion. I don't really see a problem with it, other than I viewed it as a deviation from what we had as it explicitly mentions a dependent package, and now I'm not sure. Lets involve the rest of the group and see how to handle these. IMO, we should remove all three and add to the note in the introduction The order of the wget lists should be followed to account for all dependencies. Xorg-7.1 will be out soon (Monday), and I'll go ahead and make all the requested changes when that update occurs. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: libdrm autoreconf breaks shared library
Dan Nicholson wrote: Yes, I should be clear that in my earlier post, I actually used autoreconf -fi. I'm not sure the --install is needed, but --force definitely is to get libtoolize to run. It's probably a good idea to use -i since any missing files would be added with versions from our newer autoconf/automake. DJ, OK to commit the change s/autoreconf/autoreconf -ifv/ ? Yes. Please do. Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: libdrm autoreconf breaks shared library
Dan Nicholson wrote: On 5/20/06, DJ Lucas [EMAIL PROTECTED] wrote: Yes. Please do. One more thing. The http link is broken right now. Everything has been removed from here: http://xorg.freedesktop.org/releases/X11R7.0/src/extras/ How about using the actual site at dri.freedesktop.org: http://dri.freedesktop.org/libdrm/ Yes, it will be best in the future. Thanks for getting these done. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Correction Xorg-7.1 release date.
Dan Nicholson wrote: On 5/20/06, DJ Lucas [EMAIL PROTECTED] wrote: And some better: http://lists.freedesktop.org/archives/xorg/2006-May/015476.html Have you seen a tarball list yet? No, but take the RC2 list, and substitute the announcements from the threaded view of 2006-May above, and you should have a pretty good idea of what to expect. I'm assuming xorg-server-1.0.99.903 will become 1.1.0? once the 'DriverRec ABI fix' mentioned in the previous thread goes in. That does leave a question however. Should we return to the 'badged' tarballs? This _will_ eliminate any confusion as to which versions to use, but I worry that if a single component needs updating, it won't be covered by the wget scripts. I think I already answered my own question there, but I'll leave it here JIC. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Correction Xorg-7.1 release date.
DJ Lucas wrote: Should we return to the 'badged' tarballs? This _will_ eliminate any confusion as to which versions to use, but I worry that if a single component needs updating, it won't be covered by the wget scripts. Now I know this is bad. There may be several small fixes to several drivers in the coming week if the individual maintainers follow instructions. If I read that correctly, these will be safe to use with xorg-7.1 as they are now, and probably desired by the users for their individual cards. So a solid no on the badged tarballs. :-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: libdrm autoreconf breaks shared library
Dan Nicholson wrote: I'm gonna wait a while longer to see if anyone (DJ) responds. Can anyone confirm that the library builds without autoreconf? I checked the list of symbols with nm in both cases and they were the same. I think this is just broken autotools action. Strange, I hadn't noticed this before now. The reason the autoreconf is there is that the configure script, as shipped, is broken: ./configure: line 19219: test: too many arguments It needs to be regenerated...unfortuantely, the tarball was created with older autotools as you suspected. Now to figure out why it's stripping the so off, or maybe just fix the test in configure manually. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: libdrm autoreconf breaks shared library
Dan Nicholson wrote:
On 5/19/06, DJ Lucas [EMAIL PROTECTED] wrote:
./configure: line 19219: test: too many arguments
It needs to be regenerated...unfortuantely, the tarball was created with
older autotools as you suspected. Now to figure out why it's stripping
the so off, or maybe just fix the test in configure manually.
Maybe we can just run autoconf rather than autoreconf since that also
calls libtoolize. I'll try it out. Can you see if the package builds
with the broken configure for you?
Yes it does, and the shared libs are named correctly.
Hmm. This is weird. The part of configure where it's broken is that
part where there's an sed to change the file extension on shared
libraries in the libtool script.
if test -z `grep -e 'shared_ext.*shrext' $ofile`; then
# Make sure $shared_ext gets set to $shrext
if sed -e 's/shared_ext/shrext/g' $ofile ${ofile}T; then
mv ${ofile}T $ofile
chmod +x $ofile
else
rm -f ${ofile}T
{ { echo $as_me:$LINENO: error: unable to update shared_ext. 5
echo $as_me: error: unable to update shared_ext. 2;}
{ (exit 1); exit 1; }; }
fi
fi
The first line is 19219. This is strange, and I don't know enough
about autotools.
Hey, the new version of libdrm has ltmain.sh created by
libtool-1.5.22. Yay! aclocal is automake-1.9.6, and configure.ac
looks like autoconf-2.5.7. So, the good news is that this probably
won't be a problem after this release.
I don't know if 2.0.1 is compatible with current Xorg or intended for
7.1. Browsing the diff, I see a couple of changes that _look_ to me
possibly cause compatibility probs. One is specific to alpha arch so no
biggie for the x86 target of BLFS, and the SIGIO mentioned in the
changelog I don't know where (if) it's used currently. Rest looks like
code cleanups except for the hash fix. Lets hope that xorg stays close
to it's schedule for 7.1. They are a week behind on the initial target
for the RC3 release...today was the scheduled release date for 7.1, but
RC2 was a week or so late too IIRC.
And now for the fix: 'libtoolize --force' and then build as directed.
:-) Now, comparing the resulting libs...'readelf -s'. The Values are
different, but contain identical symbols.
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: location of xorg-server's lnx_agp.c wrong
Archaic wrote: Book says: programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c When it should say: hw/xfree86/os-support/linux/lnx_agp.c I'm guessing the former was a CnP from the monolithic page? Yep, and now fixed, along with the two test suites in x7utils. Thanks for keeping an eye out. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: About Devices
Bruce Dubbs wrote: Dan Nicholson wrote: On 5/16/06, Bruce Dubbs [EMAIL PROTECTED] wrote: We do not want to run MAKEDEV upon boot. The /dev directory only needs to be populated once. What do you plan to populate /dev with? We have a good set of devices upon the first boot. I kinda like Alex Merry's suggestion: mount --bind / /mnt cp -a /dev/* /mnt/dev rm /etc/rc.d/rcsysinit.d/S10udev reboot I haven't tried it yet, but I think it should work. Almost...you have to 'rm /etc/rc.d/rcsysinit.d/S45udev_retry' as well...I haven't tried it yet either, and don't plan to, but it should work fine. Also, if reversing the process, make sure that console and null remain. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Former Xorg items
Hi guys. I wanted to ask a question about policy. It's only one package that I know of, and most probably is only one, but I haven't checked lesstif yet. I was thinking about adding rman as a required dependency for NAS, rather than wraping it with 'if you've installed xorg 7', and then adding a note at the top of rman page that says it's already installed if you've installed Xorg6 or XFree86. What do you's think? This also warrants revisiting my original opinion about libdrm, mesa, rman, and xterm being in other parts of the book. I think I might have been a little to quick to judge on those. Moving these packages to the xorg7 section takes about ten seconds to do, so it's very little work. I still say that the packages are already in the correct sections by expected use, but the expected environment of an installed X Window System includes them, and will generally make it easier for editors that might have to deal with them in the book. I also think being linear, as Bruce had mentioned previously, will be easier for users. I'm undecided, so let me know what's best. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Former Xorg items
Randy McMurchy wrote: Sorry for being so candid, but I believe that is what you were asking for. I just hope others contribute as well. If I'm wrong and the entire community disagrees with me, then great. At least we have a consensus. Right now, it seems only you and I have contributed to the threads and we are in total disagreement. Yes, exactly what I wanted. Sorry to make that difficult to read. And FYI, total agreement now. My opinion has reversed completely. Since nobody responded the other day, when I was against putting all the packages together, I wanted to check. Combining all is what Bruce was shooting for the other day. It's throwing out the organization of the book IMO, but I also see that it is much easier for end users (and editors too) if xorg7 parts are all viewed as one package and instructions put into a nice linear order. I'm making the changes locally. It'll be commited tomorrow if nobody chalenges. If anyone disagrees, speak up now. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: typo in xorg utils page
Archaic wrote: Finally, build the three remaining packages with the standard build commands: s/three/four/ Thanks. Fixed locally. Will be in soon. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Former Xorg items
Bruce Dubbs wrote: I don't have any problems with what you are saying. I don't agree that it is changing the organization of the book. It is all a part of xorg7 and keeping that together makes sense. When doing something like this, don't be afraid of doing something different. If it's a problem others will let you know -- some more stridently than others -- but looking at things in a new way is good. We can always fix things that are not optimal. BTW, you seem to always pick the hard things: Java, OO, Xorg7. I appreciate what you do. Thanks. I appreciate it. There is more to it than being difficult...they take forever. I don't have the time I'd like to have to put toward LFS/BLFS anymore. This always varies from week to week, and I've had more than usual lately, but the long build times allow me to step away for a bit and still contribute. :-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: OOo-2.0.2 installation with Firefox
DJ Lucas wrote: I'm not sure if we can obtain those values from the toplevel makefile, but we can certainly make configure scripts use a new moz_flavour and test for all of the above in one shot as is done in the toplevel config_office/configure. In these tests, the standalone tests must occur before the mozilla/firefox/seamonkey ones. After a little more review, I've found that the internal nss libs provided by seamonkey are insufficient for the OpenOffice build. Wether or not the missing functions are actually needed is not soemthing I'm prepared to test for ATM, so to give it what it wants, requires a system nss with seamonkey. Firefox nspr/nss libs work, and I'll submit a new system-mozilla patch to account for that (have to rip out the changes I make for seamonkey in libxmlsec in my patch first). I'll also like to add OpenOffice to the Recomended note for system nss on the mozilla product pages currently in the book. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Open Tickets
Bruce Dubbs wrote: It would be helpful if all editors would review the list and claim those tickets assigned to blfs-book that you feel qualified to do. DJ, you need to accept #1970 and #1971. Done. A little different query...looks like we are at 7 not owned by anyone for 6.2 now: http://wiki.linuxfromscratch.org/blfs/query?status=newstatus=assignedstatus=reopenedmilestone=6.2owner=blfs-book%40linuxfromscratch.orgorder=priority -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Mesa Problem ?
DJ Lucas wrote: The instructions are correct in the context of release7 which uses '/usr' as the default prefix, but are really confusing when taking into account /usr/X11R6. I honestly didn't expect anyone to build against release 6, and the instructions weren't targeted for it. If this is XFree86, it would be good to make a backup copy of /usr/X11R6 before proceeding. 'cp -a /usr/X11R6 /usr/X11R6-bak' should work well. Xorg-6.9.0 works fine with new mesa (it's only a tiny version change 6.4.1-6.4.2), but I can't personally vouch for how well it'll work with XFree86. Anyway, skip the first two instructions (the find and sed) and change the /usr install path to /usr/X11R6. Also, remove the 'X11' from the module path. New instructions will be in the book in about 5 minutes (it'll be a while before it renders still). Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: MesaLib and XFree86
Alexander E. Patrakov wrote: DJ Lucas wrote: Has anyone tested against XFree86? I haven't. Xorg-6.9.0 is fine with the new Mesa No it isn't. The problem is that parts of Mesa that come with Xorg-6.9.0 are still compiled statically into /usr/X11R6/lib/modules/extensions/libGLcore.so. This file is used for indirect rendering. When you update Mesa with installed Xorg-6.9.0, you update only libGL.so, and thus have a version mismatch for direct and indirect rendering. Check yourself with: LIBGL_ALWAYS_INDIRECT=1 glxinfo This still shows old libGL renderer version. This is not necessarily bad, but a warning must be put on Mesa page stating that Mesa that comes with Xorg-6.9 or with XFree86 is fine and there is usually no reason to update it. Thanks for that Alexander. I had no idea the extension linked to gl static. [EMAIL PROTECTED] ~]# LIBGL_ALWAYS_INDIRECT=1 glxinfo | grep Mesa OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 (1.5 Mesa 6.4.1) [EMAIL PROTECTED] ~]# glxinfo | grep Mesa OpenGL renderer string: Mesa DRI Radeon 20050528 AGP 1x NO-TCL OpenGL version string: 1.2 Mesa 6.4.2 Basically, if you should rebuild mesa, then you really should rebuild the the glx, drm, and xprint extensions (from the modular tree). I wonder what else is hidden in there. I guess my next question is whether passing the data from glx to it's recipient could be harmful. This seems especially important WRT xprint and drm. I think this is above my current understanding. Anyway, rebuilding Mesa after X is not a good thing to do AFAICT, the dep is not as strait forward as I had previously thought. I'm going to remove xorg6 from Mesa's required options. It can be added later if this is determined to be alright. I'm not about to get into the reciprocal dependency. Well, one could drop it into the completed build tree and 'make Everything', right? I've never used the everything target. Still, it's not a scenario I'd like to explain in the book. It's covered well enough by the comment about the 'Everything' make target in the mono instructions. Thanks again Alexander. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
ttf2tp1 and rman
Just a reminder for those forging ahead with Xorg7. If you need these utils before they go into the book, they are located at... http://ttf2pt1.sourceforge.net/ and http://polyglotman.sourceforge.net/ I'll fix tickets tomorrow...off to bed. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
MesaLib and XFree86
Has anyone tested against XFree86? I haven't. Xorg-6.9.0 is fine with the new Mesa (it's only a tiny version change, I still tested), but I don't know about XFree86-4.5.0. Also, what version ships with 4.6.0? That dep was changed when the instructions were still in my homedirI never paid it a second thought until now. I'm not comfortable having the whole of 'X Window System' in the deps without having tested with XFree86. Anyone still have XFree86 around to test that? If not, I'll get to it soon, but am pulling the dep until I do, or somebody else confirms that the new libs are compatible with XFree86 bins. If you already have tested, please feel free to change what I've just commented out in the mesalib instructions. Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
