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:
|[Match]
Driver=brcmsmac
Path=pci-:02
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=eth1instead of
Name=eth0 the interface would
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
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 current
list of packages that are only
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
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.
I
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 them ;-)
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 want to do this. If
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 Sat, Dec 21, 2013 at 05:56:37PM +0100, Armin K. wrote
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
(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 K. wrote:
devpts
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 process.
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,
/usr/lib being
Matthew Burgess wrote:
On Wed, 21 Aug 2013 21:20:43 +0800, JC Chong jayceech...@gmail.com
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
William Harrington wrote:
On Aug 21, 2013, at 21:49, Bryan Kadzban
br...@kadzban.is-a-geek.net 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.
The first error
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:
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
partitions,
Bruce Dubbs wrote:
Bryan Kadzban wrote:
But maybe something else changed. What happens if you:
ls /dev/pts
note the files present
./testpts
At this point as user nobody (in chroot), I get:
nobody:/tmp$ ./testpt
posix_openpt succeeded
grantpt: Operation not permitted
That's
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 mount probably needs -o gid=4,mode=620 added. If you add that,
do both
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 identified by
On Mon, Aug 05, 2013 at 06:16:53AM -0600, Matthew Burgess wrote:
On Sat, 03 Aug 2013 18:07:43 -0500, Bruce Dubbs bruce.du...@gmail.com 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.
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 if
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?
Hmm,
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.du...@gmail.com:
Bruce Dubbs wrote:
xinglp wrote:
2013/1/10 Bruce Dubbs bruce.du...@gmail.com:
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 report.
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 info --attribute-walk on this device's /sys
directory
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, now, there's a
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 in
(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
index for each disk. And since
wrote:
Bryan Kadzban wrote:
I will also note that using /dev/disk/by-id/ links allowed me to
survive the IDE - libata transition (/dev/hd* to /dev/sd*) with
zero userspace changes.
I don't recall running into that problem. ISTR that hdx mapped to
sdx without issue.
It didn't. You had
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 none.) That would be either assigning each PCI
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 taken with 'udevadm settle'.
When I instrumented the scripts, over half
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 want.
Well, you are, of course, but this appears to be nothing
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 to
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
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 X11
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
removing them seems to fix things up without causing other
problems
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: git is
[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
the
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 version to /tools/bin/su: 'cp src/su
/tools/bin'
Until
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
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
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|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
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 note
to
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 repository may not be the best place to keep
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 much about
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 afraid
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.
Zenther working my way through the cvs book and get to 7.2.1.
Creating stable names for network interfaces
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.
Zenther 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:
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.
Looking at what was created, they all
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 otherwise
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 passing
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'
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 glibc, it's
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 the record, says that newer kernels will work with older
udev versions
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, into the
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.*
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 key.
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 root root
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
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 place to
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 which to
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 soon will be
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
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 (systemd-hostnamed)
timedated (systemd-timedated)
localed
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 with systemd, we
should move away from it.
Let's see what
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 a newer
version of popt.
Actually
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
Bruce Dubbs wrote:
Andrew Benton wrote:
On Fri, 01 Jun 2012 18:39:59 +0100 Bruce Dubbs
bruce.du...@gmail.com 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.
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 /
Dan Nicholson wrote:
On Mon, May 28, 2012 at 1:00 PM, Jeremy Huntwork
jhuntw...@lightcubesolutions.com 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
Bruce Dubbs wrote:
Andrew Benton wrote:
On Thu, 31 May 2012 16:58:00 +0100 Bruce Dubbs
bruce.du...@gmail.com 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?
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 --prefix=/usr \
--with-rootprefix='' \
--bindir=/sbin
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.so.0
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:
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 udev
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. This
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
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
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. In udev-182, there are over 70 entries in
src
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 the way through make udevd, without
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 flags look
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
implies a
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... no idea yet. :-) I
should get some hardware
Jeremy Huntwork wrote:
On 3/14/12 11:32 PM, Bryan Kadzban wrote:
It *almost* looks like sysroot is the equivalent of a DESTDIR
install, where all the libs are installed intosysroot
prefix/whatever/path, but ask for /whatever/path at runtime (e.g.
when ld.so is looking for DT_NEEDED entries
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
don't suppose there's a way
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 symbols
Pierre Labastie wrote:
Le 15/03/2012 04:32, Bryan Kadzban a écrit :
This may have been covered in this thread already, but I don't
recall anymore -- did you do an ICA run with this change?
What I have done:
http://linuxfromscratch.org/pipermail/lfs-dev/2012-March/065866.html
OK, yeah, I
Greg Schafer wrote:
The sysroot infrastructure is clearly designed for a $SYSROOT/usr
layout which we DO NOT HAVE in the temporary phase!
Yeah, that's why my previous message was more or less comparing it to a
DESTDIR type installation. That may not be accurate, but it seems
vaguely similar.
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 look as soon as I
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
Andrew Benton wrote:
On Mon, 27 Feb 2012 20:10:28 -0800 Bryan Kadzban
br...@kadzban.is-a-geek.net 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
straightforward
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
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 required for X
Matthew Burgess wrote:
On Mon, 06 Feb 2012 11:00:31 -0500, Jeremy Huntwork
jhuntw...@lightcubesolutions.com 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
1 - 100 of 568 matches
Mail list logo
