Re: jh-branch
Greg Schafer wrote: I plan to start on x86_64 some time next week. Hopefully the problem is reproducible on non-Debian setups. Confirmed. I've just reproduced it here. I'll send a note upstream and try to get an explanation as to why it affects only x86_64. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: jh-branch
Greg Schafer wrote: Confirmed. I've just reproduced it here. I'll send a note upstream and try to get an explanation as to why it affects only x86_64. Many thanks. Could you please keep lfs-dev informed about your further communication with upstream? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS 6.3-rc2
Bruce Dubbs wrote: I would really not want anyone except editors to update the web site. Its really pretty easy. svn checkout ... (once); edit html; svn commit -m '...' and its done. I think you misunderstood my intention. I wasn't talking about implementing a full wiki, or replacing the current website. What I wanted to do was *add* some sort of framework or form, or something that will allow *editors* to quickly and easily add news items. The news items would then be dropped onto the current pages, much like the svn logs are done already. This is something that was requested long ago, but we never got around to finishing it. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LiveCD ISO
I'm curious, what's the difference between the LiveCD ISO images that are ~200M and the ones that are ~500M? E.G. lfslivecd-x86-6.3-r1952.iso - 607M lfslivecd-x86-6.3-r2014.iso - 243M Mike -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
[EMAIL PROTECTED] wrote: lfslivecd-x86-6.3-r2014.iso - 243M This file is just incomplete, where did you get it? Please download from http://ums.usu.ru/~patrakov/test/ -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
From the Corvallis, OR, USA HTTP mirror link on the LiveCD download page of the LFS website. http://www.linuxfromscratch.org/livecd/download.html There are several ISO images there that are significantly smaller than 500M -- Original message -- From: Alexander E. Patrakov [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: lfslivecd-x86-6.3-r2014.iso - 243M This file is just incomplete, where did you get it? Please download from http://ums.usu.ru/~patrakov/test/ -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 64 bit processors
Dan Nicholson wrote: There's probably a better way, but grab x86info, build, run as root. http://www.codemonkey.org.uk/projects/x86info/ Thanks Dan. I got: Found 2 CPUs -- CPU #1 /dev/cpu/0/cpuid: No such device or address Family: 15 Model: 4 Stepping: 1 Type: 0 Brand: 0 CPU Model: Pentium 4 (Prescott) [E0] Original OEM Processor name string: Intel(R) Pentium(R) 4 CPU 3.20GHz Feature flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflsh ds acpi mmx fxsr sse sse2 ss ht tm pbe sse3 monitor ds-cpl cntx-id cx16 xTPR Extended feature flags: em64t Cache info Instruction trace cache: 12K uOps, 8-way associative. L1 Data cache: 16KB, sectored, 8-way associative. 64 byte line size. L2 unified cache: 1MB, sectored, 8-way associative. 64 byte line size. TLB info Instruction TLB: 4K, 2MB or 4MB pages, fully associative, 64 entries. Data TLB: 4KB or 4MB pages, fully associative, 64 entries. The physical package supports 2 logical processors - So I am em64t capable. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
[EMAIL PROTECTED] wrote: From the Corvallis, OR, USA HTTP mirror link on the LiveCD download page of the LFS website. http://www.linuxfromscratch.org/livecd/download.html There are several ISO images there that are significantly smaller than 500M On anduin there are lfslivecd-x86-6.3-minimal-pre1.iso 209386 KB 07/17/0718:33:00 lfslivecd-x86-6.3-pre1.iso 525272 KB 12/18/0600:00:00 lfslivecd-x86-6.3-r1952-nosrc.iso 418660 KB 07/12/0717:06:00 lfslivecd-x86-6.3-r1952.iso 621374 KB 07/12/0716:46:00 lfslivecd-x86-6.3-r2014.iso 248349 KB 08/07/0714:01:00 lfslivecd-x86_64-6.3-min-pre1.iso 207106 KB 07/26/0701:48:00 Alex, are these correct? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
Bruce Dubbs wrote: On anduin there are lfslivecd-x86-6.3-minimal-pre1.iso 209386 KB 07/17/0718:33:00 lfslivecd-x86-6.3-pre1.iso 525272 KB 12/18/0600:00:00 lfslivecd-x86-6.3-r1952-nosrc.iso 418660 KB 07/12/0717:06:00 lfslivecd-x86-6.3-r1952.iso 621374 KB 07/12/0716:46:00 lfslivecd-x86-6.3-r2014.iso 248349 KB 08/07/0714:01:00 lfslivecd-x86_64-6.3-min-pre1.iso 207106 KB 07/26/0701:48:00 Alex, are these correct? Only lfslivecd-x86-6.3-r2014.iso looks wrong. BTW, old r snapshots and 6.3-pre1 (non-minimal) should be probably deleted. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
lfslivecd-x86-6.3-r2014.iso is definitely wrong. I'm downloading it directly from Alex's site as we speak and on his site it is ~643M. Is it possible that mirrors, etc. are getting updated while the sources (file) are being updated at their respective home sites? I dunno how all of that works, but short of an aborted transfer, I can't imagine how there'd be such a difference in the file sizes. -- Original message -- From: Alexander E. Patrakov [EMAIL PROTECTED] Bruce Dubbs wrote: On anduin there are lfslivecd-x86-6.3-minimal-pre1.iso 209386 KB 07/17/0718:33:00 lfslivecd-x86-6.3-pre1.iso 525272 KB 12/18/0600:00:00 lfslivecd-x86-6.3-r1952-nosrc.iso 418660 KB 07/12/0717:06:00 lfslivecd-x86-6.3-r1952.iso 621374 KB 07/12/0716:46:00 lfslivecd-x86-6.3-r2014.iso 248349 KB 08/07/0714:01:00 lfslivecd-x86_64-6.3-min-pre1.iso 207106 KB 07/26/0701:48:00 Alex, are these correct? Only lfslivecd-x86-6.3-r2014.iso looks wrong. BTW, old r snapshots and 6.3-pre1 (non-minimal) should be probably deleted. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
[EMAIL PROTECTED] wrote: lfslivecd-x86-6.3-r2014.iso is definitely wrong. I'm downloading it directly from Alex's site as we speak and on his site it is ~643M. Is it possible that mirrors, etc. are getting updated while the sources (file) are being updated at their respective home sites? I dunno how all of that works, but short of an aborted transfer, I can't imagine how there'd be such a difference in the file sizes. Perhaps you can publish a .info file with each iso that has md5sum, file size, brief info, etc. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
Alexander E. Patrakov wrote: Only lfslivecd-x86-6.3-r2014.iso looks wrong. BTW, old r snapshots and 6.3-pre1 (non-minimal) should be probably deleted Whoops, it wasn't my intention for those to go live yet. osuosl.org must have changed their system, before nothing went live until a prog was called, now it goes live immediately! I've fixed up the r2014 and removed the old rxxx and 6.3-pre1 full. Justin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
Sorry guys, I didn't intend to create a fire drill. -- Original message -- From: Justin Robert Knierim [EMAIL PROTECTED] Alexander E. Patrakov wrote: Only lfslivecd-x86-6.3-r2014.iso looks wrong. BTW, old r snapshots and 6.3-pre1 (non-minimal) should be probably deleted Whoops, it wasn't my intention for those to go live yet. osuosl.org must have changed their system, before nothing went live until a prog was called, now it goes live immediately! I've fixed up the r2014 and removed the old rxxx and 6.3-pre1 full. Justin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
[EMAIL PROTECTED] wrote: Sorry guys, I didn't intend to create a fire drill. No prob, good to get it fixed up and prevent someone else from wasting their time with an incomplete iso! :) Justin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
On Tue, Aug 14, 2007 at 11:41:54AM -0500, Bruce Dubbs wrote: Perhaps you can publish a .info file with each iso that has md5sum, file size, brief info, etc. We're working on a getting a master server in place for mirroring the ISOs. We hope to have that up by the end of the week. That should help, but yes, I'm inclined to agree with your idea, Bruce. Something like that for each released CD could be very useful. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
Jeremy Huntwork wrote: We're working on a getting a master server in place for mirroring the ISOs. We hope to have that up by the end of the week. That should help, but yes, I'm inclined to agree with your idea, Bruce. Something like that for each released CD could be very useful. FYI, The current livecd master repo already has md5sums and sha1sums: ftp://ftp.lfs-matrix.net/pub/lfs-livecd/MD5SUMS ftp://ftp.lfs-matrix.net/pub/lfs-livecd/SHA1SUMS If you wish to setup a different server for master, if it helps here is my script for generating md5sums/sha1sums, a .timestamp with last update and a directory listing. These are done on all other repos (lfs, clfs, blfs, hlfs) so might want to keep the same functionality. Also don't forget to email all livecd mirrors about the change. Justin [EMAIL PROTECTED] ~ $ cat ~/bin/livecdpackage #!/bin/bash DATDIR=/data/ftp/.1/lfs-livecd LISTING=.listing.bz2 cd $DATDIR rm -f MD5SUMS SHA1SUMS for ISO in *.iso ; do echo $ISO md5sum $ISO MD5SUMS sha1sum $ISO SHA1SUMS done date +%Y%m%d%H%M .timestamp find . -type f -name *.iso | bzip2 $LISTING -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: jh-branch
On 8/14/07, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Greg Schafer wrote: Confirmed. I've just reproduced it here. I'll send a note upstream and try to get an explanation as to why it affects only x86_64. Many thanks. Could you please keep lfs-dev informed about your further communication with upstream? Out of curiosity, could you see what happens using FSF binutils-2.17 + the branch_update patch that Robert had been updating? http://www.linuxfromscratch.org/patches/downloads/binutils/binutils-2.17-branch_update-2.patch -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD ISO
Justin Robert Knierim wrote: FYI, The current livecd master repo already has md5sums and sha1sums: I see that now on anduin too. I missed it. I still feel a short file with the same base name for each iso would be useful. For example: lfslivecd-x86-6.2-4.iso lfslivecd-x86-6.2-4.iso.txt -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
A call for help
Hello Everyone: The LFS LiveCD project is currently attempting to produce four CDs. A minimalistic CD and a full Xorg+XFCE CD each for both x86 and x86_64. There are two of us working on this project officially. It becomes quite a bit of work to try to keep up with the development of LFS and continue to produce CDs that are both stable and usable on a wide range of CDs. We need help from experienced LFSers. Even help from those not as experienced would be greatly appreciated in the form of testers and reporters. We could use: * Developers to experiment with and present new concepts for the CDs * Maintainers to help build the CDs, correct flaws in the build scripts, update (and test) existing software included on the CDs * Testers to download the isos, run as much of the software on as wide a range of machines as they can, and report. Yes, please report both successes and failures * Editors to help write and maintain documentation for various aspects of the CDs If you could help with any of those aspects, we'd love to hear from you on the livecd mailing list. If you're not currently a developer on any of the xLFS projects, we'd like to encourage you to submit reports, patches, and text for a bit on the list. After some time and we see that you're serious and very helpful we'll give you an account. Thanks in advance. Note that I intend to put a more public-type version of this on the LiveCD section of the site. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
An idea for a new development model
Hello,
As I've been giving some thought to what might make the LiveCD project
more manageable, more open to community development and better all
around, it occurred to me that our build method could be adjusted. Right
now the build is automated by a long series of Makefiles that was, in
some respects, the inspiration for jhalfs. You set some variables, run
make, wait 6 hours or so, and voila! (hopefully) a LiveCD. It gets very
difficult (or, at least, annoying) to develop because of the long times
involved in building the entire thing.
So an idea is brewing...
Essentially, the LiveCD is a distribution. But it is a distribution
without something that nearly all others have: package management. Up to
now, there hasn't really been a need. But, if the CD incorporated PM at
its very heart, developers could focus more on tightening individual
components instead of always building the entire CD in one shot.
For example, let's say a flaw was found in one of the pieces of software
included on the CD. With the PM incorporated into the build, all we
would need to do is grab the latest packages, run a small script to
install them into a working directory with the proper configuration,
update the build commands for the package in question, rebuild it,
re-package it, and re-release an ISO. Working in this method should
shorten build times, help solidify the build, and open up a host of
other possibilities.
If you like the sound of this new approach, please share your thoughts
on what might help make it work. Details need to be discussed, such as
the exact development model, package management tools, updated
development scripts, tracking dependencies and standards for
development. I'll wait until there is some discussion before I speak any
further on some of the details that are already forming in my head.
Lastly, I'm posting this to {,b}lfs-dev because I'd like to make sure
those current groups of readers have the opportunity to comment. If
possible, though, please send discussion to the livecd list.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: jh-branch
Dan Nicholson wrote: Out of curiosity, could you see what happens using FSF binutils-2.17 + the branch_update patch that Robert had been updating? http://www.linuxfromscratch.org/patches/downloads/binutils/binutils-2.17-branch_update-2.patch Same as without the patch. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Resolution (was Re: jh-branch)
Alexander E. Patrakov wrote: Greg Schafer wrote: Confirmed. I've just reproduced it here. I'll send a note upstream and try to get an explanation as to why it affects only x86_64. Many thanks. Could you please keep lfs-dev informed about your further communication with upstream? Sure. The thread starts here and is quite interesting and features input from the usual toolchain gurus: http://sourceware.org/ml/binutils/2007-08/msg00198.html In summary, it basically confirms everything we already knew and also what I've been saying all along here on lfs-dev. ie: - it's an x86_64 binutils-2.17 bug - binutils devs are reluctant to fix bugs in old releases - hash-style is supposed to be back-compatible - a 2 line patch works around the problem The facts are, our current native build method relies on the ability to link against the host libc with the target ld. There is nothing inherently wrong with this approach because it should always work in typical LFS build scenarios (barring bugs of course). Yes, it would probably be better if we could avoid it somehow, but the build method would need to change radically in order to achieve this - cross compilation, gross hacks, whatever. If someone can come up with something sane (and tasteful!) that works, great, let's look at it. But I'm not holding my breath.. At the risk of dredging up old flamewars, I'd be very reluctant myself to involve cross compilation in a mainstream build method. It's all been said before, but I'll repeat just this point - IMHO cross compilation is a specialty niche area that is not at all well suited to the relatively simple task of building a new Linux system for Joe Sixpack (typical LFS audience). It *is* complicated and relatively few folks understand it. And finally, Alex, you should be more careful with what you write. Making wild and flagrant comments doesn't help anyone. You already have a reputation for jumping to (sometimes wrong) conclusions so please just put a little more thought into your postings. BTW, Alex, I would like to see from you a clear set of guidelines listing all the possible bugs and problems in the LFS LiveCD, even the ones you haven't discovered yet (just joking! :-) See? Hopefully now you'll realise how ridiculous one of your postings in this thread was. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Resolution (was Re: jh-branch)
Greg Schafer wrote: The thread starts here and is quite interesting and features input from the usual toolchain gurus: http://sourceware.org/ml/binutils/2007-08/msg00198.html Indeed. However, as you point out, it is not explained why the problem is specific to x86_64 (and a proposed two-line patch changes architecture-independent code). So I am afraid that a bug still exists somewhere and will manifest itself again (and again, only on x86_64) when someone adds a new DT_* dynamic section tag that is supposed to be backwards compatible. If you agree with this opinion, I think it would be a good idea express it upstream in that thread. In summary, it basically confirms everything we already knew and also what I've been saying all along here on lfs-dev. ie: - it's an x86_64 binutils-2.17 bug - binutils devs are reluctant to fix bugs in old releases - hash-style is supposed to be back-compatible - a 2 line patch works around the problem Yes, I think this is good enough for now for the DIY reference build, if it is clearly stated that the patch is a workaround. Not sure about LFS - the x86 build is not affected, the x86_64 branch apparently (Jeremy: am I right?) should not be used (because it is merged into jh), and the jh branch solved the problem by upgrading binutils. The facts are, our current native build method relies on the ability to link against the host libc with the target ld. There is nothing inherently wrong with this approach because it should always work in typical LFS build scenarios (barring bugs of course). Yes, it would probably be better if we could avoid it somehow, but the build method would need to change radically in order to achieve this - cross compilation, gross hacks, whatever. If someone can come up with something sane (and tasteful!) that works, great, let's look at it. But I'm not holding my breath.. I will try to cross-compile the least possible set of packages on x86 and x86_64, just to see where one can stop the gross hacks. At the risk of dredging up old flamewars, I'd be very reluctant myself to involve cross compilation in a mainstream build method. It's all been said before, but I'll repeat just this point - IMHO cross compilation is a specialty niche area that is not at all well suited to the relatively simple task of building a new Linux system for Joe Sixpack (typical LFS audience). It *is* complicated and relatively few folks understand it. All facts are above and in the binutils thread, so IMHO there is nothing to flame about. And finally, Alex, you should be more careful with what you write. Making wild and flagrant comments doesn't help anyone. You already have a reputation for jumping to (sometimes wrong) conclusions so please just put a little more thought into your postings. BTW, Alex, I would like to see from you a clear set of guidelines listing all the possible bugs and problems in the LFS LiveCD, even the ones you haven't discovered yet (just joking! :-) An attempt (also to be taken as a joke) will be posted separately, because it is off-topic for this thread. There are indeed some unreported bugs, such as ddccontrol does not support Intel 965G onboard graphics chipsets (patch available). See? Hopefully now you'll realise how ridiculous one of your postings in this thread was. Sorry. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
