Revision 12166
chapter06/binutils-pass2.xml
has
Compile the package:
make
Install the package, and
workaround an issue causing
libctf.so
to link against zlib from the host distribution:
make DESTDIR=$LFS install
install -vm755 libctf/.libs/libctf.so.0.0.0 $LFS/usr/lib
On Thu, 4 Mar 2021 at 03:57, Ken Moffat via lfs-dev
wrote:
>
> My point is that you should not unpack then until you build them,
> and if you need to build them again you should remove the directory
> and unpack again.
I'm with you on that.
I also have a "clean up" stanza at the bottom of each
On Wed, 3 Mar 2021 at 01:04, Bruce Dubbs wrote:
>
>
> > FWIW, I do something akin to
> >
> > links2 -width 132 -dump -html-numbered-links 0 LFS-BOOK-10.1-NOCHUNKS.html
> > | \
> > grep Download: \
> > cut -d/ -f 3- > LFS-BOOK-10.1-SRC_PATHS.txt
> >
> > to get a list of "paths to" each
On Sat, 27 Feb 2021 at 11:27, Bruce Dubbs via lfs-dev
wrote:
>
> We are about ready to release LFS/BLFS 10.1. All tickets have been
> closed and all packages have been tested using the current instructions
> in the books.
>
> That said, there are probably issues that still need to be addressed.
On Sat, 27 Feb 2021 at 11:27, Bruce Dubbs via lfs-dev
wrote:
>
> We are about ready to release LFS/BLFS 10.1. All tickets have been
> closed and all packages have been tested using the current instructions
> in the books.
>
> That said, there are probably issues that still need to be addressed.
I appreciate there are only a few people actively using Matthias's approach
and scripts, but the effects of this one have bugged me for ages whenever
I come to install Xen from a Package User account. I have even asked about
it on the xen-devel list, but yesterday, after mentioning it again,
had
On Thu, 19 Nov 2020 at 13:22, Bruce Dubbs via lfs-dev
wrote:
>
> On 11/18/20 11:05 PM, Kevin Buckley via lfs-dev wrote:
> > On Wed, 18 Nov 2020 at 00:18, Bruce Dubbs via lfs-dev
> > wrote:
> >>
> >> I am in favor of just removing the strip section in Chapter
On Tue, 17 Nov 2020 at 17:47, Pierre Labastie via lfs-dev
wrote:
>
>
> Yes, I've seen this. It had something to do with stripping (so 1st
> question is: did you strip binaries? Old versions (don't ask the
> version, something around 2.28 IIRC) of strip do not recognize some
> R_X86_64_xxx
On Wed, 18 Nov 2020 at 00:18, Bruce Dubbs via lfs-dev
wrote:
>
> I am in favor of just removing the strip section in Chapter 7. Saving
> 90 MB is not really significant for today's HW. We say that the user
> should have at least 5 GB free, so 90 MB is less than 2% of that.
Despite having
On Tue, 17 Nov 2020 at 17:47, Pierre Labastie via lfs-dev
wrote:
>
> On Tue, 2020-11-17 at 15:45 +0800, Kevin Buckley via lfs-dev wrote:
>
> ...
> > /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/crtend.o
> > /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crtn.o
>
On Mon, 16 Nov 2020 at 14:49, Kevin Buckley wrote:
>
> Pretty sure this will be an "end-user" issue but, just in case anyone
> has seen something similar and can thus point me in the right direction,
> I have seen this twice now, and i was more careful the second time.
>
> (Note: following the
Pretty sure this will be an "end-user" issue but, just in case anyone
has seen something similar and can thus point me in the right direction,
I have seen this twice now, and i was more careful the second time.
(Note: following the Multilib Book, plus some PkgUser additons)
Get to the end of
On Fri, 13 Nov 2020 at 09:29, Kevin Buckley wrote:
>
> Hi Thomas,
>
> I believe that, as of Revision: 12059, your Zlib section in Chapter 5
> is missing the "--host=$LFS_TGT" flag
>
> Compare
>
> Prepare Zlib for compilation:
>
> ./configure
> --prefix=/usr
>
> Compile the package:
>
>
>
On Thu, 12 Nov 2020 at 22:35, Bruce Dubbs via lfs-dev
wrote:
>
> When LFS was originally developed, a single URL was deemed sufficient.
> When BLFS was started we wanted an ftp URL because LFS had an ftp
> client, but we also wanted to offer http access.
>
> Over the years, upstream has changed
Hi Thomas,
I believe that, as of Revision: 12059, your Zlib section in Chapter 5
is missing the "--host=$LFS_TGT" flag
Compare
Prepare Zlib for compilation:
./configure
--prefix=/usr
Compile the package:
with the corresponding XML from the GZip section
Prepare Gzip for
On Wed, 11 Nov 2020 at 23:53, Bruce Dubbs via lfs-dev
wrote:
>
> On 11/11/20 3:21 AM, Kevin Buckley via lfs-dev wrote:
> > I was recently trying to generate a downlaod listing of the packages I had
> > used
> > when building my Pkguser based 9.1 system, inclduing the BLFS
I was recently trying to generate a downlaod listing of the packages I had used
when building my Pkguser based 9.1 system, inclduing the BLFS components
that I'd merged into a single book.
FWIW, so as to see what I needed to download from BLFS 10.0
I noticed that in BLFS, where the package
On Wed, 7 Oct 2020 at 08:59, Kevin Buckley wrote:
> ...
> All this time, and I had assumed that LFS had extended the Schema/DTD
> so as to use certain attributes that appeared specific to LFS.
>
> Cheers for pointing that out: I'll "make other plans" !
>
> Kevin
Since then, Bruce has written
>
On Tue, 6 Oct 2020 at 20:03, Pierre Labastie via lfs-dev
wrote:
>
> >
> > Where should such a declaration go?
>
> The attribute has to be declared in the dtd (document type definition),
> where anything pertaining to the xml document is declared (not only
> attributes, but also tags and their
i was experimenting with making use of an extra attribute in the
XML source tags, akin to the vanilla book's 'sysv' or 'systemd'
for the "revision" attribute,, or to Thomas's Multilib arch attribute
('ml_32', 'ml_x32' or 'ml_all').
When i come to render my source, having added an extra
On Sun, 13 Sep 2020 at 14:59, Bruce Dubbs via lfs-dev
wrote:
>
> On 9/12/20 9:35 PM, Kevin Buckley via lfs-dev wrote:
> > One of those things you probably only notice if you are doing
> > a PkgUser type build, as a root build will simply see the file
> > overwri
One of those things you probably only notice if you are doing
a PkgUser type build, as a root build will simply see the file
overwritten without any warning, but wanted to point out that
Chapter 8's TCL installs this manpage
/usr/share/man/man3/Thread.3
and then Perl will also want to install
On Wed, 19 Aug 2020 at 20:39, Roger via lfs-dev
wrote:
> >
> >Meant to follow up on this one by asking if the TCL docs
> >are now required, or are still optional ?
>
> Optional, in that not having the docs hasn't caused any problem
> so far. Currently doing a mixed partition build with updated
>
On Sat, 15 Aug 2020 at 16:31, Roger via lfs-dev
wrote:
>
> The second paragraph begins "First, unpack the documentation..."
>
> This threw me until I remembered that with every package we
> start by unpacking the source code and cd'ing into it. Perhaps
> it would be as well to stop any possible
chapter04/settingenviron.xml, Line 35
- shell, which does not read, and execute, the conten of
/etc/profile or
+ shell, which does not read, and execute, the content of
/etc/profile or
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe:
On Fri, 14 Aug 2020 at 11:48, Bruce Dubbs via lfs-dev
wrote:
> >
> > I might have missed this in the email thread but why does the change,
> > which I've seen at r12020, hard-code the version number and not use
> > the entity ?
> >
> > ...
.34 later versions?
>
> Probably an oversight. I'll fix
>
> I've also install git using a sed to put the modules into
> /usr/lib/perl5/5.32/site_perl..
>
> All of perl itself is in /usr/lib/perl5/5.32/core_perl, all the
> extra modules are in /usr/lib/perl5/5.32/site_perl).
>
> I think we ought to change the book to do this, but I'm not sure
> everyone
On Sun, 2 Aug 2020 at 04:32, Timothy Russo via lfs-dev
wrote:
>
> With efi being more the standard now, I'd like to ask if we could default
> grub to supporting uefi instead of having to use the uefi hint.
>
> Or at last maybe formalize it and make it an option, where you can pick
> bios/mbr or
As some of you will be aware from other threads, I have been
spending way too much time looking at the way that the LFS
book goes about creating its directory hierarchy, but for those
of you who find these things interesting, here's some more.
Here's what the current (r12002) book does, as
On Mon, 27 Jul 2020 at 20:57, Pierre Labastie via lfs-dev
wrote:
>
> The LFS root directory ($LFS), is supposed to be owned by the root
> user, and to have permissions rwxr-xr-x, so that user lfs cannot create
> anything in it. That's the reason why we create the hierarchy as root
> and chown the
On Mon, 27 Jul 2020 at 01:19, Bruce Dubbs via lfs-dev
wrote:
>
> I haven't checked, but I think you may be taking the word 'minimal' too
> literally. Perhaps we should just change the description to:
>
> Creating a Limited directory layout in LFS filesystem
>
> Whether or not all the directories
At present, the LFS Book, at Revision r12002, says
4.2. Creating the Minimal directory layout in LFS filesystem
The first task performed in the LFS partition is to create a minimal
directory hierarchy so that programs compiled in Chapter 6 may be
installed in their final location. This is needed
In LFS 9.1 Multilib, the Glibc x32 test Was
Redo test for x32-ABI:
echo 'int main(){}' > dummy.c
$LFS_TGT-gcc -mx32 dummy.c
readelf -l a.out | grep ': /tools'
Output should be like:
[Requesting program interpreter: /tools/libx32/ld-linux-x32.so.2]
Note the libx32 there.
Revision r12033
Well I assume it does, given that the rendered version
of r12003 I have just produced says
8.48.2. Installation of Libffi - 32bit
but then
8.48.3. Installation of Libtool - x32bit
Actually, no, it's not the wrong entity, the section titles have the Package
names written in directly, so
On Wed, 22 Jul 2020 at 17:07, John Burrell via lfs-dev
wrote:
>
> I'm experimenting with installing chapters 5 and 6 as a package user.
> Can I safely delete the directory $LFS/usr/share/locale for each
> package that is reinstalled in Chapter 8?
> I assume I can, but thought I should ask in case
Noticed this in r11999 chapter07/creatingdirs.xml
...
mkdir -pv /usr/{,local/}share/man/man{1..8}
install -dv -m 1777 /tmp /var/tmp
install -dv -m 0750 /root
mkdir -v /var/{log,mail,spool}
ln -sv /run /var/run
ln -sv /run/lock /var/lock
mkdir -pv /var/{opt,cache,lib/{color,misc,locate},local}
Haven't got there in a build yet, as I'm looking at where to build
Shadow, so as to get an su. but have noticed that there's an explicit
"testers" user being created now, so as to run some Chapter 8 tests
that should not be run as root.
Given that, when starting from a older LFS installation and
On Mon, 20 Jul 2020 at 11:06, Xi Ruoyao via lfs-dev
wrote:
>
> On 2020-07-19 14:07 -0500, Timothy Russo via lfs-dev wrote:
> > ...
> > In chapter 7 for Util-linux, the default configure options has --disable-su.
> > I still couldn't get it to work after rebuilding util-linux with su enabled,
> >
On Tue, 14 Jul 2020 at 00:57, Daniel Schepler via lfs-dev
wrote:
>
> On Mon, Jul 13, 2020 at 7:56 AM Bruce Dubbs via lfs-dev
>
> > Sure, that could be done, but why? There are a lot of ways to
> > accomplish the same task, but I don't see the advantage of one way over
> > the other.
>
> Well, it
At present, in Chapter 4, the host system's root user creates a
minimal directory hierarchy, then creates the lfs user and then
chown's the minimal directory hierarchy so as to be owned by th e
lfs user, and finally does an su to the lfs user.
I was thinking that the order could be altered so
On Thu, 18 Jun 2020 at 15:16, Pierre Labastie via lfs-dev
wrote:
>
> Why "environment"? I'm not sure here.
I wasn't sure either.
Was probably taking my cue from "7.4. Entering the Chroot Environment "
> We really save the tools.
> And what we "clean up" is not really an environment (rather we
On Wed, 17 Jun 2020 at 22:01, Pierre Labastie via lfs-dev
wrote:
>
> Please tell us what you think of:
> http://www.linuxfromscratch.org/~pierre/lfs-svn/index.html
> (I've not bee able to remove the latin numbering in the "Preliminary
> material")
Seems a much better separation of the
On Wed, 17 Jun 2020 at 21:48, Pierre Labastie via lfs-dev
wrote:
>
> > Can anyone think of any reasons why I would not be able to use the su
> > from Util-linux, until such time as Chapter 8's (nearly typed Chapter
> > 6's
> > there) Shadow get's built?
>
> Actually, We have looked at it (you may
With the recent reorganisation comes the addition of Util-linux into the
chroot environment.
The instructions there follow the standard LFS practice of disabling various
utilities from Util-linux , including the su utility, which gets provided by the
Shadow package.
As someone who builds LFS
On Mon, 15 Jun 2020 at 22:51, Joel Bion via lfs-dev
wrote:
>
> ...
> And with ARM, the interesting thing about it is that at this point there
> isn’t much interesting about it.
Apologies, this is going a bit off-topic but I couldn't let that one
go: it's had me
chuckling for over half-an-hour
On Mon, 15 Jun 2020 at 20:01, Bruce Dubbs via lfs-dev
wrote:
>
> > I'd like to see the "cross-compiling 101" sections, so
> >
> > Introduction
> > Toolchain Technical Notes
> > General Compilation Instructions
> >
> > in "chapter" 5, separated out from the package build sections there.
>
> We can
On Mon, 15 Jun 2020 at 18:34, Pierre Labastie via lfs-dev
wrote:
>
> OTOH, personally, I like meson/ninja. I wish it were used more often.
> They have nothing to do with systemd.
For some reason, I had thought that there was a package in the SysD
build that was "so new" that it had never had an
On Sat, 13 Jun 2020 at 20:46, Bruce Dubbs via lfs-dev
wrote:
>
> In the last few weeks, the LFS editors have been working on a major
> overhaul of LFS. This work can be reviewed at
>
> http://www.linuxfromscratch.org/~bdubbs/cross2-lfs-book/
>
Was there an SVN reference (branch) to pull the
On Sat, 13 Jun 2020 at 23:02, Saul Tigh via lfs-dev
wrote:
>
> Well, There is PiLFS (intestinate.com/pilfs) which is LFS on Raspberry Pi
> which in turn is an ARM architecture. The instructions are pretty similar to
> standard LFS. Kernel and bootloader instructions are a bit different though.
On Wed, 15 Apr 2020 at 06:09, Uwe Düffert via lfs-dev
wrote:
>
> ...
> about a certain versioned/timestamped archive matches the checksum of
> presumably the same archive fetched from any other mirror. After all,
> checksumming is about increasing trust and not about (unnecessarily)
> sowing
On Tue, 31 Mar 2020 at 04:06, Bruce Dubbs via lfs-dev
wrote:
>
> I would like to propose keeping the kernel at the most recent long term
> support (LTS) version for the book. Users can, of course, use whatever
> version they want.
>
> What do you think?
>
>-- Bruee
A slightly different take
Just wanted to say that I have managed to get my "Package User
approach" system to the point where Xen builds and so have refreshed
the public copy of the book here:
http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html
Hoping it might be of interest to some folk,
Kevin
--
On Sun, 29 Mar 2020 at 14:07, Kevin Buckley wrote:
>
> On Fri, 27 Mar 2020 at 23:52, Bruce Dubbs via lfs-dev
> wrote:
> > ...
> > The patch applies, but there are some issues:
>
> Not sure where the "extra" paragraph snuck in, so as to
> screw things over like that.
>
> Presume a cut and paste
On Sat, 28 Mar 2020 at 00:02, Douglas R. Reno via lfs-dev
wrote:
>
> I only have one small nitpick on this one (I've only read it, it's best
> for Bruce to apply it):
> ...
> > +a robust general-purpose scripting language. The
> > Expect package
> > +written in the Tcl language.
>
>
On Fri, 27 Mar 2020 at 23:52, Bruce Dubbs via lfs-dev
wrote:
>
> On 3/27/20 7:31 AM, Kevin Buckley via lfs-dev wrote:
> > This patch tunrs the paragraph explanations of the contents of the
> > .bashrc file into a variable list, thereby highlighting the individual
> > comma
This patch tunrs the paragraph explanations of the contents of the
.bashrc file into a variable list, thereby highlighting the individual
commands before explaing them.
This appears to be a more standard way to explain command lines across
the Books.
All it does is move the existing paragraph
This patch provides a fuller description of three, Chapter 5 only,
packages, Tcl, DejaGnu and Expect, so that the reader gets a better
feel for what the packages are.
The fuller descriptions are taken from, or are aligned with, the
"Introduction to ..." stanzas from the BLFS instructions for the
On Mon, 23 Mar 2020 at 16:59, Pierre Labastie via lfs-dev
wrote:
>
> I think blfs adds a level of details so that users can decide whether they
> want to build the package or not. In LFS, they have to build the package
> anyway.
>
> Look at the descriptions for Python too.
They DO appear to be
I noticed that, in 7.5. General Network Configuration,
we explcitly
cd /etc/sysconfig/
cat > ifconfig.eth0 << "EOF"
but then go on to create the remaining "here documents" by using
the full paths to the files
cat > /etc/resolv.conf << "EOF"
echo "" > /etc/hostname
cat > /etc/hosts << "EOF"
Because I decided to build the three packges from LFS's Chapter 5
that don't get built in Chapter 6, despite the builder having had to
download the sources for Chapter 5, I noticed:
5.11. Tcl-8.6.10
The Tcl package contains the Tool Command Language.
5.12. Expect-5.45.4
The Expect package
More of a Multilib question but I'm interested in the
general principle here.
The very last pair of commands for Chapter 6's GCC section are
mkdir -pv /usr/share/gdb/auto-load/usr/lib
mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib
but does GDB differentiate between "lib" architectures
I note, because my PkgUser Book has explicit sections for
unpacking the sources that the vanilla book doesn't, that,
in Chapter 5 GGC Pass2, the order of actions prior to the
creation of the build directory is:
Unpack the required external packages
Change the location of GCC's default dynamic
On Thu, 12 Mar 2020 at 16:45, Pierre Labastie via lfs-dev
wrote:
>
> Sorry, looks like there is something "magic" in glibc source, and that it is
> better to use "MAKEINFO=:". See manual/Makefile in glibc source tree:
> -
> ifneq ($(strip $(MAKEINFO)),:)
> info: $(objpfx)libc.info
> endif
>
On Tue, 10 Mar 2020 at 17:59, Pierre Labastie via lfs-dev
wrote:
> ...
> what if you tried passing "MAKEINFO=/bin/true" to configure?
>
> Pierre
Gets you very close.
make MAKEINFO=/bin/true install
then fails at the point where it tries to access
manual/glibc.info*
as the target for a copy
As I usually build against Thomas Trepl's Multilib book, I've realised
that I end up building the Glibc Info pages SIX times, three in Chapter 5
and three in Chapter 6.
I've been looking at the Glibc Makefile hierarchy but couldn't see an
obvious place at which to prevent the Info pages being
The Chapter 6 Python configure instructions have a
--with-system-expat
option, suggesting Expat should have Python in its
Must be installed before:
list.
Libffi provides a matching example.
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
On Mon, 2 Mar 2020 at 21:55, Xi Ruoyao via lfs-dev
wrote:
>
> On 2020-03-02 10:11 +0100, Pierre Labastie via lfs-dev wrote:
> > Presently, this entity is 9.0, and has been last changed in July 2019. The
> > questions are:
> > - what's its use?
> > - if it is used, shouldn't it be changed to 9.2?
Only just noticed this
chapter03/packages.xml
has
The version of vim changes daily. The get the latest version, go to
https://github.com/vim/vim/releases;>
https://github.com/vim/vim/releases.
Should read
On Sun, 1 Mar 2020 at 01:16, Pierre Labastie via lfs-dev
wrote:
>
> Le 29/02/2020 à 16:09, Bruce Dubbs via lfs-dev a écrit :
> > On 2/29/20 4:57 AM, Pierre Labastie via lfs-dev wrote:
> >
> >>>
> >>> Assuming there's no reason why the noChunks book shouldn't
> >>> be created from the xmllint-ed
I do hope I have this right: I don't think this one is down
to my rendering environment.
As I think of it, there are three files created in RENDERTMP
lfs-html2.xml
lfs-full.xml
lfs-html.xml
resulting from this pipeline (simplfied) in the Makefile
xsltproc index.xml --output
Can anything think of a reason why, when I render the Book sources
locally, some entities don't render ?
I've recently noticed this with the ssh-askpass section in the BLFS book
but have seen similar with the LFS sources too, when adding to them.
In the source the title fo the section is
I'll spare you the details of how I cam to notice this but i was just
applying some local patches to the most recent trunk Rev 11745
and realised that
Chapter 5 still has these two XML files in the source directory
gmp.xml
mpfr.xml
even though they are no longer rendered, nor referred to, in
On Sun, 19 Jan 2020 at 14:18, DJ Lucas via lfs-dev
wrote:
>
> On 1/18/2020 9:21 PM, Kevin Buckley via lfs-dev wrote:
>
> > On the back of trying to build Xen 4.12.2 on an LFS system, I've hit
> > an issue whereby the Xen M4 python_devel module fails but, even when I
> &
On Mon, 20 Jan 2020 at 05:28, Akira Urushibata via lfs-dev
wrote:
>
> I plan to distribute a short questionnaire to attendants.
> The following are the questions that I would like to ask.
> If anyone subscribed to the list has suggestions, I'd like to hear.
> I'll post a digest of the answers
On Sun, 19 Jan 2020 at 14:18, DJ Lucas via lfs-dev
wrote:
>
>
> On 1/18/2020 9:21 PM, Kevin Buckley via lfs-dev wrote:
> > On the back of trying to build Xen 4.12.2 on an LFS system, I've hit
> > an issue whereby the Xen M4 python_devel module fails but, even when I
> &
On the back of trying to build Xen 4.12.2 on an LFS system, I've
hit an issue whereby the Xen M4 python_devel module fails but,
even when I fix that, Python3 seems to report the "wrong" info.
I am asking similar questions, albeit with more of a Xen focus,
on the Xen developers list.
The first
On Thu, 9 Jan 2020 at 10:06, Douglas R. Reno via lfs-dev
wrote:
>
>
> On 1/8/20 3:59 PM, Bruce Dubbs via lfs-dev wrote:
> > I've been seeing some references to zstd lately. AFAIK, the only use
> > of it right now in LFS/BLFS is for some tests, but I think it will
> > become more common in the
On Wed, 9 Oct 2019 at 00:07, Bruce Dubbs via lfs-dev
wrote:
>
> Is what we have really that confusing?
In that few people ever read the Dependencies Appendix then, probably not.
I did: I saw some LFS packages listed as "Optional dependencies".
Then Ken said "no packages in LFS are optional"
On Tue, 8 Oct 2019 at 10:18, Ken Moffat via lfs-dev
wrote:
>
> On Tue, Oct 08, 2019 at 09:32:17AM +0800, Kevin Buckley via lfs-dev wrote:
> >
> > To that end though, a couple of other, related, RFCs
> >
> > 1)
> > Within the LFS Book's "Optional de
On Mon, 7 Oct 2019 at 23:48, Bruce Dubbs via lfs-dev
wrote:
>
>
> I think the above is way too much. Upon thinking about it, expanding
> the page in section "9.4. What Now?" should be sufficient.
>
> Generally, packages can be rebuilt with LFS instructions after the
> additional dependencies are
On Sat, 5 Oct 2019 at 19:25, Bruce Dubbs via lfs-dev
wrote:
>
> ...
> > This might be yet another package that could be in a "Reinstalling
> > LFS packages for a BLFS system" section of the BLFS Book, along
> > with Shadow.
>
> Perhaps. You can probably add grep after pcre to that list. Would
In the Chapter 6 Python XML source,
1) there's a block of commands rendered as
chmod -v 755 /usr/lib/libpython3.7m.so
chmod -v 755 /usr/lib/libpython3.so
ln -sfv pip3.7 /usr/bin/pip3
which come from the following XML
chmod -v 755 /usr/lib/libpythonm.so
chmod -v 755 /usr/lib/libpython3.so
ln
On Sat, 21 Sep 2019 at 07:46, DJ Lucas via lfs-dev
wrote:
>
> In the book, we currently have the text "Install the modules, if the kernel
> configuration uses them:" - this is incorrect. All kernels use them, whether
> they are built-in or not, and this step is required to populate
>
On Wed, 11 Sep 2019 at 06:06, Ken Moffat via lfs-dev
wrote:
> ...
> > Would appear then, that someone has been updating the chapter06/db.xml file
> > (or perhaps just the entity strings?) as newer versions of B-DB came out
> > but
> > at some point also removed what would have been the entity
On Mon, 9 Sep 2019 at 01:19, Bruce Dubbs via lfs-dev
wrote:
> We are using the public version of gdbm, not the proprietary Oracle
> version. We use gdbm.xml in LFS and not the db.xml file.
>
> See http://wiki.linuxfromscratch.org/blfs/ticket/10989#ticket
>
> The only reason that db.xml is there
OK, so I appreciate that the
chapter06db.xml
source file isn't pulled into the Book in the "official" rendering,
however, I have noticed that if you do add it in, the rendering
of the Book fails because the entity
doesn't exist.
FWIW. it is used here
SVN/LFS-9.0$ grep -r db-fixes-patch *
On Tue, 3 Sep 2019 at 14:03, Bruce Dubbs via lfs-dev
wrote:
> > Couple of small "tidy-ups"
> >
> > On the download page of the website, there's the text
> >
> >> Other versions of the source may be similarly downloaded by changing the
> >> URL above. For example, use
> >>
On Sun, 25 Aug 2019 at 21:24, Jean-Marc Pigeon via lfs-dev
wrote:
> Lets be blunt here, ;)
Why?
I think we are expressing the same sentiment, although I'd
add a couple of observations to your points, if I may.
> Are you telling to us?, you blindly follow all book directives and
> you were
On Mon, 2 Sep 2019 at 02:38, Bruce Dubbs via lfs-dev
wrote:
>
> The Linux From Scratch community is pleased to announce the release of
> LFS Version 9.0, LFS Version 9.0 (systemd), BLFS Version 9.0, and BLFS
> Version 9.0 (systemd).
Couple of small "tidy-ups"
On the download page of the
On Fri, 23 Aug 2019 at 09:22, Jean-Marc Pigeon via lfs-dev
wrote:
>
> Bonjour,
>
> English is not my native language, I'll try my best
> to give|share some ideas about LFS to Akira and you(list),
> so please bear with me.
>
On 08/22/2019 10:12 AM, Bruce Dubbs via lfs-dev wrote:
> > On 8/22/19
I noticed
Kmod
Installation depends on: Bash, Binutils, Bison, Coreutils, Flex, GCC,
Gettext, Glibc, Gzip, Make, Sed, Xz-Utils, and Zlib
Test suite depends on: No test suite available
Must be installed before: Eudev
Optional dependencies: None
but
Pkg-config
Installation depends on: Bash,
On Sun, 11 Aug 2019 at 16:17, Kevin Buckley wrote:
>
> Then again, was it in the kernel when the last "Hardened LFS" versio
> was produced, back in 2011
>
> http://www.linuxfromscratch.org/hlfs/view/development/
To answer my own question, no, it wasn't, given that the
Linux Kernel Driver
On Fri, 9 Aug 2019 at 20:55, Riccardo Corsi via lfs-dev
wrote:
>
> Hello, I have a question about a 5.2.7 kernel parameter.
> Initialize kernel stack variables at function entry: (1...4)
>
> This is the related part of config kernel file:
>
> # Memory initialization
> #
> # CONFIG_INIT_STACK_NONE
On Wed, 5 Jun 2019 at 02:54, Bruce Dubbs via lfs-dev
wrote:
>
> I am thinking about moving pcre from BLFS to LFS. The latest less now
> supports pcre and pcre2 and grep also supports pcre. It should be
> pretty stand alone as the only dependency is (optionally) valgrind.
>
> If added, I would
On Wed, 22 May 2019 at 17:38, Kevin Buckley wrote:
> be aware that I hope to have a copy of the "book I work from" visible on the
> web
> "real soon now"*, although it is spun out of a local SVN repo, as
> opposed to anything
> out on the web, let alone anything hosted by LFS, so it'll just be
On Fri, 3 May 2019 at 00:21, James B via lfs-dev
wrote:
> I've been lurking in this mailing list for quite a while now and seen some
> developments going on.
>
> Specifically, I have seen Thomas' multilib work being discussed and I think
> Thomas recently put
> his work into somewhere in LFS
On Sun, 21 Apr 2019 at 12:08, Xi Ruoyao via lfs-dev
wrote:
> > by virtue of pointing to the /lib/udev, which is arch-specific,
>
> It's not. /lib/udev only contains udev scripts and some executable helpers
> for
> udevd. There are no libraries in it.
>
> We can not have two udevd instances
On Sat, 20 Apr 2019 at 23:49, Bruce Dubbs via lfs-dev
wrote:
> >> I have to say that,whilst I have followed the FHS over the years,
> >> I've never quite worked out why /usr/lib/pkgconfig seems to have
> >> gained favour, as PkgConfig files are not "libs" and can provide
> >> non-lib info, as
Because I have been performing a PkgUser build, I have
noticed, when coming to install Xen, that Eudev appears
to install its two PkgConfig files in seperate locations.
pkg xen:xen-master> ls -l /usr/lib/pkgconfig/
-rw-r--r-- 1 eudev eudev 503 Mar 24 11:29 libudev.pc
pkg xen:xen-master> ls -l
On Tue, 16 Apr 2019 at 15:07, Pierre Labastie via lfs-dev
wrote:
>
> I think linking python->python3 is a bit premature. We should do that when
> upstream python does, or most packages expect it, but not only one. ATM, a lot
> of packages, which can accept P3, can still accept python2.7, and
1 - 100 of 114 matches
Mail list logo
