Re: jhalfs: Ready to go.
El Sábado, 15 de Octubre de 2005 04:42, Alexander E. Patrakov escribió: > The problem is only with non-LFS hosts that define > NONINTERACTIVE_LOGIN_SHELLS. Since the "lfs" user never logs in using an > interactive shell, his .bash_profile is never used on "normal" hosts and > (as already mentioned) only causes damage on "strange" hosts. So I > propose to add role="nodump" to the creation of .bash_profile in the book. Point taken. Removing now the creation of .bash_profile. 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: jhalfs: Ready to go.
El Viernes, 14 de Octubre de 2005 17:08, Bruce Dubbs escribió: > /etc/fstab is a different matter. If jhalfs could pick up a custom file > from the host system written before running, it might avoid a > post-script edit. Added a switch to can submit a real /etc/fstab file, and a note on the final message from the Makefile that read: "If you're an experienced LFS user, several of that steps can be skipped or done in a different way. But then, that is something that you already know and there is no need to discuss it here." Thanks for your inputs :-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] LFS-6.1.1
El Viernes, 7 de Octubre de 2005 00:42, Jeremy Huntwork escribió: > I've heard no recent talk of cutting a testing branch from trunk in > preparation of a release, and in the meantime, I think we owe it to our > readers to supply a stable LFS with all these known items fixed. I was thinking to add jhalfs support for 6.1.1, but noticed that there is no patches.ent file on that branch. If jhalfs support is wanted and such type of change is allowed on this bug-fixes release, I could do the needed edits this weekend. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: jhalfs: Ready to go.
El Viernes, 14 de Octubre de 2005 20:17, David Fix escribió:
>
> if [ ${i: -5} = "groff" ] ; then {do something} ; fi
Fixed but using something a little diferent:
if [ ${i:4:8} = "binutils" ] ; then
That will match both 027-binutils-pass1 and 036-binutils-pass2 ;-)
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: jhalfs: Ready to go.
El Viernes, 14 de Octubre de 2005 19:52, David Fix escribió: > You bet. :) Just remember to change the -5 to whatever the length of the > command is that you're checking against. :) The number means the lenght of the string after the - right? -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: jhalfs: Ready to go.
El Viernes, 14 de Octubre de 2005 17:08, Bruce Dubbs escribió: > I havn't tried jhalfs yet, but as a suggestion, /etc/shadow could have a > null root password: > > echo "root" > /etc/shadow Yes, but that will implies another deviation from the book's commands, and not to corfim that Shadow is doing well their work. > You could also put in default files for /etc/hosts, > /etc/sysconfig/clock,/etc/sysconfig/console, /etc/sysconfig/network, and > /etc/sysconfig/ifconfig.eth0/ipv4. > > The contents of these really don't matter that much for an initial boot, > but can be changed after the user tests the system for the first time. Actually, that default files are already created and placed into the final system. > /etc/fstab is a different matter. If jhalfs could pick up a custom file > from the host system written before running, it might avoid a > post-script edit. Good idea, a switch could be added tu supply a proper /etc/fstab file, in a similar way that is done for the kernel configuration file. > Grub is a bit more difficult. I always have a separate /boot partition, > so I can just copy the kernel, System.map, and (my technique) .config, > to /boot from /mnt/lfs/path/to/file and edit /boot/grub/grub.conf (which > could be done with an append). I generally don't reinstall grub as I am > building from a prior LFS system and the existing grub is fine. I follow the same approach that you. The final Makefile message is saying only what the LFS book say, but like you know, "Your distro, your rules" ;-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: jhalfs: Ready to go.
El Viernes, 14 de Octubre de 2005 16:19, Alexander E. Patrakov escribió: > Jeremy Huntwork wrote: > > BTW, has anyone else tried this? > > The showstopper is in /home/lfs/.bash_profile: the "su" command starts a > shell that, as a result, waits for user input. I deleted that file. /home/lfs/.bash_profile is created for consistency with th LFS commands (and to allow to login in the host as the lfs user, if desired) but never used during the automatic build. In the generated Makefile the commands lines for chapter05 steps are like su - lfs -c "source /home/lfs/.bashrc && /mnt/lfs/jhalfs/commands/chapter05/025-introduction" "su - lfs" clean el envars and not load the bash startup files. Then only /home/lfs/.bashrc is sourced. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: jhalfs: Ready to go.
El Viernes, 14 de Octubre de 2005 15:36, David Fix escribió:
> Sorry, a bit of a typo, but this is "more" correct:
>
> if [ ${i: -5} = "groff" ] ; then {do something} ; fi
>
That sounds good and is more portable for when supporting Cross-LFS.
I will test it soon, 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.com
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: jhalfs: Ready to go.
El Miércoles, 12 de Octubre de 2005 14:06, Alan Lord escribió: > Is this an alternative to alfs or something more different [sorry about > the English there - yeuckkk!] than that? Is something very different to nALFS. nALFS have many features and uses beyond the build of a base LFS system. > Is it suitable for "non" LFS Developers? Is suitable, but not recomended to build production systems. At least until has been tested in deep on several different host systems and the jhalfs code will be deemed as "stable". > I re-build my LFS quite frequently (just for fun) and use have > sucessfully used ALFS in the past. I would be happy to try this on my > systems. If you build several times LFS for fun, then jhalfs may be a choice for you. Try it and send your 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
jhalfs: Ready to go.
Hi! I'm very happy to announce that jhalfs is now able to build a full LFS SVN system (or any other LFS XML sources based in current LFS SVN) in a very simple way and using the actual commands found in the XML sources. The sources can be downloaded via svn co svn://svn.linuxfromscratch.org/ALFS/jhalfs/trunk Testers are needed to find possible bugs, features request, code improvements, make better build logs, etc... I think that the output from "./jhalfs -h" and the message displayed by "make" after a succesful full build are self-explanatory: ./jhalfs -h Usage: ./jhalfs [OPTION] Options: -h, --help print this help, then exit -V, --version print version number, then exit -d --directory DIR use DIR directory for building LFS; all files jhalfs produces will be in the directory DIR/jhalfs. Default is "/mnt/lfs". -P, --get-packages download the packages and patches -D, --download-client CLIENT use CLIENT as the program for retrieving packages (for use in conjunction with -P) -W, --working-copy DIR use the local working copy placed in DIR as the LFS book -L, --LFS-version VER ckeckout VER version of the LFS book -T, --testsuites add support to run the optional testsuites --no-toolchain-test don't run the toolchain testsuites. This disables also the build of TCL, Expect and DejaGNU --timezone TIMEZONE set TIMEZONE as the local timezone. If not specified, Europe/London will be used. --page_size PAGE set PAGE as the default page size (letter or A4). This setting is required to build Groff. If not specified, "letter" will be used. -C, --kernel-config FILE use the kernel configuration file specified in FILE to build the kernel. If not found, the kernel build is skipped. -M, --run-make run make on the generated Makefile make ... Finished the build of LFS-SVN-20051009 W A R N I N G To be able to boot your new LFS system you need to follow the next steps: - Enter to the chroot using the command found in chapter06/revisedchroot.html - Set a password for the root user - Edit /etc/fstab, /etc/hosts, /etc/sysconfig/clock, /etc/sysconfig/console, /etc/sysconfig/network, /etc/sysconfig/ifconfig.eth0/ipv4 and any other configuration file required to suit your needs. - Set-up Grub. See chapter08/grub.html - Unmount the filesystems. See chapter09/reboot.html Have a nice day :-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Compiling LFS-BOOK
El Martes, 4 de Octubre de 2005 09:50, Filip Bartmann escribió: > I have translated LFS-BOOK-6.1-XML into Czech language,but I have during > compilation this errors: ... > I have installed all needed tools from INSTALL file in my home > directory.What i have wrong? You need to set-up a proper catalog file to resolve locally all that URLs. See "Chapter 4: XML catalogs" in the "DocBook XSL: The Complete Guide" book: http://www.sagehill.net/docbookxsl/Catalogs.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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Automatics LFS builds using jhalfs.
El Lunes, 3 de Octubre de 2005 23:44, Dan Nicholson escribió:
> Don't know if this works with make, but I saw a nice solution to this
> problem in Greg Shafer's build system that uses Bash scripts. In
> order to continue to run as root user in the chroot, he uses:
> exec su -c "${CHROOT_CMD}"
> where CHROOT_CMD is something like
> chroot ${DIR} ${ENV_VARS} ${the_same_script} --chroot
That is very similar to what Jeremy has added, except for the "exec su -c" and
that instead of invoking "make" we execute the relevant shell script for each
package 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.com
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Automatics LFS builds using jhalfs.
El Lunes, 3 de Octubre de 2005 00:52, Jeremy Huntwork escribió: > This should be very easy, especially considering you've already > accomplished a similar feat when su-ing as 'lfs'. All you would need to > do is make sure that the proper kernfs and dev structure is in place in > chroot and then for each target run "chroot $(DIR) $(ENV) bash -c > 'command1 && command2'" where $(DIR) is your mount point, ie, /mnt/lfs > and $(ENV) is the specific environment variables you want to include. I see that you go ahead and made some improvements and bugs fixes. Not revised/tested yet, but in the commits look very nice. I'm very happy to see you doing some work and keeping your "child" in a sane state ;-) Testing the new code now (i.e, rebuilding the system up to chapter05 and then run the chapter06 targets one-by one) to see what issues remain. > You have a point there. Guess I was thinking of items like 'all chapter4 > chapter5 chapter6 clean-all clean' etc. Targets that you want to > *always* run. The others that you 'touch $@' on are 'real' targets. Point taken. That is easy to 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Automatics LFS builds using jhalfs.
El Domingo, 2 de Octubre de 2005 18:45, Joshua Murphy escribió: > hmm ... would it work to make a "Stage 2" script that's simply called > as the command to execute through chroot? ... i'm not much of a > developer, but i've looked at building my own scripts before, and i've > considered a lot of little things like this one, just never tested > them ... i'm planning on starting a build tuesday morning with this > script ... Yes, maybe some type of wrapper could be needed. > also, it would be interesting to see a tool that could do the same > parsing, but instead of a build, put together the nALFS profile for > the given copy of the book ... seems like it may save the nALFS team > some work in the long run, as long as the books format doesn't change > much anyways ... but now i'm just rambling ... :) Well, that could be very nice but can't be done (or will be very very difficult) with the current book's sources. The problem is that there is no easy way to map a plain flow of characters (the ones inside the [screen][userinput] ... [/userinput][/screen] tags in the book sources) to the combo on xml tags, attributes and strings needed by nALFS profiles. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Automatics LFS builds using jhalfs.
El Domingo, 2 de Octubre de 2005 17:35, Jeremy Huntwork escribió: > Wow, you've really taken my idea and run with it. ;) It looks nice, just > where I would have (probably) gone myself. I'll have to get some time to > sit down and really look it over. Thanks, and very happy to read to you :-) The problem at this moment is that I can't figure yet how to manage the chroot phase. > One thing I noticed, though it's not a huge thing... You may want to add > a .PHONY list of targets that don't need to be checked to see if they've > already been run. Will slightly speed up processing time. But if it's a > lot of trouble to automate, it's not that important. Due that this is a linear build where each step depend on the proper execution of the previous one, I can't think in this momment on any cadidate target for .PHONY. The rebuild from/up-to one child target can be achieved also removing the relevant $JHSLFSDIR/???-* files and touching the remaining ones. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Automatics LFS builds using jhalfs.
El Domingo, 2 de Octubre de 2005 13:15, M.Canales.es escribió: > Do by hand all steps up to the end of chapter03, create the $LFS/jhalfs > directory and place into it a fresh svn working-copy of your sources naming > the directory lfs-development. Actually i'm planning to add a switch to can use any local working copy. That will allow to test commands changes and packages updates before commit the changes to the repository -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Automatics LFS builds using jhalfs.
El Domingo, 2 de Octubre de 2005 12:51, Alexander E. Patrakov escribió: > What should I do with my UTF-8 book to make sure that it's compatible > with the script? First, to add the role="nodump" attributes found in the current LFS SVN book, to skip undesired commands, and to add the -v switchs in the book's commands, if your want full logs. Do by hand all steps up to the end of chapter03, create the $LFS/jhalfs directory and place into it a fresh svn working-copy of your sources naming the directory lfs-development. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Automatics LFS builds using jhalfs.
Hi! jhalfs is a tool to build an LFS system using the real commands found in the LFS SVN book. It's intended as a standar framework for developers and testers. http://svn.linuxfromscratch.org/viewcvs.cgi/jhalfs/trunk/?root=ALFS It can dowload the needed packages and patches (from ftp.lfs-matrix.net) adding the -P switch, and can run the optional testsites adding the -T switch. At this momment it can build the system up to the end of chapter5. I will start the work to support the other chapters soon. I will be very happy if some of you could review the code and test it, I'm not a shell scripts or Makefile guru ;-) Any feedback will be apreciated, included a plain "It sucks." -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS
El Sábado, 1 de Octubre de 2005 23:49, Ken Moffat escribió:
> There is a slight difficulty with starting at binutils in Contructing a
> Temporary System - we only build binutils and gcc once and we don't
> build glibc at all ;) Realistically, the multi-arch book would need
> sections added. Also, we're using ${LFS_TARGET}-gcc and friends - it
> doesn't feel right to specify LFS_TARGET in a native build, and there
> are config.cache things that are only needed in a cross-compile.
Yes, the creation of the temporally tools must be different on both sets of
books.
> I'm all in favour of extending the platforms that people can reliably
> use for LFS, but I don't see tangible gains - as I read your proposal,
> there would be two books with a common source. Users might be attracted
> by not having to cross-compile, but equally they might think that issues
> in "cross-lfs" were unrelated to their "multi-arch lfs".
I see a common sources, but two differen projects with their own rendering
books pulled from that sources: multi-arch books in LFS and cross-build books
in Cross-LFS.
> I'm also a little worried that rendering the book will become unwieldy.
> It already strains my patience ;)
If you are rendering/validating all book each time that you made a little
change in the sources, yes, the process is very long.
But if the change you made only affect some archs, you can validate/render
only that books (for example, mips ands mips64) adding "ARCH=mips mips64" to
the make command.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Cross LFS
El Sábado, 1 de Octubre de 2005 21:03, Jim Gifford escribió: > Manuel and LFS-dev, > > I have been thinking about this for a few days. Cross-LFS has two > different options in it, boot and chroot. Boot is a complete reboot and > chroot is like the standard LFS book. Talking with various people, an > idea popped into my mind. Having two separate books, Cross-LFS with the > cross-tools and boot section and a version of the old Multi-Arch LFS > book which would have the cross-tools section remove and utilizing the > chroot section. I think that do you meant a repository setting like this: BOOK top level files (entities, book's index, Makefiles, etc..) editor-tools stylesheets cross-build introduction final-preps cross-tools temp-system (with boot files included) temp-tools native-build introduction (chapter01 from LFS with multi-arch support) final-preps (chapter04 from LFS with multi-arch support) temp-system (chapter05 from LFS with multi-arch support) chroot common prologue partitioning materials final-system bootscripts bootable the-end appendices > The only downfall I see of this idea, is the book rendering issues. Is > it possible just to render the complete book as it is now, and then make > new index pages with the sections listed as above? Yes, you can create all the *-index.xml files that you want rearrangin the included files in any way (except placing duplicated ones, of course ;-)) > What type of modifications would we need to do accomplish this? Appart the repository reestructuration, maybe some changes in the Makefile. > Would LFS benefit from this? (I say yes) I say yes also, but only if the multi-archs books replace the current 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: This is the end
El Martes, 20 de Septiembre de 2005 21:19, Jeremy Huntwork escribió: > Thanks again - I've enjoyed it immensely. Thanks to you for all the work done :-) I will try to keep alive your other child: jhalfs. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
El Martes, 20 de Septiembre de 2005 19:53, Matthew Burgess escribió: > I replied 22 minutes after Jim sent the original RFC, saying I agree > with it in principle. Once Gerard confirms, Jim can email me in private > and I'll set up the Subversion repository and book rendering. I don't > have any experience in setting up mailing lists, so Gerard will have to > sort that out. I can't think of any other infrastructure tasks that > need to be carried out, though polite reminders are always useful :) ... and to create the web pages for that new project ;-) The decision about other pointed issues, like if LFS should to migrate to a multiarch schema, can be made a posteriori. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
El Jueves, 15 de Septiembre de 2005 23:43, Jim Gifford escribió: > If we do this, we could remove chroot from the Cross-LFS, since it's > only there for same arch to same arch capability. Exactly ;-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
El Jueves, 15 de Septiembre de 2005 22:56, Jim Gifford escribió: > One of things I've been mulling over is maybe have cross-lfs just build > the toolchains, but the rest of the stuff, currently the temp-system and > final-system of Cross-LFS, could be the future LFS book that supports > multiple architectures. Yes, that is how I see it also. Both books could be almost indentical except in how the tolchains are created and the way used to build the final system (boot or chroot). -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
El Jueves, 15 de Septiembre de 2005 19:06, Jim Gifford escribió: > After some discussion with Gerard, he has requested I prepare a proposal > to the LFS community concerning the Cross-LFS book. > > Up to this point work on Cross-LFS has been done with the idea that, > eventually, its features would be merged into the main LFS book. I would > like at this time to propose that we create a separate project for > Cross-LFS, like ALFS, HLFS and BLFS. There are many reasons for wanting > to do so: If that will meant that Cross-LFS will be focused on pure cross-build techniques and scenarios, i.e. it assumes that host-triplet != target-triplet, thus no chroot way to build the final system, focusing the normal LFS book on host-triplet = target-triplet builds (not only for x86, but also for other archs, primarily x86_64) using the chroot way, then I support the proposal. But if we keep Cross-LFS as is now, and LFS centered only on x86, that could meant the dead of the LFS book in a no very far future, 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Udev configuration changes
El Martes, 13 de Septiembre de 2005 20:50, Matthew Burgess escribió: > With that in mind, we'd appreciate feedback on the attached config file > especially if you've tested it "in the field" and found that we broke > something! Errors and omissions expected :) The network devices removal includes eth0 and like? -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC4 branch merge
El Jueves, 8 de Septiembre de 2005 21:32, Matthew Burgess escribió: > Manuel, is this likely to cause problems > for your intended docbook-xsl-1.69.1 related patches you've got planned > for the weekend? Don't worry about that. The merge will implies only that I don't will need to verify the render and do the commit on the GCC4 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
DocBook-XSL-1.69.1 book update
Hi! I'm planning to update all [B,H]LFS books (trunk and active branches) to use the new DocBook-XSL-1.69.1 version the next Saturday 2005-09-10 at 12h UTC. Please, update your machines to can render the books using that new XSL version. 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ncurses cannot find libstdc++ in chapter 6.21
El Domingo, 4 de Septiembre de 2005 10:49, Chris Staub escribió: > I don't think that's a problem with the fact that you stopped and > restarted - if libstdc++ does not exist in /usr/lib then you forgot to > install the c++ compiler in chap. 6. Does /usr/bin/gcc exist? I think that do you meant /usr/bin/g++ -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4 (more nagging) :-)
El Lunes, 29 de Agosto de 2005 19:25, Matthew Burgess escribió: > I'll try to get around to getting the two changes in some time this > week, then we'll merge the branch into trunk probably a week after that > (just to give folks a chance to ensure there's no more problems, and > that the 'ftp' and 'cfdisk' bugs really are fixed). Great :-)) Jim, will be cross-lfs updated also to GCC 4 or is there some archs 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of tar in LFS books
El Lunes, 29 de Agosto de 2005 00:31, Jeremy Huntwork escribió: > One of the packages is unpacked from '/sources' while the other one is > unpacked from '../' - Presumably they're located in the same directory. > Which location should we be using? IMHO, ../ Both for consistency with how the patches are applied and to prevent issues if the user prefer to use a different name for the sources directory. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Remove inetutils from LFS [was Re: GCC-4.0.1]
El Martes, 23 de Agosto de 2005 20:56, Jim Gifford escribió: > M.Canales.es wrote: > >IMHO, for LFS we need only "ping" for FHS compliance. It's possible to > > build (and use) just Inetutil's ping on all archs? > > Doesn't work on Sparc Debian have an inetutils ping for Sparc: http://packages.debian.org/stable/net/inetutils-ping -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Remove inetutils from LFS [was Re: GCC-4.0.1]
El Martes, 23 de Agosto de 2005 20:09, Jim Gifford escribió: > Matt, > Which direction do we want to go in. IMHO, for LFS we need only "ping" for FHS compliance. It's possible to build (and use) just Inetutil's ping on all archs? About "ftp", actually isn't a requisite for LFS. We could point the user to the NcFTP, Wget, Lynx and Links BLFS pages. Or, if the community feel that some download program must be installed on the base LFS, to add one of them. In that case i will vote for Lynx. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Book Info Table Layout
El Domingo, 21 de Agosto de 2005 19:35, Bruce Dubbs escribió: > I think a list would look better: > >o Revision svn-20050821 2005-08-21 Development Release >o Revision 6.0 2005-04-02 Fourth release > > etc. > > Perhaps Manuel can take a look when he has time. Decide how do you think that it should look and I will try to do it. Related to this, when upgrading to DB-XSL-1.69.1 we can to place the revision history on a separate page, like we do with legalnotice.html, if wanted. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: pure64 iproute2 version not found
El Sábado, 20 de Agosto de 2005 08:03, Doug Ronne escribió: > pure-64 packages, iproute2 > > instead of 050815, now there is an 050816 Fixed, 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The trunk Changelog.
El Miércoles, 17 de Agosto de 2005 21:16, Richard A Downing escribió: > Does this mean a big change in the markup that we have to edit - does it > introduce any more error prone-ness? As you can see in the new XML, there is a template on the top ready to be cut-and-pasted and then edited to insert the real text, then there is no need to worry about the extra tags 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.com 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 LFS Developer
El Viernes, 12 de Agosto de 2005 20:18, Matthew Burgess escribió: > Hi folks, > > Please join me in welcoming Ken Moffat to the LFS development team. Ken > has been a long time contributor to both the development and support > communities, and his knowledge and dedication to the project are certain > to be beneficial to the project. Welcome Ken :-)) That is a very good notice. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS - Pure 64 - Bootloaders [RFC]
El Miércoles, 10 de Agosto de 2005 23:18, Jim Gifford escribió: > I've been working on our cross-lfs build methods quite a bit lately, but > have ran into some dead ends when it comes to the bootloaders for all > the architectures we support. None of them will build properly on a Pure > 64 bit system. The only way I see to get around this is to build some 32 > bit tools and utilize the gcc -m32 for the bootloader builds. LILO could to solve the x86_64 problems, but the issue still will remain on the other archs. Then, at least for consistency, I will prefer an homogeneous solution for all archs. If that implies to build some 32 bits tools to can compile the bootloaders, go for it. But, if possible, try to keep that 32 bits tools separate from the 64 bits system (i,e, installing they on /tools/32 or /opt/32). -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Shadow/CrackLib - A compromise?
El Lunes, 8 de Agosto de 2005 08:42, Archaic escribió: > Hrmm. Well if it is deemed to be more accurate using screen tags as > opposed to just para tags, that is easily fixed, but since we aren't > actually typing in the command as seen, but rather inserting it into > another command, I don't know if screen would be semantically correct, > either. I'll let Manuel or Matt decide. The use of [screen] is fine for both look consistency and to prevent unwanted line wrapping, not only on PDF output, but also in browsers with a window size smaller than the actual command. About the child tag, [literal] is semantically correct due that the sed script must be typed literally, but isn't a command on their own, then [userinput] don't fit well here. Plus, using [literal] the font size used will be "normal" instead of "bold", making most notable that is an optional step. Committing that small fix now. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] On LFS' Package Selection Policy
El Sábado, 6 de Agosto de 2005 12:46, Matthew Burgess escribió: > Err, yeah. I should have been clearer on which bit of the LSB I was > referring to here. I was just looking at using table 15-1 - > http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-gener >ic/command.html#AEN21889 - as a quick guide. On that table there is, among others, "crontab", "mailx" or "sendmail", that don't look very appropriate for a base development system. IMHO, the FHS and POSIX standards can/should be implemented from the beginning in LFS, but many of the LSB directives are BLFS or hint material. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Typo in Docbook XSL Stylesheets section
El Lunes, 1 de Agosto de 2005 20:01, Randy McMurchy escribió: > > Manuel, could you start looking into the differences between the > 1.68.1 and recent version so we can think about updating BLFS. 1.69.0 is a beta version. Actually, all "dot cero" versions are beta, not intended to production use, then not suitable to be added to BLFS. In two or three weeks will be released 1.69.1. But revising the 1.69.0 sourced I notices several changes: .- The installation process has changes, like pointed by Tushar. Following the INSTALL file, the package should be unpacked where you'd like to install it (i.e., /usr/share/xml/docbook), and the run install.sh that is an interactive installer. After finish the installation, a test.sh script is created to can test it. Also is crated an unistall.sh script. .- The documentation is now on a separate tarball (good to install it under /usr/share/doc/xsl-&version;) .- Has been integrated the "website" stylesheets (previously they where on a separate package). .- Several changes on the FOP and [X]HTML output, mainly to start adding support for Relax-NG and the new tags in the next BocBook-5.0. More testing when the stable release will be out. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Bash Docs
El Sábado, 30 de Julio de 2005 20:54, Matthew Burgess escribió: > Well, bashref.html is linked to from > http://www.linuxfromscratch.org/~matthew/LFS-references.html, which is > itself linked to from chapter01/resources.html in the book. We could > add a link to the full bash-doc tarball to the LFS-references.html page > I suppose. I'm wary of putting instructions in the book itself for fear > of setting a precedent :-) The precedent is already here. We are dowloading the glibc-linuxthreads package only to install the API manpages. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cross-lfs
El Miércoles, 27 de Julio de 2005 00:10, Randy McMurchy escribió: > I would like to think that if Cross-LFS has a chance at becoming the > default build method, the group should be involved with the project > from the beginning.At least that's how I see it. Nothing prevent to you or other people to review the cross-lfs book and send your comments, sugestions, compliments or improvements. Any feellback will be apreciated. But that is yet a play-branch where we (the people currently invloved on that brach) are creating a POC for a possible new generation of LFS books. Then, like in any POC, we should can made any change on our onw. At this moment the branch is usable and can be used to build test systems, but nothing is in stolen. There is no timeline to merge it on trunk, and before do that, the community will be able to decide if or what from cross-lfs will be merged to 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.com TLDP-ES: http://es.tldp.org -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Roadmap
El Martes, 26 de Julio de 2005 04:16, Gerard Beekmans escribió: > Clutter will be a concern. The TOC has to be clean and easy to navigate. > Like I said above, a chapter re-organization may be required to maintain > a logically flowing TOC where you don't get lost. Actually at this momment we are using an XSL hack to can read the book linearlly following the "boot" method or the "chroot" method. See, for example: http://www.linuxfromscratch.org/lfs/view/cross-lfs/x86/temp-system/choose.html That hack could be used to choose the "croos-tools" method or the "native-tools" method (current trunk chapter5) if it's needed/required/wanted, allowing us to have both ways in one book and allowing to the users to read the book linearlly based on their choosen build way. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Xinclude stuff in cross-lfs
Hi! A new Xinclude approach is now available for review. It can be found into the installation sections of the kernel pages, boot in bootable and reboot chapters. I will wait comments and complaints before to propagate it to the rest of the book. That work as follow: .- Each text block that will be included into other file(s) must have an os="some_string" attribute. "some_string" can be any string. That will allow us to know that some block is included to other file(s) when it will need to be edited or removed. I chosse the "os" attribute because is the most short one, don't have an special use in the stylesheets, and can be defined as an acronym for "Outside Sourced." Example 1: ==chapter/common/package.xml== Block to be included into other file. Block not included anywhere. Another block to be included into other file. .- The "xpointer" attribute of the "xi:include" tag match the exact block that have the defined string value in the "os" attribute, regardless where is placed the requested block into the target file, making the Xinclude stuff possition-independant. Example 2: ==chapter/arch/package.xml== http://www.w3.org/2003/XInclude"; href="../common/package.xml" xpointer="xpointer(//[EMAIL PROTECTED]'abc'])"/> Block not included from/to anywhere. http://www.w3.org/2003/XInclude"; href="../common/package.xml" xpointer="xpointer(//[EMAIL PROTECTED]'123'])"/> = .- The "os" attribute is propagated also. That meant that we can point to text that was also imported on the target file. This will allow us to keep each arch book more self-contained. Example 3: ==other-chapter/arch/package.xml== http://www.w3.org/2003/XInclude"; href="../../chapter/arch/package.xml" xpointer="xpointer(//[EMAIL PROTECTED]'abc'])"/> Block not included from/to anywhere. http://www.w3.org/2003/XInclude"; href="../../chapter/arch/package.xml" xpointer="xpointer(//[EMAIL PROTECTED]'123'])"/> = .- To make edition changes isn't hard. To add a new block or to remove a non-exported one in a file don't have impact on other files. If the removal (full block deletion) or no more inclusion (removing only the "os" attribute) of a previously exported block is required, "make validate" will say what other files must be fixed also (or you can to grep the files for the "os" string value). Lastly, if for example a change in the "arch" stuff implies that the "123" block can't be included anymore from "common" to "arch", will be enought fixing "chapter/arch/package.xml" (Example 2) and, if suitable, removing the "os" attribute from "chapter/common/package.xml" (Example 1), remaining "other-chapter/arch/package.xml" (Example 3) untouched. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Italian localization in lfs-l10n.xml
El Martes, 12 de Julio de 2005 12:19, Claudio Cattazzo escribió: > Hi all, > if you want to add the Italian localization in lfs-l10n.xml, here it is! Many thanks. It will be added soon to the official stylesheets. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: xi:include tags in the cross-lfs book
El Martes, 5 de Julio de 2005 08:39, Alexander E. Patrakov escribió: > I think that the biggest trouble is that xpointer expressions include > some meaningless offset numbers like para[2] instead of assigning a > meaningful name to the exact text to be copied to another page. The more simplest way is using ID attributes: parent.xml--- Text to be xincluded. --child.xml-- The problem: by definition, each ID must be unique into each full book. Then, after do the Xinclude processing the sources will not validate due duplicated IDs. Another way is using a different common DocBook attribute, like "role", if there is no conflicts with its other current uses in the XSL templates. parent.xml--- Text to be xincluded. --child.xml-- Now the problem is, what police should we to use to define in an standardized way that some-unique-strings? Solving that (and the possible conflicts with the stylesheets) it could fix both issues: to be sure that the proper block is always the one that we are importing, and to know beforehand that some block is exported to other file(s). -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: xi:include tags in the cross-lfs book
El Lunes, 4 de Julio de 2005 22:05, Jim Gifford escribió: > I wouln't say it failed, I think we should just keep it architecure > specific. It failed on their current form. The xpointer expesions used aren't useful for moving targets. That is the big issue: if there is a change on the nodes position in the target file, the xpointers that point to that file wll be wrong. > Don't do includes from x86 in MIPS and sparc. I think this is what > Jermey is saying. I see another issue here: how can we know that some text in some file is xincluded into other file? Knowing that some block is xincluded into other(s) files, we will know that other file(s) must be revised after updating the affected block. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: xi:include tags in the cross-lfs book
El Lunes, 4 de Julio de 2005 19:43, Jeremy Huntwork escribió: > I'm not trying to be a stick in the mud here, and Manuel, I do > appreciate all your good work and efforts to make things more fluid, but > after trying to edit the new cross-lfs book several times and *still* > getting lost and turned around and frustrated, I'd really like to see > something different done. All that Xinclude stuff in the installation sections is an experiment, like the profile stuff in the multi-arch branch. Profiling was removed from cross-lfs due that it is a mess when more than 3-4 profiles are involved. Now look like the Xinclude experiment has failed also, at least when we try to Xinclude all possible text/command blocks. But also due that the current xpointers are based on the node absolute position, not on the actual content of the block that should be xincluded. Then, I will go to revert many of the Xinclude tags and try to use another xpointer approach (maybe based on IDs or other attribute) for the remaininig ones. And remember, if something don't work like was expected, it must be changed or removed, no matter how many time someone was invert doing 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS 6.1 schedule
El Lunes, 27 de Junio de 2005 19:53, Matthew Burgess escribió: > Hi folks, > > After a very long delay [1] it looks as if we really are nearly there. > There are two bugs remaining to be fixed (1582 and 1586) which are > simply textual changes. I'll be doing a 6.1 pre-release tomorrow night > (~19:00-20:00 UTC). I'd like to get 6.1 out this weekend, Good :-)) I will start the last PDF review just after that two bugs will be fixed. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Testing (long)
El Sábado, 25 de Junio de 2005 19:16, Archaic escribió: > Hopefully less than 2 weeks. Trying to roll it out before or at the same > time as 6.1 for marketing reasons. IIRC, news items are the only thing > lacking a roll out. The links to translated books are missing also on the new site. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Testing (long)
El Sábado, 25 de Junio de 2005 18:01, Randy McMurchy escribió: > Hi all, > However, my question is this: All that is a know issue that should be adderssed ASAP: http://linuxfromscratch.org/pipermail/lfs-dev/2005-June/051727.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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: new entity - "generic version"
El Jueves, 23 de Junio de 2005 08:24, Archaic escribió: > I made some changes in my WC and created a diff to see if something like > this might be usable and worthwhile. Basically it just keeps us from > having to update the test results link in abouttestsuites.xml. Look a good idea to me. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: XML/HTML question
El Jueves, 23 de Junio de 2005 13:09, Archaic escribió: > In the inputrc page I noticed an tag. In HTML it was > converted to . However, I do not see any > difference in the output of this text. So I looked at the stylesheets > and sure enough, that class isn't listed. > > So now the question is; is this an unneeded tag that should be stripped, > or is this an error in the stylesheets? For LFS the use of is unneeded, IMHO. Currently there is five file in 6.1 and trunk (3 files in cross-lfs) that have that tag. Hasn't been removed yet due that don't have impact on the HTML/PDF look, then having a very low priority in my TODO list. Matt, do you want that tag removed before 6.1 release? Pd: When no more text/command/packages changes will be needed on 6.1, please, notify me to do another PDF review. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org pgp0rVBlbs6F1.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Entities in the cross-lfs book
El Martes, 21 de Junio de 2005 22:49, Archaic escribió: > On Tue, Jun 21, 2005 at 08:21:27PM +0200, M.Canales.es wrote: > > To place entities on the files headers isn't a good idea for LFS, IMHO. > > Please explain what is not good about having all package-specific > entities in one place. To place entities on the files headers (in the XML headers, like in BLFS) isn't a good idea for LFS. More clear now? > > Also, we don't need to declare the new packages.ent file on each XML > > file. Is enouch declaring it in general.ent (the same is valid for > > patches.ent). > > I'm not sure where that came from since I didn't suggest it. Is a comment for when that entities changes will be implemented. If a package.ent file is created, we can declare it in general.ent instead on each XML file (like was done for patches.ent). -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Entities in the cross-lfs book
El Martes, 21 de Junio de 2005 21:42, Jim Gifford escribió: > SBU's are going to be invalid up to chapter 9, chapter 9 will be the > first chapter that we could provide SBU information. I agree. That meant that SBUs could be removed in other chapters, true? > My plan for packages.ent was something simliar to what archaic was > suggesting > > > > > http://url/to/package/official/download"; > > > > The one thing I'm not sure on is if the SBU's will be the same on the > different architectures, I we can to use the same SBU and build size on al archs that would be great. IMHO a desviation < 5 % (or maybe 10%) could be acceptable for both, SBUs and build sizes. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Entities in the cross-lfs book
El Martes, 21 de Junio de 2005 01:56, Archaic escribió: > > A hybrid of something like BLFS does might be nice. However, I don't > like the idea of having package-specific entities spread across multiple > files. Here's an idea for a packages.ent (or even left in general.ent) > file: To place entities on the files headers isn't a good idea for LFS, IMHO. I think that Jim is proposing that new packages.ent to can do packages updates, when no commands changes are needed, editing only the *.ent and changelog files. > > > http://url/to/package/official/download"; > > > > > Some packages, like Glibc and GCC, will require several blocks like that, one for each time that the package is builded. > > > > > The same here, if want SBUs for pre-final-system packages. > Not sure about this. I see more easy to handle patches agrupped by arch, like they are currently in patches.ent. Also, we don't need to declare the new packages.ent file on each XML file. Is enouch declaring it in general.ent (the same is valid for patches.ent). In general that look like a good idea. Could do more easy simple packages updates. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS build method
El Jueves, 16 de Junio de 2005 23:05, Jeremy Huntwork escribió: > 1) If you chose to build on the host system because of its speed, you > get to use that speed for the entire build. That will meant that the user will want to cross-compile also a lot of packages from BLFS, most notably an X Window System, a Windows or Desktop Manager, and other big packages. Then, or BLFS should to change to use also cross-compile instructions, or the user is smart enough to figure out how to build that packages. But it that case the user possibly will know also how to cross-compile a full system without the need of to read the 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS build method
El Jueves, 16 de Junio de 2005 23:05, Jeremy Huntwork escribió: > One drawback is that we'd be cross-compiling every package (which we > don't currently do) and some would need to be hacked a bit to get that > to work. However, it can be done, and it has been done. Another big drawback (at least to me) is that you don't need to cross-compile anything if your host machine arch = target machine arch. In that case, that is the most common one, to create cross-tools is acceptable a maybe needed for purity and isolation from the host system. But to have to cross-compile the full final system look excessive. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
El Jueves, 16 de Junio de 2005 19:28, Archaic escribió: > > Manuel, after he does that, could you BZ this so it isn't forgotten, > please? It isn't really relevant to the discussion at hand but must be > dealt with separately after the current issue is resolved. Sure. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
El Jueves, 16 de Junio de 2005 18:59, Archaic escribió: > On Thu, Jun 16, 2005 at 11:28:40AM -0500, Randy McMurchy wrote: > > Okay, we really need this sorted. > > Randy: SBU changes will throw everything off > Bruce: SBU changes are minor > > I was only holding off due to Randy's concern for the timings, but if it > isn't a big deal, I'd rather the book assumes *all* commands (sans > testsuites) as that is the only was for us to use *one* standard. I am > not loking at this as "This part is really for package X and this part > for package Y" as that is not maintainable without a list of exceptions > explicitly stated in the book. Remember that we will have the issue about how to measure SBUs on cross-lfs (LFS 7.0): http://linuxfromscratch.org/pipermail/lfs-dev/2005-June/051682.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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Typos on X86 package page of cross-lfs book (current svn)
El Martes, 14 de Junio de 2005 21:52, Jay D. McHugh escribió: > There are typos are the URL's for the bzip and texinfo packages. bzip > has two "2"s and texinfo says "textinfo" rather than "texinfo". Fixed, 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS in a rut?
El Lunes, 13 de Junio de 2005 20:18, Jeremy Huntwork escribió: > Especially after editing up a new acknowledgements page (and seeing the > few names that are left associated with LFS) it feels like we might be > right back there again. IMHO one issue is that LFS 6.0 was released on October 06, 2004, seven months ago, and LFS 6.1 (testing) and cross-lfs aren't available on-line on the master server and mirrors. That could bring to the users and visitants the sensation that the LFS Book development is slow and that no more work is done except few packages version updates on the unstable branch, making it not very attractive for potential new collaborators. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: relocation of the sources
El Martes, 7 de Junio de 2005 19:56, Archaic escribió: > from > http://www.linuxfromscratch.org/lfs/view/testing/chapter06/revisedchroot.ht >ml The redaction changes look fine to me. > > This brought up a philosophical debate in my mind. If the book mentions > moving the sources, but then proceeds to move them to a directory where > only root can write, ISTM that this can be mis-interpreted as "you have > to download sources as root to be able to save them". If someone has to > be root to save new sources in the suggested directory then how far is > that from being root to build? > > Apart from this line of thinking, another thought was why does the book > suggest this at all? Is this something that should be left as an > exercise to the reader instead of something that a new reader will > blindly follow (and they most likely will blindly follow)? That is why I > added "if so desired", "If you wish", and "wherever you choose". > > Suggestions? Like sash said, for 6.1 and SVN that page could be moved after kernel installation to avoid confusions. For the new cross-lfs books we can try to do the "rigth thing", i.e., to dowloads the packages and patches as lfs user (like in HLFS) and to build the final system packages as normal user doing only the "make install" as root (like in 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
About SBUs in cross-lfs
Hi ! Due that in the new cross-lfs books is possible to build the temp tools on a different machine than the final system, we can't use any more the first package builded in the book as SBU unit (the Cross Binutils at "Constructing Cross-Compile Tools". Well, actually the first in cross-lfs is Linux-Libc-Headers). Then, I see this roads: .- To remove SBUs. I don't agree but is a possibility. .- To use two SBUs: one for temp tools, based on Cross Binutils, and another for final system, based on (see below). .- To remove SBUs for temp tools. Meassure SBUs only for final system packages based on the build time for the first package builded after the reboot/chroot step. That is my prefered way. That package is Tcl installed in /tools. Currently in LFS-SVN the SBU for Tcl is 0.9. In BLFS-SVN is 0.28 + 0.73 for the test suite. Thus making mandatory to run the test suite on Tcl we can have a SBU unit very similar (if not identical) to the current one. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Thank You - Manuel
El Viernes, 3 de Junio de 2005 21:37, Jim Gifford escribió: > Manuel, > On behalf of the Development team, we would like to thank you for > all your hard work on standardizing the format of the XML files for the > cross-lfs book. We really appreciate it. Thanks to you for start all that stuff that will be the next generation of the LFS books. Actually the work is yet on their first steps. I'm now centered on the indentation, making a few tags changes, small redaction fixes, and some of the Xinclude replacements. After that will began a more closer review of the current text to catch the remaining Xinclude replacements (I hope that the range-to bug will be fixed on the next libxml2 release), obslete or inconsistent text, point-out commands or new procederues that need an explanation, an so on. My idea is to clean and to comment the surrounding text to make more easy for you and the other technical writers the redaction changes needed for all that arch books. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: testing patches
El Miércoles, 1 de Junio de 2005 03:04, Anderson Lizardo escribió: > &lfs-root;patches/lfs/svn/testing/ > > Can some editor do this change? Thanks, Done. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RaQ2 build instructions
El Sábado, 28 de Mayo de 2005 11:53, Matthew Burgess escribió: > > Why not simply list OpenSSH/OpenSSL as host requirements then, and point > folks via a hyperlink to BLFS? That don't seem to me very appropiate, due that aren't host requiremts, but final system requeriments. You need OpenSSH/OpenSSL instaled on a Raq2 server to can login and admin the system. And may have changes on the installation commands. For example, now in RaQ2 we are allowing root logins. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RaQ2 build instructions
El Sábado, 28 de Mayo de 2005 07:46, Archaic escribió: > I would rather see a link in the book referring to the blfs pages as I > don't think we should be catering to such odd harware configurations. > That is no different than writing the book with the explicit goal of > being able to fully do a remote build with no changes to what the book > lists. Like Jim said, we don't have now an unique LFS book, but several LFS books, one for each arch, that shares several base info from common XML source files (package description, dependencies, contents, etc..). Each book has their own characteristics based on the target arch: different patches and build commands in some cases, but also different packages version or addition/removal of some packages when needed by the target arch typology. And like Jim said also, I have in mind to find a way to include those BLFS packages needed only for few archs directly from the BLFS sources (except actual build commands, if they must to be different). That is one of the reasons wy I'm trying to unifiy the tagging used on both projects, to can have the same look on imported files. That cuold be usefful also for HLFS, where we actually have several BLFS packages ;-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Viernes, 27 de Mayo de 2005 21:08, Jim Gifford escribió: > http://documents.jg555.com/cross-lfs/x86/reboot/whatnext.html, "Object not found" But reading the XML file, that look sensible to me. 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Viernes, 27 de Mayo de 2005 16:52, Archaic escribió: > Attempts to support building where > host!=target is hints territory as there are just too many variables for > a linear based book to contend with. That's also my point. In resumen: Cross-build techniques are good. To reboot using the temp tools is good, noticing that when host(machine+arch)=target(machine+arch) we can to use the old chroot way, if dessired. To try to solve the question "How can I boot my target machine when host-machine!=target-machine?" into the book is bad. We can't test all possible combinations and scenarios, and there isn't an unique solution that can work for all. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Jueves, 26 de Mayo de 2005 23:03, Jim Gifford escribió: > Matt, that was one of the purposes of the cross-lfs was the > multi-architecture build, the reboot section is needed. I have it > working and have been making the changes. It's just at the reboot point > where there seems to be an issue. IMHO the issue is try to say into the book how to the user must to use the temp tools compiled on the host machine to boot the target machine, due that we don't know the available hardware or if the user has physical acces to both machines. We can point out different solutions without discuss full details, but the user is in their own to handle that. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Jueves, 26 de Mayo de 2005 22:11, Archaic escribió: > On Thu, May 26, 2005 at 04:05:41PM -0400, Jeremy Huntwork wrote: > > After spending some time on the "reboot" section, I think it's a mistake > > to include any of that extra stuff in the book. Esp. when it still seems > > that more will be taking the chroot path anyway. > > Exactly what I was saying... I see two different issues here. One is to build the temp tools in one machine using they to boot the target machine and build then the final system. IMHO, there is few (or none) cases where that will be actually required. The other is to reboot the current machine using the temp tools to build the final system, instead to chroot. That look like a good way to build, for example, a 64 bits O.S from a 32 bits host O.S. Then, for me to have a "reboot" way is fine, but try to support "build in one machine to boot other machine" into the book is a bad 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: XML changes in cross-tools
El Miércoles, 25 de Mayo de 2005 01:11, Jim Gifford escribió: > M.Canales.es wrote: > >.- To add all possible XInclude tags to avoid duplicated text before to > > start updating the arch-specific text redaction. I will use the next > > rules: > > I tried to do that were possible, ran into some issue we can talk about > those. Well, in some cases to find the proper xpointer path could be hard. And we are yet moving/copying files to the archs directories, breaking the existent xpointers. > I'm not sure how we are going to approach the SBUs issue. I personally > think they should be eliminated I was thinking also on that. Now we can't use the cross-binutils build time as SBU unit due the possibily that this package will be compiled on a different machine than the fiinal system. Then, how to meassure SBUs for final system packages? But to full remove SBUs we need also the BLFS editors agreement. > I tried to merge all the changes as Matt has done them, so you may want > to check them before you change them. I'm aware that several typo fixes has been already ported. But I want to be sure that no one is missed before to merge this branch to trunk ;-) Like in BLFS, I will do the commits file-by-file to try to avoid conflicts. But in this case to follow an alphabetical order isn't usefull due that we need to have ready first the master files to can adjust the xpointer paths. Then, I will start on the final-system/ directory following build order. Then the other directories in book order. Inside each top-level directory (incuding the final-system/ one), the order will be: common, x86, multilib, ppc, raq2, sparc, sparc64, x86_64. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
XML changes in cross-tools
Hi! I'm thinking to start soon the following XML changes on the cross-tools branch, if there is no complaints: .- Sources indentation. Like the current one in BLFS. .- Some fixes and small changes in the tagging. .- To add all possible XInclude tags to avoid duplicated text before to start updating the arch-specific text redaction. I will use the next rules: For packages, the master source file will be the ones under final-system/common. If the package isn't here, then using the final-system/x86 one. If the package is arch-specific, then using final-system/[arch]. For non-package files, the master source file will be the one under [dir]/common. If the file isn't here, then using [dir]/x86. .- To change all "Space used" and "SBUs" values by "Not checked yet" .- To add placeholders to discuse new build commands and to remove obsolete command explanations. .- To sinchonize the text with the current one in trunk to don't lost the several typos fixes doned after multi-arch branch creation. What do you think? -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Sábado, 14 de Mayo de 2005 16:23, Jim Gifford escribió: > It depends on your setup, we would have to create a netboot floppy. Take > a look at http://gentoo-wiki.com/HOWTO_Gentoo_Diskless_Install From that page: "Booting the client Now, just boot the client. Configure the bios and the network card to use PXE in first to boot (before CD-ROM or floppy). " Then, you need physical acces to the client to can configure the BIOS and the network card. Plus, that look hint material, not book material. Several extra dependecies and host requeriments are needed to can create that setup. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Sábado, 14 de Mayo de 2005 15:43, Ken Moffat escribió: > > I think I've got a third - machines that can run a 32-bit or a 64-bit > system (i.e. x86_64 or ppc64) that are currently running 32-bit (i686 or > ppc). It's easy enough to install current 32-bit LFS on them, upgrading > to multilib should be educational (I'm trying at the moment, learning a > lot about the toolchain so far, but a very long way from completing). But in that case you already have a linux system running on that machine, then you could do the full mulltilib build on the target. Don't miss the point of this thread: Is there realy some case where you must to build the packages up to "reboot" in one machine (the HOST) and then to copy that temp system to other machine (the TARGET) to build the final system? -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Sábado, 14 de Mayo de 2005 07:36, Jim Gifford escribió: > My idea is the netboot thing. Since all the bootloaders in question will > work with NFS or TFTP booting. Could you explain that in detail? I'm not sure but IMHO, to can boot from net the BIOS must be configured first to allow it, and that implies to have physical acces to the 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Sábado, 14 de Mayo de 2005 01:42, Archaic escribió: > Ideas? Comments? Suggestion? We need your input. Multiple perspectives > ultimately make for a better book. The above is merely my perspective > and likely does not cover all aspects needed to make a good decision. There is some aspects that I don't fully understand yet. If the target host (remote or local) is a machine running linux, wy not to do the full construction from the begin directly at the target machine? In that case HOST=TARGET due that both are the target machine. A question, when the target host is a remote machine not running linux, how do you manage it to install any other linux distro? Lastly, IMHO the combo HOST != TARGET only is usefull in two cases: To build a full system (with X, servers, etc...) in a fast machine that will be later instaled in a slow machine. Or to build a minimal system to can boot a machine that have no system instaled yet. But in that case you must have physical acces, then you can use also a BooCD to boot the machine and to install LFS using HOST=TARGET. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Typos and Phrasing -- Request
El Sábado, 14 de Mayo de 2005 00:16, Archaic escribió: > As we discussed on IRC, it can still be done without any historical > loss, but it will require a lot of manual fiddling. However, as this is > a one time thing, I think we'd be shooting ourselves in the foot > researching a way to automate instead of just doing it. This is > predicated on the fact that the only automated solution recommended by > the SVN devs has failed and further research will take quite some time. Revising the webcvs I noticed that the historial is already loss in the cross-lfs branch due the big changes in the book structure. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Typos and Phrasing -- Request
El Viernes, 13 de Mayo de 2005 00:07, Matthew Burgess escribió: > Yeah, I thought as much. I just don't want those changes getting lost, > and I'm not quite sure how we're going to migrate the cross-lfs stuff to > trunk when we get to that stage. I think that the migration could be done without lost all the historial, but need to be very well planified and doing some previous test merges into a brach. I.e, dowload a new working copy of trunk, merge the multi-arch svn diff from their revision creation up to the revsion of the creation of cross-lfs, merge the the cross-lfs svn diff from their creation revion until now, and see what happend ;-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Editor's Manual
El Lunes, 9 de Mayo de 2005 23:14, Matthew Burgess escribió:
> chapter03/checkout.xml
>
> "lfs-book" isn't really a "filename", but I don't know what tag is most
> appropriate for a mailing list! This also occurs in chapter03/diff.xml
> with "lfs-dev" inside "userinput" tags. Whatever we pick, we'll have to
> be consistent :)
[EMAIL PROTECTED]/email}
or
{systemintem class="newsgroup"}lfs-dev{/systemitem}
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Acronyms
El Lunes, 9 de Mayo de 2005 21:19, Randy McMurchy escribió: > My point being that the tags are in the book, they may be useful one > day. Why are we removing them? > > What is the harm in them being there? http://archives.linuxfromscratch.org/mail-archives/blfs-book/2005-April/013052.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.com 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: Multi-arch/Cross-lfs discussion -- Book Structuring
El Domingo, 8 de Mayo de 2005 22:47, Jim Gifford escribió: > We have been talking about different formats for the different books, I > was thinking and wondering if it was possible to do the following. Created a bug to address that: http://bugs.linuxfromscratch.org/show_bug.cgi?id=1075 Please, use that bug to made related proposals, comments or suggestions (links to lfs-dev threads are fine, of course). I will start working on that ASAP, after finish the current BLFS changes, but need many inputs and new ideas from all you. At this moment I can see the need to do the changes, but I'm not sure yet how that could be done. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Editor's Manual
El Sábado, 7 de Mayo de 2005 19:54, Jeremy Huntwork escribió: > M.Canales.es wrote: > > Many thanks for start that work :-) > > No problem, I sure could use your help though ;) Very busy now reformating the BLFS sources. But I need to add the tags & attributes use policies to explain the Index stuff, the use of arch="XX", how to tag a final PDF version, XSL tips, 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Editor's Manual
El Sábado, 7 de Mayo de 2005 17:45, Jeremy Huntwork escribió: > Take a look: > > http://linuxfromscratch.org/~jhuntwork/editor-manual/ > Many thanks for start that work :-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS 64-bit decisions
El Viernes, 6 de Mayo de 2005 20:43, Jeremy Huntwork escribió: > So, in a nutshell, my opinion is that we should do multilib as a default > for 64-bit archs with /lib and /lib64 directories. > > This has not yet been decided on for the book (which is why I'm asking > this question here), so if you have an opinion or comment on the above, > *please* reply here. We *need* your feedback in order to make a decision. Is there some "de facto" standard used by commercial distros? -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Rendering of multi-arch books
El Viernes, 6 de Mayo de 2005 17:34, Jeremy Huntwork escribió:
> Proposed setup:
>
> multi-arch
>
>|_Common
>|
>| |_Entire Book (defaults)
>|
>|_Arch1
>|
>| |_Symlinks to ../Common if nothing arch specific
>| |_Arch-specific pages
>|
>|_Arch2 (You get the idea, same as above)
>
> Hopefully the above comes through ok. Manuel, any thoughts?
That is the ideal setup for XHTML output (but not for PDF output) IF the
number of common pages is significant and IF we can find or develop and
XML/XSL framework that could generate that hierarchy without break the PDF
output.
For the first "IF" we don't know yet what will be the real number of common
pages and where will be they located.
If, for example, the common pages are all together at the beginning of the
book, then maybe with to change the master {book} to {set}, to create a
{book} for that common pages, and to add the required {book arch="XX"} for
the rest could be enougth.
But if the common pages are missed along the book, then there is two problems
to be solved:
First, to create a profiling engine that, instead to remove from the output
the undesired marked blocks like it do now, will generate a separate page for
each arch into their own dirs containing only the related text for each arch.
And second, to generate the TOCs and navigational links properly to can read
each arch book linearly based in that new pages locations.
Nothing impossible, I think, but very difficult to implement.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: New Cross-LFS book - what about the printed version?
El Viernes, 29 de Abril de 2005 10:30, steve crosby escribió: > The question is, with the new multi-choice cross-lfs book being worked > on, how are we planning on producing a hardcopy version? Questions > regarding the "linear" flow of the book are resolved by using smart > XML processing, but I've yet to see that technology in paperback ;) For now the approach is that each arch will have their own PDF version. IMHO, that is the most logical way for personal use. If you want to print the book at your home, is most likelly that you will want to print only that pages/commands really needed for you. > If no-one has considered it, I'd like to suggest the use of > pageheading "graphics" which the user can follow, depending on their > target configuration. > > i.e. If building for sparc, you would use the sections in the book > (linearly) that have either the "sparc" graphic, or the "all" graphic > in the section heading. That could be considered when making another hardcopy version. But in that case the final word is for Gerard and the publisher. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: multiarch Makefile ignores CHUNK_QUIET=1
El Lunes, 25 de Abril de 2005 01:41, Anderson Lizardo escribió: > Hi Manuel, > > The multiarch Makefile seems to ignore the CHUNK_QUIET=1 parameter so > the cronjob which runs the render script always mails the output. Can > this be fixed? Oppss, removed accidentally in one of the big Makefile changes to render multiple books. It should be fixed now. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Spacing in the NFS Utilities
El SÃbado, 23 de Abril de 2005 18:04, Bruce Dubbs escribiÃ: > > .- To change template.xml to reflect that policies. > > That can be done now to reflect the edguide. If anyone sees issues, > they should be discussed on the list. Done. > > .- To adapt the XSL/CSS code to have the same look with the old and new > > tagging. > > That is where we are now. Done. Added also support to can change the look for commands executed as root. > > .- To make the changes in the sources. > > After the proposed changes have been finalized. Retagged nfs-utils.xml as a POC of the new tagging. -- Manuel Canales Esparcia Usuario de LFS nÂ2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com 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: Spacing in the NFS Utilities
El SÃbado, 23 de Abril de 2005 18:04, escribiÃ: > > Yes, due an improper pattner selector in the CSS code. > > That's what I figgured, but I didn't have the time to check it out. Thae fix is easy, I have it ready. > We've got a tentative policy in the edguide. It has been updated, but > we don't wnt to make wholesale changes quite yet. OK. That is wy I'm not doing editions yet, until have finished the policies. > That can be done now to reflect the edguide. If anyone sees issues, > they should be discussed on the list. Making the template update... > > .- To adapt the XSL/CSS code to have the same look with the old and new > > tagging. > > That is where we are now. Yes. I will commit it with the new template. > > .- To make the changes in the sources. > > After the proposed changes have been finalized. Of course ;-) -- Manuel Canales Esparcia Usuario de LFS nÂ2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org pgpcTVBXz5SvU.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Planning for Cross-LFS/Multi-Architecture 7.x Release
El Lunes, 18 de Abril de 2005 23:03, Jim Gifford escribió: > There are a few pitfalls to this. Another one: when you reboot you're alone. No mail, no web, no IRC, no possibility to ask for help if something go bad while building the new system. But well, I want multi-arch capabilities, I want cross-build techniques, I want the most professional and educational book that we could do, and I want that the user could choice how to build their systems. Is the recommended method to reboot to build the final system?. Yes. Is possible to use the chroot method for uni-arch builds?. Yes. Then, IMHO, we only need to solve how to integrate both build ways into one book and let the user to decide what to use based in their needs. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc-4.0 branch created
El Domingo, 17 de Abril de 2005 20:34, Andrew Benton escribió: > Err...following that link leads to a copy of the book that seems to be > building with gcc-3.4.3...shurely shom mishtake? Not mistake. The structure is ready but the GCC-4.0 changes hasn't been commited 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.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Change to 25-lfs.rules
El Sábado, 16 de Abril de 2005 01:14, John Gnew escribió: > > What do I need to do to get this change made in LFS? (provided everyone > goes along with the change) > > John Gnew I can run glxgears having this permissions: [EMAIL PROTECTED]:~$ ls -l /dev/nvidia* crw-rw 1 root video 195, 0 2005-04-15 17:40 /dev/nvidia0 crw-rw 1 root video 195, 255 2005-04-15 17:40 /dev/nvidiactl writeables. Is more easy (and secure) to add the user to the video group that to make the devices world writeables. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Typos
El Miércoles, 13 de Abril de 2005 06:17, Peter Ennis escribió: > Linux From Scratch - Version SVN-20050411 > > 1. Foreword > My adventures in Linux began six years ago ... > s/six years ago/in 1999 ??? Revising the file historial look like it should be 1998. > s/Such custom-built LFS systems not only to meet user specifications > and requirements, but also serve as/Such custom-built LFS systems > serve not only to meet user specifications and requirements, but also > as Or, maybe, "Such custom-built LFS systems not only meet user specifications and requirements, but also serve as ..." Matt, could you handle that two typos? Or point to me in the right direction. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
Matthew Burgess escribió en lfs.dev el Viernes, 1 de Abril de 2005 20:48:
> M.Canales.es wrote:
>
>> d) Is a PDF look fix ;-)
>
> Of course. I will trust anything from anyone (as long as their name is
> Manuel :)) that touches stuff in the stylesheets/ directory as there is
> some serious black-magic juju going on in there :) However, rule c)
> still applies - i.e. if the fix is common to both trunk and the 6.1
> branch, then trunk gets the fix first and it gets merged to the branch
> afterwards.
The changes will be in the XML, not the XSL. Bassically the readdition of
{beginpage/} tags, some URL splits and like.
That stuff in suitable only for released versions, when no more textual
changes will be made. Idealy that should be the last commits before create
tag/6.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.com
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: 6.1 release branch
Matthew Burgess escribió en lfs.dev el Viernes, 1 de Abril de 2005 20:22: > > Editors: Please *do not* commit to this branch unless: > > a) It's an obvious typo/spelling mistake > b) It fixes a problem reported against the 6.1 branch either on the > mailing lists or bugzilla > c) The fix has already been applied to trunk/, and therefore the fix is > just an 'svn merge' of the exact same change back onto this branch. d) Is a PDF look fix ;-) I will start that work the day 9 (I'm very busy at this moment doing the BLFS-6.0 translation). -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Update to the INSTALL file
Randy McMurchy escribió en lfs.dev el Lunes, 7 de Marzo de 2005 15:36:
> Attached you'll find a diff that will update the INSTALL file. Changes
> are as follows:
Thanks. Updating it now in {H}LFS.
--
Manuel Canales Esparcia
Usuario de LFS nº 2886: http://www.linuxfromscratch.org/
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com
TLDP-ES http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Docbook and XSL
Matthew Burgess escribió en blfs.dev el Sábado, 5 de Marzo de 2005 18:18: > Also see > http://lists.oasis-open.org/archives/docbook-apps/200503/msg00024.html > which mentions a bug in the latest version. And there is another problem with the new default param values and FOP: [ERROR] Error in relative-align property value 'baseline': org.apache.fop.fo.expr.PropertyException: No conversion defined That error is showed a lot of times. -- Manuel Canales Esparcia Usuario de LFS nº 2886: http://www.linuxfromscratch.org/ LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
