Kevin Buckley wrote:
>>> The suggestion above is that gettext only needs it for Glade
>>> support.
>> That's true. So far, only Glade support in gettext requires an XML
>> parser.
>
> I think that's the key for me. It seems as though it is only
> Glade-related input to gettext which requires XML
HouHongxun wrote:
> "root=/dev/sda7" after kernel's image belongs to kernel's parameters.
Right, but irrelevant here, see below. :-)
> I don't think grub cares about kernel's parameters. file systems'
> uuid and root variable used by grub is irrelevant to "root=/dev/sdax"
> or "root=UUID=xxx
Timothy Rice wrote:
> I was contemplating how to implement dependency tracking in the
> Package User system and had an idea. Perhaps it would be of interest.
>
> <...>
>
> Opinions? Are there any obvious problems that I might have
> overlooked?
How do you propose, during package X's installation
Sebastian Plotz wrote:
> I'm note sure, but I think that the LANG variable influences the
> encoding of the output.
Only if the program has been translated into the language and character
set that you set in $LANG. If not, it has no effect. gettext is not
magic; it just provides an alternate by
max wrote:
> Chapter 6.12: binutils-2.20
> ---
> /tools/libexec/pt_chown needs to be suid root at this point,
Not if devpts is set up correctly -- or at least, that used to be the
case a couple years ago. You don't need pt_chown if the kernel is
creating the /dev/pts/* dev
Drew Ames wrote:
> What you say is true for the root user,
Nope, it's true for the non-root user that I run as, every day, as well.
Every time I start urxvt or xterm, in fact. My pt_chowns -- both of
them, since this is a multilib system and each bit-size glibc installed
its own -- are user:group
Drew Ames wrote:
> Instead, I'm going to repartition my laptop and build LFS 6.7 on it.
> With your build notes and Bryan's helpful information on pt-chown, I
> should be able to build everything as package users.
Please let us know if modifying the devpts mount command removes the
need for pt_c
Matthew Burgess wrote:
> Quoting from the vulnerability description above:
>
> "This security issue allows a local attacker to gain root if they can
> create a hard link to a setuid root binary."
>
> So, on your system, is that possible?
That's actually not the only exploit vector. See the fol
Matthew Burgess wrote:
> On Sun, 24 Oct 2010 10:25:26 -0700, Bryan Kadzban
> wrote:
>
>> You can make your own simple library like this:
>>
>> cat <bad.c #include #include #include
>>
>>
>> void __attribute__((constructor)) init() {
>&g
Matthew Burgess wrote:
> On Fri, 21 Jan 2011 15:48:09 -0600, Bruce Dubbs wrote:
>
>> OK, so do we use 2.6.30.2 (LFS-6.5)? Do we need to update any other
>> packages in the requirements or make everything from LFS-6.5 (Aug 2009)?
>> Right now, the minimum requirements are from LFS-6.3 (Aug 200
Matthew Burgess wrote:
> On Fri, 21 Jan 2011 20:52:56 -0800, Bryan Kadzban
> wrote:
>> Matthew Burgess wrote:
>>> If we set it to 2.6.30 (there's no point in adding the stable
>>> version as Glibc only checks the major.minor.patch level), we'll
>>
Bryan Kadzban wrote:
> But from looking at the test code, it doesn't appear to be directly
> dealing with any of these __ASSUME_BLAH symbols. It appears to be using
> standard pthread_blahblah() functions, so if the test is segfaulting, or
> getting the wrong result back, I&#
Andrew Benton wrote:
> On Sun, 23 Jan 2011 15:02:42 -0800
> Bryan Kadzban wrote:
>> I've verified that this patch fixes the problem. This might be possible
>> with sed, but I'm not sure how.
>
> (Doh! Try again. Resending 'cos the the last one only chang
Bruce Dubbs wrote:
> Matthew Burgess wrote:
>> On Mon, 24 Jan 2011 20:06:39 -0800, Bryan Kadzban
>> wrote:
>>
>>> I'm not sure if that's the best setup; we'll have to make sure at each
>>> glibc release (until the bug is fixed) that no ne
akhiezer wrote:
>> Date: Thu, 17 Feb 2011 23:38:21 +
>> From: akhiezer
>> Subject: sed matches too much? - sec-7.10 custom symlinks
>>
>> ver: "SVN-20110216"
>> sec: "7.10. Creating Custom Symlinks to Devices"
>>
>> In sub-section '7.10.1. CD-ROM symlinks', does the sed command match
>> too m
Bruce Dubbs wrote:
> The first question is whether we need to change this file at all.
Well, it's an optional sed. It would depend on the user's setup.
> If we do, then the GENERATED matches both rules and is inappropriate.
> I think the simple change with the quotes will work.
Fixed in trunk (
When looking at the udev sed in chapter 7, I found a change I had
sitting in my local svn client from way back in October, that I never
submitted. See the discussion starting here:
http://linuxfromscratch.org/pipermail/lfs-dev/2010-October/064343.html
and more specifically, the pt_chown discussi
Bruce Dubbs wrote:
>>> * Multi-lib - Shunned previously, but there are many projects
>>> that expect this environment.
>>>
>> For people who build from source, which projects *expect* multilib
>> on x86_64 ?
>>
>> I will agree that building a bi-arch desktop (that is, both 32-bit
>> and 64-bit X
Bruce Dubbs wrote:
> Heads up.
>
> Following the util-linux mailing list, I see that they want to change
> /etc/mtab to a symlink to /proc/mounts. The outstanding issues are
> mount.nfs and pam_mount.
>
> This is also to support systemd.
Sigh.
Have I recently reiterated my extreme dislike of a
On Fri, Apr 15, 2011 at 05:01:21PM -0500, Bruce Dubbs wrote:
> Following some of the discussion lately on file placement, we may want
> to consider doing the following:
>
> 1. In 6.5. Creating Directories
>a. Create /run
>
> 2. Mount a tmpfs in /etc/init.d/mountkernfs on /run. This also req
Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>
>> * Add a param to release any dhclient addresses from a device if it is
>> running in the ipv4-static service
>
> Wouldn't this be a BLFS issue? It's a good idea, but I don't use dhcp
> myself. It makes it hard to ssh into the system.
Unless yo
Jeremy Huntwork wrote:
> On 5/8/11 8:46 PM, Bryan Kadzban wrote:
>> I don't think there's any way to make all potential service scripts
>> able to handle switching to and from all the other potential
>> service scripts, just by starting them. I don't think th
DJ Lucas wrote:
> Jeremy Huntwork wrote:
>> On 5/9/11 2:53 AM, DJ Lucas wrote:
>>> The simple solution is to stop networking before applying
>>> changes.
>> When
>>
>> Yes, I know. :) But in practice that becomes an annoyance. Admins
>> used to working Fedora/Debian/Ubuntu or others assume that c
Jeremy Huntwork wrote:
> On 5/9/11 1:57 AM, Bryan Kadzban wrote:
>> Right, but you have no way to know (in the static config, or the
>> DHCP config, for instance) whether a pppd was running and needs to
>> be killed, or whether DNS needs to be unregistered (unlikely, but
&
Jeremy Huntwork wrote:
> On 5/9/11 11:36 PM, Bryan Kadzban wrote:
>> Right, but the former /etc/sysconfig/network* was also default
>> configuration for how the bootscripts run. Well, the network script
>> anyway. :-)
>
> Just ifup/ifdown (which are now in /sbin) a
DJ Lucas wrote:
> After updating from udev-165 to udev-168, I ran into a timing issue
> with settle using tmpfs for /dev. My swap partition failed to mount
> because the device node was not present. No other changes than those
> made to the bootscripts and FS layout to account for /run.
Ah. /r
DJ Lucas wrote:
> On 05/11/2011 11:14 PM, Bryan Kadzban wrote:
>> Where is your swap?
>
> /dev/sda3...which gives a much better explanation as to why it works
> with devtmpfs. I did not buy the "faster" bit.
Yeah, that sounds about right.
>> (I'm thinkin
DJ Lucas wrote:
> * the path for the setclock script in 55-lfs.rules needs to be
> changed
So... yeah.
Why was this whole tree moved in the LSB scripts, again? :-)
I really really hate systems where I can't reasonably tab-complete the
bootscript filenames. And there's way too much junk in /etc
Zachary Kotlarek wrote:
> On May 15, 2011, at 2:25 AM, DJ Lucas wrote:
>> might actually be easier to provide a default IFCONFIG values in
>> each service script, and walk /lib/network-services.
>
> This make sense to me -- then it's easy to extend the same approach
> for arbitrary service types
Zachary Kotlarek wrote:
> On May 15, 2011, at 12:31 PM, Bryan Kadzban wrote:
>
>> I'm trying to figure out why it'd be necessary to do this. We
>> already have the previous configuration of every interface stuffed
>> away in /run, and we use that when deciding
DJ Lucas wrote:
>
I see some traffic on linux-hotplug about this as well, so it looks like
it's not LFS-specific, at least. (Arch and Debian have both had bugs
reported about this.) The messages from Kay so far seem encouraging, as
well.
...Oh, and I see the message from you there, too. OK, n
Zachary Kotlarek wrote:
> A compromise might be to provide an `ifreset` script, that does a
> full ipflush, walks the services dir calling a `reset` target, etc.,
> but *not* integrate that script into ifdown.
That seems like a pretty good idea. :-)
signature.asc
Description: OpenPGP digital s
Jeremy Huntwork wrote:
> On 5/16/11 1:49 AM, Bryan Kadzban wrote:
>> I'm not sure what the goal *should* be. :-) Does it make sense to
>> try to clean up completely in this kind of setup? Maybe or maybe
>> not.
>>
>> I do think it's least *surprisin
Few nits related to the shell. In the network script:
> # Process individual configuration files
> for file in `ls "${dir}"`; do
Ew. :-) How about:
for file in "${dir}"/* ; do
ONBOOT=`grep "ONBOOT" "${file}" | sed ...
...
(since it always does a ${dir}/${file} as
DJ Lucas wrote:
> On 05/16/2011 12:59 AM, Bryan Kadzban wrote:
>> DJ Lucas wrote:
>>>
>> I see some traffic on linux-hotplug about this as well, so it looks like
>> it's not LFS-specific, at least. (Arch and Debian have both had bugs
>> reported about
Bryan Kadzban wrote:
> DJ Lucas wrote:
>> * the path for the setclock script in 55-lfs.rules needs to be
>> changed
>
> So... yeah.
>
> Why was this whole tree moved in the LSB scripts, again? :-)
>
> I really really hate systems where I can't re
Bruce Dubbs wrote:
> DJ Lucas wrote:
>
>> Might have to configure multiple services on one interface, for
>> instance ip and ipx, or maybe one interface does not provide default
>> gw, but a static route is still needed for a dual homed machine.
>
> ipx? Does anyone still use that?
I use multip
DJ Lucas wrote:
> There are a couple of packages, non-obvious packages at that, that
> install their own bootscripts and they work in the current proposal
> without modifications using the lsb functions.
I must not install them, then. Alternately, I do install them, but
don't care to use their bo
Matthew Burgess wrote:
> Hi all,
>
> The following is taken from my build logs when using Glibc-2.13:
>
> checking cpuid.h usability... no
> checking cpuid.h presence... yes
> configure: WARNING: cpuid.h: present but cannot be compiled
> configure: WARNING: cpuid.h: check for missing prerequi
Bruce Dubbs wrote:
> Another solution may be to do:
>
>cd /dev
>ln -sv root
>
> before running a program that needs grub-probe.
Ew! :-)
/dev/root is *never* a real device, and anything that requires it to be
is broken by design. There were several long arguments about this on
linux-h
Bruce Dubbs wrote:
> Does anyone think we need to revert back to the partial build? The
> only real issue is whether we want to build these modules statically.
> I think we can leave things as they are and revert if someone reports
> a problem.
It *may* make sense to run a diff test (IIRC: build
Zachary Kotlarek wrote:
> I haven't ever found a use for a DHCPv6 client,
Dynamic DNS: having the DHCP server update the DNS server with A, ,
PTR, and (well, uh... more PTR) records for each client that registers
with it (and which sends a hostname in the request, of course, but AFAIK
this is
Bruce Dubbs wrote:
> Nathan Coulson wrote:
>
>>> Alternatively we could use something like:
>>>
>>> #TYPE:IP:PREFIX:MASK:GATEWAY:BOOT
>>> eth0=static:192.168.1.1:24:192.168.1.255:192.168.1.1:onboot
>> that, is beautiful.
>
> I'm not sure about that. :)
Adding extra fields for each new service
Zachary Kotlarek wrote:
> On Jul 7, 2011, at 10:05 PM, Bryan Kadzban wrote:
>> I dislike having the DHCP client update DNS on its own, because (a)
>> that requires some sort of authentication to do correctly (rather
>> than just a shared key between the DHCP and DNS servers
Bruce Dubbs wrote:
> 5. Updated udev_retry to handle the /run directory for events that
> occur between starting udevd and mounting / read/write.
Good, it's using the same thing the rule_generator.functions file is
using (see choose_rules_file): "udevadm info --run".
Though it looks a little stra
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> It actually probably makes sense to pull this out into its own
>> change? We'll need it with newer udev versions no matter what
>> happens to the rest (and maybe current udev versions; I'm not
>> sure). Up to you th
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Commit the udev_retry update as a separate revision in svn. It's
>> pretty independent of the other changes being proposed. Maybe that
>> was the plan already though.
>
> I wasn't planning that, but I suppose I co
William Immendorf wrote:
> We should start with only using one configuration file per interface,
Strong disagreement from me on this one.
I *really, really* do not want to give up wake-on-LAN. That requires
two config files per interface, because it requires two services per
interface. (One for
Matthew Burgess wrote:
> But that raises the question of what that bootscript was trying to do
> in the first place? So, it turns out that the actions specified by
> 'RUN+=' udev rules can fail for any of a variety of reasons, and this
> script was simply there to retry such failed actions in the h
Matthew Burgess wrote:
> On 05/08/2011 19:55, Bruce Dubbs wrote:
>
>> The first script to run is mountvirtfs. Perhaps we could have that
>> create a /dev device like /dev/sda? and mount that as /var before udev
>> ever starts.
>
> Yeah, I started thinking along the same lines, and was wondering
Bruce Dubbs wrote:
> Doing some debugging, I'm making some progress. I made some debug
> printouts and in the first case got:
>
>required_pkgconfig_version 999.999
>
> but in the second
>
>required_pkgconfig_version a=b
>
> (which for some reason returns a positive number for
> compar
(Splitting this off as well.)
DJ Lucas wrote:
> On 09/05/2011 07:48 PM, Bruce Dubbs wrote:
>> DJ Lucas wrote:
>>> There is no reason to redefine 35+ values every time a new script
>>> is run. Once per runlevel change in rc is sufficient. One
>>> conditional around the source line in each script, o
Bruce Dubbs wrote:
> Matthew Burgess wrote:
>> 1) Setting the kernel time from the rtc
>>
>> I'm in vehement agreement with Kay here; the rtc *cannot* be
>> trusted to provide an accurate time,
It doesn't have to; it just has to be within a few minutes, so that ntpd
doesn't refuse to start.
(Sin
Jeremy Huntwork wrote:
> On Sep 13, 2011, at 1:02 PM, Bruce Dubbs wrote:
>> ntpd -q doesn't daemonize. It just hangs. That's why I have
>> modified my boot script to:
>
> -g is still a useful flag to have. My bootscripts (and Fedora's) use
> -g on startup for ntpd. It allows the first time cor
Bruce Dubbs wrote:
> So it looks like for us it should be /run/udev/tmp-rules--*, but we
> could copy that to /run/udev/rules.d/ for a temporary location or to
> /etc/udev/rules.d/ for a permanent location.
>
> I'd like to use /run/udev/rules.d/ because the less we write to /etc,
> the better.
Jeremy Huntwork wrote:
> On Sep 13, 2011, at 10:37 PM, Bryan Kadzban wrote:
>> Yes, but I think there's another way to accomplish this, without
>> the long delay inherent in using -q. If we can sync from the
>> hardware clock at boot time, then the user only has to m
Nathan Coulson wrote:
> Another thought (one I have not actually tested, forgive me if It's
> not possible) is trigger only block devices in the first pass, then
> try devices/subsystems on the 2nd pass?
DJ Lucas wrote:
> Can we not simply re-trigger all known affected subsystems with a
> subsys
DJ Lucas wrote:
>
> Bryan Kadzban wrote:
>
>> Although, hmm. Either way here, there's a possible problem, with
>> symlinks for disk devices. If the USB ID file isn't present, then
>> it's possible that the /etc/fstab entry for /usr refers to a
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> Or sysconfig, or wherever similar scripts are put in Bruce's new setup.
>
> Just to mention the layout, what I have is:
>
> /lib/services (network service scripts)
> /lib/lsb(symlink to /lib/services/, ini
Andrew Benton wrote:
> On Thu, 15 Sep 2011 21:46:08 +0100 Matthew Burgess
> wrote:
>
>> So, based on the above, 5 is definitely something to look into I
>> think. If that doesn't pan out, then I think option 2 is the next
>> 'least worst'.
>
> Or you could set the time with a bootscript.
Only i
Andrew Benton wrote:
> On Wed, 21 Sep 2011 17:53:52 -0500
> Bruce Dubbs wrote:
>
>> Upon review of udev due to a question on -support, we are creating some
>> directories that I don't know are still required.
>>
>> install -dv /lib/{firmware,udev/devices/pts}
>>
>> I think we still need /lib/ude
angeLog (working copy)
@@ -1,4 +1,10 @@
-2100-09-18
+2011-10-04 Bryan Kadzban
+ * Add configuration for udev_retry, to eventually remove --type=failed
+ (which does not work with recent udev versions anyway, since no events
+ can possibly trigger it). Start with just the "rtc&q
Bruce Dubbs wrote:
> Matthew Burgess wrote:
>> On Tue, 04 Oct 2011 21:45:13 -0700, Bryan Kadzban
>> wrote:
>>> Longer term, we can remove the --type=failed invocation entirely,
>>> although maybe that's better done as part of this change?
>>
>
Bruce Dubbs wrote:
> One minor thing to consider that I didn't change: If we change the
> config file to use a variable, then the configuration could be
> optionally placed in the rc.site file. For example:
Hmm.
That would make it easier for admins to find one file with all settings
in it. O
Bruce Dubbs wrote:
> I ran into a new problem today with the /run directory. As we create it
> right now, the permissions are 755. I was trying to run stunnel today
> and it wanted to write the stunnel.pid file after the program dropped
> root and was working as the stunnel user. It then fail
(Sorry, been not-looking-at-this-stuff for a while...)
Dan Nicholson wrote:
> I tried looking through current popt for a fix, but it's diverged
> quite a bit. Can you make this a real patch with description?
If you don't want to merge a newer upstream version (sounds like no?),
then sure, I can t
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> (Sorry, been not-looking-at-this-stuff for a while...)
>>
>> Dan Nicholson wrote:
>>> I tried looking through current popt for a fix, but it's diverged
>>> quite a bit. Can you make this a real patch with
Bruce Dubbs wrote:
> Andrew Benton wrote:
>> On Sat, 12 Nov 2011 19:39:04 -0600 Bruce Dubbs
>> wrote:
>>
>>> Ugh. Is there a mailing list for udev so I can ask about
>>> tarballs? Google doesn't seem to help.
>>>
>> I've made a tarball
>>
>> http://www.linuxfromscratch.org/~andy/udev-175.tar.x
Sorry, this won't thread properly -- but I deleted the original before I
realized I wanted to reply, so now I have to copy from the archives, and
the archives don't have the right message-ids. :-/
Matthew Burgess wrote:
> On Wed, 2011-12-28 at 15:01 +0100, Pierre Labastie wrote:
>
> > I meant `c
On Thu, Dec 29, 2011 at 04:43:30PM -0600, Bruce Dubbs wrote:
> Ken Moffat wrote:
> > On Thu, Dec 29, 2011 at 03:56:39PM -0600, Bruce Dubbs wrote:
> >> I think that idea is fine, but wonder about the use of awk. It may not
> >> be available. Perhaps:
> >>
> >> ldd /bin/ls | grep '/libc.*so'
> >>
On Tue, Jan 03, 2012 at 05:36:18PM -0500, Baho Utot wrote:
> On 01/03/2012 03:44 PM, Ren? GARCIA wrote:
> > Hi,
> >
> > I am using LFS 7.0 with LVM2/ext4 for all partitions excepted /boot
> > which is a primary partition using ext4.
> > I haven't followed
Baho Utot wrote:
> I am not looking for something too complicated, All I need is to be
> able to boot into lvm with minimal trouble.
Sounds like either way might work? dracut will require work on the
bootscripts, while my setup won't, however...
> Will your system work with LFS7.0 or just 6.8?
Following up since we took debugging off-list...
The root issue here was that the kernel didn't have initramfs support
enabled. So even when grub loaded the initrafms image, the kernel
didn't try to use it.
signature.asc
Description: OpenPGP digital signature
--
http://linuxfromscratch.org/ma
[Replying to a whole bunch of messages here...]
Nathan Coulson wrote:
> /usr on a seperate partition: In the past when I was more involved
> in the bootscripts, I setup my system to ensure this feature worked
> for the sole reason that it is part of the standard. I felt that if
> there was n
Matt Burgess wrote:
> This passes a boot test with no changes required to the bootscripts
> or fstab. Maybe I'm misunderstanding Bruce's and Bryan's comments in
> the ticket, but this to me suggests that Udev >= 176 doesn't require
> a devtmpfs mounted on /dev
That's very strange, given this comm
Matt Burgess wrote:
> The second issue is this, inflicted on us from upstream since version
> 174:
>
> "The rules to create persistent network interface and cdrom link
> rules automatically in /etc/udev/rules.d/ have been disabled by
> default. Explicit configuration will be required for these
Bruce Dubbs wrote:
> I'll note here that on my system Ubuntu's initramfs is 7.5M. My largest
> LFS kernel is 3.9M.
Ouch.
The initramfs images that I have built are actually 9 megs (28 megs
uncompressed). But that's because I include all kernel modules and all
firmware on the host, which pulls
Matt Burgess wrote:
> What I actually did was to include DEVTMPFS_MOUNT
...
Oh, *that* option! Heh. I had forgotten it existed. :-)
> As a possibly interesting aside, even though the DEVTMPFS_MOUNT
> seemingly does the right thing here, it does not cause /dev to be
> listed by either 'df' o
Reading through the patch:
Matt Burgess wrote:
> And here's the latest version that I've just kicked off a build for.
> This one even has the kmod.xml file in it that the last version
> didn't. It applies on top of Bruce's fstab and bootscript changes in
> r9710.
> + remap="configure">BLKID_CF
Bruce Dubbs wrote:
> About Filesystems, LVM, and RAID
>
>
> Filesystems
>
> Compare Ext2/3/4, Reiser4, JFS, XFS (Add jfsutils to the book)
>
> Mention FAT/NTFS, BTRFS, ISO9660, and UDF
>
> LVM
> fdisk type 8e
Note that this is absolutely not required. I'm using part
Steve Crosby wrote:
> On Mon, Jan 23, 2012 at 7:58 PM, Zachary Kotlarek
> wrote:
>> On Jan 22, 2012, at 7:33 PM, Steve Crosby wrote:
>>
>>> 3. Populate /dev using busybox cutdown version of udev (mdev)
>>
>> Is there a benefit to mdev over just using tmpdevfs?
>>
>> I say that as a current user
Zachary Kotlarek wrote:
> On Jan 23, 2012, at 7:56 PM, Bryan Kadzban wrote:
>
>> UGH. FWIW I really don't like this "feature".
>>
>> It causes the booted-with-initramfs case to require different
>> handling from the booted-without-initramfs ca
Zachary Kotlarek wrote:
> On Jan 24, 2012, at 7:49 PM, Bryan Kadzban wrote:
>
>>> Why? Can't you mount the devtmpfs both with and without the
>>> initramfs?
>> Not if it's already mounted, unless you want to undo the
>> modifications that udev has ma
Zachary Kotlarek wrote:
> On Jan 25, 2012, at 10:23 AM, Bruce Dubbs wrote:
>
>> I'm sure that systemd solves a problem for 1% of users, but for
>> 99%, it's not needed. I recently installed Fedora 16 on a virtual
>> system with exactly one partition. The listing below is what I
>> got for a sim
Bruce Dubbs wrote:
> Sigh.
>
> http://www.phoronix.com/scan.php?page=news_item&px=MTA0OTY
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
I like the reply (on the freedesktop page) to myth #2.
> Myth #2: Fedora is the only Linux distribution to implement the /usr
> mer
Bruce Dubbs wrote:
> The section 7.2.1. Creating stable names for network interfaces
> failed.
Argh. Again.
> Running manually gives:
>
> <...>
>
> This program is for debugging only, it does not run any program,
> specified by a RUN key. <...>
I wonder if they finally made this true. This
Andrew Benton wrote:
> But according to that bugzilla page, the bug was fixed weeks ago? The
> 'fix' is definitely in the glibc source so it would appear that it's
> not working.
I assume that by this you mean you've verified that the right-hand side
of this diff is present in your git tree?
http
Andrew Benton wrote:
> On Fri, 03 Feb 2012 21:44:34 -0800 Bryan Kadzban
> wrote:
>
>> Do you get __USE_ISOC11 #define'd (to what value?) or #undef'ed?
>> What about __cplusplus (again, what value)?
>>
>
> andy@eccles:/mnt/lfs/sources$ /tools/bin/x86_6
Andrew Benton wrote:
> On Sat, 04 Feb 2012 09:49:37 -0800 Bryan Kadzban
> wrote:
>
>> Andrew Benton wrote:
>>> On Fri, 03 Feb 2012 21:44:34 -0800 Bryan Kadzban
>>> wrote:
>>>
>>>> Do you get __USE_ISOC11 #define'd (to what value?) o
Ken Moffat wrote:
> I don't have kmod source handy, so I can't tell if it will take an
> overide in the same way.
Both kmod and xz needed a "pkgconfigdir=/usr/lib/pkgconfig" override on
the "make install" command line for me, when I built both recently. I
also passed udev a "sharepkgconfigdir=/u
Bruce Dubbs wrote:
> I used the following instructions:
>
> liblzma_CFLAGS="-I/usr/include" \
> liblzma_LIBS="-L/lib -llzma"\
> zlib_CFLAGS="-I/usr/include"\
> zlib_LIBS="-L/lib -lz" \
> ./configure --prefix=/usr --bindir=/sbin --libdir=/lib \
> --sysconfdir=/etc
Ken Moffat wrote:
> On Sat, Feb 04, 2012 at 03:22:53PM -0800, Bryan Kadzban wrote:
>> I
>> also passed udev a "sharepkgconfigdir=/usr/lib/pkgconfig" override,
>> otherwise it dumped udev.pc into /usr/share/pkgconfig, where nothing
>> ever looks -- or at least
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Ken Moffat wrote:
>>> I don't have kmod source handy, so I can't tell if it will take an
>>> overide in the same way.
>> Both kmod and xz needed a "pkgconfigdir=/usr/lib/pkgconfig" override on
&g
Andrew Benton wrote:
> To save spamming the list I've put that up here:
> http://www.linuxfromscratch.org/~andy/dump-1.txt
Looks like Uli broke it again:
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=c3a87236702cb73be1dada3438bbd3c3934e83f8
If you remove that "&& defined __USE_GNU" off
Matthew Burgess wrote:
> On Mon, 06 Feb 2012 11:00:31 -0500, Jeremy Huntwork
> wrote:
>> Was just reviewing your kmod build instructions - haven't built it yet
>> myself, but it's noticeably missing lsmod - shouldn't this be another
>> symlink to kmod?
>
> Yup, if you look closely you'll notice
Qrux wrote:
> For 7.2 & beyond...
>
> Bridge-utils is not dissimilar from udev, in that it's a userspace
> tool for a kernel. And, it's certainly no less optional than
> inettools.
I disagree -- assuming by "inettools" you mean "inetutils", because the
former is not in LFS.
hostname is requir
Jeremy Huntwork wrote:
> 5. Since we don't support multilib, remove all toolchain uses of
> lib64. No need for those symlinks any more. Everything goes to lib.
I don't think this is a good idea.
The 64-bit x86 SysV ABI *REQUIRES* /lib64/ld-linux-x86-64.so.2 to be the
runtime linker path. (This
Andrew Benton wrote:
> On Mon, 27 Feb 2012 20:10:28 -0800 Bryan Kadzban
> wrote:
>>
>> Specifically, section 5.2.1.
>
> In practice it works fine and causes no problems. I have everything
> in /lib with no lib64 symlinks. It makes a simpler and more
> straightfor
Qrux wrote:
> I would add 3rd party hardware drivers and control programs that
> might be dynamically linked
Oh. Right. Duh.
nvidia-settings, and probably nvidia-installer, are precompiled 64-bit
binaries that still need to work for people that use the nvidia drivers.
:-)
signature.asc
Desc
Jeremy Huntwork wrote:
> On 3/8/12 4:24 PM, Bruce Dubbs wrote:
>> Jeremy Huntwork wrote:
>>> On 3/2/12 11:10 AM, Bruce Dubbs wrote:
Yes, I saw that. Reviewing.
>>> How is that coming along?
>> Not well, sorry. I've got some personal things going on right now
>> and can't get to it. I'll loo
101 - 200 of 666 matches
Mail list logo
