[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
Re: [RFC] Bootscript changes
Dan Nicholson wrote: http://wiki.linuxfromscratch.org/lfs/changeset?format=diffnew=7962old=7931new_path=trunk%2Fbootscripts%2Flfsold_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: [new XSL] Ready for inputs.
El Lunes, 9 de Abril de 2007 22:19, Bruce Dubbs escribió: [EMAIL PROTECTED]/new-xsl]$ make pdf xsltproc --xinclude --nonet --output ~/lfs-book/lfs-pdf.fo \ stylesheets/lfs-pdf.xsl index.xml xsl:attribute-set : use-attribute-sets recursion detected Making portrait pages on USletter paper (8.5inx11in) runtime error: file stylesheets/pdf/lfs-mixed.xsl line 255 element choose xsl:choose: unexpected content attribute I don't see anything wrong with stylesheets/pdf/lfs-mixed.xsl unless the xsl:otherwise on line 271 is out of place. Right, the tag is out of place but my xsltproc don't show that errors :-?? new-xsl$ make pdf xsltproc --xinclude --nonet --output ~/lfs-book/fop1-lfs-pdf.fo \ stylesheets/lfs-pdf.xsl index.xml Making portrait pages on USletter paper (8.5inx11in) sed -i -e 's/span=inherit/span=all/' ~/lfs-book/fop1-lfs-pdf.fo FOP_HOME=~/cosas/fop-0,93 ~/cosas/fop-0.93/fop ~/lfs-book/fop1-lfs-pdf.fo ~/lfs-book/fop1-LFS-BOOK.pdf new-xsl$ xsltproc --version Using libxml 20627, libxslt 10120 and libexslt 813 xsltproc was compiled against libxml 20627, libxslt 10120 and libexslt 813 libxslt 10120 was compiled against libxml 20627 libexslt 813 was compiled against libxml 20627 After fixed the tag, is the xsl:attribute-set : use-attribute-sets recursion detected warning still showed? I think that that is a different bug. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 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: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.
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 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 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 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: 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
