Ken Moffat wrote:
> When I woke up in the
> morning, I was surprised to find that my OpenJDK script was still running
> rm -rf for the source directory, and had been doing so for more than 5
> hours (both wall-clock time and CPU time), and was now at 99%-100% of one
> CPU, according to top.
...Odd
Ken Moffat wrote:
> On Sun, Mar 02, 2014 at 05:47:36PM -0600, Bruce Dubbs wrote:
>> Ken, You mentioned a problem with linux-3.13.5. Can you explain your
>> issues with that version?
>>
>> -- Bruce
>
> Ah! I've just put a short summary in my reply to you re libexecdir
> on blfs-dev. Here's
On Sun, Mar 02, 2014 at 05:47:36PM -0600, Bruce Dubbs wrote:
> Ken, You mentioned a problem with linux-3.13.5. Can you explain your
> issues with that version?
>
>-- Bruce
Ah! I've just put a short summary in my reply to you re libexecdir
on blfs-dev. Here's a MUCH fuller one:
I built
On 3/2/2014 4:31 PM, Bruce Dubbs wrote:
> The Linux From Scratch community is pleased to announce the release of
> LFS Version 7.5.
> [snip]
I would like to say that it pleases me that the LFS community is as
active as it is, and congratulations on another release of this fine
product. LFS is as a
I am pleased to announce the first stable release of the Linux From
Scratch book that is using systemd as the init system.
For a quick summary about differences between this and the official LFS
book see the first release candidate announcement[1].
The book can be read online[2] or downloaded[3]
Ken, You mentioned a problem with linux-3.13.5. Can you explain your
issues with that version?
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
The Linux From Scratch community is pleased to announce the release of
LFS Version 7.5.
This release includes numerous changes to LFS-7.4 (including updates to
Linux-3.13.3, GCC-4.8.2, Glibc-2.19, binutils-2.24) and security fixes.
It also includes editorial work on the explanatory material thro
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:
>>
>> ht
> 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
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
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:
> 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/developmen
On 03/02/2014 10:13 AM, William Harrington wrote:
> On Mar 2, 2014, at 8:22 AM, thomas wrote:
>
>> If I remember right, at least in previous versions of the kernel
>> sources
>> the target directory had been cleared before the headers were written.
>> That would be no good for the /tools/include d
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 ta
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 pack
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 accou
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
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"
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.
Wha
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.
>>>
On Mar 2, 2014, at 8:22 AM, thomas wrote:
> If I remember right, at least in previous versions of the kernel
> sources
> the target directory had been cleared before the headers were written.
> That would be no good for the /tools/include dir but meaningless for
> the
> newly created "dest" d
> Date: Sun, 02 Mar 2014 11:11:50 +0100
> From: Pierre Labastie
> To: LFS Developers Mailinglist
> Subject: Re: [lfs-dev] gcc pass 1/2 instructions re mpfr/gmp/mpc.
>
.
.
>
> But useless!!!
>
Thanks for the reminder and re-pointing to .la ;] .
> lib{gmp,mpfr,mpc}.so
> 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 $
On 03/02/2014 09:22 AM, thomas wrote:
> Am Sonntag, den 02.03.2014, 08:36 -0500 schrieb baho utot:
>> Why is the installation of the headers in the book like this
>>
>> make INSTALL_HDR_PATH=dest headers_install
>> cp -rv dest/include/* /tools/include
>>
>> instead of
>>
>> make INSTALL_HDR_PATH=/
Am Sonntag, den 02.03.2014, 08:36 -0500 schrieb baho utot:
> Why is the installation of the headers in the book like this
>
> make INSTALL_HDR_PATH=dest headers_install
> cp -rv dest/include/* /tools/include
>
> instead of
>
> make INSTALL_HDR_PATH=/tools/include headers_install
if at all, than
> 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 $
Why is the installation of the headers in the book like this
make INSTALL_HDR_PATH=dest headers_install
cp -rv dest/include/* /tools/include
instead of
make INSTALL_HDR_PATH=/tools/include headers_install
??
Would the latter be "just the same" or am I missing something here?
--
http://linux
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
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
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 s
> 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
> 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
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 s
Le 02/03/2014 02:35, akhiezer a écrit :
>> Date: Sat, 01 Mar 2014 18:17:42 -0600
>> From: Bruce Dubbs
>> To: LFS Developers Mailinglist
>> Subject: Re: [lfs-dev] gcc pass 1/2 instructions re mpfr/gmp/mpc.
>>
>> akhiezer wrote:
Date: Sat, 01 Mar 2014 17:04:38 -0600
From: Bruce Dubbs
>>>
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
> be
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
36 matches
Mail list logo
