Re: Package dependency updates
El Domingo, 23 de Septiembre de 2007 08:03, Chris Staub escribió: I just double-checked dependencies for a number of packages and have attached a patch with some corrections...in some cases accounting for changes due to newer package versions, and in others fixing mistakes in the existing deps. list. This includes updates for Bash, Grep, Gzip, M4, and Tar. Applied, many thanks :-) -- 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: Updates to the book
El Miércoles, 12 de Septiembre de 2007 19:33, Chris Staub escribió: Attached should be a patch to add ncurses5-config to the Ncurses program list, and several grammar/spelling fixes. Applied on r8385, thanks :-) -- 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: Merging the jh branch to trunk
El Viernes, 7 de Septiembre de 2007 21:18, Matthew Burgess escribió: Full patch series is now at http://www.linuxfromscratch.org/~matthew/patches/ (see the series file there for the order they need to be applied in). Is there some timeline about when that patches will be applied to trunk? I would prefer to implement the screen attributes addition after that patches has been applied, to not break they and to make more easy the addition merge into the jh branch. -- 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: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 08:43, Alexander E. Patrakov escribió: The question is how they manage to continue building packages with documentation successfully when DocBook XSL is upgraded. For the gimp-help-2 package, the answer is that the current version of stylesheets is used by default, instead of the explicit number. If you know a package that doesn't use the current version, tell me its name, and I will look how Debian deals with this situation. The current version remap is a catch-all for stock DB documents that don't need to worry about the output tagging and look and are happy with the defaults. They are not using customized XSL nor CSS layouts and are agnostics about what DB-XSL version is used to generate the docs. That is the normal approach used for DB documentation included in packages and by the API documentation generated by Doxygen. That allow graphical help systems, like Gnome or KDE help interfaces, to display the documentation pages with the same look for all packages via help browser embedded CSS code. Due changes on DB-XSL output code from version to version the look my differ from docs generated with one DB-XSL version to another if that CSS code is not adjusted, but that is not an issue for distros due that normally they use the same DB-XSL version for all packages (and its upgrades) across a stable distro version. On the other side, technical documentation that need a customized tagging look on HTML and/or PDF output (i,e,. on-line documentation that should follow the look of the web site or books destined to commercial printing) relies on XSL/CSS customizations to can generate it. That approach depend on the use of a well-known base DB-XSL version, thus the current version can't be used in such cases. -- 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: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 15:04, Alexander E. Patrakov escribió: OK. Now imagine the following situation: someone wants to create a Debian package with the LFS book. Debian policy requires that all HTML and PDF files are rebuilt from XML source in this case. If the LFS book relies on the external DocBook XSL setup of a certain version, I see no way to do it, except by reverting the switch to the external copy of DocBook XSL stylesheets (which is as bad as any other reversion of upstream changes) or changing the stylesheet version to current (which is going to break PDF - even worse). I don't see here an issue for us, but for distro packages creators. In any distro, when package A depend on version X of package B where X is not the default version for B on the target distro release version, then a package B-X that can be installed side-by-side without conflicts with the default package B is created. That has been true from always for autotools packages, back-ward compatibility libraries, libstdc++ versions needed to run closed binaries, etc. Why should it be diferent when related about DB-XSL versions? -- 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: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 15:04, Alexander E. Patrakov escribió: The problem is that old versions of DocBook XSL are simply not available as Debian packages, so one cannot build-depend on them without immediately getting a release-critical bug report. Forgot to mention. That's a distro policy fault. DocBook XML DTDs or DocBook XSL styleshets versions are not exclusives. All available versions can be installed on a system without conflicts and should be availables if some source document request them. -- 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: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 15:48, Alexander E. Patrakov escribió: Yes, an issue for distro package creators, but caused by LFS upstream not willing to cooperate :) Hu? What most cooperation is needed apart from saying on what external packages version our sources depends on? If someone what create, for example, a LFS-6.2 package for Debian Lenny, it know that must create also a DocBook-XSL-1.69.1 package, and maybe a current or patched tidy package, if not availables upstream. -- 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: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 16:09, Alexander E. Patrakov escribió: Would you mind if I report this to Debian as a bug, and CC: you so that you get a chance to answer the replies? If you ask about creating sepparate DB-XSL packages for each available version, and no other Debian package depends on a specific DB-XSL version, I think that the bug might be refused as WONTFIX saying that if you need a concret DB-XSL version you can create your own tarball or install it in your home dir. But if you ask about including into the Lenny release packages for LFS-6.2 and/or BLFS-6.2 (not LFS-6.3), if that inclusion is accepted then they will be forced to create also a DocBook-XSL-1.69.1 package. -- 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: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 16:30, Alexander E. Patrakov escribió: Make it easy to use a just-downloaded private copy of the correct version of the stylesheets. That is already done. You can place the stylesheets anywhere, just update the XML catalogs to point to that path when that version is requested. If you have no permissions to edit /etc/xml/catalog, you can create your own ~/xml/catalog and use it adding to your env XML_CATALOG_FILES=~/xml/catalog -- 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: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 17:06, Dan Nicholson escribió: FYI, this is a property of xsltproc(1), and not something native to LFS. Actually, it's an standard. All XML parsers should honour XML_CATALOG_FILES, the same that all SGML parsers should honour SGML_CATALOG_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: r7105 - in trunk/BOOK/stylesheets/lfs-xsl/docbook-xsl-snapshot
El Lunes, 10 de Septiembre de 2007 06:10, Randy McMurchy escribió: I'm wondering if we shouldn't go back to using stock stylesheet versions installed locally, and not a version included with the sources? Looks like DB-XSL-1.73.2 is good enough to be used as the default base XSL code for the next months (maybe the next upgrade will be to DB-5 + DB-XSL-NS-1.74.1, but that is another beast), that is wy I updated the code to that release instead to the most current snapshot code. About going again to system-side installed DB-XSL version, is a matter to update the version and instrucctions in the BLFS page, and to install DB-XSL-1.73.2 on all servers that are rendering *LFS books, i.e., quantum, andiun, and the CLFS servers. CC to lfs-dev and clfs-dev to let editor and servers admins opine about this. -- 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: [Clfs-dev] r7105
El Lunes, 10 de Septiembre de 2007 19:26, Dan Nicholson escribió: That would be the drawback to this approach. If we do go back to using the host's stylesheets, then it should be completely clear in the sources (or somewhere else) what version is expected. Possibly we can check and enforce this in the Makefile. The expected version is defined on the xsl:import statements placed on the top level stylesheets/ files (see the LFS-6.2 stylesheets for an example), and a sane system must not remap an explicit DB-XSL version to a different one via XML catalogs (that is fine for compatible DTDs releases, but never for XSL versions), thus that should not be an issue. -- 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: Merging the jh branch to trunk
El Sábado, 8 de Septiembre de 2007 12:26, Matthew Burgess escribió: Thanks Jeremy, that was exactly the problem. I've uploaded the updated gcc.patch file. I just removed the '^' so the sed only matches what current trunk matches, rather than the ld-uClibc.so.0 entry as well which your '/lib/ld/@' version would. On the gcc.patch file, into the chunk chapter05/gcc-pass2.xml, in the sed and surroinding text that replaces the gcc-specs-patch there is references to linux64.h, /lib64/ld, and /lib32/ld. Don't should that references be left-out until x86_64 support merge? -- 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: [PATCH] Add package info in sect1info elements
El Sábado, 21 de Julio de 2007 01:10, Dan Nicholson escribió: I've been playing around with jhalfs and I realized that there was no easy way to access the package name and version on a given page. Manuel and I had a discussion on alfs-discuss and he suggested using the productname and productnumber children of the sect1info elements. This one has been applied in r8366 with two changes: - In productname the actual package name is used, instead off adding tools- to chapter05 pages and -headers to the linux headers installation. At this moment jhalfs is finding the package name via several hacks that could be avoided now. That name extensions can be re-generated from inside the jhalfs code and placed on a separate variable, if required to help creating customizations for PM. - An address tag has been added containing the package URL entity. From it we will can extract more easily the tarball name, removing more hacks, and could allow to extract the tarballs from inside the scripts instead than from the Makefile like 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.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: [PATCH] Add screen install attributes for final system packages
El Sábado, 21 de Julio de 2007 01:42, Dan Nicholson escribió: Another jhalfs helper. As has been discussed before, it would be nice to mark the screen sections with an attribute to announce that it will be installing to the system rather than just working in the source/build tree. Manuel suggested adding the attribute userlevel=install, so I've done that for the Ch. 6 packages and the kernel in Ch. 8. Now that LFS-6.3 has been released and we are just openning a new 7.0 milestone, I think that is the best momment to implement that XML additions, if they are accepted. For reference, the propossals was made on this posts: http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059682.html http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059687.html If there is no objetions about that additions, I will commit the changes this weekend. Comments, 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: Released jhalfs-2.3.1
El Viernes, 31 de Agosto de 2007 15:27, sacarde escribió: Alle venerdì 31 agosto 2007, sacarde ha scritto: can you suggest me a way to re-initialize jhalfs in blfs step after a building stop in previus release ? Please, use the alfs-discuss list for that typo of questions, thanks. -- 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: LFS 6.3 stealth update complete
El Jueves, 30 de Agosto de 2007 06:33, Bruce Dubbs escribió: I updated all the 6.3 files on the server so the md5sums in the book now match the md5sums of the files. No filenames were changed. Great, now all packages are downloaded without issues :-) Many thanks. -- 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: Summary: Debian Lenny as host
El Jueves, 30 de Agosto de 2007 19:08, Jeremy Huntwork escribió: Because of that, I'm inclined to let the matter rest, at least for now. The current build method works for every default setup I've tested so far - I think that is good enough. At least until we encounter some more information. I agree, at least as a starting point for 7.0 milestone. Some plans to start merging jh branch into trunk? On a related topic, have you tried to build the jh branch using jhalfs? I has not time yet to try it and I'm not sure if it might work without some fixes on the jhalfs code. -- 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.3.1
The jhalfs development team is pleased to announce the release of jhalfs-2.3.1. This is a bugs-fixes release to match LFS-6.3 and current BLFS development book. If you are using jhalfs-2.3, please upgrade to jhalfs-2.3.1. The jhalfs-2.3.1 tarball can be downloaded from http://www.linuxfromscratch.org/alfs/downloads/jhalfs/stable/jhalfs-2.3.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/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Test logs for 6.3
El Jueves, 30 de Agosto de 2007 19:12, Dan Nicholson escribió: Which reminds me. Manuel, can you add man-db to the MAKEFLAGS blacklist for jhalfs? 2.4.4 fails pretty consistently for me on -j3. Was added several days ago, when it start failing also to me ;-) It's on the just-released 2.3.1 version. -- 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: Test logs for 6.3
El Miércoles, 29 de Agosto de 2007 19:15, Dan Nicholson escribió: Thanks. I created the directory, and you should have write privs. http://www.linuxfromscratch.org/lfs/build-logs/6.3/ Please create a directory for your system with a 00-README file describing it like here: http://www.linuxfromscratch.org/lfs/build-logs/6.2/Athlon64-3200+/ Done, published the logs from two machines. The Petium4 one have full chapter06 testsuites, the AMD64 one have both chapter05 and chapter06 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: Test logs for 6.3
El Martes, 28 de Agosto de 2007 23:53, Dan Nicholson escribió: If anyone has clean test/build logs to contribute for the 6.3 book, please tar them up and post them with a hardware description. Preferably Ch. 5 and Ch. 6, but just Ch. 6 will do. They will eventually go here: http://www.linuxfromscratch.org/lfs/build-logs/ I have logs for the Ch. 6 tests form a Core Duo laptop. These were generated from jhalfs, which makes it really easy if anyone is interested in helping out. I'll be uploading them later today some time. Starting now some builds to verify that jhalfs-2.3.1 can be released. When done I will upload the resulting logs. -- 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
Wrong MD5SUM values in LFS-6.3
Hi, jhalfs has reported this when trying to build LFS-6.3: lfs-bootscripts-6.3.tar.bz2 does not match MD5SUMS value NEW MD5SUM: 4898129064e2edf93d52c9def3053ae1 lfs-bootscripts-6.3.tar.bz2 udev-config-6.3.tar.bz2 does not match MD5SUMS value NEW MD5SUM: 154bb3fd0aa36506ffa57e88cc08910d udev-config-6.3.tar.bz2 Both packages has been downloaded from http://www.linuxfromscratch.org/lfs/downloads/6.3/ That MD5SUM discrepancies need be verifyed and fixed on the XML sources to can release both jhalfs-2.3.1 and the LFS LiveCD. An entry on the errata page don't solve the issue. -- 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: Wrong MD5SUM values in LFS-6.3
El Miércoles, 29 de Agosto de 2007 20:20, Bruce Dubbs escribió: OK, I copied the config files from development to 6.3 and renamed appropriately. The md5sums match what is in the book. That should fix the jhalfs problem. Thanks. I will test that the new files are properly downloaded and verified when the first machine finished doing it current LFS 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: stray references
El Lunes, 27 de Agosto de 2007 14:17, [EMAIL PROTECTED] escribió: SVN-20070820 When I compiled PCRE, and others, butterfly-build appears in the compiler output and harmful or not, that is unclean and unacceptable. On a LFS or CLFS-based system, both current and old versions, there is a lot of references to /sources/gcc-build. That is due /usr/lib/libstdc++.la and /usr/lib/libsupc++.la contains: # Libraries that this one depends upon. dependency_libs=' -L/sources/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src -L/sources/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -lm -lm -lm -L/sources/gcc-build/gcc -lgcc_s -lc -lgcc_s -lm -lgcc_s -lc -lgcc_s' /usr/lib/libbfd.la contains also references to /sources/binutils-build Rebuilding GCC and Binutils don't solve that, the sources build directory is always referenced on its .la files. Thus, I see three possible solutions: - To patch GCC and Binutils to not include references to the build tree and to remove all that diplicated -lgcc_s -lm - To edit manually that .la files. - To not install GCC and Binutils .la files, like most distros do. -- 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: stray references
El Lunes, 27 de Agosto de 2007 19:46, M.Canales.es escribió: Actually, the solution for the book is do nothing, IMHO. That references to the GCC and Binutils build trees has been on all *LFS-based systems from years ago without known 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/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Additional wget-list renders
El Lunes, 20 de Agosto de 2007 07:25, Justin Robert Knierim escribió: For the ftp repos, I make heavy use of the wget scripts. Some are already rendered with the book, such as: http://www.linuxfromscratch.org/lfs/view/development/wget-list If it isn't too much trouble, could this be added for blfs and hlfs as well? The command is the same, make wget-list with whatever BASEDIR you need. If it is too much a pain, I can keep rendering them manually on quandary (my server) instead. Updated the Makefile for both, HLFS and BLFS. If the server is using that Makefile to render the books (I think so), its wget-list files should be available on-line at the next render. -- 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: An idea for a new development model
El Miércoles, 15 de Agosto de 2007 15:07, Jeremy Huntwork escribió: I'm not going to push to get this into LFS. If the vast majority of those with a voice here are for PM in LFS, great. If not, great. :) The question are: What changes would be needed to let *LFS books be PM-aware? Without forcing the use of an specific PM implementation, of course. Would that changes have some impact on that of us (read users) that don't want/need to use a PM? As least to me, if_something_work_as_needed==don't_upgrade, small-upgrade==reinstall_on_top, big_upgrade==build_a_ new_system. And lastly, like Rady said, the master goal of the LFS project is to provide educational books about how to build a Linux system. If PM support is added, who will writte the text explaining how to set-up and use a PM? Understandable. Of course, it could be argued that part of what makes a Linux system is package management. It is after all part of the LSB. LSB dictates that RPM must be available, but it don't tell that RPM must be used. -- 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: Gnome-Python
El Lunes, 13 de Agosto de 2007 00:34, Randy McMurchy escribió: Would you recommend that we split this up a bit? Don't should be needed. What is needed is to create a sub-routine to parse Dbus-Bindings and Python-Modules on a different way, like was done for Xorg7. I will try to have it done before BLFS-6.3 release. Perl-Modules is not an issue due that almost all its dependencies are also Perl modules. Im wide open to suggestions or ideas that can help. Though (as I've heard Manuel mention before) I'm not certain we'll ever be able to fully automate BLFS due to the myriad of possibilities each package may have, if there are things that can help, please let us know. Yes, full automatization is impossible, not only due peculiarities on some BLFS pages, but also due that in a lot of packages the build commands need be adjusted based on what dependencies are installed and/or should be used. Plus, we should try to keep the XML structure the most simple possible to not do more hard the editor's work, IMHO. The current XML structure was not designed thinking on automate builds. That requires rigid XML trees with several hocks to can diferentiate each commad type (pre-configuration, patches, seds, configure, binaries build, documentation build, testsuites, binaries install, documentation install, post-configuration, etc...) and a more fine-grained optional dependencies (to add extra features, to allow testsuites run, to build documentation, etc...). A lot of changes and more work for the editors, but at the end the users will need yet to read carefully the book, to decide what internal and external dependencies he want, to review the scripts, and to decide what need be changed to build the package as he want. No, thanks. I someone want a full-automated from sources build, he can use Gentoo and like. Nevertheless, small not-intrusive changes like the ones propossed by Dan for LFS can be evaluated, if all you think that could be beneficial for both the editors, the book users, and jhalfs users. -- 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: LFS-6.3-rc2 has been generated
El Lunes, 13 de Agosto de 2007 19:32, Dan Nicholson escribió: Yeah, that site is gone. In BLFS we're using this: http://cross-lfs.org/files/packages/svn/shadow-4.0.18.1.tar.bz2 There are plenty of places we can put it on one of the LFS servers. downloads.linuxfromscratch.org seems like as good a place as any. Let's see what the other editors say. Why not to use one of the FTP mirrors URL's? For example the one used by jhalfs: ftp://ftp.lfs-matrix.net/pub/lfs/conglomeration/shadow/shadow-4.0.18.1.tar.bz2 -- 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: Is 6.3 ready for release?
El Miércoles, 1 de Agosto de 2007 19:43, Jeremy Huntwork escribió: I suppose that's argument for producing a separate set of text for 64-bit. Not, if creating sepparate books I refuse to have separate diskusage/buildtime blocks and entities sets for each arch. On CLFS and HLFS that info was removed due the big amount of work involved on maintain the XML code and in keeping that values more or less accurates for each book. If we are happy with big figures, thus use the same values for all archs, If we want something accurate for each arch, remove the info from the book a create a web page to place jhalfs reports. -- 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: udev-config 20070731
El Martes, 31 de Julio de 2007 16:07, Dan Nicholson escribió: http://downloads.linuxfromscratch.org/udev-config-20070731.tar.bz2 I think that the book URLs to download both lfs-bootscripts and udev-config should be changed to use http://downloads.linuxfromscratch.org. It's neutral and should work for all books. Right now in both 6.3-rc1 and 6.3 branch that URL are hardcoded in packages.ent to http://www.linuxfromscratch.org/lfs/downloads/development/, that is not kosher. -- 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: Is 6.3 ready for release?
El Lunes, 30 de Julio de 2007 20:02, Bruce Dubbs escribió: I put out a 6.3-rc1 a week ago and there really has been very little feedback. Is it ready for final release? I think so, but fixing before the missing consolelog bootscript description in chapter07/bootscripts.xml. I have done a lot of builds this days with no issues. If some bug is found later we always could do a 6.3.1 release. Plus, I would start today with the preparative to can merge the x86_64 branch into trunk. -- 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: Is 6.3 ready for release?
El Lunes, 30 de Julio de 2007 21:26, Jeremy Huntwork escribió: I've been thinking about this some more recently. I really think it's not worth the time and effort (at least not now) to add the extra complexity to the XML/XSL to render two separate books for x86 LFS and x86_64 LFS. The command changes are so minimal that in the end, there would be very few differences at all. Just for the sake of review and to show how I would resolve the differences in one book, here's what we would need to change: Yes, the differences between a x86 build and a pure 64 libs x86_64 build are minimal. The question is, we will add only pure 64 libs x86_64? or is that a mean of POC before adding also instructions to build multilib x86_64 systems? IMHO, multilib build instructions will be very intrussive due that several packages need be builded two times. If we want to add it, we will need to render sepparate books to not mess the reader with a lot of if . Thus I think that if multilib support will be added, is best to have ready the profiling and rendering framework now that the changes are minimal, to let editors familiarice with the new XML tagging. 6) Bootloader. This one is probably the biggest. Legacy grub is probably still preferable for x86. I see 3 options here: a. Convert to lilo for both (dependency on bin86 which requires a patch for x86_64) b. Convert to grub2 for both (untested by me, but I believe it works for both. Joe Ciccone has more info.) c. Tell users to install grub via their host system. (Most have it these days. Wouldn't work for the 64-bit only LiveCD as of now.) d. Move bootloader compilation to Chapter 8 Making the LFS System Bootable discussing available alternatives (Grub, Grub2, LiLo, the host bootloader, a boot CD, etc...) -- 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.3
The jhalfs development team is pleased to announce the release of jhalfs-2.3. New features in this version: - Many code updates to follow current SVN books - Generation of installed files logs. - Added an option to stop the build at a desired point - Several bugs fixes, code clean-up and documentation updates. The jhalfs-2.3 tarball can be downloaded from http://www.linuxfromscratch.org/alfs/downloads/jhalfs/stable/jhalfs-2.3.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: Anduin Package Repo
El Viernes, 27 de Julio de 2007 02:01, Randy McMurchy escribió: Hi all, Best as I can tell, the Anduin package repository hasn't been updated for well over a month. There's probably been more than 100 package updates since then. I know Justin is busy these days, so should we just forget this idea of having a repo? Ask Justin. IMHO, having the ftp repo up to date for when BLFS-6.3 will be released could be enought. Seems Justin and Manuel worked out some sort of automation to make the repo update easier, but I guess it didn't get put into place. Yes, there is the wget-list Makefile target to extract all packages patches download URLs. -- 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: New BLFS Editor
El Viernes, 27 de Julio de 2007 17:36, Randy McMurchy escribió: Hi all, It is my pleasure to announce that Ag Hatzimanikas has accepted a position as a BLFS Editor. Ag brings a long time affiliation with the (x)LFS projects (and a great passion towards the projects), a great amount of Linux experience, and very good i18n knowledge to the project. Welcome, Hag. Is nice to see a new editor on BLFS :-) -- 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: gcc make check
El Jueves, 26 de Julio de 2007 18:28, Dan Nicholson escribió: IIRC, the last time I ran the 4.1.2 testsuite, I also had no failures. That wasn't during a bootstrap, though. Oh, I don't remember what happened with mudflap. Manuel, do you still have the test logs from the LFS jhalfs run you did the other day? On the Pentium-IV machin I have no current testsuites logs right now. On the AMD64 machine I have the logs for a normal build, a 3-iterations build and a build using MAKEFLAGS=-j3. On all of them the results are identical: LAST_UPDATED: Obtained from SVN: tags/gcc_4_1_2_release revision 121944 Native configuration is i686-pc-linux-gnu === g++ tests === Running target unix XPASS: g++.dg/tree-ssa/pr14814.C scan-tree-dump-times this 0 XPASS: g++.old-deja/g++.other/init5.C execution test === g++ Summary === # of expected passes 12408 # of unexpected successes 2 # of expected failures 66 # of unsupported tests 69 /sources/gcc-build/gcc/testsuite/g++/../../g++ version 4.1.2 === gcc tests === Running target unix XPASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file (^|n)cmdlne-dI-M.*: [^n]*cmdlne-dI-M.c XPASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file (^|n)cmdlne-dM-M[^n]*: [^n]*cmdlne-dM-M.c === gcc Summary === # of expected passes 38985 # of unexpected successes 2 # of expected failures 99 # of untested testcases 28 # of unsupported tests 246 /sources/gcc-build/gcc/xgcc version 4.1.2 === libmudflap tests === Running target unix === libmudflap Summary === # of expected passes 1799 === libstdc++ tests === Running target unix XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) === libstdc++ Summary === # of expected passes 3398 # of unexpected successes 1 # of expected failures 12 # of unsupported tests 324 The unique diference with Bruce's result are the 2 unexpected successes in gcc. -- 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: x86_64 build method
El Miércoles, 25 de Julio de 2007 19:10, Jeremy Huntwork escribió: Manuel, I'm slowly beginning to understand how the HLFS render 'magic' works. One question: would the 'condition' For LFS we should use the arch= attribute. It's more semantically correct. parameter be usable in an ENTITY declaration? If it is, the differences between the books could be even more minimal as we can set an entity for the target triplet and dynamic linker based on the arch we are building. I'm not sure what do you meant, but entities are resolved while loading the XMLs in memory and before processing the they with XSL, thus I don't see how could we say to xmllint/xsltproc that they must use one set of entities or the other at sources load time. -- 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: x86_64 build method
El Martes, 24 de Julio de 2007 17:59, Jeremy Huntwork escribió: My biggest problem with this approach is that it gets to be a nightmare to edit. But, it is do-able. See how HLFS manages the Glibc/uClibc - Linux-2.4/2.6 books flavours and ask Robert if it hard to maintain. Four sepparte books are generated from one common sources tree. CLFS uses a diferent, more complex, method due that 12 book need be generated. But also, there is only one common sources tree. I prefer to use the HLFS-way for x86_64 integration. -- 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: [PATCH] Add screen install attributes for final system packages
El Sábado, 21 de Julio de 2007 01:42, Dan Nicholson escribió: Another jhalfs helper. As has been discussed before, it would be nice to mark the screen sections with an attribute to announce that it will be installing to the system rather than just working in the source/build tree. Manuel suggested adding the attribute userlevel=install, so I've done that for the Ch. 6 packages and the kernel in Ch. 8. IMHO, both this and the sect1info patch are good additions for the 7.x milestone. But I think also that could be better to apply they after the final 6.3 release to can do more easy merges from/to the 6.3 branch to/from trunk. -- 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: x86_64 build method
El Martes, 24 de Julio de 2007 19:51, Dan Nicholson escribió: Out of curiosity, will the Relax NG XML ease in generating multiple books from a common source? Not, what Relax-NG make more easy is to customize the schema declaration. I.e, to add new tags or attributes (placed on a diferent namespace) to the default DocBook-XML set while allowing separate or combined schemas validation. For example, in the old times when the migration to XML/XSLT was initiated, one of the cool new features discussed was that we would be able to change the book screen blocks to nALFS sintax. That has no sense right now, 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.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: x86_64 build method
El Martes, 24 de Julio de 2007 20:12, Jeremy Huntwork escribió: M.Canales.es wrote: I prefer to use the HLFS-way for x86_64 integration. Well, you obviously know that setup better than I do. If you could help me set that up, I'd appreciate it. I have many fronts open right now, with priority on doing the jhalfs-2.3 release. Could you continue using the x86_64 branch for now until jhalfs-2.3 will be released? I think that at the weekend I will can start mergin the x86_64 changes into trunk. For a full set-up a new top-level index.html file must be created and the Makefile need be modified to support multiple books 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: Plans for LFS-6.3
El Lunes, 23 de Julio de 2007 20:49, Dan Nicholson escribió: That doesn't say too much. OK, looking at postix/test-vfork3.c, I think I see the issue. At that point it does 'unsetenv (PATH);' and then tries to execute echo. For this to work, we need to have echo in /bin, which we don't at that point. If /bin/echo - /tools/bin/echo is added to the Essential Symlinks, I bet it will pass. Can you give that a try? Yes, it passes, included using -j3 ;-) -- 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: Plans for LFS-6.3
El Jueves, 19 de Julio de 2007 00:13, Matthew Burgess escribió:
I did a full final system testsuite run with the latest package updates
(including a repackaged version of the latest iproute2 package). No
failures there. I've not done an ICA/farce build though, so that would
certainly be useful.
ICA/farce reports that the next files differ on iteration1Viteration2 but not
in iteration2Viteration3:
/etc/ld.so.cache
/usr/include/c++/4.1.2/i686-pc-linux-gnu/bits/stdc++.h.gch/0{0,2}g.gch
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/cc1
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/cc1plus
The cc1{,plus} differ was reported some time ago, but the issue was not
resoled:
http://linuxfromscratch.org/pipermail/lfs-dev/2007-February/059028.html
The build has been done on a new AMD64 machine using Ubuntu-6.06.1 (linux
2.6.15-28-k7 SMP PREEMPT) as host.
Glibc testsuite sow this errors in iteration1:
posix/tst-vfork3.out
nptl/tst-cancell.out
but iteration{2,3} show only:
nptl/tst-cancell.out
Binutils and GCC testsuites are identical on all iterations.
--
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: Plans for LFS-6.3
El Domingo, 22 de Julio de 2007 20:15, Dan Nicholson escribió: Do you still have the output from tst-vfork3? Do you meant the log output on the posix/tst-vfork3.out file? If the later, I will need to do a new build but stopping it before Glibc sources and build directory deletion. -- 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: Refactor newlines in dump-commands XSL
El Viernes, 20 de Julio de 2007 02:08, Dan Nicholson escribió: Manuel, I was playing with the dump-commands output and saw a couple things that I thought could be cleaned up. First, I think it's nicer to create a global variable for newlines instead of always using the entity directly. Second, there were an excessive number of newlines in the output. Now, there is just an extra newline at the end of each screen block. What do you think? Looks good to me. Actually, when updating to the new XSL code, I was tempted to remove dump-commads.xsl in favour of jhalfs generated scripts, but keeped due that is more fast and their output is more raw. -- 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: Refactor newlines in dump-commands XSL
El Viernes, 20 de Julio de 2007 19:22, Dan Nicholson escribió: OK, I'm going to commit that. Do you mind if I use a similar variable in jhalfs/LFS/lfs.xsl? If you have commits right to the ALFS repo, fell free to do the changes. I'm very busy now trying to install some usable host system with full hardware support for my new AMD64 machine. -- 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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
El Viernes, 20 de Julio de 2007 22:29, George Boudreau escribió: Should we add lfs-x86_64 to to jhalfs now or wait a few weeks/months? I assume there will be a multi-lib version after all objections/ideas have been aired. (planning ahead for jhalfs) Depends on how the changes are applied in the branch. If the branch will contains only x86_64 pure64 libs commands for now (i.e. replacing the needed x86 trunk commands by the ones for pure64), current jhalfs should work fine. If we start merging directly the new pure64 command/packages with the current x86 ones using XSL profiles to generate separate books, then jhalfs will need be updated to can handle such profiles in a similar way than HLFS do. -- 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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
El Viernes, 20 de Julio de 2007 22:54, Jeremy Huntwork escribió: Indeed. I meant to drop something in, but forgot about it. bin86/lilo would probably be alright. Anyone tried grub2? IMHO, for now lilo should be used due that the build commands could be copied from CLFS. For the future, see Alexander comment on http://wiki.linuxfromscratch.org/lfs/ticket/1955 -- 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: Plans for LFS-6.3
El Miércoles, 18 de Julio de 2007 02:49, Bruce Dubbs escribió: What do you want for a target release date? I would think we could get a -rc1 out in a week if we don't make any changes to the tool chain. Looks good. I will start some ICA/farce and full-testsuites 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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20070706: Step 5.7 Adjusting the Toolchain
El Sábado, 14 de Julio de 2007 01:26, Dan Nicholson escribió: I would actually really like to add x86_64 (non-multilib to start) support to LFS and BLFS. It's becoming increasingly uncommon to even be able to purchase a non-64bit processor at this point. We can basically copy what Greg's done on DIY (which is where I go looking for native toolchain stuff anyway), and maybe we could use Manuel's XSLfoo to not have a whole bunch of $ARCH conditionals. That's what I think, anyway. When was proposed to convert the cross-build branch into a separate CLFS book instead to merge it into the main LFS book, I mentioned that LFS should start including at least pure and multilib x86_64 native builds to not die: http://linuxfromscratch.org/pipermail/lfs-dev/2005-September/053368.html IMHO, we need to release LFS-6.3 ASAP and start working on 7.x book series including x86_64 support. -- 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: SVN-20070706: Step 5.7 Adjusting the Toolchain
El Viernes, 13 de Julio de 2007 18:18, Ivan Kabaivanov escribió: actually there's a notice just before the command you've quoted. This is what I'm referring to: quote If working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, replace ld-linux.so.2 with the name of the platform's dynamic linker in the following commands. Refer to Section 5.2, Toolchain Technical Notes, if necessary. /quote However, further to this discussion, there is actually a problem with the sed command on platforms other than x86. Right. If architectures others than x86 aren't oficialy supported by the LFS book, then that quote should be removed. If the quote is not removed we implicity are assuming that the book could be used as is to do native builds on other arches, what is not true. -- 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 is now using the new stylesheets
El Viernes, 6 de Julio de 2007 01:21, Dan Nicholson escribió: +ifdef V +Q = +else +Q = @ +endif + Yea, I saw something like that on the BusyBox makefiles the other day. Looks good 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.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: [nex-xsl] What to do?
El Jueves, 5 de Julio de 2007 15:40, Dan Nicholson escribió: I think this would be the best. It gives maximum flexibility if the stylesheets we use are local to our repos. This also solves the issue of people having different versions of the stylesheets installed. So long as someone (Manuel) tracks upstream to fold any updates into our local copies, then this seems like the best solution, IMO. Looks like there is some type of consensus. I will start working on the migration today. Many thaks for the replies and comments. -- 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: [nex-xsl] What to do?
El Miércoles, 4 de Julio de 2007 22:59, Bruce Dubbs escribió: Do you have any insight into why there will be no 1.72.1 release? Apart the comments in the commits and some developer's post in docbook-apps saying that 1.73.0 will be released soon. I think that the main reason that they have to not do yet a *.1 release is that the nest stable version is supossed to support natively DocBook-XML-5.0. Thus, how can a XSL release be called stable if there is no stable DocBook-XML-5.0 yet? -- 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
LFS is now using the new stylesheets
Hi, I just finished to update the LFS book sources to use the new stylesheets. NOTE: I'm not sure if the script that generates the on-line book need be adjusted to use the new code properly. The Makefile has been also re-factored. There is a new all target and a new ROOT_ID variable. The ROOT_ID variable is very cool. It allow to render only a part of the book based on the given Id value. For example: make ROOT_ID=ch-system-glibc lfs will render only the chapter06/glibc.html file. That work also for PDF output, but FOP will emit several warnings. Maybe there is some bugs. I hope we can find and fix them quickly. -- 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
[nex-xsl] What to do?
Hi,
As you know, the new XSL stylesheets are ready for production time waiting the
release of stable DocBook-XSL-1.72.1.
The bad news it that there will be no DocBook-XSL-1.72.1 release, but a new
beta DocBook-XSL-1.73.0 that may contains several bugs due very intrusive
changes on how the package is generated from source code, changes on how
processing instructions are handled, and maybe other changes they are
planning before release.
That lead us to the next choices:
1. - Wait up to the next *.1 release to start using the new code. That could
meant to wait at least other 3-4 months :-/
2.- To create our own LFS-XSL-1.0 package based on current new-xsl branch
code and use it as a temporally solution. That implies to add a installation
page for such package in BLFS and to install it on the servers and editor's
machines.
3.- To clean-up the docbook-xsl-snapshoot branch subdirectory to keep only
that files actualy required to build the books. Then merge the code to the
{,B,C,H}LFS SVN trees. That will made the book's sources full auto-contained.
This will increase maintenance work to keep it sinchronized with upstream
code, but IMHO is the more simple solution and my prefered way.
Options 2 and 3 implies also that the DocBook-XSL page in BLFS could be
updated at least up to 1.71.1
--
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: [nex-xsl] What to do?
El Miércoles, 4 de Julio de 2007 23:29, Matthew Burgess escribió: I also think this is the way we should proceed. I'm not sure that we necessarily need to remove files that we don't require for a build of any of our books - in fact, keeping them around would probably make diffs between upstream and our downstream copy easier to understand. The files to be removed are almost all internationalization support files (keeping only the few ones used for current translators) and the highlighting/ files (used only by Saxon6). Thats around 5M of text files. What I'm afraid is that if the stable DocBook-XSL release take another 5-6 months we could start working on the Relax-NG migration before using the nex-xsl code :-/ -- 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: [nex-xsl] What to do?
El Miércoles, 4 de Julio de 2007 23:49, Matthew Burgess escribió: Well, I took a look at the Relax-NG stuff a while back and hit a bug in libxml2 (http://bugzilla.gnome.org/show_bug.cgi?id=413248). That pretty much stops any work on migrating the stylesheets to be Relax-NG friendly. Actualy for DocBook-XML-5.0 libxslt2 is not useful as a validator tool due that it can't do RelaxNG+Schematron validations, at least for now. Plus, Bob Stayton said some days ago in the docbook-apps list that the libxslt maintainer confirms that libxslt will never support XSLT-2.0 -- 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: Preparing for 6.3 Release
El Viernes, 8 de Junio de 2007 23:23, Dan Nicholson escribió: So, I think it's about time we start pushing out a 6.3 release. What do you guys think? IMHO, just update to the packages listed now on Trac (except, of course, the toolchain ones), and do package freezing to release 6.3 very soon. Toolchain update, bootloader(s) update, and the other remaining open bugs may meant to start working on 7.x LFS series. * Docbook XML/XSL changes: Manuel, how's that coming along? I haven't really been paying attention to this lately. The DocBook-XSL-1.72.1 release timeframe is a unknow variable. I asked some days ago to Bob Stayton about that without answers for now. Due that 1.72.0 was the first testing release including native support for DB-XML-5.0-rcX, I suposse that he might be waiting the final DB-XML-5.0 release to release the acompaning XSL stable release. If that DB-XSL release is not done at time for LFS-6.3, we must release the book with the current stylesheets or, if really wanted to use the new code, to port the full nex-xml branch, included the docbook-xsl-snapshot files (or even create our own LFS-XSL tarball). -- 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: Add an IP alias to ethernet interface
El Jueves, 7 de Junio de 2007 05:00, Bryan Kadzban escribió: this list whose address isn't resolving again. It seems like it's taking these messages about a half hour to get delivered. The message I'm replying to was sent at 21:42 EDT, but wasn't delivered to my mail server until 22:04 EDT. Might be worth double-checking out what's going on with postfix.) That's a recurring problem not solved yet :-/ http://linuxfromscratch.org/pipermail/lfs-dev/2007-April/059300.html -- 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: misc observances
El Lunes, 4 de Junio de 2007 02:45, Archaic escribió: On the vim page, where the docs are symlinked, a hardcoded reference to vim70 exists. This one has been fixed in r8148. Thanks. -- 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: Little note on psmisc
El Jueves, 10 de Mayo de 2007 19:56, Matthew Burgess escribió:
Indeed, and there's no man page for it, and no useful info in --help for it
either. I'm certainly not going to go and try to grok the source to figure
out what on earth it does.
Looks like is related to generic netlinks control and inet socket monitoring,
but I don't know what it actually do.
In the same boat as that is groupmems, which is installed by Shadow.
Again, no source of info as to what it is supposed to do.
This one have a man page. At least it XML source can be found in
{shadow_sources}/man/groupmems.8.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: Little note on psmisc
El Jueves, 10 de Mayo de 2007 21:11, Bruce Dubbs escribió:
Looking at the source and then running `genl -help` I get
$ ./genl -help
Usage: genl [ OPTIONS ] OBJECT | help }
where OBJECT := { ctrl etc }
OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] }
But I have no idea what that means.
After looking also at include/linux/genetlink.h, looks like genl is a tool for
monitoring generic netlink linux sockets (what is that??), similar to what
ip monitor do for devices, addresses, and routes.
--
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
[new XSL] Finished LFS and BLFS rework
Hi, The LFS and BLFS stylesheets rework has been done, or as least I can't find any obvious remaining issues. To allow review it, the generated chunked XHTML and PDF versions for both books can be found here: http://www.linuxfromscratch.org/~manuel/ I will wait some days for your comments and inputs. I would have solved all concerns and complaints about the LFS/BLFS outputs and the stylesheets layout before start working on HLFS and CLFS integration. Please, keep the discussion on the lfs-dev 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: File reg_startend patch
El Sábado, 7 de Abril de 2007 18:57, Matthew Burgess escribió: Thanks Greg, I'll remove the patch some time this week. Matt, don't forget this one, there is no trac entry for 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: [new XSL] Ready for inputs.
El Lunes, 9 de Abril de 2007 22:19, Bruce Dubbs escribió: [EMAIL PROTECTED]/new-xsl]$ make pdf xsltproc --xinclude --nonet --output ~/lfs-book/lfs-pdf.fo \ stylesheets/lfs-pdf.xsl index.xml xsl:attribute-set : use-attribute-sets recursion detected Making portrait pages on USletter paper (8.5inx11in) runtime error: file stylesheets/pdf/lfs-mixed.xsl line 255 element choose xsl:choose: unexpected content attribute I don't see anything wrong with stylesheets/pdf/lfs-mixed.xsl unless the xsl:otherwise on line 271 is out of place. Right, the tag is out of place but my xsltproc don't show that errors :-?? new-xsl$ make pdf xsltproc --xinclude --nonet --output ~/lfs-book/fop1-lfs-pdf.fo \ stylesheets/lfs-pdf.xsl index.xml Making portrait pages on USletter paper (8.5inx11in) sed -i -e 's/span=inherit/span=all/' ~/lfs-book/fop1-lfs-pdf.fo FOP_HOME=~/cosas/fop-0,93 ~/cosas/fop-0.93/fop ~/lfs-book/fop1-lfs-pdf.fo ~/lfs-book/fop1-LFS-BOOK.pdf new-xsl$ xsltproc --version Using libxml 20627, libxslt 10120 and libexslt 813 xsltproc was compiled against libxml 20627, libxslt 10120 and libexslt 813 libxslt 10120 was compiled against libxml 20627 libexslt 813 was compiled against libxml 20627 After fixed the tag, is the xsl:attribute-set : use-attribute-sets recursion detected warning still showed? I think that that is a different bug. -- 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 XSL] Ready for inputs.
El Lunes, 9 de Abril de 2007 22:50, Bruce Dubbs escribió: OK, I made some changes. See what you think. In admonitions, that make all types having almost the same look. Both #E0E0E0 and #EEE are near identical. What about this value? #DCC On verbatim, using #EEE is like removing the border. Try with this: #888 I could accept also to not have a border in verbatim chaded blocks. PD. I'm trying to find the most updated libxml/libxslt versions combo that outputs the attribute-set warning... -- 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 XSL] Ready for inputs.
El Martes, 10 de Abril de 2007 19:41, M.Canales.es escribió: Might be a bug in current libxml or libxslt. After several versions changes and research looks that actually was a bug in old libxslt versions that was not merging properly xsl:attribute-set settings when the same one is found on two files with different import precedence. It was fixed in libxslt-1.1.17. -- 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 XSL] Ready for inputs.
El Martes, 10 de Abril de 2007 22:02, Bruce Dubbs escribió: Looking at the output, all my issues have been addressed nicely with the exception of the font-family/font-style of the titles. That's not very important, but may be a nice tweak. At my end there is yet an issue to be solved: let very long screen block to split on several pages. Not an issue for LFS (except if selecting a smaller paper size), but will be at least for the compressdoc.sh script in BLFS. About fonts, at this momment the one used is TimesRoman (sans-serif is an alias to it). We could change body.font.family and/or title.font.family to Helvetica and/or Courier to see if there is other combinations with a better look. More info in http://www.sagehill.net/docbookxsl/Typography.html -- 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 XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 23:03, Bruce Dubbs escribió: Manuel, I pulled the new style sheets from svn. How do you use them? Do you just have a temporary symbolic link from the trunk/BOOK/stylesheets to ../../branches/new-xsl/ ? I have it in this way: $ svn co svn+ssh://[EMAIL PROTECTED]/LFS/trunk/BOOK new-xsl $ cd new-xsl/stylesheets $ svn switch svn+ssh://[EMAIL PROTECTED]/LFS/branches/new-xsl . Note the dot in the last line. To render the PDF you need to edit the Makefile to change the line sed -i -e s/inherit/all/ $(BASEDIR)/lfs-pdf.fo to sed -i -e 's/span=inherit/span=all/' $(BASEDIR)/lfs-pdf.fo and be sure that FOP-0.93 is used. I changed the line in the Makefile to read FOP_HOME=~/fop-0,93 ~/fop-0.93/fop $(BASEDIR)/lfs-pdf.fo \ $(BASEDIR)/$(PDF_OUTPUT) -- 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 XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 04:28, Bruce Dubbs escribió:
Please, try to keep the CC to lfs-dev.
I do think that each section in Chapters 5 and 6 that install a new
package should start on a new page, but places like Chapters 8 and 9 and
possibly 1, 2, 3, 4, and 7 should 'flow'.
Yes, I was thinking also about that. The code was committed some hours ago.
Now the PDF have only 254 pages:
http://www.lfs-es.info/new-lfs-book/fop1-try2-lfs-book.pdf
It would also be nice to solve the problem of long urls that cause ugly
spacing when the text is fully justified. Examples are: page 13
(section 1.5), page 14, page 206 (section 7.5), page 217 (7.12.1).
The last paragraph on page 224 (8.2) also suffers from the
long-name-spacing-problem.
These word spacing issues vary a bit in 'badness', but it would be nice
if there were optional (zero width space) breaks at slash ('/') and
underscore ('_') characters.
The URLs hyphenation support on the old stylesheets and FOP-0.20 was very
ugly. I will test if the current one is more usable and, if true, trying to
extend the support also to filenames.
--
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 XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 17:33, M.Canales.es escribió: The URLs hyphenation support on the old stylesheets and FOP-0.20 was very ugly. I will test if the current one is more usable and, if true, trying to extend the support also to filenames. And done: http://www.lfs-es.info/new-lfs-book/fop1-try3-lfs-book.pdf -- 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 XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 19:30, Bruce Dubbs escribió: I like this a lot better. Thanks. Now I'm going to get a bit picky about the pdf, but its offered in a constructive manner. Don't feel obligated to fix any of these issues. I'd like to see other opinions too. Starting with my owns ones ;-) 1. The font on the headers doesn't seem right. Most of the text is standard serif fonts (computer modern?). That looks fine. The headers are sans-serif and bold. The bold seems a little too wide. My acroreader say that the used ones are this Arial-BoldMT TimesNewRomanPSMT TimesNewRomanPS-ItalicMT TimesNewRomanPS-BoldMT Courier-Bold Courier Courier-Oblique Courier-BoldOblique Looking at a typical O'Reilly book, they use ITC Garamond Light (Italic) for headings and Garamond Book for the normal text. It seems to flow there pretty nicely. How much control do we have over fonts? http://xmlgraphics.apache.org/fop/0.93/fonts.html I have not full read it yet, but look that for files outside the ones listed above extra FOP configurations are needed and may implies that the user/reader must have intalled that fonts on their system. 2. The highlighted text has borders that seem a little heavy. The notes have borders that are light gray. 'Important' and 'Caution' areas have the heavy border too. Perhaps removing the border completely from the gray backgrounds and using the light gray border for all the light yellow backgrounds would give a better visual appearance. The colors and border are the same than the ones used on the XHTML output. The border could be changed from 1pc to 0.5pc to make ir less heavy, but in resume I would to have the same look in both versions. -- 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 XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 20:52, Bruce Dubbs escribió: One place that is still a problem is the last paragraph of 8.2 (page 212). The long config variables, CONFIG_NLS_DEFAULT, CONFIG_SMB_NLS_DEFAULT, CONFIG_FAT_DEFAULT_CODEPAGE, and CONFIG_FAT_DEFAULT_IOCHARSET throw off the word spacing. If a break was made at the underscores, it would improve that paragraph. Actually that parameters are not tagged at this moment, thus can't be hyphenated. -- 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 XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 21:10, Bruce Dubbs escribió: Is this a function of the reader's system or the system that renders the pdf. I thought the actual fonts used were enclosed in the file. I'm not 100% sure though. For specifications, the Base-14 fonts must be available to all PDF readers and are not embedded, except if forced. Additional fonts must be embedded or be available to the readers. What I noticed, is that in Acrobat Reader 5.0 the fonts looks nice, but in KGoshtView looks a little ugly. Maybe due that Acrobat Reader uses their own fonts while other readers uses the ones from gs? 0.5pc? I think that's a pica which is 1 PostScript pica = 4.2333 millimeters I don't think the borders are that thick--at least not on my system. My estimate is about 1 mm. Are you sure that's not the margin? Where is the border specified? Perhaps we could do some preprocessing for the pdf. In new-xsl/stylesheets/pdf/lfs-admon.xsl for admonitions and new-xsl/stylesheets/pdf/lfs-mixed.xsl for verbatim environments. The line to search in both is: xsl:attribute name=border-width1pt/xsl:attribute Changing it to 0.5pt looks a good idea. -- 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 XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 22:32, Bruce Dubbs escribió: I'll pull the xsl and look some more. Great, I need inputs about the explanatory comments. -- 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
[new XSL] Ready for inputs.
Hi, Looks like the stylesheets revision for LFS is done for now, until have DocBook-xsl-1.72.1 available. The unique visible change in the XHTML output is that chapters TOC has been added, as was suggested. An on-line version is available here: http://www.lfs-es.info/new-lfs-book/ In PDF output there are several changes. To can compare it, both the current PDF and the new one can be downloaded from here: http://www.lfs-es.info/new-lfs-book/fop0-lfs-book.pdf current PDF http://www.lfs-es.info/new-lfs-book/fop1-lfs-book.pdf new PDF I'm awaiting your comments, sugestions and complaints, not only about the outputs look but also about the documentational comments in the stylesheets, before start working on the BLFS stylesheets 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/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: dummy user for testsuites
El Lunes, 2 de Abril de 2007 23:10, Jeremy Huntwork escribió:
Does anyone see a problem with adding that dummy user/group to the
original /etc/{passwd,group} files, perhaps with a note explaining its
purpose? At the end of chapter 6 we would remove the user and group.
Why not to use the nobody user for that tests?
There is recent thread about this same issue started by Robert Connolly:
http://linuxfromscratch.org/pipermail/lfs-dev/2007-March/059171.html
--
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-tools package
El Sábado, 31 de Marzo de 2007 03:49, Randy McMurchy escribió: Automating LFS has never been really a goal for me. However, it's time I looked into, and started using the jhalfs tool. Great, I will be very happy to heard your feeling and complaints about the tool when actually using it. Your inputs will be very appreciated :-) -- 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
[new XSL] The Index generation
Hi,
The generation of the Index is one of the most broken parts using the new
DocBook-XSL code. That meant that that higly customized stylesheets need be
full reworked.
Due that it need be reworked in any case, I would take advantage of a new
available feature: The possibility to create separate index pages for each
index section. That is, an index HTML page for packages, another for
programs, another for libraries, and so on.
To acomplish that (if I can implement it) a few changes will be need on how
{indexterm} block are tagged. For example, at a first look and waiting for
testing, a current entry like:
{indexterm zone=ch-system-bash}
{primary sortas=a-Bash}Bash{/primary}
{/indexterm}
could be
{indexterm zone=ch-system-bash type=package}
{primary}Bash{/primary}
{/indexterm}
I.e, the sortas attribute in {primary} will be replaced by a type
attribute in {indexterm}.
Of course, that XML changes can't be made until have the new XSL code ready.
Thus the question is, do you want that I start working on that Index pages
split or do you want only to fix the current very long longindex.xtml page
generation?
I could try to prepare a very simple POC of that index pages split if you need
something to look-at before taking a decission.
--
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
Created the branch to develop new XSL stylesheets
Hi, A branch to develop the new XSL stylesheets has been justs created. To work with that branch: $ svn co svn+ssh://[EMAIL PROTECTED]/LFS/trunk/BOOK new-xsl $ cd new-xsl/stylesheets $ svn switch svn+ssh://[EMAIL PROTECTED]/LFS/branches/new-xsl . From now on, an svn up on the new-xsl/ dir will update book files to trunk, but stylesheets files to the new-xsl branch. This stylesheets branch contains the required files from the most current docbook-xsl-snapshot tarball, thus there is no need to install the newer DocBook-XSL package on the system to render the book, until 1.72.1 version will be released and the new stylesheets developed. -- 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: FOP-0.93
El Viernes, 23 de Marzo de 2007 23:24, Randy McMurchy escribió:
Hi all,
I'm ready to update the book to FOP-0.93, but wanted to throw out a
note that we cannot use it to produce PDF output from the SVN XML
sources.
Yes, that it a known issue. Our current stylesheets (both the DocBook-XSL
version used and our customizations layout) are very old to use it.
It appears Manuel needs to work some magic to produce
compatible .fo files.
Better said, almost a full rewrite to can match DocBook-XSL 1.72.1 version,
when released. Before that, and in case LFS-6.3 is released without having
finished the XSL upgrade, I will try to do a quick fix.
I would to start working on the XSL rewrite the next week, using the most
current DocBook-XSL snapshopt as the base.
I don't see any harm in updating, as there really is no need right
now to produce .pdf forms of the book.
I neither. As a worse scenario we could say that the PDF file for {,B}LFS-6.3
books has been created using FOP-0.20, pointing to the BLFS-6.2 book for
installation instructions.
--
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: Bash shell startup files
El Jueves, 22 de Marzo de 2007 19:30, Randy McMurchy escribió: Hi all, I'm not certain of something. Do we expect *all users* to perform the steps shown in the Bash shell startup files? I know I don't do them. I have my own way of setting up /etc/profile, et. all. To me that section is only an example about how to improve bash configuration, but it is not mandatory and we should not force users to follow it by the letter. That is applicable also to the rest of the After LFS Configuration Issues chapter., IMHO And this makes the JDK instructions related to the CLASSPATH broken. I'm not a big fan of this pathprepend and pathappend stuff. In fact, I'd like to remove it in favor of something that isn't BLFS specific. I agree. I'm wondering if the Bash Shell Startup Files shouldn't be listed in the required dependencies? No, please. I don't recall anything in BLFS as being mandatory, yet the JDK instructions simply *assume* that folks followed the Bash Shell startup stuff. Thus bad assumption, IMHO. I'm looking for an answer, as I think we need to add JUnit to the book as it is now required by Apache Ant. And Apache Ant is now a required dependency for FOP (Ant is no longer in the FOP source tree). The Junit install dir and the .jar file need to be in the CLASSPATH and I'm not sure how to handle this. The standard CLASSPATH=$CLASSPATH:/path/to/jar_file should work and be enough. -- 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: LFS-6.3 status update
El Miércoles, 21 de Marzo de 2007 02:05, Matthew Burgess escribió: Hi folks, Progress appears to being made toward a 6.3 release. We currently have 9 tickets to resolve before we can push another release out[0]. Great :-) I'm happy to postpone the rendering toolchain related bugs #1947 (fop-0.93) and its dependency of #1956 (docbook-xsl-1.72.1) if upstream aren't in a position to make a release in time. They are yet fixing bugs, the last one just 90 minutes ago. I'm thinking on creating the branch this weekend and start working based on the most current snapshot tarball available at that time #1893 (docbook-4.5) has a patch available so that's a no-brainer really. Looks like it is not installed yet on quantum :-? [EMAIL PROTECTED] ls /usr/share/xml/docbook/ . .. xml-dtd-4.4 xsl-stylesheets-1.69.1 [EMAIL PROTECTED] grep -l 4.4 /etc/xml/* /etc/xml/docbook [EMAIL PROTECTED] grep -l 4.5 /etc/xml/* [EMAIL PROTECTED] I will made the commit upgrade as soon docbook-4.5 will be properly installed on quantum. I'll be on holiday from 2007-03-23 to 2007-04-06 and am unlikely to be able to deal with any LFS issues during that time. That said, if anyone wants to try and find me in a bar in North Carolina, I might be persuaded to deal with LFS stuff, in exchange for a beer or 2 of course :-) Enjoy the holidays :-)) -- 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.3 status update
El Miércoles, 21 de Marzo de 2007 19:09, Matthew Burgess escribió: Wow, sorry about that. I could have sworn I'd done that already. Anyway, it's done now. Verified and confirmed that the catalog resolution works. Thanks. Working on the commit 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.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: FC6 (x86_64) as a host system
El Martes, 20 de Marzo de 2007 06:18, Fix escribió: If you're building 64-bit *LFS system WITHOUT use of the cross compilation, you would need the 64-bit host system, I guess. That's what I do. And I think that system wouldn't be neither Cross nor Beyond LFS. Right, but the LFS book is intended only for x86 -- x86 builds. For not cross-compiled builds on others arches, included x86-64 -- x86-64 builds, you may need a different sets of instructions and/or patches that currently aren't discussed on any *LFS 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
Released jhalfs-2.2
The jhalfs development team is pleased to announce the release of jhalfs-2.2. New features in this version: - Better support for CLFS Sysroot and CLFS Embedded books - Support for BLFS-6.2.0 - Added customized tools support to all books - Added blfs-tool support to all books (except CLFS Embedded that can't use it) - Several bugs fixes and code clean-up The jhalfs-2.2 tarball can be downloaded from http://www.linuxfromscratch.org/alfs/downloads/jhalfs/stable/jhalfs-2.2.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: 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: 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: 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: 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: 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: 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: 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 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: 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 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 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
