Alexander E. Patrakov wrote:
DJ Lucas wrote:
A quick summary of changes: The ghost PIDs (and false already running
messages) have been fixed; boot_mesg() has been greatly simplified
without the text wraping; and logging was moved out of the standard
scripts. There will still need more chang
Archaic wrote:
On Fri, Dec 23, 2005 at 08:14:18AM +0500, Alexander E. Patrakov wrote:
It is not broken. Outdated but not broken.
Not to beat a dead horse, because this isn't the focus of the thread,
but having to unplug and replug in a USB device that is on at bootup
sounds broken to
DJ Lucas wrote:
A quick summary of changes: The ghost PIDs (and false already running
messages) have been fixed; boot_mesg() has been greatly simplified
without the text wraping; and logging was moved out of the standard
scripts. There will still need more changes when 2.6.15 and no
hotplug
On Fri, Dec 23, 2005 at 08:14:18AM +0500, Alexander E. Patrakov wrote:
> >
> It is not broken. Outdated but not broken.
Not to beat a dead horse, because this isn't the focus of the thread,
but having to unplug and replug in a USB device that is on at bootup
sounds broken to me. Apparently the eve
Archaic wrote:
On Thu, Dec 22, 2005 at 12:23:06PM -0700, Jeremy Herbison wrote:
Now won't udev require headers for the new functionality? Seems the
linux-libc-headers project is defunct at this point (he promised a 2.6.14
release by 3 weeks ago, and now he's just MIA).
If a CVS pull m
Archaic wrote:
On Thu, Dec 22, 2005 at 11:21:41AM -0800, Jim Gifford wrote:
Previously we have said no release versions of the kernel. I think we
should stick with that policy.
I'm assuming you meant pre-release versions. Generally I agree with that
policy. However, my rationale for t
Archaic wrote:
DJ, what is the current status of the bootscripts? I recall you changing
something WRT the removing the PID of the script, but is there anything
else in the works? If not, perhaps a pre-release could be generated so
it receives more wide-spread testing.
AFAIK, there are no outst
On Fri, 23 Dec 2005, Greg Schafer wrote:
Ken Moffat wrote:
'su' from /tools. Neither CLFS nor LFS suppress this in the first
build of coreutils.
WARNING: insufficient access; not installing su
NOTE: to install su, run 'make install-root' as root
Sorry, you are right and I was wrong - so
Ken Moffat wrote:
> 'su' from /tools. Neither CLFS nor LFS suppress this in the first
> build of coreutils.
WARNING: insufficient access; not installing su
NOTE: to install su, run 'make install-root' as root
The temporary tools are (meant to be) built as non-root.
Regards
Greg
--
http:/
On Fri, 23 Dec 2005, Greg Schafer wrote:
On Wed, 21 Dec 2005 11:34:22 -0800, Jim Gifford wrote:
I posted a solution in lfs-support. Here is it
In my testing with Cross-LFS, I have found that this works
echo "dummy1:x:1000:" >> /etc/group
echo "dummy:x:1000:1000:::/bin/bash" >> /etc/passwd
cd
On Wed, 21 Dec 2005 11:34:22 -0800, Jim Gifford wrote:
> I posted a solution in lfs-support. Here is it
>
> In my testing with Cross-LFS, I have found that this works
>
> echo "dummy1:x:1000:" >> /etc/group
> echo "dummy:x:1000:1000:::/bin/bash" >> /etc/passwd
> cd tests
> su dummy -c "sh run-al
Jeremy Herbison wrote:
> Now won't udev require headers for the new functionality?
What new functionality? Possibly the new netlink socket stuff?
udev-071 compiled just fine against l-l-h version 2.6.11.2 when I moved
to it from -056 a few months back. Now, that's not the most recent
version of
On Thu, Dec 22, 2005 at 12:47:44PM -0700, Jeremy Herbison wrote:
>
> I just meant that linux-libc-headers is stuck at some sort of 2.6.14 pre-
> release, and that someone will have to add the new 2.6.15 udev headers
> manually. Don't bite!
I didn't. :) Just pointing out that for the purpose of fi
> On Thu, Dec 22, 2005 at 12:23:06PM -0700, Jeremy Herbison wrote:
> >
> > Now won't udev require headers for the new functionality? Seems the
> > linux-libc-headers project is defunct at this point (he promised a
> 2.6.14
> > release by 3 weeks ago, and now he's just MIA).
>
> If a CVS pull must
Archaic wrote:
> On Thu, Dec 22, 2005 at 12:23:06PM -0700, Jeremy Herbison wrote:
>
>>Now won't udev require headers for the new functionality? Seems the
>>linux-libc-headers project is defunct at this point (he promised a 2.6.14
>>release by 3 weeks ago, and now he's just MIA).
>
>
> If a CVS p
Archaic wrote:
1) Hotplug/coldplug is currently broken in LFS.
2) There have been 6 release candidates so far.
3) Numerous security vulnerabilities in 2.6.12
If all we were doing was updating a kernel just because it was the
latest, I'd say no. If all we were doing was updating a kernel to add
s
The only difference between the 2.6.14 and 2.6.12 headers in linux libc
headers is they removed sound.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
On Thu, Dec 22, 2005 at 12:23:06PM -0700, Jeremy Herbison wrote:
>
> Now won't udev require headers for the new functionality? Seems the
> linux-libc-headers project is defunct at this point (he promised a 2.6.14
> release by 3 weeks ago, and now he's just MIA).
If a CVS pull must be done, so be
On Thu, Dec 22, 2005 at 11:21:41AM -0800, Jim Gifford wrote:
> Previously we have said no release versions of the kernel. I think we
> should stick with that policy.
I'm assuming you meant pre-release versions. Generally I agree with that
policy. However, my rationale for this proposal is as foll
> ISTM that since trunk is a dev branch, we should be able to get away
> with a pre-release piece of software that is just around the corner of
> being released. With that in mind, should we going ahead and add
> 2.6.15-rc6 to the book and start fixing the hotplug/udev problems now so
> it at least
Previously we have said no release versions of the kernel. I think we
should stick with that policy.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Un
On 12/22/05, Archaic <[EMAIL PROTECTED]> wrote:
> ISTM that since trunk is a dev branch, we should be able to get away
> with a pre-release piece of software that is just around the corner of
> being released. With that in mind, should we going ahead and add
> 2.6.15-rc6 to the book and start fixin
Archaic wrote:
> On Thu, Dec 22, 2005 at 01:07:45PM -0600, Bruce Dubbs wrote:
>
>>That seems like a reasonable proposal to me, but if you are asking for
>>Matt's go-ahead, I believe he is away for the next week.
>
>
> Yes, I'm aware of his absence. I was asking for community response.
> There ar
On Thu, Dec 22, 2005 at 01:07:45PM -0600, Bruce Dubbs wrote:
>
> That seems like a reasonable proposal to me, but if you are asking for
> Matt's go-ahead, I believe he is away for the next week.
Yes, I'm aware of his absence. I was asking for community response.
There are a few of us who can do t
Archaic wrote:
> ISTM that since trunk is a dev branch, we should be able to get away
> with a pre-release piece of software that is just around the corner of
> being released. With that in mind, should we going ahead and add
> 2.6.15-rc6 to the book and start fixing the hotplug/udev problems now s
DJ, what is the current status of the bootscripts? I recall you changing
something WRT the removing the PID of the script, but is there anything
else in the works? If not, perhaps a pre-release could be generated so
it receives more wide-spread testing.
--
Archaic
Want control, education, and se
ISTM that since trunk is a dev branch, we should be able to get away
with a pre-release piece of software that is just around the corner of
being released. With that in mind, should we going ahead and add
2.6.15-rc6 to the book and start fixing the hotplug/udev problems now so
it at least has a cha
On 12/22/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> 3) Leave --enable-svg commented as it adds a bit of overhead (to
> support something that really isn't even in widespread use yet). If
> someone wants to build with it, they simply need to remove the comment
> pound sign.
>
> 4) Keep --enable
Randy McMurchy wrote:
5) Comment out the MOZILLA_FIVE_HOME line out, and write some text
saying it doesn't need to be enabled for end user browsing and is
used for development purposes only.
Thanks Randy,
If it causes any problems at all, you know who to blame! ;)
Andy
--
http://linuxfromscra
I shall be shutting down my systems tonight for the Christmas
Holiday, back on Wednesday. SWMBO and I have to deliver Seasonal
Cheer to various parts of the UK over the next few days.
It has been an interesting year, moved house, became a BLFS Editor,
started renovating said house, gave up editing
On Thu, Dec 22, 2005 at 12:47:46PM +0100, Nico R. wrote:
>
> What say the others?
I say if using switches versus moving groff both result in identical
binaries, then switches are probably easier and better in that the
explanation of the switch is the perfect forum to mention that perl is
looking
On 12/22/05, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
> Nico R. wrote:
>
> > I haven't actually built a system from the alphabetical branch, but in
> > situations like this one, I usually prefer using some configure
> > switches. But that may be due to the fact that I like to have more
> >
Nico R. wrote:
I haven't actually built a system from the alphabetical branch, but in
situations like this one, I usually prefer using some configure
switches. But that may be due to the fact that I like to have more
control and dislike badly written configure scripts which have broken
tests, pr
Dan Nicholson wrote:
Who hates the perl build system? I do, I do.
Me too. %-|
I can't tell you how long it took
to figure this out since it appears the perl build system was written
by a high school student.
??? ;-)
Now, we could just add some mandir= type statements to configure.gnu,
bu
34 matches
Mail list logo
