Re: Proposing a new LFS release
Bruce Dubbs wrote: Thanks to Matt's hard work, it looks like the -dev version of the book now has over half the packages updated from the current stable release. There only a couple of minor tickets outstanding. We are at Linux-2.6.32 which has been designated for long term support. I've now closed off all of the remaining tickets for the 6.6 release. Bruce, do you want the honour of closing #2491, officially marking LFS as bug-free? :-) I am proposing that we make a -rc1 release next weekend with a target 6.6 stable release around the 1st of March. I was a bit busy this weekend. I'll push RC1 out tomorrow evening, if things don't conspire against me. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposing a new LFS release
Matthew Burgess wrote: Bruce Dubbs wrote: Thanks to Matt's hard work, it looks like the -dev version of the book now has over half the packages updated from the current stable release. There only a couple of minor tickets outstanding. We are at Linux-2.6.32 which has been designated for long term support. I've now closed off all of the remaining tickets for the 6.6 release. Bruce, do you want the honour of closing #2491, officially marking LFS as bug-free? :-) Done. I am proposing that we make a -rc1 release next weekend with a target 6.6 stable release around the 1st of March. I was a bit busy this weekend. I'll push RC1 out tomorrow evening, if things don't conspire against me. Sounds good. Is there anything you want me to do? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposing a new LFS release
On Sun, 24 Jan 2010 19:42:58 -0600 Bruce Dubbs bruce.du...@gmail.com wrote: Jean-Philippe MENGUAL wrote: ok thanks for this answer. I'll remember that 32-32 64-64, it will be easier for me to solve some problems. For multilib, I understand it'll be never done lfs. ok. I'm pleased with knowing precisely this. It will help me to see my translation strategy among complex lfs world :) Never say never. It's my opinion that multilib, in general, is not needed for LFS. Others may (probably do) disagree. Last question (still short): do you think it's useful (and will be done) to build lfs from 32 to 64bits? Personally, no, I don't think it's useful in general. It is useful in specialized applications like building for an embedded device that doesn't have a compiler and other build support. However, I think that is beyond the scope of LFS. -- Bruce Actually, there is one problem with a pure-64 bit system, as far as FOSS is conserned: GNU Emacs has not been ported to it (yet). Emacs can be built using a multilib, and works like a dream when it is. -AKuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposing a new LFS release
2010/1/25 Bruce Dubbs bruce.du...@gmail.com: Thanks to Matt's hard work, it looks like the -dev version of the book now has over half the packages updated from the current stable release. There only a couple of minor tickets outstanding. We are at Linux-2.6.32 which has been designated for long term support. I am proposing that we make a -rc1 release next weekend with a target 6.6 stable release around the 1st of March. Comments? -- Bruce -- I've got one issue on 64-bit - I eventually build gnumeric. That pulls in perl's dynaloader (seems to be for embedding perl). Gnumeric fails to build on x86_64 unless I pass --without-perl because of relocation errors from libperl while trying to link perl_loader.so. On i?86 it's ok to mix static and shared objects in a shared lib, on x86_64 they don't link. The simplest fix is to configure perl with -Duseshrplib=Y. That certainly builds on i?86, but it looks as if it passes -fPIC all over the place. I haven't compared the sizes of the installed perl files on i686, so I don't know if that would be a benign change. I also haven't identified what changes in gnumeric - all the functionality I rely on seems to be there, it's just a pain having to tweak the configure. Presumably, anything else that embeds perl might have a similar problem (but, the only obvious candidate was apache, which seemed not to care). If there was a way of easily adding the extra configure switch to x86_64 only, that would be good, but my ideas so far have been ugly. Measuring this is on my ToDo list, but for the moment I don't have time. ĸen -- After tragedy, and farce, OMG poneys! -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposing a new LFS release
On Mon, 25 Jan 2010 01:39:13 +0100, Jean-Philippe MENGUAL wrote: what kind of buildings can do a user exactly with this stable (6.6)? From 64 to 64 bits? From 32 to 32? Or 32 to 64? Actually, the underlying build method supports all combinations: 32-32 64-64 32-64 64-32[*] (* the last one really surprised me as I never designed the method for this. It just requires some judicious use of `setarch') And it even works on hybrid hosts ie: those running a 64-bit kernel with a 32-bit userland. However, as currently implemented by LFS, the full capabilities of the build method are not being exploited. But that's OK, because the LFS target audience probably doesn't need all the possibilities. 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
Proposing a new LFS release
Thanks to Matt's hard work, it looks like the -dev version of the book now has over half the packages updated from the current stable release. There only a couple of minor tickets outstanding. We are at Linux-2.6.32 which has been designated for long term support. I am proposing that we make a -rc1 release next weekend with a target 6.6 stable release around the 1st of March. Comments? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposing a new LFS release
Hi, Just a precision because, beyond translating, I manage a French help network too. Can you tell me, and I think it could be precised in the book or on the website, what kind of buildings can do a user exactly with this stable (6.6)? From 64 to 64 bits? From 32 to 32? Or 32 to 64? If I read architecture.xml, I see that, originally we build a 32 bits, but a 64 is possible. Only a 64bits host is required for that? If yes, can we do a 32bits with a 64bits host? To finish, I guess no multilib is still supported. Thanks for these precisions which will help me if this book becomes stable. Regards, - Jean-Philippe MENGUAL Vice-Président de l'association traduc.org Coordinateur du projet Linux From Scratch Le dimanche 24 janvier 2010 à 18:22 -0600, Bruce Dubbs a écrit : Thanks to Matt's hard work, it looks like the -dev version of the book now has over half the packages updated from the current stable release. There only a couple of minor tickets outstanding. We are at Linux-2.6.32 which has been designated for long term support. I am proposing that we make a -rc1 release next weekend with a target 6.6 stable release around the 1st of March. Comments? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposing a new LFS release
ok thanks for this answer. I'll remember that 32-32 64-64, it will be easier for me to solve some problems. For multilib, I understand it'll be never done lfs. ok. I'm pleased with knowing precisely this. It will help me to see my translation strategy among complex lfs world :) Last question (still short): do you think it's useful (and will be done) to build lfs from 32 to 64bits? Regards, - Jean-Philippe MENGUAL Vice-Président de l'association traduc.org Coordinateur du projet Linux From Scratch Le dimanche 24 janvier 2010 à 18:59 -0600, Bruce Dubbs a écrit : Jean-Philippe MENGUAL wrote: Just a precision because, beyond translating, I manage a French help network too. Can you tell me, and I think it could be precised in the book or on the website, what kind of buildings can do a user exactly with this stable (6.6)? From 64 to 64 bits? From 32 to 32? Or 32 to 64? If I read architecture.xml, I see that, originally we build a 32 bits, but a 64 is possible. Only a 64bits host is required for that? If yes, can we do a 32bits with a 64bits host? I don't see a need to change what we do now: 32-32 and 64-64. It's really the same way we did it when transitioning from Linux 2.4 to Linux-2.6 where we required somebody else's Linux-2.6 to build the first LFS with a 2.6 kernel. To finish, I guess no multilib is still supported. Short answer, no. The only reason I can think of to have a multilib system is to be able to run proprietary binaries that don't support 64-bit systems. What applications do you have that fit that category? To me, multilib is twice the work for very little benefit. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposing a new LFS release
Jean-Philippe MENGUAL wrote: ok thanks for this answer. I'll remember that 32-32 64-64, it will be easier for me to solve some problems. For multilib, I understand it'll be never done lfs. ok. I'm pleased with knowing precisely this. It will help me to see my translation strategy among complex lfs world :) Never say never. It's my opinion that multilib, in general, is not needed for LFS. Others may (probably do) disagree. Last question (still short): do you think it's useful (and will be done) to build lfs from 32 to 64bits? Personally, no, I don't think it's useful in general. It is useful in specialized applications like building for an embedded device that doesn't have a compiler and other build support. However, I think that is beyond the scope of LFS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New LFS RElease?
The kernel is about to release 2.6.16 (they have been on 2.6.16-rc5 for about two weeks now) so we are quite a bit behind there. Yes, but any upgrade to the kernel will require a newer version of udev which is why the udev_update branch was created. If your considering the new 2.6.16 kernel as a justification to update, then surly the LLH / Raw headers should be a consideration, as moving everything else forward and keeping on the 2.6.12 headers seems a little odd. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New LFS RElease?
On Thu, Mar 09, 2006 at 11:11:41AM +, Matt Darcy wrote: If your considering the new 2.6.16 kernel as a justification to update, then surly the LLH / Raw headers should be a consideration, as moving everything else forward and keeping on the 2.6.12 headers seems a little odd. Keeping the old llh, to be sure, is not the goal, but it seems to work and can be useful until another method has stabilized enough for inclusion. From what I've read, inotify is the only thing that keeps popping up and a patch will satisify that. The 2.6.16 update will be less of a problem than the glibc-2.4 update, which appears will be the absolute furthest threshold in our timeline to replace the old llh. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New LFS RElease?
Archaic wrote: From what I've read, inotify is the only thing that keeps popping up and a patch will satisify that. Not quite true anymore; 2.6.16 also includes some new syscalls (openat and friends) that will (may? probably will) require changes in the userspace headers. There may be other reasons too; I'm not sure. I know of inotify and an issue with kd.h and X.org[1] as of 2.6.15, but there may be others. Now, yes, we could patch these into llh (actually, Mariusz may welcome us doing a patch like that, if we give it to him as well; it might be worth a shot at least). But it's more than just inotify. [1] http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/07.html signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New LFS RElease?
Bryan Kadzban wrote: Not quite true anymore; 2.6.16 also includes some new syscalls (openat and friends) that will (may? probably will) require changes in the userspace headers. Most definitely, if you want them to be used that is :-) Tho' only Glibc-2.4 and above has support for the new syscalls so it shouldn't matter much to LFS from a release POV. Now, yes, we could patch these into llh (actually, Mariusz may welcome us doing a patch like that, if we give it to him as well; it might be worth a shot at least). More info about Mariusz here: http://www.diy-linux.org/pipermail/diy-linux-dev/2006-March/000755.html 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: New LFS RElease?
Bruce Dubbs wrote: It is time to start considering a new LFS release. I see that we are behind on gcc and glibc as gcc-4.1 and glibc-2.4 have been released. I don't think these are appropriate if we're thinking of a near-term release. They're simply too new and untested at present. The current toolchain has had a fair amount of testing already and has proved to be relatively stable. The only change I'd like to see is an upgrade to gcc-4.0.3 when it's available, in order to fix a kernel compilation problem (see ticket #1718). The kernel is about to release 2.6.16 (they have been on 2.6.16-rc5 for about two weeks now) so we are quite a bit behind there. Yes, but any upgrade to the kernel will require a newer version of udev which is why the udev_update branch was created. I'm not sure what the status of the udev branch is. I haven't seen much activity there for a while. I don't think it's far off at all now. There's a few known bugs in trac and another couple of minor one's I'll be fixing up real soon now. The biggest issue at the moment is ticket #1720. Perhaps an update to the Roadmap on the wiki and some target dates there would help. Well, apart from putting Real Soon Now against each one, I'm not sure how accurate we can be with dates. The reason I'm asking is that BLFS needs to go into a different mode to get out a companion release and there have been a lot of significant updates including X, Gnome, and KDE since the last stable release. That includes rebuilding all the packages with the latest toolchain once that gets frozen in LFS. OK then. I'll go out on a limb and say that LFS will be feature complete by 2006-04-01, at which point we'll branch a stabilisation effort and keep trunk for regular package updates including the gcc-4.1 and glibc-2.4 stuff. Does that sound reasonable to everyone? Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New LFS RElease?
El Miércoles, 8 de Marzo de 2006 20:36, Bruce Dubbs escribió: It is time to start considering a new LFS release. I see that we are behind on gcc and glibc as gcc-4.1 and glibc-2.4 have been released. The kernel is about to release 2.6.16 (they have been on 2.6.16-rc5 for about two weeks now) so we are quite a bit behind there. I see two possibilities: 1- Release LFS-6.2 using trunk as is now. 2- Wait up to can merge both alphabetical and udev_update branchs. That would meant to include also GCC-4.1, Glibc-2.4 and Linux-2.6.16. Thinking on BLFS, I think that 1 could be the best choice. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New LFS RElease?
Bruce Dubbs wrote: It is time to start considering a new LFS release. Only after reverting all UTF-8 changes in trunk. BLFS as-is is not ready, and BLFS+Wiki is not BLFS. And even BLFS+Wiki will take at least three months before I can put it into shape. Matthew: sorry for violating my promise not to talk about this. UTF-8 really needed to go into a branch. Bottom point: I don't want to see another RedHat 8 in BLFS. I see that we are behind on gcc and glibc as gcc-4.1 and glibc-2.4 have been released. Yes, and I noticed that gcc-4.1.0 probably miscompiles the nfs-root code in linux-2.6.15.4 at least on x86_64. Let me see if the problem is indeed in gcc-4.1.0, by compiling a kernel with the same config using an older version of gcc. To see the problem, boot the kernel with the command line similar to the following (assuming that you have a NFS server available and running on 10.0.2.2): root=/dev/nfs nfsroot=10.0.2.2:/mnt/vm/qlfs3,nfsvers=3,tcp,port=2049 ip=10.0.2.15:10.0.2.2:10.0.2.2:255.255.255.0:lfs:eth0:off When I force the port number 2049 (0x801), the kernel connects to port 264 (0x108). Looks that the htons() function is either called improperly or miscompiled. As for glibc-2.4, compile it and see that it is a development release. Please wait for 2.4.1. The kernel is about to release 2.6.16 (they have been on 2.6.16-rc5 for about two weeks now) so we are quite a bit behind there. Newer kernels are good (and in fact needed for users that want open-source 3D acceleration for newer ATI cards). They also bring security fixes. Unfortunately, old udev doesn't quite work with these kernels. I'm not sure what the status of the udev branch is. I haven't seen much activity there for a while. Ticket #1720 is a real blocker that doesn't have a solution upstream (they even deny that this bug exists). Waiting for reaction of other people who can produce the bugreport. Perhaps it is a good idea to drop udev and hotplug temporarily from trunk, and update the kernel. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New LFS RElease?
Archaic wrote: What's the hurry? Who are we competing with? I'm not trying to be defensive, but trying to sort out your reasoning. We all want a release, but that should have happened a few months back. It just isn't ready right now and a rush job is not a good idea. No real hurry. I just wanted to get developers thinking in that direction. I wasn't saying 'do it now', but 'lets start planning to do it'. Matt's earlier comment about March is probably too soon. What I would really like to see is a list of things to do in the trac roadmap. Target dates would be a plus, but I don't have anything specific in mind. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
