Re: [blfs-dev] pulseaudio runaway

[Richard Melville via blfs-dev]

On Tue, 30 Apr 2019 at 23:39, Thomas Trepl via blfs-dev <
blfs-dev@lists.linuxfromscratch.org> wrote:

> Am Dienstag, den 30.04.2019, 15:59 -0600 schrieb Roger Koehler via
> blfs-dev:
>
> On Tue, Apr 30, 2019, 3:50 PM Ken Moffat via blfs-dev <
> blfs-dev@lists.linuxfromscratch.org> wrote:
>
> On Tue, Apr 30, 2019 at 04:13:44PM -0500, Bruce Dubbs via blfs-dev wrote:
> > I've been noticing that sometimes pulseaudio consumes 100% of one core
> and
> > stays that way for hours.  In one case I can close every application on
> my
> > desktop and pulseaudio still runs at 100%.
> >
> > It doesn't really affect things because I have four cores and response
> stays
> > fine, but it shouldn't be happening.
> >
> > Has anyone else seen this?
> >
> >   -- Bruce
>
> Yes, but only on my AMD Phenom, and I think I've seen it across all
> releases from the past few years.  'killall -KILL pulseaudio'.
>
> At one time I removed all its config files and let it regenerate
> them when next used, but the issue remains.
>
>
> I've stopped using pulseaudio. ALSA seems to be able to meet all of my
> needs. I also noticed the LXDE desktop constantly maxing out one of cores
> (Intel), so I just use xfce.
>
>
> Thats my goal, too. I'd need a soundsystem on my host which can be
> controlled/accessed by mpd and it should be able to auto-connect to a
> bluetooth speaker. All that if possible without any user interaction, just
> be available after system boot. So far, PA worked ok (while not ideal as i
> have to do one mouseclick in X on the host to connect to the bluez device).
> Hope alsa can work with bluez well.
> And yes, xfce is a nice DE, i'm using it for years now, its the best fit
> in resource, stability and beauty
>

"Beauty", are you sure? It looks like something out of the 1990s, which, of
course, is what it is.

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

Re: [blfs-dev] From xfce4-xkb-plugin to rustc, layering?

[Richard Melville via blfs-dev]

On Mon, 5 Nov 2018 at 07:28, Thomas Trepl via blfs-dev <
blfs-dev@lists.linuxfromscratch.org> wrote:

> Am Donnerstag, den 01.11.2018, 14:47 -0400 schrieb Jean-Marc Pigeon
> via blfs-dev:
> > Hello,
> >
> > ...
> >
> > Well... as there is countries flags in "svg" format you
> > need librsvg, right
> >
> > librsvg need cargo (according designer, to be able to
> > easily set the compilation debug flag (?)), and cargo
> > is embedded with rustc...
> >
> > Wohhh... I have seen Email with a subject as "I hate rustc".
> >
> > Lets figure this out.
> > #metoo, "I hate rustc".
> > - 2 Build,  hours apart won't give the same result, event
> >if it is the same version number.
> > - As package is huge (2Gig), compilation time is out
> >of control.
> > - No way to compile without being on the net.
> > - Its a "package deal" coming with own basic libraries set
> >(doubling the bugs surface)
> > - RPM file is near 600 Megs
> >(600 Megs for a compiler???, some time ago, I designed a
> > YACC parser in UCSD-pascal, within the Apple-II 64kbyte memory,
> > and it was able to compile its own YACC definition and rebuild
> > itself..., come on, 600 Megs for compiler...).
> > - Rustc project seems to be a biological chimera between
> >C (language) and modula2 (units implementation and
> >standardization)
> > - I wonder if rustc is an experimentation or a "coding bad trip".
> >
> > I (strongly) think rustc should be outcasted From Linux From Scratch.
> >
> > ...
> >
> I have never updated librsvg beyond 2.40.20, so no rustc on my
> systems. X11/Xfce works well so far. Ok, i also do not install firefox
> (systems are mainly servers) and i'm looking for alternatives.
> Does firefox *require* newer versions of librsvg or is it just because
> we have newer versions in book?
>
> Currently looking at Vivaldi - a chromium based browser. But source
> tarball is 1GB in size - so my hope for something lightweight is
> rather small.
>

In addition, Vivaldi is proprietary "freeware" and not FLOSS.

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

[blfs-dev] Emacs and EWW

[Richard Melville via blfs-dev]

A very nice web browser EWW (emacs web wowser -- a backronym) has been
included in the default emacs build since version 24.4.  It includes the
"duck duck go" web search engine which launches automatically if EWW does
not detect a URL or a file name typed into the minibuffer.  I can confirm
that this works really well.  Maybe this should be mentioned, either on the
emacs page or the text browser page, or both.

I'm suggesting this because anybody not familiar with emacs might be more
interested in installing it if they are already aware of EWW.

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

Re: [blfs-dev] Trimming BLFS

[Richard Melville via blfs-dev]

On 24 September 2018 at 20:36, Bruce Dubbs via blfs-dev <
blfs-dev@lists.linuxfromscratch.org> wrote:

>
> btrfs-progs-4.17.1
> xfsprogs-4.18.0
>

Maybe it's not relevant here but these two are the default file systems for
openSUSE Tumbleweed.  Btrfs has matured over the years and is an
interesting alternative to the widely used Ext4.  I've been using it for
the last five or six years and found it to be quite stable, and very
useful.


> zsh-5.6
>

This is widely used as a bash alternative.

>
> Guile-2.2.4
>

There has been a lot of work recently integrating guile with emacs in an
effort to improve emacs further.  I think that it would be a mistake to
remove it from the book.

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

Re: [blfs-dev] Mailing list issues

[Richard Melville via blfs-dev]

On 30 August 2018 at 20:17, Ken Moffat via blfs-dev <
blfs-dev@lists.linuxfromscratch.org> wrote:

> On Thu, Aug 30, 2018 at 01:45:10PM -0500, Brendan L via blfs-dev wrote:
> > It happened to me a few months ago, I was wondering what was up.
> >
> It happened to me this morning on blfs-support, I assumed it was just
> my usual upstream doing its "randomly fail to accept email" normal
> procedure ;)
>

I don't believe that this is anything new, but maybe it has intensified.  I
was unsubscribed a couple of years ago, and it happened again two days
ago.  Let's see how it goes after Bruce's configuration changes.

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

Re: [blfs-dev] colord fix for warnings:

[Richard Melville]

On 29 April 2018 at 01:19, Ken Moffat  wrote:

> On Fri, Apr 27, 2018 at 09:55:45PM -0500, Bruce Dubbs wrote:
> > On 04/27/2018 08:08 PM, Ken Moffat wrote:
> > > Looking at the sed in colord, I question its usefulness.  Sure,
> > > without it ninja produces the warnings, regarding fur as an invalid
> > > country code, but labelling what is friulian (a language, or dialect
> > > depending on your point of view) of Italy as Urdu seems unuseful.
> > >
> > > Now, quite why something is looking for _country_ codes when it
> > > should be looking for _language_ codes I do not understand.
> > >
> > > Raised upstream, https://bugs.freedesktop.org/show_bug.cgi?id=106288
> >
> > You are much more knowledgeable about that than I am.  I thought it was a
> > typo.  I never heard of friulian before.
> >
> >   -- Bruce
>
> Well, you might have heard of it under a slightly different name (I
> looked at wikipedia earlier, but I forget what that name was).
> Friulian is what we Brits call it.  And technically it isn't a
> dialect of Italian (it has Rhaeto-Romanic antecedents).  But ever
> since I spent holidays in the alps, I've been fascinated by the
> different languages and the way that speech in alpine regions can
> vary even over very short distances (presumably because they used to
> be cut off from each other for much of the year).
>
> Unfortunately, the 'country' label is a red herring - the problem is
> that the spec for ICC profiles includes two bytes for the language
> (ISO-639-1) but other languages covered by -2 or -3 need three
> bytes.
>
> I haven't built it without the sed yet, and I'm not sure what will
> result.  Hopefully I'll at least remember to install all locales on
> my next build.
>

Let me start by saying that this has nothing to do with the bug, but I was
intrigued by Ken's description of languages in the Alps, of which, like
Bruce, I knew nothing.

Coincidently (or maybe not, considering how data is exchanged these days) I
received a post from Quora this morning asking "when did Italy start
speaking one language?".  I'm posting the answer by Riccardo Sciolti here
because I thought that others may be as surprised, and interested, as I
am:-

"Italy, unknown to most, possibly has the richest linguistic diversity in
the whole EU. It is also on the forefront of minority language protection.

Actual LANGUAGES spoken (and partly protected by law) in Italy include:

   - Italian (obviously)
   - German (in South Tyrol)
   - French (in Valle d'Aosta)
   - Occitanic (in Western Piedmont valleys)
   - Catalan (in Alghero, Sardinia)
   - Sardinian (a language, not a dialect)
   - Friulian (a language, not a dialect)
   - Slovenian (in selected towns and villages near Trieste)
   - Ladin (a Romance language, also spoken in Swiss Grisons — few valleys
   in South Tyrol)
   - Cymbric (an old Teutonic dialect, few villages in Central Alps)
   - Greek (in three villages in Apulia)
   - Albanian (in fairly large, scattered communities in Molise, Calabria
   and Sicily— these are the descendants of the Christian army who fled
   Albania in the 16th Century, after being defeated by the Turks)
   - Rhaesian, a slavic dialect in a specific valley on Friulian Alps
   - Walser or Titsch (a Germanic dialect in Valle d'Aosta)"

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

Re: [blfs-dev] libressl

[Richard Melville]

On 22 April 2018 at 16:51, Bruce Dubbs <bruce.du...@gmail.com> wrote:

> On 04/22/2018 10:32 AM, ag wrote:
>
>> On Tue, Apr 10, at 10:48 ag wrote:
>>
>>> On Mon, Apr 09, at 02:49 Bruce Dubbs wrote:
>>>
>>>> On 04/09/2018 02:18 PM, Richard Melville wrote:
>>>>
>>>
> We just have to provide two different sets of instructions; one for
> openssl and
>
>> one for libre. No big deal.
>>>
>>   Its not that simple as both can not coexist in the same namespace.
>>   The thing is that the sonames are identical and much of the API (if
>> all, i don't
>> know) but that doesn't certainly provides ABI compatibility. So all the
>> libraries
>> and applications should link against the specific library.
>>
>
> Interesting.
>
> Now for us that means some choises:
>>1. we can just add a page for libressl and whereever refers openssl,
>> we have
>> additionally refer libressl. But there must be a big fat warning that
>> either
>> one or the other. (and also to wait for breakages when linking with
>> libressl,
>> for instance I use a patch to build the elinks web browser, but this
>> is not
>> going to be a big issue as there is a precedence and a source we can
>> take
>> patches)
>>
>> 2. use different namespaces. This should work. But it is not practical and
>> can be a little bit complicated.
>> We have to talk about using the LD_LIBRARY_PATH, when building and
>> when
>> running the applications. Personally someone can take this path but as
>> book instructions again is not practical and can end up wasting our
>> time
>> anwsering questions
>>
>> 3. another copy of the book that will have libressl as the default tls
>> layer.
>> I can do this book in the summer when we are going to build lfs with
>> Dimy,
>>
>
> What is this about?  What is Dimy?
>
> but I shouldn't be able to test as I use very little things already and
>> its going to be worse with years, but we can do this with my son as an
>> educational project
>>
>> My opinion is the first option or nothing but this is horrible and its a
>> pity.
>>
>
> I agree with the do nothing option.


I wasn't going to be drawn into this discussion again as it appears that
Bruce's mind is already made up, however, I think that a summary is worth
the effort.

Taking openssh as the starting point, the discussion revolved around which
of the two TLS libraries, openssl or libressl, should be linked to it.
Openssh is an openbsd project, so which makes more logical sense: another
openbsd project: libressl. or openssl from an entirely separate developer
team with a heavily patched openssh?

Another point that I'd like to make is that since 2014 openssh does not
need *any* additional TLS library as it already contains the AES-CTR,
ED25519, ECDH, and ChaCha20 cryptos, where elliptic curve is more secure,
and faster, than RSA/DSA.  An added advantage is that building openssh in
this manner produces a much smaller code base, which is always better.
Compiling openssh without the patch, and using -- without-openssl worked
for me.

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

Re: [blfs-dev] pppoe network service script

[Richard Melville]

On 18 April 2018 at 17:45, Tim Tassonis  wrote:

>
> I'm not asking for inclusion into blfs-bootscripts and also agree with
> Bruce that pppoe maybe is not the bright future of internet connectivity, I
> just wanted to share it in case someone has a similar setup.
>
> It (pppoe) may not be the "bright future of internet connectivity" but
here in the UK many people (myself included) still rely on ADSL and the
copper pair supplied by British Telecom/Openreach; a company which, since
privatisation, is now pretty much a privatised monopoly.  Although, for
"privatised" read public limited company (plc).

If you look on amazon.co.uk you will see just how many big-name
manufacturers of routers have a version in their range that has a built-in
ADSL modem.  Although, personally, I prefer to use a separate modem
(usually a D-Link DSL320B) in bridge mode.  I can then use BLFS, or
OpenWrt, on the router itself, built by us, or commercially available.
Just out of interest I've been playing with one of these recently
https://www.gl-inet.com/ar150/ and they are really impressive, as, indeed,
is this company's whole range.

So, all I really wanted to say was that it's always useful to see how
others are handling ppoe.

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

Re: [blfs-dev] openssh-7.7p1

[Richard Melville]

On 9 April 2018 at 21:59, Tim Tassonis <st...@decentral.ch> wrote:

> On 04/09/2018 09:18 PM, Richard Melville wrote:
>
>> On 9 April 2018 at 17:31, Tim Tassonis <st...@decentral.ch > st...@decentral.ch>> wrote:
>>
>>     On 04/09/2018 09:47 AM, Richard Melville wrote:
>>
>> On 7 April 2018 at 23:48, Tim Tassonis <st...@decentral.ch
>> <mailto:st...@decentral.ch> <mailto:st...@decentral.ch
>>
>> <mailto:st...@decentral.ch>>> wrote:
>>
>>  On 04/08/2018 12:42 AM, Bruce Dubbs wrote:
>>
>>  It's disturbing that openssh still requires a 60K patch
>> to build
>>  with openssl-1.1.0.  openssl-1.1.0. has been in release
>> since
>>  August 2916.
>>
>>
>>  I guess that's probably because they just concentrate on
>> their own
>>  libressl.
>>
>>
>> Which is why I suggested, a long time ago, that we replace
>> openssl with libressl.  I use it and have had no issues.
>>
>>
>>
>> Tricky situation, I think. On one hand, it's a very good thing of
>> lfs/blfs to usually quickly follow upstream on new versions.
>>
>> In the openssl case, they went for an api change with 1.1, and quite
>> a few dependent packages did not (yet) follow, as dropping 1.0
>> support would break compatibility with libressl, as libressl does
>> not seem to prioritize 1.1 support. I just looked at libressl's
>> release notes for their latest 2.7.2 release:
>>
>>   * Added support for many OpenSSL 1.0.2 and 1.1 APIs, based on
>> observations of real-world usage in applications. These are
>> implemented in parallel with existing OpenSSL 1.0.1 APIs -
>> visibility
>> changes have not been made to existing structs, allowing code
>> written
>> for older OpenSSL APIs to continue working.
>>
>>
>> This translates to me that full openssl 1.1 compatibility is not
>> high on libressl's priority list, and so it looks like the
>> situation  with opensh will also not change in the near future.
>>
>>
>> Well, I disagree.  Joel Sing has made it clear that he wants libressl to
>> be a drop-in replacement for openssl.  He has also stated publicly that he
>> thinks opaque data structures (the basis of the openssl 1.1 API change) are
>> a good thing.  It's openssl that has broken compatibility between the 1.0
>> and the 1.1 APIs, and thus created issues with openssh, not libressl.  It
>> is, therefore, unrealistic to expect libressl to conform to the 1.1 API
>> over night.  Clearly, it is going to take some considerable time.
>>
>
> Well, as I read you, you actually fully agree...
>
> I am not expert enough to judge on the quality differences between openssl
> and libressl, not am I well informed enough to judge about the necessity of
> the api break between openssl 1.0 and 1.1. I was just trying to describe
> the current situation as neutrally as possible.
>

Tim, I don't think that our disagreement was over the time scale, but
rather the inclination of the libressl developers.

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

Re: [blfs-dev] openssh-7.7p1

[Richard Melville]

On 9 April 2018 at 20:49, Bruce Dubbs <bruce.du...@gmail.com> wrote:

> On 04/09/2018 02:18 PM, Richard Melville wrote:
>
> Well, I disagree.  Joel Sing has made it clear that he wants libressl to
>> be a drop-in replacement for openssl.  He has also stated publicly that he
>> thinks opaque data structures (the basis of the openssl 1.1 API change) are
>> a good thing.  It's openssl that has broken compatibility between the 1.0
>> and the 1.1 APIs, and thus created issues with openssh, not libressl.  It
>> is, therefore, unrealistic to expect libressl to conform to the 1.1 API
>> over night.  Clearly, it is going to take some considerable time.
>>
>
> It has been two years.  How much time do you think is reasonable?
>
> As a corollary of the need for the original fork, we have seen how many
>> further openssl security breaches were discovered post fork, none of which
>> affected libressl.
>>
>
> I wonder why there has been no mass exodus to libressl.  It has been
> around from 2014.  Do you have any ideas about that?
>
> I did read https://en.wikipedia.org/wiki/LibreSSL
> It does read like it was written by libressl or bsd developers.


Bruce, I'm neither a libressl nor a bsd developer, but merely a bystander
watching from the sidelines.  My interest is that I have chosen to use
libressl over openssl because I believe that it is a superior product, and
I have had no issues with it.  So, in answer to your question about what is
a reasonable time for 1.1 API compliance, I don't know, but from the
evidence that I have seen I am confident that the will is there.  Of
course, that's my personal view.

Regarding "no mass exodus to libressl", I don't think that a "mass exodus",
or the lack of it, determines what is good software and what isn't.
Clearly, openssl has the impetus (and the inertia) by having been around
for years.  A similar example is the apache web server.  It's been around
for years and, in my opinion, has become a bloated monster.  There are a
host of other web servers, which, in my opinion, are mostly a lot better;
nginx perhaps being the best known, but also a number of fast web servers
written in erlang.  Despite this, apache still has a huge following.
People are loathe to move from a product with which they are familiar.

Wikipedia pages have to be written by someone, and I'm sure that most of
them contain bias.

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

Re: [blfs-dev] openssh-7.7p1

[Richard Melville]

On 9 April 2018 at 17:31, Tim Tassonis <st...@decentral.ch> wrote:

> On 04/09/2018 09:47 AM, Richard Melville wrote:
>
>> On 7 April 2018 at 23:48, Tim Tassonis <st...@decentral.ch > st...@decentral.ch>> wrote:
>>
>> On 04/08/2018 12:42 AM, Bruce Dubbs wrote:
>>
>> It's disturbing that openssh still requires a 60K patch to build
>> with openssl-1.1.0.  openssl-1.1.0. has been in release since
>> August 2916.
>>
>>
>> I guess that's probably because they just concentrate on their own
>> libressl.
>>
>>
>> Which is why I suggested, a long time ago, that we replace openssl with
>> libressl.  I use it and have had no issues.
>>
>
>
> Tricky situation, I think. On one hand, it's a very good thing of lfs/blfs
> to usually quickly follow upstream on new versions.
>
> In the openssl case, they went for an api change with 1.1, and quite a few
> dependent packages did not (yet) follow, as dropping 1.0 support would
> break compatibility with libressl, as libressl does not seem to prioritize
> 1.1 support. I just looked at libressl's release notes for their latest
> 2.7.2 release:
>
>  * Added support for many OpenSSL 1.0.2 and 1.1 APIs, based on
>observations of real-world usage in applications. These are
>implemented in parallel with existing OpenSSL 1.0.1 APIs - visibility
>changes have not been made to existing structs, allowing code written
>for older OpenSSL APIs to continue working.
>
>
> This translates to me that full openssl 1.1 compatibility is not high on
> libressl's priority list, and so it looks like the situation  with opensh
> will also not change in the near future.
>

Well, I disagree.  Joel Sing has made it clear that he wants libressl to be
a drop-in replacement for openssl.  He has also stated publicly that he
thinks opaque data structures (the basis of the openssl 1.1 API change) are
a good thing.  It's openssl that has broken compatibility between the 1.0
and the 1.1 APIs, and thus created issues with openssh, not libressl.  It
is, therefore, unrealistic to expect libressl to conform to the 1.1 API
over night.  Clearly, it is going to take some considerable time.

As a corollary of the need for the original fork, we have seen how many
further openssl security breaches were discovered post fork, none of which
affected libressl.

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

Re: [blfs-dev] openssh-7.7p1

[Richard Melville]

On 7 April 2018 at 23:48, Tim Tassonis  wrote:

> On 04/08/2018 12:42 AM, Bruce Dubbs wrote:
>
>> It's disturbing that openssh still requires a 60K patch to build with
>> openssl-1.1.0.  openssl-1.1.0. has been in release since August 2916.
>>
>
> I guess that's probably because they just concentrate on their own
> libressl.
>

Which is why I suggested, a long time ago, that we replace openssl with
libressl.  I use it and have had no issues.

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

Re: [blfs-dev] Versioning

[Richard Melville]

On 18 March 2018 at 08:33, Pierre Labastie  wrote:

> Hi,
>
> I cannot remember who (and on which list) did complain about versioning.
> I've
> found this: https://semver.org/
>
> Maybe we could mention it to our upstream devs...
>

You can't remember!!!? :-)  It was Bruce:-

[blfs-dev] QA in BLFS

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

Re: [blfs-dev] A few suggestions including a package manager

[Richard Melville]

On 4 March 2018 at 15:41, Pierre Labastie  wrote:

> On 04/03/2018 06:34, m...@pc-networking-services.com wrote:
>
> > 2) There is a package manager already that works on building from source
> > code.  It is called nix https://nixos.org/nix/.  I have off and on
> looked
> > at this, and it was only through reading the documentation on it, that I
> > found that it can be made to use source only builds by moving the default
> > location, so that it will not download ANY binary builds.
> >
> > For me it gave me a really bad headache as you need to learn the nix
> > language and add the build scripts, much like jhalfs does.  What this
> > package manager does is install in a DEST-DIR.  Each package has its own
> > directory.  It may well be that some of the programmers, on the team may
> > find it very easy to add the scripts.  If this could be made to work at
> > the LFS stage then any packages added on at the BLFS stage would get
> > automatically added to the nix package repository.
> >
> > It may also take a little of the stress out of security updates as you
> are
> > also able to check for updates.  If this could be achieved then future
> > upgrade/downgrade of packages could be rather painless.
> >
> > The adaption to this sort of package manager would be a task too big for
> a
> > single person to do.  It might be worth thinking about, as a long-term
> > goal.  Even if a programmer had an hour or so spare without real life,
> > updating the book every so often they could add the build scripts.
> >
>
> Thanks for the suggestion. I'll have a look at nix to include it in jhalfs.
>

Maybe GNU Guix is a better bet; it's built on Nix, but instead of having to
learn a language that can't be used anywhere else, Guix uses Guile, which
is much more useful.


>
> I do not think rebuilding all the dependencies of a package each time it is
> updated is necessary: some packages like qt5 have more than 250
> dependencies
> at the recommended level (and more than 400 at the optional level). It
> would
> not be reasonable to rebuild all of those. OTOH, it'd be nice to be able to
> build a package in an environment where only the listed dependencies are
> installed (well, sometimes added packages may break things, like for
> File::BaseDir, where the tests do not pass if xdg-user-dirs is installed
> and
> XDG_CONFIG_HOME is set). I understand nix is able to do that (insulate
> building from the system). Actually, I'm almost sure the apt/dpkg suite
> can do
> that too (there is a "chroot" mode for apt-build). Right now, I use porg:
> it
> is very basic, but at least, there is almost no language to learn.
> Building in
> insulation would involve setting the chroot manually... But I am not up to
> that yet.
>

+1 for porg.

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

Re: [blfs-dev] QA in BLFS

[Richard Melville]

On 4 March 2018 at 02:11, Bruce Dubbs  wrote:

>
> I have run into that with the package currency scripts.  About 65% of the
> packages can be automated quite easily, but the other third require a
> custom procedure for each package.  Look at just package names for
> instance.  Most are something like pkg-x.y.z.tar.?z*  Then look at
>
> acl-2.2.52.src.tar.gz (why do they need src?)
> expect5.45.4.tar.gz (why not expect-5.45.4?)
> python-3.6.4-docs-html.tar.bz2 (why not python-docs-html-3.6.4?)
> sysvinit-2.88dsf.tar.bz2 (why was dsf needed at all?)
> tcl8.6.8-src.tar.gz (tcl-src-8.6.8 would be better)
> tzdata2018c.tar.gz (tzdata-2018.3?)
> ConsoleKit2-1.0.2.tar.bz2 (why use caps?  why not consolekit-2.0.2?)
> krb5-1.16.tar.gz (krb-5.16?)
> openssh-7.6p1.tar.gz (what good does the p do?)
> volume_key-0.3.9.tar.xz (why an underscore?  I suppose it's better than a
> space)
>
> Bruce, I'm not trying to be deliberately obtuse here, and maybe you are
referring to the use of jhalfs, which I don't use, but otherwise I can't
see the problem.  Yes, those packages, and others, aren't consistent with
traditional versioning, but each one is consistent within itself; in other
words, the format doesn't change over an upgrade cycle.  Surely, once a
script is written for a particular package the only thing that changes on
an upgrade (other things being equal) are the digits.

Anyway, I'd like to echo Spikey's words and offer my congratulations and
thanks to you and the team for such hard, consistent work; it really is
much appreciated.

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

Re: [blfs-dev] Archive mod_dnssd? And others

[Richard Melville]

On 28 February 2018 at 12:25, Bruce Dubbs  wrote:

> Bruce Dubbs wrote:
>
>> The only reference to it that I can find is
>>
>> 1.  archive/gnome/gnome-user-share.xml:  
>
> Here are some more candidates for archiving:
>
> 2. general/prog/jinja2.xml
>
> The only place this is locates is in systemd python modules.  I see
> nothing that references it.
>
> I don't use jinja2 as I'm not a web developer, but I know many who do.
Here's a link:-

http://jinja.pocoo.org/docs/2.10/

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

Re: [blfs-dev] w3m and openssl

[Richard Melville]

On 20 February 2018 at 07:41, Pierre Labastie 
wrote:

>
> A more radical step away: archive w3m. Do we really need 3 text browsers in
> this book nowadays?
>
> I use w3m, but I use libressl instead of openssl.  This issue was flagged
back in 2014 by the freebsd community, and a patch was created to disable
the egd api in w3m.  Here's the link:-

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191956

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

Re: [blfs-dev] ppp support in BFLS networking

[Richard Melville]

On 25 January 2018 at 00:44, Bruce Dubbs  wrote:

> Tim Tassonis wrote:
>
>> Hi all
>>
>>
>> I just setup a VDSL router with LFS, adding ppp to it and then setting up
>> the interface in rc.firewall. Which of course is not really optimal...
>>
>>
>> As currenty, blfs seems to have no support of ppp network devices, I was
>> wondering wheter blfs could include
>>
>> - an instruction to build ppp
>> - a simple ppp service script
>>
>>
>> I used the standard ppp from samba org:
>>
>>
>> https://download.samba.org/pub/ppp/ppp-2.4.7.tar.gz
>>
>> As bringing up a ppp interface usually requires a configfile in
>> /etc/ppp/peers/ with some details, the service maybe should leave any
>> details away and just allow something like that:
>>
>>
>> ifconfig.ppp0:
>>
>> ONBOOT="yes"
>> IFACE="enp1s0"
>> PPP_IFACE="ppp0"
>> PEERNAME="dslprovider"
>> MANAGE_IFACE="yes"
>>
>>
>> The service script would then just call
>>
>> /usr/sbin/pppd call dslprovider
>>
>> and in case of MANAGE_IFACE="yes"
>>
>> bring up IFACE befoe, calling by
>>
>> /sbin/ip link set dev enp1s0 up
>>
>>
>> If there is any interest, I would provide a service script and compile
>> instructions for ppp.
>>
>
> I personally have no interest.  What do you use ppp to do?   AFAIK it is
> ancient technology.
>
> How prescient, I'm just working on a ppp script myself.  If Internet
access over 3G/4G is required then ppp is essential.

I've recently had issues with the broadband connection from my ISP.  In
security terms, an internet connection is essential for me as it enables me
to access my CCTV images whilst I'm away from home.  In response to this
recent failure I'm working on a script that samples the eth0 (broadband)
connection, and if it drops out then the system switches to a Huawei E3531
dongle with a giffgaff SIM installed. This gives me a failover solution
whilst the broadband connection is reinstated.

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

Re: [blfs-dev] Candidate for removal - guile

[Richard Melville]

On 6 December 2017 at 06:30, Jeremy Henty <onepo...@starurchin.org> wrote:

> Richard Melville wrote:
>
> > Guile is also important in relation to GnuCash and LilyPond.
>
> Keep  in mind  that LilyPond  still uses  guile-1, although  there are
> efforts to port it  to guile-2.2.  I believe that the  same is true of
> GNU TeXmacs (a mathematics typesetting program).
>
> Thanks, good points.  I wasn't aware of GNU TeXmacs; it looks interesting.

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

Re: [blfs-dev] Candidate for removal - guile

[Richard Melville]

On 3 December 2017 at 15:59, Bruce Dubbs <bruce.du...@gmail.com> wrote:

> Richard Melville wrote:
>
>> On 2 December 2017 at 21:53, Bruce Dubbs <bruce.du...@gmail.com
>> <mailto:bruce.du...@gmail.com>> wrote:
>>
>> I am proposing that we remove guile from BLFS.
>>
>> Packages where it is referenced: gdb, graphviz, gnutls.
>>
>> In graphviz, it is only used to create optional bindings.
>> In gdb it is optional and we say that it is currently broken.
>> In gnutls is is only mentioned as optional.
>>
>> It takes a long time to build: 9+ SBU.
>>
>> Removing this package and making the current links external for those
>> really interested will reduce the overall package maintenance a little
>> and every little bit helps.
>>
>> Are there any BLFS users who actually need guile?
>>
>> Yes, I do.  Guile is very important as an intrinsic part of the "GNU
>> Project".  There has been a great deal of work looking at replacing Scheme
>> with Guile in Emacs.  Guile is also important in relation to GnuCash and
>> LilyPond.
>>
>
> Thanks for the feedback.  We'll leave it in the book.
>
> That's much appreciated Bruce, thanks.  I forgot to mention GNU Guix, a
useful package manager which also relies on Guile.  I'm currently looking
to see if I can incorporate it into my BLFS builds.

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

Re: [blfs-dev] Candidate for removal - guile

[Richard Melville]

On 2 December 2017 at 21:53, Bruce Dubbs  wrote:

> I am proposing that we remove guile from BLFS.
>
> Packages where it is referenced: gdb, graphviz, gnutls.
>
> In graphviz, it is only used to create optional bindings.
> In gdb it is optional and we say that it is currently broken.
> In gnutls is is only mentioned as optional.
>
> It takes a long time to build: 9+ SBU.
>
> Removing this package and making the current links external for those
> really interested will reduce the overall package maintenance a little and
> every little bit helps.
>
> Are there any BLFS users who actually need guile?
>
> Yes, I do.  Guile is very important as an intrinsic part of the "GNU
Project".  There has been a great deal of work looking at replacing Scheme
with Guile in Emacs.  Guile is also important in relation to GnuCash and
LilyPond.

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

[blfs-dev] dbus optional dependencies

[Richard Melville]

Shouldn't libcap-ng and audit be added as optional dependencies to dbus to
enable audit support?

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

Re: [blfs-dev] LFS and BLFS Version 8.1 are released

[Richard Melville]

On 2 September 2017 at 01:11, Bruce Dubbs  wrote:

> The Linux From Scratch community is pleased to announce the release of LFS
> Version 8.1, LFS Version 8.1 (systemd), BLFS Version 8.1, and BLFS Version
> 8.1 (systemd).
>
> This release is a major update to both LFS and BLFS.
>
> The LFS release includes updates to glibc-2.26, binutils-2.29, and
> gcc-7.2.0. In total, 32 packages were updated, fixes made to bootscripts,
> and changes to text have been made throughout the book.
>
> The BLFS version includes approximately 900 packages beyond the base Linux
> From Scratch Version 8.1 book. This release has over 885 updates from the
> previous version including numerous text and formatting changes.
>
> Thanks for this release goes to many contributors.  Notably:
>
> DJ Lucas
> Pierre Labastie
> Ken Moffat
> Douglas Reno
>

I would like to thank Bruce and all the other devs for the continuation of
this excellent community-run resource; all your hard work is much
appreciated.

Thank you.

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

Re: [blfs-dev] rustc and llvm - thoughts

[Richard Melville]

On 28 July 2017 at 01:27, Ken Moffat  wrote:

> I was going to ask just the editors about this, but maybe people on
> this list can contribute other ideas.
>
> I've found information in links from this week's lwn.net about new
> releases for llvm and rust.  I continue to feel uncomfortable about
> using such old versions of rustc and cargo (everything else normally
> uses up to date releases), but they (particularly rust) are such a
> pain to build. Anyway -
>
> llvm-5.0 is scheduled for about August 23rd, I assume that will miss
> our 8.1 release.
>
> rustc merged support for the llvm-5 branch on 21st July, but is
> expected to continue to support llvm-3.9 for the foreseeable future.
> But like firefox itself, they have beta and nightly branches.
> AFAICS, rustc-1.19.0 was released on 20th July, which if I'm reading
> correctly means that llvm-5.0 support is only in current nightly,
> and will be in the 1.21 release around the 11th or 12th October.
>
> For 8.1 we could probably move to a single llvm (4.0.1 - not
> tested), but it looks as if we would need to move that version to
> old-llvm (only for rustc) as soon as we moved -dev to llvm-5.0.
> And of course using only one llvm means augmenting the build with
> the -DLLVM_INSTALL_UTILS=ON switch (makes little difference to the
> build time or space) - but building llvm-3.9.1 only for use by rustc
> is much quicker than building llvm-4.0.0.
>
> I find this whole thing a pain, so I'm minded to continue to use an
> old llvm (3.9.1) for as long as possible.
>
> Or we could forget our preference for system libs (which is
> increasingly broken both by firefox and by anything based on
> chromium) and use the static version of llvm shipped in the rustc
> tarball - with the increased time and space that involves. But then
> the overhead for a regular user (re)building rustc is much worse.
>
> The real problem is the time this all takes on anything less than a
> state of the art machine.
>

Regarding the build times, I think that there might be a dissonance between
those working on developing a new edition of the book, and those who are
just building a BLFS system for their own use.  Clearly, the former need to
try a number of different builds in order to produce a stable book edition,
so speed is of the essence.  However, the latter (at least from my own
experience) are happy to run a time-consuming build overnight.

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

Re: [blfs-dev] AX_REQUIRE_DEFINED : which package provides this ?

[Richard Melville]

On 24 July 2017 at 03:08, Ken Moffat  wrote:

> My attempt to build all the recommended deps for evince has failed -
> after building the usual shed-load of gnome packages I normally only
> build to test hte book, I eventually got to nautilus-3.24.1 and
> configure blew up:
>
> checking whether to use NLS... yes
> checking where the gettext function comes from... libc
> checking pkg-config is at least version 0.16... yes
> ./configure: line 15879: syntax error near unexpected token `GTK_DOC_CHECK'
> ./configure: line 15879: `AX_REQUIRE_DEFINED(GTK_DOC_CHECK)'
>
> And indeed 15879 only says:
>
> AX_REQUIRE_DEFINED(GTK_DOC_CHECK)
>
> From
> https://www.gnu.org/software/autoconf-archive/ax_require_defined.html
> I can see that it is an m4 macro.  Most of my packages in this build
> are old (late May), so maybe upgrading to a later version of
> something will fix it : but which package should be providing it ?
>

Maybe this is of some help:-

https://wiki.gnome.org/Projects/GnomeCommon/Migration

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

Re: [blfs-dev] systemd and qemu experiences

[Richard Melville]

On 18 June 2017 at 03:35, Bruce Dubbs  wrote:

> Warning:  This is quite long.  If replying, please trim the response to
> just the relevant portion.
>
> Another issue is that package configuration needed to be done as the
> packages are built to get a working system.  I do not have any ideas about
> how to automate that.  It's a very difficult issue.
>

I meant to say that I was considering this issue last week.  My plan is to
create individual configuration scripts for each package that needs
configuring, and then break from the build and run the configuration
script, before returning to the build sequence.  Let me say straight up
though that I don't use jhalfs so I don't know how it would fit in with
running that.  Maybe it wouldn't work anyway; I don't know as I haven't had
time to give it much thought.  The other thought that I had is to finish
the build and then run all the configuration scripts sequentially.

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

Re: [blfs-dev] systemd and qemu experiences

[Richard Melville]

On 18 June 2017 at 03:35, Bruce Dubbs  wrote:

> Warning:  This is quite long.  If replying, please trim the response to
> just the relevant portion.
>
> Starting out, there are several packages needed to really get things
> going.  In my case openssh, wget, nfs (libtirpc/nfs-utils/rpcbind), and
> sudo.  Using the order generated by jhalfs indicates to me some problems we
> have in the blfs book.  Most of these are issues with dependencies. For
> instance with gptfdisk, popt should be recommended.
>

I reported a dependency issue in v4l-utils a couple of days ago; it read
thus:-

"None of the dependencies shown in the book as "Required" is, in fact, a
build dependency.  They should all be listed as "Recommended" or "Optional".

Mesa and GLU are only needed if building against X windows.  Libjpeg-turbo
is a compile-time option.

I've just built v4l-utils with libjpeg-turbo installed (because I wanted
that support), but I don't have Mesa or GLU installed as I'm not building
for X windows.  v4l-utils built just fine with no issues."

I'll bet that there are a number of packages in the book that have
misleading dependencies listed.


> Back to jhalfs.
>
> As I was going through the list of packages, I was unsure of the versions
> I had vs what was in the book.  In the script names, is would be helpful if
> the package version was also listed.  for instance:
>
> 120-z-cmakevs
> 120-z-cmake-3.8.2
>

I had the same issue in my build and came up with a similar solution.  I
think it's a good idea.

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

Re: [blfs-dev] Odd failure in heirloom-mailx

[Richard Melville]

On 10 April 2017 at 16:27, Ken Moffat <zarniwh...@ntlworld.com> wrote:

> On Mon, Apr 10, 2017 at 03:44:12PM +0100, Richard Melville wrote:
> > On 9 April 2017 at 22:45, Bruce Dubbs <bruce.du...@gmail.com> wrote:
> >
> > Ken, I'm tagging on to the end of this post, not because I have an answer
> > to your issue, but because, coincidently, I'm looking at mailx at the
> > moment and I can see that you are the owner of the patch.
> >
>
> For the moment, I don't have a problem (it built in the end) so I'm
> not actively looking for an answer.
>
> And I'm not sure that I own the patch - I took the fixes from debian
> and redhat.
>
> > I've found another issue which, maybe, could be added to your patch.
> Mailx
> > is supposed to look for NSS first before falling back to OpenSSL.  I have
> > NSS installed and it didn't find it.  On examining the config.log I can
> see
> > that it's looking in /usr/include/ssl.h when the NSS header is actually
> at
> > /usr/include/nss/ssl.h.  In the book we create the /usr/include/nss
> > directory but this clearly breaks the mailx build.
> >
> > Richard
>
> It sounds like you are in a position the fix the patch and test it!
>

I appreciate your faith in me Ken, but I think it might be misplaced.
Anyway, the wierdness continues.  Despite the mailx documentation claiming
that it can be built with nss support by adding both nspr and nss header
directories to the make file it steadfastly refuses to accept both; it only
reads the second one in my script.  I've tried reversing them but it's
always only the second entry that gets read.

I finally got it to build with a horrible hack: changing the paths of six
nss header files in four different mailx files.  Whether it runs or not
remains to be seen; I'm still in chroot.  If you, or anybody else, have any
better ideas they would be very welcome.

I've contacted the mailx developer to see if I can get an answer.

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

Re: [blfs-dev] Odd failure in heirloom-mailx

[Richard Melville]

On 9 April 2017 at 22:45, Bruce Dubbs  wrote:

> Ken Moffat wrote:
>
>> Mailx is one of those packages I always build before booting a new
>> system, so that fcron can send mail to my server.  The current build
>> is using exactly the same scripts / versions as I used on another
>> machine about 4 days ago (I need a fresh, clean, system to review
>> what I'm planning re llvm-3 for rust).
>>
>> To my surprise, mailx failed:
>>
>> cc -O2 -fuse-ld=gold -g  -DMAILRC='"/etc/nail.rc"'
>> -DMAILSPOOL='"/var/mail"' -DSENDMAIL='"/usr/sbin/sendmail"'-c
>> fio.c
>> fio.c:48:2: error: #error wordexp support is required
>>   #error wordexp support is required
>>^
>> fio.c:59:17: fatal error: ssl.h: No such file or directory
>>   #include 
>>   ^
>>
>> Looking at the log, and comparing it to past builds, it correctly
>> noticed that I don't have NSS, but then it told me
>>
>> The following optional features are enabled:
>>   + Locale support: Printable characters depend on the environment
>>   + Multibyte character support
>>   + Character set conversion using iconv()
>>   + Automatic detection of terminal character set
>>   + Networking support (IMAP, POP3, and SMTP)
>>   + S/MIME and SSL/TLS using Network Security Services (NSS)
>> 
>>   + S/MIME and SSL/TLS using OpenSSL
>>
>> That was new on this failed build, and AFAICS from fio.c it either
>> uses nss OR openssl.  Not sure about the not defined HAVE_WORDEXP
>> that caused the first error.
>>
>> Anyway, in chroot I eventually tried manually (re) running 'sh
>> ./makeconfig' and this time got the expected result.  I've now added
>> that to my script and successfully built it from the script.
>>
>> At first I had thought this might be a problem with parallel make,
>> but I don't do that for this package.
>>
>
> It's hard for me to say since openssl is always the 2nd or 3rd package
> that I build in a new system, but looking at the mailx source, it is
> looking for wordexp.h and that is installed by glibc.  Alternatively, mailx
> is doing a trivial gcc build and including that file and perhaps gcc
> failed.  That does not seem likely.


Ken, I'm tagging on to the end of this post, not because I have an answer
to your issue, but because, coincidently, I'm looking at mailx at the
moment and I can see that you are the owner of the patch.

I've found another issue which, maybe, could be added to your patch.  Mailx
is supposed to look for NSS first before falling back to OpenSSL.  I have
NSS installed and it didn't find it.  On examining the config.log I can see
that it's looking in /usr/include/ssl.h when the NSS header is actually at
/usr/include/nss/ssl.h.  In the book we create the /usr/include/nss
directory but this clearly breaks the mailx build.

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

Re: [blfs-dev] wireless tools

[Richard Melville]

On 15 March 2017 at 18:06, Bruce Dubbs  wrote:

> We are looking at a new package, https://www.kernel.org/pub/sof
> tware/network/iw/iw-4.9.tar.xz.  This only produces a single executable:
> iw.  It does not produce a library.
>
> It does provides functionality similar to wireless tools.
>
> pm-utils will continue to need wireless-tools.
> wicd needs wireless-tools
> lxpanel needs iwlib.so that is only in wireless-tools
>
>
> We have references in the mozilla apps:
>
> # If you have installed wireless-tools comment out this line:
> ac_add_options --disable-necko-wifi
>
> I've looked at thunderbird and can't find where any of the wireless-tools
> commands or library are used.  I suspect the same for seamonkey and firefox.
>
> Should we add iw to the book?
>
> The instructions for BLFS are fairly simple:
>
> sed -i "/INSTALL.*gz/s/.gz//" Makefile
> make
> make check
> make SBINDIR=/sbin install
>
> The only files installed are iw and iw.8.
>
>
This link gives a good overview of iw and its dependencies:-

https://wireless.wiki.kernel.org/en/users/documentation/iw

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