Bryan Kadzban wrote:
[snip]
Thanks for the clarifications, they were very helpful.
> Forcing the user to build the kernel before they start may work
I would think that doing this would provide optimal build results for
glibc. If you do it after the first pass of gcc, but before glibc, then
yo
DJ Lucas wrote:
> DJ Lucas wrote:
>
>> DJ Lucas wrote:
>>
>>
>>> This is long, but mostly just test output. This tested on a box from
>>> 20081012 with the added coreutils-i18n patch. Apparently, grep still
>>> has an issue.
>>>
>>>
>>>
>> A couple of quick builds co
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeremy Huntwork wrote:
> Bryan Kadzban wrote:
>> Ken Moffat wrote:
>>> but also I think we should encourage
>>> people to build a new kernel first (if they aren't using a Live CD)
>>> so that they can be sure it works with their .config, and the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> Bryan Kadzban пишет:
>> It *looks* like vimtutor -- or at least the way LFS installs it now
>> -- has simply gotten better. If that's correct: Yay! ;-)
>
> Yes, that's correct, and that's old news. Exactly because
DJ Lucas wrote:
> DJ Lucas wrote:
>
>> This is long, but mostly just test output. This tested on a box from
>> 20081012 with the added coreutils-i18n patch. Apparently, grep still
>> has an issue.
>>
>>
> A couple of quick builds confirms that it is the current Debian patch
> that
Jeremy Huntwork wrote:
> Perhaps I'm not understanding your point. Certainly
> --enable-kernel=current would cover that very circumstance?
--enable-kernel=current breaks downgrades that are inevitable after any
RedHat release, and introduces a new variable into the build. That's why
I am agains
Bryan Kadzban wrote:
> Ken Moffat wrote:
>> To me, 2.6.9 is ancient history! (4 years old). I think something
>> like 2.6.16 (purely because it is still getting long-term support
>> updates) is a better minimum, but also I think we should encourage
>> people to build a new kernel first (if they
Bryan Kadzban пишет:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
> DJ Lucas wrote:
>> ## Test 4
>> [EMAIL PROTECTED] TESTS]$ export LANG=ru_RU.UTF-8
>> [EMAIL PROTECTED] TESTS]$ vimtutor
>> ===
>> =Д о б р
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Ken Moffat wrote:
> To me, 2.6.9 is ancient history! (4 years old). I think something
> like 2.6.16 (purely because it is still getting long-term support
> updates) is a better minimum, but also I think we should encourage
> people to build a
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
DJ Lucas wrote:
> ## Test 4
> [EMAIL PROTECTED] TESTS]$ export LANG=ru_RU.UTF-8
> [EMAIL PROTECTED] TESTS]$ vimtutor
> ===
> =Д о б р о п о ж а л о в а т ь в у ч
William Immendorf wrote:
> As for the i18n patch, I am going to say, 'No way, Jose.'
Your distro, your rules.
As for the book, your opinion will be ignored until you start to contribute
something useful.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linux
DJ Lucas wrote:
> This is long, but mostly just test output. This tested on a box from
> 20081012 with the added coreutils-i18n patch. Apparently, grep still
> has an issue.
>
A couple of quick builds confirms that it is the current Debian patch
that caused the regression.
-- DJ Lucas
DJ Lucas wrote:
>This is long, but mostly just test output. This tested on a box from
>20081012 with the added coreutils-i18n patch. Apparently, grep still
>has an issue. Need to see if we can dig up the proper patch or changes
>necessary to make it work correctly, and we still need to kill
DJ Lucas wrote:
> This is long, but mostly just test output. This tested on a box from
> 20081012 with the added coreutils-i18n patch. Apparently, grep still
> has an issue. Need to see if we can dig up the proper patch or changes
> necessary to make it work correctly, and we still need to ki
This is long, but mostly just test output. This tested on a box from
20081012 with the added coreutils-i18n patch. Apparently, grep still
has an issue. Need to see if we can dig up the proper patch or changes
necessary to make it work correctly, and we still need to kill
vi_VN.TCVN in GLibc.
Matthew Burgess wrote:
> On Sun, 19 Oct 2008 15:50:15 -0400, Jeremy Huntwork
> <[EMAIL PROTECTED]> wrote:
>> Bruce Dubbs wrote:
>>> http://wiki.linuxfromscratch.org/lfs/ticket/2115
>>>
>>> I am starting to address the subject ticket. I propose to follow Chris'
>>> suggestion and move the 'Toolch
On Monday 20 October 2008 04:55:26 pm Matthew Burgess wrote:
> On Sun, 19 Oct 2008 15:50:15 -0400, Jeremy Huntwork
<[EMAIL PROTECTED]> wrote:
> > Bruce Dubbs wrote:
> >> http://wiki.linuxfromscratch.org/lfs/ticket/2115
> >>
> >> I am starting to address the subject ticket. I propose to
> >> follo
On Sun, 19 Oct 2008 15:50:15 -0400, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Bruce Dubbs wrote:
>> http://wiki.linuxfromscratch.org/lfs/ticket/2115
>>
>> I am starting to address the subject ticket. I propose to follow Chris'
>> suggestion and move the 'Toolchain Technical Notes' section to th
On Mon, Oct 20, 2008 at 07:24:50PM +0200, Gilles Espinasse wrote:
> Selon Ken Moffat <[EMAIL PROTECTED]>:
> ...
>
> LFS dev has on glibc --enable-kernel=2.6.0
> FC9 has set --enable-kernel=2.6.9
> Debian lenny has set --enable-kernel=2.6.18
> Greg has the same 2.6.18 setting on glibc chroot compil
Selon Ken Moffat <[EMAIL PROTECTED]>:
...
>
> In an *ideal* world, I still think that building the kernel version
> used in LFS on the host is the way to go. Doesn't fit every usage,
> but it has to be a lot better than attempting to support people
> building from some antique version of 2.6.
LF
Ken Moffat wrote:
> On Mon, Oct 20, 2008 at 10:36:14AM -0400, Jeremy Huntwork wrote:
>> * "Gcc-3.0.1" can at _least_ become "Gcc-2.95" I don't know if you
>> want to mention "egcs-2.91.66" but it works.
>>
> Possibly, but if you have to build a linux-2.6 kernel on the old
> host, you won't be a
Bruce Dubbs wrote:
> That's interesting Jeremy, but as a minimum, I wouldn't want to make the
> changes
> for LFS 6.4. I don't think you are proposing that but I wanted to make it
> explicit.
Yes, I wasn't aiming for 6.4. As I said, these changes will be going
into the jh branch. The only thi
On Mon, Oct 20, 2008 at 10:36:14AM -0400, Jeremy Huntwork wrote:
>
> * "Gcc-3.0.1" can at _least_ become "Gcc-2.95" I don't know if you
> want to mention "egcs-2.91.66" but it works.
>
Possibly, but if you have to build a linux-2.6 kernel on the old
host, you won't be able to build a recent v
Jeremy Huntwork wrote:
> So after some testing on a Redhat 6.2 system, I can say definitely that
> our host pre-reqs are higher than they technically need to be. I'd like
> to eventually drop all the below changes into the jh branch, but I just
> wanted to give a little status report first, for
On Sun, Oct 19, 2008 at 4:38 PM, Nathan Coulson <[EMAIL PROTECTED]> wrote:
>
> oh, btw pre Xorg 7.4, there was the dri2 stuff. That was removed
> before releasing Xorg 7.4. Mesa 3d 7.1 used dri2, while Mesa 7.2 had
> that removed.
The dri2 stuff was dependent on the TTM memory manager, which is
On Sat, Oct 18, 2008 at 12:03 PM, DJ Lucas <[EMAIL PROTECTED]> wrote:
>
> xf86-video-intel is probably a big problem. It fails specifically
> because of changes in libdrm. Hopefully 2.4.3 is out soon. I haven't
> investigated the others because I do not even know what they are.
Ah, you're tread
Hello,
So after some testing on a Redhat 6.2 system, I can say definitely that
our host pre-reqs are higher than they technically need to be. I'd like
to eventually drop all the below changes into the jh branch, but I just
wanted to give a little status report first, for those interested.
Firs
Greg Schafer wrote:
> Jeremy Huntwork wrote:
>
>> I think this is the right answer. Greg, if you're reading, do you have
>> any comments to make on this topic?
>
> None at all, sorry. Next Gen build method utilizes cross compilation for
> the initial Pass 1 toolchain which avoids fixincludes pro
DJ Lucas wrote:
> Jeremy Huntwork wrote:
>> The command I propose is:
>>
>> GCC_FIXED=`dirname $(gcc -print-libgcc-file-name)`/include-fixed &&
>> find ${GCC_FIXED}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; &&
>> rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_FIXED}/*` &&
>> unset GCC_FIXED
> So
>> Also, I think we talked about adding loop-aes to hlfs a long time ago,
>> and it was voted against because its a physical security thing... but
>> with swap it's not. If someone has read access to the swap device
>> (someone in the 'disc' group), they could find sensitive information.
>> GnuPG
Jeremy Huntwork wrote:
> I think this is the right answer. Greg, if you're reading, do you have
> any comments to make on this topic?
None at all, sorry. Next Gen build method utilizes cross compilation for
the initial Pass 1 toolchain which avoids fixincludes problems altogether.
But I suspect
31 matches
Mail list logo
