Re: Kernel headers [Was: Re: User IDs and Group IDs]

Bryan Kadzban wrote: Andrew Benton wrote: If it is wrong to use the kernel headers why don't the kernel developers include fixed headers in with the kernel source? Because the linux-libc-headers project already exists. (Now, this wasn't a valid answer until recently, but until 2.5.something,

Re: User IDs and Group IDs

Matthew Burgess wrote: If folks are happy enough having a mismatched version of kernel vs. userspace headers I'm more than willing to upgrade the kernel just so we can get all this udev mess behind us. Note that after the first time the user upgrades his kernel (e.g. for security reasons), h

Kernel headers [Was: Re: User IDs and Group IDs]

Andrew Benton wrote: > That doesn't sound too dangerous to me. Except that the kernel headers use different names (and possibly different types, although the types have to be the same size) from what userspace needs to use. For instance, see: http://groups.google.com/group/linux.kernel/browse_fr

Re: User IDs and Group IDs

Dan Nicholson wrote: One reason is that the headers in the kernel source include all the internal kernel definitions. As I understand it, it's bad form for userland apps to be using internal kernel interfaces (with the exception of glibc). That doesn't sound too dangerous to me. Surely the hea

Re: OT: simplify CLFS [WAS: Re: User IDs and Group IDs]

Jeff Cousino wrote: Greetings from a long time lurker. Jeremy's post prompted me to ask a question I've had for some time now. Why have a crooslfs if you end building lfs natively anyway? --snip-- Crosslfs is good for cross-compiling between different architectures (eg i686-pc-linux-gnu ->

Re: User IDs and Group IDs

Dan Nicholson wrote: On 11/22/05, Matthew Burgess <[EMAIL PROTECTED]> wrote: Jeremy Huntwork wrote: --snip-- That's not true. I use Beagle, which uses iNotify from 2.6.13+, and my headers are 2.6.12.0 from linux-libc-headers. And it definitely works. -- Dan I had to modify my Linu

Re: User IDs and Group IDs

Richard A Downing wrote: Anyone tried asking the llh devs about their plans? I've just emailed the maintainer now. I'll let lfs-dev know when I hear back. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the

Re: User IDs and Group IDs

On Wed, 23 Nov 2005 20:28:27 + Matthew Burgess <[EMAIL PROTECTED]> wrote: > Murphy's law being as it is, the moment we add such a message to the > book, an updated version of LLH will be released and make it immediately > out of date! Anyone tried asking the llh devs about their plans? --

Re: User IDs and Group IDs

Randy McMurchy wrote: Do not be alarmed if the Kernel version and the LLH version are not exactly the same. The combination of x.x.x kernel and x.x.x LLH have been tested and are known to work together. But does that put too much of an onus on the developers to test all of the new features pr

Re: User IDs and Group IDs

Matthew Burgess wrote these words on 11/23/05 14:15 CST: > Agreed, though I'm going to introduce one now. When upgrading the > kernel so that it no longer matches version numbers with llh, we need a > note on the llh page(s) stating that this isn't a problem because... How about: Do not be al

Re: User IDs and Group IDs

Jeremy Huntwork wrote: Dan Nicholson wrote: That's not true. I use Beagle, which uses iNotify from 2.6.13+, and my headers are 2.6.12.0 from linux-libc-headers. And it definitely works. From what I'm hearing, I personally can't see any reason to not upgrade the kernel version in LFS SVN

Re: User IDs and Group IDs

On 11/23/05, Andrew Benton <[EMAIL PROTECTED]> wrote: > Jim Gifford wrote: > > Matt, > >I should also mention Ryan is working on a way for us to santize our > > own headers. > > > Please excuse my ignorance, but why do we need to sanitize the kernel > headers? What's wrong with using the heade

Re: User IDs and Group IDs

Jim Gifford wrote: > 65533 - 65534 Nobody/Nogroup See my disussion of nobody/nogroup in the note at http://www.linuxfromscratch.org/blfs/view/cvs/server/nfs-utils.html#nfs-utils-install -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/

Re: User IDs and Group IDs

We took Debian, Gentoo, and Fedora pulled out a common list of users and groups. This is what we came up with. We used the following Scheme. 0 - 9 Administration Users/Groups 10 - 29 Device Users/Groups 30 - 49 Daemon Users/Groups 50 - 99 Various Users/Groups Accounts with Admin rights to Daemo

Re: User IDs and Group IDs

Jim Gifford wrote: Matt, I should also mention Ryan is working on a way for us to santize our own headers. Please excuse my ignorance, but why do we need to sanitize the kernel headers? What's wrong with using the headers in the kernel source? Andy -- http://linuxfromscratch.org/mailman/

Re: OT: simplify CLFS [WAS: Re: User IDs and Group IDs]

Greetings from a long time lurker. Jeremy's post prompted me to ask a question I've had for some time now. Why have a crooslfs if you end building lfs natively anyway? I've been playing with lfs for about a year now. I turned to the crooslfs project when I wanted to turn an old pentium machine in

Re: User IDs and Group IDs

Bruce Dubbs wrote: I still do not know why it is desirable to consolidate these uids/gids. For what it's worth, I don't think it's feasible either. The whole idea of this discussion is that each service/package/program/whatever gets its own ID to use. If you, for whatever reason, installed bo

Re: User IDs and Group IDs

Matt Darcy wrote: > how about having all mail server programs run with the user "mserver" > with uid/gid 32/33 (just for an example) that way average joe won't have > a problem and anyone with a little more insite can change this as they > see appropriate. We would then have to investigate each s

Re: User IDs and Group IDs

Bruce Dubbs wrote: Jim Gifford wrote: Here's what's bugging me about this whole hardcoding of UIDS. Here is the page from the BLFS book Name UG exim31 31 postfix 32 32 postdrop33 sendmail 34 mail34 I think we all agre

Re: User IDs and Group IDs

Jim Gifford wrote: > Here's what's bugging me about this whole hardcoding of UIDS. > > Here is the page from the BLFS book > Name UG > exim31 31 > postfix 32 32 > postdrop33 > sendmail 34 > mail34 > > I think we all agree

Re: User IDs and Group IDs

On 11/23/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > Dan Nicholson wrote: > > > > That's not true. I use Beagle, which uses iNotify from 2.6.13+, and > > my headers are 2.6.12.0 from linux-libc-headers. And it definitely > > works. > > From what I'm hearing, I personally can't see any reaso

Re: User IDs and Group IDs

Dan Nicholson wrote: That's not true. I use Beagle, which uses iNotify from 2.6.13+, and my headers are 2.6.12.0 from linux-libc-headers. And it definitely works. From what I'm hearing, I personally can't see any reason to not upgrade the kernel version in LFS SVN. -- JH -- http://linuxfr

Re: User IDs and Group IDs

On 11/22/05, Matthew Burgess <[EMAIL PROTECTED]> wrote: > Jeremy Huntwork wrote: > > > 1) Are those specific headers for that version necessary? Wouldn't the > > current ones work? > > Well, they work for me (I've been running 2.6.14 for a while now). > However, I'd imagine that if the kernel gets

Re: User IDs and Group IDs

Here's what's bugging me about this whole hardcoding of UIDS. Here is the page from the BLFS book Name UG exim31 31 postfix 32 32 postdrop33 sendmail 34 mail34 I think we all agree these are mail servers. So why can'ts e

Re: User IDs and Group IDs

Matthew Burgess wrote: Jim Gifford wrote: Matt, I should also mention Ryan is working on a way for us to santize our own headers. Why is this the first we've heard of this on the list? The subject briefly came up not too long ago, an ideal point at which someone could have told us wh

Re: User IDs and Group IDs

On Tue, 2005-11-22 at 21:14 +, Matthew Burgess wrote: > Jeremy Huntwork wrote: > > > 1) Are those specific headers for that version necessary? Wouldn't > the > > current ones work? > > Well, they work for me (I've been running 2.6.14 for a while now). > However, I'd imagine that if the kern

Re: User IDs and Group IDs

On Tue, 2005-11-22 at 13:15 -0800, Jim Gifford wrote: > Matt, > I should also mention Ryan is working on a way for us to santize our > own headers. > Don't dob me in yet ;-) It can be done but man its a fair amount of work... If worst comes to worst and llh doesn't release in a timely fash

Re: User IDs and Group IDs

On Tue, 2005-11-22 at 20:54 +, Matthew Burgess wrote: > Jim Gifford wrote: > > Now we need to re-evaluate the UID/GID's. We are going to need some > > changes for the GID's for udev. > > Why? > > > I'm basing this off of Kay Sievers work, with Debian and OpenSuse. This > > will elminate and

Re: User IDs and Group IDs

On Tue, 2005-11-22 at 20:47 +, Matthew Burgess wrote: > Tushar Teredesai wrote: > > > There is no advantage of hard-coding the UID/GID. (Just as there is no > > advantage to hard-coding /tools into the LFS book but allowing users > > to change $LFS but that is another topic). > > Well, there'

Re: User IDs and Group IDs

Archaic wrote: > Then the argument stays, but the terms change. Instead of arguing > specific uid/gid, it will be how best to arrange it. It is a policy > decision. As such, I like an arbitrary system with an emphasis in each > book that they are merely suggestions and not set in stone (though I'm

Re: OT: simplify CLFS [WAS: Re: User IDs and Group IDs]

Ken Moffat wrote: My experience with the pure64 hint (which was pretty close to LFS-6.1, no biarch or triarch considerations, and the same toolchain) suggests that it's pretty awkward to produce a meaningful precis like this. Certainly, multilib variants are not going to fit nicely into th

Re: User IDs and Group IDs

On Tue, 22 Nov 2005 16:26:02 -0700 Gerard Beekmans <[EMAIL PROTECTED]> wrote: > > I read all the lists (I think, I didn't check for new ones recently). > > I have not seen this on lfs-dev or blfs-dev. Which lists? > > cross-lfs Damn it, there would be one! I didn't notice that cross-lfs had it

Re: User IDs and Group IDs

I read all the lists (I think, I didn't check for new ones recently). I have not seen this on lfs-dev or blfs-dev. Which lists? cross-lfs Gerard, you just burst back on the scene after months (or was it eons?) of inactivity with a 'I'm The Boss, listen to me' kind of mailing. What do you exp

Re: User IDs and Group IDs

On Tue, 22 Nov 2005 16:09:45 -0700 Gerard Beekmans <[EMAIL PROTECTED]> wrote: > Richard A Downing wrote: > > Gerard suddenly discovered that, in his long absence, the LFS > > projects have got away from him and went looking for an 'issue' so as > > to re-establish his authorty. > > Richard, I am

Re: User IDs and Group IDs

Tushar Teredesai wrote: Agreed. But for the *LFS books, it is good to have instructions that work for most users irrespective of their setup. Hard coding the UID/GID would break in more scenarios than the scheme I mentioned. I can agree with that point of view, technically speaking. Personally

Re: User IDs and Group IDs

On 11/22/05, Gerard Beekmans <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > With the scheme I mentioned, they would not be hard coding the UID/GID at > > all. > > That one comes down to a preference I suppose. I don't like these > "dynamics" IDs where things are different every time I in

Re: User IDs and Group IDs

Richard A Downing wrote: Gerard suddenly discovered that, in his long absence, the LFS projects have got away from him and went looking for an 'issue' so as to re-establish his authorty. Richard, I am not looking for an issue, nor have I a need to re-establish my authority. There is a problem

Re: User IDs and Group IDs

On Tue, 22 Nov 2005 11:34:45 -0700 Gerard Beekmans <[EMAIL PROTECTED]> wrote: > Guys, > > There seems to be some issues relating UIDs and GIDs especially between > BLFS and CLFS. > > I'm not going to point the finger whose fault this is and I don't care > about personal issues as I have notice

Re: User IDs and Group IDs

Tushar Teredesai wrote: With the scheme I mentioned, they would not be hard coding the UID/GID at all. That one comes down to a preference I suppose. I don't like these "dynamics" IDs where things are different every time I install a system, depending on which order things happen to be instal

Re: User IDs and Group IDs

On 11/22/05, Gerard Beekmans <[EMAIL PROTECTED]> wrote: > > You work through the CLFS book and you install a service using those > instructions and that book suggest UID 25 and GID 25. > > Now you move on to BLFS and the BLFS has you install another service. > But becuase our IDs are out of sync, t

Re: User IDs and Group IDs

(I'm not subscribed to lfs-dev, so I'd be grateful if you could Cc me on followups) I'd strongly advise against trying to mandate fixed assignments of any application userids. Build procedures should include a dynamic useradd-type account creation that automatically finds a free numeric uid, and s

Re: OT: simplify CLFS [WAS: Re: User IDs and Group IDs]

Jeremy Huntwork wrote: Gerard Beekmans wrote: --snip-- This is a bit off-topic, but this discussion has triggered another thought. With CLFS at some point (whether you decide to chroot or boot) you're going to be building the remainder of the book natively. At that point does CLFS real

Re: OT: simplify CLFS [WAS: Re: User IDs and Group IDs]

On Tue, 22 Nov 2005, Jeremy Huntwork wrote: This is a bit off-topic, but this discussion has triggered another thought. With CLFS at some point (whether you decide to chroot or boot) you're going to be building the remainder of the book natively. At that point does CLFS really need to mainta

Re: OT: simplify CLFS [WAS: Re: User IDs and Group IDs]

In some circumstanaces yes, we have some different architectures that require different programs. So merging the two books would not be an ideal scenario. Not to mention the loads of patches needed for some of the programs to work under MIPS. Unless the LFS book is going to have those in place.

Re: OT: simplify CLFS [WAS: Re: User IDs and Group IDs]

Jeremy Huntwork wrote: Well, I was thinking of non-BLFS arch-specific programs, ie., bootloaders. Now that's got a simple solution (simple == Just Needs Code TM). Rather than getting it to play music and have it be Turing-complete, maybe Grub2 could get support for other architectures? Tha

Re: OT: simplify CLFS [WAS: Re: User IDs and Group IDs]

Archaic wrote: On Tue, Nov 22, 2005 at 04:52:22PM -0500, Jeremy Huntwork wrote: Less redundancy, less maintenance, less worry about conflicts. I guess there is the various arch issues and packages specific to those, but CLFS could give general notes for each arch and instruct users to return

Re: User IDs and Group IDs

On Tue, Nov 22, 2005 at 02:46:01PM -0700, Gerard Beekmans wrote: > > What we need is all projects give a list of all the IDs they use (I have > BLFS' already from a post by Bruce earlier this afternoon) and see if > ther are issues, then reassign a new ID to use. We follow LFS conventions. As f

Re: OT: simplify CLFS [WAS: Re: User IDs and Group IDs]

On Tue, Nov 22, 2005 at 04:52:22PM -0500, Jeremy Huntwork wrote: > > Less redundancy, less maintenance, less worry about conflicts. I guess > there is the various arch issues and packages specific to those, but > CLFS could give general notes for each arch and instruct users to return > when do

OT: simplify CLFS [WAS: Re: User IDs and Group IDs]

Gerard Beekmans wrote: UID 25 should be assigned to, for example, the Postifx service, and you can choose to install it from CLFS or BLFS depending on what your needs are. Maybe Postfix is a poor example, but the idea is clear I hope. Different books can install the same program in different

Re: User IDs and Group IDs

Tushar Teredesai wrote: Would someone really be affected if the UID of postfix on their server is 21 but on the remote server that they login to it is 22? Except during the creation, no one ever uses the UIDs and GIDs, everyone uses the user/group name. That's not exactly the scenario I was thi

Re: User IDs and Group IDs

Jim Gifford wrote: Matt, I should also mention Ryan is working on a way for us to santize our own headers. Why is this the first we've heard of this on the list? The subject briefly came up not too long ago, an ideal point at which someone could have told us what Ryan was up to. You mi

Re: User IDs and Group IDs

On Tue, 22 Nov 2005, Matthew Burgess wrote: Jeremy Huntwork wrote: 1) Are those specific headers for that version necessary? Wouldn't the current ones work? Well, they work for me (I've been running 2.6.14 for a while now). However, I'd imagine that if the kernel gets a new feature (e.g. iN

Re: User IDs and Group IDs

On 11/22/05, Gerard Beekmans <[EMAIL PROTECTED]> wrote: > Randy McMurchy wrote: > > http://linuxfromscratch.org/pipermail/blfs-dev/2005-April/009761.html > > I agree with that idea also for other reasons: it makes things more > uniform across everybody's LFS system if people don't care about coming

Re: User IDs and Group IDs

Matt, I should also mention Ryan is working on a way for us to santize our own headers. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe

Re: User IDs and Group IDs

Jeremy Huntwork wrote: 1) Are those specific headers for that version necessary? Wouldn't the current ones work? Well, they work for me (I've been running 2.6.14 for a while now). However, I'd imagine that if the kernel gets a new feature (e.g. iNotify) but we don't install the userspace hea

Re: User IDs and Group IDs

On 11/22/05, Matthew Burgess <[EMAIL PROTECTED]> wrote: > > Well, there's one really good reason to mandate $LFS being "/tools" - > that's the gcc-4.0.2-specs-1.patch which hardcodes /tools in there. If > we were to relax that /tools assumption, we'd have to explain what folks > would have to do i

Re: User IDs and Group IDs

Matthew Burgess wrote: Jim Gifford wrote: Matt, I've been working with Kay on this, let me get the changes out, it's been working really well for me. I'm not stopping you from getting the changes out, Jim (CLFS is your baby!). I'm merely asking how you are installing a later version of

Re: User IDs and Group IDs

Jim Gifford wrote: Matt, I've been working with Kay on this, let me get the changes out, it's been working really well for me. I'm not stopping you from getting the changes out, Jim (CLFS is your baby!). I'm merely asking how you are installing a later version of the kernel, without the

Re: User IDs and Group IDs

Matt, I've been working with Kay on this, let me get the changes out, it's been working really well for me. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.

Re: User IDs and Group IDs

Jim Gifford wrote: Now we need to re-evaluate the UID/GID's. We are going to need some changes for the GID's for udev. Why? I'm basing this off of Kay Sievers work, with Debian and OpenSuse. This will elminate and change bootscripts also. How have you gotten around the fact that these later

Re: User IDs and Group IDs

Now we need to re-evaluate the UID/GID's. We are going to need some changes for the GID's for udev. I'm working on some changes, that will benefit all projects, it will give LFS/HLFS/CLFS the basic devices, and be able to useful for BLFS. I'm going to have the necessary changes in CLFS in a few

Re: User IDs and Group IDs

Tushar Teredesai wrote: There is no advantage of hard-coding the UID/GID. (Just as there is no advantage to hard-coding /tools into the LFS book but allowing users to change $LFS but that is another topic). Well, there's one really good reason to mandate $LFS being "/tools" - that's the gcc-4

Re: User IDs and Group IDs

On Tue, Nov 22, 2005 at 02:39:06PM -0600, Tushar Teredesai wrote: > > But that "savings" is offset by the discussions on which UID/GID to > assign to a user/group :) Random number generation. :D -- Archaic Want control, education, and security from your operating system? Hardened Linux From Sc

Re: User IDs and Group IDs

Randy McMurchy wrote: http://linuxfromscratch.org/pipermail/blfs-dev/2005-April/009761.html I agree with that idea also for other reasons: it makes things more uniform across everybody's LFS system if people don't care about coming up with their own ID schemes. -- Gerard Beekmans /* If L

Re: User IDs and Group IDs

On 11/22/05, Archaic <[EMAIL PROTECTED]> wrote: > On Tue, Nov 22, 2005 at 02:20:06PM -0600, Tushar Teredesai wrote: > > > > There is no advantage of hard-coding the UID/GID. > > Sure there is: less support questions. :) But that "savings" is offset by the discussions on which UID/GID to assign to

Re: User IDs and Group IDs

Gerard Beekmans wrote these words on 11/22/05 14:31 CST: > That's fine. The scheme is not of importance -- it's the coordination. > If in BLFS book Postfix ends up with UID 21, then Postfix in the CLFS > and/or HLFS books also has to use ID 21. > > When we're all adding new components, we shoul

Re: User IDs and Group IDs

On Tue, Nov 22, 2005 at 02:07:25PM -0600, Randy McMurchy wrote: > Tushar Teredesai wrote these words on 11/22/05 13:58 CST: > > > Instead of assigning a fixed ID number, why not define a range. For example: > > * 1-20: Core users and groups (must have on every system). These are > > created manual

Re: User IDs and Group IDs

On Tue, Nov 22, 2005 at 02:20:06PM -0600, Tushar Teredesai wrote: > > There is no advantage of hard-coding the UID/GID. Sure there is: less support questions. :) > I guess most folks do follow the recommended values. I actually went *to* using the book's values because of having admin access o

Re: User IDs and Group IDs

Randy McMurchy wrote: This is not a bad idea. However, Bruce's plan was to group the UID/GIDs by the type of package it is. Mail = 21-30 Security = 31-40 And so on. The values you see above are not what is in the book. I was just trying to show what Bruce's plan was. That's fine. The scheme i

Re: User IDs and Group IDs

Jeremy Huntwork wrote these words on 11/22/05 14:09 CST: > I didn't really follow that original discussion. What was the reason for > that decision? http://linuxfromscratch.org/pipermail/blfs-dev/2005-April/009761.html -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3]

Re: User IDs and Group IDs

Randy McMurchy wrote: Though I personally think taking it out of the book is wrong. There could be folks that use PDF versions and asking them to visit the web to see the recommended values it not right. There's a misunderstanding there. This document is for our use only -- the developers of t

Re: User IDs and Group IDs

Matthew Burgess wrote: Last I heard, externals can only point to a directory, not a particular file (and http://svnbook.red-bean.com/en/1.1/ch07s04.html appears to support that too). So we would put the entity file in its own dedicated directory? If I understand it correctly, there is no need

Re: User IDs and Group IDs

On 11/22/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote these words on 11/22/05 13:58 CST: > > > Instead of assigning a fixed ID number, why not define a range. For example: > > * 1-20: Core users and groups (must have on every system). These are > > created manually using t

Re: User IDs and Group IDs

Randy McMurchy wrote: Tushar Teredesai wrote these words on 11/22/05 13:58 CST: Instead of assigning a fixed ID number, why not define a range. For example: * 1-20: Core users and groups (must have on every system). These are created manually using the cat command in

Re: User IDs and Group IDs

Tushar Teredesai wrote these words on 11/22/05 13:58 CST: > Instead of assigning a fixed ID number, why not define a range. For example: > * 1-20: Core users and groups (must have on every system). These are > created manually using the cat command in >

Re: User IDs and Group IDs

Randy McMurchy wrote: Though I personally think taking it out of the book is wrong. There could be folks that use PDF versions and asking them to visit the web to see the recommended values it not right. The impression I got behind the suggestion would be that the books used the webpage to co

Re: User IDs and Group IDs

M.Canales.es wrote these words on 11/22/05 13:48 CST: > I would prefer an html page on the web server. And I'm voluntary to update > all > books to that new set of standard user and group IDs if needed. Why on earth would we need "new" standards? We already have a standard. The only thing that

Re: User IDs and Group IDs

On 11/22/05, Gerard Beekmans <[EMAIL PROTECTED]> wrote: > To address this UID and GID issue, a possible solution seems pretty > straight-forward: we'll maintain a UID and GID list that every LFS > project refers to if they need to use a service or ID or whatever. And > if they introduce a new one,

Re: User IDs and Group IDs

El Martes, 22 de Noviembre de 2005 20:32, Gerard Beekmans escribió: > If what you said can easily be done--a shared file across all > repositories--then that's how we should go about it. svn:externals have several limitations, see the last two paras in this page: http://svnbook.red-bean.com/en/1

Re: User IDs and Group IDs

Jeremy Huntwork wrote: You could just have each repo use svn externals and link to that master .ent file. When you check out the repo (whether in CLFS, BLFS or HLFS) you check out that external .ent file as well. Last I heard, externals can only point to a directory, not a particular file (a

Re: User IDs and Group IDs

Jeremy Huntwork wrote: You could just have each repo use svn externals and link to that master .ent file. When you check out the repo (whether in CLFS, BLFS or HLFS) you check out that external .ent file as well. The difficulty would be deciding where to keep it and who has commit privs on it.

Re: User IDs and Group IDs

Bruce Dubbs wrote: I am offering to update the blfs page I mentioned earlier to incorporate all the values. That automatically puts it on the website. I don't think this information should be in one of the *LFS books as it's not project specific data. -- Gerard Beekmans /* If Linux doesn't

Re: User IDs and Group IDs

Gerard Beekmans wrote: Bruce Dubbs wrote: An alternative way to maintain a master list might be to but it in an .ent file as entities (similar to general.ent) and have each project include that in the files where groups and users are needed. For BLFS, we add explicit useradd and group add inst

Re: User IDs and Group IDs

Gerard Beekmans wrote: > I think we can easily have a file on the website somewhere we refer to. > If an update is required, that'll be an easy task. I am offering to update the blfs page I mentioned earlier to incorporate all the values. That automatically puts it on the website. -- Bruce --

Re: User IDs and Group IDs

Bruce Dubbs wrote: An alternative way to maintain a master list might be to but it in an .ent file as entities (similar to general.ent) and have each project include that in the files where groups and users are needed. For BLFS, we add explicit useradd and group add instructions in most packages

Re: User IDs and Group IDs

Gerard Beekmans wrote: > Are any of the project leads (blfs, clfs, hlfs) opposed to maintaining a > shared file like this, and possible more such files down the road if > they become needed? I'll speak on behalf of the LFS project itself and > say that I don't see a problem here. In fact, I think

User IDs and Group IDs

Guys, There seems to be some issues relating UIDs and GIDs especially between BLFS and CLFS. I'm not going to point the finger whose fault this is and I don't care about personal issues as I have noticed things don't get done because people don't care for other people for whatever reason.