Re: Default filesystem
Fix escribió: > On 4/9/07, Ismael Luceno <[EMAIL PROTECTED]> wrote: > >> My system is somewhat deviated, so a normal LFS may take a bit more, >> but the gettys/dm will be up as soon as possible, that's the beauty >> of initng, it does it without any effort :). > > InitNG is great __idea__. However, I know two men at least, who tried > to use it on a LFS system with no success. Can't you help, please? > The problems come from our scripts, not InitNG itself, we want to drop them, maintaining generic scripts is a big trouble, and they aren't as fast as they could be, because of the generic-ness :(. I can help to find the bugs in our scripts, but i prefer to have scripts specific for lfs. -- Ismael Luceno <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> InitNG maintainer and project lead - http://www.initng.org Registered Linux User #439653 - http://counter.li.org LFS User #17162- http://www.linuxfromscratch.org SourceMage GNU/Linux User - http://www.sourcemage.org IRC: ismaell @ irc.freenode.net #initng #uruguay #cross-lfs Jabber ID: [EMAIL PROTECTED] Blog: http://ismaell.wordpress.com GPG Key ID: EC8E5C9A GPG Key Fingerprint: 1356 7578 232E CCA6 D16D 46A8 FE6C 58D3 EC8E 5C9A signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Martes, 10 de Abril de 2007 22:02, Bruce Dubbs escribió: > > Looking at the output, all my issues have been addressed nicely with the > exception of the font-family/font-style of the titles. That's not very > important, but may be a nice tweak. At my end there is yet an issue to be solved: let very long screen block to split on several pages. Not an issue for LFS (except if selecting a smaller paper size), but will be at least for the compressdoc.sh script in BLFS. About fonts, at this momment the one used is TimesRoman (sans-serif is an alias to it). We could change body.font.family and/or title.font.family to Helvetica and/or Courier to see if there is other combinations with a better look. More info in http://www.sagehill.net/docbookxsl/Typography.html -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
M.Canales.es wrote: > El Martes, 10 de Abril de 2007 19:41, M.Canales.es escribió: > >> Might be a bug in current libxml or libxslt. >> > > After several versions changes and research looks that actually was a bug in > old libxslt versions that was not merging properly xsl:attribute-set settings > when the same one is found on two files with different import precedence. > > It was fixed in libxslt-1.1.17. Confirmed. [EMAIL PROTECTED]/new-xsl]$ time make pdf xsltproc --xinclude --nonet --output ~/lfs-book/lfs-pdf.fo \ stylesheets/lfs-pdf.xsl index.xml Making portrait pages on USletter paper (8.5inx11in) sed -i -e 's/span="inherit"/span="all"/' ~/lfs-book/lfs-pdf.fo fop ~/lfs-book/lfs-pdf.fo ~/lfs-book/LFS-BOOK.pdf rm ~/lfs-book/lfs-pdf.fo real1m2.429s user0m57.480s sys 0m1.049s [EMAIL PROTECTED]/new-xsl]$ xsltproc --version Using libxml 20627, libxslt 10120 and libexslt 813 xsltproc was compiled against libxml 20627, libxslt 10120 and libexslt 813 libxslt 10120 was compiled against libxml 20627 libexslt 813 was compiled against libxml 20627 Looking at the output, all my issues have been addressed nicely with the exception of the font-family/font-style of the titles. That's not very important, but may be a nice tweak. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Martes, 10 de Abril de 2007 19:41, M.Canales.es escribió: > > Might be a bug in current libxml or libxslt. > After several versions changes and research looks that actually was a bug in old libxslt versions that was not merging properly xsl:attribute-set settings when the same one is found on two files with different import precedence. It was fixed in libxslt-1.1.17. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
M.Canales.es wrote: > El Lunes, 9 de Abril de 2007 22:50, Bruce Dubbs escribió: >> OK, I made some changes. See what you think. > > In admonitions, that make all types having almost the same look. Both #E0E0E0 > and #EEE are near identical. This was intentional. I wanted to remove the border, but thought it was easier to make the border color the same as the background. > What about this value? #DCC Perhaps that would work. I haven't looked and have an "emergency" at work. Perhaps I can look at this later. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Lunes, 9 de Abril de 2007 22:50, Bruce Dubbs escribió: > OK, I made some changes. See what you think. In admonitions, that make all types having almost the same look. Both #E0E0E0 and #EEE are near identical. What about this value? #DCC On verbatim, using #EEE is like removing the border. Try with this: #888 I could accept also to not have a border in verbatim chaded blocks. PD. I'm trying to find the most updated libxml/libxslt versions combo that outputs the attribute-set warning... -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Martes, 10 de Abril de 2007 19:29, Bruce Dubbs escribió: > Mine is slightly older: > > $ xsltproc --version > Using libxml 20622, libxslt 10115 and libexslt 812 > xsltproc was compiled against libxml 20622, libxslt 10115 and libexslt 812 > libxslt 10115 was compiled against libxml 20622 > libexslt 812 was compiled against libxml 20622 > > Do you think that this should matter? Might be a bug in current libxml or libxslt. The issue is that we have an xsl:attribute-set that is calling itself via an xsl: use-attribute-sets attribute (directly or indirectly). That at least increase parse time due recursion and could afect the output look in unknow ways :-/ Going to research... -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
M.Canales.es wrote: > El Lunes, 9 de Abril de 2007 22:19, Bruce Dubbs escribió: > > Right, the tag is out of place but my xsltproc don't show that errors :-?? > > new-xsl$ make pdf > xsltproc --xinclude --nonet --output ~/lfs-book/fop1-lfs-pdf.fo \ > stylesheets/lfs-pdf.xsl index.xml > Making portrait pages on USletter paper (8.5inx11in) > sed -i -e 's/span="inherit"/span="all"/' ~/lfs-book/fop1-lfs-pdf.fo > FOP_HOME=~/cosas/fop-0,93 && ~/cosas/fop-0.93/fop ~/lfs-book/fop1-lfs-pdf.fo > ~/lfs-book/fop1-LFS-BOOK.pdf > new-xsl$ xsltproc --version > Using libxml 20627, libxslt 10120 and libexslt 813 > xsltproc was compiled against libxml 20627, libxslt 10120 and libexslt 813 > libxslt 10120 was compiled against libxml 20627 > libexslt 813 was compiled against libxml 20627 Mine is slightly older: $ xsltproc --version Using libxml 20622, libxslt 10115 and libexslt 812 xsltproc was compiled against libxml 20622, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20622 libexslt 812 was compiled against libxml 20622 Do you think that this should matter? > After fixed the tag, is the "xsl:attribute-set : use-attribute-sets recursion > detected" warning still showed? I think that that is a different bug. Yes, with the patch I sent earlier, I still got that as a warning, but it didn't affect the output. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Bootscript changes
On Tue, Apr 10, 2007 at 09:40:56PM +0600, Alexander E. Patrakov wrote: > Dan Nicholson wrote: > > 1. Make statusproc() return unsuccessfully if the process isn't running > > +1 +1 here too. > > 2. Make statusproc() use pidofproc() instead of the deprecated getpids() > > +1 +10 here. We shouldn't be using deprecated functions at all, if you ask me. (Of course no one did, at least not directly. :-P) > > 3. Allow the -p pidfile argument to all *proc() functions > > +1 Yep, +1 here too. > > 4. Add the /sbin/service script to allow an agnostic way to query the > > bootscripts > > +0 I don't have any strong feelings either way. I always thought of the service program/script as a RH-specific thing, but if one of HAL's dependencies is using it, then it's probably a bit more widespread. (And regardless of what I think, if it's a requirement of a package that we support in BLFS, we should have it somewhere. Whether that's in LFS or BLFS could be up for debate. I'd say it'd be useful to have it in LFS if we have it at all.) > 5. Apply the patch from > http://linuxfromscratch.org/pipermail/lfs-dev/2006-October/058454.html - > also needed for hibernation on the LiveCD when the non-standard > implementation of the PPPoE network service is used. Assuming that's still needed, +1. pgpLj7mK7E7oj.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Spam in trac tickets
On Sunday 08 April 2007 02:05, Bruce Dubbs wrote: > Jeremy Huntwork wrote: >... >You are right about the registration. Anyone can register and then spam > away on both the lfs and blfs trac ticket systems. About the only thing > I can think of is to require an admin to verify and explicitly allow the > creation or update capabilities for new registrations. Hmm, what about a captcha? I dont know how hard it would be to patch such a functionality into trac - but it would have very good results, I believe. I added a captcha to a mail form on my home page and the amount of spam i received from bots filling the form tends to zero - no, it *is* zero. -- Thomas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Lunes, 9 de Abril de 2007 22:19, Bruce Dubbs escribió: > [EMAIL PROTECTED]/new-xsl]$ make pdf > xsltproc --xinclude --nonet --output ~/lfs-book/lfs-pdf.fo \ > stylesheets/lfs-pdf.xsl index.xml > xsl:attribute-set : use-attribute-sets recursion detected > Making portrait pages on USletter paper (8.5inx11in) > runtime error: file stylesheets/pdf/lfs-mixed.xsl line 255 element choose > xsl:choose: unexpected content attribute > I don't see anything wrong with stylesheets/pdf/lfs-mixed.xsl > unless the on line 271 is out of place. Right, the tag is out of place but my xsltproc don't show that errors :-?? new-xsl$ make pdf xsltproc --xinclude --nonet --output ~/lfs-book/fop1-lfs-pdf.fo \ stylesheets/lfs-pdf.xsl index.xml Making portrait pages on USletter paper (8.5inx11in) sed -i -e 's/span="inherit"/span="all"/' ~/lfs-book/fop1-lfs-pdf.fo FOP_HOME=~/cosas/fop-0,93 && ~/cosas/fop-0.93/fop ~/lfs-book/fop1-lfs-pdf.fo ~/lfs-book/fop1-LFS-BOOK.pdf new-xsl$ xsltproc --version Using libxml 20627, libxslt 10120 and libexslt 813 xsltproc was compiled against libxml 20627, libxslt 10120 and libexslt 813 libxslt 10120 was compiled against libxml 20627 libexslt 813 was compiled against libxml 20627 After fixed the tag, is the "xsl:attribute-set : use-attribute-sets recursion detected" warning still showed? I think that that is a different bug. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Bootscript changes
Dan Nicholson wrote: > http://wiki.linuxfromscratch.org/lfs/changeset?format=diff&new=7962&old=7931&new_path=trunk%2Fbootscripts%2Flfs&old_path=trunk%2Fbootscripts%2Flfs > > Can you check if these are the same issue? I will do this tomorrow, thanks for the link. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Bootscript changes
On 4/10/07, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: > > 5. Apply the patch from > http://linuxfromscratch.org/pipermail/lfs-dev/2006-October/058454.html - > also needed for hibernation on the LiveCD when the non-standard > implementation of the PPPoE network service is used. I recently added a fix for a bug in pidofproc -p. I can't tell if this is the same issue, but I've been using killproc -p successfully for a while now: http://wiki.linuxfromscratch.org/lfs/changeset?format=diff&new=7962&old=7931&new_path=trunk%2Fbootscripts%2Flfs&old_path=trunk%2Fbootscripts%2Flfs Can you check if these are the same issue? The problem I was seeing was the the -p was basically doing nothing because of a broken shell test in pidofproc and falling back to killing all processes by that name. I suspect that the patch in that mail is working around this issue. Hmm, it looks like both patches might be needed. I can't tell what killproc is trying to do in that section. It looks wrong to test for $killsig in that if since it has nothing to do with whether the process is still running or not. Hopefully DJ or Nathan will chime in. If not, I have an idea of the right way to fix it. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Bootscript changes
Dan Nicholson wrote: > I've been digging around in the bootscripts a little more lately, and > I've found some behavior that I think could be changed and I'd like > comments on. I can provide patches later, but first I thought I'd like > to hear comments. > > 1. Make statusproc() return unsuccessfully if the process isn't running +1 > 2. Make statusproc() use pidofproc() instead of the deprecated getpids() +1 > 3. Allow the -p pidfile argument to all *proc() functions +1 > 4. Add the /sbin/service script to allow an agnostic way to query the > bootscripts +0 > This is not an original idea. I think all the major distros do this > (Fedora and SuSE for sure), although it's not an LSB requirement. Debian doesn't do this 5. Apply the patch from http://linuxfromscratch.org/pipermail/lfs-dev/2006-October/058454.html - also needed for hibernation on the LiveCD when the non-standard implementation of the PPPoE network service is used. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[RFC] Bootscript changes
I've been digging around in the bootscripts a little more lately, and I've found some behavior that I think could be changed and I'd like comments on. I can provide patches later, but first I thought I'd like to hear comments. 1. Make statusproc() return unsuccessfully if the process isn't running Right now, statusproc always returns successfully with a list of pids for the requested process name or a message saying that it's not running. I think it would be more helpful to have it return unsuccessfully if there are no processes by that name running. In order to do this right now, I need to parse the output. This is a one line fix. Basically, I want to do something like this from a script: if /etc/rc.d/init.d/process status >/dev/null; then /etc/rc.d/init.d/process restart fi 2. Make statusproc() use pidofproc() instead of the deprecated getpids() statusproc is using getpids, which has been marked as deprecated in the functions. I think all the *proc functions should be calling pidofproc for consistency. 3. Allow the -p pidfile argument to all *proc() functions statusproc does not allow the pidfile argument to be passed in. This goes along with 2. getpids will respect the variable PIDFILE, but it should also allow the -p argument like loadproc and killproc and pass it on to pidofproc. 4. Add the /sbin/service script to allow an agnostic way to query the bootscripts This one might be more controversial. To run the bootscripts, you need to know the implementation detail about where they are, particularly the info in /etc/sysconfig/rc. Ideally, there should be an agnostic way to run these bootscripts without any prior knowledge of how LFS has set them up. This is not an original idea. I think all the major distros do this (Fedora and SuSE for sure), although it's not an LSB requirement. Where I got the idea is from the pm-utils project. This project is a dependency of newer HAL releases which tries to provide a distro-neutral way to run power management functions for suspend/hibernate/etc. Part of these processes is stopping/starting system services like ntpd. In order to do this with any sanity across multiple distros, there has to be an agnostic way to run services. Here is a mailing list thread discussing the /sbin/service approach, the pm-utils functions where service or its fallback are defined (search for service), and an example usage of service in pm-utils: http://lists.freedesktop.org/archives/pm-utils/2007-March/000383.html http://webcvs.freedesktop.org/pm-utils/pm-utils/pm/functions?view=markup http://webcvs.freedesktop.org/pm-utils/pm-utils/pm/hooks/90clock?view=markup While this is only one specific case where a service wrapper could be used, it seems like a smart idea in my opinion to hide distro-specific implementation details where possible. I've attached the very simple version that I came up with and has been working for me. Basically, it just sources /etc/sysconfig/rc and then wraps the call to the bootscript. The result can be something like this: /sbin/service clock start Let me know what you guys think. -- Dan service.sh Description: Bourne shell script -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
