from:"DJ Lucas"

On 07/10/2012 10:52 AM, Armin K. wrote:
 Hi there. There was some talk about splitting Xorg Packages into
 seperate ones. I went with Xorg Applications first. I did not make
 instructions for every package, since there are too many of them, and
 nearly all of them are required at runtime of Xorg Server, so it's
 dependency list would become big. Anyways, I took the way of generating
 the wget and md5sum lists manualy instead of putting them to server.
 These lists are generated using xml entities of each package.

 You can see how that looks here:
 http://linuxfromscratch.org/~krejzi/xorg/x/x7app.html

 Also, there is a patch for that at
 http://linuxfromscratch.org/~krejzi/xorg.patch.gz if desired.

 I won't commit anything if someone does not like that way.

 Drivers splitup is next on my TODO list.

 Comments?
Excellent! Thanks Armin. Looks good. What I was thinking earlier is what 
you have, plus the loop to build the packages, using sudo as mentioned 
elsewhere in this thread. I have a list of seds that you can use as 
instructions to automate adding the packages and md5sums to the xml on 
-support in the thread titled Worlds worst sedder. There were a couple 
of other things I wanted to do with the page, but what you have now can 
be committed any time as that immediately fixes the problem of 
individual package upgrades.

The other things I wanted to do were to get rid of the wget file and 
just use the md5 file for both - just run the grep on the md5sums file 
and then pipe to awk '{print $2}'. I had also planned to add some abuse 
of bridgehead and segmented list for package descriptions for those who 
wish to build the packages separately. The first of those two is easy, 
and the other will be time consuming, plus I haven't gotten output I 
like yet, but both of those can wait. If you have the time and want to 
do what you have above, please do so as time and interest permit.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] [blfs-book] r10408 - in trunk/BOOK: introduction/important kde4/add kde4/core postlfs/filesystems postlfs/virtualization

On 07/11/2012 08:11 AM, Ragnar Thomsen wrote:
 On Tue, Jul 10, 2012 at 9:02 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
 We've had discussions here before about this type of use.  Generally we
 want to use 'an' to prevent two adjacent vowel sounds.  In this case I
 think of lvm as 'ell vee em', so the 'an' is appropriate to to avoid
 the 'a ell' combination.
 Ok, I will revert it.

 -Ragnar-
My favorite place to look up English grammar quirks is the the online 
writing lab at Purdue University. It is a great resource to have handy.

http://owl.english.purdue.edu/

-- DJ Lucas



-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Xorg Applications

On 07/11/2012 06:53 PM, Andrew Benton wrote:
 On Wed, 11 Jul 2012 12:10:01 +0100
 Ken Moffat zarniwh...@ntlworld.com wrote:

   I drop a different set, e.g. I drop bdftopcf (I don't use the
 traditional fonts) and luit (I don't use xterm itself : the book
 does, so I think luit is required in the book, depending on what
 languages / locales you need - I might be way off base).
 Xterm doesn't require luit, it's an optional dep. I think you're right,
 xterm uses luit for internationalisation

 Conversely, I use xgamma so that photo prints bear *some*
 relationship to how the paper looks - saves me a lot of ink, and on
 my latest machines I also use it to reduce the worst colour-tints
 from my integrated graphics (must find more time to try my
 colorhug).

   But I agree that some apps can be dropped by some people :) Another
 difference - I rely on xmodmap to be able to easily type certain
 obscure glyphs.  It's all about choice.
 And there's the rub; how can people make a choice if they don't have
 the info about what depends on what? If we just present all the apps in
 a long take it or leave it list people will have to work out for
 themselves which ones they need. It's the kind of information that
 should be in the book. Documenting dependencies is what the book is
 good at.


Yep, I plan to do it, but I put it on the back burner because I got 
frustrated as I couldn't get it to render the way I wanted it. See my 
previous response to the OP for what I had in mind to cover both 
scripted build and those of us who package.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Xorg Applications

On 07/10/2012 10:52 AM, Armin K. wrote:
 Hi there. There was some talk about splitting Xorg Packages into
 seperate ones. I went with Xorg Applications first. I did not make
 instructions for every package, since there are too many of them, and
 nearly all of them are required at runtime of Xorg Server, so it's
 dependency list would become big. Anyways, I took the way of generating
 the wget and md5sum lists manualy instead of putting them to server.
 These lists are generated using xml entities of each package.

 You can see how that looks here:
 http://linuxfromscratch.org/~krejzi/xorg/x/x7app.html

 Also, there is a patch for that at
 http://linuxfromscratch.org/~krejzi/xorg.patch.gz if desired.

 I won't commit anything if someone does not like that way.

 Drivers splitup is next on my TODO list.

 Comments?
LOL..too funny. I just looked at your diff. I didn't want the package 
versions in general.ent either. We had almost identical idea of how to 
go about it:

dj [ installing ]$ diff -au x7app.xml applications.xml
--- x7app.xml2012-06-11 21:15:46.0 -0500
+++ applications.xml2012-06-26 00:21:21.0 -0500
@@ -4,28 +4,102 @@
!ENTITY % general-entities SYSTEM ../../general.ent
%general-entities;

- !ENTITY x7apps-download-http 
http://xorg.freedesktop.org/releases/individual/app/;
- !ENTITY x7apps-download-ftp  ftp://ftp.x.org/pub/individual/app/;
- !ENTITY x7apps-wget  
files-anduin;/xorg/app-xorg7-release;.wget
- !ENTITY x7apps-md5sum
files-anduin;/xorg/app-xorg7-release;.md5
- !ENTITY x7apps-size  4.8 MB
- !ENTITY x7apps-buildsize 39.2 MB
- !ENTITY x7apps-time  1.5 SBU
+ !ENTITY applications-download-http 
http://xorg.freedesktop.org/releases/individual/app/;
+ !ENTITY applications-download-ftp  ftp://ftp.x.org/pub/individual/app/;
+ !ENTITY applications-size  4.8 MB
+ !ENTITY applications-buildsize 39.2 MB
+ !ENTITY applications-time  1.5 SBU
+
+ !-- versions and md5sums --
+ !ENTITY bdftopcf-version 1.0.3
+ !ENTITY bdftopcf-md5sum  4a7a4a848c43c42f7d499b60666434a4
+ !ENTITY iceauth-version  1.0.5
+ !ENTITY iceauth-md5sum   08e3f6b523da8b0af179f22f339508b2
+ !ENTITY luit-version 1.1.1
+ !ENTITY luit-md5sum  c4a3664e08e5a47c120ff9263ee2f20c
+ !ENTITY mkfontdir-version1.0.7
+ !ENTITY mkfontdir-md5sum 18c429148c96c2079edda922a2b67632
...
+ !ENTITY xwud-version 1.0.4
+ !ENTITY xwud-md5sum  3025b152b4f13fdffd0c46d0be587be6

  ]

-sect1 id=xorg7-app xreflabel=Xorg Applications
- ?dbhtml filename=x7app.html?
+sect1 id=x-applications xreflabel=Xorg Applications
+ ?dbhtml filename=x-applications.html?
...
+ paraFirst, create the md5sums file./para
+
+screenuserinputcat gt; applications.md5 lt;lt; EOF
+# Xorg-7.7-1 application package md5sums
+bdftopcf-md5sum;  bdftopcf-bdftopcf-version;.tar.bz2
+iceauth-md5sum;  iceauth-iceauth-version;.tar.bz2
...
+EOF/userinput/screen
+
+ paraThen download the needed files:/para
+
+screenuserinputmkdir applications amp;amp;
+cd applications amp;amp;
+grep -v '^#' ../applications.md5 | sed 's@^[0-9a-z]\{32\}  @@' | wget 
-i- -c \
  -B http://xorg.freedesktop.org/releases/individual/app/ amp;amp;
-md5sum -c ../app-xorg7-release;.md5/userinput/screen
+md5sum -c ../applications.md5/userinput/screen
...

Adding the spacing like you did is much easier to look at, and just 
ignore that sed...awk is better in this case.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Shared library file locations

On 07/08/2012 03:43 AM, Andrew Benton wrote:
 On Sun, 08 Jul 2012 01:14:43 +0100
 Bruce Dubbs bruce.du...@gmail.com wrote:

 The question was a bit more subtle.  Is it OK to put things only needed
 for building in /lib?  Historically, that location was only for the
 minimum needed to get critical programs running at boot time before /usr
 was mounted.
 Huge disks are cheap now. The time when /usr needed to be on a separate
 partition has long since passed (I've never seen a system where /usr
 was a separate partition). I don't see the need for /usr at all now.
 Why don't we install everything into /? It simplifies configuring many
 packages as the don't need to be told --sysconfdir=/etc or
 --localstatedir=/var.
There are other reasons to have /usr on a separate partition, but I 
question how often they are actually used. A School computer lab is a 
prime example, but I'm seeing more and more OS X and OpenDirectory in 
that space. Just did a Lion migration last week in fact.

Unfortunately, we are at the point where /usr cannot be on a separate 
partition and still meet FHS-2.3 without an initrd (well, we could ditch 
udev and make BLFS a lot more difficult). Lots of changes coming though. 
With the loss of a few servers (in May IIRC), FHS-3.0 was put on hold.

At this point, as much as I hate it, I can't suggest any way to handle 
it properly. We can suggest that users move forward with an initrd that 
can mount /usr but that still doesn't address the spec non-compliance at 
present. Thus far, FHS draft has done nothing to address the /usr debate 
as it can be _partially_ pushed off by providing an initrd that is 
capable of mounting /usr. RedHat is moving forward in F17 with the 
symlinked directories for /lib, /lib64, /bin, and /sbin, and Debian will 
continue to push forward with their sane approach to multi-lib instead 
of the abuse for binaries to the FHS spec that had been adopted by 
everyone but Debian (libqual for primary arch). Who knows which way 
things are going at this point? There is going to have to be some give 
though, because the spec dependencies aren't quite compatible 
(POSIX-FHS-LSB).

 The only downside is that for themes to work the
 environment variable XDG_DATA_DIRS=/share needs to be set.
That could be fixed in the freedesktop source, or easier, symlink /share 
- /usr/share just like /lib, /libqual, /bin, and /sbin in the RedHat 
configuration. Do you mean to ditch the /usr directory completely?

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Shared library file locations

On 07/08/2012 11:58 AM, Bruce Dubbs wrote:
 DJ Lucas wrote:
 On 07/08/2012 03:43 AM, Andrew Benton wrote:

 The only downside is that for themes to work the
 environment variable XDG_DATA_DIRS=/share needs to be set.
 That could be fixed in the freedesktop source, or easier, symlink /share
 - /usr/share just like /lib, /libqual, /bin, and /sbin in the RedHat
 configuration. Do you mean to ditch the /usr directory completely?
 I thought the direction was the reverse:  ditch /bin, /sbin, /lib and
 put everything in /usr.


It is, I believe Andy was shooting for the reverse, which is why I asked.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] GDM (very minor) issue and a suggestion

Okay, so first of all, in the default X configuration, the gdm user 
should be added to the video group so that Gnome doesn't fallback, and 
also to the audio group so that sound works properly. This can be done 
when creating the user (there are other methods, but they are not in the 
book and I've left them out intentionally).

The other issue is the gdm bootscript lives on. I've always disliked 
using a bootscript for gdm. We use wait lines in inittab, so the TTYs 
are never brought up because rc never finishes. Of course, it could be 
argued that they never should be brought up, but that leaves one without 
a failsafe should gdm get broken or get stuck in a loop (for which it 
will gracefully kill itself eventually IIRC). I would much rather drop 
the bootscript and start directly from inittab. Setting initdefault to 5 
and adding a seventh line 7:5:respawn:/usr/sbin/gdm -nodaemon line is 
sufficient (and as an aside, it should get rid of the 7th tty patch). In 
the event of gdm fouling up, Ctrl+Alt+F{1..6} will still get you to a 
shell login prompt where you can 'telinit 3' to gracefully ditch gdm 
until fixed.

Comments?


# Begin /etc/inittab

id:5:initdefault:

si::sysinit:/etc/rc.d/init.d/rc S

l0:0:wait:/etc/rc.d/init.d/rc 0
l1:S1:wait:/etc/rc.d/init.d/rc 1
l2:2:wait:/etc/rc.d/init.d/rc 2
l3:3:wait:/etc/rc.d/init.d/rc 3
l4:4:wait:/etc/rc.d/init.d/rc 4
l5:5:wait:/etc/rc.d/init.d/rc 5
l6:6:wait:/etc/rc.d/init.d/rc 6

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

su:S016:once:/sbin/sulogin

1:2345:respawn:/sbin/agetty --noclear tty1 9600
2:2345:respawn:/sbin/agetty tty2 9600
3:2345:respawn:/sbin/agetty tty3 9600
4:2345:respawn:/sbin/agetty tty4 9600
5:2345:respawn:/sbin/agetty tty5 9600
6:2345:respawn:/sbin/agetty tty6 9600
7:5:respawn:/usr/sbin/gdm -nodaemon

# End /etc/inittab

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Proposed changes

On 07/07/2012 08:50 PM, Ken Moffat wrote:
   Back in January last year, I made a proposal to add some discussion
 of vulnerabilities in the security chapter, and how to look at what
 the distros are doing to fix their builds (for vulnerabilities but
 also for when packages no longer build).  There was some interest
 from users, but no comment from editors.  At that time, I *thought*
 several editors were still active, but I was probably mistaken.  My
 normal attitude is to not break things, and to follow the party line
 even if that means doing nothing.  Je suis anarchiste bourgeois. [1]

   I then went off in a huff, but had to come back because changes in
 LFS-7.0 (glibc and bootscripts) broke nfs.  Since then, we've got a
 lot more active editors, but I think those proposed changes would
 still be useful - it's not as if we are on top of known
 vulnerabilites.  Some of this proposal is updated and expanded.
Sounds good.
   Additionally, I think that now is a suitable time to replace
 gnome-media with gvolwheel, and to add another lightweight window
 manager (icewm).
Cool cool. I don't use either, but I gather that others will appreciate 
them.
   When I started preparing this, my current BLFS version was
 2012-06-23.  You can find a rendered version of the changes, and a
 gzipped diff of the xml, at
 http://www.linuxfromscratch.org/~ken/tmp/

   This contains the following changes:

 1. new page in chapter 2 to explain static/shared libraries : in the
 book we now often use --disable-static but I don't think we've
 explained why.

Sounds good. I don't know if this is still covered in LFS. It used to be 
before PureLFS.

 2. add pointers to some distros in Beyond BLFS, change freshmeat.net
 to freecode.com, and add  a link to a rpm2cpio script.  Basically,
 as in  last year's suggestion (the change to google/linux is no
 longer appropriate, that has become google/webhp and is not linux
 specific).
Any particular reason for rpm2cpio specifically? CLFS has an rpm2targz 
that we could add.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Firefox/Thunderbird MimeType

2012-07-07 Thread DJ Lucas

On 07/05/2012 07:11 AM, Andrew Benton wrote:
On Thu, 05 Jul 2012 07:15:20 +0100
DJ Lucas d...@linuxfromscratch.org wrote:

We need to add the MimeType to the .desktop files for Firefox and
Thunderbird. These are required to make them the default handlers in
Gnome and KDE. I believe there are other ways in both, but I haven't
looked in KDE, and haven't been able to figure it out in Gnome yet, but
this is the way the spec wants it. I'm not sure about LXDE and XFCE...do
they follow freedesktop.org standard?
I don't know. With XFCE the firefox.desktop file that's in the book
shows up in the menu. If I click on a html file in Thunar a dialog pops
up that asks me to pick an application. If I add a MimeType line to the
firefox.desktop it makes no difference, it still doesn't suggest to use
Firefox, I still have to choose it from all the others. Once I've
chosen it I can make it the default so it's not something that needs to
be done every time. It only needs to be done once for each mime type.

Also, the --enable-calendar
switch is not included in the Thunderbird mozconfig that is in the book.
I've never used this calendar but if it's useful to some people that's
fine. Maybe we could put the option in the mozconfig with a line that
says:

# If you want to compile the Mozilla Calendar, uncomment this line:
# ac_add_options --enable-calendar

There is actually more to it than that. I didn't notice it missing until
after I built it and didn't have a calendar sidebar. I just installed
the binary lightening plugin for now. Will revisit all of my previous
comments/commitments as soon as I have a fully functional system again.

What I have for mime types is...

Firefox:
MimeType=text/html;text/xml;application/xhtml+xml;x-scheme-handler/http;x-scheme-handler/https;

Thunderbird:
MimeType=text/calendar;text/x-vcard;text/directory;application/mbox;message/rfc822;x-scheme-handler/mailto;x-scheme-handler/news;x-scheme-handler/snews;x-scheme-handler/nntp;x-scheme-handler/feed

Fair enough. Those line make no difference that I'm aware of to LXPanel
or to XFCE but I don't think it'll do any harm and if it helps someone
then it should go in the book.
I'm worried about the long lines in the book. What do you think of
putting only the mime types in by default? Defaults would be:

Firefox:
MimeType=text/html;text/xml;application/xhtml+xml;

Thunderbird:
MimeType=text/x-vcard;text/directory;application/mbox;message/rfc822

And then providing a list in the book with the available additional
types (only text/calendar is added for thunderbird) and handlers (all
above) and instructions to modify as appropriate for the system it is
going on? Again, I'll be happy to take care of it in a couple of days.

-- DJ Lucas

--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Firefox/Thunderbird MimeType

2012-07-07 Thread DJ Lucas

On 07/07/2012 11:23 AM, Bruce Dubbs wrote:
 DJ Lucas wrote:

 What I have for mime types is...

 Firefox:
 MimeType=text/html;text/xml;application/xhtml+xml;x-scheme-handler/http;
 x-scheme-handler/https;
 Thunderbird:
 MimeType=text/calendar;text/x-vcard;text/directory;application/mbox;
 message/rfc822;x-scheme-handler/mailto;x-scheme-handler/news;
 x-scheme-handler/snews;x-scheme-handler/nntp;x-scheme-handler/feed

 I'm worried about the long lines in the book. What do you think of
 putting only the mime types in by default? Defaults would be:

 Firefox:
 MimeType=text/html;text/xml;application/xhtml+xml;

 Thunderbird:
 MimeType=text/x-vcard;text/directory;application/mbox;message/rfc822
 Sometimes long lines are a problem.  I've noticed that the new Seamonkey
 breaks lines at dashes for me, but I'm sure some browsers don't.  I'm no
 longer concerned about a pdf version of BLFS.  We haven't created a
 version in years and I don't recall anyone saying
 they'd like one.
I've seen some conversation about an epub version, but my real concern 
regarding Firefox (and long lines in general) is that i imagine quite a 
few people are still using links or lynx at that point. One of them puts 
spaces at the beginning of the new line. I actually forgot about 
SeaMonkey as I don't use it, but it too is affected and should have the 
same MimeType lines combined and added, and of course, the length is 
probably even more important there regarding links/lynx. I'm not sure of 
the additional mime-types for the irc client. Does SeaMonkey include 
.desktop file(s) by default?

 For MimeType we could just break it manually and add a note saying the
 line breaks should not be present.  Alternatively, if we are going to
 use echo, we could do something like:

 m1=text/calendar;text/x-vcard;text/directory;
 m2=application/mbox;message/rfc822;x-scheme-handler/mailto;
 m3=x-scheme-handler/news;x-scheme-handler/snews;
 m4=x-scheme-handler/nntp;x-scheme-handler/feed

 echo MimeType=$m1$m2$m3$m4  some-file

 We might even get clever and write something like:

 m5=`echo x-scheme-handler/{mailto,news,snews,nntp,feed}|sed '/ /;/g'`
 m6=`echo text/{calendar,x-vcard,directory} |sed '/ /;/g'`
 echo MimeType=$m6;application/mbox;message/rfc822;$m5  some-file

 :) :)

Yes, that works well for all. Sounds good.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] Firefox/Thunderbird MimeType

2012-07-05 Thread DJ Lucas

We need to add the MimeType to the .desktop files for Firefox and 
Thunderbird. These are required to make them the default handlers in 
Gnome and KDE. I believe there are other ways in both, but I haven't 
looked in KDE, and haven't been able to figure it out in Gnome yet, but 
this is the way the spec wants it. I'm not sure about LXDE and XFCE...do 
they follow freedesktop.org standard? Also, the --enable-calendar 
switch is not included in the Thunderbird mozconfig that is in the book.

What I have for mime types is...

Firefox:
MimeType=text/html;text/xml;application/xhtml+xml;x-scheme-handler/http;x-scheme-handler/https;

Thunderbird:
MimeType=text/calendar;text/x-vcard;text/directory;application/mbox;message/rfc822;x-scheme-handler/mailto;x-scheme-handler/news;x-scheme-handler/snews;x-scheme-handler/nntp;x-scheme-handler/feed

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] pam_ck_connector and pam_loginuid

2012-07-03 Thread DJ Lucas

On 07/02/2012 01:47 AM, Armin K. wrote:
 It is not my fault that sudo is broken when it comes to pam. Everything
 else works but it and I don't want to sacrifice everything else for some
 stuff I don't care about. Just don't use system-session in sudo in the
 first place like I do.
Well, that is the problem, sudo isn't broken, it is just doing what it 
was told to do. I'm going to disagree with you about sudo including 
session defaults (see below), but I'm going to follow your example 
nonetheless. I don't particularly like it as it was not what I had 
intended when I wrote those files, but it looks like you and Ubuntu do 
agree on it. They have added a common-session-noninteractive to handle 
this particular use case since I last visited their configuration (for 
which I based a good portion of BLFS's PAM configuration, though 
minimalist). While I dislike it, seeing as I did base it from theirs, 
I'm going to continue to follow their lead and do similar. ck_connector 
and loginuid will require no changes in your instructions this way, and 
the new can be used for cron and samba later on (as in Ubuntu, so this 
might even be expected by some users).

As far as your sudo configuration, for what reason do you not follow the 
book? Only the above, or do you go well beyond the minimal defaults? If 
so, do you have any other suggestions? I wasn't aware that any other 
editors actually used it. While I'm browsing through it, I see a few 
other wrinkles, for instance, session limits should probably be added to 
system-session as well--while no limits are configured by default, it is 
probably surprising to an end user if they make changes and they don't 
see them immediately. I'm going to pick through it a little more as our 
defaults are getting a little long in the tooth (about 2 years old now). 
I'd like to keep pam_unix as a session module in system-session for 
logging though. In the case of sudo, it is an easy way to catch abuse 
cases of 'sudo su' or 'sudo bash' or similar. Do you have any other 
suggestions for the default PAM configuration?

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] pam_ck_connector and pam_loginuid

2012-07-01 Thread DJ Lucas

Shall I try this again

pam_ck_connector and pam_loginuid should not be placed into

system-session, but rather directly in login, {g,k,x}dm, sshd, etc. as
session optional. These modules are only intended for login sessions.
When using sudo, pam_ck_connector causes gnome-shell to segfault. I
don't completely understand the interaction just yet, but I suspect it
has something to do with root now owning the session cookie. :-)

I think the best solution would be to create empty login-*
configurations and append to those (include them by default in login
configuration), and then include that into login utilities pam
configuration. I'll try and get a look at it Wed night or so (maybe even
tonight...we'll see).

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] xorg problems

2012-06-27 Thread DJ Lucas

On 06/27/2012 09:54 PM, Bruce Dubbs wrote:
 Ken Moffat wrote:
 On Wed, Jun 27, 2012 at 05:43:48PM -0500, Bruce Dubbs wrote:
 Ken Moffat wrote:
 On Wed, Jun 27, 2012 at 04:22:39PM -0500, Bruce Dubbs wrote:
 Good spot.  I do not have CONFIG_INPUT_EVDEV set.
   LOL - I looked through my notes, which was why I suggested it : on
 both of my old x86_64 machines I was trying out evdev in 2009, when
 still building both i686 and x86_64 kernels, and had a similar
 problem: EVDEV set on the 64-bit kernels but not on the 32-bit.
 I rebuilt the kernel with CONFIG_INPUT_EVDEV and now evdev works fine.

 Now I'm having a problem with getting my two monitors working properly.
It seems that anything I do, I get the same display reflected on both
 monitors instead of stretching across both.

Dang, it's been a really long time since I messed with it. The man page 
suggests 'Option Dualhead true' needs Virtual. Maybe two monitor 
sections and only one screen section with 'Virtual  3840 x 1200', 
(or 1920 x 2400 for top and bottom) or ditch the Dualhead option if 
using Xinerama extension, but I don't honestly know if you can use both 
outputs with the nv driver that way. Playing with an Nvidia card is 
something I've been meaning to do for a couple of years now and I have 
just never gotten around to it. Whatever the final solution is, please 
replace the example in the book, or post it so I can.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Release Plan (Was: Separate Xorg packages)

2012-06-27 Thread DJ Lucas

On 06/26/2012 08:25 PM, Bruce Dubbs wrote:
 Ken Moffat wrote:
 On Tue, Jun 26, 2012 at 04:02:05PM -0500, Bruce Dubbs wrote:
The only caveat is to consider the release plan.  Right now, I'd
 like to release a coordinated LFS/BLFS on 1 September.  That means a
 package freeze and an -rc1 for both about 1 August or slightly over one
 month from now.

 Someone might also want to think about some of the items at the
 bottom of longindex.html,  Some of what is in section g ('Others')
 is reasonable, some doesn't necessarily belong there.  Not sure if
 everything in the preceding Bootscripts section belongs there -
 maybe it all does!  Certainly the subsequent 'L' and 'O' headings
 look as if their contents are in the wrong places.  Indexing is
 easily broken ;)
 Yes, the index entries are tedious, especially for a new package with
 lots of items.  That's one reason I think a whole month is needed.  Even
 that may not be enough.

I'm afraid a month probably won't be enough time. It has been several 
years since a BLFS release. I'm not even sure what year that was now, 
but it has been overwritten by years of only basic proof reading by 
people perusing the commit logs and the instruction authors themselves. 
The entire book needs to be reviewed for spelling, grammar, and 
consistency, which is a painful job that few of us will _want_ to do. In 
addition to a spell checker and manual reading (out loud), a decent 
screen reader works wonders for finding transposed words and odd phrases 
(and it gives those of us without disabilities a good reason to test at 
least part of the accessibility stack).
 There's a lot of things that could be done at that time like moving
 packages to different sections, reviewing especially the Preface and the
 first three chapters which have a lot of text, etc.

 If I'm around and not doing anything else after the package freeze,
 you could ping me - I suspect most editors don't really care about
 longindex.  I tend to use it a lot, and have just been looking at
 it for some things I plan to (re)propose shortly.

 Beyond that, are we supposed to start tagging packages for 7.2 once
 the freeze starts ?  If so, what happens if anything in LFS has to
 be revised during the -rc ?
 If we freeze LFS, then I think we can mark BLFS with an entity like
 lfs_72_checked; and have it display -rc1  while we are in freeze and
 then at release just change the definition.
Actually, the original plan was to make it empty at release if we are 
going for a matching release version. I don't know if this holds true 
today. Also, in the old days (it was sooo long ago), we had waited for 
LFS final, then freeze. BLFS would lag behind LFS by at least a couple 
of months for final commits and cleanup. I don't know if we should 
follow the old way, but figured I'd throw it out there.
 I suspect that packages that must be changed during freeze would only be
 due to bugs or security issues, not enhancements.  Generally, if a
 package is major.minor.patch and only the patch level changes, updating
 does not affect other packages.
Personally, I'd suggest branching at package freeze time, and back 
porting changes from head. I realize that is extra work for whoever the 
RM is, but the one thing I really do not like to see is somebody sitting 
on a big commit for a month or better because of a package freeze for 
release. That is really frustrating from a peon's POV! We seem to have a 
pretty good editorial team now, maybe a little rough around the edges, 
but for the most part we are tolerable of each other and work pretty 
well together. I'd like to see some of the (not so) new additions stick 
around for a while. :-)
 One thing to note is that my release proposal is just that, a proposal.
I'd like to get some agreement this is the right thing to do and the
 approach is reasonable.

See minor points above.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Separate Xorg packages (Was: Xorg-7.7-1 upgrade)

2012-06-27 Thread DJ Lucas

On 06/26/2012 04:02 PM, Bruce Dubbs wrote:
 DJ Lucas wrote:
 On 06/19/2012 08:18 PM, Fernando de Oliveira wrote:

 Embedding the md5 and wget files in the book seems like an OK idea to
 me.  The only caveat is to consider the release plan.  Right now, I'd
 like to release a coordinated LFS/BLFS on 1 September.  That means a
 package freeze and an -rc1 for both about 1 August or slightly over one
 month from now.

 Would such a change be reasonable by then?


With the existing pages, it'd take about 10 minutes. What I want to do, 
however, is to separate the packages but leave the group instructions 
(or at very least see what I can make it look like). I've obviously 
stalled on that for a little bit, but I'll get back to it over the weekend.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Separate Xorg packages (Was: Xorg-7.7-1 upgrade)

2012-06-22 Thread DJ Lucas

On 06/22/2012 06:08 PM, Armin K. wrote:
 On 06/23/2012 12:46 AM, Fernando de Oliveira wrote:

 Yuck! I don't believe that world will end in December.

OT Warning!

LOL! Sorry, just being silly. But yeah, I don't really get the supposed 
Mayan calendar correlation. I figure the translators just screwed up 
somewhere along the lines and it actually ends in another 140 years or 
so, at a logical end point for a long calendar given the belief system.
 I like the idea. So, an individual package being upgraded, the cat ..
 EOF. sounds good, easier for book upgrade patches, if I understand
 correctly. I am looking forward to see the proto page.

Yes, that is the point of putting the wget lists in the book directly.
 Great. I've said that I'm going to split Drivers into individual
 packages in Python/Perl Modules or Additional Xorg Drivers style (All of
 them on one page, but still seperated - since not all of them are really
 needed for one machine). Looking at this thread, I could also make
 instructions for generating wget and md5sum lists at the beginning of
 the instructions. I plan to start that in the first week of July since I
 have some exams to do right now and I don't have any time for that.

 I am willing to volunteer to what you think I could do.

 If I take a page from xml, make changes and post a diff this is what you
 would need?

 Cheers,

 Yeah, just clone the repo, edit xml and post svn diff output as an
 email attachment. Check if it validates before sending it. Someone will
 look at your changes and possibly merge them if they seem apropriate.

 See http://www.linuxfromscratch.org/blfs/edguide/ for some basic
 information regarding book editing.
Actually, in this particular case, I'd suggest creating new pages as 
almost nothing of the old will be reused. I'm going to play around with 
a few ideas over the weekend and see if I can come up with something 
aesthetically pleasing...something a little more compact than say the 
various modules pages as there will be quite a few more packages per 
page. Maybe abuse bridgehead-renderas a little more.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Separate Xorg packages (Was: Xorg-7.7-1 upgrade)

2012-06-22 Thread DJ Lucas

On 06/22/2012 06:08 PM, Armin K. wrote:

 Great. I've said that I'm going to split Drivers into individual
 packages in Python/Perl Modules or Additional Xorg Drivers style (All of
 them on one page, but still seperated - since not all of them are really
 needed for one machine). Looking at this thread, I could also make
 instructions for generating wget and md5sum lists at the beginning of
 the instructions. I plan to start that in the first week of July since I
 have some exams to do right now and I don't have any time for that.

Forgot to add that the drivers might be fine without the wget lists, as 
most people will want only the 5 drivers, but maybe better to keep it 
for consistency's sake. IDK, guess we'll just see how it turns out. Of 
course, without a wget list for drivers, the additional drivers page can 
be merged with the main page.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] Separate Xorg packages (Was: Xorg-7.7-1 upgrade)

2012-06-19 Thread DJ Lucas

On 06/19/2012 08:18 PM, Fernando de Oliveira wrote:

 Since we had a discussion about upgrading Xorg, I stopped doing some
 upgrades. Other than the few new splits, I only had to upgrade 8 packages:

 -libX11-1.4.99.901.tar.bz2  +libX11-1.5.0.tar.bz2
 -libXaw-1.0.10.tar.bz2  +libXaw-1.0.11.tar.bz2
 -libXft-2.3.0.tar.bz2   +libXft-2.3.1.tar.bz2
 -libXi-1.6.0.tar.bz2+libXi-1.6.1.tar.bz2
 -xbitmaps-1.1.0.tar.bz2 +xbitmaps-1.1.1.tar.bz2
 -xinput-1.5.99.1.tar.bz2+xinput-1.6.0.tar.bz2
 -xmodmap-1.0.6.tar.bz2  +xmodmap-1.0.7.tar.bz2
 -xorg-server-1.12.1 +xorg-server-1.12.2

 With much respect, IMHO, as Xorg is not anymore monolithic, i.e., is
 modular, it would be good keeping doing upgrades, for example, once a
 month, as several distros do upgrades continuously.

I'm not sure about once per month, but it should happen 
periodically...but I'm going to take it a bit further (see below). If we 
stick with the format in the book now, I'd suggest the usual security, 
feature, and bugfix updates as they always have been done (when an 
editor (usually me) deems it necessary), in addition to a scheduled 
quarterly update. This would give us ~6-8 scheduled releases between 
katamari releases, but, on to the new subject line...

Unlike other packages in BLFS, I've unintentionally limited Xorg updates 
over the past several years to release updates (katamari), security 
updates (few), and the occasional feature group updates (as above) due 
to the incrementing release number that is tacked on to the wget lists. 
This is usually when somebody chimes in with the separate the packages 
argument, and where I shoot it down citing the amount of work it would 
take and the user experience. I always give the thumbs up for 
educational and packaging value, but down it goes when it comes to a 
user's experience as we go from something like 35 sets of instructions, 
to around 270 sets of instructions from start to finish (not to mention 
the editor workload involved).

Well, I'm not going to shoot it down tonight, but rather suggest a 
compromise, one that I've hinted at before. What I envision for that 
compromise is that we continue with the logical groups of packages on 
one page (I really do like the additional drivers page that was added, 
but it could be simplified even more for the group of packages pages), 
with instructions to create the wget and md5sums lists with the cat  
file  EOF syntax, instructions to edit those files based on the 
information below (package information and purpose), and the completed 
loop instructions on the page. This makes individual package updates 
easier as we are not assigning an arbitrary build number which requires 
new wget and md5 file lists to be generated, each package's purpose (or 
lack thereof) can be explained, and we cater to the packagers without 
giving up our simplified build of ~35 sets of instructions (which will 
continue to be necessary for the average user).

With the above goals stated, if we are going to do it, then it needs to 
be done right the first time. We can stick with what we have now and 
take our time to attack the interdependent explanations of the packages. 
I plan to do a -2 release about a month after Meas/libdrm is completed 
to give the upstream packagers time to incorporate the changes in their 
respective packages after general availability. I'm open to suggestions 
on the explanations here, but I suspect it will come in a totally 
foreign dependency order (actually reversed for the most part) due to 
the way that Xorg was separated (Ex: This package contains protocol 
headers for libXabc, libXxyz, and the server components X, Y, and Z.). 
Comments or suggestions would really be appreciated here. The pages 
could be written initially without the package descriptions/explanations 
to get most of the grunt work done by whoever might be interested in 
helping.

Have any of you already started on documenting any of this on the side? 
Is there a dependency matrix someplace that I'm unaware of? I'll plan to 
do a quick mockup of the proto page (hopefully this weekend, following 
any info gleaned in this thread) as an example and a template of sorts, 
but I definitely need volunteers. I assure you that if left to do it 
alone, you can expect completion sometime well after the end of the 
world in December! ;-)

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Xorg-7.7-1 Update

2012-06-12 Thread DJ Lucas

On 06/12/2012 04:26 AM, Andrew Benton wrote:
 On Tue, 12 Jun 2012 03:40:08 +0100
 DJ Lucasd...@linuxfromscratch.org  wrote:

 Update is complete, save for the index entries in the app, driver, font,
 lib, and proto sections. I ran out of time for them (I may still get it
 tonight, if not, Friday, but not much has changed). Otherwise, it's
 done. Let me know if you find any problems.
 Hey DJ, what's happening with the Xorg section? It looks like you've
 added separate pages for some things (like libXp) but not others (like
 libX11)? It seems a bit random at the moment, is there a plan?
 Personally I'd like to see all the xorg packages have their own pages
 (possibly organised into subsections like proto, app, lib, driver and
 util). It seems as though you've started to break some of the xorg
 packages out onto their own pages. Is this something that will continue?

 Andy
No, the only separate packages that are those that are not part of the 
katamari, not from x.org, or those few from the x.org folks that must be 
separated for proper build order to still use the groups of packages.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] openjdk test report

2012-06-11 Thread DJ Lucas

On 06/11/2012 01:49 PM, Bruce Dubbs wrote:
 Fernando de Oliveira wrote:
 On 08-06-2012 03:21, Bruce Dubbs wrote:  I was able to build and test 
 openjdk.  The results are OK, but I'm
 disappointed in the number of issues that are not addressed upstream.

 I used:

 #!/bin/bash

 export DISPLAY=:20
 Xvfb :20 -screen 0 1x1x24 -ac
 echo $!   Xvfb.pid
 make jtregcheck -k 2jdktest-errs |tee jdktest
 kill -9 `cat Xvfb.pid`
 unset DISPLAY
 rm -f Xvfb.pid
 Don't you and/or DJ think these lines could be in the page?
 Yes, I think they are useful, but I was waiting for DJ to have some time
 to discuss.
Yeah, but 1x1 session is not adequate for testing things like borders, 
window decorations, and transparent backgrounds, so I left it out for now.
 There were several lines in jdktest-errs like

 WARNING: Path does not exist as file or directory:
 Makefile:205: Extraneous text after `ifeq' directive
 xxx uses or overrides a deprecated API
 Note: Some input files use unchecked or unsafe operations.

 I just don't think a package as important as java should have those
 types of errors/warnings in their test suite.
 Completely agree with this and the disappointment you mentioned in the
 first line above.
 Since this was orifinally done by Sun, the tests probably assume a shell
 program different from bash.  That may explain some of the problems.

 Personally, I wouldn't release anything that causes any warnings.   If
 other environments cause warnings, then that is worth checking out and
 either fixing the code or fixing the test.

With the patch I've just added, it stabilizes it a bit more, but there 
are still unexplained test failures if not in an absolutely pristine 
environment. I unfortunately don't have a better way to explain it in 
the book. All of the crypto and SSL failures are due to tests that have 
not been updated for newer NSS (padding failures). The JDK code has long 
ago been updated, but these tests are from a very old version of the 
full JTReg (as explained in the book). A 1x1 Xvfb session doesn't cut it 
either (see above), hence why I only added a mention of it instead of 
the actual instructions. As it is now, I am passing all remaining tests 
on i686 in TWM with the xset commands Bruce posted earlier. As I 
understand it, hacking up JTReg to work in the limited environment 
expected (no junit - and alot in there to assist) was a chore to begin 
with, and even more so with a newer version, so we simply have to wait 
or fix them ourselves and send upstream. IcedTea bugs #913 and #914 are 
to fix the NSS related failures, which will eliminate ~40 of the 80 
(currently expected) failures, and are still slotted for the 2.2 release 
cycle (presumably icedtea-2.2.1).

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] openjdk test report

2012-06-11 Thread DJ Lucas

On 06/08/2012 01:21 AM, Bruce Dubbs wrote:
 I was able to build and test openjdk.  The results are OK, but I'm
 disappointed in the number of issues that are not addressed upstream.

 I used:

 #!/bin/bash

 export DISPLAY=:20
 Xvfb :20 -screen 0 1x1x24 -ac
 echo $!   Xvfb.pid
 make jtregcheck -k 2jdktest-errs |tee jdktest
 kill -9 `cat Xvfb.pid`
 unset DISPLAY
 rm -f Xvfb.pid

 There were several lines in jdktest-errs like

 WARNING: Path does not exist as file or directory:
 Makefile:205: Extraneous text after `ifeq' directive
 xxx uses or overrides a deprecated API
 Note: Some input files use unchecked or unsafe operations.

 I just don't think a package as important as java should have those
 types of errors/warnings in their test suite.

 The tests themselves were:

 --- jtreg console summary for hotspot ---
 Test results: passed: 154
 --- jtreg console summary for jdk ---
 Test results: passed: 4,052; failed: 33; error: 2
 --- jtreg console summary for langtools ---
 Test results: passed: 1,938

 So here is 35 errors out of about 7000 tests.  Workable, but not impressive.

 Tests like com/oracle/security/ucrypto/TestAES.java should not be screen
 or disk sensitive.  It doesn't really say why it failed, but just that
 it threw an exception.
Sorry, I thought I had responded earlier to this one

Unfortunately, JTReg is a monster. You'll have to edit 
icedtea-2.2/test/jtreg/com/sun/javatest/TestResult.java and set 
DEFAULT_MAX_OUTPUT_SIZE above 10 to get the full output for that 
test (I just added a zero). For that particular one, it is a padding 
error (known issue).

-- DJ Lucas



-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] Xorg-7.7-1 Update

2012-06-11 Thread DJ Lucas

Update is complete, save for the index entries in the app, driver, font, 
lib, and proto sections. I ran out of time for them (I may still get it 
tonight, if not, Friday, but not much has changed). Otherwise, it's 
done. Let me know if you find any problems.

-- DJ


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] Old files

2012-06-07 Thread DJ Lucas

After running across the SVN server page, I gave the server a minor 
workout tonight...

cd ~/LFS/BLFS/BOOK
for file in `find . -name *.xml | sed '/\.svn/d' | sed '/stylesheets/d'`
do
 svn info $file  svninfolist.txt
done
for year in 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012
do
 echo ## Last updated in $year  old-files.txt
 grep -B 11 -A 1 Last Changed Date: $year svninfolist.txt | grep 
^Path | sed 's@Path: @@'  old-files.txt
 echo   old-files.txt
done


The results are interesting, very good, not unexpected! I've omitted the 
*795* pages that have been updated over the past 5 months! Great work guys!

dj [ BOOK ]$ cat old-files.txt
## Last updated in 2002

## Last updated in 2003

## Last updated in 2004

## Last updated in 2005
postlfs/security/syslog.xml
postlfs/security/nessus.xml

## Last updated in 2006

## Last updated in 2007
networking/netprogs/othernetprogs.xml
appendices/creat-comm.xml
book/dedication.xml
book/errata.xml
archive/obsolete/nautilus-media.xml
archive/obsolete/gal.xml
xincludes/X11R6_symlink.xml
xincludes/scrollkeeper-dir.xml
xincludes/kde-apidocs.xml
xincludes/kde-sysconfdir.xml
xincludes/lib-config.xml
xincludes/use-unzip.xml
postlfs/filesystems/ext3.xml
postlfs/config/skel.xml
postlfs/config/logon.xml
postlfs/config/random.xml
postlfs/config/vimrc.xml
postlfs/config/etcshells.xml
postlfs/config/inputrc.xml
introduction/welcome/acknowledgments.xml
introduction/welcome/mirrors.xml
introduction/welcome/wiki.xml
introduction/welcome/maillists.xml
introduction/welcome/conventions.xml
introduction/welcome/newsserver.xml
introduction/welcome/packages.xml
introduction/important/bootscripts.xml
introduction/important/position.xml
introduction/important/pkgmgt.xml
introduction/important/patches.xml

## Last updated in 2008
appendices/mit-lic.xml
postlfs/config/compressdoc.xml
introduction/welcome/version.xml
introduction/important/beyond.xml

## Last updated in 2009
networking/netprogs/openssh-client.xml
general/prog/other-tools.xml
book/whoread.xml
archive/kde/devel/kdewebdev.xml
archive/kde/devel/kdesdk.xml
postlfs/config/profile.xml
introduction/welcome/askhelp.xml
introduction/important/building-notes.xml

## Last updated in 2010
gnome/gnome-intro.xml
networking/textweb/textweb.xml
general/general.xml
archive/kde/devel/devel.xml
archive/obsolete/gail.xml
archive/obsolete/gnome-keyring-manager.xml
archive/obsolete/ggv.xml
archive/obsolete/gnome-vfs-monikers.xml
archive/obsolete/eel.xml
archive/obsolete/gnome-audio.xml
archive/obsolete/gnopernicus.xml
xincludes/gtk-doc-rebuild.xml
x/x.xml
pst/pst.xml
pst/scanning/scanning.xml
pst/sgml/sgml.xml
introduction/important/important.xml
introduction/introduction.xml
server/databases/databases.xml
server/server.xml

## Last updated in 2011
networking/netlibs/libpcap.xml
networking/netprogs/rpcbind.xml
networking/netprogs/netfs.xml
networking/netutils/nmap.xml
networking/netutils/traceroute.xml
networking/connect/ppp.xml
networking/connect/connect.xml
networking/textweb/links.xml
networking/networking.xml
appendices/glossary.xml
general/prog/svnserver.xml
general/prog/gc.xml
general/prog/librep.xml
general/prog/slang.xml
general/genlib/talloc.xml
general/sysutils/sysstat.xml
general/sysutils/gpm.xml
general/sysutils/eject.xml
general/sysutils/fcron.xml
general/graphlib/aalib.xml
general/graphlib/jasper.xml
general/genutils/rxvt-unicode.xml
general/genutils/rep-gtk.xml
archive/kde/add/kdegames.xml
archive/kde/add/kdeadmin.xml
archive/kde/add/kdemultimedia.xml
archive/kde/kde-intro.xml
archive/kde/core/core.xml
archive/kde/core/config.xml
archive/kde/core/pre-install-config.xml
archive/obsolete/gpdf.xml
postlfs/config/bootdisk.xml
postlfs/editors/joe.xml
postlfs/security/tripwire.xml
x/installing/xorg7.xml
x/wm/sawfish.xml
x/wm/fluxbox.xml
pst/sgml/openjade.xml
pst/printing/lprng.xml

## Last updated in 2012
Snip 795 udpated pages

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Fwd: [ANNOUNCE] X11R7.7

2012-06-07 Thread DJ Lucas

On 06/07/2012 03:16 AM, Armin K. wrote:
 Yay, finally!

Excellent! Want to update the book? :-) If not, I'll try and get to it 
on Monday. The only changes I had planned for it are adding a note about 
katamari and why our version number is what it is for the full 
distribution and then separating printproto, libXp, and xinit from the 
wget lists since they are not part of the katamari.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] OpenJDK Test failures

2012-06-06 Thread DJ Lucas

  On 06/02/2012 09:32 PM, DJ Lucas wrote:
 Okay, so digging into the test results on the new OpenJDK/IcedTea, the
 following jdk test failures can be ignored while testing on icedtea-2.2:

 Just append the following to icedtea-2.2/test/jtreg/excludelist.jdk.jtx
 to actually skip the tests

Snip

In addition to the above, I've found that RedHat is using Xvfb to run 
the display tests...

export DISPLAY=:20
http://pkgs.fedoraproject.org/gitweb/?p=java-1.7.0-openjdk.git;a=blob;f=java-1.7.0-openjdk.spec;h=9bfd2949fb14ac75590148a3eb064b90166081a3;hb=f2f1a7cb522137f2078b9a75388efa7c53fce8df#l918Xvfb
 :20 -screen 0 1x1x24 -ac 

echo $!  Xvfb.pid
make jtregcheck -k
http://pkgs.fedoraproject.org/gitweb/?p=java-1.7.0-openjdk.git;a=blob;f=java-1.7.0-openjdk.spec;h=9bfd2949fb14ac75590148a3eb064b90166081a3;hb=f2f1a7cb522137f2078b9a75388efa7c53fce8df#l921kill
 -9 `cat Xvfb.pid`
http://pkgs.fedoraproject.org/gitweb/?p=java-1.7.0-openjdk.git;a=blob;f=java-1.7.0-openjdk.spec;h=9bfd2949fb14ac75590148a3eb064b90166081a3;hb=f2f1a7cb522137f2078b9a75388efa7c53fce8df#l922unset
 DISPLAY
http://pkgs.fedoraproject.org/gitweb/?p=java-1.7.0-openjdk.git;a=blob;f=java-1.7.0-openjdk.spec;h=9bfd2949fb14ac75590148a3eb064b90166081a3;hb=f2f1a7cb522137f2078b9a75388efa7c53fce8df#l923rm
 -f Xvfb.pid

...that handles the screensaver and screen blank settings, and gets us 
away from any WM discrepancies and user interaction. I'm not so sure 
about 1x1 but if it works, great. I'm going to give that a shot with the 
tests removed for WM compat put back and see where we are. Hopefully 
I'll have the book updated later this afternoon with whatever results I 
have. I have come to the conclusion that the test suite is just too 
fragile to be run on a system that is doing anything else, though it is 
much improved over the ~180 failures in the IT6 version. My plan for the 
book is for any test that I've restored that still results in failure to 
be removed again, as well as the NSS dependent tests that seem to still 
be broken, and leave the current note with an estimated 60 failures 
since my results are fairly consistent on both supported arches. With 
the other 17 removed, I'm down to zero failures on both if I do nothing, 
but I'm also in a very limited, and dedicated environment. Test time 
outs occur while copying the resultant j2sdk out of the source tree for 
instance. While Xvfb does give some of that back, I'm not convinced that 
the suite itself is ready for a perfect run by an end user, there are 
just too many environmental factors to consider (nor would I expect a 
user to adhere to such a limiting set of expectations).

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] OpenJDK Test failures

2012-06-06 Thread DJ Lucas

On 06/06/2012 11:09 AM, DJ Lucas wrote:
On 06/02/2012 09:32 PM, DJ Lucas wrote:
 Okay, so digging into the test results on the new OpenJDK/IcedTea, the
 following jdk test failures can be ignored while testing on icedtea-2.2:

 Just append the following to icedtea-2.2/test/jtreg/excludelist.jdk.jtx
 to actually skip the tests

 Snip

 In addition to the above, I've found that RedHat is using Xvfb to run
 the display tests...

 export DISPLAY=:20
 http://pkgs.fedoraproject.org/gitweb/?p=java-1.7.0-openjdk.git;a=blob;f=java-1.7.0-openjdk.spec;h=9bfd2949fb14ac75590148a3eb064b90166081a3;hb=f2f1a7cb522137f2078b9a75388efa7c53fce8df#l918Xvfb
  :20 -screen 0 1x1x24 -ac
 
 echo $!  Xvfb.pid
 make jtregcheck -k
 http://pkgs.fedoraproject.org/gitweb/?p=java-1.7.0-openjdk.git;a=blob;f=java-1.7.0-openjdk.spec;h=9bfd2949fb14ac75590148a3eb064b90166081a3;hb=f2f1a7cb522137f2078b9a75388efa7c53fce8df#l921kill
  -9 `cat Xvfb.pid`
 http://pkgs.fedoraproject.org/gitweb/?p=java-1.7.0-openjdk.git;a=blob;f=java-1.7.0-openjdk.spec;h=9bfd2949fb14ac75590148a3eb064b90166081a3;hb=f2f1a7cb522137f2078b9a75388efa7c53fce8df#l922unset
  DISPLAY
 http://pkgs.fedoraproject.org/gitweb/?p=java-1.7.0-openjdk.git;a=blob;f=java-1.7.0-openjdk.spec;h=9bfd2949fb14ac75590148a3eb064b90166081a3;hb=f2f1a7cb522137f2078b9a75388efa7c53fce8df#l923rm
  -f Xvfb.pid

Oops...

That should read

export DISPLAY=:20
Xvfb :20 -screen 0 1x1x24 -ac
echo $!  Xvfb.pid
make jtregcheck -k
kill -9 `cat Xvfb.pid`
unset DISPLAY
rm -f Xvfb.pid

-- DJ Lucas





-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] OpenJade requires Perl4::Corelibs

2012-06-05 Thread DJ Lucas

FYI, getopts is gone, so we may see a bit more of this.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] OpenJade requires Perl4::Corelibs

2012-06-05 Thread DJ Lucas

On 06/05/2012 04:33 AM, Armin K. wrote:
 On 06/05/2012 11:20 AM, DJ Lucas wrote:
 FYI, getopts is gone, so we may see a bit more of this.

 -- DJ Lucas



 I have used this patch to build OpenJade with perl 5.16.0 ... And 
 since the perl script is only used for some locale related files 
 generation, I think it should be enough. There is also patch from BLFS 
 combined with this one.

LOL. In my defense, It is 4:40 AM here! But yeah, I guess that putting 
back one fairly simple function is a little easier than installing 
several of them globally. :-)

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] OpenJDK and libreoffice-3.5.4.2 failures (Was: OpenJDK Test failures)

2012-06-04 Thread DJ Lucas

On 06/04/2012 01:15 PM, Fernando de Oliveira wrote:
 1.7 is not a supported Java bytecode version!
Looks like this has been fixed upstream, but may require a backport. 
When was the current version of LibreOffice released? You can try to get 
rid of the bytecode check in configure.ac, and then do ./autogen.sh and 
see if it works, but if it was released before February, then you will 
need the hsqldb changes also mentioned here.

http://comments.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/24011

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Fwd: [ANNOUNCE] libX11 1.5.0

2012-06-02 Thread DJ Lucas

On 06/02/2012 04:49 AM, Armin K. wrote:
 At last. You can start upgrading Xorg section now.

 --

Not quite. There are still two outstanding bugs

https://bugs.freedesktop.org/showdependencytree.cgi?id=47255hide_resolved=0

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] OpenJDK Test failures

2012-06-02 Thread DJ Lucas

javax/swing/JTableHeader/6889007/bug6889007.java
javax/swing/JTextArea/4697612/bug4697612.java
javax/swing/JTree/6263446/bug6263446.java
javax/swing/JTree/6505523/bug6505523.java
javax/swing/JViewport/7107099/bug7107099.java
javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java
javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java
javax/swing/Security/6657138/ComponentTest.java
javax/swing/SwingUtilities/4917669/bug4917669.java
javax/swing/text/CSSBorder/6796710/bug6796710.java
javax/swing/text/DefaultEditorKit/4278839/bug4278839.java

# Still using LCMS1 (replacement LCMS2 tests need backports from java 8 
tree)
sun/java2d/cmm/ColorConvertOp/MTSafetyTest.java
sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java

# Invalid test case of initializer (constant)
sun/net/idn/TestStringPrep.java

# Fails to compile
sun/security/ec/TestEC.java
###

Likewise, the one langtools test failure can be ignored:

Append to icedtea-2.2/test/jtreg/excludelist.langtools.jtx to exclude it.

###
# Fails to compile
tools/javac/processing/6499119/ClassProcessor.java
###


The above gets me down to only a few failures, 17 actually. Obviously, 
some failures I could not simply explain away, but the mass majority of 
them do seem to be easily explained (invalid tests for one reason or 
another). I am unsure of the reason for the NSS failures. These same 
tests used to fail when building without NSS, but with NSS they 
shouldn't (this may also prove yet to be a classpath error). Perhaps 
they simply haven't caught up. I did see something about a wrap failure 
that might explain the ucrypto tests, and possibly some other fixes for 
some of the remaining failures. If these upstream fixes check out after 
testing, they'll be included in a yet to be determined patch (individual 
tests have to be patched in the source tree after expansion of the 
project tarballs). x86_64 bin package will be up in a little bit, and 
I'll try and get an i686 build done on Monday or Tuesday (and book 
updated at that time).

http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK-1.7.0.4/

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] icedtea notes

2012-05-24 Thread DJ Lucas

On 05/23/2012 12:02 PM, Bruce Dubbs wrote:
 Bruce Dubbs wrote:

 The second time through the build/test not going through ssh seems to
 have a lot fewer errors but I've probably still got a couple of hours to
 go.  I'll give a final result tomorrow.
 OK, here are some results:

 Sources directory 195M
 Build directory:  6.8G  (at one time grew to at least 7.2G)
 /opt/icedtea-bin  423M
 /opt/OpenJDK-1.7.0.3  422M
 rhino1_7R3 17M
 /usr/share/java   2.5M

 Build time (minutes) 74:35  ( 44 SBU)
 Test time (minutes) 216:59  (129 SBU)

 Internally in the log I found:

 -- Build times --
 Target all_product_build
 Start 2012-05-22 21:16:55
 End   2012-05-22 22:09:15
 00:06:56 corba
 00:07:29 hotspot
 00:00:18 jaxp
 00:01:06 jaxws
 00:35:52 jdk
 00:00:39 langtools
 00:52:20 TOTAL


 -- Build times --
 Target all_product_build
 Start 2012-05-22 22:09:22
 End   2012-05-22 22:30:12
 00:01:38 corba
 00:07:10 hotspot
 00:00:20 jaxp
 00:00:24 jaxws
 00:10:41 jdk
 00:00:37 langtools
 00:20:50 TOTAL

 -- Build times --
 Target all_product_build
 Start 2012-05-22 22:30:51
 End   2012-05-22 22:33:01
 00:00:02 corba
 00:00:07 hotspot
 00:00:03 jaxp
 00:00:07 jaxws
 00:01:46 jdk
 00:00:05 langtools
 00:02:10 TOTAL

 -- Build times --
 Target all_product_build
 Start 2012-05-22 22:33:03
 End   2012-05-22 22:35:24
 00:00:04 corba
 00:00:11 hotspot
 00:00:03 jaxp
 00:00:05 jaxws
 00:01:54 jdk
 00:00:04 langtools
 00:02:21 TOTAL

 Test results: passed: 144
 Report written to test/hotspot/JTreport/html/report.html

 Test results: passed: 3,959; failed: 136; error: 10
 Report written to test/jdk/JTreport/html/report.html

 Test results: passed: 1,920; failed: 1
 Report written to test/langtools/JTreport/html/report.html

 ===

 The number of hotspot and langtools failures are the same as DJ's, but I
 got 136 failures in the jdk where DJ only got 78.  In particular, I got
 28 failures in com/sun/jdi/ where DJ got none.
Hmm...JDI is the debug interface. I don't have an immediate explanation 
for that. Do you have traditional debugging tools available in the 
environment? They should not have an effect, but at the time I tested, I 
did not have them available.

 I also gor 29 failures
 in java/awt/ where DJ got 12.

This could be due to the window manager. I always sit and watch it 
through the tests. There were a couple where my login window was to 
blame when it was trying to iconify and restore windows. Also, root or 
unprivileged user? My results were obtained as an unprivileged user, 
using TWM on a fairly minimal system (just enough to meet required and 
recommended deps).

On a side note, 2.2 is scheduled for release next Wednesday (5/30). I 
don't anticipate any changes in the options or dependencies. 2.2 will 
basically be the same as the Oracle 7u4 with some of the security 
updates that are slotted for 7u5, along with the typical build fixes for 
newer system software and the closed parts of the software replaced by 
free software (easily arguable as _better_ replacements (pulse for the 
old sgi audio for example)). Basically, just disregard the upstream 
fixes patch and build as before. Existing 2.1 builds should work fine as 
a bootstrap compiler, however, we'll be pulling the downloads from git 
again (make download if you have wget installed, the all target will 
also get them for you in one step).
 I don't know if these differences is due to different HW (e.g. cheap
 video), installed packages, or are even due to kernel configuration.
 For instance I got an error in NoUpdateUponShow where DJ did not:

 JavaTest Message: Test threw exception:
 sun.awt.SunToolkit$OperationTimedOut: 10001

 I did take some pains to ensure the screensaver did not kick in.

 ==

 The open question is how we should address the test failures in the book.


Unfortunately, until I hear back from the other maintainers on their 
test suite results, I really have nothing to go on. I know one of the 
core ITW developers had mentioned that he was working on a public repo 
for test results in private message, but as I understand it, he has 
about as much free time as I do lately. :-) Perhaps I should just 
install Fedora or Debian and build from their respective sources to make 
a meaningful comparison. In the grand scheme of things, the numbers are 
small in comparison to the number of tests, and not that different from 
what is in the book now which was deemed OK previously (by me using 
comparison with the other distros)...at least once the mystery is solved 
about the JDI tests. Maybe we should consider dropping the -samevm flag 
as one failure could conceivably cause a whole group of tests to fail if 
the running environment gets trashed. The downside to that is that a new 
VM is created for each test, which has a rather obvious effect on the 
wall clock.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed

Re: [blfs-dev] Observations about firefox and xulrunner

2012-05-19 Thread DJ Lucas

On 05/19/2012 04:20 AM, Andrew Benton wrote:
 On Sat, 19 May 2012 01:01:28 +0100
 Bruce Dubbsbruce.du...@gmail.com  wrote:

 For FF, the command

 tar -xvf firefox-build-dir/dist/firefox-12.0.en-US.linux-$(uname
 -m).tar.bz2 -C /usr/lib/firefox-12.0 --strip-components=1

 hung on me.  I already had a /usr/lib/firefox-12.0 directory with items
 installed from previous builds, but deleting all the files there allowed
 the instruction ot complete.  We may want to do something like:

 rm -rf /usr/lib/firefox-12.0
 mkdir /usr/lib/firefox-12.0
 Fair enough, it never occurred to me that people may be reinstalling
 Firefox.

 The instructions on the firefox page says:

If you have linked against an already installed Xulrunner, as the root
 user:

 make -C firefox-build-dir install
 ...

 My problem was that I didn't have a firefox-build-dir directory
 Then you must have altered your mozconfig or make -f client.mk failed.
Yes, despite the lack of --enable-application=firefox in the mozconfig 
file, I still had this directory and the instructions worked as 
expected. I believe it is defined in one of the deeper config.mk 
files...it's been a while since I played in the combined source tree.
 I think we may need to clarify that make -f client.mk is still required
 but the options

 # ac_add_options --with-system-libxul
 # ac_add_options --with-libxul-sdk=/usr/lib/xulrunner-devel-12.0

 will bypass most of the long build.
Yes, maybe simply provide the full build SBU and a note that this will 
reduce the build to about 0.3 SBU.
 The page says Compile Firefox by issuing the following commands:
 (which include make -f client.mk) and in the mozconfig it says:
 # The rest of these options have no effect if you're
 # building against an already installed xulrunner:

 I don't see why anyone would want to install xulrunner. I don't think
 the Firefox page should mention xulrunner. It is complicated enough to
 describe the options without xulrunner, adding a useless xulrunner into
 the mix doesn't help.

Just because you don't see a use for it, doesn't mean the rest of us 
don't. I am perfectly fine with only Firefox providing our dev tools (In 
fact, I'd even prefer it at this point), but it does require a fair bit 
of work to make a *complete* Firefox build (something the book hasn't 
done since around 2008, maybe earlier) and even then it was a bit messy 
(see the old OpenOffice system mozilla patches for an example). If you 
want XUL gone from the book, good luck, but it is possible to replace 
it's individual functionality with Firefox, and that includes the 
development libs and the XUL pc files, or at least some method for 
building plug-ins (so we can hack up the few dependent packages to use 
firefox-plugin.pc or whatever is needed). Alternately, we just continue 
to build Firefox against XUL with the option to build stand-alone for 
those who don't need it.

Again, if you can get an --enable-application=firefox build to produce 
everything that we need, then great! I'm all for it, and may be able to 
help out after I finish up Java. The only test cases left in the book 
that I am sure of are OpenJDK and IcedTea-Web, but I believe LibreOffice 
can still use it too. It would be a shame if we lost mail-merge 
functionality with thunerbird/seamonkey (and the browser plug-in was 
actually nice to have on occasion). One popular external example is 
gecco-media-player, and of course, there are literally thousands of 
others that I personally happen to find useless, most of which provide 
working binaries.

Also, what is the status of the merged projects now, IOW is TB/SM still 
building a hacked up XUL for the MozAB or is it all in one again? It 
would be really nice if we could get down to a ~60MB XUL install and two 
tiny installs for Firefox and Thunderbird (or somewhere there abouts). 
FYI, my Firefox build size is 420MB and my install size is 3MB. If TB 
can build against an installed XUL, then maybe SM could too...any 
arguments for removing XUL would certainly be killed if that were the case.

-- DJ


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] [blfs-book] r10221 - trunk/BOOK/xsoft/graphweb

2012-05-19 Thread DJ Lucas

Bruce Dubbs bruce.du...@gmail.com wrote:

a...@linuxfromscratch.org wrote:
 Author: andy
 Date: 2012-05-19 16:21:51 -0600 (Sat, 19 May 2012)
 New Revision: 10221
 
 Modified:
trunk/BOOK/xsoft/graphweb/firefox.xml
 Log:
 Neither Seamonkey or Thunderbird can use xulrunner

Really?  I haven't tried but Wikipedia says:

All XUL-based applications like Mozilla Firefox, Mozilla Thunderbird, 
Songbird, Flickr Uploadr, SeaMonkey, Conkeror, Sunbird, Miro, Joost,
and 
TomTom Home 2.0 run on XULRunner.

I haven't validated that, but I'll investigate some more.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

TB and SM used to require many changes to xpcom for mozab, not sure this is the 
case any more, I haven't tried since 4.0 or so. It was supposed to be one code 
base and they were getting close at that time.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Observations about firefox and xulrunner

2012-05-18 Thread DJ Lucas

On 05/18/2012 06:41 PM, Bruce Dubbs wrote:
 When I started FF, I looked at Help-About.  Since I was using twm, I
 couldn't close that window!  There is no close button for 'About' and
 twm doesn't have a window close function that I could find.  This isn't
 a BLFS issue, but I thought it was worthy of comment.
Yes, the old Ctrl+Shift+W went away it seems. Keyboard shortcuts for 
special windows such as downloads and bookmarks still toggle correctly 
though. Wonder why they did that.

-- DJ


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] OpenJDK downloads

2012-05-17 Thread DJ Lucas

On 05/16/2012 10:52 PM, Fernando de Oliveira wrote:
 On 16-05-2012 22:22, Fernando de Oliveira wrote:
 On 14-05-2012 20:26, DJ Lucas wrote:
 On 05/14/2012 10:38 AM, Fernando de Oliveira wrote:
 --- Em seg, 14/5/12, DJ Lucas escreveu:

 De: DJ Lucas
 Assunto: [blfs-dev] OpenJDK downloads
 Para: BLFS Development List
 Data: Segunda-feira, 14 de Maio de 2012, 2:16
   The makefile will download the needed files as part of the build 
 process (alternately you can use the download make target).
 I will try one of these in my next build. Think It sould be this way in the 
 book, like LibreOffice, so, in the next version, book's instructions could 
 be used just changing the version. I believe that the versions in Anduin 
 will be useless then.
 I have not built on i686 yet. Help would be appreciated
 here, but I'll get to it in a few days if nobody steps up. I've included
 a tar.xz extract of the Fedora i686 RPM to use as an initial bootstrap
 compiler. If anybody would like to create the i686 binary, please do a
 bootstrap build using the Fedora JDK, followed by a bootstrap using the
 previously created one, and then tar it up with the format of the x86_64
 file, after having run the test suite against the final. I'm currently
 looking into the few remaining test suite failures, but I suspect a
 number of them are related to running in twm (windows not automatically
 anchored in awt tests).
 I had a fatal failure in make, due to the fact that oracle jdk was installed 
 and found by configure. Moved out the /opt/jdk* (link and versioned dir), 
 and still failed. Next, linked /opt/jdk to icedtea-bin, and next failure: no 
 cpio. so, cpio is a requirement. Had noticed this requirement months ago 
 also in book's version.

 Phase1: using Fedora-bin
 Phase2: using New-bin

 I have done phase 1

 START - Building OpenJDK-1.7.0.3-i686-bin - Qua Mai 16 14:41:02 BRT 2012
 END - Building OpenJDK-1.7.0.3-i686-bin - Qua Mai 16 18:32:12 BRT 2012

 real231m10.016s
 user156m43.051s
 sys 36m36.799s

 For make -j1: 66m22.809s
 For make -k jtregcheck:  164m15.324s


 For phase2, after make, the tests are running, now.

 Please, keep on reading below.

 Files are available here:
 Bin builds:
 http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/OpenJDK-1.7.0.3-x86_64-bin.tar.xz
 or
 http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/java-1.7.0-openjdk-1.7.0.3-i686-fedora-18.tar.xz

 Source files:
 http://icedtea.classpath.org/download/source/icedtea-2.1.tar.gz
 http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/corba.tar.gz
 http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/hotspot.tar.gz
 http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/jaxp.tar.gz
 http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/jaxws.tar.gz
 http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/jdk.tar.gz
 http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/langtools.tar.gz
 http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/openjdk.tar.gz
 ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_7R3.zip

 Patches:
 http://www.linuxfromscratch.org/patches/downloads/icedtea/icedtea-2.1-upstream_fixes-2.patch
 http://www.linuxfromscratch.org/patches/downloads/icedtea/icedtea-2.1-fixed_paths-1.patch
 http://www.linuxfromscratch.org/patches/downloads/icedtea/icedtea-2.1-add_cacerts-1.patch


 Instructions:

 Extract the binary installation, and move it to /opt/icedtea-bin
 Extract Rhino and put the js.jar and js-14.jar files into /usr/share/java

 Extract the icedtea-2.1 tarball as would normally be done.
 link the other tar.gz downloads into the source tree:

 ln -s ../openjdk.tar.gz .
 ln -s corba.tar.gz .
 ln -s jaxp.tar.gz .
 ln -s jaxws.tar.gz .
 ln -s jdk.tar.gz .
 ln -s langtools.tar.gz .
 ln -s hotspot.tar.gz .
 Of course, ln -s ../ everywhere, above, right?

 Apply the patches and prep for build:

 patch -Np1 -i ../icedtea-2.1-upstream_fixes-2.patch
 patch -Np1 -i ../icedtea-2.1-fixed_paths-1.patch
 patch -Np1 -i ../icedtea-2.1-add_cacerts-1.patch
 ./autogen.sh


 Finally, build and install the thing:

 ./configure --with-jdk-home=/opt/icedtea-bin \
   --enable-nss \
   --enable-pulse-java
 Here, failure, as I do not have pulse installed, so, another requirement, 
 and --enable-pulse-java was dropped. Having read troubles from others with 
 puse, which I do no need untill now, after finished current build, will make 
 a copy of this machine to install pulse and rebuild. This will be done after 
 I install xulrunner and build IcedTea plugin.

 make
 Here, race failure, with make -j4. Used -j1. Same behavior in phase 1 and 2.

 make -k jtregcheck
 For phase1:

 $ grep Test results 
 /home/fernando/Downloads/blfs/OpenJDK-1.7.0.3-i686-bin-with-Fedora-2012.05.16.log
 Test results: passed: 144
 Test results: passed: 3,643; failed: 452; error: 10
 Test results: passed: 1,920; failed: 1
 Test results: passed: 144
 Test results: passed: 3,643; failed: 452; error: 10
 Test results: passed: 1,920

Re: [blfs-dev] OpenJDK downloads

Pierre Labastie pierre.labas...@neuf.fr wrote:

Le 15/05/2012 01:26, DJ Lucas a écrit :

Okay, well this is gonna be ugly compared to typical book
instructions,
but: x86_64 production bin file is in place. It no longer includes
IcedTea-Web. I have not built on i686 yet. Help would be appreciated
here, but I'll get to it in a few days if nobody steps up. I've
included
a tar.xz extract of the Fedora i686 RPM to use as an initial
bootstrap
compiler. If anybody would like to create the i686 binary, please do
a
bootstrap build using the Fedora JDK, followed by a bootstrap using
the
previously created one, and then tar it up with the format of the
x86_64
file, after having run the test suite against the final. I'm
currently
looking into the few remaining test suite failures, but I suspect a
number of them are related to running in twm (windows not
automatically
anchored in awt tests).

Files are available here:
Bin builds:

http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/OpenJDK-1.7.0.3-x86_64-bin.tar.xz
or

http://anduin.linuxfromscratch.org/files/BLFS/OpenJDK/java-1.7.0-openjdk-1.7.0.3-i686-fedora-18.tar.xz

[...files and installation instructions]

Thanks for the instructions. Will give it a try, but what about the
deps? Is xulrunner really needed?

Pierre

--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

Not any more as I don't include icedtea web...but nss should be recommended s
well as pulse. Giflib, cups, and libXp are required.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] iced tea web

On 05/14/2012 08:43 PM, DJ Lucas wrote:
 On 05/12/2012 12:10 AM, Bruce Dubbs wrote:
 Looking at iced tea web, it looks like xulrunner is a required dependency.  
 It's
 looking for mozilla-plugin.pc.  When I search the web, it looks like that's 
 the
 only thing that installs it.  Not sure though.

  -- Bruce
 We should probably backport the --with-gtk={3,2} patch that came across
 on 5/11, else if built against gtk-2 and used with Midori, Epiphany, or
 other webkit based browsers built against gtk+-3, it will fail to work.

 -- DJ Lucas


Tested, checks OK. I'll add it when I do the new OpenJDK instructions if 
not done before then.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Recent build notes

On 05/15/2012 06:18 PM, Ken Moffat wrote:
 On Tue, May 15, 2012 at 05:44:14PM -0500, DJ Lucas wrote:
 Couple of things I noticed on my latest build.

 The DRM backend is broken in cairo with Xorg-7.7, no idea if this is the
 result of the export symbols patch or latest xorg. Anybody built it?
 (probably unused)

   I think my recent build was still on cairo-1.12.0 and
 libdrm-2.4.33.  Does the backend fail to build, or fail at runtime ?
 Do you have to enable it specifically in the build, and is there
 an easy test to prove it works ?

 ĸen
You have to specifically enable it, it fails at build time, and nothing 
uses it yet AFAIKhence why I didn't dig in further.

-- DJ


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Recent build notes

On 05/15/2012 06:57 PM, Andrew Benton wrote:
 On Tue, 15 May 2012 23:54:06 +0100
 DJ Lucasd...@linuxfromscratch.org  wrote:

 Couple of things I noticed on my latest build.

 The DRM backend is broken in cairo with Xorg-7.7, no idea if this is the
 result of the export symbols patch or latest xorg. Anybody built it?
 (probably unused)
 I spent an evening working on trying to build with --enable-drm and
 gave up. I could get past each error but after fixing about 15 or 20
 bugs I gave up. It seems to be unmaintained code.

I never bothered to build it before. I started down the same path, but 
gave up after the second mismatch figuring there would be more to fix.
 Ghostscript lists lcms as a dependency, it should be lcms2.
 It lists lcms2 as recommended and lcms1 as optional, or do you mean we
 should be recommending lcms1?

Indeed it does. I guess I must have been looking for little-cms-2 
because it is right there in front of me.
 Udev 182 didn't rebuild with pci-utils without a decompressed pci.ids file.

 Because of build order (a very minimal target), the firefox.desktop file
 got installed as /usr/share/applications (need to check first, and
 create the directory if necessary).
 Doh! Good point. I'll fix that tomorrow. Thanks

Yeah, I suffered a major space cadet moment on that one. Funny now, but 
I was like Permission denied? Huh? It's 755! WTH?!?! 10 minutes of the 
same cycle later the light bulb comes on. Oh...Yep I'm a dumb a**! LOL

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] OpenJDK downloads

2012-05-14 Thread DJ Lucas

On 05/14/2012 07:21 PM, Ken Moffat wrote:
 On Mon, May 14, 2012 at 06:26:56PM -0500, DJ Lucas wrote:

 I suspect a
 number of them are related to running in twm (windows not automatically
 anchored in awt tests).

   I know we include twm for a minimal build of xorg, but I didn't
 think anybody used it for a completed system.  Obviously, I'm
 missing something - for me, fluxbox is an almost-usable wm, twm is
 too painful.

   Normally, I use icewm-1.3 (which needs gtk+-2) - feel free to call
 me a wimp, but I really don't understand how you can use twm
 comfortably!

 ĸen

Heh, no I'd shoot myself if subjected to it for too long. Just meeting 
the most minimal requirements for a Java rebuild, and for that, a decent 
WM was not high prioritybut will be in about 10 minutes. That's 
still 190 packages in (-LFS packages included but not individual xorg 
packages)...probably just over the halfway point. Now I have heard that 
somebody is actually taking the time to modernize twm, but the only 
evidence I've seen of it is that it still builds against Xorg-7.7. Years 
ago I had seen some pretty elaborate twmrc setups, but I've never taken 
the time.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] iced tea web

2012-05-14 Thread DJ Lucas

On 05/12/2012 12:10 AM, Bruce Dubbs wrote:
 Looking at iced tea web, it looks like xulrunner is a required dependency.  
 It's
 looking for mozilla-plugin.pc.  When I search the web, it looks like that's 
 the
 only thing that installs it.  Not sure though.

 -- Bruce
We should probably backport the --with-gtk={3,2} patch that came across 
on 5/11, else if built against gtk-2 and used with Midori, Epiphany, or 
other webkit based browsers built against gtk+-3, it will fail to work.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] OT: twm [Was: Re: OpenJDK downloads]

2012-05-14 Thread DJ Lucas

On 05/14/2012 08:50 PM, Bruce Dubbs wrote:
 On 5/14/12, DJ Lucasd...@linuxfromscratch.org  wrote:

 Heh, no I'd shoot myself if subjected to it for too long. Just meeting
 the most minimal requirements for a Java rebuild, and for that, a decent
 WM was not high prioritybut will be in about 10 minutes. That's
 still 190 packages in (-LFS packages included but not individual xorg
 packages)...probably just over the halfway point. Now I have heard that
 somebody is actually taking the time to modernize twm, but the only
 evidence I've seen of it is that it still builds against Xorg-7.7. Years
 ago I had seen some pretty elaborate twmrc setups, but I've never taken
 the time.
 I agree that twm is not a wm that you want to spend a lot of time
 with, but it's extreme simplicity makes it a good choice for testing
 after building X.

-- Bruce
twm *can* be made to act modern-ish!

http://www.over-yonder.net/~fullermd/projects/twmrc

6 work spaces, a full applications menu (right click like flux/black), 
sane windowing behavior, etc:-)

-- DJ


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] XUL Runner and Firefox

On 05/13/2012 01:49 PM, bdu...@linuxfromscratch.org wrote:
 Author: bdubbs
 Date: 2012-05-13 12:49:25 -0600 (Sun, 13 May 2012)
 New Revision: 10201

 Modified:
 trunk/BOOK/general.ent
 trunk/BOOK/introduction/welcome/changelog.xml
 trunk/BOOK/x/lib/lib.xml
 trunk/BOOK/x/lib/xulrunner.xml
 Log:
   Restore xulrunner

Actually, I've been thinking a bit more on this one. As a compromise, we 
could probably still get rid of the XUL Runner page and use only the 
Firefox page to first build XUL Runner, and then Firefox in a separate 
build directory from only the Firefox source tarball. This is the way 
Firefox should actually be built anyway for our purposes. Without the 
dev libs, a user cannot build browser extensions from source (still 
ignoring the fact that the build tree needs to kept around). The FF 
portion of the build should take  0.1 SBU. The reason it is not done 
that way by default is that the Mozilla devs choose not to cater to 
developers, but rather end users...understandable give the huge Windows 
target, but a minor PITA for us and a source of mild disagreement. 
Anybody think this is a bad compromise?

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] XUL Runner and Firefox

On 05/13/2012 02:55 PM, Andrew Benton wrote:
 On Sun, 13 May 2012 20:13:02 +0100
 DJ Lucasd...@linuxfromscratch.org  wrote:

 Actually, I've been thinking a bit more on this one. As a compromise, we
 could probably still get rid of the XUL Runner page and use only the
 Firefox page to first build XUL Runner, and then Firefox in a separate
 build directory from only the Firefox source tarball. This is the way
 Firefox should actually be built anyway for our purposes. Without the
 dev libs, a user cannot build browser extensions from source (still
 ignoring the fact that the build tree needs to kept around). The FF
 portion of the build should take  0.1 SBU. The reason it is not done
 that way by default is that the Mozilla devs choose not to cater to
 developers, but rather end users...understandable give the huge Windows
 target, but a minor PITA for us and a source of mild disagreement.
 Anybody think this is a bad compromise?
 Yes, I think it's stupid to make people install half a gigabyte of
 files just to get a browser. Firefox works fine with 31 megabytes of
 files. Only people who want to make the java plugin will benefit from
 the extra half a gigabyte. It is years since I've installed java.

 Andy
Understood. There is an easier workaround someplace.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] XUL Runner and Firefox

On 05/13/2012 03:01 PM, Armin K. wrote:
 On 05/13/2012 09:55 PM, Andrew Benton wrote:
 On Sun, 13 May 2012 20:13:02 +0100
 DJ Lucasd...@linuxfromscratch.org   wrote:

 Actually, I've been thinking a bit more on this one. As a compromise, we
 could probably still get rid of the XUL Runner page and use only the
 Firefox page to first build XUL Runner, and then Firefox in a separate
 build directory from only the Firefox source tarball. This is the way
 Firefox should actually be built anyway for our purposes. Without the
 dev libs, a user cannot build browser extensions from source (still
 ignoring the fact that the build tree needs to kept around). The FF
 portion of the build should take   0.1 SBU. The reason it is not done
 that way by default is that the Mozilla devs choose not to cater to
 developers, but rather end users...understandable give the huge Windows
 target, but a minor PITA for us and a source of mild disagreement.
 Anybody think this is a bad compromise?
 Yes, I think it's stupid to make people install half a gigabyte of
 files just to get a browser. Firefox works fine with 31 megabytes of
 files. Only people who want to make the java plugin will benefit from
 the extra half a gigabyte. It is years since I've installed java.

 Andy
 Half a gigabyte?

 29M   /usr/lib/xulrunner
 3.6M  /usr/lib/xulrunner-devel
 24M   /usr/include/xulrunner
 6.8M  /usr/share/idl/xulrunner
 6.8M  /usr/lib/firefox

 About 70 MB when using Firefox with system Xulrunner.
Think he is referring to the build size...actually...IDK.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] XUL Runner and Firefox

On 05/13/2012 03:16 PM, Bruce Dubbs wrote:
 Armin K. wrote:
 On 05/13/2012 09:55 PM, Andrew Benton wrote:
 On Sun, 13 May 2012 20:13:02 +0100
 DJ Lucasd...@linuxfromscratch.org   wrote:

 Actually, I've been thinking a bit more on this one. As a compromise, we
 could probably still get rid of the XUL Runner page and use only the
 Firefox page to first build XUL Runner, and then Firefox in a separate
 build directory from only the Firefox source tarball. This is the way
 Firefox should actually be built anyway for our purposes. Without the
 dev libs, a user cannot build browser extensions from source (still
 ignoring the fact that the build tree needs to kept around). The FF
 portion of the build should take   0.1 SBU. The reason it is not done
 that way by default is that the Mozilla devs choose not to cater to
 developers, but rather end users...understandable give the huge Windows
 target, but a minor PITA for us and a source of mild disagreement.
 Anybody think this is a bad compromise?
 Yes, I think it's stupid to make people install half a gigabyte of
 files just to get a browser. Firefox works fine with 31 megabytes of
 files. Only people who want to make the java plugin will benefit from
 the extra half a gigabyte. It is years since I've installed java.

 Andy
 Half a gigabyte?

 29M  /usr/lib/xulrunner
 3.6M /usr/lib/xulrunner-devel
 24M  /usr/include/xulrunner
 6.8M /usr/share/idl/xulrunner
 6.8M /usr/lib/firefox

 About 70 MB when using Firefox with system Xulrunner.
 The build size is pretty big and /usr/lib/xulrunner-devel-12.0 is pretty big 
 for me.

 $ find /usr -type d -name xulrunner\* -exec du -sh {} \;
 2.4G/usr/src/firefox/mozilla-release/xulrunner-build-dir
 32M /usr/src/firefox/mozilla-release/xulrunner-build-dir/dist/xulrunner
 1.4M/usr/src/firefox/mozilla-release/xulrunner-build-dir/xulrunner
 2.2M/usr/src/firefox/mozilla-release/xulrunner
 45M /usr/src/xulrunner
 6.8M/usr/share/idl/xulrunner-12.0
 27M /usr/include/xulrunner-12.0
 475M/usr/lib/xulrunner-devel-12.0
 32M /usr/lib/xulrunner-12.0

 Most of this is in /usr/lib/xulrunner-devel-12.0/sdk/lib/libxul.so

 -rwxrwxr-x 1 root root 463M May 13 13:45 libxul.so, but stripping it gets it
 down to 24M.



Oh. Nix the -g flag in the XUL runner build and install everything. 
Firefox should be no different than any other package in BLFS.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] OpenJDK downloads