Sebastian Plotz wrote:
> Am 15.04.2014 05:37, schrieb Bryan Kadzban:
>> Also, does it work to match NICs by device path instead of MAC
>> address,
>
> Yes. Have a look at "|Path=pci-:02:00.0-*":|
Huh. OK, that's unexpected. :-)
However, while this:
Bruce Dubbs wrote:
> Bruce Dubbs wrote:
>> Sebastian Plotz wrote:
>>> This assignes the name eth0 to the interface with the MAC address
>>> 12:34:56:78:9a:bc. The file name is important: if there would be a
>>> second file (for example 10-eth1.link) with "Name=eth1"instead of
>>> "Name=eth0" the
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> However, if someone (like me...) *really really* doesn't want systemd,
>> and knows it from the get-go, shouldn't they avoid building all the other
>> junk like libacl / libattr / expat / *dbus* / etc., too? The curre
Bruce Dubbs wrote:
> I did have a private email with a volunteer to write a hint. If I get
> that, I'll add a note in the systemd section that points there.
I saw a commit mail to -book that added the hint link.
However, if someone (like me...) *really really* doesn't want systemd, and
knows it
Ken Moffat wrote:
> When I woke up in the
> morning, I was surprised to find that my OpenJDK script was still running
> rm -rf for the source directory, and had been doing so for more than 5
> hours (both wall-clock time and CPU time), and was now at 99%-100% of one
> CPU, according to top.
...Odd
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> After a fairly extensive discussion, I've update the host system
>> requirements page in svn:
>>
>> http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html
>
> Looks reasonable to me, unl
Bruce Dubbs wrote:
> After a fairly extensive discussion, I've update the host system
> requirements page in svn:
>
> http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html
Looks reasonable to me, unless we want to take lib64 / lib32 into account,
rather than just lib. I'd
Armin K. wrote:
> No matter what you say, if a package A installs a file X.Y that requires
> file Z.Y and package A doesn't either:
>
> a) pull automatically the package (depend on) that contains file Z.Y
> b)ships that file itself
>
> the packaging is broken.
Then BLFS's and LFS's "packaging"
Bruce Dubbs wrote:
> Ken Moffat wrote:
>> On Fri, Feb 07, 2014 at 03:06:52PM -0600, Bruce Dubbs wrote:
>>> BTW, without the above, we do have /usr/lib/libncurses.a. Shouldn't
>>> shouldn't that be picked up?
>
>> You should know me by now - disable static libs when I can, and hide the
>> rest of
Armin K. wrote:
> On 01/19/2014 12:45 AM, Bruce Dubbs wrote:
>> Armin K. wrote:
>>
I'm glad you reminded me of that. I suppose I could avoid a lot of
changes if we made the symlinks, including one for
/usr/include/{blkid,uuid}/. I'll keep investigating.
>>> You don't really
On Sat, Dec 21, 2013 at 06:32:11PM -0600, Bruce Dubbs wrote:
> Bryan Kadzban wrote:
> > On Sat, Dec 21, 2013 at 03:17:31PM -0600, Bruce Dubbs wrote:
> >> Ken Moffat wrote:
> >>> On Sat, Dec 21, 2013 at 10:11:06AM -0800, Bryan Kadzban wrote:
> >>>> On S
(Headers on this one might be weird because the ssh session died, so I
had to go through weirdness to recover the email...)
On Sat, Dec 21, 2013 at 07:59:37PM +0100, Armin K. wrote:
> On 12/21/2013 07:16 PM, Bryan Kadzban wrote:
> > On Sat, Dec 21, 2013 at 04:33:42PM +0100, Armin
On Sat, Dec 21, 2013 at 03:17:31PM -0600, Bruce Dubbs wrote:
> Ken Moffat wrote:
> > On Sat, Dec 21, 2013 at 10:11:06AM -0800, Bryan Kadzban wrote:
> >> On Sat, Dec 21, 2013 at 05:56:37PM +0100, Armin K. wrote:
> >>> This also might be relate
On Sat, Dec 21, 2013 at 04:33:42PM +0100, Armin K. wrote:
> devpts should also be bind-mounted, as it will override default devpts
> flags and permissions which were mounted before.
>
> In my case:
>
> mount output before mounting devpts at $LFS/dev/pts
>
> devpts on /dev/pts type devpts (rw,nos
On Sat, Dec 21, 2013 at 05:56:37PM +0100, Armin K. wrote:
> On 12/21/2013 04:26 PM, Armin K. wrote:
> > In latest lfs book, the "Preparing Virtual File Systems" page contains:
> >
> > 6.2.1. Creating Initial Device Nodes
> >
> > When the kernel boots the system, it requires the presence of a few
John Burrell wrote:
>> ...Also, it is *not* possible to replace either /lib/ld-linux.so.2 or
>> /lib64/ld-linux-x86-64.so.2 (...and yes, I use those paths intentionally,
>> since those are the ABI standard) on a running system unless you replace
>> both it and /lib{,64}/libc.so.6 from the same pr
William Harrington wrote:
> On Dec 16, 2013, at 5:17 PM, John Burrell wrote:
>
>> When I try and update the dynamic linker, /usr/lib/ld-2.18.so in my case,
>>
>>
>> I get the message 'Text file busy'
>>
>> and when I then access the chroot window I get a seg fault.
>
> You aren't clear,
>
> /
William Harrington wrote:
>
> On Aug 21, 2013, at 21:49, Bryan Kadzban
> wrote:
>
>> So if the host is running 2.6.28 or something, then entering the
>> chroot probably isn't going to work when chapter 5's libc was built
>> with --enable-kernel=2.6.34.
&g
Matthew Burgess wrote:
> On Wed, 21 Aug 2013 21:20:43 +0800, JC Chong
> wrote:
>> Another thing, the HSR lists a minimum running 2.6.25 kernel, but
>> building glibc 2.18 needs --enable-kernel=2.6.34. A long time ago,
>> during the LFS 5.1 days, I tried --enable-kernel=2.6.0 with a
>> running 2.
Bruce Dubbs wrote:
> Ken Moffat wrote:
>> I'm about to do an almost [1] "by the book" build (-j1, keep static
>> libs until the end of chapter 6 which should at least make more of
>> the ld tests pass) so I rebuild my kernel to add
>> CONFIG_SCSI_DEBUG=y. Disaster : /dev/sda showed up with no
>> p
Ragnar Thomsen wrote:
> In glibc 2.18, the pt_chown binary no longer gets installed by
> default due to security reasons. This resulted for me in konsole not
> working. I tracked the issue down to the missing pt_chown binary.
You shouldn't need pt_chown; devpts just needs to be mounted correctly.
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> ...Wait, this might be the issue. chapter06/kernfs.html says:
>>
>> mount -vt devpts devpts $LFS/dev/pts
>>
>> but my fstab has:
>>
>> devpts /dev/pts devpts gid=4,mode=620 0 0
>>
>> The
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> But maybe something else changed. What happens if you:
>
>> ls /dev/pts
>>
>> ./testpts
>
> At this point as user nobody (in chroot), I get:
>
> nobody:/tmp$ ./testpt
> posix_openpt succeeded
>
Bruce Dubbs wrote:
> Bruce Dubbs wrote:
>> script: race conditions...script: openpty
>> failed: Operation not permitted
>> <...>
>>
>> It looks like this is due to the change in glibc because this passed
>> before I update to glibc-2.18.
>
> OK, I've confirmed that the test
On Mon, Aug 05, 2013 at 06:16:53AM -0600, Matthew Burgess wrote:
> On Sat, 03 Aug 2013 18:07:43 -0500, Bruce Dubbs wrote:
>
> > With that in mind, I would like to freeze LFS (mostly) on August 15 and
> > release LFS-7.4-rc1. The target date for LFS-7.4 will be 1 September.
> > During the freeze
Bruce Dubbs wrote:
> I just noticed that we do not create /usr/local/lib64. Should be make
> /usr/local/lib64 a symlink to /usr/local/lib the way we have:
>
> ln -sv lib /lib64
> ln -sv lib /usr/lib64
>
> What I found was that some programs (e.g. gcc) will create a separate
> /usr/local/lib64
bt wrote:
> 3. Also from the Arch Wiki, regarding when an initramfs is not being
> used. Most of the points are in the LFS book or Bruce's hint, but I
> couldn't find mention of support for AUTOFS4_FS or TMPFS (different
> from DEVTMPFS_MOUNT, which is mentioned). Should these be mentioned?
Hm
Randy McMurchy wrote:
> I
> am not sure if they need to be modified because we move the libraries to
> /lib and the libdir in the .pc files points to /usr/lib, but I think it
> would be alright as any package wanting to link with ncurses libs will
> use the .so files that do exist in /usr/lib.
The
xinglp wrote:
> 2013/1/10 Bruce Dubbs :
>> Bruce Dubbs wrote:
>>> xinglp wrote:
2013/1/10 Bruce Dubbs :
> xinglp wrote:
>> If so, the script init-net-rules.sh in udev-lfs-197-1 also need some
>> change.
>>
>> DEVICES=$(eval echo /sys/class/net/{eth*,ath*,wlan*[0-9], ...
>>>
Bruce Dubbs wrote:
> Matt Burgess wrote:
>
>> Obviously, this is all pretty academic for me; if I'd have been
>> using or otherwise needing the by-path symlinks, I would have
>> noticed their disappearance in udev-182. The only reason I noticed
>> they were missing now is because of xinglp's repo
Matt Burgess wrote:
> On Wed, 2012-11-28 at 20:44 -0800, Bryan Kadzban wrote:
>
>> it's a SATA drive. I'm pretty sure all of those show up as SCSI.
>
> That's what I thought as well, hence the sd* name, rather than hd*.
>
>> What does a udevadm i
Bruce Dubbs wrote:
> Matt Burgess wrote:
>> On Wed, 2012-11-28 at 14:12 -0600, Bruce Dubbs wrote:
>>
>>> Checking against a slightly older build with udev 182, I only
>>> have two entries in /dev/disk/by-path, /dev/hda (CD-ROM) and
>>> /dev/sdc (which appears to be a leftover usb entry).
>> Ah, no
Matt Burgess wrote:
> On Tue, 2012-11-27 at 18:42 +, Matt Burgess wrote:
>> On Tue, 2012-11-27 at 18:13 +0800, xinglp wrote:
>>> The Udev-196 only create "/dev/disk/by-path".
>> Confirmed. I'll take a look.
>
> Well, 2 hours later and I'm stumped. I've run 'udevadm --debug test
> /sys/block/
On Wed, Nov 21, 2012 at 11:21:21AM -0600, Bruce Dubbs wrote:
> I've been testing udev from systemd-196. I have been able to build and
> install it with some changes to the LFS Makefile. One new capability is
> that it has it's own hw database instead of lspci and lsusb.
>
> The raw db files go
Bruce Dubbs wrote:
> This is a continuation of the thread Boot and shutdown timing.
>
> Bryan Kadzban wrote:
>
> > If you use /dev/sd??, then I wish you the best of luck the next time
> > the kernel's disk discovery order changes. Because it's not
> &g
(Hooray life. Got busy the last couple of days. Getting back to these
threads now...)
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> The only thing that matters is the order that calls to sd_probe
>> (assuming SCSI or SATA) occur in, since that's what assigns the
>&
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> What's rather more likely is an eventual change to probe disks in
>> parallel across controllers, at which point everything will look
>> like USB in terms of ordering guarantees. (In particular, there
>> are no
ged
in across a boot could still break it. I'd rather use something that's
guaranteed; one of labels, UUIDs, device IDs, or device paths.
Also, from earlier:
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> I will also note that using /dev/disk/by-id/ links allowed me to
>&g
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Armin K. wrote:
>>> On 05.10.2012 20:58, Bruce Dubbs wrote:
>>>> I've been looking at the boot and shutdown timing of our boot scripts.
>>>>
>>>> For boot, it seems that most of the time is ta
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Bruce Dubbs wrote:
>>> Bryan Kadzban wrote:
>>>> Bruce Dubbs wrote:
>>>>> Seriously, I don't believe in multiboot. If I can't build a
>>>>> 64-bit version of a package, then I don&
Armin K. wrote:
> On 05.10.2012 20:58, Bruce Dubbs wrote:
>> I've been looking at the boot and shutdown timing of our boot scripts.
>>
>> For boot, it seems that most of the time is taken with 'udevadm settle'.
>>When I instrumented the scripts, over half the boot time was waiting
>> for settle
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Bruce Dubbs wrote:
>>> Seriously, I don't believe in multiboot. If I can't build a
>>> 64-bit version of a package, then I don't need it. I should be
>>> able to put libraries in the directories I wan
Bruce Dubbs wrote:
> Seriously, I don't believe in multiboot. If I can't build a 64-bit
> version of a package, then I don't need it. I should be able to put
> libraries in the directories I want.
Well, you are, of course, but this appears to be nothing more than
fallout from violating the assu
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>>> We can add that to Section 6.64 - Stripping Again. What I've
>>> found is that I get a lot of warning messages and sometimes
>>> failures when packages try to use the .la files, but just
>>> remov
Ragnar Thomsen wrote:
> On Wednesday 03 October 2012 21:12:06 Armin K. wrote:
>> So the answer is, just add pam_systemd to system-session.
>
> I'm afraid this doesn't work. There is still no logind session
> started when I run startx.
>
> Running loginctl only lists the console session, but no X1
Bruce Dubbs wrote:
> I am wondering about making a change to LFS to combine some of the root
> directories and /usr. Looking at the sizes on a fairly complete system:
>
> 22M /lib
> 4.9M/bin
> 7.6M/sbin
> 1.4G/usr/lib
> 300M/usr/bin
> 15M /usr/sbin
>
> It seems like the
[Whee, I didn't see this yesterday. Stupid mail server. :-)]
Bruce Dubbs wrote:
> The sysfs filesystem was mentioned briefly above. One may wonder how
> sysfs knows about the devices present on a system and what device
> numbers should be used for them. Drivers that have been compiled into
> t
Ken Moffat wrote:
> (changing the subject)
>
> On Tue, Oct 02, 2012 at 06:32:14PM +0100, Ken Moffat wrote:
>> I see that Bryan has a 'fork' of standalone udev (I guess that just
>> means his own branch), and at least one of his commits has gone
>> into standalone.
Yeah, my own branch. (Side note
Drew Ames wrote:
> On 09/05/2012 11:06 PM, Bryan Kadzban wrote:
>> Drew Ames wrote:
>>> It seems that the simplest solution would be to build coreutils-8.15
>>> or some other version prior to 8.18. Run configure and make, then
>>> copy the uninstalled v
Drew Ames wrote:
> It seems that the simplest solution would be to build coreutils-8.15
> or some other version prior to 8.18. Run configure and make, then
> copy the uninstalled version to /tools/bin/su: 'cp src/su
> /tools/bin'
>
> Until somebody can figure out why the shadow su is behaving
> d
John Burrell wrote:
> coreutils no longer installs su.
As others said, LFS now uses su from shadow. However, this doesn't help
you, because there is no chapter-5 shadow installation, and adding its
dependencies might be problematic.
What *may* help you is a return to the package-user hint as it
Jasmine Iwanek wrote:
> On 2012-08-27 03:30, Bruce Dubbs wrote:
>> Starting a new thread.
>>
>>
>> I'm starting to think that the problem is that we've built Chapter
>> 6 glibc in 7.2 without the --enable-obsolete-rpc which would
>> probably solve the problem there. For a 7.1 host, we'd need a n
Bruce Dubbs wrote:
> Try this as the lfs user:
>
> tar -xf glibc-2.16.0.tar.xz
> cd glibc-2.16.0
>
> sed -i 's/ -lgcc_s//' Makeconfig
> sed -i 's||"rpc/types.h"|' sunrpc/rpc_clntout.c
>
> mkdir -v ../glibc-build
> cd ../glibc-build
>
> echo BUILD_CC=${LFS_TGT}-gcc > configparms
Uh, isn't that
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Are the sources for this tarball in a source control repository
>> somewhere? I might have missed where, in the discussion earlier
>> when it was being created. I don't see them in the book repository,
>> but that repo
Bruce Dubbs wrote:
> What I'm using right now is:
>
> # Ignore Xen virtual interfaces
> if [ -e /proc/xen ]; then
>msg="The rules file should not be created in the Xen environment"
>usage
> fi
>
> I'm not sure if that is right or not. Someone with Xen needs to verify.
Hmm, I don't know
Bruce Dubbs wrote:
> I'm trying to write a script to be run in Section 7.2 to initialize
> 70-persistent-net.rules. I'm using, as a base, the udev-182 rule
> 75-persistent-net-generator.rules.
>
> I have a problem in that this rule uses a variable SUBSYSTEMS.
Uh oh, that's one thing I was afra
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Bruce Dubbs wrote:
>>> Armin K. wrote:
>>>> Bruce, some guy came on the irc saying that network rules creation
>>>> does not work in systemd extracted udev.
>>>>
>>>> working my way thr
Bruce Dubbs wrote:
> Armin K. wrote:
>> Bruce, some guy came on the irc saying that network rules creation
>> does not work in systemd extracted udev.
>>
>> working my way through the cvs book and get to 7.2.1.
>> Creating stable names for network interfaces and I am getting a
>> cat: /etc/udev/r
Bruce Dubbs wrote:
> LIBUDEV_MAJOR = .1
> LIBUDEV_MINOR = .0
> LIBUDEV_PATCH = .2
Note that (if upstream does this correctly) these will change with every
change to libudev. Not sure if there's some way to pull the values from
their Makefile.am (probably not terribly easy), or otherwis
Ken Moffat wrote:
> On Sat, Jul 14, 2012 at 01:37:30PM -0700, Bryan Kadzban wrote:
>> We disable keymap in -182, and have for (IIRC) a long time. It's
>> probably therefore better to keep the current state of things as
>> they are, and continue to not enable it.
>>
Haven't had a chance to try this yet, but:
Armin K. wrote:
> I've taken some time and wrote rules to build udev's keymap feature.
We disable keymap in -182, and have for (IIRC) a long time. It's
probably therefore better to keep the current state of things as they
are, and continue to not enable
Matt Burgess wrote:
> On Sun, 2012-07-01 at 18:20 +0100, Andrew Benton wrote:
>> Fixed by this sed in the gcc source before the first pass of gcc:
>>
>> sed -i '/k prot/agcc_cv_libc_provides_ssp=yes' gcc/configure
>
> I don't mind displaying my lack of autofoo knowledge in public, so why
> is pass
Fun fun fun. :-)
Andrew Benton wrote:
> Then an error due to a problem with gcc:
>
> /mnt/lfs/sources/glibc-build/resolv/libresolv_pic.a(gethnamaddr.os): In
> function `getanswer':
> /mnt/lfs/sources/glibc-2.16.0/resolv/gethnamaddr.c:180: undefined reference
> to `__stack_chk_guard'
> /mnt/lfs
Ken Moffat wrote:
> On Sat, Jun 16, 2012 at 05:00:08PM -0500, Bruce Dubbs wrote:
>> Bryan Kadzban wrote:
>>
>> I looked at the .config and I do have
>>
>> CONFIG_SYSFS_DEPRECATED=y
>> CONFIG_SYSFS_DEPRECATED_V2=y
>>
>>> (Upstream, for th
Armin K. wrote:
> On 06/17/2012 12:00 AM, Bruce Dubbs wrote:
>> Also, as with the discussion on BLFS support discussing updating
>> glibc in place, I think I will put udev in the same category as too
>> risky to update in place.
>
> Erm, why? What could go wrong?
For udev, for for glibc?
For gli
Bruce Dubbs wrote:
> Also, as with the discussion on BLFS support discussing updating
> glibc in place, I think I will put udev in the same category as too
> risky to update in place.
Maybe. As to upgrading glibc directly -- as long as you replace both
the ld-linux* symlink and the libc.so.* syml
Bruce Dubbs wrote:
> Inside chroot, I do have:
> $ ls -l /sys/class/net/eth0/
>
> device -> ../../../devices/pci:00/:00:1c.0/:02:00.0
>
> but of course I don't have lspci in chroot yet.
On kernel 3.2.3 (I need to try 3.4, but haven't yet),
/sys/class/net/eth0 itself is a symlink, int
Bruce Dubbs wrote:
> The line 'INTERFACE=eth0 udevadm test --action=add /sys/class/net/eth0'
> does not run write_net_rules. I get the following output:
>
> run_command: calling: test
> adm_test: version 182
> This program is for debugging only, it does not run any program,
> specified by a RUN
Ken Moffat wrote:
> On Thu, Jun 07, 2012 at 04:21:05PM -0500, Bruce Dubbs wrote:
>> $ ls -l /lib/udev
>> total 1528
>> -rwxr-xr-x 1 root root 196379 May 21 15:41 accelerometer
>> -rwxr-xr-x 1 root root 91401 May 21 15:41 ata_id
>> -rwxr-xr-x 1 root root 138252 May 21 15:41 cdrom_id
>> -rwxr-xr-x 1
Ken Moffat wrote:
> 2. How did you decide on that date and time ?
Um. Yeah. I looked at what "ls -l" with no special configuration was
telling me, and picked a time that was comfortably earlier than the
mtime on aclocal.m4.
This is probably completely unusable for people in other timezones; I
d
Ken Moffat wrote:
> On Tue, Jun 05, 2012 at 09:51:23PM +0100, Matt Burgess wrote:
>> Why is sedding configure not enough? I don't doubt it isn't, but
>> can't think why. My understanding is that configure.ac is used as
>> input to generate configure. Therefore, whatever Makefile rules
>> are in
Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>> On 6/4/12 8:52 PM, Bruce Dubbs wrote:
>>> "As stated earlier, the goal of LFS is to build a complete and
>>> usable foundation-level system. This includes all packages needed
>>> to replicate itself while providing a relatively minimal base
>>> from wh
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> Probably also want to double check whether any of the following are
>> still being built or checked for:
>>
>> acl (libsystemd-acl.la)
>> tcpwrap (see if configure is checking for it)
>> hostnamed
Bruce Dubbs wrote:
> I grabbed the current git version of Makefile.am and applied the patch
> with no errors. autoreconf also works without error.
>
> ./configure --disable-systemd --with-usb-ids-path=no \
> --with-pci-ids-path=no
>
> ...
>
> configure: error: Package requirements
DJ Lucas wrote:
> On 06/03/2012 02:03 PM, Bruce Dubbs wrote:
>> Bryan, I tried the patch you submitted to linux-hotplug yesterday:
>>
>> systemd-make-systemd-optional.patch
>>
>> It doesn't apply cleanly to either systemd-183 or -184.
>
> It applies with offsets to git master...which hopefully s
Ken Moffat wrote:
> On Sat, Jun 02, 2012 at 12:46:57AM +0100, Andrew Benton wrote:
>> I spent a couple of hours banging my head against the dbus
>> dependency before I gave up. It turned out it was easier to live
>> without systemd. Bryan wrote about the dbus issue earlier
>> http://linuxfromscrat
Markku Pesonen wrote:
> Bryan Kadzban wrote:
>> Might be worth a shot. (If you have a system to test it on; don't go
>> build something just for this.) OTOH that sed, or an equivalent, might
>> have already been applied to pkg-config, or maybe they pulled in
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Andrew Benton wrote:
>>> It seems to me that we should remove udev from LFS and point
>>> anyone who needs it at the systemd page in BLFS. They've shown
>>> that they're integrating udev more tightly
Andrew Benton wrote:
> It seems to me that we should remove udev from LFS and point anyone
> who needs it at the systemd page in BLFS. They've shown that they're
> integrating udev more tightly with systemd, we should move away from
> it.
Let's see what they say when I post the configure.ac / Mak
Bruce Dubbs wrote:
> Andrew Benton wrote:
>> On Fri, 01 Jun 2012 18:39:59 +0100 Bruce Dubbs
>> wrote:
>>
>>> The current version, Dan's version, and the 'lite' verion all
>>> fail the same test for me.
>> I get the same test failure with both pkg-config-0.26 and
>> pkg-config-lite-0.26-1. With b
Bruce Dubbs wrote:
> Andrew Benton wrote:
>> On Thu, 31 May 2012 16:58:00 +0100 Bruce Dubbs
>> wrote:
>>
>>> Try this diff for configure.ac.
>> It helps. I can get through configure Ok, but I can't see a way to
>> get through make without dbus.
>
> Did you try in a Chapter 6 environment? I can'
Dan Nicholson wrote:
> On Mon, May 28, 2012 at 1:00 PM, Jeremy Huntwork
> wrote:
>> On 5/28/12 2:52 PM, Bruce Dubbs wrote:
>>> The problem is that none of these libraries are used for udev. On a
>>> recent blfs system, where the systemd dependent libraries are installed,
>>> I as able to build an
Bruce Dubbs wrote:
> You are not doing this in an LFS Chapter 6 type of environment. I did
> this and immediately got:
Yeah, you're right, see my reply to Ken. No system in the proper state
to test that at the moment. :-(
> Anouther problem is that src/shared/util.c is needed to build the ude
Ken Moffat wrote:
> My first thought was "I wonder how he's disabled the tests for
> intltool and XML::Parser?". You're on a completed system.
Arg, you're right of course. (I don't have a chapter-6-level system
handy to use for testing, hence my comment earlier about missing some of
the required
Bruce Dubbs wrote:
> Perhaps it's because I invested so much work in the last couple of days,
> but I am leaning towards static linking of udevd and udevadm. At least
> the udev part.
ldd /usr/bin/Xorg
linux-vdso.so.1 => (0x7fff4455c000)
libudev.so.0 => /usr/lib64/libudev.s
Bryan Kadzban wrote:
> DBUS_CFLAGS=" " \
> DBUS_LIBS=" " \
> BLKID_CFLAGS="-I/usr/include/blkid" \
> BLKID_LIBS="-L/lib64 -lblkid" \
> KMOD_CFLAGS="-I/usr/include" \
> KMOD_LIBS="-L/lib64 -lkmod" \
> ./configure
Bryan Kadzban wrote:
> Upgrading kmod now; will see what I hit next. This might just work;
> let's see. :-)
Got it to compile all the binaries (I think) we need, by removing a
couple of totally unnecessary dependencies from libsystemd-label. :-)
Reformatting ./configure so the
Bryan Kadzban wrote:
> Bryan Kadzban wrote:
>> Let me see if I can hack anything up.
>
> Still poking.
OK (now that I'm replying to myself here :-) ), I think I have something
that's looking promising. This makes it all the way through configure,
and part of th
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> I came up with one problem that I need advice on. I can't build the
>> keymap program becasue I'm missing keys-from-name.h and
>> keys-to-name.h. The systemd configure/make command generates them
>> using gperf. I
Bruce Dubbs wrote:
> I got rid of the systemd-sysctl problem by deleting
> /lib/udev/rules.d/99-systemd.rules.
...Arrrg, forgot to reread the thread to the end. :-)
(Yeah, we'll need to pull in the write_{net,cd}_rules stuff from either
udev-182, or -- probably better since it'll be maintained
Bruce Dubbs wrote:
> /lib/udev/rules.d/99-systemd.rules:46
We probably need to delete this file. :-)
signature.asc
Description: OpenPGP digital signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information pa
Bruce Dubbs wrote:
> I came up with one problem that I need advice on. I can't build the
> keymap program becasue I'm missing keys-from-name.h and
> keys-to-name.h. The systemd configure/make command generates them
> using gperf. In udev-182, there are over 70 entries in
> src/keymap/keymaps. Th
Ken Moffat wrote:
> libudev.la has installed=no - I'm not sure exactly how it gets
> installed, but we probably need to do the same because the following
> are wrapper scripts for libtool files of the same name in .libs and
> these will definitely all need to be correctly installed :
>
> accele
Ken Moffat wrote:
> Unfortunately, mdev appears not to be a full replacement. Looking at
> the gentoo wiki - https://wiki.gentoo.org/wiki/Mdev - I see two
> breakages for desktop users, and a further problem:
>
> <...>
>
> The further problem is with additional usb devices. The gentoo wiki
> i
FWIW...
DJ Lucas wrote:
> Fortunately, that is not a deal breaker for me if the
> readers get the same treatment (which seems to be the case), but this
> does hard code optional dependencies for the pre-packaged installations.
> This is both good and bad. From a development standpoint, it won't
xinglp wrote:
> Now, It is the job of udev to start /etc/init.d/setclock .
>
> When I use initd-tools to install somethings else, it was installed
> for depended.
Is there a way in these newfangled headers to say that setclock is
really an alias for udev? That's what's happening in the scripts,
Ken Moffat wrote:
> The build system of kbd is clever enough to reconfigure itself!
> *very_weird*. BUT, the required videomodes files are missing.
For the record -- automake-generated Makefiles contain rules to rerun
the bits of autofoo that are required whenever the source files change.
So if
Pierre Labastie wrote:
> Le 18/03/2012 23:56, Bryan Kadzban a écrit :
>>> I am not sure I fully understand this story of relocation data...
>>>
>> I'd have to guess different flags sent to the linker. As for *why*
>> those flags are being sent differently
Pierre Labastie wrote:
> Now I have done it, but I do not fully understand what is going on.
> The comparison between current build and Jeremy's is done in ICA style:
> First remove all symlinks,
> Then extract archives into a directory with the same name
> Then stripping ".o" files from debug symb
Jeremy Huntwork wrote:
> On 3/16/12 3:22 AM, Bryan Kadzban wrote:
>> That being said, is editing the pass1 gcc sources with sed (editing
>> the STANDARD_STARTFILE_PREFIX_? values, and the header directories)
>> better, or worse, than reverting upstream changes in pass2? I
>
1 - 100 of 666 matches
Mail list logo
