Re: [lfs-dev] Are we ready for LFS-7.5?
Le 02/03/2014 21:00, akhiezer a écrit : >> Date: Sun, 02 Mar 2014 12:36:34 -0600 >> From: Bruce Dubbs >> To: LFS Developers Mailinglist >> Subject: Re: [lfs-dev] Are we ready for LFS-7.5? >> >> After a fairly extensive discussion, I've update the host system >> requirements page in svn: >> >> http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html >> >> I considered an erratum, but we really don't want to be put in the >> position of having to bring it forward for each release. >> >> What I have is a compromise. I added the note under gcc and added the >> final few lines in the script. I believe that the combination addresses >> the slackware problem. >> >> If I do not hear anything that needs adjustments in the next few hours, >> I will release the current svn as LFS-7.5 stable. >> > > > In the gcc text-section: > -- > * s/have can be/can be/ ? > > * s@look in /usr/lib for @look in /usr/lib (or /usr/lib64) for @ ? > > * s|Either all three should be present or absent, but not only one or > two.|Either all three should be present or absent, in the same directory, but > not only one or two.| ? > > This part addresses multilib hosts, where /usr/lib and /usr/lib64 are > present. > -- > > > Pierre: double-check: are you OK with the 'all three present' part? > Sorry, been out for Sunday... I think host's libmpc.la files are not used, so only libmpfr.la and libgmp.la matter. The matrix of results is that found by Hazel Russman in December: roughly, the build only fails when libmpfr.la is there and libgmp.la isn't. (can be tested on LFS if you remove just libgmp.la) But the wording in host requirements (r10496) looks OK to me. I do not think we should go into too much details. If users do as much test as Hazel Russman, they may complain that it is not exact, but sure it allows the build to succeed. I've begun digging into the gcc tree, to see if it is possible to avoid using host's .la files. I guess we'll find that each configure in each subdirectory generates its own version of libtool, so it might be somewhat difficult to change them all. Actually, only the mpc one is giving trouble, so will work on this one first. Regards Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
> Date: Sun, 02 Mar 2014 14:27:05 -0600 > From: Bruce Dubbs > To: LFS Developers Mailinglist > Subject: Re: [lfs-dev] Are we ready for LFS-7.5? > > >> After a fairly extensive discussion, I've update the host system > >> requirements page in svn: > >> > >> http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html > >> . . > >> > >> What I have is a compromise. I added the note under gcc and added the > >> final few lines in the script. I believe that the combination addresses > >> the slackware problem. > >> > >> If I do not hear anything that needs adjustments in the next few hours, > >> I will release the current svn as LFS-7.5 stable. . . > >> Looks ok from here, as of r10496 (, to within a here-acceptable delta of how would've done it). rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
akhiezer wrote: >> Date: Sun, 02 Mar 2014 12:36:34 -0600 >> From: Bruce Dubbs >> To: LFS Developers Mailinglist >> Subject: Re: [lfs-dev] Are we ready for LFS-7.5? >> >> After a fairly extensive discussion, I've update the host system >> requirements page in svn: >> >> http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html >> >> I considered an erratum, but we really don't want to be put in the >> position of having to bring it forward for each release. >> >> What I have is a compromise. I added the note under gcc and added the >> final few lines in the script. I believe that the combination addresses >> the slackware problem. >> >> If I do not hear anything that needs adjustments in the next few hours, >> I will release the current svn as LFS-7.5 stable. >> > > > In the gcc text-section: > -- > * s/have can be/can be/ ? OK > * s@look in /usr/lib for @look in /usr/lib (or /usr/lib64) for @ ? I've reworded it a bit differently, but added /usr/lib64 > * s|Either all three should be present or absent, but not only one or two.| Either all three should be present or absent, in the same directory, but not only one or two.| ? >This part addresses multilib hosts, where /usr/lib and /usr/lib64 are > present. Too detailed for this corner case. We haven't encountered a pathological situation where the .la files are in different directories. In fact we have only encountered one repeatable instance. > Pierre: double-check: are you OK with the 'all three present' part? > > > In the script part, I'd output the path, as that resolves potential > ambiguity for multilib hosts. It's a test for users to see if they are ready for LFS. :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
On 02/03/2014 22:00, akhiezer wrote: >> Date: Sun, 02 Mar 2014 12:36:34 -0600 >> From: Bruce Dubbs >> To: LFS Developers Mailinglist >> Subject: Re: [lfs-dev] Are we ready for LFS-7.5? >> >> After a fairly extensive discussion, I've update the host system >> requirements page in svn: >> >> http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html >> >> I considered an erratum, but we really don't want to be put in the >> position of having to bring it forward for each release. >> >> What I have is a compromise. I added the note under gcc and added the >> final few lines in the script. I believe that the combination addresses >> the slackware problem. >> >> If I do not hear anything that needs adjustments in the next few hours, >> I will release the current svn as LFS-7.5 stable. >> > > In the gcc text-section: > -- > * s/have can be/can be/ ? > > * s@look in /usr/lib for @look in /usr/lib (or /usr/lib64) for @ ? > > * s|Either all three should be present or absent, but not only one or > two.|Either all three should be present or absent, in the same directory, but > not only one or two.| ? > >This part addresses multilib hosts, where /usr/lib and /usr/lib64 are > present. > -- > > > Pierre: double-check: are you OK with the 'all three present' part? > > > In the script part, I'd output the path, as that resolves potential > ambiguity for multilib hosts. > > > Generally, yes, reasonable+ compromise. > As a blanket statement its fine however they "stack" gmp->mpfr->mpc so it should be ok for gmp to be there alone or gmp+mpfr. i however agree that if any are missing they likely "broken" and should all be removed for safety. a "sed" could fix it modifying the dependency_libs line to replace "s/ .lib\(.*\)\.la/ -l\1/g". *.la files are your friends when building multiple arches into a "sysroot" when used uniformly and consistently they actually not so evil but to obtain this nirvana is not easy with some older packages. see this blog for some info on libtool. https://blog.flameeyes.eu/2008/04/what-about-those-la-files Greg -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
> Date: Sun, 02 Mar 2014 12:36:34 -0600 > From: Bruce Dubbs > To: LFS Developers Mailinglist > Subject: Re: [lfs-dev] Are we ready for LFS-7.5? > > After a fairly extensive discussion, I've update the host system > requirements page in svn: > > http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html > > I considered an erratum, but we really don't want to be put in the > position of having to bring it forward for each release. > > What I have is a compromise. I added the note under gcc and added the > final few lines in the script. I believe that the combination addresses > the slackware problem. > > If I do not hear anything that needs adjustments in the next few hours, > I will release the current svn as LFS-7.5 stable. > In the gcc text-section: -- * s/have can be/can be/ ? * s@look in /usr/lib for @look in /usr/lib (or /usr/lib64) for @ ? * s|Either all three should be present or absent, but not only one or two.|Either all three should be present or absent, in the same directory, but not only one or two.| ? This part addresses multilib hosts, where /usr/lib and /usr/lib64 are present. -- Pierre: double-check: are you OK with the 'all three present' part? In the script part, I'd output the path, as that resolves potential ambiguity for multilib hosts. Generally, yes, reasonable+ compromise. rgds, akh >-- Bruce > -- > -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Bryan Kadzban wrote: > Bryan Kadzban wrote: >> Bruce Dubbs wrote: >>> After a fairly extensive discussion, I've update the host system >>> requirements page in svn: >>> >>> http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html >> >> Looks reasonable to me, unless we want to take lib64 / lib32 into account, >> rather than just lib. I'd hope people can figure that out though, so maybe >> not. > > ...And the find down below does do that, just not the text in the tag, > so even better. :-) I can change the note. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
On 03/02/2014 08:05 PM, Bryan Kadzban wrote: > Armin K. wrote: >> No matter what you say, if a package A installs a file X.Y that requires >> file Z.Y and package A doesn't either: >> >> a) pull automatically the package (depend on) that contains file Z.Y >> b)ships that file itself >> >> the packaging is broken. > > Then BLFS's and LFS's "packaging" are broken, because neither of them does > dependencies. (And nothing pulls them automatically.) In LFS there's an > order of installation that hopefully covers everything, and we try to either > fix up builds (via configure flags or whatever) or provide new deps as they're > discovered, but that's not always perfect. In BLFS there's the list of > dependent packages (and it even does optional / required, which is great!), > but it doesn't do anything automatic. > > My understanding of Slackware (which is rather limited) is that its packaging > has no automatic dependencies either. Yes, this makes it possible to have a > system that doesn't work right. But no, I don't think that's an excuse to say > that it's "broken". An individual system, maybe, but not "the packaging". > Something is. Two people were able to reproduce it using (almost?) the same setup. I must admit that I have never used slackware nor know how it works, but I still think that whatever installs mpfr *.so and *.la files should make sure the same is installed for gmp, too. In LFS we do that by installing gmp before mpfr, so it isn't (and shouldn't be) broken unless you break it yourself by modifying/removing installed files and what not. >> Again, it's irrelevant if mpfr uses host mpfr or not since the target >> library is static library and it won't pull host dependencies at all. > > Um, no, actually. These are .la files, not .a files. There are no static > libs in sight. > Pierre's log shows that link fails at linking mpc (not gcc) static library and libtool is (trying to) using (host's) *.la file to get information on how to link against the static mpfr library but it chokes on finding the gmp file which is listed as a dependency in the mpfr .la file. >> You couldn't install a package that contains libmpfr.so and libmpfr.la (the >> -dev package) on Debian without it pulling package that contains libgmp.so >> and libgmp.la. > > And in Slackware, there is no such thing as a "pulling" of other packages; > just like in BLFS. > > In this particular case, if I understand everything I've read correctly, I > think that either (a) a warning but not an error if any of the three libtool > files are present, or (b) a fix to the gcc build or build system to not use > them from the host at all, would be right. But (b) is rather harder, and not > likely to happen during an -rc anyway. > > I wonder if we can make libtool work right. Looking at gcc's ltmain.sh, line > 5309 is where the host paths are getting in there for libtool --mode=link -o > foo.la, and line 5311 is where the host paths are getting in there for libtool > --mode=link -o foo (i.e. a program). But it's not entirely clear where all > the directory searches are coming from... > > Maybe adding a --debug to the libtool invocation that fails would help figure > out why it's pulling .la files from the host, as opposed to from the build > tree where they're supposed to be pulled from? If anyone has a system that's > in this unbuildable state, that --debug info might help. I'd recommend > running the make that fails, then taking just the last command and adding > --debug to it, and saving the output somewhere (it turns on "set -x", so there > will be a ton of it). > > > -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Bryan Kadzban wrote: > Bruce Dubbs wrote: >> After a fairly extensive discussion, I've update the host system >> requirements page in svn: >> >> http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html > > Looks reasonable to me, unless we want to take lib64 / lib32 into account, > rather than just lib. I'd hope people can figure that out though, so maybe > not. ...And the find down below does do that, just not the text in the tag, so even better. :-) signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Bruce Dubbs wrote: > After a fairly extensive discussion, I've update the host system > requirements page in svn: > > http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html Looks reasonable to me, unless we want to take lib64 / lib32 into account, rather than just lib. I'd hope people can figure that out though, so maybe not. Figuring out a way to fix gcc can happen post-7.5. signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Armin K. wrote: > No matter what you say, if a package A installs a file X.Y that requires > file Z.Y and package A doesn't either: > > a) pull automatically the package (depend on) that contains file Z.Y > b)ships that file itself > > the packaging is broken. Then BLFS's and LFS's "packaging" are broken, because neither of them does dependencies. (And nothing pulls them automatically.) In LFS there's an order of installation that hopefully covers everything, and we try to either fix up builds (via configure flags or whatever) or provide new deps as they're discovered, but that's not always perfect. In BLFS there's the list of dependent packages (and it even does optional / required, which is great!), but it doesn't do anything automatic. My understanding of Slackware (which is rather limited) is that its packaging has no automatic dependencies either. Yes, this makes it possible to have a system that doesn't work right. But no, I don't think that's an excuse to say that it's "broken". An individual system, maybe, but not "the packaging". > Again, it's irrelevant if mpfr uses host mpfr or not since the target > library is static library and it won't pull host dependencies at all. Um, no, actually. These are .la files, not .a files. There are no static libs in sight. > You couldn't install a package that contains libmpfr.so and libmpfr.la (the > -dev package) on Debian without it pulling package that contains libgmp.so > and libgmp.la. And in Slackware, there is no such thing as a "pulling" of other packages; just like in BLFS. In this particular case, if I understand everything I've read correctly, I think that either (a) a warning but not an error if any of the three libtool files are present, or (b) a fix to the gcc build or build system to not use them from the host at all, would be right. But (b) is rather harder, and not likely to happen during an -rc anyway. I wonder if we can make libtool work right. Looking at gcc's ltmain.sh, line 5309 is where the host paths are getting in there for libtool --mode=link -o foo.la, and line 5311 is where the host paths are getting in there for libtool --mode=link -o foo (i.e. a program). But it's not entirely clear where all the directory searches are coming from... Maybe adding a --debug to the libtool invocation that fails would help figure out why it's pulling .la files from the host, as opposed to from the build tree where they're supposed to be pulled from? If anyone has a system that's in this unbuildable state, that --debug info might help. I'd recommend running the make that fails, then taking just the last command and adding --debug to it, and saving the output somewhere (it turns on "set -x", so there will be a ton of it). signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
After a fairly extensive discussion, I've update the host system requirements page in svn: http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html I considered an erratum, but we really don't want to be put in the position of having to bring it forward for each release. What I have is a compromise. I added the note under gcc and added the final few lines in the script. I believe that the combination addresses the slackware problem. If I do not hear anything that needs adjustments in the next few hours, I will release the current svn as LFS-7.5 stable. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Armin K. wrote:
> On 03/02/2014 09:29 AM, Bruce Dubbs wrote:
>> Alice Wonder wrote:
>>> On Sun, 2014-03-02 at 03:06 +0100, Armin K. wrote:
>>>
It is. Package ships *.la file that depends on another *.la file which
no package ships that the former one depends on. Packaging error.
>>>
>>> Indeed, Fedora quite some time ago stopped shipping libtool .la files
>>> because of how frequently they were flat out wrong and the dependency
>>> issues they caused.
>>>
>>> To be honest life is just fine without them. pkgconfig does a better job
>>> at the same thing.
>>>
>>> I hope I wasn't going off-topic on the point, but .la files are fragile
>>> and cause issues especially when you are doing fancy stuff like using a
>>> DESTDIR option to make install.
>>>
>>> For LFS where you typically are building locally they probably are fine
>>> but for package managers, they should not be packaged and pkgconfig
>>> should be used instead.
>>
>> You are right about all of this, but the .la files are created and
>> installed by the upstream make files. They have to be manually removed
>> periodically.
>>
>> Unfortunately, at least one program (gstreamer IIRC) uses .la files at
>> run time to dynamically load modules. That complicates the process of
>> removing them.
>>
>> -- Bruce
>>
>
> Not gstreamer. Only two packages I have ever installed use them at runtime.
>
> ImageMagick (only ones in /usr/lib/ImageMagick*/modules*/)
> libgphoto2 (only ones in /usr/lib/libgphoto*/)
>
> /usr/lib*/*.la files can always be removed, those cause nothing but trouble.
Yes, that was what I was looking for:
find /usr/lib* /usr/local/lib /opt -name \*.la | grep -v
/usr/lib/ImageMagic |grep -v /usr/lib/libgphoto | xargs rm
I got 1425 entries, but I have some older directories contributing:
/opt/{qt-5.1.0,qt-5.1.1,xorg.old,kde-4.10.3,kde-4.11.0,kde-4.11.2,qt-4.8.5.old}
:)
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
> Date: Sun, 02 Mar 2014 01:55:54 -0600
> From: Bruce Dubbs
> To: LFS Developers Mailinglist
> Subject: Re: [lfs-dev] Are we ready for LFS-7.5?
>
.
.
> I think I have the test for version-check.sh:
>
> for lib in lib{gmp,mpfr,mpc}.so; do
>echo $lib: $(if find /usr/lib* -name $lib|
> grep -q $lib;then :;else echo not;fi) found
> done
>
.
.
>
> All of the libraries may not be strictly required, but it errs on the
> side of completeness.
>
> If I can get agreement on this, I can add it and make the 7.5 release
> tomorrow (um, later today).
>
Excuse me if I'm just now gotten brain-tired on this, but how about just
warning if the .la files are present, as follows. I've left it 'wordy'
just to try to be clear here; it can of course be boiled-down.
echo 'Searching for lib{gmp,mpfr,mpc}.la under /usr/lib* :';
for lib in lib{gmp,mpfr,mpc}.la; do
find /usr/lib* -name $lib -ls ;
done;
echo 'If any are shown above as found, then you should either remove them or
move them aside temporarily - e.g. to /var/tmp - otherwise they may cause
problems for compiling gcc in chapter 5.';
The find() '-ls' output is so the user can see orig perms/ownerships/&c,
in case they somehow want to restore later.
Also, I'd be wary of just recommending outright deletion, as it's the
user's host-system.
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
> Date: Sun, 02 Mar 2014 01:55:54 -0600
> From: Bruce Dubbs
> To: LFS Developers Mailinglist
> Subject: Re: [lfs-dev] Are we ready for LFS-7.5?
>
.
.
> I think I have the test for version-check.sh:
>
> for lib in lib{gmp,mpfr,mpc}.so; do
>echo $lib: $(if find /usr/lib* -name $lib|
> grep -q $lib;then :;else echo not;fi) found
> done
>
(You could of course negate the find - 'if ! find ...' - and cut-out the
':;else ' ).
But that still fails - doesn't cover properly - the multilib case (ref the
'Gawd' email): one would need to check 32-bit and 64-bit separately.
Anyhow it may be moot per Pierre's note early today reminding re .la role;
will followup there.
rgds,
akh
> Gives:
>
> libgmp.so: found
> libmpfr.so: found
> libmpc.so: found
>
> or
>
> libgmp.so: not found
> libmpfr.so: found
> libmpc.so: found
>
> All of the libraries may not be strictly required, but it errs on the
> side of completeness.
>
> If I can get agreement on this, I can add it and make the 7.5 release
> tomorrow (um, later today).
>
>-- Bruce
>
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
On 03/02/2014 01:38 PM, akhiezer wrote:
>> Date: Sun, 02 Mar 2014 03:06:12 +0100
>> From: "Armin K."
>> To: LFS Developers Mailinglist
>> Subject: Re: [lfs-dev] Are we ready for LFS-7.5?
>>
> .
> .
>>>>>>
>>>>>> I've just started sendmail. Actually I'm most interested in getting the
>>>>>> slackware issue settled for LFS. That's our only holdup for release.
>>>>>>
>>>>>> -- Bruce
>>>>>
>>>>> Why should we care when it's a distribution issue? Every "sane" distro
>>>
>>>
>>> It's not a 'distribution issue': you're wrong.
>>>
>>>
>>
>> It is. Package ships *.la file that depends on another *.la file which
>> no package ships that the former one depends on. Packaging error.
>>
>
>
> Nope, you're still misapprehending, to say the least, the picture here:
> and perhaps being misled by a 'quick to condemn & cast out' approach rather
> than a 'learn and understand' attitude; the world - and as we all know,
> certain regions even more than others - doesn't need yet more of the former,
> and could do with much more of the latter.
>
>
> The 'a/aaa_elflibs...' package, like the 'a/aaa_base...' and
> 'a/aaa_terminfo...' packages are there to, inter alia, provide foundation to
> the subsequent parts of the install: it's not intended - and the docs make
> that quite clear - that you stop there and have an even minimal consistent
> functioning system. The 'l/...' series &c fill in the rest of the install,
> even for a minimal install.
>
>
> Any distro has a sequence of steps that must be completed before they
> are at the stage of a minimum, or full, &c, install. You don't just stop
> partway through the LFS sequence, end up with a system that has 'gaps'
> (e.g not booting), and yell that it's not a 'sane' distro, and why should
> anyone care about it, and the 'packaging' (1 page ~= 1 pkg) is garbage
> cos it didn't auto-prevent that issue, and so on.
>
>
> That 'a/aaa_elflibs...' package that you're "going on" about, is
> installed at approx the same stage as the 'a/aaa_base...' package: that
> 'a/aaa_base...' package is equivalent to __section **2.1**__ of the lfs book
> ('chapter02/creatingpartition.html'). You try stopping an lfs build that
> early, and immediately label lfs as not 'sane', and not worth 'caring'
> about, and its packaging system borken, and you just make yourself look
> silly.
>
I don't really know what are you talking about since I have always had a
problem understading your "style of writing".
But again:
No matter what you say, if a package A installs a file X.Y that requires
file Z.Y and package A doesn't either:
a) pull automatically the package (depend on) that contains file Z.Y
b) ships that file itself
the packaging is broken. Fill a bug against the package that ships
libmpfr.la in your $distribution. Again, it's irrelevant if mpfr uses
host mpfr or not since the target library is static library and it won't
pull host dependencies at all.
In case of LFS, mpfr and mpc are built after GMP, thus *.so and *.la
files for GMP are always there (we don't advise users to rm anything). I
don't know what is being done in slackware, but I still stand that it's
a packaging issue.
You couldn't install a package that contains libmpfr.so and libmpfr.la
(the -dev package) on Debian without it pulling package that contains
libgmp.so and libgmp.la.
As for default slackware install, I am sure it works since they make
sure that everything gets pulled in, including the package that ships
libgmp.{so,la} and libmpfr.{so,la}, but that's not the case with minimal
setup. Missed dependency or such. Been there, done that.
And as a note - try not to take offense. I'd appreciate if you don't
turn every response that describes things differently than you into a
personal insults or such (even minor ones).
Thanks and have fun. Hope you guys figure this out, I tried to give a
few pointers on what's being done wrong on either side, but I am always
wrong and make myself look silly even though everything that I've said
makes (at least some) sense.
--
Note: My last name is not Krejzi.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
On 03/02/2014 08:55 AM, Bruce Dubbs wrote:
> Bruce Dubbs wrote:
>> Armin K. wrote:
>>> On 2.3.2014 2:55, akhiezer wrote:
>>
>> Why should we care when it's a distribution issue? Every "sane" distro
>>
It's not a 'distribution issue': you're wrong.
>>
>>> It is. Package ships *.la file that depends on another *.la file which
>>> no package ships that the former one depends on. Packaging error.
>>
>> I have to agree with Armin on this point. An .la file is installed that
>> depends on another file that is not installed.
>>
>> That said, I do think we need to address it in some way. Even if it's
>> just a note.
>>
>> I took a look at http://sotirov-bg.net/slackpack/pack.cgi?id=1280 and
>> the item 'SlackBuild: Yes, included' indicates to me that it should be
>> present.
>>
>> It's really up to the user to install it though. We don't want to get
>> into the business on advising how to install a package on a distro.
>>
>> A little googling suggests a check on slackware can be done with:
>>
>> find /var/log/packages -name gmp\*
>
> I think I have the test for version-check.sh:
>
> for lib in lib{gmp,mpfr,mpc}.so; do
>echo $lib: $(if find /usr/lib* -name $lib|
> grep -q $lib;then :;else echo not;fi) found
> done
>
> Gives:
>
> libgmp.so: found
> libmpfr.so: found
> libmpc.so: found
>
> or
>
> libgmp.so: not found
> libmpfr.so: found
> libmpc.so: found
>
> All of the libraries may not be strictly required, but it errs on the
> side of completeness.
>
> If I can get agreement on this, I can add it and make the 7.5 release
> tomorrow (um, later today).
>
>-- Bruce
>
Again, since it's a distribution specific issue, my recommendation is
that it goes into errata.
--
Note: My last name is not Krejzi.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
On 03/02/2014 09:29 AM, Bruce Dubbs wrote: > Alice Wonder wrote: >> On Sun, 2014-03-02 at 03:06 +0100, Armin K. wrote: >> >>> >>> It is. Package ships *.la file that depends on another *.la file which >>> no package ships that the former one depends on. Packaging error. >> >> Indeed, Fedora quite some time ago stopped shipping libtool .la files >> because of how frequently they were flat out wrong and the dependency >> issues they caused. >> >> To be honest life is just fine without them. pkgconfig does a better job >> at the same thing. >> >> I hope I wasn't going off-topic on the point, but .la files are fragile >> and cause issues especially when you are doing fancy stuff like using a >> DESTDIR option to make install. >> >> For LFS where you typically are building locally they probably are fine >> but for package managers, they should not be packaged and pkgconfig >> should be used instead. > > You are right about all of this, but the .la files are created and > installed by the upstream make files. They have to be manually removed > periodically. > > Unfortunately, at least one program (gstreamer IIRC) uses .la files at > run time to dynamically load modules. That complicates the process of > removing them. > >-- Bruce > Not gstreamer. Only two packages I have ever installed use them at runtime. ImageMagick (only ones in /usr/lib/ImageMagick*/modules*/) libgphoto2 (only ones in /usr/lib/libgphoto*/) /usr/lib*/*.la files can always be removed, those cause nothing but trouble. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
> Date: Sat, 01 Mar 2014 20:33:55 -0600
> From: Bruce Dubbs
> To: LFS Developers Mailinglist
> Subject: Re: [lfs-dev] Are we ready for LFS-7.5?
>
> Armin K. wrote:
> > On 2.3.2014 2:55, akhiezer wrote:
>
> >>>> Why should we care when it's a distribution issue? Every "sane" distro
>
> >> It's not a 'distribution issue': you're wrong.
>
> > It is. Package ships *.la file that depends on another *.la file which
> > no package ships that the former one depends on. Packaging error.
>
> I have to agree with Armin on this point. An .la file is installed that
> depends on another file that is not installed.
>
Two wrongs ... ; ref note to Armin on such perceptions; and ref foot of
below further on package dependencies.
> That said, I do think we need to address it in some way. Even if it's
> just a note.
>
> I took a look at http://sotirov-bg.net/slackpack/pack.cgi?id=1280 and
> the item 'SlackBuild: Yes, included' indicates to me that it should be
> present.
(Hmmm, that's a secondary/tertiary reference, surely - and no offence to
them, I'm sure they'd agree at least re 'non-primary ref'.)
>
> It's really up to the user to install it though. We don't want to get
> into the business on advising how to install a package on a distro.
>
> A little googling suggests a check on slackware can be done with:
>
> find /var/log/packages -name gmp\*
>
Not entirely sure what point is being made there: but here goes: yes,
the 'l/' series - that includes the lib{gmp,mpc,mpfr} - is expected
to be installed for even a minimal install; and the docs make this
absolutely clear. (Info on install/upgrade is stored mainly under:
/var/log/{setup,{removed_,}{packages,scripts}}/{gmp,libmpc,mpfr}* - NB the
'lib'mpc, re name clash with some other software.)
At the same time, slackware will allow you to install whatever packages you
want; and it - by and large - won't hold your hand for auto- dependency
checking. It's rather like b/lfs in at least that respect: if you know
enough to chop'n'change away from default supported methods (cf 'follow book,
...') then it is assumed that you know enough to do the right things and
to handle any fall-out; tho' of course folks'll still help - just like
for b/lfs.
Hope that helps clarify at least some things.
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
> Date: Sun, 02 Mar 2014 03:06:12 +0100
> From: "Armin K."
> To: LFS Developers Mailinglist
> Subject: Re: [lfs-dev] Are we ready for LFS-7.5?
>
.
.
> >>>>
> >>>> I've just started sendmail. Actually I'm most interested in getting the
> >>>> slackware issue settled for LFS. That's our only holdup for release.
> >>>>
> >>>> -- Bruce
> >>>
> >>> Why should we care when it's a distribution issue? Every "sane" distro
> >
> >
> > It's not a 'distribution issue': you're wrong.
> >
> >
>
> It is. Package ships *.la file that depends on another *.la file which
> no package ships that the former one depends on. Packaging error.
>
Nope, you're still misapprehending, to say the least, the picture here:
and perhaps being misled by a 'quick to condemn & cast out' approach rather
than a 'learn and understand' attitude; the world - and as we all know,
certain regions even more than others - doesn't need yet more of the former,
and could do with much more of the latter.
The 'a/aaa_elflibs...' package, like the 'a/aaa_base...' and
'a/aaa_terminfo...' packages are there to, inter alia, provide foundation to
the subsequent parts of the install: it's not intended - and the docs make
that quite clear - that you stop there and have an even minimal consistent
functioning system. The 'l/...' series &c fill in the rest of the install,
even for a minimal install.
Any distro has a sequence of steps that must be completed before they
are at the stage of a minimum, or full, &c, install. You don't just stop
partway through the LFS sequence, end up with a system that has 'gaps'
(e.g not booting), and yell that it's not a 'sane' distro, and why should
anyone care about it, and the 'packaging' (1 page ~= 1 pkg) is garbage
cos it didn't auto-prevent that issue, and so on.
That 'a/aaa_elflibs...' package that you're "going on" about, is
installed at approx the same stage as the 'a/aaa_base...' package: that
'a/aaa_base...' package is equivalent to __section **2.1**__ of the lfs book
('chapter02/creatingpartition.html'). You try stopping an lfs build that
early, and immediately label lfs as not 'sane', and not worth 'caring'
about, and its packaging system borken, and you just make yourself look
silly.
> >>> works just fine except slackware.
> >
> >
> > Slackware non-'pathological'-install works fine in this respect: you're
> > wrong.
> >
Ditto.
> >
> >>> So let them fix it instead of us.
> >
> >
> > What needs fixing is your rant borne from lack of understanding and goodness
> > knows what else ... .
> >
> >
> > Just to be perhaps even clearer:
> > --
> > * even a modicum of understanding of the thread - as opposed to some of
> > the recent off-the-cuff postings from the side - would let you realise
> > that a normal slackware installation is just fine for building gcc per
> > lfs instructions.
> >
> > * it's not a distro issue per se: it's, roughly speaking, how gcc looks
> > into host-os and makes a slightly-less-than-rigourous assumption or two.
> > --
> >
> >
> >>
> >>
> >> The real core of the issue is how gcc is looking for mpfr/mpc/gmp .
>
> According to Pierre's test, it's mpc issue, not gcc. mpc tries to use
> host's libmpfr.la (for a static library it shouldn't matter if it uses
> host or bundled one imho), but it fails to do so because host's
> libmpfr.la tries to use host's libgmp.la which is not installed by any
> package that mpfr (should) depend(s) on.
>
Yes, that's taken as read, in both the new (2014) thread, and in the
original (2013) thread once it was clearer what was going on. The term
'gcc' is used as a shorthand - e.g. for the gcc build seq (incl sub-seq)
in lfs book - in the threads, where the context is clear to at least those
that are following the thread in good faith.
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Em 02-03-2014 05:29, Bruce Dubbs escreveu: > Alice Wonder wrote: >> On Sun, 2014-03-02 at 03:06 +0100, Armin K. wrote: >> >>> >>> It is. Package ships *.la file that depends on another *.la file which >>> no package ships that the former one depends on. Packaging error. >> >> Indeed, Fedora quite some time ago stopped shipping libtool .la files >> because of how frequently they were flat out wrong and the dependency >> issues they caused. >> >> To be honest life is just fine without them. pkgconfig does a better job >> at the same thing. >> >> I hope I wasn't going off-topic on the point, but .la files are fragile >> and cause issues especially when you are doing fancy stuff like using a >> DESTDIR option to make install. >> >> For LFS where you typically are building locally they probably are fine >> but for package managers, they should not be packaged and pkgconfig >> should be used instead. > > You are right about all of this, but the .la files are created and > installed by the upstream make files. They have to be manually removed > periodically. > > Unfortunately, at least one program (gstreamer IIRC) uses .la files at > run time to dynamically load modules. That complicates the process of > removing them. > >-- Bruce > While in this discussion about version-check.sh. I acnnot understand, but it seems to be still one of the most frequent failures from the user. I gave a reply telling one user: *Each line of the output is relevant.* I would add: "If different from what is recommended in the page, fix, before proceeding." I think I note, caution or warning (in red, not yellow, but I think it is impossible in red) could be inserted just in the beginning of the page or just before the script. I have discussed this many times, apologies for writing about again. Bruce sometimes accepted, made modifications, sometimes did not. The problem is recurrent, situation is much better now, but I believe that someday a definitive "magical" solution will be found. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Alice Wonder wrote: > On Sun, 2014-03-02 at 03:06 +0100, Armin K. wrote: > >> >> It is. Package ships *.la file that depends on another *.la file which >> no package ships that the former one depends on. Packaging error. > > Indeed, Fedora quite some time ago stopped shipping libtool .la files > because of how frequently they were flat out wrong and the dependency > issues they caused. > > To be honest life is just fine without them. pkgconfig does a better job > at the same thing. > > I hope I wasn't going off-topic on the point, but .la files are fragile > and cause issues especially when you are doing fancy stuff like using a > DESTDIR option to make install. > > For LFS where you typically are building locally they probably are fine > but for package managers, they should not be packaged and pkgconfig > should be used instead. You are right about all of this, but the .la files are created and installed by the upstream make files. They have to be manually removed periodically. Unfortunately, at least one program (gstreamer IIRC) uses .la files at run time to dynamically load modules. That complicates the process of removing them. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
On Sun, 2014-03-02 at 03:06 +0100, Armin K. wrote: > > It is. Package ships *.la file that depends on another *.la file which > no package ships that the former one depends on. Packaging error. Indeed, Fedora quite some time ago stopped shipping libtool .la files because of how frequently they were flat out wrong and the dependency issues they caused. To be honest life is just fine without them. pkgconfig does a better job at the same thing. I hope I wasn't going off-topic on the point, but .la files are fragile and cause issues especially when you are doing fancy stuff like using a DESTDIR option to make install. For LFS where you typically are building locally they probably are fine but for package managers, they should not be packaged and pkgconfig should be used instead. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Bruce Dubbs wrote:
> Armin K. wrote:
>> On 2.3.2014 2:55, akhiezer wrote:
>
> Why should we care when it's a distribution issue? Every "sane" distro
>
>>> It's not a 'distribution issue': you're wrong.
>
>> It is. Package ships *.la file that depends on another *.la file which
>> no package ships that the former one depends on. Packaging error.
>
> I have to agree with Armin on this point. An .la file is installed that
> depends on another file that is not installed.
>
> That said, I do think we need to address it in some way. Even if it's
> just a note.
>
> I took a look at http://sotirov-bg.net/slackpack/pack.cgi?id=1280 and
> the item 'SlackBuild: Yes, included' indicates to me that it should be
> present.
>
> It's really up to the user to install it though. We don't want to get
> into the business on advising how to install a package on a distro.
>
> A little googling suggests a check on slackware can be done with:
>
> find /var/log/packages -name gmp\*
I think I have the test for version-check.sh:
for lib in lib{gmp,mpfr,mpc}.so; do
echo $lib: $(if find /usr/lib* -name $lib|
grep -q $lib;then :;else echo not;fi) found
done
Gives:
libgmp.so: found
libmpfr.so: found
libmpc.so: found
or
libgmp.so: not found
libmpfr.so: found
libmpc.so: found
All of the libraries may not be strictly required, but it errs on the
side of completeness.
If I can get agreement on this, I can add it and make the 7.5 release
tomorrow (um, later today).
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Armin K. wrote: > On 2.3.2014 2:55, akhiezer wrote: Why should we care when it's a distribution issue? Every "sane" distro >> It's not a 'distribution issue': you're wrong. > It is. Package ships *.la file that depends on another *.la file which > no package ships that the former one depends on. Packaging error. I have to agree with Armin on this point. An .la file is installed that depends on another file that is not installed. That said, I do think we need to address it in some way. Even if it's just a note. I took a look at http://sotirov-bg.net/slackpack/pack.cgi?id=1280 and the item 'SlackBuild: Yes, included' indicates to me that it should be present. It's really up to the user to install it though. We don't want to get into the business on advising how to install a package on a distro. A little googling suggests a check on slackware can be done with: find /var/log/packages -name gmp\* -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
On 2.3.2014 2:55, akhiezer wrote: >> Date: Sun, 02 Mar 2014 01:22:26 + >> From: lf...@cruziero.com (akhiezer) >> To: LFS Developers Mailinglist >> Subject: Re: [lfs-dev] Are we ready for LFS-7.5? >> >>> Date: Sun, 02 Mar 2014 01:36:21 +0100 >>> From: "Armin K." >>> To: LFS Developers Mailinglist >>> Subject: Re: [lfs-dev] Are we ready for LFS-7.5? >>> >> . >> . >>>> >>>> I've just started sendmail. Actually I'm most interested in getting the >>>> slackware issue settled for LFS. That's our only holdup for release. >>>> >>>> -- Bruce >>> >>> Why should we care when it's a distribution issue? Every "sane" distro > > > It's not a 'distribution issue': you're wrong. > > It is. Package ships *.la file that depends on another *.la file which no package ships that the former one depends on. Packaging error. >>> works just fine except slackware. > > > Slackware non-'pathological'-install works fine in this respect: you're > wrong. > > >>> So let them fix it instead of us. > > > What needs fixing is your rant borne from lack of understanding and goodness > knows what else ... . > > > Just to be perhaps even clearer: > -- > * even a modicum of understanding of the thread - as opposed to some of > the recent off-the-cuff postings from the side - would let you realise > that a normal slackware installation is just fine for building gcc per > lfs instructions. > > * it's not a distro issue per se: it's, roughly speaking, how gcc looks > into host-os and makes a slightly-less-than-rigourous assumption or two. > -- > > >> >> >> The real core of the issue is how gcc is looking for mpfr/mpc/gmp . According to Pierre's test, it's mpc issue, not gcc. mpc tries to use host's libmpfr.la (for a static library it shouldn't matter if it uses host or bundled one imho), but it fails to do so because host's libmpfr.la tries to use host's libgmp.la which is not installed by any package that mpfr (should) depend(s) on. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
> Date: Sun, 02 Mar 2014 01:22:26 +
> From: lf...@cruziero.com (akhiezer)
> To: LFS Developers Mailinglist
> Subject: Re: [lfs-dev] Are we ready for LFS-7.5?
>
> > Date: Sun, 02 Mar 2014 01:36:21 +0100
> > From: "Armin K."
> > To: LFS Developers Mailinglist
> > Subject: Re: [lfs-dev] Are we ready for LFS-7.5?
> >
> .
> .
> > >
> > > I've just started sendmail. Actually I'm most interested in getting the
> > > slackware issue settled for LFS. That's our only holdup for release.
> > >
> > > -- Bruce
> >
> > Why should we care when it's a distribution issue? Every "sane" distro
It's not a 'distribution issue': you're wrong.
> > works just fine except slackware.
Slackware non-'pathological'-install works fine in this respect: you're
wrong.
> > So let them fix it instead of us.
What needs fixing is your rant borne from lack of understanding and goodness
knows what else ... .
Just to be perhaps even clearer:
--
* even a modicum of understanding of the thread - as opposed to some of
the recent off-the-cuff postings from the side - would let you realise
that a normal slackware installation is just fine for building gcc per
lfs instructions.
* it's not a distro issue per se: it's, roughly speaking, how gcc looks
into host-os and makes a slightly-less-than-rigourous assumption or two.
--
>
>
> The real core of the issue is how gcc is looking for mpfr/mpc/gmp .
>
>
> The lfs build approach for gcc is actually 'advised against' by at least
> part of upstream: so maybe that needs reviewed, likely post-7.5 (cf also
> Pierre's posts from earlier on Sat 1st); and gcc upstream could - _if_
> they were at all like you - take a 'let LFS fix it' approach on any gcc
> issues ("don't bug us unless you fix your build approach", etc).
>
>
>
> rgds,
> akh
>
>
>
> > An errata entry should be fine.
Likewise the mooted host-os-reqs adjustment should be similarly
straightforward.
> > The other solution is to "rm $(grep -rl
> > libgmp.la /usr/lib*/)" since the issue seems to come from another .la
> > file which seems to pull libgmp.la, but the latter one isn't arround.
Right now, I think folks at most want to adjust host-os-reqs.
Post-7.5, I think a better fix than that 'rm ...' is desirable and likely.
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
> Date: Sun, 02 Mar 2014 01:36:21 +0100
> From: "Armin K."
> To: LFS Developers Mailinglist
> Subject: Re: [lfs-dev] Are we ready for LFS-7.5?
>
.
.
> >
> > I've just started sendmail. Actually I'm most interested in getting the
> > slackware issue settled for LFS. That's our only holdup for release.
> >
> > -- Bruce
>
> Why should we care when it's a distribution issue? Every "sane" distro
> works just fine except slackware. So let them fix it instead of us.
>
The real core of the issue is how gcc is looking for mpfr/mpc/gmp .
The lfs build approach for gcc is actually 'advised against' by at least
part of upstream: so maybe that needs reviewed, likely post-7.5 (cf also
Pierre's posts from earlier on Sat 1st); and gcc upstream could - _if_
they were at all like you - take a 'let LFS fix it' approach on any gcc
issues ("don't bug us unless you fix your build approach", etc).
rgds,
akh
> An errata entry should be fine. The other solution is to "rm $(grep -rl
> libgmp.la /usr/lib*/)" since the issue seems to come from another .la
> file which seems to pull libgmp.la, but the latter one isn't arround.
> --
>
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
On 1.3.2014 23:44, Bruce Dubbs wrote: > Pierre Labastie wrote: >> Le 01/03/2014 22:58, Bruce Dubbs a écrit : >>> Pierre Labastie wrote: Le 28/02/2014 23:24, Bruce Dubbs a écrit : >>> Now, I have a question. I have never been involved in development, so just take my question as a mark of curiosity: what is the reason to expect release of LFS and BLFS to be close in time? I would think of something like: - LFS rc1 (duration: a few weeks, unless there is a need for rc2): - freeze packages on LFS - extensive testing of LFS build; correct security issues and blockers - update BLFS svn as usual - LFS stable, BLFS test against LFS (duration: a month or so): - restart updating LFS svn - stop testing/updating BLFS against the previous LFS release - begin building/updating/tagging BLFS against the recent LFS release - BLFS rc1 (duration: a few weeks + possibly rc2,3...): - freeze packages on BLFS. - extensive testing of BLFS build; correct security issues and blockers - tag untagged packages - BLFS stable What I see as an advantage is that during the LFS rc stage, it is still possible to change a few things on LFS, without risk to break already tagged pacakges in BLFS. But there may be drawbacks I do not see... >>> >>> The problem is that upstream changes packages very often and it takes >>> time to check BLFS. We did a package freeze two weeks ago and LFS has >>> had 7 packages update. BLFS has had about 40 update in the same time. >>> If we update a library, then what does that say about the testing of >>> packages that may need that library but have already been tested? >>> >>> For many years, we didn't release a 'stable' BLFS at all. We just used >>> a rolling release. We've got some more help now, so the freeze time is >>> relatively short. >>> >>> Testing the LFS build is actually fairly quick. With alfs and skipping >>> checks, we can do it in a couple of hours. The real test is whether >>> BLFS builds on it. Unfortunately, as you know, it's difficult to >>> automate BLFS. >>> >>> It's all a tradeoff. We are almost ready. The only things left right >>> now are fretts, gnash, and sendmail. >>> >> >> Yeah, I have seen that this morning, only two packages left, it is >> incredible! >> + sendmail in archive. I feel bad I have done such a small part, and you have >> done a wonderful job. >> >> I cannot test any multimedia app (no sound). >> >> I can have a look at sendmail, if nobody is working on it (tomorrow... it is >> late here). > > I've just started sendmail. Actually I'm most interested in getting the > slackware issue settled for LFS. That's our only holdup for release. > > -- Bruce Why should we care when it's a distribution issue? Every "sane" distro works just fine except slackware. So let them fix it instead of us. An errata entry should be fine. The other solution is to "rm $(grep -rl libgmp.la /usr/lib*/)" since the issue seems to come from another .la file which seems to pull libgmp.la, but the latter one isn't arround. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Pierre Labastie wrote: > Le 01/03/2014 22:58, Bruce Dubbs a écrit : >> Pierre Labastie wrote: >>> Le 28/02/2014 23:24, Bruce Dubbs a écrit : >> >>> Now, I have a question. I have never been involved in development, so just >>> take my question as a mark of curiosity: what is the reason to expect >>> release >>> of LFS and BLFS to be close in time? I would think of something like: >>> >>> - LFS rc1 (duration: a few weeks, unless there is a need for rc2): >>> - freeze packages on LFS >>> - extensive testing of LFS build; correct security issues and blockers >>> - update BLFS svn as usual >>> - LFS stable, BLFS test against LFS (duration: a month or so): >>> - restart updating LFS svn >>> - stop testing/updating BLFS against the previous LFS release >>> - begin building/updating/tagging BLFS against the recent LFS release >>> - BLFS rc1 (duration: a few weeks + possibly rc2,3...): >>> - freeze packages on BLFS. >>> - extensive testing of BLFS build; correct security issues and blockers >>> - tag untagged packages >>> - BLFS stable >>> >>> What I see as an advantage is that during the LFS rc stage, it is still >>> possible to change a few things on LFS, without risk to break already tagged >>> pacakges in BLFS. But there may be drawbacks I do not see... >> >> The problem is that upstream changes packages very often and it takes >> time to check BLFS. We did a package freeze two weeks ago and LFS has >> had 7 packages update. BLFS has had about 40 update in the same time. >> If we update a library, then what does that say about the testing of >> packages that may need that library but have already been tested? >> >> For many years, we didn't release a 'stable' BLFS at all. We just used >> a rolling release. We've got some more help now, so the freeze time is >> relatively short. >> >> Testing the LFS build is actually fairly quick. With alfs and skipping >> checks, we can do it in a couple of hours. The real test is whether >> BLFS builds on it. Unfortunately, as you know, it's difficult to >> automate BLFS. >> >> It's all a tradeoff. We are almost ready. The only things left right >> now are fretts, gnash, and sendmail. >> > > Yeah, I have seen that this morning, only two packages left, it is incredible! > + sendmail in archive. I feel bad I have done such a small part, and you have > done a wonderful job. > > I cannot test any multimedia app (no sound). > > I can have a look at sendmail, if nobody is working on it (tomorrow... it is > late here). I've just started sendmail. Actually I'm most interested in getting the slackware issue settled for LFS. That's our only holdup for release. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Le 01/03/2014 22:58, Bruce Dubbs a écrit : > Pierre Labastie wrote: >> Le 28/02/2014 23:24, Bruce Dubbs a écrit : > >> Now, I have a question. I have never been involved in development, so just >> take my question as a mark of curiosity: what is the reason to expect release >> of LFS and BLFS to be close in time? I would think of something like: >> >> - LFS rc1 (duration: a few weeks, unless there is a need for rc2): >>- freeze packages on LFS >>- extensive testing of LFS build; correct security issues and blockers >>- update BLFS svn as usual >> - LFS stable, BLFS test against LFS (duration: a month or so): >>- restart updating LFS svn >>- stop testing/updating BLFS against the previous LFS release >>- begin building/updating/tagging BLFS against the recent LFS release >> - BLFS rc1 (duration: a few weeks + possibly rc2,3...): >>- freeze packages on BLFS. >>- extensive testing of BLFS build; correct security issues and blockers >>- tag untagged packages >> - BLFS stable >> >> What I see as an advantage is that during the LFS rc stage, it is still >> possible to change a few things on LFS, without risk to break already tagged >> pacakges in BLFS. But there may be drawbacks I do not see... > > The problem is that upstream changes packages very often and it takes > time to check BLFS. We did a package freeze two weeks ago and LFS has > had 7 packages update. BLFS has had about 40 update in the same time. > If we update a library, then what does that say about the testing of > packages that may need that library but have already been tested? > > For many years, we didn't release a 'stable' BLFS at all. We just used > a rolling release. We've got some more help now, so the freeze time is > relatively short. > > Testing the LFS build is actually fairly quick. With alfs and skipping > checks, we can do it in a couple of hours. The real test is whether > BLFS builds on it. Unfortunately, as you know, it's difficult to > automate BLFS. > > It's all a tradeoff. We are almost ready. The only things left right > now are fretts, gnash, and sendmail. > Yeah, I have seen that this morning, only two packages left, it is incredible! + sendmail in archive. I feel bad I have done such a small part, and you have done a wonderful job. I cannot test any multimedia app (no sound). I can have a look at sendmail, if nobody is working on it (tomorrow... it is late here). Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Pierre Labastie wrote: > Le 28/02/2014 23:24, Bruce Dubbs a écrit : > Now, I have a question. I have never been involved in development, so just > take my question as a mark of curiosity: what is the reason to expect release > of LFS and BLFS to be close in time? I would think of something like: > > - LFS rc1 (duration: a few weeks, unless there is a need for rc2): >- freeze packages on LFS >- extensive testing of LFS build; correct security issues and blockers >- update BLFS svn as usual > - LFS stable, BLFS test against LFS (duration: a month or so): >- restart updating LFS svn >- stop testing/updating BLFS against the previous LFS release >- begin building/updating/tagging BLFS against the recent LFS release > - BLFS rc1 (duration: a few weeks + possibly rc2,3...): >- freeze packages on BLFS. >- extensive testing of BLFS build; correct security issues and blockers >- tag untagged packages > - BLFS stable > > What I see as an advantage is that during the LFS rc stage, it is still > possible to change a few things on LFS, without risk to break already tagged > pacakges in BLFS. But there may be drawbacks I do not see... The problem is that upstream changes packages very often and it takes time to check BLFS. We did a package freeze two weeks ago and LFS has had 7 packages update. BLFS has had about 40 update in the same time. If we update a library, then what does that say about the testing of packages that may need that library but have already been tested? For many years, we didn't release a 'stable' BLFS at all. We just used a rolling release. We've got some more help now, so the freeze time is relatively short. Testing the LFS build is actually fairly quick. With alfs and skipping checks, we can do it in a couple of hours. The real test is whether BLFS builds on it. Unfortunately, as you know, it's difficult to automate BLFS. It's all a tradeoff. We are almost ready. The only things left right now are fretts, gnash, and sendmail. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Le 28/02/2014 23:24, Bruce Dubbs a écrit : > Fernando de Oliveira wrote: >> Em 28-02-2014 18:23, Ken Moffat escreveu: >> >>> i686, nor if we should care. >> >> Is i686 gong to be deprecated? > > I don't think so. My main system is still a 686, but I don't normally > do a full development on it. If we don't have the hardware, then we > could always build in a virtual environment. > >-- Bruce > > > FWIW, I've built successfully rc1 on virtual 32 bit, but not done much BLFS testing. Now, I have a question. I have never been involved in development, so just take my question as a mark of curiosity: what is the reason to expect release of LFS and BLFS to be close in time? I would think of something like: - LFS rc1 (duration: a few weeks, unless there is a need for rc2): - freeze packages on LFS - extensive testing of LFS build; correct security issues and blockers - update BLFS svn as usual - LFS stable, BLFS test against LFS (duration: a month or so): - restart updating LFS svn - stop testing/updating BLFS against the previous LFS release - begin building/updating/tagging BLFS against the recent LFS release - BLFS rc1 (duration: a few weeks + possibly rc2,3...): - freeze packages on BLFS. - extensive testing of BLFS build; correct security issues and blockers - tag untagged packages - BLFS stable What I see as an advantage is that during the LFS rc stage, it is still possible to change a few things on LFS, without risk to break already tagged pacakges in BLFS. But there may be drawbacks I do not see... Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Fernando de Oliveira wrote: > Em 28-02-2014 18:23, Ken Moffat escreveu: > >> i686, nor if we should care. > > Is i686 gong to be deprecated? I don't think so. My main system is still a 686, but I don't normally do a full development on it. If we don't have the hardware, then we could always build in a virtual environment. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
Em 28-02-2014 18:23, Ken Moffat escreveu: > i686, nor if we should care. Is i686 gong to be deprecated? -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
On Fri, Feb 28, 2014 at 01:15:10PM -0600, Bruce Dubbs wrote: > > So the questions is whether we should release 7.5 tomorrow or not. We > could wait for BLFS, but I'm not sure that's really necessary. > As far as I am concerned, LFS -rc1 seems fine : but I've only built it on x86_64 desktops (two machines, three builds, all deviating by using eudev). I'm fine with either releasing now, or with waiting for BLFS. My only reservation is that I've no idea what sort of coverage there has been in testing for i686, nor if we should care. For once, I'm glad that you haven't rolled the kernel forward - 3.13.4 seems good, but 3.13.5 had an issue (using it on one machine) which caused me to drop back to 3.13.4. I'm now using my time to try to replicate the problem on a kernel with a lot of debugging features enabled, so far without any success. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
akhiezer wrote: >> Date: Fri, 28 Feb 2014 13:15:10 -0600 >> From: Bruce Dubbs >> To: LFS Developers Mailinglist >> Subject: [lfs-dev] Are we ready for LFS-7.5? >> >> The commit for -rc1 was on Feb 16. Since then there have been text >> changes plus the following: >> >> Update kmod to install man pages properly. >> Delete symlinks in /usr and add /usr/libexec. >> Add a patch for glibc FHS issues. >> >> There is also ticket #3705. It really looks like a user error to me, > > > '3507' ? Yes. 3507. >> but I'm inclined to not address it now and add an erratum later if >> necessary. >> >> BLFS is not yet read and will take a few more days to get the 30 or so >> packages not yet tested done. >> >> So the questions is whether we should release 7.5 tomorrow or not. We >> could wait for BLFS, but I'm not sure that's really necessary. >> > > > Extra-'publicity', for the staggered release? > > > Also, it'd seem to make sense to release LFS when it's ready, then BLFS > (hopefully within ~~3-4 weeks) when _it's_ ready. > > >> Note: I predicted 4-6 new LFS packages released during the package >> freeze. I underestimated. There are seven, but the kernel, man-pages, >> grep, and systemd have all had two releases in the last two weeks. >> > > > Maybe vindicates not doing late-adoptions, if they'd bugfixes released in > such short order. Yes, it's too bad they don't do -rc releases to sort out the bugs. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
On 28.2.2014 20:15, Bruce Dubbs wrote: > The commit for -rc1 was on Feb 16. Since then there have been text > changes plus the following: > > Update kmod to install man pages properly. > Delete symlinks in /usr and add /usr/libexec. > Add a patch for glibc FHS issues. > > There is also ticket #3705. It really looks like a user error to me, > but I'm inclined to not address it now and add an erratum later if > necessary. > > BLFS is not yet read and will take a few more days to get the 30 or so > packages not yet tested done. > > So the questions is whether we should release 7.5 tomorrow or not. We > could wait for BLFS, but I'm not sure that's really necessary. > > Note: I predicted 4-6 new LFS packages released during the package > freeze. I underestimated. There are seven, but the kernel, man-pages, > grep, and systemd have all had two releases in the last two weeks. > > -- Bruce > I don't think any of the changes were major enough to delay the release further. I say go for it, no need to wait for BLFS. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Are we ready for LFS-7.5?
> Date: Fri, 28 Feb 2014 13:15:10 -0600 > From: Bruce Dubbs > To: LFS Developers Mailinglist > Subject: [lfs-dev] Are we ready for LFS-7.5? > > The commit for -rc1 was on Feb 16. Since then there have been text > changes plus the following: > > Update kmod to install man pages properly. > Delete symlinks in /usr and add /usr/libexec. > Add a patch for glibc FHS issues. > > There is also ticket #3705. It really looks like a user error to me, '3507' ? > but I'm inclined to not address it now and add an erratum later if > necessary. > > BLFS is not yet read and will take a few more days to get the 30 or so > packages not yet tested done. > > So the questions is whether we should release 7.5 tomorrow or not. We > could wait for BLFS, but I'm not sure that's really necessary. > Extra-'publicity', for the staggered release? Also, it'd seem to make sense to release LFS when it's ready, then BLFS (hopefully within ~~3-4 weeks) when _it's_ ready. > Note: I predicted 4-6 new LFS packages released during the package > freeze. I underestimated. There are seven, but the kernel, man-pages, > grep, and systemd have all had two releases in the last two weeks. > Maybe vindicates not doing late-adoptions, if they'd bugfixes released in such short order. akh -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
