Re: Updated acknowledgment
Jean-Philippe MENGUAL wrote: > Hi, > > Here's a suggestion to update the acknowledgment. I wonder if it's not the > process I'm supposed to use to suggest such changes. > > Best regards, JPM When the book is released, the website will need to be updated as well. Is the location of the translation the same? Thanks, -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New Linux Headers method
Greg Schafer wrote: > On Mon, Oct 27, 2008 at 12:54:04AM -0400, Jeremy Huntwork wrote: >> Greg Schafer wrote: >>> On Thu, Oct 16, 2008 at 11:52:13PM -0400, Jeremy Huntwork wrote: >>>> http://www.linuxfromscratch.org/~jhuntwork/linux-2.6.27.1-perl_compat-1.patch >>> Interesting. I've become busy again and haven't had a chance to test the >>> 2.6.27 headers yet. You must be doing the crazy thing and test-building >>> from >>> RH6.2 like I do :-) Nice work on the patch. Did you CC the right kernel >>> people? >> So Andrew Morton just emailed me a message that it's in his tree >> (although I don't see it yet), so maybe this will get in after all. > > Ah, cool. I was going to send you a note that Sam the Kbuild maintainer had > resurfaced and to ping him: > > http://article.gmane.org/gmane.linux.kbuild.devel/2767 And now the patch is in Linus' tree, so it looks like this incompatibility will disappear with 2.6.28 -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc-4.3.2 build fails
John Frankish wrote: > Hi, > > I'm trying to build on a playstation 3 with yellow dog linux v6 > > Although binutils-2.18 builds OK, gcc-4.3.2 fails after the first > bootstrap pass succeeds and then gcc tries to compile a second > version of itself. The failure is "gcc compiler cannot build > executables" - config.log does not give too many clues... > > Note that I'm obliged to build using > LDFLAGS=$CXXFLAGS=$CFLAGS='-m32' otherwise gcc-4.2.2 tries to build > a 64-bit version of itself and fails looking for gnu/stubs-64.h - > glibc and the rest of the ydl system is 32-bit. The host gcc is > gcc-4.1.1 (I think). -m32 only specifies what types of _binaries_ to produce. This means that when you build gcc with -m32, it will produce a 32-bit binary gcc (provided you have 32-bit libs, which you do), but the gcc you build will still be configured for a 64-bit machine and when you run it, it will attempt to build for that architecture. Because you don't have 64-bit libs, it will fail. You can't build 64-bit without first building a 64-bit libc, and you can't build 32-bit unless you modify your host settings. If you want to build LFS as 32-bit, you _might_ get away with hacking the output of uname to trick the build system into thinking you're running on a 32-bit host, but a saner approach would be to build a 32-bit only kernel. If you want to build LFS as 64-bit, there is an approach that currently works pioneered by DIY-Linux which involves cross-compiling your first glibc and then building natively after that. I have some notes on that method and have started adapting it to LFS, but I haven't published anything yet. Otherwise, as was already mentioned, CLFS should be able to help you in the right direction, too. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version in glibc
Matthew Burgess wrote: > I'm inclined to agree with Randy here, in that as we don't modify the > upstream sources at all, there's no need to 'LFS' in the version string. > That, to me, suggests that there's something LFS specific about the sources. > I'd think it would suggest the same to upstream as well, such that should an > LFS user or developer provide them with a bug report containing that string, > they may well direct users back to lfs-dev based on that assumption. I can see your point, but just to be a Devil's advocate here, while there's no modifications to the sources, there is a definite standard build instruction which affects the end result very much. If another distro were to build Glibc without any modifications, a label of some sort is still appropriate because they _way_ they build it is specific to their distro and identifies the resultant package with those build options. We've gone a long time saying that we aren't a distro. But in a sense we are. The book is _very_ specific as to its instructions. If you follow it you have an LFS system. (We even have our own bootscripts!). If you don't follow it you have either a mess or some sort of your own quasi-ma-jig distro type thingy. At the least, presenting an option like this demonstrates to the reader just a little bit more about customizing their build. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
The value of 64-bit vs 32-bit
Greetings, About a month or so ago I'd said I'd start looking into writing a section for LFS that deals with pros/cons of using full 64-bit libs/binaries in Linux, since LFS is considering adding in 64-bit support. I came across this article: http://forums.amd.com/devblog/blogpost.cfm?threadid=93648&catid=317 and several other articles from people who at various times benchmarked performance with 32-bit vs 64-bit on the same hardware. Just two quick questions: * Any comments on the details provided in the above article, specifically in how that might relate to LFS? * If you were to benchmark 32-bit vs 64-bit on an LFS system, what would your tests include? -- JH -- 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: > 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). 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. Well, the hardware has already moved en masse. All of AMD's current chips appear to support 64-bit. And even Intel's low-end Celeron chips these days support 64-bit. As far as software goes, nearly all (if not all) of the major Linux distros provide an x86_64 bit version. Software that is not usable or buildable on 64-bit is becoming more the exception than the rule. If the argument that '64-bit is where computing is unequivocally heading' is enough to bring 64-bit support into LFS, then to me that is enough to provide support without justification, or without worrying about listing pros and cons. It is what it is, and just the natural progression of things. The only consideration, to my mind, would then be: should LFS worry about providing multilib support or not? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Readjusting toolchain nitpick
In section 6.10, Readjusting the Toolchain we perform about 3 sed expressions to specs file. The first one looks like this: -e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED]' Also, there is a prominent note before this sed command stating: "If working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, substitute “ld-linux.so.2” with the name of the platform's dynamic linker in the following commands. Refer to Section 5.2, “Toolchain Technical Notes,” if necessary." We can simplify the sed expression and get rid of the note entirely if we change it to: -e 's@/tools@@g' Anyone have any objections to this change? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Readjusting toolchain nitpick
Greg Schafer wrote: > Jeremy Huntwork wrote: > >> We can simplify the sed expression and get rid of the note entirely if we >> change it to: >> >> -e 's@/tools@@g' >> >> Anyone have any objections to this change? > > I'd just like to make the following points: > > 1. You're introducing a distinct lack of clarity about what is actually >being performed. > > 2. The dynamic linker issue is such a critical aspect in the whole process >that it warrants highlighting. I appreciate those concerns, and a concise explanation about what is happening should still be highlighted textually. My motives for the change are that it simplifies the command and it will work for all cases, so there would be no need to say 'use a different linker name if your platform requires it'. I always thought that was kind of an unfitting warning anyway for a book that claims to support only x86. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Chapter 6 building against /tools still?
Greg Schafer wrote: > Simon Geard wrote: > >> One other thing I wonder about, in the find 6.4 book. As I noted before, >> one of my earlier problems was that libtool was ending up with hardcoded >> references to /tools/bin/grep, which I corrected by moving grep to be >> build a little earlier. However, the 6.4 book has grep built after >> libtool, so I'm not sure what's going on there... > > It looks like you missed the /bin/grep symlink from `Creating Essential > Files and Symlinks'. From memory, I believe it was put there to satisfy > the silly "Alphabetical" build order. A simple change in the build order > is IMHO much more preferable than an extra symlink. You're right. The alphabetical change was first and foremost intended to help document dependencies and to understand why we built packages when we did. A very secondary intent was to provide a mechanism for placing packages where the build order wasn't critical. The goal was _not_ to simply alphabetize the book. Therefore, when we were still trying to decide how to handle certain issues that came up, I think we made a concession with the grep symlink, perhaps because it seemed a small issue or 'less work'. To be honest, especially looking back on it now, using a symlink was not in the spirit of the change. Grep should have been moved up in the build. Because this was a consensus made by several people back in the early part of 2006, I'd like to open it up for comment again now. Anyone mind if we do the more technically correct thing and move grep up in the build order of chapter 6? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Fwd: LFS 6.4: Helped me with with "/tools/bin/ld: cannot find -lgcc_eh " in Chapter 5.7 Patch for glibc --]
Bruce Dubbs wrote: > But this helped me... > > Btw I'd appreciate if youl'd make a notice to this patch in that (and the > other chapters as well) in chapter 5.7 of LFS 6.4... This patch is unecessary in LFS, since we create a symlink at the end of gcc-pass1, like so: ln -vs libgcc.a `gcc -print-libgcc-file-name | \ sed 's/libgcc/&_eh/'` He probably missed this command or didn't run it successfully (didn't use backticks?) -- JH -- 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: > Anything else? Oh, I also forgot. We could give some thought to using DIY's new build method, which is essentially building the first pass of binutils and gcc as cross compilers, cross-compiling the first build of Glibc and building natively after that. There's several advantages to doing it this way. To briefly mention a few: * Much less chance of anything on the host side creeping in or affecting the build. * If you have 64-bit hardware but are using a 32-bit OS, you can build the new system as 64-bit, if you wish. * There is less complicated toolchain adjustment for chapter 5. I'm sure Greg would have more... One thing that does concern me, although I know Greg has a solution worked out for this, I'm not sure how long this solution would be valid in the future. Upstream appears to think that using sysroot is the correct approach, and Greg currently backports a change in GCC in order to allow this build method to work. See here, it's an interesting read: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Aiming for 7.0
I would prefer if it didn't take us another year (or more) to push out a 7.0 release. Or, even if it did, as long as the time is well spent. I.E., we are actually pursuing the new features we slated and not just letting package updates slowly creep in. I know we have listed things before, but can we get a solid picture of what new features we are bringing in for 7.0? I'll start us off: * 64-bit support * Multilib? * DESTDIR style PM support? (To me, this is the easiest way of offering a default pseudo-style PM support. We don't actually tell the users how to package up the binaries, track dependencies or track what is installed, but we do show whatever DESTDIR-compatible commands exist for the package so that LFS can be that much more compatible with a wide range of PM offerings). Anything else? Also, as far as the 64-bit stuff goes, I don't think the task should be left up to just me. It would be nice to get some other hands on that. If we're planning on using anything that's already existing in the jh branch to port over to trunk, perhaps we should just copy again to another 64-bit branch for use by everyone. I would hope that would encourage a few devs to get their hands dirty with it. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
xkeyboard-config and intltool
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? -- JH -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
xorg-server and pixman
Hello, I know there has been a lot of discussion on Xorg lately, so sorry if this is bringing up a known issue, but xorg-server also appears to require pixman now. The instructions in BLFS svn break for me at xorg-server because pixman is missing. If I build and install pixman as per the instructions in the Xorg Libraries section, then xorg-server builds fine. Should be enough to just add the file name of the latest pixman file to the lib wget file. -- JH -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xorg-server and pixman
Dan Nicholson wrote: > Yeah, pixman is now required for both the xserver and cairo. I thought > DJ added it, but maybe I'm just guessing. It's not part of the Xorg Library section (which is where it appears to belong) and I didn't encounter it anywhere else. -- JH -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Aiming for 7.0
DJ Lucas wrote: > 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. Well, I've learned to leave room for the differing views, because you can never quite tell what the reaction will be to various proposals. Or at least, I can't... :-) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Greg Schafer wrote: > Greg Schafer wrote: > >> In a (native) sysroot scenario, anything and _everything_ can be found >> on the host. > > Here's a Binutils thread about a sysrooted ld which touches upon what I'm > talking about: > > http://sourceware.org/ml/binutils/2008-08/msg00060.html Interesting. Thanks for that. I knew you'd have a good reason for avoiding it. But I'm still not quite sure where that leaves us with the bug you reported and the patch you are using. There seems to be a difference in thought as to how GCC should behave when run from $objdir. What do you think is likely to happen in future versions and/or what is your plan? Just continue to maintain the backport patch for future versions? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Ok, so we have a fair amount of items we'd like to push into 7.0, some of which, work has already begun. As far as step-by-step plan of attack goes, how does this sound? 1. Move to DIY's new build method in trunk. If we ignore multilib and any extra arch support for this step, the changes required aren't actually that many, and they all take place pretty early in chapter 5. We can have trunk using the new build method within a day. 2. Add instructions for DESTDIR commands. I don't think there has yet been a consensus yet on what type of PM to use. But, if we make the instructions just slightly more PM friendly by adding in DESTDIR commands it opens up a wide range of possibilities. If we limit the changes now to just adding in DESTDIR commands and a short explanation about what these mean somewhere or how to work with them, we should be able to drop this into trunk in a short time (a day or two?). Otherwise we may need a separate branch for PM. 3. Merge all recent changes in trunk to the jh branch, copy that branch to a new multi-arch branch and strip out anything extra that doesn't really have to do with adding multiple archs. (I don't think there are many, but I'd just have to do a quick look.) Hopefully making this its own branch again would encourage a few more people to get involved in finsihing up these changes. If desired, multilib support could also be added to this branch. 4. Ticket 2284, upgrade of Udev, and strip out udev-config. I doubt this needs its own branch. What sort of time/work is involved here? 5. Ticket 2033. Include support for initramfs. Would this require a separate branch, and can it be worked on in parallel to other changes, or is it better to wait until other above changes are sorted out? Have I missed anything? -- JH -- 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: > I've already got the trivial patch that upgrades Udev, but doesn't strip out > Udev-config. It's been build-tested but not boot-tested currently. It may > have an impact on the minimum host-kernel pre-req, but I don't have anything > to test on to confirm/deny this. My proposal would be to just chuck it over > the wall and see what breaks - this is trunk after all :-) I certainly don't > think it needs its own branch. > > I think stripping out Udev-Config is fairly safe too - the discrepancies I > flagged may cause some breakage in some esoteric use cases/devices but I > think by and large people will still be able to boot and use LFS-based > systems. Any breakage can be easily rectified by including new rules in an > LFS-format patch, which can then be submitted upstream for their > consideration. Alright, then I guess this is one of those things you can drop in anytime. Thanks, Matt. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Bruce Dubbs wrote: > Jeremy Huntwork wrote: >> 1. Move to DIY's new build method in trunk. If we ignore multilib and >> any extra arch support for this step, the changes required aren't >> actually that many, and they all take place pretty early in chapter 5. >> We can have trunk using the new build method within a day. > > That sounds fine to me. No objections so far, and a couple of encouraging comments, I'll start on this one now. >> 2. Add instructions for DESTDIR commands. I don't think there has yet >> been a consensus yet on what type of PM to use. But, if we make the >> instructions just slightly more PM friendly by adding in DESTDIR >> commands it opens up a wide range of possibilities. If we limit the >> changes now to just adding in DESTDIR commands and a short explanation >> about what these mean somewhere or how to work with them, we should be >> able to drop this into trunk in a short time (a day or two?). Otherwise >> we may need a separate branch for PM. > > This is also good. IMO, trunk is fine. OK, once I finish with the above, we can open this up as a ticket to bring all packages into compliance. This could probably benefit from a few different hands/eyes. >> 3. Merge all recent changes in trunk to the jh branch, copy that branch >> to a new multi-arch branch and strip out anything extra that doesn't >> really have to do with adding multiple archs. (I don't think there are >> many, but I'd just have to do a quick look.) Hopefully making this its >> own branch again would encourage a few more people to get involved in >> finsihing up these changes. If desired, multilib support could also be >> added to this branch. > > I'm not a big fan of branches. This would be fine for the trunk, but after > the > above two items are done and the changes have matured a bit. Do we have a > solution for the boot loader for this? OK. I assumed we'd want to get the boot loader stuff fixed up first. (No, it's not done yet.) The solution really amounts to: add lilo or grub2 for use by Non-multilib x86_64. Multilib x86_64 could obviously still make use of grub legacy. If we want to officially support PowerPC on new-world Macs (the current instructions in the jh branch do work for these) we'd have to add Yaboot for them. But if we're taking it as a separate ticket that we will be adding in a proper bootloader I could just go ahead and merge the jh branch back to trunk. > As a personal note, I guess I'll need to get a 64-bit system. I'm really > still > pretty happy with my current 3.2GHz/2G Ram. It almost never swaps and I use > KDE > and Vmware. I think my wife's system would work (it's an Intel 2160 with two > cores) but she would not be happy. ... thinking about it, I don't think > that's > a viable solution. :) > >> 4. Ticket 2284, upgrade of Udev, and strip out udev-config. I doubt this >> needs its own branch. What sort of time/work is involved here? > > Just do it. I don't think it will be a large time consumer. It could be > done now. Yep. This is Matt and Bryan's arena. >> 5. Ticket 2033. Include support for initramfs. Would this require a >> separate branch, and can it be worked on in parallel to other changes, >> or is it better to wait until other above changes are sorted out? > > This is one I don't agree with. This should be in BLFS. A pointer to a BLFS > page in LFS would be OK, but this goes beyond the philosophy of LFS as it is > only rarely needed. Well, I'll let the rest of you sort this one out as I can't say I have a strong opinion either way. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Greg Schafer wrote: > Jeremy Huntwork wrote: > >> 1. Move to DIY's new build method in trunk. If we ignore multilib and >> any extra arch support for this step, the changes required aren't >> actually that many, and they all take place pretty early in chapter 5. > > I realize you say "this step", but LFS is already too far behind, 64-bit > should be top priority. Actually, as I'm looking at it now, at least in terms of handling the XML, I'm thinking that you're right, it's going to be easier to merge the 64-bit changes in first. The changes required to pull in your method aren't really that many, but they do change things around a bit. But I know that's not really your point. You're speaking more to the logical development of the features. We are actually trying to do a good deal of 'catching up' here. All at once we're aiming for 64-bit, a new build method that supports multilib, and PM. Well, all I can say is, prepare for trunk to experience some periods of brokenness in the near future as we bring all this in. I think I'm going to start by bringing in the work that has already been done, namely allowing for 64-bit or 32-bit native in one book. Udev changes can be dropped in anytime, so can the DESTDIR stuff, since that's all in chapter 6. Greg, as I have your attention, I'm curious why the -fomit-frame-pointer change is still present in your second pass of gcc. I thought the purpose of this was to maintain compatibility between the first bootstrapped pass of gcc and the second pass? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r8754 - in trunk/BOOK: chapter01 chapter05 chapter06
Greg Schafer wrote: > This is nothing like the new build method at all. It appears you've taken > stuff from the old jh branch, which is now completely outdated because > it's based on the old build method.. Ughh. Not sure where you're going > dude, but this is definitely the wrong way to do 64-bit. As stated > earlier, I'm not touching the old method with a 10 foot pole.. Relax. :) This is not the final commit, we _are_ moving to your new method, this is just the first step. As far as x86 is concerned, nothing of importance has changed, so it's essentially the same build as what has always been in trunk. Much of the reason I wanted to merge the jh branch into trunk was because of the textual changes that had already been done there. > I realize it's early days, but how are you going to distinguish between > 32-bit and 64-bit builds? As it stands, you're creating 64-bit dirs even > in the 32-bit case. Yes, this is a valid point. I'll keep this in mind as we bring in the multilib method. >> Modified: trunk/BOOK/chapter06/readjusting.xml >> === >> --- trunk/BOOK/chapter06/readjusting.xml 2008-12-03 22:04:18 UTC (rev >> 8753) >> +++ trunk/BOOK/chapter06/readjusting.xml 2008-12-03 22:46:04 UTC (rev >> 8754) > >> -gcc -dumpspecs | sed \ >> --e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED]' \ >> +gcc -dumpspecs | sed -e 's@/tools@@g' \ > > So you went ahead and snuck this in anyway? No, I wasn't sneaking in anything. This was already in the jh branch. It was just part of the merge to bring in initial support for 64-bit. I have it marked in my TODO as I begin importing your build method to highlight textually what is going on with the command. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Moving to Grub2?
Hello, I started working on bringing in compatible boot loaders for use with x86_64 (and, possibly, PowerPC). The idea at first was just to move all bootloaders down to chapter 8 and list which ones are compatible for which arch/setup. I have started on that route already, see here: http://www.linuxfromscratch.org/~jhuntwork/lfs-trunk/ But as I'm working on this, I figured I'd pop in to grub2 headquarters and see what the status is. I know that historically, this community hasn't really been too fond of grub2 because of all the perceived attention spent on bells and whistles. Still, the idea of one bootloader that works for nearly all hardware (their site says: It is working on PC, OpenFirmware-based PowerPC machines (PowerMac and Pegasos) and EFI-based PC (IntelMac)), it's just too attractive to ignore completely. The latest version is 1.96, released in February of this year. Has anyone tested this yet? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving to Grub2?
Matthew Burgess wrote: > That said, I've not tried it out myself yet. Maybe in my next build! Testing it out now... Requires LZO, so if we were to use it we could move LZO from BLFS over to chapter 6 of LFS. One less package for BLFS devs to monitor... :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving to Grub2?
[EMAIL PROTECTED] wrote: > I've been running it since march and it happily boots everything I have > on the box. This includes OS X and WinXP i addition to LFS. Cant > remember any special problems either, but this is close to 9 months > back. I do remember using the instructions from CBLFS That's good to hear. I didn't realize that CBLFS had a page. I used this as a general guide: http://grub.enbug.org/TestingOnX86 I must say, this was the easiest boot loader setup (just to get from source to a working boot screen) I have yet encountered in Linux. It appears to be working well, and the default doesn't seem to introduce any major bells and whistles that I can see. The auto-configuration tools are pretty accurate. With two quick commands you can get grub auto-configured for a default Linux setup pretty easily. Obviously we'd want to show how to tweak the configuration manually, but I think, just to get things working for trunk, we could just drop in the commands auto-config and build on that. As an aside, what does everyone think of having grub moved down to chapter 8 just after the installation of the kernel? I kind of like it there. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving to Grub2?
Alexander E. Patrakov wrote:
> 2008/12/4 Jeremy Huntwork <[EMAIL PROTECTED]>:
>> Matthew Burgess wrote:
>>> That said, I've not tried it out myself yet. Maybe in my next build!
>> Testing it out now...
>
> Please take time to create the following setup in a virtual machine:
Sorry, I have too many other things to do. As you say, without LVM2
support in {B,}LFS, it's not really a showstopper. I would appreciate it
if you could report back your findings if you do get around to doing
this for yourself.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Moving to Grub2?
Alexander E. Patrakov wrote: > 2008/12/4 Alexander E. Patrakov <[EMAIL PROTECTED]>: >> OTOH, since (B)LFS doesn't support LVM2 anyway, I don't consider the >> failure of this test a showstopper. > > But the docs are still in too bad shape. E.g., the wiki page > http://grub.enbug.org/CommandList doesn't really document the new > commands, but refers to the documentation of GRUB Legacy even if it > doesn't apply. Texinfo documentation does exist in upstream > repository, but not in the tarball. Even more, the texinfo docs don't > contain the word "lvm", i.e., are incomplete. > > I am afraid that it would be too irresponsible to throw a new > undocumented package upon our readers. There are two alternatives: 1. Provide the option of using grub-legacy for x86 and x86_64 multilib or lilo/bin86 for all architectures (except PowerPC). Include yaboot if we wish to support PowerPC. Pros: We are covered for all tested architectures. Cons: There are options in an otherwise linear book, and it also requires more maintenance and initial setup/writing. 2. Switch solely to lilo and don't bother supporting PowerPC with yaboot. Pros: We are covered for all x86* archs/setups. Book is still linear and there is only one supported bootloader. Cons: lilo is not a popular bootloader, i.e., less user familiarity. Requires very different configuration, must always run lilo when configuration changes. PowerPC arch totally out of the question. Are there any other alternatives? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving to Grub2?
Dennis Clarke wrote: > It worked well enough even if I did have problems with the menu list > initially. I can't recall the last time I have looked at this or given it > any thought. Perhaps I should take a glance there again as I was ( past > tense ) doing some LFS work earlier this year on PowerPC and had > diligently documented each and every build step. Thanks Dennis. I do recall that you were working on this. Any relevant notes you took at the time would be helpful. Thanks, JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving to Grub2?
Alexander E. Patrakov wrote: > 2008/12/4 Alexander E. Patrakov <[EMAIL PROTECTED]>: >> OTOH, since (B)LFS doesn't support LVM2 anyway, I don't consider the >> failure of this test a showstopper. > > But the docs are still in too bad shape. E.g., the wiki page Check this out: http://wiki.debian.org/Grub/Grub2 -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving to Grub2?
Alexander E. Patrakov wrote: > Jeremy Huntwork wrote: >> Check this out: http://wiki.debian.org/Grub/Grub2 > > Yes, they have good manual pages in Debian. Thanks for the link. Let's > hope this documentation will be accepted upstream. > > It is still worth mentioning that Debian uses a SVN snapshot, not a > release, because of various bugs. See (experimental) > http://packages.debian.org/changelogs/pool/main/g/grub2/grub2_1.96+20081201-1/changelog > It doesn't really matter too much, unless we just want to use grub2 because of features or because it supports PowerPC. I was completely wrong: it turns out that you need 32-bit libs to build it. So, it looks like we're back where we started. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
The new build method is in...
...Mostly. With revision 8755, the new build method from DIY is in place with the exception of support for multilib. (More on that in a second.) I tried to make as many textual changes as I could to keep the accuracy of the book on a high level, but I'm sure I missed some things that referenced the old build methods. I would appreciate it if you all could take a second to read through Chapters 4 & 5 particularly to help spot discrepancies. Until the book renders tonight/tomorrow, there is a rendered version here: http://www.linuxfromscratch.org/~jhuntwork/lfs-trunk 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? Another side note, jhalfs can't currently handle the new build method becuase it hard-codes the build user's .bashrc file. A slight tweak in jhalfs to match what is now in Chapter 4 should take care of it. CCing George Boudreau so he can fix it up when he as a second. Thanks! -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future LFS 7.x Plans
Jim Gifford wrote: > It seems now that LFS is ready to go into the world that CLFS has been > in for a while. There seems to be a lot of discussions, that are going > to be a duplication of work, and no one from LFS reaching out to the > CLFS team for input on what issues we have seen and what you will cross. > It was proposed a while back to make CLFS the LFS 7, which got > rejected, but someone else brings it up something similar, now it's a > great idea let's get it done. It was a matter of timing, and I think, the fact that LFS can only take little bits of changes at a time. I think to a lot of people, turning CLFS into LFS 7.0 seemed like a large pill to swallow all at once. (I'm not necessarily voicing my own opinions here, just what I believe is the cause for what happened). Plus, there is a large difference still with CLFS vs LFS. One of your aims is true cross compiling, being able to start from any arch and build for any arch. LFS still is, and from what I can tell, will always be a strictly native build. > If LFS wants to support multiple architectures, I would recommend only > supporting x86, x86_64, and powerpc. The others are just too complicated. You're probably right. In fact, I'm not even certain that PowerPC will officially make it in. > I also hope anything from what people have done towards the LFS's 7.0 > goal, that the appropriate credit is giving. Of course. When I first started looking at adding in 64-bit support to LFS I did look at CLFS and I used some commands and principles, and a patch found there. Here are the initial two commits to the x86_64 branch which started all this: http://wiki.linuxfromscratch.org/lfs/changeset/8229/branches/x86_64/BOOK http://wiki.linuxfromscratch.org/lfs/changeset/8232/branches/x86_64/BOOK Admittedly, I was amiss in not giving credit to CLFS at that point, during those couple of commits. It did not seem like a big deal at the time, since we were sister projects and I had worked on CLFS myself. Shortly after that, Greg Schafer started advising me on the method. Threads to that effect start here: http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059715.html and here: http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059744.html And there are more if you dig around. After Greg started advising me, the build method started changing. On only the third commit to the x86_64 branch, stuff from CLFS started being removed: http://wiki.linuxfromscratch.org/lfs/changeset/8241/branches/x86_64/BOOK Since then, any borrowed ideas have come from DIY and Greg Schafer, which is why, when I merged all these changes into trunk from the jh branch (the successor of the x86_64 branch) I gave him credit and thanks. I have not really looked at CLFS in a long time, but to my knowledge, there isn't anything left in LFS that originated in CLFS. Even so, if you feel it is appropriate, I will gladly drop in a line in the changelog that expressly thanks CLFS for building pure 64-bit and 64-bit multilib first and for initially setting us on the path. -- JH -- 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...
Matthew Burgess wrote: > On Fri, 05 Dec 2008 15:58:24 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > >> Another side note, jhalfs can't currently handle the new build method >> becuase it hard-codes the build user's .bashrc file. A slight tweak in >> jhalfs to match what is now in Chapter 4 should take care of it. CCing >> George Boudreau so he can fix it up when he as a second. > > Arrggghh! I've just kicked a build off with all the new packages in on top > of your build method, before reading this message. I don't suppose you've > got a workaround for this by any chance, have you? You'll have to start the build from the top, but try this patch: http://www.linuxfromscratch.org/~jhuntwork/jhalfs.patch -- JH -- 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...
Matthew Burgess wrote: > Oh, how trivial! Thanks muchly, the build had only gotten part way through > gcc-pass1, so I didn't lose too time thanks to your quick reply! Glad to help. :) Looking forward to seeing how the build goes. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future LFS 7.x Plans
Jim Gifford wrote: > It seems now that LFS is ready to go into the world that CLFS has been > in for a while. There seems to be a lot of discussions, that are going > to be a duplication of work, and no one from LFS reaching out to the > CLFS team for input on what issues we have seen and what you will cross. Thinking on this some, and reading through old posts, I came across this one from Craig Jackson: http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059585.html I think Craig made some valid points which are still valid now, perhaps even more so, given that man-power/activity in LFS and all its related projects is low these days. It's picking up somewhat, but it's still low. From a brief conversation with Joe Ciccone not too long ago, I gather CLFS is in a similar boat. Can we resolve any actual differences between the projects (and individuals making up the projects) and put aside any perceived disputes and work together in a more unified manner again? If so, what are we willing to do to be more unified? What possibilities are there? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future LFS 7.x Plans
Charles wrote: > Hi LFS and CLFS developers, > > As an ardent follower of these projects, I'd be very glad to see the > two projects be one. In my opinion, they are gaining the same result > by different techniques. If DIY is trying some cross compiling and LFS > may go after it, then what's left to the name CLFS? I think it's right > time to reunify the two if LFS is trying cross compiling. Just to be clear, though. LFS is _not_ trying cross compiling. The only thing cross-compiled in LFS's new method is Glibc in the temporary tools section - and even with that, the host and target system must be the same architecture. Even though the second pass of Binutils and GCC will also make use of the cross compiler and linker, they are actually native builds. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future LFS 7.x Plans
Jim Gifford wrote: > Randy McMurchy wrote: >>> >> Too bad that they don't practice what they preach. >> >> > Gee this what your looking for http://cblfs.cross-lfs.org/index.php/License > > I see credit given? You owe an apology. C'mon guys. This is the type of stuff that creates the rifts and gets us nowhere. Can we please put aside the egos and pointing fingers and work together to reach the common goal? -- JH -- 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...
Greg Schafer wrote:
> No. You've also omitted perhaps the most interesting feature of the whole
> thing - the ability to migrate from a 32-bit system to a 64-bit system. As
> it currently stands, you're forcing folks to start from a 64-bit system if
> they want 64-bit. Useless.
Greg, c'mon. You know it's not useless so why must you be so harsh in
your appraisal? You well know the technical benefits the basic method
brings with or without the specific benefit to migrate from 32 to 64.
You've littered this all over our lists for the past month or two,
throwing around such phrases as 'I would not touch the old method with a
10-foot pole'. The basic methodology is there, with the benefits of
being better able to separate from the host.
Anyway, the specific example you cite here of being able to migrate from
a 32-bit system to 64-bit does in fact work perfectly, _if_ you have a
64-bit kernel available. I'm currently building a 64-bit system on the
32-bit LiveCD and it's working fine. :)
OK, OK, I realize the point you are trying to make. In DIY you can take
a 32-bit distro (with a 32-bit kernel) build the 64-bit libs from the
32-bit host and then build a 64-bit kernel and reboot, finishing the
build in 64-bit. You have this before binutils pass2:
[[ $DIY_TARGET == x86_64* && $(uname -m) == i?86 ]] &&
{ echo 'build a 64-bit kernel and reboot into it!'; exit 1; }
This is all excellent, but it is another feature that I would like the
LFS community to discuss before we implement. When we decide what we
want to do wrt to handling the BOOK with optional paths (multilib or no
multilib, require a reboot in the middle of the build...) we can strip
out the stuff that makes it linear right now and give the user more
options at the beginning. We can turn the initial setting of the LFS_TGT
variable into something the user sets manually.
> All this `case $(uname -m) in' stuff you've
> added is bogus.
Knock it off. I don't come to DIY and disparage your work. This is not
'bogus'. It's a valid command that works fine in this initial step where
LFS is still a very linear book.
Did you really expect this to be absolutely perfect on the first import
into LFS? You know how LFS works and that it is a slow-turning ship. I
was actually surprised that there wasn't more fuss concerned with
incorporating your new method. Once I get some more input, we'll start
moving in the other aspects.
> You'll have to rethink how you're going to handle this
> aspect if you want it to work.
Undoubtedly.
> The other thing you've omitted is proper attribution. A simple "Thanks,
> me" is not good enough for something this big. The LFS changelog is not
> perpetual. You of all people should know how much time and effort goes
> into engineering this stuff. Some extra words next to my existing entry on
> the Acknowledgments page will suffice. "... Technical Writer and Architect
> of the Next Generation 64-bit-enabling Build Method" or similar.
Shall I just use the acronym? You'll be the T.W.A.N.G. 64BM. Heh, I
kinda like that. :)
But, yeah, no problem. If you can think of a better term, I'll use that
instead.
While we're agreeable to these sorts of edits, I wonder if you'd be so
kind as to finally remove the disparaging and now inaccurate statements
about LFS from your Reference Build and website?
> It's a good question. It's easy for me in DIY because I actively target
> scripting. Because LFS targets the interactive command line, you'll have
> to be careful not to introduce too much awkwardness. But whatever you do,
> you *must* introduce a 32-bit Glibc in the 64-bit case. I'm even
> considering dropping pure 64-bit in DIY because its usefulness is limited.
Yes, the more I am around pure 64-bit, the more I agree with you. Even
if you hardly use the 32-bit libs at all, just having them there and
available makes the system that much more valuable.
--
JH
--
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...
Greg Schafer wrote: > Jeremy Huntwork wrote: > >> Knock it off. I don't come to DIY and disparage your work. > > Huh? Get over yourself dude. You've *always* taken things so personally. > Grow a thick skin. I'm not personally bothered in the least. > Remember I'm trying to support *you* implementing *my* work. Watch your > tone and focus on the task at hand. Thanks. I do appreciate your support. But for someone who supports my implementation, you so far have had very few positive things to say about it. -- JH -- 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...
Greg Schafer wrote: > the Acknowledgments page will suffice. "... Technical Writer and Architect > of the Next Generation 64-bit-enabling Build Method" or similar. I'll give you a day or so to decide on the exact wording you prefer, or for someone else to offer a suggestion. Then I'll add this in. -- JH -- 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: > Jim Gifford wrote: >> Your violating his license if you don't put it in. Why play these petty >> games, you need to include his license and the terms of his license, >> since you have fully stated that your borrowed from his work. > > Jeremy's request is reasonable, Jim. I don't think there was ever any > thought > of not giving proper attribution to either Greg or CLFS. Jim, you have not yet said how you would like CLFS to be credited. I am still more than willing to put something in, but I would like to hear from you what you feel is fair. Thanks, -- JH -- 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 academia, the accepted method of using other authors' ideas is to just > create > a bibliographic entry. 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. This sounds like a good idea to me. In any case, for now, I'll go ahead and update Greg's entry in the acknowledgments section as he requested. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Toolchain Pass 1 Question (6.4 vs dev)
Reece Dunn wrote: > Is this an intentional change - for example, as a result of the new > build method - or is it an accidental result of the merge of Jeremy's > 64-bit support? That is, does the --target= remove the need for the > CC= override? The use of -B/usr/bin/ in the past was to force the use of the host's linker tools when building the ld-new at the end of Binutils pass1 and GCC pass 1 because of possible incompatibility between the host and the tools being built. (Past examples were when the toolchain in Fedora as a host was too new for the versions LFS was building.) The current development book is quite a bit different than 6.4 and previous released versions and it uses a completely new build method which originated in DIY-Linux. In fact, there are still some things that need to be sorted out and fixed with it. In the new build method, we are essentially cross-compiling the first pass of Binutils (and note, we also don't create an adjusted ld-new there for use later, either) and GCC which means, there's no chance of using the new ld as found in the PATH variable to build GCC pass 1. Hope that helps... -- JH -- 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...
Ryan Oliver wrote:
[snip]
> Just some thoughts
Ryan, thanks for the feedback. I don't have anything specific to say in
connection with any of your points yet (I guess no one else does
either), but I will be looking them over in more detail as I have a free
moment, so I'm bookmarking this thread.
Just wanted to say thanks and it was nice hearing from you again.
While you are 'here' I have another question I want to throw out there
for opinions. If and when LFS also decides to allow multilib on x86_64
(which, more and more I'm thinking it is only the 'Right Thing' to do if
supporting 64-bit - specifically just enough to add 32-libs and the
ability for gcc to compile 32-bit binaries if necessary), I'm currently
leaning towards going a different direction than Greg has done in DIY.
Specifically, DIY currently has 64-bit libs in /lib64 and /usr/lib64 and
32-bit libs in /lib, /usr/lib. I'm guessing that this is because this is
the logic the toolchain uses by default for search paths and requires
less configuration of the toolchain.
However, such a situation requires _more_ configuration when building
packages, especially those that install libraries. This is because GCC
will build 64-bit binaries and libraries by default, but the configure
system for most packages will install by default into /lib, /usr/lib.
There is of course the --libdir option for many packages, but this
doesn't hold true for all. Some (like OpenSSL) will still hard-code lib
into the build system.
What I would like to see (which agrees with what the FHS seems to
suggest, or at least lists as a possible scenario) is this:
/lib64
/lib32
/lib -> lib64
/usr/lib64
/usr/lib32
/usr/lib -> lib64
This way, both libraries are clearly identified and the default location
of lib agrees with the default architecture gcc will build for. If
people don't like the symlink, we can always remove {/usr,}/lib64 and
just use {/usr,}/lib for 64-bit.
The only thing is that (from what I can see) this will require
configuring GCC to search in lib32 for 32 bit libs, which it doesn't do
by default.
Thoughts?
--
JH
--
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...
Bryan Kadzban wrote: > ABI issues. Or at least, last time I remember seeing this idea on some > list or other (perhaps it was CLFS? perhaps DIY? can't remember for > sure), this was the reason for keeping /lib64 and /lib. > > The dynamic linker *must* be /lib64/ld-linux-x86-64.so.2 for a 64-bit > executable, and *must* be /lib/ld-linux.so.2 for a 32-bit executable. > Otherwise binaries that weren't built on the system won't run. Symlinks > might let you work around this, but ... eeewww. Just set --libdir for > autoconf, or LIBDIR for other Makefiles. Well, that's a pretty good reason. I should have known that there would be one. But, Argh!, it just seems such a backwards way to (unofficially?) standardize. It feels that, logically, /lib should house the _default_ libraries. > (I have a fairly large collection of build64 scripts that hold what I've > done for various packages to get their libs into the right directory. > This is for LFS, chunks of BLFS, and several beyond-BLFS packages. The > *vast* majority needed nothing more than --libdir. If/when multilib > starts being worked on, I'd have no problem going through those and > seeing what packages in LFS needed what arguments. In fact, I might do > this anyway; now I'm curious...) Yeah, I've been starting to build a multilib system based on current LFS dev and these are just the sorts of issues that are cropping up. I'd be interested in seeing your results. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: CLFS antics
Rob Thornton wrote: > I look forward to seeing the community unite and make itself stronger! > xLFS has been an excellent source for me and anything that makes it > stronger makes life better for my next build! Hi Rob, I would love to see what you and Robert C. have suggested happen. Especially because of lack of resources these days, I think it could be very useful to integrate the projects, or, at least, merge them somewhat more. The issues you'll face trying to make this happen however, are social issues, and not technical ones. Unfortunately, there are (apparently) deep rifts. There exists suspicion and distrust, hurt feelings, bruised and bloated egos and it has been historically very hard for some of us to put these aside. If the ones that are currently taking the lead (or perhaps it is better phrased: 'in positions of responsibility') can't individually change their perspective and come to an agreement that allows them to define and work on common goals, nothing will ever change for the better. My love for LFS has motivated me (despite my frustration at times with the poor leadership) to jump in and help keep the ball rolling where I can. Unfortunately, many times, my efforts have been perceived by some as being either a play for more power or personal glory or something of the kind. I find myself at the center of a conflict that I really want nothing to do with. I also realize that this rift is bigger than just me. For example, Greg and Ryan need to work out their differences - and that rift goes back years. I know Greg was asked to leave LFS a long time ago, before my time, even, but I would be happy to see him back working more directly with LFS - if only he cultivated a little more tact and respect for others involved in the project. Anyway, as far as I am concerned, I would be glad to give up any commit privileges I have in the projects and work only from the sidelines if it would help remove the rift and get people working together. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: CLFS discussion
Bruce Dubbs wrote: > Tushar Teredesai wrote: > >> I still don't get it. Does the current LFS leadership get to decide >> what every project that ever "forked" from LFS can and cannot do? > > No, and I don't think it's even being tried. There are some expressions of > regret that there are personality conflicts and a wish by some, including me, > to > get together, but I don't see anyone trying to direct anything. Well, it's going to take a firm resolve and direction by those taking the lead in the projects. You would have to have some sort of discussion to attempt to bring efforts together. Here's a quick list to try: Gerard (if someone can wake him up...) Matthew Burgess and Bruce Dubbs (representing LFS) Randy McMurchy and DJ Lucas (representing BLFS) Robert Connolly (representing HLFS) George Boudreau (representing ALFS) Jim Gifford, Ryan Oliver and Joe Ciccone (if CLFS is interested, which I think is the hope) And a somewhat 'neutral' party. I would suggest either Ken Moffat or Dan Nicholson, or perhaps both. These two have always (in my opinion) kept to a very balanced view of things. If you want the LiveCD project involved, I would suggest Alexander as a representative. Also, I think the invitation for any initiative should be extended to Greg Schafer representing DIY, if he is interested. I think, if anything is going to happen, this is the crew that's going to have to get together and agree. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: CLFS discussion
Ken Moffat wrote: > I'm flattered, but disconcerted - aren't all editors supposed to > take a balanced view ? Yes, they are. And I think for the most part they have. What I really meant was, from my perspective, you seem to have managed to keep yourself separate from the social issues, which is a good thing. > In the interests of "full disclosure" (one > of my buzzwords because I don't think "our" (LFS, BLFS, clfs) > security is "up to scratch" I need to disclose that I perhaps still > bear you (JH) a tiny amount of scepticism - you pulled me in to this, > for which I'm grateful, but then you put ppc64 into clfs, only to > lose your access to the hardware - making that work on the desktop > has taken far more time (basically, a huge chunk each time gcc had a > version upgrade) than I ever wished to use, and then there was the > teaser of the jh LFS book - yes, it worked, but it withered on the > vine. So, I recognize your past contributions, and your good intent, > but I'm not yet convinced that this will be a productive use of my > time. You have hit on what is perhaps my single biggest shortcoming in connection with LFS: I leave things unfinished. It's bad because it ends up affecting others, and I'm very sorry for that. I guess I put ppc64 out of my mind after I lost the hardware, Ken, and I'm sorry that it affected you in that way. I almost wish then, that it had been removed from the book after that point. (As an aside, what the jh branch was is now in trunk, with the added support of methods from DIY. PowerPC should actually work in LFS, although I have not tested it recently, with the exception of a boot loader. I know it was slow, but the work there did actually make it back to trunk.) In any case, you'll notice that I did not include myself in the list of proposed names. To what extent it is true, I do not know for sure, but I feel somewhat responsible for the fragmentation of LFS. I would like to help fix it somehow, but I get a feeling that one of the best ways I can help is to step back and let others step in. I'm not proposing to leave entirely, because I don't want to continue in the trend of irresponsibility, and to whatever extent I am still needed or wanted, I am glad to help out. But I think this discussion needs to happen, and it would probably be better off without me. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Quantum HTTP processes using 100% CPU?
Randy McMurchy wrote: > Hi all, > > If anyone with privileges to Quantum could look in and see why the > Quantum server is so bogged down, I sure would appreciate it. It seems > as though it has been really, really sluggish the last few days. > > Top shows that HTTP processes have the CPU running at 100%. Perhaps if > the Apache server was restarted, things might be better. The Apache > server has been running since June. > Seems to be ok, now. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adapting LFS SVN for multilib
Nathan Coulson wrote: > I have been using a modified LFS (built for 32/64bit at the same time) > and it worked well until the latest changes were introduced to trunk > (that use the -B flag). Specifically GCC pass2 does not find crt0.o > 32bit (just see's the 64bit). I was curious if this is what the > buildsystem that 7.0 is going to be using, or if it is still a work in > progress. > > I was a bit lost with the latest change, as to why it does not use > /tools/lib or /tools/lib64 without -B as that would allow me to use my > old work without deviating too far from LFS. I meant to have a message posted here before now, but things have been busy. I have been adapting Ryan's methods to LFS because I think that there are certain improvements over what is currently in trunk. Specifically: * No need for ever specifying '-B/tools/lib' * No more need to do a 'post install' adjustment of the toolchain in chapter 5 * No need to patch gcc in pass 2 to revert to previous functionality. The gcc devs have said that the sysroot methodology is the 'correct path forward' for cross compiling. Although the build as a whole is a native build, it relies on cross-compilation early in the game, so making use of the sysroot functionality leaves us where we want to be, now and going forward, I feel. I have not used all of Ryan's configure switches and patches, because I have not seen a need for some things on i686, PowerPC or x86_64 multilib. Adding in the bare necessities illustrates the core changes needed to get this working. I also have only added in what is necessary in chapter 5 up to and including gcc pass 2. If you're doing multilib you'll notice that there is not yet a 32-bit Glibc in chapter 6 added and there are no --libdir=/usr/$LIBDIR switches either. Also, there is some explanatory text missing. But, to give you an idea, here's what I have so far: http://www.linuxfromscratch.org/~jhuntwork/lfs-multilib/ To me, this is the way forward for 7.0. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adapting LFS SVN for multilib
Greg Schafer wrote: > By installing stuff into different prefixes, you are forced to butcher the > GCC source to coax it into searching the right places. Why? Because many > of the toolchain search paths are keyed off of $prefix. There is much less > hackery involved if you install into a single prefix ie: /tools. It really makes no difference whatsoever to me if the cross-binutils and cross-gcc are installed in /cross-tools or /tools. For my testing purposes and while I was running several builds, I chose to follow Ryan's example with the prefixes, mostly for the reason he mentioned, that it makes it easy to start again (when you know that the instructions for the first two packages are correct). I can totally appreciate that (perhaps for the sake of simplicity) some may want to just have it all dropped into /tools, and if so, I'd be happy to stick to that. As far as 'butchering the source' goes, there's nothing done in the first pass of GCC to the source that isn't done in pass 2. Essentially it's the same sort of stuff we've _always_ done in pass 2 to ensure that the compiler uses only the libs and headers in /tools. In fact, it's less, because we don't have to mess with a specs setting. I think the rest speaks for itself. The build produces good results and there's less massaging that needs to be done post install to get gcc and /tools/lib to play together. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adapting LFS SVN for multilib
Greg Schafer wrote: > Sorry, you're wrong and clearly not getting it. Meanwhile, it's apparent > you've turned into a Ryan nut hugger, just like the rest of the CLFS > crowd. God help LFS! > > I honestly don't care anymore. LFS is a project without direction, without > leadership and apparently has lost sight of what made it popular back in > the day. Good luck fellas! If you had some solid technical proof (think demonstrable example) to show why this method is not a correct approach, instead of just "your're wrong", or spouting insults, your feedback would be worth much more. As it is, this just sounds like a personal attack because I'm not using your method and/or because I'm using work from your 'nemesis'. I have had good success with this build, and although I have not yet verified itwith any sort of comparison analysis (part of the reason why I hadn't committed anywhere) it will be done before it goes into the book. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adapting LFS SVN for multilib
Randy McMurchy wrote: > Ryan Oliver wrote: > There is technical information being passed. Simply look > at what is being said, and don't worry how it is being > said. Let's say that you decided to eat at my restaurant. You sit down and order some food. After some time, I return and slam down onto your table a full plate of food such that when it hits your table, hot juice/sauce flies up and stings you in the face and all over your good clothes. Technically, you got your food. You got what you ordered. Does the same principle apply? It doesn't matter how it is presented, just that the food is there? I highly doubt that you would happily ignore the fact that I ruined your clothes (and your food) and just sit quietly and eat the remains. One's personal image/ego isn't the point here. It's a matter of respect for the project and those contributing. The point is that these sorts of personal comments/insults/attacks/whatever makes the project look bad to those looking on, is totally unnecessary, actually degrades the image of the one doing the insulting and detracts from the technical issues because you have to weed through the social aspects to find them. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Toolchain
Gerard Beekmans wrote: > Can somebody do me a favour and give me both a high overview and a > detailed technical nitty-gritty overview of those three (are there > more?) methods - how they compare to each other. You've summarized it pretty well. What is currently in trunk is based on current DIY, however, there are a few aspects that are not finished and it needs some attention, whatever is decided about actual direction. It is a new approach compared to earlier versions of LFS in that the the first pass of binutils and gcc we are creating cross compilers and the chapter 5 glibc is cross compiled. It is a native build from that point forward. Some weeks ago, Ryan proposed a somewhat alternative method that does not require any adjustment of the toolchain in chapter 5 and does not depend on using -B/tools/lib/, by the cross compiler in order to get it to find the new startfiles. There is also a patch that DIY and current trunk uses for GCC pass 2 which reverts GCC to old functionality so that it will use prefix to find the startfiles. Ryan's approach also does not require the use of this patch. After Ryan proposed his method, CLFS incorporated it into a native build approach and I also started looking at taking the core concepts directly from Ryan's email and adapting to LFS for testing purposes. This is what is currently found at: http://www.linuxfromscratch.org/~jhuntwork/lfs-multilib/ This method uses sysroot functionality in GCC and Binutils to help 'mask' off the host system further. IIUC, Greg's objection is that this is abusing what sysroot was intended for, Ryan's stance is that the intention of sysroot was more generic. I like this method for the fact that gcc is configured right away to point at /tools and there's no post-install configuration/modification of GCC in order to get it to find its startfiles and headers in /tools. Greg says we're 'hacking the source' in the first pass of GCC, but if you actually look at the changes being done, it's the same modification of config/linux.h that the specs patch has always done in pass 2 to get gcc to use /tools. Hope this helps. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Toolchain
Greg Schafer wrote: > Jeremy Huntwork wrote: >> This method uses sysroot functionality in GCC and Binutils to help >> 'mask' off the host system further. > > Huh? No! It's quite the opposite! This clearly demonstrates you don't > understand the sysroot feature at all. I'm surprised that I have to > explain this to you in detail, but I will anyway. 'mask' was the wrong word to use here. I am aware that the toolchain will use the full host path to /tools i.e., '/mnt/lfs/tools' (and so, --with-local-prefix=/tools also becomes important). All I really meant is that the system is configured such that it is expecting your logical system root to be equal to '$LFS' or '/mnt/lfs' and so will be explicitly searching there for the rest of the toolchain components. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Toolchain
Greg Schafer wrote: > You're making the changes in *both* passes. Unnecessary hackery and you > know it. Stop blurring the truth. I fail to see how I could blur the truth about something that is publicly available for all to read. Of course the changes are there in both passes, I never said otherwise. As far as it being unnecessary hackery is another matter. I certainly prefer editing macros in headers over reverting gcc to code that the devs explicitly removed. It's notable that when you continued to explain to them your build method/procedure the response was invariably 'use sysroot'. I suppose you'll next say that the devs didn't understand your intention or method even though you thoroughly explained yourself and they even took the trouble to walk through your ref build. For those unfamiliar see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 For those not interested in reading the entire bug history, the last comment by a dev was: "Using the sysroot flags is the solution for Greg's scenario. In fact I would say it makes his job easier." -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Toolchain
Greg Schafer wrote: > Umm, that bug report is about Pass 2. Your using the sysroot feature in > Pass 1. See a problem? No, sorry, I don't. In the comments of that bug report the dev suggests using sysroot for pass 1 of gcc. Also, haven't you noticed that making use of sysroot in pass one eliminates the scenario that is causing you trouble in pass 2, thereby removing the need for the patch? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Toolchain
Greg Schafer wrote: >> Also, haven't you noticed that making use of sysroot in pass one >> eliminates the scenario that is causing you trouble in pass 2, thereby >> removing the need for the patch? > > Huh? Not at all. Please, JH, explain how this is so. I'm not a gcc internals expert, so I'm not going to try to begin to explain all the intricacies on my own. I readily admit that - and I am learning a lot as I work through this. What I have published in my home directory is not a line for line copy of Ryan's proposed method. I did aim to learn the principles of what he was achieving and apply it to current trunk in an unobtrusive manner. What I do know is that the combination of sysroot and macro edits leaves us with a compiler in pass1 that is set to link against libc in /tools/lib and requires no adjustment or command line modifications to do so. Removing the sysroot bits leaves us still dependent on -B and a toolchain adjustment. This first build of gcc is able to build the second pass without requiring the startfiles patch. In order to explain why this is so, I admit, I would have to dig deeper. > And like I said earlier, the patch is already gone in my dev build - no > sysroot in sight. I wasn't aware that you removed it. I'll be taking a look... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Some detail needs to be added
On Nov 28, 2009, at 1:25 PM, Ken Moffat wrote: > other packages - and you really could use another system > on which to do those downloads because LFS itself doesn't > include even a console browser or wget or an ftp client > (that's what BLFS is for. Actually, LFS does include a basic ftp client via inetutils. I used to use that to grab wget from ftp.gnu.org as one of my first post-LFS packages when I built by hand. But still, point well-made. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Splash Screen
On Dec 3, 2009, at 2:43 AM, TheOldFellow wrote: > The instructions really should be in BLFS. That way peeps can roll > their own. This isn't IMO LFS material. > "peeps", eh? Someone hijacked TheOldFellow's keyboard, methinks. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: T_CFLAGS on x86_64 (gcc in 5.10 and 6.15
On Dec 4, 2009, at 7:17 PM, Ken Moffat wrote:
> I still haven't built a recent LFS system, but I'm about to
> restart (x86_64), and I'm checking my scripts match the
> current development book, and working out what the
> presence of the {,/usr}/lib64 symlinks from 6.5 will do to my
> BLFS scripts (for the moment, I'm not sure if I like these
> symlinks but they certainly save patching gcc for pure64
> (spent some time yesterday trying to bootstrap 4.4.x on a
> clfs host before I eventually twigged what was wrong).
>
Patching how? I'm sure I'm out of the loop a little bit, but the last I checked
this wasn't necessary. In any case, for my own scripts I decided a while ago
the best way was to always build a multilib system. It gives complete
flexibility, works with what the toolchain (generally speaking) expects what
you will do and for the most part requires little else for system libraries
other than configuring them with a --libdir= param.
--
JH
http://www.lightcubesolutions.com
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
FYI: Multilib broken
Greetings Everyone,
I know LFS to date hasn't really expressed much interest in adding in support
for multilib builds, but I figured I'd send out the FYI for anyone out there
who has been experimenting or would like to do so in the future. (The very
minor changes LFS needs in order to build multilib are listed at the end).
The latest toolchain packages (the ones LFS is currently using, gcc-4.4.3,
binutils-2.20, glibc-2.11.1) along with the general build methodology appears
to break for multilib. Following the latest DIY reference build but with these
package versions yields the same results. In GCC pass 2, after gcc successfully
builds libgcc and the new compiler, the build fails at libgomp with the
following error:
configure: error: unsupported system, cannot find sizeof (omp_lock_t)
Digging into the config log, the particular conftest that is failing actually
builds successfully, but attempting to run the newly built binary produces:
./conftest: error while loading shared libraries: libgcc_s.so.1: cannot open
shared object file: No such file or directory
build:~/gcc-build/x86_64-unknown-linux-gnu/32/libgomp$ ldd conftest
linux-gate.so.1 => (0xf7745000)
librt.so.1 => /temptools/lib/librt.so.1 (0xf772f000)
libgcc_s.so.1 => not found
libpthread.so.0 => /temptools/lib/libpthread.so.0 (0xf7716000)
libc.so.6 => /temptools/lib/libc.so.6 (0xf75cb000)
/temptools/lib/ld-linux.so.2 (0xf7746000)
Compiling the binary with -v -Wl,--verbose shows it linking against libgcc_s.so
in the gcc-build dir:
attempt to open /home/build/gcc-build/./gcc/32/libgcc.so failed
attempt to open /home/build/gcc-build/./gcc/32/libgcc.a succeeded
attempt to open /home/build/gcc-build/./gcc/32/libgcc_s.so succeeded
-lgcc_s (/home/build/gcc-build/./gcc/32/libgcc_s.so)
But it's obviously not looking there when trying to run the binary, which is
where the conftest is failing. In fact, the config.log shows:
configure:19341: ./conftest
./conftest: error while loading shared libraries: libgcc_s.so.1: wrong ELF
class: ELFCLASS64
I intend to keep working my way through this problem slowly, but I wanted to
put it out there in case anyone else had any ideas as to what's going on.
--
JH
-- Changes for LFS --
1. Binutils Pass 1: remove the /{,usr}/lib -> /{,usr}/lib64 links
2. Kill the --disable-multilib switches on all Gcc builds
3. Add a 32-bit Glibc for both chapters with essentially the following
configure command (the one for chapter 6 would of course use the different
prefix and no need to use the $LFS_TGT tools):
echo "CFLAGS += -march=i486 -mtune=native" > configparms
CC="$LFS_TGT-gcc -m32" AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib \
../glibc-2.11.1/configure --prefix=/tools \
--host=i686-pc-linux-gnu --build=$(../glibc-2.11.1/scripts/config.guess) \
--disable-profile --enable-add-ons \
--enable-kernel=2.6.18 --with-headers=/tools/include \
libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes
4. For the 64-bit Glibc builds, add this before the configure line:
echo "slibdir=/tools/lib64" > configparms
echo "libdir=/tools/lib64" >> configparms
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: FYI: Multilib broken
On Feb 22, 2010, at 5:44 PM, Bruce Dubbs wrote: > Jeremy Huntwork wrote: >> Greetings Everyone, >> >> I know LFS to date hasn't really expressed much interest in adding in >> support for multilib builds, but I figured I'd send out the FYI for >> anyone out there who has been experimenting or would like to do so in >> the future. (The very minor changes LFS needs in order to build >> multilib are listed at the end). > > http://wiki.linuxfromscratch.org/lfs/ticket/2491#comment:6 I am aware of your stance on multilib, Bruce. Due to LFS's limited active developers, I agree, adding in multilib right now for LFS wouldn't be very beneficial. Which is why I never suggested that you do that. :) The post was meant as an FYI for anyone currently experimenting on that front and a request for any feedback from those who have or are interested in finding an answer. The 'Changes for LFS' section on the bottom was intended as a hint for anyone willing to experiment using LFS dev as a base. If that makes this post off-topic for this list, then my apologies, but the last I knew, since lfs-hackers was killed, this was also the list intended for experimental discussion. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: FYI: Multilib broken
On Feb 22, 2010, at 6:42 PM, Bruce Dubbs wrote: > No problem. I think the idea of a hint is appropriate, but we haven't > heard from you for a long time. I didn't know if you were up to speed on > the decision we made. Yeah, thanks. I needed a serious break. It was good that I did, too. I have been able to get a lot of my priorities arranged correctly and things are generally doing well. Off and on I've been doing some work on a personal project: essentially a distro based loosely on LFS/DIY/CLFS using rpm as a package manager (although, there's been nothing distributed yet). I say loosely because it's really just the initial build environment that is bootstrapped, and my scripts for doing that don't quite match any of the above. The focus is to provide a solid, minimal system for use as an application server. There's no deadlines with it, so I take my time. I was surprised at how useful rpm actually is at solidifying the final build, and at forcing you to think about where all the files are going. Anyway, that's how I came across this particular issue. > I did read 'Changes for LFS' as a suggestion to > change the book. You probably didn't intend that. Yeah, sorry. Intended only as a reference for what was needed to reproduce the error. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Website
Hi Everyone, Last summer I worked on a mockup for a new LFS site design. I showed it to Gerard and he liked it, and helped with suggestions to tweak it to a point he was generally happy with. Shortly thereafter, Gerard 'disappeared', and I haven't heard anything more from him. I'm curious what the community as a whole thinks of it and if there is any interest in updating the LFS website, or if I should just archive the demo site. (That also brings up a few questions about the status of certain projects, but that's another issue, I guess.) Here's the site: http://dev.lightcube.us/~jhuntwork/LightCube/LFS-NG/ None of the links do anything, since it's just a mockup. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Mar 17, 2010, at 5:34 PM, Matthew Burgess wrote: > Welcome back...again :-) Thanks. I'm not sure how 'back' I am, but I'm still interested in what goes on in LFS-land. > It looks better than the current site, certainly. > > I think I'd prefer to see the green menu bar & blue menu bar swapped > around. To me, the top-level menu should be at the top, and the > 'sub-menu' should be underneath. Yeah, that's a good point. I'm sure something could be worked out there. I think my fear for putting the site items up above was that it would appear top-heavy (since they were larger). Although I'm sure it could be adjusted. > The bottom paragraph overflows the right-hand 'margin' (underneath the > google ads), which looks a little odd when compared to the paragraphs > above it. Yeah, that's somewhat intentional. Maybe this isn't an issue for LFS, but I personally dislike sites that have a sidebar on pages with lots of text and when you scroll down the page you end up with a big empty column where the sidebar is but has no content. > Aside from those minor nits, it looks nice! > > Now, if we (err, you! :)) could 'theme' wiki.linuxfromscratch.org > similarly, I'd prefer to have all of www.linuxfromscratch.org under the > trac system, if that's possible? Yeah, I could definitely do that. I spent some time not long ago theming Trac for a personal project. I can get tricky, but it's definitely do-able. As another possibility (which I won't push, because I really don't care :-) ), I switched to Redmine for myself just a bit ago (http://www.redmine.org/) and its feature set is really impressive. Plus it's ridiculously easy to migrate to from Trac. Lastly, you can set up Apache SVN access to authenticate through Redmine which means, if you ever decide to give someone commit access, you can do so through the Redmine system and don't have to give them another account in the system. One last thing to think about: the current site could just be 'themed' with the new layout/appearance, or you could take the opportunity to do two other things: 1. Assess the status of 'dead' projects and determine how to handle them 2. Use a PHP-driven website for advanced features on the site. Just thoughts. Like I said, I don't really have a personal preference for any of the above wrt LFS, but will certainly help with anything you all decide. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Mar 17, 2010, at 5:34 PM, Matthew Burgess wrote: > Now, if we (err, you! :)) could 'theme' wiki.linuxfromscratch.org > similarly, I'd prefer to have all of www.linuxfromscratch.org under the > trac system, if that's possible? Apologies, I actually missed that you said you prefer to have the entire site under trac, and I think some of my answer reflected that. Still, yes, it's definitely possible. For those that have said they like the site so far: thank you. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Mar 19, 2010, at 9:22 AM, James Robertson wrote: > I really like the new design, but agree with Steve here. And I agree with both of you. :) Some type of CMS really makes things much easier. Of course, you want one that is easily theme-able. Most are these days... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Mar 19, 2010, at 10:11 AM, Matthew Burgess wrote: > I'm not sure that the LFS website has enough content or rate-of-change of > content that a > full blown CMS is required. I could be wrong of course :-) Well, in this context, Trac is (nearly) a CMS. In any case, it allows you to edit content from the front-end and manage who has access to do so. So in one sense, you're still in agreement with us. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Mar 19, 2010, at 11:49 AM, Matthew Burgess wrote: > Yeah, I guess I didn't really make my point clear. What I was trying to say > was that I'm > not sure the overhead of having both trac and plone is worth it for our > relatively small > site. If trac is 'good enough' for our needs, then let's just use that. As I've said, whatever you decide, it's really up to you guys. If you all like the design (so far it seems pretty positive), I'd be happy to help you implement whatever you want to do. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Bzip2 version mismatch
Hi All, I don't know if anyone ever noticed this, but the library version installed with bzip2-1.0.5 is still 1.0.4. Also, the man pages still say 1.0.4. Seems like the maintainer just forgot to update the Makefile and man sections. Since everything still works as it should, I suppose this is really just a minor issue. But if you feel like changing it, I created a patch which changes the necessary sections (although the pdf and ps files still probably contain the reference to 1.0.4): http://dev.lightcube.us/~jhuntwork/sources/bzip2/bzip2-1.0.5-version_fixes-1.patch -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bzip2 version mismatch
On Apr 1, 2010, at 5:39 PM, Bruce Dubbs wrote: > > Will you please create a ticket. Sure. > Have you reported this upstream? Nope, not yet. Although I saw that the issue was reported to Debian's Bug Tracking site in December. They don't appear to have touched it yet though. (Unless I'm missing something, their site is confusing to navigate, I find.) I suppose I should go look to see if the maintainer is aware of it... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
iproute2 text nitpick
Just a small nitpick. The Iproute2 page says: "The arpd binary included in this package is dependent..." That sounds like there is actually a compiled binary shipped in the package. Might be better worded as something like: "The arpd binary produced through this package..." -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LightCube OS
Hello All, I refrained from mentioning this here for some time, but I figured that with our move to Redmine from Trac and with all of its collaborative tools, now might be a good time to mention this (sorry for the slight OT content). My company has been hosting work for a distro based loosely on LFS. Its main goal is to provide a very simple, very lightweight web application server. Our main reason for doing this work has been to package up the builds that we have already been using on a few of our production servers. In the near future, there will be more systems we will be deploying with custom web applications, and a known environment tweaked just to our needs will be very useful. A real short list of its main goals / features: * A web application server (typical usage would be Apache, PHP, and probably MongoDB) * Support for optional lighttpd, MySQL, PostgresSQL, Python, Ruby, etc. * Use vanilla configuration everywhere possible - no obscuring of default configuration files in preference of custom configuration systems * Uses RPM for package management * Possibly auto-building a custom VM image for use as a web appliance To build the RPMS, first a build environment based mostly on LFS is created (minus some packages needed for booting and plus RPM and its dependencies). Once that's ready, chroot into that environment and the building of the core system spec files can begin using rpmbuild. Most of the core system is done. The two biggest tasks remaining are to build non-LFS packages (create their spec files) and to create some sort of proper install system. I don't intend to flood this mailing list with any further plugs for this distro, but I just wanted to make a one time announcement about the work happening on it. If anyone is interested in the concept, the project site is here: http://dev.lightcube.us/projects/lightcubeos and anyone is welcome to help out. Feel free to register there and poke around, ask questions, offer suggestions, whatever. :-) Thanks, Jeremy Huntwork LightCube Solutions http://www.lightcubesolutions.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4.5.0 - Pass 2
On Apr 15, 2010, at 4:44 PM, Bruce Dubbs wrote: > checking whether the target supports .symver directive... yes > configure: versioning on shared library symbols is gnu > checking whether the target supports __sync_*_compare_and_swap... yes > configure: updating cache ./config.cache > configure: error: unsupported system, cannot find sizeof (omp_lock_t) > make[1]: *** [configure-target-libgomp] Error 1 > make[1]: Leaving directory `/mnt/lfs/sources/gcc-build' > Heh, that's kind of funny. That's the same error I was getting when attempting to do multilib with the current toolchain version and posted about here: http://www.linuxfromscratch.org/pipermail/lfs-dev/2010-February/063582.html -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Prototyping new packages
On Apr 16, 2010, at 2:03 AM, Bruce Dubbs wrote: > I can't recommend the 2.6.33 series for the kernel until this gets > straightened out. OTOH, this may be a gcc-4.5.0 issue. I can try > building 2.6.30.2 or 2.6.32.8 with gcc-4.5.0 and see if that is any > better. If those segfault, it's the compiler. If I find out anything, > I'll post the results. FWIW, I've been using 2.6.33.2 with the current toolchain and everything works well. I even have the system packaged up enough that you could test it with your hardware, if you want :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Mar 19, 2010, at 3:52 PM, Jeremy Huntwork wrote: > On Mar 19, 2010, at 11:49 AM, Matthew Burgess wrote: >> Yeah, I guess I didn't really make my point clear. What I was trying to say >> was that I'm >> not sure the overhead of having both trac and plone is worth it for our >> relatively small >> site. If trac is 'good enough' for our needs, then let's just use that. > > As I've said, whatever you decide, it's really up to you guys. If you all > like the design > (so far it seems pretty positive), I'd be happy to help you implement > whatever you > want to do. So... where does this stand? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Apr 16, 2010, at 5:44 PM, Ken Moffat wrote: > I didn't comment earlier, but I find the blue and green backgrounds too dark > (at the bottom - the top is ok), which surprisingly makes them slightly hard > to > read on my LCD. The blue and green backgrounds on the bottom? Do you mean the link colors? Not sure I understand... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Apr 16, 2010, at 6:19 PM, Bruce Dubbs wrote: > I have to say that I agree. In my mind, the current site is quite > adequate. I'm not going to be 'for' or 'against' a change, but I don't > see the value in changing. > > Ken, us old guys need to stick together. :) Well, it certainly "does the job". But it looks dated, and overly simplistic. Not that you need anything extravagant, the site should definitely be simple, but it could also stand to be more attractive. The way I see it, changing the look of the site every once in a while helps keep things fresh, and it affects they way newcomers think of the site. I would hope that you guys aren't wearing the same clothes you did in the 80s, even if they didn't wear out by now. :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Apr 16, 2010, at 6:46 PM, Ken Moffat wrote: > Sorry, it was obvious to me when I wrote it. The green backgrounds > are graduated from top to bottom of each box. On a quick glance I > thought the blue ones were too, but now I'm less sure about the main > batch (BLFS ... Patches) - those are ok, it's just the main 'LFS' and > the little 'Search' boxes that I find hard to read. It's also > possible that it looks different on my other main desktop, certainly I > have to set the brightness slightly differently for the differnet > video card (same monitor). Ah, OK, thanks for the clarification, this helps. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Get Counted
On May 3, 2010, at 7:18 PM, Andrew Benton wrote: > Hello, > Does the Get Counted page work? I came across this thread on Linux Questions > http://www.linuxquestions.org/questions/linux-from-scratch-13/6-6-went-smoothly-one-minor-thing-805362/ > Where people seem to be having a problem entering 6.6 for the LFS version. That whole page needs to be re-designed - the counter itself could use some major improvement. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Get Counted
On May 3, 2010, at 9:28 PM, Bruce Dubbs wrote: > I have never liked cgi. I'd much rather see a php version. It looks > like one was started a few years ago, but never finished. > > Volunteers? Well, since no one else volunteered, I'll see if I can fit this in. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: kernel and gcc-4.5
On May 14, 2010, at 12:06 AM, Bryan Kadzban wrote: > Ken Moffat wrote: >> Related question, although maybe it belongs on support - how do you >> get grub2 (1.97, if it matters) to boot in single mode? I need to >> fsck my /home partition manually (fsck'd after nn boots, came up with >> errors), and it's shared between all the systems on that box. >> >> init=/bin/bash works, but (of course) no disk devices. > > Run the bootscripts manually, up until checkfs? Dunno, but that's what > I tend to do when (say) even single-user is running scripts that break > something (like, oh, udev for instance). :-) > > Or follow Bruce's advice. Also, if you've followed the book's instructions precisely (i.e., you've named your kernel vmlinux-...) when you run grub-mkconfig, a config file will be generated with two options based on that kernel, one being single user mode. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Just for fun
On May 15, 2010, at 1:55 AM, Bruce Dubbs wrote: > I added a new image to the lfs home page. > > http://www.linuxfromscratch.org/ It's a fun picture, and I'm all for a little fun in the site. I don't think it belongs on the home page, though. I really mean no personal offense, but I don't know how to say this without being blunt: The way the site currently looks (especially now with the picture and the prominent Google ads), it really looks like LFS is run by amateurs. At least, the site lacks the professional look that speaks to the quality of the work done here. The front page is the first thing that new people see and it really should speak to the fact that the editors/devs/community of LFS really care about producing a quality book. I know that this may come across as harsh, and I am sorry for that. But having spent a number of years working in and around the graphic design industry, and working in the web application development sphere - I cannot stress enough how important it is to have a site (or at least home page) that shows you care about quality/details. If the general consensus is in disagreement with me, and we're just going to leave the site like this (actually, with or without the picture), that's fine. In that case, I would just prefer that my name came out of the footer. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
How to prevent community
Hey Guys, Someone just forwarded this link to me. The presentation is a little silly, but there's a lot of good points he makes: http://video.linuxfoundation.org/video/1715 I think LFS could take a few pointers from this. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Consider adding in Cloog-PPL and PPL
Hi All, As you probably know by now, recent gcc's make use of PPL (Parma Polyhedra Library) and Cloog-PPL (A branch of the Code Generator in the Polyhedral Model making use of PPL for polyhedral functions). If I gather correctly, LFS has up to now avoided including this in favor of sticking closely to traditional build methods and wanting to keep LFS trim and build times shorter. However, despite the extra build times and MBs of added space, I feel these are inclusions worthy of consideration given that their intent is to provide GCC with a methodology to further 'optimizations over a wide variety of processors'. I think the readers are missing out on a good deal of performance/functionality for GCC without these packages. I'm still reading up on all that's involved with using the 'graphite loop optimizations' as the GCC prereqs refer to them (http://gcc.gnu.org/install/prerequisites.html), so I'm no expert as to all that's involved. I do think LFS should at least look into it. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
gmp gotcha
Hey, Not sure if anybody else ran into this, but just something to look out for with gmp: My machine is an Intel Core 2 Duo processor, however I was running a Virtual Machine and building an LFS-type build using a 32-bit kernel, so my architecture was i686. When I went to build gmp, it detected that the processor was actually a core 2 duo and so selected optimizations for that arch, which then promptly failed to build because the rest of the system was built for i686. I could see this possibly affecting some LFS users who are using 64-bit capable hardware, but running a 32-bit kernel. A note that adding '--build=i686-pc-linux-gnu' to the configure line in such a case might be useful. Or if not, at least it's documented here. :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gmp gotcha
On Jul 18, 2010, at 6:32 AM, Andrew Benton wrote: > The note on the GMP page > http://www.linuxfromscratch.org/lfs/view/development/chapter06/gmp.html > says that this problem only occurs if you have set CFLAGS. Did you set > CFLAGS? Aha, thanks for spotting that. I don't recall setting CFLAGS anywhere, but I'll have to dig further now to see if it is somewhere, somehow. -- JH -- 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 Jul 18, 2010, at 7:04 AM, Andrew Benton wrote > I've just tried compiling ppl-0.10.2. configure fails because it relies > on an obsolete function that has been removed from gmp-5.0.1: > ... > checking how to link with libgmpxx... -lgmpxx -lgmp > checking for the GMP library version 4.1.3 or above... no > configure: error: Cannot find GMP version 4.1.3 or higher. > GMP is the GNU Multi-Precision library: > see http://www.swox.com/gmp/ for more information. 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. -- JH -- 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 Jul 18, 2010, at 1:31 PM, William Immendorf wrote: > Oh, and some more stuff is needed before PPL/ClooG goes into LFS: > > * G++ needs to be made a host system requirement, due to the fact > that PPL requires a working C++ compiler. > * GMP needs to be moved out of the GCC build (I don't think MPFR and > MPC need to be moved out) during the temporary toolchain phrase. Also, > GMP needs to have --enable-cxx added to it's configure. > * As for PPL, use --enable-interfaces="c,cxx" to prevent PPL from > building the Java interface (there is no Java compiler in the chroot > enviorment, by the way) in the temp toolchain phrase. > * CLoog-PPL needs --with-bits=gmp in the temp toolchain phrase too. These are all unnecessary because we don't need to build ppl and cloog-ppl for the temporary toolchain. They're throw-away toolchains, their sole purpose is to get us to chapter 6, so there's no need to build in optimization libraries for chapter 5. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysvinit --> Upstart?
On Jul 6, 2010, at 6:06 PM, Stuart Stegall wrote: > I would suggest reading something like: > http://0pointer.de/blog/projects/systemd.html I just spent the last hour reading through this, many thanks for the link :) I'm definitely impressed by the functionality systemd is looking to provide. I'll be experimenting with it in LightCube OS... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Mar 17, 2010, at 5:34 PM, Matthew Burgess wrote: > Now, if we (err, you! :)) could 'theme' wiki.linuxfromscratch.org > similarly, I'd prefer to have all of www.linuxfromscratch.org under the > trac system, if that's possible? So this comment inspired me to try to work up a usable all-in-one solution. Trac isn't bad for that but it's starting to show its age, IMO, and it's especially painful when you have essentially one organization but with multiple projects. Trac makes you handle everything separately in each project. What would be nice is to have one system, but with multiple sub-projects where permissions, settings and so on can be fine-tuned per project. Here's where Redmine comes in. To me, Redmine is everything Trac is, but better. Besides providing one-stop management for several projects, it also has some nice additional features. For example, users created on redmine can be eventually given commit privileges to a repository without requiring creation of a Unix system account. There are also some nice action keywords you can use in commit logs: 'Did some stuff. Fixes #5677' Will mark ticket 5677 as resolved (or whatever status you configure it to). 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. 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. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Jul 25, 2010, at 12:53 AM, Bruce Dubbs wrote: > If we were setting up a new project, I might want to use Redmine, but we > manage LFS using Subversion, Mailman, and Trac and have been using those > tools for about 6 years. The main web pages are standard xhtml. I'm > reluctant to replace one of the main management tools. I'd say that's a fair sentiment. We like what we like, and we like what we're used to. Personally, I was using Trac for everything (several other side projects) up to a few months ago. Before that, a few friends of mine were pushing and pushing to get me to try Redmine, and I was stubborn about it, mostly because it uses Ruby on Rails. But when I finally did try it, I really liked it. There's a number of things that just work smoother than Trac. All I can say is, at least poke around in it - give it a fair test-spin before you let yourself become firmly set against it just because it's a change. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Jul 25, 2010, at 2:06 AM, Robert Xu wrote: > Just a curious thought - what theme did you use? I modified the classic theme to use a similar style to the one I demoed earlier. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Jul 25, 2010, at 2:13 AM, DJ Lucas wrote: Whoa! That's a lot of questions... :) I'll try to answer them when I get back home, but until then I've made you an administrator so you can see all that's there (in the front-end, anyway). > 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. Thanks. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
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. > 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. > 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. > 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. These sorts of things would be available to administrator - did you get to play with it after I made you one? > 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. Most of these thing would be covered either by plugins or custom code. It's all ruby on rails so it's not that difficult to adjust if you really want to hack some new features in. Hope some of these answers helped... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Jul 26, 2010, at 1:57 AM, DJ Lucas wrote: > 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 wonder if we're talking at cross points here. Someone who is a regular contributor and has an account in Redmine *can* be given commit privileges through the Redmine system. The only caveats here are: 1. They must use the http(s) svn scheme when they checkout and commit code, e.g., svn co https://linuxfromscratch.org/svn/lfs/trunk/BOOK lfs-trunk. 2. They wouldn't receive a system account meaning that (with our current setup) they would not receive a @linuxfromscratch.org email address. Of course for some people this isn't a big deal since they're already using a certain mail address for LFS communication (and perhaps elsewhere on the web). This is achieved by adding proper restrictions to various svn commands in Apache's virtual host definitions, and by having Apache run a perl script to find Redmine users/passwords. See this article: http://www.redmine.org/wiki/redmine/repositories_access_control_with_apache_mod_dav_svn_and_mod_perl > 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? Ah, I see what you're saying. Yes I believe Resolution was brought in from Trac, it's listed under 'Custom Fields' in the main Administration section. Besides the custom fields, all the rest of the workflow can be modified in the main Administration section via 'Roles and permissions', 'Trackers', 'Issue statuses', 'Workflow' & 'Enumerations'. > 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. Sure, all those could be added. > My Ruby is about as fluent as my Cantonese (ie: not). Probably about > time to learn anyway. But feature requests are simply to streamline > administration (which I don't believe is that difficult anyway). The > lack of public key auth pretty much limits the use of virtual users I > think. I mean, it might be able to be hacked in, but that would > probably be a bit much to ask for so little gain. The method that is > used now works and is fairly easy to do. At any rate, the line of > questions related to the virtual users are no lesser than our current > Track setup, so we have some options gained, but certainly nothing lost. Yep, I agree. > Overall, it really doesn't look like much needs changed from the default > settings. So now that my nitpicks are done, the resulting todo list > (per my own opinions) is pretty short. The default assignees must be > set per tracker types and per sub-project, add the custom status types > added, remove the display of the resolution field, edit "Developer" > permissions and possibly even "Reporter" permissions, and acquire a cert > for https (maybe don't listen on http). The SCM browser to do an anon > checkout and create a tarball would still be nice so that users who want > to contribute patches don't have to install the SCM client. Pretty > common feature on Trac, so I'd bet that there is probably already a > plugin for that. Great, you planning on helping test this thoroughly then? Would you be able to help get HTTPS working successfully? Thanks, JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On Jul 24, 2010, at 11:23 PM, Jeremy Huntwork wrote: > Here's where Redmine comes in. To me, Redmine is everything Trac is, but > better. Besides providing one-stop management for several projects, it also > has some nice additional features. For example, users created on redmine can > be eventually given commit privileges to a repository without requiring > creation of a Unix system account. There are also some nice action keywords > you can use in commit logs: 'Did some stuff. Fixes #5677' Will mark ticket > 5677 as resolved (or whatever status you configure it to). This is illustrated by the fact that the related Issues in Redmine were automatically closed after Matt's commits today: http://community.linuxfromscratch.org/issues/2718 http://community.linuxfromscratch.org/issues/2717 http://community.linuxfromscratch.org/issues/2711 http://community.linuxfromscratch.org/issues/2709 http://community.linuxfromscratch.org/issues/2705 The times showing for when they were closed are incorrect because I didn't have the appropriate settings in place when he made the commit earlier. But I added them in and browsed to the repository which triggers Redmine's reloading of repository info. It found the key words 'fixes' and closed out the appropriate tickets. This has been added in as a post-commit hook so this would be fully automated going forward. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
It's interesting what logs will show. For instance, the access logs for community.linuxfromscratch.org show 117 unique IP addresses viewing the site yesterday, and 76 unique IPs today. Combine the two lists and there are a total of 167 unique IPs. Even taking into account robots and individuals viewing the site from multiple locations, that's still a lot of readers who were curious enough about it to go have a look. And yet, we have very few people writing in to express their opinion. So it appears that either they don't really care, or they're holding back from speaking their mind because of some expectation of what will happen when they do. I find that very interesting. And very unfortunate. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
Yaacov,
Thanks for this, this is exactly the sort of discussion I was after...
On Jul 27, 2010, at 6:06 AM, Yaacov-Yoseph Weiss wrote:
> Just wondering, how many people are signed up to this email list? This
> might give a
> better indication of how interested the (potential) community is.
It's over 500 distinct email addresses.
> I'm risking insulting people, but it seems to me that the alfs, clfs,
> hlfs, and livecd
> projects are basically dead.
Indeed. And an email I sent last night to the livecd list with the intent of
measuring interest of resurrection met with a rather interesting reply that I
still have to respond to.
> Most of the changes discussed are in administration and development, which
> really don't concern most users, for reasons I'll discuss below.
Fair enough.
> 1. There is no way to get back to the home page
> ('http://community.linuxfromscratch.org/')
> from any of the other pages.
>
> 2. There is no way to move from project to project. (Well, actually
> there is through
> the tiny link to 'http://community.linuxfromscratch.org/projects'
> which I just noticed,
> which is next to a tiny link for #1 above.
So you think these should be more prominent?
> 3. The home page ('http://community.linuxfromscratch.org/') should
> have a list of
> projects. It should be possible to reach
> 'http://community.linuxfromscratch.org/projects/lfs'
> directly without it happening to be in the news or a latest project
> (which it isn't).
Yes, that certainly could be done, and I definitely could see the value of that.
> 4. The "main" page should include the content of
> 'http://community.linuxfromscratch.org/projects/lfs/wiki/WikiStart'.
> If that makes the page to lfs-centric against blfs, put it at least
> in 'http://community.linuxfromscratch.org/projects/lfs'. Try guessing
> how to read the book when at
> 'http://community.linuxfromscratch.org/projects/lfs'.
Indeed. I was in fact looking to make the WikiStart page the main start page
for each project. Doing so would require a code edit (or plugin perhaps) to
replace the Overview page with the wiki page, or at least swap them.
> 5. I don't like the design of the main page of LFS holding news
> instead of content. The
> content of LFS is generally stable. It isn't a news site which needs
> to point people
> to the latest content. Even if yes, updates of several times a year
> will not bring
> people. First time visitors need the main content, and returning users
> usually need
> links to several of reading the book, downloading it, and editing
> (developing) it. The
> current page does not supply that. News might deserve a small box on the side
> of
> the page, not most of the center of the page.
Heh, it's interesting that you should say that. That was, IIRC, one of the
things that was disliked about the old purple-y website. I think this is a
valid point, and if we get the above two things sorted, this should also sort
itself out.
> That is definitely an issue, though I think this isn't really the best
> example,
> since trac/redmine really makes no difference to me, and I'm sure to almost
> all of the readers, except for the few actual developers.
Except that the point was, if you recall, to see whether this would make a good
replacement for the main site.
> 3. Building a second time, possibly with personal "touches". I suspect
> most people stop
> here because there is no convenient way to automate the process. Doing
> it by hand
> quickly becomes boring, alfs - when it works - doesn't make it easy to
> personalize
> the result, or to read the book again while installing the packages.
> The user usually
> isn't involved enough yet to work on writing scripts for this. Perhaps
> some package
> management system can be used (or designed) for this. I suspect most LFS users
> install LFS once for the experience, and then forget about it due to this.
I find this an interesting thought. Any further thoughts along this line as to
what would 'engage' readers more?
> When people reply to the mailing list digests and edit the subject, the reply
> is not threaded with the original mail in the archive. I noticed that,
> and suggested
> how it could be fixed, knowing perfectly well that the maintainers do not mind
> fiddling with system code (as this thread proves). The reply I got was
> basically
> that I can subscribe non-digest. (which happens to not help for past
> messages.)
> Even some discussion why I was wrong and it was not an issue or more
> difficult than I thought would have been welcome.
Yes, you've hit what I think amounts to an attitude problem in LFS. Sometimes
it's very heavy. 'This is how we do it, because this is how we've always done
it. I see no reason to consider another solution because this doesn't affect
me, and I can't be bothered to work on fixing this issue for someone else. Why
don't you do things the way I like to do it?'
Granted, you can't cater to everyone's preferences, and it's all the m
