This is my last post on this issue, like I've said I'm tired of all this
crap. This is my opinion. I know a lot of people feel the same way I do
about this, and would love to see the projects unified or at least some
type of join effort between them.
The bottom line is that LFS should of not c
On Tue, May 23, 2006 at 12:24:11AM -0700, Jim Gifford wrote:
>
> The bottom line is that LFS should of not created a new package. They
> should contacted CLFS team and worked together, which was the original
> plan way back when 2.6.15 was released.
This is apparently a misunderstanding. The p
On 5/23/06, Chris Staub <[EMAIL PROTECTED]> wrote:
Randy McMurchy wrote:
> Hi all,
>
> If anyone can confirm that Xorg-7.x and the new XFree also provides
> this library, then the dependency should be removed from MPlayer. If
> both Xorg versions install it, and XFree doesn't, then I'll change th
Dan Nicholson wrote these words on 05/23/06 10:36 CST:
> libXvMC to be specific. According to my dependencies, it's also used
> by the i810 video driver and Xine-Lib.
No, no, no. What I am speaking of is the *wrapper* library for the
library you mention above. They are different. It is libXvMCW.
On 5/23/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
Dan Nicholson wrote these words on 05/23/06 10:36 CST:
> libXvMC to be specific. According to my dependencies, it's also used
> by the i810 video driver and Xine-Lib.
No, no, no. What I am speaking of is the *wrapper* library for the
librar
Dan Nicholson wrote these words on 05/23/06 10:50 CST:
> Right. I forgot about that. It is installed by the package libXvMC,
> though.
Well I don't know anything about that. I've always installed it using
the libXvMCW package. You and I are not on the same page here. The
library you consistentl
On Tue, May 23, 2006 at 10:56:36AM -0500, Randy McMurchy wrote:
>
> Now it ships with Xorg. My question is does it ship with XFree.
One of the reasons for keeping Xfree was because it was nearly
maintenance free. The package itself may be, but obviously anything that
uses X components requires a
Archaic wrote these words on 05/23/06 11:00 CST:
> One of the reasons for keeping Xfree was because it was nearly
> maintenance free. The package itself may be, but obviously anything that
> uses X components requires a lot of hassle only because of Xfree. Does
> any editor here use Xfree?
"A lot
On Tue, May 23, 2006 at 11:03:49AM -0500, Randy McMurchy wrote:
>
> I surely don't see it that way.
Not that yes or no question, the fact that a lot of questions have had
to be asked to write up the deps of various packages to contend for the
differences.
--
Archaic
Want control, education, an
Archaic wrote:
On Tue, May 23, 2006 at 11:03:49AM -0500, Randy McMurchy wrote:
I surely don't see it that way.
Not that yes or no question, the fact that a lot of questions have had
to be asked to write up the deps of various packages to contend for the
differences.
It would certainly help
Archaic wrote these words on 05/23/06 11:19 CST:
> Not that yes or no question, the fact that a lot of questions have had
> to be asked to write up the deps of various packages to contend for the
> differences.
Though we probably shouldn't continue this banter as it isn't leading
to anything prod
Jim Gifford wrote:
This is my last post on this issue, like I've said I'm tired of all this
crap. This is my opinion. I know a lot of people feel the same way I do
about this, and would love to see the projects unified or at least some
type of join effort between them.
And as much as you say
Ismael Luceno wrote:
I noticed that in the chapter 6, glibc-2.3.6 will fail to compile,
because the gcc specs patch is preventing glibc from including the
kernel headers at /usr/include, adding the option --with-headers should
solve the problem.
Please take this to lfs-support. This list is fo
Ismael Luceno wrote:
tic complains about an undefined symbol (_nc_check_termtype2),
when installing ncurses.
Please take this to lfs-support as it's a support issue not a
development issue. When posting there though, please give the
information listed in the book
(http://www.linuxfromscratc
On 5/23/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
Anyway, if it means I have to install XFree into a dummy directory
just to get a log of the files installed, I'll spend the 25 minutes
and do it every time there is a new release (every couple of years)
if that's what it takes to keep it in t
Dan Nicholson wrote:
And as Randy said, Xorg-6.9 is in maintenance mode only now. So, that
would leave XFree as the monolithic build of choice as long as
development continues. In that case, it should stay in the book if
there's an editor to support it.
While that certainly helps, I'm not sur
El Martes, 23 de Mayo de 2006 19:24, Matthew Burgess escribió:
> And as much as you say you want a joint effort, you're unprepared to
> drop your package in favour of the one that LFS is using without any
> technical justification, merely saying "we had a tarball first".
IMHO, the best solution
M.Canales.es wrote:
IMHO, the best solution is to drop both and create a separate Udev-Rules
project managed by a neutral developer.
Heh, that's great - and I can't believe no one said it before now. And
Alexander is the perfect guy for the job, if he's willing. If you want
neutrality and a w
Jeremy Huntwork wrote:
Heh, that's great - and I can't believe no one said it before now. And
Alexander is the perfect guy for the job, if he's willing. If you want
neutrality and a working solution for all participants, this is the way
to go.
I was just in the middle of writing a (somewh
On Tue, May 23, 2006 at 02:21:24PM -0400, Chris Staub wrote:
>
> I was just in the middle of writing a (somewhat longer) response that
> basically said the same thing. Start the project with all the stuff
> common to the LFS and CLFS rules, and go from there.
If it will allow this thing to move
On 5/23/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
M.Canales.es wrote:
> IMHO, the best solution is to drop both and create a separate Udev-Rules
> project managed by a neutral developer.
Heh, that's great - and I can't believe no one said it before now. And
Alexander is the perfect guy for
Archaic wrote:
On Tue, May 23, 2006 at 02:21:24PM -0400, Chris Staub wrote:
I was just in the middle of writing a (somewhat longer) response that
basically said the same thing. Start the project with all the stuff
common to the LFS and CLFS rules, and go from there.
If it will allow this thi
Matthew Burgess wrote:
Even though I'm sure it'll differ very little (if at all) from what's
currently in LFS, sure, go ahead. Obviously we can't presume Alexander
will agree to maintain it, so if there are any other volunteers then I'm
all ears.
Well, if Alexander doesn't want the job, my s
The bottom line is if it's Alex or Dan, it needs it's own repo. With
branches for LFS and CLFS, so if we make some changes, then Alex or Dan
can merge the changes in.
On similar note I talked to DJ about this also, a separate repo for
bootscripts, with the same requirements will also need to b
Jim Gifford wrote:
The bottom line is if it's Alex or Dan, it needs it's own repo. With
branches for LFS and CLFS, so if we make some changes, then Alex or Dan
can merge the changes in.
On similar note I talked to DJ about this also, a separate repo for
bootscripts, with the same requirements
On 5/23/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote:
> The bottom line is if it's Alex or Dan, it needs it's own repo. With
> branches for LFS and CLFS, so if we make some changes, then Alex or Dan
> can merge the changes in.
>
> On similar note I talked to DJ about this also
Hi folks,
While I know DJ is hard at work doing the Xorg 7.1 update I thought I'd
share a script that I just wrote to automatically generate the wget
files for downloading all those packages. It's written in Python (the
only scripting language I know, other than shell scripting which would
h
Tushar Teredesai wrote:
It is not just about getting a list of installed files. Dependent
packages should also compile and run when XFree86 is used. If there
number of folks who will be prefer XFree86 over Xorg is minuscule,
there is no point in having XFree86 in the book and it is better of as
a
Andrew Benton wrote:
Seems to me that the only BLFS editor who has installed xfree86-4.6.0 is
the one who opened the bug to have it removed from the book...
http://wiki.linuxfromscratch.org/blfs/ticket/1966
You meant this one?
http://wiki.linuxfromscratch.org/blfs/ticket/1973
--
JH
--
http:/
Andrew Benton wrote:
Seems to me that the only BLFS editor who has installed xfree86-4.6.0 is
the one who opened the bug to have it removed from the book...
http://wiki.linuxfromscratch.org/blfs/ticket/1966
Doh! Wrong bug http://wiki.linuxfromscratch.org/blfs/ticket/1973
Andy
--
http://linux
To just make sure we all have a clear understanding.
1 - Repo will be created for Bootscripts and Udev rules
2 - Repo to be maintained by DJ, Alex, and Dan ( my choices). With the
Dev Teams from BLFS, CLFS, and LFS.
3 - Trunk to be maintained by DJ, Alex, and Dan.
CLFS Branch to be maintai
Jim Gifford wrote these words on 05/23/06 15:41 CST:
> Is this acceptable to all.
No. One person should not have final say on anything except an overall
project leader. For example, the entire BLFS Editing staff should have
write privileges to whatever repo will be used to create the
'production'
El Martes, 23 de Mayo de 2006 22:41, Jim Gifford escribió:
> Is this acceptable to all.
Seem fine to me.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:
Randy,
We would have our own branches, and DJ, Alex, and Dan would control
the releases and what is in trunk. If a release is needed, the dev teams
would contact them with the reason for the release and they would take
care of it.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FA
Jim Gifford wrote these words on 05/23/06 15:51 CST:
> Randy,
> We would have our own branches, and DJ, Alex, and Dan would control
> the releases and what is in trunk. If a release is needed, the dev teams
> would contact them with the reason for the release and they would take
> care of it
Randy,
What everyone wants is a unified package, where all the scripts for
BLFS, CLFS, and LFS are in one package. We will need to become dependent
on the this team that will be handling this package. We can have them
release a nightly tarball if we need to, but these are the details that
a
Jim Gifford wrote:
Randy,
What everyone wants is a unified package, where all the scripts for
BLFS, CLFS, and LFS are in one package.
Everyone? IIRC Jeremy made the suggestion, Dan agreed, now *everyone*
wants to move from a process that is well understood and appears to work
without pro
Jim Gifford wrote these words on 05/23/06 16:07 CST:
What everyone wants is a unified package, where all the scripts for
BLFS, CLFS, and LFS are in one package. We will need to become dependent
on the this team that will be handling this package. We can have them
release a nightly tarball i
Archaic wrote:
On Sun, May 21, 2006 at 03:27:01PM +0100, Matthew Burgess wrote:
Anyone having issues with any of the above feel free to point fingers
and laugh in my general direction, oh and anything more constructive
would be appreciated too :-)
There are still bugs that need to be dealt
Jim Gifford wrote:
Development of the rules will need to submitted into a common svn, that
will need to be created.
I'm going to do a complete about-turn on my earlier message from
tonight. The way I see it is that the current svn layout and procedures
around them should work just fine:
L
Jim Gifford wrote:
Is this acceptable to all.
The bootscripts package and udev rules seem to me to be two separate
issues here, and at least until there's shown to be some benefit of
merging those two together, I'd prefer to keep them separate. So far,
most seem agreeable to making the udev
Jeremy Huntwork wrote:
we still need to hear Alexander's comments on it, so let's give him the
time he needs. (I think he's sleeping, atm.)
He is gone for another week at least, an exam and other things until
20060602:
http://archives.linuxfromscratch.org/mail-archives/livecd/2006-May/003576
Matthew Burgess wrote:
So, what are the drawbacks to this approach? Why won't it work?
My comments below are concerning udev *only*. As I've said, to me, the
bootscripts are a separate issue.
What you suggested is the approach that LFS has assumed up to now and
CLFS has rejected. If I'm vi
Justin R. Knierim wrote:
Jeremy Huntwork wrote:
we still need to hear Alexander's comments on it, so let's give him
the time he needs. (I think he's sleeping, atm.)
He is gone for another week at least, an exam and other things until
20060602:
http://archives.linuxfromscratch.org/mail-archi
Jeremy Huntwork wrote:
What you have described, Matt, has been tried and has failed.
I think it's a bit too soon to be saying that it's failed. LFS has only
been using a udev-config tarball, the contents of which come from the
LFS svn repo, for a short period of time.
--
http://linuxfroms
On Tue, May 23, 2006 at 10:36:07PM +0100, Matthew Burgess wrote:
>
> LFS/trunk/BOOK - LFS book, forms the base of CLFS, BLFS, etc.
> LFS/trunk/bootscripts - LFS bootscripts, forms the base on which BLFS
> and CLFS bootscripts are built on.
> LFS/trunk/udev-config - LFS udev rules, forms the base
Matthew Burgess wrote:
Everyone? IIRC Jeremy made the suggestion, Dan agreed, now *everyone*
wants to move from a process that is well understood and appears to
work without problems to some new procedure whose benefits haven't
even been outlined?
The current process doesn't take in account
On Tue, May 23, 2006 at 11:52:35PM +0100, Matthew Burgess wrote:
>
> I think it's a bit too soon to be saying that it's failed. LFS has only
> been using a udev-config tarball, the contents of which come from the
> LFS svn repo, for a short period of time.
No, not even. The repo has not been u
Matthew Burgess wrote:
The major advantage to this scheme, IMO, is consistency. Everything
to do with the LFS book is in one repository. Likewise, for BLFS and
CLFS, everything concerning their books would be in their own svn
repos. If you need changes to the LFS bootscripts or rules files
Archaic wrote:
And BTW, Alex was consulted on all of these changes to verify their
sanity first. As for the persistence stuff, that's all his work. I just
packaged it, so what has been done so far is basically Alex's work with
me pitching in a bit. IOW, there is no need to throw the baby out with
Matthew Burgess wrote:
Jeremy Huntwork wrote:
What you have described, Matt, has been tried and has failed.
I think it's a bit too soon to be saying that it's failed. LFS has only
been using a udev-config tarball, the contents of which come from the
LFS svn repo, for a short period of time
Jim Gifford wrote:
Face it LFS and CLFS both don't want to give up
what we currently have, and _/* The CLFS team is trying to compromise*/_
with this proposal, but like normal it's the LFS way or no way.
If I knew what we were compromising on, Jim, it'd be a hell of a lot
easier. Tell me wha
Archaic wrote:
I'm really not understanding why BLFS is in this proposal. They are in
addition to the rules needed by a base system (whether that base is
HLFS, CLFS, or LFS). There is nothing to be gained by putting blfs rules
in there, especially since they use cat commands to create the rules
t
Jim Gifford wrote:
If we have a common repo for all projects, the unique issues that arise
from the projects can be addressed in the private repo there, under a
neutral parties control. Face it LFS and CLFS both don't want to give up
what we currently have, and _/* The CLFS team is trying to co
On Tue, May 23, 2006 at 04:04:31PM -0700, Jim Gifford wrote:
> >
> Because it will be one package for the entire system. No more separate
> development, no separate package. The community has wanted this for
> years, but everyone has ignored that fact.
But BLFS doesn't have rules files. They t
Matthew Burgess wrote:
Jim Gifford wrote:
Face it LFS and CLFS both don't want to give up what we currently
have, and _/* The CLFS team is trying to compromise*/_ with this
proposal, but like normal it's the LFS way or no way.
If I knew what we were compromising on, Jim, it'd be a hell of a l
Jim Gifford wrote:
So the bottom line is Matt, the LFS package should of never been
created. But co-operation with CLFS and a unified package could of been
born instead of us fighting.
Well, in which case, what *you* should have done is come to LFS when you
originally created the udev tarbal
Jim Gifford wrote:
So the bottom line is Matt, the LFS package should of never been
created. But co-operation with CLFS and a unified package could of been
born instead of us fighting. Which frankly I'm tired of it. So at this
point Matt, I think we will agree to disagree.
The CLFS Udev rules
Justin R. Knierim wrote:
The CLFS Udev rules were discussed in depth on the clfs-dev list,
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2006-January/055092.html
Obviously I meant lfs-dev, as the link I pasted shows. Typoed the above
sentence.
Justin
--
http://linuxfromscrat
On Tue, May 23, 2006 at 04:26:37PM -0700, Justin R. Knierim wrote:
>
> So why objections to merging them or even starting with the CLFS rules?
> If Alexander is to rule over them like Jeremy H and others mentioned,
> then wouldn't it be logical to start with what he already has reviewed?
No, i
On 5/23/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote:
> The bottom line is if it's Alex or Dan, it needs it's own repo. With
> branches for LFS and CLFS, so if we make some changes, then Alex or Dan
> can merge the changes in.
>
> On similar note I talked to DJ about this also
On 5/23/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
I still think, from an organisational
perspective, the rules belong in the LFS repository and that CLFS should
add to those rules, either like BLFS does via 'cat'ting to additional
files, or by providing additional rules files.
+1.
--
Tush
Archaic wrote:
No, it wasn't logical. What was logical was to take a fresh look at
things. Udev has been a fast moving target. The rules need refreshed as
we go along. For instance, NAME="%k" is no longer needed. A second thing
was new concepts that were seemingly not present when LFS/CLFS rules
On Tue, May 23, 2006 at 05:29:49PM -0700, Jim Gifford wrote:
> >
> Which you pointed out, and I changed.
But what about all the other changes? We need to discuss all differences
and sort out which way to go every step of the way if we are going to
produce something both books can use.
--
Arch
Archaic wrote these words on 05/23/06 19:46 CST:
> But what about all the other changes? We need to discuss all differences
> and sort out which way to go every step of the way if we are going to
> produce something both books can use.
So, start the ball rolling.
As a totally neutral party to th
As I've been reading this thread I noticed one common theme. control.
The main problem that I think is holding us back is that some people
don't want to give up their control over *their* udev rules.
Yes, The packages are almost identical.
Yes, It would be easy to use cat to create extra rules spe
On Tue, May 23, 2006 at 09:03:05PM -0400, Joe Ciccone wrote:
>
> I think a svn repo should be added for a common set of udev rules. I
> will be willing to go through both the lfs rules and the clfs rules,
> find all of the common rules, and mosh them together into one common
> package. I don't thi
Archaic wrote:
Replying to you and Randy, everything you described has already been
started. The repo exists now in the LFS repo. Feel free to check it out
and also to look at my email that detailed all the changes currently
made. There's more in my working copy as well. Things like adding more
s
Archaic wrote:
> On Tue, May 23, 2006 at 09:03:05PM -0400, Joe Ciccone wrote:
>
>> I think a svn repo should be added for a common set of udev rules. I
>> will be willing to go through both the lfs rules and the clfs rules,
>> find all of the common rules, and mosh them together into one common
On Tue, May 23, 2006 at 06:45:38PM -0700, Jim Gifford wrote:
>
> The repo also exists in CLFS, but lets stop playing this stupid game.
> Lets get the common repo up.
What stupid game? I'm pointing out that the goal of unification has
already started. The changes made thus far should not be throw
Archaic wrote:
What stupid game? I'm pointing out that the goal of unification has
already started. The changes made thus far should not be thrown out just
because that are in the lfs repo. They should be copied into the new
repo and continued.
I'll get the repo and trac up on cross-lfs.org.
Jim Gifford wrote:
To just make sure we all have a clear understanding.
1 - Repo will be created for Bootscripts and Udev rules
2 - Repo to be maintained by DJ, Alex, and Dan ( my choices). With the
Dev Teams from BLFS, CLFS, and LFS.
3 - Trunk to be maintained by DJ, Alex, and Dan.
CLFS
Randy McMurchy wrote:
./configure --prefix=/usr
make
make install
and I've not heard a peep from any package about libpng. And I'm
close to the 300 packages into the build so far.
Before we do anything else, let's determine what you did different
than me, that is causing you to see such strang
Ok it's now setup. http://udev.cross-lfs.org/
Alex and Dan when you sign up let me know what your usernames are so I
can give you admin access to trac and full access to the SVN.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See t
Jim Gifford wrote:
Ok it's now setup. http://udev.cross-lfs.org/
Alex and Dan when you sign up let me know what your usernames are so I
can give you admin access to trac and full access to the SVN.
I have registered as "[EMAIL PROTECTED]". Only then I found that
this is inconsistent with "ji
Alexander E. Patrakov wrote:
I have registered as "[EMAIL PROTECTED]". Only then I found
that this is inconsistent with "jim". Should I re-register?
Your choice. Registered both if you want, it is all good.
Justin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxf
Alexander E. Patrakov wrote:
Jim Gifford wrote:
Ok it's now setup. http://udev.cross-lfs.org/
Alex and Dan when you sign up let me know what your usernames are so
I can give you admin access to trac and full access to the SVN.
I have registered as "[EMAIL PROTECTED]". Only then I
found that
On 5/23/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote:
> To just make sure we all have a clear understanding.
>
> 1 - Repo will be created for Bootscripts and Udev rules
> 2 - Repo to be maintained by DJ, Alex, and Dan ( my choices). With the
> Dev Teams from BLFS, CLFS,
On 5/23/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote:
> Ok it's now setup. http://udev.cross-lfs.org/
>
> Alex and Dan when you sign up let me know what your usernames are so I
> can give you admin access to trac and full access to the SVN.
I have registered as "[EMAIL
Dan,
We just need someone to lay down the law between the projects. I
think your perfect for the job.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Access is now setup for Dan and Alex, you guys have full control. I
still have access, but you can delete it if you need to. The only other
person who has access is Justin, since he's maintainer of the hardware
for cross-lfs.org, I recommend he stays in that group for
troubleshooting for the do
81 matches
Mail list logo
