Re: [blfs-dev] Files in BLFS svn missing on anduin
Le 20/04/2014 18:08, Bruce Dubbs a écrit : bdu...@linuxfromscratch.org wrote: Missing OpenJDK-1.7.0.55-i686-bin.tar.xz Missing OpenJDK-1.7.0.55-x86_64-bin.tar.xz These tarballs are really large. Have the binaries in them been stripped? I have not looked at stripping. I did not worry about sizes, since they were (almost) the same size as the preceding (1.7.0.51) ones. Will look at it. Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Files in BLFS svn missing on anduin
Le 21/04/2014 10:36, Pierre Labastie a écrit : Le 20/04/2014 18:08, Bruce Dubbs a écrit : bdu...@linuxfromscratch.org wrote: Missing OpenJDK-1.7.0.55-i686-bin.tar.xz Missing OpenJDK-1.7.0.55-x86_64-bin.tar.xz These tarballs are really large. Have the binaries in them been stripped? I have not looked at stripping. I did not worry about sizes, since they were (almost) the same size as the preceding (1.7.0.51) ones. Will look at it. Pierre Stripping the shared libraries with --strip-debug, the executables with --strip-unneeded, removing src.zip and man, demo, sample directories, reduces the size of the tarball by roughly a factor of three (slightly less). I'll test that I can rebuild OpenJDK/Icedtea with those reduced binaries before uploading them. OTOH, if somebody does not want to build OpenJDK/Icedtea, and wants to use the binary as is, it may be better to keep demo, man, and sample (adds 7MB or so). I do not know if src.zip is useful: It adds 40-45MB. Anybody knows what it is useful for? Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Files in BLFS svn missing on anduin
Pierre Labastie wrote: Le 21/04/2014 10:36, Pierre Labastie a écrit : Le 20/04/2014 18:08, Bruce Dubbs a écrit : bdu...@linuxfromscratch.org wrote: Missing OpenJDK-1.7.0.55-i686-bin.tar.xz Missing OpenJDK-1.7.0.55-x86_64-bin.tar.xz These tarballs are really large. Have the binaries in them been stripped? I have not looked at stripping. I did not worry about sizes, since they were (almost) the same size as the preceding (1.7.0.51) ones. Will look at it. Pierre Stripping the shared libraries with --strip-debug, the executables with --strip-unneeded, removing src.zip and man, demo, sample directories, reduces the size of the tarball by roughly a factor of three (slightly less). I'll test that I can rebuild OpenJDK/Icedtea with those reduced binaries before uploading them. OTOH, if somebody does not want to build OpenJDK/Icedtea, and wants to use the binary as is, it may be better to keep demo, man, and sample (adds 7MB or so). I do not know if src.zip is useful: It adds 40-45MB. Anybody knows what it is useful for? I have not looked at src.zip, but I think the man, demo, and sample directories should remain for exactly the reason you say -- for instance, some may only want java for something like fop and may not want to build java. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
Le 20/04/2014 23:26, Ken Moffat a écrit : I've no idea what that refers to, but it doesn't matter. I know that (at least) you and Pierre use jhalfs, and for me that is unusable (/scratch is an nfs mount on/from my server, I _really_ do not want to try to build there - by the same token, I use different 'patch' commands). [...] If you tell me what your setting is, I could arrange to make jhalfs compatible with this setting, and you could see whether you want to use it... Regards Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
Pierre Labastie wrote:
Le 20/04/2014 23:26, Ken Moffat a écrit :
I've no idea what that refers to, but it doesn't matter. I know
that (at least) you and Pierre use jhalfs, and for me that is
unusable (/scratch is an nfs mount on/from my server, I _really_ do
not want to try to build there - by the same token, I use different
'patch' commands). [...]
If you tell me what your setting is, I could arrange to make jhalfs compatible
with this setting, and you could see whether you want to use it...
I'm not sure that's needed Pierre. The only thing to do is to just copy
the sources to the local LFS partition. I have a couple of scripts I
keep in $LFS/sources, check.sh and extra.sh. They are also included in
the lfs source tarballs on the files mirrors.
$ cat check.sh
#! /bin/bash
while read line; do
base=`basename $line`
if [ ! -s $base ]; then
echo $base misssing
fi
done wget-list
-
$ cat extra.sh
#! /bin/bash
aux=check.sh extra.sh md5sums wget-list
for f in $(ls); do
base=$base `basename $f`
xxx=`grep $f wget-list`
yyy=`echo $aux | grep $f`
if [ -z $xxx ] [ -z $yyy ]; then
echo $f extra
fi
done
---
When starting a new build, I generally do:
cd ~/lfs-svn
make
cd $LFS/sources
cp ~/lfs-book/{wget-list,md5sums) .
sh check.sh
md5sum -c md5sums
cd ~/jhalfs
make
cd $LFS/jhalfs
make
For convenience I also have scripts to mount and unmount virtual file
systems and to clean up $LFS prior to the start of a new build. I also
have an alias to enter chroot.
I'm sure everyone does things their own way, but the principles should
be the same. I do understand that some may want to do a lot of
customization to their build scripts mainly to instrument things to
their liking, but the above allows a very quick build of the LFS book,
especially if tests are turned off.
My most recent test used 64 SBU @ 123 seconds/SBU. If I used -j2 it
would probably be faster. I need to check that out.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
Le 21/04/2014 20:49, Bruce Dubbs a écrit : Pierre Labastie wrote: Le 20/04/2014 23:26, Ken Moffat a écrit : I've no idea what that refers to, but it doesn't matter. I know that (at least) you and Pierre use jhalfs, and for me that is unusable (/scratch is an nfs mount on/from my server, I _really_ do not want to try to build there - by the same token, I use different 'patch' commands). [...] If you tell me what your setting is, I could arrange to make jhalfs compatible with this setting, and you could see whether you want to use it... I'm not sure that's needed Pierre. The only thing to do is to just copy the sources to the local LFS partition. I have a couple of scripts I keep in $LFS/sources, check.sh and extra.sh. They are also included in the lfs source tarballs on the files mirrors. I meant I was wondering why jhalfs was not usable by Ken, and that maybe a little bit of customization could make it usable for him. [...] For convenience I also have scripts to mount and unmount virtual file systems and to clean up $LFS prior to the start of a new build. I also have an alias to enter chroot. All that is also in jhalfs: - make -C /mnt/lfs/jhalfs devices # for mounting virtual files - make -C /mnt/lfs/jhalfs teardown # for unmounting them - Cleaning is done if you tick General Settings-Rebuild files - make -C /mnt/lfs/jhalfs chroot # mount the virtual files and enter chroot. Unmounting is done automatically at exit. [...] My most recent test used 64 SBU @ 123 seconds/SBU. If I used -j2 it would probably be faster. I need to check that out. My SBU is 160 seconds, but if I need a fast build, I can use -j4 (or 5) and disable tests, to get a full build in a hour and a half or so. Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
On Mon, Apr 21, 2014 at 03:28:01PM -0500, Bruce Dubbs wrote:
Pierre Labastie wrote:
Le 21/04/2014 20:49, Bruce Dubbs a écrit :
Pierre Labastie wrote:
Le 20/04/2014 23:26, Ken Moffat a écrit :
For convenience I also have scripts to mount and unmount virtual file
systems and to clean up $LFS prior to the start of a new build. I also
have an alias to enter chroot.
All that is also in jhalfs:
- make -C /mnt/lfs/jhalfs devices # for mounting virtual files
- make -C /mnt/lfs/jhalfs teardown # for unmounting them
- Cleaning is done if you tick General Settings-Rebuild files
- make -C /mnt/lfs/jhalfs chroot # mount the virtual files and enter chroot.
Unmounting is done automatically at exit.
There are times when something fails in Chapter 6. There it is nice to
be able to enter chroot via a simple alias: lfs='...'
My mounting and unmounting does a little more. For instance, I also
bind mount /usr/src so I can build non-lfs packages in chroot.
My cleaning does more than that. It removes $LFS/{bin,sbin,usr,...}
after unmounting virtual filesystems, and /usr/src.
There are lots of techniques and I'm sure a lot of users develop their
own way of doing things. Providing ideas is a good thing though.
-- Bruce
Thanks to both of you for the suggestions. I remember trying jhalfs
when I was on cross-lfs : yes, copying everything to /sources is
probably going to work, but it doesn't fit with the rest of my build
(particularly the BLFS part, and the sanity checks in my own scripts).
There is also a deeper difference - jhalfs was originally a tool for
builders. As an editor, my preference is to look at a new package
version on a completed system [ normally, just a DESTDIR ], see what
options I want to use [ e.g. omit static libs even in LFS, unless they
turn out to be required somewhere ]. Only once I'm happy that the
resulting _system_ is ok will I think about editing the XML. And on
a desktop, the resulting system is normally my full normal desktop,
so that I can pick up knock-on effects in later packages.
So, my method has the danger that the resulting instructions will
occasionally be incorrect (e.g. 'check' for 'test' in graphite).
The jhalfs method appears to require me to prepare the XML as a
first step before I have confidence it will work, and I continue to
feel that is back-to-front ;-)
Anyway, I'm unlikely to progress far with my attempt to test
sysv-systemd for a while - got a problem in kernel 3.15.0-rc2 on one
of my machines [ blank screen on one of my radeon machines ], need
to take time out to explore that. My weakest, slowest, machine -
of course. The other two (R600, intel) are fine with rc2.
ĸen
--
das eine Mal als Tragödie, dieses 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: [blfs-dev] #4977: D-Bus-1.8.0: messagebus group and user already exist
Ken Moffat wrote: There is also a deeper difference - jhalfs was originally a tool for builders. As an editor, my preference is to look at a new package version on a completed system [ normally, just a DESTDIR ], see what options I want to use [ e.g. omit static libs even in LFS, unless they turn out to be required somewhere ]. Only once I'm happy that the resulting _system_ is ok will I think about editing the XML. And on a desktop, the resulting system is normally my full normal desktop, so that I can pick up knock-on effects in later packages. Of course I do the individual check too, but I also need to build the whole system, in order, as a sanity check to make sure the system can be built according to the book as written. I also need to check that the packages build in the chroot environment in the book order. This was especially important when we added util-linux to Chapter 5. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
