[00:40] <JanC> I think shan3 wants to boot slower  ;)
[01:48] <Caesar> Is there a way to validate an upstart job for anatomical correctness but otherwise not do anything with it?
[03:28] <shan3> In Ubuntu 10.04, is it possible that a bash script I run from an Upstart job can exit with errors because it is not compliant with dash?
[03:30] <Keybuk> your question doesn't make sense
[03:32] <Keybuk> scripts run from an Upstart job (within the script...end script block) are run with /bin/sh, which on Ubuntu is dash
[03:32] <Keybuk> this means you *cannot* include so-called bashisms in them
[03:32] <Keybuk> they are not bash scripts
[03:32] <Keybuk> if you instead call out to an executable bash script using exec, then it will be run with whatever the #! line is at the top
[03:33] <Keybuk> (ie. set that to #!/bin/bash *not* #!/bin/sh)
[03:34] <shan3> Keybuk: Thanks for the reply... but I cannot figure out why my bash script will not run from the Upstart job but works perfectly when run from terminal
[03:34] <Keybuk> can you pastebin the upstart job?
[03:34] <shan3> sure...  1 sec
[03:36] <shan3> http://pastebin.com/JVLiFwaZ
[03:36] <Keybuk> /usr/sbin/mfmrootdaemon being the bash script?
[03:36] <shan3> yes
[03:36] <Keybuk> well, it could be any number of issues
[03:37] <Keybuk> for example, is /usr even mounted/
[03:37] <Keybuk> it's stopped when rcS is started, which might be quite soon after udev is started
[03:37] <Keybuk> it might need mounted filesystems like /proc, which aren't available when udev is started
[03:37] <Keybuk> have you tried adding set +x to your bash script, and "console output" to the job, to see what it fails on?
[03:38] <shan3> but it should work if I run 'sudo start myjob' , right?
[03:38] <Keybuk> if it works when you do that, but doesn't work otherwise, then it would be a dep issue
[03:38] <Keybuk> if it doesn't work when you "sudo start", then I'd do the set +x/console output trick to see how it fails
[03:39] <shan3> no it doesn't work when I use start... I'll try set +x now
[03:39] <Keybuk> the set =x goes at the top of mfmrootdaemon obviously
[03:39] <Keybuk> set +x I mean
[03:39] <Keybuk> it makes bash print each line before executing it
[03:39] <Keybuk> so you'll see where it breaks
[04:05] <shan3> Keybuk: do you mean set -x ? coz that print the commands and arguments... either way, I've added 'console output' ans set +x and also set -x... but still no output
[04:05] <Keybuk> err yes
[04:05] <Keybuk> maybe -x
[04:07] <shan3> -x enables and +x disables... 
[04:08] <shan3> start outputs 'myjob start/running' but there is no sign on it in ps
[04:08] <shan3> *of it
[16:47] <Keybuk> notting: around?
[16:47] <notting> sure, why not
[16:48] <Keybuk> I hear RedHat have written their own init replacement, and will be using that instead of Upstart
[16:48] <Keybuk> care to comment?
[16:52] <notting> (give me a few minutes)
[16:52] <Keybuk> :-)
[16:56] <notting> someone who is a RH employee is writing something in their spare time. i have not looked at what they've written so far
[16:57] <notting> there are no current plans to either ship it, or not ship it
[16:59] <Keybuk> they claim RH is paying them to write it
[16:59] <Keybuk> and that it's a foregone shoe into Fedora
[17:09] <notting> i'm not exactly comfortable attempting to talk about a third party in their absence. i'd prefer to let them speak for themselves.
[17:09] <notting> but nothing has been built for fedora, or proposed for fedora, or discussed in fedora in any way
[17:10] <mclasen> I'm sure it will be, in time
[17:16] <Keybuk> notting: ok ;)
[17:16] <Keybuk> so you don't know much about it
[17:19] <notting> i know of it/the basics about it
[17:28] <ion> iNIHt
[17:29] <ion> Nothing wrong with NIH if you have a good reason for it. What’s the reason for the RH init?
[17:34] <notting> no linux subsystem is complete unless there's a implementation that starts with 'g' and an implementation that starts with 'k'. init has neither.
[17:46] <Keybuk> it's all about the 'u' now
[17:55]  * notting waits for canonical to come out with their ibis mascot, then
[18:40] <sadmac> Keybuk: I heard this rumor too. My reaction was the same as yours.
[21:33] <Keybuk> sadmac: I had a reaction? :p
[21:34] <sadmac> Keybuk: yes. I asked notting :)
[21:34] <Keybuk> when I first heard about it (six months ago?) I didn't expect it to actually get finished, so yeah, I guess I'm surprised about that ;p
[21:34] <Keybuk> ah, that it's basically launchd?
[21:34] <sadmac> Keybuk: I know nothing about it
[21:35] <sadmac> Keybuk: where'd you hear it from?
[21:40] <Keybuk> various people leaking things to me, until finally Lennart came clean and sent me the draft announcement today
[21:40] <sadmac> Keybuk: its lennart then?
[21:40] <Keybuk> who else? :p
[21:40] <sadmac> Keybuk: I actually did think that earlier.
[21:41]  * sadmac wonders if he hasn't done enough damage
[21:42] <Keybuk> damage?  he did a great job on Avahi, finally killing that evil mdns responder crap from Apple
[21:42] <Keybuk> and PulseAudio killed esd
[21:42] <sadmac> Keybuk: Pulseaudio killed puppies too
[21:42] <Keybuk> I never said that ;)  you said that ;)
[21:42] <sadmac> Keybuk: avahi... no opinion, I'll give you that one
[21:43] <sadmac> Keybuk: Whenever Ubuntu gets that magical patch that makes Pulse not suck upstream then I'll be ok (not your fault in this case. He won't take the damn thing.)
[21:45] <Keybuk> is that the "apt-get remove pulseaudio" patch?
[21:45] <sadmac> Keybuk: also, do you look at it as killing esd or cementing alsa?
[22:06] <JanC> pulseaudio works fine
[22:10] <JanC> except for 1 usage scenario maybe (a system daemon like mpd needing to play sound, but even that's solvable)
[22:11] <Keybuk> yeah, it's always worked ok for me
[22:13] <sadmac> right now this box will periodically produce static instead of sound unless I kill pulse.
[22:13] <sadmac> and that's for straight alsa apps
[22:13] <sadmac> if it goes through gstreamer it hardlocks
[22:13] <sadmac> busy-looping inside libpulse
[22:13] <JanC> your gstreamer uses pulse I hope?
[22:14] <sadmac> JanC: yes. It seems to use it in such a way that it hits the pulseaudio glitch harder, or hits a different glitch.
[22:14] <JanC> anyway, never seen that happen recently on Ubuntu (for at least 1 year)
[22:15] <JanC> may depend on the hardware though
[22:15] <sadmac> intel
[22:15] <sadmac> this box is on its second motherboard too. same problems as the last chipset on this one.
[22:16] <JanC> I think you mean HDA, intel doesn't make audio chips (anymore?)
[22:16] <sadmac> yeah. that's what I mean