-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> It looks like 2071 says that we need to add -Dvendorprefix=/usr to
> the configuration process, but configure.gnu doesn't support it.
>
> <...>
>
> Are there any comments about this? Should I just drop in these
> instructio
Alexander E. Patrakov wrote:
> 2008/10/29 Bryan Kadzban <[EMAIL PROTECTED]>:
>> Useless warnings: who cares.
>
> Authors of CGI scripts, because users see the warnings, at least
> under thttpd.
Well, Apache puts those into syslog but (AFAIK anyway) does not spit
them out
On Wed, Nov 26, 2008 at 03:16:30PM -0600, Bruce Dubbs wrote:
> We need to discuss a couple of issues.
>
> 1. How do we handle the bootscripts and udev config files' excessive line
> length? We can go in and adjust the bootscripts' line lengths to have a max
> of
> 72 characters, but the udev
On Thu, Nov 27, 2008 at 09:23:41PM -0500, Jeremy Huntwork wrote:
> * Any comments on the details provided in the above article,
> specifically in how that might relate to LFS?
Other than "that 3GB number is only applicable to Windows anyway", not
really. :-P
> * If you were to benchmark 32-bit
On Fri, Nov 28, 2008 at 12:01:45AM -0600, Bruce Dubbs wrote:
> One commenter said that virtually everything except flash and grub
> were 64 bit. I believe that flash is a very important application for
> many users and until that becomes available, many users will reject
> 64-bit Linux.
That is
Jeremy Huntwork wrote:
> Because this was a consensus made by several people back in the early
> part of 2006, I'd like to open it up for comment again now. Anyone mind
> if we do the more technically correct thing and move grep up in the
> build order of chapter 6?
I'm not sure whether I was p
Jeremy Huntwork wrote:
> Anything else?
Ticket 2033 -- initramfs. This way people with crappy software "RAID1
cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows,
can still boot from those cards. Also, support for MD RAID (*real*
software RAID ;-) ), LVM, and encrypted rootfs
Jeremy Huntwork wrote:
> 4. Ticket 2284, upgrade of Udev, and strip out udev-config. I doubt
> this needs its own branch. What sort of time/work is involved here?
Not a ton of work; with a few hours of time, I can probably get this up
and running. (I'd just have to compile a newer kernel, install
Matthew Burgess wrote:
> Tell you what, Bryan. On Saturday, I'll commit the Udev upgrade by
> itself. Then you/we can work on getting rid of the duplicate rules.
> Then, at our leisure we can figure out what other rules we can nuke.
I like this idea. :-P
I think the "getting rid of the dupli
Ken Moffat wrote:
> Last time this was discussed, the general view seemed to be that
> pure64 was a step far enough. Care to remind me what the advantages
> of multilib builds are ?
For me: Flash. Either "standard" flash, or nspluginwrapper-flash --
both require 32-bit libs somewhere. (nsplugi
Jim Gifford wrote:
> As far as udev rules, CLFS has made the move to use the rules that
> have been included for over a year with no issues at all.
Great! :-)
That (well: the fact that you've seen no issues, at least) means we can
very likely do the same: drop udev-config entirely and go with ud
Jim Gifford wrote:
> I just started to play around with extlinux, just started to do my
> testing, it does come premade already, but looks like it could be
> built with a standard compiler. I'll give feedback as I progress.
extlinux looks different (...obviously! ;-) ), but it may work fairly
wel
Gordon Schumacher wrote:
> Gordon Schumacher wrote:
>> I think I have an even better idea: rather than putting *any*
>> package management commands in, what about something like this:
>>
>> If you would like to generate binary packages, you will need
>> to define a function that will be used to ge
Jeremy Huntwork wrote:
> Specifically, DIY currently has 64-bit libs in /lib64 and /usr/lib64 and
> 32-bit libs in /lib, /usr/lib.
As does *every* normal distro I've seen that supports multilib...
(...)
> This way, both libraries are clearly identified and the default location
> of lib agrees
Jeremy Huntwork wrote:
> Bryan Kadzban wrote:
>> (I have a fairly large collection of build64 scripts that hold what
>> I've done for various packages to get their libs into the right
>> directory. This is for LFS, chunks of BLFS, and several beyond-BLFS
>> packa
Jim Gifford wrote:
> I know I told Bryan I would post my build and findings on this. So here
> they are.
Thanks! I'm actually considering changing on my main system (!!) now.
(Or at least testing it out.) :-) I may switch back once grub2 is
sane, though; we'll see.
> cat >> /boot/extlinux.con
Jim Gifford wrote:
>>> extlinux --install /boot dd if=/dev/zero of={/dev to root drive}
>>> bs=446 count=1
>
> This one removes the old mbr without affecting the partition table
Right, but I don't think it's needed, since:
>>> dd if=/usr/share/syslinux/mbr.bin of={/dev to root drive}
this will
DJ Lucas wrote:
> jp wrote:
>> After rendering, the md5sums of udev-config and lfs-bootscripts
>> tarballs match those in the generated book, but both differ from
>> what I can read here:
>> http://www.linuxfromscratch.org/lfs/view/development/chapter03/packages.html
>>
>> As those files are supp
Nathan Coulson wrote:
> BTW, one thought that I've been having in my setup, is using /usr/lib
> for 64bit, and /usr/lib/32 for 32bit [and /usr/lib/32/bin for
> things like ncurses-config].
Interesting idea, but (as you note) it isn't standardized. This means
your dynamic linker will not be in th
(Ticket 2314 is about this issue specifically. 2297 is more general,
but still related.)
Currently the udev-config 55-lfs.rules sets the GROUP of everything in
the "comms devices" section to "uucp". Upstream seems to have mostly
standardized on Debian's setup, where group "uucp" is used for a UU
Matthew Burgess wrote:
> I'm actually surprised that none of LFS' packages have started to use
> pkg-config yet, given its increasing adoption.
Well, depends on what you mean by "use". :-)
udev-13x (for some values of x; maybe all), for instance, stuffs at
least a libudev.pc and libvolume_id.pc
Bruce Dubbs wrote:
> The problem code looks like:
>
> gzip_status=$(
>exec 4>&1
>(gzip -cdfq -- "$1" 4>&-; echo $? >&4) 3>&- |
> ( (gzip -cdfq -- "$2" 4>&-; echo $? >&4) 3>&- 5<&- eval "$cmp" /dev/fd/5 -) 5<&0
> )
Sheesh, that's complicated! Let's see if I can decipher.
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Sheesh, that's complicated!
>
> Yes, it's bad. Earlier they have:
>
> for file
> do
>test "X$file" = X- || <"$file" || exit 2
> done
>
> but file is never defined, so this al
DJ Lucas wrote:
> hdparm is required as jhalfs currently processes the book. Need to
> make this not happen for jhalfs. I sent this to both lists because
> I'm not sure if this is part of the dump-commands target, or
> something that jhalfs does when extracting the commands.
Should be fixed in r
Bruce Dubbs wrote:
> The build of glibc-2.10.1 goes without a problem, but make check fails even
> with
> the -k parameter:
>
> /usr/bin/perl scripts/begin-end-check.pl argp/argp.h ...
>> /sources/glibc-build/begin-end-check.out
> make[1]: Target `check' not remade because of errors.
> make[
Bruce Dubbs wrote:
> --enable-kernel=VERSION compile for compatibility with kernel not older than
>VERSION
Yes: abort any program at startup if the current kernel version is less
than VERSION, and also remove any workarounds included in the glibc
sources for kernels older than VERSION (if any)
Bruce Dubbs wrote:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=448
>
> This indicates that
>
>sed -i '/vi_VN.TCVN/d' localedata/SUPPORTED
>
> is not needed any more.
Hmm.
The bug is that bash loops forever on startup, right? That shouldn't be
terribly hard to test: just set LC_AL
Dan Nicholson wrote:
> On Tue, May 26, 2009 at 12:40 PM, Bruce Dubbs wrote:
>> Dan Nicholson wrote:
>>> On Tue, May 26, 2009 at 9:32 AM, Bruce Dubbs wrote:
Using 2.6.18 appears to potentially affect binaries built
against kernels older than that and run on a LFS-6.5 or later
system
Tobias Gasser wrote:
> i can't find any XCFLAGS in the gcc/Makefile.in
Looking at "svn blame", and tracking back through the state of the book
at various svn revisions, that sed was committed when we still used
gcc-4.3.2. Wouldn't surprise me if they changed the way this was
specified now.
Ah, i
Bruce Dubbs wrote:
> jp wrote:
>
>>> What version of the kernel is you host system running?
>
>> uname -r on my host returns: 2.6.29
>
> Oops. I made a change to the host requirements section to require
> 2.6.18 or later, but never updated the glibc instruction. The option
> should be
>
> --e
jp wrote:
> Re-using the tools dir that I had got backed up, I re-runned glibc chapter 6
> with --enable-kernel=2.6.18 and tests results are even worse than with --
> enable-kernel=2.6.0:
>
> <...>
>
> I can see a process still running after the tests, see below ( I used ps axww
> from my host to
jp wrote:
> Still having the old error. I used strace to trace it, as I had been advised.
What about the contents of the .out file?
> 3 processes are started. the 3rd is created by the second, and the 2nd by the
> 1st.
Yep. The tst-mutex9 executable forks to run the test function (like all
the
Bryan Kadzban wrote:
> Poking around in glibc, this *looks* like a bug in it (at least in
> 2.10.1).
Filed this bug:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=10262
Does the patch mentioned there (to glibc) fix the testsuite? It needs to
be done whether it fixes the tests
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Bryan Kadzban wrote:
>>> Poking around in glibc, this *looks* like a bug in it (at least in
>>> 2.10.1).
>> Filed this bug:
>>
>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=10262
>>
&
jp wrote:
> I was about to start a new build, but have tried your patch before.
> It fixes this futex looping bug (for this 32-bit build). Now, no processes
> are
> left looping after the tests :)
Yay! :-)
> There are some other tests, still failing:
> stdio-common/bug22.out
> posix/wordexp-te
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> (I'm just hoping it doesn't get closed as a duplicate of bug 333:
>> "build failures aren't to be reported here".)
>
> The latest comment is:
>
> Fixed in git.
Yeah, that's helpful. :-)
Bruce Dubbs wrote:
> I'd prefer a sed. For one line a patch is overkill.
Yeah, probably.
The sed is really long, though; it might break the PDF's line length limit
(or whatever the issue was with long lines and the PDF book). Most of this
is the fact that nptl/sysdeps/unix/sysv/linux/i386/i486
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> I'd prefer a sed. For one line a patch is overkill.
>
> Yeah, probably.
>
> The sed is really long, though; it might break the PDF's line length limit
> (or whatever the issue was with long lines and the PDF book)
Tobias Gasser wrote:
> chapter 6.56 / svn-20090611
>
> the vol_id mentionned in the short descriptions does not exist any more.
> the libvolume_id is missing too.
See bug #2391.
In short: the current book is broken.
I thought there would be much less time before the util-linux-ng-2.16
release
Tobias Gasser wrote:
> accoring to the book util-linux-ng is build *after* e2fsprog. thus i
> just had to add the --with-fsprobe=builtin to util-linux-ng and after
> booting i'm happy to find all four flavours of /dev/disk/by-*
Out of curiosity: did your util-linux-ng version of mkswap build wit
Bruce Dubbs wrote:
> blfs-...@lfs.lucasit.com wrote:
>
>> Finally, back to util-linux-ng, per private mail with Karl Zak,
>> distros are only using static linking for libuuid, so *we* may want to
>> change Requires.private in the uuid.pc file, as we don't have to deal
>> with the dependency hell o
Bruce Dubbs wrote:
> I believe there was some discussion of setting the system clock via
> udev a while back, but I can't find the thread right now.
http://wiki.linuxfromscratch.org/lfs/changeset/8902
is the actual change. You could probably find that though. :-)
I'm not sure where the thread
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Mmm? Did mount stop writing to /etc/mtab or something? That needs
>> to be writable no matter which blkid / uuid library you use.
>> Unless you don't mind having "-o user" broken (I don't, but others
>>
Matthew Burgess wrote:
> 1. Build pkg-config in chapter 5 (required for point 3)
> 2. Build util-linux-ng with --with-fsprobe=builtin and
>'make -C libs/blkid install' to have it provide libblkid for e2fsprogs to
> use
> 3. Build e2fsprogs with --disable-libblkid so that it uses Util-Linux-NG'
Matthew Burgess wrote:
> and was able to determine that uuid.pc was a dependency for it.
Oh. Duh. Yeah, you're right -- without uuid.pc (from e2fsprogs if we
go that route, or from util-linux-ng-2.16), the libblkid.pc file doesn't
really help.
OK, never mind. Waiting it is then.
(Or releasing
Tobias Gasser wrote:
> i don't upgrade udev to 1.43 for the moment,
It's 143, not 1.43 -- there are a hundred and forty-three
different udev versions. They're not just minor updates.
But anyway... :-)
> as they made to many changes (see the thread about "udev 143" by
> william immendorf) and
Gilles Espinasse wrote:
> chap 6.56.1 say
> This package does not come with a test suite.
>
> Appendix C say
> Udev
> Installation depends on: Binutils, Coreutils, GCC, Glibc, and Make
> Test suite depends on: Findutils, Perl, and Sed
> Must be installed before: None
There used to be a test
Gilles Espinasse wrote:
> It look even when logged in (as gespinasse), I can't write anything on the
> wiki ticket.
> I didn't see any buttons allowing me to do that.
We were mucking around with the trac permissions a while ago, trying to
combat useless junk. Maybe this is a side effect from that
Bruce Dubbs wrote:
> I was experimenting with Util-linux-ng-2.16-rc1 and we may need to
> fix up what we do in chapter 5. Right now we:
>
> cp -v disk-utils/mkswap mount/{,u}mount text-utils/more /tools/bin
>
> But in 2.16 the disk-utils/mkswap mount/{,u}mount programs are
> scripts with the fol
On Fri, Jul 03, 2009 at 08:55:50PM +0100, Guy Dalziel wrote:
> I don't know how important the difference
> between _most_ compiles and _all_ compiles is, but T_CFLAGS seems to work
> just as well.
The point of adding that flag was to create byte-for-byte identical
compiler binaries. Have you ve
On Sat, Jul 04, 2009 at 07:56:02AM -0600, Matthew Burgess wrote:
> On Sat, 4 Jul 2009 06:52:49 -0700, Bryan Kadzban
> wrote:
> > On Fri, Jul 03, 2009 at 08:55:50PM +0100, Guy Dalziel wrote:
> >> I don't know how important the difference
> >> between _most_
On Sun, Jul 05, 2009 at 08:58:29AM -0600, Matthew Burgess wrote:
> Hi Bruce,
>
> Attached are my patches for all outstanding 6.5 tickets. It upgrades
> Util-Linux-NG as far as 2.16-rc2. This has survived a build and boot
> test. Feel free to commit them (in the order listed in 'series'), or
> h
On Mon, Jul 06, 2009 at 02:08:21AM -0500, Bruce Dubbs wrote:
> Bruce Dubbs wrote:
> > I decided to do a manual installation so I can watch what is going on
> > easier. For Util-linux-ng-2.16-rc2, I get:
> >
> > configure: WARNING: unrecognized options: --with-fsprobe
> >
> > The build goes OK th
On Mon, Jul 06, 2009 at 01:18:07PM -0500, Bruce Dubbs wrote:
> Bruce Dubbs wrote:
> > Bryan Kadzban wrote:
> >> On Mon, Jul 06, 2009 at 02:08:21AM -0500, Bruce Dubbs wrote:
> >>> Bruce Dubbs wrote:
> >
> >>> OK, I committed the changes. I was ab
On Mon, Jul 06, 2009 at 10:37:19PM +0100, Guy Dalziel wrote:
> e2fsprogs no longer hard codes rm in lib/blkid/test_probe.in. I rolled
> back a few versions to check when this happened and it was 1.41.6. The
> test executes 'rm' and therefore will find /tools/bin/rm to satisfy it.
I assume this is
Matthew Burgess wrote:
> On Sun, 12 Jul 2009 12:13:55 -0500, Bruce Dubbs wrote:
>> This is primarily to Bryan.
>>
>> Are there any issues or changes needed for the udev instructions
>> that need to be made to incorporate udev-144 into the book?
There weren't any major overhauls to the install se
Matthew Burgess wrote:
> I see 3 instances of `/sbin/udevd --daemon' running at the same time.
>
> Process 498, parent 1
> Process 543, parent 498
> Process 544, parent 498
>
> Is this what 'NEWS' in the tarball refers to as 'worker'
> processes, or are we not configuring/starting Udev-145 correc
Bruce Dubbs wrote:
> I was just reviewing the files installed bu LFS-6/5 and notice that the
> udev-config documentation is installed in /usr/share/doc/udev-config.
>
> Shouldn't that be /usr/share/doc/udev-config-20090523?
Only if you avoid the autofoo standard by putting the version in the
dir
Bruce Dubbs wrote:
> I'm talking about udev-config (an LFS created tarball) not the udev
> package from upstream. No autofoo, just vim.
Yeah. See commit #8542 for the change that made it put these docs into
a udev-config directory instead of udev-; this tarball used to
dump those files alongside
Trent Shea wrote:
> CCing Development List
>
> On Sunday 13 September 2009 16:40:59 you wrote:
>> thanks. I would have read given this straightforward and direct
>> answer (dont remember this bit from my reading; and I would have
>> expected the book to make a note of it if it was about FHS
>>
Bruce Dubbs wrote:
> Randy McMurchy wrote:
>> Bruce Dubbs wrote:
>>> Bryan Kadzban wrote:
>>>
>>>> But we don't put *any* .so (or .a) files into /lib, because the only
>>>> reason for /lib is to hold libraries that are required before /usr
ga ho wrote:
>>> 55-lfs.rules:SUBSYSTEM=="rtc", MODE="0644", ACTION=="add",
>>> RUN+="/etc/rc.d/init.d/setclock start"
>>>
>>> ???-- Bruce
>>>
>>>
>> Thanks, I'll double check /dev/rtc and the 55-lfs.rules on my
>> system.
>
> The rule in my 55-lfs.rules file is exactly as stated above howeve
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>>>> So, actually, .so and .a files are really only needed at compile time for
>>>> other packages. :-)
>>> OK, I was throwing the .so and the .so.1 files together. Since they are
>>> generally onl
Matthew Burgess wrote:
> On Mon, 14 Sep 2009 20:51:16 -0700, Bryan Kadzban
> wrote:
>> It might be that your kernel's SUBSYSTEM is wrong for this device.
>> Do you have CONFIG_SYSFS_DEPRECATED turned on in the kernel .config
>> file? Udev docs claim it may not wor
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>>>> What does "/sbin/udevadm info -q path -n /dev/rtc" say? Where does
>>>> the /sys/$(/sbin/udevadm info -q path -n /dev/rtc)/subsystem
>>>> symlink point to?
>>> udevadm returns '/dev
ga ho wrote:
>> It might be that your kernel's SUBSYSTEM is wrong for this
>> device. Do you have CONFIG_SYSFS_DEPRECATED turned on in the kernel
>> .config file? Udev docs claim it may not work with that setting (though I
>> don't know if that will cause this type of failure or not).
>
> CONFIG
Matthew Burgess wrote:
> On Tue, 15 Sep 2009 20:42:57 -0700, Bryan Kadzban
> wrote:
>
>> Did you have that setting on? We might want to warn about that in the
>> book in the kernel-config section, actually. Hmm.
>
> Nope, CONFIG_SYSFS_DEPRECATED_V2 is not set.
Matthew Burgess wrote:
> On Thu, 17 Sep 2009 16:18:16 -0500, Bruce Dubbs
> wrote:
>
>> #2033 Create initramfs
>>
>> I think this one should be closed as won't fix. The reason for a
>> initrd is for those systems that don't know in advance which
>> drivers are needed for accessing the bo
Nathan Coulson wrote:
> On Thu, Sep 17, 2009 at 2:31 PM, Matthew Burgess
> wrote:
>> On Thu, 17 Sep 2009 16:18:16 -0500, Bruce Dubbs
>> wrote:
>>> About the only other thing I can think of that is a candidate for
>>> LFS would be to add instructions for multi-lib.
>> I think I'd like to see that
Matthew Burgess wrote:
> On Fri, 18 Sep 2009 15:52:44 -0600, Matthew Burgess
> wrote:
>
>> stty: standard input: Inappropriate ioctl for device
>
> OK, figured this out to be the section of /etc/rc.d/init.d/functions
> that sets the COLUMNS variable by calling 'stty' (obvious now!). So,
> why c
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Matthew Burgess wrote:
>>> On Thu, 17 Sep 2009 16:18:16 -0500, Bruce Dubbs
>>> wrote:
>>>
>>>> #2033 Create initramfs
>>>>
>>>> I think this one should be closed as won'
Tobias Gasser wrote:
> Nathan Coulson schrieb:
>
>> I have been experimenting with a multilib LFS System (where /lib,
>> /usr/lib are used for 64bit, and /lib/32, and /usr/lib/32 are used
>> for 32bit). I wanted something as close to LFS as possible,
>> primarily 64bit, but just enough 32bit so
Bruce Dubbs wrote:
> I've been looking at LSB and in running a couple of basic checks find
> that we have some missing libraries and programs in LFS/BLFS to get
> to compliance.
Surprise.
LSB is by *no* means minimal. Neither is LFS, of course, but when you
require a specific package manager to
Zachary Kotlarek wrote:
> On Oct 27, 2009, at 12:16 AM, Bryan Kadzban wrote:
>> cpio, no. Nothing uses it except rpm (and see above about that
>> one).
>
> I've added cpio to my standard install, for use in the construction
> and editing of initramfs images.
Actuall
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Of course, RPM is available in BLFS I think, so we technically have
>> this already. But it's the kind of scope creep that I hate. They
>> already have this giant list of programs and interfaces that are
>> supposed
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> See the raid-crypt-lvm hint, and specifically the lfs-initramfs
>> package referenced there. Although, actually, that hint never got
>> committed apparently?
>
> Send me the hint and I'll commit it.
OK, link t
(Now we're getting a bit too far off topic, I think but oh well...)
Zachary Kotlarek wrote:
>
> On Oct 27, 2009, at 11:08 AM, Bryan Kadzban wrote:
>
>> Actually, you don't need it for that, either. Mostly because the
>> format of the cpio archive that the ker
Bruce Dubbs wrote:
> I have updated the book to GRUB-1.97. The on-line book should
> regenerate in a few hours.
>
> The GRUB section in Chapter 6 is pretty straight forward, but the
> section on configuration and testing in Chapter 8 is pretty complex.
> I'd appreciate anyone building and install
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> It doesn't remove the need for an initramfs. What it does do, is
>> remove the need for a separate /boot partition in many initramfs
>> cases (since grub2 can read LVM and I think some RAID types -- but
>> not, I thi
Ken Moffat wrote:
> 2009/10/29 Bryan Kadzban :
>> Same with some kinds of RAID -- it can assemble a RAID array, but
>> won't (always) do it on its own. (It can autoassemble some types
>> of md-raid, I think, but I'm not sure how well-maintained that is.
>> It
Chris Staub wrote:
> On 11/19/2009 08:30 PM, Bruce Dubbs wrote:
>> find dest/include -name .install -or -name ..install.cmd -exec rm
>> -v '{}' \;
>
> Not quite - the -exec only works on the last option before it...or
> something, I'm not quite sure exactly how to describe it technically,
> but i
Bruce Dubbs wrote:
> Bruce Dubbs wrote:
>> Chris Staub wrote:
>>> On 11/19/2009 08:30 PM, Bruce Dubbs wrote:
Chris Staub wrote:
> But there are the ".install" files in every subdir, not just in the
> "linux" dir. I use:
>
> find dest/include -name .install -or -name ..install.c
Bruce Dubbs wrote:
> William Immendorf wrote:
>> I've recently stumbled upon an security flaw in Linux. It affects
>> Linux < 2.6.32-rc6. The problem is that when using the
>> pipe_read_open(), pipe_write_open() or pipe_rdwr_open() functions
>> while releasing a mutex (mutual exclusion) too earl
On Wed, Dec 02, 2009 at 09:28:25PM -0600, Bruce Dubbs wrote:
> I've been playing with GRUB2 and splash screens. I've got it working so
> I wanted to make an lfs screen with a somewhat dark background so that
> the menu would show over it.
>
> I played around with gimp and came up with:
>
>
On Sat, Dec 05, 2009 at 11:43:14AM -0600, Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
> > On the off chance you like the black background, but not the gnu, you
> > can probably grab some SVG editor (inkscape worked pretty well last time
> > I tried it) and one of the just
Andrew Benton wrote:
> The problem is that nilfs-cleanerd looks in /proc/mounts to see which
> device node in /dev it should be working on. If you cat /proc/mounts
> you'll see that / is listed as /dev/root which doesn't exist on an
> LFS system so nilfs-cleanerd quits,
That's broken. I'd file a
Andrew Benton wrote:
> On 06/01/10 04:59, Bryan Kadzban wrote:
>> Before the nilfs2 FS is mounted, I assume you mean. Because it
>> doesn't make much difference whether the symlink exists before the
>> rootfs is mounted -- the kernel (or initramfs...) does that bef
Matthew Burgess wrote:
> I wasn't sure whether to report this as a bug in LFS or Udev or
> whether it's just my misunderstanding. If I remove
> /etc/udev/rules.d/70-persistent* (simulating how things look on a
> first boot into a freshly-built system) I then get the following on a
> reboot:
>
>
Matthew Burgess wrote:
> Matthew Burgess wrote:
>> Bryan Kadzban wrote:
>>
>>> Or, actually, what happens if you move 70-persistent-net.rules
>>> out to /dev/.udev/rules.d/, then do what we have in the
>>> udev_retry bootscript? (That is, cat the file
Bruce Dubbs wrote:
> 1. The reason for multilib in the first place is to handle packages
> that are pre-compiled for a 32-bit only environment. It only is
> needed on a 64-bit system.
>
> 2. There are very few packages that actually need it. Almost all of
> them proprietary. Open source packa
Mark Rosenstand wrote:
> Also, for the people that will run an initramfs for whatever reason,
> this will make it much simpler, not having to put udev in there.
No, you still need udev.
devtmpfs does *not* give you /dev/disk/by-{label,uuid}, which are
required for device name stability.
devtmpf
Bruce Dubbs wrote:
> gcc:
>
> FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
> FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE
>
> ERROR: tcl error sourcing
> /sources/gcc-4.4.3/gcc/testsuite/gcc.misc-tests/linkage.exp.
> ERROR: couldn't
Bruce Dubbs wrote:
> I did some testing tonight using the environment variable
> MAKEFLAGS=-j2.
I assume you have a dual-core CPU -- have you tried -j3? Any higher?
I see full CPU usage on both cores with -j3, although I haven't looked
at that with -j2. I *believe* -j2 will leave part of the av
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Bruce Dubbs wrote:
>>> I did some testing tonight using the environment variable
>>> MAKEFLAGS=-j2.
>> I assume you have a dual-core CPU -- have you tried -j3? Any higher?
>
> Chapter 6 binutils:
>
> time
Bruce Dubbs wrote:
> I've noticed an irritating message when klogd starts up. It says:
>
> Cannot find map file.
Meh. I've been skipping the System.map copy (as part of the kernel
install) *forever* -- or at least ever since I moved to kernel 2.6, I
believe -- and never cared enough to fix this
David Jensen wrote:
> Bryan Kadzban wrote:
>> Bruce Dubbs wrote:
>>
>>> To stop klogd from trying to read System.map, it requires passing -x
>>> in the command line. We can do that easily in the boot scripts.
>>>
>> Which I would sugge
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> David Jensen wrote:
>>> from slackware rc.syslog
>>> # '-c 3' = display level 'error' or higher messages on console
>> Starting to get off topic now, but after reading the klogd manpage, this
&
Grant Bowman wrote:
> I needed
> something because the glibc version was cut off on both a Debian
> testing/squeeze netinst machine with glibc 2.10.2 and Ubuntu 9.10
> Karmic machine with glibc 2.10.1.
Not glibc 2.10.2 / 2.10.1 -- *e*glibc 2.10.x.
That "e" is the problem: they decided to advertis
Ken Moffat wrote:
> sed-4.2.1
>
> 4 failures
> FAIL: utf8-1
> FAIL: utf8-2
> FAIL: utf8-3
> FAIL: utf8-4
>
> (these are testing case conversion (\u and \U)
> for cyrillic
I saw this when I had LC_ALL=C on the host. The sed test script only
sets individual LC_* variables that it thinks will aff
Ken Moffat wrote:
> Related question, although maybe it belongs on support - how do you
> get grub2 (1.97, if it matters) to boot in single mode? I need to
> fsck my /home partition manually (fsck'd after nn boots, came up with
> errors), and it's shared between all the systems on that box.
>
>
1 - 100 of 666 matches
Mail list logo
