Re: svn bootscripts
Jeremy Huntwork wrote: > On 5/31/11 2:21 AM, DJ Lucas wrote: >> On 05/30/2011 12:34 PM, Bruce Dubbs wrote: > I'd appreciate it if you could do a revert. >> Done. > > So where are we standing with this currently? What's left to do and > what's the intended path? > > I know what I want to happen with LightCube, but I'd like to determine > if I should use your scripts as an upstream package as they are, > maintain a patch of changes, or fork completely. I finally got some time. I'll take a look at this when I finish the 3 packages I'm trying to upgrade right now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 5/31/11 2:21 AM, DJ Lucas wrote: > On 05/30/2011 12:34 PM, Bruce Dubbs wrote: I'd appreciate it if you could do a revert. > > Done. So where are we standing with this currently? What's left to do and what's the intended path? I know what I want to happen with LightCube, but I'd like to determine if I should use your scripts as an upstream package as they are, maintain a patch of changes, or fork completely. Thanks in advance, JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On Tue, 31 May 2011 21:55:37 -0500 Bruce Dubbs wrote: > Jeremy Huntwork wrote: > > I'm not sure I understand the objection to C. It's not really that > > difficult to understand or maintain - the community has the skillset > > required for a simple package like this one. Regardless, I volunteered > > to take over maintenance of that package so you could consider LightCube > > OS as upstream for that one, if you wish. I haven't had a chance yet to > > put that code in an official location on our servers, but I will aim to > > do so this week. > > It just another package and I'd like to avoid that in LFS even if it is > CMMI. If the install of the bootscripts is basically copying files and > setting some symlinks, we don't need a C program to do just that. OTOH, > putting it into BLFS is not an issue with me. It seems to me the solution is to integrate the C program into the bootscripts. The bootscripts used to just need "make install" but now they should also need a "make" (to compile the tools needed to install the bootscripts). Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On Jun 1, 2011, at 12:10 AM, Bruce Dubbs wrote: >> >> > Also see > http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html#SWINSTALL-INTRO > > They may say that you don't have to actually use rpm, but only that a > conforming application can process rpm packages. I see little difference. Touché. Although I'd say the bootscripts and the initd-tools are a bit more tightly coupled. > I don't see us putting rpm into LFS any time soon. If you ever want help with that, let me know ;-) JH-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
Jeremy Huntwork wrote: > On 5/31/11 10:55 PM, Bruce Dubbs wrote: >> It just another package and I'd like to avoid that in LFS even if it is >> CMMI. If the install of the bootscripts is basically copying files and >> setting some symlinks, we don't need a C program to do just that. > > Well, yes, that is what it's doing, but it's also working out > dependencies on those scripts (from the headers) and determines startup, > shutdown order auto-magically based on those deps. Sure beats doing it > manually. > >> OTOH, putting it into BLFS is not an issue with me. > > OK. It's pretty core to the LSB script workings, to me it seems silly to > separate it, but that's your call. > (http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html) Also see http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html#SWINSTALL-INTRO They may say that you don't have to actually use rpm, but only that a conforming application can process rpm packages. I see little difference. I don't see us putting rpm into LFS any time soon. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 5/31/11 10:55 PM, Bruce Dubbs wrote: > It just another package and I'd like to avoid that in LFS even if it is > CMMI. If the install of the bootscripts is basically copying files and > setting some symlinks, we don't need a C program to do just that. Well, yes, that is what it's doing, but it's also working out dependencies on those scripts (from the headers) and determines startup, shutdown order auto-magically based on those deps. Sure beats doing it manually. > OTOH, putting it into BLFS is not an issue with me. OK. It's pretty core to the LSB script workings, to me it seems silly to separate it, but that's your call. (http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html) JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
Jeremy Huntwork wrote: > On 5/31/11 7:28 PM, DJ Lucas wrote: >> Yeah, I had thought about PHP, and I know you are good at that. I >> suppose waiting until BLFS would work, then it could be up the user to >> select which tool set is best for them. I don't exactly like that idea >> personally, but it should provide a working compromise. Gimme a day to >> figure out how to handle the Makefile and we'll see if it is a plausible >> solution or not--install_initd should be used if available (think >> upgrades) with a fallback to a predefined order if not, for new installs. > > I'm not sure I understand the objection to C. It's not really that > difficult to understand or maintain - the community has the skillset > required for a simple package like this one. Regardless, I volunteered > to take over maintenance of that package so you could consider LightCube > OS as upstream for that one, if you wish. I haven't had a chance yet to > put that code in an official location on our servers, but I will aim to > do so this week. It just another package and I'd like to avoid that in LFS even if it is CMMI. If the install of the bootscripts is basically copying files and setting some symlinks, we don't need a C program to do just that. OTOH, putting it into BLFS is not an issue with me. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 5/31/11 7:28 PM, DJ Lucas wrote: > Yeah, I had thought about PHP, and I know you are good at that. I > suppose waiting until BLFS would work, then it could be up the user to > select which tool set is best for them. I don't exactly like that idea > personally, but it should provide a working compromise. Gimme a day to > figure out how to handle the Makefile and we'll see if it is a plausible > solution or not--install_initd should be used if available (think > upgrades) with a fallback to a predefined order if not, for new installs. I'm not sure I understand the objection to C. It's not really that difficult to understand or maintain - the community has the skillset required for a simple package like this one. Regardless, I volunteered to take over maintenance of that package so you could consider LightCube OS as upstream for that one, if you wish. I haven't had a chance yet to put that code in an official location on our servers, but I will aim to do so this week. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 05/31/2011 10:21 AM, Bruce Dubbs wrote: > > Thanks for the input. Personally, I like php for scripting, but that > isn't appropriate for LFS. > > Perhaps we are overthinking here. The trouble I had was using > install_initd in the lfs-bootscripts Makefile. If we just get that > fixed and put Dan's initd-tools in BLFS, it would work out. After all, > we don't make LFS completely LSB compatible (e.g. no package manager), > so postponing initd-tools seems reasonable. Yeah, I had thought about PHP, and I know you are good at that. I suppose waiting until BLFS would work, then it could be up the user to select which tool set is best for them. I don't exactly like that idea personally, but it should provide a working compromise. Gimme a day to figure out how to handle the Makefile and we'll see if it is a plausible solution or not--install_initd should be used if available (think upgrades) with a fallback to a predefined order if not, for new installs. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
DJ Lucas wrote: > On 05/30/2011 08:19 PM, Bruce Dubbs wrote: >> I'll take a look and perhaps I'll come to the same conclusions. I'm not >> sure speed is the issue though. > > Oh yes it is! At least in shell with a couple of calls to sed and grep > anyhow. :-) I wish I had seen this prior to my other message. Please > allow me to save you some time as I speak from experience. Of course, > you are certainly welcome to try, but as Dan mentioned above, it was an > absolute nightmare in bash, unless I just way over thought it. You are > limited to a group of arrays and a rat's nest of complex loops. Dividing > into smaller functions and making it more linear might help a little > with readability, but I still fear that you'll be dealing with insane > loops. Also, in the event of a reciprocal dependency (which is actually > an error in the script being installed), the potential for infinite > loops exists without error checking on every iteration (which means more > calls to grep further slowing things down). > > As for other _interpreted_ languages, I didn't really get far enough > with perl to evaluate it, plus I don't actually know it well enough to > write a utility that I'd want distributed (it was a learning exercise). > Perl certainly provides a more advanced/polished tool set with which to > work and seems somewhat of an obvious step WRT LFS (if you really want > to use an interpreted language that we already have access to), while > Python is the current flavor per Debian (and at least was for other > distributions back in 2007/2008) and did seem to work well at that time. > Here is the current set of tools that Debian uses: > > http://ftp.debian.org/pool/main/l/lsb/lsb_3.2-27.tar.gz > > I just figured that was immediately out with LFS as it added yet another > group of dependencies for which a base package will have to be rebuilt > in BLFS (that's two added packages unless the install_initd and > remove_initd scripts are included in the bootscripts package). Plus with > the exceptionally slow move to Python 3 lingering...it just doesn't seem > like a good fit for LFS, at least IMO. With the above said, however, I'm > still partial to Dan's tools as I've used them for so long and they seem > to work well for our purposes. Another set of eyes on that code would > certainly be welcome too I'm sure, and perhaps they can be extended in > time to include an lsb-config utility (of course, that could easily be > written in shell too, I imagine that wouldn't take more than half an hour). > > Well anyway, there is some food for thought. I hope it helps. See my > other message as well if you do decide to proceed with a new tool as > there are at least a couple of corner cases that don't immediately > spring to mind when doing the outline. Thanks for the input. Personally, I like php for scripting, but that isn't appropriate for LFS. Perhaps we are overthinking here. The trouble I had was using install_initd in the lfs-bootscripts Makefile. If we just get that fixed and put Dan's initd-tools in BLFS, it would work out. After all, we don't make LFS completely LSB compatible (e.g. no package manager), so postponing initd-tools seems reasonable. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 05/30/2011 08:19 PM, Bruce Dubbs wrote: > Dan Nicholson wrote: >> On Mon, May 30, 2011 at 12:55 PM, Bruce Dubbs wrote: >>> DJ Lucas wrote: On 05/30/2011 12:34 PM, Bruce Dubbs wrote: > In the latest svn, the bootscripts are lfs-bootscripts-20110424. > > I get an error: Â make[1]: /usr/lib/lsb/install_initd: Command not found > > This was identified a week ago by xinglp, but I don't see a fix. > > Â Â -- Bruce Either need to roll back the inadvertent commit to the bootscripts tarball job or move forward with the patch I sent in. Let me know if I should do this. >>> I'd appreciate it if you could do a revert. Done. >>> Â I took a look at the patch >>> and it installs initd-tools as yet another package. Â I looked at the >>> source to initd-tools and I don't understand why we need a C program to >>> do that. Â It could be done in a shell script. That would require some >>> effort to create, but would be much easier to maintain. >>> >>> Perhaps I can try writing the script after the middle of next month. Â We >>> have a big deadline coming up. Â After that, Â I think I've earned about a >>> year of comp time. >> Try writing as a shell script, Bruce. DJ did before and found that my >> C version was much, much faster. Parsing the dependencies and building >> a tree in an interpreted language with no data structures is a >> nightmare. In C it's a linked list of structs. Just my opinion, >> though. > I'll take a look and perhaps I'll come to the same conclusions. I'm not > sure speed is the issue though. Oh yes it is! At least in shell with a couple of calls to sed and grep anyhow. :-) I wish I had seen this prior to my other message. Please allow me to save you some time as I speak from experience. Of course, you are certainly welcome to try, but as Dan mentioned above, it was an absolute nightmare in bash, unless I just way over thought it. You are limited to a group of arrays and a rat's nest of complex loops. Dividing into smaller functions and making it more linear might help a little with readability, but I still fear that you'll be dealing with insane loops. Also, in the event of a reciprocal dependency (which is actually an error in the script being installed), the potential for infinite loops exists without error checking on every iteration (which means more calls to grep further slowing things down). As for other _interpreted_ languages, I didn't really get far enough with perl to evaluate it, plus I don't actually know it well enough to write a utility that I'd want distributed (it was a learning exercise). Perl certainly provides a more advanced/polished tool set with which to work and seems somewhat of an obvious step WRT LFS (if you really want to use an interpreted language that we already have access to), while Python is the current flavor per Debian (and at least was for other distributions back in 2007/2008) and did seem to work well at that time. Here is the current set of tools that Debian uses: http://ftp.debian.org/pool/main/l/lsb/lsb_3.2-27.tar.gz I just figured that was immediately out with LFS as it added yet another group of dependencies for which a base package will have to be rebuilt in BLFS (that's two added packages unless the install_initd and remove_initd scripts are included in the bootscripts package). Plus with the exceptionally slow move to Python 3 lingering...it just doesn't seem like a good fit for LFS, at least IMO. With the above said, however, I'm still partial to Dan's tools as I've used them for so long and they seem to work well for our purposes. Another set of eyes on that code would certainly be welcome too I'm sure, and perhaps they can be extended in time to include an lsb-config utility (of course, that could easily be written in shell too, I imagine that wouldn't take more than half an hour). Well anyway, there is some food for thought. I hope it helps. See my other message as well if you do decide to proceed with a new tool as there are at least a couple of corner cases that don't immediately spring to mind when doing the outline. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 05/30/2011 02:55 PM, Bruce Dubbs wrote:
> I'd appreciate it if you could do a revert. I took a look at the
patch and it installs initd-tools as yet another
> package. I looked at the source to initd-tools and I don't understand
why we need a C program to do that. It could
> be done in a shell script. That would require someeffort to create,
but would be much easier to maintain.
I'll jump in and fix that for now real quick then, I'll also add the
subsystem call to udev script, but IDK about scripting
{install,remove}_initd. Initd-tools is one extra package, it's tiny, it
works, and being only in C, the maintenance burden is likely to be very
small.
> Perhaps I can try writing the script after the middle of next month.
We have a big deadline coming up.
> After that, I think I've earned about a year of comp time.
I'll wish you luck then. ;-) Been there, done that. It was really slow
in just bash (and a couple hundred sed and grep calls), but was a neat
learning exercise none the less. For fun, I then wound up using make to
handle dependencies and the script was almost fast enough to be usable
(somebody had suggested using make as a replacement for init in some
passing conversation and I thought it a neat idea). :-) Then I decided
to use it as an excuse to learn perl. Dan came up with initd-tools
before I really even got started on it in perl (which I still do not
know well BTW). I thought C would be perfect (no additional dependencies
for LFS), so I scrapped all three previous attempts.
At any rate, here are a couple of caveats that I vaguely remember
causing me to start from scratch or make major changes to the way I was
doing things a few times:
1. Scriptname != Facility. Admittedly, this seems obvious now.
2. Do not fall into the trap of looking at /etc/rc.d/init.d and
expecting all scripts to be activated. The easiest method I came up with
for a list of activated scripts was to run through all of the rc?.d
directories to assemble a list of link targets. From that list, I then
read all of the headers into multiple arrays and worked only from the
index with the new script as the last in the array so that disk i/o was
limited to the beginning and end of the script.
3. Don't forget about start links in 0 and 6 which will be dependent on
both *-stop and *-start of the current runlevel, but not scripts
supplied in runlevel S (formerly sysinit).
4. All other runlevels will have to account for items started in
runlevel S.
5. The Default-St{art,op} does not have to define in which runlevels any
existing activated scripts are started, but both Dan and I, while
working independently, chose to do so as the spec does not limit the
program in that way, and the note at the bottom of
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html
does not seem to indicate that will change. LFS does not provide any
existing automation, and in practice this is really the most direct way
of managing runlevel 4 if needed, and provides similar functionality to
insserv or chkconfig in Suse or RedHat without any added complexityor
additional tools(in fact, in all test cases that I could come up with,
it greatly simplifies the job to always reorder as opposed to trying to
fit a script in between others).
HTH
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: svn bootscripts
Dan Nicholson wrote: > On Mon, May 30, 2011 at 12:55 PM, Bruce Dubbs wrote: >> DJ Lucas wrote: >>> On 05/30/2011 12:34 PM, Bruce Dubbs wrote: In the latest svn, the bootscripts are lfs-bootscripts-20110424. I get an error: Â make[1]: /usr/lib/lsb/install_initd: Command not found This was identified a week ago by xinglp, but I don't see a fix. Â Â -- Bruce >>> Either need to roll back the inadvertent commit to the bootscripts >>> tarball job or move forward with the patch I sent in. Let me know if I >>> should do this. >> I'd appreciate it if you could do a revert. Â I took a look at the patch >> and it installs initd-tools as yet another package. Â I looked at the >> source to initd-tools and I don't understand why we need a C program to >> do that. Â It could be done in a shell script. That would require some >> effort to create, but would be much easier to maintain. >> >> Perhaps I can try writing the script after the middle of next month. Â We >> have a big deadline coming up. Â After that, Â I think I've earned about a >> year of comp time. > > Try writing as a shell script, Bruce. DJ did before and found that my > C version was much, much faster. Parsing the dependencies and building > a tree in an interpreted language with no data structures is a > nightmare. In C it's a linked list of structs. Just my opinion, > though. I'll take a look and perhaps I'll come to the same conclusions. I'm not sure speed is the issue though. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On Mon, May 30, 2011 at 12:55 PM, Bruce Dubbs wrote: > DJ Lucas wrote: >> On 05/30/2011 12:34 PM, Bruce Dubbs wrote: >>> In the latest svn, the bootscripts are lfs-bootscripts-20110424. >>> >>> I get an error: make[1]: /usr/lib/lsb/install_initd: Command not found >>> >>> This was identified a week ago by xinglp, but I don't see a fix. >>> >>> -- Bruce >> Either need to roll back the inadvertent commit to the bootscripts >> tarball job or move forward with the patch I sent in. Let me know if I >> should do this. > > I'd appreciate it if you could do a revert. I took a look at the patch > and it installs initd-tools as yet another package. I looked at the > source to initd-tools and I don't understand why we need a C program to > do that. It could be done in a shell script. That would require some > effort to create, but would be much easier to maintain. > > Perhaps I can try writing the script after the middle of next month. We > have a big deadline coming up. After that, I think I've earned about a > year of comp time. Try writing as a shell script, Bruce. DJ did before and found that my C version was much, much faster. Parsing the dependencies and building a tree in an interpreted language with no data structures is a nightmare. In C it's a linked list of structs. Just my opinion, though. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
DJ Lucas wrote: > On 05/30/2011 12:34 PM, Bruce Dubbs wrote: >> In the latest svn, the bootscripts are lfs-bootscripts-20110424. >> >> I get an error: make[1]: /usr/lib/lsb/install_initd: Command not found >> >> This was identified a week ago by xinglp, but I don't see a fix. >> >> -- Bruce > Either need to roll back the inadvertent commit to the bootscripts > tarball job or move forward with the patch I sent in. Let me know if I > should do this. I'd appreciate it if you could do a revert. I took a look at the patch and it installs initd-tools as yet another package. I looked at the source to initd-tools and I don't understand why we need a C program to do that. It could be done in a shell script. That would require some effort to create, but would be much easier to maintain. Perhaps I can try writing the script after the middle of next month. We have a big deadline coming up. After that, I think I've earned about a year of comp time. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn bootscripts
On 05/30/2011 12:34 PM, Bruce Dubbs wrote: > In the latest svn, the bootscripts are lfs-bootscripts-20110424. > > I get an error: make[1]: /usr/lib/lsb/install_initd: Command not found > > This was identified a week ago by xinglp, but I don't see a fix. > > -- Bruce Either need to roll back the inadvertent commit to the bootscripts tarball job or move forward with the patch I sent in. Let me know if I should do this. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
svn bootscripts
In the latest svn, the bootscripts are lfs-bootscripts-20110424. I get an error: make[1]: /usr/lib/lsb/install_initd: Command not found This was identified a week ago by xinglp, but I don't see a fix. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
MYSQL bootscript will not work with svn bootscripts
mysql's bootscript uses killproc with no parameters, which breakes the check I have included. [which just prints out a useage message]. the LSB [what I was trying to make the functions compatible to], uses the killproc [options] progname [killsig] notation. The way killproc is "currently" written, it does not use the progname if a pidfile is given [setting the PIDFILE variable, or using killproc -p [pidfile]. This has to be addressed before the next LFS release. -- Nathan Coulson (conathan) -- nathan at linuxfromscratch org conathan at gmail com -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
