Re: [lfs-dev] Doubled instruction in Binutils Pass2 in Multilib book
Am Sonntag, dem 21.03.2021 um 10:39 +0800 schrieb Kevin Buckley via lfs-dev: > 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 > > > Workaround an issue causing > libctf.so > to link against zlib from the host distribution: > > > install -vm755 > libctf/.libs/libctf.so.0.0.0 $LFS/usr/lib > > The second and pair appear to duplicate the first, which is > all the vanilla book has. > > Kevin Oops, thanks! Will remove the extra instructions -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib Chapter 5 zlib: configure maybe missing --host flag
Am Samstag, den 14.11.2020, 10:04 +0100 schrieb Pierre Labastie via lfs-dev: > On Sat, 2020-11-14 at 10:45 +0800, Kevin Buckley via lfs-dev wrote: > > 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: > > > > > > > > > with the corresponding XML from the GZip section > > > > > > > > > Prepare Gzip for compilation: > > > > > > ./configure --prefix=/usr > > > --host=$LFS_TGT > > > > > > Compile the package: > > > > > > > > > When I came to build the Zlib, I ended up getting an error from the > > > host compiler > > > and it took me a while to work out why the build wasn't using the > > > compiler in > > > $LFS/tools/bin. > > > > > > It is also possible that the 32-bit and x32 build instructions for > > > Zlib are missing the > > > $LFS_TGT in their CC configure overrides that ones sees in the > > > Chapter 5 Ncurses > > > > > > zlib.xml:CC="gcc -m32" \ > > > zlib.xml:CC="gcc -mx32" \ > > > > > > Cf > > > > > > ncurses.xml:CC="$LFS_TGT-gcc > > > -m32" \ > > > ncurses.xml:CC="$LFS_TGT-gcc > > > -mx32" \ > > > > > > Hoping that helps, and thanks again for the Mulitlib additions, > > > Kevin > > > > > > What I have since discovered is that the Configure script for Zlib > > doesn't > > accept the --host= argument, hence, I guess, the use of the CC= > > constructs > > in the Multilib stanzas. > > > > With that in mind, the x86_64 configure probably needs to be marked > > up as > > > > CC="$LFS_TGT-gcc" \ > > ./configure --prefix=/usr > > > > so as to enforce the use of the compiler in /tools/bin. > > Actually, I'm amazed to see zlib in chapter 6 of the multilib book. In > the pure x86_64 (or i686) book, it is not built there at all (only in > chapter 8). > > Thomas, do you remember why it was added there (was on June 29th)? > Have to check that. I think it was introduced in former versions of the ML-book. I'll leave that out in chap6 for a test to see whats happening... -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding attributes in the source XML
Am Dienstag, den 06.10.2020, 18:48 +0800 schrieb Kevin Buckley via lfs-dev: > 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 > stringparam to the xsltproc invocations, vis > > --stringparam profile.revision $(REV) \ > --stringparam profile.arch $(ARCH)\ > --stringparam profile.pkguser $(PKGUSER)\ > > I get told > > validity error : No declaration for attribute pkguser of element > > I realise that I have missed adding such a declaration into one of the > stylesheet, or other ancillary, files but I can't determine, by inspection > of many of those files, where such a declaration needs to go. > > Where should such a declaration go? Those attributes like 'arch', 'revision' etc. are defined somewhere in the deepness of docbook. You cannot simply introduce new ones by adding them to the string parameter list for the renderer. All the attributes used in the {B,}LFS-book are predefined ones. You may have allready seen the pages at http://www.sagehill.net/docbookxsl/AddProfileAtt.html - the talk about "how easy it is to add". Well, i didn't find it that easy, maybe you have more luck. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Chapter 8 Multilib Libffi x32-bit section title has Libtool entity
Am Samstag, den 25.07.2020, 14:11 +0800 schrieb Kevin Buckley via lfs- dev: > 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 chapter08/libffi.xml does currently say > > > > > > > Installation of Libtool - x32bit > > Kevin Oops, must have been a copy-paste-error. Will be fixed in the next update. Thanks for reporting. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] perl install options
Am Samstag, den 20.06.2020, 14:53 +0100 schrieb Ken Moffat via lfs- dev: > On Sat, Jun 20, 2020 at 02:42:03PM +0200, Thomas Trepl via lfs-dev wrote: > > Hi all, > > > > this is about hte configuration options of perl. > > > > Problem: > > whenever perl is upgraded to a newer version (for example 5.30.2 to > > 5.30.3), all perl modules needs to be reinstalled as the current > > configuration of perl forces a directory structure like > > > > > > All modules are installed under /usr/lib/perl5/5.30.2 . Now, when > > installing a newer patch-version by overwriting the existing one, the > > structure looks like > > > > > > The 5.30.2-directory (which includes the modules) is more or less > > garbage as the new perl will use 5.30.3. Therefore, any installed > > module must be reinstalled to appear in the 5.30.3 structure. > > > > This all is not really a problem as long as the system is completely > > built from scratch and all modules are installed freshly. For those > > who uses some kind of pkgmnr or upgrade the system package by package > > it might be a problem when perl is about to upgrade. > > > > Yes, for my own systems I have had to rebuild all the modules if > upgrading perl. > > > Suggestion: > > The following is under the assumption that patch-versions of perl are > > compatible to each other. To solve the upgrade issue described above, > > add a few new options to the perl install command in the LFS book: > > > > sh Configure -des \ > > -Dprefix=/usr \ > > - > > Dvendorprefix=/usr \ > > * -Dprivlib=/usr/share/perl5/core_perl > > \ > > * -Darchlib=/usr/lib/perl5/&perl-version-min;/core_perl \ > > * - > > Dsitelib=/usr/share/perl5/site_perl \ > > * - > > Dsitearch=/usr/lib/perl5/&perl-version-min;/site_perl \ > > * - > > Dvendorlib=/usr/share/perl5/vendor_perl \ > > * - > > Dvendorarch=/usr/lib/perl5/&perl-version-min;/vendor_perl \ > > - > > Dman1dir=/usr/share/man/man1 \ > > -Dman3dir=/usr/share/man/man3 \ > > - > > Dpager="/usr/bin/less -isR" \ > > -Duseshrplib \ > > - > > Dusethreads > > > > assuming that we have in packages.ent: > > > > > > > > > > > > > minor;.&perl-version-patch;"> > > > > This will produce a directory structure: > > > > /usr > > /lib > > /perl5 > > /5.30 > > /core_perl > > /... > > /site_perl > > /... > > > > where modules are installed under /usr/lib/perl5/5.30/site_perl/ . In > > this case, overwriting the installed perl with a newer one has no > > effect on the installed modules unless minor or even major version of > > perl > > > Sounds nice. But just to be clear - under site_perl I have a > versioned directory (e.g. 5.30.2 for your current example). I > assume, or hope, that will either be 5.30 or completely omitted. This versioned subdir will be omitted completely. Files from XML::Parser are installed as usr/lib/perl5/5.30/site_perl/auto usr/lib/perl5/5.30/site_perl/auto/XML usr/lib/perl5/5.30/site_perl/auto/XML/Parser usr/lib/perl5/5.30/site_perl/auto/XML/Parser/.packlist usr/lib/perl5/5.30/site_perl/auto/XML/Parser/Expat usr/lib/perl5/5.30/site_perl/auto/XML/Parser/Expat/Expat.so usr/lib/perl5/5.30/site_perl/XML usr/lib/perl5/5.30/site_perl/XML/Parser usr/lib/perl5/5.30/site_perl/XML/Parser/Encodings usr/lib/perl5/5.30/site_perl/XML/Parser/Style usr/lib/perl5/5.30/core_perl usr/lib/perl5/5.30/core_perl/perllocal.pod net-ssleay installs as ... usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/randomize.al usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/do_httpx2.al usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/put_https3.al usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/do_https3.al usr/lib/perl5/5.30/site_perl/Net usr/lib/perl5/5.30/site_perl/Net/SSLeay.pod usr/lib/perl5/5.30/site_perl/Net/SSLeay usr/lib/perl5/5.30/site_perl/Net/SSLeay/Handle.pm usr/lib/perl5/5.30/site_perl/Net/SSLeay.pm ... > > i.e. /usr/lib/perl5/5.30/site_perl/5.30/ or > /usr/lib/perl5/5.30/site_perl/ for the directory where 'top level' > modules SGMLS.pm and URI.pm live ? URI: usr/share/perl5/site_perl/URI.pm this pkg seems to use the "sitelib" instead of "sitearch" configuration target. Any info why/when this target is used? > > A note to "make install" might be required as perl refuses to > > overwrite an installation in case of an version mismatch (which make
[lfs-dev] perl install options
Hi all, this is about hte configuration options of perl. Problem: whenever perl is upgraded to a newer version (for example 5.30.2 to 5.30.3), all perl modules needs to be reinstalled as the current configuration of perl forces a directory structure like /usr /lib /perl5 /5.30.2 /... /site_perl All modules are installed under /usr/lib/perl5/5.30.2 . Now, when installing a newer patch-version by overwriting the existing one, the structure looks like /usr /lib /perl5 /5.30.2 /... /5.30.3 /... /site_perl The 5.30.2-directory (which includes the modules) is more or less garbage as the new perl will use 5.30.3. Therefore, any installed module must be reinstalled to appear in the 5.30.3 structure. This all is not really a problem as long as the system is completely built from scratch and all modules are installed freshly. For those who uses some kind of pkgmnr or upgrade the system package by package it might be a problem when perl is about to upgrade. Suggestion: The following is under the assumption that patch-versions of perl are compatible to each other. To solve the upgrade issue described above, add a few new options to the perl install command in the LFS book: sh Configure -des \ -Dprefix=/usr \ - Dvendorprefix=/usr \ * -Dprivlib=/usr/share/perl5/core_perl \ * -Darchlib=/usr/lib/perl5/&perl-version-min;/core_perl \ * - Dsitelib=/usr/share/perl5/site_perl \ * - Dsitearch=/usr/lib/perl5/&perl-version-min;/site_perl \ * - Dvendorlib=/usr/share/perl5/vendor_perl \ * - Dvendorarch=/usr/lib/perl5/&perl-version-min;/vendor_perl \ - Dman1dir=/usr/share/man/man1 \ -Dman3dir=/usr/share/man/man3 \ - Dpager="/usr/bin/less -isR" \ -Duseshrplib \ - Dusethreads assuming that we have in packages.ent: This will produce a directory structure: /usr /lib /perl5 /5.30 /core_perl /... /site_perl /... where modules are installed under /usr/lib/perl5/5.30/site_perl/ . In this case, overwriting the installed perl with a newer one has no effect on the installed modules unless minor or even major version of perl changes. A note to "make install" might be required as perl refuses to overwrite an installation in case of an version mismatch (which makes sense in case of incompatible version, maybe when minor or major version changes). To overcome this, a mv /usr/bin/perl{,.old} can be executed before doing the install. As far as i have seen, there is no change required for BLFS except one textual adjustment in the "Perl Modules" page. All comments, suggestions, tomatos and eggs are welcome! Is there something i have completely overseen? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc-10 and stack protector in kernel
Am Montag, den 11.05.2020, 09:50 +0200 schrieb Pierre Labastie via lfs-dev: > Sorry if this has already been reported. With gcc 10 and kernel 5.6.11, > I get: > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted > in: start_secondary+0x169/0x170 > > at early boot. > this has been reported upstream [1], who made a complicated patch, > mainly consisting of comments. It seems it occurs only when > CONFIG_STACKPROTECTOR_STRONG=y. I do not know which kernel will have > it. 5.6.12 doesn't. > > Two possibilities: remove the STACK_PROTECTOR_STRONG config, or apply > this sed: > > sed -e '/cpu_startup/a asm("");' -i arch/x86/kernel/smpboot.c > > which does not fix xen kernel, but does everything else the patch does. > > Pierre > > [1] end of a long thread on lkml: > https://lore.kernel.org/lkml/158798746828.28353.6010675315553653459.tip-bot2@tip-bot2/ > Sorry for not responding in time. I just compiled linux-5.6.13 first without the modifications and i failed to boot with exactly the same kernel-panic. According to a patch which can be found on lkml, i modified the sources by applying diff -Naur linux-5.6.13.orig/arch/x86/kernel/smpboot.c linux- 5.6.13/arch/x86/kernel/smpboot.c --- linux-5.6.13.orig/arch/x86/kernel/smpboot.c 2020-03-30 00:25:41.0 +0200 +++ linux-5.6.13/arch/x86/kernel/smpboot.c 2020-05-19 14:00:42.250125049 +0200 @@ -262,6 +262,7 @@ wmb(); cpu_startup_entry(CPUHP_AP_ONLINE_IDLE); + asm(""); // disable tail-call optimization } /** diff -Naur linux-5.6.13.orig/arch/x86/xen/smp_pv.c linux- 5.6.13/arch/x86/xen/smp_pv.c --- linux-5.6.13.orig/arch/x86/xen/smp_pv.c 2020-03-30 00:25:41.0 +0200 +++ linux-5.6.13/arch/x86/xen/smp_pv.c 2020-05-19 14:01:41.717566594 +0200 @@ -92,6 +92,7 @@ cpu_bringup(); boot_init_stack_canary(); cpu_startup_entry(CPUHP_AP_ONLINE_IDLE); + asm(""); // disable tail-call optimization } void xen_smp_intr_free_pv(unsigned int cpu) And with this, machine boots. Btw, i have CONFIG_STACKPROTECTOR_STRONG=y I'd vote for applying the patch (or a sed) rather than unsetting CONFIG_STACKPROTECTOR_STRONG as at least the name of this option sounds like it has to do with security. Switching off security i think is the second best. But i also have to admit that i haven't read the documentation about those options, yet. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] proposal: some improvements to LFS book
Am Montag, den 11.05.2020, 19:51 +0800 schrieb Xi Ruoyao via lfs-dev: > I just redone LFS build for GCC-10.1.0. I proposed several improvements > during > the process: > > At first, some changes suggested by Firas: > > 1. Remove bzip2 in Chap. 5. No other changes needed. > > 2. Remove ncurses in Chap. 5. Move Chap. 6 readline after ncurses to satisify > it. > Notes: > (1) Chap. 5 Python 3 can be built w/o ncurses, just lacking one module we > don't > need. > (2) We moved readline before bc to satisify GNU bc, but now Gavin's bc doesn't > need readline. > (3) It slightly reduces the functionality of Chap. 5 bash. Long command lines > won't be wrapped automatically anymore. Just had the joy to do a bit manually on such kind of cmdline (help testing Pierres branch) and there we ran into this. Really no fun. Reme mber that we always tell the users to do everything manually (at least for the first time) and do not script because scripts add another layer of errors. So we "force" them to use such kind of command line - I'd say second- best. > > 3. Remove flex in Chap. 5. Move Chap. 6 flex before Binutils so `ranlib` and > `ar` can link to libfl.so. It seems bison test suite does not depends on flex > any more. > > However Firas' other suggestions are proved to be impossible. Glibc requires > bison, gzip, gettext, perl, texinfo, python, and xz (to be untarred) so all of > them need to stay in Chap. 5. Util-linux can't be removed from Chap. 5 due to > its circular dependency with systemd/eudev. > > And: > > 4. Move Chap. 6 zstd before GCC, so GCC can link to libzstd.so and use zstd to > compress LTO stream. > > 5. Remove PKG_CONFIG_PATH=/tools/lib/pkgconfig in Chap. 6 kbd. It seems > unneeded now. > > 6. Remove PERL5LIB=$PWD/tests/ in Chap. 6 make. It is unneeded now. > > 7. Add: > > mkdir /tools/lib/locale > localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true > > into Chap. 5 Glibc. It will satifisy Chap. 6 man-db test. > > 8. Remove libctf{,-nobfd}.a (along 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 above information page
Re: [lfs-dev] Modified build of LFS using pure cross-compilation and sysroot
Am Freitag, den 01.05.2020, 15:53 +0200 schrieb Pierre Labastie via lfs-dev: > Hi, > > I propose a new way to build LFS, which removes the need for the /tools > symlink, and decreases the number of tweaks needed when building gcc. > > The current build builds a cross-compiler in pass1, and uses it as a > native compiler in pass2. This needs to use a non standard directory > (/tools) to host the toolchain and insulate it from the build machine. > > The modified build uses the cross compiler to cross compile packages > that need themselves to be rebuilt, thus insulating them automatically > from the host, without the need for a non standard directory layout. > Chroot is entered as soon as possible, and the remaining chapter 5 > packages are built in chroot. Wow, quite interesting! I'd vote to have a deeper look to that mechanism. > This is WIP: the text must be improved at several places, bison and > flex may be moved to after chroot (to be tested). But the commands seem > to produce an acceptable system, with almost clean ICA. > > You can view it at [1], only for sys V since I have not tested systemd > yet (I do not expect many changes). > > There are pros and cons compared to the current method: > > pros: no /tools symlink, no need to tweak gcc sources, no need to > build twice ld in binutils-pass2, no need to readjust the toolchain > after chapter 6 glibc, no need to tweak the gcc specs, no need to > reinstall kernel headers in chapter 6. The less we have to tweak core packages (and gcc is for sure one of them), the better. I would see that as a great benefit. > > cons: chroot is entered in the middle of chapter 5 (maybe chapter 5 > should be split), the debug sections of several packages reference > x86_64-lfs-linux-gnu instead of x86_64-pc-linux-gnu, binutils-pass2 > needs "enable-shared". Ok, here is the "traditional" separation of Chapter 5 (as run with host tools) and the Chapter 6 (running previously built tools in chroot) in danger. But at the end, its just a naming issue. With your method we have kinda Chapter 5a building core tools, a Chapter 5b building toolchain for full build using 5a in chroot and finally the well-known Chapter 6. For the cost of entering the chroot in the middle of chap5, we got rid of the adjusting which sometimes causes trouble for newbies. This knot is simply untied. > Another pro, not tried, is that some simple packages built in chapter 5 > may be built only once if testing them is not required. > > Comments and suggestions for improvement (there's a lot of room for > improvement) welcome. Its great! I'd see that as a big evolution step in the LFS ecosystem. I see a restart to continue not more complicated as it is now. When continuing an interrupted build in chap5 now, user has also to prepare the environment carefully. Same in new chapter 5a so no change here. Continuing in chap 5b, only need to reenter the chroot, this not any different to want currently has to be done while it comes a few steps earlier. Maybe the new Chapter 5 should end with leaving the chroot environment with unmounting the virtFS. It could be a proper end to chap5 as at this stage, a backup of the system might be recommended (as a hint for the user). The new chapter 6 should then reenter the chroot env again. IMHO this would make the differentiation of chap5 and 6 a bit easier. -- Thomas > > Regards > Pierre > > > [1] http://www.linuxfromscratch.org/~pierre/lfs-modified/index.html > -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Need update to Fop-2.4 instructions
Am Samstag, den 11.04.2020, 11:53 -0500 schrieb Timothy Russo via lfs- dev: > I'm building a current LFS/BLFS system and while loading Fop-2.4 this > morning, the required download links for PDFBox and PDFBox Fonts need to be > updated to pdfbox/2.0.19. It looks like this was updated Feb 20th. > > Also, just a side question, has anyone done a LFS/BLFS Systemd-multilib patch? > I followed Thomas' updated LFS multilib but I wanted systemd so I finangled > my way through combining the systemd build and his multilib build to get LFS > complete. I just wasn't sure how much of BLFS would also need to be compiled > multilib for it all to work together nicely. you don't *need* to build any lib32-stuff to run the system. But if you have built ML in LFS, then you *could*. Which packages you might need in 32bit depends on what you're going to do with your system or what you need on your system. I've a printer driver which is only available in 32bit binary (which was the trigger to setup LFS-multilib) for which i need at least lib32-nettle and lib32-cups. VirtualBox (using the LFS system as host) needs ML-support internally. So there's no clear direction pointing to "you need X and Y" it depends on what you need. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch
Am Dienstag, den 24.03.2020, 12:44 -0500 schrieb Timothy Russo via lfs-dev: > Whatever happened to the multilib patch? I was following the thread back in > August 2018: > On 08/25/2018 12:13 AM, DJ Lucas wrote: > > > One more thing, need to add lib32 paths to remove-la-files.sh. I, thus > > far, have not messed with lib32x. I used a separate path for files in > > /usr/lib32. Same for /usr/lib32/pkgconfig and /usr/local/lib32/pkgconfig. > > > > On second thought, there is no purpose for the pc files in > /usr/lib32/pkgconfig, should just remove the directory if it exists. > Regardless of the libdir value in the pc file, the libraries themselves > will always be in the library search path because of our change to > /etc/ld.so.conf. > > --DJ > > and then it seemed to die. > I've found this: http://www.linuxfromscratch.org/~dj/lfs-systemd-multilib/ > from Nov 2018. > However, I'd love to help/test/edit an updated multilib patch to work against > the current 9.1 version of LFS/BLFS. > I was able to get my printer to work with multilib using these outdated > references, but I was only able to get steam to function with a flatpak. > If DJ or Thomas would like to revisit the multilib patch or > lfs-systemd-multilib version of the book, I'd love to help. Hi Tim, ML is still maintained - well, basically its a periodical merge of the trunk to the branch and subsequently fixing clashes ;-) You can find it at http://www.linuxfromscratch.org/~thomas/multilib/index.html and the sources are in a branch named 'multilib' in SVN. Feel free to post patches/ideas/remarks! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Inaccuracy in chroot page
Am Samstag, den 14.03.2020, 18:11 +0100 schrieb Pierre Labastie via lfs-dev: > Le 14/03/2020 à 17:36, Bruce Dubbs via lfs-dev a écrit : > > On 3/14/20 10:55 AM, Pierre Labastie via lfs-dev wrote: > > > Le 14/03/2020 à 16:00, Bruce Dubbs via lfs-dev a écrit : > > > > On 3/14/20 3:41 AM, Pierre Labastie via lfs-dev wrote: > > > > > In "6.4 Entering the Chroot Environment", we have: > > > > > > > > > > From this point on, there is no need to use the LFS variable > > > > > anymore, > > > > > because > > > > > all work will be restricted to the LFS file system. This is because > > > > > the Bash > > > > > shell is told that $LFS is now the root (/) directory. > > > > > > > > > > But it is not true that the bash shell is told anything: the _kernel_ > > > > > is told > > > > > that $LFS is now the root (/) directory for all the processes > > > > > launched by the > > > > > first one (that is, here, "env", which itself launches "bash", which > > > > > will > > > > > launch all the others). I am not sure how to phrase this: something > > > > > like: > > > > > - > > > > > ... system. This is because the kernel is told that $LFS is now the > > > > > root (/) > > > > > directory for all the programs run from the current Bash shell. > > > > > - > > > > > But I'm sure native English writers can find something better (without > > > > > excluding non native of course :) > > > > > > > > I think I disagree with your premise. bash IS told where the root > > > > directory > > > > is, but there is some interaction with the kernel. > > > > > > > > When I enter chroot, env no longer exists. It does an 'exec' and > > > > replaces > > > > itself with bash. I took a look at /proc/ for that instance of > > > > bash and > > > > in that directory is the pseudo file 'mounts'. That tells me: > > > > > > > > /dev/sda6 / ext4 rw,noatime 0 0 > > > > > > > > which is my /mnt/lfs directory on the host. My interpretation is that > > > > this is > > > > a configuration for bash. When doing 'cd /', the kernel looks at this > > > > configuration for the bash instance and uses that to determine what disk > > > > partition (it could be a directory) to use for the head of an absolute > > > > path. > > > > > > > > In my opinion what we have now is correct. > > > > > > > > > > Thinking a little more about this, what I mean is the following: bash is > > > not > > > "told" anything, and does not "know" that "/" is $LFS: bash may ask the > > > kernel > > > to open(2) (or stat(2), or other basic calls) a file by passing the > > > filename > > > to the kernel, say, /a/file/name, and it is the kernel which resolves that > > > filename to $LFS/a/file/name, not bash itself. > > > > I'm OK with: > > > > This is because the Bash shell is set up so that $LFS is now the root (/) > > directory. > > > > That is: sed /told/set up so/ > > > > I just feel like I cannot explain. Bash is _unchanged_: it is the _kernel_, > which is set up so that $LFS is the new root for the process where bash (or > anything fork(2)ed from bash) is running. I agree, i think bash not even know that its running in chroot. > Anyway, nobody has complained for > years, let's not change anything. It does not prevent the build to work. also true > Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Building Glibc without the Info pages?
Am Dienstag, den 10.03.2020, 17:19 +0800 schrieb Kevin Buckley via lfs-dev: > 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. Thats for sure kinda redundant. It might be caused by building glibc for m64, m32 and mx32 in each of chapter 5 and 6, sums up to 6 times. Ususally for a normal build using the "standard" book, only one time is wasted (the one in chapter 5), so much efforts has not been taken do avoid redundant builds. > I've been looking at the Glibc Makefile hierarchy but couldn't see an > obvious place at which to prevent the Info pages being built. > > It looks like there's a subdir build on the "manual" subdirectory > during the "make install" but I'm having a hard time unravelling > the actual target and/or rule to avoid. > > Anyone on here got any "previous" in this area? Not yet, but this might be an interesting add-on in ML-book... -- Thomas btw, thanks for using the ML-book and especially providing hints, bugfixes and other tweaks! -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] 20 years LFS
Am Sonntag, den 17.11.2019, 22:30 +0100 schrieb Thomas Trepl via lfs- dev: > > Ok, its about three years to go for celebrating the 20th anniversary > of version 1.0 (tarball's timestamp is 2002-11-04) but LFS as such was > born already... > And this is not correct: Gerard dates the Version 1.0 to 16th December 1999. So, this year is really the 20th anniversary of LFS :-) -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] 20 years LFS
Hi all, well, its not really the first time i took a look to the {,B}LFS-book this year ;-) but today I realized what is written in the Copyright statement: > Copyright © 1999-2019 Gerard Beekmans This is now 20 years LFS! Thanks to Gerard for the project, all the editors came and went away and of course the current leaders and editors! Its been a great time so far, wonder where LFS will take us in the future. Ok, its about three years to go for celebrating the 20th anniversary of version 1.0 (tarball's timestamp is 2002-11-04) but LFS as such was born already... -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Searching for a chapter on multilib
Am Donnerstag, den 11.07.2019, 10:29 -0400 schrieb Lewis Pike via lfs- dev: > Hi all, > > Last year, I went through the process of adding multilib support to my > existing 64-bit LFS system. I had come across what appeared to be a > fork of the book at > http://www.linuxfromscratch.org/~dj/history/lfs-systemd-multilib/ > which contained an additional chapter (Chapter 10) addressing this > very topic. > > Sadly, the above link is now dead and the notes I had taken at the > time aren't sufficient to reproduce my prior build. > > Might anyone have a copy of this fork or know where it can be found? > > .lewis Hi Lewis, thanks for showing interests in doing multilib stuff. DJ's work you refered to was a big big help to setup the ML-branch you can find at http://www.linuxfromscratch.org/~thomas/multilib/index.html - i think it has been mentioned allready in this thread. Without thinking about much in detail, adding ML support to an existing non-ML system should not be more difficult than seting up a fresh one. I think you'll just have to redo the core utils to be ML enabled, than redo the other libs. There are several libs in the ML-bool which are built in 32bit mode too even they are not really required to run the (LFS) system. But when going on to more sofisticated packages it will turn out that they will need them. Thats the reason why those libraries are built in LFS book, its just to provide ML support for doing BLFS. The essence of ML is in binutils/gcc/glibc - this is where ML "lives". -- Thomas Btw, after being away for vacation, i just merged the latest changes to the ML-book, its now on SVN-20190721. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Things could get much worse for bzip2
Am Donnerstag, den 27.06.2019, 05:24 -0400 schrieb Marty Jack via lfs- dev: > Reading the new homepage, it seems this is the gentleman who rewrote librsvg > in Rust and plans to do the same for bzip2. If he cannot be dissuaded, this > will have a disastrous effect on Chapter 5. Right, unfortunatly. I'm still using the last version of non-rust-librsvg. Up to now, it seems to work fine. Of course, bugfixes are not there. (in my undergraduated mind i never understood whats so cool in rust which justifies that monster of compiler infrastructure, and in this case, such a monster building a relativly small tool) -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Upgrades in LFS
Hi all, i'm just in the process of running thru a modified book including (most of) the version upgrades (linux, e2fsprogs, perl, eudev, bison, openssl) to see what happens using them. I just saw that they has been commited in the minute... I was to slow in reporting my findings (while compilation and checks are currently still running), but it seems so that the sed in perl regarding the gcc-versions is no longer required. When upgrading LFS packages, i think we should do a quick check on seds or patches created by our own whether they are still required. Thats also true for e2fsprogs-1.45.2 were a fix has been included due to my report of that strange install behavior in case /etc/cron.d does not exist. The option --with-crond-dir=no is no longer required for LFS (while does not harm anyway) as e2fsprogs now does the checking right. I'm also testing the new bc (#4436) which seems to be actively maintained and is now on v2.0.2. Looks like it works well - at least i didn't notice any failures trackable down to bc. Btw, we have statements in gcc echoing a #define STANDARD_STARTFILE_PREFIX_1 etc. to some files. Couldn't that be simplified if we change gcc/gcc.c (the STANDARD_STARTFILE_PREFIXes are defined there)? I'm going to test that when build is finished... -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] e2fsprogs 1.45.1 + patch
Am Montag, den 13.05.2019, 10:31 +0200 schrieb thomas via lfs-dev: > Just a few hours ago they released 1.45.1 of e2fsprogs. > Unfortunatly, nothing changed in the crond_dir case. > > Anyway, I've reported that to Ted - lets see if he (or others) will have > a lok at it. > > -- > Thomas Got following answer+fix from Ted: >>> On Mon, May 13, 2019 at 11:08:44AM +0200, thomas wrote: > Hi Ted, > > if your time allows, could you have a quick look to following issue? > > What is it about > > > When installing on a (non-systemd-)machine where no cron is installed (yet), > the installation of e2scrub_all does some strange things. It looks to me > that the issue is not related to systemd vs. sysv. Thanks for your bug report! I beleive this patch should fix things; can you test and confirm? - Ted commit a9cf13748946ce9ceb56f962fc22b965048d2cef Author: Theodore Ts'o Date: Wed May 22 13:03:38 2019 -0400 configure: fix test where cron is not installed on a non-systemd system Reported-by: tho...@linuxfromscratch.org Signed-off-by: Theodore Ts'o diff --git a/configure b/configure index 205b2d6dc..065bff761 100755 --- a/configure +++ b/configure @@ -13150,7 +13150,8 @@ fi { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_blkid_blkid_probe_get_topology" >&5 $as_echo "$ac_cv_lib_blkid_blkid_probe_get_topology" >&6; } if test "x$ac_cv_lib_blkid_blkid_probe_get_topology" = xyes; then : - $as_echo "#define HAVE_BLKID_PROBE_GET_TOPOLOGY 1" >>confdefs.h + +$as_echo "#define HAVE_BLKID_PROBE_GET_TOPOLOGY 1" >>confdefs.h fi @@ -13191,7 +13192,8 @@ fi { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_blkid_blkid_probe_enable_partitions" >&5 $as_echo "$ac_cv_lib_blkid_blkid_probe_enable_partitions" >&6; } if test "x$ac_cv_lib_blkid_blkid_probe_enable_partitions" = xyes; then : - $as_echo "#define HAVE_BLKID_PROBE_ENABLE_PARTITIONS 1" >>confdefs.h + +$as_echo "#define HAVE_BLKID_PROBE_ENABLE_PARTITIONS 1" >>confdefs.h fi @@ -14511,6 +14513,8 @@ if test "x${with_crond_dir}" != "xno"; then : if test -d "/etc/cron.d"; then : with_crond_dir="/etc/cron.d" +else + have_crond="no"; with_crond_dir="" fi fi diff --git a/configure.ac b/configure.ac index 3b86c1a14..cf03444d8 100644 --- a/configure.ac +++ b/configure.ac @@ -1674,7 +1674,8 @@ AS_IF([test "x${with_crond_dir}" != "xno"], AS_IF([test "x${with_crond_dir}" = "xyes"], [ AS_IF([test -d "/etc/cron.d"], - [with_crond_dir="/etc/cron.d"]) + [with_crond_dir="/etc/cron.d"], + [have_crond="no"; with_crond_dir=""]) ]) AC_MSG_CHECKING([for system crontab dir]) crond_dir="${with_crond_dir}" <<< No need to specify the --with-crond-dir=no option at configure command anylonger (and no 'yes'-directory). Find the (reformatted) patch attached. -- Thomas diff -Naur e2fsprogs-1.45.1.orig/configure e2fsprogs-1.45.1/configure --- e2fsprogs-1.45.1.orig/configure 2019-05-13 03:23:53.0 +0200 +++ e2fsprogs-1.45.1/configure 2019-05-22 19:41:28.234071070 +0200 @@ -14511,6 +14511,8 @@ if test -d "/etc/cron.d"; then : with_crond_dir="/etc/cron.d" +else + have_crond="no"; with_crond_dir="" fi fi diff -Naur e2fsprogs-1.45.1.orig/configure.ac e2fsprogs-1.45.1/configure.ac --- e2fsprogs-1.45.1.orig/configure.ac 2019-05-13 03:23:53.0 +0200 +++ e2fsprogs-1.45.1/configure.ac 2019-05-22 19:42:34.413062225 +0200 @@ -1674,7 +1674,8 @@ AS_IF([test "x${with_crond_dir}" = "xyes"], [ AS_IF([test -d "/etc/cron.d"], - [with_crond_dir="/etc/cron.d"]) + [with_crond_dir="/etc/cron.d"], + [have_crond="no"; with_crond_dir=""]) ]) AC_MSG_CHECKING([for system crontab dir]) crond_dir="${with_crond_dir}" -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] e2fsprogs + crond
Am Montag, den 13.05.2019, 00:47 +0100 schrieb Ken Moffat via lfs-dev: > On Sun, May 12, 2019 at 10:25:34PM +0200, Thomas Trepl via lfs-dev wrote: > > Hi all, > > > > i just started a build of a new system. To my surprise, it failed in > > chap6 at e2fsprogs where it never stopped before. > > The reason for stopping is > > > > > > ake[1]: Leaving directory '/autolfs/sources/e2fsprogs-1.45.0/build/po' > > making install in scrub > > make[1]: Entering directory '/autolfs/sources/e2fsprogs- > > 1.45.0/build/scrub' > > MKDIR_P /usr/lib/e2fsprogs > > MKDIR_P yes > > INSTALL yes/e2scrub_all > > /usr/bin/install: cannot create regular file 'yes/e2scrub_all': No > > such file or directory > > make[1]: *** [Makefile:447: install-crond] Error 1 > > make[1]: *** Waiting for unfinished jobs > > make[1]: Leaving directory '/autolfs/sources/e2fsprogs- > > 1.45.0/build/scrub' > > make: *** [Makefile:434: install-progs-recursive] Error 1 > > make: *** Waiting for unfinished jobs > > make[1]: Leaving directory '/autolfs/sources/e2fsprogs- > > 1.45.0/build/lib/et' > > making install-shlibs in lib/ss > > make[1]: Entering directory '/autolfs/sources/e2fsprogs- > > 1.45.0/build/lib/ss' > > > > > > A look to the build/Makefile showed > > > > > > HAVE_UDEV = no > > UDEV_RULES_DIR = > > HAVE_CROND = yes > > CROND_DIR = yes > > HAVE_SYSTEMD = no > > SYSTEMD_SYSTEM_UNIT_DIR = > > > > > > Note the setting of CROND_DIR. I checked the configure script and > > found in line ~14500 a check on option $with_crond_dir=[yes,no]. If > > not set, yes is assumed. Later on, in case $with_crond_dir == yes, the > > test if /etc/cron.d exists and set with_crond_dir to /etc/cron.d if > > the directory is there. It remains "yes" if that directory does not > > exist. I assume that is the reason why CROND_DIR set to "yes" in the > > Makefile. > > > > What i really do not understand is why that happens now and never > > before? We have e2fsprogs-1.45.0 a good amount of time in the book, > > there is nothing new but if my reading of the configure script is > > correct, there is a fulminant logical error in it. Wonder why that > > never came up before. > > > > What do you think, am i right in interpreting the section in the > > configure script that there is a logical bug in it? If so, i do not > > get it why it comes up now and not at all the previous builds too... > > > > Btw, i specified --with-crond-dir=no and compilation/installation of > > e2fsprogs went fine. > > > I've just looked at my build from a couple of days ago - > > checking for udev... no > checking for udev rules dir... no > checking for system crontab dir... yes > checking for systemd... no > > make[2]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub' > ../util/subst -t -f ../util/subst.conf ../../scrub/e2scrub_all.cron.in > e2scrub_all.cron > make[2]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > make[2]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub' > ../util/subst -t -f ../util/subst.conf ../../scrub/e2scrub_all_cron.in > e2scrub_all_cron > chmod a+x e2scrub_all_cron > make[2]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > > make[1]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub' > MKDIR_P yes > make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > make[1]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub' > MKDIR_P /usr/lib/e2fsprogs > make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > make[1]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub' > INSTALL yes/e2scrub_all > make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > make[1]: Entering directory '/building/e2fsprog > INSTALL /usr/lib/e2fsprogs/e2scrub_all_cron > make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > > From that, I would expect to have a directory called 'yes'. > Fortunately, it was not *that* broken. Sure? It should be in ~/e2fsprogs-1.45.0/build/scrub/. I just rerun $ sudo make install and e voila, here in ~/e2fsprogs-1.45.0/build it is: $ dir scrub/ insgesamt 68 drwxr-xr-x 3 lfs users 4096 13. Mai 08:21 . drwxr-xr-x 15 lfs users 4096 13. Mai 07:56 .. -r-xr-xr-x 1 lfs users 6738 13. Mai 07:57 e2scrub -
Re: [lfs-dev] e2fsprogs + crond
Am Sonntag, den 12.05.2019, 17:45 -0500 schrieb Bruce Dubbs via lfs- dev: > On 5/12/19 3:25 PM, Thomas Trepl via lfs-dev wrote: > > Hi all, > > > > i just started a build of a new system. To my surprise, it failed in > > chap6 at e2fsprogs where it never stopped before. > > The reason for stopping is > > > > > > make[1]: Entering directory '/autolfs/sources/e2fsprogs- > > 1.45.0/build/scrub' > > MKDIR_P /usr/lib/e2fsprogs > > MKDIR_P yes > > INSTALL yes/e2scrub_all > > /usr/bin/install: cannot create regular file 'yes/e2scrub_all': No > > ... > > My logs show: > > > making install in scrub > make[2]: Entering directory '/sources/e2fsprogs-1.45.0/build/scrub' > MKDIR_P yes > MKDIR_P /usr/lib/e2fsprogs > INSTALL yes/e2scrub_all > INSTALL /usr/lib/e2fsprogs/e2scrub_all_cron > MKDIR_P /sbin /usr/share/man/man8 /etc > SYMLINK /usr/lib/libe2p.so > INSTALL /sbin/e2scrub > INSTALL /sbin/e2scrub_all > INSTALL_DATA /usr/share/man/man8/e2scrub.8 > INSTALL_DATA /usr/share/man/man8/e2scrub_all.8 > INSTALL_DATA /etc/e2scrub.conf > make[2]: Leaving directory '/sources/e2fsprogs-1.45.0/build/scrub' There is that "MKDIR_P yes" too and later, an install to that yes- directory happens. I'm not sure why it breaks here, but not at your system. Anyway, isn't that 'yes' fundamentaly wrong? > > Are you running make install at -jx where x > 1 ? I'll run tests about this later without -j5 (which is set by default here). A quick redo of install using DESTDIR (and without MAKEFLAGS) shows $ sudo make install Q= DESTDIR=/tmp/e2fs ... make[1]: Verzeichnis „/home/lfs/e2fsprogs-1.45.0/build/scrub“ wird betreten for i in e2scrub.rules; do \ echo " INSTALL /lib/udev/rules.d/$i"; \ /usr/bin/install -c -m 644 $i /tmp/e2fs/lib/udev/rules.d/96- $i; \ done MKDIR_P yes /bin/mkdir -p /tmp/e2fsyes MKDIR_P /usr/lib/e2fsprogs /bin/mkdir -p /tmp/e2fs/usr/lib/e2fsprogs MKDIR_P /lib/udev/rules.d /bin/mkdir -p /tmp/e2fs/lib/udev/rules.d if test -n "e2scrub_all.cron" ; then \ echo " INSTALL yes/e2scrub_all" ; \ /usr/bin/install -c -m 644 e2scrub_all.cron /tmp/e2fsyes/e2scrub_all ; \ fi for i in e2scrub_all_cron; do \ echo " INSTALL /usr/lib/e2fsprogs/$i"; \ /usr/bin/install -c $i /tmp/e2fs/usr/lib/e2fsprogs/$i; \ done INSTALL /lib/udev/rules.d/e2scrub.rules INSTALL yes/e2scrub_all INSTALL /usr/lib/e2fsprogs/e2scrub_all_cron MKDIR_P /sbin /usr/share/man/man8 /etc /bin/mkdir -p /tmp/e2fs/sbin \ /tmp/e2fs/usr/share/man/man8 /tmp/e2fs/etc for i in e2scrub e2scrub_all; do \ echo " INSTALL /sbin/$i"; \ /usr/bin/install -c $i /tmp/e2fs/sbin/$i; \ done INSTALL /sbin/e2scrub INSTALL /sbin/e2scrub_all for i in e2scrub.8 e2scrub_all.8; do \ for j in gz bz2 bz Z; do \ /bin/rm -f /tmp/e2fs/usr/share/man/man8/$i.$j; \ done; \ echo " INSTALL_DATA /usr/share/man/man8/$i"; \ /usr/bin/install -c -m 644 $i /tmp/e2fs/usr/share/man/man8/$i; \ done INSTALL_DATA /usr/share/man/man8/e2scrub.8 INSTALL_DATA /usr/share/man/man8/e2scrub_all.8 for i in e2scrub.conf; do \ echo " INSTALL_DATA /etc/$i"; \ /usr/bin/install -c -m 644 $i /tmp/e2fs/etc/$i; \ done INSTALL_DATA /etc/e2scrub.conf make[1]: Verzeichnis „/home/lfs/e2fsprogs-1.45.0/build/scrub“ wird verlassen ... $ ls -la /tmp ... drwxr-xr-x 7 root root 4096 13. Mai 08:00 e2fs drwxr-xr-x 2 root root 4096 13. Mai 08:00 e2fsyes ... Strange, isn't it? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] e2fsprogs + crond
Hi all, i just started a build of a new system. To my surprise, it failed in chap6 at e2fsprogs where it never stopped before. The reason for stopping is ake[1]: Leaving directory '/autolfs/sources/e2fsprogs-1.45.0/build/po' making install in scrub make[1]: Entering directory '/autolfs/sources/e2fsprogs- 1.45.0/build/scrub' MKDIR_P /usr/lib/e2fsprogs MKDIR_P yes INSTALL yes/e2scrub_all /usr/bin/install: cannot create regular file 'yes/e2scrub_all': No such file or directory make[1]: *** [Makefile:447: install-crond] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory '/autolfs/sources/e2fsprogs- 1.45.0/build/scrub' make: *** [Makefile:434: install-progs-recursive] Error 1 make: *** Waiting for unfinished jobs make[1]: Leaving directory '/autolfs/sources/e2fsprogs- 1.45.0/build/lib/et' making install-shlibs in lib/ss make[1]: Entering directory '/autolfs/sources/e2fsprogs- 1.45.0/build/lib/ss' A look to the build/Makefile showed HAVE_UDEV = no UDEV_RULES_DIR = HAVE_CROND = yes CROND_DIR = yes HAVE_SYSTEMD = no SYSTEMD_SYSTEM_UNIT_DIR = Note the setting of CROND_DIR. I checked the configure script and found in line ~14500 a check on option $with_crond_dir=[yes,no]. If not set, yes is assumed. Later on, in case $with_crond_dir == yes, the test if /etc/cron.d exists and set with_crond_dir to /etc/cron.d if the directory is there. It remains "yes" if that directory does not exist. I assume that is the reason why CROND_DIR set to "yes" in the Makefile. What i really do not understand is why that happens now and never before? We have e2fsprogs-1.45.0 a good amount of time in the book, there is nothing new but if my reading of the configure script is correct, there is a fulminant logical error in it. Wonder why that never came up before. What do you think, am i right in interpreting the section in the configure script that there is a logical bug in it? If so, i do not get it why it comes up now and not at all the previous builds too... Btw, i specified --with-crond-dir=no and compilation/installation of e2fsprogs went fine. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib LFS and other variants
Am Donnerstag, den 02.05.2019, 21:23 +0100 schrieb Ken Moffat via lfs- dev: > On Thu, May 02, 2019 at 09:39:44PM +0200, Thomas Trepl via lfs-dev wrote: > > Regarding pkgmngt, i started a project for my own to see&learn how > > pkgmngt may work. There is no heavy development on > > https://www.belfs.org since its a one-man- and spare-time show but it > > works for me so far and a new rework will come up these days. > > Certificate seems to be only valid for ispgateway (or perhaps only > for its webserver) - firefox dislikes it because it is not valid for > www.belfs.org, reporting "The certificate is only valid for ." > > Looking at it 'Could not verify this certificate because the issuer > is unknown.' > > Error code: MOZILLA_PK1X_ERROR_SELF_SIGNED_CERT. > Ouch ... fixed. I redirected from http to https first and than to https at io.ax.lt. There is a valid cert. The first redirect was no good and now it goes directly to io.ax.lt regardless if you request http or https. Thanks! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib LFS and other variants
Am Freitag, den 03.05.2019, 01:58 +1000 schrieb James B via lfs-dev: > Hi guys, > > 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 website. I've also seen > comments about "LFS with package management" but I've never actually seen the > book. > > These are two that I'm aware, and there may be others. However, I want to > highlight that googling "LFS multilib" doesn't bring me anywhere, > specifically it doesn't bring up Thomas work. Could it be because there is no > link from LFS main website to his? If I want to access Thomas website I need > to know the exact URL: http://www.linuxfromscratch.org/~thomas/multilib/ Yes, thats the link currently shows the "ML-enabled" book. It may be a bit beind the 'real' LFS book because i have to merge trunk from time to time into the ML-branch. Thats currently manual work and i do not believe that automated merge+commit will work stable. I'm really happy and feel honored (hope that its ok since its translated word by word from german "ich fühle mich geehrt") that my - and others! - work is somehow recognized. I assume that your interest in ML does not come out of the blue. It would be interesting to know something about the reason why you are searching for ML stuff. The answer might help to optimize the ML stuff and even more, if you have trouble building the ML system or trouble while using it (e.g. missing core libraries and such). > My apology if this has already been done; but if it has not, may I suggest > that we put a link from somewhere in LFS website to these? I understand that > they aren't official LFS works or projects (not on the same level as BLFS, > CLFS or ALFS), so the links should be marked as such; nevertheless, they're > valuable reference in their own right. Making these variants accessible from > the main site would be helpful for others. Well, yes, some kind of ML-enabled BLFS will be the next step. On the way to get my printer driver (32bit from DELL) working, at least nettle has to be built with -m32 ... Regarding pkgmngt, i started a project for my own to see&learn how pkgmngt may work. There is no heavy development on https://www.belfs.org since its a one-man- and spare-time show but it works for me so far and a new rework will come up these days. DJ has published some work on pacman for LFS. You may check https://github.com/djlucas/LFS-systemd-pacman for that. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc9 test log
Am Mittwoch, den 24.04.2019, 10:04 -0500 schrieb Bruce Dubbs via lfs- dev: > On 4/24/19 12:34 AM, Thomas Trepl via lfs-dev wrote: > > Am Mittwoch, den 24.04.2019, 00:21 -0500 schrieb Bruce Dubbs via lfs- > > dev: > > > On 4/24/19 12:05 AM, Thomas Trepl via lfs-dev wrote: > > > > Hi, > > > > > > > > just for interest/fun I build a "full featured" gcc-9 including ada > > > > and all other available frontends. Note that there is a new language > > > > frontend for 'D' :-) > > > > > > > > All in all, it does not look bad, what do you think? > > > > > > Yes, looks pretty good. How long did it take to doo all that? Build > > > and installed sizes? > > > > > > -- Bruce > > > > My scripts reported > > > > INFO : 00:17:41 +--- > > INFO : 00:17:41 | Module ... gcc9 > > INFO : 00:17:41 | Duration . 13855 seconds > > INFO : 00:17:41 | SBU .. 144.32 > > INFO : 00:17:41 | Build size ... 12.5 GB > > INFO : 00:17:41 | Test size + 1.1 GB > > INFO : 00:17:41 | Bin size . 3.8 GB > > INFO : 00:17:41 | Total size ... 17.4 GB > > INFO : 00:17:41 +--- > > > > so it last nearly 4 hours using 4 cores in a VM with 4GB RAM. The > > 'Total size' includes everything, source, binaries and logfiles and so > > on. > > Thanks a lot. When gcc9 gets released, these numbers can be listed for > informative purposes even though we will probably not recommend building > everything. > >-- Bruce Yes, its an rough estimate. The above numbers (the duration) includes the test run (make -k check). Without, duration went down to 7464sec (77.75 SBU). And all this*) numbers are for a multilib-enabled gcc (m32 as well as mx32). A native 32bit gcc (of course non-multilib) lasts 5744sec (59.83 SBU) to build without check, but also including all available languages. -- Thomas *) to the native speakers: is 'this numbers' here correct or should it read 'these numbers' ? -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc9 test log
Am Mittwoch, den 24.04.2019, 00:21 -0500 schrieb Bruce Dubbs via lfs- dev: > On 4/24/19 12:05 AM, Thomas Trepl via lfs-dev wrote: > > Hi, > > > > just for interest/fun I build a "full featured" gcc-9 including ada > > and all other available frontends. Note that there is a new language > > frontend for 'D' :-) > > > > All in all, it does not look bad, what do you think? > > Yes, looks pretty good. How long did it take to doo all that? Build > and installed sizes? > >-- Bruce My scripts reported INFO : 00:17:41 +--- INFO : 00:17:41 | Module ... gcc9 INFO : 00:17:41 | Duration . 13855 seconds INFO : 00:17:41 | SBU .. 144.32 INFO : 00:17:41 | Build size ... 12.5 GB INFO : 00:17:41 | Test size + 1.1 GB INFO : 00:17:41 | Bin size . 3.8 GB INFO : 00:17:41 | Total size ... 17.4 GB INFO : 00:17:41 +--- so it last nearly 4 hours using 4 cores in a VM with 4GB RAM. The 'Total size' includes everything, source, binaries and logfiles and so on. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] gcc9 test log
Hi, just for interest/fun I build a "full featured" gcc-9 including ada and all other available frontends. Note that there is a new language frontend for 'D' :-) All in all, it does not look bad, what do you think? -- Thomas cat <<'EOF' | LAST_UPDATED: Obtained from SVN: trunk revision 270485 === acats tests === === acats Summary === # of expected passes2320 # of unexpected failures0 Native configuration is x86_64-pc-linux-gnu === gcc tests === Running target unix FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2 === gcc Summary === # of expected passes139578 # of unexpected failures1 # of expected failures 536 # of unsupported tests 2146 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/xgcc version 9.0.1 20190421 (experimental) (GCC) === gdc tests === Running target unix === gdc Summary === # of expected passes29394 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/gdc version 9.0.1 20190421 (experimental) (GCC) === gfortran tests === Running target unix === gfortran Summary === # of expected passes50213 # of expected failures 188 # of unsupported tests 94 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/gfortran version 9.0.1 20190421 (experimental) (GCC) === g++ tests === Running target unix === g++ Summary === # of expected passes134395 # of expected failures 528 # of unsupported tests 5871 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/xg++ version 9.0.1 20190421 (experimental) (GCC) === gnat tests === Running target unix === gnat Summary === # of expected passes2981 # of expected failures 23 # of unsupported tests 3 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/gnatmake version 9.0.1 20190421 (experimental) === go tests === Running target unix FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments === go Summary === # of expected passes7349 # of unexpected failures1 # of expected failures 1 # of untested testcases 6 # of unsupported tests 1 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/gccgo version 9.0.1 20190421 (experimental) (GCC) === obj-c++ tests === Running target unix === obj-c++ Summary === # of expected passes1458 # of expected failures 10 # of unsupported tests 77 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/xg++ version 9.0.1 20190421 (experimental) (GCC) === objc tests === Running target unix === objc Summary === # of expected passes2797 # of expected failures 6 # of unsupported tests 68 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/xgcc version 9.0.1 20190421 (experimental) (GCC) === gotools tests === === gotools Summary === # of expected passes419 # of untested testcases 190 === libatomic tests === Running target unix === libatomic Summary === # of expected passes54 === libffi tests === Running target unix === libffi Summary === # of expected passes2214 === libgo tests === Running target unix FAIL: runtime/pprof === libgo Summary for unix === # of expected passes183 # of unexpected failures1 Running target unix/-m32 === libgo Summary for unix/-m32 === # of expected passes184 Running target unix/-mx32 FAIL: runtime/pprof === libgo Summary for unix/-mx32 === # of expected passes183 # of unexpected failures1 === libgo Summary === # of expected passes550 # of unexpected failures2 === libgomp tests === Running target unix === libgomp Summary === # of expected passes6499 # of expected failures 4 # of unsupported tests 349 === libitm tests === Running target unix === libitm Summary === # of expected passes42 # of expected failures 3 # of unsupported tests 1 === libphobos tests === Running target unix === libphobos Summary === # of expected passes750 === libstdc++ tests === Running target unix FAIL: 22_locale/time_get/get_time/char/2.cc execution test FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test FAIL: 22_locale/time_get/get_time/wchar_
Re: [lfs-dev] Our perl builds are not hardened
Am Dienstag, den 23.04.2019, 04:09 +0100 schrieb Ken Moffat via lfs- dev: > On Thu, Apr 18, 2019 at 10:59:04PM +0100, Ken Moffat wrote: > > I was looking through my logs to identify which packages do not use > > my CFLAGS, CXXFLAGS (thinking about trying LTO at some point) and > > reading the voluminous output from perl's Configure I noticed: > > > > Guessing which symbols your C compiler and preprocessor define... > > You seem not to have gcc 4.* or later, not adding -D_FORTIFY_SOURCE. > > > > That is because 5.28.1 has the following: > > > > case "$gccversion" in > > [4567].*) case "$optimize$ccflags" in > > > > Using > > sed -i 's/^\(\[4567\)/\18/' Configure > > gives me > > > > Guessing which symbols your C compiler and preprocessor define... > > Adding -D_FORTIFY_SOURCE=2 to ccflags... > > > > ĸen > > This still applies to 5.28.2. I guess that distros such as fedora > and Arch have not reported this upstream because they *always* force > their own CFLAGS which include a -DFORTIFY_SOURCE setting. > > ... Is there a reason why we won't add that sed to the book? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] multilib book SVN-20190327
Am Dienstag, den 16.04.2019, 20:00 +0100 schrieb spiky0011 via lfs- dev: > Hello > > Just going through multilib book > > at ch5.7 glibc running sanity check for -mx32 > > I get wrong output > > [Requesting program interpreter: /tools/libx32/ld-linux-x32.so.2] > > not > > [Requesting program interpreter: /tools/lib/ld-linux-x32.so.2] > > ls -l tools/lib/ld-linux-x32.so.2 > > tools/lib/ld-linux-x32.so.2 -> /tools/libx32/ld-linux-x32.so.2 > > I have rebuilt from scratch a couple of times but always the same output? > > The 64 part is ok and the -m32 is ok. > > All commands were copy & paste. > Thanks for reporting this. That was a copy&paste error. Sorry that you had to waste some (cpu-)seconds with that. I fixed that along with a merge of upstream changes. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Multilib branch
Hi all, for those who are interested in multilib-LFS: A branch of the current trunk has been created and now contains all modifications to support m32 as well as mx32. Browse the sources at http://wiki.linuxfromscratch.org/lfs/browser/branches/multilib and find the rendered book at http://www.linuxfromscratch.org/~thomas/multilib/ Trunk will be merged into this branch from time to time, currently not in an automated way but manually. The book will be rendered once a day (if changes are made). The stuff on https://io.ax.lt/ will be still available for a while but will disappear there some day. The ML part is now maintained in the new branch only. There is something new: Previously, to render the ML-book the Makefile accepted an option "ARCH=multilib" which then causes the ML-stuff to be included. Now, you can specify which arch should be in: make ARCH=ml_32Includes 32 bit extensions (-m32) only make ARCH=ml_x32 Includes x32 bit extensions (-mx32) only make ARCH=ml_all Includes both So, if you have used "make ARCH=multilib", just replace it by "make ARCH=ml_all" and result should be same. If you need m32 instructions only, use "make ARCH=ml_32". -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Instruction on a wrong page?
Am Sonntag, den 07.04.2019, 14:14 +0200 schrieb Pierre Labastie via lfs-dev: > Is there a reason why the instruction: > "install -vdm755 /usr/lib/pkgconfig" > is on the "6.6. Creating Essential Files and Symlinks" page, > and not in "6.5. Creating Directories"? Don't see a reason why it is in "Creating Files" instead of "Creating Directories", too. Would say it could be moved. > This lead to another question: should we use "install" or "mkdir -pv" in > "Creating Directories"? Actually, for pedagogical reasons, keeping both is not > bad, but, although I do not remember why, I have a vague memory that "install" > should be preferred. Maybe install is preferred because you can specify permission flags and ownership right with the command. Using mkdir would create the dir with default permissions and then you have to use a second or even third command to set permissions and/or ownership. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Patching LFS XML sources: SVN insight required
Am Sonntag, den 31.03.2019, 10:04 +0800 schrieb Kevin Buckley via lfs- dev: > Hi there, > > I'd be interested in some feedback, should anyone have a chance to > look at things, as to how best to leverage SVN to add "mutiple > rendering pathways", so let me expand on that. > > The build system for the vanilla LFS book already has the ability to > branch on SysV or SysD. > > Thomas's patch adds multilib capability to either of those pathways. > > I am looking to apply a "PkgUser" (the More Control hint) approach > on top of that. > > My local (file-backed) SVN repo contains a mix of direct PkgUser > modifications, along with things such as > > 2>&1 | tee ../make.out > > being added into (hopefully) all of the various make commands, so including > the "make check/test" and "make install" stuff. > > I also make a few changes to blocks so as to remove some > things from the output generated by the book's Makefile's dump-commands > target. As you surly have seen, the ML stuff is controlled via 'arch="multilib"' or 'arch="default"' profiling attributes in the books sources. Using them made it possible to switch on/off the ML modifications at rendering time by setting a parameter to 'make'. So if set to "default", the rendering output should be exactly the output you get when using the original book and not using ML at all. You may use such a profiling attribute for your modifications as well but unfortunatly, docbook in the used version has only a limited set of those attrs while its possible to introduce own ones. > > What's not been clear to me in trying to store changes within my local > SVN repo is how to seperate things out so that for example, i could > apply a "PkgUser" SVN diff to a vanilla LFS XML source tree if it > hadn't had Thomas's Multilib patch already applied. > > Another one along the same lines is the make redirection stuff that > I add into my own books. That is what kept me busy for a while to get things done like you described. Goal was to minimze the impact on the "infrastructure" of the book (modifying the Makefile etc), simply be as much "compatible" as possible. Even jhalfs (with a few modifications DJ made) runs on the ML-variant. Finally, I end up with: Create a local copy of the LFS repository (svn checkout). This repo can be updated simply via "svn up". Than, i created a copy of the book (directory BOOK) and made my modifications there. A diff between this directory and the original repo is what is known as the multilib- patch. Same procedure is made for the so-called "belfs extensions" which are modifications i like to have in the book but which are surly nothing to ever go to the original book. For example, in this variant i use the base kernel sources and a patch to get them uptodate (linux- 5.0.tar.xz + patch-5.0.4.xz) simply to save diskspace and download time... To keep things uptodate, i run a script which does: - diff the ML working dir and the upstream repo and store the patch in a temporary location - diff the BELFS working dir and the upstream repo and store the patch in a temporary location - update the upstream repository (never to that before the first two steps has been made) - duplicate the original sources into the ML working dir (via rsync -- delete) - apply the temp-patch to it - create the ML-patch (now this patch is against the most recent original sources) - duplicate the original sources into the BELFS working dir - apply the temp-patch to it - create the BELFS-patch - duplicate the original sources into the "merged" working dir - apply the BELFS-patch to it - apply the ML-patch to it - copy the BELFS- and the ML-patch to my website This process runs every day at 04:45. I use the interdiff utils to see whether there are differences between the previous and the newly created patches. If none, the new patches are thrown away. The description sounds a bit complicated but usually the process runs well, from time to time some .rej are created. That happens if there are modifications made in the original repo which are in conflict with my modifications. Then i have to fix that manually. I use the "merged" book for building my machines. Problem in this approach is that i cannot track my modifications in a SVN repository since the BELFS and the ML copies are simple file copies and are not under SVN control. The only history i have is that i keep the previously created patches. Next step will be to make a branch in the original repository for the ML part. > > Whilst that's not realy PkgUser specific, i could see that a standlone > SVN diff that applied just that might be useful to some folk, but again > it's not clear how to seperate things out when using SVN across the > two "regimes" I am adding stuff on top off, namely, the vanilla LFS and > the Multilib additional source. > > Any pointers/insight welcome. > Kevin > > PS > I have a rendering of my current book but am yet to stick it up on > the internet in case anyone wnats to take a look.:
Re: [lfs-dev] Multilib patch: ncurses 64-bit build wants to use /usr/lib32/pkgconfig
Am Samstag, den 23.03.2019, 17:39 +0800 schrieb Xi Ruoyao via lfs-dev: > On Sat, 2019-03-23 at 16:48 +0800, Kevin Buckley via lfs-dev wrote: *snip* > > Anyroad, just came to do Chapter 6 ncurses after applying Thomas's patch > > (note also I am doing a PkgUser build) and saw > > > > ** Configuration summary for NCURSES 6.1 20180127: > > > >extended funcs: yes > >xterm terminfo: xterm-new > > > > bin directory: /usr/bin > > lib directory: /usr/lib > > include directory: /usr/include > > man directory: /usr/share/man > >terminfo directory: /usr/share/terminfo > > pkg-config directory: /usr/lib32/pkgconfig > > > > and was surprised by the 32-bit Pkg-conf dir. > > *snip* > > > and so I thimk that the ncurses configure search "falls through" to > > /usr/lib32 > > where it finds a directory named 'pkgconfig' > > > > The suggestion in the Ncurses build is that one can explicitly specify the > > pkg-config directory by using a flag to ./configure. > > Yes. --with-pkg-config-libdir=/usr/lib64/pkgconfig would work. > > > Maybe that's something Thomas needs to add to his patch ? Thanks Kevin and Xi, good spot! Also the symlinks created later in that chapter for ncurses, form, panel and menu are invalid as ncursesw.pc does not exist in /usr/lib. I think I have to add --with-pkg-config-libdir=/usr/lib/pkgconfig (not .../lib64/...) since we do not have a /usr/lib64 at all, /usr/lib is the 'default' for 64bit. For the 32bit builds, this configure argument is set allready. Alternativly, we could do a sed to remove lib32 in configure for the *64 case: sed -e "/cf_path\/lib64/{n;d}" -i configure but i think the configure argument is less intrusive and works well. ML-patch is modified. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch
Am Mittwoch, den 20.02.2019, 18:03 +0800 schrieb Kevin Buckley via lfs-dev: > Just wanted to tidy up the "loose end" here by saying that I did get an LFS > that was able to build Xen 4.10 going by using the Mutlilib patch against > LFS 8.3, and all this using a PkgUser approach. > > I have been tracking the changes I made in a local SVN, but am thinking > that I will wait for the 8.4 release before trying to feedback anything into > the > community. > > Thanks again for the MultiLib patch and feedback in this thread. > Kevin Cool stuff and thanks for the feedback - this one and the one may come! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch
Am Mittwoch, den 20.02.2019, 18:03 +0800 schrieb Kevin Buckley via lfs-dev: > Just wanted to tidy up the "loose end" here by saying that I did get an LFS > that was able to build Xen 4.10 going by using the Mutlilib patch against > LFS 8.3, and all this using a PkgUser approach. > > I have been tracking the changes I made in a local SVN, but am thinking > that I will wait for the 8.4 release before trying to feedback anything into > the > community. > > Thanks again for the MultiLib patch and feedback in this thread. > Kevin Cool stuff and thanks for the feedback! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-support] LFS 8.4 rc
Am Samstag, den 16.02.2019, 18:45 +0100 schrieb Pierre Labastie via lfs-dev: > On 2/16/19 6:19 PM, Bruce Dubbs via lfs-dev wrote: > > On 2/16/19 9:08 AM, Thomas Trepl via blfs-support wrote: > > > Am Samstag, den 16.02.2019, 15:18 +0100 schrieb Gerhard Gedigk via > > > blfs-support: > > > > Hello, > > > > > > > > please correct the example for the German console fonts. (7.6.5) > > > > > > > > KEYMAP="de-latin1" # is correct > > > > > > > > FONT="lat0 ... needs to be changed to lat1 as well. > > > > This is needed to display the special characters for the German > > > > language correctly. > > > > > > > > Thank you > > > > Gerhard > > > > > > I have > > > > > > - > > > # Begin /etc/sysconfig/console > > > > > > UNICODE="1" > > > KEYMAP="de-latin1" > > > KEYMAP_CORRECTIONS="euro2" > > > > > > #FONT="lat0-16 -m 8859-15" > > > FONT="Lat2-Terminus16 -m 8859-15" > > > > > > # End /etc/sysconfig/console > > > - > > > > > > in my /etc/sysconfig/console. Note the UNICODE="1". With this, lat0-16 > > > works fine, while my favorite font is the Terminus. > > > > > > Would you try it with UNICODE=1 again and tell the result? > > > > > > Btw, thats something for LFS-support, not BLFS-support. Lets continue > > > talking there. > > > > Replying to both blfs-dev and lfs-dev. Please answer on lfs-dev. > > > > I am not familiar with the requirements for the German console. I > > checked for 'lat0' in the book and fond it in two places, both sysV only: > > > > lfs-bootscripts, specifically in rc.site, but commented out. > > > > 7.6. System V Bootscript Usage. > > 7.6.5. Configuring the Linux Console > > > > We can change the reference in Chapter 7 before the release of 8.4, > > but I do not want to change the bootscripts until after release of 8.4, > > > > Let me know what the exact changes are needed. > > > For French, I have: > > UNICODE="1" > KEYMAP="fr-latin9" > FONT="lat0-16" > > That is enough. But when I set font to Lat2-Terminus16, many characters > don't display OK, for example €, û, ö... > > (even with -m 8859-15). > > Pierre Strange that Lat2-Terminus16 does not work well for french. All in all, i think adding UNICODE="1" to the example for german keyboard should be fine (to solve Gerhards issue). Maybe he tries that and tells us the result. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Python 3.7.2 build errors using Glibc 2.29
Am Samstag, den 09.02.2019, 23:45 -0800 schrieb Brandon Murry via lfs- dev: > Hi, I hope this is the right place to put this. > I've been attempting to build Linux From Scratch from the development book > using Systemd. One of the big new changes is an early build of Python 3.7.2 > for the newest version of Glibc 2.29. I've tried this about 6 times trying > all different setups within the host environment. Compiling Python 3.7.2 > during chapter 5 produces a ton of "error: unknown type name" for standard C > libraries. > Python fails to build the majority of it's modules. When Glibc is rebuilt > during chapter 6, it fails due to missing Python modules. Haven't seen any > hints about this from LFS or on the net, so curious to see if I'm the only > one having this issue. > Thanks, > Brandon Whats your host system? (Distro, architecture etc.) Did you run the check script of chapter 2.2 ? Can you provide a snippet of the log where the errors are shown? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Updates to lfs
Am Freitag, den 01.02.2019, 12:01 -0600 schrieb Bruce Dubbs via lfs- dev: > Just a heads up. I am in the process of updating all current packages > in the ticket system except systemd (7 packages including a new glibc). > > Glibc now requires Python-3.4 or later so that will be going into > Chapter 5 and requires an update to the host system requirements. Why do we build python3 after glibc in chap-5 then? That would require to have P3 on host system (which usually is) but can't we get rid of that dependency if building P3 before glibc? > > Checking against lfs-8.3, that brings us to 33 new packages in this > cycle not including an expected update to binutils in the next day or > two. Our normal number of updates in a six month cycle is about 28 > packages. In addition, there may be some other new packages released > before the lfs-8.4 package freeze scheduled for Feb 14. > > I expect the current set of updates to be committed later today. > >-- Bruce -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] perl install dirs
Hi all, here a question about install directories of perl. Currently, an installation of perl results in a structure like /usr +---> lib +---> perl5 +---> 5.28.0 +---> site_perl +---> 5.28.0 Installed perm modules seems to go mainly in /usr/lib/perl5/site_perl/5.28.0 and some files in /usr/lib/perl5/5.28.0. As we do not specify any pathes to the Configure command to perl, it seems that this is the default. The reason why i ask is what happens when perl gets upgraded (from 5.28.0 to 5.28.1). Looks like the result is a structure like /usr +---> lib +---> perl5 +---> 5.28.0 +---> 5.28.1 +---> site_perl +---> 5.28.0 +---> 5.28.1 Are the modules installed in the */5.28.0 directoies still available to perl or are they "lost" and need to be reinstalled in order to get placed into the */5.28.1 directories? Or does perl automatically recognize those multible directories? There are several options to the Configure script of perl (-Dprivlib -Darchlib -Dsitelib -Dvendorlib etc.) which seems to have influence on the final directory structure. Could the usage of those options ease the upgrade of perl (without having to rebuild the modules (if required))? (All those are dump questions as I'm really not an perl expert but i have the strong feeling that an in-place-upgrade of perl somehow breaks installed modules.) Whats your opinion? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch: Chapter 6 ISL/GCC instructions
Am Sonntag, den 13.01.2019, 12:48 +0800 schrieb Kevin Buckley via lfs- dev: > More of a heads up than somethng likley to affect most LFS builders, > but just to point out that one of the last commands in the GCC section > does the following > > = > Finally, move a misplaced file: > > mkdir -pv /usr/share/gdb/auto-load/usr/lib > mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib > == > > > however by the time you have reached that point in the > Multilib buid, there are actually two files matching > > /usr/lib/*gdb.py > > as the standalone ISL install has created > > /usr/lib/libisl.so.19.1.0-gdb.py > > to go along with GGC's > > /usr/lib/libstdc++.so.6.0.25-gdb.py > > > To my mind then, the directory creation should be really > being done as part of the ISL section, with the misplaced > file from that package being moved there then. > > > FYI: > > I only noticed this as I'm following a PkgUser build process, > and saw that the GCC PkgUser wasn't able to move the > file that had been created by the ISL PkgUser > > Hoping that's useful to someone, > Kevin I modified the patch to move those files at ISL and GCC separatly. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch
Am Sonntag, den 06.01.2019, 14:16 +0800 schrieb Kevin Buckley via lfs- dev: > A web search for my GCC-internal zlib config error > > configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES > > turned up, amongst others, these two, the first of which results from > an LFS build ! > > https://stackoverflow.com/questions/46487529/crosscompiling-gcc-link-tests-are-not-allowed-after-gcc-no-executables-when-che > > https://github.com/easybuilders/easybuild-easyconfigs/issues/3964 > > > The second of those suggests that it may be the lack of a "multilib capable" > toolchain ON THE HOST that is the issue for me? No, i've just tested building it from an LFS-8.2 without ML. That is what chapter 5 is for - make us (more or less) independent from host. > With that in mind, I'm coming back to my original remarks about rebuidling > in that: > > the way I last "upgraded" an x86_64 LFS to have multilib capibilty was by > following one of DJ's old books, wherein things were effectively done in > these stages: > > x86_64 host -> x86_64 LFS-tools > x86_64 LFS-tools -> x86_64 LFS > x86_64 LFS -> Multilib LFS-tools components > Multilib LFS-tools -> Multilib LFS components > > Indeed, after the Binutills pass1 now, the only file in /tools/bin are > > > x86_64-lfs-linux-gnu-addr2line x86_64-lfs-linux-gnu-nm > x86_64-lfs-linux-gnu-ar x86_64-lfs-linux-gnu-objcopy > x86_64-lfs-linux-gnu-as x86_64-lfs-linux-gnu-objdump > x86_64-lfs-linux-gnu-c++filtx86_64-lfs-linux-gnu-ranlib > x86_64-lfs-linux-gnu-elfeditx86_64-lfs-linux-gnu-readelf > x86_64-lfs-linux-gnu-gprof x86_64-lfs-linux-gnu-size > x86_64-lfs-linux-gnu-ld x86_64-lfs-linux-gnu-strings > x86_64-lfs-linux-gnu-ld.bfd x86_64-lfs-linux-gnu-strip > > suggesting that any non-x86_64 stuff has to come from the host ? There is not much to see in ch5-binutils-pass1. > > Then again, you've stated that your sucessful build came from an > non-multilib host. Yes, see above. > FYI, my host (Ubuntu 1404 - yes. old, yes) has > > Binutils: (GNU Binutils for Ubuntu) 2.24 > gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4 > (Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19 > > so is a little diferent to what the Multilib book suggests things > have been tested against, bis: > > Binutils-2.25 (Versions greater than 2.31.1 are not recommended as > they have not been tested) > GCC-4.9 including the C++ compiler, g++ (Versions greater than 8.2.0 > are not recommended as they have not been tested) > Glibc-2.11 (Versions greater than 2.28 are not recommended as they > have not been tested) H, usually we do not dig around in issues with hosts doesn't match the requirements. Anyway, the "oldest" thing i have around is a CentOS7. Tried to build there, but failed with quite simmilar messages at ch5-gcc-pass1. > I think I may find the best way forwards to be one in which I build an > non-Multilib LFS 8-3 > and then use that to boostrap the Multilib one, as that would give me > a "host" with > > Binutils-2.31.1 > GCC-8.2.0 > Glibc-2.28 Thats what I'd suggest - then we have a well defined environment. Make sure that the running kernel is 32-bit-enabled [*] 64-bit kernel ... Executable file formats / Emulations ---> [*] IA32 Emulation [*] x32 ABI for 64-bit mode > > Just out of interest then, what are the Binutils, GCC, Glibc versions on > the "non-multilib" host that your Multilib buils suceeds ? The only non-ML (but kernel is 32bit-enabled) i have around is a LFS- 8.1+ machine which is actually from 2018/01/01. gcc is 7.2.0, glibc is 2.26, binutils-2.29.1. There the built ran smoothly. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch
Hi Kevin, Am Samstag, den 05.01.2019, 18:56 +0800 schrieb Kevin Buckley via lfs- dev: > ... > > Failed at the second hurdle. > > The first GCC pass gets as far, in the `make`, as building the included zlib > and, whilst configuring that, ends with > Adding multilib support to Makefile in ../../zlib > multidirs=32 x32 > with_multisubdir= > Running configure in multilib subdirs 32 x32 > pwd: /home/lfs/gcc-8.2.0/build/zlib > Running configure in multilib subdir 32 > pwd: /home/lfs/gcc-8.2.0/build > mkdir 32 > configure: creating cache ./config.cache > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking target system type... x86_64-lfs-linux-gnu > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for x86_64-pc-linux-gnu-strip... no > checking for strip... strip > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether to enable maintainer-specific portions of Makefiles... no > checking for x86_64-pc-linux-gnu-gcc... gcc -m32 > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc -m32 accepts -g... yes > checking for gcc -m32 option to accept ISO C89... unsupported > checking for style of include used by make... GNU > checking dependency style of gcc -m32... gcc3 > checking how to print strings... printf > checking for a sed that does not truncate output... /bin/sed > checking for grep that handles long lines and -e... /bin/grep > checking for egrep... /bin/grep -E > checking for fgrep... /bin/grep -F > checking for ld used by gcc -m32... ld -m elf_x86_64 > checking if the linker (ld -m elf_x86_64) is GNU ld... yes > checking for BSD- or MS-compatible name lister (nm)... nm > checking the name lister (nm) interface... BSD nm > checking whether ln -s works... yes > checking the maximum length of command line arguments... 3458764513820540925 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... yes > checking for ld -m elf_x86_64 option to reload object files... -r > checking for x86_64-pc-linux-gnu-objdump... objdump > checking how to recognize dependent libraries... pass_all > checking for x86_64-pc-linux-gnu-ar... ar > checking for x86_64-pc-linux-gnu-strip... strip > checking for x86_64-pc-linux-gnu-ranlib... ranlib > checking command to parse nm output from gcc -m32 object... failed > checking how to run the C preprocessor... /lib/cpp > checking for ANSI C header files... no > checking for sys/types.h... no > checking for sys/stat.h... no > checking for stdlib.h... no > checking for string.h... no > checking for memory.h... no > checking for strings.h... no > checking for inttypes.h... no > checking for stdint.h... no > checking for unistd.h... no > checking for dlfcn.h... no > checking for objdir... .libs > checking if gcc -m32 supports -fno-rtti -fno-exceptions... no > checking for gcc -m32 option to produce PIC... -fPIC -DPIC > checking if gcc -m32 PIC flag -fPIC -DPIC works... yes > checking if gcc -m32 static flag -static works... no > checking if gcc -m32 supports -c -o file.o... yes > checking if gcc -m32 supports -c -o file.o... (cached) yes > checking whether the gcc -m32 linker (ld -m elf_x86_64 -m elf_i386) > supports shared libraries... yes > checking dynamic linker characteristics... configure: error: Link > tests are not allowed after GCC_NO_EXECUTABLES. > make[1]: *** [configure-zlib] Error 1 > make[1]: Leaving directory `/media/sda5/home-lfs/gcc-8.2.0/build' > make: *** [all] Error 2 > > > Has my applying the Multilib patch not done all it should - it applied cleanly > as I noted above. If it applied cleanly, then it should have touched everything needed. Strange enough - i cannot reproduce this issue, just did a build on a non-multilib host and it goes fine (so far, now at gcc-pass2 in chap- 5). Can you have a look into the config.log file - maybe there is something more informative? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] VirtualBox running on LFS
Am Sonntag, den 18.11.2018, 23:35 + schrieb Ken Moffat via lfs- dev: > On Sun, Nov 18, 2018 at 10:52:54PM +0100, Thomas Trepl via lfs-dev wrote: > > Hi all, > > > > today VirtualBox started on a LFS host and i was able to start a VM > > with it. I'm definitely not saying it is fully functional, much more > > testing and bug fixing might be required for that. It is for sure not > > "production ready" yet as some errors are still there. It does not > > work to start machines using the GUI, but it is possible to start them > > using the CLI tool "VBoxManage". So i think its some kind of > > configuration issue, fundamently it seems that VBox is working. > > Cool, and congratulations. Just one question. > > > Well, i forgot that the kernel i run > > wasn't 32-bit enabled. Booting the right kernel, all was fine again. > > In kernel config, don't forget to set > > > >Executable file formats / Emulations ---> > > [*] IA32 Emulation > > < |M|*> IA32 a.out support > > [*] x32 ABI for 64-bit mode > > > IA32 is clearly needed for 32-bit support, no argument about that. > > But x32 is a different thing entirely, and I wonder if anybody > (except gentoo and perhaps debian) use it ? In particular, gcc and > g++ need -mx32. > > https://en.wikipedia.org/wiki/X32_ABI > > But I see that you do have libx32 in your diff, so perhaps you > really are using it. mx32 is in the patch more or less just to have it. I also do not need it for the VirtualBox stuff. It was more an exercise when doing multilib as the configure options and CFLAGS are different to m32 as well as to m64. Alain was interested in mx32 to limit memory usage of tasks to 4GB on a large system with 32 or 64 GB memory. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] VirtualBox running on LFS
Hi all, today VirtualBox started on a LFS host and i was able to start a VM with it. I'm definitely not saying it is fully functional, much more testing and bug fixing might be required for that. It is for sure not "production ready" yet as some errors are still there. It does not work to start machines using the GUI, but it is possible to start them using the CLI tool "VBoxManage". So i think its some kind of configuration issue, fundamently it seems that VBox is working. To come to that status was my "hobby" over the last months. I'm so proud about it so that I need to bug you with my little success story ;-) All my LFS development happens in VBox-VMs which are currently run by an ArchLinux host system. Because I still dislike systemd*) and this host is the only Linux system which is not LFS, i accepted the challenge to replace it (by LFS). Since VirtualBox needs 32-bit support (and a printer driver for my laser also does) it was required to patch the LFS book in the way that the instructions will produce a multilib supporting tool chain. A patch set has been created which applies to recent LFS books and rendering can be parameterized to include/exclude multilib support. Thanks especially to DJ for supporting me here, keeping track on the systemd side and providing fixes on the patches. If interested, you find the patch at https://io.ax.lt/LFS/lfs/patch-multilib-SVN.diff The rest is more or less business as usual, many package to install, some compiled as 32bit-binaries too. Here the list of installed packages: Miscellaneous: which pcre zip unzip lynx sqlite db apr apr-util libtirpc pam cyrus- sasl subversion serf nano belfs***) libxml2 libgpg-error libgcrypt libxslt sgml-common docbook-xml docbook-xsl docbook-dsssl tidy shadow openssh ca-certs lib32-nettle**) icu libldap(=openldap) libunistring libtasn1 nettle p11-kit gnutls libidn2 curl libarchive X11: xorg-config util-macros xorgproto libXau libXdmcp xcb-proto libxcb libpng libuv cmake harfbuzz freetype fontconfig xorg-libraries xcb-util xcb-util-image xcb-util-keysyms xcb-util-renderutil xcb-util- wm xcb-util-cursor libdrm wayland wayland-protocols llvm-libs llvm MesaLib glu xbitmaps xorg-apps xcursor-themes font-util graphite2 xorg-fonts xkeyboard-config libxkbcommon pixman libepoxy xorg-server libevdev mtdev xf86-input-evdev xf86-input-synaptics xf86-video-ati xf86-video-intel xf86-video-vboxvideo xf86-video-vesa twm xterm xclock xinit QT: pcre2 alsa-lib yasm libjpeg-turbo libmng libinput pciutils postgresql- client freeglut libtiff libevent mariadb-client libogg libvorbis flac libsndfile dbus glib gobject-introspection libical bluez sbc pulseaudio cdparanoia libtheora gstreamer gst-plugins-base libusb lib32-libusb xmlto xdg-utils lib32-gnutls lib32-libtasn1 lib32-p11-kit lib32-libidn lib32-libunistring cups lib32-cups**) qt VBox: cdrtools libIDL iasl SDL libvpx libaio libdevmapper(=llvm) gsoap libvncserver opus VirtualBox So all in all (beside from core LFS) about 140 packages. Some pitfalls: 32bit support: I wasted a good amount of time to figure out why suddenly glibc no longer compiles in lib32 mode (gcc -m32). I searched and searched and even asked on mailing list... Well, i forgot that the kernel i run wasn't 32-bit enabled. Booting the right kernel, all was fine again. In kernel config, don't forget to set Executable file formats / Emulations ---> [*] IA32 Emulation < |M|*> IA32 a.out support [*] x32 ABI for 64-bit mode VirtualBox: Build instructions stolen from ArchLinux but compilation always crashed while compiling vboxwebservice with quite strange error messages. Finally i found out that 4GB RAM isn't enough, the OOM- killer canceled gcc. I increased my VMs size to 8GB and it compiled fine. A photo of LFS running a quite old and strange (but cool) operating system can be found here: https://io.ax.lt/LFS/lfs-vbox-1024.png That OS is called "EUMEL", developed somewhere back in the 80's, its primary programming language is ELAN which is also the language used at command line. It is a multiuser and multitask OS running on Z80 CPUs before it was ported to x86. Again, this VBox on LFS is by far not running well atm. VirtualBox GUI starts fine and it presents me all my VMs but i cannot start them within the GUI. To start VMs i have to use "VBoxManage startvm ". But all in all i think the whole story shows that with LFS everything is possible ;-) Btw, there is no Python2 at all on this machine, everything compiles fine with Python3. -- Thomas *) don't want to start any discussions about this here as I do not really have other "arguments" than "don't like it" atm. I'm not able to argue on a technical basis... **) for the Dell printer driver ***) my own pkgmngr inspired by pacman. Just set up to see how package management will work (or not) -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information pag
Re: [lfs-dev] gcc fails to build
Am Freitag, den 09.11.2018, 10:19 -0600 schrieb Bruce Dubbs via lfs- dev: > On 11/09/2018 09:44 AM, Pierre Labastie via lfs-dev wrote: > > On 09/11/2018 14:30, Pierre Labastie via lfs-dev wrote: > > > On 09/11/2018 13:38, John Frankish via lfs-dev wrote: > > > > > As an aside, what is the first line of the current script meant to > > > > > expand to? > > > > > > > > > > $ for file in gcc/config/{linux,i386/linux{,64}}.h > > > > > > > > > > ... > > Hmm, sorry, I see that your system is tinycore64. AFAICS, there is no > > dash shell in tinycore (unless you compiled it). It seems to have only > > bash... But maybe it is a stripped down version of bash, not > > interpreting double {. Or maybe you are using busybox shell (testing it > > on debian shows it does not interpret the double {). > > The issue of dash vs bash should be handled in the version-check.sh > script. Maybe we add two lines to the version-check.sh: X=$( echo X{1,2{,.{1,2}}} ) [ "$X" == "X1 X2 X2.1 X2.2" ] || \ echo "ERROR: Shell doesn't handle brace expansion correctly" unset X or something like that... -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc fails to build
Am Freitag, den 09.11.2018, 11:15 + schrieb John Frankish via lfs- dev: > > > > > Ref: > > > > > > > > > > Linux From Scratch - Version SVN-20181029 Chapter 5. Constructing a > > > > > Temporary System 5.5. GCC-8.2.0 - Pass 1 > > > > > > > > > > Using the latest script to update the dynamic linker results in gcc > > > > > failing to build. > > > > > > > > > > Using a previous script fixes the problem. > > > > > > > > > > Details below. > > > > > > > > > > > > > > > > > > > > This script: > > > > > > > > > > for file in gcc/config/{linux,i386/linux{,64}}.h > > > > > do > > > > > cp -uv $file{,.orig} > > > > > sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \ > > > > > -e 's@/usr@/tools@g' $file.orig > $file > > > > > echo ' > > > > > #undef STANDARD_STARTFILE_PREFIX_1 > > > > > #undef STANDARD_STARTFILE_PREFIX_2 > > > > > #define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/" > > > > > #define STANDARD_STARTFILE_PREFIX_2 ""' >> $file > > > > > touch $file.orig > > > > > done > > > > > > > > > This script has been in the book for a couple of years. It is hard to > > > > believe that nobody else has seen a failure if it is wrong. > > > > > > > > Maybe your system is not recognized as either i386 or x86_64, or not as > > > > linux? > > > > > > > > Are you building on a Mac, Unix derivate or raspberry pi? What is the > > > > response of the " arch" command? > > > > > > > I'm building on a linux machine recognised as x86_64 and I > > > tried three separate times... > > > > > Could it be a copy/paste artifact, such as a space after '\' at the end > > of a line? > > GNU_TARGET_OS_etc is defined in gcc/config/linux.h, and shouldn't > > be modified by the said script; unless possibly if there is a typo. > > Sorry if I sound like the error comes from your side (script, our unusual > > system, I rule out LFS and LFS_TGT variable settings, since it seems to work > > with the old script), but really, after 2 years, somebody should have > > spotted > > the same error as you. > > > I don't think that the new script has been in use as much as two years, since > I last built using the LFS instructions a year ago with the old script. This > being said, yes, you would have thought that somebody else would have noticed > it. Wouldn't believe that editors update instructions of those essential tools without testing. Anyway, the scripts works, I just verified it in this minute here again... > It could be a copy paste error ... or something else in the build environment. I assume you double- checked a thousand times that all the envvars are set proper and the host-gcc is not damaged somehow? (well shouldn't - otherwise binutils wouldn't be compiled) > but I tried three times with the new script and it worked first time when > copy pasting the old script... Which shell are you using? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc fails to build
Am Freitag, den 09.11.2018, 07:55 + schrieb John Frankish via lfs- dev: > > > Ref: > > > > > > Linux From Scratch - Version SVN-20181029 > > > Chapter 5. Constructing a Temporary System > > > 5.5. GCC-8.2.0 - Pass 1 > > > > > > Using the latest script to update the dynamic linker results in gcc > > > failing to build. > > > > > > Using a previous script fixes the problem. > > > > > > Details below. > > > > > > > > > > > > This script: > > > > > > for file in gcc/config/{linux,i386/linux{,64}}.h > > > do > > > cp -uv $file{,.orig} > > > sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \ > > > -e 's@/usr@/tools@g' $file.orig > $file > > > echo ' > > > #undef STANDARD_STARTFILE_PREFIX_1 > > > #undef STANDARD_STARTFILE_PREFIX_2 > > > #define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/" > > > #define STANDARD_STARTFILE_PREFIX_2 ""' >> $file > > >touch $file.orig > > > done > > > > > This script has been in the book for a couple of years. It is hard to > > believe > > that nobody else has seen a failure if it is wrong. > > > > Maybe your system is not recognized as either i386 or x86_64, or not as > > linux? > > > > Are you building on a Mac, Unix derivate or raspberry pi? What is the > > response of the " arch" command? > > > I'm building on a linux machine recognised as x86_64 and I tried three > separate time... whats the output of "uname -a" ? (i assume Julius meant this by "arch" command). Append the output of "gcc -v --version" -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-support] Incorrect MD5 for /development/lfs-bootscripts-20170626.tar.bz2
Am Freitag, den 29.12.2017, 10:05 -0600 schrieb Bruce Dubbs: > Ken Moffat wrote: > > On Fri, Dec 29, 2017 at 01:10:06PM +, Nate Costello wrote: > > > I'm getting an incorrect hash for the lfs-bootscripts file. This is using > > > the development branch. Can anyone attempt to repeat my finding or > > > provide guidance? I apologize in advance if it is bad form to email this > > > list about the development version. > > > > > > > First, it's perfectly fine to ask about problems building the dev > > book on this list. But, based on what I note below I'll Cc: the > > -dev list because I didn't expect this. > > > > > Thanks, > > > > > > Nate > > > > > > File path: > > > > > > http://www.linuxfromscratch.org/lfs/downloads/development/lfs-bootscripts-20170626.tar.bz2 > > > > > > Supposed Correct Hash: > > > > > > 4d886e7f5c3b092991cd0c56f3d8aa31 > > > > > > Listed at: > > > > > > http://www.linuxfromscratch.org/lfs/view/development/chapter03/packages.html > > > > I wonder if we have somehow switched to regenerating these ? My > > local copy (downloaded on 19th July) has > > > > c8c20c854d7590662ae04f21949566ea > > > > The 8.1 book, which uses these, says > > > > d4992527d67f28e2d0c12e3495422eab > > And that matches what is in > http://www.linuxfromscratch.org/lfs/downloads/8.1/lfs-bootscripts-20170626.tar.bz2 > > The script that rebuilds the book daily also repackages the boot scripts > and the timestamps will change each time, even though the content does not. > > On my local system, the tarballs are not rebuilt without a change to the > file name because I do not do a fresh checkout of the sources into an > empty directory like the daily scripts do. > > I could update the md5sum in the on-line book daily, but I think that > would also cause problems. > > I suppose I could come up with a way to put in a note that would only > generate in the development versions of the book(s), but right now I think > it is more effort than it is worth. The daily build script has been > unchanged for 18 months and this it the first anyone noticed. > > > All this applies to the lfs systemd development version and blfs tarballs > also. Today I came across that issue too because i want to build a 8.3 system (for some reference purposes) and failed because of that chksum mismatches. Currently there are again 3 chksums for lfs-bootscripts- 20180820.tar.bz2 - one in 8.3, one in devel and one at the file i previously downloaded in August - all different ... Isn't there really no way to (re)package the bootscripts a) when changes has been made AND b) with a new version number? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Possible patch for Grub 2.02
Am Samstag, den 06.10.2018, 17:21 +0800 schrieb Kevin Buckley via lfs-dev: > This patch may or may not be needed for Grub, as installed > in the LFS book, however it is a patch to the sources that > was required when I rebuilt Grub for a UEFI system, as per > the UEFI hint, on a machine that has an "AMD A8-6600K APU > with Radeon(tm) HD Graphics" as the CPU. > ... Very good report. I filed a ticket (#4354) so we don't forget to check. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] (sysv) Moving util-linux before eudev
Am Freitag, den 14.09.2018, 15:25 +0800 schrieb Xi Ruoyao: > On 2018-09-14 09:09 +0200, Thomas Trepl wrote: > > Hi all, > > > > we have a lot of tweaks in eudev regarding blkid by creating a config.cache > > file > > and using LD_LIBRARY_PATH=/tools/lib. > > The tweaks are no longer necessary and will be removed in 8.4. > See #4345 <http://wiki.linuxfromscratch.org/lfs/ticket/4345>. Ah, reading the ticket is what i missed ;-) Thanks! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] (sysv) Moving util-linux before eudev
Hi all, we have a lot of tweaks in eudev regarding blkid by creating a config.cache file and using LD_LIBRARY_PATH=/tools/lib. What if we just swap places of eudev and util-linux? It looks to me that we could drop the tweaks in eudev than. Or do i miss something? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Upcoming 8.3 release
Am Donnerstag, den 30.08.2018, 23:19 +0100 schrieb Ken Moffat: > On Fri, Aug 31, 2018 at 12:08:07AM +0200, Thomas Trepl wrote: > > > > Would give a +1 if kernel gets upgraded (is there something we > > could > > check upfront?) because of the Intel bug, > > For those, like me, who haven't been paying attention: is this > 'intel bug' the "fails to build on (old) core machines", or a > different one ? > > I've lost track of all the recent intel bugs, but I thought we were > up to date for modern hardware. > > ĸen > -- > Also Spuke Zerothruster > (Finnegans Wake) I refered to the L1TF stuff which was addressed in 4.18.1 but additional fixes seem to occur in 4.18.2 and .3 (for example https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.18.3) -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Upcoming 8.3 release
Am Donnerstag, den 30.08.2018, 15:57 -0500 schrieb Bruce Dubbs: > I plan to release 8.3 this weekend. Before I do I plan on updating > the > kernel to version 4.18.5 (or .6 if it is released before Saturday). > > The are four other packages waiting: > > e2fsprogs-1.44.4 > gdbm-1.18 > meson-0.47.2 > bison-3.1 > > I hesitate to add them to 8.3 since the current versions have been > used > to validate blfs. > > Any comments? > > Also, please consider this a last call for text or other changes in > lfs-dev before it is used for the 8.3 release. (BLFS does have a > few > pending issues but progress there is good.) > >-- Bruce Would give a +1 if kernel gets upgraded (is there something we could check upfront?) because of the Intel bug, the others may go in 8.4 as they are more or less "daily maintenance" changes as far as i can see. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] RC1 security issues
Am Montag, den 20.08.2018, 10:25 -0500 schrieb Bruce Dubbs: > On 08/20/2018 07:18 AM, Thomas Trepl wrote: > > Am Mittwoch, den 15.08.2018, 21:25 -0500 schrieb DJ Lucas: > > > ... > > While creating a ticket for a minor bug in the Makefile, i saw that > > linux-4.18.3 is targeted for LFS-8.4. Is that by intention or > > shouldn't L1TF-stuff go into the upcoming LFS-release (as well as > > the > > e2fsprogs)? > > Which makefile? You are always free to create a ticket for anything. The Makefile to create the book. I've opened a ticket (#4339) on it. Note that this is more of cosmetic kind, minor inconsistence than a real bug. > Note that we always say to use the latest point version of the > kernel, > in this example 4.18.x. If you look at the dates for kernel releases > > https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ > > you'll see by our scheduled release date that we will be up to at > least > 4.18.5. See that for 4.17 the e were 18 releases in 49 days. Yes, sure. My thought was that when releasing a book version, we mark some sort of "milestone" and while we are doing that, we know that there are critical bugfixes to one of the most important packages but do not include them. Someone who is building LFS using the stable version 8.3 will miss the fixes if following the written text. Yes we note that there may be newer kernels out there and user should use them, but does it cost us really much to upgrade the kernel version until release date has come? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] RC1 security issues
Am Mittwoch, den 15.08.2018, 21:25 -0500 schrieb DJ Lucas: > Discussion was requested in bug to see if security issues should be > fixed before or after release. There are two low severity security > issues in OpenSSL-1.1.0h currently in rc1. My thoughts, there is a > low > probability of breakage, and since we need to do kernel and headers > again (again, I assumed this was a necessity instead of discussion), > I > figured OpenSSL would be a shoe-in as a result of that. I don't see > a > problem with it, but understand that there is some risk of breakage. > The > same is true of all the updates, but again, all minimal risk. > > I figure at least a few of us haven't updated to the RC yet, so any > issues would be discovered on those rebuilds (these would only be > packages between end of LFS and Xorg in BLFS). If nobody else is > planning on full rebuild for RC, I can commit to rebuilding > everything > that depends on them currently to validate after I complete the few > items I've assigned to myself. > > I've updated all outstanding packages that I've slotted for 8.3, > including the obligatory glibc rebuild for new kernel headers, and > am > proceeding with those changes in place. Unfortunately, the updates > did > not come in until after I had completed Xorg (2nd milestone on my > build > order). I intend to do a short overnight build of LFS in a different > prefix. > > Thoughts? I guess really, do any editors intend to start from > scratch > for the RC period or is everyone up to date already? > While creating a ticket for a minor bug in the Makefile, i saw that linux-4.18.3 is targeted for LFS-8.4. Is that by intention or shouldn't L1TF-stuff go into the upcoming LFS-release (as well as the e2fsprogs)? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] ninja not found
Am Samstag, den 18.08.2018, 22:32 -0500 schrieb Bruce Dubbs: > On 08/18/2018 07:25 PM, scsijon wrote: > > https://github.com/ninja-build/ninja/archive/ is where they are all > > now, > > the version number between archive/ and the package was made > > redundant > > back in april due to certain kinds of attacks when https was > > enforced. > > #1378 (closed) > > So what is the full url? > https://github.com/ninja-build/ninja/archive/ > is not found as is > https://github.com/ninja-build/ninja/archive/ninja-1.8.2.tar.gz > > https://github.com/ninja-build/ninja/archive/v1.8.2.tar.gz works, > but > sucks for a wget list. The whole github stuff sucks. As it is owned now (or is about to be owned) by Microsoft. Wikipedia says for US$7.5 billion. Can't imagine that MS will keep all that stuff up for free - they never did. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Vim download url
Am Samstag, den 18.08.2018, 09:57 +0100 schrieb Robin Parker: > Hi, > > In the 8.3 release candidates, the vim download url - > ftp://ftp.vim.org/pub/vim/unix/vim-8.1.tar.bz2 doesn’t work for me. > > This link however, does work - > http://ftp.vim.org/vim/unix/vim-8.1.tar.bz2 Works for me: [thomas@ganymed ~]$ wget ftp://ftp.vim.org/pub/vim/unix/vim-8.1.tar.bz2 --2018-08-18 15:21:22-- ftp://ftp.vim.org/pub/vim/unix/vim-8.1.tar.bz2 => »vim-8.1.tar.bz2« Auflösen des Hostnamens ftp.vim.org (ftp.vim.org)… 145.220.21.40, 2001:67c:6ec:221:145:220:21:40 Verbindungsaufbau zu ftp.vim.org (ftp.vim.org)|145.220.21.40|:21 … verbunden. Anmelden als anonymous … Angemeldet! ==> SYST ... fertig.==> PWD ... fertig. ==> TYPE I ... fertig. ==> CWD (1) /pub/vim/unix ... fertig. ==> SIZE vim-8.1.tar.bz2 ... 11258868 ==> PASV ... fertig.==> RETR vim-8.1.tar.bz2 ... fertig. Länge: 11258868 (11M) (unmaßgeblich) vim-8.1.tar.bz2 100%[===>] 10,74M 246KB/sin 45s 2018-08-18 15:22:11 (244 KB/s) - »vim-8.1.tar.bz2« gespeichert [11258868] [thomas@ganymed ~]$ md5sum vim-8.1.tar.bz2 1739a1df312305155285f0cfa6118294 vim-8.1.tar.bz2 Maybe it was just a temporary outage of vim's ftp server. Thanks anyway for the report. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Multilib patch
Hi, for those who are interested in doing {,B}LFS with multilib support, here is a patch on the LFS book adding some instructions to build the LFS core system with multilib support. Apply the patch to the LFS sources and run "make ARCH=multilib". If leaving out the ARCH= parameter or set it to ARCH=default will produce the book without any ML stuff in it. Running thru the book created with ARCH=multilib will provide you a system with m64, mx32 and m32 ABI. The patch is based on the latest development LFS book (20180808), not yet tested on the 8.3-rc1. I had to split up building glibc in chapter 6 into two sections, the "usual" build of 64-bit glibc and than the 32-bit glibc with having the adjustment section in between. Otherwise i ran into the "glibc builds endlessly"-issue. Root directory gets a bit polluted by two additional dirs(symlinks) named /lib32 and /libx32. I think there could be a way to avoid this when diving deeper into the gcc-specs-stuff and such. The patch also adds ISL as a new package. I'm not sure whether there is a real dependency on that, I just included it as DJ did that in his ML- book, too. Whats missing: * The kernel chapter should be enhanced with instructions to enable the required emulation support. * My building system has multilib support allready builtin. Need to redo testing from a single-64bit-ABI-system to ensure that there are no silent cross-references. And finally: I'm pretty sure that there are some bugs/flaws/whatever in the patch (and the instructions it provides), consider the patch as an alpha version. Please be invited to report bugs, provide tweaks, comments and enhancements! Yes, ML goes a bit beyond the basic educational approach of LFS but there is still software out there (in my case a printer driver from DELL) which is only provided as 32bit-binary and this renders a pure- 64bit LFS useless to some extend. And big thanks to DJ, Nathan and William F. for their recent work on multilib support! -- Thomas diff -Naur -x .svn -x 'lfs-bootscripts-*.tar.bz2' -x appendices BOOK-orig/chapter01/askforhelp.xml BOOK-multilib/chapter01/askforhelp.xml --- BOOK-orig/chapter01/askforhelp.xml 2018-08-10 07:50:45.0 +0200 +++ BOOK-multilib/chapter01/askforhelp.xml 2018-08-12 21:15:20.298266973 +0200 @@ -39,7 +39,8 @@ The version of the book being used (in this case - &version; + &version; + &version;-multilib &versiond;) diff -Naur -x .svn -x 'lfs-bootscripts-*.tar.bz2' -x appendices BOOK-orig/chapter01/changelog.xml BOOK-multilib/chapter01/changelog.xml --- BOOK-orig/chapter01/changelog.xml 2018-08-10 07:50:45.0 +0200 +++ BOOK-multilib/chapter01/changelog.xml 2018-08-12 21:13:51.669498909 +0200 @@ -11,7 +11,8 @@ Changelog This is version -&version; +&version; +&version;-multilib &versiond; of the Linux From Scratch book, dated &releasedate;. If this book is more than six months old, a newer and better diff -Naur -x .svn -x 'lfs-bootscripts-*.tar.bz2' -x appendices BOOK-orig/chapter03/packages.xml BOOK-multilib/chapter03/packages.xml --- BOOK-orig/chapter03/packages.xml 2018-08-10 07:50:45.0 +0200 +++ BOOK-multilib/chapter03/packages.xml 2018-08-10 09:43:39.531077226 +0200 @@ -356,6 +356,15 @@ + ISL (&isl-version;) - &isl-size;: + +Home page: +Download: +MD5 sum: &isl-md5; + + + + Kbd (&kbd-version;) - &kbd-size;: Home page: diff -Naur -x .svn -x 'lfs-bootscripts-*.tar.bz2' -x appendices BOOK-orig/chapter04/settingenviron.xml BOOK-multilib/chapter04/settingenviron.xml --- BOOK-orig/chapter04/settingenviron.xml 2018-08-10 07:50:46.0 +0200 +++ BOOK-multilib/chapter04/settingenviron.xml 2018-08-12 13:38:55.044890706 +0200 @@ -37,7 +37,7 @@ .bashrc file instead. Create the .bashrc file now: -cat > ~/.bashrc << "EOF" +cat > ~/.bashrc << "EOF" set +h umask 022 LFS=/mnt/lfs @@ -46,6 +46,17 @@ PATH=/tools/bin:/bin:/usr/bin export LFS LC_ALL LFS_TGT PATH EOF +cat > ~/.bashrc << "EOF" +set +h +umask 022 +LFS=/mnt/lfs +LC_ALL=POSIX +LFS_TGT=x86_64-lfs-linux-gnu +LFS_TGT32=i686-lfs-linux-gnu +LFS_TGTX32=x86_64-lfs-linux-gnux32 +PATH=/tools/bin:/bin:/usr/bin +export LFS LC_ALL LFS_TGT LFS_TGT32 LFS_TGTX32 PATH +EOF The set +h command turns off bash's hash function. Hashing is ordinarily a useful diff -Naur -x .svn -x 'lfs-bootscripts-*.tar.bz2' -x appendices BOOK-orig/chapter05/binutils-pass1.xml BOOK-multilib/chapter05/binutils-pass1.xml --- BOOK-orig/chapter05/binutils-pass1.xml 2018-08-10 07:50:46.0 +0200 +++ BOOK-multilib/chapter05/binutils-pass1.xml 2018-08-12 17:07:56.147972097 +0200 @@ -72,12 +72,20 @@ Now prepare Binutils for compilation: -../configure --prefix=/tools\ +../configure --prefix=/tools \ --with-sysroot=$LFS\ -
Re: [lfs-dev] Future of i686 builds (in gcc, et al.)
Am Donnerstag, den 08.03.2018, 17:27 +0300 schrieb rslov...@yandex.com: > I don't have any old hardware but I always build entire i686 > userland, my sole > motivation is to use wine to run old games, but it's a strong enough > one, and > I sincerely think I would be doing this forever... > > Never tried the multiarch way, it just seems too messy for me. Would you mind to try https://io.ax.lt/LFS/lfs/book/index.html ? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] 8.2-rc1 obervation / mdmon
Hi, the url to lfs-bootscripts is invalid: http://www.linuxfromscratch.org/lfs/downloads/8.2.rc1/lfs-bootscripts-2 0170626.tar.bz2 should be http://www.linuxfromscratch.org/lfs/downloads/8.2-rc1/lfs-bootscripts-2 0170626.tar.bz2 (note the dot instead a dash in 8.2.rc1) The md5 checksum of the bootscript package has changed but name is still the same. Even a diff shows no difference. I assume that the package has been recreated and some bytes in the bz2 itself did change. I'd recomment to not recreated the tarball (if that is the reason for chksum change) when creating a tag - recreate the bz2 only when changes has been made in the scripts. Apropos bootscripts. Recenty i sent over a patch to not kill mdmon process when shutdown. Does this still has no chance to get into the package? In case one is using fakeraid, the surrent bootscripts will leave the array dirty every time system shuts down (causing recovery the next time system boots) because mdmon gets killed to early... -- Thomasdiff -Naur lfs-bootscripts-20170626.orig/lfs/init.d/mountfs lfs-bootscripts-20170626/lfs/init.d/mountfs --- lfs-bootscripts-20170626.orig/lfs/init.d/mountfs 2017-08-18 20:41:57.0 +0200 +++ lfs-bootscripts-20170626/lfs/init.d/mountfs 2017-11-26 05:48:08.618518870 +0100 @@ -64,6 +64,13 @@ # Make all LVM volume groups unavailable, if appropriate # This fails if swap or / are on an LVM partition #if [ -x /sbin/vgchange ]; then /sbin/vgchange -an > /dev/null; fi + + if [ -n "$(pidof mdmon)" ]; then + # No longer possible to write to bootlog. Use "echo". + echo -n " Wait for clean array ... " + /sbin/mdadm --wait-clean --scan + echo "rc=$?" + fi ;; *) diff -Naur lfs-bootscripts-20170626.orig/lfs/init.d/sendsignals lfs-bootscripts-20170626/lfs/init.d/sendsignals --- lfs-bootscripts-20170626.orig/lfs/init.d/sendsignals 2017-08-18 20:41:57.0 +0200 +++ lfs-bootscripts-20170626/lfs/init.d/sendsignals 2017-11-26 05:48:08.671852575 +0100 @@ -29,8 +29,11 @@ case "${1}" in stop) + omit=$(pidof mdmon) + [ -n "$omit" ] && omit="-o $omit" + log_info_msg "Sending all processes the TERM signal..." - killall5 -15 + killall5 -15 $omit error_value=${?} sleep ${KILLDELAY} @@ -42,7 +45,7 @@ fi log_info_msg "Sending all processes the KILL signal..." - killall5 -9 + killall5 -9 $omit error_value=${?} sleep ${KILLDELAY} -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] vimrc problem with current -dev
Am Donnerstag, den 15.02.2018, 23:09 + schrieb Ken Moffat: > On Wed, Feb 14, 2018 at 11:51:04PM +, Ken Moffat wrote: > > On Wed, Feb 14, 2018 at 05:16:54PM -0600, Bruce Dubbs wrote: > > > > > > I think it is going to the last match in a search. Try adding > > > 'set > > > noincsearch' to vimrc. > > > > > > > Yes, that seems to fix it. > > > > Well, I thought it fixed it - but it didn't. OTOH, I've just had to > correct an error in two of my scripts (moved a package script from > one to the other, forgot to change the directory where it now > lives), and going back into vim dropped me where I had been - in > that case, just what I needed. > > I guess I'll try to learn to get used to it ;) I like that feature. Looks like that everyone has his personal dislikes in vim. Its the auto-indention which drives me crazzy. To switch it off, if have to do 12 keystrokes (ESC : set paste). In nano its only two (ESC-I) -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] 回复:Re: Linux 4.15 and OpenSSL
Am Dienstag, den 06.02.2018, 10:49 -0600 schrieb Bruce Dubbs: > hykw...@sina.com wrote: > > > Actually, I want to build a new kernel with my old kernal config > > (for the kernel 4.9) and here is my procedure: > > > > 1. Extract Linux source codes > > 2. switch to the source code folder and type "make mrproper" > > 3. copy the old configure file to the folder: cp /sources/config- > > 4.9 .config > > 4. type "make oldconfig" and apply default value for all new > > options > > 5. type "make menuconfig" and check the value of the "Module > > signature verification". Also, I make sure it is OFF. > > 6. type "make" to build the codes. > > That is basically the procedure I use also. > > > I used Linux kernel 4.14.17, 4.15 and 4.15.1 source codes and > > followed the above procedures. However, I could build the kernel > > 4.14.17 sucessfully only. I got the same error message for kernel > > 4.15 and 4.15.1. > > > > So, any other options should I unselect for kernel 4.15? > > I took a look at this and I think we will need to move openssl from > BLFS > to LFS to enable the kernel to build. The good news is that openssl > does > not depend on any other BLFS packages, so it is just that one page. +1 to this one. Put it just before Python which than will be able to handle https urls. To support that, it's currently required to build Python again after OpenSSL has been installed - at least doing so fixed it for me (found that while installing Ansible). > By my count, there are 72 packages in BLFS that refer to openssl so > it may > be a good move anyway. > > For now, I suggest building openssl in chroot before trying to build > the > kernel. > >-- Bruce > > -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-support] binutils-2.20 and grub
Am Freitag, den 02.02.2018, 15:03 -0600 schrieb Bruce Dubbs: > Thomas Seeling wrote: > > Hallo, > > > > > > I rebuilt LFS from SVN with kernel 4.15 gcc 7.3 on i686. > > > > # head -n7 /proc/cpuinfo > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 15 > > model : 4 > > model name : Intel(R) Pentium(R) 4 CPU 3.20GHz > > stepping: 9 > > microcode : 0x3 > > > > > PTI offers mitigation against Meltdown, retpoline against Spectre > > > v2. > > > > Basic LFS compiles fine with book settings, apart from grub where a > > minimal change was required in the final build of binutils 2.30. I > > admit > > I simply hacked the script 082-binutils in lfs-commands to achieve > > that. > > > > configure needs the following switch on 32 bit systems: > > --enable-64-bit-bfd > > Thomas, Have you tested you built grub? When I investigate the > enable-64-bit-bfd option, the comment I see is "64-bit support (on > hosts > with narrower word sizes)" I am thinking about adding this > unconditionally, but am a bit concerned that grub will try to run 64- > bit > code on a 32-bit system (and crash). I'm not sure that adding the > option > to a normal 64-bit build will hurt anyting, but I'll test that. > > Yes, got that hint from Pierre. It works pretty fine with this switch. Indeed, it seems to be a bit strange that 64bit code is generated on a 32bit system. Unfortunatly I'm not that deep in grub to see whether that code will ever be executed (or at least tried to). Would be cool if that switch could make it into the book as it wouldn't no longer require the build scripts to be patched every time. I'm just finishing building a new i686-system with thew new binutils, glibc and such. Will see whether grub still works (but i assume it as it allways did). Thank you all! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Has i686 support dropped in (B)LFS?
Am Mittwoch, den 31.01.2018, 19:16 +0100 schrieb Pierre Labastie: > On 31/01/2018 18:57, Thomas Trepl wrote: > > Am Mittwoch, den 31.01.2018, 18:48 +0100 schrieb Pierre Labastie: > > > On 31/01/2018 18:16, thomas wrote: > > > > Hi all, > > > > > > > > does (B)LFS "officially" support i686 platforms or did we > > > > silently > > > > drop > > > > 32-bit? There were a few comments about this question in > > > > Sept/Oct > > > > last year as > > > > Bruce brought this up. I cannot find a final decision. > > > > > > > > I ask this question because of the issue occured by upgrading > > > > binutils to 2.30 > > > > with which grub2 cannot be compiled [1]. Since there are no > > > > other > > > > complains > > > > than from i686 systems, it looks like that this issue does not > > > > occur on x86_64 > > > > systems. If LFS supports 32bit, shouldn't we then refuse > > > > upgrading > > > > packages to > > > > version which do not compile on all platforms? > > > > > > > > I know, there is that good feeling of living on the bleeding > > > > edge - > > > > but what > > > > does make us feel that we have to have the most recent version > > > > in > > > > the book? > > > > The intention of the book is to show how things work - that can > > > > be > > > > pretty much > > > > achieved with not-that-new version too. This allows us to stay > > > > on a > > > > previous > > > > version if the new one does not work proper. Making a comment > > > > in > > > > the package's > > > > chapter why this is not upgraded to the last version right now > > > > should be > > > > sufficient. > > > > > > > > Yes, there may be security issues fixed in newer versions. But > > > > is > > > > that that > > > > much relevant for a LFS system where we hardly care about > > > > security > > > > fixes? > > > > > > > > Personally, i do recompiling LFS on 32bit for some of my older > > > > machines. It's > > > > as fast as for 64bit as I'm doing it in a VM (which is not > > > > realy > > > > much slower > > > > than bare metal). So compile time isn't that important to me, i > > > > think its not > > > > an argument at all. I'd be kind of sad if 32bit support would > > > > be > > > > dropped. > > > > > > > > Whats your opinion? > > > > > > Looks like all the devs (except you maybe) only compile on > > > x86_64, so > > > 32-bit > > > support has not been dropped, but it is much less tested. For the > > > binutils > > > issue, have you tried my suggestion on support? > > > > > > Pierre > > > > Yes, I placed a message on the grub-bug-list with a lot of logs > > (see > > link http://lists.gnu.org/archive/html/bug-grub/2018-01/msg6.ht > > ml). > > > > To my text above, to make long text short: Shouldn't we downgrade > > to > > binutils-2.29.1 for a while (until a fix comes up somehow)? > > > > Sorry, I meant "my suggestion in my answer to the other Thomas on > lfs-support". Sometimes unifying names has disadvantages :-) > You may want to try adding two flags to binutils' configure: > --enable-64-bit-bfd > --enable-targets=x86-64 --enable-targets=x86_64 results in a configure error but the --enable- 64-bit-bfd did work. You guys are so ingenious! What did you do to discover this? configure --help doesn't show those switches. Grub compiles fine with that. Will do another clean build, but for now it looks promising... -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Has i686 support dropped in (B)LFS?
Am Mittwoch, den 31.01.2018, 18:48 +0100 schrieb Pierre Labastie: > On 31/01/2018 18:16, thomas wrote: > > Hi all, > > > > does (B)LFS "officially" support i686 platforms or did we silently > > drop > > 32-bit? There were a few comments about this question in Sept/Oct > > last year as > > Bruce brought this up. I cannot find a final decision. > > > > I ask this question because of the issue occured by upgrading > > binutils to 2.30 > > with which grub2 cannot be compiled [1]. Since there are no other > > complains > > than from i686 systems, it looks like that this issue does not > > occur on x86_64 > > systems. If LFS supports 32bit, shouldn't we then refuse upgrading > > packages to > > version which do not compile on all platforms? > > > > I know, there is that good feeling of living on the bleeding edge - > > but what > > does make us feel that we have to have the most recent version in > > the book? > > The intention of the book is to show how things work - that can be > > pretty much > > achieved with not-that-new version too. This allows us to stay on a > > previous > > version if the new one does not work proper. Making a comment in > > the package's > > chapter why this is not upgraded to the last version right now > > should be > > sufficient. > > > > Yes, there may be security issues fixed in newer versions. But is > > that that > > much relevant for a LFS system where we hardly care about security > > fixes? > > > > Personally, i do recompiling LFS on 32bit for some of my older > > machines. It's > > as fast as for 64bit as I'm doing it in a VM (which is not realy > > much slower > > than bare metal). So compile time isn't that important to me, i > > think its not > > an argument at all. I'd be kind of sad if 32bit support would be > > dropped. > > > > Whats your opinion? > > Looks like all the devs (except you maybe) only compile on x86_64, so > 32-bit > support has not been dropped, but it is much less tested. For the > binutils > issue, have you tried my suggestion on support? > > Pierre Yes, I placed a message on the grub-bug-list with a lot of logs (see link http://lists.gnu.org/archive/html/bug-grub/2018-01/msg6.html). To my text above, to make long text short: Shouldn't we downgrade to binutils-2.29.1 for a while (until a fix comes up somehow)? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] os="x" attributes in chapter06/adjusting.xml
Am Sonntag, den 07.01.2018, 12:56 +0100 schrieb Thomas Trepl: > Hi, > > I came across that adjusting.xml has nearly on every docbook tag the > os > attribute set (with values from "a" upto "t"). > > For what is that good for? It looks to me that this has been a test, > according to changelog at least more than 20 months ago... ;-) > > You can simply remove the attributes by > sed -e 's/ os=".">/>/' -i /path/to/chapter06/adjusting.xml > > -- > Thomas The above is total bullsh*t - forget about it, sorry for making noise. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] os="x" attributes in chapter06/adjusting.xml
Hi, I came across that adjusting.xml has nearly on every docbook tag the os attribute set (with values from "a" upto "t"). For what is that good for? It looks to me that this has been a test, according to changelog at least more than 20 months ago... ;-) You can simply remove the attributes by sed -e 's/ os=".">/>/' -i /path/to/chapter06/adjusting.xml -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] libstdc++.la (and others)
Am Samstag, den 06.01.2018, 10:48 -0600 schrieb Bruce Dubbs: > Thomas Trepl wrote: > > we're moving away all the .la file but in chap6.creating-files we > > maintain libstdc++.la. In systemd version, there is even more: > > blkid > > lzma mount uuid > > > > Do we still need that, if yes, why? > > All the .la files are removed at the end of Chapter 6. > > find /usr/lib -name \*.la -delete That is what i meant, why do we create them at beginning of chap6 when we delete them at the end? It looks like we do not need them in between so section "Create Essential Files and Symlinks" could be simplified (a suggestion). -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] libstdc++.la (and others)
we're moving away all the .la file but in chap6.creating-files we maintain libstdc++.la. In systemd version, there is even more: blkid lzma mount uuid Do we still need that, if yes, why? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] linux-4.14.12
looks like we will get a lot of new dot versions these days. What do you think about using the linux-4.14.tar-xz + patch-4.14.x.xz archives instead of the whole source archive? Would decrease the download size from >100MB to 0.37MB for each dot version. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] install MPlayer fail
Am Donnerstag, den 14.12.2017, 11:13 +0800 schrieb Rogue S.T: > My LFS is 7.0, i have a demand about play video, so i want to install > MPlayer. > But i get a error:cannot find pow when i install libpng package that > dependent. > What? then i search it on google and lfs? nothing ,can you help me? > 7.0 might be a bit old. Anyway, collect information about - the command you executed and failed - logs showing the error (not only the last error message but all the lines which shows what happened) - post that in blfs-support as this is the lfs-dev list, we have lists for supporting beyond LFS -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Don't kill mdmon
Hi all, after digging around to get LFS booting on a mdadm-raid (based on a fakeraid on C236 chipset) I've collected a few changes to some essentials files. LFS bootscripts Problem was that after every reboot, the array has been rebuild. While rebuild, the system is nearly unusable slow and the rebuild takes a good amount of time (here 1.5h). The reason seems to be that the initscripts - here especially sendsignals - do not really take care of raid services. sendsignals sends SIGTERM/SIGKILL to any running process, including a mdmon process started earlier in initramfs. This makes it impossible for mdmon to mark the array as clean. Booting an dirty array forces a rebuild automatically. The patch to sendsignals simply omits the pid of mdmon from being killed. Next, in mountfs I added a wait-clean after the root filesystem has been remounted to be read-only on shutdown. Even though mdmon should mark the array clean when no writes has occured for a certain amount of time, it is kind of "forced" by calling mdadm to do so. Initramfs This patch belongs to BLFS. It simply adds readlink and basename to initramsfs as some udev rules do refer to them. Unfortunatly, they are called qualified in /usr/bin so it was not enough to simply add them to $binfiles or $sbinfiles. A symlink in /usr to /bin makes those pgms accessable via /usr/bin. Would you mind to have a look to the patches and discuss whether they could applied? -- Thomas diff -Naur lfs-bootscripts-20170626.orig/lfs/init.d/mountfs lfs-bootscripts-20170626/lfs/init.d/mountfs --- lfs-bootscripts-20170626.orig/lfs/init.d/mountfs 2017-08-18 20:41:57.0 +0200 +++ lfs-bootscripts-20170626/lfs/init.d/mountfs 2017-11-26 05:48:08.618518870 +0100 @@ -64,6 +64,13 @@ # Make all LVM volume groups unavailable, if appropriate # This fails if swap or / are on an LVM partition #if [ -x /sbin/vgchange ]; then /sbin/vgchange -an > /dev/null; fi + + if [ -n "$(pidof mdmon)" ]; then + # No longer possible to write to bootlog. Use "echo". + echo -n " Wait for clean array ... " + /sbin/mdadm --wait-clean --scan + echo "rc=$?" + fi ;; *) diff -Naur lfs-bootscripts-20170626.orig/lfs/init.d/sendsignals lfs-bootscripts-20170626/lfs/init.d/sendsignals --- lfs-bootscripts-20170626.orig/lfs/init.d/sendsignals 2017-08-18 20:41:57.0 +0200 +++ lfs-bootscripts-20170626/lfs/init.d/sendsignals 2017-11-26 05:48:08.671852575 +0100 @@ -29,8 +29,11 @@ case "${1}" in stop) + omit=$(pidof mdmon) + [ -n "$omit" ] && omit="-o $omit" + log_info_msg "Sending all processes the TERM signal..." - killall5 -15 + killall5 -15 $omit error_value=${?} sleep ${KILLDELAY} @@ -42,7 +45,7 @@ fi log_info_msg "Sending all processes the KILL signal..." - killall5 -9 + killall5 -9 $omit error_value=${?} sleep ${KILLDELAY} --- BOOK/postlfs/filesystems/initramfs.xml (Revision 19536) +++ BOOK/postlfs/filesystems/initramfs.xml (Arbeitskopie) @@ -93,6 +93,7 @@ binfiles="sh cat cp dd killall ls mkdir mknod mount " binfiles="$binfiles umount sed sleep ln rm uname" +binfiles="$binfiles readlink basename" # Systemd installs udevadm in /bin. Other udev implementations have it in /sbin if [ -x /bin/udevadm ] ; then binfiles="$binfiles udevadm"; fi @@ -113,10 +114,11 @@ WDIR=$(mktemp -d /tmp/initrd-work.XX) # Create base directory structure -mkdir -p $WDIR/{bin,dev,lib/firmware,run,sbin,sys,proc} +mkdir -p $WDIR/{bin,dev,lib/firmware,run,sbin,sys,proc,usr} mkdir -p $WDIR/etc/{modprobe.d,udev/rules.d} touch $WDIR/etc/modprobe.d/modprobe.conf ln -s lib $WDIR/lib64 +ln -s ../bin $WDIR/usr/bin # Create necessary device nodes mknod -m 640 $WDIR/dev/console c 5 1 @@ -153,7 +155,8 @@ # Install basic binaries for f in $binfiles ; do - ldd /bin/$f | sed "s/\t//" | cut -d " " -f1 >> $unsorted + if [ -x /bin/$f ]; then f="/bin/$f"; else f="/usr/bin/$f"; fi + ldd $f | sed "s/\t//" | cut -d " " -f1 >> $unsorted copy $f bin done -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Version in udev-rule-package
Hi, in the Makefile.lfs of udev-lfs-20171027.tar.bz2 there is VERSION=20140408 Shouldn't it be 20171027 ? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] New packages in LFS
Am Samstag, den 23.09.2017, 17:32 -0500 schrieb Bruce Dubbs: > I have added four new packages to LFS: libffi, python3, ninja, and > meson. > Please take a look and let me know of any issues/suggestions/typos > etc. > > For those who do not render the book themselves, it will be rendered > overnight on the main web site. > > I have not changed systemd. I ask either DJ or renodr to make > changes and > test the systemd build using meson/ninja. There are other packages > in > BLFS that can use meson and I suggest we move to that build mechanism > as > it seems to be a lot faster and cleaner than autotools based builds. > > We will be able to remove libffi from BLFS and meson will not be > needed > there, but python and ninja will still need to remain for additional > optional dependencies. > >-- Bruce Hi, looks like this packages are only required for systemd. My suggestion would be to add this packages only in the systemd-branch in order to not "pollute" the sysv-branch; just the same way as systemd itself does only appear in the systemd branch. Since there are many dependencies in Python (bluez, openssl, etc.) the Python installation here in LFS is only temporary to get the build tools meson and ninja running. Since those tools are required more or less only for gnome stuff, they need to be built anyhow, but only if systemd/gnome stuff is required. If they are not built in LFS, it does not cost anything to build them when needed later in BLFS. Apropos openssl - there are options in the kernel config which adds a dependency to openssl to the kernel. A full featured kernel (like the one you get when using Archlinux's config) does not build without having openssl installed. With this said, it looks to me more important to have openssl in the basic tool chain than the ones above (except you do a systemd build). What do you think? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Instruction for glibc, chap-6, on 32bit machines
Am 2017-05-24 17:13, schrieb Bruce Dubbs: Thomas Trepl wrote: Hi all, shouldn't the instruction (6.9. Glibc-2.25) case $(uname -m) in x86)GCC_INCDIR=/usr/lib/gcc/x86-pc-linux-gnu/7.1.0/include ln -s ld-linux.so.2 /lib/ld-lsb.so.3 ;; x86_64) GCC_INCDIR=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include ln -s ../lib/ld-linux-x86-64.so.2 /lib64 ln -s ../lib/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3 ;; esac read like case $(uname -m) in i?86) GCC_INCDIR=/usr/lib/gcc/$(uname -m)-pc-linux-gnu/7.1.0/include ... No. The kernel does not differentiate between 32-bit x86 processors in its machine name. -- Bruce No, too. $(uname -m) does not output "x86" on a 32bit installation - it outputs "i686". So, to the case-label "x86" will never be jumped to, never gets executed. Same in the GCC_INCDIR in that command, "x86-pc-linux-gnu" does not exist, it's named "/usr/lib/gcc/i686-pc-linux-gnu/...". -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Instruction for glibc, chap-6, on 32bit machines
Hi all, shouldn't the instruction (6.9. Glibc-2.25) case $(uname -m) in x86)GCC_INCDIR=/usr/lib/gcc/x86-pc-linux-gnu/7.1.0/include ln -s ld-linux.so.2 /lib/ld-lsb.so.3 ;; x86_64) GCC_INCDIR=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include ln -s ../lib/ld-linux-x86-64.so.2 /lib64 ln -s ../lib/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3 ;; esac read like case $(uname -m) in i?86) GCC_INCDIR=/usr/lib/gcc/$(uname -m)-pc-linux-gnu/7.1.0/include ... ? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Thinking about a new LFS Live CD/iso
Am Montag, den 18.04.2016, 15:24 -0500 schrieb Bruce Dubbs: > I've been thinking thinking about a new Live CD/Rescue CD based on > LFS. > It would be much less ambitious than the old one that included an X > implementation. > > What I had in mind is a base LFS system with the following: > > dhcpcd > wget > ssh/ssl > which > links > screen > mc > gptfdisk > gpm > LFS HTML > LFS sources tarball > > What else? Other possibilities: > unzip > subversion > git > wireless-tools > wpa-supplicant > > -- Bruce > A new "offical" CD would be great but should not introduce too much changes in the LFS system. On my wishlist would be that the CD could be built from a clean, fresh compiled LFS, adding some additional BLFS packages like networking dhcpcd, wget, openssl, openssh (as daemon, not only the client), rpcbind, nfs-{utils,client}, wpa-supplicant, wireless-tools development (all whats needed for LFS), cvs, subversion, git, jhalfs editors nano, vim, joe A graphical env is cool and usefull but it needs not to be full blown with every characterset existing on that earth and every language supported. English is the common base, and if there is an option to set the keyboard layout then its fine. For version 1.0, its not required at all and the question is, should the CD be another SystemRescueCD or will we have a working CD built in the "LFS way" ? Before the CD exists, it would be very interesting to see a "How to build a Live-CD". If a user finally can put the bricks together and (re)build the CD, than it's no longer a very important question which packages are included. The user her/himself can remaster it on their own. Working thru the book is telling the user how things work. I that all has been understood, many users starts to add additional packages like dhcp clients or such in their "chapter-6" before they are going to boot. The added packages are not documented in the LFS book (maybe in the BLFS book they are) but the important thing is that the user knows how to deal with them. I dream of something like that for the CD. When the official CD is not sufficient for me, I'll find a documentation how the CD is made and can easily (more or less) rebuild the CD to my taste. Long text short: a CD-book not a CD-image ;-) -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] make-4.2 upstream patch missing
Hi, http://www.linuxfromscratch.org/patches/lfs/development/make-4.2-upstre am_fixes-1.patch gives a 404 btw, 4.2.1 is out -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page