Re: LFS LiveCD x86_64-6.3-min-pre1 Available
Jeremy Huntwork wrote: Hello, The LFS LiveCD team is pleased to announce a new 64bit-only CD. It is a minimal CD, meaning that it contains no X Windows System and dependent software nor any source packages. The LFS book that is included is based on the current development x86_64 branch. Be advised that as of now that book contains no instructions for building a boot loader, and some of the textual information may need adjusting. However, it will produce a working base system. Since this is a pre-release, please help test the CD and report any bugs you may find to the livecd mailing list. The link to the primary mirror is: ftp://ftp.lfs-matrix.net/pub/lfs-livecd/lfslivecd-x86_64-6.3-min-pre1.iso There is also a secondary mirror: ftp://ftp.osuosl.org/pub/lfs-livecd/lfslivecd-x86_64-6.3-min-pre1.iso Enjoy! -- JH on a reboot: /ect/rc.d/rc6.d/K30dbus Error, return code 1 pid: so such file or directory pid: system_bus_socket : no such file or directory these messages occurred on both reboot commands. the final message, and a stop of all activity, manual reset required: Shutdown Helper line 89 /usr/bin/chroot no such file or directory. The tools that I tested in a quick 10 minute check all worked perfectly. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
HLFS Help - Chapter 6
Hi all, I am new to the mailing list and HLFS, and have just started having a go at building HLFS SVN-20070708. My progress so far is up to Chapter 6, building Glibc 2.5, and all has gone well until now. Approximately half way down the page, having built Glibc the first time and removed the 'configparms' file, we then recreate a second configparms file (The section in light blue lettering) and rebuild a second time. When I try to run that second build, it stops almost immediately, stating that there is a missing separator in the configparms file, like so: make -r PARALLELMFLAGS= CVSOPTS= -C ../glibc-2.5 objdir='pwd' all make[1]: Entering directory '/sources/glibc-2.5' /sources/glibc-build/configparms:6: *** missing separator. Stop. make[1]: Leaving directory '/sources/glibc-2.5' make: *** [all] Error 2 I have removed and retyped the contents of this file 3 times now and had the same error message when trying to build again. I've also had a friend look over the file contents and he agrees the content is as per the instructions: echo 'CC = gcc -fPIE CXX = g++ -fPIE CFLAGS-sln.c += -fno-PIC -fno-PIE +link = $(CC) -nostdlib -nostartfiles -fPIE -pie -o $@ $(sysdep-LDFLAGS) $(config-LDFLAGS) $(LDFLAGS) $(LDFLAGS-$(@F)) -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,now $(hashstyle-LDFLAGS) $(addprefix $(csu-objpfx),S$(start-installed-name)) $(+preinit) `$(CC) --print-file-name=crtbeginS.o` $(filter-out $(addprefix $(csu-objpfx),start.o $(start-installed-name)) $(+preinit) $(link-extra-libs) $(common-objpfx)libc% $(+postinit),$^) $(link-extra-libs) $(link-libc) `$(CC) --print-file-name=crtendS.o` $(+postinit) ' configparms If anybody else has experienced this or has an idea what might be wrong, I'd appreciate the info. Regards, Steve. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS LiveCD x86_64-6.3-min-pre1 Available
On Wednesday 25 July 2007 11:27:39 pm Jeremy Huntwork wrote: Hello, The LFS LiveCD team is pleased to announce a new 64bit-only CD. It is a minimal CD, meaning that it contains no X Windows System and dependent software nor any source packages. The LFS book that is included is based on the current development x86_64 branch. Be advised that as of now that book contains no instructions for building a boot loader, and some of the textual information may need adjusting. However, it will produce a working base system. I kicked off a 64 bit jhalfs-2.2 build from LFS LiveCD x86_64-6.3-min-pre1 last night. The build ran to completion and resulted in a bootable system (using a kernel from another distro but that was just laziness ... I don't journal /boot so no Ext2 support meant no kernel 'til morning) ;) The dbus and ext2 problems noted elsewhere exist here also but don't affect things noticeably until system shutdown ... had to boot into that F-word distro to get into my boot partition as the LiveCD system won't mount Ext2 filesystems and a reset was required as shutdown hangs ... umount partitions you care about manually and let the rough side drag ... maybe mount the partition where $SRC_ARCHIVE is ro too. It is interesting to note how much slower the 64 bit build was. Even though the SBU count is down a little, the SBU time is much longer. I don't see that the book changed that much. 64 bit was run from the CD whereas the 32 bit build was run from the CD installed on a hard drive. Otherwise, everything was pretty much identical. I only noticed 1 or 2 things being dl'd so sources were pretty much identical between builds. Slowness seemed to be due to cache ejection ... the bigger the package, the longer the relative time to complete ... small packages often were a few seconds faster. This system is a Skt754 so no dual channel and main memory is a little slow so if it ain't in the cache, you wait. jhalfs-2.2 was used in both cases and the config setup the same. I don't understand the huge difference in disk storage use ... 64 bit ought to have been higher ... maybe more coffee is required for proper analysis and reportage ... Anyhow, here it is FWIW. for 64 bit build excluding grub and no kernel build --- Book version is:SVN-x86_64-20070725 Using logs/028-binutils-pass1 to obtain the SBU unit value. The SBU unit value is equal to 169.741 seconds. Total time required to build the systen:73.876 SBU Total Installed files disk usage (including /tools but not /sources):610256 KB or 595.96 MB (209 minutes) for 32 bit build including grub but no kernel build --- Book version is:SVN-20070718 Using logs/028-binutils-pass1 to obtain the SBU unit value. The SBU unit value is equal to 152.126 seconds. Total time required to build the systen:75.619 SBU Total Installed files disk usage (including /tools but not /sources):739944 KB or 722.60 MB Grub added .137 SBU and 1.09 MB (192 minutes) K -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS LiveCD x86_64-6.3-min-pre1 Available
On Fri, Jul 27, 2007 at 08:33:53AM -0600, Jeremy Huntwork wrote: Of course, as the build progresses and you begin using more and more items on the hard-disk only, (first in /tools and then in chroot), the read time would increase. Er, decrease. The speed increases. :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
New BLFS Editor
Hi all, It is my pleasure to announce that Ag Hatzimanikas has accepted a position as a BLFS Editor. Ag brings a long time affiliation with the (x)LFS projects (and a great passion towards the projects), a great amount of Linux experience, and very good i18n knowledge to the project. Please help me in welcoming Ag as the newest member of the team. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 10:29:01 up 15 days, 3:36, 1 user, load average: 0.23, 0.07, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: HLFS Help - Chapter 6
Wonkey Donkey wrote: Hi all, I am new to the mailing list and HLFS, and have just started having a go at building HLFS SVN-20070708. My progress so far is up to Chapter 6, building Glibc 2.5, and all has gone well until now. Approximately half way down the page, having built Glibc the first time and removed the 'configparms' file, we then recreate a second configparms file (The section in light blue lettering) and rebuild a second time. When I try to run that second build, it stops almost immediately, stating that there is a missing separator in the configparms file, like so: make -r PARALLELMFLAGS= CVSOPTS= -C ../glibc-2.5 objdir='pwd' all make[1]: Entering directory '/sources/glibc-2.5' /sources/glibc-build/configparms:6: *** missing separator. Stop. make[1]: Leaving directory '/sources/glibc-2.5' make: *** [all] Error 2 I have removed and retyped the contents of this file 3 times now and had the same error message when trying to build again. I've also had a friend look over the file contents and he agrees the content is as per the instructions: echo 'CC = gcc -fPIE CXX = g++ -fPIE CFLAGS-sln.c += -fno-PIC -fno-PIE +link = $(CC) -nostdlib -nostartfiles -fPIE -pie -o $@ $(sysdep-LDFLAGS) $(config-LDFLAGS) $(LDFLAGS) $(LDFLAGS-$(@F)) -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,now $(hashstyle-LDFLAGS) $(addprefix $(csu-objpfx),S$(start-installed-name)) $(+preinit) `$(CC) --print-file-name=crtbeginS.o` $(filter-out $(addprefix $(csu-objpfx),start.o $(start-installed-name)) $(+preinit) $(link-extra-libs) $(common-objpfx)libc% $(+postinit),$^) $(link-extra-libs) $(link-libc) `$(CC) --print-file-name=crtendS.o` $(+postinit) ' configparms If anybody else has experienced this or has an idea what might be wrong, I'd appreciate the info. Regards, Steve. Ok, I think I have spotted the problem. On the seventh line down, as per the above code, there are 2 open brackets, one close bracket, then a comma. After it, there is one open bracket and two close brackets. Either the comma needs to be moved to the end of 'S$(start-installed-name))', OR, the final close bracket at the end of 'S$(start-installed-name))' needs to be moved to before the comma '$(addprefix $(csu-objpfx)),' Any ideas guys ? I'm struggling a bit here. Steve. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New BLFS Editor
On Fri, Jul 27, 2007 at 10:36:42AM -0500, Randy McMurchy wrote: Please help me in welcoming Ag as the newest member of the team. Congrats, Ag. Nice to have you onboard officially. :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: LFS LiveCD x86_64-6.3-min-pre1 Available
On Fri, Jul 27, 2007 at 10:25:31AM -0400, kas wrote: that the book changed that much. 64 bit was run from the CD whereas the 32 bit build was run from the CD installed on a hard drive. This would kind of skew the accurateness of your test. Reads performed on a CD filesystem are noticeably slower than those from a hard disk. As you build /tools you are continuously reading and making use of items on the host system, in other words, the LiveCD. Since your SBU is measured by the first program you build, binutils, you would end up having a higher SBU for a system built from the CD than one from an internal disk. Of course, as the build progresses and you begin using more and more items on the hard-disk only, (first in /tools and then in chroot), the read time would increase. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Anduin Package Repo
El Viernes, 27 de Julio de 2007 02:01, Randy McMurchy escribió: Hi all, Best as I can tell, the Anduin package repository hasn't been updated for well over a month. There's probably been more than 100 package updates since then. I know Justin is busy these days, so should we just forget this idea of having a repo? Ask Justin. IMHO, having the ftp repo up to date for when BLFS-6.3 will be released could be enought. Seems Justin and Manuel worked out some sort of automation to make the repo update easier, but I guess it didn't get put into place. Yes, there is the wget-list Makefile target to extract all packages patches download URLs. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: New BLFS Editor
El Viernes, 27 de Julio de 2007 17:36, Randy McMurchy escribió: Hi all, It is my pleasure to announce that Ag Hatzimanikas has accepted a position as a BLFS Editor. Ag brings a long time affiliation with the (x)LFS projects (and a great passion towards the projects), a great amount of Linux experience, and very good i18n knowledge to the project. Welcome, Hag. Is nice to see a new editor on BLFS :-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: New BLFS Editor
On Fri, Jul 27, 2007 at 10:36:42AM -0500, Randy McMurchy wrote: Please help me in welcoming Ag as the newest member of the team. With great pleasure. Welcome, Αγ. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Stuck on gnome 2.18 - gnome-vfs
Randy McMurchy wrote these words on 07/27/07 12:27 CST:
Looking at the dependencies for GNOME VFS, I missed adding the
dbus-glib package to the required section.
This is really bothering me. I think the biggest thing that BLFS
provides is the dependency lists. I carefully scan configure.{in,ac}
for each package. I suppose when I saw this:
if test $ENABLE_HAL = yes; then
PKG_CHECK_MODULES(HAL, hal = 0.5.7,
[ USE_HAL=hal = 0.5.7, hal-storage = 0.5.7, dbus-1 = 0.32,
dbus-glib-1 = 0.32
AC_DEFINE(USE_HAL, 1, [defined if using libhal])
msg_hal=yes],
[ USE_HAL=])
else
USE_HAL=
fi
in my mind this made dbus optional. Only problem is I overlooked this:
PKG_CHECK_MODULES(LIBGNOMEVFS, glib-2.0 = $GLIB_REQUIRED gmodule-no-export-2.0
= $GLIB_REQUIRED gthread-2.0 = $GLIB_REQUIRED gobject-2.0 = $GLIB_REQUIRED
gconf-2.0 = $GCONF_REQUIRED libxml-2.0 = $XML_REQUIRED gnome-mime-data-2.0
$dbus_requirement)
and I just don't know how I missed the dbus requirement. I hope
this hasn't happened in other places down the road. I suppose now
I need to go in and rip out all the D-Bus optional dependencies in
other packages that require GNOME VFS.
Sigh
--
Randy
rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686]
12:52:00 up 15 days, 5:59, 1 user, load average: 0.02, 0.06, 0.07
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: LFS LiveCD x86_64-6.3-min-pre1 Available
On Friday 27 July 2007 10:33:53 am Jeremy Huntwork wrote: On Fri, Jul 27, 2007 at 10:25:31AM -0400, kas wrote: that the book changed that much. 64 bit was run from the CD whereas the 32 bit build was run from the CD installed on a hard drive. This would kind of skew the accurateness of your test. Reads performed on a CD filesystem are noticeably slower than those from a hard disk. As you build /tools you are continuously reading and making use of items on the host system, in other words, the LiveCD. Since your SBU is measured by the first program you build, binutils, you would end up having a higher SBU for a system built from the CD than one from an internal disk. Of course, as the build progresses and you begin using more and more items on the hard-disk only, (first in /tools and then in chroot), the read time would increase. -- JH Ok, so I didn't think that the CD was making much difference as the activity led was never on for more than a flash ... but I had to be sure so I ran from the r1952 LiveCD to do a 32 bit jhalfs-2.2 build on the same hardware (yes, I removed 2.1 and untarred 2.2 in its place). As before, I didn't build a kernel. So I was using a slightly different kernel but everything else was the same. The same swap partition was mounted in both cases. 32-bit build using the r1952 LiveCD --- Book version is:SVN-20070726 Using logs/028-binutils-pass1 to obtain the SBU unit value. The SBU unit value is equal to 151.428 seconds. Total time required to build the systen:76.144 SBU Total Installed files disk usage (including /tools but not /sources):538912 KB or 526.29 MB Build time comes out 192 minutes ... CD access time was lost in the noise as the run from the hard drive took 192 mins also ... the same as the 32-bit build from the LiveCD installed to a partition. It is what it is ... I had hoped and fully expected 64-bit building to be a little faster. 068-GCC took almost 9.5 minutes longer on the 64-bit build (54:37 vs 64:02 minutes) by itself. Riddle me that, Batman. Note that the disk space usage between this run and the 64-bit run are fairly close ... 64-bit using somewhat more ... but my earlier 32-bit run showed much greater usage ... seems like something is broken now or was before. For reference, here is the data from the 64-bit build. for 64 bit build excluding grub and no kernel build --- Book version is:SVN-x86_64-20070725 Using logs/028-binutils-pass1 to obtain the SBU unit value. The SBU unit value is equal to 169.741 seconds. Total time required to build the systen:73.876 SBU Total Installed files disk usage (including /tools but not /sources):610256 KB or 595.96 MB (209 minutes) Jeremy, I'm not trying to rain on your parade ... I want to figure out if I am doing something wrong or if we are building incorrectly ... or if gcc is (you fill in the blank). Bummer, K -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS LiveCD x86_64-6.3-min-pre1 Available
kas wrote: Jeremy, I'm not trying to rain on your parade ... I want to figure out if I am doing something wrong or if we are building incorrectly ... or if gcc is (you fill in the blank). It's OK, I had my parade rain-proofed recently. ;) I just wanted to make sure your comparisons would be as accurate as possible without any unexpected influences. Whether or not 64-bit outshines (or is outshined by) 32-bit is a complicated and, from all I can tell, unsettled issue. The factors that influence performance vary from case to case. In any case, the current comparisons may very well be something that changes over time, as developers design their software with 64-bit in mind. BTW, I do appreciate the thoroughness with which you tackled this. :) The project(s) could always use more skilled hands that help test and report on various issues. For example, the LiveCD project could always do with some help testing the CD build scripts, reporting on package upgrades, etc. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS LiveCD x86_64-6.3-min-pre1 Available
Jeremy Huntwork wrote: On Fri, Jul 27, 2007 at 10:25:31AM -0400, kas wrote: that the book changed that much. 64 bit was run from the CD whereas the 32 bit build was run from the CD installed on a hard drive. This would kind of skew the accurateness of your test. Reads performed on a CD filesystem are noticeably slower than those from a hard disk. For 90% accurate results, please boot the CDs with the toram argument. In this case, the hard disk would indeed be slower than the CD image in memory :) Building LFS in tmpfs (assuming that you have enough RAM) adds the missing 9%. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
