Re: [blfs-dev] Upcoming BLFS-7.5 release
On 03/06/2014 05:32 AM, Ken Moffat wrote: > On Thu, Mar 06, 2014 at 04:18:45AM +0100, Armin K. wrote: >> >> That's rather not correct. >> >> If a package a is dynamically linked to package b and package b gets >> updated to new version that doesn't have an ABI break (soname in b v1.2 >> is same as in b v1.0, ie libb.so.1), you *don't* need to recompile >> package a or anything else. >> >> In case of ABI break (b v1.4 has libb.so.2 and b v1.2 has libb.so.1), >> only the packages that link against libb.so.1 have to be recompiled >> against libb.so.2, NOTHING ELSE. >> >> In the gnutls case, you didn't need to recompile anything since there >> was no ABI break (there was, but it was reverted since it was not >> intentional). >> >> So even when you upgrade glibc from version 2.12 to version 2.19, you >> don't need to rebuild anything, since libc.so.6 in 2.19 still exports >> the same interfaces it did in 2.12 and also some aditional ones that got >> introduced later, but they are not important since they are not used by >> the software compiled against 2.12. >> > That is a correct statement of how things ought to be. But many > developers are like me - we make mistakes. For a distro which ships > binaries, no big deal. Similarly, fixing an existing BLFS-7.5 with > latest gnutls works. > > But there have been many cases over the years where minor changes > cause accidental breakage. I'm thinking of changes to headers - > those sorts of things only show up when building a fresh system. > Based on your previous mail, I've moved gnutls, glib-networking, and > their required/recommended dependencies, to _much_ earlier in my > build so that I can hope to exercise most possible users. > > ĸen > I don't recall any major changes on this scale that could probably break something. One of the examples might be Glibc 2.14 or upgrading between major versions of gcc (4.6->4.7, 4.7->4.8). Then again, when it comes to header changes it most likely results in an ABI break too or simply removing deprecated functionality (yay ffmpeg), so you have to rebuild one way or another. But then still, you only need to rebuild what gets linked against the libraries. Exceptions are gcc and glibc. (As a side note, header change in readline might break a package or two in BLFS). -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Upcoming BLFS-7.5 release
Em 05-03-2014 20:03, Ken Moffat escreveu: > On Wed, Mar 05, 2014 at 11:10:16PM +0100, Pierre Labastie wrote: >> Le 05/03/2014 22:34, Ken Moffat a écrit : >>> On Wed, Mar 05, 2014 at 02:04:16PM -0600, Bruce Dubbs wrote: Are we ready to release? -- Bruce >>> Yes. >>> >>> ĸen >>> >> Well, I think it's never ready anyway... >> >> Go for it! >> >> Pierre > > Alternatively, perhaps we should see if we can fix the now-public > gnutls vulnerability (potential man-in-the-middle attack from > crafted certificate), although I don't see any practical way of > testing the fix. > > Those who are able to read https://lwn.net/Articles/589291/ (might > be subscriber-only for the next 2 weeks, I'm not sure) will see from > nix's comment that there is already a second "fix" version of gnutls > (perhaps the first will be fine for BLFS), and _apparently_ it needs > a new version of p11-kit. > > My gut feeling is that we should get the current book out the door, > but continue to recommend that people use the development version of > the book. Call me a wimp, but I don't think this will be the last > known vulnerability. The real danger is that a change in either of > these packages might break compilation of something which pulls them > in as a dep of another package, so that the only real way to test > would be on a fresh build, not on an upgrade. > > ĸen > Everyday there is something in to be washed, after coffee. Any non-rolling distribution releases at on today and already have what o be updated. That is the reason I was at first against any cahanges during freeze even php (than changed a bit, but I am back to what I thought first). I saw several of the packages waiting to be updated had security problems. So, I agree with what you write: continue to recommend that people use the development version, although I think that it is the 7.5 updated version, not development. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] CA Certificates
Dear all, On http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cacerts.html you indicate to download CA Certificates from: http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1 However, on the "mxr frontpage" http://mxr.mozilla.org/ the branch "Mozilla CVS" http://mxr.mozilla.org/mozilla/ is described as follows: QUOTE This contains the entire current CVS repository. For Gecko, XULRunner, and Firefox, CVS trunk is no longer the trunk, and is instead used for Gecko 1.9 / Firefox 3 and the 1.9.0.* / 3.0.* security releases. UNQUOTE So I would like to suggest that alternative sources may be described a well. See e.g. http://kaarpux.kaarposoft.dk/packages/c/certdata.html#certificates_from_mozilla (You are more that welcome to link to this page, if you find it appropriate). We are not the only ones struggling to figure out which branch to use. See e.g. the thread started here: http://curl.haxx.se/mail/archive-2013-12/0033.html The integrity of the certdata.txt file is essential, so I would also like to suggest that 1) you download from https://hg.mozilla.org/... 2) you include a sha256 checksum for the file. /Henrik PS: I have some problems with my subscription, so please CC me on any replies. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Package stats
There is a question in the tickets about statistics. This is how I do
it. I have a script for each package that measures time and size.
I build packages in /tmp, but really could be anywhere.
First measure the free disk space:
before=`df -k /tmp | grep / | sed -e "s/ \{2,\}/ /g" | cut -d' ' -f3`
Run the build:
TIMEFMT='%1R Elapsed Time - '
{ time \
{
echo Making $TITLE
date
# Instructions go here
}
} 2>&1 | tee -a $LOG
Get the statistics:
stats $LOG $DIR/$PROGRAM.tar.?z* $before
Where stats does:
function stats()
{
log=$1
tarball=$2
b4=$3
# This changes slightly for a base LFS build
base_sbu=118
free_now=`df -k /tmp | grep / | sed -e "s/ \{2,\}/ /g" |
cut -d" " -f3`
buildtime=`tail -n1 $log|cut -f1 -d" "`
sbu=`echo "scale=3; $buildtime / $base_sbu" | bc`
psizeK=`du -k $tarball | cut -f1`
psizeM=`echo "scale=3; $psizeK / 1024" | bc`
bsizeK=`echo "$free_now - $b4" | bc`
bsizeM=`echo "scale=3; $bsizeK / 1024" | bc`
echo "SBU=$sbu" | tee -a $log
echo "$psizeK $tarball size ($psizeM MB)"| tee -a $log
echo "$bsizeK kilobytes build size ($bsizeM MB)" | tee -a $log
(echo -n "md5sum : "; md5sum $tarball) | tee -a $log
(echo -n "sha1sum: "; sha1sum $tarball) | tee -a $log
echo "`date` $tarball" >> /usr/src/packages-$(lsb_release -r|
cut -f2).log
}
So build size is measured as df_after - df_before. The issue to note
is that there is activity during the build that adds or deletes space on
/tmp, the size will be off. I have /tmp on its own partition.
-- 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] Upcoming BLFS-7.5 release
On Thu, Mar 06, 2014 at 09:40:31AM +0100, Armin K. wrote: > > Then again, when it comes to header changes it most likely results in an > ABI break too or simply removing deprecated functionality (yay ffmpeg), > so you have to rebuild one way or another. But then still, you only need > to rebuild what gets linked against the libraries. Exceptions are gcc > and glibc. > Yes, this is my point. The book is about starting from a minimal LFS system and building from source. I'm hoping that no minor breakage like this will show up, but it certainly would not be the first time. ĸ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] CA Certificates
Henrik /KaarPoSoft wrote: > Dear all, > > On > http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cacerts.html > you indicate to download CA Certificates from: > http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1 > > However, on the "mxr frontpage" > http://mxr.mozilla.org/ > the branch "Mozilla CVS" > http://mxr.mozilla.org/mozilla/ > is described as follows: > > QUOTE > This contains the entire current CVS repository. > For Gecko, XULRunner, and Firefox, CVS trunk is no longer the trunk, > and is instead used for Gecko 1.9 / Firefox 3 and the 1.9.0.* / 3.0.* > security releases. > UNQUOTE > > So I would like to suggest that alternative sources may be described a well. > See e.g. > http://kaarpux.kaarposoft.dk/packages/c/certdata.html#certificates_from_mozilla > > (You are more that welcome to link to this page, if you find it > appropriate). > > We are not the only ones struggling to figure out which branch to use. > See e.g. the thread started here: > http://curl.haxx.se/mail/archive-2013-12/0033.html > > The integrity of the certdata.txt file is essential, > so I would also like to suggest that > 1) you download from https://hg.mozilla.org/... > 2) you include a sha256 checksum for the file. It would seem that https://hg.mozilla.org/releases/mozilla-release/raw-file/058ed8ee9adf/security/nss/lib/ckfw/builtins/certdata.txt is correct right now, but I don't see a way to specify 'current' or 'latest' for the raw file that we need. We could write a script to download the html and then parse the raw file URL, but that would require downloading a 5M file just to get the url of a 1.5M files. :( I don't see how we can give a checksum if the file is changing. We need to let users decide which version they need. I'd be interested in other ideas. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] [was: ... r12830 ...]
Em 06-03-2014 13:22, bdu...@higgs.linuxfromscratch.org escreveu: > Author: bdubbs > Date: Thu Mar 6 08:22:54 2014 > New Revision: 12830 > > Log: > try again > -
Re: [blfs-dev] Upcoming BLFS-7.5 release
On 03/06/2014 05:48 PM, Ken Moffat wrote: > On Thu, Mar 06, 2014 at 09:40:31AM +0100, Armin K. wrote: >> >> Then again, when it comes to header changes it most likely results in an >> ABI break too or simply removing deprecated functionality (yay ffmpeg), >> so you have to rebuild one way or another. But then still, you only need >> to rebuild what gets linked against the libraries. Exceptions are gcc >> and glibc. >> > Yes, this is my point. The book is about starting from a minimal > LFS system and building from source. I'm hoping that no minor > breakage like this will show up, but it certainly would not be the > first time. > > ĸen > But then again, rebuilding entire system because of change in gnutls, which is rather not very important part of ones' system was waste of time. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Package stats
Em 06-03-2014 13:36, Bruce Dubbs escreveu:
> There is a question in the tickets about statistics. This is how I do
> it. I have a script for each package that measures time and size.
>
> I build packages in /tmp, but really could be anywhere.
>
> First measure the free disk space:
>
> before=`df -k /tmp | grep / | sed -e "s/ \{2,\}/ /g" | cut -d' ' -f3`
>
> Run the build:
>
> TIMEFMT='%1R Elapsed Time - '
>
> { time \
>{
> echo Making $TITLE
> date
> # Instructions go here
>
>
>}
> } 2>&1 | tee -a $LOG
>
> Get the statistics:
>
> stats $LOG $DIR/$PROGRAM.tar.?z* $before
>
> Where stats does:
>
> function stats()
> {
>log=$1
>tarball=$2
>b4=$3
>
># This changes slightly for a base LFS build
>base_sbu=118
>
>free_now=`df -k /tmp | grep / | sed -e "s/ \{2,\}/ /g" |
> cut -d" " -f3`
>
>buildtime=`tail -n1 $log|cut -f1 -d" "`
>sbu=`echo "scale=3; $buildtime / $base_sbu" | bc`
>
>psizeK=`du -k $tarball | cut -f1`
>psizeM=`echo "scale=3; $psizeK / 1024" | bc`
>
>bsizeK=`echo "$free_now - $b4" | bc`
>bsizeM=`echo "scale=3; $bsizeK / 1024" | bc`
>
>echo "SBU=$sbu" | tee -a $log
>echo "$psizeK $tarball size ($psizeM MB)"| tee -a $log
>echo "$bsizeK kilobytes build size ($bsizeM MB)" | tee -a $log
>(echo -n "md5sum : "; md5sum $tarball) | tee -a $log
>(echo -n "sha1sum: "; sha1sum $tarball) | tee -a $log
>
>echo "`date` $tarball" >> /usr/src/packages-$(lsb_release -r|
> cut -f2).log
> }
>
>So build size is measured as df_after - df_before. The issue to note
> is that there is activity during the build that adds or deletes space on
> /tmp, the size will be off. I have /tmp on its own partition.
>
>-- Bruce
>
Thanks, Bruce.
I find "du" more accurate, although more tome consuming, so have to to
mark some instants to avoid it from interfering in the timings.
On example is that df wil include the log size, perhaps you think it is
relevant.
But all numbers we give are approximate, large error bar, so I do not
dispute methods or numbers.
The problem there is that Ken found values very different, even one
negative: building the API docs takes less than installing the ones in
the tarball, is one example, and I can hardly believe this is possible:
build taking less time than just installing the documents.
As I introduced many of these numbers, probably after what Ken used to
do with ImageMagick, what I think is that being non-english speaking
native, I am giving wrong names to what I measure. That was the reason I
detailed how and what I measure there. It seems I need to rename in the
book, some number I gave.
What I mean is: everybody know 1 inch is different from 1 cm. But I can
use a ruler, make a measurement and tell Ken it is 1, using a cm ruler,
but he thinking I am using inches.
He is not wrong
I am not wrong
We are giving numbers for different things, probably my fault of not
writing carefully what my number means.
--
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Package stats
On Thu, Mar 06, 2014 at 02:36:02PM -0300, Fernando de Oliveira wrote: > Em 06-03-2014 13:36, Bruce Dubbs escreveu: > > > >So build size is measured as df_after - df_before. The issue to note > > is that there is activity during the build that adds or deletes space on > > /tmp, the size will be off. I have /tmp on its own partition. > > To me, that seems excessively complicated. But each to his own. > > > Thanks, Bruce. > > I find "du" more accurate, although more tome consuming, so have to to > mark some instants to avoid it from interfering in the timings. > > On example is that df wil include the log size, perhaps you think it is > relevant. When I measure for the book, I don't usually make logs! If I am making logs, I usually put them in ../ and use du for the directory and for the DESTDIR or equivalent directory. > > But all numbers we give are approximate, large error bar, so I do not > dispute methods or numbers. Agree, I see large variations - even in remeasuring the SBU. > > The problem there is that Ken found values very different, even one > negative: building the API docs takes less than installing the ones in > the tarball, is one example, and I can hardly believe this is possible: > build taking less time than just installing the documents. > Did I write that ? I intended to say that rebuilding the API docs took a lot of extra time, but that the space used was 1MB less - I guess that the recreated docs are trimmed down. > As I introduced many of these numbers, probably after what Ken used to > do with ImageMagick, what I think is that being non-english speaking > native, I am giving wrong names to what I measure. That was the reason I > detailed how and what I measure there. It seems I need to rename in the > book, some number I gave. > > What I mean is: everybody know 1 inch is different from 1 cm. But I can > use a ruler, make a measurement and tell Ken it is 1, using a cm ruler, > but he thinking I am using inches. > > He is not wrong > > I am not wrong > > We are giving numbers for different things, probably my fault of not > writing carefully what my number means. > It is clear that my rebuild of the docs was very different from Fernando's. At the moment I'm concentrating on rebuilding everything in chroot, just in case there is any breakage from accidental change in gnutls. My first attempt at LO just timed out on one of the downloads, so I guess I'm hours away from completing. After that, I'll take another look. Unfortunately, this system with gnome packages is my only 7.5 system with gtk-doc and p11-kit, so I can't do comparative tests on the other box. What I did notice was a *lot* of activity during the rebuilding of the docs (not logged, so I watched stdout scroll past, with references to html at one point. Guess I'd better create logs when I come back to this, so that I can summarise the difference in the builds. ĸ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] Package stats
Em 06-03-2014 15:22, Ken Moffat escreveu: > On Thu, Mar 06, 2014 at 02:36:02PM -0300, Fernando de Oliveira wrote: >> Em 06-03-2014 13:36, Bruce Dubbs escreveu: >>> >>>So build size is measured as df_after - df_before. The issue to note >>> is that there is activity during the build that adds or deletes space on >>> /tmp, the size will be off. I have /tmp on its own partition. >>> > To me, that seems excessively complicated. But each to his own. >> >> >> Thanks, Bruce. >> >> I find "du" more accurate, although more tome consuming, so have to to >> mark some instants to avoid it from interfering in the timings. >> >> On example is that df wil include the log size, perhaps you think it is >> relevant. > > When I measure for the book, I don't usually make logs! If I am > making logs, I usually put them in ../ and use du for the directory > and for the DESTDIR or equivalent directory. One thing is that the value of du -sch id different from (du -sh) + (du -sh), du -sch is more accurate, if more than one file/dir are measured. >> >> But all numbers we give are approximate, large error bar, so I do not >> dispute methods or numbers. > > Agree, I see large variations - even in remeasuring the SBU. >> >> The problem there is that Ken found values very different, even one >> negative: building the API docs takes less than installing the ones in >> the tarball, is one example, and I can hardly believe this is possible: >> build taking less time than just installing the documents. >> > > Did I write that ? I intended to say that rebuilding the API docs > took a lot of extra time, but that the space used was 1MB less - I > guess that the recreated docs are trimmed down. LOL. My bad, mixed the two subjects. Sorry > >> As I introduced many of these numbers, probably after what Ken used to >> do with ImageMagick, what I think is that being non-english speaking >> native, I am giving wrong names to what I measure. That was the reason I >> detailed how and what I measure there. It seems I need to rename in the >> book, some number I gave. >> >> What I mean is: everybody know 1 inch is different from 1 cm. But I can >> use a ruler, make a measurement and tell Ken it is 1, using a cm ruler, >> but he thinking I am using inches. >> >> He is not wrong >> >> I am not wrong >> >> We are giving numbers for different things, probably my fault of not >> writing carefully what my number means. >> > It is clear that my rebuild of the docs was very different from > Fernando's. At the moment I'm concentrating on rebuilding > everything in chroot, just in case there is any breakage from > accidental change in gnutls. My first attempt at LO just timed out > on one of the downloads, so I guess I'm hours away from completing. > After that, I'll take another look. > > Unfortunately, this system with gnome packages is my only 7.5 > system with gtk-doc and p11-kit, so I can't do comparative tests on > the other box. > > What I did notice was a *lot* of activity during the rebuilding of > the docs (not logged, so I watched stdout scroll past, with > references to html at one point. > > Guess I'd better create logs when I come back to this, so that I > can summarise the difference in the builds. > > ĸen > Actually, I only came discussing this subject, because you mentioned in some mail this or last week. Now, that I am trying to get done the tickets, I lost so much time with docs and tests, that for the moment, I will continue updating without caring about them, only in the second round will restart. So, for a couple of packages, I already have the complete set of numbers, but for all following ones, only the main values of dirsizes and SBU will updated, the other ones will be kpt as are. After what you wrote, in the ticket, I think we are measuring the same thing, probably I committed a mistake. As I said in previous paragraph. I don't care, for the moment. Next updates, we will have more time to do things decently. Cheers, -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [was: ... r12830 ...]
Fernando de Oliveira wrote: > Em 06-03-2014 13:22, bdu...@higgs.linuxfromscratch.org escreveu: >> Author: bdubbs >> Date: Thu Mar 6 08:22:54 2014 >> New Revision: 12830 >> >> Log: >> try again > > >> -
Re: [blfs-dev] Package stats
Fernando de Oliveira wrote: > I find "du" more accurate, although more tome consuming, Yes, that's why I went ot df. so have to to > mark some instants to avoid it from interfering in the timings. > > On example is that df will include the log size, perhaps you think it is > relevant. For me the log is at /usr/src/ so it is not included. > But all numbers we give are approximate, large error bar, so I do not > dispute methods or numbers. True. > The problem there is that Ken found values very different, even one > negative: building the API docs takes less than installing the ones in > the tarball, is one example, and I can hardly believe this is possible: > build taking less time than just installing the documents. That would take some analysis. I don't see how that could happen either. > As I introduced many of these numbers, probably after what Ken used to > do with ImageMagick, what I think is that being non-english speaking > native, I am giving wrong names to what I measure. That was the reason I > detailed how and what I measure there. It seems I need to rename in the > book, some number I gave. > > What I mean is: everybody know 1 inch is different from 1 cm. But I can > use a ruler, make a measurement and tell Ken it is 1, using a cm ruler, > but he thinking I am using inches. > > He is not wrong > > I am not wrong Yes, but seconds is the same for everyone. So is bytes. Well some differentiate between KiB and KB. :) > We are giving numbers for different things, probably my fault of not > writing carefully what my number means. WE are just giving the user an approximation. When I update, I do change the stats, but it's rarely a significant change. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Xorg Font package causes script stop and exit shell
I'm building BLFS from a recent development version. The package font-bh-ttf-1.0.3.tar.bz2 in Xorg Fonts causes the installation script to exit with an error... rm: cannot remove 'font-bh-ttf-1.0.3/@baseconfigdir@/conf.avail/42-luxi-mono.conf': Permission denied rm: cannot remove 'font-bh-ttf-1.0.3/@baseconfigdir@/conf.d/42-luxi-mono.conf': Permission denied So some files did not get installed, and it wasn't really obvious either. I might not have known except for noticing that the exit command did not return to the previous shell but logged me out of the console. And there was the build directory still sitting there in the font directory. I'm running the Xorg scripts as an ordinary user and Sudo is installed, so the as_root function is using the sudo "if" condition. I reproduced this issue by attempting to re-install font-bh-ttf-1.0.3 manually. The ordinary user cannot delete this package's build directory (and perhaps others, who knows). I could remove it with sudo. I often find that root is required to delete build directories. Anyway, I don't know if this affects other people or not. What's your opinion of adding the as_ root function to the rm -rf $packagedir command in these Xorg scripts? -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg Font package causes script stop and exit shell
Arthur Radley wrote: > I'm building BLFS from a recent development version. The package > font-bh-ttf-1.0.3.tar.bz2 in Xorg Fonts causes the installation script to > exit with an error... > > rm: cannot remove > 'font-bh-ttf-1.0.3/@baseconfigdir@/conf.avail/42-luxi-mono.conf': Permission > denied > rm: cannot remove > 'font-bh-ttf-1.0.3/@baseconfigdir@/conf.d/42-luxi-mono.conf': Permission > denied > > So some files did not get installed, and it wasn't really obvious either. I > might not have known except for noticing that the exit command did not > return to the previous shell but logged me out of the console. And there was > the build directory still sitting there in the font directory. > > I'm running the Xorg scripts as an ordinary user and Sudo is installed, so > the as_root function is using the sudo "if" condition. I reproduced this > issue by attempting to re-install font-bh-ttf-1.0.3 manually. The ordinary > user cannot delete this package's build directory (and perhaps others, who > knows). I could remove it with sudo. I often find that root is required to > delete build directories. > > Anyway, I don't know if this affects other people or not. What's your > opinion of adding the as_ root function to the rm -rf $packagedir command in > these Xorg scripts? Some packages modify or create packages in the local directory when doing a make install so when you exit sudo, you can't delete those files in the directory. Just go ahead and use sudo to delete. -- 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] Xorg Font package causes script stop and exit shell
Bruce Dubbs gmail.com> writes: > > Some packages modify or create packages in the local directory when > doing a make install so when you exit sudo, you can't delete those files > in the directory. Just go ahead and use sudo to delete. > >-- Bruce > Well, that isn't exactly why I posted about this. I already knew to delete the directory as root. It's more about how I easily could have overlooked this and moved on not knowing that about 600 files did not get installed. I experimented with re-installing Xorg Fonts again with sudo as currently written in the book, and also again as root, and again with the as_root function added to the rm -rf line. The script as it is in the book consistently exits the shell after installing that particular package. Installing Xorg Fonts as root or with the extra as_root function call both install identical complete package sets (I'm using a timestamp package logging script). I just sort of viewed this a potential defect in the those Xorg installation scripts. Maybe not though. Could just be some kind of local issue with me. So long. Arthur -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg Font package causes script stop and exit shell
Arthur Radley wrote: > Bruce Dubbs gmail.com> writes: > >> >> Some packages modify or create packages in the local directory when >> doing a make install so when you exit sudo, you can't delete those files >> in the directory. Just go ahead and use sudo to delete. > Well, that isn't exactly why I posted about this. I already knew to delete > the directory as root. It's more about how I easily could have overlooked > this and moved on not knowing that about 600 files did not get installed. I don't understand why they didn't get installed. I can see that a several directories may be kept that are not needed, but all the files should still be installed. -- 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] Xorg Font package causes script stop and exit shell
Bruce Dubbs gmail.com> writes: > > I don't understand why they didn't get installed. I can see that a > several directories may be kept that are not needed, but all the files > should still be installed. > >-- Bruce That happened because the errors caused by the failure to remove two files in the build directory resulted in the script exiting the shell at that exact point, as it should I guess. That particular package is somewhere in the middle of the md5 file. Nothing following it was installed. All of this happened without a lot of visual evidence that anything went awry. The two single lines reporting the error are plainly there if I am looking for them, but not particularly noticeable the first time as I was moving fast through this stuff as usual. Anyway, the one thing that made me stop and start looking at it was that the exit command logged me out of the console instead of merely dropping back to the previous shell. I repeated this several times. It happens consistently. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xorg Font package causes script stop and exit shell
Arthur Radley wrote: > Bruce Dubbs gmail.com> writes: > >> >> I don't understand why they didn't get installed. I can see that a >> several directories may be kept that are not needed, but all the files >> should still be installed. >> >> -- Bruce > > That happened because the errors caused by the failure to remove two files > in the build directory resulted in the script exiting the shell at that > exact point, as it should I guess. That particular package is somewhere in > the middle of the md5 file. Nothing following it was installed. OK. I see the issue now. We jsut need to add as_root to the rm command. > All of this happened without a lot of visual evidence that anything went > awry. The two single lines reporting the error are plainly there if I am > looking for them, but not particularly noticeable the first time as I was > moving fast through this stuff as usual. > > Anyway, the one thing that made me stop and start looking at it was that the > exit command logged me out of the console instead of merely dropping back to > the previous shell. I repeated this several times. It happens consistently. If the exit is a part of the script started by bash -e, then that shouldn't happen. If it is after the script, I can see that. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
