Re: Website

On Jul 27, 2010, at 3:21 AM, Alan Lord (News) wrote: > Hi Jeremy et al :-) Hi Alan! > I had a quick look over the redmine site and thought it looked great. > > As I am not really involved in LFS at all any more I didn't feel as > though I had any position to comment, but seeing as you asked I t

Re: Website

On Jul 28, 2010, at 1:07 AM, Bruce Dubbs wrote: > Section 6.3 discusses PM. It says why we don't have PM in the book. > > There are six hints on PM. These sorts of replies are discouraging. It says "we've dealt with this, no point in discussing further". It's terse and official and unwelcoming.

Re: Website

On Jul 28, 2010, at 11:36 AM, Bruce Dubbs wrote: > I'm not opposed to someone creating an alternative version of LFS with > package management. If a volunteer needs the resources on the LFS site, > I'll be glad to set them up. However, I don't want to work on such a > project. Ok, that's your

Re: Website

On Jul 28, 2010, at 1:01 PM, Bruce Dubbs wrote: >> Ok, that's your personal choice. But I'm curious, is there any >> particular reason why you are personally opposed to working on a >> project with package management? > > Because I don't use it and don't see the need for it (for me). I have > no

Re: Website

On Jul 28, 2010, at 2:23 PM, Bruce Dubbs wrote: > I guess that goes back to "Your distro, your rules". I haven't felt the > need you have. I prefer a simpler system. Absolutely, which is why it's nice to demonstrate in the book the simplest method of PM, namely DESTDIR. That one extra variabl

Re: Website

On 7/25/10 2:13 AM, DJ Lucas wrote: > 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 e

Re: How can I contribute?

On Jul 30, 2010, at 8:10 PM, Bruce Dubbs wrote: > That needs to be reconsidered since LFS 6.7 will be out in about a month. > Is one of the considerations to keep just one, current, BLFS book version, instead of producing releases? I know there's compatibility concerns with released versions o

greylisting

Would anyone mind if we updated Postfix and killed the greylisting on quantum? There are alternatives that would not have the same delay issue that greylisting by nature causes. For example, I've been playing with SPF (http://en.wikipedia.org/wiki/Sender_Policy_Framework). Jeremy -- http://lin

Re: greylisting

On 7/30/10 10:39 PM, Bruce Dubbs wrote: > Go ahead. I tried to get SPF to work once, but it didn't work for me. > That was several years ago though. Testing once more... Jeremy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the

Re: greylisting

On 7/31/10 3:11 PM, Jeremy Huntwork wrote: > On 7/30/10 10:39 PM, Bruce Dubbs wrote: >> Go ahead. I tried to get SPF to work once, but it didn't work for me. >> That was several years ago though. > > Testing once more... Well, it seems greylisting is gone now, although

Re: Package Management and such (Was RE: Website)

On 7/31/10 4:44 PM, DJ Lucas wrote: > Unfortunately, most times anyway, a proof of concept must come first > before anybody will listen. Take for instance Jeremy's > community.lfs.org site for which this thread started. Most of us agree > that the website is looking a little tired, but it took th

Re: greylisting

On 7/31/10 4:12 PM, Bruce Dubbs wrote: > I get the rejected links for almost all the lists daily. Typically > there are 4 or 5 messages per list. There's a summary for each list > every morning. I can delete them from the summary fairly quickly. > > In a way, it's interesting to see the identica

Re: Website

On 8/2/10 4:35 PM, Matthew Burgess wrote: > 1) http://community.linuxfromscratch.org/ - This should be a pretty sparse > page > with just a description of that LFS (the project) aims to do, with a link to > each of the sub-project's front pages. Sure, that's easily modified. > 2) http://communit

Re: Website

On 8/2/10 5:45 PM, Matthew Burgess wrote: > With that in mind, I've also just realised that > http://community.linuxfromscratch.org/projects/lfs has no links to send > readers to the online copies of the actual book! I'm not sure where the > links to > those would go; perhaps remove the 'Members'

Re: Website

On 8/2/10 5:21 PM, Ken Moffat wrote: > Bear in mind that I hate change (except when I like it ;) - the details on > /my/page are unpleasant. I can cope with 0 issues assigned to me, and > I'm sure that will be useful when I'm actually doing something. But I really > don't need "Reported issues" (

Re: Another problem in current -dev

On 8/4/10 6:56 PM, Ken Moffat wrote: > Actually, this is the first problem I saw, but I've waited until the final > toolchain was completed before I mention it. > > On x86_64, with glibc-2.12.1 and otherwise the 20100803 book, in > pass 2 glibc the build failed in libgomp with > > configure: error:

Re: fcron php ~/update_packages.php

I have a script that runs on one of my servers every 6 hours. It downloads the latest version of the LFS book from svn, parses the urls from it and then downloads the required files into appropriate directories. Oftentimes, this breaks on patches because it takes some time for the book on quant

Re: fcron php ~/update_packages.php

On 8/5/10 5:20 PM, Bruce Dubbs wrote: > > I just copied it from glibc-2.12.1-makefile_fix-1.patch so it should be > OK now. OK. Any idea why it failed? If there's a bug in the rendering scripts, we should probably identify it. Jeremy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ:

Re: fcron php ~/update_packages.php

On 8/5/10 9:59 PM, Chung Pham The wrote: > Could I get your script ? > and fcron line to run script ! > my mail: pham.the.chu...@gmail.com > Thank you ! Sure. Here's the source: http://dev.lightcube.us/~jhuntwork/update_packages.phps You'll need php with suppor

peekfd on x86_64

Hello, Anyone else notice that psmisc-22.12 is not building and installing peekfd on x86_64? Apparently this is a known issue with an upstream fix: http://sourceforge.net/tracker/?func=detail&aid=3029302&group_id=15273&atid=115273 Jeremy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev

Re: glibc-2.12.1-gcc_fix-1.patch doesn't exist

On 8/9/10 7:49 AM, Matthew Burgess wrote: > > I should be able to fix the link up in a couple of hours. Don't forget these: Retrieving file: glibc-2.12.1-gcc_fix-1.patch Retrieving file: glibc-2.12.1-makefile_fix-1.patch Jeremy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http:/

Re: peekfd on x86_64

On 8/9/10 5:34 AM, Ken Moffat wrote: > I hadn't noticed, but I confirm I don't have peekfd. Looking in > my logs, the only reference to peekfd is a link for the man page, > no sign of any reported errors. This patch fixes the issue: http://dev.lightcube.us/~jhuntwork/sources/psmisc/psmisc-22.1

Re: peekfd on x86_64

On 8/9/10 12:04 PM, Matthew Burgess wrote: > Thanks Jeremy. Could you confirm the following sed has the same affect > please? > > sed -i -e 's/struct_rdx" "/&#include\n/' configure Nope, but this does: sed -i 's...@#include @#include \n&@' configure Yours was only catching one instance of the

Re: peekfd on x86_64

On 8/9/10 5:44 PM, Matthew Burgess wrote: > Right, I misunderstood how the configure.ac construct was going to expand so > only applied it > to one of the occurrences. Totally understandable. :) Took me a few looks to figure out exactly what was happening, too. > I'll add your version during my

New binary with sysvinit

FYI, The new version of sysvinit you've added to the dev book includes a binary not listed in the book (at least on x86_64, I assume it's not arch-specific): /sbin/fstab-decode Jeremy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe:

Bootscript future

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 syst

Re: Bootscript future

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. Possibly, except that the scripts themselves should have chkconfig parameters in them - an

Re: Bootscript future

On 8/10/10 6:49 PM, Matthew Burgess wrote: > Having got so used to doing this at work just recently, I wondered why LFS > didn't have the > 'service' binary. Apparently it should be supplied by sysvinit (see, for > example, > http://packages.ubuntu.com/lucid/i386/sysvinit-utils/filelist). It wa

Re: Bootscript future

On 8/11/10 12:49 AM, DJ Lucas wrote: > 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 Awesome thanks. J

Re: Bootscript future

On 8/11/10 12:49 AM, DJ Lucas wrote: > 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. I've got to figure out why things are still taking so long... Greylisting has

Re: Ticket 2722 (Mistake on the linux console page)

On 8/18/10 11:16 AM, Bryan Kadzban wrote: > I wish Alexander was still around; he knew a lot more about language > issues than most of us. Mostly because he could read Cyrillic, I > believe. :-) He still monitors the lists, apparently, or at least checks in now and then. He sent me this message

Re: lfs on xen

On 8/19/10 12:54 AM, Bruce Dubbs wrote: > Has anyone built lfs as a xen client? I've tried a couple of kernel > builds, but they didn't work. I'm very new to xen and haven't worked > wtih it before today. > > To start, I've got a CentOS client running, but cannot properly build a > new kernel. >

Re: Perl -fPIC on x86_64

On 8/19/10 7:12 AM, Andrew Benton wrote: > Should -Duseshrplib be added to the book? I'm fairly certain I've built mod_perl on x86_64 using perl as built in LFS. What exactly does that switch do? Jeremy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org

Re: Perl -fPIC on x86_64

On 8/19/10 9:48 AM, Andrew Benton wrote: > On 19/08/10 13:56, Jeremy Huntwork wrote: >> On 8/19/10 7:12 AM, Andrew Benton wrote: >>> Should -Duseshrplib be added to the book? >> >> I'm fairly certain I've built mod_perl on x86_64 using perl as built i

Re: Bootscript future

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.

Re: Bootscript future

On 8/23/10 11:12 PM, DJ Lucas wrote: > 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. Heh, no worries, I was just glad the fix went in. :) Jeremy --

Re: IANA-Etc links broken (for now)

On 11/23/10 12:33 PM, Bruce Dubbs wrote: > William Immendorf wrote: >> On Tue, Nov 23, 2010 at 1:59 AM, Ilya Kaliman wrote: >>> I think we can drop the package itself and supply /etc/services and >>> /etc/protocols directly as most distributions do. We can get newer >>> versions from one of the di

Re: IANA-Etc links broken (for now)

On Nov 23, 2010, at 7:10 PM, Bruce Dubbs wrote: > William Immendorf wrote: > >> Instead, what I'll do is use the scripts from IANA-etc to format my >> files, so it'll be a new version of IANA-Etc. I'll mantain this >> package and make announcements here. The only thing I need is some >> hosting

Re: PPL and Cloog-Pharma

On Apr 6, 2011, at 6:14 PM, Ken Moffat wrote: > From my viewpoint (minimalist, extra packages which aren't > mandatory need to be justified), the lack of applications (that I > know of, maybe there is now something) which detect and use > Cloog-whichever was the problem. The number of applicatio

Re: Possible system changes

On Apr 15, 2011, at 6:01 PM, Bruce Dubbs wrote: > Following some of the discussion lately on file placement, we may want > to consider doing the following: Which discussion? Did I miss a thread? Thanks, JH > -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfroms

Using the LSB Bootscripts

Hello, So we've been using the LSB bootscripts for some time now on LightCube OS, with very little modification (we added dhclient service and the random bootscript to the default install), and it's behaved wonderfully. There have been a few things that we noticed that we felt needed to change

Re: Using the LSB Bootscripts

On 5/8/11 8:03 PM, Bruce Dubbs wrote: > Wouldn't this be a BLFS issue? It's a good idea, but I don't use dhcp > myself. It makes it hard to ssh into the system. :) yep, necessary for a packaged distro though. And invaluable for network booting. > I'm not sure about the name rc.local, but I lik

Re: Using the LSB Bootscripts

On 5/8/11 8:46 PM, Bryan Kadzban wrote: > This seems like it might be starting to get complicated. The scripts > may set up more than just IP addresses. (I have one to set up WoL bits > via ethtool, for instance.) > > I don't think there's any way to make all potential service scripts able > to h

Re: Using the LSB Bootscripts

On 5/8/11 8:57 PM, Jeremy Huntwork wrote: > I'll get the scripts up as soon as I can. I had to take a break to > finish up some other important work tonight. At the latest, I'll have > them available tomorrow. Here's the main scripts as they currently are (

Re: Using the LSB Bootscripts

On 5/9/11 1:57 AM, Bryan Kadzban wrote: > I believe the book has static IP addressing, and DHCP. There's also > both PPP (for both dial-up modems and cell-phone-network access) and > PPPoE, and I've added WoL to this system, as noted above. (Obviously > that only works for wired network cards tho

Re: Using the LSB Bootscripts

On 5/9/11 2:53 AM, DJ Lucas wrote: > The simple solution is to stop networking before applying changes. When Yes, I know. :) But in practice that becomes an annoyance. Admins used to working Fedora/Debian/Ubuntu or others assume that changing the config and running 'service network restart' is s

Re: Using the LSB Bootscripts

On 5/10/11 8:25 AM, DJ Lucas wrote: > * Most important, pull as much as possible of the items below from > LightCube OS's files to ease merging and keep the diffs to a minimum so > that they are easily shared across distributions. > * Move ifup and ifdown scripts to /sbin. > * Mov

Re: Using the LSB Bootscripts

On 5/10/11 8:25 AM, DJ Lucas wrote: > * Move network service scripts to /lib/services (there was one > minor objection here, should that be /lib/network-services or > /lib/network? I don't really have any preference here, /lib/services is > fine by me). Forgot to mention that I vote for /lib

Re: Using the LSB Bootscripts

On 5/9/11 11:36 PM, Bryan Kadzban wrote: > Right, but the former /etc/sysconfig/network* was also default > configuration for how the bootscripts run. Well, the network script > anyway. :-) Just ifup/ifdown (which are now in /sbin) and network-services/* which is now in /lib/{network-}services

Re: Using the LSB Bootscripts

On 5/10/11 11:13 AM, DJ Lucas wrote: >> Why MIT? These aren't book instructions. > > Hmm, to change licenses, or rather define one outside the scope of the book, > we'd need approval from all contributors. That is currently AFAIK Alexander, > Archaic, Bruce, Dan, Jeremy, Matt, Michael Tremmor (IP

Re: Using the LSB Bootscripts

On May 10, 2011, at 3:26 PM, Matthew Burgess wrote: >>> >> > I don't mind changing the version numbering to whatever suits people best, > but I'm just interested as to why this is an issue? If I had to pick any > numbering scheme at all, I'd choose something simple like Udev's; I wouldn't say

Re: Using the LSB Bootscripts

On 5/10/11 9:11 PM, Bruce Dubbs wrote: > Unnecessary. The book copyright already covers it. Except, if I am understanding it correctly, if LightCube OS uses and distributes it, we are bound by that license to keep the it with the code and we have no other tie to the book. So putting the license

Re: Using the LSB Bootscripts

On 5/10/11 9:06 PM, Bruce Dubbs wrote: > A date gives the user additional information. How long since the last > change? Do I really need to update? Using mmdd gives a > monotonically increasing number and an idea of how long it has been > since changes were made. That is my preference. *s

Re: udevadm --settle

On 5/12/11 3:09 AM, DJ Lucas wrote: > Sure there is...a fully event driven init as Bryan described earlier. I > just don't find that to be transparent enough for my taste, nor udev > quite mature enough just yet (as evidenced by this very issue), though > it is getting there slowly but surely. Per

Re: Summary: Using the LSB Bootscripts

On 5/16/11 1:49 AM, Bryan Kadzban wrote: > I'm not sure what the goal *should* be. :-) Does it make sense to try > to clean up completely in this kind of setup? Maybe or maybe not. > > I do think it's least *surprising* to only undo the effects of the start > script, though. For whatever that's

Re: Changes to contrib bootscripts

On 5/18/11 1:16 PM, DJ Lucas wrote: > Alright, with last commit to lsb-bootscripts, I think we are ready to > go. Bruce, Matt, you guys get a chance to review the patch? I've been looking over the scripts, they look good, nice job! There are a couple of things that I think I'd still prefer to see

Re: Summary: Using the LSB Bootscripts

On 5/18/11 12:28 AM, Bryan Kadzban wrote: > Anybody know how other distros do it? I can't figure out what Debian's > ifdown binary is supposed to do (its source is *extremely* obfuscated, > being built from a texinfo file, and containing a file parser)... Fedora does a much more elaborate version

Re: Summary: Using the LSB Bootscripts

On 5/15/11 3:25 AM, DJ Lucas wrote: > wanted anyway). Problem with dhclient is that the value of DHCP_STOP > will always be empty...all interfaces using dhclient will go. If you do > 'service network stop' then no big deal. OTOH, if you execute ifdown > ethn, and you have dhclient configured on mul

Re: Changes to contrib bootscripts

On 5/18/11 1:16 PM, DJ Lucas wrote: > On 05/14/2011 11:12 PM, DJ Lucas wrote: >> Attached patch is pretty invasive, 33 KB uncompressed. :-) I wasn't >> sure whether to leave inittab in the book where it is currently, but I >> am thinking from a packaging POV that it should remain as is and be >> re

Re: Changes to contrib bootscripts

On 5/18/11 9:26 PM, DJ Lucas wrote: > Results of a bad sed? I hadn't noticed that, only fixing the misspelling > in the dependencies. Prior to that commit it was "kernel" when it was > mountkernfs. Fixing. > > Thanks. Ha ha, the ones in the parentheses got me, it looked intentional. I actually go

Re: Changes to contrib bootscripts

On 5/21/11 2:48 AM, DJ Lucas wrote: > I do plan to add a "service" script later that would alleviate the issue > completely, as was suggested by Jeremy a few months ago, but I'm a > little stuck as far as how to handle multi-level, conditional tab > completions in bash, so it is on hold for a sec.

Re: Changes to contrib bootscripts

On 5/21/11 12:52 PM, DJ Lucas wrote: > Oh, I didn't realize that it had continued beyond the new network script > and ifup/ifdown scripts, or rather I read it as just example, not an > actual suggestion. Give me a few minutes to run through the thread again. I didn't actually see the new scripts.

Re: Changes to contrib bootscripts

On 5/21/11 1:20 PM, Bryan Kadzban wrote: > The service script might work, but it's a complete re-training for me, > and I'm a bit of a curmudgeon. That's probably not a reason to avoid > doing it, though. :-P The first picture that came back in google's image search for curmudgeon: http://ameri

Re: svn bootscripts

On 5/31/11 7:28 PM, DJ Lucas wrote: > Yeah, I had thought about PHP, and I know you are good at that. I > suppose waiting until BLFS would work, then it could be up the user to > select which tool set is best for them. I don't exactly like that idea > personally, but it should provide a working com

Re: svn bootscripts

On 5/31/11 10:55 PM, Bruce Dubbs wrote: > It just another package and I'd like to avoid that in LFS even if it is > CMMI. If the install of the bootscripts is basically copying files and > setting some symlinks, we don't need a C program to do just that. Well, yes, that is what it's doing, but it

Re: svn bootscripts

On Jun 1, 2011, at 12:10 AM, Bruce Dubbs wrote: >> >> > Also see > http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html#SWINSTALL-INTRO > > They may say that you don't have to actually use rpm, but only that a > conforming application can process rpm pa

Re: Bootsplash for LFS 6.8

I splashed my screen with juice once. Wah wah wah. Thanks, JH On Jun 15, 2011, at 6:36 PM, Bruce Dubbs wrote: > Ankur Agrawal wrote: >> Hey guys, did anyone have successfully installed the splash screen on LFS >> 6.8 ?? > > I'm still working on GRUB-1.99, but I had a splash screen working f

Re: svn bootscripts

On 5/31/11 2:21 AM, DJ Lucas wrote: > On 05/30/2011 12:34 PM, Bruce Dubbs wrote: I'd appreciate it if you could do a revert. > > Done. So where are we standing with this currently? What's left to do and what's the intended path? I know what I want to happen with LightCube, but I'd like

Re: Bootscript reorganization

This is requesting feedback on many of the exact things we discussed in a recent thread, although some of the conclusions were different. I can't pull up the exact thread at the moment since I'm on the road, but DJ should be able to point the way. Thanks, JH On Jul 7, 2011, at 12:31 PM, Bruc

Re: Partial update of bootscripts

On Jul 20, 2011, at 3:12 AM, DJ Lucas wrote: >> >> >> >> >> > I didn't get a chance to install yet, but did a quick walk through, and > barring any simple errors, they look good, nice and clean too. More time > tomorrow hopefully. Suggestions: need to add LSB headers to all of the > script

Re: Rewrite bootscripts and Chaper 7

On Sep 1, 2011, at 6:48 PM, Nathan Coulson wrote: > [I dont like this suggestion] We could use /run to keep track of what > interfaces are up/down, but that would add more logic then I think our > scripts should have... > [nor this one] An alternative is to add more code to ipv4-static to > detect

Re: Rewrite bootscripts and Chaper 7

On Sep 1, 2011, at 9:03 PM, Bruce Dubbs wrote: >>> >>> >> > What I did is basically the same as the LSB scripts, but updated for > /run and to streamline the file locations. > > The only outstanding issues are network related in some relatively rare > cases (e.g. multiple IPs attached to a

Re: Rewrite bootscripts and Chaper 7

On Sep 2, 2011, at 1:27 AM, DJ Lucas wrote: > >>> >> > I believe complexity was the main objection. Seriously? What complexity? I'm sorry but LFS is a complex book for advanced Linux users. We're really going to run away from a set of shell scripts because we can't be bothered to read th

Re: Rewrite bootscripts and Chaper 7

On Sep 2, 2011, at 1:13 PM, Bruce Dubbs wrote: > Jeremy Huntwork wrote:e >> >> >> > Complexity was not the reason I rewrote the scripts. I didn't want to > add initd-tools to LFS, although I did add it to BLFS. I made the > scripts LSB compatible, but di

Re: Rewrite bootscripts and Chaper 7

On Sep 2, 2011, at 4:55 PM, Bruce Dubbs wrote: > What point? That you duplicated all the effort DJ spent addressing these same issues and improvements in the LSB bootscripts. We had _long_ discussions about this which you seemed only vaguely interested in and did not appear to follow well and

Re: Rewrite bootscripts and Chaper 7

On Sep 2, 2011, at 10:48 PM, Bruce Dubbs wrote: >> >> >> > I didn't disregard the other work. I basically integrated the LSB > scripts into the old scripts and made some new changes that I felt were > needed Then I'm glad you didn't disregard the work. I still disagree with backporting cha

pkg-config tests

You modify the expected return value of a test for pkg-config and in doing so, I think you may be invalidating the test. I have not yet had the time to dig deeper into it, so it's possible I'm missing something, however, the script's comments say it's testing for a broken popt lib. I use a syst

Re: pkg-config tests

On Sep 3, 2011, at 11:52 AM, Bruce Dubbs wrote: > I think the change is to the internal pkg-config version of popt. If an > external version of popt is used, then the change to the test may not be > needed. It's changing the test-suite, the script that checks pkg-config's usage of popt, not th

Re: pkg-config tests

On Sep 3, 2011, at 12:58 PM, Matthew Burgess wrote: > Confirmed here with popt-1.16. It seems odd that pkg-config bundles a > version of popt known to be broken, and requires a configure switch > (with-installed-popt) to use a system-installed version. popt is > certainly small enough to bring

Re: pkg-config tests

On Sep 3, 2011, at 1:13 PM, Jeremy Huntwork wrote: > On Sep 3, 2011, at 11:52 AM, Bruce Dubbs wrote: >> I think the change is to the internal pkg-config version of popt. If an >> external version of popt is used, then the change to the test may not be >> needed. >

pcreposix

Hello, Now that pcre is part of the base LFS, I think you need to take into consideration how you will handle the conflict with the libc namespace, namely some of the functions declared in regex.h and their associated symbols in libc.so.6 The readme file (http://www.pcre.org/readme.txt) has th

Re: Bootscripts rewrite - writing/logging messages

On Sep 6, 2011, at 1:42 PM, Bruce Dubbs wrote: > Comments? Test and use the LSB scripts. There's no reason to duplicate all this effort in the current scripts. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above informa

Re: LFS' future server plans

On Sep 11, 2011, at 7:23 PM, Gerard Beekmans wrote: >>> >> >> > I agree on the issue with Git and that it appears to be overkill for > what LFS needs. But, seeing you raised it, let's at least give it an > honest discussion before summarily dismissing it. I like the idea of git. Certainly i

Re: udevadm: trigger --type=failed deprecation

On Sep 13, 2011, at 1:02 PM, Bruce Dubbs wrote: > ntpd -q doesn't daemonize. It just hangs. That's why I have modified > my boot script to: -g is still a useful flag to have. My bootscripts (and Fedora's) use -g on startup for ntpd. It allows the first time correction to be large (IIRC). JH

Re: udevadm: trigger --type=failed deprecation

On Sep 13, 2011, at 10:37 PM, Bryan Kadzban wrote: > Yes, but I think there's another way to accomplish this, without the > long delay inherent in using -q. If we can sync from the hardware clock > at boot time, then the user only has to manually adjust (or run ntpd -q > manually, and wait for it)

Re: Question about chapter 6: file before gcc

On Tue, Oct 18, 2011 at 11:21 AM, Jonathan Oksman wrote: > I was curious about these compiler warnings so I decided to look into > it a bit further through various logs. At a glance it looks as though > the issue is that gmp, mpfr and mpc are all using hardwired paths to > /usr/bin/file or /bin/

Stripping in Chapter 6

There appears to be a somewhat bogus statement in section 6.63 "Stripping Again". It says there: "If disk space is very tight, the --strip-all option can be used on the binaries in /{,usr/}{bin,sbin} to gain several more megabytes. Do not use this option on libraries—they will be destroyed." The st

Re: Stripping in Chapter 6

On Thu, Oct 27, 2011 at 8:58 AM, Dan Nicholson wrote: > http://www.technovelty.org/linux/strip.html That was a great link, thanks. And nice simple examples you gave, too. Aye, there indeed be dragons. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.or

Re: Stripping in Chapter 6

On Oct 27, 2011, at 11:46 PM, Bruce Dubbs wrote: > I guess the only thing we should do is change the last sentence in > section 6.63 to: > > Do not use this option on static (.a) libraries—they will be destroyed. Maybe recommend using --strip-unneeded instead since that intelligently does the ri

Re: Stripping in Chapter 6

On Oct 28, 2011, at 2:41 PM, Bruce Dubbs wrote: > Jeremy Huntwork wrote: >> >> Maybe recommend using --strip-unneeded instead since that >> intelligently does the right thing for both types of libs. > > So you recommend instead: > > "If disk space is very

Re: Stripping in Chapter 6

On Oct 28, 2011, at 10:42 PM, Bruce Dubbs wrote: > Well, --strip-unneeded doesn't, but --strip-all on libraries does > because I think using that would basically destroy static libraries. The > chance of a user using a wildcard with that is reasonably high. I feel like there must be a misunderst

Re: Stripping in Chapter 6

On Oct 29, 2011, at 12:26 AM, Bruce Dubbs wrote: > I've already removed it in Chapter 6 and the wording in Chapter 5 is > accurate. Cool, glad you got it in chapter 6. Did you see Jonathan's email? The wording in chapter 5 may not be accurate. It says: "Take care not to use --strip-unneeded on

Re: LFS-7.0 is released

On Oct 29, 2011, at 1:46 AM, Bruce Dubbs wrote: > A somewhat major change was made in this version of the book by adding a > new top level directory, /run. This directory has a tmpfs mounted and is > used by programs like udev to store run time information. The > directories /var/run and /var/lo

Re: [lfs-dev] LFS7.0

On Dec 29, 2011, at 5:43 PM, Bruce Dubbs wrote: > Sure, it's a requirement, but if it isn't there, then the check for libc > fails. Right now, the resources needed are head, cut, echo, readlink, > and cat; other than the resources being directly tested. > > I just don't want to see a cascading

Re: [lfs-dev] LFS7.0

On Jan 5, 2012, at 12:09 AM, Bruce Dubbs wrote: > That's too complicated. The idea is to keep it as simple as possible. I'm sure whatever you choose to do is perfectly fine for your needs, but objecting to parameter substitution as being more complicated than piping to head and then cut is sill

Re: [lfs-dev] LFS Direction

On Jan 13, 2012, at 1:50 AM, Nathan Coulson wrote: > On Thu, Jan 12, 2012 at 1:32 PM, Bruce Dubbs wrote: >> >> >> If we don't add things like an initramfs to the book, we will probably >> need to limit what our users can do. Initramfs is widely used everywhere else, so at the least, even if it'

Re: [lfs-dev] LFS Direction

On Jan 13, 2012, at 11:20 PM, Bruce Dubbs wrote: > I agree. To me, an initramfs seems to be much more useful for a desktop > system than a server. This particular statement I don't agree with. An initramfs, IMO, doesn't have much to do with your intended use of the system, whether server or des

Re: [lfs-dev] LFS Direction

On Jan 14, 2012, at 1:54 AM, Zachary Kotlarek wrote: > While I agree that server vs. desktop is not the issue, you guys really need > to try the modern disk management tools -- LVM or ZFS or anything similar. > It's worth the hassle, I promise. Even if you decide you don't care on your > system,

Re: [lfs-dev] Udev-177 & Kmod-3 WIP patch

On Jan 16, 2012, at 12:27 PM, Bryan Kadzban wrote: > > I'd be curious what's in /proc/mounts as well, but eh whatever. Is there a reason LFS doesn't just symlink /etc/mtab to /proc/mounts? JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsub

Re: [lfs-dev] Udev-177 & Kmod-3 WIP patch

On Jan 16, 2012, at 1:21 PM, Bruce Dubbs wrote: > My objection is that mtab has > /dev/sda5 / ext3 rw 0 0 > > where /proc/mounts has > rootfs / rootfs rw 0 0 > > 'rootfs' doesn't tell me much. I can see that it is the rootfs because > it's mounted on /./dev/sda5 and ext3 give me informati

<    1   2   3   4   5   6   7   8   9   10   >