Re: ICA/Farce
Greg Schafer wrote: > (Me wonders if Bruce realizes the whole "build straight from the doc" > concept in jhalfs is based on my own practices in DIY? Which in turn was > based on the old lfscmd from about 8 years ago? :-) > OT, but Wow, good memory! Timothy B. right? (I'd have butchered his last name) -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ICA/Farce
Greg Schafer wrote: > DJ Lucas wrote: > > >> Hey guys. Is there any recent documentation on the expectations of >> farce or ICA? >> > > Docs? What docs :-) > > >> Doing only 2 passes of chapter6 >> with both comparison methods checked. What are the advantages of 3 or >> more passes? >> > > Huh? ICA by definition is 3 passes. No ifs, buts or maybes. Any other > number is meaningless and exposes a lack of understanding of what is being > tested. > I've never used it. My question was based only on the options provided in jhalfs, which probably means that they are intended specifically for Farce. Anyway, I killed the build I was working on. Given the Ken's description of current Farce, I'm not sure that both can run on the same system and have meaningful results. I'd really like to do a sanity check on the development LFS. A positive ICA run would do us very well to prove that the old build method is at least still working, even though it is dated. After I take care of these last two bugs, I'll take a look at your current gsbuild and see if I can make it make sense to me since I haven't used it. Maybe even get jhalfs updated to your current tests. IIRC there were also some good notes when ICA was developed in the LFS archives, but they are probably way outdated. I will take the time to search them myself, but if you happen to run across any interesting threads in the DIY archives before I get to it, would you mind posting a link? > I've never looked at jhalfs but I understand it implements my ICA > algorithms. My own scripts have been getting exceptionally clean > results lately now that the randomness in GCC builds has apparently gone > as of GCC 4.3. I'll happily check any results you can post up. > After I get a basic understanding, I'll probably take you up on that. Thanks a million Greg. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Xorg-7.4
Nathan Coulson wrote:
> On Sat, Oct 18, 2008 at 12:03 PM, DJ Lucas <[EMAIL PROTECTED]> wrote:
>
>> DJ Lucas wrote:
>>
>> Okay...these drivers failed to build for me and I haven't had the time
>> to investigate the failures yet, got to keep moving for LFS testing:
>>
>> [EMAIL PROTECTED] driver]$ grep "^##x" ../driver-7.4.wget | sed '[EMAIL
>> PROTECTED]@@'
>> xf86-video-glide-1.0.1.tar.bz2
>> xf86-video-impact-0.2.0.tar.bz2
>> xf86-video-intel-2.4.2.tar.bz2
>> xf86-video-vermilion-1.0.1.tar.bz2
>> xf86-video-wsfb-0.2.1.tar.bz2
>> xf86-video-xgixp-1.7.99.3.tar.bz2
>>
>>
> I think the latest mesa needs libdrm 2.3.1 as well... [I am using
> xf86-video-intel 2.4.2, libdrm 2.3.1, xorg 7.4 packages, and Mesa
> 7.2]. Compiles ok for my subset anyway.
>
OK...with libdrm-2.3.1, intel driver builds. The broken list is
otherwise the same. Probably need to drop back a version, but I am
unsure at the moment. Will look into it further a little bit later on.
For anybody interested, the rest is long. With the wget files I posted
earlier, here is the first 60 linsts of BLFS in order for a 'complete' X
setup (have not done the font setup or xterm), all built against current
LFS-SVN with little to no modification to the current book instructions
(xorg-server, Mesa, and packages that do not appear in the book
currently are obvious exceptions, see instructions changes below the list):
[EMAIL PROTECTED] logs]# ls 2* | sed '[EMAIL PROTECTED]@@'
pth-2.0.7
bc-1.06
openssl-0.9.8i
gdbm-1.8.3
Python-2.6
cracklib-2.8.13
Linux-PAM-0.99.10.0
shadow-4.1.2.1
shadow-Linux-PAM-config
sudo-1.6.9p17
libjpeg-6b
libpng-1.2.32
freetype-2.3.7
expat-2.0.1
wget-1.11.4
libxml2-2.6.32
pkg-config-0.23
fontconfig-2.6.0
libart_lgpl-2.3.20
gpm-1.20.5
which-2.20
unzip-6.0d
zip-3.0
pciutils-3.0.2
libusb-0.1.12
usbutils-0.73
gcc-4.3.2
openssh-5.1p1
Xorg-7.4-protocol-headers
Xorg-7.4-utilities
libXau-1.0.4
libXdmcp-1.0.2
xcb-proto-1.1
libpthreadstubs-0.1
libxslt-1.1.24
libxcb-1.1
ed-1.0
Xorg-7.4-libraries
xbitmaps-1.0.1
libdrm-2.3.1
Mesa-7.2
Xorg-7.4-applications
xcursor-themes-1.0.1
Xorg-7.4-fonts
Bundle::CPAN-20081101
XML-Parser-2.36
intltool-0.40.5
xkeyboard-config-1.4
luit-1.0.3
dbus-1.2.4
glib-2.18.2
dbus-glib-0.76
dbus-python-0.83
hal-0.5.11
gperf-3.0.3
xcb-util-0.3.0
pixman-0.12.0
cairo-1.8.0
xorg-server-1.5.1
Xorg-7.4-drivers
Here are the instruction changes that I used:
Build commands are taken directly from the command block of the lspec
files (my homegrown PM) and placed at the top of the build logs.
Basically, only the items in the 'time { ... }' blocks are relevant.
[EMAIL PROTECTED] logs]# grep -B 100 "^## shadow" 207-shadow-4.1.2.1
{
echo "## $(basename $PWD)"
llog -p
time {
sed -i 's/groups$(EXEEXT) //' src/Makefile.in &&
find man -name Makefile.in -exec sed -i 's/groups\.1 / /' {} \; &&
sed -i -e 's/ ko//' -e 's/ zh_CN zh_TW//' man/Makefile.in &&
for i in de es fi fr id it pt_BR; do
convert-mans UTF-8 ISO-8859-1 man/${i}/*.?
done &&
for i in cs hu pl; do
convert-mans UTF-8 ISO-8859-2 man/${i}/*.?
done &&
convert-mans UTF-8 EUC-JP man/ja/*.? &&
convert-mans UTF-8 KOI8-R man/ru/*.? &&
convert-mans UTF-8 ISO-8859-9 man/tr/*.? &&
sed -i -e '[EMAIL PROTECTED] [EMAIL PROTECTED] SHA512@' \
-e 's@/var/spool/mail@/var/mail@' etc/login.defs &&
./configure --sysconfdir=/etc &&
make &&
make install &&
mv -v /usr/bin/passwd /bin &&
useradd -D -b /home &&
sed -i 's/yes/no/' /etc/default/useradd
}
llog shadow-4.1.2.1
} 2>&1 | tee -a ../logs/207-shadow-4.1.2.1
## shadow-4.1.2.1
[EMAIL PROTECTED] logs]# grep -B 100 "^## openssl" 202-openssl-0.9.8i
{
echo "## $(basename $PWD)"
llog -p
time {
patch -Np1 -i ../openssl-0.9.8i-fix_manpages-1.patch &&
./config --openssldir=/etc/ssl \
--prefix=/usr \
shared \
enable-gmp \
enable-zlib-dynamic \
enable-tlsext &&
make depend &&
make MANDIR=/usr/share/man &&
make MANDIR=/usr/share/man install &&
cp -v -r certs /etc/ssl &&
install -v -d -m755 /usr/share/doc/openssl-0.9.8i &&
cp -v -r doc/{HOWTO,README,*.{txt,html,gif}} \
/usr/share/doc/openssl-0.9.8i
}
llog openssl-0.9.8i
} 2>&1 | tee -a ../logs/202-openssl-0.9.8i
## openssl-0.9.8i
[EMAIL PROTECTED] logs]# grep -B 100 "^## Mesa" 240-Mesa-7.2
{
echo "## $(basename $PWD)"
llog -p
time {
./configure $XORG_CONFIG --enable-xcb &&
make &&
make install &&
install -v -m755 progs/xdemos/glx{info,gears} ${XORG_PREFIX}/bin &&
ln -s -v ${XORG_PREFIX}/include/GL /usr/i
Re: Vim man pages
Ken Moffat wrote: > Me again! > > I seem to have an excess of man pages from vim. It's possible I've > fubar'd something when I removed my own "everything UTF-8" commands, > it's equally possible vim has always done this duplication. So I'll > start by asking if other people have this: > > fr pages in man/fr man/fr.ISO8859-1 man/fr.UTF-8 > it pages in man/it man/it.ISO8859-1 man/it.UTF-8 > pl pages in man/pl man/pl.ISO8859-2 man/pl.UTF-8 > ru pages in man/ru.KOI8-R man/ru.UTF-8 > > Each of these is a full set. > > Confirmed. Looks like vim devs are trying to please everyone. :-) That's actually nice in a way. At very least, cut one of the legacy encoded sets for each and let the user decide what (if anything) to do with both sets. The ones in the UTF-8 directories are correctly encoded UTF-8 (as you might have guessed), and old file incorrectly identifies _all_ the rest as iso8859-1 (translates to it's an 8bit encoding but it doesn't know how to determine which). At any rate, my preference is still to see a slow transition to all UTF8 (when provided and where convenient) and let man-db do it's thing. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version in glibc
Jeremy Huntwork wrote: > > We've gone a long time saying that we aren't a distro. But in a sense we > are. I've given up on that argument. We are not a 'standard' distro, but none the less, whether we like it or not, we are considered a distro by everyone else out there. Ever hear of distrowatch? Look us up! ;-) > At the least, presenting an option like this demonstrates to the reader > just a little bit more about customizing their build. > It should be added IMOand should further use the lfs-release number so that if anybody is questioning modifications, you can easily look back at the version referenced to see if there were any modifications. I'm not even sure about leaving the date in there...but I think it's fine. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: book numbering
Lefteris Dimitroulakis wrote: > It is not that important, but it seems > strange number is added to the LFS-BOOK-SVN in > http://www.linuxfromscratch.org/lfs/downloads/development/ > > cheers > Thanks. Fixed in r8742. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Problems with PDF Output
Bruce Dubbs wrote: > Thomas Reitelbach wrote: > > > >> But it would have been wise to fix this before the release. I'm of course >> not >> one of those people to decide such things. But for the last releases i >> believe that someone (who?) resolved rendering issues like this with the >> book. >> > > I've made that last couple of releases. In this case, I decided to release > without the pdf for now because further delay would make too many packages > out > of date. > > 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 config does not allow line breaks. > > 2. How do we break up long sections so the rendering goes > across multiple pages? > > One solution would be to strip the bootscripts and udev files completely from > the book (at least for the pdf rendering) as was done before 6.4. The still > leaves the problem of properly rendering the long table in Man-DB. I suppose > we > could double it up to four columns. > Forgive the obvious, but I'm thinking a smaller font for these parts. I don't see any problem with having smaller text in these sections of the book as they are tables and appendixes, not necessarily required reading. I don't have any clue how to go about doing this, but it seems to me that this would be the best option. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The value of 64-bit vs 32-bit
Bryan Kadzban wrote: > 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 vs 64-bit on an LFS system, what would >> your tests include? >> > > I wouldn't bother benchmarking it. Every single time that a bit width > increase has come along so far, it has eventually won out (except Itanium, > which came along too early and without enough attention paid to having > some sort of backward compatibility). Not exactly...this is the third time that Intel had to take a step backwards because they didn't care about hardware cost. 8086-8088, 80386-80386SX, Itanium-whatever (I pretty much don't understand the new Intel naming convention, nor care since AMD took the time to nip both cost and compatibility in it's initial 64 release). > I don't think it's a question of > whether people should use 64-bit; I think it's a question of when they > will eventually move to it en masse. > Took about 11 years last time before 32 was the default and 16 was 'legacy' (using NT-4 and the 80386 as a rough benchmark, some may prefer Win98 as a the timestamp for consumers and NT-3.1 for business, but NT4 was where large adoption took place in my fuzzy memory, I was very green at that time). We are over halfway there. Fortunately, Windows isn't my chosen baseline anymore, though they are there now on the server side...the consumer OS is still flipping. > Of course, if you have to choose between the two bit widths (i.e. if we > don't support multilib -- and I realize that would be a lot of work!), > it may still make sense to go with 32-bit, given the huge set of > programs already written out there. But if you can run both, I see no > reason not to. > At this time, multilib is unfortunately the proper way to go IMO...I just haven't taken into account how difficult it is yet. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Matthew Burgess wrote: > On Tue, 02 Dec 2008 05:07:25 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > > >> Anything else? >> > > Ticket #2284 - radical plan would be to just drop udev-config completely, > then any reported issues should be passed upstream and fixed there. I really > don't see anything special about LFS that means it should have to customise > Udev beyond upstream's default config :-) > > Regards, > > Matt. > Good idea, but I think there will always be some distro overrides needed. Look at our last change in the changelog (fdx? - detail escapes me ATM)...but when I researched it, it was brought up before on the udev list, hashed out on the udev list, and finally a change made that didn't quite match the recommendation because two distros disagreed (I forget who). The compromise was still better than the original, but we still needed to change it for our take on what was correct. Hopefully though, the overrides will be cut to a minimum. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Jeremy Huntwork wrote: > Jeremy Huntwork wrote: > >> Anything else? >> > > Oh, I also forgot. We could give some thought to using DIY's new build > method Some? I thought this was a no brainer. During the big push for 6.3, Greg handed us many, many tips, and showed several examples of where the new build method was clearly the better choice. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: libidn update
Alexander E. Patrakov wrote: > 2008/12/2 DJ Lucas <[EMAIL PROTECTED]>: > >> Alexander E. Patrakov wrote: >> >>> Testcase (I think it should even be put into the book): >>> >>> LANG=en_US xterm >>> in that xterm: curl http://räksmörgås.josefsson.org/ >>> >>> >> Thanks for the testcase Alexander. All of them have been invaluable to >> my limited uni-lingual mind (is that even a word?). Might be nice if an >> expectation was set. :-) I don't have curl installed yet so I haven't >> tried it. >> >> I assume the expected outcome is something to the effect of 'Resolving >> r\303\244ksm\303\266rg\303\245s.josefsson.org... failed: Name or service >> not known.', as it does with an old wget if not working...otherwise >> we'll be greeted with a raw copy of the index. >> > > The expected outcome is a portion of HTML. Obviously, this works only > if you really have the en_US locale, i.e., the "locale" command in the > xterm doesn't print any errors. And your locale setup is indeed > incorrect, as "\303\244" appear, as if the paste resulted in UTF-8 > bytes instead of ISO-8859-1, and as if bash treats these characters as > unprintable (this happens only in the "C" locale). > That wasn't the paste..that was the result of an old version of wget mangling it in the error on a well abused 6.3 LFS host. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xkeyboard-config and intltool
Jeremy Huntwork wrote: > Hi, > > I see on the xkeyboard-config page that intltool is listed as an > optional dependency, but if I try building the current instructions as > is without intltool, I get the following configure error: > > checking for intltool >= 0.30... ./configure: line 3519: > intltool-update: command not found > found > configure: error: Your intltool is too old. You need intltool 0.30 or > later. > make[2]: *** [compile-stage2] Error 1 > > > Can anyone confirm or deny this? > > > No, I don't have it noted as required, but it certainly is. Chalk it up to another error made because I rushed to get it in. All of the xorg commits were very sloppy because I was in a hurry, though I thought I had corrected everything. The patch is certainly not required. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: The new build method is in...
Jeremy Huntwork wrote:
> There is no technical hindrance to bringing in multilib, the changes are
> minimal. The effect is not so minimal. I would like to know people's
> thoughts on how to deal with multilib in LFS. Specifically, how do we
> handle for x86, where multilib is not an option? Do we just have a note
> that says 'for 64-bit architectures only'? If so, how do we handle this
> in jhalfs?
>
I personally would like to see multi-lib in the book, simply for the
educational value. I figure now is as good a time as any. Having not
done it myself, makes the topic a little difficult. Just taking a
cursory glance at the instructions, it looks as though almost all
instructions are identical for pure64 and 32bit builds. Thinking of
jhalfs here, is it possible to add an additional attribute to the
command tags? For instance, now we have something like (using configure
as an example value for remap):
[command remap="configure"]...[/command]
I don't know if it is legal to do something like:
[command remap="configure" buildtype="{pure|multilib|}"]...[/command]
Or, would new remap parameters have to be added for configure-pure and
configure-multi, where plain configure is for everybody (like old grub
that only builds 32bit).
From a book perspective, it's not a big deal IMO to do one {sect2} with
'pure' commands and another with multi-lib commands...just add a
standard blob (xi) to prefix each section of instructions.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[Fwd: Re: Mailing lists archives]
William Harrington wrote: > So anyone gonna fix the archives? None of the archives can be > downloaded. > > No archive from any mailing list can be downloaded. Forwarded to lfs-dev so that at least some of the proper people see it. I don't recall the admins group address right off the top of my head. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The new build method is in...
Bruce Dubbs wrote: > In BLFS, the first section of the Introduction is > Acknowledgments, but there is no similar section in LFS. Perhaps a similar > section should be added to the LFS Preface. > I have suggested this a few times off list. I think it would be a good addition. It's right up front and center and gives credit where credit is due, and a link provided to DIY or CLFS so that users can go check out the other projects if they like. I'm sure that there are others that should get a mention in there as well, though they escape me ATM. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: lfs-dev Digest, Vol 1235, Issue 1
Gordon Schumacher wrote: > Gordon Schumacher wrote: > > >> So what I did in my work was implement a new >> (which in my opinion should be able to be switched on and off via >> profiling), which does the fakeroot install. The command to actually >> turn that into a SquashFS module is wrapped in a profiling switch >> specific to Linux-Live. >> > > I think I have an even better idea: rather than putting *any* package > management commands in, what about something like this: > Personally, I see a totally different approach. I haven't thought it out fully, but my take is that if we are going to move to DESTDIR installations, please do at least the full installation of all parts completely from the DESTDIR for the sake of education. > I think that this would satisfy all the desires stated: not supporting a > specific package manager, supporting package management if people want > it, and still allowing for automation! > No it doesn't. It's not enough just to tar up the DESTDIR. You need to consider installing the package (which IMO should be done by a script created in the DESTDIR after removing any updated/dynamicly generated files). That way you can create a tarball that is PM neutral and ready for any real packaging scripts that you want to throw at it. I guess my question is "What was the goal when this was decided?" 'make DESTDIR=foo install', inspect the DESTDIR, and then 'make install'? While I guess that there is nothing specifically wrong with that approach, the DESTDIR is pretty much useless IMO, might as well stick to installation logging. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Mangement (was Re: lfs-dev Digest, Vol 1235, Issue 1)
DJ Lucas wrote: Sorry about the subject. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Package management and creating the file system layout
Guys, while I'm waiting on my automated build to complete, I'm running
through a manual build on a second system that I have, in order to test
the idea of using a DESTDIR installation. I must say that it has been a
*long* time since I did a full manual build. Anyway, can anyone provide
a technical reason not to create the entire 'base' while in chapter 4?
I think with current host system requirements, the syntactical
differences can probably be thrown out the window (and if not, then the
host requirements can be updated).
The reason that I ask is that I'm looking at this from a packager's
point of view. Everything in section 6.5 and the second, third, and
fourth set of commands in section 6.6 (creating /etc/passwd, /etc/group,
and /var/log/{lastlog,{b,u,w}tmp}files) belongs in back in Chaper 5 so
as to create an "LFS-Base" package. Additionally, this gets rid of the
"I have no name" bit, and the extra invocation of bash. The "I have no
name" prompt is the only educational piece that is lost (and it could
stay, although it'd have to be changed a bit), while logically creating
the entire base at one time sets the stage for proper packaging (IMO).
Thoughts?
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Package management and creating the file system layout
DJ Lucas wrote: > a technical reason not to create the entire 'base' while in chapter 4? > Oops, that should have been 'chapter 5'. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package management and creating the file system layout
DJ Lucas wrote: > chapter 4? > UGH. I was thinking that 6.2 was at the end of chapter 5. Anyway, the request is to merge virtual file systems page with creating directories and the last 3 of 6.6 so that all directories and files that are manually created (with the exception of links that will be overwritten), are created in a single section, before entering the chroot environment. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package management and creating the file system layout
Bruce Dubbs wrote: > Can you explain what you mean by "create the entire 'base'". > Again, looking at this from a packaging point of view, IMO, all files and directories that are created manually should be together on one page so that a single package can be generated and called 'lfs-base' or something to that effect. I had the chapters screwed up, but basically, we should create all of the directories first and the then the essential files (not symlinks) on the same page. Follow that up with mounting virtual file systems and then chroot. The symlinks can (and should) still be created after entering chroot (the last three sets of instructions would never be packaged). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package management and creating the file system layout
Bruce Dubbs wrote: > DJ Lucas wrote: > >> Bruce Dubbs wrote: >> >>> Can you explain what you mean by "create the entire 'base'". >>> >>> >> Again, looking at this from a packaging point of view, IMO, all files >> and directories that are created manually should be together on one page >> so that a single package can be generated and called 'lfs-base' or >> something to that effect. I had the chapters screwed up, but basically, >> we should create all of the directories first and the then the essential >> files (not symlinks) on the same page. Follow that up with mounting >> virtual file systems and then chroot. The symlinks can (and should) >> still be created after entering chroot (the last three sets of >> instructions would never be packaged). >> > > > Hmm. My initial reaction is that I don't really like it. Under that > scenario, > we wouldn't be using the new packages as they are built. I'm not sure if we > can > build everything without using our new packages because some may depend on > others. > Woah..reading a bit too much into it. As David correctly pointed out, I'm only suggesting that creating the basic filesystem (sections 6.2-6.6) be reordered, or rather reworked. Creating packages at build time is the goal, however, the packages would be installed immediately. The 'lfs-base' package would be 2 files, plus 5 empty ones that would only be created by the install routine, not stored, plus the base directory structure would also be created. No need to add DESTDIR commands or anything of that like until the first package is installed in chapter 6. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package management and creating the file system layout
Bruce Dubbs wrote: > OK, I don't have time for studying it now, but I did misunderstand the > proposal. > I'll go back and study it some more. > I'm working on Gnome again right now, but I'll put up a copy of the book in my home dir with the proposed changes on Friday evening if I have the time, or Saturday if not. The point of the change is simply to get any files not tied to a package installation installed at one time. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Mangement
traneous files rm -f $DESTDIR/usr/share/info/dir rm -f $DESTDIR/etc/ld.so.cache rm -f $DESTDIR/usr/share/info/configure.info # Generate file and directly lists cd package for dir in `find . -type d` do ls -ld $dir | sed "s@ ./@ /@"; done > ../dirlist.txt for file in `find . -type f` do ls -l $file | sed "s@ ./@ /@"; done > ../filelist.txt cd .. # End build.sh [...@name25 usb]# cat packages/binutils-2.18-1/install.sh #!/bin/sh # Begin install.sh # Install files cp -av package/* / # Set ownership for dir in `cut -d " " -f 9 dirlist.txt` do chown -v root:root $dir done for file in `cut -d " " -f 9 filelist.txt` do chown -v root:root $file done # End install.sh [...@name25 usb]# cat packages/binutils-2.18-1/post-install.sh #! /bin/sh # Begin post-install.sh # Update /usr/share/info/dir for info in `ls package/usr/share/info` do echo "Installing /usr/share/info/$info." install-info --dir-file=/usr/share/info/dir \ --info-file=/usr/share/info/$info done # Update the linker cache /sbin/ldconfig # End post-install.sh [...@name25 usb]# As you can see, there really isn't that much added to the existing instructions. I was simply being tedious for the scripts. I'd really like for LFS to go all the way to an unprivileged user to build the package. From an educational standpoint, it is perfect as this is how the distro's do it (granted not in an extremely minimal chroot environment), however, I'm not so sure that this is an easily obtainable goal...hence why the whole thing is done as root for now (as is current LFS practice in the chroot environment). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Mangement
DJ Lucas wrote: > > For example, here is my chapter 6 glibc and chapter 6 > binutils build scripts: > From 6.4, not SVN. I didn't yet want to mess with the changes in the toolchain. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: md5sum for lfs-bootscripts-20081031.tar.bz2
jp wrote: > Bruce Dubbs a écrit : > >> jp wrote: >> >> >>> hi, all >>> >>> I rendered the xml of the development book. Surprisingly, the md5sum of >>> lfs-bootscripts differs from what is on the website. >>> >>> Can someone explain what is happening ? >>> >>> >> You don't say what version you are rendering. >> >> In any case, there are a couple of scripts, make-aux-files.sh and >> aux-file-data.sh that adjust the md5sums when the book is run. >> >> Do the md5sums in your copy of the book match those of the bootscripts and >> udev >> tarballs that are generated? >> >>-- Bruce >> >> > Hi, Bruce and all > > I downloaded the book from the svn repository, using: svn co > svn://svn.linuxfromscratch.org/LFS/trunk/BOOK/ > at the end of the download, I was advised that rev. 8777 had been extracted. > > 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 supposed to be identical, I wonder where the problem > is: in my copy, or on the website ? > Neither is a problem. They differ because the sums are dynamically inserted into the book at render time, when the tarballs are generated from current SVN source on your local system. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: CLFS antics
Greg Schafer wrote: > Here it is folks, living proof CLFS are competing directly against their > parent project. I'm utterly gobsmacked.. > Damn Greg, did they piss in your Cheerios or what? Just as you did, the CLFS group did not like the goals, nor the direction that LFS was taking and they went and did their own thing that met their goals, as Ryan had mentioned previously, continuing where the lfs-hackers list left off. Whether it is a fork is really irrelevant at this point, but for the record, CLFS *is* a fork. That said, is a fork really so bad? It might have been more disheartening if they had copied the book and called it "J&R's BYOL" or something to that effect (sorry if I've missed anyone who was part of the original CLFS core team at the time of the split), but they didn't. They attempted to keep it under the LFS name and at least pay tribute to its roots. CLFS and LFS have had our differences in the past, and will probably continue to at times, but the various LFS camps should try to work together as much as possible for the common goal. I'm not sure where that puts DIY, but I'd like to include you as well, though you probably benefit the least since you typically forge ahead on your own. On that note, your input has been very valuable, and I'd like to again say thank you for all your help in getting 6.3 out the door. Though you do pretty damn well with your group, it is due mostly to your own dedication to DIY. LFS and CLFS are short on people who want and/or have the time to do the work. I'd like to be able to forge a working relationship between all like groups so that we can continue to feed from each other, no matter how little or great that benefit that may prove to be. Directed comments like the one above do a lot more damage than the idea of CLFS 'competing' with LFS. Take SM or Gentoo as an example. They are direct competitors, if there is such a thing in Open Source. I've recently had the pleasure of working with one of the SM devs through the Mozilla products, and he even sub'd to BLFS-dev to post his comments in the ongoing thread. In the past, we've had the assistance of Debian maintainers, Gentoo devs, and even the Redhat guys and gals. All have been great to work with...it is just the nature of open source. Please try to keep this in mind in the future. > PS. Merry Christmas. > Back at you! I hope you had a wonderful Christmas, and enjoy your New Year's celebration. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
very old FHS issue
Just a quick note so that it is not forgotten. Fixing an issue in my logging scripts, I just noticed that sysklogd installs to /usr. This can't work as syslog starts in runlevel 2. Need to change install instructions for sysklogd to 'make BINDIR=/sbin install' and update the bootscript. I honestly don't know why I hadn't noticed this before. Will bug it later and get a fix in soon. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Mangement
DJ Lucas wrote: > Gordon Schumacher wrote: > >> Indeed, I'm not even attempting to address that yet - for the >> immediate moment, just getting each package's files isolated into its >> own tarball is such a big first step that I'm willing to deal with any >> changes that need to be made to install those packages. >> > > Yeah, it's a little bit of work, but not all that bad. In my 'vision' > of the perfect balance between packaging and being PM neutral, I've > chosen to create a /packages directory and use it as the working > directory for packaging and installation. I've divided each package > into 3 parts: build, install, post-install, and used scripts for each. > It's a first attempt so be nice! It *can* be streamlined... > ...like test suites run after install. Still some cruft in there from that in the cleanup section of build.sh for each package. Anyway, group of scripts is put up at http://www.linuxfromscratch.org/~dj/DESTDIR-LFS-6.4/ and a tarball (if you really want it) at http://www.linuxfromscratch.org/~dj/packages-6.4.tar.bz2 I must say that new system is a lot faster than my normal build PC. I think I'll try to make it catch up to my dev system...give me another box ready for alternate directories anyway. OK, back to Gnome for me. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management
Randy McMurchy wrote: > > I realize I could keep my old logs from packages I've since removed and > replaced, but I'm wondering how others do it. > I didn't...hadn't even considered it when logging installations. I've since moved to DESTDIR so my latest logging scripts were destroyed (but I'm pretty sure I still have earlier versions on my mail server). Anyway, I'd make the installation (removal by upgrade) a part of the logging tool, in fact that was exactly how I handled upgrades in my previous tool. In the event of an upgrade, it wouldn't be a big deal to compare line by line (grep by output of cut) the old log file for files that do not appear in the new, then check to see if they still exist. If you use rmdir for directories when removing the old version of a package that you intend to upgrade, you could simply ignore (or capture) the error when removing a directory (because it is not empty). If a dir is in the old log that isn't in the new one, and it still exists on the filesystem, then it should be appended to the new log file. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
Matthew Burgess wrote: > On Fri, 20 Mar 2009 08:04:45 -0600, Archaic > wrote: > >> On Fri, Mar 20, 2009 at 04:55:15AM -0600, Matthew Burgess wrote: >> >>> # type [ >>> [ is a shell builtin >>> >>> # type test >>> test is a shell builtin >>> >> If this is true for all sh-compatible shell, then I concur. Haven't >> tested it, though. >> > > I can't see anything specified in SUSv3/IEEE Std 1003.1, 2004 Edition. > dash(1) and > zsh(1) say that they contain builtins for 'test' and '['. > > ksh(1) and ash(1) don't seem to mention those builtins, but tests on my > Kubuntu > host suggest they are supported. > > Given that LFS only installs bash, does any of this matter? :) > Not if you go and change the schebang on all of them to say /bin/bash. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5
Bruce Dubbs wrote: > I am proposing that we release LFS 6.5 in the next week or so. We really > haven't made a lot of progress on the main issues of the targeted 7.0 > release, > but there has been good incremental progress on the routine updates of > package > versions in the book. LFS-6.4 was released last November. > > I've created a new 6.5 milestone and put the tickets that appear to be > appropriate for a 6.5 release in that milestone: > > http://wiki.linuxfromscratch.org/lfs/query?status=new&status=assigned&status=reopened&group=milestone&order=priority > > I've already fixed several tickets that seemed quick and the others should go > fairly fast too. > > I'm proposing that the now current 6.5 tickets be fixed in the next week and > then release a 6.5-rc1 around May 24. Then we can target a full release for > somewhere around June 14. > > Comments? > >-- Bruce > OK...The what happens for BLFS? I'm guessing BLFS-6.4 will be a no go, and BLFS should be targeting current SVN? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
hdparm used in current book
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. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5
Bruce Dubbs wrote: > DJ Lucas wrote: > > >> OK...The what happens for BLFS? I'm guessing BLFS-6.4 will be a no go, >> and BLFS should be targeting current SVN? >> > > I would think that is reasonable. > >-- Bruce > Ok. Rebuilding again. Scripts should still be good for as far as I am ATM...just double checking build times on current tool chain. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: zdiff problem
Bryan Kadzban wrote: > (Does that actually help? :-) ) > LOL I started to do the same, and then I read what would have been posted about half way through, and said the hell with it. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: module-init-tools --enable-zlib-dynamic
Tobias Gasser wrote: > Gilles Espinasse schrieb: > >>> i don't link anything static. i move all .a files out of the library >>> path if there is a corresponding .so available. >>> >>> excptions are the modutils package (which require libc and libz to be >>> linked static), and sysvinit (libcrypt) where i copy the static >>> libraries back during the build. >>> >>> >> that's no more true concerning libz. >> On module-init-tools-3.8, there is a new --enable-zlib-dynamic parameter. >> insmod,rmmod,modprobe are much smaller without static libz. >> > > should we add this option to chapter 6.48.1? > > probably with some comment about /usr/lib must be on the root partition > to be able to access the tools during bootup. > And I thought that I had been complaining on this long enough so that we would never violate the FHS again. ;-) Even as rare as a remote /usr mount is now days, libz really must be moved to /lib if anything in /bin or /sbin links against it if we are to follow the FHS. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev 1.42 : vol_id missing *SOLVED*
> 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 of RPM or DEB. > > Static linking for this is OK with me, but do we know all the packages > that use > libuuid? > I think like 142 packages was what one of the RH guys had. My main dev PC is down so I can't check right now. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Util-Linux-NG-2.15.1 vs. e2fsprogs
Matthew Burgess wrote: > Once 2.16 comes out, we'll have to figure out how to prevent e2fsprogs from > building & installing libuuid unless they also have a release relatively > soon. > http://www.linuxfromscratch.org/~dj/e2fsprogs-1.46.1-system_libs-1.patch or http://people.ubuntu.com/~scott/0001-configure.in-add-disable-libuuid-option.patch -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Util-Linux-NG-2.15.1 vs. e2fsprogs
Bryan Kadzban wrote: > 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 with udev-141, but I doubt people will go for that.) > We could also add libuuid from the released e2fsprogs into the util-linux-ng build. It's really not a big deal. Once I have a working system again (tomorrow morning), I'll do it. I've actually already done it from ULNG git, but that diff is huge against 2.15.1 because they moved both uuid and blkid to a /shlibs sub dir. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New BLFS Editor
> Hi all, > > I'd like to announce that Guy Dalziel has accepted a position as a BLFS > Editor. Guy has been regularly contributing to the various LFS mailing > lists as well as sending in patches for the BLFS book. > > Guy will make a fine addition to the BLFS team and I encourage everyone > to welcome him as the newest addition to the editing team. > Excellent! Welcome aboard Guy! -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc-4.4 configure options (for hlfs / native builds)
Robert Connolly wrote: > LFS is using --disable-decimal-float, --disable-threads, > and, --disable-libgomp with gcc pass 1. I've noticed that if I do not use > these options the build of gcc pass 1 will be much longer. > > I would like to know what affect these options have on building Glibc. Is > there zero advantage to building decimal-float, thread, or gomp support in > gcc pass1? > > robert > No time to find in archives ATM...I'm late, but 10/3/2008 from my local archive. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gawk-3.1.7
Matthew Burgess wrote: > I don't mind adding it to 6.5 though, if the general opinion is that it > belongs in > there. I've no educated opinion on this, so I'll offer a question to qualify it. How likely is it that, or how many other, undiscovered packages would have the same problem? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Library requirements for Linux Standards Base
On 09/19/2009 11:29 AM, Bruce Dubbs wrote: > I've been investigating the Linux Standards Base core specification. > > http://dev.linux-foundation.org/betaspecs/booksets/LSB-Core-IA32/LSB-Core-IA32.html#REQUIREMENTS > > 1. Looking at the required libraries, I see that libncurses.so.5 is required. > We have libncursesw.so.5 and libcurses.so.5. I think we may also need to add > a > symlink: > > libncurses.so.5 -> libncursesw.so.5 > > I don't believe that will work. IIRC, although the tests themselves were actually broken, they depended on the narrow :-) version of ncurses. Might not be an issue now days, I don't know...have to do a full test run to find out. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Standards Base
t can be met with any of the MTA packages in BLFS. > > ------ > The sendmail scripts provided by other MTA's would probably be acceptable, however, I am not entirely sure of this. Probably have to run the test suite against each of them to find out. It may be that we'd have to modify postscript (what other MTAs? Courier is no longer included) to not install over the existing ones. > Comments and discussion are welcome. > > I certainly hope so! :-) -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Standards Base
On 10/27/2009 12:16 AM, Bryan Kadzban wrote: > Noting which programs are needed wouldn't be too bad. Moving a lot of > them into LFS, I wouldn't like. Most of the stuff you mentioned is > pretty rarely needed in reality -- or at least, on my system, which is > mostly all I care about. Obviously this is a bit of a skewed > perspective though. :-P I agree...abut having them noted, not moving them, and making an effort to support it. I'd also like to see the boot scripts dynamically allocated (dependency based), as it is one less list to worry about, and should a BLFS package install it's own scripts, we no longer have to worry about maintaining our own for it (cups for example). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An important typo in mpfr
On 11/18/2009 02:47 AM, Uwe Düffert wrote:
> On Tue, 17 Nov 2009, Bruce Dubbs wrote:
>
>> The . after find is also redundant.
>>
> Well, depending on the version of find... The one from (current) MacOS X
> for example requires the '.' (there is no --version, but 'man' claims it
> to be the BSD version and a superset of what IEEE 1003.1-2001 ("POSIX.1")
> defines). Therefore I'm voting for leaving that 'redundancy'.
>
> Uwe
>
I agree, just because you can, doesn't make it a good idea to abandon
well recognized syntax, for something that is not portable. For
instance, we still use -{z,j}xf for tarballs when neither the -, nor the
{z,j} are required on any fairly recent tar (I'm pretty sure that our
host requirements, by rough estimation, exclude any distributions that
shipped tar-1.13).
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: An important typo in mpfr
On 11/19/2009 9:54 AM, Bruce Dubbs wrote: > > Actually, specifying Gnu tar options without the - is only supported for > compatibility with other/older tar programs. > Seems my facts were not. :-) I had thought I had used short options on an old Xenix box that I had brought back from the dead recently, hardware from around 1987 at best guess...maybe a little older, box was a 386-DX. That was actually a fun project, a box that had given 20+ years of service shows up out of nowhere, guy just called one day. I have no access to check now as everything was migrated off and sent to the trash heap. Anyway, thanks for the correction. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Bootscript sequence
On 12/02/2009 07:09 PM, Walter Webb wrote: > When I shutdown or reboot with a mounted nfs filesystem, it cannot be > unmounted. Now that I have retired, I am more inclined to investigate > irritations. It appears that the K?? links are all executed > before the S?? links. /etc/rc.d/rc[06].d/K80network gets executed > before /etc/rc.d/rc[06].d/S70mountfs. It takes some time before umount > gives up. > This is correct. Take a peek at /etc/rc.d/init.d/rc (runlevel control) to see how the scripts all work together. For your specific problem, what you are missing is the netfs script provided by BLFS, which is responsible for mounting and unmounting network filesystems at boot and shutdown. http://www.linuxfromscratch.org/blfs/view/svn/postlfs/netfs.html -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Boot messages
On 12/28/2009 03:33 PM, Marc Ferland wrote: > The logo is displayed correctly during kernel booting (I used the "quiet" > option on the kernel cmd line). But when I switch to the real rootfs and > start /sbin/init I see all the messages from the different init.d services. > > Is there a way to remove these messages? Maybe by redirecting them in a > log file? > > Not a built-in way in the scripts, however, take a look at the runlevel control script (/etc/rc.d/init.d/rc) and maybe you could redirect it to null there. If you want logging, the root filesystem is not writable in sysinit until after the 6th script (mountfs) has ran, so I'm not sure exactly how to deal with it in your setup. I kinda doubt that the initramfs can be abused, but maybe. Take a look at the rc script in the contrib directory for the LSB-V3 bootscripts (warning: I never finished them so they might be ugly to read...also the entire set was broken because of changes to make them not distro specific which I also hadn't bothered to finish...really I will). A tempfs is mounted first thing to enable boot logging, but you need to take into account the entire script as I put in a couple of simple tricks (which escape me ATM) to get the time correct for the log files, and then a dump and then switch to real log files after sysinit finishes. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: lsb-bootscripts maintained?
On 03/10/2010 05:11 PM, Robert Xu wrote: > Hi all, > I've been wondering if the lfs LSB bootscripts are being maintained, > since I want to use them and integrate them with plymouth for a > bootsplash. (I have no idea how to do this, any tips would be great). > Are the bootscripts being maintained? > Unfortunately, no. I haven't made changes to them in a long time and they are currently broken with the distro config file. Probably a fairly easy fix, but I just don't recall what was broken and haven't had the time to look into it. I do plan to fix them, but when I will have the time is currently unknown. Anyone else is perfectly welcome to hack on them, supply patches, etc. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Note about include-fixed and limits.h
On 03/18/2010 02:05 PM, Bruce Dubbs wrote: > Chris Staub wrote: >> On the Chapter 6 GCC page, there is this... >> >> Note >> As of version 4.3.0, GCC now unconditionally installs the limits.h file >> into the private include-fixed directory, and that directory is required >> to be in place. >> >> I don't really understand the necessity for this. I mean, I certainly >> know what it's saying, but why does it need to be said? In other words, >> who is this note targeted to? I'd think that anyone who would be likely >> to know that directory even exists (really, how many casual users - or >> even LFS builders - regularly inspect the contents of /usr/lib/gcc?) >> would already know that it should be there anyway. >> >> If this note does stay, it should also give at least a quick explanation >> for what include-fixed is for. > > That note was added by DJ in October 2008 in response to Ticket 2229 > created by Randy. > > http://wiki.linuxfromscratch.org/lfs/ticket/2229 > > I'm not sure the note really adds anything useful for LFS. Randy or DJ, > would you like to comment? It doesn't really add any value now. At the time it was introduced, it was a change in the new version of GCC that required a few patches in both books...put there mainly to guide as to what might need fixing in other packages. Even Glibc needed a patch at the time. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LSB Bootscripts are up to date
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Got some free time tonight. If anyone in interested, the LSB style bootscripts are up to date and working as expected. They require Dan Nicholson's initd-tools-1.3 which gets us one step closer to LSB compliance. Existing bootscripts will work, but all scripts (LFS and BLFS) must have LSB headers (comment blocks) added to the top of the script in order to meet LSB, and dependency information must be correct on all scripts. The ones that I am currently using are done in BLFS SVN. I'll be working on more BLFS scripts as time permits, so expect some of the dependencies to change a bit. - -- DJ Lucas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJL17pnAAoJEIUM+xKzBYsI4U8P/RwosZVtDbqWLTK4LH/cHHb8 e7/rH61PgFGGUpBqb6KjqBsBVkGjx8YT8+FEXTVxQH3GU8cf/pFXLZdAlPEYuOh3 QVlCk9bgaydcKybs8BL2Zq8PDSSaHxpPgHLD0aF1jvAbZrpAhhmxAP9h6cGo1CsT 8CAqYC8rGskbiLTbkzSmBG2NLmeVZuR7thsueaz9hFrziQRsIEOJ/I3OxiFLnygF 4DVdmJm+zBnfiLCrq1FSTf6s4BZwCqQ8cvb9XgE4USN3qJApiav75c1/pW/3sKPP OZVYEZMP14s1lqzA9srUN68HHaIZ7NqBaBqUKmhfCIH1oE8ZLljZ+8vuUyDwm7yh RVoIokhZ9uq8LryV0ltlT24Ef6op+efraU2/eB+maQaNlEMnMQGSc76CJKAP04pU NMtElEDUmIlxg20pxqmBMu2aoyXxcA5wnX/jMEvNSDW6nWYFoifMvfluQ5qy8bah 1nJLfLunLyTjHCrg7mMNhQ6oWNYAXsZa0LKgxKNO/9EG1G2fsHBh9cAydoEeUd2J nLb7svnz4wKeu1sYaw1Kvlz6rOGAG9uf0thUWb27JvBN5vBPXD10zlBsI3PT7/fW rrh7oTErtxMSd4+lQl9nQo0e5/nCMEcmAHARvrLRpZEfdUE+fbQxJByu3DDeV9pq ewoyQPvONIblsZDUlPqh =iKsO -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS-6.6 - Old bug in bash has returned
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can someone confirm? This was an old bug that seems to have returned in LFS-6.6. When you use color escapes (or presumably any other escape sequence), the count is added for the total of all columns, followed by line wrapping overwriting the prompt. I don't know a better way to explain other than showing: I like to use red for root (to make it explicitly clear that your are working as root!). Added the blue color to make it easier to reproduce and managed to make it even more of an annoying problem: r...@anu:/sources/lfs-bootscripts-20100527 $ echo $PS1 \033[1;31...@\h:\033[1;34m\w \033[0;39m$ r...@anu:/sources/lfs-bootscripts-20100527 $ ls ChangeLog contrib lfs LICENSE Makefile README l r...@anu:/sources/lfs-bootscripts-20100527 $ ls > /dev/null l r...@anu:/sources/lfs-bootscripts-20100527 $ echo blah/null blah r...@anu:/sources/lfs-bootscripts-20100527 $ echo blah/null blah ls > /dev/null Removing the color escapes fixes everything: r...@anu:/sources/lfs-bootscripts-20100527 $ echo $PS1 \033[1;31...@\h:\033[1;34m\w \033[0;39m$ @\h:\ $ "/sources/lfs-bootscripts-20100527 $ export PS1="\u r...@anu:\ $ export PS1="\...@\h:\w $ " r...@anu:/sources/lfs-bootscripts-20100527 $ ls ChangeLog contrib lfs LICENSE Makefile README r...@anu:/sources/lfs-bootscripts-20100527 $ ls > /dev/null kjdlfjlfkjlksjflskjflkljlfjslkfjlsdkj ls: cannot access kjdlfjlfkjlksjflskjflkljlfjslkfjlsdkj: No such file or directory r...@anu:/sources/lfs-bootscripts-20100527 $ ls > /dev/null r...@anu:/sources/lfs-bootscripts-20100527 $ ls > /dev/null r...@anu:/sources/lfs-bootscripts-20100527 $ ls > /dev/null r...@anu:/sources/lfs-bootscripts-20100527 $ ls > /dev/null r...@anu:/sources/lfs-bootscripts-20100527 $ echo blah blah r...@anu:/sources/lfs-bootscripts-20100527 $ That is going to wrap incorrectly, but that is the way it is on the screen. In the first example PS1, the 'ls > /dev/null' is just the right length with that hostname, path, and PS1 to never advance the line with repeatedly pressing the up arrow. and leaving that trailing l character in column 80, and of course overwriting the previous command with the next. Can anybody else confirm? Or better, has somebody already confirmed and found a fix? Eratta? Does the problem exist in svn version? - -- DJ Lucas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJMCe7OAAoJEIUM+xKzBYsIvhoP/3GFz+/x1jLkUQqIe8RLEFQu LDCLt6Ppo3AOrvj9GAkzaEdZJlikDpDdWfD4DtYkQ37Ve2T2RDic8kbFUidB01Tn EDhMj1qcCe/tf+3Rc9DhTfHWgsYJYPIPgL9wAyKIyhP7G2ahsKlLljLVWZ0aaTgr REGITYOzBp5hk4Ug909Y/b3lYnOevNon82baAo45bmkwAOnQJFY4dJx9w5kplK69 GE1gTkQMYdkD54BbYCFMW/I4J/SUMADjEfidx7/rtooNLRWC9jgJzsJ/BWjyirf2 09cFgQdurG240BSiz8kSX9cawX8H3/dqxT6DwyHDU5ZpKKUtxM2DEcyvuzKRBOEF 47q39zee9bUHx7xiWz/N9feJInAN8nCocRZHiVu1z/ZDKdwoDaFgF6NHnEmMjnmd pi4cM0Tr7RK0xTuHVMDP2ZJhWSAQvukJPUQxAZA5p6vPZi6KAlPeh3kl+F9ZbsQq NKOJAk/NGi1YxXMLkM6Ygn96Lap+VXHLHRwSnIhVWsSOoVXs20H4lYaYrhRoJVMr 9qZYP4xVh1xKbSytsHNEoMbzrxGAkLO7czhxJJT2HejHk/hBAP24g1PIYTkQO+Av LrrZC3fm8CzTO2dCTcOE0I/im3r6kCD3Dy5ka/Nr6qIipGlNa4Qi95XfhezN/U+7 V5kcDsJS3GI8UtvlyQ0Q =p5qp -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.6 - Old bug in bash has returned
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/05/2010 04:28 AM, Gilles Espinasse wrote: > not a bug > I fixed the same mistake in our prompt 2 years ago > you have to escape with \[ \] the non printing characters Thank you Giles. Taken directly from info bash -> Shell Variables -> Bourne Shell Variables -> PS1 (for which I've probably skimmed over 20 times trying to figure out if something had changed): `\[' Begin a sequence of non-printing characters. This could be used to embed a terminal control sequence into the prompt. `\]' End a sequence of non-printing characters. I had thought about posting to support, then thought "No, this is an old bug." I'm not sure, maybe I've always just copied the previous version's profile items, but I've never noticed this. Anyway, completely documented and certainly not a bug. Thanks again. - -- DJ Lucas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJMCl+JAAoJEIUM+xKzBYsIu3IQAOTt/zZVcMasLXRKSL1lEOkq Bw4dDvSIqCERmBG9h+XTy9pi61VYmQx4jrG+2scheTOeknC6FqrVE4bsLyrioSl2 g5fRP8UK0M/V3LHm7tJbQZ2BKThZchRbnjKlU/TGTZ0G+LHSnG6F0jbDosnxyerL PJ/CKRThulwUYtmo/PhbWwnK8T9Pk4Dl0FZ8SLeFtDHtgtJ6mK39XHwyJ6TKPATM xqbEFn4umFCgHeE139AQkHa6QUYTt0Jn2z/ozkE1v6VpP2N/AJo/Fb2E7RWTwiVu bSmvSMzMdDe5DzfmAGptZpmh7YMcmK70sPb4SE0lvXxJFkjiS/LQ/HUNH6P1o45r UOGHFeXXLXsvozjSKSIyaS8h/3kihFwvu3ok4D9V1V99w+4IwXdRTaHOHu/iHKfq qB/qEn9O6TKWpTGmNTVrjvwrvoeSi9pIAKprjAR/ecGsHKSnC+nBCy0X9Vd5YQ8/ pwZX6EDaaCgQZ7d3vm3otEwtdEFj2ObhhSQU1h0LvmKVQbw2wdC7lgC+UwYNzzSY tZ/6CuMYMRBbCCgDC9F+MFVuovrrmRCz5kVR9tENpWtaOnG2dXeJ//WYWhe9ltda rJhkRpNz90NEqo7oWROfyVZCPrWF4/Or/4p1KJeDl9qaZH7/wggiVyeOWjpS/lkZ hOuiveHMCtn5PKjlT40F =wE+X -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
BLFS - Target 6.5 or SVN?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The last decision was that we would prepare for BLFS-6.5. I personally have no interest in working towards a BLFS-6.5 release, but others may differ. We could create a branch if there is still interest in continuing along that goal, and now would be a good time that Gnome is completed and deemed stable. I'd like to start working on current LFS-SVN. I haven't committed anything in so long because of this and it is about time for a new desktop build. Still working on my testing server which is somewhere between 6.6 and current (some package updates to 6.6) so I can commit to cyrus-sasl, postfix, openldap, samba, php, mysql, openssl, httpd, dovecot, etc. I do not see that anything will conflict with current SVN and I'll want to do a rebuild before it goes live anyway. Regarding Wayne's question on -book about Gnome...3.0 is due on September 29th, but it's probably a little bit early to start targeting the 2.31 stack, but feature freeze is on August 2nd, just over a month away. http://live.gnome.org/TwoPointThirtyone/#Schedule By then, I think BLFS will likely be completely freed of gconf, and should already be free of bonobo. An update to 2.30 probably wouldn't hurt and then a decision could be made for 3.0 as to a BLFS release, but I'd hate to see all that work go into 2.30 with 3.0 so close to the LFS release. Also, Wayne, is there any interest in the $GNOME_CONFIG approach to the Gnome distribution? I'm specifically interested in the shared libexec directories for all of Gnome. - -- DJ Lucas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJMJlcfAAoJEIUM+xKzBYsIj2cP/1pvfGN8wkytArGiIIwTaENm aYAy+NpmzPQmIIIgKohE3MEWUtSwiese8jLwcv0JEsv6GCkgZPpDrsFN0RfeIgqJ auK9mfje//vSoeP8xV9qnmIh5/UAXOIZqksuMuNl1KYYW5kDrN/fSDGoZ84/Jfv1 Md0yxvSxRWGyWEc2mkKyEzauvudCOlE87BREv7i9/NZFP5ULvLwB6BHmE0cK6jTM MSFsYha4/Swd4W0Ha7UDGtXYnp1EobvOYsWVaeg3K/J9AP7cu7P9iu0or6yCgbJ9 /f94azDbEJgYdsyaA612VmNgvfd7xNt3Ddq3hoWSEmXSApq203eCg9BllTMa3mQF 7bBQ9WSSLg4rhucGVcxVauA+4Xd4GTy8HV4kwxi/5xM0GOscuZloBiXMAkYAApuV 0m3YHlOxILOZU9bc7BsxdGUfCTeobcYKzLMqYPWdAKuh36bMKzr2rHrfvNVg33wg Ybq1w/2aNPlBjE/D6lNunzKHNb8M+eBzSjJ9GHctIw5c4ie9bnMh/oj322/yzAy0 FFpIHrY+FZSGLpy3mIelGi+uJbCdq8C3xhf0w+7MtCShk5qqCZY06zTgaBGI8HS9 jXoCrhjQEnFdhdrxSUMQ5cP1oATHkDALzcU0dWLJR1LEyzhQYDQ263HHmVnQBNTM xwRsax25pdHNaH+0Oxh1 =34/i -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: System LinuxPam configuration files
On 06/27/2010 05:15 PM, Bruce Dubbs wrote: > DJ Lucas wrote: >> Any interest in that failsafe in BLFS? > > For me personally, I try to avoid pam completely. It just seems to get > in the way. I think it stems from the days of using rsh and related > functions when today ssh, sudo, and iptables can do the same thing in a > much cleaner way. Yes, PAM certainly has its difficulties! Anything to simplify the maintenance burden a bit, even if it's a little more complex in the default configuration, would probably not hurt. But I'm still thinking no on the failsafe in the default config. I'll drop it into the wiki for those who want the extra hand holding. :-) OT: I wonder if nss_ldap, winbindd, and mit/heimdal alone could do what I'd need, trading the complexity of PAM for that of the more secure, but less understood (by me) Kerberos. Kerberos eliminates the shadow headache anyway. That would leave Cracklib as the only consumer for PAM on the server. Heimdal can work with Cracklib directly (MIT?), but I'm not sure how granular you can get with the complexity or if there is a built-in way to set/meet complexity requirements in either Kerberos implementation. So, yeah, the servers _could_ do without. Unfortunately, PAM comes back into the mix for the *nix clients, else a lot more compile time (which probably doesn't come into play very often in distro land). Something I'll have to toy with later (much later). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: SHA512 passwords in shadow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/28/2010 10:20 PM, Bruce Dubbs wrote: > We probably need to also mention: > > # Note: If you use PAM, it is recommended to use a value consistent with > # the PAM modules configuration. > > Other opinions? > >-- Bruce Despite the comment in login.defs, that is not necessary. In fact, PAM also adds support for bigcrypt (DEC C2) and blowfish encryption in the shadow file (as long as crypt() supports them). The passwd program is going to use whatever value is handed to pam_unix.so in the /etc/pam.d/passwd file. This bit is an error in BLFS. ENCRYPT_METHOD should be added to the sed for login.defs at the end of the shadow instructions, and the first sed removed. Just a quick test to show the above in action, I thought the comment was wrong (thinking of blowfish), but had to verify quick: dj [ /media/lfs ]$ sudo passwd dj New Linux password:<- "password" Retype new Linux password: BAD PASSWORD: it is based on a dictionary word passwd: password updated successfully dj [ /media/lfs ]$ sudo grep dj /etc/shadow dj:$1$GHXqyIJ5$LSPJqqMrJnW29KRfJmBD20:14789:0:9:7::: dj [ /media/lfs ]$ sudo sed -e 's...@md5 @sha512 @' -i /etc/pam.d/system-auth ## this is not standard yet, but /etc/pam.d/login includes system-auth on my system dj [ /media/lfs ]$ sudo sed -e 's...@md5 @sha512 @' -i /etc/pam.d/passwd dj [ /media/lfs ]$ grep "^ENCRYPT" /etc/login.defs ENCRYPT_METHOD MD5 dj [ /media/lfs ]$ sudo passwd dj New Linux password:<- "password" Retype new Linux password: BAD PASSWORD: it is based on a dictionary word passwd: password updated successfully dj [ /media/lfs ]$ sudo login name51 login: dj Password: dj [ ~ ]$ sudo grep dj /etc/shadow dj:$6$wvESC6TO$4BUZxy6FKKleNcsn2MFF2pdPucYVV/JlvrdwO.li4gUZeTnQPl9rZ8RhI.Lik79DWvFMua5LVaf5kQVC3dM5M0:14789:0:9:7::: dj [ ~ ]$ exit logout dj [ /media/lfs ]$ - -- DJ Lucas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJMKXJAAAoJEIUM+xKzBYsIq2wP+QH7q+qVQLm/a/we6C8A78vA xA7IrZDbposY5AsxxgWAnl1IrBDf19wj7+OOYygN+DXp+GHtVkFzew9U0M4CS44W G/mmXJcuiOw0PyqWKJHWnbXAOpThJpALIDWZ3COsclCvp4uiaOnWv1xjaPZq7lcV E2+59IK+4VN19PiRvTa6VHfo8ohFwugKLFZm2YDq0MxKb0FO+YG7AUwFUcZLXPCA s6Iv3gy+RNXdOwhl63Fdz8My6GScl/FMkV4BqFZN+KhcBG6YEBKDX9lQbN1wB9hK ZgfoUfcPPw5QNElgsXL79wIFwQxL4d5y60LWt9S8Tg1wU91d3jGbgkYXrH11dQuQ xgcZeNcRHwIjtB3HUNW7cqdaclN46s6eFr0+bzcrBc2XoqXudZO2ZZLd9PTmMDiZ u9UwlgdB2KtvKUNEu2Z1nbK/qTcjWT6MaCLkWH3K3n8U74T3i0znDTROL8JUQkdj LsDY7T0PkETf+roDDrVujUqZBFmV8s4CpsrT0PHAHhhSq5/7qKOiHLu6VAwRrm6k su5e5AM1V0LylWy1C2B9wAUGbI1+peDAEcZoDYAUz4KHYcHT3UoQnNGi/454k1FB 71GCNFJJjE0puaEqayGZjY0nGnzzteR0r9AUX2k09Hy9F9zlif2gsDiYhwe4FCFq pyAJbuW2P4nHW07NT0v/ =upfx -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SHA512 passwords in shadow
On 06/28/2010 11:10 PM, DJ Lucas wrote: > On 06/28/2010 10:20 PM, Bruce Dubbs wrote: > >> We probably need to also mention: > >> # Note: If you use PAM, it is recommended to use a value consistent with >> # the PAM modules configuration. > >> Other opinions? > >>-- Bruce > > > Despite the comment in login.defs, that is not necessary. In fact, PAM > also adds support for bigcrypt (DEC C2) and blowfish encryption in the > shadow file (as long as crypt() supports them). OT: Just for good measure: http://pasky.or.cz/~pasky/dev/glibc/crypt_blowfish-1.0-suse.diff -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysvinit --> Upstart?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2010 03:46 PM, Stuart Stegall wrote: > [SNIP] > > I think it would be a wise plan. Someone can of course try converting > all the base startup jobs over to systemd. It might be wise to > mention upstart/systemd now that it looks as though most of the > distros other than openSUSE are at the least going to be on to > something else. What advantage do the alternatives give us? I seen something about event driven...sounds complicated. As they are now, things are quite simple, with the most difficult task being keeping track of the links (which I've been working on automating following the LSB standard). Do scripts contain dependency information? If so, how about using the LSB comment blocks directly to kill two birds with one stone? You mentioned event driven scripts? How do they work? How are events generated and interpreted? I'm assuming another daemon must be running. Do client apps needing services also have to be compiled with support, or is there something akin to inetd/xinetd running the show? Lots of questions unanswered so far. A proof of concept would be the best way to start. At this point, the "advantages" haven't been explained, and I have no interest in reading some dry documentation without some expected advantage. Give me that "WOW" feature that makes me want to read, and I will. The best way to do that, and to gain an understanding of it at the same time so that *you* can answer questions, is to do the leg work to prove to all (yourself included) that one of the alternatives is better than the current boot process. We have a wiki available for your use. The hints site is also still around if you prefer plain text. You could also host instructions on your own website with a link sent to the list, or even just send a text step by step to the list. As long as the advantages *and* *disadvantages* are covered we'll take a look. OTOH, don't bother sending in anything if you can't objectively list disadvantages as well as advantages, as nothing is without flaw. HTH - -- DJ Lucas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJMM7m7AAoJEIUM+xKzBYsI6dIP/0tACteQDgpTTUc36btLemqk oH30pmI3kq+qWbPZhIr3yb2DddUhQPTdNdib+kantx+TwOTOVO7B3QE011ceMChv FTsX+OGFMwAxorF51WDTE87ejo8YkG8Krfm04kuvftqUkTMaYLfVHi9UWFXsOi6y 2TT5OXDhCY9WtChykGQBguYXlKAjG00Lku+5efURyetNhL7seXsi8NlR3vP2hI4W WY9UJijq4IegcPPOfNy6kU4MTrDQT3GQ4Z7wqvPZ7nwBXo30wWq13PJQcf0TYaXY ZxQ9aRGPADZ4RRBHQZb46cFHnEY3kg5Ju+XYjlNmP5Kg2LCVBg8quMmnm9xqLaZk zYMT6WynXqUheg2dfseNgPWoNPr7BghVPQHJ6Dx73JpGwsMH9btJBHfkskvy8InL Jv97ax5PQhD5MMsi38Vs6qywTvT4F9X2cZnsgcPOZ8bYP7gpIrusYYN+3xQReHeJ PASvoTpxX5AmCFyQDnhDLdUZNVdHqDv7yBm9z4o7+rYEPRDBKU83aVeyfM58MJxt TZxjm3y+ip6tByRo0BZRWcvQQz178UR3kZF5ekMIm2W5LR+X0qcEf9D2rMztAs5D f7IeixflehJcC5DBL8qreifHjkUrlaryvrcV/HoEigudAwKqjw8SsaeIO+BEYt3J Naa2R6W4cxVUVR4XqoT/ =PnVS -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Consider adding in Cloog-PPL and PPL
On 07/19/2010 08:59 AM, Andrew Benton wrote: > On 18/07/10 13:56, Jeremy Huntwork wrote: >> There's a fix available here: >> http://www.cs.unipr.it/pipermail/ppl-devel/2010-January/015872.html >> >> I've added those 4 files into a single patch here: >> http://dev.lightcube.us/~jhuntwork/sources/ppl/ppl-0.10.2-upstream_fixes-1.patch >> >> After patching, you still have to run 'autoreconf -f' as per the >> thread listed above. I suppose you could create a patch after running >> the autoreconf if you want to avoid that command in the future. >> > > Ok, I've made a patch which doesn't need aclocal or any autotools. > Unfortunately it's quite large (over 3MB uncompressed). I think that > even compressed it's too large to attach. > http://63nt.supanet.com/ppl-gmp.patch.xz > > Andy I don't think all of the Prefix stuff in the makefile templates is necessary. Also, I'm not sure why aclocal was failing for you, I thought it should just say that it's not there and then use whatever is in the missing script for a fallback. Also, for future reference, your diffs will be quite a bit smaller if you use a local copy of the original versions used of automake and autoconf. At anyrate, since much of the internals of the auto* tools are a black box to me, I toyed with it for about 2 hours tonight and generated a few diffs. There is a subproject "Watchdog" that you have to account for as well. Using the same version of auto* as the original file and accounting for that sub project gets the diff down to 572KB with everything generated. http://www.linuxfromscratch.org/~dj/ppl-0.10.2-upstream_fixes-1.patch Being a little hacky and removing aclocal.m4 and Watchdog/aclocl.m4 in the original before diffing makes a 160 KB patch that works (but you have to remove those same files before applying. http://www.linuxfromscratch.org/~dj/ppl-0.10.2-upstream_fixes-2.patch However, I'm pretty sure all you need is the original patch and a newly generated copy of configure. Those PREFIX's are not used AFAICT. I think at that point, anything that is needed (and not present on the system) will be covered by the missing script as distributed. I moved all of my /usr/bin/auto* files out of the way and was able to compile and install fine, with a few warnings and another forced run of configure when starting make. This gets it down to a livable 70 KB. Can somebody test with this one next time you rebuild? http://www.linuxfromscratch.org/~dj/ppl-0.10.2-upstream_fixes-3.patch -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Consider adding in Cloog-PPL and PPL
On 07/19/2010 11:36 PM, DJ Lucas wrote: > On 07/19/2010 08:59 AM, Andrew Benton wrote: >> On 18/07/10 13:56, Jeremy Huntwork wrote: >>> There's a fix available here: >>> http://www.cs.unipr.it/pipermail/ppl-devel/2010-January/015872.html >>> >>> I've added those 4 files into a single patch here: >>> http://dev.lightcube.us/~jhuntwork/sources/ppl/ppl-0.10.2-upstream_fixes-1.patch >>> >>> After patching, you still have to run 'autoreconf -f' as per the >>> thread listed above. I suppose you could create a patch after running >>> the autoreconf if you want to avoid that command in the future. >>> >> >> Ok, I've made a patch which doesn't need aclocal or any autotools. >> Unfortunately it's quite large (over 3MB uncompressed). I think that >> even compressed it's too large to attach. >> http://63nt.supanet.com/ppl-gmp.patch.xz >> >> Andy > > I don't think all of the Prefix stuff in the makefile templates is > necessary. Oops...meant to add "unless building inline or multi-lib." For our purposes it isn't. Standard locations. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/24/2010 10:23 PM, Jeremy Huntwork wrote: > I set up a redmine installation on quantum. It has all the latest info > merged over from trac (well, from earlier today), and it has a new look > based on the design I showed earlier. It automatically created users > from the accounts/emails it found in the issues, and many of you likely > received a notice about that. > Yes, received my login information today without notice and was like WTH?!?!?! :-) > It's here for now: http://community.linuxfromscratch.org > > I personally think this would be a nice replacement for both trac and > the main site. Anyway, I've given it a little run through, and I like it. My first impressions are good. I love the layout! It's clean, modern, and it seems to be quite a bit snappier than Trac. I especially like something that is kind of silly for most of us...probably one of the least used features. Tickets from all projects show in the My Issues module. Single sign-on (for the projects) is nice, as well as having names as opposed to email addresses or user names for assigning tickets. Overall, I like Redline (and the current theme) very much. Some technical questions: What is the authentication method? Can it be used for system accounts as well or can it use the existing system authentication? You had mentioned giving an existing Redline users commit privileges. Can it create a system account from the existing user, or does the SCM (Subversion currently) use the virtual users? Really doesn't matter for my usage, but I can see it as helpful as the project grows for the admins. I see that LDAP is an option, so in that case, certainly you can, but how about with flat files? I also noticed three things I didn't like right off the bat. First, we are using http. At very least, we should listen on 443 and get a free certificate that is trusted by Mozilla out of the box (since that is where BLFS get's its certificate store). I personally use StartCom. I realize that has been an outstanding problem for a long time. Second, setting a resolution in the ticket does not automatically close the ticket. Third, e-mail addresses are not hidden by default. I'm guessing that both of the last two are probably globally configurable, are they? Didn't see anything in user preferences...or any user preferences at all beyond the my account page. What additional features are available? Actually, I just found how to retrieve the RSS key so need to ask about that now, but it is an added feature--click on an editors name, and then click the Atom link in the bottom right corner of the page. I wouldn't use it, but others may. On the same vein, how about public_html dirs without changing the hostname to www or possibly adding personal additions beyond commit messages when somebody clicks on a name in a ticket as opposed to maintaining our 'home' pages in our home directory on quantum? That would invalidate the need for system accounts beyond server admins if Subversion (or another SCM) could use the same authentication method (see above). Coincidentally, does Subversion have an add-on to download a tarball like Git? Seems to me to be correct topic while discussing server updates. - -- DJ Lucas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAEBAgAGBQJMS9YbAAoJEIUM+xKzBYsIdOIQAKDy/kL6CInEAkcVmx3fQHzG 5Bsno/6+SB6GsgESCpYfSVQfmYpoU7EPD+qiVK1z56pDCodx1itPcDuD8yTjMADI 0A4l7ZDDtmCQf329Yn/6+VkgmjgfBVKHf1ViY7SDna8kJnJqeZ7V1a3oc+f0tKMJ BfV3xEak5+bk7gkI2yuLF4ra/bTIf619zBIEs+DuvX/PjlHR2tBiOX9K2PMBi2aG Txz3Vbju917szHUcbIyLjoBsMcg/hsgCVxctaIESnRsqdxThuF8Zyk/uwqJwvX6t dAwy8jiYVHirGuJynnT9fzlkia3Zpcq6znoPIZ3KgNGANpbbcPWtwCK0O2FJQXwh PNGE/mu1G8rlk2j6Bwvw/kIEyDH1/4XHZPbqkFeCSEfQcl602Mse5UscEqncItLL 6a7UbQt0bOJR8t6Juv4c+4KmrRkGcxMSgAmvBmDmb2Ry2bP4eXVlXI1u2VIYSraO cwx4St5rJ5WjeUQu4M07480Vfbv8eNrbkaNvIJmGqqFSC4L65nnHSJQ1AcZVeaE2 KIJ8NLQxe3NsN0yJLE6WT3pALdWs4Q2hO9VFiHacSO5lsmC46WgU53f/jKkEcxzp jMagbV6zOXpsRn7JhegAOrdwL78KAjwXSavql3XGcAbVQHpQSEyGK7pXT5MXRkQY GVEK/N0mUS9vSjUXIwhF =hYAV -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On 07/25/2010 01:13 AM, DJ Lucas wrote: > Didn't see anything in user preferences...or any user > preferences at all beyond the my account page. > Err...I meant in regard to setting a resolution...of course the hide email address was there or I probably wouldn't have noticed. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2010 08:03 PM, Jeremy Huntwork wrote: > On Jul 25, 2010, at 2:13 AM, DJ Lucas wrote: > >> Some technical questions: What is the authentication method? > > The default seems to be some form of basic authentication. I haven't > delved into the code to see if it does any sort of password obscuring > or not, but as you say we could run it over HTTPS. > That would be preferable. >> Can it be >> used for system accounts as well or can it use the existing system >> authentication? > > Well it can use LDAP as you noted. Other than that, I think if we wanted > it to use unix accounts we'd have to add that feature in (or look to see > if someone out there has done it). > >> You had mentioned giving an existing Redline users >> commit privileges. Can it create a system account from the existing >> user, or does the SCM (Subversion currently) use the virtual users? > > The SCM uses the virtual user. Basically, it uses an HTTP(S) subversion > setup which has been configured to look in Redmine's user table to > authenticate users. > >> Really doesn't matter for my usage, but I can see it as helpful as the >> project grows for the admins. I see that LDAP is an option, so in that >> case, certainly you can, but how about with flat files? > > Again, it's something we'd have to bake in if that's what we wanted, but > I'm sure we could do it relatively easily. Another option is using OpenID, > which redmine supports. No. no need to modify it. Besides it would only add additional security concerns. Just would be nice to elevate someone who is a pretty regular contributor to an editor role (would save Bruce, Matt, and others? some admin work). It's not like editors are added every day. I also wonder how public key authentication would work with a virtual user. I'm not familiar with OpenID. These are probably features that would not be used anyway, I was more curious as to how it all fit together and maybe using it to streamline the process a bit. >> I also noticed three things I didn't like right off the bat. First, we >> are using http. At very least, we should listen on 443 and get a free >> certificate that is trusted by Mozilla out of the box (since that is >> where BLFS get's its certificate store). I personally use StartCom. I >> realize that has been an outstanding problem for a long time. > > Sure, I'd be all for that. > >> Second, >> setting a resolution in the ticket does not automatically close the >> ticket. > > I believe that can be configured in the workflow section. It's fairly > customizable. Actually, in issue status you can set resolved status to = a closed type, but I don't see a way to automatically modify status based on the custom resolution field. I poked around on the forums, but nothing caught my eye WRT to modifying status based on a custom field, but this can probably be done in the code. Actually, a better option, I think, would be to define what is currently the Resolution items as a custom status and set the issue type to closed for all of the above. That would probably be easiest. I'm not sure what that would do to historical data though. I guess keep both the custom resolution and the custom status types, but don't display the resolution field by default. Was the resolution field pulled in by the Trac import, or manually added? Also, currently users with the "Developer" role cannot change status on closed type tickets (for instance, reopening or requesting additional information). I haven't made any changes to the permissions, just browsing about to see what all would need to be modified from the defaults. Also, another feature request. It might not be a bad idea to add a need info status (that is of a closed type) and then add a re-opened status and allow that for only the reporter and developer and manger if type status was set to need info. This gives us the ability to close a ticket and get it out of the queue without offending the OP by setting invalid prematurely if they haven't answered a request after a few days. > >> Third, e-mail addresses are not hidden by default. I'm >> guessing that both of the last two are probably globally configurable, >> are they? Didn't see anything in user preferences...or any user >> preferences at all beyond the my account page. I didn't see anything related to default new user settings, but users are set to be BCC'd for messages globally anyway, so the option would be unneeded. I also noticed that default assignees weren't set (this would auto add to the cc list for the various sub-projects). I'm guessi
Re: Website
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2010 10:52 AM, Yaacov-Yoseph Weiss wrote: > >>> 2. Include more automation options with LFS. Including making sure they >>> work with the errata pages. > >>> 3. Include package management options, both for moving packages from >>> installation to installation, and for keeping track of installations. The problem with package management is that one flavor or the other is not perfect for everyone. I personally prefer a simple tar.gz package file. No dependency tracking or any of that. One suggestion I had made before is to use the DESTDIR method with tar.gz packaging, and go no further within the book, as that package, or rather the three sets of instructions (build, install, post-install) used to build that package, can be used nearly verbatim for all of the PM types (including verbatim for the users that like simple file lists. Here was the POC of Chapter 6 at the time, just the installation scripts, which are more than a little stale, but could be easily adapted for 6.6. http://www.linuxfromscratch.org/~dj/DESTDIR-LFS-6.4/ Others who already use RPM, have also duplicated the same work as the above, well before I did it, but the intention was to find a working middle ground for use in the book. Could even take it a step further and include the breaking up of bin, lib, and dev packages. Then it'd be a cake walk to copy and past into your deb-build, or spec, or whatever you can dream up. > >>> 4. Include several BLFS installation paths up to date. I'm not sure I understand that request. I've taken it to mean a linear BLFS. Is that what you meant? I'm afraid that the scope is far too great for that. I suppose that you could make the case to include *all* dependencies including reciprocal, and reuse existing XML, but IDK exactly how you'd go about it. I think we'd need some actual dependency tracking info in the xml source, and conditional code blocks based on those tracking items. Shooting from the hip here, one easy way I can think of would be to use specially formatted comment blocks, and a tool to pre-process the xml source before handing over to the tools to generate the completed book which would then be used by jhalfs. In fact, you could probably reuse quite a bit of jhalfs for this task. But, if I've understood the request correctly, you are asking for something to be done when we are already taxed for editors. The only way it will get done is if you, or somebody else, takes the lead and runs with it...give us a small, but working POC to get all googly eyed over first. This goes along with #2, but is only one (simple IMO, course I haven't tried it yet) way to handle it. > >>> 4a. LFS host system. Will include the host system requirements for >>> installing LFS. > > 4b. I would add to the list a basic X system. > X used to be in LFS, but I haven't put an X on a server that I've installed in probably 10 years or better. I did do a concept recently for an SBS replacement, which I'll be adding to later...likely after Samba 4 gets some more stabilization work done. > I would probably start with #2 and #3. I'll try to develop these further, > though > as this requires more thought, it won't do this on the spot. As a start, I > would > like to know what method of automation the developers use, and definitely > wouldn't mind seeing their scripts if possible. > > #4 and #5 would require coordination with BLFS, and could take advantage > of #2 and #3, so I would wait with them. > > Another task which could help keeping #4 and #5 up to date, (and ultimately > all of blfs) would be a (partially) automated test system which will at least > warn when updates to LFS cause the compiling of a later file to fail. Yes, but it'd go hand in hand with #2 and #4. - -- DJ Lucas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAEBAgAGBQJMT3eAAAoJEIUM+xKzBYsIkrEP/3qjA2zvw6xPhgecrWnYUlbw FiQtCvvn3zjhWiJAFF5JjPgp9nCw/dZ+zns04csuG41ek17s1y3PCvT/0uQqVHyk 6U7ThHnrwDWh+8Qu9U/v37us+X81YJFTiQP7hjVT5BbEKl08RUEo9Ko1Cp8BVynP WyrDqgOghYLxOFHzlPN8++43JlqbeRs0kIcoHrDsahKQer50aaRV3Vp6KgE+INoH U9u2HvT2VUStw8dOvq7sW8R8NX6n1DbwPIvlryt7HMSeRj0+cHE7yqN4j7z6RFO6 ghgtcD/lM5qLRKEZjvwRAy0cTZdtmVSCILfLjQy4pzVNrNUD9VcTXbxCc7Gk/bUt YzqhYOuDToqWxa7XhTn4a5Elg2iX9Ld36sMnSNzOjx/I3ln7OG41idyNHnwoxv3A D+/JjYU0OaJF3EO/pYzxpCVxbgl2cB19pHvXL+TO+REMXI9fyxAeiKw/WkQcA3wT 7cuWzSboyQFappny7YyTsj+afeLy852bQZNKEUZCVJIGu6Cqpw5zFP0HMKUUvXgS 3/6B4R5suN+c/ruwukqtnipLt5RyurUoN+BDJ1LLj6HLe3sPb2GApH+o9oTD/4dk Hqt0eUhRHRFOFCACq6e2hTgy9TkehFTez2hOpyhHeb8cH3Hr5cPEUrmkThoJ31Kg 4uRBg2ldHxU2X64oOQrH =CDol -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: How can I contribute?
On 07/30/2010 07:33 PM, Randy McMurchy wrote: > Ken Moffat wrote: > >> Just for the record, BLFS is still targetted at LFS-6.5, so build >> instructions >> should be appropriate to that version. > > That should probably change now. I'm not sure any active developers > are using 6.5. I am open to suggestions, but I feel BLFS may need > to just simply target the LFS Development book. Anybody who could > contribute some alternate ideas would certainly be helpful. > I actually believe that it was Ken who mentioned the long term support kernels not too long ago in passing. I had suggested that we stick with whichever version of LFS includes one of the LTS kernels when they are determined (that would be 6.6 as of now). There is just no way for BLFS to keep up with LFS's 6 month cycle. That would give us at least a one year target anyway, besides, I'm personally not quite ready to deal with gcc-4.5's fixes just yet. :-) There were a few complaining about gcc's buffer overflow protection, now those should be fixed upstream as quickly as possible anyway, but I'd rather give upstream some time to get corrected releases out there than picking through their various SCMs. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Package Management and such (Was RE: Website)
ed book for the POC (complete with remap="destdir" for jhalfs use) if somebody doesn't get to it first. I've been meaning to learn a little better how jhalfs works internally anyhow and this has given me just the excuse I need to get a better look at jhalfs/LFS/lfs.xsl. - -- DJ Lucas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAEBAgAGBQJMVIs7AAoJEIUM+xKzBYsIOC8P/RoqJBO7+i4d9NUVMEMXDZFN i74FBVM85wL8Fi1ZtcokomVrvyUzaPZ+4J7pj0D4jonZIOBJfOBPvE/xX7e1eAij d2Z5TbhN5ofvSu23cmigs6snsxvRmtsENUSrhcRbXlRms3H2vNmNl6vkib+VLmx5 LzhxmJll1g09heyjFEBlU7PoErUSSykguvNGHM8zUqaZ0WXZoq7Iu3GYBZQoEpYO 3dGyGfprqgdyBW/39daVn5kj8IqiTNK4p01kdvIDGe1Ni1eGTBpLYIjCiHn0tYuK rrEGiUeJWIFHBDkK7Zr0imnFuNeF2woa7VnkrP+TLZizsMOG5lUkazfKesNGVt+m 60u/eGjhK6J+QB2fI6tvyknFqkrhpHQGmnU7aHKrQm6A22clnTdC6SCwaIDm7ZEG 9Mq0UIjna0BFLAfhGAoNtBllUGOTWR6TmHnJjU8Ongs9du0fV7LuoRHuclnWLwlj XlB+x8x7dZ9PKtynJmX6TTu1Yt43MYxBb0X1f2Qodm0RfsSeoXQNE0jzOhAsQCgt ouSdQaA7G4xCdmiJGxvIzGveRgoR0R4vJ1gf8aOK6ee4fmOcIRvvkkdKFH3/aLMR 0yisMT8yY73ZPmtikHvEXL7p2D4HhjSDuMZ8tPGcBbR6vtiSIIlbSahNRcVABmub V3vyOgL8zoCHaijVN2Uj =GJly -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management and such (Was RE: Website)
On 07/31/2010 08:08 PM, Kevin Buckley wrote: > On 1 August 2010 09:12, Bruce Dubbs wrote: > >> BTW, I once (IIRC around 2004) made a suggestion to scan the filesystem >> after each package and store information about each package's files in a >> DB. That kinda begs the question about how you get a db installed for >> use. We really don't want to install mysql in Chapter 5. Berkeley DB could be done easily enough I think. > > Do you really need a DB though ? > >> Having a DB that has the history of every file on the system: what >> package, date, package version, filename, directory, would be useful. > > Could it not be a simple flat file listing ? > > find / -newer SOME_TIMESTAMP_FILE -ls > > where SOME_TIMESTAMP_FILE is touched after every package install > would seem to do all that one wants. > >> It's also well beyond what I think should be in LFS. If I ever actually >> implemented something like that, I'd write it up as a hint. >> >> -- Bruce > > There would seem to be an assumption there that the later package > additions, where they overwrite a file installed by an earlier package, > (because everything is done as root) are the versions of the file that > is the required one. Not exactly true. You very well may need to go back to a specific point in time. > One thing I found appealing about the Package-User hint and it's > methodology, was that such clashes were explicitly flagged whenever > a newer package tried to overwrite and existing file. > > It was then up the installer to decide what to do. > > It's not clear that use of DESTDIR, on it's own, would make that issue > any easier to sort out. > No, it is not covered in my version of the proposal. It wouldn't be terribly difficult to account for that however. The point of this exercise is to know what is being done. If you do run into a situation like that, then you'll know what to do about it, ie: reciprocal dependencies within the binary package. There is a lot of learning to be gained by introducing DESTDIR. I actually hadn't thought of that one WRT only LFS for the scope. > What one would appear to need to do is to go down the PkgSrc route > where one creates a list of files after the DESTDIR install which can then > be altered so as not to overwrite existing files in the install proper by > virtue > of inspecting the DESTDIR installtion against the file in the live system > and removing those which should not be overwritten by that package's > version. > But then one is installing against an existing list of files which seems > to complicate matters in that you either have to trust someone who > created the list ahead of your install or jump through a couple more > hoops when installing yourself. > > Then again, maybe that "trust" is no more than that afforded to the > writers of the install commands in the *LFS books? This is true, but it is also already accounted for in LFS. For instance, the man-pages package is installed very early in chapter 6. This is because all the package specific man pages are assumed to be newer than the ones in the man-pages package. Of course, situations like that should be dealt with by removing those files before installation, and introducing a reciprocal dependency in your packaging system. If you work with a full blown PM, then you know where every file comes from, conflicts are simply not allowed. This is one of those situations where install logging fails us, unless you account for it after the fact. I do so by grepping through the entire log directory for each file that is "newer" and prepend (M) in my logs. In some cases, I've have files like /usr/share/info/dir that have 200 (M)s in front of them (because I had forgotten not to include that file in my excludes for my package logging tool). It also goes without saying that I cannot make binary packages from my completed system by using this method, whereas, if everything were properly accounted for, prior to installation, I could. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: greylisting
On 07/31/2010 06:06 PM, Jeremy Huntwork wrote: > Alright, so let me know if that number starts to rise. We may start to > see messages that weren't getting through before due to postgrey. Actually, while you are on the mail server, I've been getting some backscatter recently. It's not been bad, usually about 1 to 3 per week using a forged mime from field. Any chance we can account for that either in header checks or in SA? It's been a while since I've dealt with it, but it shouldn't be too difficult to catch the majority of them, just don't bounce if over a certain threshold. All of them have been above 20 points. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscript future
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/10/2010 03:45 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>> Hey All,
>>
>> So with my LightCube OS project (which is actually nearing first alpha
>> release), I am at the point where I need to decide what to do for boot
>> scripts. I have been using LFS and BLFS scripts up to now, but I'm not
>> sure if I will continue to do so in the future.
>>
>> (I also played with systemd, which is really cool, but it's not 100%
>> yet, in my opinion, nor does my OS generally need it, due to its goals).
>>
>> It depends on a couple of things, really. Firstly, what's the goal of
>> LSB compliance with the scripts, and how far away is that? I want to
>> meet that, if possible.
>>
>> Secondly, is there any likelyhood that LFS/BLFS will want to adopt
>> chkconfig for their scripts. It's dead easy to set up, but it does
>> require modifying the scripts to contain runlevel and order information,
>> and a description (no big deal, really). chkconfig also is a super small
>> package with no need to use crazy dependencies (unless you want to use
>> the semi-graphical ntsysv program).
>>
>> Thoughts?
>
> If there were updates to the bootscripts to make them LSB compliant, I
> would support that. I think that the chkconfig program should be
> deferred to BLFS though.
>
>-- Bruce
Actually, for LSB compliance, the 'distribution supplied boot scripts'
need not use /lib/lsb/init-functions at all. All that is required is
that the scripts provide the LSB header information, and can therefor be
manipulated by {install,remove}_initd. That said, I have been working
on a replacement for the LFS bootscripts for some time, and have a fully
compliant set in LFS/trunk/BOOK/bootscripts/contrib/lsb-v3/, with quite
a few of the BLFS scripts completed as well in
BLFS/bootscripts/contrib/lsb-v3/.
I've been using them for quite some time, and even apply a patch to my
jhalfs copy of the book. All that is required from the book POV is to
install Dan Nicholson's initd-tools package (which provides the
install_initd and remove_initd programs required by LSB) to utilize the
scripts (or any script with LSB header information). The scripts that
I've written do not use /lib/lsb/init-functions directly, but rather use
another functions script (/etc/init.d/lfs-functions) that wraps around
the LSB functions to give us something similar to the simplicity that
has always existed in lfs-bootscripts, while keeping the output
consistent regardless of whether it is one of our scripts or a vendor
supplied script. The scripts also contain all of the added niceties
that were requested previously (single step booting, sane boot logging,
distro independence, verifying weather a pid file is sane, validating
signal name/number, etc.). In addition to the above, we no longer need
to keep track of the symlink number of a script, this is totally
dynamic. I think they are ready for prime time, everyone should really
should give them a try on your next build.
As far as chkconfig, I'm personally not a fan, just because it
duplicates the purpose of the LSB tools, but it does allow you to change
started runlevels which the LSB tools do not (I'm pretty sure that would
conflict with Dan's tools, so if we did that, we'd need to use what RH
and others use for the install_initd and remove_initd tools (which
require python IIRC). IMO, it would be easier to just edit the runlevel
header information in the script rather than using chkconfig.
Also, the service program could easily be a function provided in
/etc/profile.d/service.sh if the magic to build it is not found easily
in sysvinit.
- -- DJ Lucas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (GNU/Linux)
iQIcBAEBAgAGBQJMYim8AAoJEIUM+xKzBYsIfKIP/AkztIrKYcaTB5aJhAfFSYep
c6+V9q3ux5JwtLaJwjebZSuT/VSuDXoRIohHH5E2AmRe7Kt+ZwxQ91CGGq1Oll6u
bGl0wC3COJ1QFi0bLJx5b7tNcAQjEAcPPCOGjvM/3qyHWLKREASM3Td+qz5JAlI9
otN1LXp1ZGIf385k1tioelC0tboeG8ryJ2HPvW0ynYJoSTf4z9HNTlu4gBC5uBh5
DqWAsu7PcnIjyqOoDmBU0HDyE6ZuCPkg8xYWBCXXJTW6ztdLKT6NeSYPTu025gnT
uZ13QpvA5/i5a8ZowTGbb0Lgos+DTvtzT56U3aAq7kbnOzgaWfxjdNCIfnfDvXUm
q8sVjaEe5H/C8Jeh146TU2psMeDUJw/UqAxNhsuxey94GUfSjtb1QGu30qIMhi/Q
rk22a1+gIZ2/ItBRMBKppvAga8LLS9ObhK046SHjDU1rbUkgN5HsMOX4WrzVMadV
j8bCfRsOB8NfwokwJ6+RK37MxIquYWeg8DaBt59XgZe+UBp9Om/4Q59bLVXz6z8Q
d3Lor8Elv7VzB4JCFWgDiJ49ByXqaBh+GgcGQYqavBJpe5OsiSq8VulahPHvrsMS
B387E26f9HifIWflhQWzlaD7w9l4GKLgY5FVvG5FI09kPLIp1eUV8qMgYdo0RcHT
B6D4SitcZUinPhAd/rI+
=Wa5P
-END PGP SIGNATURE-
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Bootscript future
On 08/10/2010 11:40 PM, DJ Lucas wrote: > On 8/10/10 4:45 PM, Bruce Dubbs wrote: >> If there were updates to the bootscripts to make them LSB compliant, I >> would support that. I think that the chkconfig program should be >> deferred to BLFS though. > > > I even patch my jhalfs copy of the book... I hope this doesn't break threading as my previous message was too slow in getting here, so I just obliterated the next response in thread to hopefully provide proper quoting. http://www.linuxfromscratch.org/~dj/lfs-6.6-lsb-v3.patch Figured it would be helpful to get testers if a patch was ready made. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscript future
On 08/23/2010 04:12 AM, Jeremy Huntwork wrote:
> On 8/11/10 12:40 AM, DJ Lucas wrote:
>> Actually, for LSB compliance, the 'distribution supplied boot scripts'
>> need not use /lib/lsb/init-functions at all. All that is required is
>> that the scripts provide the LSB header information, and can therefor be
>> manipulated by {install,remove}_initd. That said, I have been working
>> on a replacement for the LFS bootscripts for some time, and have a fully
>> compliant set in LFS/trunk/BOOK/bootscripts/contrib/lsb-v3/, with quite
>> a few of the BLFS scripts completed as well in
>> BLFS/bootscripts/contrib/lsb-v3/.
>
> Awesome work. I've been playing with them and they will definitely fit
> my needs. They're a huge improvement over the current LFS bootscripts.
>
> I did encounter a syntax error, however. The sendsignals script is
> missing ' ; then' after a leading if in two places. This sed fixes it:
>
> sed -i 's...@\]@& ; then@' init.d/sendsignals
Ahh, yes. That was added a few weeks ago with the new killall. Fixed
real quick in r9365.
>
>> dynamic. I think they are ready for prime time, everyone should really
>> should give them a try on your next build.
>
> I'd be pretty happy if these went into LFS.
>
>> As far as chkconfig, I'm personally not a fan, just because it
>> duplicates the purpose of the LSB tools, but it does allow you to change
>> started runlevels which the LSB tools do not (I'm pretty sure that would
>> conflict with Dan's tools, so if we did that, we'd need to use what RH
>> and others use for the install_initd and remove_initd tools (which
>> require python IIRC). IMO, it would be easier to just edit the runlevel
>> header information in the script rather than using chkconfig.
>
> I can do without chkconfig. I do miss the ability to list what is
> enabled, and only mildly miss the ability to enable/disable specific
> run-levels for a given service.
>
> Having said that, assuming it doesn't break any LSB compliance, I'd be
> happy to add those features into Dan's tools. As it is, if I begin using
> them in earnest, I may just take over maintenance of them.
>
>> Also, the service program could easily be a function provided in
>> /etc/profile.d/service.sh if the magic to build it is not found easily
>> in sysvinit.
>
> For my own purposes, as a temporary solution, I've added the following
> script to my rpm of your bootscripts:
>
> http://dev.lightcube.us/~jhuntwork/sources/lsb-bootscripts/service
>
Excellent! Off to work for me.
> Thanks!
>
> Jeremy
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Don't edit /etc/grub.d/grub.cfg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wow, first time I've messed with grub 2, and I had like 6 kernels still
hanging around and the result was just plain ugly! Is there any reason
we are recommending that the user edit grub.cfg manually instead of
using the /etc/grub.d directory as intended?
The grub config files are simply shell scripts, and stdout gets put into
the output file of grub-mkconfig (you can redirect to stderr in order to
print a nice message to the screen as in the example below). I'd much
rather get rid of /etc/grub.d/10_linux (by making it not executable) and
let the users define what is needed as opposed to searching for kernels
to make the file.
Example:
==
cat > /etc/grub.d/11_LFS-6.7 << "EONF" &&
#! /bin/sh -e
echo "Adding LFS-6.7" >&2
cat << EOF
menuentry "LFS-6.7" {
echoStarting LFS-6.7...
linux /vmlinux-2.6.35.2 root=/dev/sda6 ro
}
menuentry "LFS-6.7 (recovery)" {
echoStarting LFS-6.7 in recovery mode...
linux /vmlinux-2.6.35.2 root=/dev/sda6 ro single
}
EOF
EONF
cat > /etc/grub.d/12-LFS-6.6 << "EONF" &&
#! /bin/sh -e
echo "Adding LFS-6.6" >&2
cat << EOF
menuentry "LFS-6.6" {
echoStarting LFS-6.6...
linux /vmlinux-2.6.32.15 root=/dev/sda5 ro
}
menuentry "LFS-6.6 (recovery)" {
echoStarting LFS-6.6 in recovery mode...
linux /vmlinux-2.6.32.15 root=/dev/sda5 ro single
}
EOF
EONF
cat > /etc/grub.d/13_Windows << "EONF" &&
#! /bin/sh -e
echo "Adding Windows" >&2
cat << EOF
menuentry "Windows" {
set root=(hd0,1)
chainloder +1
}
EOF
EONF
chmod 755 /etc/grub.d/11_LFS-6.7 &&
chmod 755 /etc/grub.d/12_LFS-6.6 &&
chmod 755 /etc/grub.d/13_Windows &&
chmod 644 /etc/grub.d/10_linux &&
grub-mkconfig -o /boot/grub/grub.cfg
===
The first example give a little more info to the user as to what is
going on, but the alternate is to use 40_custom like so (untested):
===
cat >> /etc/grub.d/40_custom << "EOF" &&
menuentry "LFS-6.7" {
echoStarting LFS-6.7...
linux /vmlinux-2.6.35.2 root=/dev/sda6 ro
}
menuentry "LFS-6.7 (recovery)" {
echoStarting LFS-6.7 in recovery mode...
linux /vmlinux-2.6.35.2 root=/dev/sda6 ro single
}
menuentry "Windows" {
set root=(hd0,1)
chainloder +1
}
EOF
chmod 644 /etc/grub.d/10_linux &&
grub-mkconfig -o /boot/grub/grub.cfg
=======
Additionally, we can comment out the search line in 00_header (since it
is pretty much useless on default build) and add some additions there
(like background image, or prettier colors, etc.). Also, I don't know
what 30_os-prober does, but thus far, it has been empty.
- -- DJ Lucas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (GNU/Linux)
iQIcBAEBAgAGBQJMczYIAAoJEIUM+xKzBYsIV/IQAIaOY64lnhf6nLtfn9TNxThN
zA3PUIP3Zs3ZaMvYeqmvfAhLCydeM9mFla+x95w0YnNTlCbCvGAhkxl394Egt7au
xZHxXKTmcR/cXo7YjXtRRvHiFI9XY8dfocv1F3tLucm/8xMRwXCJx5uHJdUOMY/T
e442lT13MJtJPG2BJVQgBTr8wVK/Bs+w72dcP88slZoI5pykk9NtKlf9Jt5qiP/L
CkFzcAC5/+aa2FVESoNGCIV2dbU3YvbDp4nAoFvKeJQzI68i0xo/XyWH8xbhxQ/p
pa8EhJektvhRU3XgPUSTV1F7rSkqdv3Xu1z7kUH72dBPgXuNCOWr/qHrcpfCaBH4
KD6PONn2zXsRcSxK18AJgghW7Wh290QIrRIercskaqAtUaEsAy1wpQDqnSeW8BXu
HvmSnXcsJMPyqUMwK2M1q8zJ/AVp/qJEy24hMIaNON1LxFkXmE/IAhKVT9dCUWeN
YI7zJz0XbyuFlhfXNe1rEnfCeZzDsvavG1MHDJw7h7bPBBaoz1Z1uO6MC58Rw+co
rqIm0qsO9iJeFcyO0soobel2kqoqSsyxmf5Khaqmg0wDAPhdJ2YC+NZSXJUB5hal
1EO0BkH99UAmHm3HqSMsPJE0NUh76CYSnPjoM3VwHutVpTnuNQbV8mciBbWDdXYS
FgoZbIYDgHiMPUSsLnUl
=xfGD
-END PGP SIGNATURE-
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Bootscript future
On 08/23/2010 08:27 AM, DJ Lucas wrote: > Ahh, yes. That was added a few weeks ago with the new killall. Fixed > real quick in r9365. And my hasty ignorance in r9366. Sorry about that. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Don't edit /etc/grub.d/grub.cfg
On 08/23/2010 10:38 PM, Bruce Dubbs wrote:
> DJ Lucas wrote:
>> Additionally, we can comment out the search line in 00_header (since it
>> is pretty much useless on default build) and add some additions there
>> (like background image, or prettier colors, etc.).
I think I spoke too soon on that. I haven't been able to figure out
exactly where that line comes from.
> Wow. I think that's a lot harder than just editing a file.
Oh yes, it is certainly more difficult, but I was looking more at
explaining how things are done (education has always been a top priority
in the past). Also, by editing the grub.cfg file manually, we are
making a recommendation that conflicts with one made by the developers.
Doing something like that has a tendency to bite you in the rear later
on down the road. I do realize that I'm asking for a lot of changes to
be made very late in the development cycle, but I really think it's
wrong to recommend editing that file if the devs don't want you doing
it. I'll be happy to do the leg work.
We also used to have multiple examples in the book, for instance the
prettier colors and the chainloading example. The chainloading example
need not be Windows specific (though that is probably the most used).
Chainloading is useful for booting to CD, floppy, (PXE?,) or any other
bootloader, even another copy of grub, on a different partition.
Additionally, the possibility of destroying a good config if
grub-mkconfig is run again kinda scares me. Though it shouldn't happen
given the text in the book, who knows what kind of documentation a user
might run into out in the wild. I ran into exactly that command when
looking for the chainloader example, the second hit with "grub2
chainload windows" in Google (the first one *looked* really hairy).
http://wiki.archlinux.org/index.php/GRUB2#Dual-booting
Ultimately, for my previous message, I used the first 'hairy' example
because it is a lot more informative as to what is really happening when
you run grub-mkconfig:
http://blogs.koolwal.net/2008/12/28/windows-xpvista-dual-boot-does-not-boot-from-grub2-or-grub-pc/
> To add a
> new kernel, you just need to add 2 lines.
>
> menuentry "LFS SVN 20100627, Linux 2.6.34" {
> linux /linux-2.6.34 root=/dev/sda13 ro
> }
The following example would work just as well as manually editing the
file, and would avoid the 'scare' I had mentioned above:
cat >> /etc/grub.d/40_custom << "EOF"
menuentry "LFS SVN 20100627, Linux 2.6.34" {
linux /linux-2.6.34 root=/dev/sda13 ro
}
EOF
Finally, I'm still not very happy with that disaster created by the
10_linux script, which is why I suggested changing the permissions on it
(and have done so locally).
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Glibc vulnerability . . . implications for LFS?
On 10/24/2010 09:48 PM, Bruce Dubbs wrote: > Bryan Kadzban wrote: > >> Ah, I think I see. You have to put libbad.so into /lib64 (emulating >> libpcprofile), then set LD_AUDIT to just "libbad.so.0", with no path. >> At that point it works as expected (at least for me). (Though this is a >> multilib setup. But ping is 64-bit; on a single-bit-width system you >> should be able to just use /lib instead.) > > I don't understand this issue. Wouldn't you need root to add anything > to /lib64 (which should be a symlink to /lib on LFS)? If you can do > that, there are a lot of easier ways to get a root shell. > >-- Bruce No. The original exploit has two parts. The link that Bryan posted has full details. See below: dj [ ~ ]$ ls -l /usr/bin/bad ls: cannot access /usr/bin/bad: No such file or directory dj [ ~ ]$ umask 0 dj [ ~ ]$ LD_AUDIT="libpcprofile.so" PCPROFILE_OUTPUT="/usr/bin/bad" ping ERROR: ld.so: object 'libpcprofile.so' cannot be loaded as audit interface: undefined symbol: la_version; ignored. ping: missing host operand Try `ping --help' or `ping --usage' for more information. dj [ ~ ]$ ls -l /usr/bin/bad -rw-rw-rw- 1 root dj 4 Oct 25 01:28 /usr/bin/bad dj [ ~ ]$ rm /usr/bin/bad rm: cannot remove `/usr/bin/bad': Permission denied dj [ ~ ]$ chmod 775 /usr/bin/bad chmod: changing permissions of `/usr/bin/bad': Operation not permitted dj [ ~ ]$ echo blah > /usr/bin/bad dj [ ~ ]$ cat /usr/bin/bad blah dj [ ~ ]$ sudo rm /usr/bin/bad dj [ ~ ]$ The file is not executable, so not much can be done with it (without utilizing cron as was done in the original example). Regardless, creating world writable files anywhere in the filesystem is bad. Even without cron as a means to get a root shell, this is dangerous enough. A simple DOS attack to fill the root file system might screw up the nightly backups for instance. Granted, there are multiple audit trails using that method... -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc vulnerability . . . implications for LFS?
On 10/25/2010 01:57 AM, Matthew Burgess wrote: > On Sun, 24 Oct 2010 19:13:09 -0700, Bryan Kadzban > wrote: > >> Well, if I had any other users on this system, I'd think about patching >> 2.10.1 and trying it out -- but since I don't, I'll probably just wait >> until the next full system rebuild. (Replacing glibc on a running >> system is ... nontrivial. :-( ) > > Maybe that was my screw-up last night then. I thought I'd just rebuild and > 'make install' the patched Glibc as they were at the same version. I guess > I'll > have to rebuild the whole system then, to definitively prove the patch works, > unless you have some crib notes on how I should be re-installing Glibc? > > Thanks, > > Matt. > Should be fine IIUC. The libpcprofile exploit was simple enough to use as an example. Did the patch stop that one? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc vulnerability . . . implications for LFS?
On 10/25/2010 01:57 AM, Matthew Burgess wrote: > On Sun, 24 Oct 2010 19:13:09 -0700, Bryan Kadzban > wrote: > >> Well, if I had any other users on this system, I'd think about patching >> 2.10.1 and trying it out -- but since I don't, I'll probably just wait >> until the next full system rebuild. (Replacing glibc on a running >> system is ... nontrivial. :-( ) > > Maybe that was my screw-up last night then. I thought I'd just rebuild and > 'make install' the patched Glibc as they were at the same version. I guess > I'll > have to rebuild the whole system then, to definitively prove the patch works, > unless you have some crib notes on how I should be re-installing Glibc? > > Thanks, > > Matt. > That should have worked. Did you try a reboot before testing to clear cache? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc vulnerability . . . implications for LFS?
On 10/24/2010 06:13 PM, Matthew Burgess wrote: > On Sun, 24 Oct 2010 16:32:48 -0600, Matthew Burgess > wrote: > >> It'll be a while until I run another full build, but I'm recompiling glibc >> now, with the patch I uploaded earlier. I'll post results tomorrow, but >> expect it to work just fine. > > Well, it didn't appear to fix the vulnerability here, but maybe I've made > another screw > up :( I'll wait until someone else can confirm/deny whether the patch works > for them. > > Regards, > > Matt. > Didn't fix it on 2.11.1 either. I used the patch in the repo. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc vulnerability . . . implications for LFS?
On 10/24/2010 11:14 AM, Matthew Burgess wrote: > On Sun, 24 Oct 2010 9:59:25 -0600, Matthew Burgess > wrote: >> On Sun, 24 Oct 2010 11:38:27 -0400, Drew Ames wrote: >> >>> 1) Is it worth downloading and using the development version of Glibc >>> from git://sourceware.org/git/glibc.git to build LFS with the updated >>> source? >> >> I wouldn't be keen building from the latest development version myself. >> I'm more cautious than that (especially for toolchain packages), so >> would advise to build 2.12.1 + patch for this bug. Finding such patches >> can take some time, but this one was pretty easy: >> >> http://sourceware.org/ml/libc-hacker/2010-10/msg7.html. > > That patch is now also available, in LFS format, from > http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.12.1-origin_fix-1.patch. > > Apply using the usual 'patch -Np1 -i ../glibc-2.12.1-origin_fix-1.patch'. > > Regards, > > Matt. > Additional part. Haven't tested. http://sourceware.org/ml/libc-hacker/2010-10/msg00010.html Makes LD_AUDIT behave same as LD_PRELOAD. Will rebuild glibc in a few moments on this system see if it fixes it. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc vulnerability . . . implications for LFS?
On 10/26/2010 12:26 AM, DJ Lucas wrote: > > Additional part. Haven't tested. > > http://sourceware.org/ml/libc-hacker/2010-10/msg00010.html > > Makes LD_AUDIT behave same as LD_PRELOAD. > > Will rebuild glibc in a few moments on this system see if it fixes it. That got it on 2.11.1. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc vulnerability . . . implications for LFS?
On 10/26/2010 04:51 AM, Matthew Burgess wrote: > > Thanks DJ! Was that in conjunction with the original patch I submitted, > or instead of? > > Regards, > > Matt. > Yes, both patches were applied. Also, just for kicks, I did a live update of Glibc on system running Gnome at the time. It had been a while since I had done an in-place update of glibc but no problems as usual. Of course I rebooted pretty quick, but I haven't had any issues with doing an in-place update since before NPTL IIRC. I don't know if I'd change versions on a running system without dropping to 1, but same with a patch is OK still. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc vulnerability . . . implications for LFS?
"Bruce Dubbs" wrote: >DJ Lucas wrote: >> Also, just for kicks, I did a live update of Glibc on system running >> Gnome at the time. It had been a while since I had done an in-place >> update of glibc but no problems as usual. Of course I rebooted pretty >> quick, but I haven't had any issues with doing an in-place update >since >> before NPTL IIRC. I don't know if I'd change versions on a running >> system without dropping to 1, but same with a patch is OK still. > >Is there a special technique or did you just do a make install? Just a straight "make install" but keep in mind that it was same version, just the patches added. I also have backups of all installed files in tar.gz format, so not a big deal for me if it did foul up. I used to do that all the time, but never from RL5. I build so frequently now that it really doesn't make much sense. I just wanted to see if it would work. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc vulnerability . . . implications for LFS?
On 10/26/2010 09:44 PM, Bruce Dubbs wrote:
> Drew Ames wrote:
>
>> Now I have another question. How do I make the patch in the link above
>> into a .patch file that I can apply?
>>
>> Do I fill out the Submitted By, Date, Initial Package Version,
>> Upstream Status, Origin, and Description, at the top, paste in the
>> information from the link starting at the line with the diff command,
>> and then give it all a .patch extension?
>
> You need an original and a modified version:
>
> diff -u modified orig > name.patch
>
> Then edit the patch to add the other info at the top. The 'orig' and
> 'modified' are generally the package top level directory as in:
>
> orig:
>file.c
>
> modified:
>file.c
>
>-- Bruce
Generaly the process is as follows:
{{{
tar -xf package-1.2.3.tar.gz
cp -R package-1.2.3/ package-1.2.3-orig
cd package-1.2.3
patch -Np1 -i patchfile
# from affected directory (typical for svn or git diffs as usually
# p1 is a/ and b/)
cd ..
diff -Naurp package-1.2.3-orig/ package-1.2.3/ > \
package-1.2.3-fixes_something_bad-1.patch
vi package-1.2.3-fixes_something_bad-1.patch
}}}
Then just add needed header information (copy from an existing patch and
modify as needed). The p flag in the diff command is not required, and
not mentioned in the editors guide (at least last time I checked
probably about 5 years ago), but is a nice to have addition if you later
have to manually apply against a different version.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: IANA-Etc links broken (for now)
On 11/22/2010 06:12 PM, William Immendorf wrote: > Pretty recently, the download location for IANA-etc stopped working, > and so, that means that IANA-etc is not avaliable. At least for now, I > don't know if it will get better at all. > > This means we have to use Anduin for getting this package. This > probally needs to be listed in the errata. > The domain expired. Anybody still keep in touch? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Segmentation fault in sort with Coreutils-8.7
Guys, getting a segfault in sort using large input set. The behavior changed to always use the number of processors available in parallel by default. The following commands (taken from cracklib installation which is where I first saw the error) work to successfully reproduce the error (in a chroot environment): zcat cracklib-words-20080507.gz | sort -u The following, however, works fine on my system: zcat cracklib-words-20080507.gz | sort -u --parallel=1 Can somebody else on a mult-core CPU, on 32-bit, confirm before I troubleshoot further? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Segmentation fault in sort with Coreutils-8.7
On 11/25/2010 12:14 AM, Stuart Stegall wrote: > x86, arm, ppc64, and x86_64 all work without a problem here - x86 and > x86_64 are both built from current SVN - arm and ppc64 are 6.7 + > coreutils-8.7. > Okay, probably a problem on my system then. Will check and see if it happens native. Thanks for checking. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Segmentation fault in sort with Coreutils-8.7
On 11/25/2010 12:17 AM, DJ Lucas wrote: > On 11/25/2010 12:14 AM, Stuart Stegall wrote: >> x86, arm, ppc64, and x86_64 all work without a problem here - x86 and >> x86_64 are both built from current SVN - arm and ppc64 are 6.7 + >> coreutils-8.7. >> > > Okay, probably a problem on my system then. Will check and see if it > happens native. > > Thanks for checking. Full rebuild and same issue here. Hardware seems to check OK, but more thorough testing coming. Also, the update to expect broke jhalfs. I haven't looked into why yet, but last time I had seen similar error, it was due to a missing role= tag on one of the screen blocks. Anyway, going offline to try a pure64 build from the livecd. Problem did not exist in Coreutils-8.6 (as was used on previous build on same hardware). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Segmentation fault in sort with Coreutils-8.7
On 11/26/2010 12:07 AM, Bruce Dubbs wrote: > DJ Lucas wrote: > >> The update to expect broke jhalfs. I >> haven't looked into why yet, but last time I had seen similar error, it >> was due to a missing role= tag on one of the screen blocks. > > I suspect it's because the package was renamed expect5 instead of > expect-5. IIRC, the same problem existed with tcl8. > > I think the problem may be in common/urls.xsl where an option needs to > be added similar to the tcl option at line 87. > > For a work around, try editing jhalfs/lfs-commands/chapter05/040-expect > and s/$PKGDIR/expect5.45/ > Work around I used was directly in the Makefile. I added the missing lines to the 040-expect target directly and it finished without issue AFAICT. I had the exact same thing happen once before when adding initd-tools to my local copy and I didn't use either the role= or remap= tags in the instructions. I just reviewed expect.xml and it looks correct, so you are probably correct about the real problem. Still dealing with sort issue. No hardware issues found. I need to isolate the issue either to this machine or to a certain environment, unfortunately, I don't have another 64bit multi-core machine at my disposal. So far, I've managed to limit it to UTF-8 on multi-core (possibly only 32bit on a 64bit multi-core CPU). Doesn't make sense for this to show up on a system, that has thus far been stable, after such significant changes to the code (added multi-threading support to sort) and it be a hardware issue, especially when sidestepping the new code doesn't display the problem. Reviewing the strace output now... Any chance you (or anyone) could test the following in a 32bit userland on 64bit multi-core system? If a segmentation fault occurs, then it's not my system...and if it does, then I need to do a more thorough hardware test. zcat cracklib-words-20080527.gz | LANG=en_US.UTF-8 sort -u Removing the i18n patch resulted in no change. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Segmentation fault in sort with Coreutils-8.7
On 11/26/2010 10:45 AM, Bruce Dubbs wrote:
> Matthew Burgess wrote:
>> On Wed, 24 Nov 2010 23:47:41 -0600, DJ Lucas
>> wrote:
>>
>>> Can somebody else on a mult-core CPU, on 32-bit, confirm before I
>>> troubleshoot further?
>>
>> This is also being tracked upstream and at RedHat:
>>
>> http://lists.gnu.org/archive/html/coreutils/2010-11/msg00083.html
>> https://bugzilla.redhat.com/show_bug.cgi?id=655096
>
Cool..so I'm not insane.
> Should we revert to .6 until this is fixed?
>
Either that or apply a really cheezy hack to disable multi-threading.
:-) I'm sure there is a better test, but this was quick and easy.
--- coreutils-8.7/src/sort.c2010-10-25 10:07:57.0 +
+++ coreutils-8.7-new/src/sort.c2010-11-26 17:38:53.0 +
@@ -4534,6 +4534,11 @@
if (!nthreads || nthreads > np2)
nthreads = np2;
+ /* Threading is currently broken in multibyte locales, so disable it
+ temporarily if not C. I'm sure there is a better test for
this... */
+ if (getenv ("LC_COLLATE") != "C")
+nthreads = 1;
+
sort (files, nfiles, outfile, nthreads);
}
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Segmentation fault in sort with Coreutils-8.7
On 11/26/2010 10:45 AM, Bruce Dubbs wrote: > Matthew Burgess wrote: >> On Wed, 24 Nov 2010 23:47:41 -0600, DJ Lucas >> wrote: >> >>> Can somebody else on a mult-core CPU, on 32-bit, confirm before I >>> troubleshoot further? >> >> This is also being tracked upstream and at RedHat: >> >> http://lists.gnu.org/archive/html/coreutils/2010-11/msg00083.html >> https://bugzilla.redhat.com/show_bug.cgi?id=655096 > > Should we revert to .6 until this is fixed? > >-- Bruce My previous message did not get through for whatever reason. Quick hack was to set nthreads=1 if using multibyte locales on or around line 4538 in sort.c. I used getenv on LC_COLLATE, and compared only to C, but there is certainly a better way to do that, I just don't know how...hack works for me. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Segmentation fault in sort with Coreutils-8.7
On 11/26/2010 02:44 PM, Matthew Burgess wrote: > On Fri, 26 Nov 2010 14:09:30 -0600, Bruce Dubbs wrote: > >> I've been pretty busy with a work project. I'd appreciate it if you can >> do it. > > No probs, done in r9421. Thanks, DJ, for the report. > > Regards, > > Matt. > Yep yep...reported as actual bug upstream and it was reproducible by one of the developers. http://lists.gnu.org/archive/html/bug-coreutils/2010-11/msg00209.html -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Segmentation fault in sort with Coreutils-8.7
"Bruce Dubbs" wrote: > >It looks like he can't reproduce it. > Not all of messages are archived yet. Problem is acknowledged, and even suspected cause determined. --DJ Lucas -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Segmentation fault in sort with Coreutils-8.7
On 11/27/2010 02:30 AM, DJ Lucas wrote:
> Problem is acknowledged, and even suspected cause determined.
We have an upstream fix, hasn't appeared in the archives yet.
> On 11/27/2010 06:57 PM, Paul Eggert wrote:
>> Could you please try this little patch? It should fix your
>> problem. I came up with this fix in my sleep (literally!
>> I woke up this morning and the patch was in my head), but
>> haven't had time to look at the code in this area to see
>> if it's the best fix.
>>
>> Clearly there's at least one more bug as noted in my previous email
>> <http://lists.gnu.org/archive/html/bug-coreutils/2010-11/msg00216.html>
>> but I expect it's less likely to fire.
>>
>> diff --git a/src/sort.c b/src/sort.c
>> index 7e25f6a..1aa1eb4 100644
>> --- a/src/sort.c
>> +++ b/src/sort.c
>> @@ -3226,13 +3226,13 @@ queue_pop (struct merge_node_queue *queue)
>> static void
>> write_unique (struct line const *line, FILE *tfp, char const *temp_output)
>> {
>> - static struct line const *saved = NULL;
>> + static struct line saved;
>>
>>if (!unique)
>> write_line (line, tfp, temp_output);
>> - else if (!saved || compare (line, saved))
>> + else if (!saved.text || compare (line, &saved))
>> {
>> - saved = line;
>> + saved = *line;
>>write_line (line, tfp, temp_output);
>> }
>> }
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Segmentation fault in sort with Coreutils-8.7
On 11/27/2010 08:22 PM, DJ Lucas wrote: > On 11/27/2010 02:30 AM, DJ Lucas wrote: >> Problem is acknowledged, and even suspected cause determined. > > We have an upstream fix, hasn't appeared in the archives yet. > The threaded code. Fixes are in upstream following the bug from the previous thread in November, and falling over into December here: http://lists.gnu.org/archive/html/bug-coreutils/2010-12/msg1.html All should be good as soon as a new release is available. -- DJ -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Issues with the XZ-utils instructions
On 01/03/2011 09:51 PM, Bruce Dubbs wrote:
> William Immendorf wrote:
>> There are some new issues with the XZ-utils instructions:
>>
>> 1. There is a redundant PREFIX=/tools in the Ch5 make install command
>> (it's redundant because --prefix=/tools is arleady passed to the
>> configure command)
>
> You're right. I was going from the bzip2 instructions, but that isn't
> fully autotooled like xz utils are.
>
>> 2. XZ-utils is considered a core compression utility (like Bzip2 and
>> Gzip), yet the programs are not on the root partition.
>
> I really didn't consider it a core compression utility since I've never
> really *needed* it. However, both gzip and bzip2 are in /bin. When I
> look at some other distros, I don't see bzip2 in /bin let alone xz. The
> FHS is really old and doesn't address either.
Ouch. Bad decision on the part of the distros IMO. I'd definitely
consider that an issue not to have tar and/or bzip2 on the root
partition for recovery purposes. tar -> bz2 is fairly common for backups
as far as inexpensive solutions. Most of your tape drives have hardware
compression, but external HDDs are perfect for home users and SMEs. I
mean, you can buy 15 external HDDs (with plenty of room for growth) for
the price of a sufficiently large tape drive now days.
>
> The thing is that there is one symlink that would be broken with your
> suggested changes, lzmore, but it seems inconsistent to have
> lz{cmp,diff,grep,{,e,f}grep,less} in one directory and lzma,unlzma, and
> lzcat in another. The same logic goes for the xz* files.
>
> I note that we do split bzip2 files in the way you suggest.
>
> I'd like to get other opinions on this.
Interesting. I had an immediate need for a multilib system for some
32bit binaries I need to run, and I ventured into Cross LFS this weekend
and made a hybrid. Some really neat tricks in there! I especially like
the simplicity of the multiarch-wrapper. Even a couple of suggestions
for the base LFS (two of which actually do pertain to your inquire above).
Anyway, back on topic, since it is fresh in my head, CLFS puts all xz
utils in /bin but I do not know the rational. It might be interesting to
find the discussion as to why in their archives. I'd suspect that it has
something to do with tar (which is also in /bin as hinted above)
attempting to call the externals, but tar is not _linked_ to the
libraries so xz is technically excluded from the /bin and /usr/bin FHS
requirement.
That said, xz format might prove to be nice for backup/recovery purposes
(again as noted above). Also, again taking from CLFS, texinfo has a
patch available to utilize xz format as is current with gz and bz2. Just
a guess, but since xz is being utilized by GNU, it will probably, at
some point in the future, become a dependency of texinfo requiring an
order change (although I agree with Randy's comment the other day
regarding the usefulness of compressed info pages).
http://cross-lfs.org/view/svn/x86_64/final-system/xz-64bit.html
http://cross-lfs.org/view/svn/x86_64/final-system/texinfo.html
Also of interest (which may already be covered by sed commands currently
in readline) and not at all related to the topic at hand:
readline-6.1-branch_update-1.patch.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Xorg plans (Was: Re: problem with groff 1.21)
On 01/12/2011 05:45 PM, Ken Moffat wrote: > I've no idea where BLFS is going in the move to 7.6 - my (old) > radeons work well in everything except mesa-demos, but then I no > longer build a lot of the old things (many of the 'apps' still > listed in BLFS, also the old core fonts - I'm all TTF here). Moved to BLFS-Dev... BLFS hopefully will move to 7.6-1 this weekend (time permitting). I've tested on both x86 and x86_64 and it seems to be solid on my hardware. I've done both /opt/X11 and /usr installations on x86, but only /usr on x86_64 (the /opt/X11 prefix will require a lib64 -> lib symlink). While I've done a complete U-turn on my intentions, I also plan to suggest that we do only system installations in the book for everything after this release, and move instructions to the wiki if we choose to support packages installed elsewhere (the maintenance burden of Trinity and Gnome using /opt is far too much to handle reliably (and later KDE4?)). I plan to add a warning box in the book for this release mentioning the $XORG_PREFIX/lib64 -> lib symlink. Mesa Demos will be gone from the book and the Configuring Xorg will be one page. Old fonts will remain as they are still listed as part of the Xorg distribution. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Xorg plans (Was: Re: problem with groff 1.21)
"Dan Nicholson" wrote: > >I'm curious why you want to get rid of the demos. Surely everyone goes >to glxinfo and glxgears to see if 3D is working, right? > Not in a place where I can check right now, but AFAICT, they havent been updated for new Mesa. Could probably use old ver, but why add another package when other tools available? --DJ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On 02/25/2011 04:38 PM, Bruce Dubbs wrote: > Neal Murphy wrote: >> On Friday 25 February 2011 15:02:23 Bruce Dubbs wrote: >>> It looks like the process is: >>> >>> 1. Use null and console at the start. >>> 2. Mount a tmpfs on /dev hiding the original null and console devices. >>> 3. Create all new devices, including null, on the tmpfs via udev and >>> the boot script. >>> >>> Newer versions of udev or the kernel may make some of these procedures >>> unnecessary, but they don't hurt anything. A device node takes up 1 >>> directory entry and no additional space. >>> >>> I don't understand what appears to be a sense of urgency in your post. >>> What are the drawbacks of the procedure as is? >> >> You are quite right. Your three steps work fine and hurt nothing. The >> drawback >> is slightly elevated code complexity in building and preparing the system, >> booting it, as well as the effort to keep and maintain that code. >> >> Enabling CONFIG_DEVTMPFS_MOUNT in the kernel (2.6.32+, I believe) reduces the >> steps to: >>1. Mount devtmpfs on /dev; the kernel populates it with devices it knows >>2. Run udev to 'take over' those nodes and populate it with everything >> else > Interesting. I hadn't noticed these changes. I had seen the extra configuration item, but didn't put two and two together and simply ignored it as unnecessary baggage (fortunately it actually is with our current boot scripts). Guess I'm getting a little slow. I still haven't looked at it yet, just working from Neal's comments. > I don't understand your comment about effort to keep and maintain the > code. There were a couple of minor text changes about 7 months ago and > prior to that, basically no changes for four years. > The comment was only to say that it is now unnecessary. > The biggest problem I see for your methodology is that it requires a > specific kernel configuration. We don't do that anywhere in the book. > We do mention some optional configurations in Chapter 8. > Actually, we do. The kernel must be built with tmpfs support as required by udev. Why not extend that and require that devtmpfs support be built-in as well? Assuming it works, and I've no reason to doubt that it does (only that I haven't tested myself), we remove a few lines from the udev script, the mountkernfs script gets a change, a new recommendation is added to the book where the current one is, and a small section of the book is rendered unnecessary - yes the information gets locked away in a little black box, but IMO, that happened 5 years ago when the makedev script went away. The concept of device nodes (and even the devices.txt included with the kernel) is probably already lost to the younger users until it becomes necessary to create one that udev knows nothing about (and those are few and far between). Nothing really lost here, and a small gain in efficiency. The old race car bit fits nicely here: don't look for 1 place to loose 100 pounds; look for 100 places to loose 1 pound. :-) -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Thinking forward LFS-7.0
Okay, so I was just thinking...<Deity> help us! I figure we have at least 6 months, potentially a year until the next major LFS release, and now seems like a pretty good time to explore some of the ideas that have been shelved for previous releases, and even some new ones. Here is a quick list to see if there is any interest. I'll reply to my own post afterward to separate my own suggestions from the initial list. * Package Management - Always causes a good debate. * DESTDIR - Been mentioned several times and actually this is not too disruptive (I did a POC about 3 years ago). * LSB Compliance - For LFS we are nearly there anyway. * Dynamic boot script - No more static list of links, this kind of ties into LSB Bootscripts, but there are other options. * Multi-lib - Shunned previously, but there are many projects that expect this environment. * EGlibC - Seems like Debian and friends are moving to EGlibc, gives us a couple of niceties but nothing major, not sure what other distros are doing, but I've seen a lot of mentions of it recently. The work is already done by the way, our fellow devs at CLFS already have it covered for us. * Modular *.d/ directories - I'm pretty sure this is already covered in another thread, but it should be done by default where possible. * Anything else that I've missed -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
