Re: Small typo in Chapter 6.9: Glibc
El Miércoles, 28 de Febrero de 2007 16:24, Dan Nicholson escribió: > > Editors: I went with the BLFS approach where the date and changelog > aren't updated for trivial changes. Is that alright? Right. As you can see, I do some commits from time to time in all xLFS books, but very few of them have actually a changelog entry due that are small typos or tags fixes. -- 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.info 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: Various issues with the book
> > I will start tomorrow another build with the updated LFS-SVN code (if the > new patches are availables for download at that time) and without chapter05 > M4. Doned also. Conclusions: M4 can be romoved from Chapter05. I'm doing the commit now. We must to investigate wy now ICA/farces tests shows that /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/cc1 and /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/cc1plus differs. -- 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.info 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: Various issues with the book
El Domingo, 25 de Febrero de 2007 00:43, Ken Moffat escribió: > Sorry I'm a bit later than I'd like in replying to this, but I saw > these running farce on the book as it was in December. Didn't > bother reporting it, so feel free to moan at me. Thanks for remembering that now. My second ICA/farce build has finished just now, and it corfims that that GCC binaries differs also having M4 on chapter05. That builds has been done before the GCC, Glibc, and DB updates done by Matthew this morning. I will start tomorrow another build with the updated LFS-SVN code (if the new patches are availables for download at that time) and without chapter05 M4. -- 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.info 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: Various issues with the book
El Sábado, 24 de Febrero de 2007 21:38, Jeremy Huntwork escribió: > I had thought that the alphabetical branch didn't even touch chapter 5? There was some changes, included the removal of the commented-out Bison and Flex lines, when doned the merge. See svn diff -r7279:7489 chapter05/chapter05.xml -- 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.info 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: Various issues with the book
El Sábado, 24 de Febrero de 2007 21:34, M.Canales.es escribió: > I'm doing now a new ICA/farce build but with M4 to see if that two binaries > differs also or not. Another cause could be that my system have now a very big load and ocasionally I have aleatories build fails (two times in the last four days, one building Glibc and another running the Autoconf testsuite). That it what i'm doing two or three build of each type to do the tests. But reports from others folks will very very apreciated. -- 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.info 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: Various issues with the book
El Sábado, 24 de Febrero de 2007 21:28, Dan Nicholson escribió: > > Did you ever find out if the diffs in cc1 were related to the m4 removal? > I'm doing now a new ICA/farce build but with M4 to see if that two binaries differs also or not. If they not differ, M4 should be retained and maybe added to GCC dependencies list. If they not differ, M4 can be removed but we will need to investigate what causes that that files differs. -- 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.info 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: Various issues with the book
El Sábado, 24 de Febrero de 2007 12:58, Alexander E. Patrakov escribió: > Thanks. Could you please patch your local copy of the book and determine > via jhalfs whether it is still usable with HJL binutils, if one doesn't > drop m4? If not, then I really see no reason to keep it. HJL Binutils complaints about missing Bison and Flex, thus being M4 missing also (if it can be removed) is not worse than the current situation, IMHO. -- 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.info 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: Various issues with the book
El Sábado, 24 de Febrero de 2007 12:40, M.Canales.es escribió: > > I'm doing the ICA/farce build now. > ICA and farce reports this differs: FAIL: /usr/lib/libstdc++.la is different FAIL: /usr/lib/libsupc++.la is different That two has been here from always. FAIL: /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/cc1 differs after stripping and processing FAIL: /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/cc1plus differs after stripping and processing That two are new, at least for me, but I'm not sure yet if are due the M4 removal or not. Looks like another set of builds using current SVN (i.e, using gcc-4.1.2 and the Glibc update branch patch) might be needed before taking a decission about the Chapter05 M4 removal. -- 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.info 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: RFC: Create a new-rendering-tools branch
El Sábado, 24 de Febrero de 2007 17:14, Bruce Dubbs escribió: > Randy has assigned that ticket to himself. I can update quantum and > anduin anytime, but I haven't looked at the procedure to do that. > However, I can't imagine it being much different from what we have now. On that ticket there is patch by Matthew with the commands update. -- 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.info 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: Various issues with the book
El Sábado, 24 de Febrero de 2007 14:49, Matthew Burgess escribió: > No complaints here, Manuel. Thanks! Done in r7942 and r7943 -- 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.info 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: Various issues with the book
El Sábado, 24 de Febrero de 2007 14:30, Bryan Kadzban escribió:
> Or, since I'm not at all sure how the automatic indexing stuff works yet
> in DocBook ({indexterm}, etc.), perhaps it would be possible to just
> remove the hyphens for that package, and call it "Linux 2.6.20 Headers"
> or "Linux Headers", so those strings show up in the index (and on the
> rest of the pages)?
Right, the Index need be fixed. It uses yet the tagging inherited for when
using the Linux-libc-headers package.
Also I vote for changing the pages title to "Linux-2.6.20 API Headers"
I can do both changes later today if there are no complaints.
--
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.info
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: Various issues with the book
El Sábado, 24 de Febrero de 2007 12:58, Alexander E. Patrakov escribió: > Thanks. Could you please patch your local copy of the book and determine > via jhalfs whether it is still usable with HJL binutils, if one doesn't > drop m4? If not, then I really see no reason to keep it. What's the download URL for current HJL binutils? I will try it after finished the current ICA/farce build. -- 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.info 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: Testing required: SVN build segfaults on stripping chapter6
El Sábado, 24 de Febrero de 2007 13:02, Alexander E. Patrakov escribió: > > Does this mean that LFS LiveCD 6.3-pre2 has to use jhalfs from SVN trunk? > We want to release jhalfs-2.2 in a week or so. Plus that fixes it will have also other fixes for CLFSx books and add support for BLFS-6.2. -- 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.info 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: Testing required: SVN build segfaults on stripping chapter6
El Sábado, 24 de Febrero de 2007 00:36, Bruce Dubbs escribió: > Manuel, > I've only been following this casually. What was different about the > chroot command that would cause a segfault? The first issue was that chapter06/115-strippingagain script was using #!/bin/bash as the shabang, thus after stripping libreadline and/or libhistory the subshell hangs, leading to a "make: Error 126" That has been fixed changing that script shabang to #!/tools/bin/bash The second issue, not fixed yet, is that when resuming a failed chroot build after installing Chapte06 Bash, $LFS/bin/bash exist and is the final bash binary (not the link to /tools/bin/bash created at the begining of the chapter), thus "make mk_CHROOT" will use $LFS/bin/bash as the $SHELL instead using /tools/bin/bash (like does on a clean build), segfaulting when running the strip command. To fix that we need to force the mk_CHROOT target to allways use /tools/bin/bash as their $SHELL, but withiut messing the shell used by sub-make process launched by build scripts :-/ -- 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.info 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: Various issues with the book
El Sábado, 24 de Febrero de 2007 05:49, Dan Nicholson escribió: > > Manuel, since you're all set up to do the ICA builds with jhalfs, > could you remove m4 from Ch. 5 and see if anything happens? I'm doing the ICA/farce build now. A previous sucessful build with all final system testsuites enabled show that the removal of M4 from chapter05 don't afect the testsuites. -- 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.info 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: RFC: Create a new-rendering-tools branch
El Sábado, 24 de Febrero de 2007 05:20, Bruce Dubbs escribió: > Dan Nicholson wrote: > > Is this still going to happen. Manuel is obviously going to drive any > > changes, but I think any branches have to be created by Matthew or > > Bruce. > > Actually, anyone with commit privs can create a tag or branch. It's > just a svn command away. Right, I'm waiting the DocBook-XSL-1.72.1 release (just few minutes ago was committed another bug fix into the extensions/ subdirectory) What we should do as soon is possible is to update the sources to DocBook-XML-4.5 DTD, but that depend on having the package installed at least on quantum, and anduin. Bruce, some timeline about that? Also BLFS should close #2241 to allow editors to install the new DTD on their hosts. -- 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.info 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: Testing required: SVN build segfaults on stripping chapter6
El Viernes, 23 de Febrero de 2007 20:26, M.Canales.es escribió: > That should corfim that the issue is in jhalfs, not related with the book > or the GCC/Glibc planned updates. And fixed. After knowing what was causing the segfault in both a full build and later in my partial build tests, the fix was terribly obvious :-/ -- 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.info 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: Testing required: SVN build segfaults on stripping chapter6
El Viernes, 23 de Febrero de 2007 20:18, Matthew Burgess escribió: > Ah, slight clarification here! I'm actually running the command via the > following (from chapter06/revisedchroot.html): > > sudo chroot $LFS /usr/bin/env -i \ > HOME=/root TERM=\"$TERM\" PS1='\u:\w\$ ' \ > PATH=/bin:/usr/bin:/sbin:/usr/sbin \ > /bin/bash --login" > > Therefore, /bin/bash is linked to /lib/* which is why it exhibits the same > behavior, I'd guess. Well, that is not the chroot command found in chapter06/strippingagain.html :-/ That should corfim that the issue is in jhalfs, not related with the book or the GCC/Glibc planned updates. -- 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.info 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: Testing required: SVN build segfaults on stripping chapter6
El Viernes, 23 de Febrero de 2007 19:53, Dan Nicholson escribió: > I think the issue in jhalfs may be because progress-bar.sh is using > /bin/bash. Just a guess, but I saw the same issue before and that was > what initially struck me. Not, reducing the Makefile target to just: 116-strippingagain: 114-vim source envars && $(crCMDSDIR)/chapter06/$@ segfaults also. -- 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.info 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: Testing required: SVN build segfaults on stripping chapter6
El Viernes, 23 de Febrero de 2007 19:39, Matthew Burgess escribió: > If anyone can confirm the above, could you also suggest an explanation as > to why the above two libraries are problematic? I initially thought it was > a problem specific to jhalfs, because of the way it executes scripts under > /bin/bash (therefore /lib/lib* would be in use and stripping may cause > problems). I think Manuel's done tests to force the stripping to be > executed under /tools/bin/bash and had the same result though, which rules > that explanation out. I still think that, at least for current LFS-SVN, the issue is jhalfs-specific due the recent Makefile $SHELL changes. But Matthew confirmed that while testing the updates to GCC-4.1.2 and glibc branch_update patch, running the stripping command manually from inside the chroot jail hangs the shell, thus maybe there is other issues involved here. -- 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.info 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: Various issues with the book
El Martes, 20 de Febrero de 2007 09:22, Dan Nicholson escribió: > > 3. Is m4 really needed in Chapter 5? I thought the only reason it was > > there was because of Binutils, but it doesn't need m4 now... > > Is that why? I have no idea, and I think you're probably most > qualified since you did all the work on the dependencies. The other > things that need it early in Ch. 6 are bison and autoconf, and they're > taken care of. I just looked through my logs, and gcc checks for m4, > but I don't think it uses it. > > It could probably be removed or commented out, but I think someone > will have to do an ICA build to see what happens. I'm starting now a ICA/farce build to test that and to verify that the warning in the Bzip2 instructions about needing to run rm /usr/bin/bz* if you reinstall is no longer needed with the latest version. T -- 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.info 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: problems to make glibc-2.3.6 : /tools/include/asm/errno.h:4:31: error: asm-generic/errno.h: No such file or directory
El Miércoles, 14 de Febrero de 2007 21:11, Matthew Burgess escribió: > Thinking about this a bit more, now that we know that LFS needs to be built > under bash, can we not just get rid of the workaround of doing `make > SHELL=/bin/bash' in jhalfs and instead just do a config check on the host > instead to see what the current shell is and bail out if it's anything > other than 'bash'? FYI, although Ubuntu uses /bin/dash by default, > /bin/bash is available on a default install so it shouldn't be hard for a > user to get a sane environment. Maybe, but jhalfs is used also to build HLFS and CLFSx systems. Moving this to alfs-discuss to allow George to can discuss about it. -- 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.info 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: Fwd: r1764 - in trunk: . vorbis-tools
El Miércoles, 14 de Febrero de 2007 20:41, Dan Nicholson escribió: > I just noticed that the entities for vorbis-tools in BLFS are all > named vorbistools-*. Will this patch be picked up by the render script > since it's named vorbis-tools-*? I don't really understand how the > patches get updated. The patches list is generated using the actual patches names found in the book, after resolving entities. No matter how the entities are named as long as the patch name in the output HTMLs is the proper one. -- 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.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: problems to make glibc-2.3.6 : /tools/include/asm/errno.h:4:31: error: asm-generic/errno.h: No such file or directory
El Miércoles, 14 de Febrero de 2007 20:22, Matthew Burgess escribió: > Oh, and Manuel, if jhalfs is using any other workarounds currently, or > needs to in the future, could you let lfs-dev know so we can see whether > the book needs to integrate the fixes? Thanks. > > In an ideal world, jhalfs should be using the *exact* commands that are in > the LFS book. Well, that work-around was needed due jhalfs is using a lot of basshims in their internal code, not due issues with the book commads itself. The build commads are just the ones used in the book, but we need to run the Makefile sub-process using "make SHELL=/bin/bash" to let unpack commands and progress_bar.sh run nicely. As a side effect, that shell change is propagated to the actual build scripts hidding the current Glibc issue with dash :-/ -- 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.info 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: problems to make glibc-2.3.6 : /tools/include/asm/errno.h:4:31: error: asm-generic/errno.h: No such file or directory
El Miércoles, 14 de Febrero de 2007 19:59, Matthew Burgess escribió: > Well, I've done a couple of LFS-svn builds recently on this box and never > encountered this problem, so I'm not sure that `dash' is the cause. If you are using jhalfs to do the builds you will not find the bug. We changed all shabangs to #!/bis/bash and added "make SHELL=/bin/bash" to the jhalfs build Makefile several time ago due Ubuntu start using dash ;-) -- 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.info 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: Dev book images are missing
El Viernes, 9 de Febrero de 2007 20:13, Randy McMurchy escribió: > Either way, I think BLFS and LFS should use similar strategies. For consistency, yes. > I like the LFS way. :-) I'm indifferent, there is no a "proper" ar "better" way and upstream PNG files hasn't been modifyed from five years ago. -- 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.info 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: RFC: Create a new-rendering-tools branch
El Jueves, 8 de Febrero de 2007 21:49, Matthew Burgess escribió: > Hi folks, > > Do you think it's worth creating a branch so we can work on updating the > book rendering infrastructure? This way, if we can't get it sorted in time > for a release we simply don't merge from that branch? It also means that > folks with an interest in this can contribute and relieve some pressure > from Manuel. I agree. But only the stylesheets/ subdir need be branched, not the full book sources. The XML code don't must be afected by the XSL update. To work and test the new XSL code, just pull a fresh trunk working copy and then "svn switch" stylesheet/ to the branch. > I can install things on Quantum so that they don't interfere with regular > book renderings, which should allow a side-by-side comparison to ensure we > don't introduce any aesthetic regressions. Great. -- 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.info 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: Dev book images are missing
El Viernes, 9 de Febrero de 2007 03:07, Randy McMurchy escribió: > That's great, but I'm proposing we don't have them at all in SVN. > Seems, though, that in the conversation you don't remember, Manuel > mentioned something why we should continue to carry them in SVN. > I don't remember what it was. I remember a discussion about that but not the postures of each of us. The question is that both approach works and are portable (after fixing the PDF issue in LFS pointed in my other post). Having the images in SVN have this pros, IMHO: - Make the sources more auto-contained - Avoid setting a Makefile envars and updating the XSL version number in stylesheets/pdf/lfs-admon.xsl. - Also allow to use customized images, if dessired, and prevent to use newer upstream ones that might not have a good look for our book layout. The cons has been already pointed by you. -- 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.info 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: Dev book images are missing
El Viernes, 9 de Febrero de 2007 08:53, Matthew Burgess escribió: > I'm not sure I understand this argument, Bruce. Rendering the book is > already dependent on DocBook, DocBook-XSL (and a specific version at that), > libxml2, libxslt and Fop, for PDF output. The XSLROOTDIR is overridable on > the command line, just like any other Make variable, so folks can still > render the book successfully on non LFS/BLFS setups. Right for HTML, the images path is set in a Makefile variable. For PDF output the images path is defined as a xsl:param in stylesheets/pdf/lfs-admon.xsl. To make it portable to non-LFS hosts, the first command in the "pdf" Makefile target need be changed to read something like (not tested): xsltproc --xinclude --nonet --output $(BASEDIR)/lfs-pdf.fo \ --stringparam admon.graphics.path $(XSLROOTDIR) \ stylesheets/lfs-pdf.xsl index.xml -- 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.info 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: Proposal for an LFS-6.3
El Jueves, 8 de Febrero de 2007 20:44, Dan Nicholson escribió: > > I'd like to second that we wait on the book source conversion for a > release. This will have to happen sooner or later, and after > BLFS-6.2.0 is as good a time as any. This doesn't mean we can't keep > moving the book towards release, but I'd like this stuff to be in > place if possible. I want to do the update as soon as possible, but not delaying LFS-6.3 waiting that. If the XSL+FOP update isn't at time for LFS-6.3, we need to decide what will happen with BLFS-6.3. > Manuel, if there's anything I can do to help out let me know. My XSL > sucks, but I can usually read it decently. Until having 1.72.1 at hand I don't know how many deeper the stylesheets rewrite will be (testing 1.72.0 isn't an option due that there is already bug-fixes and files renaming in the SVN code). But I will agree if you can investigate how FOP-0.93, and it dependencies, should be installed. -- 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.info 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: Problems rendering the book
El Jueves, 8 de Febrero de 2007 20:17, Matthew Burgess escribió: > 1. Wait for BLFS-6.2 to be released - we don't want to be screwing with > Quantum's rendering infrastructure so close to a release. It'd also be > nice to have the DocBook-4.5 instructions in BLFS and installed on Quantum > according to them. I'll try and get a BLFS book patch together for that > tonight. > > 2. Upgrade to DocBook-4.5 DTD (#1893). This should just be a trivial > `sed'. It shouldn't directly affect our HTML or PDF output so is the > easiest/safest change to get in. That's a non-brain update. The model contents changes don't affect us. > 3. Upgrade to DocBook-XSL-1.72.1 (no Trac ticket). I'll leave this up to > Manuel, though I really should try and get my head around XSLT one of these > days. DB-XSL-1.72.1 should be released at the end of this month. Depending on how intrusive the needed changes will be, count one-three week to have the new stylesheets almost ready. > 4. Upgrade to Fop-0.93 (#1947). Again, this will be largely/wholly > dependent on Manuel to fix up any rendering issues that crop up. This is an unknown variable. This first issue is to can install it properly (not tried yet). > 5. Move to DocBook-5.0 (RelaxNG) for XML validation (#855). This is a way > off yet, but will require a fair bit of work on all the individual XML > files. I'm anxious for doing that update to can remove all that xmlns:xi="http://www.w3.org/2003/XInclude"; bloat, primarly from CLFS sources ;-) -- 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.info 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: Proposal for an LFS-6.3
El Jueves, 8 de Febrero de 2007 20:05, Matthew Burgess escribió: > I'll go through Trac and reassess milestones and such like tonight, but I > think a 6.3 release within 1 month is feasible. Does everyone else agree? That would meant not time to me to do the update to DB-XML-4.5+DB-XSL-1.72.1+FOP-0.93 at time for LFS-6.3 release. Following our current policy, that implies that that packages will can not be updated again in the future BLFS-6.3 book, except if adding separate pages for each version, the current ones and the ones used to render the books. :-/ > Now that I'm more or less settled down in my new place, I'd like to don the > Release Managers hat again if nobody else objects? I agree. -- 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.info 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: Problems rendering the book
El Jueves, 8 de Febrero de 2007 15:40, Dan Nicholson escribió: > > I completely forgot about this. Sorry. I think you need to use 1.69.1. > According to our local XSL guru, our book is broken using newer > versions. > > http://wiki.linuxfromscratch.org/blfs/ticket/2088 That ticket was about 1.70.1, but there is a lot of another changes and bug fixes from 1.70.1 to the soon-to-be-released 1.72.1 that implies several modifications on our XSL customization layer. I'm waiting 1.72.1 release to start working on the update. Also, the DTD need be updated to 4.5. -- 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.info 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: Dead Links
El Miércoles, 24 de Enero de 2007 21:53, Randy McMurchy escribió: > > No hurry. Thanks Manuel. > Done in r6464. See stylesheets/wget-list.xsl for a more-in-deeper links test. Attached the true_bad_links file generated with the new "test-links" target for r6463. From 930 tested URLs there is only 44 dead links, not so bad ;-) -- 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.info TLDP-ES: http://es.tldp.org http://ftp.pld.org.pl/software/shadow/shadow-4.0.15.tar.bz2 ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.19.tar.gz http://ftp.debian.org/debian/pool/main/i/iso-codes/iso-codes_0.51-1.1.tar.gz http://www.imagemagick.org/download/ImageMagick-6.2.8-0.tar.bz2 http://www.pilot-link.org/files/pilot-link-0.11.8.tar.bz2 ftp://ftp.starlink.rl.ac.uk/pub/ussc/store/starperl/starperl.tar.Z ftp://ftp.starlink.rl.ac.uk/pub/ussc/store/starperl/starperl.tar.Z ftp://ftp.starlink.rl.ac.uk/pub/ussc/store/starperl/starperl.tar.Z ftp://ftp.starlink.rl.ac.uk/pub/ussc/store/starperl/starperl.tar.Z http://cpan.org/authors/id/M/MS/MSISK/HTML-Element-Extended-1.14.tar.gz http://cpan.org/authors/id/P/PE/PETDANCE/HTML-Tree-3.1901.tar.gz http://cpan.org/authors/id/B/BD/BDFOY/Business-ISBN-1.82.tar.gz http://cpan.org/authors/id/B/BD/BDFOY/Business-ISBN-Data-1.11.tar.gz http://cpan.org/authors/id/B/BD/BDFOY/Test-Prereq-1.031.tar.gz http://cpan.org/authors/id/R/RG/RGARCIA/Module-CoreList-2.04.tar.gz http://cpan.org/authors/id/A/AU/AUTRIJUS/PAR-Dist-0.09.tar.gz http://cpan.org/authors/id/A/AN/ANDK/Devel-Symdump-2.05.tar.gz ftp://ftp.python.org/pub/python/2.4.4/Python-2.4.4.tar.bz2 ftp://ftp.samba.org/pub/ppp/ppp-2.4.4.tar.gz ftp://ftp.ing-steen.se/pub/unix/unsort/wvdial-1.54.0.tar.gz http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-stable-4.2.0a-20060224.tar.gz ftp://ftp.udel.edu/pub/ntp/ntp4/ntp-stable-4.2.0a-20060224.tar.gz ftp://ftp.research.telcordia.com/pub/nsb/mm2.7.tar.Z http://www.apache.org/dist/httpd/httpd-2.2.2.tar.bz2 ftp://ftp.tux.org/pub/net/apache/dist/httpd/httpd-2.2.2.tar.bz2 http://dev.mysql.com/get/Downloads/MySQL-5.0/mysql-5.0.21.tar.gz/from/http://mysql.mirrors.hoobly.com/ ftp://ftp.fr.postgresql.org/source/v8.1.3/postgresql-8.1.3.tar.bz2 http://samba.org/ftp/rsync/rsync-2.6.8.tar.gz ftp://ftp.samba.org/pub/rsync/rsync-2.6.8.tar.gz http://mirrors.isc.org/pub/kde/stable/koffice-1.5.0/src/koffice-1.5.0.tar.bz2 ftp://ftp.kde.org/pub/kde/stable/koffice-1.5.0/src/koffice-1.5.0.tar.bz2 ftp://ftp.ussg.iu.edu/pub/openoffice/stable/2.0.3/OOo_2.0.3_src.tar.gz ftp://ftp.us.xemacs.org/pub/xemacs/aux/nas-1.7.src.tar.gz ftp://ftp.raphnet.net/pub/libmikmod/libmikmod-3.1.11.tar.gz http://www.mplayerhq.hu/MPlayer/releases/codecs/essential-20060501.tar.bz2 http://www.mplayerhq.hu/MPlayer/releases/codecs/all-20060501.tar.bz2 http://www.mplayerhq.hu/MPlayer/Skin/Blue-1.5.tar.bz2 http://ftp.easysw.com/pub/cups/1.2.7/cups-1.2.7-source.tar.bz2 http://downloads.sourceforge.net/ghostscript/ghostscript-8.53.tar.bz2 http://ftp.easysw.com/pub/ghostscript/8.15.2/espgs-8.15.2-source.tar.bz2 ftp://ftp.sane-project.org/pub/sane/sane-backends-1.0.17/sane-backends-1.0.17.tar.gz http://www.tug.org/ftp/tex-archive/systems/unix/teTeX/3.0/distrib/tetex-src-3.0.tar.gz http://www.tug.org/ftp/tex-archive/systems/unix/teTeX/3.0/distrib/tetex-texmf-3.0.tar.gz http://www.tug.org/ftp/tex-archive/systems/unix/teTeX/3.0/distrib/tetex-texmfsrc-3.0.tar.gz -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: LFS Book translation.
El Martes, 16 de Enero de 2007 23:37, Vincent escribió: > In the -unlikely- event that you only need translators to start it, I > stand as a candidate to do a bit (or even a lot) of English -> French > translation. See this, you could to help them ;-) http://www.fr.linuxfromscratch.org/ -- 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.info 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: BLFS package repo
El Domingo, 14 de Enero de 2007 18:31, Justin R. Knierim escribió:
> Justin R. Knierim wrote:
> Anyways, any thoughts or a way to do this would help much. :)
Committed in r6393 an LFS-like stylesheet to create a wget-list file. To
generate it, run "make wget-list".
Attached is the one generated for current BLFS SVN (r6393).
This file contains all packages and patches download URLs in book order.
Only that URLs that are uder a {itemizedlist}{listitem}{para}{ulink} XML
structure are output. In theory, no mandatory/optional packages and patches
URLs should be outside that type of XML structure.
For that packages that both HTTP and FTP URLs are available, only one of them
is output, primarly the FTP one.
There is 8 duplicated URLs than could be removed pipping the file throw sort
and uniq.
At first chance looks like there is no missing packages or patches, except
maybe some Perl module from PDL dependencies or the Perl-modules page.
Say me if you need something different or complementary.
Pd: I'm still waiting that you say me how you want the one for HLFS. one
common wget file or one for Glibc and othe for uClibc based books.
--
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.info
TLDP-ES: http://es.tldp.org
wget-list.bz2
Description: BZip2 compressed data
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: Book rendering
El Lunes, 11 de Diciembre de 2006 12:06, M.Canales.es escribió: > I never played with it due that are very buggy, are unmantained, and I > don't know TeX sintax. Actually looks that there is some very slow development, in http://db2latex.sourceforge.net/snapshot/ the last snapshop is dated 06-May-2006. -- 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.info 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: Book rendering
El Lunes, 11 de Diciembre de 2006 12:46, Luca escribió: > > Now it's clearer; I'm not 100% sure but when I passed make tex maybe the > errors were others and not the one you mentioned, they should be > something like DB2Latex: Need to process XPath match book/xi:include but > as already said not sure. Yes, that's are ones of the the error messages showed, among others, after fixed the --xinclude and quandaset issues. It's are due db2latex not supporting some of the tags we are using now in BLFS. > I tried to process other tex files and it seems to work; dunno. > Debian uses db2lated with a patch of its own but don't know if it solves > the problem. On simple DocBook XML documents db2latex should work fine "as is", but BLFS is a very big beast and BLFS/stylesheets/blfs-tex.xsl was not updated to use the current BLFS tagging. -- 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.info 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: Book rendering
El Lunes, 11 de Diciembre de 2006 07:12, Bruce Dubbs escribió: > > Why do you think the db2latex is required? BLFS has teTeX. The > makefile generates a TeX file (blfs-book.tex), not a LaTeX file. To > create the TeX version of the book, just: The Makefile "tex" target calls stylesheets/blfs-tex.xsl to generate blfs-book.tex. That stylesheet was written by Larry long time ago and it uses db2latex-xsl-0.8pre1 to do the *.tex transformation: http://db2latex.sourceforge.net/ I never played with it due that are very buggy, are unmantained, and I don't know TeX sintax. -- 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.info 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: Book rendering
El Lunes, 11 de Diciembre de 2006 07:00, Luca escribió: > In blfs-book-sources Makefile there's the target "make tex" that has the > dependency of db2latex; the latter is not installed in blfs-book (I > installed it following the stylesheets installation); when I tried > passing "make tex" it broke (don't remember exactly the point). Yes, it's broken. In the first xsltproc command the --xinclude option is missing. And when generating the blfs-book.tex file the parsing fails with: compilation error: file /usr/share/docbook/db2latex-xsl-0.8pre1/xsl/qandaset.mod.xsl line 366 element template xsl:template: error duplicate name 'question.answer.label' That is due a bug in db2latex that could be avoided by commenting out the line in db2latex-xsl-0.8pre1/xsl/docbook.xsl. The parsing will still output several errors but blfs-book.tex is created. I don't know if that tex file can be compiled due that that don't have installed TeX or LaTeX right now, but the last time I tried, more than 2 years ago, the PDF generated was bugy and very ugly. > Can you explain me about the possible tex target and not including in > blfs the required dependency? Due that db2latex stylesheets are buggy and unmantained. -- 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.info 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: Released jhalfs-2.1
El Sábado, 9 de Diciembre de 2006 05:30, Alexander E. Patrakov escribió: > > Please don't ask questions how to do the above - you are assumed to know > this, otherwise jhalfs is not for you. > > > Objections? Corrections? Good, I like it. Plus, that procedure is more simple than the steps made in chapter02 up to Chapter04 when building manually the system, except for the sudo configuration. Thus IMHO, if the user can't follow that procedure most likely it will have problems also following the book. -- 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.info 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: Released jhalfs-2.1
El Viernes, 8 de Diciembre de 2006 16:50, Alexander E. Patrakov escribió: > I propose, instead of the current setup, to add the new "jhalfs" user to > /etc/passwd on the CD, setup sudo, put the jhalfs tarball in > /lfs-sources, and put some README file into root's home directory (or > append this information to the existing README). Any better suggestions > are welcome. The user already have to manually format the partition and mount it before launch current jhalfs-1.0, right? Then adding to the README that is also must to create a user account, configure sudo, change the partition mount point ownership to that user, and launch jhalfs-2.1 while logging as that user could be enough. If he don't know how to configure sudo to run jhalfs, then he is not ready to use this tool to build *LFS systems. The prerequisites listed in jhalfs README is very clear about who can use it. -- 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.info 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: Released jhalfs-2.1
El Viernes, 8 de Diciembre de 2006 15:41, Alexander E. Patrakov escribió: > > May I include it into the LFS LiveCD 6.2-4 instead of jhalfs-1.0? Yezs you should. But take note that now jhalfs-2.x must be run as unprivileged user with sudo privileges. -- 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.info 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: Patches issues
El Jueves, 7 de Diciembre de 2006 13:57, M.Canales.es escribió: > All that missing patches prevent HLFS be build using jhalfs and also > prevent to update the FTP mirrors. Sorry, missing patches are actually the ones listed in http://www.linuxfromscratch.org/patches/hlfs/svn/copyerrs and http://www.linuxfromscratch.org/patches/hlfs/2.4-branch/copyerrs The other false positives was due the server refusing wget download conexion. -- 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.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Patches issues
In HLFS trunk: glibc-2.5-dl_execstack_PaX-1.patch does not match MD5SUMS value NEW MD5SUM: d3c45b9f63a3f0f6cf5847d4ae4f9759 glibc-2.5-localedef_segfault-1.patch does not match MD5SUMS value NEW MD5SUM: 879fcc4d60526a4796e5d99d5839de38 texinfo-4.8a-tempfile_fix-2.patch not found in the patches repo. In HLFS 2.4 branch: glibc-2.5-dl_execstack_PaX-1.patch does not match MD5SUMS value NEW MD5SUM: d3c45b9f63a3f0f6cf5847d4ae4f9759 glibc-2.5-hardened_tmp-1.patch does not match MD5SUMS value NEW MD5SUM: 77d9ae683f662e284aac6371fd3c glibc-2.5-iconv_unnest-1.patch not found in the patches repo glibc-2.5-localedef_segfault-1.patch not found in the patches repo glibc-2.5-pt_pax-1.patch not found in the patches repo linux-2.4.33.3-unistd_x86_PIC-1.patch not found in the patches repo texinfo-4.8a-tempfile_fix-2.patch not found in the patches repo vim-7.0-hardened_tmp-1.patch not found in the patches repo All that missing patches prevent HLFS be build using jhalfs and also prevent to update the FTP mirrors. -- 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.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Released jhalfs-2.1
The jhalfs development team is pleased to announce the release of jhalfs-2.1. New features in this version: - Better support for CLFS Sysroot book - Added support for CLFS Embedded book - Several bugs fixes and code clean-up The jhalfs-2.1 tarball can be downloaded from http://www.linuxfromscratch.org/alfs/downloads/jhalfs/stable/jhalfs-2.1.tar.bz2 The list of supported books can be found at http://wiki.linuxfromscratch.org/alfs/wiki/SupportedBooks Please, try it out and send any comments or bugs you find to the alfs-discuss mailing list. -- 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.info 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: Unnable to do ICA/farce comparative builds
El Miércoles, 6 de Diciembre de 2006 12:10, Greg Schafer escribió:
> IMHO there is little point in reinstalling the kernel headers during
> subsequent ICA iterations. I've never done it. After all, they are not
> binary, they are just ascii text.
Are the headers files already sanitized inside the kernel tree or are they
generated on-the-fly by "make headers-install" command ?
If the last, the tools used to generate the headers files (the ones in /tools
for the first build, but the ones in /{bin,usr} in iterative builds) could
have some impact on how they are generated and what contains each one.
> That said, it does seem strange that current LFS uses different methods
> for kernel headers installation in each phase ie: they are cp'd into place
> in the the temp system, but "make INSTALL_HDR_PATH=/usr headers_install"
> is used directly in the real system. It's unfortunate that
> "headers_install" wants to wipe out /usr/include in that scenario.
In the chapter05 phase when the linux kernel headers are installed
the /tools/include directory already contains headers from binutils-pass1
build, thus the "cp" method is used to not delete them.
> If you insist upon reinstalling the kernel headers during subsequent ICA
> iterations, the chroot phase kernel headers cmds should be switched to the
> cp method. Otherwise, just skip the reinstall like I do.
To switch to the "cp" method in chapter06 would be the most failsafe solution,
but for jhalfs to work that change should be done in the book. If not, the
most simple is to skip the headers reinstallation, if we are sure that that
will have no impact on the comparative analysis.
--
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.info
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
Unnable to do ICA/farce comparative builds
Hi, Doing yesterday a SVN-20061201 build to test current ICA/farce support in jhalfs I found that the first iterative build of Glibc fails at the configure stage with that: === ./configure output fragment checking how to run the C preprocessor... /lib/cpp configure: error: C preprocessor "/lib/cpp" fails sanity check See `config.log' for more details. The config-log file is attached. There is a lot of sintax errors, but the relevant part, I think, is that several header files can't be found. A search for some of them show: [EMAIL PROTECTED]:/mnt/build_dir$ sudo find . -name "limits.h" ./jhalfs/ICA/iteration-1/usr/include/linux/limits.h ./jhalfs/ICA/iteration-1/usr/include/limits.h ./jhalfs/ICA/iteration-1/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/install-tools/include/limits.h ./jhalfs/ICA/iteration-1/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/limits.h ./jhalfs/farce/iteration-1/usr/include/linux/limits.h ./jhalfs/farce/iteration-1/usr/include/limits.h ./jhalfs/farce/iteration-1/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/install-tools/include/limits.h ./jhalfs/farce/iteration-1/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/limits.h ./tools/lib/gcc/i686-pc-linux-gnu/4.1.1/install-tools/include/limits.h ./tools/lib/gcc/i686-pc-linux-gnu/4.1.1/include/limits.h ./tools/include/linux/limits.h ./tools/include/limits.h ./usr/include/linux/limits.h ./usr/lib/gcc/i686-pc-linux-gnu/4.1.1/install-tools/include/limits.h ./usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/limits.h [EMAIL PROTECTED]:/mnt/build_dir$ sudo find . -name "assert.h" ./jhalfs/ICA/iteration-1/usr/include/assert.h ./jhalfs/farce/iteration-1/usr/include/assert.h ./tools/include/assert.h As can be seen, when finished the system build both /usr/include/limits.h and /usr/include/assert.h are present. But when reinstaling the linux kernel headers at the beggining of the iterative build, both headers (and I think that many others) are deleted by the "make INSTALL_HDR_PATH=/usr headers_install" command. My question is, how that could be fixed to can do again proper comparative builds? -- 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.info TLDP-ES: http://es.tldp.org This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU C Library configure (see version.h), which was generated by GNU Autoconf 2.59. Invocation command line was $ ../glibc-2.5/configure --prefix=/usr --disable-profile --enable-add-ons --enable-kernel=2.6.0 --libexecdir=/usr/lib/glibc ## - ## ## Platform. ## ## - ## hostname = sandbox uname -m = i686 uname -r = 2.6.8.1 uname -s = Linux uname -v = #1 SMP Mon Nov 1 16:34:32 CET 2004 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /bin PATH: /usr/bin PATH: /sbin PATH: /usr/sbin PATH: /tools/bin PATH: /usr/sbin ## --- ## ## Core tests. ## ## --- ## configure:1701: checking build system type configure:1719: result: i686-pc-linux-gnulibc1 configure:1727: checking host system type configure:1741: result: i686-pc-linux-gnulibc1 configure:1909: running configure fragment for add-on libidn configure:1909: running configure fragment for add-on nptl configure:2042: checking sysdep dirs configure:2280: result: sysdeps/generic/elf sysdeps/generic configure:2358: checking for a BSD-compatible install configure:2413: result: /usr/bin/install -c configure:2428: checking whether ln -s works configure:2432: result: yes configure:2486: checking for gcc configure:2502: found /usr/bin/gcc configure:2512: result: gcc configure:2756: checking for C compiler version configure:2759: gcc --version &5 gcc (GCC) 4.1.1 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2762: $? = 0 configure:2764: gcc -v &5 Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.1/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ Thread model: posix gcc version 4.1.1 configure:2767: $? = 0 configure:2769: gcc -V &5 gcc: '-V' option must have argument configure:2772: $? = 1 configure:2776: checking for suffix of object files configure:2797: gcc -c conftest.c >&5 configure:2800: $? = 0 configure:2822: result: o configure:2826: checking whether we are using the GNU C compiler configure:2850: gcc -c conftest.c >&5 configure:2856: $? = 0 configure:2860: test -z || test
Re: Minor build order breakage
El Jueves, 30 de Noviembre de 2006 17:11, Jeremy Huntwork escribió: > Or are there any other ideas? Maybe to install Sed before E2fsprogs like is done in CLFS? -- 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.info 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: Section 6.40.2 (inetutils)
El Lunes, 6 de Noviembre de 2006 00:25, Matthew Burgess escribió: > Manuel, does jhalfs have an option/feature for producing a list of files > installed by a particular package? I couldn't see one, nor could I see > an easy way of parsing the log files that jhalfs produces to see what > files were installed by a particular package. If not, the way I handled > this previously was to do something similar to `touch /timestamp && make > install && find / -newer /timestamp' within the chroot environment. Like Dan said, the PACO patch could be used for that. But unfortunately the patch hasn't been updated/tested to work with jhalfs-2.x series due that Tor Olav, its developer, is very busy with real-live work :-/ -- 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.info 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 HLFS editor
El Viernes, 3 de Noviembre de 2006 16:13, Robert Baker escribió: > Thank you for the welcome its great to be a part of the team. Welcome Robert. Is nice to see more people involved on HLFS developent. -- 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.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Slow but finally just about done
El Martes, 31 de Octubre de 2006 19:18, Gerard Beekmans escribió: > I plan to use the opportunity to get LFS out of maintenance mode and > back as a forward moving project the way we all want it to be, and it > used to be. Can have you on-board again are good news :-)) -- 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.info 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: Greetings and a General Cleanup
El Lunes, 30 de Octubre de 2006 19:12, Jeremy Huntwork escribió: > Hi Everyone, Hi :-) I'm very happy to see you again. > First off, the ALFS project as a whole needs some re-structuring. I > gather that development on jhalfs is still hot (I've taken a peek at > recent code - you guys are doing some cool stuff. :) ), Thanks, we are doing the best we can. > but it seems > that everything else there is rather dead. I'd suggest dropping the rest > of it entirely, focus on improving jhalfs, and clean up the project so > that it better reflects the activity. This leads me to my second point... I agree. Profiles are unmaintained from several time ago and no more development is done on the nALFS code and DTD. I still would see something working on the alfs server-client binary code, but looks like there is no progremmers interested on (or maybe the lack of interest is due how jhalfs has been improved). > The ALFS page on the website is a good example of the condition of the > site as a whole. The content there is generally outdated and there's > nothing to show the activity that's going on in the background. So, I > guess I'm curious if there is still resistance to the idea of turning > the wiki into the main site. I agree also. I'm triying to keep up-to-date the wiki pages, but I have no acces to update the web pages. Gerard is working on building the new server. Maybe the decission about that should be taken soon to have it implemented on the new server from the beggining. -- 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.info 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: Build order change - Re: r7807 - in trunk/BOOK: . chapter01 chapter06
El Lunes, 16 de Octubre de 2006 19:15, Dan Nicholson escribió: > > 1. Add /bin/sed -> /tools/bin/sed to essential symlinks. Hacky, but it > would be the fast solution. A bit ugly, IMHO. > 2. Move sed up to before e2fsprogs. I think this would work. sed > appears to only use libc, texinfo and gettext besides the standard > build commands. And it was already relying on the texinfo and gettext > from /tools. That may be the best solution, if there is no other regressionsw associated with. > 3. Build just chattr from e2fsprogs in /tools. To add another package to /tools only to fix one test, no please. -- 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.info 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
Released jhalfs-2.0
The jhalfs development team is pleased to announce the release of jhalfs-2.0. New features in this version: - Added support for CLFS-2.0 development book - Added support for BLFS via blfs-tool framework - Added support to install blfs-tool dependencies while installing xLFS systems - A configuration system full-based on a menuconfig interface - Full Makefile rewrite to su to the "lfs" user and to enter to the chroot jail only one time. - Now the system build must be done as an unprivileged user, no more as root. That meant that sudo is now a required dependency. - Check that the host has installed the proper tools and versions to can run jhalfs and to can build the system. The jhalfs-2.0 tarball can be downloaded from http://www.linuxfromscratch.org/alfs/downloads/jhalfs/stable/jhalfs-2.0.tar.bz2 The list of supported books can be found at http://wiki.linuxfromscratch.org/alfs/wiki/SupportedBooks Please, try it out and send any comments or bugs you find to the alfs-discuss mailing list. -- 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.info 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: Upgrade to Linux-2.6.18
El Lunes, 25 de Septiembre de 2006 23:12, Dan Nicholson escribió: > > linux-headers) echo $(grep "^linux-headers.*.bz2" > > $JHALFSDIR/pkg_tarball_list | head -n1 ) ;; > > But the tarball name will probably not be linux-headers-*.bz2. It will > probably be linux-2.6.18.x since you do the installation straight from > the kernel tarball. Basic procedure is this: The above is the current line in jhalfs that need be changed by the new one found at the bottom of my post, to make use of the kernel tarball. > The only gotcha is in the last step because headers_install does `rm > -rf $INSTALL_HDR_PATH/include'. So, maybe we'd want to let it install > in the kernel tree and copy it ourselves. But, that's basically what > you'll be up against. At that point there should be nothing inside /tools/include, thus I see no harm in the `rm -rf $INSTALL_HDR_PATH/include'. -- 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.info 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: Upgrade to Linux-2.6.18
El Lunes, 25 de Septiembre de 2006 22:45, Matthew Burgess escribió: > I was going to simply call it "Linux Headers" and have it being written > out to "linux_headers.html". Does that help you at all? Yes. With that we can know that the needed change is to replace in get_package_tarball_name() function the line linux-headers) echo $(grep "^linux-headers.*.bz2" $JHALFSDIR/pkg_tarball_list | head -n1 ) ;; by linux_headers) echo $(grep "^linux-[[:digit:]]" $JHALFSDIR/pkg_tarball_list | head -n1 ) ;; -- 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.info 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: Upgrade to Linux-2.6.18
El Lunes, 25 de Septiembre de 2006 21:39, Dan Nicholson escribió: > I've been thinking about this for a while. Is there any reason why > jhalfs doesn't use the $package-url entity to find out the tarball > instead of assuming that there is a 1:1 mapping between package and > tarball? > With a small shell function (or xsl if it's easier), you > could strip out the tarball name and figure out the directory > (approximately using tar -tf $tarball | head -n1). Then you could get > rid of the ugliness in get_package_tarball_name() and get_sources(). > If you think it could be done, I'd be glad to work on it. I think this > could also be done as a make function. The current mapping work-flow is html_page_name-->script_name-->package_name-->tarball_name-->sources_dir_name. What you are speaking about is the last three steps (package_name-->tarball_name-->sources_dir_name). If there is a way to simplifiy it I will be very happy changing the code. In this case (headers installed from the kernel sources) the issue is about html_page_name-->build_script_name-->package_name mapping, and that can't be done until know how that new "Headers Installation" page will be called. -- 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.info 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: Upgrade to Linux-2.6.18
> Personally, I think this should be tackled in a 2-step approach. 1) > Simple version bump to 2.6.18. 2) Drop linux-libc-headers installation, > replacing it with 'make headers_install' from the kernel tarball. That > way, if the headers_install thing is not feasible for the time being, we > don't have to downgrade the kernel but can, if required, patch > linux-libc-headers to provide a suitable set of headers for us. I agree with playing with 'make headers_install', but if that don't work as expected I would prefer to use CLFS linux-headers package, due that it has been proved that works. > Incidentally, has anyone done any work on getting the headers_install > approach integrated with jhalfs. Is any specific support required, or > does it just require the "linux-libc-headers" page being replaced with a > "linux headers" page? For jhalfs, first we must to make mandatory the linux kernel package download (at this moment the kernel download/build is optional to allow folks to upgrade their kernel sources using patches). Then we will need to map the new headers page script name to the kernel package name, to can unpack it. Maybe some other fix could be needed, but we can't know until see the commands on that new page. -- 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.info 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: Minor Typos for cat and EOF
El Jueves, 21 de Septiembre de 2006 20:33, Matthew Burgess escribió: > Sorry about that complete and utter lie above. It's the other way > around, of course. If EOF is unquoted, shell expansion occurs within > the here-document. Yes. > Additionally, as bash(1) states, newline handling > differs between the quoted and unquoted cases, Yes. > so the quotes are > required in the case of our udev rules. Just the apposite. We need unquoted EOF to can generate working udev rules. -- 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.info 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: Minor Typos for cat and EOF
El Jueves, 21 de Septiembre de 2006 19:32, Peter Ennis escribió: > > cat >/etc/udev/rules.d/82-cdrom.rules << EOF > sbould be: > cat > /etc/udev/rules.d/82-cdrom.rules << "EOF" Not. That EOF must not be quoted to can have each udev rule spited in the book, due layout issues, but dumped on an unique line when actually issuing the command. -- 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.info 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: My status at the project
El Miércoles, 13 de Septiembre de 2006 18:11, Alexander E. Patrakov escribió: > I am sorry to say this, but it would be better if LFS goes on without > me. I hope that at least you continue sending posts and comments. Your contributions are very appreciated. > > This also means that LFS should drop (too kludgy and half-working) UTF-8 > support. This decision is also backed by the fact that some BLFS editors > repeatedly, but certainly not deliberately, misinterpreted my writings. > Beware, however, that there are applications (e.g. shadow and > nautilus-cd-burner) that expect RedHat-like UTF-8 setup (shadow is > already fixed in the book, nautilus-cd-burner is unfixable). IMHO, a not-full-working UTF-8 support is better than no support at all. Keeping it in the book can allow folks to catch the bugs and try to fix it, ot report it to better document the issues. -- 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.info 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: Welcome Bryan Kadzban to the editorial team
El Miércoles, 13 de Septiembre de 2006 19:04, Gerard Beekmans escribió: > Hi all, > > I'd like to officially welcome Bryan as a new member to our editorial > team. I don't think more introductions are needed, you (should) all know > Bryan and his work by now. Welcome Bryan, having new editors with new ideas to revitalize the book development is a good thing. -- 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.info 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: Package Users Hint
El Sábado, 19 de Agosto de 2006 16:51, Chris Staub escribió:
> Note: A similar warning should be added to the ALFS webpage, saying that
> you should not even attempt ALFS until you can successfully build a
> system manually without errors and without any help from support
> channels, and that any user who does try ALFS without this prerequisite
> will not get any help from the support channels.
The next entry will be added to the jhalfs README:
---
2. PREREQUISITES::
To use this tool you MUST:
- have experience building {c,h,b}LFS packages
- know how to edit and write shell scripts
- know how a Makefile works
- be able to trace build failures and to find what is causing it
(user error, package bug, {c,h,b}LFS command bug, or jhalfs code bug)
If you don't have the above skill, please don't use this tool.
--
Looks that enought?
--
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.info
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: some things I worried about when building lfs
El Jueves, 24 de Agosto de 2006 21:03, Dan Nicholson escribió: > Do the other servers mirror off of Justin's server? How does this work? Justin update the master one, then the others mirrors are sync using rsync, like the web mirrors. -- 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.info 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: some things I worried about when building lfs
El Jueves, 24 de Agosto de 2006 20:51, Dan Nicholson escribió: > > Sorry. I made the change. However, it went in before 6.2 was released. Oh, yes. I read badly the diff. The one in the FTP mirrors is the old one. > > What's the best procedure forward on this one? The mirroring confuses me. I this case I think that Justin should to update the patch manually. -- 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.info 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: some things I worried about when building lfs
El Jueves, 24 de Agosto de 2006 20:24, Matthew Burgess escribió: > Oh dear. It was updated after the book was released but the version > number didn't get bumped, so now the md5s differ between what's in the > released book and what's on the server? That's not nice! Can someone > revert that change, then put a -2 patch up so the 6.2 book is no longer > broken when using jhalfs? Actually jhalfs isn't broken. When it noticed that the patch downloaded from the FTP mirror not match the MD5, then that patch is removed and downloaded again from lfs.org, that have the proper MD5 ;-) -- 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.info 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: some things I worried about when building lfs
El Jueves, 24 de Agosto de 2006 02:06, Martin Ereth escribió: > > 1) The md5sum (and maybe the sha1sum, too) of the grub disk geometry patch > was wrong. Maybe this is reported, yet. You downloaded it from an FTP mirror, right? The one in http://www.linuxfromscratch.org/patches/lfs/6.2/grub-0.97-disk_geometry-1.patch match the MD5 placed in the book. The diff between both is: diff -Nau mirror/grub-0.97-disk_geometry-1.patch LFS-6.2/grub-0.97-disk_geometry-1.patch --- mirror/grub-0.97-disk_geometry-1.patch 2006-08-24 19:39:16.511351456 +0200 +++ LFS-6.2/grub-0.97-disk_geometry-1.patch 2006-08-24 19:35:45.438439416 +0200 @@ -1,5 +1,5 @@ Submitted By: Jim Gifford -Date: 05-28-2008 +Date: 05-28-2006 Initial Package Version: 0.97 Upstream Status: Unknown Origin: Fedora and Mandriva The patch was updated to fix the date after the LFS-6.2 book was released, thus the book uses the old version while the FTP mirrors have the new version, but both are the same. -- 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.info 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: xLFS Book Licenses
El Martes, 22 de Agosto de 2006 06:13, Bruce Dubbs escribió: > He and Ryan are proposing the Open Publication License, > http://www.opencontent.org/openpub, for all the books. I've looked at > it and it seems to meet the standards of having a recognized license and > protecting the books. If it is the community's decision, I have no > problem with using this in BLFS. OPL looks fine to me for the textual part of the books. But as you said below, the code (both the code embedded into the books, the XSL code, extra scripts inside the SVN trees used to process the book sources, bootscripts, Udev rules, etc) should use a different license. IMHO a BSD-based one could be the best. About jhalfs, it uses GPL from the beginning and I would to change it to the same decided for book's code, If that can be done and don't will cause conflicts with the included menu and lxdialog files that are under GPL. -- 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.info 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: Dead Project? (I hope not)
El Sábado, 19 de Agosto de 2006 06:59, Randy McMurchy escribió: > Recently there was a call for funds to replace the Belgarath server. > Funds were raised in a matter of days. For all practical purposes, > anyone who contributed money, wasted it. That call for funds (and the > raising of it) was *many* months ago. There has been no effort to even > explain where the donated money went (other than someone bought some > hardware, and has it, but won't commit the couple of hours it would > take to put it online). That is a good question, where is that new server? > The entire LFS project seems to be in the toilet. Am I the only one > that thinks this? Am I over reacting? > > Is there anyone else concerned about the health of the project? In the last weeks there has been a lot of development in HLFS, but Robert is alone. CLFS team is working on the 1.0.0 release, but 1.0.0rc3 was released three weeks ago and no rc4 yet We don't know yet if there is a BLFS-6.2 release planned and for when. LFS need be updated to Glibc.2.4 and to use a new set of kernel headers, but no discussion about that yet. In the last month there has been more development discussion in alfs-discuss that in all other list. Yes, I'm concerned also :-/ -- 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.info 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: [RFC] kernel tree to /usr/src [was: Re: jhalfs and kernel tree]
El Martes, 15 de Agosto de 2006 18:37, Bryan Kadzban escribió: > Does that still break cdrtools? It used to, with an early 2.6 kernel > (2.6.1 maybe?) and possibly-old cdrtools version. That was the point > where I started putting the kernel source tree in my home directory > instead of /usr/src (and I also removed the /usr/src/linux symlink, > because no well-behaved program should be using it). I think that the cdrtools issue was due having the /usr/src/linux symlink. -- 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.info 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: Mounting Virtual Kernel File Systems
El Miércoles, 9 de Agosto de 2006 20:53, Peter Ennis escribió:
> 1. Does the mount --bind take care of this normally
> with cut and paste?
Yes, after the "mount -bind ..." $LFS/dev/{pts,shm} must exist.
> 3. Is there a reason not to explicitly create
> /dev/pts and /dev/shm under $LFS ?
Due that theoretically isn't needed.
> 4. Is this suitable for the book?
No except if you find that it is a real bug and it may be reproducible by an
editor.
--
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.info
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: Bad MD5SUM in LFS-6.2
El Miércoles, 2 de Agosto de 2006 19:14, M.Canales.es escribió: > glibc-2.3.6-inotify-1.patch does not match MD5SUMS value > NEW MD5SUM: 94f6d26ae50a0fe6285530fdbae90bbf glibc-2.3.6-inotify-1.patch > > If that can't be fixed, we have the first entry for the errata page. That has been fixed in the 6.2 branch at the same time that the updated DB fixes patch. At this moment there is no MD5SUM issues on 6.2. -- 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.info 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
Bad MD5SUM in LFS-6.2
glibc-2.3.6-inotify-1.patch does not match MD5SUMS value NEW MD5SUM: 94f6d26ae50a0fe6285530fdbae90bbf glibc-2.3.6-inotify-1.patch If that can't be fixed, we have the first entry for the errata page. -- 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.info 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: Minor pdf issue
El Miércoles, 2 de Agosto de 2006 16:19, Bruce Dubbs escribió:
>
> I was using the tools on belgarath.
>
The xsltproc command installed in belgarath is the culprit. When generating
the lfs-pdf.fo file, It is adding ", " to each {term} part of a
{varlistsntry} that is the unique member of a {variablelist} block (plus
other oddities like bad line lenght calculations and like).
libxml and libxslt should be updated in belgarath to fix that bugs.
--
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.info
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: Minor pdf issue
El Miércoles, 2 de Agosto de 2006 04:34, Bruce Dubbs escribió: > Manuel, > In checking the pdf generation log, I note warnings on pages 83, 109, > 124, and 162. In each case, the warning is in the Short Descriptions > section when there is only one entry. > > Also, in the same cases, the title, e,g, m4, has a comma appended to > the list item name. I can see that commas in the PDF that has been placed in the downloads/6.2 directory, but I can't reproduce it. See this PDF generated on my machine: http://www.macana-es.com/pruebas/LFS-BOOK-6.2.pdf Maybe is an issue with the tools versions or set-up that you are using? -- 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.info 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: r7716 - in branches/6.2/BOOK: chapter06 chapter07 chapter08
El Domingo, 30 de Julio de 2006 22:11, Bruce Dubbs escribió: > Manuel, I know why you split the lines, but AFAIK udev does not respect > the baskslash as a line continuation character. > > I am open to suggestions. Try the commands and look at the generated files ;-) -- 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.info 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: Bad MD5SUMS in LFS SVN-20060723
El Domingo, 30 de Julio de 2006 17:49, Tor Olav Stava escribió: > I got this while testing jhalfs: > > lfs-bootscripts-20060712.tar.bz2 does not match MD5SUMS value > NEW MD5SUM: a6c176e365323f23b63173adbdeb4692 > lfs-bootscripts-20060712.tar.bz2 > > udev-config-20060715.tar.bz2 does not match MD5SUMS value > NEW MD5SUM: 85a3b32be0d8c0dfb52d21239247277b udev-config-20060715.tar.bz2 That is a known issue due how that tarballs are generated now. We will try to fix it after LFS 6.2 release. -- 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.info 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: problems building 6.2
El Viernes, 28 de Julio de 2006 06:24, Bruce Dubbs escribió:
> I did this because I really don't expect the udev and bootscripts to
> change prior to final, so they are now in their "final" form. Could you
> do a quick sed in the jhalfs scripts to remove the -pre{$num} from the
> instructions?
Actually the pre2 book is "broken" due that we have this command in
chapter06/udev.html to install the LFS Udev rules:
cp -v udev-config-6.2-pre2/[0-9]* /etc/udev/rules.d/
--
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.info
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
jhalfs-1.0 Released
The jhalfs development team is pleased to announce the release of jhalfs-1.0. This new version includes support for current LFS, CLFS and HLFS books. The under development code for BLFS is included also in the tarball. Among the ability to build a system directly from the book's sources, this version has some nice additional features like: - Creation of SBU/disk usage reports - ICA/farce iterative builds - Customized build optimizations - A contributed patch that adds PACO support The jhalfs-1.0 tarball can be downloaded from http://www.linuxfromscratch.org/alfs/downloads/jhalfs/stable/ The list of supported book's versions can be found at http://wiki.linuxfromscratch.org/alfs/wiki/SupportedBooks Please, try it out and send any bugs you find in to alfs-discuss@linuxfromscratch.org Manuel Canales Esparcia jhalfs maintainer and co-author -- 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.info 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: LFS 6.2 status
El Lunes, 10 de Julio de 2006 06:39, Bruce Dubbs escribió: > Also at the suggestion of several people, I have given Dan and Tushar > full LFS commit privileges, so they can now make changes. Great. Remember that you, Dan, and Tushar must to be subscribed to lfs-book to allow that the commit logs go to the list ;-) -- 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.info 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: LFS Testers: Please use jhalfs
El Lunes, 10 de Julio de 2006 04:24, Dan Nicholson escribió: > Very quickly, here are some relevant links and locations if you want > to try jhalfs. It won't take long to get familiarized with the tools. > If you find anything you think is a bug, please report to > alfs-discuss. George and Manuel are "on the ball" as they say > (although Manuel says he'll be busy for the next few weeks). Right, I have no time until August except some hours on weekend. I will try to create jhalfs tarballs on that few free hours. -- 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.info 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: LFS Testers: Please use jhalfs
El Lunes, 10 de Julio de 2006 19:49, Bruce Dubbs escribió: > I agree with you Dan. The way to test the instructions is via a > scripted method. However, the text needs to be checked for consistency > with the instructions and that is as important as the instructions. > > When given a choice, take both. Agreed, jhalfs is great for testing and fast automatized build purposes. But jhalfs need be validated also doing build by others methods (by hand or personal scripts) and comparing the resulting logs and systems. -- 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.info 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: LFS-6.2 release manager
El Lunes, 10 de Julio de 2006 03:10, Gerard Beekmans escribió: > Hi guys, > > To get the ball rolling on this 6.2 release Bruce has stepped up to the > plate and offered to get that coordinated and I've given him the "green > light" if you will to get this done without further delays. Great, I'm anxious to see LFS-6.2 out and trunk moving-on :-) -- 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.info 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: My status on the project
El Sábado, 8 de Julio de 2006 20:21, Matthew Burgess escribió: > As such, I think my continued involvement with the LFS project is actually > hindering it more than it is helping. It is therefore with some regret I > will be resigning from both the LFS-coordinators role and my editors > position effective immediately. I hope that you will can return with us in a near future, that will mean that that personal issues has been satisfactory solved. Good luck and many thanks for the work done. -- 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.info 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: Forgot one more update to list of installed programs
El Miércoles, 7 de Junio de 2006 17:12, Chris Staub escribió: > Tried adding [ to the list for coreutils. However, this causes > validation problems with the xml. Perhaps someone knows a way to add > this without screwing up the xml code? All ID values must start with a letter, and several punctuation characters and symbols aren't allowed. Try with id="test2" and zone="ch-system-coreutils test2" -- 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: build-logs
El Sábado, 27 de Mayo de 2006 21:51, M.Canales.es escribió: > In the same way that we adding " || true " to each "make test" command, we > could try to add a redirection to a JHALFSDIR/test-logs/ directory. Done. Now testsuite logs are created into a separate $JHALFSDIR/test-logs directory. -- 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: Bootscripts merge? (Was: Summarize of Plan and changes)
El Domingo, 28 de Mayo de 2006 00:00, Matthew Burgess escribió: > Because I don't think the proposed method of dealing with the rules is > beneficial to the LFS book, relative to the current organisation. I've > already described how the books and bootscripts are handled (and it > seems most agree that the current separation works well). I don't see > why udev rules need to follow a different process than the books and > bootscripts. Facts: The CLFS team don't want to depend on the LFS team to have available the base udev-rules and bootscripts tarballs. You don't want that a separate team take care of maintain and creating full udev-rules and bootscripts tarballs containing the base one, to be used in LFS, plus any addition/changes required by CLFS or HLFS. If no one change their postures, the unification is impossible :-/ -- 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: build-logs
El Sábado, 27 de Mayo de 2006 21:20, Jeremy Huntwork escribió: > I don't really care what scripting method does it, I just liked the idea > of archiving the results of several builds. jhalfs might make this very > easy and practical. You're right that the test-results only are > required. Manuel, any thoughts? In the same way that we adding " || true " to each "make test" command, we could try to add a redirection to a JHALFSDIR/test-logs/ directory. -- 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: Proposal: new requirements for referenced translations
El Sábado, 27 de Mayo de 2006 13:13, Randy McMurchy escribió:
>
> You may want to see if the sgmldiff program from docutils can help.
> It may work with XML just fine. And if so, it sounds like it may
> help.
That type of tools help comparing XML trees, but not CDATA.
CDATA (the actual output text) will be different in translated books, except
for the ones inside {screen}{userinput} blocks and the
{packages,patches}.ent files, that must be identical.
To compare {packages,patches}.ent is easy, but to have a clean diff of
{screen}{userinput} blocks some way of stracting that info from the book is
needed. We could to use the ugly and unmantained dump-commands.xsl stylesheet
supplied with the book sources (plus diffing packages.ent, due that packages
versions aren't resolved by that) , to develop a new approach, to see if same
translators-helper program can do the work (I don't use they, then I don't
know), or to use jhalfs.
--
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: Proposal: new requirements for referenced translations
El Sábado, 27 de Mayo de 2006 06:18, Alexander E. Patrakov escribió: > 1) The translation must be done with the same DocBook XML tools as the > English book, and a link to the DocBook source must be provided > > 2) The translation should be compatible with jhalfs, and the non-obvious > differences in produced Makefiles, if any, should be explained in XML > comments, in English, so that the original LFS editors can read them. Actually, running jhalfs on both the original book and the translated book and diffing the output is the best way to be sure that the commands and packages/patches versions in both books are identical. And that implies that the sources of translated books must be in the same format and layout than the original book. > 3) The comments in example files (such as /etc/fstab) must not be > translated Saying that all translations whose jhalfs output differs from the official output (except for TIMEZONE and LANG environment settings, that can differs also from one user to another running jhalfs on the official book) will be rejected should to cover that also. > Is this proposal acceptable? Fine by me. I will adapt the Spanish SVN translation to that policies in the next update. -- 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: Summarize of Plan and changes - was Re: Unifying the Udev Rules Packages
El Martes, 23 de Mayo de 2006 22:41, Jim Gifford escribió: > Is this acceptable to all. Seem fine to me. -- 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: Unifying the Udev Rules Packages - My final post on this matter
El Martes, 23 de Mayo de 2006 19:24, Matthew Burgess escribió: > And as much as you say you want a joint effort, you're unprepared to > drop your package in favour of the one that LFS is using without any > technical justification, merely saying "we had a tarball first". IMHO, the best solution is to drop both and create a separate Udev-Rules project managed by a neutral developer. -- 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: removing old branches
El Sábado, 13 de Mayo de 2006 01:08, Jeremy Huntwork escribió: > Seems to me that the only one that needs to stay (maybe) is LFS-RNG. The > rest have either been merged or abandoned. Cab be removed. It is very out-of-date and the move-on to DocBook-5.0 depend on upstream developing XSL-2.0 based stylesheets and functional validators and processors. IMHO, not before one year from now. -- 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: Getting 6.2 ready for testing
El Lunes, 8 de Mayo de 2006 02:30, Archaic escribió: > Yes. And due to Ken's convincing emails, 2.6 will be updated possibly > right up to the day the book is released. 2.6.16.X, I suppose that you meant. -- 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: What's Going on
El Jueves, 4 de Mayo de 2006 23:29, Jim Gifford escribió:
> The biggest problem I've had about the md5sums in ALFS is that they are
> ones we have created. We shouldn't be recreating them, but using the
> author's version. I know we have repackages items so they are .bz2, but
> that's not keeping a clean chain. That's my objection. If we are not
> going to provide the original author's sums, then we are no better than
> a distro.
All packages in the FTP mirrors are now in that formats used upstreams.
Justin do that change for BLFS packages several weeks ago, and for {C,H}LFS
packages this weekend.
Thus your complaints is not valid now, if we place the MD5SUMS into the books
they will match that packages released by their developers.
--
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: What's Going on
El Jueves, 4 de Mayo de 2006 02:42, Archaic escribió:
> jhalfs was discussed in dozens of threads a long time ago. What you are
> arguing against is a method to test the book directly from it's XML.
And that was one of the goals listed in the specifications when the work on
the newxml format was discussed three years ago ;-)
> That is extremely powerful. And if it is the MD5s you don't like, I
> cannot understand that, either. It is common (and recommended) practice
> to verify checksums. I would hope before any md5 is added to the book
> that the dev who is adding it has checked it against the upstream
> checksum file (if it exists). But many upstream packages don't have
> md5's. For that reason alone, I think the book should have them. The
> rest are for convenience.
I must to add that that the MD5SUMS discussion are jump now due jhalfs, but
actually it is a technical and editorial issue.
BLFS has proved that to include direct download links plus the MD5SUM for each
package is a good thing for our final readers/users. LFS book was the last
one to include direct downloads links. I think that now is the time for
{C,H}LFS books to start including also the MD5SUMS.
--
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: Finalizing the sanity checks
El Martes, 2 de Mayo de 2006 02:01, Jeremy Huntwork escribió: > Also, here's an svn diff of the source files so you can see what I did > with the XIncludes. Manuel is this good enough, or do you have a better > idea? > > http://linuxfromscratch.org/~jhuntwork/sanity-checks.diff The method used is not very elegant. That dummy sect2 are hugly in both the XML and the HTML output code (the output look is good). I think that will be best to use a similar method that the one used in CLFS. That will allow us to insert/remove paras or screens without having to modify the Xincludes already sets. -- 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: Measuring disk usage and build time.
El Lunes, 1 de Mayo de 2006 22:53, Archaic escribió: > Yes, and something that will be greatly helped along by jhalfs, but > going back in memory to previous SBU threads, I believe it was decided > that SMP machines would be quite skewed. Hyprethreading acts like SMP > (to what extent I'm not sure) so I think UNI systems should be used to > verify Manuel's results before his times are added. Manuel is the SBU > and sizing stuff done in jhalfs (sorry, I don't have time to follow > development). I have several UNI systems I can set to build while > sleeping. More results from others is always good, too. Yes, jhalfs creates very good reports for SBU and disk usage. And I was not updating the values due my HT CPU ;-) -- 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: Missing patch
El Lunes, 1 de Mayo de 2006 22:48, Archaic escribió: > The patch is in the repo, but doesn't get copied over until the book > re-renders. Oh, right. jhalfs is trying to download it from http://www.linuxfromscratch.org/patches/lfs/development, of course. -- 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
