Gordon Schumacher wrote:
> I think I have an even better idea: rather than putting *any* package
> management commands in, what about something like this:
>
> If you would like to generate binary packages, you will need to
> define a function that will be used to generate those packages. Run a
> c
Matthew Burgess wrote:
> Tell you what, Bryan. On Saturday, I'll commit the Udev upgrade by
> itself. Then you/we can work on getting rid of the duplicate rules.
> Then, at our leisure we can figure out what other rules we can nuke.
I like this idea. :-P
I think the "getting rid of the dupli
On Thu, 04 Dec 2008 08:32:00 -0800, Bryan Kadzban <[EMAIL PROTECTED]> wrote:
> Jeremy Huntwork wrote:
>> 4. Ticket 2284, upgrade of Udev, and strip out udev-config. I doubt
>> this needs its own branch. What sort of time/work is involved here?
>
> Not a ton of work; with a few hours of time, I can
Jeremy Huntwork wrote:
> 4. Ticket 2284, upgrade of Udev, and strip out udev-config. I doubt
> this needs its own branch. What sort of time/work is involved here?
Not a ton of work; with a few hours of time, I can probably get this up
and running. (I'd just have to compile a newer kernel, install
Jeremy Huntwork wrote:
> Greg, as I have your attention, I'm curious why the -fomit-frame-pointer
> change is still present in your second pass of gcc. I thought the
> purpose of this was to maintain compatibility between the first
> bootstrapped pass of gcc and the second pass?
GCC is no long
Greg Schafer wrote:
> Jeremy Huntwork wrote:
>
>> 1. Move to DIY's new build method in trunk. If we ignore multilib and
>> any extra arch support for this step, the changes required aren't
>> actually that many, and they all take place pretty early in chapter 5.
>
> I realize you say "this ste
Jeremy Huntwork wrote:
> 1. Move to DIY's new build method in trunk. If we ignore multilib and
> any extra arch support for this step, the changes required aren't
> actually that many, and they all take place pretty early in chapter 5.
I realize you say "this step", but LFS is already too far
Gordon Schumacher wrote:
> Bruce Dubbs wrote:
>
>> Bryan Kadzban wrote:
>>
Ticket 2033 -- initramfs. This way people with crappy software "RAID1
cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows,
can still boot from those cards. Also, support for MD RAID (*
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> > Ticket 2033 -- initramfs. This way people with crappy software "RAID1
>> > cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows,
>> > can still boot from those cards. Also, support for MD RAID (*real*
>> > software RAID ;-) ),
Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>> 1. Move to DIY's new build method in trunk. If we ignore multilib and
>> any extra arch support for this step, the changes required aren't
>> actually that many, and they all take place pretty early in chapter 5.
>> We can have trunk using the new b
Jeremy Huntwork wrote:
> * DESTDIR style PM support? (To me, this is the easiest way of offering
> a default pseudo-style PM support. We don't actually tell the users how
> to package up the binaries, track dependencies or track what is
> installed, but we do show whatever DESTDIR-compatible com
Jeremy Huntwork wrote:
> Ok, so we have a fair amount of items we'd like to push into 7.0, some
> of which, work has already begun.
>
> As far as step-by-step plan of attack goes, how does this sound?
>
> 1. Move to DIY's new build method in trunk. If we ignore multilib and
> any extra arch sup
Selon Jeremy Huntwork <[EMAIL PROTECTED]>:
>
> 5. Ticket 2033. Include support for initramfs. Would this require a
> separate branch, and can it be worked on in parallel to other changes,
> or is it better to wait until other above changes are sorted out?
>
We have initramfs working on IPCop (with
64-bit would be pre for me. Every recent pc is capable of it and as
RAM exceeds 4GB or more, people want 64-bit to make full use of it.
That you can complile 64-bit code on 32-bit software, that has already
been made possible by CLFS, but that brings the problem that if the
host is 32-bit, you have
Matthew Burgess wrote:
> I've already got the trivial patch that upgrades Udev, but doesn't strip out
> Udev-config. It's been build-tested but not boot-tested currently. It may
> have an impact on the minimum host-kernel pre-req, but I don't have anything
> to test on to confirm/deny this. M
On Wed, 03 Dec 2008 07:22:48 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> 4. Ticket 2284, upgrade of Udev, and strip out udev-config. I doubt this
> needs its own branch. What sort of time/work is involved here?
I've already got the trivial patch that upgrades Udev, but doesn't strip out
Ok, so we have a fair amount of items we'd like to push into 7.0, some
of which, work has already begun.
As far as step-by-step plan of attack goes, how does this sound?
1. Move to DIY's new build method in trunk. If we ignore multilib and
any extra arch support for this step, the changes requi
Jeremy Huntwork wrote:
> What do you think is likely to happen in future versions and/or what is
> your plan?
GCC is not going to revert back, clearly.
> Just continue to maintain the backport patch for future versions?
Pretty much. It's similar in principle to the current specs handling ie:
ch
Bruce Dubbs wrote:
> Even it it's poor hardware support, does the frequency of occurrence rise to
> the
> level of needing to be in the LFS book? As several comments in the ticket
> suggest, initramfs would be more appropriate for BLFS, but I'm thinking that
> even that is too much and an upda
Greg Schafer wrote:
> Greg Schafer wrote:
>
>> In a (native) sysroot scenario, anything and _everything_ can be found
>> on the host.
>
> Here's a Binutils thread about a sysrooted ld which touches upon what I'm
> talking about:
>
> http://sourceware.org/ml/binutils/2008-08/msg00060.html
Intere
DJ Lucas wrote:
> Jeremy Huntwork wrote:
>> Jeremy Huntwork wrote:
>>
>>> Anything else?
>>>
>> Oh, I also forgot. We could give some thought to using DIY's new build
>> method
> Some? I thought this was a no brainer. During the big push for 6.3,
> Greg handed us many, many tips, and sh
On Tue, Dec 2, 2008 at 9:10 AM, Matthew Burgess
<[EMAIL PROTECTED]> wrote:
> On Tue, 02 Dec 2008 05:07:25 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
>> Anything else?
>
> Ticket #2284 - radical plan would be to just drop udev-config completely,
> then any reported issues should be passed
Jeremy Huntwork wrote:
> Jeremy Huntwork wrote:
>
>> Anything else?
>>
>
> Oh, I also forgot. We could give some thought to using DIY's new build
> method
Some? I thought this was a no brainer. During the big push for 6.3,
Greg handed us many, many tips, and showed several examples of w
Matthew Burgess wrote:
> On Tue, 02 Dec 2008 05:07:25 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
>
>> Anything else?
>>
>
> Ticket #2284 - radical plan would be to just drop udev-config completely,
> then any reported issues should be passed upstream and fixed there. I really
>
Bryan Kadzban wrote:
> Jeremy Huntwork wrote:
>> Anything else?
>
> Ticket 2033 -- initramfs. This way people with crappy software "RAID1
> cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows,
> can still boot from those cards. Also, support for MD RAID (*real*
> software RAID
On Tue, 02 Dec 2008 05:07:25 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Anything else?
Ticket #2284 - radical plan would be to just drop udev-config completely, then
any reported issues should be passed upstream and fixed there. I really don't
see anything special about LFS that means
Jeremy Huntwork wrote:
> Anything else?
Ticket 2033 -- initramfs. This way people with crappy software "RAID1
cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows,
can still boot from those cards. Also, support for MD RAID (*real*
software RAID ;-) ), LVM, and encrypted rootfs
Greg Schafer wrote:
> In a (native) sysroot scenario, anything and _everything_ can be found
> on the host.
Here's a Binutils thread about a sysrooted ld which touches upon what I'm
talking about:
http://sourceware.org/ml/binutils/2008-08/msg00060.html
Regards
Greg
--
http://www.diy-linux.org/
Jeremy Huntwork wrote:
> Upstream appears to think that using sysroot is the correct approach
sysroot is a complete non-starter for us. Think about it. Have you ever
tried a sysroot build? In our current build methods, we go to *great*
lengths to prevent stuff from being found on the host. In a (
Jeremy Huntwork wrote:
> Anything else?
Oh, I also forgot. We could give some thought to using DIY's new build
method, which is essentially building the first pass of binutils and gcc
as cross compilers, cross-compiling the first build of Glibc and
building natively after that. There's several
I would prefer if it didn't take us another year (or more) to push out a
7.0 release. Or, even if it did, as long as the time is well spent.
I.E., we are actually pursuing the new features we slated and not just
letting package updates slowly creep in.
I know we have listed things before, but c
31 matches
Mail list logo
