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-M
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/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 into> prefix>/whatever/path, but ask for /whatever/path at runtime (e.g.
>> when ld.so is lo
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
>
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
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
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
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,
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
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
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
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 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. I
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:
> 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:
> 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
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
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 ude
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:
> 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'
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
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:
> 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
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
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
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
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
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
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
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 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
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
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:
> 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
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
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
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
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
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
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
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.
>>
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
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:
> 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:
> 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:
> 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:
> 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:
> 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
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
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
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
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
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
[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
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
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:
> 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
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:
>> 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
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:
>>> 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&
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
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:
>
>> 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
(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:
> 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
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
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/
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 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:
>
>> 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
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], ...
>>>
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
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
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
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:
> 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
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:
> 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
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
>> p
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.
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
Chris Staub wrote:
> The Chapter 6 ncurses instructions in the LFS dev book have this
> construction:
>
> for lib in curses ncurses form panel menu ; do \
> rm -vf /usr/lib/lib${lib}.so ; \
> echo "INPUT(-l${lib}w)" >/usr/lib/lib${lib}.so ; \
> ln -sfv lib${lib}w.a /usr/lib
Alexander E. Patrakov wrote:
> Bryan Kadzban wrote:
>
>> This is NOT safe if either of those library files are currently
>> linked into any process that's running!
>>
> They are not used. Certainly :)
>
> The used file may be /lib/libncursesw.so.5 (whic
Dan Nicholson wrote:
> In the adjustment, though, he uses `gcc -dumpmachine`, though. This
> is probably wise since you don't know what MACHTYPE is from the
> host's bash. In fact, this might be a good idea for both
> adjustments. I don't know how reliable MACHTYPE is, but I'm
> speculating sin
Dan Nicholson wrote:
>>I also ended up with multiple copies of the compilers (not symlinked) as in:
>>g++
>>i686-pc-linux-gnu-g++
>>(IIRC, there were 3 variants for g++ all the same size, a couple gcc, ..)
>
> That seems normal to me. On my current system I have
>
> $ ls -l /usr/bin/*{c,g}++
>
Richard A Downing wrote:
> I still can't see how to hotplug the usb printer though. Can someone
> tell me which rules in the lfs set are supposed to moad the usblp
> module, and it's module dependencies usbcore, ohci_hcd and ehci_hcd?
Here's what I understand happens: (If this is wrong, someone
Matthew Burgess wrote:
> I'm still concerned that we won't load all modules correctly though;
> some of the distro rules load various SCSI modules dependent on the
> SYSFS{type} variable. I'd appreciate it if someone with the
> necessary hardware could test to see what does or doesn't work.
Oh
Richard A Downing wrote:
> I tried Jim Gifford's Cross-lfs udev patches, and they work fine, so
> that's what I'm going with for now.
I'm not familiar with these patches, and I can't seem to find them in
the (x86 at least) cross-lfs book. Where are they?
Seeing the patches might help figure out
On Thu, Feb 23, 2006 at 11:20:02AM -0500, Jeremy Huntwork wrote:
> >If the text is not US-ASCII and the content-transfer-encoding is
> >quoted-printable, all non-ASCII bytes are converted to the "=XY"
> >notation, where X and Y are hex digits. ASCII pats of the message are
> >readable with vim t
Matthew Burgess wrote:
> Andrew Benton wrote:
>
>> With the udev_update branch nothing loads the uhci-hcd module.
>
> Thanks. Alexander, do you know if this is one of those problematic
> drivers that has since been fixed up in 2.6.16-rc4?
I doubt it; the kernel source for 2.6.15.3 has somethin
On Fri, Feb 24, 2006 at 05:29:07PM +0500, Alexander E. Patrakov wrote:
> As written, this is incorrect. Increasing the logging verbosity achieves
> nothing, because udev runs before syslogd. Proposed solution:
>
> 1) Implement some "restart" target in the udev initscript that kills old
> udevd,
Alexander E. Patrakov wrote:
> No, that won't work. We want to mount tmpfs on /dev for start, but
> not for restart.
True, unless we unmount it first (thus removing all devices). Well,
actually we probably can't unmount it, because at least /dev/console
will be open.
OK, so how about restart doe
On Mon, Feb 27, 2006 at 07:03:04AM -0700, Archaic wrote:
> It is done before udev is started. It just happens to be done in the
> same script that starts udev and currently that is the most logical. We
> can't do it in the mountfs script because udev must run before that. We
> could do it in the mo
Archaic wrote:
> From what I've read, inotify is the only thing that keeps popping up
> and a patch will satisify that.
Not quite true anymore; 2.6.16 also includes some new syscalls (openat
and friends) that will (may? probably "will") require changes in the
userspace headers.
There may be othe
On Mon, Mar 13, 2006 at 04:39:11PM +, Florian Schanda wrote:
> On Monday 13 March 2006 16:10, Florian Schanda wrote:
> > On Wednesday 08 March 2006 04:21, Jim Gifford wrote:
> > > available at http://ftp.jg555.com/headers/headers.
> >
> > You can replace the long sed with the following:
> >
> >
201 - 300 of 666 matches
Mail list logo
