Re: LFS Directions
On Fri, 2009-09-18 at 00:20 +, Greg Schafer wrote: > (Sidenote: Any plans for LFS to incorporate parallel make into the build? > Seems like a gaping omission in this day and age of commonplace multicore > cpu's. At the very minimum, Glibc, GCC and Binutils should be given the > option of `make -jX' with the appropriate explanation...) Much more clever would be to mention MAKEFLAGS in the intro somewhere, and add -j1 as needed for the packages that don't support parallel make. This is what I do in my build scripts, and out of >1300 source packages, I've only had to enforce -j1 for 15 or so. Many of those are using obscure build systems, e.g. cdrtools with its Silly Makefile System. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: devtmpfs proposal
On Sun, 2009-09-20 at 14:56 -0700, Nathan Coulson wrote: > On Sun, Sep 20, 2009 at 11:49 AM, Bruce Dubbs wrote: > > Nathan Coulson wrote: > >> I noted that the linux kernel is working on a system called devtmpfs. > >>>From what I have read, it mount's a tmpfs, then populates it (Giving > >> us console, and null, even all the device module nodes before udev > >> runs). It is designed to allow udev to come along later, and > >> replace/update the nodes. > >> > >> This would allow the boot scripts to be simplified, and allow booting > >> with init=/bin/bash w/o additional setup (Other then mounting / > >> readwrite). > >> > >> Information on how it works: > >> http://lwn.net/Articles/330985/ > >> > >> Upstream Status: > >> http://lwn.net/Articles/345480/ > > > > I'm not sure how this affects us. It appears that we remove section 6.2.1. > > Creating Initial Device Nodes (but insist on a specific kernel option). I > > don't > > see anything else. I suppose /dev would be automatically mounted as a > > tmpfs, > > but how does that help someone who is not doing something with an embedded > > system without a disk drive? > > > > What am I missing? > > well, I think it was myself missing something actually. > > When I was suggesting it, I was imagining /dev already existing when > the kernel boots [the fact I still have to mount it on /dev slipped my > mind]. > > It would only have minimal value to the book, if any. There would not > be any changes to the bootscripts. Right after the CONFIG_DEVTMPFS option, there is CONFIG_DEVTMPFS_MOUNT which when enabled mounts the tmpfs automatically on driver core initialization. This is what you want. I've been using devtmpfs since the first patches were posted, and I really like it. It's the just-works of devfs with the (optional) configurability of udev on top. I haven't simplified my boot scripts and sequence yet, but for the first time in years, I'll get to remove lines instead of adding them. Also, for the people that will run an initramfs for whatever reason, this will make it much simpler, not having to put udev in there. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: PROPOSAL -- new group to handle multi-project tasks
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 target for the kernel which would produce such headers. AFAIR it's scheduled for inclusion in 2.6.18. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
8.3.1 doesn't warn about world-writable sources
Hi, I just read chapter 8.3.1 which states: It is important to note that the files in the kernel source directory are not owned by root. Whenever a package is unpacked as user root (like we did inside chroot), the files have the user and group IDs of whatever they were on the packager's computer. But the kernel sources are tar'ed world-writable, and the default behaviour of GNU tar is to preserve both the owner *and* permissions when running as root. This is a pretty serious flaw if people aren't aware of it, so I think it needs to be mentioned. Thanks for a great, distro-neutral book! :-) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 8.3.1 doesn't warn about world-writable sources
On Sat, 2006-08-26 at 12:27 +0200, Mark Rosenstand wrote: [snip] > This is a pretty serious flaw if people aren't aware of it, so I think > it needs to be mentioned. Oh, and it could be recommended to use the --no-same-owner --no-same-permissions arguments for tar, in case people wan't to actually change that idiotic, non-standard behaviour. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Book text updates
On Tue, 2006-07-18 at 07:31 -0700, Dan Nicholson wrote:
> On 7/18/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> >
> > > -install -dv -m 1777 /tmp /var/tmp
> > > +install -dv -m 1777 {/var,}/tmp
> >
> > This syntax looks wrong to me. Seems it would create a /var/tmp
> > dir but not /tmp.
>
> It's correct. {/var,} expands to /var and "".
I think this obfuscation of the command is unneccessary, since the paths
are so short (you save 2 chars and in the keys you'll have to strike are
placed at worse positions) and it's also a bash-ism (which I don't mind
in general, but to do it for things as simple as this, the whole book
might as well be converted to l33t...)
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
udev rules: to patch or tar
As the udev team is becoming better at providing default rules, I'm
wondering if some of the pain in terms of (as well as errors associated
with) maintaining a complete set of rules externally could be avoided.
Attached is a diff between the LFS 20060920 rules and the rules.d
directory from the udev tarball - I'm not sure how many of these are
intentional, perhaps someone could comment?
Who knows, if the patch approach is chosen, perhaps some of the changes
(such as nicer comments) could go upstream. And who would be better
suited to provide a 50-udev-default.rules skeleton for the distros than
the developers of the LSB reference system? :)
diff -ur rules.d/05-udev-early.rules lfs/05-udev-early.rules
--- rules.d/05-udev-early.rules 2006-09-07 11:32:45.0 +0200
+++ lfs/05-udev-early.rules 2006-09-21 01:37:26.0 +0200
@@ -1,4 +1,3 @@
# sysfs is populated after the event is sent
-ACTION=="add", DEVPATH=="/devices/*", ENV{PHYSDEVBUS}=="?*", WAIT_FOR_SYSFS="bus"
+ACTION=="add", DEVPATH=="/devices/*", SUBSYSTEMS=="?*", WAIT_FOR_SYSFS="bus"
ACTION=="add", SUBSYSTEM=="scsi", WAIT_FOR_SYSFS="ioerr_cnt"
-
Only in lfs: 25-lfs.rules
Only in lfs: 26-modprobe.rules
Only in lfs: 27-firmware.rules
Only in rules.d: 60-persistent-input.rules
diff -ur rules.d/60-persistent-storage.rules lfs/60-persistent-storage.rules
--- rules.d/60-persistent-storage.rules 2006-09-07 11:32:45.0 +0200
+++ lfs/60-persistent-storage.rules 2006-09-21 01:09:11.0 +0200
@@ -5,11 +5,11 @@
SUBSYSTEM!="block", GOTO="persistent_storage_end"
# skip rules for inappropriate block devices
-KERNEL=="ram*|loop*|fd*|nbd*|dm-*", GOTO="persistent_storage_end"
+KERNEL=="ram*|loop*|fd*|nbd*", GOTO="persistent_storage_end"
-# never access non-cdrom removable ide devices, the drivers are causing event loops on open()
+# never access removable ide devices, the drivers are causing event loops on open()
KERNEL=="hd*[!0-9]", ATTRS{removable}=="1", DRIVERS=="ide-cs|ide-floppy", GOTO="persistent_storage_end"
-KERNEL=="hd*[0-9]", ATTRS{removable}=="1", GOTO="persistent_storage_end"
+KERNEL=="hd*[0-9]", ATTRS{../removable}=="1", GOTO="persistent_storage_end"
# for partitions import parent information
KERNEL=="*[0-9]", IMPORT{parent}=="ID_*"
@@ -19,7 +19,7 @@
KERNEL=="hd*[!0-9]", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/ata-$env{ID_MODEL}_$env{ID_SERIAL}"
KERNEL=="hd*[0-9]", IMPORT{parent}=="ID_*", SYMLINK+="disk/by-id/ata-$env{ID_MODEL}_$env{ID_SERIAL}-part%n"
-KERNEL=="sd*[!0-9]|sr*|st*", ATTRS{ieee1394_id}=="*", ENV{ID_SERIAL}="$attr{ieee1394_id}", ENV{ID_BUS}="ieee1394"
+KERNEL=="sd*[!0-9]|sr*|st*", ATTRS{ieee1394_id}=="?*", ENV{ID_SERIAL}="$attr{ieee1394_id}", ENV{ID_BUS}="ieee1394"
KERNEL=="sd*[!0-9]|sr*|st*", ENV{ID_SERIAL}=="", IMPORT{program}="usb_id -x"
KERNEL=="sd*[!0-9]|sr*|st*", ENV{ID_SERIAL}=="", IMPORT{program}="scsi_id -g -x -s %p -d $tempnode"
KERNEL=="sd*[!0-9]|sr*|st*", ENV{ID_SERIAL}=="", IMPORT{program}="scsi_id -g -x -a -s %p -d $tempnode"
@@ -35,9 +35,9 @@
KERNEL=="*[0-9]", ENV{ID_PATH}=="?*", SYMLINK+="disk/by-path/$env{ID_PATH}-part%n"
# by-label/by-uuid (filesystem properties)
-KERNEL=="*[!0-9]", ATTR{removable}=="1", GOTO="persistent_storage_end"
+KERNEL=="*[!0-9]", ATTRS{removable}=="1", GOTO="persistent_storage_end"
IMPORT{program}="vol_id --export $tempnode"
-ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}"
+ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_UUID}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}"
ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_LABEL_SAFE}=="?*", SYMLINK+="disk/by-label/$env{ID_FS_LABEL_SAFE}"
# BIOS Enhanced Disk Device
@@ -45,4 +45,5 @@
KERNEL=="*[!0-9]", ENV{ID_EDD}=="?*", SYMLINK+="disk/by-id/edd-$env{ID_EDD}"
KERNEL=="*[0-9]", ENV{ID_EDD}=="?*", SYMLINK+="disk/by-id/edd-$env{ID_EDD}-part%n"
+
LABEL="persistent_storage_end"
Only in lfs: 81-cdrom.rules
Only in rules.d: 95-udev-late.rules
Only in lfs: ChangeLog
Only in lfs: contrib
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: udev rules: to patch or tar
On Fri, 2006-09-22 at 16:49 +0600, Alexander E. Patrakov wrote:
> Mark Rosenstand wrote:
> ("---" = upstream, "+++" = LFS)
> > # sysfs is populated after the event is sent
> > -ACTION=="add", DEVPATH=="/devices/*", ENV{PHYSDEVBUS}=="?*",
> > WAIT_FOR_SYSFS="bus"
> > +ACTION=="add", DEVPATH=="/devices/*", SUBSYSTEMS=="?*",
> > WAIT_FOR_SYSFS="bus"
> >
> Upstream updated their rule.
> > -KERNEL=="ram*|loop*|fd*|nbd*|dm-*", GOTO="persistent_storage_end"
> > +KERNEL=="ram*|loop*|fd*|nbd*", GOTO="persistent_storage_end"
> >
> Upstream change requested by me but not propagated to LFS
> > -KERNEL=="hd*[0-9]", ATTRS{removable}=="1", GOTO="persistent_storage_end"
> > +KERNEL=="hd*[0-9]", ATTRS{../removable}=="1", GOTO="persistent_storage_end"
> >
> Looks like a conversion error on LFS end: the "removable" attribute
> applies to the whole disk (or maybe even to the CF card which appears as
> a controller), but not partitions. However, the LFS form should also work.
> >
> > -KERNEL=="sd*[!0-9]|sr*|st*", ATTRS{ieee1394_id}=="*",
> > ENV{ID_SERIAL}="$attr{ieee1394_id}", ENV{ID_BUS}="ieee1394"
> > +KERNEL=="sd*[!0-9]|sr*|st*", ATTRS{ieee1394_id}=="?*",
> > ENV{ID_SERIAL}="$attr{ieee1394_id}", ENV{ID_BUS}="ieee1394"
> >
> Same. "*" matches any value, "?*" matches any non-empty value.
So if "*" is bogus the proper action would be to submit it upstream so
all udev users get the fix, right? (And if it isn't bogus, upstream will
explain why and a wrong fix won't be made - not that I think that's the
case for this one)
> > -KERNEL=="*[!0-9]", ATTR{removable}=="1", GOTO="persistent_storage_end"
> > +KERNEL=="*[!0-9]", ATTRS{removable}=="1", GOTO="persistent_storage_end"
> >
> This rule matches whole-disk devices, although there is indeed some
> inconsistency in ATTR vs ATTRS upstream.
> > -ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID}=="?*",
> > SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}"
> > +ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_UUID}=="?*",
> > SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}"
> >
> Upstream updated their rule.
>
> It does make sense to use 05-udev-early.rules and
> 60-persistent-storage.rules directly from upstream, unless a bug is
> found there. There is also 60-persistent-input.rules and
> 95-udev-late.rules that should also be used in their upstream form.
:)
> > Only in lfs: *
> >
> That's the meat that should be discussed. Without these rules, nothing
> works.
Exactly. Do any of these have potential to go upstream at some point, so
that other distros can use them, too? I.e. get 25-lfs.rules into a shape
where it'd be a good candidate for a 50-udev-default.rules of the shared
rules.d in the udev tarball?
Thanks for you comments!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: udev rules: to patch or tar
On Fri, 2006-09-22 at 17:48 +0600, Alexander E. Patrakov wrote:
> Mark Rosenstand wrote:
> > On Fri, 2006-09-22 at 16:49 +0600, Alexander E. Patrakov wrote:
> >
> >> Mark Rosenstand wrote:
> >> ("---" = upstream, "+++" = LFS)
> >>
> >>> Only in lfs: *
> >>>
> >>>
> >> That's the meat that should be discussed. Without these rules, nothing
> >> works.
> >>
> >
> > Exactly. Do any of these have potential to go upstream at some point, so
> > that other distros can use them, too? I.e. get 25-lfs.rules into a shape
> > where it'd be a good candidate for a 50-udev-default.rules of the shared
> > rules.d in the udev tarball?
> >
> Tried that earlier, and (since that's our responsibility to update rules
> submitted upstream!) it was found to be unacceptable for LFS. E.g.,
> upstream won't update LFS rules when conversion is needed. Some early
> udev tarballs actually shipped with ancient and non-working LFS rules
> and bootscripts, and it has been requested then that they don't ship LFS
> rules anymore.
By "shared rules.d" I was thinking of the directory that currently host
the persistant rules and such. Another option (though only for LFS)
would be to take a nicely maintained 50-udev-default as a base (suse
could obviously be a good candidate), patch it and install it.
What I want to accomplish here is to always be able to grab the latest
udev tarball and expect it to work, without having to wait weeks for
distro rule maintainers to update their external rules (and yet have
them slightly outdated) - but if that's too optimistic, not duplicating
the shipped udev rules is a step in the right direction :)
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: udev rules: to patch or tar
On Fri, 2006-09-22 at 07:24 -0700, Dan Nicholson wrote: > On 9/22/06, Mark Rosenstand <[EMAIL PROTECTED]> wrote: > > > > What I want to accomplish here is to always be able to grab the latest > > udev tarball and expect it to work, without having to wait weeks for > > distro rule maintainers to update their external rules (and yet have > > them slightly outdated) - but if that's too optimistic, not duplicating > > the shipped udev rules is a step in the right direction :) > > Sorry, but I'm gonna lean towards too optimistic. The only reason the > suse rules get updated at the time of udev release is because Kay > works on suse. I'm aware of that, but don't see how it conflicts with my argument that they would make a good base to diff against. Quite the opposite :) > The other rules work the same way ours do. Frugalware > and Slackware are the only other distros that submit their rules > changes upstream in a timely manner. But it's not like the udev > release is being delayed until that happens. Which only makes the need for a common set of rules (for all distros, which the distros then patch to meet their needs, instead of having an external set of duplicated/outdated rules for every distro on the planet) even more apparent, IMO. > So, if you want to live on the bleeding edge, I'd suggest using the > default rules or the suse ones. Even if the LFS specific rules were in > the tarball, they wouldn't necessarily be current. This is not my intention. What I asked was if it would be possible to get the LFS rules (those not already provided in the rules.d dir of the udev tarball) into a shape where they could become "the 50-udev-default.rules" Currently I am using suse's 50-udev-default and all the others are from the default rules.d, and it does work alright, except some of the features provided by the LFS rules (generic modprobe for instance) aren't there. No problem, I just make my own rules for them, but I think all users (and distro maintainers) could benefit from a "base" set of rules. The duplicated effort that happens today is just mad. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev fb[0-9]* permissions
On Mon, 2006-10-09 at 11:50 +0600, Alexander E. Patrakov wrote: > Bryan Kadzban wrote: > > KERNEL=="fb[0-9]*", MODE="0620", GROUP="video" > > > That's a bug. Must be 0660, because there is no such thing as > "write-only mmap" in Linux. Another locally added bug in the udev rules :( I sort of fear to bring it up again, since last time it only caused even more rule files to get copied, but wouldn't it make sense to take the 50-udev-default.rules from the suse directory (since they're well maintained) and the rest from the udev directory, and patch as needed, instead of "forking" all the files? In any case, calling the default rules "25-lfs.rules" is probably not too good, since it contradicts with both the udev documentation and other distros. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev fb[0-9]* permissions
On Mon, 2006-10-09 at 19:03 -0400, Bryan Kadzban wrote: > Mark Rosenstand wrote: > > Iwouldn't it make sense to take the 50-udev-default.rules from the > > suse directory (since they're well maintained) and the rest from the > > udev directory, and patch as needed, instead of "forking" all the > > files? > > I am not aware of any way to patch "in-flight" -- if we used seds to do > the updates, we could just sed the various files as part of the copy > process. But AFAIK patch only works in-place; we'd have to copy the > files and patch them afterward. Or patch them first, then install them. > Either way, though, I suppose that's not a huge issue. Actually, maybe > patch's -o option would be helpful. > > But I don't see this bug as an argument for using the SuSE rules (or > modified SuSE rules, for that matter). It was added years and years > ago, way back before *any* rules were included in the udev tarball. It > was copied (more or less) from the MAKEDEV script. I wasn't aware it started out like that. Explains why the rules was kept as copies instead of patches, but now when there are generic rules included, some reconsideration might be in place :-) Now, basing a patch on the SUSE 50-udev-default.rules have the huge advantage that they're both generic and well-maintained. If LFS really is that different, I guess an external 50-udev-default.rules could be maintained, but I think at least forking the sample rules should be avoided. > Yes, using "standard" rules makes it less likely to introduce gratuitous > bugs, that's true. But I'm not sure that the extra work of reevaluating > each upstream release that we put into the book is worth it, either. As I see it, the rules are mostly like a library of known device nodes. Reevaluating each upstream release would only make sense if you do the same for the source code. And it makes just as much sense to copy the entire source tree into LFS svn, and synchronize it on each release, as is currently done for the rules. > For instance, if we did this now, we would have several patch hunks that > serve no purpose except fixing bugs (or inconsistencies) in the current > sample rules. But the next release of udev will include these changes > as well. If we basically have to look at the whole patchset at each > release to see which of our changes (if any) are already there, I think > that's a lot of work. In my POV, the correct solution is to submit any changes upstream, and I'm very happy that you seem to do just that :-) Anyway, if a correction/fix is significant enough, it can be patched in LFS; otherwise just send it upstream and it will be there in the next release. > Today we can upgrade udev and udev-config independently (most of the > time anyway). If we move to patches, we'll be tying the two together > more closely. True, but the point of this is to get rid of udev-config. I think most LFS-people like the fact that it's pretty distro neutral and that you use mostly vanilla software. > Now maybe it's no more work to merge our patchset "forward" into the > upstream rules than merging the upstream changes "backward" into our > rules. But I suspect it would be more work. It depends on the relative > frequency of upstream changes that duplicate our patch(es), I suppose. For the first release or two, this could be true. However the goal is to get most of it upstream, so it's likely to require much less maintenance in the long run. > > In any case, calling the default rules "25-lfs.rules" is probably not > > too good, since it contradicts with both the udev documentation and > > other distros. > > Other distros I can see; most call it *-default.rules or something > similar. Which would be fine, don't get me wrong. But what does it > contradict in the udev docs? I don't see anything in the udev(7) > manpage that mentions specific names for rules files. Or isn't that > what you meant? I was refering to the Udev Bible, AKA writing-udev-rules.html :-) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev fb[0-9]* permissions
On Sat, 2006-10-14 at 15:57 -0700, Dan Nicholson wrote: > On 10/14/06, Mark Rosenstand <[EMAIL PROTECTED]> wrote: > > On Mon, 2006-10-09 at 19:03 -0400, Bryan Kadzban wrote: > > > > > Now maybe it's no more work to merge our patchset "forward" into the > > > upstream rules than merging the upstream changes "backward" into our > > > rules. But I suspect it would be more work. It depends on the relative > > > frequency of upstream changes that duplicate our patch(es), I suppose. > > > > For the first release or two, this could be true. However the goal is to > > get most of it upstream, so it's likely to require much less maintenance > > in the long run. > > Why don't you supply a diff of the shipped udev rules vs. udev-config > so we can see just how much of an issue we have? Personally, I copy everything in the SUSE directory, then overwrite with all the example rules, which currently means everything except 50-udev-default.rules and 64-device-mapper.rules is overwritten. Try a "diff -ur etc/udev/suse etc/udev/rules.d" to understand why I'm doing so. I have a seperate file for the modprobe magic and one for alsa since those aren't provided by either. > > I was refering to the Udev Bible, AKA writing-udev-rules.html :-) > > FWIW, that file is not written by the Udev maintainer. I don't think > he even looks at it. He just applies patches to it if anyone provides > them. It's still the official udev documentation, and 50-udev-default.rules *is* the most common name for the default rules. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev fb[0-9]* permissions
On Sun, 2006-10-15 at 00:50 +0200, Barius Drubeck wrote: > On Sunday 15 October 2006 00:27, Mark Rosenstand wrote: > > most LFS-people like the fact that it's pretty distro neutral and > > that you use mostly vanilla software. > Indeed. So I puzzled how does that strengthen the argument for using > the udev rules from another distro? Because the maintainer of that other distro is also the upstream maintainer of the program, and the rules are generic. It's not like YaST is being called from them. But as I said, an external 50-udev-default.rules file could be maintained if needed, it just seems silly to duplicate all the example rules. If they need fixing, doing so with patches and submit them upstream is the right thing to do. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev fb[0-9]* permissions
On Sat, 2006-10-14 at 17:59 -0700, Dan Nicholson wrote: > On 10/14/06, Mark Rosenstand <[EMAIL PROTECTED]> wrote: > > On Sat, 2006-10-14 at 15:57 -0700, Dan Nicholson wrote: > > > > > > Why don't you supply a diff of the shipped udev rules vs. udev-config > > > so we can see just how much of an issue we have? > > > > Personally, I copy everything in the SUSE directory, then overwrite with > > all the example rules, which currently means everything except > > 50-udev-default.rules and 64-device-mapper.rules is overwritten. > > > > Try a "diff -ur etc/udev/suse etc/udev/rules.d" to understand why I'm > > doing so. I have a seperate file for the modprobe magic and one for alsa > > since those aren't provided by either. > > I know how to do the diff. I'm asking you to do it and convince me of > the change because I don't think there's anything wrong with the > current arrangement. > > Also, I'm confused on what you're asking to do. Do you want to use the > rules in etc/udev/rules.d or etc/udev/suse? For udev-101, it seems > there isn't a 50-default.rules currently, so you must mean the suse > rules. I use all the example rules and then 50-udev-default.rules and 64-device-mapper.rules from the SUSE directory, exactly because there aren't any examples for those, and because they're the most generic and well-maintained. I think LFS could do the same, or at least use the example rules from the tarball and only maintain the missing files externally. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: download location for shadow down since a while ?
On Mon, 2007-05-14 at 08:02 -0700, Dan Nicholson wrote: > On 5/14/07, Jens Stroebel <[EMAIL PROTECTED]> wrote: > > > > I've been trying for some time now to get the shadow-4.0.18.1 source > > from ftp://ftp.pld.org.pl/software/shadow/shadow-4.0.18.1.tar.bz2 ; > > the site is not resolvable, though. > > Yeah, that's about the least reliable server on the internet :) You > can just use a mirror for now. It's _unresolvable_ and has been so for several months. I don't think it's coming back. pld.org.pl redirects to pld-linux.org, and the latest version of shadow at their FTP site is 4.0.3. I haven't gotten any traffic from their mailing list since Feb 1, which was the maintainer telling that he was busy with his new job. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Headers question
On Wed, 2007-11-21 at 20:35 +, Reece Dunn wrote: > Hi, > > In the sections on building the Linux headers from the kernel sources, > the build instructions are (for section 6): > > make mrproper > make headers_check > make INSTALL_HDR_PATH=dest headers_install > cp -rv dest/include/* /usr/include > > What is the rationale behind the last two lines? Why not simply run: > > make INSTALL_HDR_PATH=/usr/include headers_install IIRC will the headers_install target wipe out INSTALL_HDR_PATH prior to installing the headers, which is Ungood[tm] for /usr/include. At least at some point I think headers_install depended on headers_check; if that's still the case perhaps that step could be left out. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: mktemp, tempfile & coreutils
On Wed, 2007-10-17 at 18:41 -0400, Bryan Kadzban wrote: > > I think we've given plenty of time for any users of the `tempfile' > > binary to have been updated now, so any remaining users should be > > patched to use `mktemp'. > > That's my first thought as well, but I don't know for sure how many > users there are. It looks like "none during installation", but who > knows if that's actually true. FWIW, I've been maintaining a full LFS-like distribution since '05 currently counting 969 source packages and have never used any tempfile wrapper nor noticed anything missing it. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2. 6.14.x)
On Wed, 2005-11-30 at 07:46 -0800, Dan Nicholson wrote: > On 11/30/05, Feldmeier Bernd <[EMAIL PROTECTED]> wrote: > > > > Hello guys, > > > > I created a LFS 6.1.1 test system. > > But is there a problem if I use > > the latest kernel version ? > > > > Because Using Linux-Libc-Headers version > > and latest kernel version differs? > > It's perfectly fine as far as I know. Every major distro does it. In > fact one of the main reasons to install l-l-h is so the glibc you > installed will always have a known set of headers to interface with > the kernel. All that happens is that your glibc can't use the new > kernel features that come up, but other applications that are aware of > them can. > > For instance, 2.6.14 includes something called FUSE (File Systems in > Userspace) which allows ordinary users to mount various filesystems in > userspace (I'm bungling the description). Anyway, my l-l-h headers > are 2.6.12.0, but I updated the kernel to 2.6.14.2 and used the FUSE > interface to my heart's content. Just an example. And I run a dovecot IMAP server without inotify-support on a inotify-enabled Linux 2.6.14 machine because it couldn't find -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2. 6.14.x)
Matt Darcy wrote: > Mark Rosenstand wrote: > > And I run a dovecot IMAP server without inotify-support on a > > inotify-enabled Linux 2.6.14 machine because it couldn't find > > > > And what is your experience with this ? > > Do you find that inotify works/is picked up by dovecot ? or do you > find its just a feature that is enabled in the kernel, that is not > picked up by applications. > > I'm interested I thought the "because" part made it pretty clear :) I would like it to use inotify, but it doesn't because the headers are too old. I never really understood why most (all?) distributors choose to use kernel headers that doesn't match the running kernel. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
FAQ: Package management
Hi there, Not knowing anything about the development of LFS (and in the hopes of not having to) I would like to suggest two (faily big) package management systems to be mentioned on the FAQ: - pacman from Arch Linux It does dependency tracking, supports (optionally remote) package repositories, file collisions, package conflicts, etc. It's also used by a couple of other distributions as well, such as Frugalware. - dpkg from Debian Well, somebody else will probably do a better job explaining it, but I think it should be mentioned. Unlike RPM, this one actually builds on distributions other than the one supplied by the vendor... (Recent versions of RPM fails to locate rpm.h.) It's also much lighter on dependencies. On a side note: Another headline for "Why isn't some package manager in the book?" would be appreciated. I failed to look there before going to lfs-support because I knew the answer to that question. "Is it possible to use a package manager with LFS?" or something in those lines really fits the answer better. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: FAQ: Package management
Bruce Dubbs wrote: > Mark Rosenstand wrote: > > > On a side note: Another headline for "Why isn't some package > > manager in the book?" would be appreciated. > > http://www.linuxfromscratch.org/blfs/view/cvs/introduction/important.html#pkgmgt Yes. This is exactly what leads people to believe that they already know the answer to that question when they later see "Why isn't some package manager in the book?" in the FAQ. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
