Re: [blfs-dev] ImageMagick-7.0.6-10 md5sum is not correct

[akhiezer]

> From: Bruce Dubbs <bruce.du...@gmail.com>
> Date: Tue, 29 Aug 2017 12:32:38 -0500
>
> akhiezer wrote:
>
> > The matter is clearly, obviously, not about how long a single error
> > persists.
> >
> >
> > It is about how long folks remain addicted to donkey-tasks; the
> > inevitable stream, cycle, of repeated types of errors that ensue; and
> > the inevitable stream, cycle, of repeated types of donkey-tasks that
> > ensue of correcting said inevitable errors.
>
> We are waiting for you to fork blfs with a 'better way'.
>
>-- Bruce
>


If a person long-term demonstrates repeatedly that they won't, or can't,
implement properly even the handling of checksum calculations -
whether doing in-house or availing themselves of any of those already
widely implemented and readily available;
then how likely are they to be able &/or willing to avail themselves
satisfactorily of any new such placed in front of them.


It is therefore not enough in such a case, for the person to attempt
to deflect attention from the matter by asininely/ trying
to get others to implement yet another instance,
while the person's past and current behaviours, attitudes, indicate that
the person is too-likely to continue as-ever.


Instead, the person has to at least exhibit some intent,
willingness, some good-faith, that such new materials
will not be wasted on them.


It is advisable and appropriate in such a case that
an approach of 'lead to water', 'teach to fish', be used.


To that end, a reasonable suggested starting sequence
of infos, tasks, for such a person, is:
---
* implement auto-calc of checksum.
  Then add cross-checking.

* then implement auto-writing-out of the info to a file.
  Then add cross-checking.

* then implement auto-writing-out to the required place in
  the required xml/ file(s).
  Then add cross-checking.

* then implement auto-sync/commit - with cross-checking - with svn/
---
Keep a note of any issues encountered; and of any ideas
(look it up, if nec) for how the process might be improved further.


If that goes all-ok, then progress to auto-handling of date/time info;
ref above seq of steps.


Any problems, let the lists know.


It is stated perennially that a central goal, pillar, of b/lfs is education;
is the person per the above, willing &/or able to allow themselves to learn.


Folks, I know that you may be hurting to be queried: if
you at core know and understand the matter -
the issues and resolutions - and will improve,
then that's the main thing,
and relegates the protestations-too-much to where they belong.



akh





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

Re: [blfs-dev] ImageMagick-7.0.6-10 md5sum is not correct

[akhiezer]

> Date: Tue, 29 Aug 2017 19:26:32 +0100
> From: Ken Moffat <zarniwh...@ntlworld.com>
>
> On Tue, Aug 29, 2017 at 06:19:42PM +0100, akhiezer wrote:
> > > Date: Tue, 29 Aug 2017 17:44:13 +0100
> > > From: Ken Moffat <zarniwh...@ntlworld.com>
> > >
> > >
> > > I look forward to your fork where you show us how to automate this.
> > > Bonus points for using no more than 4 cores on machines with more
> > > cores (for things using rust and ninja).  More bonus points for not
> > > requiring user input to specify which files to read for
> > > measurements.
> > >
> > 
> > 
> > Here's a clue: break the problem down: start with (for you) low-hanging
> > fruit: how about you start with checksums; and then maybe progress to
> > dates; see if you can manage that first.
> > 
> > 
> > Then you might start to get some vision - taste, abilities, even -
> > for the parts that currently seem to be over-the-horizon difficult for
> > you. But do keep breaking the problem down into manageable pieces.
> > 
>
> Thanks for your expressed lack of confidence in my taste and vision.
> Your comment on my lack of ability is, of course, well-founded - but
> since the project lacks skilled and able contributors, I try to
> contribute what I can.
>
> As far as I am concerned, I _use_ parts of BLFS, so I try to ensure
> they are up to date.  Anything more is a distraction - sometimes the
> distractions are interesting, other times not.
>
> So no, taking time out to figure out how to automate finding the
> md5sums in the book, as a first step towards comparing them, is not
> attractive.
>
> We work with what we have.  If we started today, I very much doubt
> that the book would be structured as it is - a new structure *might*
> support some of your proposed automation, it might not.  So, it is
> up to you to fork at least a proof of concept.  However, I suspect
> that I at least will not share your taste.
>
> Either you really are keen to contribute, or it's just another excuse
> to be passive-aggressive.  I'll be charitable, so "Enjoy forking, and
> let us know when you have a proof of concept."
>


Might such lazy facile attempted 'pssv/aggrsv' labelling be,
rather, applied to your reactions at your poor practices
being at least queried.


Wrong instructions and other wrong infos are being put
into the book - the central repo - that have not even been
tested and verified-ok; letting others hit the problems.


And you try to nay-say when queried about your practices
and urged to change and not just keep repeating the cycle.
Who do you think you are. The issues are not so much just
about abilities per se; it's also attitude.


A person's own repo should be in order before
pushing to central.


Your talk-to-the-hand final position statement is
interestingly attemptedly high-handed.

Demonstrate ability to learn and improve, such that
you might learn from such materials.

To get you started on the first steps towards improvement,
ref the initial getting-you-started checklists in the note
to your similarly-postured colleague.


Folks, I know that you may be hurting to be queried: if
you at core know and understand the matter -
the issues and resolutions - and will improve,
then that's the main thing,
and relegates the protestations-too-much to where they belong.



akh





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

Re: [blfs-dev] ImageMagick-7.0.6-10 md5sum is not correct

[akhiezer]

> From: Bruce Dubbs <bruce.du...@gmail.com>
> Date: Tue, 29 Aug 2017 10:48:07 -0500
>
> akhiezer wrote:
> >> From: Wayne Blaszczyk <wblas...@bigpond.net.au>
> >> Date: Tue, 29 Aug 2017 19:16:41 +1000
> >>
> >> Again, it seemed not to change from the previous version.
> >>
> >
> >
> > The central issue is that much of that 'header' info
> > (dates/checksums/sizes/build-times/...) get input manually, instead of
> > done automatically. That the former persists for so long is technically
> > and administratively incompetent; and it's further worsened that it
> > gets clung onto.
>
> For 'so long' is less than 24 hours.  I check new commits every morning on 
> the day after the commit.
>
> Note that there are sometimes problems with stealth updates and 
> differences between mirrors.
>


As often, you (willfully?, cos "nobody's _that_ stupid, surely") happily,
brightly, address a different point.


The matter is clearly, obviously, not about how long a single error
persists.


It is about how long folks remain addicted to donkey-tasks; the
inevitable stream, cycle, of repeated types of errors that ensue; and
the inevitable stream, cycle, of repeated types of donkey-tasks that
ensue of correcting said inevitable errors.



akh





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

Re: [blfs-dev] ImageMagick-7.0.6-10 md5sum is not correct

[akhiezer]

> From: Wayne Blaszczyk 
> Date: Tue, 29 Aug 2017 19:16:41 +1000
>
> Again, it seemed not to change from the previous version.
>


The central issue is that much of that 'header' info
(dates/checksums/sizes/build-times/...) get input manually, instead of
done automatically. That the former persists for so long is technically
and administratively incompetent; and it's further worsened that it
gets clung onto.



akh





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

Re: [blfs-dev] Text quibble for xorg intel driver

[akhiezer]

> Date: Sun, 27 Aug 2017 23:57:43 +0100
> From: Ken Moffat <zarniwh...@ntlworld.com>
>
> On Sun, Aug 27, 2017 at 10:56:00PM +0100, akhiezer wrote:
> > > Date: Sun, 27 Aug 2017 01:07:26 +0100
> > > From: Ken Moffat <zarniwh...@ntlworld.com>
> > >
[...]
> > >
> > > So, the current text for HD graphics processors is less than
> > > complete, whilst the separate video cards are (probably) antiquated
> > > and now uncommon - or tell me if I'm wrong about that!
> > >


There's some i8xx, 8x5G, 9x5G, and Atom D5xx machines still alive here -
some for testing, some still in production; several use X-win. Although
their os/sw builds are not by-the-book b/lfs, b/lfs is a reference.


> > 
> > 
> > (Not sure what list is being referred to there.)
> The part I originally quoted at the start of the thread (Sandy and
> Ivy Bridges and Haswell).
> > 
> > 
> > > Does anyone have a better, and ideally concise, way of specifying
> > > which CPUs/GPUs are covered ?  And does this driver work for Atom
> > > CPUs, if any of our users have the misfortune to build on those ?
> > >
[...]
>


akh





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

Re: [blfs-dev] Text quibble for xorg intel driver

[akhiezer]

> Date: Mon, 28 Aug 2017 08:58:11 +0100
> From: lf...@cruziero.com (akhiezer)
>
> > Date: Sun, 27 Aug 2017 23:57:43 +0100
> > From: Ken Moffat <zarniwh...@ntlworld.com>
> >
[...]
>
> tarball-unpack, then:
>
> man ./xf86-video-intel-20170826/man/intel.man


$ man ./xf86-video-intel-20170826/man/intel.man | col -b | fmt -sw80 | less
[...]
SUPPORTED HARDWARE
   intel supports the i810, i810-DC100, i810e, i815, i830M,  845G,  852GM,
   855GM,  865G,  915G,  915GM,  945G,  945GM,  965G,  965Q, 946GZ, 965GM,
   945GME, G33,  Q33,  Q35,  G35,  GM45,  G45,  Q45,  G43,  G41  chipsets,
   Pineview-M  in  Atom  N400 series, Pineview-D in Atom D400/D500 series,
   Intel(R) HD Graphics, Intel(R) Iris(TM) Graphics, Intel(R) Iris(TM) Pro
   Graphics.
[...]
$


And in the usual way, there's a slightly different list in the tarball
readme - and likely intel ark, or the 'https://01.org/linuxgraphics/'
per below, would each be different again. : NB the 'including'
immed before the list:


ref: tarball-unpack: ./xf86-video-intel-20170826/README
==
xf86-video-intel
Open-source X.org graphics driver for Intel graphics
https://01.org/linuxgraphics/

What is xf86-video-intel

The xf86-video-intel module is an open-source 2D graphics driver for
the X Window System as implemented by X.org. It supports a variety of
Intel graphics chipsets including:

i810/i810e/i810-dc100,i815,
i830M,845G,852GM,855GM,865G,
915G/GM,945G/GM/GME,946GZ
G/GM/GME/Q965,
G/Q33,G/Q35,G41,G/Q43,G/GM/Q45
PineView-M (Atom N400 series)
PineView-D (Atom D400/D500 series)
Intel(R) HD Graphics,
Intel(R) Iris(TM) Graphics,
Intel(R) Iris(TM) Pro Graphics.

Where to get more information about the driver
--
The primary source of information about this and other open-source
drivers for Intel graphics is:

https://01.org/linuxgraphics/

Documentation specific to the xf86-video-intel driver including
possible configuration options for the xorg.conf file can be found in
the intel(4) manual page. After installing the driver this
documentation can be read with the following command:

man intel

Mailing list for communication with users and developers of
xf86-video-intel:

intel-...@lists.freedesktop.org

[...]




akh





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

Re: [blfs-dev] Text quibble for xorg intel driver

[akhiezer]

> Date: Sun, 27 Aug 2017 23:57:43 +0100
> From: Ken Moffat 
>
[...]
> > 'Intel integrated graphics chipsets' ; ref e.g. 'man 4 intel' .
>
> Thanks.  The problem with referring readers to that page is that the
> text for the driver should help people to decide which drivers they
> should install.  But that manpage is installed by the driver, so you
> can't read read it until you have installed the driver.


The refs to manpage are for suggested source for lifting text for
putting onto the blfs page: hopefully generally obviously, it wasn't
being intended to suggest that instead the blfs page only refers readers
to the manpage.


> > 
[...]
> > Atoms:
> > 'man 4 intel' usually notes which (strict) subset of Atoms are supported.
> > 
> > 
> Thanks.  Now that I'm on an intel I'll take a look at that re Atoms
> at some point.
>
> Possibly the manpage can be found online - on this box I don't have


wbsrch 'man 4 intel' will find it no-problem.


> a useful browser yet (still checking my rustc build) - I'll try to


tarball-unpack, then:

man ./xf86-video-intel-20170826/man/intel.man

(Yes, it's a part-template page; but the reqd info is there.)


(Just to be clear, it is not 'being intended to suggest that' this be
put in the blfs book page - and certainly not as the only pointer for
readers  ;)  . )


> remember to look later (maybe a day or two before I get there, this
[...]
>



akh





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

Re: [blfs-dev] Text quibble for xorg intel driver

[akhiezer]

> Date: Sun, 27 Aug 2017 01:07:26 +0100
> From: Ken Moffat 
>
> I'm reading the detail of pages in the book more than I normally do
> between releases, and in the Xorg Intel Driver we say:
>
> "The Xorg Intel Driver package contains the X.Org Video Driver for
> Intel integrated video cards including 8xx, 9xx, Gxx, Qxx and HD


'Intel integrated graphics chipsets' ; ref e.g. 'man 4 intel' .


> graphics processors (SandyBridge, IvyBridge and Haswell)."
>
> My quibble is with the list of HD graphics processors - Broadwell,
> Skylake and Kaby Lake all belong in that list, and I guess that the
> latest git driver will support them.  But if we just add those, then
> we'll have to keep extending the list in future versions of the book
> (Coffee Lake, and if wikipedia is to be believed Cannonlake, and
> later some currently undreamed-of names).


Usually 'x thru y' or 'x thru present' or 'from x onwards' ; where x
here would be SandyBridge / Sandy Bridge .


>
> So, the current text for HD graphics processors is less than
> complete, whilst the separate video cards are (probably) antiquated
> and now uncommon - or tell me if I'm wrong about that!
>


(Not sure what list is being referred to there.)


> Does anyone have a better, and ideally concise, way of specifying
> which CPUs/GPUs are covered ?  And does this driver work for Atom
> CPUs, if any of our users have the misfortune to build on those ?
>


Atoms:
'man 4 intel' usually notes which (strict) subset of Atoms are supported.



akh





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

Re: [blfs-dev] Cannot bootstrap current rust

[akhiezer]

> Date: Tue, 15 Aug 2017 05:24:22 +0100
> From: Ken Moffat 
>
> I took a look at firefox-56.0beta a few days ago, and it needs a
> newer rustc.  Only need one version newer, but I thought I'd try the
> current rust-1.19.0 for future-proofing, particularly since Arch
> apparently build it with cargo included (but they don't bootstrap
> it, so I assume they are using the immediately previous rust, and
> probably current cargo).
>
> FWIW, trying to build a newer rust looks to be as painful as trying
> to build it the first time.  At this rate I'll probably give up
> trying to build firefox from source, and when librsvg needs rust
> I'll probably give up the whole game.
>
> FWIW, I can't get past this early error:
>
> extracting
> /tmp/rust-1.19.0/build/cache/2017-06-08/cargo-0.19.0-x86_64-unknown-linux-gnu.tar.gz
> error: failed to read
> `/tmp/rust-1.19.0/src/tools/rust-installer/Cargo.toml`
>
> Caused by:
>   No such file or directory (os error 2)
> failed to run:
> /tmp/rust-1.19.0/build/x86_64-unknown-linux-gnu/stage0/bin/cargo
> build --manifest-path /tmp/rust-1.19.0/src/bootstrap/Cargo.toml
> Build completed unsuccessfully in 0:00:19
> make: *** [Makefile:24: all] Error 1
>
> which sounds suspiciously like
> https://github.com/rust-lang/rust/issues/40284 - but that was fixed
> in March, so I assume 1.19.0 ought to be ok.


It's maybe worth double-checking that it _is_ changed in what you
are using - incl e.g. the diff that changes 'src/tools/cargo' to just
'cargo'  .


>
> There is  a Cargo.toml, but if I symlink to that it blows up:
>
> error: multiple workspace roots found in the same workspace:
>   /tmp/rust-1.19.0/src/tools/cargo
>   /tmp/rust-1.19.0/src
>
> Similarly, with fresh source, removing src/tools/cargo doesn't
> prevent that error.
>
> At the moment I'm not inclined to look at bootstrapping this pile of
> #$*£ any more.  My first attempts got similar errors when (old)
> rustc and cargo were available.
>
> If it's worth anything, I'm using rust-installer-master.zip from
> github (maybe only needed if trying to install both rust and cargo
> in one go, dunno) and the following src/bootstrap/config.toml:
>  - - -
> [build]
> # If you specify paths to rustc and cargo here, they get used
> # but that is no use for bootstraping it in BLFS
>
> # install Rust and Cargo together - it's disabled by default
> #extended = true


Should that be un-commented - ie:

extended = true

?


> # Verbosity level: 0 == not verbose, 1 == verbose, 2 == very verbose
> verbose = 2 # until I get it to build
>
> [install]
> prefix = "/usr"
>
> [rust]
> channel = "stable"
>
> [target.x86_64-unknown-linux-gnu] # similar for i686, I suppose
> llvm-config = "/opt/llvm3/bin/llvm-config"
>  - - -
>



akh





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

Re: [blfs-dev] mariadb-10.2.6 my.cnf file

[akhiezer]

> From: John Burrell 
> Date: Sat, 1 Jul 2017 08:33:57 +
>
> The line:
>
> "innodb_additional_mem_pool_size = 2M"
>
> in the /etc/my.cnf file causes this message:
>
> "[ERROR] /usr/sbin/mysqld: unknown variable 
> 'innodb_additional_mem_pool_size=2M'"
>
> when running this command from the book:
>
> "mysql_install_db --basedir=/usr --datadir=/srv/mysql --user=mysql"
>
> Commenting out this line in the my.cnf file fixes the problem.
>


https://mariadb.com/kb/en/mariadb/xtradbinnodb-server-system-variables/#innodb_additional_mem_pool_size
==
"Deprecated in MariaDB 10.0 and removed in MariaDB 10.2 along with
InnoDB's internal memory allocator."
==



akh





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

Re: [blfs-dev] Book additions due to udisks2

[akhiezer]

> From: Bruce Dubbs <bruce.du...@gmail.com>
> Date: Wed, 21 Jun 2017 18:55:42 -0500
>
> akhiezer wrote:
> >> From: Bruce Dubbs <bruce.du...@gmail.com>
> >> Date: Wed, 21 Jun 2017 17:04:06 -0500
> >>
> >> udisks[...]
> >
> >
> > ( - SPOS. )
>
> I don't know what that means.
>


  "> helpful.  It sorta assumes I don't know how to search."


> >> http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cryptsetup.html
> > [...]
> >>
> >> The configuration/use of cryptsetup definitely needs some text about
> >> setting up encrypted partitions.  Any suggests about that will be 
> >> appreciated.
> >
> >
> > http://slackware.osuosl.org/slackware64-14.2/README_CRYPT.TXT
> >   - esp. the 'Combining LUKS and LVM' section.
> >
> >
> > Aux ref:
> > ---
> > * http://slackware.osuosl.org/slackware64-14.2/README.initrd
> > * http://slackware.osuosl.org/slackware64-14.2/README_LVM.TXT
> > * http://slackware.osuosl.org/slackware64-14.2/README_RAID.TXT
> > ---
>
> Yes, I found several places that explain cryptsetup.  What I was asking is 
> what words should *LFS* use.  Just providing some links is not really very 
> helpful.  It sorta assumes I don't know how to search.
>


Base the lfs text, drawing on that main ref, with attrib o/c: that's
the suggestion; hence the link, & aux links.



akh





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

Re: [blfs-dev] Book additions due to udisks2

[akhiezer]

> From: Bruce Dubbs 
> Date: Wed, 21 Jun 2017 17:04:06 -0500
>
> udisks[...]


( - SPOS. )


> http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cryptsetup.html
[...]
>
> The configuration/use of cryptsetup definitely needs some text about 
> setting up encrypted partitions.  Any suggests about that will be appreciated.


http://slackware.osuosl.org/slackware64-14.2/README_CRYPT.TXT
 - esp. the 'Combining LUKS and LVM' section.


Aux ref:
---
* http://slackware.osuosl.org/slackware64-14.2/README.initrd
* http://slackware.osuosl.org/slackware64-14.2/README_LVM.TXT
* http://slackware.osuosl.org/slackware64-14.2/README_RAID.TXT
---



hth,

akh





--
-- 
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-dev] Misspellings

[akhiezer]

> From: Bruce Dubbs 
> Date: Sun, 14 May 2017 01:15:12 -0500
>
> Bruce Dubbs wrote:
> > William Harrington wrote:
> >> https://pypi.python.org/pypi/misspellings
> >>
> >> I've used this a lot with our CLFS book. It may help with the LFS book.
> >
> > Thanks,  Tried it and it seems to work well.
>
> I just fixed all the identified misspellings in both LFS and BLFS. 
> Actually I was surprised how few there were considering the size of the 
> books.  Several were in xml comments that will never be seen by users and 
> several more in archived files.  Lots in the stylesheets but I'm going to 
> ignore those as most are not really ours are are invalid.
>
> Editors:  Install this package with:
>
>sudo python setup.py install
>
> Use as (from the base of LFS or BLFS BOOK/ diretory:


((
  diretory
 ->
  directory
))


>
>find . -name \*.xml | misspellings -f -|grep -v style


It's likely preferred to, automatically:
--
* skip .svn dirs.
* skip stylesheets dirs.
* proc txt but not binary.
* proc ~all-else, under resp b/lfs 'trunk' dirs.
--


Across b/lfs, filename extensions, or names of files w/o extensions, are:
==
[...]
  8 README
  8 ent
 12 sh
 13 txt
 15 conf
 18 png
 29 php
 42 md5
 48 service
 49 wget
   1547 xml
==
This, plus some grep/inspection, indicates omitting .png & maybe also
.md5 .


Have also, as ref, got:

$ ls -aCF ./{,b}lfs/curr/trunk/
./blfs/curr/trunk/:
./  ../  .svn/  BOOK/  auxfiles/  bootscripts/  edguide/  scripts/  
systemd-units/

./lfs/curr/trunk/:
./  ../  .svn/  BOOK/  OLD_BRANCHES_AND_TAGS  editor-manual/
$



So, overall, may want the find() to be, at core, for each of b/lfs dirtrees:

 find -P ./trunk \
  \( \( -name .svn -o -name stylesheets \) -prune \) \
  -o \
  \( -type f ! -name '*.png' -print \) 
=


Although that may seem to cast the net unnecessarily wide, it's really
the spellchecker opts/dicts/rules that you'd want to narrow things
down further. (And o/c the system can 'learn').


As this is o/c a repeat-process, so it's useful that there is used the
~usual type of setup/structure:

* a report/summary and ready-made patch, are generated automatically,
  periodically via cron/, at master repo side;

* there is an "apply-or-don't-apply" flag that is aut set to
  default="don't-apply";

* the/any patch gets aut-sent-to/reviewed/adj-if-nec, by a human;

* the flag is if nec adj to 'apply', or left at default "don't-apply";

* and a later cron-job does the apply-or-not, acc to flag status;

* cron-jobs' outputs get mailed as nec to persons/lists.




akh





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

[blfs-dev] typos: 'docummentation' .

[akhiezer]

trunk/BOOK/general/genlib/libassuan.xml
  Optional, to fix the docummentation build:

trunk/BOOK/archive/webkitgtk2.xml
  docummentation also applies here:

trunk/BOOK/pst/scanning/xsane.xml
   (for the help docummentation at runtime)


(Yes, the webkit... is arkv now).


akh



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

[blfs-dev] typo: 'documention' .

[akhiezer]

trunk/BOOK/general/graphlib/jasper.xml
   (needed to regnerate the pdf documention)

trunk/BOOK/multimedia/videoutils/ffmpeg.xml
  --disable-doc: Disables building html documention.




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

[blfs-dev] typo: gnumeric: ot to

[akhiezer]

trunk/BOOK/xsoft/office/gnumeric.xml
'The valgrind tests are known ot fail.'


(These 'typo' msgs are by-products of some testing of aspell to
spellcheck b/lfs src (xml) trees; incl aut reporting/)



akh





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

[blfs-dev] typo: developper*

[akhiezer]

trunk/BOOK/lxqt/desktop/post-install.xml:
 'developpers) or another Display Manager,'

trunk/BOOK/postlfs/security/sudo.xml:
 'See the developper note above before the configure command'



akh





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

[blfs-dev] typo: epiphany-extensions: 'debuging' .

[akhiezer]

BOOK/archive/gnome/epiphany-extensions.xml
'is an extension for debuging the Soup session'


akh




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

[blfs-dev] small typo: llvm: 'to an binary' .

[akhiezer]

trunk/BOOK/general/prog/llvm.xml
'to an binary file'


akh



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

Re: [blfs-dev] aspell-0.60.6.1 fails to compile

[akhiezer]

> From: John Burrell 
> Date: Thu, 11 May 2017 21:50:36 +
>
>
> John Burrell wrote:
> > I've installed the dev version of LFS and now compiling aspell-0.60.6.1 
> > fails.
> >
> >
> > The bug has been reported on debian here -
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853320
> >
> > I haven't found a solution yet.
>
> Yes, I ran into exactly that error.
>
>
>   g++ -DHAVE_CONFIG_H -I. -I./gen -I./gen -I./common -I./interfaces/cc/
> -I./modules/speller/default/ -DLOCALEDIR=/usr/share/locale -Wdate-time
> -D_FORTIFY_SOURCE=2 -g -O2 "-fdebug-prefix-map=/<>=."
> -fstack-protector-strong -Wformat -Werror=format-security -fno-exceptions
> -c modules/filter/tex.cpp  -fPIC -DPIC -o modules/filter/.libs/tex.o
> modules/filter/tex.cpp: In member function 'bool
> {anonymous}::TexFilter::process_char(acommon::FilterChar::Chr)':
>
> modules/filter/tex.cpp:177:72: error: ISO C++ forbids comparison between
> pointer and integer [-fpermissive]
> if (top.in_what == Parm || top.in_what == Opt || top.do_check == '\0')
>
> The '\0' is an old way to check for a null string.  It probably can be
> fixed with
>
> strlen(top.do_check) == 0
>
> or possibly
>
> top.do_check == (char*)'\0'
>
>
> I was able to get the package to build but it needed fixes to
> modules/filter/tex.cpp and prog/check_funs.cpp for basically the same
> problem in both files.
>
> I did not check the function of the built package.
>
>-- Bruce
>
> Yes that works. Thanks for that.


_What_ are you saying 'works': the strlen() approach, or the char*
approach, or both?


Also, could you possibly set your mailer to indent-quote (e.g. with
'> ') your replies.



akh





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

Re: [blfs-dev] Use HTTPS URL for HarfBuzz archive

[akhiezer]

> Date: Wed, 10 May 2017 16:31:38 +0100
> From: lf...@cruziero.com (akhiezer)
>
> > From: Paul Menzel <pmen...@molgen.mpg.de>
> > Date: Wed, 10 May 2017 17:06:05 +0200
> >
> > Dear BLFS folks,
> >
> >
> > It???d be awesome
>
>
> ((
>  - really, 'awesome' again: I guess the threshold for being awed,
> varies greatly.
> ))
>
>
> > if you used the more secure HTTPS URL for downloading 
> > the HarBuzz archive in the instructions [1].
> [...]
> >
>


Just to be perhaps clear(er): from here at least:

* thanks for the (objective) info on the adjusted, redirecting,
  upstream url.

* (Imho, https-vs-http is (o/c) not 100% clear-cut: e.g. there
  are pros'n'cons of the overall current certificate-chain setup;
  e.g. ultimately, what parties are essentially the gatekeepers -
  who wants paid before you can play.)

* (the 'awesome' was really a 'gentle' nudge re lang accuracy.)




rgds,

akh





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

Re: [blfs-dev] Use HTTPS URL for HarfBuzz archive

[akhiezer]

> From: Paul Menzel 
> Date: Wed, 10 May 2017 17:06:05 +0200
>
> Dear BLFS folks,
>
>
> It???d be awesome


((
 - really, 'awesome' again: I guess the threshold for being awed,
varies greatly.
))


> if you used the more secure HTTPS URL for downloading 
> the HarBuzz archive in the instructions [1].
[...]
>



akh





--
-- 
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-dev] b/lfs books' xml-formatting -vs- patch readability/fragility.

[akhiezer]

> From: Bruce Dubbs 
> Date: Sun, 23 Apr 2017 12:47:40 -0500
>
[...]
> >
> > If the original xml were formatted thus:
> > 
> > 
> > echo "/opt/llvm3/lib" >> /etc/ld.so.conf 
> > mkdir -v build   
> > cd   build   
>
> That creates unwanted blank lines on the page.  We do what we can to keep 
> things readable, but we are constrained by the docbook syntax (and that is 


It'd be simple to pre-process the xml, to unwrap the code-related
open/close tags as reqd, prior to feeding it into docbook.


E.g. roughly:

$
#
# todo: perh use sed script instead of tr()s, if hit buffering problems.
#
cat $xmlfile |
 tr '\n' $'\x80' |
 sed -rue 's/()([[:blank:]]*\x80/\1/g' |
 tr '\x80' '\n' |
 docbook_scr ... ;
$

And similarly for the relevant code-related closing tags, if that'd
be reqd.



akh





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

[blfs-dev] b/lfs books' xml-formatting -vs- patch readability/fragility.

[akhiezer]

Hi,


A high percentage of lfs/blfs book-commits' patches, could be a lot
more readable - and therefore less fragile/error-prone - if the xml
tags were kept on separate lines from the code.

This would be do-able while still avoiding pitfalls like the old
'vertical-formatting' in *roff/


For example, most of the following diff is caused by formatting of the
original & new xml, as opposed to changes in the shell/ commands;
and as such makes the change/patch much less readable and therefore
more fragile/error-prone for editors/


vv Start of Example vv

From blfs-book-boun...@lists.linuxfromscratch.org Fri Apr 21 07:34:19 2017
To: blfs-b...@lists.linuxfromscratch.org
Date: Fri, 21 Apr 2017 06:34:33 -
Subject: [blfs-book] r18621 - trunk/BOOK/general/prog
From: via blfs-book 

Author: pierre
Date: Thu Apr 20 23:34:33 2017
New Revision: 18621

Log:
LLVM-3: move a command needing root privs to a proper location

Modified:
   trunk/BOOK/general/prog/llvm3.xml

Modified: trunk/BOOK/general/prog/llvm3.xml
==
--- trunk/BOOK/general/prog/llvm3.xml   Thu Apr 20 10:28:42 2017(r18620)
+++ trunk/BOOK/general/prog/llvm3.xml   Thu Apr 20 23:34:33 2017(r18621)
@@ -131,8 +131,7 @@
   commands:
 
 
-echo "/opt/llvm3/lib" >> /etc/ld.so.conf 
-mkdir -v build   
+mkdir -v build   
 cd   build   
 
 CC=gcc CXX=g++   \
@@ -156,11 +155,10 @@
   Now, as the root user:
 
 
-
-make install  
-ldconfig  
-ln -sfv /opt/llvm3/bin/FileCheck /usr/bin
-
+echo "/opt/llvm3/lib" >> /etc/ld.so.conf 

+make install 
+ldconfig 
+ln -sfv /opt/llvm3/bin/FileCheck /usr/bin
 
 
   Building the documentation for current LLVM is

^^^ End of Example ^^


If the original xml were formatted thus:


echo "/opt/llvm3/lib" >> /etc/ld.so.conf 
mkdir -v build   
cd   build   
[...]

make install 
ldconfig 
ln -sfv /opt/llvm3/bin/FileCheck /usr/bin



; and the new-version xml formatted thus:


mkdir -v build   
cd   build   
[...]

echo "/opt/llvm3/lib" >> /etc/ld.so.conf 
make install 
ldconfig 
ln -sfv /opt/llvm3/bin/FileCheck /usr/bin



; then the diff would basically just be:
==
 
-echo "/opt/llvm3/lib" >> /etc/ld.so.conf 
 mkdir -v build   
 cd   build   
 [...]
 
+echo "/opt/llvm3/lib" >> /etc/ld.so.conf 
 make install 
 ldconfig 
 ln -sfv /opt/llvm3/bin/FileCheck /usr/bin
==

; which shows much more clearly what the change is and - as importantly -
is only.


The suggested practice could be made to be part of editorial 'requirements'.



akh





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

Re: [blfs-dev] seamonkey

[akhiezer]

> From: Bruce Dubbs 
> Date: Wed, 28 Dec 2016 23:15:38 -0600
> Subject: [blfs-dev] seamonkey
>
> After a lot of trials I've finally got seamonkey to run without a seg 
> fault.  To do it, I had to disable system icu.   I'm using icu-58.2.
>
> I seem to recall something about this at one time, but I can't find it 
> right now.
>


ca 14/nov/2016, blfs lists?


> There are a few other changes.  --enable-gstreamer (or disable) is not 
> recognized at all.  The build choked with 
> MOZ_OBJDIR=@TOPSRCDIR@/moz-build-dir but it builds fine without that 
> statement.
>
> The easiest way to handle this would be to just remove the mention of icu 
> and gstreamer and MOZ_OBJDIR in mozconfig.  Does that sound like the way 
> to go?
>


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

Re: [blfs-dev] libtool/autotools [Was: nosym branches]

[akhiezer]

> From: DJ Lucas 
> Date: Fri, 16 Dec 2016 23:55:35 -0600
> Subject: Re: [blfs-dev] nosym branches
>
.
.
> > (4) But then, libtool/ltmain.sh/ would throw warnings: cos they compare
> > two path variables' values, and just complain at that stage that
> > they're different; whereas if they (libtool/) went a little bit
> > further and resolved each path to their respective 'real' paths,
> > then it would be seen that they (the 'real' paths) were identical.
>
> This happens to be addressed in a round about way, but was not the 
> driving force behind this change. Although functional, the symlink has 
> always been a workaround. It has served us well, but as above, it is not 
> really necessary any longer - nine package changes for all of LFS and 
> BLFS. In fairness, many of the would be changes were already covered 
> because of /opt installs for QT, KF5, Plasma, and LXQT.
>
> As to the libtool archives, there is more that can be done. Strictly 
> speaking, they should be removed, but it's not something easily 
> addressed in the books. I'd like to add a small blurb about this in the 
> LFS introductory text someplace, but it doesn't really seem to fit 
> anywhere. To be done properly, the .la files must be removed after every 
> package is installed in Chapter 6 and for all of BLFS, and only at 
> -maxdepth 1 for /lib and /usr/lib (and /usr/lib32 if applicable). I have 
> a script that I had used, which I just tacked on to the end of each of 
> the scripts in the chapter06 directory after generating the target 
> JHALFS tree. The only one I had left last time I went through that 
> exercise (libarchive.la) did not seem to be necessary this past time 
> (IOW: I had no .la files in /usr/lib or /lib).
>
> >
> > (5) To try to 'solve' such behaviour, the warnings were suppressed;
> > but it meant being drawn into (again, a degree of) per-package
> > whac-a-mole.
>
> Yes, and again, while the new changes address this indirectly, it really 
> is only a nice consequence of removing the symlink. It doesn't actually 
> fix that particular problem, only hides it again with less work on the 
> part of the user (or editors). Best for now is just to explain it and 
> let the user decide whether to remove them or leave them. For the most 
> part, they don't cause issues, especially without package management.


Is there some way, centrally/efficiently, to address the
libtool/ltmain.sh warnings.


E.g. slackware patches-out the pair of moved/removed lines of code,
in libtool's own os-installed ltmain.sh; and doesn't patch it out
of any other packages at compile-time; and does mostly does use
explicit '--libdir'/ pkg cfg args; and _seems_ to not see any of the
moved/removed warnings when compiling such pkgs - even when /{,usr/}lib*
use some symlnks instead of slackware's usual all-dirs.


BUT, more work/avail-time on this here is needed, to get a more-definite
picture on that.


>
.
.
>



akh





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

Re: [blfs-dev] nosym branches

[akhiezer]

> From: DJ Lucas 
> Date: Fri, 16 Dec 2016 21:48:20 -0600
> Subject: Re: [blfs-dev] multiarch [Was: nosym branches]
>
.
.
> I don't intend to carry them forward. I might throw something in the 
> wiki some day, but I though it important to show at least one working 
> example being that it was brought up.
>


Would it be a good fit to have the chapter (or similar) near to the
'virtualisation' chapter in blfs.



akh




--
-- 
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-dev] nosym branches

[akhiezer]

> From: Bruce Dubbs 
> Date: Fri, 16 Dec 2016 16:10:27 -0600
> Subject: Re: [blfs-dev] [lfs-dev] nosym branches
>
.
.
> I think we can probably put this in trunk as it is simpler than the 
> symlinks we have now and will avoid all those 'seems to be moved' warnings.
>
> I'm also thinking that this may be a big enough conceptual change (it's 
> not really a dramatic change in instructions) to make this LFS 8.0.  If we 
> do that, we should probably do it now so we have a lot of experience with 
> it when we do the final tests for a March release.
>
> What do you think?
>


From the point of view of the earlier posts from here (incl refs,
re versioning) to earlier discussion on version-bumps: I'd say that
there is enough of an ~api change, to warrant a new major version.

(This is as distinct from any number of spurious 'reasons'. And, it
helps keep b/lfs version numbers having a meaning.)



akh





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

Re: [blfs-dev] nosym branches

[akhiezer]

> From: DJ Lucas 
> Date: Sun, 11 Dec 2016 17:10:28 -0600
> Subject: Re: [blfs-dev] nosym branches
>
.
.
> release, and just for fun (I know it wasn't asked for by you, but 
> example anyway):
>
> http://www.linuxfromscratch.org/~dj/lfs-systemd-multiarch/
> http://www.linuxfromscratch.org/~dj/lfs-multiarch/
>


In case these are going to be carried-fwd, as opposed to once-offs:
--
* both seem to be sysd.

* the 'Details of this package ...' links seem to be a bit mis-wired
  on the following pages in each book's ch.6:

   * Binutils-2.27 Multilib (temp)
   * GCC-6.2.0 Multilib (temp)
   * Glibc-2.24 32-bit (temp)
   * Binutils-2.27 Multilib
   * GCC-6.2.0 Multilib
   * Glibc-2.24 Multilib
--



akh





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

Re: [blfs-dev] nosym branches

[akhiezer]

> From: DJ Lucas <d...@linuxfromscratch.org>
> Date: Sun, 11 Dec 2016 17:10:28 -0600
> Subject: Re: [blfs-dev] nosym branches
>
> On 12/11/2016 03:58 PM, akhiezer wrote:
> >
> > Link to patches?
> >
> > Are you 'scripting'/parametrising all of the stuff according to 'bitness'
> > (32-bit or 64-bit) &/or whether user wants to do such a thing: or are
> > you just hard-wiring without regard for either parameter.
> >
>
> Done as per current books, taking into account 'bitness' ('bit width' 
> ??). Feel free to diff the real branch if you'd like, but diffs are here 
> from my former working copy (updated):
>
> http://www.linuxfromscratch.org/~dj/LFS-nosym-20161211.diff
> http://www.linuxfromscratch.org/~dj/BLFS-nosym-20161211.diff
>
> These are now compliant, as per your earlier concern shortly after 
> release, 


Thanks for the links.


Haven't ran a build thru from those, 'fraid: but have read through the
diffs; and looks ok - tho' did have the following coupla queries.


(A) Noticed that creation of /usr{,/local}/lib64 is patched-out
('LFS-nosym-20161211.diff' : 'Index: chapter06/creatingdirs.xml') ;
but seemingly there is no equivalent replacement/'patch-in'. Might it
be prudent to still create them, as part of the new 'x86_64) mkdir -v
/lib64 ;;' ? (Tho' I guess that's partly what the requested real-build
testing would be for.)


(B) Just to check on some of the 'history' of how b/lfs has treated
lib64/

Aiui, it seems that there has happened the following approx sequence:

(1) Some packages were by default installing into /lib64, and some into
/lib ; & sim for /usr/lib* 
These were all dirs.

(2) To avoid such splits, one could use ./configure args
'--libdir=...'/'--with-libdir=...', or similar 'make ...' args, etc.
But that can mean being drawn into (a degree of) per-package
whac-a-mole.

(3) Instead, a symlnk /lib -> /lib64 was used; & sim for /usr/lib ->
/usr/lib64, 

(4) But then, libtool/ltmain.sh/ would throw warnings: cos they compare
two path variables' values, and just complain at that stage that
they're different; whereas if they (libtool/) went a little bit
further and resolved each path to their respective 'real' paths,
then it would be seen that they (the 'real' paths) were identical.

(5) To try to 'solve' such behaviour, the warnings were suppressed;
but it meant being drawn into (again, a degree of) per-package
whac-a-mole.

(6) Now, a mixture of '(1)' and '(2)', above, is being returned to: all
separate dirs again; and still (a degree of) per-package whac-a-mole
use of './configure'/make args '--libdir=...'/'--with-libdir=...'/,
particularly for cmake-based builds.


Is that about right - a reasonably accurate summary.


> and just for fun (I know it wasn't asked for by you, but 
> example anyway):
>
> http://www.linuxfromscratch.org/~dj/lfs-systemd-multiarch/
> http://www.linuxfromscratch.org/~dj/lfs-multiarch/
>


(Have yet to have a look at these.)



rgds,

akh





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

Re: [blfs-dev] drop modemmanager?

[akhiezer]

> From: Bruce Dubbs <bruce.du...@gmail.com>
> Date: Tue, 13 Dec 2016 10:24:58 -0600
> Subject: Re: [blfs-dev] drop modemmanager?
>
> akhiezer wrote:
> >>  From blfs-dev-boun...@lists.linuxfromscratch.org Tue Dec 13 10:45:39 2016
> >> Date: Tue, 13 Dec 2016 10:45:26 +
> >> From: lf...@cruziero.com (akhiezer)
> >> To: BLFS Development List <blfs-dev@lists.linuxfromscratch.org>
> >> Subject: Re: [blfs-dev] drop modemmanager?
> >>
> >>> From: "Douglas R. Reno" <renodr2...@gmail.com>
> >>> Date: Mon, 12 Dec 2016 20:39:58 -0600
> >>> Subject: Re: [blfs-dev] drop modemmanager?
> >>>
> >>> On Mon, Dec 12, 2016 at 8:36 PM, Bruce Dubbs <bruce.du...@gmail.com> 
> >>> wrote:
> >>>
> >>>> Looking at http://wiki.linuxfromscratch.org/blfs/ticket/8569, I am
> >>>> wondering if we should drop modemmanager from BLFS.  I have no idea how 
> >>>> it
> >>>> should be used and I don't think any devs know how to test it.
> >>>>
> >>>> I looked at a couple of references on line and it apparently can be used
> >>>> for sending or receiving cell phone text messages.
> >>>>
> >>>> In any case, if we keep in in the sysV book, we appear to need a boot
> >>>> script.
> >>>>
> >>>> Does anyone have more insight into this package?
> >>>>
> >>>
> >>> Go ahead and drop it from sysv.
> >>>
> >>> It is *required* for GNOME on systemd. I also have some experience with
> >>> this package as it is required for tethering a cell phone on the CDMA
> >>> network to a computer for data purposes. I do it all the time when I'm in 
> >>> a
> >>> remote area.
> >>>
> >>> The simple answer is: It's not usable on sysv. It requires systemd to 
> >>> spawn
> >>> the D-Bus service. That is one drawback to sysv IMO, I can't use my PC in 
> >>> a
> >>> remote area without being able to spawn that service. Again, why I use
> >>> systemd.
> >>
> >>
> >> ( - sounds like propaganda/fud/bllcks/'a-little-knowledge-...'  .)
>
> We were acknowledging ignorance, not in building MM, but in 
> configuring/testing.
>


It is at least reasonably obvious that it is the immediately-preceding
para that was being addressed; and the other materials retained for
overall context for the overall note.


>
> >> Slackware uses modemmanager no-probs:
> >> 
> >> http://slackware.uk/slackware/slackware64-current/source/n/ModemManager/
> >>   [TAR] ModemManager-1.4.14.tar.xz   16-Mar-2016 12:01  1.4M
> >>   [SPT] ModemManager.SlackBuild  20-Dec-2015 06:04  3.1K
> >>   [CMP] WeDoNotHaveSystemD.patch.gz  22-Sep-2013 22:10  444
> >>   [TXT] slack-desc   31-Mar-2016 21:46  832
> >> --
> >> http://slackware.uk/slackware/slackware64-current/source/n/NetworkManager/
> >>   [   ] 55NetworkManager 22-Mar-2016 18:59  938
> >>   [TAR] NetworkManager-1.2.2.tar.xz  11-May-2016 13:03  3.6M
> >>   [SPT] NetworkManager.SlackBuild13-Jun-2016 04:25  5.8K
> >>   [TXT] NetworkManager.conf  22-Apr-2016 04:58  139
> >>   [DIR] conf.d/  25-Mar-2016 04:54-
> >>   [SPT] doinst.sh25-Mar-2016 04:35  1.2K
> >>   [TXT] rc.networkmanager25-Mar-2016 22:57  2.6K
> >>   [TXT] slack-desc   08-Oct-2013 05:28  1.0K
> >> 
> >>
>
> This is useful/helpful.
>
> >> (NB though that 'apparently' b/lfs dev(s) opine(s) that it must be
> >> unusable on Slackware.)
>
> Why the personal slights?  I would be much more appreciative of the help 
> without them.


Ditto.


>
> I have heard the saying before:  All of us are a lot more knowledgeable 
> than any one of us.
>


And again.



hth,
akh





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

Re: [blfs-dev] drop modemmanager?

[akhiezer]

> From blfs-dev-boun...@lists.linuxfromscratch.org Tue Dec 13 10:45:39 2016
> Date: Tue, 13 Dec 2016 10:45:26 +
> From: lf...@cruziero.com (akhiezer)
> To: BLFS Development List <blfs-dev@lists.linuxfromscratch.org>
> Subject: Re: [blfs-dev] drop modemmanager?
>
> > From: "Douglas R. Reno" <renodr2...@gmail.com>
> > Date: Mon, 12 Dec 2016 20:39:58 -0600
> > Subject: Re: [blfs-dev] drop modemmanager?
> >
> > On Mon, Dec 12, 2016 at 8:36 PM, Bruce Dubbs <bruce.du...@gmail.com> wrote:
> >
> > > Looking at http://wiki.linuxfromscratch.org/blfs/ticket/8569, I am
> > > wondering if we should drop modemmanager from BLFS.  I have no idea how it
> > > should be used and I don't think any devs know how to test it.
> > >
> > > I looked at a couple of references on line and it apparently can be used
> > > for sending or receiving cell phone text messages.
> > >
> > > In any case, if we keep in in the sysV book, we appear to need a boot
> > > script.
> > >
> > > Does anyone have more insight into this package?
> > >
> >
> > Go ahead and drop it from sysv.
> >
> > It is *required* for GNOME on systemd. I also have some experience with
> > this package as it is required for tethering a cell phone on the CDMA
> > network to a computer for data purposes. I do it all the time when I'm in a
> > remote area.
> >
> > The simple answer is: It's not usable on sysv. It requires systemd to spawn
> > the D-Bus service. That is one drawback to sysv IMO, I can't use my PC in a
> > remote area without being able to spawn that service. Again, why I use
> > systemd.
>
>
> ( - sounds like propaganda/fud/bllcks/'a-little-knowledge-...'  .)
>
>
> Slackware uses modemmanager no-probs:
> 
> http://slackware.uk/slackware/slackware64-current/source/n/ModemManager/
>  [TAR] ModemManager-1.4.14.tar.xz   16-Mar-2016 12:01  1.4M
>  [SPT] ModemManager.SlackBuild  20-Dec-2015 06:04  3.1K
>  [CMP] WeDoNotHaveSystemD.patch.gz  22-Sep-2013 22:10  444
>  [TXT] slack-desc   31-Mar-2016 21:46  832
> --
> http://slackware.uk/slackware/slackware64-current/source/n/NetworkManager/
>  [   ] 55NetworkManager 22-Mar-2016 18:59  938
>  [TAR] NetworkManager-1.2.2.tar.xz  11-May-2016 13:03  3.6M
>  [SPT] NetworkManager.SlackBuild13-Jun-2016 04:25  5.8K
>  [TXT] NetworkManager.conf  22-Apr-2016 04:58  139
>  [DIR] conf.d/  25-Mar-2016 04:54-
>  [SPT] doinst.sh25-Mar-2016 04:35  1.2K
>  [TXT] rc.networkmanager25-Mar-2016 22:57  2.6K
>  [TXT] slack-desc   08-Oct-2013 05:28  1.0K
> 
>


 - and the compiled packages are at:

http://slackware.uk/slackware/slackware64-current/slackware64/
--
./n/ for ModemManager, NetworkManager, ...
./a/ for dbus, *udev, ...



>
> (NB though that 'apparently' b/lfs dev(s) opine(s) that it must be
> unusable on Slackware.)
>



hth,
akh





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

Re: [blfs-dev] drop modemmanager?

[akhiezer]

> From: "Douglas R. Reno" 
> Date: Mon, 12 Dec 2016 20:39:58 -0600
> Subject: Re: [blfs-dev] drop modemmanager?
>
> On Mon, Dec 12, 2016 at 8:36 PM, Bruce Dubbs  wrote:
>
> > Looking at http://wiki.linuxfromscratch.org/blfs/ticket/8569, I am
> > wondering if we should drop modemmanager from BLFS.  I have no idea how it
> > should be used and I don't think any devs know how to test it.
> >
> > I looked at a couple of references on line and it apparently can be used
> > for sending or receiving cell phone text messages.
> >
> > In any case, if we keep in in the sysV book, we appear to need a boot
> > script.
> >
> > Does anyone have more insight into this package?
> >
>
> Go ahead and drop it from sysv.
>
> It is *required* for GNOME on systemd. I also have some experience with
> this package as it is required for tethering a cell phone on the CDMA
> network to a computer for data purposes. I do it all the time when I'm in a
> remote area.
>
> The simple answer is: It's not usable on sysv. It requires systemd to spawn
> the D-Bus service. That is one drawback to sysv IMO, I can't use my PC in a
> remote area without being able to spawn that service. Again, why I use
> systemd.


( - sounds like propaganda/fud/bllcks/'a-little-knowledge-...'  .)


Slackware uses modemmanager no-probs:

http://slackware.uk/slackware/slackware64-current/source/n/ModemManager/
 [TAR] ModemManager-1.4.14.tar.xz   16-Mar-2016 12:01  1.4M
 [SPT] ModemManager.SlackBuild  20-Dec-2015 06:04  3.1K
 [CMP] WeDoNotHaveSystemD.patch.gz  22-Sep-2013 22:10  444
 [TXT] slack-desc   31-Mar-2016 21:46  832
--
http://slackware.uk/slackware/slackware64-current/source/n/NetworkManager/
 [   ] 55NetworkManager 22-Mar-2016 18:59  938
 [TAR] NetworkManager-1.2.2.tar.xz  11-May-2016 13:03  3.6M
 [SPT] NetworkManager.SlackBuild13-Jun-2016 04:25  5.8K
 [TXT] NetworkManager.conf  22-Apr-2016 04:58  139
 [DIR] conf.d/  25-Mar-2016 04:54-
 [SPT] doinst.sh25-Mar-2016 04:35  1.2K
 [TXT] rc.networkmanager25-Mar-2016 22:57  2.6K
 [TXT] slack-desc   08-Oct-2013 05:28  1.0K



(NB though that 'apparently' b/lfs dev(s) opine(s) that it must be
unusable on Slackware.)



akh





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

Re: [blfs-dev] nosym branches

[akhiezer]

> From: DJ Lucas 
> Date: Sat, 10 Dec 2016 23:37:29 -0600
> Subject: [blfs-dev] nosym branches
>
> Howdy all. You might have noticed the nosym branches in SVN. This 
> removes the /usr/lib64 symlink and replaces the /lib64 symlink with a 
> directory containing only the symlinks to the dynamic loader for x86_64. 
> The changes are actually pretty minimal, excluding the change to 
> t-linux64 in the gcc builds and all of the removed changes to ltmain.sh 
> (..lib/whatever.la has been moved), there are changes to eight packages 
> in BLFS and one in LFS (where libdir must be specified). AFAICT, those 
> nine changes should have no effect on builds where GCC is not modified. 
> Although it's already been tested pretty thoroughly, I'd appreciate just 
> a tad of wider testing before the changes land in trunk. If you've 
> already built from the patches that have been floating around in my home 
> directory over the past few months, then you are already up to date with 
> the branches.
>


Link to patches?


Are you 'scripting'/parametrising all of the stuff according to 'bitness'
(32-bit or 64-bit) &/or whether user wants to do such a thing: or are
you just hard-wiring without regard for either parameter.



rgds,
akh





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

Re: [blfs-dev] seeking advice about exim

[akhiezer]

> From: Pierre Labastie 
> Date: Fri, 9 Dec 2016 10:29:54 +0100
> Subject: Re: [blfs-dev] seeking advice about exim
>
.
.
> I think usual MUA like heirloom mailx use batch submission (exim -bm), 


(By default, yes; but can use smtp/tls/imap/pop/ no-problem.)


>
.
.
>



akh





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

Re: [blfs-dev] seeking advice about exim

[akhiezer]

> From: Pierre Labastie 
> Date: Thu, 8 Dec 2016 21:58:38 +0100
> Subject: [blfs-dev] seeking advice about exim
>
> Hi list,
> With version 4.87 of exim, the instructions in the book do not produce a
> functional MTA. Namely sending local mails is not possible (I have not tried
> to send mail to remote accounts anyway). The log shows:
> ---
> 2016-12-08 17:18:35 U=root F=<[obfuscated address]> temporarily rejected RCPT
> [same address]: syntax error in "control=dkim_disable_verify"
> ---
>
> The reason is that since version 4.87, DKIM support is no more built by
> default, but only if TLS support is asked. But the default config file still
> has "control = dkim_disable_verify", which is taken as syntax error since the
> program does not know anything about DKIM.
>
> There are two solutions for the book:
> - the simplest is to comment out the lines containing dkim in the config file.
> - a smartest one (IMO) would be to recommend the use of TLS. That would
> promote openssl to a recommended dependency. I do not think it would be a
> problem, because openssl is needed for so many things nowadays.
>
> Thoughts?
>


If the above description/ is correct, then (fwiw) I'd say yes, do
recommend tls.



rgds,
akh





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

Re: [blfs-dev] pt.3 -- Re: Xorg bitmap fonts - deprecate them

[akhiezer]

> Date: Tue, 6 Dec 2016 23:17:40 +
> From: Ken Moffat <zarniwh...@ntlworld.com>
> Subject: Re: [blfs-dev] pt.3 -- Re:  Xorg bitmap fonts - deprecate them
>
> On Tue, Dec 06, 2016 at 09:24:50PM +, akhiezer wrote:
> > 
> > To reiterate in summary, addressing much of your words:
> > --
> > * the central point is about managing the book information, incl
> >   release engineering.
> > 
>
> At the moment, this is a proposed change.  If my fellow editors
> agree, something based on it will go into the development book.  If


You did ask for opinions please: now you seem to be restricting to
editors-only.


> there are then problems, it can be altered or reverted.
>
> > * it's better to do the phase-out as the two-stage process than the
> >   one-stage; that includes educational value.
>
> Says you.


( - childish pouting.)


>
> > --
> > It seems that maybe you are a bit too close to the fine-details of the
> > subject matter to see the wider-picture trees.
> > 
>
> That I will accept - those of us who are editing the book have


(Again, you seem to try to 'pull rank' back to editors-only, after
asking for opinions please. "Editing" does not auto-confer goodness on
person or their book content: and your current proposed edits contain
not-good aspects; and I'd contend that that is clearly and obviously so.)


> visions of where certain things can be improved.


('Visions', indeed.)


>
> > 
> > > > 
> > > > The legacy page should at this time include all of the fonts/ that
> > > > you've removed from elsewhere.
> > > > 
> > >
> > > On this, I disagree strongly.  We've carried multiple versions of
> > > some of the old fonts (bitmap, Type1, ttf) for too long.  Meanwhile
> > > current distros use TTF/OTF and even our own xterm page is already
> > > set to do that.
> > >
> > > BLFS, like LFS, is about learning AND about building leading-edge
> > > software.
> > >
> > > > And only after a few more book releases, then remove some/all of the
> > > > items from the book
> > > > 
> > > > That's a standard way of 'putting out to pasture' - phasing out - such
> > > > materials: don't just - for such a case - do the reorganise and remove
> > > > in same step.
> > > > 
> > >
> > > IFF somebody wants them, I provided links to the relevant page in
> > > the two 7.10 books.  But nobody really documented what those bitmap
> > > fonts were good for.  Initially they were part of monolithic X.
> > > So I have no idea *why* anybody might want them.  Do you have a
> > > use-case ?
> > >
> > > > It's ok though to prioritise at this time the focus on the
> > > > libXfont/bdftopcf/font-adobe-100dpi  .
> > > > 
> > > > 
> > > > > +
> > > > > +
> > > > > +  
> > > > > +
> > > > > +  
> > > > > +$LastChangedBy: dibbler $
> > > > > +$Date: 2038-01-19 03:14:07 + (Tue, 19 Jan 2038) 
> > > > > $
> > > > > +  
> > > > > +
> > > > > +  Xorg Legacy
> > > > > +
> > > > > +  
> > > > > +Xorg Legacy
> > > > > +  
> > > > > +
> > > > > +  
> > > > > +Introduction to Xorg Legacy
> > > > > +
> > > > > +Xorg originally provided bitmap 
> > > > > fonts,
> > > > 
> > > > 
> > > > 'originally' implies that it now doesn't: does it still; if so then
> > > > reword.
> > > > 
> > > I can change originally to 'at first only'.
> > 
> > 
> > The 'at first only' is better.
> > 
> > 
> > >  Does that help you ?
> > 
> > 
> > ("Now, now"). It helps the book and readers of the book.
> > 
> > 
>
> So far, _you_ are the only person complaining about the wording, so


('Complaining' is your misapprehension.)


> I was asking if it helped you.


(You know 'fine well' the tone and weight of your phrasing: don't be
now transparently dishonest and try to pretend innocence and ignorance.)


> > > > 
> > > > > +and a tool (bdftopcf) to assist in their 
> > > > > installation.
> > > > > +With the introduction of 
> > > > > xorg-server-1.19.0
> > > > > +and libXfont2, many people will not 
> > > > > need

Re: [blfs-dev] pt.3 -- Re: Xorg bitmap fonts - deprecate them

[akhiezer]

> Date: Tue, 6 Dec 2016 20:54:32 +
> From: Ken Poppet <zarniwh...@ntlworld.com>
> Subject: Re: [blfs-dev] pt.3 -- Re:  Xorg bitmap fonts - deprecate them
>
> On Tue, Dec 06, 2016 at 03:55:57PM +, akhiezer wrote:
> > > Date: Tue, 6 Dec 2016 13:35:55 +
> > > From: Ken Moffat <zarniwh...@ntlworld.com>
> > > Subject: Re: [blfs-dev] Xorg bitmap fonts - deprecate them
> > >


To reiterate in summary, addressing much of your words:
--
* the central point is about managing the book information, incl
  release engineering.

* it's better to do the phase-out as the two-stage process than the
  one-stage; that includes educational value.
--
It seems that maybe you are a bit too close to the fine-details of the
subject matter to see the wider-picture trees.


> > 
> > The legacy page should at this time include all of the fonts/ that
> > you've removed from elsewhere.
> > 
>
> On this, I disagree strongly.  We've carried multiple versions of
> some of the old fonts (bitmap, Type1, ttf) for too long.  Meanwhile
> current distros use TTF/OTF and even our own xterm page is already
> set to do that.
>
> BLFS, like LFS, is about learning AND about building leading-edge
> software.
>
> > And only after a few more book releases, then remove some/all of the
> > items from the book.
> > 
> > That's a standard way of 'putting out to pasture' - phasing out - such
> > materials: don't just - for such a case - do the reorganise and remove
> > in same step.
> > 
>
> IFF somebody wants them, I provided links to the relevant page in
> the two 7.10 books.  But nobody really documented what those bitmap
> fonts were good for.  Initially they were part of monolithic X.
> So I have no idea *why* anybody might want them.  Do you have a
> use-case ?
>
> > It's ok though to prioritise at this time the focus on the
> > libXfont/bdftopcf/font-adobe-100dpi  .
> > 
> > 
> > > +
> > > +
> > > +  
> > > +
> > > +  
> > > +$LastChangedBy: dibbler $
> > > +$Date: 2038-01-19 03:14:07 + (Tue, 19 Jan 2038) $
> > > +  
> > > +
> > > +  Xorg Legacy
> > > +
> > > +  
> > > +Xorg Legacy
> > > +  
> > > +
> > > +  
> > > +Introduction to Xorg Legacy
> > > +
> > > +Xorg originally provided bitmap 
> > > fonts,
> > 
> > 
> > 'originally' implies that it now doesn't: does it still; if so then
> > reword.
> > 
> I can change originally to 'at first only'.


The 'at first only' is better.


>  Does that help you ?


("Now, now"). It helps the book and readers of the book.


> > 
> > > +and a tool (bdftopcf) to assist in their 
> > > installation.
> > > +With the introduction of 
> > > xorg-server-1.19.0
> > > +and libXfont2, many people will not need 
> > > them.
> > > +There are still a few old packages which might require, or benefit 
> > > from,
> > > +these deprecated fonts and so the following packages are shown 
> > > here.
> > 
> > 
> > Those last two sentences - and in partic the last - are a bit too vague
> > and ~hand-waving; and leave readers a bit too much in the dark.
> > 
>
> Beyond the two packages from the book which I mention below, I have
> no idea what strange desktop packages might still need bitmap fonts.
> Possibly, somebody wrote an application years ago, abandonned it, and
> somebody else is still using it.  In an infinite universe, anything
> is possible.
>
> I know of the two packages in the book, I also recall that when I
> first started looking at console fonts (probably in 2006 or 2007) I
> initially started from a bdf source file, but I do not recall
> whether it actually used bdftopcf, only that at the time somebody
> used my variant to create a bitmapped psf and raised a bug.  Also,
> the default Makefile of Terminus uses bdftopcf to create bitmap
> fonts and some format for (I think) a BSD.
>
> > At least, for those packages (if any) that are in BLFS and that
> > are _known_ or _thought_ to still require the now-legacy materials,
> > they should be listed and linked-to explicitly: if there are only a
> > few such packages (e.g. tigervnc ) then it's not a hassle to list;
> > if the list were not short, then it'd call into question doing the
> > 'legacy' stuff yet.
> > 
> They are linked *from* (tigervnc, xscreensaver).  As in the rest of
> the book, we expect you to know what you want to build, and then
> determin e the depen den 

Re: [blfs-dev] Xorg bitmap fonts - deprecate them

[akhiezer]

> Date: Tue, 6 Dec 2016 20:04:32 +
> From: Ken Moffat <zarniwh...@ntlworld.com>
> Subject: Re: [blfs-dev] Xorg bitmap fonts - deprecate them
>
> On Tue, Dec 06, 2016 at 01:46:42PM +, akhiezer wrote:
> > > Date: Tue, 06 Dec 2016 13:45:09 +
> > > From: lf...@cruziero.com (akhiezer)
> > > Subject: Re: [blfs-dev] Xorg bitmap fonts - deprecate them
> > >
>
> First, thanks for taking the time to review this.  I'll reply to all
> your poi nts, event ually.
> > > > --- BOOK-r18030/packages.ent2016-12-05 00:16:59.916891130 +
> > > > +++ BOOK-deprecate/packages.ent 2016-12-06 13:10:34.135075775 +
> > > > @@ -481,7 +481,7 @@
> > > >  
> > > >  
> > > > 
> > > > -  
> > > > +  
> > >
> > >
> > > Shurely not? Instead, keep that xorg-version ENTITY with the accurate
> > > version ('7.7'/); and just do a manual-override ('7') in the relevant
> > > page titles/ or define a related xorg-version-main ENTITY ('7')
> > 
> > 
> > s/main/major/
> > 
>
> I see Bruce and DJ have already commented.  My opinion was that 7.7
> came out in April 2012 and the overall version has not changed since
> then. Specifically, changes to the parts now happen irregularly.
>
> Bruce suggested removing the 7.7, I went with 'cut it down to just
> 7' after I saw it was fro m a version entity -  because we reference
> the major version in text and in the names of book pages and wiki
> pages.
>
> For the moment I cannot see any reason why keeping the 7.7 entity
> would be useful.
>


If just using '7', then entity would (much-)more-correctly be
'xorg-version-major' .



akh





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

[blfs-dev] pt.3 -- Re: Xorg bitmap fonts - deprecate them

[akhiezer]

> Date: Tue, 6 Dec 2016 13:35:55 +
> From: Ken Moffat 
> Subject: Re: [blfs-dev] Xorg bitmap fonts - deprecate them
>
.
.
> diff -Naur BOOK-r18030/x/installing/x7legacy.xml 
> BOOK-deprecate/x/installing/x7legacy.xml
> --- BOOK-r18030/x/installing/x7legacy.xml 1970-01-01 01:00:00.0 
> +0100
> +++ BOOK-deprecate/x/installing/x7legacy.xml  2016-12-06 11:37:04.231916269 
> +
> @@ -0,0 +1,229 @@
> +
> + +   "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [
> +  
> +  %general-entities;
> +
> +  
> +  
> +  
> +  
> +  
> +
> +  
> +   "254ee42bd178d18ebc7a73aacfde7f79">
> +
> +  
> +   "53a48e1fdfec29ab2e89f86d4b7ca902">
> +
> +  
> +   "1347c3031b74c9e91dc4dfa53b12f143">
> +
> +]>


The legacy page should at this time include all of the fonts/ that
you've removed from elsewhere.

And only after a few more book releases, then remove some/all of the
items from the book.

That's a standard way of 'putting out to pasture' - phasing out - such
materials: don't just - for such a case - do the reorganise and remove
in same step.

It's ok though to prioritise at this time the focus on the
libXfont/bdftopcf/font-adobe-100dpi  .


> +
> +
> +  
> +
> +  
> +$LastChangedBy: dibbler $
> +$Date: 2038-01-19 03:14:07 + (Tue, 19 Jan 2038) $
> +  
> +
> +  Xorg Legacy
> +
> +  
> +Xorg Legacy
> +  
> +
> +  
> +Introduction to Xorg Legacy
> +
> +Xorg originally provided bitmap fonts,


'originally' implies that it now doesn't: does it still; if so then
reword.


> +and a tool (bdftopcf) to assist in their installation.
> +With the introduction of xorg-server-1.19.0
> +and libXfont2, many people will not need them.
> +There are still a few old packages which might require, or benefit from,
> +these deprecated fonts and so the following packages are shown 
> here.


Those last two sentences - and in partic the last - are a bit too vague
and ~hand-waving; and leave readers a bit too much in the dark.

At least, for those packages (if any) that are in BLFS and that
are _known_ or _thought_ to still require the now-legacy materials,
they should be listed and linked-to explicitly: if there are only a
few such packages (e.g. tigervnc ) then it's not a hassle to list;
if the list were not short, then it'd call into question doing the
'legacy' stuff yet.


> +
> +
> +  
> +The font-adobe-100dpi package installs 100 dots per inch versions of
> +Courier, Helvetica, New Century Schoolbook and Times fonts. In 
> previous
> +versions of BLFS a lot more fonts were installed, and also 75 dots 
> per


s/and also/including/

or maybe even (less good)

s/and also/plus/

 - but _NOT_ 'and also'; red pen.


> +inch versions.
> +  
> +
> +  
> +   Please consult the BLFS-7.10 book at  +   url="http://www.linuxfromscratch.org/blfs/view/7.10/x/x7font.html"/>
> +   if you wish to install any of those other fonts.


Still too vague: you're leaving readers to hunt'n'peck, while you
know what they're likely to be looking for. Again: for packages in
BLFS that are known/thought to still require the legacy materials,
state the details explicitly. As noted, such materials should anyhow
be listed in legacy page.


> +  
> +
> +  
> +   Please consult the BLFS-7.10 systemd book at  +   
> url="http://www.linuxfromscratch.org/blfs/view/7.10-systemd/x/x7font.html"/>
> +   if you wish to install any of those other fonts.
> +  
> +
> +


Ditto.


>
.
.
> +Downloading Xorg Legacy
> +
> +First, create a list of files to be downloaded. This file will also
> +be used to verify the integrity of the downloads when complete:
> +
> +cat  legacy.dat  "EOF"
> + lib/ libXfont-.tar.bz2
> + app/ bdftopcf-.tar.bz2
> + font/ 
> font-adobe-100dpi-.tar.bz2
> +EOF
> +
> +To download the needed files using wget,
> +use the following commands:
> +
> +mkdir legacy 
> +cd legacy 
> +grep -v '^#' ../legacy.dat | awk '{print $2$3}' | wget -i- -c \
> +-B / 
> +grep -v '^#' ../legacy.dat | awk '{print $1 " " $3}' >../legacy.md5 
> 
> +md5sum -c ../legacy.md5
> +   
> 


Not sure exactly what that comment means. D'you mean, how to pass it
through to wget? If so, then use a '<<<' construct:

$
while read x y z spng; do
  some_cmds;
done <<< "$(
{
  grep -vE '^[[:blank:]]*(#|$)' ../legacy.dat ;
}
)" ;
$


>
.
.
>



hth,
akh





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

[blfs-dev] pt.2 -- Re: Xorg bitmap fonts - deprecate them

[akhiezer]

> Date: Tue, 6 Dec 2016 13:35:55 +
> To: BLFS Development List 
> Subject: Re: [blfs-dev] Xorg bitmap fonts - deprecate them
>
.
.
> diff -Naur BOOK-r18030/x/installing/x7font.xml 
> BOOK-deprecate/x/installing/x7font.xml
> --- BOOK-r18030/x/installing/x7font.xml   2016-08-27 22:39:04.030521290 
> +0100
> +++ BOOK-deprecate/x/installing/x7font.xml2016-12-06 12:57:44.398642468 
> +
> @@ -6,118 +6,37 @@
>  
>
>
> -  
> -  
> -  
> +  
> +  
> +  
>  
>
> "0f2d6546d514c5cc4ecf78a60657a5c1">
>  
> -  
> -   "1347c3031b74c9e91dc4dfa53b12f143">
> -
> -  
> -   "6c9f26c92393c0756f3e8d614713495b">
> -
> -  
> -   "66fb6de561648a6dce2755621d6aea17">
> -
> -  
> -   "e99276db3e7cef6dccc8a57bc68aeba7">
> -
>
> "fcf24554c348df3c689b91596d7f9971">
>  


Cf. note further below: 'font-adobe-utopia-type1' retained here
(apparently): but removed at said note below.


>
> "6d25f64796fef34b53b439c2e9efa562">
>  
> -  
> -   "cc0726e4a277d6ed93b8e09c1f195470">
> -
> -  
> -   "9f11ade089d689b9d59e0f47d26f39cd">
> -
> -  
> -   "565494fc3b6ac08010201d79c677a7a7">
> -
> -  
> -   "c8b73a53dcefe3e8d3907d3500e484a9">
> -
> -  
> -   "f6d65758ac9eb576ae49ab24c5e9019a">
> -
>
> "e8ca58ea0d3726b94fe9f2c17344be60">
>  
>
> "53ed9a42388b7ebb689bdfc374f96a22">
>  
> -  
> -   "6b223a54b15ecbd5a1bc52312ad790d8">
> -
> -  
> -   "d7c0588c26fac055c0dd683fdd65ac34">
> -
>
> "5e0c9895d69d2632e2170114f8283c11">
>  
> -  
> -   "e452b94b59b9cfd49110bb49b6267fba">
> -
> -  
> -   "3e0069d4f178a399cffe56daa95c2b63">
> -
> -  
> -   "0571bf77f8fab465a5454569d9989506">
> -
> -  
> -   "6e7c5108f1b16d7a1c7b2c9760edd6e5">
> -
>
> "bfb2593d2102585f45daa960f43cb3c4">
>  
> -  
> -   "a2401caccbdcf5698e001784dbd43f1a">
> -
> -  
> -   "cb7b57d7800fd9e28ec35d85761ed278">
> -
> -  
> -   "143c228286fe9c920ab60e47c1b60b67">
> -
> -  
> -   "96109d0890ad2b6b0e948525ebb0aba8">
> -
>
> "6306c808f7d7e7d660dfb3859f9091d2">
>  
> -  
> -   "e3e7b0fda650adc7eb6964ff3c486b1c">
> -
> -  
> -   "c88eb44b3b903d79fb44b860a213e623">
> -
> -  
> -   "56b0296e8862fc1df5cdbb4efe604e86">
> -
> -  
> -   "e805feb7c4f20e6bfb1118d19d972219">
> -
> -  
> -   "6f3fdcf2454bf08128a651914b7948ca">
> -
> -  
> -   "beef61a9b0762aba8af7b736bb961f86">
> -
> -  
> -   "948f2e07810b4f31195185921470f68d">
> -
>
> "23756dab809f9ec5011bb27fb2c3c7d6">
>  
> -  
> -   "829a3159389b7f96f629e5388bfee67b">
> -
>
> "3eeb3fb44690b477d510bbd8f86cf5aa">
>  
.
.
> @@ -185,40 +107,11 @@
>  cat  font-.md5  "EOF"
>font-util-.tar.bz2
>encodings-.tar.bz2
> -  
> font-adobe-100dpi-.tar.bz2
> -  
> font-adobe-75dpi-.tar.bz2
> -  
> font-adobe-utopia-100dpi-.tar.bz2
> -  
> font-adobe-utopia-75dpi-.tar.bz2
> -  
> font-adobe-utopia-type1-.tar.bz2


Cf. note above: 'font-adobe-utopia-type1' removed here (apparently),
but not at said note above.


>font-alias-.tar.bz2
> -  
> font-arabic-misc-.tar.bz2
> -  font-bh-100dpi-.tar.bz2
> -  font-bh-75dpi-.tar.bz2
> -  
> font-bh-lucidatypewriter-100dpi-.tar.bz2
> -  
> font-bh-lucidatypewriter-75dpi-.tar.bz2
>font-bh-ttf-.tar.bz2
>font-bh-type1-.tar.bz2
> -  
> font-bitstream-100dpi-.tar.bz2
> -  
> font-bitstream-75dpi-.tar.bz2
> -  
> font-bitstream-type1-.tar.bz2
> -  
> font-cronyx-cyrillic-.tar.bz2
> -  
> font-cursor-misc-.tar.bz2
> -  
> font-daewoo-misc-.tar.bz2
> -  font-dec-misc-.tar.bz2
>font-ibm-type1-.tar.bz2
> -  font-isas-misc-.tar.bz2
> -  font-jis-misc-.tar.bz2
> -  font-micro-misc-.tar.bz2
> -  
> font-misc-cyrillic-.tar.bz2
>
> font-misc-ethiopic-.tar.bz2
> -  
> font-misc-meltho-.tar.bz2
> -  font-misc-misc-.tar.bz2
> -  font-mutt-misc-.tar.bz2
> -  
> font-schumacher-misc-.tar.bz2
> -  
> font-screen-cyrillic-.tar.bz2
> -  font-sony-misc-.tar.bz2
> -  font-sun-misc-.tar.bz2
> -  
> font-winitzki-cyrillic-.tar.bz2
>
> font-xfree86-type1-.tar.bz2
>  EOF
>  


A first-pass skim of the two lists, indicates no other _obvious_
discrepancies: but it should be checked again.



rgds,
akh





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

Re: [blfs-dev] Xorg bitmap fonts - deprecate them

[akhiezer]

> Date: Tue, 06 Dec 2016 13:45:09 +
> From: lf...@cruziero.com (akhiezer)
> Subject: Re: [blfs-dev] Xorg bitmap fonts - deprecate them
>
> > Date: Tue, 6 Dec 2016 13:35:55 +
> > From: Ken Moffat <zarniwh...@ntlworld.com>
> > Subject: Re: [blfs-dev] Xorg bitmap fonts - deprecate them
> >
> > On Mon, Dec 05, 2016 at 07:59:52PM +, Ken Moffat wrote:
> > > On Mon, Dec 05, 2016 at 01:02:33PM -0600, Bruce Dubbs wrote:
> > > 
> > > > As an aside, perhaps we should remove '-7.7' from that section title.
> > > > 
> > It came from the xorg-version, I've reduced it to 7.
> >
> > Rendered versions of both books are at
> > http://www.linuxfromscratch.org/~ken/deprecate-bitmap-fonts/
> >
> > In the end I continued with the "do multiple packages in a script"
> > approach - it fits with the rest of xorg. Extra 'data' file to get
> > the lib, app, font from different subdirectories and then extract the
> > md5 file from it.
> >
> > Opinions, please ?
> >
> > I'll need to make a ticket if I'm going to apply this.
> >
> > A diff of the changes follows
> >
> > ??en
> >
> >
> > diff -Naur BOOK-r18030/packages.ent BOOK-deprecate/packages.ent
> > --- BOOK-r18030/packages.ent2016-12-05 00:16:59.916891130 +
> > +++ BOOK-deprecate/packages.ent 2016-12-06 13:10:34.135075775 +
> > @@ -481,7 +481,7 @@
> >  
> >  
> > 
> > -  
> > +  
>
>
> Shurely not? Instead, keep that xorg-version ENTITY with the accurate
> version ('7.7'/); and just do a manual-override ('7') in the relevant
> page titles/ or define a related xorg-version-main ENTITY ('7')


s/main/major/


> or similar and use that for the/any overrides?
>
>
> >  
> >  
> >  
>   .
>   .
> >
>



akh





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

Re: [blfs-dev] Xorg bitmap fonts - deprecate them

[akhiezer]

> Date: Tue, 6 Dec 2016 13:35:55 +
> From: Ken Moffat 
> Subject: Re: [blfs-dev] Xorg bitmap fonts - deprecate them
>
> On Mon, Dec 05, 2016 at 07:59:52PM +, Ken Moffat wrote:
> > On Mon, Dec 05, 2016 at 01:02:33PM -0600, Bruce Dubbs wrote:
> > 
> > > As an aside, perhaps we should remove '-7.7' from that section title.
> > > 
> It came from the xorg-version, I've reduced it to 7.
>
> Rendered versions of both books are at
> http://www.linuxfromscratch.org/~ken/deprecate-bitmap-fonts/
>
> In the end I continued with the "do multiple packages in a script"
> approach - it fits with the rest of xorg. Extra 'data' file to get
> the lib, app, font from different subdirectories and then extract the
> md5 file from it.
>
> Opinions, please ?
>
> I'll need to make a ticket if I'm going to apply this.
>
> A diff of the changes follows
>
> ??en
>
>
> diff -Naur BOOK-r18030/packages.ent BOOK-deprecate/packages.ent
> --- BOOK-r18030/packages.ent  2016-12-05 00:16:59.916891130 +
> +++ BOOK-deprecate/packages.ent   2016-12-06 13:10:34.135075775 +
> @@ -481,7 +481,7 @@
>  
>  
> 
> -  
> +  


Shurely not? Instead, keep that xorg-version ENTITY with the accurate
version ('7.7'/); and just do a manual-override ('7') in the relevant
page titles/ or define a related xorg-version-main ENTITY ('7')
or similar and use that for the/any overrides?


>  
>  
>  
.
.
>



akh





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

Re: [blfs-dev] Xorg bitmap fonts - deprecate them

[akhiezer]

> Date: Mon, 5 Dec 2016 02:43:27 +
> From: Ken Moffat 
> Subject: Re: [blfs-dev] Xorg bitmap fonts - deprecate them
>
> On Sat, Dec 03, 2016 at 04:40:04PM +, Ken Moffat wrote:
> > 
> > Proposal to deprecate the Xorg bitmap fonts, etc.
> > -
.
.
>
> I'm working on a local version - anything to get rid of the old
> bitmap fonts for most users, and bring the book kicking and
> screaming into the first decade of this century (sic) ;)
>


Might it be better to separate-out the 'Xorg bitmap fonts' to a separate
set of pages, rather than just removing them altogether from the book
at this stage: it seemed that your proposal intended to do the former;
is that the case?



rgds,
akh





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

Re: [blfs-dev] lxdm

[akhiezer]

> From: Roger Koehler 
> Date: Sat, 3 Dec 2016 08:49:47 -0700
> Subject: Re: [blfs-dev] lxdm
>
> On Fri, Dec 2, 2016 at 8:30 PM, Ken Moffat  wrote:
> > On Tue, Nov 29, 2016 at 01:32:18AM +, Ken Moffat wrote:
> >> On Mon, Nov 28, 2016 at 01:59:26PM -0700, Roger Koehler wrote:
> >> > On Mon, Nov 28, 2016 at 1:55 PM, Douglas R. Reno  
> >> > wrote:
> >> > >
> >> > >
> >> > > On Mon, Nov 28, 2016 at 2:48 PM, Roger Koehler 
> >> > > 
> >> > > wrote:
> >> > >>
> >> > >> It crashes for me, too, with the latest xorg-server. If I go back to
> >> > >> the previous version of xorg-server and libXfont, it works.
> >> > >>
> >> > >
> >> > > I don't have xorg-server-1.19 on my workstation, I'm still at 1.18.x. 
> >> > > I do
> >> > > have the latest libXfont though.
> >> >
> >> > That may be the issue. Try libXfont 1.5.2.
> >> I guess you meant "try libXfont-1.5.1 ?"  The new font lib is
> >> libXfont2.
> >>
> >> I assume both need to be old - with 1.5.1 and 1.19.0 it is still
> >> broken for me.
> >>
> >> Raised upstream at https://sourceforge.net/p/lxde/bugs/842/
> >>
> > I haven't made any progress on this.  According to upstream, lxdm
> > doesn't reference libXfont, and it works on fedora25 with
> > libXfont-1.5.2 and xorg-server-1.19.0.
> >
> > The segfault is after glibc seems to think my locale is
> > ANSI_X3.4-1968 and failing to convert the UTF-8 message.  Root's
> > locale when running lxdm via gdb was en_GB.UTF-8.
> >
> > Fedora are using lxdm-git : I tried that but it too segfaulted for
> > me - I didn't bother to look at a bt for the moment, so I guess it
> > might be different.
> >
> > I'm starting to wonder if something in current glibc broke this,
> > but basically I'm flailing around and trying to clutch at straws.
> >
> > If I can't make any progress in the next few days, I guess I'd
> > better raise a BLFS ticket asserting that this is broken.
>
> Could be the kernel.  I just rebuilt my system with all the latest
> (SVN) packages except for the kernel.  I built with linux 3.16.39, and
> lxdm works fine. I am on an intel x86_64 laptop.
>



If you then bisect with different kernel versions (similar configs),
then does it stop working at any point?



rgds,
akh





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

Re: [blfs-dev] Sendmail page - Think we are missing a command

[akhiezer]

> From: Bruce Dubbs 
> Date: Thu, 1 Dec 2016 11:18:59 -0600
> Subject: Re: [blfs-dev] Sendmail page - Think we are missing a command
>
.
.
> # Put in place as root
> install -m755 /etc/mail


(install -d ...)


> install -m644 aliases /etc/mail/aliases
>



akh





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

Re: [blfs-dev] Sendmail page - Think we are missing a command

[akhiezer]

> From: "Douglas R. Reno" <renodr2...@gmail.com>
> Date: Thu, 1 Dec 2016 03:17:23 -0600
> Subject: Re: [blfs-dev] Sendmail page - Think we are missing a command
>
> On Thu, Dec 1, 2016 at 2:53 AM, akhiezer <lf...@cruziero.com> wrote:
>
> > > From: "Douglas R. Reno" <ren...@linuxfromscratch.org>
> > > Date: Thu, 1 Dec 2016 00:56:27 -0600
> > > Subject: Re: [blfs-dev] Sendmail page - Think we are missing a command
> > >
> > > Pierre Labastie wrote:
> > > > On 01/12/2016 04:38, Douglas R. Reno wrote:
> > > >> Hello,
> > > >>
> > > >> Upon trying to run the newaliases command in the Configuration
> > > >> Information page, I'll get the following error:
> > > >>
> > > >> newaliases: cannot open /etc/mail/aliases: Group writable file
> > > >>
> > > >> For context, these are the commands that I ran (similar to the book):
> > > >>
> > > >> renodr [ /sources ]$ su
> > > >> Password:
> > > >> root [ /sources ]# echo $(hostname) > /etc/mail/local-host-names
> > > >> root [ /sources ]# cat > /etc/mail/aliases << "EOF"
> > > >> > postmaster: root
> > > >> > MAILER-DAEMON: root
> > > >> >
> > > >> > EOF


Did /etc/mail/aliases somehow exist prior to the above here-doc command;
and if yes, then was it somehow created by your own, non-root, user;
and would that be why it was 0664 .


What happens if you do:

renodr$ su -
root# cat > /tmp/SOME_FILE_THAT_YOU_KNOW_DOES_NOT_YET_EXIST <<"EOF"
test
EOF
root#

What perms does '/tmp/SOME_FILE_THAT_YOU_KNOW_DOES_NOT_YET_EXIST' have?


((NB that one would of course 'more-properly' use mktemp for gen such
a new file.))


> > > >> root [ /sources ]# newaliases
> > > >> newaliases: cannot open /etc/mail/aliases: Group writable file
> > > >> root [ /sources ]#
> > > >>
> > > >> In order to fix this, I had to run something similar to:
> > > >>
> > > >> root [ /sources ]# chmod -v 644 /etc/mail/aliases
> > > >> mode of '/etc/mail/aliases' changed from 0664 (rw-rw-r--) to 0644
> > > >> (rw-r--r--)
> > > >> root [ /sources ]# newaliases
> > > >> /etc/mail/aliases: 2 aliases, longest 4 bytes, 31 bytes total
> > > >>
> > > >> I propose adding the "chmod -v 644 /etc/mail/aliases" command to the
> > > >> book.
> >
> >
> > Normally you do want such files 0644, and the corresp generated .db files
> > as 0640 : but the root of the problem is why the 0664 appeared at all ...
> >
> >
> > > >>
> > > >> I'd like to ask for comments / suggestions before I put it in there
> > > >> myself.
> > > >>
> > > > I guess it is an "umask" problem.
> >
> >
> >  ...  +1
> >
> >
> > > >  Normally, if your bash startup files
> > > > are set as in the book, umask should be 022 when you are root, and no
> > > > additional instruction should be necessary. OTOH, maybe su does not
> > > > run the bash startup files...
> > > >
> > > As far as I can see after tracing it for a little bit, I can't find a
> > > line in /root/.bashrc, /etc/profile, /etc/bashrc, or /root/.bash_profile
> > > that accomplishes that. However, we do execute it in
> > > /etc/profile.d/umask.sh.
> > >
> > >
> > > When I am "su"ed to root, my umask is 0022. If I use my normal user, my
> > > umask is 0002.
> > >
> > > root [ ~ ]# umask
> > > 0022
> > >
> > > renodr [ /sources ]$ umask
> > > 0002
> > >
> >
> >
> > And if you do 'su -' ?
> >
> >
> renodr [ /sources ]$ su - root
> Password:
> root [ ~ ]# umask
> 0022
> root [ ~ ]#
>
>
>
> > > I just verified that all of my bash startup files are identical to the
> > > ones in the book.
> > >
.
.
>



akh





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

Re: [blfs-dev] Sendmail page - Think we are missing a command

[akhiezer]

> From: "Douglas R. Reno" 
> Date: Thu, 1 Dec 2016 00:56:27 -0600
> Subject: Re: [blfs-dev] Sendmail page - Think we are missing a command
>
> Pierre Labastie wrote:
> > On 01/12/2016 04:38, Douglas R. Reno wrote:
> >> Hello,
> >>
> >> Upon trying to run the newaliases command in the Configuration 
> >> Information page, I'll get the following error:
> >>
> >> newaliases: cannot open /etc/mail/aliases: Group writable file
> >>
> >> For context, these are the commands that I ran (similar to the book):
> >>
> >> renodr [ /sources ]$ su
> >> Password:
> >> root [ /sources ]# echo $(hostname) > /etc/mail/local-host-names
> >> root [ /sources ]# cat > /etc/mail/aliases << "EOF"
> >> > postmaster: root
> >> > MAILER-DAEMON: root
> >> >
> >> > EOF
> >> root [ /sources ]# newaliases
> >> newaliases: cannot open /etc/mail/aliases: Group writable file
> >> root [ /sources ]#
> >>
> >> In order to fix this, I had to run something similar to:
> >>
> >> root [ /sources ]# chmod -v 644 /etc/mail/aliases
> >> mode of '/etc/mail/aliases' changed from 0664 (rw-rw-r--) to 0644 
> >> (rw-r--r--)
> >> root [ /sources ]# newaliases
> >> /etc/mail/aliases: 2 aliases, longest 4 bytes, 31 bytes total
> >>
> >> I propose adding the "chmod -v 644 /etc/mail/aliases" command to the 
> >> book.


Normally you do want such files 0644, and the corresp generated .db files
as 0640 : but the root of the problem is why the 0664 appeared at all ...


> >>
> >> I'd like to ask for comments / suggestions before I put it in there 
> >> myself.
> >>
> > I guess it is an "umask" problem.


 ...  +1


> >  Normally, if your bash startup files 
> > are set as in the book, umask should be 022 when you are root, and no 
> > additional instruction should be necessary. OTOH, maybe su does not 
> > run the bash startup files...
> >
> As far as I can see after tracing it for a little bit, I can't find a 
> line in /root/.bashrc, /etc/profile, /etc/bashrc, or /root/.bash_profile 
> that accomplishes that. However, we do execute it in 
> /etc/profile.d/umask.sh.
>
>
> When I am "su"ed to root, my umask is 0022. If I use my normal user, my 
> umask is 0002.
>
> root [ ~ ]# umask
> 0022
>
> renodr [ /sources ]$ umask
> 0002
>


And if you do 'su -' ?


> I just verified that all of my bash startup files are identical to the 
> ones in the book.
>


The wider picture here is that one should use 'install ...' with explicit
permissions, ownership, group, full src-path, full tgt-path,  - thus
reducing or eliminating implicit intentions; and then verify that what
was intended, has actually been put in place.



akh





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

Re: [blfs-dev] Seamonkey, Firefox, and Thunderbird all cause segfaults with the latest SVN build

[akhiezer]

> Date: Mon, 14 Nov 2016 15:00:13 +
> From: Ken Moffat <zarniwh...@ntlworld.com>
> Subject: Re: [blfs-dev] Seamonkey, Firefox,
>  and Thunderbird all cause segfaults with the latest SVN build
>
> On Mon, Nov 14, 2016 at 09:23:11AM +, akhiezer wrote:
> > > Date: Sun, 13 Nov 2016 21:59:07 +
> > > From: Ken Moffat <zarniwh...@ntlworld.com>
> > > Subject: Re: [blfs-dev] Seamonkey, Firefox,
> > >  and Thunderbird all cause segfaults with the latest SVN build
> > >
> > .
> > .
> > >
> > > I'm surprised that links cuts it at all for you - I find it a pain
> > > for googling error messages.  [...]
> > 
> > 
> > Any particular reason? Hopefully you can at least copy (e.g. via gpm)
> > from shell, and shift-paste into links; and similarly shift-select
> > in links, and then paste in shell. Or is it re tabs, or flipping
> > back'n'forth to shell, or what? Just interested.
> > 
> Most error messages find matches on list archives.  Doing this from
> Xorg, i n a 100x40 terminal, a google similar to yesterday's, for
> for
>  redefinition of ???struct iphdr???
> gives me 14 lines of "menu" (All/Images/Videos/etc/etc each on one
> line) with the first three matches.  And as I scroll down it is
> comparatively difficult to parse the three or four lines of plain
> text.
>


Maybe lynx's (out-of-the-box) colouring could help in the parsing?


akh




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

Re: [blfs-dev] Seamonkey, Firefox, and Thunderbird all cause segfaults with the latest SVN build

[akhiezer]

> Date: Sun, 13 Nov 2016 21:59:07 +
> From: Ken Moffat 
> Subject: Re: [blfs-dev] Seamonkey, Firefox,
>  and Thunderbird all cause segfaults with the latest SVN build
>
.
.
>
> I'm surprised that links cuts it at all for you - I find it a pain
> for googling error messages.  [...]


Any particular reason? Hopefully you can at least copy (e.g. via gpm)
from shell, and shift-paste into links; and similarly shift-select
in links, and then paste in shell. Or is it re tabs, or flipping
back'n'forth to shell, or what? Just interested.



akh





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

Re: [blfs-dev] Re3: Popt-1.16 http download corrupted file?

[akhiezer]

> Date: Sun, 23 Oct 2016 09:42:38 +0100
> From: lf...@cruziero.com (akhiezer)
> Subject: Re: [blfs-dev] Re3: Popt-1.16 http download corrupted file?
>
> > From: Peng HG <craftyflic...@hotmail.com>
> > Date: Sat, 22 Oct 2016 18:28:14 +
> > Subject: Re: [blfs-dev] Re3: Popt-1.16 http download corrupted file?
> >
> > The source of the problem is probably this:
> >
> > http://superuser.com/questions/940605/chromium-prevent-unpacking-tar-gz
> >
>
>
> It certainly tallies with the following:
> 
> Ref: http://www.linuxfromscratch.org/blfs/view/7.10/general/popt.html
> ==
> $ wget -S --spider http://rpm5.org/files/popt/popt-1.16.tar.gz \
>>./blfs710-popt116.wget-S-spider 2>&1
> $
> # Cross-check in case '--spider' mode somehow interferes:
> $ wget -S http://rpm5.org/files/popt/popt-1.16.tar.gz \
>>./blfs710-popt116.wget-S 2>&1
> $
> $ cat ./blfs710-popt116.wget-S-spider
> Spider mode enabled. Check if remote file exists.
> --2016-10-23 09:30:50--  http://rpm5.org/files/popt/popt-1.16.tar.gz
> Resolving rpm5.org (rpm5.org)... 148.251.204.42
> Connecting to rpm5.org (rpm5.org)|148.251.204.42|:80... connected.
> HTTP request sent, awaiting response... 
>   HTTP/1.1 200 OK
>   Date: Sun, 23 Oct 2016 08:51:38 GMT
>   Server: Apache/2.2.29 (OpenPKG/CURRENT)
>   Last-Modified: Fri, 07 May 2010 17:19:32 GMT
>   ETag: "a442-ab931-48604432f3100"
>   Accept-Ranges: bytes
>   Content-Length: 702769
>   Keep-Alive: timeout=15, max=100
>   Connection: Keep-Alive
>   Content-Type: application/x-gzip
>   Content-Encoding: x-gzip
> Length: 702769 (686K) [application/x-gzip]
> Remote file exists.
>
> $
> $ diff -u ./blfs710-popt116.wget-S{-spider,}
> --- ./blfs710-popt116.wget-S-spider 2016-10-23 09:30:51.06902 +0100
> +++ ./blfs710-popt116.wget-S2016-10-23 09:31:07.76802 +0100
> @@ -1,10 +1,9 @@
> -Spider mode enabled. Check if remote file exists.
> ---2016-10-23 09:30:50--  http://rpm5.org/files/popt/popt-1.16.tar.gz
> +--2016-10-23 09:31:06--  http://rpm5.org/files/popt/popt-1.16.tar.gz
>  Resolving rpm5.org (rpm5.org)... 148.251.204.42
>  Connecting to rpm5.org (rpm5.org)|148.251.204.42|:80... connected.
>  HTTP request sent, awaiting response... 
>HTTP/1.1 200 OK
> -  Date: Sun, 23 Oct 2016 08:51:38 GMT
> +  Date: Sun, 23 Oct 2016 08:51:54 GMT
>Server: Apache/2.2.29 (OpenPKG/CURRENT)
>Last-Modified: Fri, 07 May 2010 17:19:32 GMT
>ETag: "a442-ab931-48604432f3100"
> @@ -15,5 +14,22 @@
>Content-Type: application/x-gzip
>Content-Encoding: x-gzip
>  Length: 702769 (686K) [application/x-gzip]
> -Remote file exists.
> +Saving to: "popt-1.16.tar.gz"
> +
> + 0K .. .. .. .. ..  7%  357K 2s
.
.
> +   650K .. .. .. ..   100%  416K=1.2s
> +
> +2016-10-23 09:31:07 (552 KB/s) - "popt-1.16.tar.gz" saved [702769/702769]
>  
> $
> 
>
>
> So, yes, it may be the 'Content-Encoding: x-gzip' line from the popt
> web-server, that's causing the issue.
>


And for completeness:

$ file ./popt-1.16.tar.gz   # - the wget- just-/newly-downloaded object.
./popt-1.16.tar.gz: gzip compressed data, from Unix, last modified: Tue May  4 
21:56:51 2010, max compression
$



akh





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

Re: [blfs-dev] Re3: Popt-1.16 http download corrupted file?

[akhiezer]

> From: Peng HG 
> Date: Sat, 22 Oct 2016 18:28:14 +
> Subject: Re: [blfs-dev] Re3: Popt-1.16 http download corrupted file?
>
> The source of the problem is probably this:
>
> http://superuser.com/questions/940605/chromium-prevent-unpacking-tar-gz
>


It certainly tallies with the following:

Ref: http://www.linuxfromscratch.org/blfs/view/7.10/general/popt.html
==
$ wget -S --spider http://rpm5.org/files/popt/popt-1.16.tar.gz \
   >./blfs710-popt116.wget-S-spider 2>&1
$
# Cross-check in case '--spider' mode somehow interferes:
$ wget -S http://rpm5.org/files/popt/popt-1.16.tar.gz \
   >./blfs710-popt116.wget-S 2>&1
$
$ cat ./blfs710-popt116.wget-S-spider
Spider mode enabled. Check if remote file exists.
--2016-10-23 09:30:50--  http://rpm5.org/files/popt/popt-1.16.tar.gz
Resolving rpm5.org (rpm5.org)... 148.251.204.42
Connecting to rpm5.org (rpm5.org)|148.251.204.42|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Sun, 23 Oct 2016 08:51:38 GMT
  Server: Apache/2.2.29 (OpenPKG/CURRENT)
  Last-Modified: Fri, 07 May 2010 17:19:32 GMT
  ETag: "a442-ab931-48604432f3100"
  Accept-Ranges: bytes
  Content-Length: 702769
  Keep-Alive: timeout=15, max=100
  Connection: Keep-Alive
  Content-Type: application/x-gzip
  Content-Encoding: x-gzip
Length: 702769 (686K) [application/x-gzip]
Remote file exists.

$
$ diff -u ./blfs710-popt116.wget-S{-spider,}
--- ./blfs710-popt116.wget-S-spider 2016-10-23 09:30:51.06902 +0100
+++ ./blfs710-popt116.wget-S2016-10-23 09:31:07.76802 +0100
@@ -1,10 +1,9 @@
-Spider mode enabled. Check if remote file exists.
---2016-10-23 09:30:50--  http://rpm5.org/files/popt/popt-1.16.tar.gz
+--2016-10-23 09:31:06--  http://rpm5.org/files/popt/popt-1.16.tar.gz
 Resolving rpm5.org (rpm5.org)... 148.251.204.42
 Connecting to rpm5.org (rpm5.org)|148.251.204.42|:80... connected.
 HTTP request sent, awaiting response... 
   HTTP/1.1 200 OK
-  Date: Sun, 23 Oct 2016 08:51:38 GMT
+  Date: Sun, 23 Oct 2016 08:51:54 GMT
   Server: Apache/2.2.29 (OpenPKG/CURRENT)
   Last-Modified: Fri, 07 May 2010 17:19:32 GMT
   ETag: "a442-ab931-48604432f3100"
@@ -15,5 +14,22 @@
   Content-Type: application/x-gzip
   Content-Encoding: x-gzip
 Length: 702769 (686K) [application/x-gzip]
-Remote file exists.
+Saving to: "popt-1.16.tar.gz"
+
+ 0K .. .. .. .. ..  7%  357K 2s
+50K .. .. .. .. .. 14%  899K 1s
+   100K .. .. .. .. .. 21% 1.16M 1s
+   150K .. .. .. .. .. 29% 2.84M 1s
+   200K .. .. .. .. .. 36% 1.27M 1s
+   250K .. .. .. .. .. 43% 3.86M 0s
+   300K .. .. .. .. .. 50% 1.08M 0s
+   350K .. .. .. .. .. 58% 5.11M 0s
+   400K .. .. .. .. .. 65% 8.08M 0s
+   450K .. .. .. .. .. 72%  171K 0s
+   500K .. .. .. .. .. 80%  223K 0s
+   550K .. .. .. .. .. 87%  352K 0s
+   600K .. .. .. .. .. 94%  385K 0s
+   650K .. .. .. ..   100%  416K=1.2s
+
+2016-10-23 09:31:07 (552 KB/s) - "popt-1.16.tar.gz" saved [702769/702769]
 
$



So, yes, it may be the 'Content-Encoding: x-gzip' line from the popt
web-server, that's causing the issue.



rgds,
akh





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

Re: [blfs-dev] Popt-1.16 http download corrupted file?

[akhiezer]

> Date: Sat, 22 Oct 2016 01:11:48 +0100
> From: Ken Moffat 
> Subject: Re: [blfs-dev] Popt-1.16 http download corrupted file?
>
> On Fri, Oct 21, 2016 at 11:56:24PM +, Peng HG wrote:
> > Trying to extract the Popt-1.16 tarball downloaded from the http link fails 
> > with the message
> > 
> > gzip:stdin: not in gzip format
> > tar: Child returned status 1
> > tar: Error is not recoverable: exiting now
> > 
> > The tarball from the ftp link is OK though.
>
> Probably a browser error.  I think chromium did that (decompressing
> tar.gz) at one time. 


IOW(?), OP, is your http-downloaded object, a tarball ?


> I've just used wget on the http link.  I got
> the expected md5sum and file reported
>
> popt-1.16.tar.gz: gzip compressed data, last modified: Tue May  4
> 20:56:51 2010, max compression, from Unix
>


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

[akhiezer]

> From: Roger Koehler 
> Date: Sat, 15 Oct 2016 12:24:31 -0600
> Subject: Re: [blfs-dev] systemd
>
> On Sat, Oct 15, 2016 at 12:21 PM, Julien Lepiller  wrote:
> > On Sat, 15 Oct 2016 12:11:19 -0600
> > Roger Koehler  wrote:
> >
> >> So, I guess this link should be removed, and I should use the first
> >> one:
> >>
> >> svn co svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK/
> >
> > this is the correct one.
> >
> >> But this one defaults to the System V version. How do I build the
> >> systemd version?
> >
> > make REV=systemd
> > (REV defaults to sysv)
> >
> > Good luck !
> > --
>
> This is what I was looking for. Thanks!


Cc'ing this across to 'website@...' list:


Should the lfs & blfs website 'download' pages (

  http://www.linuxfromscratch.org/lfs/download.html

  http://www.linuxfromscratch.org/blfs/download.html

) be adjusted to reflect the respective mergings of the xml sources for
sysv/d; not just instructions for post-merge, but also letting folks
know how to checkout pre-merge (sysd) versions.



rgds,
akh





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

[akhiezer]

> From: Roger Koehler <roger.o.koeh...@gmail.com>
> Date: Sat, 15 Oct 2016 12:11:19 -0600
> Subject: Re: [blfs-dev] systemd
>
> On Sat, Oct 15, 2016 at 11:37 AM, akhiezer <lf...@cruziero.com> wrote:
> >> From: Roger Koehler <roger.o.koeh...@gmail.com>
> >> Date: Sat, 15 Oct 2016 11:50:38 -0600
> >> Subject: [blfs-dev] systemd
> >>
> >> I would like to build the development version of blfs systemd, but
> >> when I build the svn branch of the book listed on the
> >> www.linuxfromscratch.org website, the version is still at 2016-07-10.
> >> How do get the latest version from svn?
> >>
> >
> >
> > C'mon ... 'download' ... there's a website ... read:
> >
> >   http://www.linuxfromscratch.org/blfs/download.html
>
> That is the link I am referring to. It has this command listed under
> Current Systemd Development:
>
> svn co svn://svn.linuxfromscratch.org/BLFS/branches/systemd/
>
> Then performing this command: svn update
>
> The version is 2016-07-10.
>
> So, I guess this link should be removed, and I should use the first one:
>
> svn co svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK/
>
> But this one defaults to the System V version. How do I build the
> systemd version?


Ah, thanks for clarifying.

Maybe the 'daily rendered snapshot' link - in the systemd section -
is what u want; links to rendered html, & looks current.



hth
akh





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

Re: [blfs-dev] Question reguarding xorg rebuild due to latest changes

[akhiezer]

> From blfs-dev-boun...@lists.linuxfromscratch.org Wed Oct  5 20:03:09 2016
> From: Tim Tassonis 
> To: BLFS Development List ,
> Bruce Dubbs 
> Date: Wed, 05 Oct 2016 21:07:45 +0200
> Subject: Re: [blfs-dev] Question reguarding xorg rebuild due to latest
>   changes
>
> >> I've just rebuilt Xorg Libraries on my new (7.9) LFS based systems and all
> >> worked well.
> >>
> >> I also tried to be clever, ignored the BLFS ticket's note that older
> >> system need a full rebuild, ended up with a broken X installation and had
> >> to go back to the old version.
> >>
> >> Just if anybody knows: Does _ALL_ from Xorg after Xorg Libraries have to
> >> be rebuild, or is there a known shortcut?
> >
> > I'm not sure what you are asking.  If you want to only rebuild a selected
> > set of xorg libraries, you cna jsut use a custom lib-7.7.md5 file with
> > only the files you want to build.
> >
> > Since building all the libraries is only 2 SBU, there is not much
> > advantage to a selective rebuild.
>
>
> No, sorry, that's not what I meant. I meant, if you have an LFS  7.6 
> installation whith all stuff on the versions in that book, then an Xorg 
> Libraries upgrade to the versions in blfs current will break some stuff, 
> for instance the xorg-server. My question was only if any bodyknows by 
> chance all the exact stuff that breaks.
> Just to cut my rebuild time. But I thinks it's maybe more than just xorg, 
> the problem is one library that has a new soname, libXRand, I believe.
>


IIUIC: why not just run a script to see what's linked against the libs
in question - find ... readelf/ldd ... grep ... - usual stuff.


If that's still not addressing what you mean, then perhaps describe
more simply, procedurally, in the proverbial 'words of one syllalble',
what it is that you are wanting to do; your two outlines above, kindof
pre-filter/re-shape a bit too much, what the core basic infos are.



hth,
akh





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

Re: [blfs-dev] Perl modules

[akhiezer]

> From: Bruce Dubbs 
> Date: Sun, 2 Oct 2016 14:29:00 -0500
> Subject: Re: [blfs-dev] Perl modules
>
> Ken Moffat wrote:
> > I'm still working out the deps for the new version of biber - I have
> > them all now (more than 100 _plus_ LWP), including those needed at
> > runtime and for testing, it's just a question of which (minor)
> > dependencies need which other minor dependencies.  At a guess,
> > probably no more than 5 levels of dependencies.  And I'm not
> > bothering to separate runtime deps.
> >
> > And some of the (many) perl module developers are less reliable than
> > others - frequent new releases, sometimes severely changing the
> > dependencies.
> >
> > What we have been doing is to only list versions for the top-level
> > dependencies needed elsewhere in the book.  The advantage of that is
> > that we don't fill up the comparison report with random new versions
> > of some minor depen dency.  The downside is that any random change
> > can alter the dependencies (that happened to me in the past week,
> > took me ages to find out what was going on).  And if/when that
> > happens, the listed dependencies become incorrect.
> >
> > I'm increasingly thinking that we ought to list the version used for
> > each dependency - and to NOT automatically check for new versions
> > until either we are heading for a release, or until a package which
> > uses something has a new release which needs a later version (biber
> > tends to be good at that).
> >
> > The other problem with the perl modules page is that it is long and
> > deep.  Using versioned entities for everything would solve the
> > depth (only one level of dependency per module) but probably increase
> > the page length by at least two orders of magnitude.
> >
> > Igor's fork of the book was mentioned this week - He has moved his
> > (three) modules into a separate chapter - although I think he is
> > missing some dependencies for the one I looked at ;-)  A separate
> > chapter sounds like the way to go.  Omitting texlive, and therefore
> > biber, obviously has benefits.
> >
> > Changing this would be a major and protracted effort.  I think
> > *something* needs to be done, but my initial change to add
> > unversioned entities for dependencies doesn't look as if it will
> > help as much as I had hoped.  And to be honest, if it wasn't for the
> > pain caused by editing the biber deps I would much prefer to do more
> > interesting things such as bringing TTF/OTF fonts under control.
> >
> > I saw that DJ added some modules without dependencies this week : if
> > you are reading this, how did you find the experience ?
> >
> > Any alternative views ?
> >
> > For the meantime I'm still working through the biber deps, that
> > will take some time and then I'll put them into the CURRENT page
> > (versioned entities for top-level deps, unversioned entities where
> > used by more than one other module).
>
> My understanding is that the issue at hand is due to biblatex-biber.  I am 
> not in favor of a massive increase in the perl modules page to just 
> accommodate one relatively minor package.
>
> I think a section in biblatex-biber discussing the issue and suggesting 
> using cpan for the biber required modules would be sufficient.
>
> Another option is to just drop the biblatex-biber portion of the book.  If 
> a user needs it, there is always install-tl-unx.  Adding a huge tail of 
> dependencies is really only needed for biber developers.
>
> If it is dropped, it can be supplemented by a hint that does not need to 
> be updated every time a perl module is updated.
>


More-or-less ditto. Ken's note reads like some form of self-harming
lost-sight-of-the-woods-for-the-tress really-need-to-stand-back-a-bit
insanity: I would recommend strongly to use/track/include only
(reasonably-)sanely-behaved software/dev practices.


At the very most, perhaps include a 'perl modules reqd for *tex*'
page in the tex section; and if nec reference the main current general
perl-modules page.



rgds,
akh





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

Re: [blfs-dev] ImageMagick-6.9.5-8

[akhiezer]

> From blfs-dev-boun...@lists.linuxfromscratch.org Sat Sep 17 22:05:43 2016
> To: BLFS Development List 
> From: Bruce Dubbs 
> Date: Sat, 17 Sep 2016 16:25:50 -0500
> Subject: Re: [blfs-dev] ImageMagick-6.9.5-8
>
> Paul Hentschel wrote:
> > Hello. This version doesn't appear to exist on the servers anymore. There
> > is a version 6.9.5-9. In fact, there is no -6, -7 or -8, but the
> > ImageMagick change log has them listed. It looks like they don't keep many
> > of the "-x" versions other than -10.
>
> We had a note in the book:
>
> The ImageMagick source releases are updated frequently and the version 
> shown above may no longer be available from the download locations. You 
> can download a more recent version and use the existing BLFS instructions 
> to install it. Chances are that it will work just fine, but this has not 
> been tested by the BLFS team. If the package version shown above is not 
> available from the locations shown above, or from the legacy/ directory at 
> ftp.ImageMagick.org/pub/ImageMagick you can download it from the BLFS 
> package server at ftp://ftp.osuosl.org/pub/blfs/conglomeration/ImageMagick/.
>
> It looks like we need to put that back into the book.
>


One might wish to consider including in the book an alternative:

  http://www.graphicsmagick.org/

?



rgds,

akh





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

[blfs-dev] 'Valgrind' still listed in 'Other Programming Tools' .

[akhiezer]

'Valgrind' still listed (since <= 7.5) in:

  http://www.linuxfromscratch.org/blfs/view/svn/general/other-tools.html

; yet is in the book (since >= 7.6) :

  http://www.linuxfromscratch.org/blfs/view/svn/general/valgrind.html



akh





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

Re: [blfs-dev] gimp-2.8.18 : is gtk-doc now required ?

[akhiezer]

> Date: Tue, 30 Aug 2016 16:26:54 +0100
> From: Ken Moffat 
> Subject: Re: [blfs-dev] gimp-2.8.18 : is gtk-doc now required ?
>
> On Tue, Aug 30, 2016 at 12:01:38AM +0100, Ken Moffat wrote:
>
> > First, autoreconf ended with a lot of error messages like
> > gtk-doc.make:7: error: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL
> > 
> > I note that the book puts autoreconf at the end of that command
> > block, so I figured I'd try '|| true' (my package scripts error out
> > if the status is non-zero).
> > 
> > But now make fails with
> > 
> > Making all in tools
> > make[3]: Nothing to be done for 'all'.
> > Making all in libgimpbase
> > make[3]: Entering directory
> > '/scratch/working/gimp-2.8.18/devel-docs/libgimpbase'
> > Makefile:934: *** missing separator.  Stop.
> > make[3]: Leaving directory
> > '/scratch/working/gimp-2.8.18/devel-docs/libgimpbase'
> > make[2]: *** [Makefile:607: all-recursive] Error 1
> > make[1]: *** [Makefile:743: all-recursive] Error 1
> > 
> > For the moment, I'm stopping my 7.10 build here, I've got several
> > other issues to review.
> > 
> The error comes from the first echo line in the hunk
>
> #
> # Require gtk-doc when making dist
> #
> @HAVE_GTK_DOC_TRUE@dist-check-gtkdoc: docs
> @HAVE_GTK_DOC_FALSE@dist-check-gtkdoc:
> @HAVE_GTK_DOC_FALSE@@echo "*** gtk-doc is needed to run 'make dist'.  
>***"
> @HAVE_GTK_DOC_FALSE@@echo "*** gtk-doc was not found when 'configure' 
> ran.   ***"
> @HAVE_GTK_DOC_FALSE@@echo "*** please install gtk-doc and rerun 
> 'configure'. ***"
> @HAVE_GTK_DOC_FALSE@@false


But that's talking about 'make dist': which is a scenario outwith cmmi;
so why is your cmmi hitting anything to do with 'make dist' - is the
issue really with Makefile* ?


>
> I guess that happened because autoreconf failed because of my
> missing gtk-doc.
>
> The fix is simple -
>
> change the first sed to work on configure instead of configure.ac
>  sed -i '/gegl/s/2/3/' configure
> and drop the autoreconf invocation.
>
> Works for me, and a quick test of a couple of gegl operations
> (colour temperature, unsharp mask) worked.
>
> I've created #8239 for this, but perhaps there are conflicting
> opinions.  Me, I continue to "build as little as possible" because
> it's still hundreds of packages in a complete system and I don't see
> the point in creating unnecessary documentation.
>


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

Re: [blfs-dev] PAM now fails to build docs with links

[akhiezer]

> Date: Wed, 10 Aug 2016 18:39:05 +0100
> From: Ken Moffat 
> Subject: [blfs-dev] PAM now fails to build docs with links
>
> I've been adding PAM to my desktop builds for a while.  By the time
> I get to that point I've already built links, docbook, xslt.
>
> Until now that has built without problems, although it  has not
> built the docs (I don't have w3m), so e.g. a couple of months ago I
> got
> /usr/share/doc/Linux-PAM-1.2.1
> /usr/share/doc/Linux-PAM-1.2.1/draft-morgan-pam-current.txt
> /usr/share/doc/Linux-PAM-1.2.1/index.html
> /usr/share/doc/Linux-PAM-1.2.1/rfc86.0.txt
>
> That was with Linux-PAM-1.2.1 and links-2.12.
>
> Today, with 1.3.0 and 2.13 it tries to build the docs, and fails:
>
> /usr/bin/xsltproc --stringparam generate.toc "book toc" \
>   --stringparam section.autolabel 1 \
>   --stringparam section.label.includes.component.label 1 \
>   --stringparam toc.max.depth 2 --xinclude --nonet \
>   http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl 
> Linux-PAM_SAG.xml | /usr/bin/links -no-numbering -no-references -dump > 
> Linux-PAM_SAG.txt
> Unknown option -no-numbering


Hmmm, those '/usr/bin/links ...' args don't look like the 'real'
'links' prog: looks a bit more like the ~similar 'elinks' - ref e.g.:

  http://elinks.or.cz/documentation/manpages/elinks.1.html

Maybe the relevant pam-devs have got elinks dropped-in for 'links'?


>
> The work-around is to add '--disable-regenerate-docu' : that gives
> the same docs as before (and the index.html is useless with out the
> guides it links to).
>
> Should I add that as an optional switch for people who have the
> docbook deps and xslt but not w3m ?
>


If they're using links/elinks to generate docs, then why 'require'
w3m to build the docs.



akh





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

[blfs-dev] systemd-230 auto-kill background processes on logout?

[akhiezer]

Hi,


For new-ver 230 sysd, should b/lfs ([1,2]) use explicit default of
'--without-kill-user-processes' &/or 'KillUserProcesses=no' per debian
bug item below (where there are counter-points too):


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394
"systemd kill background processes after user logs out"
==
"It is now indeed the case that any background processes that were still
running are killed automatically when the user logs out of a session,
whether it was a desktop session, a VT session, or when you SSHed into a
machine.

Now you can no longer expect a long running background processes to
continue after logging out. I believe this breaks the expecations of
many users. For example, you can no longer start a screen or tmux
session, log out, and expect to come back to it. For this reason, I
think it is a bad decision on the part of the systemd maintainers to
enable this feature by default, and it should rather be disabled by
default in Debian, either by compiling systemd with
--without-kill-user-processes or by setting KillUserProcesses=no in
/etc/systemd/logind.conf" .



[1] http://www.linuxfromscratch.org/lfs/view/systemd/chapter06/systemd.html
[2] http://www.linuxfromscratch.org/blfs/view/systemd/general/systemd.html



rgds,
akh





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

Re: [blfs-dev] Thinking about a new LFS Live CD/iso

[akhiezer]

> From: Tim Tassonis 
> Date: Wed, 25 May 2016 15:27:01 +0200
> Subject: Re: [blfs-dev] Thinking about a new LFS Live CD/iso
>
> On 04/18/16 22:24, Bruce Dubbs wrote:
.
.
> - llvm, mdadm, good if used on a system where lvm/RAID is used


( - s/l// presumably.)




--
-- 
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 -- [Was: GCC 6 annoyances]

[akhiezer]

> From: Bruce Dubbs <bruce.du...@gmail.com>
> Date: Mon, 9 May 2016 09:14:56 -0500
> Subject: Re: [blfs-dev] Versioning -- [Was: GCC 6 annoyances]
>
> akhiezer wrote:
> >> Date: Fri, 6 May 2016 19:57:34 +0100
> >> From: Ken Moffat <zarniwh...@ntlworld.com>
> >> Subject: Re: [blfs-dev] GCC 6 annoyances
> >>
> >> On Fri, May 06, 2016 at 10:38:03AM -0500, Bruce Dubbs wrote:
> > .
> > .
> >>> Speaking of the next release, I'm tempted to call it 8.0 using
> > Linus'
> >>> rationale: it's just time for that.  It's been 5 years since 7.0.
> >>>
> >>> Thoughts?
> >>>
> >>
> >> To me, that sounds very like treating it as a decimal.  At least
> >> linus only rolls the version somewhere around .20.  Or we could
> >> join the firefox/chrome version fight - new number for every
> >> release ;-)
> >>
> >> But it is only a number, even on those days when we want to call it
> >> 666.
> >>
> >
> >
> > I'd say that a major-version increase looks likely to be justified:
> > but not for 'just because', 'itchy feet', 'just meaningless numbers',
> > "fear of (big) numbers", 'me too',  'reasons'.
> >
> >
> > The reasons for going to 8.0 would include any one or more of e.g.:
> > dropping KDE4; dropping Qt4; dropping gcc 4/5; switching to systemd
> > [goto ver '-500'?]; substantial reworking of boot scripts; change to
> > another init system; 
> >
> >
> > The rationale is that you would be making major backward-incompatible
> > changes to the ~'public ~api' of the OS (since, e.g. the newer
> > KDE/Qt/gcc/ are so very different from the dropped or switched-from
> > stuff).
> >
> >
> > Note that (yes, they are not Os's): glibc has been 2.x since ~1997;
> > binutils has been 2.x since at least 1996 (when it was at 2.7); X
> > has had major-ver 11 since 1987, and X11R7.x started in 2005; linux
> > (kernel) is still really 2.x or arguably at most 3.x  .
> >
> >
> > It's not too difficult to have thoughtful, meaningful versioning for
> > an OS; why do all that work and then flick an essentially thoughtless,
> > meaningless label on the result.
> >
> >
> > Give your users/customers some indication of the magnitude of how much
> > will they have to change at their end in order to use your new product:
> > yes, READMEs  will/should contain the details; but a proper version
> > number gives useful immediate at-a-glance information.
> >
> >
> > Internally here, for two OS's ((one based on *nix/bsd/linux, the
> > other on plan9; with eventual-aim in mind of a single line)), we use
> > essentially what is currently-'fashionably' being labelled as (wait
> > for it ... (sigh)) 'semantic versioning'; tho' we don't expect it
> > to be a miracle cure like some seem to think is being claimed (ref
> > e.g. github ref, '4)', below). Note also that it does not preclude
> > use of timestamps, checksum(-part)s,  in version labels (ref
> > e.g. points 9 & 10 of ref '1)', below).
> >
> >
> > If B/LFS did versioning like this then in practice it likely would
> > never reach as high a minor-ver as .10 (tho' it is not an aim to reach
> > or not exceed any particular arbitrary number); and its major-rel
> > number would likely be markedly and justifiedly higher than 8,
> > while not being inflated or set brainlessly, inanely (tho' again,
> > with no artifical practices).
>
> Thank you for the thoughtful post.  I'll note that most of the issues you 
> present are for BLFS and not LFS.  The reason we went to LFS 7.0 was 
> because of a complete rewrite of the boot scripts.  BLFS just followed 
> when we had enough developer time to release 7.4 -- between 6.3 and 7.4 it 
> was a rolling update of the development system only.
>
> Your comments about glibc and binutils is very apropos.  I suspect the 
> reason gcc makes major changes is because they tend to break things when 
> the change the defaults.  Commercial distros have a different motivation. 
>   They are a part of marketing and have codewords as well as version 
> numbers.  I note that some now use dates -- e.g. Ubuntu 16.04 Xenial Xerus 
> or kde applications 16.04.x.
>
> Our timed releases actually would fall into the date method.  What do you 
> think about {,B}LFS-16.09?
>


Overall, I'd say that for public/customer/users/downstream, by far
the most info is conveyed by a (tautology alert!) well-considered
X.Y.Z... scheme.


I'd suggest (~strongly) that the next B/LFS _does_ have 

[blfs-dev] (typo) icons / fonts : ch.28 intro.

[akhiezer]

==
Ref:
http://www.linuxfromscratch.org/blfs/view/stable/x/icons-introduction.html
http://www.linuxfromscratch.org/blfs/view/svn/x/icons-introduction.html
==
"Chapter 28. Icons

Window Managers and Desktop Environments can use icons from different
sources. Generally fonts are installed in /usr/share/icons and are
independent of distribution.
"
==

 s/font/icon/ ?



akh





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

Re: [blfs-dev] (small item): svn-20160323 + rel-7.9 : alsa intro: 5 -vs- 6 .

[akhiezer]

> Date: Thu, 24 Mar 2016 13:20:23 +
> From: lf...@cruziero.com (akhiezer)
> Subject: [blfs-dev] (small item): svn-20160323 + rel-7.9 : alsa intro: 5
>   -vs- 6 .
>
>
> [ Ref:
> http://www.linuxfromscratch.org/blfs/view/stable/multimedia/alsa.html
> http://www.linuxfromscratch.org/blfs/view/svn/multimedia/alsa.html
> ]
> ==
> "
>   ALSA-1.1.0
>   .
>   .
> The following five sections of the book deal with the five separate
> components of ALSA: the libraries, the utilities, the tools, the firmware
> and the OSS compatibility libraries."


Ah, maybe 'The following five sections of the book' is referring to the
list in the same sentence, rather than the book-seq sections following
the 'present' (ALSA-1.1.0) page.


But that would still leave the 'plugins' (perhaps curiously-) unaddressed?


> ==
>
>
> But the OSS stuff is six (sub-)sections after the above 'ALSA-1.1.0'
> page:
> --
> [ Ref:
> http://www.linuxfromscratch.org/blfs/view/stable/
> http://www.linuxfromscratch.org/blfs/view/svn/
> ]
> --
>  * XIII. Multimedia
>
>   * 46. Multimedia Libraries and Drivers
>
>* ALSA-1.1.0
>* alsa-lib-1.1.0
>* alsa-plugins-1.1.0
>* alsa-utils-1.1.0
>* alsa-tools-1.1.0
>* alsa-firmware-1.0.29
>* ALSA OSS-1.0.28
> --
>
>
> Looks like perhaps 'plugins' isn't taken into account in the above ~'alsa
> intro' text (maybe 'plugins' got (re-)added after the text was done,
> or similar).
>


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

[blfs-dev] (small item): svn-20160323 + rel-7.9 : alsa intro: 5 -vs- 6 .

[akhiezer]

[ Ref:
http://www.linuxfromscratch.org/blfs/view/stable/multimedia/alsa.html
http://www.linuxfromscratch.org/blfs/view/svn/multimedia/alsa.html
]
==
"
ALSA-1.1.0
.
.
The following five sections of the book deal with the five separate
components of ALSA: the libraries, the utilities, the tools, the firmware
and the OSS compatibility libraries."
==


But the OSS stuff is six (sub-)sections after the above 'ALSA-1.1.0'
page:
--
[ Ref:
http://www.linuxfromscratch.org/blfs/view/stable/
http://www.linuxfromscratch.org/blfs/view/svn/
]
--
 * XIII. Multimedia

  * 46. Multimedia Libraries and Drivers

   * ALSA-1.1.0
   * alsa-lib-1.1.0
   * alsa-plugins-1.1.0
   * alsa-utils-1.1.0
   * alsa-tools-1.1.0
   * alsa-firmware-1.0.29
   * ALSA OSS-1.0.28
--


Looks like perhaps 'plugins' isn't taken into account in the above ~'alsa
intro' text (maybe 'plugins' got (re-)added after the text was done,
or similar).



rgds,
akh





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

[blfs-dev] (small item): svn-20160323 + rel-7.9 : seamonkey reqd deps not in alphab order.

[akhiezer]

 - per subject; & cf firefox reqd deps.


rgds,
akh


p.s. Got someone here working through ((sizeable) subset of) new b/lfs
books: greatly enthused by such materials being available; also interesting
perennially to view via ~noobs' perspective.





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

Re: [blfs-dev] Acknowledgement to Ken.

[akhiezer]

> From: Fernando de Oliveira 
> Date: Sun, 20 Mar 2016 21:11:28 -0300
> Subject: [blfs-dev] Acknowledgement to Ken.
>
.
.
>
> Until recently I liked you even more than Bruce.
>
> Perhaps my masochism should make me change may aka.
>


 'sisyphus' -> 'prissy fuss' ?


> -- 
> []s,
> Fernando, aka Sísifo
> -- 
>


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

Re: [blfs-dev] terminals

[akhiezer]

> Date: Mon, 14 Mar 2016 04:00:05 +
> From: Ken Moffat 
> Subject: Re: [blfs-dev] terminals
>
> On Sun, Mar 13, 2016 at 08:30:00PM -0500, Bruce Dubbs wrote:
> > I would like to cut down the number of packages in BLFS.  The maintenance
> > burden is tremendous and we have lots of duplication of capabilities. When
> > it comes to terminals, we have:
> > 
> > xterm
> > gnome-terminal
> > xfce4-terminal
> > lxterminal
> > qterminal
> > konsole4
> > konsole5
> > 
> > I propose that we remove konsole4 and gnome-terminal.
> > 
.
.
> I have no objection to removing either of these.
>
> But you missed one - rxvt-unicode aka urxvt :
> actually, I would be happy if we removed xterm (and luit) because


Yes, it has 'baggage' (& ~poor defaults), but I'd suggest keeping xterm -
not least as an ~expected part of basic/core x environment; cf twm .


> rxvt-unicode is so much better (when pointed to a sensible set of
> fonts)
.
.
>



akh





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

Re: [blfs-dev] Weirdnesses with desktop logins

[akhiezer]

> Date: Wed, 9 Mar 2016 05:54:33 +
> From: Ken Moffat 
> Subject: [blfs-dev] Weirdnesses with desktop logins
>
> Just anecdotal comments - I have been ensuring that all my
> currently-maintained systems are updated to firefox-45.  On my first
> test box, where I had so much fun with kde4, startkde no longer
> works.  I can (happily) live with that.  But on an older system on
> the same box, using kf5, startkde worked and let me in - so I left it
> building, and a kf5 (or plasma) screen lock came up - that would NOT
> let me login, I had to reboot.
>
> Now, on my old machine which is now mostly reserved for processing
> photos, the most-recent build (June last year - yes, I know, I
> should have replaced that by now) which has been happily letting me
> login via sddm for all these months suddenly decided that neither
> ken's nor lfs's passwords were correct.  So root changed ken's
> password, but that made not the slightlest difference.  And a quick
> check shows that the system is not full (anyway, /tmp is a tmpfs).
>
> So, just when I was almsot getting used to graphical logins, I think
> I might be heading back to 'startx'.  Ain't life grand ?
>


 - sounds like any number of windows-forum issues / reported
software/system behaviours.


Why do people waste time on ploughing thorugh such crap software/systems.


 ;)



akh





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

Re: [blfs-dev] kde4

[akhiezer]

> Date: Mon, 29 Feb 2016 17:11:42 +
> From: Ken Moffat 
> Subject: Re: [blfs-dev] kde4
>
> On Mon, Feb 29, 2016 at 09:56:21AM +0100, Pierre Labastie wrote:
> > On 29/02/2016 00:04, Ken Moffat wrote:
> > >Tried that, it did not help, and user ken lost his 4 desktops and
> > >separate backgrounds in kde.  Managed to define them again.
> > >
> > >At the moment, the kdepim stuff using akonadi looks broken : I don't
> > >use kmail, kaccountwizard brings up an initial window full of
> > >errors, it looks as if it expects akonadi to be running as root, and
> > >mysql to be running (apparently, it is the default for akonadi).  I
> > >then get a window, but who knows if it is working.
> > I think ~/.config/akonadi/akonadiserverrc (or .config/akonadiserverrc) needs
> > to be changed to use sqlite. Replace "Driver=QMYSQL" with "Driver=QSQLITE3".
> > Of course, sqlite must have been present when Qt was built (same with mysql:
> > you need to build mariadb before qt4 to be able to use the QMYSQL driver).
> > You might want to have a look at https://userbase.kde.org/Akonadi/
> > OTOH, googling for "akonadi sqlite" gives some hints too.
> > 
> > Regards
> > Pierre
>
> Thanks, but ouch!  I built mariadb long after qt4.
>
> At the moment I'm on a different machine, I'll take a look at
> ~/.config when I go back to that one.  I found various posts
> mentioning different locations for akonadiserverrx, maybe I forgot
> to look in ~/.config.
>


+1 for location '~/.config/akonadi/akonadiserverrc' (NB the '...rrc' -
not '...rrx'), for kde ~4.5.5 on slackware 13.37  .

(( But no, haven't used kde since years ago now (though am still somewhat
ambivalent about regarding it as entirly SPOS software)).



akh





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

Re: [blfs-dev] Dependency is missing (xinit)

[akhiezer]

> From: Pierre Labastie 
> Date: Sun, 14 Feb 2016 12:12:24 +0100
> Subject: Re: [blfs-dev] Dependency is missing (xinit)
>
> On 14/02/2016 11:24, Igor ??ivkovi?? wrote:
> > On 02/13/2016 06:26 PM, Pierre Labastie wrote:
> >> On 12/02/2016 16:36, Yukio Shiiya wrote:
> >>> Hi,
> >>>
> >>> I encountered an error on the following page.
> >>> http://www.linuxfromscratch.org/blfs/view/7.8/x/xinit.html
> >>>
> >>> # ./configure $XORG_CONFIG \
> >>>  --with-xinitdir=/etc/X11/app-defaults
> >>> No package 'x11' found
> >>> No package 'xproto' found
> >>>
> >>> I think that "Xorg Libraries" and "Xorg Protocol Headers" should be
> >>> described as "Required Dependency".
> >>>
> >>> Thanks,
> >>>
> >>
> >> Those packages are in the (very long) chain of required dependencies for 
> >> xinit:
> >> (writing -> for "depends on") :
> >> xinit -> twm -> xorg-server -> Xorg fonts -> font-utils -> xcursor-themes 
> >> ->
> >> bdftopcf -> mesa -> X libraries (inclidung libX11) -> libxcb -> libXau -> 
> >> Xorg
> >> protos (including xproto).
> >>
> >> The book is correct.
> > 
> > No, it is not. The technically correct thing to do would be to list 
> > xorg7-lib
> > as required dependency to satisfy the build chain. twm, xclock and xterm are
> > used by default xinitrc at *runtime* but can be easily commented out.
> > 
> > 
> Agreed: I meant the book was correct respective to the OP claim. The deps you
> cite could be made recommended (instructions given later for starting X depend
> on them).
> Xorg-server is also only required at run-time, so, as you say, strictly
> speaking, the only required dep for building is the xorg libraires. But I am
> inclined to keep the server as required, because who would want to build xinit
> without a server?


This is the old mixup/conflation too-prevalent in b/lfs, between
'recommended' and 'required'; it makes the b/lfs deps infos less
reliable than they might/could and should be.


If a package B is not _required_ for building package A, then it
should not be listed as _required_ .

If it is _recommended_, then list it as _recommended_ ; and if nec
mark that it is e.g. strongly-recommended, and give brief parenthesised
few-words note why (as is done for various packages/pages).



rgds,
akh





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

Re: [blfs-dev] Minor correction to curl install

[akhiezer]

> To: BLFS Development List <blfs-dev@lists.linuxfromscratch.org>
> From: Fernando de Oliveira <fam...@yahoo.com.br>
> Date: Sat, 6 Feb 2016 10:48:59 -0300
> Subject: Re: [blfs-dev] Minor correction to curl install
>
> Em 06-02-2016 09:17, akhiezer escreveu:
> >> Date: Fri, 05 Feb 2016 17:47:27 +
> >> From: lf...@cruziero.com (akhiezer)
> >> To: BLFS Development List <blfs-dev@lists.linuxfromscratch.org>
> >> Subject: Re: [blfs-dev] Minor correction to curl install
> >>
> >>> To: BLFS Development List <blfs-dev@lists.linuxfromscratch.org>
> >>> From: Tim Tassonis <st...@decentral.ch>
> >>> Date: Fri, 5 Feb 2016 17:48:14 +0100
> >>> Subject: [blfs-dev] Minor correction to curl install
> >>>
> >>> Hi all
> >>>
> >>> I just install curl from blfs and would suggest a minor correction to 
> >>> the install section:
> >>>
> >>> find docs \( -name Makefile\* \
> >>>-o -name \*.1   \
> >>>-o -name \*.3 \)\
> >>>-exec rm {} \;  &&
> >>
> >>
> >> (Also, '[-depth] ... -delete' instead of the '-exec rm {} \;' ? The
> >> latter isn't wrong; just a little unnecessary to call-out via '-exec' .)
> >>
> > 
> > 
> > The '-exec rm {} \;' will return false on dirs (& spew out
> > errors/warnings) - tho' not cause find() to return non-zero.
> > 
> > 
> > Normally that'd be tightened-up (proactively, defensively) a bit.
> > 
> > 
> > According to blfs svn for curl (
> > http://www.linuxfromscratch.org/blfs/view/svn/basicnet/curl.html ),
> > the intent of the find-rmv is to remove files.
> > 
> > 
> > So depending on whether it's just ordinary files, or just non-dirs,
> > then one would use '-type f' or '! -type d' after the 'docs' or at
> > least before the '-exec' (tho' of course some find() implems can/will
> > do some 'optimising'/rearranging of some parts of their cmdlines).
> > 
> > 
> > And for completeness, if dirs are to be included in the rmvl, then
> > one would normally use the '[-depth] ... -delete' construct instead
> > of the '-exec ...'  .
>
> Sorry to intrude, as it was not directed to me.
>
> Thanks for the valuable info.
>
> You are right: we are only removing files.
>


So:

  # If want to rmv regular files plus symlnks  but skip dirs quietly.
  #
  # Can use '[-depth] ... -delete' instead of the '-exec rm {} \;'  .
  #
  find docs ! -type d \
 \( -name Makefile\* \
 -o -name \*.1   \
 -o -name \*.3 \)\
 -exec rm {} \;  &&

or

  # If only want to rmv regular files, but not symlnks 
  #
  # Can use '[-depth] ... -delete' instead of the '-exec rm {} \;'  .
  #
  find docs -type f \
 \( -name Makefile\* \
 -o -name \*.1   \
 -o -name \*.3 \)\
 -exec rm {} \;  &&

or

  # If not 'openbsd-mmonkeys' mailing-list.
  #
  # Can use '[-depth] ... -delete' instead of the '-exec rm {} \;'  .
  #
  leave as-is / not-bothered (much/enough) / ok-ish, but can't-be-bothered / 
  won't-bother / "nah-let's-not-fkn-bovver" [Al Murray] .  ;)

?



rgds,
akh





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

Re: [blfs-dev] Minor correction to curl install

[akhiezer]

> Date: Fri, 05 Feb 2016 17:47:27 +
> From: lf...@cruziero.com (akhiezer)
> To: BLFS Development List <blfs-dev@lists.linuxfromscratch.org>
> Subject: Re: [blfs-dev] Minor correction to curl install
>
> > To: BLFS Development List <blfs-dev@lists.linuxfromscratch.org>
> > From: Tim Tassonis <st...@decentral.ch>
> > Date: Fri, 5 Feb 2016 17:48:14 +0100
> > Subject: [blfs-dev] Minor correction to curl install
> >
> > Hi all
> >
> > I just install curl from blfs and would suggest a minor correction to 
> > the install section:
> >
> > find docs \( -name Makefile\* \
> >-o -name \*.1   \
> >-o -name \*.3 \)\
> >-exec rm {} \;  &&
>
>
> (Also, '[-depth] ... -delete' instead of the '-exec rm {} \;' ? The
> latter isn't wrong; just a little unnecessary to call-out via '-exec' .)
>


The '-exec rm {} \;' will return false on dirs (& spew out
errors/warnings) - tho' not cause find() to return non-zero.


Normally that'd be tightened-up (proactively, defensively) a bit.


According to blfs svn for curl (
http://www.linuxfromscratch.org/blfs/view/svn/basicnet/curl.html ),
the intent of the find-rmv is to remove files.


So depending on whether it's just ordinary files, or just non-dirs,
then one would use '-type f' or '! -type d' after the 'docs' or at
least before the '-exec' (tho' of course some find() implems can/will
do some 'optimising'/rearranging of some parts of their cmdlines).


And for completeness, if dirs are to be included in the rmvl, then
one would normally use the '[-depth] ... -delete' construct instead
of the '-exec ...'  .



akh





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

Re: [blfs-dev] Minor correction to curl install

[akhiezer]

> To: BLFS Development List 
> From: Tim Tassonis 
> Date: Fri, 5 Feb 2016 17:48:14 +0100
> Subject: [blfs-dev] Minor correction to curl install
>
> Hi all
>
> I just install curl from blfs and would suggest a minor correction to 
> the install section:
>
> find docs \( -name Makefile\* \
>-o -name \*.1   \
>-o -name \*.3 \)\
>-exec rm {} \;  &&


(Also, '[-depth] ... -delete' instead of the '-exec rm {} \;' ? The
latter isn't wrong; just a little unnecessary to call-out via '-exec' .)


>
.
.
>



akh





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

Re: [blfs-dev] UDisks-1.0.5 dependencies

[akhiezer]

 From blfs-dev-boun...@lists.linuxfromscratch.org Sun Dec 21 18:08:51 2014
 Date: Mon, 22 Dec 2014 07:21:59 +1300
 From: Christopher Gregory m...@pc-networking-services.com
 To: blfs-...@linuxfromscratch.org
 Subject: [blfs-dev] UDisks-1.0.5 dependencies

 Hello,

 I am a little confused here as it has LVM2-2.02.114 listed as required,
 and yet when I went to build it after the configure phase it listed llvm


( llvm != lvm/lvm2 )


 support as no.  I had to actually add --enable-lvm2 to have it build with
 it.

 I would have thought that you would not have to explicitly enable
 something if it was required to build.

 To this end, should the page be modified to have it as recommended or even
 optional?

 Regards,

 Christopher.



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

Re: [blfs-dev] UDisks-1.0.5 dependencies

[akhiezer]

 Date: Sun, 21 Dec 2014 12:49:46 -0600
 From: Bruce Dubbs bruce.du...@gmail.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] UDisks-1.0.5 dependencies

 lf...@cruziero.com (akhiezer) wrote:
  Date: Mon, 22 Dec 2014 07:21:59 +1300
  From: Christopher Gregory m...@pc-networking-services.com
  To: blfs-...@linuxfromscratch.org
  Subject: [blfs-dev] UDisks-1.0.5 dependencies
 
  Hello,
 
  I am a little confused here as it has LVM2-2.02.114 listed as required,
  and yet when I went to build it after the configure phase it listed llvm
 
 
  ( llvm != lvm/lvm2 )

 I think that was a typo. 


(yes, on balance, same here; but a reasonable zeroeth-step clarification,
in case it wasn't, and before heading any further.)


 My log also has:

 LVM2 support:   no



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

Re: [blfs-dev] Texlive and current svn

[akhiezer]

 From blfs-dev-boun...@lists.linuxfromscratch.org Wed Dec 10 20:28:01 2014
 Date: Wed, 10 Dec 2014 20:40:38 +
 From: Ken Moffat zarniwh...@ntlworld.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] Texlive and current svn

 On Wed, Dec 10, 2014 at 07:09:48PM +, akhiezer wrote:
  
  
  Apols if is stated clearly earlier in thread, but: for non-build issues,
  if possible could you post - or refer to place(s) in thread - the cmdlines
  that you're seeing not work, along with the errors that you're seeing,
  and what is expected output (I did see the n-page pdf post t'other day);
  and if possible make any input files avail for download via yr lfs webspace
  - or again pointers to them?
  
  There have so-far been two runtime issues while I'm testing my
 current tex-test scripts on recent distro versions (i.e. with 2014
 texlive)¹ :

 1. Context, as noted, is sometimes broken and craps out if you run
 'context --version'.



Does strace give a handle on what's happening?

(Again, apols if is in thread - 'RTFT / FT,TG' is a reasonable reply;
will try to review thread more fully over weekend.)


 2. My xindy test fails to produce an index.  For this, my


Ditto.


 last-released tex-test scripts at ~ken/ have a test called 'make
 encyclopedium'.  My current latest-and-greatest tests have been
 overhauled and expanded, but are not yet ready for an -rc release.
 For that test, my current changes do not really alter what the test
 does.  Deps in the released version are a desktop with fontconfig
 and a PDF viewer (mupdf or xpdf are adequate), and DejaVu (or gnu
 freefont).  Within tex, it uses lualatex so that it can use
 fontspec.

  From memory, the command runs lualatex, xindy, lualatex on the
 supplied file.  If it works, the PDF has four pages (the fourth is
 the index), if not it only has three.

 [1.] Going back before 2013, with my _current_ scripts, things
 started to fall apart.  Luaotfload-tool seems to be a fairly recent
 addition, meaning that lualatex does not always find fontconfig
 fonts in my tests.



Thanks for taking the time to summarise/reiterate the above post's info
from thread. Will try to have a look shortly(-ish).


rgds,
akh


 ??en
 -- 


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

Re: [blfs-dev] Texlive and current svn

[akhiezer]

 Date: Wed, 10 Dec 2014 18:39:59 +
 From: Ken Moffat zarniwh...@ntlworld.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] Texlive and current svn

.
.
  For xindy : yes, I used distros in qemu -

  I did not get around to testing fedora (I _know_ that their
 biblatex stuff has been broken for a few years because they did not
 ship biber (too many perl deps) - found bug(s) for that, and
 somebody had user-supplied versions at fedora for F20.  F21 is now
 out, but I don't think I've got time at the moment.

  For debian-derived, I used xubuntu-14.04 32-bit with texlive-full
 (I'm 99% sure that is now texlive-2014).  There, xindy works.  FWIW,
 asy and biber were not present - I'm sure they are available in
 separate packages, but I have not got back to looking for them.

   I also used the base xubuntu-14.04 to install the 2014 binaries
 from texlive rather than from the distro, using their preferred
 /usr/local/texlive (and also with added symlinks from /usr : I was
 testing how to find texlive OTF/TTF fonts not known to fontconfig,
 but I've now got a better way) and again xindy worked.

  I also tried slackbuilds on slackware64.  There, xindy failed.



Apols if is stated clearly earlier in thread, but: for non-build issues,
if possible could you post - or refer to place(s) in thread - the cmdlines
that you're seeing not work, along with the errors that you're seeing,
and what is expected output (I did see the n-page pdf post t'other day);
and if possible make any input files avail for download via yr lfs webspace
- or again pointers to them?


akh



 ??en



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

Re: [blfs-dev] lxpanel-0.8.0 has a new package requirement

[akhiezer]

 Date: Tue, 09 Dec 2014 10:27:23 -0600
 From: Bruce Dubbs bruce.du...@gmail.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] lxpanel-0.8.0 has a new package requirement

 Bruce Dubbs wrote:
  Ken Moffat wrote:
  On Tue, Dec 09, 2014 at 08:35:56AM -0300, Fernando de Oliveira wrote:
  On 08-12-2014 18:17, Christopher Gregory wrote:
 
  Hello,
 
  I successfully got the gtk+2 version to work with lxpanel-0.8.0.  I am
  using lxde at the moment.
 
  I think we need to add only this one.
 
O/T - I'm not seeing any of Christopher's posts recently.  Whenever
  I go into gmail, I usually find them in the spam (for some reason,
  gmail does not like his posts), but on this separate account nothing.
  I know that ntlworld mail is outsourced to google, I guess they are
  applying similar filtering but without any way for those of us using
  pop3 to get what they think is spam.
 
  I went to my Google spam filter and also found 20 messages from
  Christopher there.  I moved them back to my inbox and then I retrieved
  them via POP.
 
  I don't know why Google thought they were spam unless there is a lot of
  spam origination from his ISP.
 
  Hopefully Google can learn from me restoring the messages.
 
  I'll note that I get a huge amount of spam from the mailing lists that
  others don't see.  Of these Google does filter many and that is helpful.

 A little searching and I found:

 http://email.about.com/od/gmailtips/qt/et_whitelist.htm

 Gmail users may find this helpful.



 - hmmm, so long as gmail isn't naive about spoofed from/c addresses
(and likewise for other parameters of the messages); I'd expect them to
not be; but would be interesting to know in practice on at least that
point - I know that their spam-filtering is generally well-regarded.


akh



-- Bruce




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

Re: [blfs-dev] Some other packages that could possibly be archived

[akhiezer]

 From: Christopher Gregory m...@pc-networking-services.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Date: Mon, 01 Dec 2014 23:18:10 +1300
 Subject: Re: [blfs-dev] Some other packages that could possibly be archived

.
.

 [...].  I also know for a FACT of another package
 that does not work with current instructions but I will leave that for
 you to find out the hard way.



 - or if nec just watch/look-at your commits on your own branch; or are you
going to leave known-broken instructions present for as long as possible,
to try to foil that; or are you helpfully indicating that it's a package
in blfs but not blfs-systemd (CJBLFS/KBLFS).

Or indeed it might _just_ be found out the easy way. (Your wording seems
to imply/assume that working with/via you is not 'the hard way').


akh


 Christopher.




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

Re: [blfs-dev] LXDM: localization fixed but runlevel two different fixes [Was Re: ... bootscripts: . blfs/init.d]

[akhiezer]

 From: Christopher Gregory m...@pc-networking-services.com
 To: blfs-dev@lists.linuxfromscratch.org
 Date: Wed, 03 Sep 2014 17:03:46 +1200
 Subject: Re: [blfs-dev] LXDM: localization fixed but runlevel two different
  fixes [Was Re: ... bootscripts: . blfs/init.d]

 On Tue, 2014-09-02 at 20:05 -0300, Fernando de Oliveira wrote:
  Fixed at revision 14177.
  
  Thanks Armin and Bruce.
  
  Armin, I could not use your suggestion (my preferred one), because each
  time an x-terminal emulator started, several error messages about not
  finding patappend and pathremove appeared in the newly open terminal..
  
  I recall that they used to be unset, and is not anymore, thought it was
  /etc/profile that unset it, but was not. If I could find how to avoid
  this problem, I would replace the fix I put in the book, and don't like,
  by yours.
  
  -- 
  []s,
  Fernando

 Hello Fernando,

 I have added this to my ~/.bashrc
 source /etc/profile



(Hmmm. Depends of course on how are the startup files organised. Some
folks chain:
  { /etc/profile (+) /etc/profile.d/ }
  -- { ~/.profile | ~/.bash_profile | ~/.bash_login}
  -- { ~/.bashrc }
  -- { /etc/bashrc }
; and at most perhaps call some parts of /etc/profile.d/ from the bashrc
stuff. But yes, I know that you're talking about what worked for you here.
)


 I did this so that when I am using a terminal such as in lxde or in
 gnome-terminal that the title and directory gets correctly displayed
 when opening a new terminal in a tab or window.



Perhaps just a side-note, but: certainly at least for twm, if the locale
isn't liked by X then titlebars of windows, and strings in wm menus, c, just
all show 'untitled' (or 'Untitled'). Perhaps you're hitting a similar thing?
(Ref e.g.:
 Warning: locale not supported by Xlib, locale set to C
 http://www.linuxfromscratch.org/lfs/view/7.5/chapter07/profile.html
; and innumerable reports down the years of the 'untitled' behaviour.
)



rgds,
akh





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

Re: [blfs-dev] LXDM: localization fixed but runlevel two different fixes [Was Re: ... bootscripts: . blfs/init.d]

[akhiezer]

 Date: Wed, 03 Sep 2014 11:04:18 -0500
 From: Bruce Dubbs bruce.du...@gmail.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] LXDM: localization fixed but runlevel two different
  fixes [Was Re: ... bootscripts: . blfs/init.d]

.
.
  (Hmmm. Depends of course on how are the startup files organised. Some
  folks chain:
 { /etc/profile (+) /etc/profile.d/ }
 -- { ~/.profile | ~/.bash_profile | ~/.bash_login}

 The order here is defined by bash and ~/.profile is the last option. 
 Also the syntax might be confused as a pipe.  The actual sequence is:

 if[ -e  ~/.bash_profile ]; then source ~/.bash_profile;
 elsif [ -e  ~/.bash_login   ]; then source ~/.bash_login;
 elsif [ -e  ~/.profile  ]; then source ~/.profile;
 fi



Yes, but so what. You're regurgitating bash code: whereas the above just
schematically shows what some folks do - the '|' wasn't meaning to imply
a partic ordering; and instead that some folks just choose to use only
one of the three items.


 -- { ~/.bashrc }

 Depends if it's a login shell or not.


Yeah, but again so what: you're just regurg bash code/manpage.


  Of course is can be explicitly 
 sourced from ~/.bash_profile. etc.



Yes that's precisely what the 'example of what some folks do' ... er, _says_.


 -- { /etc/bashrc }

 Only used if explicitly called from another file (e.g. ~/.bashrc).



Ditto.


  ; and at most perhaps call some parts of /etc/profile.d/ from the bashrc
  stuff. But yes, I know that you're talking about what worked for you here.

 The things that need to be set from ~/.bashrc are aliases and PS1.  The 
 other unusual possibility is non-exported shell variables.  ~/.bashrc is 
 only automatically sourced for interactive subshells.



In what way does that relate to the post. Why are you bothering to write it.


 If the profile files are set up properly, then /etc/profile should only 
 be called once at login.  The issue is to make sure ldxm or other dm 
 does indeed run it.



Ditto.


Bruce, I think you're just yet again completely failing to grasp the
simplest info in the likes of the post. You're almost over-thinking it.



rgds,

akh



-- Bruce



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

Re: [blfs-dev] libpapersize, /etc/libpaper.d, runparts [ re #5454 ]

[akhiezer]

 Date: Tue, 2 Sep 2014 16:44:42 +0100
 From: Ken Moffat zarniwh...@ntlworld.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] libpapersize, /etc/libpaper.d, runparts [ re #5454 ]

 On Tue, Sep 02, 2014 at 12:48:59AM +0100, Ken Moffat wrote:
  On Mon, Sep 01, 2014 at 05:56:34PM -0500, Bruce Dubbs wrote:
   Ken Moffat wrote:
   
 So, should I just remove /etc/papersize ?
   
   I don't think so.  From the man page:
   
   run-parts runs all the executable files named within constraints described
   below, found in directory directory.  Other files and directories are
   silently ignored.
   
   Since there are no options, it would be easy to create a script to do
   run-parts.  What does ${PAPERDIR} resolve to?
   
 -- Bruce
   
   /etc/libpaper.d/
  
  Looking at akhiezer's suggestion (from dcron), I checked at github
 and the license is GPL (version not mentioned).  So, easy enough to
 drop in with added attribution.

  BUT - where to put it ?

 1. Put it at downloads.linuxfromscratch.org (like deb2targz.tar.bz2
 and rpm2targz.tar.bz2) and make a note within libpaper that it
 should be installed in /usr/bin and made executable)

 2. Add it to the book in its own right (so that it can be indexed).
 I suppose it might be generally useful to somebody.  I supposed it
 would go into chapter 11, General Utilities.

 3. Something else that I haven't thought of ?

  N.B. now that I have seen the version akhiezer kindly pointed to,
 anything I came up with would not be clean, it would be a derived
 work and therefore subject to the GPL (which is fine by me).  So,
 I see no benefit in attempting to produce our own version.



Apols for not going and checking, but ... isn't there some 'run-parts' or
so that's part of the cron variant that's in blfs (fcron 3.x, ch.12 blfs
7.5, http://www.linuxfromscratch.org/blfs/view/7.5/general/fcron.html );
I guess maybe not, if your system isn't picking it up.



akh





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

Re: [blfs-dev] Sendmail issues

[akhiezer]

 Date: Sun, 24 Aug 2014 19:52:54 -0500
 From: Bruce Dubbs bruce.du...@gmail.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] Sendmail issues

.
.
 The newaliases command from sendmail is actually the equivalent of 
 running 'sendmail -bi'.   The implementation of the postfix version is 
 completely different.  That said, the format of the aliases file is 
 defined by sendmail, as is the executable name 'sendmail', and all mail 
 MTAs use the same format.

 Note that the newaliases command from sendmail does not recognize the 
 switch -v.  There is a man page installed for newaliases and there are 
 no valid options.



It doesn't - _shouldn't_ - choke on it though: normally 'newaliases -v'
just gives the same output as 'newaliases'. 


 That means the command in the book is incorrect.  I'll fix it for trunk 


More 'superfluous' - the '-v' - than incorrect. But yes, 'newaliases'
is the common and 'proper' invoc - e.g. per the example commands earlier
in the thread.



akh


 at my next commit.

-- Bruce




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

Re: [blfs-dev] Sendmail issues

[akhiezer]

 Date: Mon, 25 Aug 2014 00:24:44 +0200
 From: Armin K. kre...@email.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] Sendmail issues

  Building sendmail packages and I hit an issue. Namely, the newaliases
  -v command seems to hang (or takes forever to complete), rendering my


Dealing with that head-on: often it'd point towards a resolver-related
timeout; and you'd check at least nsswitch.conf and hosts files, or equiv,
to make sure there's sensible setup in there; and in particular so that
sendmail can sanity-check its own host-machine's name c properly. Even
moreso if you're seeing the issue at boot-time: is the requisite infrastruc
avail at the point where you'd run newaliases .


  init scripts (well, systemd units) unusable. Does anyone else experience
  this?
 
 
  ISTR back at the Igor/Armin kill-stamp-sendmail episode, that 

  perhaps you
  weren't in the correct dir - e.g. /etc/mail - when issuing the cmd?


Does (cd /etc/mail  newaliases) [ or (cd /etc/mail; make all;) ] work
any better ?


Does strace give a better handle?


  I just copy/pasted the commands from the page. I can confirm that
  sendmail part works (/usr/sbin/sendmail) as the daemon can be fired up.
  However, newaliases hangs for me 


Just to check: are you saying there that newaliases still apparently-hangs
when it's issued after the machine is up  running?


  and systemd unit I have provided runs
  newaliases before starting sendmail, so that would make the boot hang. I
.
.



Had a look at the sysd unit file. What happens if you use 'ExecStartPost'
instead of the pre?

Also, noted that it uses '=-' and so (IIRC) that means that the command
failing won't prevent execution of subsequent commands. As such, the
newaliases there is kindof considered a 'nicety'.

Again: I would just remove it from startup; it's not cavalier to do so.


akh


p.s. in an earlier different thread, 'an unit' was used a coupla times:
one would really say/write 'a unit'; you'd go by the phonetic ('a you-nit')
rather than the spelling ('an u...'), for that partic case. (But by the same
'rules', you _would) say/write, 'an umbrella').





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

Re: [blfs-dev] Sendmail issues

[akhiezer]

 Date: Mon, 25 Aug 2014 01:55:17 +0200
 From: Armin K. kre...@email.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] Sendmail issues

  Building sendmail packages and I hit an issue. Namely, the newaliases
  -v command seems to hang (or takes forever to complete), rendering my
  
  
  Dealing with that head-on: often it'd point towards a resolver-related
  timeout; and you'd check at least nsswitch.conf and hosts files, or equiv,
  to make sure there's sensible setup in there; and in particular so that
  sendmail can sanity-check its own host-machine's name c properly. Even
  moreso if you're seeing the issue at boot-time: is the requisite infrastruc
  avail at the point where you'd run newaliases .
  


Do bear these in mind.


  
  init scripts (well, systemd units) unusable. Does anyone else 
  experience
  this?
 
 
  ISTR back at the Igor/Armin kill-stamp-sendmail episode, that 
  
  perhaps you
  weren't in the correct dir - e.g. /etc/mail - when issuing the cmd?
  
  
  Does (cd /etc/mail  newaliases) [ or (cd /etc/mail; make all;) ] work
  any better ?
  

 I even tried creating /etc/aliases as a symlink to /etc/mail/aliases,
 but still the command hangs like it waits for input or something like
 that. SIGINT (CTRL+C) terminates it just fine.

 I didn't try running it from /etc/mail, but I did from /etc. No


_Do_ do the (cd /etc/mail  newaliases) : do it when the machine is up 
running  settled; i.e. don't try it yet at boot-time.


 difference. I didn't try the second command.

  
  Does strace give a better handle?
  

 I haven't tried that.

  
  I just copy/pasted the commands from the page. I can confirm that
  sendmail part works (/usr/sbin/sendmail) as the daemon can be fired up.
  However, newaliases hangs for me 
  
  
  Just to check: are you saying there that newaliases still apparently-hangs
  when it's issued after the machine is up  running?
  

 Boot hangs for some time (until the timeout period is over and service
 declared as failed).



Yes, but if you remove 'newaliases' from the unit file - like you've
confirmed below that you've now done - and let the machine boot, and settle,
and then run 'newaliases', does it still take a long time and then fail?


  
  and systemd unit I have provided runs
  newaliases before starting sendmail, so that would make the boot hang. I
  .
  .
 
  
  
  Had a look at the sysd unit file. What happens if you use 'ExecStartPost'
  instead of the pre?
  

 No, I haven't. But I suppose it would bring up the daemon and then hang
 on newaliases. But then again, it would make no sense to run newaliases
 after daemon has been started, would it? You'd have to restart it again
 for them to work.


No, don't need to restart sendmail; running 'newliases' is enough for the
changes to take effect.



  Also, noted that it uses '=-' and so (IIRC) that means that the command
  failing won't prevent execution of subsequent commands. As such, the
  newaliases there is kindof considered a 'nicety'.
  

 Even with - in front of the command, it's still the same. - means ignore
 non-successful command return (or something like that) rather than


Yes, that's what I mean: whoever wrote the original unit file, by using
'=-' is kindof indicating that they're not _too_ bothered if the newaliases
part fails; and therefore that's an indication of the realtive unimportance
they're attaching to having 'newalises' there.


 scratch the program if it hangs forever

  Again: I would just remove it from startup; it's not cavalier to do so.
  

 I have already done that.

.
.
 I may give strace a go tomorrow. I had to
 remove sendmail in order to install exim (and then remove it too) and
 postfix because all 3 of them conflict with each other (more or less),
 so I'm currently settled on postfix.



Had a look at the postfix unit file: would be interesting to see if putting
a postifx 'newaliases' command in there, similar to for sendmail; see if
it hangs or not.





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

Re: [blfs-dev] postlfs/profile.html : '/etc/profile' : add 'unset script' ?

[akhiezer]

 Date: Sat, 16 Aug 2014 16:44:12 -0500
 From: Bruce Dubbs bruce.du...@gmail.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] postlfs/profile.html : '/etc/profile' : add 'unset
  script' ?

 akhiezer wrote:
  Date: Sat, 16 Aug 2014 14:38:19 -0500
  From: Bruce Dubbs bruce.du...@gmail.com
  To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
  Subject: Re: [blfs-dev] postlfs/profile.html : '/etc/profile' : add 'unset
script' ?
 
  akhiezer wrote:
 
  Hi,
 
 
  On svn blfs page:
 
  http://www.linuxfromscratch.org/blfs/view/svn/postlfs/profile.html
 
  , in section '/etc/profile' there is at the end of the code:
  --
  for script in /etc/profile.d/*.sh ; do
if [ -r $script ] ; then
. $script
fi
  done
  --
  But no ~usual-style 'unset script' follows it. Any particular reason for
  that: or should there be such a line added in the ~usual way.
 
  After booting and from the command line, run `set|grep script`.  Do you
  see anything?
 
  For another clue, see man bash and look for the builtin command 'export'.
 
 
 
  Lol, you've at times an unerring capability of entirely missing the point
;)  . You've missed the most obvious scope of the variable. But, 's ok -

 You have an unerring capability of not making your point clear. :) Is it 


There's no accounting for wilful obduracy ;)  . Here then is it re-cast in
the form of your 'teaching' 'style' above: Here's a clue: read man-bash
section Invocation; or man-ash section Invocation - it's even simpler
and more direct.; but imho such posturing talk is a bit silly. So here
instead are a few clue-bats:

 - it's concerning basic proactive defensive programming. Which of course
 is a core element of good security. And in many quarters is valued
 educationally, financially, as well as from many other standpoints.

 - as any fule kno, when a query is raised about leaving a variable in a non-
 nailed-down state, then that query is concerning defensive-programming;
 an automatic flag goes up.

 - the variable in question, as it stands, persists through - but not 
 intentionally - to the user's relevant ~/. files
 (.profile/.bash_profile/.bash_login) and to any files sourced from there,
 et seq. (Put some 'echo $script' lines in those chains of files. Then login
 /or run an appropriate shell invocation. Do you see anything?). As such,
 its scope should be addressed. And in this case that should be with an
 'unset' in the specified place.

 - if/as/when such matters are dismissed haughtily by a person, then keep
 an eye on them: they're probably not carrying out the role that they're
 purporting to, as properly as they might have people believe. And even
 moreso if they try to throw some red-herrings into the mix.


 you want to make the structure the same as other places in the book or 
 that you think that the variable hangs around after running the script?

 We don't add instructions that are not needed.  It might be an 


See above.


Ref also:

  http://www.linuxfromscratch.org/blfs/view/svn/postlfs/profile.html
  , sec '~/.bash_profile' 
  , code-line 'unset append' :

why do *you* think that's needed?


 interesting question to ask a student to research why it isn't needed.


See above.


Sounds like they might have to find out for themselves (no bad thing,
of course), why it *is* needed.



hth,

Akhiezer




-- Bruce



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

[blfs-dev] postlfs/profile.html : '/etc/profile' : add 'unset script' ?

[akhiezer]

Hi,


On svn blfs page:

  http://www.linuxfromscratch.org/blfs/view/svn/postlfs/profile.html

, in section '/etc/profile' there is at the end of the code:
--
for script in /etc/profile.d/*.sh ; do
if [ -r $script ] ; then
. $script
fi
done
--
But no ~usual-style 'unset script' follows it. Any particular reason for
that: or should there be such a line added in the ~usual way.


rgds,

akh





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

Re: [blfs-dev] postlfs/profile.html : '/etc/profile' : add 'unset script' ?

[akhiezer]

 Date: Sat, 16 Aug 2014 14:38:19 -0500
 From: Bruce Dubbs bruce.du...@gmail.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] postlfs/profile.html : '/etc/profile' : add 'unset
  script' ?

 akhiezer wrote:
 
  Hi,
 
 
  On svn blfs page:
 
 http://www.linuxfromscratch.org/blfs/view/svn/postlfs/profile.html
 
  , in section '/etc/profile' there is at the end of the code:
  --
  for script in /etc/profile.d/*.sh ; do
   if [ -r $script ] ; then
   . $script
   fi
  done
  --
  But no ~usual-style 'unset script' follows it. Any particular reason for
  that: or should there be such a line added in the ~usual way.

 After booting and from the command line, run `set|grep script`.  Do you 
 see anything?

 For another clue, see man bash and look for the builtin command 'export'.



Lol, you've at times an unerring capability of entirely missing the point
 ;)  . You've missed the most obvious scope of the variable. But, 's ok -
nevermind; your book, your rules.


Akhiezer



-- Bruce



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

[blfs-dev] postlfs/profile.html : PKG_CONFIG_PATH : allow for /usr/local/lib64/... ?

[akhiezer]

Hi,


On svn blfs page:

  http://www.linuxfromscratch.org/blfs/view/svn/postlfs/profile.html

, in section '/etc/profile.d/extrapaths.sh' there is:
--
  if [ -d /usr/local/lib/pkgconfig ] ; then
pathappend /usr/local/lib/pkgconfig PKG_CONFIG_PATH
  fi
--

Should there instead be a construct there that allows for bit-ness -
i.e. '.../lib64/...' and not nec just '.../lib/...' ?



rgds,

akh





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

Re: [blfs-dev] When naming versions of gcc

[akhiezer]

 Date: Wed, 06 Aug 2014 14:33:53 +0200
 From: Armin K. kre...@email.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] When naming versions of gcc

.
.

 If (new) compiler restrictions/rules caused an error, then it will be a
 problem with any later version.



Not really - not for _any_ later version: it's not a _problem_ for
downstream/blfs if e.g. lame at some point adjusts its code such that the
patch is not needed.


 Debian uses gcc-major-minor to indicate that patch fixes a problem that
 occours with gcc feature additions/improvements (increased minor version).



Yes, but that all becomes unnecessary if e.g. lame code adjusts such that
the patch is not needed at all.


If for some reason, the blfs lame page wants to say that a patch is for
gcc 4.9.0  4.9.1 then sure: but a blfs release is based on a single lfs
release, that has a single gcc ver; so such a comment in the blfs lame
page - talking about multiple gcc versions - is kindof an aside.


  
  For this case, I thank Christopher and will bump the version.



 -- 
 Note: My last name is not Krejzi.



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

Re: [blfs-dev] ... r13828 - in trunk/BOOK: . introduction/welcome lxde/desktop

[akhiezer]

 Date: Mon, 04 Aug 2014 19:40:46 -0500
 From: Bruce Dubbs bruce.du...@gmail.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] ... r13828 - in trunk/BOOK: . introduction/welcome
  lxde/desktop

 Armin K. wrote:

  +  paraWith this switch, parallel build is not supported. Use
  +  commandmake -j1/command if you have MAKEFLAGS set to value
  larger
  +  than unity./para

  Okay, thanks for the explanation, now it makes more sense. But I still
  don't understand the word unity and how it fits in there.

 The word 'unity' is quite valid here, but for an international audience, 
 the word 'one' would probably be better.

 u·ni·ty
 ??yo??on??t??/
 noun
 noun: unity

  1. the state of being united or joined as a whole.

  2. Mathematics British
  the number one.



Even in math, 'roots of unity' is about the only at-all common usage:
but even then, it's at least as often considered to be sounding archaic
and contrived (possibly also pretentious), and is instead expressed as
'roots of 1'.


So, definitely here ... larger than one., and not ... larger than unity.;
and not ... larger than 1.  .


(So, if we're all speaking as one - with a unity of voice - then let's
do it., c)


In related news ... there are 19 pins on the head of an angel ...



hth,

akh



 Origin Middle English: from Old French unite, from Latin unitas, from 
 unus ???one.???

-- Bruce



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

Re: [blfs-dev] ... r13824 - in trunk/BOOK: general/graphlib introduction/welcome

[akhiezer]

 Date: Mon, 04 Aug 2014 11:01:44 -0300
 From: Fernando de Oliveira fam...@yahoo.com.br
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] ... r13824 - in trunk/BOOK: general/graphlib
   introduction/welcome

 On 04-08-2014 10:26, Armin K. wrote:
  On 08/04/2014 01:54 PM, ferna...@higgs.linuxfromscratch.org wrote:
  Author: fernando
  Date: Mon Aug  4 04:54:40 2014
  New Revision: 13824
 
  Log:
  Fix FreeType-2.5.3 for first installation without FreeType-2.5.3 that I 
  forgot to make explicit (only talked about), when updating. Thanks 
  Christopher G.
 
  Modified:
 trunk/BOOK/general/graphlib/freetype2.xml
 trunk/BOOK/introduction/welcome/changelog.xml
 
  
  
  
  Modified: trunk/BOOK/introduction/welcome/changelog.xml
  ==
  --- trunk/BOOK/introduction/welcome/changelog.xml  Mon Aug  4 04:01:28 
  2014(r13823)
  +++ trunk/BOOK/introduction/welcome/changelog.xml  Mon Aug  4 04:54:40 
  2014(r13824)
  @@ -48,6 +48,11 @@
 paraAugust 4th, 2014/para
 itemizedlist
   listitem
  +  para[fernando] - Fix FreeType-2.5.3 for first installation 
  without
  +  FreeType-2.5.3 that I forgot to make explicit (only talked 
  about),
  +  when updating. Thanks Christopher G./para
  +/listitem
  
  I don't mean to be rude, but if you are taking something that was first
  done in systemd branch, it would be fair to give the credit to the one
  who fixed it (merge the correct changelog entry). You can see I do that
  all the time.
  
  
  

 Sorry about that.

 Christopher being systemd developer, I thought mentioning him was
 exactly acknowledging that.

 In the papers that I published in the past, we never mentioned
 Universities or Laboratories, just the authors, although these
 informations were always in the papers (referred and to be published)
 just below the authors names.

 Fixed at revision 13827.



Should you define some entities:

  Thanks Christopher G., from systemd branch.

  Thanks Armin K., from systemd branch.

  , from systemd branch.

Might save some typing.


akh



 Thanks.

 -- 
 []s,
 Fernando



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

Re: [blfs-dev] /etc/logrotate.conf nomail option

[akhiezer]

 Date: Sat, 2 Aug 2014 00:54:07 +0100
 From: Ken Moffat zarniwh...@ntlworld.com
 To: blfs-dev@lists.linuxfromscratch.org
 Subject: [blfs-dev] /etc/logrotate.conf nomail option

  I'm just updating my build scripts.  For years I have used a simple
 script to do log rotation, so now I am going to try the logrotate
 package.  Looking at the creation of /etc/logrotate.conf we have the
 following:

 # Don't send mail to anybody
 nomail

  I read that comment as logrotate should not send mail about its
 operation to anybody, which is not necessarily what I want
 (although I think I'm going to get a report from fcron).  But looking
 at an online manpage, and the link to techrepublic.com, the command
 appears to mean Do not mail old logs (which are about to be deleted)
 to anybody and that is proobably what I want.

  Am I right that the comment is misleading, or have I misunderstood
 it ?



What behaviour _do_ you want?


'nomail' means the opposite sense of the 'mail' directive (ref excerpt
from man-page, below).


Here, for example, we'd normally use, in /etc/logrotate.conf , as
belts'n'braces additional backup for logfiles:

mail eml_addr_userpart@eml_addr_dompart
maillast

If instead I wanted to nail-down logrotate to not send email at all for
either of the 'mailfirst' or 'maillast' senses, then I'd use 'nomail'
by itself.


Note that logrotate can have nested, hierarchical definitions/contexts
in the cfg file, with deeper-nested definitions taking precedence: so you
can use e.g. 'nomail' globally, but override it for a sub-section.


The mail/nomail settings for logrotate, don't affect the usual
cron emailed reports. Although, you _could_ use logrotate's
p{re,ost}rotate/{fir,la}staction/c directives, to mess about with such
cron stuff if you wanted, for whatever reason.


Ref: As da man says:

mail address
  When  a  log  is  rotated  out-of-existence, it is mailed to address. If
  no mail should be generated by a particular log, the nomail directive
  may be used.

mailfirst
  When using the mail command, mail the just-rotated file, instead of the
  about-to-expire file.

maillast
  When using the mail command, mail the about-to-expire file, instead of
  the just-rotated file (this is the default).

nomail
  Don't mail old log files to any address.





rgds,
akh





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

Re: [blfs-dev] /etc/logrotate.conf nomail option

[akhiezer]

 Date: Sat, 2 Aug 2014 21:10:16 +0100
 From: Ken Moffat zarniwh...@ntlworld.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] /etc/logrotate.conf nomail option

 On Sat, Aug 02, 2014 at 08:27:02AM +0100, akhiezer wrote:
   Date: Sat, 2 Aug 2014 00:54:07 +0100
   From: Ken Moffat zarniwh...@ntlworld.com
   To: blfs-dev@lists.linuxfromscratch.org
   Subject: [blfs-dev] /etc/logrotate.conf nomail option
  
I'm just updating my build scripts.  For years I have used a simple
   script to do log rotation, so now I am going to try the logrotate
   package.  Looking at the creation of /etc/logrotate.conf we have the
   following:
  
   # Don't send mail to anybody
   nomail
  
I read that comment as logrotate should not send mail about its
   operation to anybody, which is not necessarily what I want
   (although I think I'm going to get a report from fcron).  But looking
   at an online manpage, and the link to techrepublic.com, the command
   appears to mean Do not mail old logs (which are about to be deleted)
   to anybody and that is proobably what I want.
  
Am I right that the comment is misleading, or have I misunderstood
   it ?
  
  
  
  What behaviour _do_ you want?
  
  Just confirmation that the program has run.


Here, we have e.g. (for 'dcron'):

$ cat /etc/cron.daily/logrotate
#!/bin/sh
/usr/sbin/logrotate /etc/logrotate.conf
[ $? != 0 ]  /usr/bin/logger -t logrotate ALERT - exited abnormally.
$

$ crontab -l
.
.
__cron-ts-spec__ /usr/bin/run-parts /etc/cron.daily 1 /dev/null
.
.
$


You can of course adjust the output stuff re what you want cron to mail;
e.g remove/adjust the '1 /dev/null', and have '/etc/cron.daily/logrotate'
echo something on successful finish.


  
  'nomail' means the opposite sense of the 'mail' directive (ref excerpt
  from man-page, below).
  
  
  Here, for example, we'd normally use, in /etc/logrotate.conf , as
  belts'n'braces additional backup for logfiles:
  
  mail eml_addr_userpart@eml_addr_dompart
  maillast
  
  If instead I wanted to nail-down logrotate to not send email at all for
  either of the 'mailfirst' or 'maillast' senses, then I'd use 'nomail'
  by itself.
  
  
  Note that logrotate can have nested, hierarchical definitions/contexts
  in the cfg file, with deeper-nested definitions taking precedence: so you
  can use e.g. 'nomail' globally, but override it for a sub-section.
  
  
  The mail/nomail settings for logrotate, don't affect the usual
  cron emailed reports. Although, you _could_ use logrotate's
  p{re,ost}rotate/{fir,la}staction/c directives, to mess about with such
  cron stuff if you wanted, for whatever reason.
  

  Thanks for that - very informative.

  
  Ref: As da man says:
  
  mail address
When  a  log  is  rotated  out-of-existence, it is mailed to address. If
no mail should be generated by a particular log, the nomail directive
may be used.
  
  mailfirst
When using the mail command, mail the just-rotated file, instead of the
about-to-expire file.
  
  maillast
When using the mail command, mail the about-to-expire file, instead of
the just-rotated file (this is the default).
  
  nomail
Don't mail old log files to any address.
  
  

  And it is that last line which makes me think the comment Don't
 send mail to anybody is misleading.  I'm just trying to increase
 clarity and reduce possible confusion.



_Logrotate_ itself won't initiate any 'please send mail' stuff if 'nomail'
is set (for the relevant context): but it doesn't - unless you're doing
something quite ~convoluted via the aforenoted pre/post/first/last directives
- stop e.g. a parent/calling-process such as cron from sending a usual-style
cron email reporting on the process (if logrotate has been called from cron).



hth,
akh





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

Re: [blfs-dev] [blfs-book] r13663 - branches/systemd/gnome-systemd/applications

[akhiezer]

 Date: Sun, 27 Jul 2014 16:43:23 +0100
 From: lf...@cruziero.com (akhiezer)
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Subject: Re: [blfs-dev] [blfs-book] r13663 -
  branches/systemd/gnome-systemd/applications

  Date: Sun, 27 Jul 2014 10:40:37 -0500
  From: Bruce Dubbs bruce.du...@gmail.com
  To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
  Subject: Re: [blfs-dev] [blfs-book] r13663 -
  branches/systemd/gnome-systemd/applications
 
   .
   .
   +  !ENTITY bogofilter-time  less than 0.1 SBU
   .
   .
   you add configure time there, I guess it's reasonable to use 0.1 SBU
   instead of less than.
 
  My general rule of thumb is to use 'less than' if it is 0.799 sbu or 


  s/0.799/0.0799/ ?


  less and round up to '0.1' if it's greater.  You could make a case for a 


 - or s/0.1/1/ ?


  different number though.
 
 -- Bruce
 





--
-- 
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 couple of command inconsistencies

[akhiezer]

 From: John Burrell john_burr...@hotmail.com
 To: BLFS Development List blfs-dev@lists.linuxfromscratch.org
 Date: Mon, 7 Jul 2014 15:24:46 +
 Subject: Re: [blfs-dev] A couple of command inconsistencies


  
  Yes, those points've already been made in your first post, understood,
  and addressed in the reply: IOW, you might want to use e.g.:
  
  -e 's/\(.*\)[[:blank:]]*$/\1/'
  
  or even
  
  -e 's/\(.*\)[[:blank:]]*[[:blank:]]*$/\1/'
  
  or similar, depending on details of the processing environment - e.g. you
  might need/want sed's '-r' flag also, /or change the '[[:blank:]]' to
  '[ \t]' (that first char is a single (horizontal-)space char) or to 
  '[  ]' (a single horiz-space char and a single tab-char), c.
  

 Well rather and try and deal with all possible chars after the , I've added 
 the
 blank to my script for iptables and ruby. If the editors decide to add more 
 spaces,
 or a tab or whatever after a , my script will fail and then I can try and 
 fix it.



 - but the '[[:blank:]]*' (without the quotes, obviously) deals with the
 'problem' once  for all: why would one spend the time to add just a
 blank to the sed, rather than add the regex ...  . But, it's your script,
 of course.


 No loss of life will ensue so 'suck it and see' is a good approach for this 
 problem.



(Maybe not loss of life, but perhaps loss/waste of time...  .)


rgds,
akh



 jb.

 


--
-- 
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 couple of command inconsistencies

[akhiezer]

 From: John Burrell john_burr...@hotmail.com
 To: blfs-...@linuxfromscratch.org blfs-...@linuxfromscratch.org
 Date: Sun, 6 Jul 2014 20:33:55 +
 Subject: [blfs-dev] A couple of command inconsistencies



 Dear Editors

 In the BLFS commands postlfs, 041-iptables has this line

 --enable-libipq  

 There is a space after the  which makes it difficult to do a global delete 
 on the 

 This is also true for general/251-ruby with this line:

 --docdir=/usr/share/doc/ruby-2.1.2  

 Would you kindly remove the space after the  for these two commands to make 
 them consistent with all the other commands in the xml files.
.
.



While yes, it's good to have consistency in xml source, a processing of
that source should really be 'liberal in what it accepts' as input, at
least insofar as allowing for the possibility of such spaces, surely? You
could e.g. match on a regex such as '[[:blank:]]*$' or similar (depending
on what the processing environment will accept regex-wise).


rgds,
akh





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