Re: [blfs-dev] Today's new packages

[Matthew Burgess]

On Tue, 20 Aug 2013 08:30:43 -0500, Bruce Dubbs  wrote:
> Developers were very busy yesterday.

> openldap2.4.35 -> 2.0.36

Looks like either a downgrade or a typo :-)

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

Re: [blfs-dev] [lfs-dev] Planning ahead

[Matthew Burgess]

On Sat, 03 Aug 2013 18:07:43 -0500, Bruce Dubbs  wrote:

> With that in mind, I would like to freeze LFS (mostly) on August 15 and
> release LFS-7.4-rc1.  The target date for LFS-7.4 will be 1 September.
> During the freeze period, some packages may be updated, but not gcc,
> binutils, or glibc.  Any update in the freeze period will be considered
> by the impact to the rest of the books - both LFS and BLFS.

I think we should also freeze the kernel major version, but allow updates
to the patch version; that is any stable updates to the 3.10.x series should
be considered on their merits during the freeze period.

Other than that, all I can say is congratulations on wrestling BLFS into
a releasable state; the amount of work being done on it is staggering.

Having just moved house, I won't have much time for the next week or so,
but hopefully after that I can start getting back in the game.

Kind Regards,

Matt.

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

Re: [blfs-dev] More BLFS Protocol

[Matthew Burgess]

On Fri, 25 Jan 2013 07:18:02 -0600, Randy McMurchy  
wrote:
> Hi all,
> 
> As long as we are on the track of discussing the book's protocol (see
> discussion
> on -book), there is another thing I'd like to mention. The patches project
> for
> years had a maintainer (hey Tushar, you out there?) who was fairly strict
> in how
> the patches must be formatted and how there were named. I'd like to
> refresh folks
> on that protocol.

Just to add to what Randy mentioned, there is documentation on the patch 
standards
at http://www.linuxfromscratch.org/patches/submit.html.

Regards,

Matt.

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

Re: [blfs-dev] Higgs Syncronization

[Matthew Burgess]

On Thu, 24 Jan 2013 08:23:47 -0600, Randy McMurchy  
wrote:
> Matthew Burgess wrote these words on 01/24/13 07:41 CST:
>> On Thu, 24 Jan 2013 07:06:22 -0600, Randy McMurchy
>  wrote:
>>
>>> randy@rmlinux: ~/Books/BLFS/BOOK > svn status -u
>>> Status against revision:  10962
>>> randy@rmlinux: ~/Books/BLFS/BOOK > svn up
>>
>> What does 'svn info' show for your URL.  I wonder if you've got
>> 'svn+ssh://quantum.linuxfromscratch.org/' in there, and not
>> 'svn+ssh://svn.linuxfromscratch.org/')?
> 
> I had 'svn+ssh://linuxfromscratch.org/' which unfortunately points to the
> quantum server. I know what is going on now. I just want to get the two
> repos
> synced together.

I'm still stuck at work for the time being, so can't do anything immediately.

Hopefully, you're OK with re-committing your changes?  I assume here that there 
have been
more commits to the higgs repo than the quantum repo?

If so, then I think you should be OK to do the following from within your 
working copy:

svn switch svn+ssh://svn.linuxfromscratch.org

(see http://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.switch.html for the docs)

>From that above link, I think your changes may well be persisted, so you 
>should be able
to resolve any conflicts and just reapply.  If not, you'll have to copy and 
paste the
commit diff from your latest commit(s) into a patch file, apply to your working 
copy, and
commit again.

We should have (obviously) switched off the svn daemon on quantum as soon as 
(or just
before) the DNS change had been applied; that would have prevented this from 
happening.
Bruce, if you see this within the next couple of hours, would you mind doing so 
please?

Thanks,

Matt.

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

Re: [blfs-dev] Higgs Syncronization

[Matthew Burgess]

On Thu, 24 Jan 2013 07:06:22 -0600, Randy McMurchy  
wrote:

> randy@rmlinux: ~/Books/BLFS/BOOK > svn status -u
> Status against revision:  10962
> randy@rmlinux: ~/Books/BLFS/BOOK > svn up

What does 'svn info' show for your URL.  I wonder if you've got
'svn+ssh://quantum.linuxfromscratch.org/' in there, and not
'svn+ssh://svn.linuxfromscratch.org/')?

Ta,

Matt.
> Updating '.':
> At revision 10962.
> 
> 
> Now here is from a fresh checkout (which must come from Higgs):
> 
> randy@rmlinux: ~/Books/BLFS/BOOK2 > svn status -u
> Status against revision:  10964
> randy@rmlinux: ~/Books/BLFS/BOOK2 > svn up
> Updating '.':
> At revision 10964.
> 
> All I can think is I need to commit the changes that I had done to the
> repo on Quantum to the repo on Higgs and then delete my old repo that
> was on Quantum. That should get me synced with the changes that Armin
> has made. I suggest that you also do a fresh checkout, Bruce.
> 
> --
> Randy
> 
> --
> http://linuxfromscratch.org/mailman/listinfo/blfs-dev
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page

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

Re: [blfs-dev] libpng 1.5.3

[Matthew Burgess]

On Fri, 04 Jan 2013 17:09:54 +0100, Tobias Gasser  wrote:
> 
> anybody out there haveing a hint how to get rid of those missing
> exported symbols?

It's been a while, but I think this is caused by the apng patch.  Try
building without it and see if 'make check' is any cleaner.

Regards,

Matt.

-- 
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

[Matthew Burgess]

On Mon, 9 Jul 2012 00:51:08 +0100, Ken Moffat  wrote:

>  I forgot to reply to this point.  I know Matt reads this list
> (unless he's been a victim of the floods), but I'm not at all
> convinced that everyone else on lfs-dev (and who has an interest in
> LFS itself, as distinct from lfs-derived variants) also reads this
> list.

Aside from being caught out on Friday afternoon, trying to get back up
to Newcastle from London, I've managed to remain unscathed.  Even then, the
diversion only added another 2 hours onto my usual train journey.

I'm up to speed on recent discussions, but haven't had anything of value
to add really, so regressed into lurk mode for a while.

Regards,

Matt.

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

Re: [blfs-dev] seamonkey-2.10 (Was: r10285 - in trunk/BOOK: .introduction/welcome xsoft/graphweb xsoft/other)

[Matthew Burgess]

On Mon, 11 Jun 2012 12:11:12 +0100, Andrew Benton  wrote:

> Yes, you're right, the patch isn't being copied across into
> http://www.linuxfromscratch.org/patches/blfs/svn
> I'm not seeing any error emails about missing patches on the BLFS Book
> list. I don't know why the script is failing.

I can't get on the LFS server from work to check, but my immediate thought on 
this is that patch is
incorrectly named.  package-manifest should be package_manifest in its name.

Regards,

Matt

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

Re: [blfs-dev] k3b

[Matthew Burgess]

On Fri, 4 May 2012 12:05:45 +0100, Andrew Benton  wrote:

> I think we removed it because we don't like Jörg Schilling

I think it's more the case that Jorg Schilling doesn't like us (Linux) :-)

I don't see any good reason to have software in the book that is going to
bitch and moan so loudly and has the potential to unnecessarily scare
users into thinking that something's wrong with their system.

Regards,

Matt.

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

Re: [blfs-dev] wpa_supplicant

[Matthew Burgess]

On Mon, 20 Feb 2012 17:31:47 +, Andrew Benton  wrote:
> On Mon, 20 Feb 2012 7:37:53 -0700
> Matthew Burgess  wrote:
> 
>> None from me.  In fact, if you want/need a wireless-newbie guinea-pig
>> I'll volunteer to proof-read and test your instructions.  I've been
>> spoiled by Windows and NetworkManager thus far, but need to get wireless
>> set up on my LFS box now.
> 
> Jolly good. So no pressure then ;)

Hmm, I think I used the word 'now' when I should have used 'next' :)

> I've put a draft up at
> http://www.linuxfromscratch.org/~andy/BLFS/wpa_supplicant.html
> It's at the point where I can't see what's wrong with it and it won't
> get any better until it's in the book and people start emailing the
> lists with problems/issues.

Wow, that was quick!  It looks pretty darn good too, so just a couple of
minor observations for now, until I play with it properly in a couple of
hours:

1) http://hostap.epitest.fi/wpa_supplicant/ mentions that it can use either
   OpenSSL or GnuTLS.  I'll be testing against GnuTLS as I'm trying to
   avoid having 2 SSL/TLS libs in this build, if at all possible.

2) The command explanations show that the WEXT driver is used, but the
   .config file also includes the RALINK driver.  Does this require a
   separate/additional explanation?  i.e. will it use 1 or the other or
   both drivers, and under what circumstances?

3) s/Alternately/Alternatively/

Thanks!

Matt.

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

Re: [blfs-dev] wpa_supplicant

[Matthew Burgess]

On Mon, 20 Feb 2012 14:27:11 +, Andrew Benton  wrote:
> Hello,
> 
> I'd like to add wpa_supplicant-0.7.3 to the book. wpa_supplicant is
> required to connect to a secure wireless access point.
> Any objections?

None from me.  In fact, if you want/need a wireless-newbie guinea-pig
I'll volunteer to proof-read and test your instructions.  I've been
spoiled by Windows and NetworkManager thus far, but need to get wireless
set up on my LFS box now.

Regards,

Matt.

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

Re: [blfs-dev] NTP

[Matthew Burgess]

On Thu, 16 Feb 2012 11:16:12 +, Andrew Benton  wrote:
> On Wed, 15 Feb 2012 18:47:37 -0800
> Qrux  wrote:
> 
>>  * So, I propose turning -x off.
> 
> I agree, I run ntpd -g
> However, I also think the ntpd bootscript will work fine for most
> people and for those (like me) who think it should be done differently
> it's trivial to edit the bootscript; your distro, your rules and all
> that ;)

It probably doesn't affect many LFSers, but Oracle's RAC installation/
configuration wizard explicitly checks for '-x' in the ntpd options.

It does this because you really don't want your database server's time
from jumping backwards, and '-x' (or 'tinker step 0' in /etc/ntp.conf)
is the only way to guarantee that won't happen.  Interestingly,
apparently Dovecot doesn't like time going backwards either; I'm sure
there are other servers that prefer a uni-directional arrow of time too.

For more 'normal' setups, I'd agree that calling 'ntpd -g -q' to do an
initial time sync at bootup, followed by ntpd without any other options
would be sufficient; the odds that the ntp pool servers most people use
are going to jump backwards are so small, I don't think it's worth
guarding against by using the '-x' option by default.

Regards,

Matt.

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

Re: [blfs-dev] bridge-utils

[Matthew Burgess]

On Wed, 25 Jan 2012 00:33:18 -0600, Bruce Dubbs  wrote:

> If I use '-net nic -net user', there are only slight connectivity
> issues.  The client IP is 10.0.x.15 but ping doesn't appear to work to
> the outside (e.g. www.linuxfromscratch.org) but ssh does.  I can't get
> any connectivity to the local (192.168.0.0) network.

If my experience with VirtualBox is anything to go by, I wouldn't bother
trying to use 'ping' as a diagnostic tool, as ICMP didn't appear to be
handled correctly by the virtual network interfaces.  Instead, simply using
telnet was more than adequate.

> My host has eth0 on 192.168.0.22.  I don't really care what the client
> IP is as long as I know what it is.   I just want to be able to ssh from
> the host to the client or vice versa.

Again, if Xen is anything like VirtualBox, then I think what you need are
two network interfaces.  One is a bridge, which is what you appear to have
already, which allows you to get to the outside world.  The other is,
in VirtualBox parlance, a host-only interface, which allows guest -> host
communication and vice versa (see 
https://www.virtualbox.org/manual/ch06.html#network_hostonly).

Regards,

Matt.

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

Re: NFS

[Matthew Burgess]

On Tue, 08 Nov 2011 21:47:41 -0600, Bruce Dubbs  wrote:

> I can confirm that libtirpc won't build and their mailing list says
> "they are working on it".

I found a workaround for libtirpc as mentioned at
http://www.linuxfromscratch.org/pipermail/lfs-book/2011-August/026887.html
but whether it's safe/correct I've no idea.

Regards,

Matt.

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

LFS-6.8-rc1 release

[Matthew Burgess]

Hi all,


The Linux From Scratch community is pleased to announce the release of
LFS Version 6.8-rc1. This is the first release candidate on the road to
LFS-6.8. It includes numerous changes to LFS-6.7 (including updates to
Linux-2.6.37, GCC-4.5.2, Glibc-2.13 and security fixes). It also includes
editorial work on the explanatory material throughout the book, improving
both the clarity and accuracy of the text.

We encourage all users to read through this release of the book and test
the instructions so that we can make the final release as good as possible.

You can read the book online [0], or download to read locally [1].

Please direct any comments about this release to the LFS development team
at lfs-...@linuxfromscratch.org. Please note that registration for the
lfs-dev mailing list is required to avoid junk email.

Regards,

Matt.

[0] http://www.linuxfromscratch.org/lfs/view/6.8-rc1/
[1] http://www.linuxfromscratch.org/lfs/downloads/6.8-rc1/

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

Re: Xorg package order

[Matthew Burgess]

On Wed, 09 Feb 2011 16:23:32 -0600, Bruce Dubbs  wrote:
> Going thru xorg for the first time in a while.
> 
> Are Xorg Utilities really a required dependency of Xorg Protocol
> Headers?  If so, why isn't the order in the book reversed so Xorg
> Utilities precedes Xorg Protocol Headers?

Yeah, I hit this in my latest build too.  Xorg Utils definitely need to
go in before Xorg Proto.  I've lost the log from that wrong-build-order-build
but at least one of the proto packages' configure script bails out because
it fails to find the util-macros package.

Regards,

Matt.

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

Re: Xorg-7.6-1 update is complete - please review

[Matthew Burgess]

On Mon, 24 Jan 2011 20:00:15 +0100, Thomas Trepl  
wrote:

> To me it seems that util-macros (part of "util") needs to be installed
> before > the "proto" part can be done. To be more exact, the "proto" needs to 
> be
> installed before makedepend (which is the second and last pkg in "util") can
> be successfully built.

Confirmed here.  Looks like xorg-proto needs to be moved back before xorg-util 
like
it was in Xorg-7.5.

Thanks,

Matt.

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

Re: Nvidia drivers and release candidate kernels

[Matthew Burgess]

On Tue, 05 Oct 2010 16:03:10 -0400, jon  wrote:
> Hello,
> 
> This is the second time I've had problems installing the proprietary
> NVIDIA (Geforce 8200) drivers after deciding to try an -rc
> kernel. Is this an ongoing issue? It seemed I'd found a solution a while
> ago but when I tried the /customized/ build of the drivers I had around
> it didn't solve the problem. Tried the latest:
> NVIDIA-Linux-x86-256.53.run and got nowhere.

Well, I guess that's what you get for using closed-source binary blobs :-)

It's been ages since I've touched those particular bits, as I no longer
have an Nvidia card.  My only suggestion would be to try out the
nouveau drivers instead.  I don't know how feature-complete they are,
but at least if you run into trouble you can contact relevant
mailing lists for advice/fixes, and I'm sure they'd appreciate your
testing efforts.

The advantage is that they're in-tree (under Device Drivers ->
Staging drivers) so are more likely to be consistent with the rest of
the kernel code.  You may also want to build libdrm (see BLFS) and
have Xorg and other bits from BLFS that can utilise libdrm do so.

Regards,

Matt.

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

Re: Go-OO vs. OOo - Opinions?

[Matthew Burgess]

On Fri, 16 Jul 2010 23:19:22 -0500, William Immendorf 
 wrote:
> and it increases Mono dependence (Mono, for those who
> don't know, is a patent trap disguised as a C#/VB compiler).

Whilst I share the same opinions about mono, you did see the '--disable-mono' 
flag in
DJ's build instructions, didn't you? :)

Regards,

Matt.

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

Migrating Expat to LFS

[Matthew Burgess]

Hi all,

On a recent rebuild of LFS-svn I attempted an upgrade to
Gettext-0.18.  That resulted in one of the xgettext tests
failing because there is an assumption that xgettext will
support Glade files.  That support requires Expat to be
present.

I reported the test failure upstream [0], where the
Expat expectation was confirmed.

I don't think that moving Expat from BLFS to LFS will be
a particularly contentious issue, so this is really just
a heads up.  Obviously, if anyone wants to object, feel
free to, and I/we will consider your arguments.

Regards,

Matt

[0] http://lists.gnu.org/archive/html/bug-gnu-utils/2010-05/msg00032.html

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

Re: KDE4

[Matthew Burgess]

On Wed, 10 Mar 2010 11:40:29 +0300, Petr Ovtchenkov  wrote:
> On Wednesday 10 March 2010 10:25:16 Thomas Trepl wrote:
>> ... There
>> are servers which adds another layer over other servers
> (virtuoso->mysql),
>> there are (if i understood that dependency right) systems talking via
> ODBC(!)
>> to each other, just to have a desktop. Its a fact that we need a
> SQL-server
>> for a *desktop* environment!
> 
> Akonadi (i.e. PIM in KDE4) require MySQL. KMail's mails storage ported to
> Akonadi
> in KDE4.5...

What's wrong with maildir or mbox as mail storage formats?  Aside from that,
why a SQL database for emails?  I can't see any relational data there at all.

If it really must be in a SQL DB, then why not use an ORM to abstract away
the details so that I can plug it into the RDBMS of my choice (I happen to
use PostGreSQL for other things).

I guess this is the wrong forum to be ranting in about this though, and as
others have pointed out, walking away from the behemoth that is KDE now is
an option open to anyone, like me, who's had enough of the bloat.

Regards,

Matt.

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

LFS-6.6 is released

[Matthew Burgess]

Hi,

I'm pleased to announce the release of LFS Version 6.6. This release 
includes numerous changes to LFS-6.5 (including updates to 
Linux-2.6.32.8, GCC-4.4.3, Glibc-2.11.1) and security fixes. It also 
includes editorial work on the explanatory material throughout the book, 
improving both the clarity and accuracy of the text.

You can read the book online[0], or download[1] to read locally.

Please direct any comments about this release to the LFS development 
team at lfs-...@linuxfromscratch.org. Please note that registration for 
the lfs-dev mailing list is required to avoid junk email.

Regards,

Matt.

[0] http://www.linuxfromscratch.org/lfs/view/6.6/
[1] http://www.linuxfromscratch.org/lfs/downloads/6.6/
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

LFS 6.6-rc1 is released

[Matthew Burgess]

Hi all,

I'm pleased to announce the release of LFS Version 6.6-rc1. This release 
includes numerous changes to LFS-6.5 (including updates to 
Linux-2.6.32.7, GCC-4.4.3, Glibc-2.11.1) and security fixes. It also 
includes editorial work on the explanatory material throughout the book, 
improving both the clarity and accuracy of the text.

You can read the book online at [0], or download at [1] to read locally.

Please direct any comments about this release to the LFS development 
team at lfs-...@linuxfromscratch.org. Please note that registration for 
the lfs-dev mailing list is required to avoid junk email.

Regards,

Matt.

[0] http://www.linuxfromscratch.org/lfs/view/6.6-rc1/
[1] http://www.linuxfromscratch.org/lfs/downloads/6.6-rc1/
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

NSS only installs nss-config binary + libs

[Matthew Burgess]

Hi all,

Is there a reason particular reason why this line:

install -v -m755 $NSS_LINUXDIR/bin/nss-config /usr/bin &&

only installs nss-config and isn't, for example:

install -v -m755 $NSS_LINUXDIR/bin/* /usr/bin &&

The reason I ask is that neon can make use of certutil & pk12util from 
the NSS package, but they aren't currently installed.

Regards,

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

Re: Trying to fix this Dash issue upstream,

[Matthew Burgess]

On Tue, 1 Dec 2009 06:33:52 -0600, William Immendorf  
wrote:
> On Tue, Dec 1, 2009 at 1:56 AM, Matthew Burgess
>  wrote:
>> No, as discussed before, it is a patched coreutils issue.  There was a
>> bug in one of my versions of the coreutils i18n patches which caused
>> this.  What version of coreutils are you using, and what version of the
>> patch?
> I know it's a patched Coreutils issue, but Herbert dosen't, and I'm
> using LFS 6.5. That's what I meant. Just see:

You seem to be missing the point I was making though.  This is not a bug in 
"patched Coreutils" (i.e taking coreutils upstream + Fedora's i18n patch which 
is what we base our patch off of).  It's a bug in LFS' patched coreutils 
because when I created the 7.4 version of the patch I introduced this bug when 
trying to resolve conflicts occurring from the application of the 7.3 version 
of that patch to 7.4.  So, don't bother complaining to Herbert as it's not his 
problem.  Nor should you complain to the maintainer of the i18n patch at Fedora 
where we base our work off of.  This is solely an LFS issue and is resolved 
with the coreutils-7.5-i18n-2.patch.

If I get some time, I may go back and produce a coreutils-7.4-i18n-2.patch and 
publish an errata for the book.  Otherwise, can I suggest that you either try 
the 7.5 version against 7.4 or upgrade your Coreutils to 7.5 with the 2nd 
version of the patch or to 7.6.

Thanks,

Matt.

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

Re: Trying to fix this Dash issue upstream,

[Matthew Burgess]

William Immendorf wrote:
> ..but Herbert Xu lost his mind about it, thinking it was a sed issue,
> not a patched Coreutils/sort issue. I'm trying to get it fixed by
> changing all of the LC_COLLATE to LC_CTYPE, but I havn't seen it
> comitted yet. I'm waiting for Herbert to comitt this, then I'll
> backport the patch to Dash 0.5.5.1.
> 
> Good idea?

No, as discussed before, it is a patched coreutils issue.  There was a
bug in one of my versions of the coreutils i18n patches which caused
this.  What version of coreutils are you using, and what version of the
patch?

Matt.

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

Xorg-drivers builds BSD driver?

[Matthew Burgess]

Hi,

xf86-video-wsfb-0.3.0 appears to be for a BSD WS Framebuffer device.

Compilation failed for me due to a missing header file.  I think
the correct action here is to comment out the md5 & wget entries for
this driver, or am I missing something?

Thanks,

Matt.

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

Re: xorg-drivers requires glide

[Matthew Burgess]

On Sat, 7 Nov 2009 8:40:12 -0700, Matthew Burgess 
 wrote:
> Hi,
> 
> Xorg-driver currently doesn't compile, due to the fact that
> xf86-video-glide-1.0.3 requires glide.h from the glide package.
> 
> That package can be found at
> http://sourceforge.net/projects/glide/files/, though I've not
> gotten around to compiling it yet.

And it appears to be an unmaintained pile of...

It doesn't compile out of the box, even following their instructions (invoking
aclocal && automake && autoconf), due to files missing from the tarball.

So, I think the best option here is to comment out the glide driver from the
xorg-driver wget & md5 file, and put a note on the Xorg driver page mentioning
that users requiring that driver will need to install Glide first and point them
at the sourceforge page.

If that sounds OK, I'll get a patch together.

Regards,

Matt.

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

xorg-drivers requires glide

[Matthew Burgess]

Hi,

Xorg-driver currently doesn't compile, due to the fact that
xf86-video-glide-1.0.3 requires glide.h from the glide package.

That package can be found at
http://sourceforge.net/projects/glide/files/, though I've not
gotten around to compiling it yet.

I'll reply to this thread once I've done that, but this is
just a note (before I forget about it) that we'll need to
either add glide to the book or remove xf86-video-glide-1.0.3
from the wget/md5 files.

Thanks,

Matt.

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

Re: Dash fix

[Matthew Burgess]

On Mon, 2 Nov 2009 23:15:25 +, William Immendorf  
wrote:
> On Mon, Nov 2, 2009 at 11:09 PM, Guy Dalziel
>  wrote:
>> Yes, he did. The problem was with sort because of a patch that LFS
>> applies, and therefore the problem was passed over to LFS.
> I know. Anyway, would you dash off a quick commit putting the patch in
> the patch repo and mentioning it in the dash page and saying that it
> works with LFS 6.5.

It's really not worth a patch for that, the corresponding sed is trivial 
enough.  I
guess we need to add this to LFS-6.5's errata.  The issue was that the 
coreutils i18n
patch had a bug in it that caused this issue (the bug looks as if it was caused 
by me
manually fixing up a conflict by hand and getting it wrong!).  The 2nd i18n 
patch for 7.5
and the i18n patch for 7.6 are both correct.

Regards,

Matt.

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

xorg-libs & libxcb dependency

[Matthew Burgess]

Hi,

As noted on the xorg-libs page, libxcb is used by default and
a switch is required to disable building against it.

As such, should the dependency not be listed under 'Recommended'
rather than 'Optional'?  The default use of libxcb would suggest
that upstream expect/prefer it to be available?

Thanks,

Matt.

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

xorg lib md5 file error

[Matthew Burgess]

Hi DJ,

Looks like http://anduin.linuxfromscratch.org/files/BLFS/svn/xorg/lib-7.4.md5
contains an entry for an index.html file that doesn't exist/isn't required.

This leads 'md5sum -c ../lib-7.4.md5' failing.  Any chance you could just
remove that top entry please?

Thanks,

Matt.

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

Re: XZ-Utils 4.999.9beta

[Matthew Burgess]

On Tue, 29 Sep 2009 14:41:01 -0500, William Immendorf 
 wrote:
> On Tue, Sep 29, 2009 at 2:31 PM, Ken Moffat 
> wrote:
>>  I'm listening, and watching, but for the moment I don't
>> see any reason to put it in the book as a beta - for the
>> moment we can still get packages as .tar.gz.
> You don't see any reason? You need to look a lot closer:
> 
>  * Fedora, Arch, CLFS, and Slackware use it arleady, so +4 points to XZ.
>  * This release is very close to a stable release,  another +1 point to
> XZ.
>  * The file format for it is arleady stable, +1 to XZ.
>  * And tar uses too, +1 to XZ.

But those aren't any reasons to *use* it.  What *requires* the use of the .xz 
file
format that isn't also available in .gz or .bz2 files?  Unless there is 
something,
this package is simply a *nice to have*, not a necessity, and therefore can be
delayed until an editor really decides it's an itch that needs scratching.  Of 
course,
if someone were to provide a patch to the book that added the XZ-Utils package 
to the
book then I'm sure someone is more likely to review and apply it.

It takes considerable effort to add a package to the book, validate the 
instructions
and continue to maintain the package.  You should not expect anyone to respond 
to
your demands, William, especially when the need for the package being requested 
is
so small.

Regards,

Matt.

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

LFS-6.5 Released

[Matthew Burgess]

Hi,

The Linux From Scratch community is pleased to announce the release of
LFS Version 6.5. This release includes numerous changes from LFS-6.4
(including updates to Linux-2.6.30.2, GCC-4.4.1, and Glibc-2.10.1) and
security fixes. It also includes editorial work on the explanatory material
throughout the book, improving both the clarity and accuracy of the text.

You can read the book online[0], or download to read locally [1].

Please direct any comments about this release to the LFS development team
at lfs-...@linuxfromscratch.org. Please note that registration for the
lfs-dev mailing list is required to avoid junk email.

Regards,

Matt.

[0] http://www.linuxfromscratch.org/lfs/view/6.5/
[1] http://www.linuxfromscratch.org/lfs/downloads/6.5/

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

Re: Lesstif tests require Xorg-apps

[Matthew Burgess]

On Sat, 15 Aug 2009 14:27:07 +0100, Guy Dalziel  
wrote:
> On Sat, Aug 15, 2009 at 07:07:23AM -0600, Matthew Burgess wrote:
>> make[3]: Entering directory
> `/sources/blfs/lesstif-0.95.2/test/Xm/drag_help'
>> gcc -DHAVE_CONFIG_H -I. -I. -I../..  -I../../../include/Motif-2.1 
>> -I../../../include/Motif-2.1 -I../../../include/Motif-1.2 
>> -I../../../include/Motif-1.2 -g -I/usr/include  -c test1.c
>> test1.c:19:28: error: X11/bitmaps/Excl: No such file or directory
>> test1.c:20:33: error: X11/bitmaps/FlipHoriz: No such file or directory
>> test1.c:21:32: error: X11/bitmaps/FlipVert: No such file or directory
>> 
>> This is because those files come from the bitmap-1.0.3 package that is
>> within the Xorg-Apps bundle.
> 
> My general assumption was that you would build lesstif after you have
> built Xorg. Is there something in Xorg Applications that makes use of
> Lesstif?

Well, as I said in my original message, it's an optional dependency of MesaLib, 
which,
in turn, is a recommended dependency of Xorg Applications.  So, I'd imagine 
that folks
following that dependency trail would expect to be able to build Lesstif prior 
to
Xorg Applications.

Regards,

Matt.

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

Lesstif tests require Xorg-apps

[Matthew Burgess]

Hi,

My dependency chain looks like this:

Xorg-Apps -> MesaLib (recommended dep) -> Lesstif (optional dep)

So, trying to run the Lesstif testsuite prior to building Xorg-Apps I get:

make[3]: Entering directory `/sources/blfs/lesstif-0.95.2/test/Xm/drag_help'
gcc -DHAVE_CONFIG_H -I. -I. -I../..  -I../../../include/Motif-2.1 
-I../../../include/Motif-2.1 -I../../../include/Motif-1.2 
-I../../../include/Motif-1.2 -g -I/usr/include  -c test1.c
test1.c:19:28: error: X11/bitmaps/Excl: No such file or directory
test1.c:20:33: error: X11/bitmaps/FlipHoriz: No such file or directory
test1.c:21:32: error: X11/bitmaps/FlipVert: No such file or directory

This is because those files come from the bitmap-1.0.3 package that is
within the Xorg-Apps bundle.  Is it worth putting a note on the Lesstif page to
this effect?  e.g. under the Recommended deps you'd put
"Xorg Apps (if you run the test suite during the build)", similar to the note
on OpenSSL's page regarding 'bc'.  Mentioning the circular nature of this 
dependency
may also be in keeping with similar notes in the book (ala the Perl Modules).

Regards,

Matt.

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

Why do we remove Xorg packages after installation?

[Matthew Burgess]

Hi,

The example shell script loop on 
http://www.linuxfromscratch.org/blfs/view/svn/x/xorg7.html
does `rm -f $package' as its last command for each package in each Xorg 
section.  I'm just
wondering why, having downloaded the package, we then suggest to delete it, 
such that if
someone wants/needs to recompile it, we'd need to reinstall it again?

Thanks,

Matt.

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

Re: Notes on the current pdf version of the book

[Matthew Burgess]

On Wed, 05 Aug 2009 15:07:42 -0500, Bruce Dubbs  wrote:

> I wish there were an easier way to find these overflows than scrolling
> through what is now a 1200 page book.

When I spotted the recent overflow in LFS, finding it was quite easy; the
pdf.log file generated by the Makefile.  The logfile contains the warning
about the overflow with the line number it occurred in.  That line number,
in turn, refers to the .fo file that contains the entire book, which is in
the temporary render directory of the book.  Viewing the surrounding area
should point you to the package in the book that contains the overflow.

Apologies if I'm telling you something you already know, but I don't think
you should ever need to manually scroll through the entire 1200 pages to
find the overflows.

Regards,

Matt.

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

LFS-6.5-RC2 released

[Matthew Burgess]

Hi,

The Linux From Scratch community is pleased to announce the release of
LFS Version 6.5 Release Candidate 2. This release includes numerous
changes from LFS-6.4 (including updates to Linux-2.6.30.2, GCC-4.4.1,
and Glibc-2.10.1) and security fixes. It also includes editorial work on
the explanatory material throughout the book, improving both the clarity
and accuracy of the text.

You can read the book online[0], or download to read locally [1].

It is our intention to release LFS-6.5 final within 1 week.  Please
direct any comments about this release to the LFS development team at
lfs-...@linuxfromscratch.org. Please note that registration for the
lfs-dev mailing list is required to avoid junk email.

[0] http://www.linuxfromscratch.org/lfs/view/6.5-rc2/
[1] http://www.linuxfromscratch.org/lfs/downloads/6.5-rc2/

Regards,

Matt.

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

Re: proposal: new approach

[Matthew Burgess]

On Sat, 25 Jul 2009 09:03:13 -0500, Randy McMurchy  
wrote:
> DJ Lucas wrote these words on 07/25/09 08:48 CST:
> 
>> Finally, in light of the amount of work needed to be done, current LFS
>> editors should be given access to BLFS (if they don't have it already).
>> Anything that anyone can contribute, after LFS-6.5 is out the door, will
>> be greatly appreciated.
> 
> You're only talking about Matt, and he's had BLFS access for years.

And I probably have never used them!  Anyway, now that my main barrier to entry 
of
"make sure all dependant packages work following a package update" has been 
lifted,
I may well go all gung-ho following LFS-6.5-RC2 and start actually (ab)using my
commit privs :-)  I'm also willing, of course, to revert any of my updates that
cause breakage, or investigate any issues they cause.

Regards,

Matt.

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

LFS-6.5-RC1 released

[Matthew Burgess]

Hi,

The Linux From Scratch community is pleased to announce the release of
LFS Version 6.5 Release Candidate 1. This release includes numerous
changes from LFS-6.4 (including updates to Linux-2.6.30.1, GCC-4.4.0,
Glibc-2.10.1) and security fixes. It also includes editorial work on the
explanatory material throughout the book, improving both the clarity and
accuracy of the text.

You can read the book online[0], or download to read locally [1].

It is our intention to release LFS-6.5 final within 2 weeks.  Please
direct any comments about this release to the LFS development team at
lfs-...@linuxfromscratch.org. Please note that registration for the
lfs-dev mailing list is required to avoid junk email.

[0] http://www.linuxfromscratch.org/lfs/view/6.5-rc1/
[1] http://www.linuxfromscratch.org/lfs/downloads/6.5-rc1/

Regards,

Matt.

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

Re: New Hal Version: 0.5.12

[Matthew Burgess]

On Thu, 14 May 2009 13:12:12 -0500, DJ Lucas  wrote:
> William Immendorf wrote:
>> But, I would leave this one off to 7.0. Why? Because it now requires
>> Util-Linux-ng >= 2.15.

But I think we're a while away from LFS-7.0 yet, and Util-Linux-NG 2.15/2.15.1
will make it in well before we're ready to start stabilizing.

> Sold!  I'll drop in a patched 0.5.11 after the weekend.

Agreed, patched 0.5.11 is suitable for 6.4, but for 7.0 I think it's sensible
to get 0.5.12 in.

Regards,

Matt.

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

Re: SQLite Implementation

[Matthew Burgess]

On Mon, 02 Mar 2009 08:13:27 -0600, Randy McMurchy  
wrote:

> Is simply creating a page with the build instructions and links to
> the SQLite documentation sufficient. I think so. I don't think we
> need to create a user or a group or even a default database file.

I'd agree with that, Randy.  SQLite is similar in its approach to GDBM.  That 
is,
it provides library routines for a program to use in order to read/write a db 
file
directly, rather than through client-server communication.

Regards,

Matt.

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

Re: Scripting root operations

[Matthew Burgess]

On Sat, 28 Feb 2009 20:23:45 -0600, Bruce Dubbs  wrote:
> Matthew Burgess wrote:
>> Hi all,
>>
>> "Notes on Building Software" in BLFS recommends, quite rightly,
>> that readers should do as little as possible as 'root', and only
>> use superuser privs for operations that require them (e.g.
>> 'make install').
>>
>> And, as this is *LFS I have chosen to ignore that advice up
>> until now and keep all the pieces when it breaks :)
>>
>> I've been bitten by another bug/issue in the Python test
>> suite that only affects the root user (this is in the httpservers
>> tests, so is different from the original failure I saw back with
>> Python-2.5, raised in comment 10 of #2200).  If I run the tests
>> as non-root they pass fine.
>>
>> So, my question is, should LFS and BLFS enforce, or at
>> least more clearly encourage folks to build/install as non-root?
>>
>> In order to be able to support build automation, I'm considering
>> using 'sudo' along with a dedicated build-user, who is
>> configured in sudo to not require the root password.
>>
>> Do you think that this approach is suitable for LFS/BLFS?
> 
> The philosophy for Unix and all its look alikes is, in general, to allow
> the
> user to do whatever he wants.  It's not our responsibility to 'enforce'
> the
> build as non-root recommendation.  I'm not sure I see that advantage of a
> dedicated build user, but that certainly is a possibility.  It just means
> that a
> user must sudo or su to the build user to manipulate files in the build
> directories.
> 
> I'm not sure how we would 'more clearly encourage folks to build/install
> as
> non-root'.  What did you have in mind?

Something along the lines of actually installing sudo in chapter 5 of LFS,
and configuring it such that an 'lfs' user exists in chapter 6 with
appropriate configuration to get to 'root' without a password (with
appropriate warnings about the potential security implications of that, of
course).

In early chapter 6, we'd chroot into the LFS partition, but immediately su
up to the lfs user.  All privilege-requiring instructions would then be
written in the same style as BLFS, i.e. "Now, as the root user...".

Regards,

Matt.

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

Re: libusb-compat requires pkg-config

[Matthew Burgess]

On Sat, 28 Feb 2009 20:05:41 -0600, Randy McMurchy  
wrote:
> Bruce Dubbs wrote these words on 02/28/09 19:33 CST:
>> While I'm not completely against putting pkg-config in LFS, we could
> also put it
>> into Chapter 3 of BLFS, 'After LFS Configuration Issues'.
> 
> It wouldn't surprise me if some LFS package looks for pkg-config in the
> near future.

Randy, thanks for sorting out the libusb-compat requirement so quickly.

I'm actually surprised that none of LFS' packages have started to use pkg-config
yet, given its increasing adoption.

My vote would also be to migrate it over to LFS, putting it in its rightful 
place
in the alphabetical build order until such time that an LFS package requires it.

Regards,

Matt.

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

Scripting root operations

[Matthew Burgess]

Hi all,

"Notes on Building Software" in BLFS recommends, quite rightly,
that readers should do as little as possible as 'root', and only
use superuser privs for operations that require them (e.g.
'make install').

And, as this is *LFS I have chosen to ignore that advice up
until now and keep all the pieces when it breaks :)

I've been bitten by another bug/issue in the Python test
suite that only affects the root user (this is in the httpservers
tests, so is different from the original failure I saw back with
Python-2.5, raised in comment 10 of #2200).  If I run the tests
as non-root they pass fine.

So, my question is, should LFS and BLFS enforce, or at
least more clearly encourage folks to build/install as non-root?

In order to be able to support build automation, I'm considering
using 'sudo' along with a dedicated build-user, who is
configured in sudo to not require the root password.

Do you think that this approach is suitable for LFS/BLFS?

Regards,

Matt.

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

libusb-compat requires pkg-config

[Matthew Burgess]

Hi guys,

Just to let you know that trying to build libusb-compat early on
in a BLFS build fails (hard fail in ./configure) if pkg-config
isn't installed.

I wanted to report this in BLFS' Trac, but I don't have the
permission to do so (presumably thanks to the recent abuse it's
seen?).

Regards,

Matt.

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

Re: OpenSSH 5.2p1

[Matthew Burgess]

On Tue, 24 Feb 2009 07:06:01 -0600, William Immendorf 
 wrote:

> I tend to be impatient, however. So keep that in mind.

And we tend to ignore impatient people who are unwilling/unable to help 
contribute
to the books or support thereof.  So keep that in mind.

Honestly, William, could you not just have noticed that the new release had 
been made,
test that the current book's instructions work with the new version and then 
instead
of demanding the already stretched editors upgrade instantly, at least be able 
to say:

"There's a new version of the OpenSSH package.  I've tested it using the latest 
book's
instructions and it works/doesn't work (delete/add more info as appropriate)."

For bonus points, assuming the book's current instructions work as-is, 
providing the
trivial patch against packages.ent would have gone a long way to boosting 
people's
impressions of you.

And now, given that, I hereby promise not to feed the troll anymore.

Matt.

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

lesstif doesn't find Xrender by default

[Matthew Burgess]

Hi all,

I may well have missed something obvious again here, if so then my apologies!

Using the book's default instructions, I get the following output in the
run of ./configure for lesstif-0.95.0...

Checking X11/extensions/Xrender.h usability... no
Checking X11/extensions/Xrender.h presence... no

If, instead, I change the configure invocation by adding
'--x-includes=${XORG_PREFIX}', it finds a usable Xrender.h file.  Note that
in my case, XORG_PREFIX=/usr, so I'm surprised lesstif b0rked.

Is anyone able to reproduce this?

Thanks,

Matt.

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

Re: Freeglut requires GL/gl*.h

[Matthew Burgess]

On Mon, 15 Dec 2008 13:57:08 -0800, "Dan Nicholson"  wrote:

> FreeGLUT depends on the GL implementation, which is Mesa. So, you'd
> have to install Mesa then FreeGLUT. FWIW, nothing else in the Xorg
> stack uses GLUT, so you can definitely postpone FreeGLUT until later.
> The GL headers come from Mesa.

Thanks to everyone for the clarification!  When I read 'MesaLib', then went to
'MesaGLUT' and from there to 'Freeglut' I'd gotten myself confused and thought
that Freeglut was an alternative to MesaLib!

Now that's cleared up, I'll gladly leave Freeglut out until I find something
that does need it.

Regards,

Matt.

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

Re: Anduin

[Matthew Burgess]

On Thu, 27 Nov 2008 12:09:29 +, TheOldFellow <[EMAIL PROTECTED]> wrote:
> I can't get to anduin!
> All accesses timeout.  And see this traceroute:
> 
> 
> 12  10ge.ten1-1.wdc-sp2-cor-1.peer1.net (216.187.116.253)  153.570 ms 
> 157.374 ms  158.041 ms
> ...
> 30  * * *

I get the same thing, albeit via a ridiculously long route out of our corporate 
network here.  It goes dead after:

28   351 ms   343 ms   370 ms  1ge-gi3-2.sat-8500v-dis-2.peer1.net 
[216.187.124.190]

Regards,

Matt.

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

Re: JDK JRL Source

[Matthew Burgess]

On Mon, 10 Mar 2008 08:22:12 -0500, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Apache Ant (required by FOP) also needs to be considered. And to
> answer the question, I've never tried with GCJ. Not sure we want
> to go there either unless significant testing is done.

I tried a while back, and didn't get very far at all (problems with GCJ 
itself).  Both those bugs (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28572 
and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28555) are marked as fixed now, 
so things might go a bit further for others attempting it now.  Unfortunately, 
I've lost my list of dependencies for building FOP using GCJ, so I can't even 
help out in that regard.

Regards,

Matt.

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

Re: Python test suit /tmp removal

[Matthew Burgess]

On Thu, 09 Aug 2007 04:42:09 -0500, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote these words on 08/08/07 23:50 CST:
> 
>> I've noticed that the Python test suite removes the /tmp directory when
>> "make test" is run as root.
> 
> It seems someone else mentioned this a while back.

I remember running into this, so hope that the above report was from me.

> I can't remember what we decided to do.

Well, the reason for the removal of the /tmp dir is that one of the tests does 
a recursive delete on the /tmp directory.  This means that if /tmp is empty 
(which it normally is during a build of Python early on in a BLFS build), the 
directory itself will be removed.  My workaround was to simply `touch 
/tmp/dummy' prior to the Python testsuite run and `rm /tmp/dummy' immediately 
afterwards.  As you point out, Randy, BLFS already warns folks not to 
compile/test stuff as root, so whether or not the workaround is suitable for 
the book instructions is up to you.

Regards,

Matt.


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

Changing Wiki Login Procedure

[Matthew Burgess]

Hi,

At the moment, logging in to the various project's wiki sites causes a browser 
dialog to appear, which isn't particularly common these days.  There doesn't 
appear to be a way of getting a password reminder, should someone forget their 
password.  The error page someone gets if they type in an incorrect username or 
password doesn't look particularly nice either.  Over on the server-admin Trac, 
I've fixed these issues.  Users are presented with a webform to login (see 
http://wiki.linuxfromscratch.org/server-admin/login).  That form also has a 
link whereby the user can request a password reminder.  The error one gets if 
you fail to authenticate is much nicer looking as well, IMO.

I plan on implementing this login form for the LFS wiki site as well.  If BLFS 
and ALFS folks would like, I can also implement this in their respective wikis 
too.  Let me know what you think, please.

Regards,

Matt.



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

Re: [nex-xsl] What to do?

[Matthew Burgess]

On Wednesday 04 July 2007 21:34:05 M.Canales.es wrote:
> Hi,
>
> As you know, the new XSL stylesheets are ready for production time waiting
> the release of stable DocBook-XSL-1.72.1.
>
> The bad news it that there will be no DocBook-XSL-1.72.1 release

That's obviously not the news any of us were hoping for!

> That lead us to the next choices:
>
>  1. - Wait up to the next *.1 release to start using the new code. That
> could meant to wait at least other 3-4 months :-/

While this is probably the easiest option to go for (all projects simply stick 
with the current docbook toolchain), it would be a shame to see all of your 
hard work on the new-xsl branch not made use of.

>  2.- To create our own LFS-XSL-1.0 package based on current new-xsl branch
> code and use it as a temporally solution. That implies to add a
> installation page for such package in BLFS and to install it on the servers
> and editor's machines.

This, I fear, would look as if we've created a fork of the upstream project.  
While there are some good reasons for creating a fork (lack of maintenance, 
undesirable license changes, etc.), the lack of a stable release when we 
want/need one by is not one of them, in my opinion.

>  3.- To clean-up the docbook-xsl-snapshoot branch subdirectory to keep only
> that files actualy required to build the books. Then merge the code to the
> {,B,C,H}LFS SVN trees. That will made the book's sources full
> auto-contained. This will increase maintenance work to keep it sinchronized
> with upstream code, but IMHO is the more simple solution and my prefered
> way.

I also think this is the way we should proceed.  I'm not sure that we 
necessarily need to remove files that we don't require for a build of any of 
our books - in fact, keeping them around would probably make diffs between 
upstream and our downstream copy easier to understand.

Related to this issue is the fact that I'm painfully aware that the 6.3 
release has been a long-time coming.  Manuel, as you said, the current 
snapshot in the new-xsl branch are production ready, so I'd be happy for 
these to be merged, if this is the route that is decided upon.

Regards,

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

XOrg-7.2 - libXcb

[Matthew Burgess]

Hi folks.

Trying to compile libX11 according to latest SVN, I get:

checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for XPROTO... yes
checking for X11... configure: error: Package requirements (xextproto xtrans 
xcb-xlib >= 0.9.92) were not met:

No package 'xcb-xlib' found

Well, that's pretty clear, and is absolutely correct but leaves me with a 
couple of questions:

1) The book instructions mention that XCB is "optional", whereas libX11 pretty 
clearly wants/expects it to be there.  Therefore, should it be upgraded 
to "recommended"? (I have noted the book mentions the --without-xcb configure 
option, btw).

2) The links to XCB on the xorg-libs page are incorrect - they should point to  
http://xcb.freedesktop.org/ not http://xcb.freedesktop.org/wiki/ which 404's.

3) Is there a reason XCB was not added to the book?  (It needs the 
libpthread-stubs package and xsltproc from a quick look at the dependencies).

Thanks,

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

Re: Firefox 3

[Matthew Burgess]

On Tuesday 15 May 2007 20:29:46 Bruce Dubbs wrote:

> They are basically wanting to drop support for older libraries.  From a
> developer's standpoint, I can understand not wanting to support older
> stuff, but this seems to be too aggressive to me.

Well, I was under the impression that Mozilla included an in-tree copy of 
cairo because of them finding and fixing bugs locally and not wanting to have 
to wait on new upstream releases before they can benefit from them.  If this 
is still the case, it would be nice if they didn't provide 
an --enable-system-cairo configure option (or whatever vocabulary they use), 
but I don't follow development closely enough to know whether they've gone 
this far or not.

I assume glib-2.13.x is unstable?  If so, I guess Mozilla are simply 
anticipating a stable release before they are in a position to release 
Firefox-3.0?

As for libjpeg, libpng and zlib what other versions are there?

Regards,

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

Re: ghostscript

[Matthew Burgess]

On Sunday 18 March 2007 19:45, Randy McMurchy wrote:
> Matthew Burgess wrote these words on 03/18/07 14:38 CST:
> > http://sourceforge.net/project/showfiles.php?group_id=1897 shows GPL
> > Ghostscript 8.56 was released yesterday.
>
> Well, I have it 4 days ago (March 14th to today, March 18th), but
> perhaps it's an American/Britain thing to count the days differently.
>
> :-)

No, no, it's me yet again proving that I can't read properly! (I somehow 
manged to completely mix up the release dates of AFPL Ghostscript and GPL 
Ghostscript)!  I'm going to give up now, and head to the pub!

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

Re: ghostscript

[Matthew Burgess]

On Sunday 18 March 2007 19:27, Bruce Dubbs wrote:

> Where did you find this?  I can only find reference to version 8.54. Or
> are you just looking at the tags in ghostscripts's svn?

http://sourceforge.net/project/showfiles.php?group_id=1897 shows GPL 
Ghostscript 8.56 was released yesterday.

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

Re: cairo-1.4.0 test suite

[Matthew Burgess]

On Sunday 18 March 2007 18:47, Randy McMurchy wrote:
> I always install ESPGS as it provides
> CUPS support and seems to be better maintained.

That's what I assumed, from the frequency of releases.  However, I'm not 
certain that it's going to have any more releases at all after reading 
http://www.cups.org/espgs/articles.php?L449

Does anyone know anything more about the status of ESPGS?

Regards,

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

Re: Python-2.5

[Matthew Burgess]

On Saturday 24 February 2007 17:22, Dan Nicholson wrote:

> Oh, I was unprivileged, just in my home directory. What about you?
> I'll try to see what happens if I run as root (although I'm not too
> keen on the concept of removing /tmp on purpose :)

Yeah, I was running as root, and I've now figured out the cause of the 
problem!  The last line in the test is:

os.removedirs(path).

>From the Python docs:

Removes directories recursively. Works like rmdir() except that, if the leaf 
directory is successfully removed, removedirs() tries to successively remove 
every parent directory mentioned in path until an error is raised (which is 
ignored, because it generally means that a parent directory is not empty).

For now, I can work around the problem by doing `touch /tmp/marker' because 
os.rmdir(), and hence os.removedirs() doesn't work on non-empty directories.

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

Re: Python-2.5

[Matthew Burgess]

On Friday 16 February 2007 17:37, Matthew Burgess wrote:
> On Friday 16 February 2007 15:40, Dan Nicholson wrote:
> > On 2/16/07, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> > > In the Trac ticket for the Python-2.5 update, Matt claims to get
> > > testsuite failures, however, the tests in my installation were perfect.
> >
> > Tests came out fine for me. A bunch skipped, but no errors.
>
> Oh dear, I wonder what I'm doing wrong then :-(  I'll look into it more
> closely once the latest bunch of updates to LFS-SVN are in.  Thanks for the
> successful test reports guys, at least I know not to go and bother upstream
> with a support request now!

Well, I'm still getting test failures and I've narrowed down the problem to 
test_shutil.py.  For some reason, test_copytree_simple is removing /tmp.  
I've put some print statements in the test to see what paths should be being 
deleted, and there's nothing wrong there, so I'm absolutely baffled now!  
Randy, Dan, were you running the tests as root or as an unprivileged user?

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

Re: xorg 7.1 and DRI

[Matthew Burgess]

On Sunday 18 February 2007 04:16, Bruce Dubbs wrote:
> Bruce Dubbs wrote:
> > I was using my laptop this last week when I was away from home and
> > noticed that DRI was not working.  Usually, I just use the proprietary
> > Nvidia driver, but I am using the nv driver on a stable BLFS 6.2 system
> > here.
> >
> > In Xorg.0.log I get:
> >
> > (EE) AIGLX: Screen 0 is not DRI capable
>
> Never mind.  I see now that the open source driver does not support dri.

I think the open source Nouveau driver does though 
(http://nouveau.freedesktop.org/).  IIRC, the statement on their Wiki 
of "Currently, nothing works. If you're not a developer, you're not 
interested in this at all. There used to be a feature matrix of what we need 
to do." is a little exaggerated.  I'm sure I've heard of people using the 
driver successfully, but I've not personally tried it yet.

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

Re: Python-2.5

[Matthew Burgess]

On Friday 16 February 2007 15:40, Dan Nicholson wrote:
> On 2/16/07, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> > In the Trac ticket for the Python-2.5 update, Matt claims to get
> > testsuite failures, however, the tests in my installation were perfect.
>
> Tests came out fine for me. A bunch skipped, but no errors.

Oh dear, I wonder what I'm doing wrong then :-(  I'll look into it more 
closely once the latest bunch of updates to LFS-SVN are in.  Thanks for the 
successful test reports guys, at least I know not to go and bother upstream 
with a support request now!

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

Re: Consolidated Tickets in Trac

[Matthew Burgess]

On Wednesday 14 February 2007 19:07, Ag. Hatzimanikas wrote:
> On Wed, Feb 14, at 09:42 Tushar Teredesai wrote:
> > On 2/14/07, Ag. Hatzimanikas <[EMAIL PROTECTED]> wrote:
> > > What I would expect (at least in the future), from a bug-tracking
> > > technology is some kind of sub-tickets/threads.
> >
> > They are called meta bugs in mozilla's bugzilla. See
> >  for an example of
> > a meta bug.
>
> Kind of and quite close to my wishing.
> And indeed the consolidated ticket that we are talking about, it looks
> better [1] in bugzilla than Track.

There's an open ticket for Trac regarding ticket dependencies and the like.  I 
haven't looked into how much they've managed to implement yet or timescales 
for filling in the missing pieces but you can see it for yourself at 
http://trac.edgewall.org/ticket/31.

Regards,

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

Re: Xorg Dependencies

[Matthew Burgess]

On Saturday 10 February 2007 21:39, Dan Nicholson wrote:

> This isn't Fedora, right? I checked their current spec and they don't
> link to pam. Xorg on the OpenSuSE partition I have isn't linked to it,
> either.

Ubuntu don't link to it either, FWIW.

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

Re: 6.2.0 tag

[Matthew Burgess]

On Thursday 01 February 2007 02:54, Randy McMurchy wrote:

> My belief (and I'm quite strong on this one) is that we should use
> SVN in our best interests, which means for us (at least in my opinion)
> that tags are a stagnant entity, but branches are meant to be used
> for merges from trunk.

Just to give you my perspective from the LFS Release Manager side of things.  
I had this exact same discussion a while back with Archaic with regard to the 
LFS releases.  I was mandating we follow the old CVS style workflow, where 
tags shouldn't/couldn't be updated.  Discussing it with Archaic and Ben 
Collins-Sussman (a Subversion developer, on IRC), I soon got around to the 
SVN way of working and realized, like Randy, that the tool should be used to 
support our needs rather than our workflow having to "conform" to the tool's 
expectations.  As SVN allows tags to be changed, why not make use of that 
feature?

So, in short, I'd say copy trunk to a 6.2 tag, then update general.ent on the 
tag.  That's how things are done on LFS, at least.

Randy, if it'd help, I have a release-script.sh file in my home directory on 
quantum that helps me automate LFS releases.  It may be possible to coax it 
to do a similar job for BLFS, if you think that'd be useful?  I can't take 
the credit for that script though, it's all Archaic's fine work!

Regards,

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

Re: BLFS Project

[Matthew Burgess]

Dan Nicholson wrote:

On 11/20/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:


If there is someone with appropriate rights that can monitor
Belgarath and restart services as they crash (and perhaps kill
all the services that we *really* don't need), perhaps we could
get some contribution going.


Bruce. Maybe he can give someone else some privileges.


I also have privs.  However, I don't have any monitoring daemons 
available.  I know nagios used to run and provide reports to system 
admins, but I've not seen any recently.  I think it only monitored http 
and smtp.  If I notice any services are down (usually limited to http 
and imapd/smtpd), I'll usually try and get them started myself, unless I 
know of anyone else doing some admin work in that area.


Regards,

Matt.


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

Re: xLFS Book Licenses

[Matthew Burgess]

Bruce Dubbs wrote:

Matthew Burgess wrote:

Bruce Dubbs wrote:

Currently, LFS ticket 1765,
http://wiki.linuxfromscratch.org/lfs/ticket/1765, suggests that LFS use
the licenses that are currently in the BLFS book.  Jim, Ryan, and I have
had some off-line conversations about this and feel it is time to open
up this discussion to the community.

[This is going to be long...please bear with me!]

OK, before this discussion can be of any use, I really think we need to
decide on a couple of things.

1) What are the motivations behind the license change?

So far, I can only think of one, which is the fact that TLDP won't
accept documents that aren't covered by a recognized license.


It is true that TLDP triggered this issue, but the motivations are a bit
more than that.  If we wanted, we could get a lawyer and write our own
with proper legal advice, but that is expensive and unnecessary when
recognized open source licenses are available.


Agreed.  I'd really like us to use an existing license, if at all 
possible.  It reduces the legal costs on both our side and our readers side.



I think the real
motivation is that we want the books used in a certain way and not allow
someone to use our work in a way we don't approve,


OK, so we just need to agree on what we'd approve and what we'd 
disallow.  Easy, eh?  :-)



2) What licensing requirements do xLFS books have?

This is primarily based on the answer to question 1) although xLFS
developers, editors and the community may wish to have additional
constraints written into whatever license we choose.


IMO, the requirements are:

1.  Only publish commercially with permission.


This goes against the spirit of Free Software, IMO.  I *do* understand
the reasons for wanting to do so, but GPL and BSD packages have survived
without such restrictions so far, why shouldn't LFS?  Maybe books are
different from software, but at the moment I'd be in agreement with Dan
Nicholson; we should aim for as free a license as possible.  The LFS
project hasn't made much money at all from the sale of hard copy books,
as far as I'm aware.  There is no reason, therefore, to believe that
someone else could make much money from it either.  So, what do we lose? 
The ability to publish via TLDP for one.


This reminds me of a recent post by Alan Cox at
http://www.ussg.iu.edu/hypermail/linux/kernel/0608.2/0882.html - '.If
your product differentiator is "used a different ten cent ethernet chip"
then remind me not to buy your stock 8)'.  If someone takes the LFS 
book, and publishes it as-is, there is *no* product differentiator, save 
for it being in hard-copy.  Why would someone choose to buy that book 
rather than one published by LFS?  What I'm getting at is ascertaining 
a) the risk of someone publishing the book with a commercial motive and 
b) the probability of them actually profiting out of it.


If there's no commercial value to it, then there is nothing to protect,
commercially speaking.


2.  Provide appropriate acknowledgment if the book or portions of the
book are used in other non-commercial works.


Yep, that's a requirement of the CC license.  Note that, although we've 
improved recently, we have historically had a pretty poor record on 
acknowledging our own contributors!  We need to work out who our 
licensees have to acknowledge though, is it Gerard, each individual 
contributor, the LFS project itself?  I'd imagine it'd be the copyright 
holder, which at the moment is Gerard.



3.  The result of following the book is unrestricted by us.  The
restrictions of the packages used remain with the authors of the
specific packages used.


Sounds sane enough, though I don't think we need a specific clause in
the license to stipulate this - the upstream packages' license should be
enough, no?


4.  The extraction of scripts and configuration files should be
permitted for any purpose.


Again, no argument here.


Ryan suggested the GPL for the code, but that has a lot of overhead that
I don't feel is necessary.  For instance, there would be a need to put
relatively long GPL statements in each file in the bootscripts and the
need to include extra copyright files with the jhalfs output.

That's a really trivial hurdle to overcome, and well worth it
considering the protection it gives our code, IMO.


What protection do you think our code needs?  IIRC, many of our init
scripts are based on other distros.


Well, maybe "protection" was the wrong word, maybe not.  It needs a 
legally enforceable license applied to it to ensure our users have the 
same freedoms as they come to expect from Open Source software.  As with 
the book, applying a widely recognized license, such as the GPL, to our 
code will help us avoid any potential ambiguities or confusion on the 
part of our readers.


Regards,

Matt.

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

Re: xLFS Book Licenses

[Matthew Burgess]

Bruce Dubbs wrote:

Currently, LFS ticket 1765,
http://wiki.linuxfromscratch.org/lfs/ticket/1765, suggests that LFS use
the licenses that are currently in the BLFS book.  Jim, Ryan, and I have
had some off-line conversations about this and feel it is time to open
up this discussion to the community.


[This is going to be long...please bear with me!]

OK, before this discussion can be of any use, I really think we need to 
decide on a couple of things.


1) What are the motivations behind the license change?

So far, I can only think of one, which is the fact that TLDP won't 
accept documents that aren't covered by a recognized license.


2) What licensing requirements do xLFS books have?

This is primarily based on the answer to question 1) although xLFS 
developers, editors and the community may wish to have additional 
constraints written into whatever license we choose.



Jim has pointed out that there are problems with the CC:


[I've reordered the links so the easiest ones to deal with are at the top!]

> http://zesty.ca/cc.html

I don't see any concerns here that are particular to xLFS.  If Jim, Ryan 
or anyone else has specific issues that are highlighted above it'll be 
easier to comment on them if you could point them out.


> http://www.satn.org/archive/2003_04_27_archive.html

This argues that the warranties of the CC license are too onerous for 
content authors' because they force them to check everything, including 
quotes, trademarks, etc. to ensure they're not infringing copyrights and 
patents (including those on software, if your jurisdiction happens to 
recognise such ridiculous things).  However, these warranties have been 
removed in more recent versions of the CC license (see clauses 5 & 6 at 
http://creativecommons.org/licenses/by-sa/2.5/legalcode).



http://people.debian.org/~evan/ccsummary


This details concerns with CC-2.0, specifically in relation to its 
compatibility with the Debian Free Software Guidelines (DFSG).  To this 
I'll make two general points:


1) Is complying with the DFSG an important criteria for xLFS?  If so, why?

2) CC-2.5 was released in June, 2005.  (As a hopefully useful aside, 
plain text versions of both licenses can be found at 
http://evan.prodromou.name/ccpl/ccpl-by-sa-2.0.txt and 
http://evan.prodromou.name/ccpl/ccpl-by-sa-2.5.txt which allows for easy 
diff(1)ing.


As far as Evan's specific issues with CC go:

- Removing references: Clause 4a. has been reworded.  IANAL so can't 
immediately tell whether Evan's concerns have been addressed or not
- Any Other Comparable Authorship Credit: Clause 4b. remains unchanged 
(save for the version number), so this point remains.
- Anti-DRM clause: The relevant part of clause 4a is unchanged.  I don't 
quite understand Evan's argument here though, considering clause 2 of 
GFDL (http://www.gnu.org/copyleft/fdl.html), which was recently 
considered Debian-Free (http://www.debian.org/News/2006/20060316), 
contains an Anti-DRM clause.  Again, IANAL, so there may well be a 
reasonable difference between the two clauses that makes the GFDL free 
and the CC non-free.  Also note that work on the Anti-DRM is still 
ongoing in CC land 
(http://lists.ibiblio.org/pipermail/cc-licenses/2006-August/003855.html), 
so CC-3.0 might yet get the Debian seal of approval.
- Trademark Restrictions: Unchanged between CC-2.0 and CC-2.5.  This 
particular concern is not valid for the xLFS books though.  As per
http://www.tldp.org/LDP/LDP-Author-Guide/html/doc-licensing.html, "the 
full text of the license must be included in your document".  Therefore, 
the non-license text that Evan has a problem with wouldn't be in our books.
- I've not countered any of the arguments relating to the 
"Non-Commercial" variation of the CC license as it directly conflicts 
with the TLDP manifesto.
- I've not countered any of the "No Derivatives" variation of the CC 
license as I don't think it is in the spirit of the Free Software 
Community that we are a part of and take so much from.



Ryan suggested the GPL for the code, but that has a lot of overhead that
I don't feel is necessary.  For instance, there would be a need to put
relatively long GPL statements in each file in the bootscripts and the
need to include extra copyright files with the jhalfs output.


That's a really trivial hurdle to overcome, and well worth it 
considering the protection it gives our code, IMO.


Regards,

Matt.

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

Re: Dead Project? (I hope not)

[Matthew Burgess]

Ken Moffat wrote:

On Sat, Aug 19, 2006 at 03:26:01PM +0100, Matthew Burgess wrote:

And switches to a newer linux-headers package.
I'm waiting on linux-2.6.18 so we can use a supported upstream 
implementation, rather than rolling our own.  That's been delayed 
somewhat by Linus' recent break.



 I suspect that the 2.6.18 headers will break some packages, but
that's only based on what we've had to do for the clfs linux-headers
and general comments on lkml from the people doing the header
changes.


Interesting.  Is this because of userspace apps incorrectly using kernel 
headers, or is it because the header cleanups have been too aggressive?


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

Re: Dead Project? (I hope not)

[Matthew Burgess]

Joe Ciccone wrote:

Randy McMurchy wrote:


Noted that there is some minor trivial updates to CLFS recently, the
occasional package updates to LFS, and updates to jalfs (which is only
as good as the [x]LFS books), there really is no development going
on at all any more within the LFS project.


As far as the LFS book is concerned, I've been doing my best, given my 
limited time, to keep the packages up to date and fix any other bugs 
that can easily be tackled within those time constraints.  We're down to 
10 tickets in trac now, which is the lowest I've seen it for a long 
time.  Another two shouldn't be too hard as they're just package 
upgrades to glibc and shadow.  The shadow one I've held off on because 
there's a known upstream bug and I've been expecting to see a fixed 
version out from upstream though it's not materialised yet.  Glibc I've 
not upgraded because I was put off by upstream's recommendation not to 
run it in production environments coupled with a couple of bugs I've 
read about on the lfs lists.  They've probably been fixed by patches, 
but I've lost track of those!  If anyone can recall what's required to 
get glibc-2.4 in the book, I'll gladly put it in.



There really hasn't been much technical discussion on the lists
recently, There hasn't been any major changes in a while. I think it's
about time that LFS gets bumped up to gcc-4.1.1 and glibc-2.4.


LFS is already on gcc-4.1.1.  As for glibc-2.4, see above.


And switches to a newer linux-headers package.


I'm waiting on linux-2.6.18 so we can use a supported upstream 
implementation, rather than rolling our own.  That's been delayed 
somewhat by Linus' recent break.


Regards,

Matt.

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

Re: Xorg-server compilation error: agpgart.h

[Matthew Burgess]

Dan Nicholson wrote:


Unfortunately, most people aren't going to rebuild glibc on a live
system, so this is gonna need to be in for a while.


I don't see why - BLFS svn assumes an LFS svn host, no?  In which case 
I'd drop the patch and if anyone says xorg-server doesn't build then 
tell them to build on a sane host :-)


Regards,

Matt.

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

Re: Xorg wget generation script

[Matthew Burgess]

DJ Lucas wrote:
The 7.1 release folders only contain the updated packages just to make things more 
difficult, but thanks for the script


Uggh, that's just nasty :-(  They could have at least symlinked the 
unchanged packages into the 7.1 source tree so that there was just *one* 
place to go and grab everything.  Let's say that the 7.2 release (yes, 
jumping way ahead of the gun here) only changes 10 packages.  Does that 
mean we're going to have to grab 10 packages from the 7.2 folder, 130 
from the 7.1 folder then the rest from 7.0?  What a nightmare!


Regards,

Matt.

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

LFS-6.2 release plan [was Re: GNOME-2.14 Status]

[Matthew Burgess]

Randy McMurchy wrote:


3. I thought LFS would have already by now put a package freeze
   so that we can get a new release out (hint, hint)


Yeah, I know.  Real life has been getting in the way.  I should be able 
to declare a package freeze some time this week.  The plan will be:


1) Package freeze (Wed. 24th)
2) Cut an RC1 (Wed. 24th)
3) Release (Wed. 31st)

Obviously, further RCs will be released as required following testing 
from the community.  Each RC will be followed by a 1-week soak period.


Anyone having issues with any of the above feel free to point fingers 
and laugh in my general direction, oh and anything more constructive 
would be appreciated too :-)


Regards,

Matt.

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

Re: why don't add gdb package?

[Matthew Burgess]

Bruce Dubbs wrote:

I don't know if it uses an internal version of gdb or not.


I didn't think it did, but my memory is hazy at the best of times so I 
checked out the sources and INSTALL.  It lists GDB under "Execution 
Requirements" and the source tarball doesn't appear to include it's own 
version.


Regards,

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

Re: `backticks` or $(command) syntax

[Matthew Burgess]

Jeremy Huntwork wrote:

Randy McMurchy wrote:


Does anybody know right offhand if $(command) syntax is a bash-only
thing?



It appears to be. Or, at least, tcsh doesn't support it.


Please take this as tongue-in-cheek - I really don't mean to start a 
flamewar over it, but one should never consider *csh compatibility as a 
show-stopper: http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/


The SusV3/POSIX standard says that command substitution can be performed 
using either the $(command) or `command` syntax.  So, I'd simply say use 
either of those on the basis that the reader is using a standards 
conformant shell.  I'd give you the actual link to the standard but I'm 
not sure that I'm allowed to because of copyright issues.  Asking a very 
popular Internet search engine to find information on "shell command 
language command substitution" should get you the right material though, 
assuming its indexes remain accurate, of course :-)


Regards,

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

Re: New BLFS Editor

[Matthew Burgess]

Bruce Dubbs wrote:

I would like to announce that Dan Nicholson has been appointed as the
newest BLFS Editor.


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

Re: Is there a page for the open bug list in the development of lfs and blfs?

[Matthew Burgess]

nadav vinik wrote:

But I didn't find any page in the website which include open and 
critical bugs of the development lfs and blfs.


All of our bugs are available on the 'Trac' system.  For the particular 
information you want, see http://wiki.linuxfromscratch.org/lfs/report/1 
and http://wiki.linuxfromscratch.org/blfs/report/1 for LFS and BLFS 
resepctively.



When the development will become stable?


We try to keep LFS development at least buildable at all times. 
Obviously we can't guarantee its fitness for any particular purpose, but 
I know there's a number of folks that regularly use development versions 
of LFS as their production machines.



Can I upgrade my stable lfs to the development?


Yes, but don't be surprised if you encounter strange behaviour.  Oh and 
if you do encounter it, we'd love you to report it back to us so we can 
fix it :-)


Regards,

Matt.


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

Re: A cautionary tale

[Matthew Burgess]

Miguel Bazdresch wrote:


This kind of "punishment" is more appropriate in a kindergarten than in
this community.


IMNSHO, so was the behaviour that lead to it!


Bruce and Matthew are our leaders and I respect their
decision, but I deeply disagree with them.


And others have voiced similar concerns too.  This has been a steep 
learning curve for everyone involved, not least me.  It may turn out 
that I made the wrong decision, or made the decision too early/too late 
and against the wrong parties, etc.   That was why the punishment was 
suspension rather than outright dismissal - it had a clear time-limit on 
it and is easily undoable.


Regards,

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

A cautionary tale

[Matthew Burgess]

Hi folks,

No doubt you'll all be aware of the flamewar that recently hit the lists 
regarding trac and bugzilla.  Whilst disagreements are expected on this 
list, personal attacks are not appreciated by anyone involved.


As Bruce and I cannot condone such action, we decided to suspend Randy 
and Jeremy for a period of 7 days.  This suspension was intended to show 
editors that, in our opinion, they had not conducted themselves in a 
manner we thought suitable of LFS developers.


This message is reaching you firstly to let you know of what the outcome 
of their actions were and in doing so warning everyone that such 
behaviour will not be tolerated in the future.  Secondly, until their 
suspension is lifted neither Jeremy nor Randy are able to contribute to 
their respective projects.


Regards,

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

Re: KDE and CD Recording

[Matthew Burgess]

Randy McMurchy wrote:

Randy McMurchy wrote these words on 01/31/06 11:32 CST:



So, exactly how do you create Data CDs (I'm not talking about music
CDs) in the KDE graphical environment. What is the KDE tool to use?



Wow! 3 replies within 10 minutes. All saying the same thing. It is
unanimous! I'll install it right now, and report back.

So, y'all think k3b deserves to be in the book, huh?


Just thought I'd add an admittedly pointless "me too" to the discussion 
:-)  But yes, k3b rocks and would be a worthy addition to the book.  My 
script has it as an almost cmmi type affair, but as it doesn't come 
bundled with KDE by default (as you discovered yourself, Randy) it'd 
seem useful to have it in the book if only to save some googling for folks.


Regards,

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

Re: Move package management to LFS

[Matthew Burgess]

Bruce Dubbs wrote:

Matthew Burgess wrote:


Bruce Dubbs wrote:



Go ahead and put into LFS whatever you think is appropriate and we'll
"do the right thing" afterward.



OK, this is now in LFS as of r7301.



I think you need to review the text:


I already did...honest :-)


"Package Management is an often requested addition to the LFS Book."

You just added that.

"Some reasons why no package manager is mentioned in LFS or BLFS include:"


OK, it'd probably be more accurate as "Some reasons why no single 
package manager is recommended in LFS include:"



" Note

As no particular package management technique is mentioned in LFS, the
commands in the remainder of this book must be performed while logged in
as user root and no longer as user lfs. Also, double check that $LFS is
set."

You now mention several.


Well, they were mentioned before!  Again, changing "mentioned" to 
"recommended".


Thanks for your comments Bruce,

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

Re: Move package management to LFS

[Matthew Burgess]

Tushar Teredesai wrote:

On 1/24/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:


If we link to some or all of these, I worry that we will have to
continually monitor the status of the hints, i.e. to see if they still
apply to the current version of LFS and that they haven't fallen into
the "Unmaintained" bucket.


You are right. But the link to more_control should remain since it is unique:-)

Well, the *real* reason that I mentioned the hints is coz I wanted a
link to my fakeroot hint ;-)


Well, I believe that particular hint is a good example of the "Creating 
Package Archives" technique, right?  If so, I certainly don't mind 
creating a link to the fakeroot hint in that section.


Regards,

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

Re: Move package management to LFS

[Matthew Burgess]

Tushar Teredesai wrote:

On 1/24/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:


As recently discussed on the lfs-dev list and in the related bug
(http://bugs.linuxfromscratch.org/show_bug.cgi?id=1676), LFS would like
to acquire the package management info that BLFS has.


One addition. It would be nice to link to specific hints related to
package management (similar to how we do it for the more_control_.)


With or without a brief synopsis of each?  From looking at the hints 
project (which is already linked to on the Package Management page) I 
can see:


http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt
http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt
http://www.linuxfromscratch.org/hints/downloads/files/alfs_paco.txt (not 
sure this is applicable, as it assumes the use of nALFS)

http://www.linuxfromscratch.org/hints/downloads/files/rpm.txt
http://www.linuxfromscratch.org/hints/downloads/files/paco.txt
http://www.linuxfromscratch.org/hints/downloads/files/lpm.txt
http://www.linuxfromscratch.org/hints/downloads/files/pm_with_git.txt

If we link to some or all of these, I worry that we will have to 
continually monitor the status of the hints, i.e. to see if they still 
apply to the current version of LFS and that they haven't fallen into 
the "Unmaintained" bucket.


Regards,

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

Move package management to LFS

[Matthew Burgess]

Hi folks.

As recently discussed on the lfs-dev list and in the related bug 
(http://bugs.linuxfromscratch.org/show_bug.cgi?id=1676), LFS would like 
to acquire the package management info that BLFS has.  I've attached a 
patch (`svn diff` format) that removes the information from BLFS, on the 
assumption that you guys won't object to the approach we'd like to take. 
 Obviously, if you do have any concerns, then shout and I'll stop dead 
in my tracks.


Regards,

Matt.
Index: introduction/important/pkgmgt.xml
===
--- introduction/important/pkgmgt.xml	(revision 5591)
+++ introduction/important/pkgmgt.xml	(working copy)
@@ -1,239 +0,0 @@
-
-http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"; [
-  
-  %general-entities;
-]>
-
-
-  
-
-  
-$LastChangedBy$
-$Date$
-  
-
-  Package Management
-
-  Package Management is an often requested addition
-  to the LFS Book. A Package Manager allows tracking
-  the installation of files making it easy to remove and upgrade packages.
-  And before you begin to wonder, NO—this section does not talk about any
-  particular package manager, nor does it recommend one. What it provides is
-  a roundup of the more popular techniques and how they work. The perfect
-  package manager for you may be among these techniques or may be a combination
-  of two or more of these techniques. This section briefly mentions
-  issues that may arise when upgrading packages.
-
-  Some reasons why no package manager is mentioned in LFS
-  or BLFS:
-
-  
-
-  Dealing with package management takes the focus away from
-  the goals of these books—teaching how a Linux system is built.
-
-
-  There are multiple solutions for package management, each having
-  its strengths and drawbacks. Including one that satisfies all audiences is
-  difficult.
-
-  
-
-  There are some hints written on the topic of package management. Visit
-  the Hints subproject
-  and see if one of them fits your need.
-
-  
-Upgrade Issues
-
-A Package Manager makes it easy to upgrade to newer versions when
-they are released. Generally the instructions in the LFS and BLFS Book can be
-used to upgrade to the newer versions. Here are some points that you should
-be aware of when upgrading packages, especially on a running system.
-
-
-  
-If one of the toolchain packages
-(Glibc, GCC or
-Binutils) needs to be upgraded to a newer
-minor version, it is safer to rebuild LFS. Though you
-may be able to get by rebuilding all the packages
-in their dependency order, we do not recommend it. For example, if
-glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer to rebuild.
-For micro version updates, a simple reinstallation usually works, but
-is not guaranteed. For example, upgrading from glibc-2.3.4 to
-glibc-2.3.5 will not usually cause any problems.
-  
-  
-If a package containing a shared library is updated, and if the
-name of the library changes, then all the packages dynamically linked
-to the library need to be recompiled to link against the newer library.
-(Note that there is no correlation between the package version and the
-name of the library.) For example, consider a package foo-1.2.3 that
-installs a shared library with name
-libfoo.so.1. Say you upgrade
-the package to a newer version foo-1.2.4 that installs a shared library
-with name libfoo.so.2. In this
-case, all packages that are dynamically linked to
-libfoo.so.1 need to be
-recompiled to link against
-libfoo.so.2. Note that you
-should not remove the previous libraries until the dependent packages
-are recompiled.
-  
-  
-If you are upgrading a running system, be on the lookout for packages
-that use cp instead of install
-to install files. The latter command is usually safer if the executable
-or library is already loaded in memory.
-  
-
-
-  
-
-  
-Package Management Techniques
-
-The following are some common package management techniques. Before
-making a decision on a package manager, do some research on the various
-techniques, particularly the drawbacks of the particular scheme.
-
-
-  It is All in My Head!
-
-  Yes, this is a package management technique. Some folks do not find the
-  need for a package manager because they know the packages intimately and know
-  what files are installed by each package. Some users also do not need any
-  package management because they plan on rebuilding the entire system
-  when a package is changed.
-
-
-
-
-  Install in Separate Directories
-
-  This is a simplistic package management that does not need any
-  extra package to manage the installations. 

LFS-6.1.1 released

[Matthew Burgess]

The Linux From Scratch community is pleased to announce the release of 
LFS 6.1.1. This release includes fixes for all known errata since 
LFS-6.1 was released 4 months ago.


You can read the book online at 
http://www.linuxfromscratch.org/lfs/view/6.1.1/ or download it from 
http://www.linuxfromscratch.org/lfs/downloads/6.1.1/ to read locally.


Regards,

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

LFS-6.1.1-pre2 Released

[Matthew Burgess]

The Linux From Scratch community is pleased to announce the second 
pre-release of LFS 6.1.1. In addition to the fixes already made in 
LFS-6.1.1-pre1, this release addresses a bug in Glibc that prevents some 
programs (including OpenOffice.org) from running.


You can read the book online at 
http://www.linuxfromscratch.org/lfs/view/6.1.1-pre2/ or download it from 
http://www.linuxfromscratch.org/lfs/downloads/6.1.1-pre2/ to read locally.


This being a test release, we would appreciate you taking the time to 
try it out and report any bugs you find in it to the LFS development 
team at [EMAIL PROTECTED]


The final release is planned for Wednesday 30th November.

Best regards,

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

LFS-6.1.1-pre1 Released

[Matthew Burgess]

The Linux From Scratch community is pleased to announce the first 
pre-release of LFS 6.1.1. This release includes fixes for all known 
errata since LFS-6.1 was released 4 months ago.


You can read the book online at 
http://www.linuxfromscratch.org/lfs/view/6.1.1-pre1/ or download to read 
locally from http://www.linuxfromscratch.org/lfs/downloads/6.1.1-pre1/


This being a test release, we would appreciate you taking the time to 
try it out and report any bugs you find in it to the LFS development 
team at [EMAIL PROTECTED]


The final release is planned for Saturday 26th November.

A special note of thanks to Archaic for his assistance with all the 
behind the scenes activities that went into this release.  His release 
scripts and notes as have been a massive time saver!  Archaic, you're a 
star!


Regards,

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

Re: News Server Offline Indefinitely

[Matthew Burgess]

Jeremy Huntwork wrote:

Greetings All:

Due to various recurring issues with our news server, it has been 
decided to take it offline indefinitely. We apologize for any 
inconvenience this causes.


In the meantime, the LFS server admins are researching making use of 
gmane.org for those users that prefer using news servers over mailing 
lists.


Jeremy, is it off for good with immediate effect, or are you going to 
wait until the gmane stuff gets sorted out?  There are some lists that 
aren't being mirrored at all by gmane, leaving those users who don't 
want to subscribe to the lists no alternative.


I contacted the gmane guys today to see about getting things organised 
with regard to a more consistent mirroring setup for all of the lists, 
and am just waiting to hear back from them.


Regards,

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

Re: ALSA modules and restore volumes

[Matthew Burgess]

Bruce Dubbs wrote:

Richard A Downing wrote:



I used to take the view (before I retired) that if:  you found the right
expert; were convinced they understood the problem; and then took their
advice - that you didn't need to fully understand the topic yourself -
indeed there were more complicated things about than one person could
understand completely.  Although I'm minded to trust Alex on this,
perhaps it needs just a little more understanding on my part than usual.



But sometimes you want to *be* the expert.  It can be an itch that you
need to scratch.  Basically that is what {,B}LFS is all about...
learning more than "necessary".  To me, always learning new things is
essential.  Having the source code and the mailing lists and the net in
general makes is possible to drill down until the itch is satisfied.



Apologies for the massive quoting here, but I'd just like to add that 
I'm in complete agreement with Richard and Bruce here.  I am in awe of 
Alexander's understanding of all things udev, hotplug, kernel and module 
related.  That though, makes it all the more frustrating when I don't 
understand the issues myself.  Like Andrew Benton mentioned, I too have 
avoided all this by simply compiling everything into the kernel, thus 
I've never experienced any of the module related bugs others are 
currently suffering.


Whilst the desire to learn this stuff properly is still strong, up until 
now I have had no *personal* motivation to fix the module related bugs 
in LFS.  Now that it's been more or less drilled into me that upstream 
really isn't in any fit state to have hotplug removed from the setup, 
I'll have to bite the bullet and see to getting all the module 
hotplugging related bugs sorted out *then redo it all again* once we can 
ceremoniously see the back of the hotplug package once and for all!


Regards,

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

Re: ALSA modules and restore volumes

[Matthew Burgess]

Dan Nicholson wrote:

If anything is
written, I'd be glad to peruse it and give an opinion as someone who
still has only the loosest grasp of how the hardware is set up.


Well, I've written some notes up on this, though they're not entirely 
accurate. 
http://www.linuxfromscratch.org/pipermail/lfs-dev/2005-October/053675.html 
has the original announcment and 
http://www.linuxfromscratch.org/pipermail/lfs-dev/2005-October/053676.html 
has Alexander Patrakov's corrections to it, which I still haven't gotten 
around to incorporating yet.


Regards,

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

Re: ALSA modules and restore volumes

[Matthew Burgess]

Randy McMurchy wrote:


This now appears to be a continuation of the previous threads on
LFS-Dev about should or should not LFS define rules.


And I'll ask again, aside from plain ol' `cat' (which isn't useful for 
anything than raw PCM files, IIRC), what tools in LFS can utilise the 
sound devices?  If there aren't any, I don't see how we can feasibly set 
sensible permissions on sound devices in LFS and *adequately* explain 
the reasoning behind the policies we set (and no, I don't consider "we 
do this because ALSA (see BLFS), which you may or may not end up 
installing, requires this configuration" to be an adequate explanation).


What I do think could do with improving, and it will do with a revamped 
udev setup in LFS, is the explanation of how udev works and a general 
explanation of how to set up rules and a pointer to examples as provided 
by BLFS for common things like audio and video devices.


Regards,

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

Re: FAM/Gamin

[Matthew Burgess]

Randy McMurchy wrote:


I'm not getting much done anyway. I'm watching the Tulane Green
Wave play football on TV. My son doesn't play, but just stands on
the sideline in his uniform.


Your son's a cheerleader? :)
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: Remove GTK+-1?

[Matthew Burgess]

Richard A Downing wrote:


Of course, you have to have some cash


And not be married - a finanical management application is of no use to 
me whatsoever - I already know my wife spends money faster than I can 
earn it, I don't need a computer to tell me that :)


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

Re: Remove GTK+-1?

[Matthew Burgess]

Randy McMurchy wrote:


GnuCash works with current LFS-SVN and fills a void that really
can't be solved with any other open source package. 


Aside from those recently reviewed by The Grumpy Editor, of course: 
http://lwn.net/Articles/149383/.  Note, I'm not suggesting that GnuCash 
be removed, just pointing out that there are 2 least 2 other viable 
alternatives.


Regards,

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

Re: D-BUS/HAL Woes

[Matthew Burgess]

Randy McMurchy wrote:

If I simply click
on the icon for the inserted USB device, it then automatically
mounts and allows me to browse the contents.

Not sure how or why.


FWIW I experience the same behaviour in KDE under Kubuntu (still haven't 
got quite that far in my own LFS/BLFS builds yet!).  I don't know why 
it's like this, but at least it appears to be consistent across desktop 
environments.  I tried emulating it under a command-line environment, 
but obviously one can't access (via 'ls' or 'cd') the mountpoint until 
the mount has actually taken place.  For this a manual 'pmount /dev/sda' 
is still required (and is probably what KDE/GNOME are emulating when you 
click on the icon/folder).


Regards,

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

Re: Creating users that don't need a specific group

[Matthew Burgess]

Randy McMurchy wrote:


I'm creating instructions for the BLFS book to add the D-BUS package.
There is a user that needs to be created but this user has no
specific group that it needs to be added to.


In its short life, I believe tradition has this user set up as 
'messagebus' in group 'messagebus'.  I know it doesn't answer the full 
question, for that I'm in vehement agreement with archaic - just put 
users that don't specifially need group membership in their own group.


Regards,

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

Re: NTP bootscript causes long boot-times

[Matthew Burgess]

Ken Moffat wrote:

 I think it depends where you go for your timeservers - on my server 
(normally up, modulo hardware changes and kernel crashes) I've commented 
out the 'ntpd -gqx' with a note that I was getting an 'already running 
message' (gcc-3.4.3, ntp-4.2.0).  Works fine like this.


That 'already running' message is a symptom of the ntpdate-esque ntpd 
not having finished running by the time the sync-mode ntpd gets kicked 
off.  Or at least that's what I concluded when seeing the same message 
here during my own tests.


As for the timeservers, I've tested with just my router and with a 
combination of the ones listed in the BLFS book (generally just using 
the European one though to save time).


On my desktops/laptop (which get ntp from my server) the ntpd -gqx 
works fine after bios resets (or ibook system resets) and results in 
only a short delay during any boot.  No detectable difference between 
gcc-3.3.5/gcc-3.4.3/gcc-4.0.1 on the desktops (all with ntp-4.2.0, gcc4 
with the patch).


So, just to confirm:  Your ntp bootscript is unchanged on these machines 
(and is from a release newer than October-2004), you have them syncing 
to remote timeservers and those machines complete the ntp bootscript in, 
say, < 2 seconds?  Do they have anything particularly quirky in the 
/etc/ntp.conf file?


Of course, it's possible this is a problem with 4.2.0a, or perhaps you 
upgraded something else (e.g. the kernel) ?


Hmmm, good point, I'm actually on 2.6.13.2 here.  I spotted a LKML post 
(http://www.ussg.iu.edu/hypermail/linux/kernel/0509.2/0514.html) 
suggesting it might be broken, but noone can apparently confirm or deny 
that.  I'll try reverting to ntp-4.2.0 then to linux-2.6.12.6 to see if 
they fix the problem.


Regards,

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

NTP bootscript causes long boot-times

[Matthew Burgess]

Hi folks,

I've just built ntp (version 4.2.0a due to the gcc-4 fixes I need), and 
installed the bootscript from blfs-bootscripts-2005-09-10.  The ntp 
bootscript takes anywhere between 17 seconds and 51 seconds to complete, 
dependent on which servers I've configured in /etc/ntp.conf.  This is 
*not* acceptable during bootup, well not for me at least!


This command appears to have been introduced following 
http://www.linuxfromscratch.org/pipermail/blfs-dev/2004-October/007767.html. 
 The initial suggestion was to use `ntpdate', but a comment was made 
that `ntpdate' is deprecated, hence the decision to use `ntp -gqx'.


The trouble is that `ntp -gqx' acts very differently than `ntpdate'. 
`ntpdate' uses a really simple "let's use the first time we get back 
from the first server we hit, pass it into settimeofday() and bob's your 
uncle, I'm finished" approach, hence completes very quickly.  The NTP 
FAQ[1] goes into the reasoning behind why this isn't such a good idea 
(lack of accuracy of that one and only sample, clocks shouldn't go 
backwards, etc.), hence `ntp -gqx' still polls a number of servers until 
it's deemed reasonably safe to start the process of syncing the time 
using adjtimex().  This obviously takes much longer than the trivial 
`ntpdate' approach.


I think the solution is to move the initial time-sync operation out of 
the bootscript and into the configuration section of NTP (obviously with 
enough explanation as to why we need to do this and why it should be a 
one-time operation, but faulty hardware like a dodgy CMOS battery might 
require it to be rerun).  This should avoid the problem of the clocks 
being too far out that ntpd refuses to sync them.  It then allows `ntpd' 
to start up nice and quickly during the boot process as it operates in 
its normal gradual adjustment mode.


Regards,

Matt.

[1] http://www.ntp.org/ntpfaq/NTP-s-config.htm

PS: I found http://forums.fedoraforum.org/archive/index.php/t-11540.html 
particularly helpful in explaining why boot-times were so severly 
affected by ntpd.

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