On 2021-04-15 22:28 +0800, Xi Ruoyao wrote:
>
> It's caused by changes in Linux 5.11.14 (API headers). I'll raise a PR in
> systemd.
It's already fixed in systemd git repo.
> The kernel version in the book (5.11.10) won't trigger this.
--
Xi Ruoyao
School of Aerospace Science an
ild stopped: subcommand failed.
>
> Out of interest, I tried version 248 but that produced the same result.
It's caused by changes in Linux 5.11.14 (API headers). I'll raise a PR in
systemd.
The kernel version in the book (5.11.10) won't trigger this.
--
Xi Ruoyao
School of Aerospace S
On 2021-02-26 22:31 -0600, Bruce Dubbs via lfs-dev wrote:
> On 2/26/21 10:13 PM, Xi Ruoyao via lfs-dev wrote:
> > On 2021-02-26 21:26 -0600, Bruce Dubbs via lfs-dev wrote:
> > > We are about ready to release LFS/BLFS 10.1. All tickets have been
> > > closed and all pack
jor changes probably will need
> to be delayed until the next cycle. However, minor changes can be done
> now.
>
> -- Bruce
In section 11.3 (rebooting), it it better to replace those umount commands with
a simple "umount -R $LFS"?
--
Xi Ruoyao
School of Aerospace
On 2021-01-27 15:22 -0600, Brendan L via lfs-dev wrote:
> For the systemd book util-linux installs uuidd.service and
> uuidd.socket. The service file specifies a user and group of uuidd.
> Should that user and group be added to the book?
Added in r12103. Thanks for report.
--
Xi Ruoya
ges when I was sleepy :(.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
ally different. "source code (tar.gz)" is automatically
created by GitHub so there will be no generated files (which should not be
version controled) in it.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http:/
so I'll note that users of the stable book can download everything
> with a single wget command in Chapter 3.1 or one tarball from
> ftp://ftp.osuosl.org/pub/lfs/lfs-packages/ or its mirrors.
Adding a link in package page will make it easier when some LFS package need to
be upgraded
dvantage of
the new approach is that we won't need to track and develop workaround for those
faulty paths anymore.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 2020-09-04 09:30 +0200，Pierre Labastie via lfs-dev wrote:
> On Fri, 2020-09-04 at 00:47 -0500, Bruce Dubbs via lfs-dev wrote:
> > On 9/3/20 10:53 PM, Xi Ruoyao via lfs-dev wrote:
> > > Now we are using --prefix=/usr in "Ch. 6 Cross Compiling Temporary
> >
de some command line options.
"/usr/etc" should not exist on any FHS-compilant distro, but
"/usr/share/config.site" exists on many distros.
My suggestion is to add `export CONFIG_SITE=/dev/null` in /home/lfs/.bashrc. It
would override the default config.site search rule.
--
On 2020-09-03 12:18 +0100, Roger via lfs-dev wrote:
> LFS-10.0 At the end of chapter 8 user tester is deleted.
> Shouldn't group tester also be deleted?
It's deleted by userdel.
See the description of `USERGROUPS_ENAB` in /etc/login.defs.
--
Xi Ruoyao
School of Aerospace Science and Tech
eally good. I'll also mention that for inetutils, where
> > libls _may_ fail, it failed on the O2 build and one of the O3
> > builds, but not on the other O3 build.
>
> We are still working on tags fo rBLFS, so I opened a ticket on LFS so we
> don't forget.
>
>
On 2020-08-19 23:10 +0800，Xi Ruoyao via lfs-dev:
> On 2020-08-19 10:25 -0400, Julien Lepiller via lfs-dev wrote:
> > In chapter 3, I found "optain" instead of obtain. In chapter 4 there are at
> > least two "envirnment", missing a o. I tried to fix it myself as I
ion denied to write something in
> /srv/svn.
I can see only one "envirnment".
I'll try to create something like a enchant dictionary for LFS.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.
LFS packages. If there is no security issue it's
better to update the patches in 10.1. But if there is some security issue we'll
have to do it now, release LFS-10.0-rc2, and redo all BLFS packages.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo
nis
> readline zlib
> To find the necessary bits, look in setup.py in detect_modules() for the
> module's name.
Chapter 7 is temporary so we don't care about those extra modules.
--
Xi Ruoyao
School
on of macro
> ‘assert_cc’
>161 | assert_cc(IPPROTO_MAX-1 <= UINT8_MAX);
>| ^
> [530/1741] Compiling C object
> src/network/libnetworkd-core.a.p/netdev_macsec.c.o
> ninja: build stopped: subcommand failed.
Perhaps the recent change just broke systemd-245. I used systemd-246 in my
build and there was no problem.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 2020-08-05 22:03 +0100, Ken Moffat via lfs-dev wrote:
> On Thu, Aug 06, 2020 at 03:57:29AM +0800, Xi Ruoyao via lfs-dev wrote:
> > On 2020-08-05 19:53 +0100, Ken Moffat via lfs-dev wrote:
> > > (I've changed the subject and cut down some of hte obsolete detail)
> > >
chapter 8.
>
> I'll start a build WITHOUT Dprivlib later.
Is there any rationale to change the default Perl module directory, besides to
remove the Perl patch level from path?
I suggest three alternatives:
(1) -Dprivlib=/usr/share/perl5/5.32/core_perl
It's like the status quo, but versioned.
On 2020-08-05 14:37 +0800, Kevin Buckley via lfs-dev wrote:
> On Mon, 3 Aug 2020 at 00:46, Xi Ruoyao via lfs-dev
> wrote:
> > It's nearly impossible. If we do that we'll have to introduce at least five
> > new
> > packages: dosfstools, popt, pciutils, efivar, a
UEFI-aware Grub could be part of BLFS though?
[Cross post to blfs-dev]
I personally agree. Let's hear Bruce's opinion.
If he agree I'll do it for BLFS 10.1, and reference it in LFS 10.1. 10.0 is too
hurry, I think. For 10.0 I'll update the hint again.
--
Xi Ruoyao
School of Aerospace Science and
On 2020-08-02 22:19 +0100, Ken Moffat via lfs-dev wrote:
> On Sun, Aug 02, 2020 at 10:07:23PM +0200, Alexey Orishko via lfs-dev wrote:
> > On Sun, Aug 2, 2020 at 6:46 PM Xi Ruoyao via lfs-dev
> > wrote:
> >
> > > > Since majority of new laptops have
2. We can't just squeeze
everything into LFS because it's needed in some situation. I can assure that
wpa-supplicant and make-ca are more widely used than efi-grub. But we don't
move them into LFS.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
g able to run commands I usually run, of course).
Glibc-2.32 will be released on Aug 1st. I suggest to wait for it since anyway
we'll have to rebuild everything for it.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromsc
gt; why that wasn't working.
Util-linux is irrelevent. su should be provided by Shadow installed in chapter
8.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe
On 2020-07-11 09:54 -0500, Bruce Dubbs via lfs-dev wrote:
> On 7/11/20 7:38 AM, Xi Ruoyao via lfs-dev wrote:
> > On 2020-07-11 11:28 +, John Frankish via lfs-dev wrote:
> > > A couple of errors found:
> > >
> > > Chapter 6. Cross Compiling
/mnt/lfs/tools/bin/x86_64-lfs-linux-gnu-pkg-config
> Also, but probably out of scope,
>
> Chapter 5. Compiling a Cross-Toolchain
> 5.5. Glibc-2.31
>
> Fails for arm (RPi) with a long double error fixed with an upstream patch:
>
> https://sourceware.org/pipermail/glibc-cvs
as returned.
>
> Interestingly, wikipedia suggests that the Netherlands uses a dot
> '.' as the separator https://en.wikipedia.org/wiki/Decimal_separator
> (in Examples of use, the entry for 1.234.567,89) and
> https://www.freeformatter.com/netherlands-standar
On 2020-06-21 14:24 +0200，Pierre Labastie via lfs-dev wrote:
> On Sun, 2020-06-21 at 14:18 +0800, Xi Ruoyao via lfs-dev wrote:
> > 在 2020-06-21星期日的 14:14 +0800，Xi Ruoyao via lfs-dev写道：
> > > > "As said above, the standard C++ library is compiled next,
> > > >
On 2020-06-21 07:29 -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/21/20 5:33 AM, Xi Ruoyao via lfs-dev wrote:
> > On 2020-06-21 18:22 +0800, Xi Ruoyao via lfs-dev wrote:
> > > On 2020-06-21 05:16 -0500, Bruce Dubbs via lfs-dev wrote:
> > > > On 6/21/20 12:57 A
On 2020-06-21 18:22 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-06-21 05:16 -0500, Bruce Dubbs via lfs-dev wrote:
> > On 6/21/20 12:57 AM, Xi Ruoyao via lfs-dev wrote:
> > > On 2020-06-21 13:24 +0800, Xi Ruoyao via lfs-dev wrote:
> > > > On 2020-06-20 21:24 -0500,
On 2020-06-21 05:16 -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/21/20 12:57 AM, Xi Ruoyao via lfs-dev wrote:
> > On 2020-06-21 13:24 +0800, Xi Ruoyao via lfs-dev wrote:
> > > On 2020-06-20 21:24 -0500, Bruce Dubbs via lfs-dev wrote:
> > > > On 6/20/20 8:30 PM, Bruce
在 2020-06-21星期日的 14:14 +0800，Xi Ruoyao via lfs-dev写道：
> > "As said above, the standard C++ library is compiled next, followed in > "
> > "linkend=\"chapter-temporary-tools\"/> by all the programs that need "
> > "themselv
have the programs land into the LFS "
> "filesystem."
"Followed in chapter-temporary-tools" means libstdc++ pass 2, but in pass 2
DESTDIR is not installed. IMO it should be chapter-cross-tools and this
libstdc++ means pass 1.
--
Xi Ruoyao
School of Aerospace Science a
On 2020-06-21 13:24 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-06-20 21:24 -0500, Bruce Dubbs via lfs-dev wrote:
> > On 6/20/20 8:30 PM, Bruce Dubbs wrote:
> > > On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote:
> > > > On 2020-06-20 16:58 -0500, Bruce Dubbs via lf
On 2020-06-20 21:24 -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/20/20 8:30 PM, Bruce Dubbs wrote:
> > On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote:
> > > On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote:
> > > > On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev w
On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote:
> > The discussion with Frans de Boer in lfs-support shown that the environment
> > variables from host can catch us completely off guard. Though in his case
> > the
&
LFS_TGT PATH
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
cations of executed binariesfor this
> reason, hashing is switched off by passing the +h
> option.
But since the final version is simply overwriting the temporary tools *at the
same location*, I think it's not necessary to turn off bash hash in chroot.
Not tested yet.
--
Xi Ruoyao
Schoo
> probably a mistaken assumption. Anyway, now I don't have any
> > failures in acl.
>
> Not run either
>
> > util-linux-2.35.2
> > -
> >
> > I have to admit that this is my first build with this version, I'd
> >
Should stage 2 be "A B C"? Without a compiler targeting C we can't build ccC,
which should runn on C.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See
e's the pity!)
We can throw a note there in SysV book, just like the note in Vim page (Vim is
neither strictly "required", considering the dependencies).
> Then again, I could make the same claim for Intltool and a
> couple of other packages related to it.
>
> Looking f
ast VERIFY is commented out or changed to !=, then all the
> time_get failures go away.
It's GCC PR71367:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
ors we'll need some CI system. When we get an
update we just push it into a "testing" branch and let CI run a ALFS build. When
CI reports OK we merge the branch.
But for ARM we don't even have a hardware :(. Is there any ARM hardware
recommended for LFS development? (Should
/usr/lib
Sorry for forgot it. Done at r11880.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 2020-05-15 15:09 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-11 23:05 +0800, Xi Ruoyao via lfs-dev wrote:
> > On 2020-05-11 09:19 -0500, Bruce Dubbs via lfs-dev wrote:
> > > On 5/11/20 8:23 AM, Pierre Labastie via lfs-dev wrote:
> > > > On Mon, 2020-05-11 at
On 2020-05-16 04:37 +0300, Firas Khalil Khana via lfs-dev wrote:
> On Sat, May 16, 2020 at 4:19 AM Xi Ruoyao via lfs-dev
> wrote:
> > On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote:
> > > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev
> &g
ary produced in
> Chapter 5 (due to the modification of the GCC sources) will thus
> remain valid inside chroot, but wouldn't it be better to spare the
> host system?
Now we know it works well. And we know there is no other packages using /tools
(we've discussed this in lfs-dev long times ago). /tools is a simple symlink in
host so it's easy to remove.
> Also I apologize for the error in the name of this message as it's
> supposed to be /tools and not /toolchain.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 2020-05-11 23:05 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-11 09:19 -0500, Bruce Dubbs via lfs-dev wrote:
> > On 5/11/20 8:23 AM, Pierre Labastie via lfs-dev wrote:
> > > On Mon, 2020-05-11 at 19:51 +0800, Xi Ruoyao via lfs-dev wrote:
> > > > I just redon
have had to make changes.
>
> Also as new package releases address gcc10, we can probably remove a lot
> of the CFLAGS entries that we've been making.
I don't like -fcommon. It's actually changing C semantics. The correct thing
to do is to fix the code (like what we do for gdbm in LFS
On 2020-05-11 09:19 -0500, Bruce Dubbs via lfs-dev wrote:
> On 5/11/20 8:23 AM, Pierre Labastie via lfs-dev wrote:
> > On Mon, 2020-05-11 at 19:51 +0800, Xi Ruoyao via lfs-dev wrote:
> > > I just redone LFS build for GCC-10.1.0. I proposed several
> > > improvemen
ong with libbfd.a and libopcodes.a) in "Cleaning
up" section.
Are they OK to be commited into trunk?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the abov
Now GCC optionally depends on zstd (using it like zlib to compress LTO IR).
Should we move zstd before GCC?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe
On 2020-05-06 14:16 +0300, Firas Khalil Khana via lfs-dev wrote:
> On Wed, May 6, 2020 at 1:56 PM Xi Ruoyao via lfs-dev wrote:
> > Pierre recently discovered the circular dependency between eudev (in
> > Sysvinit
> > book) and util-linux:
> >
> > > util
-
> > http://lists.linuxfromscratch.org/listinfo/lfs-dev
> > FAQ: http://www.linuxfromscratch.org/faq/
> > Unsubscribe: See the above information page
>
> Then why is Util-linux also included in Chapter 5 in the SysVinit
> version of LFS? Shouldn't it suffice to only have it be built in
> Chapter 6?
Pierre recently discovered the circular dependency between eudev (in Sysvinit
book) and util-linux:
> util-linux uses libudev (eudev) in lsblk (with fallback to libblkid from util-
> linux if libudev has not been linked). And udev uses libblkid to find
> information about some block devices (specialy cdrom_id, ata_id, etc). Note
> that this is well known and cured in systemd book.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
rrectness.
>
> Leaving priority and severity to normal. It will be adjusted depending on what
> is found.
>
> Note that what we have allows building the whole blfs, so it is unlikely that
> priority and severity go the "high" direction.
I should try your approach and do an ICA, and see what will happen. But I'm now
busy preparing the problem set for an online programming contest. Maybe I'll
have time to do this on May 20.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
t; easier since they're only built once in the final system when needed (the
> final builds should also theoretically be easier because they're native builds
> now, removing the need to deal with cross builds of these packages especially
> when using other C libraries (e.g. musl)).
It's
ols glibc, although I now doubt that - see what I
> just posted).
>
> Assuming bison still fails its tests, I'll try that.
>
> Doesn't really explain why man-db has sometimes failed, but passed
> other times (for various builders). Maybe there is something else
> there.
In sysv
he issue is: we are using chapter 5 bash for bison, and chapter 5
util-linux for man-db. Chapter 5 tools' locale archive is
/tools/lib/locale/locale-archive, which is not installed.
Maybe installing en_US.UTF-8 locale in chap. 5 glibc would solve this problem.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
ke things a lot tougher for me.
Hopefully we can fix the debug info with some -ffile-prefix-map parameter in
$CC.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
python3 - perhaps
> it should be to python2. Maybe that should be made explicit somewhere?
BLFS book explicitly said asciidoc deps on Python 2.
>
> BTW I see there is an asciidoc-py3 available at:
> https://github.com/asciidoc/asciidoc-py3
>
> Is it worth moving to
, which is Linux Standard Base.
LSB 2.0.0 mandates to use /lib64/ld-linux-x86-64.so.2 on AMD64. And LSB 3.0.0+
mandates to use /lib64/ld-lsb-x86-64.so.3. If you don't care LSB or
compatibility with other distros, you can do whatever you want (your distro,
your rules). But we can't do i
On 2020-03-31 23:35 +0100, Ken Moffat via lfs-dev wrote:
> On Tue, Mar 31, 2020 at 11:37:15AM -0500, Bruce Dubbs via lfs-dev wrote:
> > On 3/31/20 4:14 AM, Pierre Labastie via lfs-dev wrote:
> > > On Tue, 2020-03-31 at 08:52 +0800, Xi Ruoyao via lfs-dev wrote:
> > >
On 2020-03-31 08:52 +0800, Xi Ruoyao via lfs-dev wrote:
> LTS meaning continuing maintenance so we'll still get one release for each
> severe bug (even if it's a bug in a strange server motherboard).
s/motherboard/& driver/
I can't type :(.
> I think we can just hold on
ing the audience to
use latest 5.x.y.) And, we should update to latest 5.x.y before 9.2.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
ight be more explict about why, so perhaps:
>
> Now fix a problem introduced by the Glibc-2.31 we have just built:
GCC 9.3.0 has been released and we'll update to it. Then this workaround will
be deleted anyway.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian Univ
vides a matching example.
Thanks for pointing out that. Done in r11777.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
n't used at all and we should remove it.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 2020-02-23 16:21 -0600, Bruce Dubbs via lfs-dev wrote:
> On 2/23/20 10:46 AM, Tadeus Prastowo via lfs-dev wrote:
> > On Sun, Feb 23, 2020 at 5:20 PM Xi Ruoyao via lfs-dev
> > wrote:
> > > We don't consider XPASS a failure. There are many XPASS in LFS packages
>
uot;XPASS is bad" so he made the entire test suite to FAIL if there was any XPASS.
Then after a Glibc upgrading, a XPASS in grep forced us to use "-k" for grep
"make check". It's stupid IMO - a test suite should not be a fragile "status
change detector".
We can add a
On 2020-02-20 22:05 -0600, Bruce Dubbs via lfs-dev wrote:
> On 2/20/20 6:57 PM, Xi Ruoyao via lfs-dev wrote:
> > On 2020-02-21 01:54 +0100, Tadeus Prastowo via lfs-dev wrote:
> > > Hello,
> > >
> > > To quote
> > > http://www.linuxfromscratch.org/lfs/v
rt of having a clean build.
>
> What do you think? Thanks.
I agree. This also confused me when I was doing the Chinese translation.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
its_posix.cc
>
> and it is probably all right since it is just an internal assertion check.
According to
https://github.com/llvm/llvm-project/commit/947f9692440836dcb8d88b74b69dd379d85974ce
it's correct. Please disregard my previous email.
--
Xi Ruoyao
School of Aerospace Science and Technology,
ll right since it is just an internal assertion check.
I don't think it's right.
It's a "static assertion":
char _static_assert_233[something_should_be_true() ? 1 : -1];
It makes the compilation to fail if something is out of the developers's
assumption.
I think GCC nee
On 2020-01-12 12:08 -0600, Bruce Dubbs via lfs-dev wrote:
> Note that tar needs to be rebuilt after zstd to recognize zstd
> compressed tarballs.
That seems not true...
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/li
Zstd is installing libzstd.a and (I think) we should remove it.
And, should we move libzstd.so.* to /lib just like libz.so.*, libbz2.so.* and
liblzma.so.*?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ
ir=/usr/libexec --sysconfdir=/etc --localstatedir=/var --
runstatedir=/var/run --libdir=/usr/lib --includedir=/usr/include --
datarootdir=/usr/share --infodir=/usr/share/info --localedir=/usr/share/locale
--mandir=/usr/share/man --{doc,html,dvi,pdf,ps}dir=/usr/share/doc/foo-1.2.3 --
with-{a,b,c,d,e,f,g}=yes --with-{h,i,j,k,l,m,n}=no
just because we can confort ourselves that it's thought to be "more robust"?
Then what if the upstream decides to use cmake or meson?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 2019-12-16 00:40 -0600, Bruce Dubbs via lfs-dev wrote:
> On 12/16/19 12:16 AM, Xi Ruoyao via lfs-dev wrote:
>
> > Considering SBU value, should we add --enable-checking=release into
> > GCC
> > configure command? Most distributions are using it and I think
> >
was about 25 seconds. On my Haswell, my LFS System
> > > V boot
> > > time is 8 seconds.
> > >
> > >-- Bruce
> >
> > My haswell often spends several seconds in boot with things like
> > unbound (for me, that is used on all systems, not as a server
nfig not to probe my LFS system (and generate unusable LFS
entries). Then I added LFS entry manually into /boot/grub/custom.cfg.
The grub.cfg generated by grub-mkconfig will load this file and show
the entry.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
his is the first time I've looked at the 5.3 kernel. Not tested other
> than the above thru make.
>
>-- Bruce
I propose:
make headers
mkdir dest
cp -rv usr/include dest/include
find dest/include \( -name .install -o -name ..install.cmd \) -delete
cp -rv dest/include/* /usr/inclu
work in
> chap. 6 as rsync is not in /tools.
>
> quel problème
>
> jb.
The change was made in 59b2bd05f5f4.
According to its commit log we can change to use "make headers" insteadly and
then copy the headers directly from "usr" directory.
--
Xi Ruoyao
School o
On 2019-09-07 11:00 +0800, Xi Ruoyao via lfs-dev wrote:
> It's said:
>
> > For some languages (e.g., Belarusian) the Kbd package doesn't provide a
> > useful
> > keymap where the stock “by” keymap assumes the ISO-8859-5 encoding, and the
> > CP1251 keymap is normally
ly.
But now there is a CP1251 keymap for Belarusian provided in kbd-2.2.0 tarball
(kbd-2.2.0/data/keymaps/i386/qwerty/by-cp1251.map).
I think the note should be revised.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-d
vironment in addition to the previous KDE/plasma, xfce, and
> lxde environments.
>
> Thanks for this release goes to many contributors. Notably:
>
> Douglas Reno
> DJ Lucas
> Ken Moffat
> Thomas Trepl
> Pierre Labastie
> Tim Tassonis
> Xi Ruoyao
>
> You
On 2019-08-28 11:39 +0200， Julien Lepiller via lfs-dev wrote:
> Hi,
>
> In meson from chapter 6, I see: … via an environment variable,
> NINJAJOBS. For example, setting …
>
> But that's not a command, is it? :)
There is a comment saying it's intentional to make "Fo
gt; Have you seen this? I'l double check my /mnt/lfs instance...
That's normal because ISL is not a part of LFS, and it's not a hard dependency
of GCC.
You can continue to build GCC unless you want to use graphite optimization
(unlikely).
--
Xi Ruoyao
School of Aerospace Science and Technolog
is something related to web engine). But why should bzip2 be
rewrote in rust?
I think I'll have to fork a non-rust-bzip2.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
ools/* /tools
> >
> > 2) Python 3 will need to be built with the switch "--with-ensurepip=yes" to
> > satisfy the installation of meson, which means that zlib and libffi will
> > need to be installed prior to Python 3, with "--with-system-ffi"
> > switc
On 2019-05-20 14:42 +0200, emiliocabrera via lfs-dev wrote:
> Hi. I´m at 5.5.1 Installation of Cross GCC, I´m building the LFS V8.4
> on
> a VirtualBox machine with Debian x86_x64 installed. I get this error:
>
> Configuring stage 2 in ./intl
Why should a cross compiler bootstrap itself?
>
script, if CFLAGS is not set, the script defaults to use
"-O2 -g" or something the package author set. However, if it is set (for some
packages, *even if set to nothing*, i. e. CFLAGS=""), the script will throw away
the default and use your setting.
That's different from cmak
Thanks for the report.
If this issue is in 8.4 release we'll need an errata...
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 2019-05-07 14:14 -0500, Bruce Dubbs via lfs-dev wrote:
> On 5/7/19 12:44 PM, Xi Ruoyao via lfs-dev wrote:
> > On 2019-05-07 11:46 -0500, Bruce Dubbs via lfs-dev wrote:
> > > On 5/7/19 6:07 AM, Xi Ruoyao via lfs-dev wrote:
> > > > Hi folks,
> > > >
>
On 2019-05-07 11:46 -0500, Bruce Dubbs via lfs-dev wrote:
> On 5/7/19 6:07 AM, Xi Ruoyao via lfs-dev wrote:
> > Hi folks,
> >
> > I just updated the status of GCC test suite in r11593. I noticed two
> > failures
> > because the lack of /etc/hosts and iana-et
/~xry111/LFS-BOOK-rfc/.
The diff is attached.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
diff -Nuar trunk/BOOK/chapter06/chapter06.xml BOOK-rfc/chapter06/chapter06.xml
--- trunk/BOOK/chapter06/chapter06.xml 2019-03-25 01:16:40.477261055 +0800
+++ BOOK-rfc/chapter06
On 2019-05-02 12:48 -0500, Bruce Dubbs via lfs-dev wrote:
> On 5/2/19 12:15 PM, Xi Ruoyao via lfs-dev wrote:
> > The test suite log says:
> >
> > *** Obsolete types detected:
> > /usr/include/linux/sysctl.h:KERN_PANIC_PRINT=78, /* ulong: bitmask to
> &g
The test suite log says:
*** Obsolete types detected:
/usr/include/linux/sysctl.h:KERN_PANIC_PRINT=78, /* ulong: bitmask to print
system info on panic */
So this test failure seems because of changes in Linux API headers.
Should we note this in the book?
--
Xi Ruoyao
School of Aerospace
On 2019-04-30 13:46 +0800, Kevin Buckley via lfs-dev wrote:
> 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 a
everal months ago):
https://rt.perl.org/Public/Bug/Display.html?id=133490
And they've fixed it in dev branch. They just didn't backport this into 5.28.x.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
1 - 100 of 181 matches
Mail list logo
