Re: [lfs-dev] ICA with jhalfs
On 1/26/2012 12:32 PM, Matthew Burgess wrote: > On Thu, 26 Jan 2012 18:27:04 +0100, Pierre Labastie > wrote: >> Hi, >> >> I wonder if anybody still uses jhalfs, and if he(she) has tried ICA >> lately. > I use jhalfs all the time, but I've never done an ICA build with it. > >> ICA is broken because of the part in glibc's instructions, which >> instructs 'test-installation.pl' to look for /usr/lib rather than >> /tools/lib. On the second (and following) pass, the line 'DL=...' sets >> DL to empty (because /tools has been removed). Then the sed creates >> a flawed 'test-installation.pl'. >> >> Here is a patch which could be applied inside the LFS subdirectory >> of jhalfs: > Thanks, I'll apply that this evening. > >> Let me know if my efforts on jhalfs may be useful. It seems that >> my post on jhalfs-discuss has reached nobody... Besides adding >> package management, which you can simply disable by setting >> package management to n (this is the default) in the config menu, >> I spotted a few other bugs in the handling of tests. For example, >> look for the line "ulimits..." before tests in gcc, in the scripts >> from current jhalfs. > I monitor alfs-discuss too, but have no interest in package management > hence made no comment on it :-) I guess if the patch doesn't break things > for none-package-management uses then it could be applied with a minimum > of discussion really. > I noticed the patch too but haven't had time to thoroughly review it yet. But I would say before it does get applied a new stable release of jhalfs as there have been a few fixes since the last stable so we have known good working version out there for the most recent versions of LFS. Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] jhalfs's error log
On Fri, Feb 17, 2012 at 4:59 PM, Pierre Labastie
wrote:
> Le 17/02/2012 18:30, Bruce Dubbs a écrit :
>> Matthew Burgess wrote:
>>
>>> I had a quick look at the Makefile and make-aux-files.sh script and couldn't
>>> see why that line is required. Bruce, is there a reason those .script
>>> files are
>>> deleted?
>> It's cleanup. For jhalfs, it would be better if a different set of
>> rules were used if different behavior is needed.
>>
>> -- Bruce
> Hi,
>
> jhalfs needs an xml file to process for extracting commands scripts.
> 'index.xml' in book sources is the most obvious choice. But using this file
> leads necessary to try to find the '.script' entities, which have been
> deleted
> or do not exist.
> Another choice is to use lfs-full.xml, after 'make validxml'.
> I am currently testing that, but the target validxml depends on maketar
> (because
> aux-file-data;sh does a `ls lfs-bootscript*.bz2') and that is not
> specified on the 'validxml:' line in Makefile.
> Maybe one of you could do that (add maketar as a dependency of validxml)
After looking at this all that is needed is to add the following line
to common/libs/func_book_parser right after we check out the sources.
cd ${PROGNAME}-$LFSVRS; bash process-scripts.sh >> $LOGDIR/$LOG 2>&1 ; cd ..
This quells all those messages.
Thomas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] jhalfs's error log
On Feb 17, 2012, at 5:22 PM, Bruce Dubbs wrote:
> Thomas Pegg wrote:
>
>> cd ${PROGNAME}-$LFSVRS; bash process-scripts.sh >> $LOGDIR/$LOG 2>&1 ; cd ..
>
> May I suggest: pushd ${PROGNAME}-$LFSVRS; ...; popd
>
> It's a little more robust.
Yes, your right, I always forget about that construct.
Thomas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Automating package listing in jhalfs
On Feb 23, 2012, at 8:30 AM, Pierre Labastie wrote: > Hi, > > I have read several times that some of you were using DESTDIR > and recording the installed files for being able to uninstall > packages. I recently realized that what I have called `package > management' in jhalfs could be used for that purpose: > basically it automates the generation of scriptlets with > DESTDIR install from the book instructions. Then the packaging > and installation is made through a function that the user has > to write. I think this function could be used for recording the > installed files. > > There is actually already functionality in jhalfs to do that already, Cant remember which menu it's under but we can create installed files logs. Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] kbd
On May 18, 2012, at 5:56 PM, Jeremy Huntwork wrote: > On 5/18/12 3:36 PM, Qrux wrote: >> I'll let you and Bruce continue on about experimentation, etc. I would >> ordinarily chime in (and suggest probably more flame-worthy stuff like >> moving to git would foster more experimentation, because the effort of >> merging would be front-loaded on forkers--not trunk maintainers) but >> I'll take a break for a bit, and wait until this episode cools off. > > I would love to see the project move from subversion to git. I'll > continue to poke at that one from time to time as well... > I would second that one, I love git so much more than subversion. Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Trac Ticket System vs. Bugzilla
Jeremy Huntwork wrote: For example: "a) I liked the field in BZ that was available for a relevant URL." You liked it. Great. Wonderful. So what? Now in Trac you can include a link *anywhere* and it is dynamic. Especially when you include them in your opening remarks is it powerful. No major loss here, though I conceded that it was nice having a special field for it. But the above statement hardly shows that Bugzilla is more functional. It had a field for a URL. Trac allows you to stick in dynamic URLS in every comment, linkable to both external sources and internal items, for example the wiki, or the source browser. This can be fixed by adding a custom field, if you wish. See http://wiki.linuxfromscratch.org/lfs/wiki/TracTicketsCustomFields Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: OFFICIAL PROPOSAL.
Ag Hatzimanikas wrote: On Sun, May 28, at 07:04:20 Alexander E. Patrakov wrote: Ag Hatzimanikas wrote: perhaps a new book with any relative info that has to do with: a.'Handling Devices' (udev) b.'Boot process' (init schemes,bootscripts,bootmanager,etc) c.'Automounting Devices' d.'Volumes,raid etc...' e.'Partitiong schemes,filesystems,etc' f.'Kernel issues.' Please vote. No justification needed, voting is enough. Please vote everybody... Project Leaders, developers, old time users, retirement developers. I vote against this. Google is more useful than a whole new book for a lot of this. Plus there is no sense duplicating documentation that is already out there. Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: proposal for inclusion of e2fsprogs in chapter 5
Bruce Dubbs wrote: > Julio Meca Hansen wrote: > I've lost the background on this. Looking at util-linux, why do we need > it at all in Chapter 5? Can't we just build it once in Chapter 6 just > before the first file that needs it? > From what I remember it was so we could mount /dev/pts and /dev/shm inside of the chroot, but that's unnecessary now with the bind mount of the host's /dev. There could be more that relies on mount, not sure what though. Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: proposal for inclusion of e2fsprogs in chapter 5
Bruce Dubbs wrote: > Julio Meca Hansen wrote: > I've lost the background on this. Looking at util-linux, why do we need > it at all in Chapter 5? Can't we just build it once in Chapter 6 just > before the first file that needs it? > From what I remember it was so we could mount /dev/pts and /dev/shm inside of the chroot, but that's unnecessary now with the bind mount of the host's /dev. There could be more that relies on mount, not sure what though. Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: proposal for inclusion of e2fsprogs in chapter 5
Bruce Dubbs wrote: > Julio Meca Hansen wrote: > I've lost the background on this. Looking at util-linux, why do we need > it at all in Chapter 5? Can't we just build it once in Chapter 6 just > before the first file that needs it? > From what I remember it was so we could mount /dev/pts and /dev/shm inside of the chroot, but that's unnecessary now with the bind mount of the host's /dev. There could be more that relies on mount, not sure what though. Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: proposal for inclusion of e2fsprogs in chapter 5
Bryan Kadzban wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > Thomas Pegg wrote: >> From what I remember it was so we could mount /dev/pts and /dev/shm >> inside of the chroot, but that's unnecessary now with the bind mount >> of the host's /dev. > > The bind-mount of /dev isn't what makes it unnecessary. That's why > section 6.2.3 still exists -- we still have to mount devpts separately. > And we use the newly-built mount for this since it exists in /tools/bin, > and /tools/bin is at the start of $PATH. (Or at least, I think it > should still be first.) Actually were using the host's mount at that point unless your adding /tools/bin to the root user path (which is not in the book I might add), since su'ing to root even from the lfs user the path does not carry over, /tools/bin is lost. Here's results from a little test I just did: [EMAIL PROTECTED]:~$ export PATH=/tools/bin:$PATH [EMAIL PROTECTED]:~$ echo $PATH /tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games [EMAIL PROTECTED]:~$ type -p mount /tools/bin/mount [EMAIL PROTECTED]:~$ su root Password: su: Authentication failure Sorry. [EMAIL PROTECTED]:~$ su root Password: [EMAIL PROTECTED]:/home/tomp# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games [EMAIL PROTECTED]:/home/tomp# type -p mount /bin/mount [EMAIL PROTECTED]:/home/tomp# exit exit [EMAIL PROTECTED]:~$ Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Successful Build of Cross-LFS
Jeremy Huntwork wrote: > > > Well it sounds like we'll have a good number of testers for the x86_64 > arch then :) > You can add me to the list of x86_64 testers. :) -- Thomas LFS User : 4729 / Linux User : 298329 kitt - Powered by: Linux 2.6.9-1.667 08:22:44 up 3 days, 22:05, 2 users, load average: 0.25, 0.51, 0.34 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS 64-bit decisions
Jeremy Huntwork wrote: > Hey All: > > Need some feedback on how exactly we're going to handle 64-bit in the > Cross-LFS book, so bring on the comments! ;) > > > However, now that 64-bit is gaining popularity in a number of archs, the > question of how to handle that in the book comes up. For example, are we > building both 32-bit and 64-bit libs (multilib), or are we just building > 64-bit? If multilib, are we creating a /lib64 and keeping /lib 32-bit, > or will it be /lib32 and /lib as 64-bit? Should we allow the user to > decide which of these options or paths to take and support all decisions? Multilib would be the best. Using /lib for 32-bit and /lib64 for 64-bit, the other way gets to be a little bit hackish. > > So, in a nutshell, my opinion is that we should do multilib as a default > for 64-bit archs with /lib and /lib64 directories. This would be the way I think it ought to be done as well, having tried to tackle a multilib build a while back things work much better that way. -- Thomas LFS User : 4729 / Linux User : 298329 kitt - Powered by: Linux 2.6.9-1.667 08:22:44 up 3 days, 22:05, 2 users, load average: 0.25, 0.51, 0.34 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Libtool installation nit
On Sat, 2005-08-06 at 18:11 +0300, Ag Hatzim wrote: > Randy McMurchy([EMAIL PROTECTED])@Sat, Aug 06, 2005 at 09:56:17AM -0500: > > > > Can anyone check and see if this is the case on a recent build of > > LFS to confirm this? > > Confirmed.Same permissions as yours Randy. > Can confirm this here as well, same perms also. -- Thomas LFS User : 4729 / Linux User : 298329 kitt - Powered by: Linux 2.6.12.3 10:41:27 up 21:52, 3 users, load average: 1.75, 1.25, 0.80 signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Corrupted files on Anduin
While testing the new LFS LiveCD Makefile system, I ran across some corrupted files downloaded from anduin via ftp.lfs-matrix.net, but have confirmed that even downloading from anduin still results in corruption. The following files are affected: openssl-0.9.7g.tar.bz2 tcl-8.4.11.tar.bz2 tk-8.4.11.tar.bz2 There could potentially be others, but these are the only ones I've come across. Thomas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Perl - Cross-LFS Multilib
On Thu, 2005-10-27 at 21:35 +0100, Ken Moffat wrote:
> >
> OK, using Ryan's patch from last week plus the installstyle echo, with
> only a 64-bit perl, everything is in /usr/lib64/perl5 and XML-Parser
> installs into /usr/lib64/perl5/site_perl. Looks good, apart from
> the libc=/lib/ issue in 'perl -V'.
>
I think I may have a found a solution for that, I used a patch (attached
below) that's a variation on the current libc patch, the main
differences being that I dropped the last hunk of the patch it's only
needed for the tools version of perl. It does set libc properly (partial
output of perl -V below". I also used the -Dlibpth Jim posted earlier so
perl doesn't set it to just /usr/local/lib.
Linker and Libraries:
ld='gcc -m64', ldflags =''
libpth=/usr/local/lib64 /lib64 /usr/lib64
libs=-lnsl -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib64/libc-2.3.90.so, so=so, useshrplib=false,
libperl=libperl.a
gnulibc_version='2.3.90'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fpic', lddlflags='-shared'
Characteristics of this binary (from libperl):
Compile-time options: USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
Built under linux
Compiled at Oct 27 2005 23:06:28
@INC:
/usr/lib64/perl5/5.8.7/x86_64-linux
/usr/lib64/perl5/5.8.7
/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux
/usr/lib64/perl5/site_perl/5.8.7
/usr/lib64/perl5/site_perl
I tested this install against a few perl modules and everything ended up
where it should and linked to the proper libs.
--
Thomas
LFS User : 4729 / Linux User : 298329
kitt - Powered by: Linux 2.6.11-gentoo-r7
18:14:37 up 12 days, 1:16, 4 users, load average: 0.31, 0.43, 0.51
Submitted By: Thomas Pegg
Date: 2005-10-27
Initial Package Version: 5.8.7
Origin: based on perl-5.8.7-libc-1.patch
Description: this patch adapts some hard-wired paths to the C library and points it to use lib64 instead of lib.
diff -uNr perl-5.8.0.orig/hints/linux.sh perl-5.8.0/hints/linux.sh
--- perl-5.8.0.orig/hints/linux.sh 2002-06-05 23:46:00.0 +1000
+++ perl-5.8.0/hints/linux.sh 2003-02-19 16:32:18.0 +1100
@@ -51,9 +51,9 @@
# We don't use __GLIBC__ and __GLIBC_MINOR__ because they
# are insufficiently precise to distinguish things like
# libc-2.0.6 and libc-2.0.7.
-if test -L /lib/libc.so.6; then
-libc=`ls -l /lib/libc.so.6 | awk '{print $NF}'`
-libc=/lib/$libc
+if test -L /lib64/libc.so.6; then
+libc=`ls -l /lib64/libc.so.6 | awk '{print $NF}'`
+libc=/lib64/$libc
fi
# Configure may fail to find lstat() since it's a static/inline
signature.asc
Description: This is a digitally signed message part
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: linux-libc-headers
Matthew Burgess wrote: Tushar Teredesai wrote: Does someone have an idea on what the source based distros are using? Gentoo appears to be using their own, I think - http://packages.gentoo.org/ebuilds/?linux-headers-2.6.11-r2. I can't see any links to the actual tarball though that would enable a full comparison, just the patches they apply against it. They use the kernel sources and apply about 7+ patches against it, then install them. Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: Implementing Trac [long]
Jeremy Huntwork wrote: Note that if the community prefers items 2 or 3, I would still like to use the new logo on our exisiting sites, so comments on that are welcome as well. I very much like the way you can view the subversion tree, and the bugzilla bugs now converted to tickets are much better, not such a clunky interface, and is very fast too. One thing I found of paticular interest is the timeline tab, has a very nice output for the svn changelogs. I like the idea of (1), but I think there may be issues with mirroring. But otherwise 2 would be my choice. Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Subversion Upgrade
Jeremy Huntwork wrote: To all Project Leads: As was mentioned in a thread on the lfs-dev list, the server admins would like to upgrade the version of Subversion on Belgarath. Being that it's not a minor version upgrade, it is recommended by upstream devs to dump and re-load the repositories. Obviously, this would require a short freeze on commits to the repositories. ALFS is set. You can hit it first if you wish. Should be really simple. Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
