On 5/30/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
It appears that all leaks reported up to now are unfixable from udev side (they
are due to drivers probing their hardware in a separate thread), so let's just
ignore bugreports and remove the "bug" rule, the /lib/udev/bug program and t
Warren Wilder wrote:
I've got a /dev/bugreport for you.
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/pci:00/:00:0d.0/fw-host0/00406354efd3
SUBSYSTEM=ieee1394
SEQNUM=469
PHYSDEVBUS=ieee1394
UDEVD_EVENT=1
_SEPARATOR=---
UDEV_LOG=3
ACTION=add
DEVPATH=/class/ieee13
On 5/30/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote these words on 05/30/06 11:20 CST:> Nathan is becoming more active again.And I'm supposed to believe this because you say so, when I haven'tseen Nathan around in ages? :-)
Started getting active again since last week. I have
Sorry to all for the previous email, it was sent to the wrong list.
--
Giulio
-
Linux user #356310
LFS user #11031
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Ho il piacere di informare tutti gli appassionati e non di LFS che ho
ristrutturato la pagina degli hint tradotti in italiano nella sezione
LFS. Ora gli hint potranno essere sia scaricati in un unico file
tar.gz, come sempre, che scaricati o consultati singolarmente. Per chi
li guardasse per la pr
1. The hard links to automake and aclocal are not [program]-1.9.6, but
[program]-1.9. Maybe there should be a "version2" entity for automake to
handle this?
2. Perl does not install any en2cxs program.
3. Glibc 2.4 does not have nscd_nischeck. I know that LFS does not use
Glibc 2.4 yet, but I
Gerard Beekmans wrote:
Matthew Burgess wrote:
I think it can just be pulled, unless someone
with a proper understanding of what it's trying to get at can shed
some light?
This sentence doesn't apply anymore. Go ahead and remove it.
Thanks Gerard. Done in r7638. Oh, and thanks for the ori
On 5/30/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
There are 2 other projects out there for headers. The Headers project,
which has roots to xLFS and what T2 Project has done.
Fedora is now using David Woodhouse's cleaned up kernel tree with the
results of `make headers_install'. The rawhide
Sorry for the cross-post, but shadow is installed in all the projects
(I'm not subscribed to hlfs). New version coming. One important
point is that the templates (/etc/default/useradd, login.def, limits
and login.access without PAM, /etc/pam.d/* with PAM) will be
installed. So all book instruct
Andrew Benton wrote:
So what you're saying is that the current LFS editors are incompetent so
lets get new people in?
Andy, you're missing the point of the proposal. It's not about any
technical issue, or whether the rules are correct for any project, but
it's organizational only and its purp
On 5/30/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
Dan,
I consider that a part of the headers project, Jürg and I worked a
lot of the logic out together, the only difference is that Jürg only
concentrated on the x86 platforms.
Gotcha. Well, to be honest, the scripts are very different. Bu
Gerard Beekmans wrote:
Hi guys,
The idea of setting up a new group that will take on the task of
handling matters like the udev discussion that is currently going on
strong. This idea had some support on this list, and some resistance,
and the discussion dropped off without much happening on
Dan,
I consider that a part of the headers project, Jürg and I worked a
lot of the logic out together, the only difference is that Jürg only
concentrated on the x86 platforms.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See t
Thanx Matt. Talked to a lot of people today about this from my headers
project. As long as there is no way to use the kernel headers, this
project is going to exist. Plus, we had a call to sanitize the 2.4
headers to get rid of the __KERNEL__ stuff from them.
If the make install_headers patch
On 5/30/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
There are 2 other projects out there for headers. The Headers project,
which has roots to xLFS and what T2 Project has done.
Jürg Billeter's linux-glibc-headers script for paldo.
http://www.paldo.org/index.php?section=packages&page=main&relea
Matthew Burgess wrote:
back to r3228 (2004)). I think it can just be pulled, unless someone
with a proper understanding of what it's trying to get at can shed some
light?
That's an ancient left over. There was a time many years ago (well
before 2004) where pwconv didn't always do a good job
Jim Gifford wrote:
> Mark Rosenstand wrote:
>
>> I believe the Red Hat kernel maintainer submitted a patch adding another
>> make target for the kernel which would produce such headers. AFAIR it's
>> scheduled for inclusion in 2.6.18.
>>
> With the last email I saw, Linus said he was going to reje
Chris Staub wrote:
There shouldn't be any need to "reset" passwords since pwconv and pwunconv
take whatever password is stored in /etc/{passwd,shadow} and convert it.
Or am I not understanding what that means?
I must confess, I don't actually understand what it means either.
However, trac sho
Randy,
I'm looking at this a totally different angle. Right now there is no
cooperation from projects, I think you can agree with this. To me this
one of many steps to help tie the projects together and be united.
My vision is that there will be no more developer walls, people only
work
Mark Rosenstand wrote:
I believe the Red Hat kernel maintainer submitted a patch adding another
make target for the kernel which would produce such headers. AFAIR it's
scheduled for inclusion in 2.6.18.
With the last email I saw, Linus said he was going to reject this
proposal, has something
In the configuration section - "However, if returning to this section
later to enable shadowing, reset any current user passwords with the
passwd command or any group passwords with the gpasswd command." There
shouldn't be any need to "reset" passwords since pwconv and pwunconv
take whatever pa
On Tue, 2006-05-30 at 09:42 -0600, Gerard Beekmans wrote:
> Soon we'll have to figure out how we want to move forward with
> linux-libc-headers. Do we start our own, or do we wait for other
> projects to take this on.
I believe the Red Hat kernel maintainer submitted a patch adding another
make
Tushar Teredesai wrote:
On 5/30/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
How does LFS update their finished, released, perhaps in print, book
to reflect that a new tarball is needed?
One solution is to have all projects go into a release freeze at the
same time (perhaps after branching) a
Having everything in one repo but releasing the base scripts and the
blfs scripts in 2 separate tarballs sounds good to me.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Tushar Teredesai wrote:
On 5/30/06, Gerard Beekmans <[EMAIL PROTECTED]> wrote:
I believe the idea is actually a good one. If you look at the bigger
picture, such a unbiased group can take on other tasks too down the
road.
In short, the current hierachy with you and Matt at the top to
arbirt
On 5/30/06, Gerard Beekmans <[EMAIL PROTECTED]> wrote:
I believe the idea is actually a good one. If you look at the bigger
picture, such a unbiased group can take on other tasks too down the
road.
In short, the current hierachy with you and Matt at the top to
arbirtrate is insufficient becaus
On 5/30/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
How does LFS update their finished, released, perhaps in print, book
to reflect that a new tarball is needed?
One solution is to have all projects go into a release freeze at the
same time (perhaps after branching) and then all projects make
Randy McMurchy wrote:
What text will be in the LFS book. "Here is the current LFS tarball
to install after you complete LFS. It also has BLFS bootscripts in
it, but they probably aren't current, so you'll need to get a
different tarball for BLFS." :-(
Maybe I wasn't clear on the combining of t
Chris Staub wrote:
The description for the kbd package includes information about several
programs that kbd does not install by default.
Thanks Chris, committed in r7637.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the abov
Chris Staub wrote:
> Randy McMurchy wrote:
>> Jim Gifford wrote these words on 05/30/06 11:56 CST:
>>
>> I know I said no more replies. But this is important. Jim, you just
>> made my point for me. If these "consolidated" bootscripts need to be
>> updated, what is the point in consolidating them?
>
Randy McMurchy wrote:
What text will be in the LFS book. "Here is the current LFS tarball
to install after you complete LFS. It also has BLFS bootscripts in
it, but they probably aren't current, so you'll need to get a
different tarball for BLFS." :-(
But in reality, how often are issues with
Chris Staub wrote:
The swapdev program hasn't been in util-linux for years.
Thanks Chris, committed in r7636.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Randy McMurchy wrote:
Jim Gifford wrote these words on 05/30/06 11:56 CST:
I know I said no more replies. But this is important. Jim, you just
made my point for me. If these "consolidated" bootscripts need to be
updated, what is the point in consolidating them?
What text will be in the LFS book
Chris Staub wrote:
Takes into account the dependency info being moved. Also, I don't see
why it currently says "If using the compiler optimizations provided in
this chapter"...there are no optimizations provided there.
Thanks Chris, applied in r7635.
--
http://linuxfromscratch.org/mailman/lis
Jim Gifford wrote these words on 05/30/06 11:56 CST:
> This could be Release 1.2.3.1, nothing says that CLFS, LFS, and BLFS
> will be using the same releases, but all the same series would be able
> to operate with each other.
I know I said no more replies. But this is important. Jim, you just
Randy McMurchy wrote:
LFS releases a book, perhaps in print, that says this is the bootscript
tarball for this release. Let's call it bootscripts-1.2.3. This has
LFS and BLFS scripts in it.
Before BLFS releases their book to match the new LFS version, it is
discovered that some of the bootscrip
Bryan Kadzban wrote these words on 05/30/06 11:53 CST:
> if all the bootscript "leads" are unavailable for some
> reason.
You mean "the" bootscript lead, right? :-)
Anyway, I'm not going to clutter the list with any more replies on
my end. I've spoken my concerns.
I'll wait until Bruce gets bac
Randy McMurchy wrote:
Hi all,
Changing the thread so that the one topic, BLFS bootscripts, can be
addressed independently from the other, good, ideas (in fact combining
Udev rules may be bad as well).
Scenario:
LFS releases a book, perhaps in print, that says this is the bootscript
tarball for
Jim Gifford wrote:
It's called coordination, when your getting ready to add a new daemon to
the book contact the team.
I personally think there should be at least one member of each of the
book's editorial staff (whoops...volunteers!) who has commit privileges
to the new repository. That wa
Jim Gifford wrote these words on 05/30/06 11:49 CST:
> Isn't DJ a part of BLFS, you can't coordinate with your own team mate?
Don't be ridiculous, Jim. My concern is when DJ is in the hospital, or
on vacation, or moves and is without Internet connectivity, or ...
I think you see my point.
-
On Tue, May 30, 2006 at 12:47:33PM -0400, Bryan Kadzban wrote:
> On Tue, May 30, 2006 at 09:42:50AM -0600, Gerard Beekmans wrote:
> > Comments are welcome.
>
> I'm in favor. Actually, assuming it gets another mailing list, I'll
> subscribe -- although now is probably too early to be deciding whet
Hey Randy,
Isn't DJ a part of BLFS, you can't coordinate with your own team mate?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Hi all,
Changing the thread so that the one topic, BLFS bootscripts, can be
addressed independently from the other, good, ideas (in fact combining
Udev rules may be bad as well).
Scenario:
LFS releases a book, perhaps in print, that says this is the bootscript
tarball for this release. Let's cal
On Tue, May 30, 2006 at 09:42:50AM -0600, Gerard Beekmans wrote:
> Comments are welcome.
I'm in favor. Actually, assuming it gets another mailing list, I'll
subscribe -- although now is probably too early to be deciding whether
it needs a separate list or not.
pgpZiNN3E7XlS.pgp
Description: PG
I agree with the ideas in this proposal.
The one idea that I'm going back and forth on is whether the
blfs-bootscripts should become part of the base scripts.
>From one side, you'd only need one tarball. How often do the bootscripts
get changed? It would possibly be easier to maintain.
>From the
The description for the kbd package includes information about several
programs that kbd does not install by default.
Index: trunk/BOOK/chapter06/kbd.xml
===
--- trunk/BOOK/chapter06/kbd.xml (revision 7634)
+++ trunk/BOOK/chapter06/kb
Jim Gifford wrote these words on 05/30/06 11:20 CST:
> Nathan is becoming more active again.
And I'm supposed to believe this because you say so, when I haven't
seen Nathan around in ages? :-)
> It's called coordination, when your getting ready to add a new daemon to
> the book contact the te
Jim Gifford wrote:
Randy McMurchy wrote:
For instance, today I'll be adding a new package that has a bootscript.
If DJ is on vacation or whatever, the package will not work. What
good does this serve the community.
BLFS bootscripts are different than the other groups (as explained).
It's ca
Randy McMurchy wrote:
Nathan doesn't come around anymore. That leaves DJ to do the updates,
if he's not around, the package become disfunctional. I cannot see one
good reason to not have BLFS be able to update their own bootscripts.
Nathan is becoming more active again.
For instance, today I
Gerard Beekmans wrote these words on 05/30/06 10:42 CST:
> The bootscripts were brought up as well as something this new group
> could take on. The udev problem we're trying to fix is different than
> the bootscript problem so people might have some issues with putting
> both tasks in the same
I fully agree with this proposal.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Gerard Beekmans wrote:
I truly don't think anything I have said in this email is news. It's
been suggested before by a few people. The ideas got lost or
misunderstood. After talking to Jim and Matt we're all on the same page
now and the idea of letting a group of people who are more specialized
Hi guys,
The idea of setting up a new group that will take on the task of
handling matters like the udev discussion that is currently going on
strong. This idea had some support on this list, and some resistance,
and the discussion dropped off without much happening on this front.
I believe
The swapdev program hasn't been in util-linux for years. From the
HISTORY file in the util-linux source tree...
util-linux 2.11c
* Czech messages (Ji Pavlovsk)
* German messages (Elrond)
* Makefile/MCONFIG improvements (Peter Breitenlohner)
...
* swapdev: deleted, it was last used with Linux 0.
Takes into account the dependency info being moved. Also, I don't see
why it currently says "If using the compiler optimizations provided in
this chapter"...there are no optimizations provided there.
Index: trunk/BOOK/chapter06/introduction.xml
55 matches
Mail list logo
