[00:23] <ccheney> anyone happen to know the name of the dd program in the archive that shows status while writing?
[00:23]  * ccheney heard about it a while back but can't find it when searching apt-cache
[00:24] <slangasek> lamont: ta
[00:26] <cjwatson> ccheney: grep-aptavail turns up a few possible candidates - dcfldd? pcopy? sdd?
[00:27] <cjwatson> I suspect this problem has been solved a few different times:)
[00:28] <ccheney> cjwatson: ah yea dcfldd
[00:28] <ccheney> cjwatson: thanks, i searched for dd and somehow managed to overlook that one
[00:29] <cjwatson> I did: grep-aptavail -e '\<dd\>'
[00:33] <ccheney> ok
[01:40] <smoser> anyone know how to tell init(upstart) to work in debug or verbose mode in /etc/init.conf ?  ie, the same effect that running 'initctl log-priority debug'
[01:42] <slangasek> smoser: there's no /etc/init.conf; but you get the effect of running 'initctl log-priority debug' by adding an upstart job that runs 'initctl log-priority debug'
[01:42] <slangasek> (or adding it to the start of whatever job you're currently debugging)
[01:42] <smoser> the man page says there is a /etc/init.conf and the code and daemon seem to at least acknowledge it
[01:43] <slangasek> well, ok
[01:43] <smoser> slangasek, in ec2, i can't pass --verbose or --debug on kernel cmdline, but i wanted it to be turned on as soon as possible
[01:43] <slangasek> I've never heard of init.conf before, and it obviously doesn't exist by default :)
[01:43] <smoser> having a job run asap and doing initclt is what i think i have to do
[01:43] <smoser> right. it doesn't exist, but man 8 init mentions it
[01:44] <slangasek> cat >> /etc/init/debug.conf
[01:44] <slangasek> description "debug me"
[01:44] <slangasek> start on startup
[01:44] <slangasek> task
[01:44] <slangasek> exec initctl log-priority debug
[01:44] <slangasek> ^D
[01:44] <smoser> thank you
[01:46] <smoser> i tried 'log-priority debug' in /etc/init.conf and it complained of unknown stanza. maybe i'm just supposed to put things like "normal jobs" there.
[03:36] <crypt-0-> anyone awake?
[03:38] <crypt-0-> i have my root partition pointing to the wrong one, even though fstab is pointing to the right one.
[03:38] <crypt-0-> it asks for "cryptoroot" when fstab clearly tells it to ask for "cryptroot" (along with crypttab)
[03:42] <ScottK> crypt-0-: Help is in #ubuntu or #ubuntu+1 if you are on Lucid.
[03:44]  * crypt-0- knows, the answers are usually much more accurate here. So i will just lurk here in case someone answers it :)
[03:46] <crypt-0-> I did just narrow the problem down, but now i just have a very simple question. "Where does GRUB2 ask for the root device?"
[04:21] <Chipzz_> ccheney: did you mean pv?
[04:42] <JanC> hm, seems like the Tracker people intend to release a non-developer version of tracker 0.7.x after the xmas/newyear period
[05:06] <LucidFox> JanC> I take it tracker was removed from the default install at some point?
[05:06] <LucidFox> Why, by the way?
[05:08] <LucidFox> Eep.
[05:48] <ScottK> StevenK_: If you do the sync in Bug #497289, then boost1.39 can die.
[06:26] <SandGorgon> just wanted to point you guys to a very interesting study of an alternative Linux driver architecture - Dingo (http://ertos.nicta.com.au/publications/papers/Ryzhyk_CKH_09.pdf). The paper is good in itself for the part where it studies the %age root-cause for driver problems
[07:40] <tseliot> slangasek, Keybuk: what is it that should call  'plymouth ask-for-password --prompt="my prompt string" when unencrypting your disk?
[07:41] <tseliot> bug #496765
[07:41] <slangasek> tseliot: the cryptsetup upstart job
[07:41] <slangasek> (implemented in lucid, as of a few hours ago)
[07:41] <slangasek> alternatively, the cryptsetup initramfs script, in the crypted-root case
[07:41] <Keybuk> tseliot: 'wot 'e said
[07:42] <tseliot> plymouth is not in the initramfs therefore the upstart job should be the right place to do it
[07:42] <Keybuk> tseliot: installing cryptsetup puts plymouth in the initramfs
[07:42] <tseliot> ah
[07:43] <tseliot> ok, I'll have to play with it then
[07:43] <Keybuk> because if you have to type a passphrase to boot, you don't care about boot speed
[07:43] <Keybuk> especially not if you're james_w
[07:43] <slangasek> tseliot: "the right place to do it" is always the initramfs, in the case of a crypted root system ;)
[07:43] <tseliot> :-D
[07:43]  * tseliot has never tried disk encryption
[07:44] <Keybuk> tseliot: careful, you know what they say
[07:44] <Keybuk> the first disk is free
[07:44] <slangasek> if you have a spare disk partition, I can add a test case for you to the bug... but I guess it's a bit easier to debug this if you can start plymouthd manually outside of the boot sequence and e.g., attach remotely with ssh?
[07:44] <tseliot> slangasek: also, about bug #496782, shall I simply not display any additional bullet?
[07:45] <Keybuk> probably much easier to debug in X :p
[07:45] <Keybuk> just start plymouthd and plymouth --show-splash from an xterm
[07:45] <tseliot> slangasek: yes, I use X and ssh for debugging
[07:45] <tseliot> as Keybuk said
[07:46] <dholbach> good morning
[07:46]  * tseliot needs to check how gdm deals with long passwords
[07:47] <tseliot> good morning dholbach
[07:47] <dholbach> hey tseliot
[07:47] <slangasek> tseliot: not displaying additional bullets is ok, though in that case I think it's best if bug #497115 can be fixed first :)
[07:48] <Keybuk> slangasek: you didn't rise to my joke! :'(
[07:48] <slangasek> :-)
[07:49] <tseliot> slangasek: I think I've noticed that too. I should bug upstream about it
[07:49] <slangasek> Keybuk: sure I did, I let you know there are lower case letters in my passphrase
[07:49] <Keybuk> tseliot: it might be because something else is reading from the console and plymouth isn't getting the characters?
[07:49] <Keybuk> worth checking file descriptors in ssh
[07:49] <Keybuk> it could also be plymouth sucking
[07:49] <slangasek> Keybuk: it's reproducible for me even in the initramfs
[07:50] <Keybuk> I've only tested stuff like that in X so far
[07:50] <Keybuk> that'd be an interesting thing - does doing it in X work fine?
[07:50] <tseliot> it sounds more like a plymouth issue. I managed to reproduce the problem in X
[07:50] <Keybuk> cool, sounds like you're on top of that one :p
[07:50] <slangasek> and cf. the comment I've just added to the bug - I think whatever event loop it has for processing input characters has no support for queuing :)
[07:50] <tseliot> yes, more or less :-P
[07:50] <Keybuk> tseliot: while you're in there, I have a theme/script improvement that'd be nice
[07:51] <Keybuk> tseliot: I'd like to be able to display two different messages on screen
[07:51] <Keybuk> plymouth message should go in the usual place
[07:51] <Keybuk> but I'd like to do something like plymouth message "keys:..."
[07:51] <tseliot> slangasek: I think I can improve that
[07:51] <Keybuk> which goes along the bottom of the screen instead
[07:51] <Keybuk> and not have the two cancel each other out
[07:51] <Keybuk> tseliot: that's theme rather than code, right?
[07:52] <tseliot> Keybuk: well, a theme *is* a program ;)
[07:52] <Keybuk> you know what I mean <g>
[07:52] <tseliot> yes, no C code would be involved
[07:52] <dholbach> how far did we get with dropping lpia from lucid?
[07:52] <dholbach> I'm looking at bug 488797
[07:53] <dholbach> which still lists lpia in the changes
[07:53] <tseliot> Keybuk: currently the text from message and the one from ask-for-password will appear on different lines. Is this what you need or just an additional message text?
[07:54] <tseliot> text message
[07:54] <Keybuk> tseliot: additional message text
[07:54] <Keybuk> e.g.
[07:54] <Keybuk> "Errors were found while checking /home"
[07:54] <slangasek> dholbach: we're at the point where if lpia is the only diff in a package, it's reasonable to make it a sync instead
[07:54] <Keybuk> then along the bottom
[07:54] <dholbach> slangasek: it wouldn't be the only change :)
[07:54] <Keybuk> "[F]ix them, [I]gnore errors, [S]kip mountpoint, [A]bort"
[07:55] <slangasek> dholbach: then IMHO we should hang on to it for now
[07:55] <dholbach> alrightie
[07:55] <persia> dholbach: Last I heard, we planned to not spend time trying to maintain it, but there's some installer stuff that relies on EFI, so it might be more work to track it down and pull it out than port the patch.
[07:55] <dholbach> good good, thanks guys
[07:55] <slangasek> we seem to still have Packages files for lpia, though I know some of the archive admin tools no longer see it
[07:56] <StevenK_> slangasek: Last I heard from lamont is that is going to require more DB hackery to kill them
[07:56] <tseliot> Keybuk: ok, and what happens when you want to show another message? Do you overwrite the one at the top or the one at the bottom? And what happens to the other one?
[07:57] <Keybuk> tseliot: if it's prefixed, it overwrites the one at the bottom
[07:57] <Keybuk> if not, it overwrites the one at the top
[07:57] <Keybuk> neither clears each other
[07:57] <Keybuk> ie. to clear both, I'd have to send message "" and message "keys:"
[07:58] <tseliot> Keybuk: ok, sounds good. Can you file a bug report about it with all these details, please?
[07:58] <Keybuk> np
[07:58] <tseliot> thanks
[08:13] <Keybuk> slangasek: I really don't have any time to work on the bootwait problem
[08:13] <Keybuk> I get dozens of mails *A DAY* of people complaining about it
[08:13] <Keybuk> so I'm going to revert back to the jaunty behaviour
[08:13] <Keybuk> if you want to try and make it work, be my guest
[08:14] <slangasek> revert back to the jaunty behavior - the jaunty behavior is that any filesystem that isn't available at the time rcS runs is skipped
[08:14] <Keybuk> no it isn't
[08:14] <Keybuk> it's that any filesystem not available causes the script to fail
[08:14] <Keybuk> and gives you a root shell
[08:14] <Keybuk> (afaict)
[08:15] <slangasek> well, that wasn't the case for network filesystems, at least
[08:15] <persia> That wasn't my experience: the boot seemed to hang for a bit of extra wait with no response, and only bounce to a shell after 5 sec or so.
[08:15] <Keybuk> persia: that's because there was a sleep 5 in there, asking you if you'd rather reboot instead
[08:15] <slangasek> for those, the behavior was "try in rcS; try again when the network comes up"
[08:15] <Keybuk> but we helpfully hid that message
[08:15] <Keybuk> slangasek: right, network are a more special case
[08:16] <Keybuk> either way, I think the friendlier recovery stuff already helps this
[08:16] <Keybuk> mountall won't bomb out
[08:16] <Keybuk> it'll prettily say "I can't find your /porn, shall I skip it?"
[08:17] <slangasek> well, and if I say yes there and then the network comes up, does mountall try again?
[08:17] <Keybuk> not if mountall has exited
[08:18] <slangasek> and if I say "no", mountall never signals the boot to proceed, so gdm never starts, so the user can't log in and the network interface never comes up?
[08:19] <slangasek> in which case that's a false choice; I don't want either of those things, I want the sensible behavior that the filesystem will be automatically mounted when the network comes up :)
[08:19] <Keybuk> as I've already said, network mounts are treated specially
[08:19] <Keybuk> you can't have that special behaviour :p
[08:19] <Keybuk> unless you implement a way to have filesystem checks and cryptsetup prompts in X :p
[08:19] <slangasek> oh, you said network /is/ special, you didn't actually say it was /treated/ specially ;)
[08:20] <persia> cryptsetup is the tricky one, because there's all sorts of things that can go oddly.
[08:20] <Keybuk> it doesn't "see" network devices until a network interface comes up
[08:23] <Keybuk> though, that being said, NM brings up wired connections before gdm ;)
[08:23] <Keybuk> and is deliberately started on local-filesystems
[08:23] <slangasek> sure; wireless / vpn is the use case there
[08:23] <Keybuk> yes...
[08:23] <Keybuk> but that's *never* worked
[08:23] <Keybuk> (that I can tell)
[08:23] <slangasek> yuh-huh
[08:23] <slangasek> :)
[08:23] <Keybuk> first I have to not break things for everyone who has a working setup ;)
[08:23] <Keybuk> especially since this is an LTS
[08:24] <slangasek> I have a working setup that fits the above description
[08:24] <slangasek> laptop; wireless; NFS mounts configured in /etc/fstab to automount
[08:24] <Keybuk> then please help make it work
[08:24] <slangasek> with jaunty, karmic, and lucid w/ current mountall, it works
[08:24] <Keybuk> I've run out of ideas
[08:25] <Keybuk> it won't work in lucid with the new mountall
[08:27] <slangasek> What are the nature of the complaints about bootwait?  Because aside from having to introduce a new option in /etc/fstab that util-linux doesn't know about yet, it does actually seem to be the Right Thing
[08:27] <Keybuk> that's the complaint
[08:27] <Keybuk> people keep refusing to add the new option saying things worked before
[08:27] <slangasek> hmm
[08:27] <Keybuk> and I am required to be a bug contact for their bugs
[08:27] <Keybuk> and I'm required to read every single one
[08:27] <Keybuk> and I'm required to reply to them
[08:28] <Keybuk> even the ones that say they're going to write to sabdfl and try and have me fired for incompetence
[08:28] <Keybuk> and that kind of thing wears you down
[08:29] <slangasek> well, if backwards-compatibility is the goal, I think blocking the filesystem signal on local filesystems + network filesystems w/ FHS mountpoints would do it
[08:29] <slangasek> and have mountall hang around to wait for network filesystems w/ non-FHS mountpoints?
[08:29] <Keybuk> mountall can't hang around once gdm starts
[08:30] <Keybuk> it has to exit
[08:30] <slangasek> why, if it's only going to process network mounts after that?
[08:30] <Keybuk> because network mounts can have loop mounts on them
[08:30] <Keybuk> which can require fsck
[08:30] <Keybuk> and can require cryptseutp
[08:30] <slangasek> well, *that* has never worked
[08:30] <Keybuk> yes
[08:31] <Keybuk> but before it didn't crash gdm ;)
[08:31] <Keybuk> and X
[08:31] <Keybuk> mountall likes to do that
[08:31] <Keybuk> if plymouth exits, then we lose the ability to communicate with users
[08:31] <persia> Can mountall emit something that starts a separate asynchonous job to handle the oddities?
[08:32] <Keybuk> not really
[08:32] <slangasek> I think you either treat those as blockers for the filesystem signal, so gdm isn't started until they're all there; or you ignore them as "crazy thing that depends on a network mount and isn't my problem"
[08:32] <slangasek> I think either way of handling them is acceptable
[08:32] <Keybuk> slangasek: that's kind of what I want to go towards
[08:33] <Keybuk> NFS on systemy places will cause a wait
[08:33] <Keybuk> anything with pass != 0 requires a wait
[08:34] <Keybuk> that doesn't solve "I have /home/joe on NFS" though
[08:34] <Keybuk> but then I can't see that that worked before
[08:34] <Keybuk> except by luck
[08:34] <slangasek> right, it was always racy
[08:35] <slangasek> "always" - "as long as we've been bringing up interfaces with udev"
[08:35] <Keybuk> that's pretty much ever in ubuntu
[08:35] <Keybuk> we used to bring them up with hotplug ;)
[08:36] <Keybuk> the real problem is that this whole thing is a *mess* of corner cases
[08:36] <Keybuk> and the kinds of people with the corner cases don't test
[08:37] <Keybuk> they just upgrade to the final release
[08:37] <Keybuk> then cry, and start spouting rubbish like "where do I send the bill to Canonical for all the downtime?"
[08:38] <Keybuk> and when I, not unreasonably, tell them to fuck off and die (politely) - I get e-mails from Millbank telling me off because they complained <g>
[08:38]  * slangasek hehs
[08:38]  * Keybuk is a bit emo, really
[08:40] <slangasek> well, as long as my system doesn't end up with a dependency loop between /home/random and gdm and network-manager because I'm roaming on an ESSID I've never seen before, I'm happy
[08:40] <slangasek> :)
[08:40] <Keybuk> I'll notice too ;)
[08:40] <Keybuk> most of my home directory is an NFS mount
[08:43] <Keybuk> well, symlinks to an invented directory on the root
[08:43] <Keybuk> /home/scott/Music -> /zelda/Music etc.
[08:43] <Keybuk> so that's even more corner-y
[08:46]  * slangasek punches NFSv4 in the face
[08:46] <slangasek> bad packet storm
[09:06] <chrisccoulson> siretart - i just saw the last few comments on bug 428884. i think the issue with updating xdg-screensaver to use the new API is that the inhibitors only remain for the life of the process that registered them
[09:07] <chrisccoulson> if i can get an ACK for a SRU, then i'm just going to patch gnome-screensaver to make the old method work again
[09:17]  * Keybuk stumbles across Ian Jackson's wikipedia entry again and chuckles at the quote
[09:22] <dholbach> could anybody imagine giving a session about reading stack traces and fixing crashes at Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has some empty slots
[09:22] <dholbach> (any other development- or packaging-related topic would be welcome too)
[09:28] <persia> dholbach: I can do the stack trace one, or, I'd prefer to give an update to PackagingWithoutCompiling: the dh7 way.
[09:28] <dholbach> persia: both would be MUCH appreciated :)
[09:28] <joaopinto> mvo, it seems that the apt's http redirect handling code does not woek when you have an http proxy set, once I have some time to reproduce I will file a bug report
[09:28] <joaopinto> s/woek/work :P
[09:29] <joaopinto> it's just returning the 302 response
[09:29] <persia> dholbach: At those hours, both is unlikely (all the sessions are scheduled for the times I try hardest to be asleep)
[09:29] <dholbach> I know
[09:30] <persia> But pick one, and stick me in the 20:00 slot of your choice.
[09:30] <persia> (Except Wednesday)
[09:30] <dholbach> persia: just pick the one that suits you best
[09:31] <persia> Anyone else up for doing stacktraces?
[09:32]  * persia thinks stacktraces are more important, but doesn't really want to do it *again*
[09:40] <siretart`> chrisccoulson: AFAIUI, the point of xdg-util is to provide a proper abstraction for applications against the used screensaver implementation. I agree that this is difficult to implement in a shell script, so I propose to rewrite xdg-screensaver after revisiting the various used screensaver implementations
[09:41] <cjwatson> dholbach: 488797's submitter should be asked why he didn't contact the person who touched the package last, as instructed on merges.ubuntu.com :P
[09:42] <dholbach> cjwatson: you strike me as a good person who could give a developer week session about how to do merges right! :-)
[09:42] <siretart`> chrisccoulson: as for the semantic change in the API, right, the rewrite would probably need to implement some kind of timeout and guesswork to fit into the new gnome-screensaver system
[09:42] <dholbach> cjwatson: I can offer you a couple of different session slots, no problem: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep :-)
[09:42] <siretart`> chrisccoulson: btw, do you know if xdg-utils upstream, the portland initiative, is still active? it looks pretty abandoned to me TBH
[09:43] <cjwatson> I suppose I asked for tyhat
[09:43] <cjwatson> -y
[09:43] <dholbach> cjwatson: but you're right, it's a valid question to ask :)
[09:44] <chrisccoulson> siretart` - i'm not too sure if it's still active or not
[09:45] <bryce> I wrote the original xdg-screensaver in xdg-utils
[09:45] <siretart`> chrisccoulson: in any case, the idea of that initiavtive is great!
[09:46] <cjwatson> dholbach: I can probably do Fri 17:00
[09:46] <siretart`> bryce: ah, cool! what's the current upstream status of it?
[09:46] <dholbach> cjwatson: that'd be fantastic - can I pencil you in?
[09:46] <bryce> the original version I did had a timeout functionality, but it got lost in a rewrite
[09:46] <cjwatson> dholbach: go ahead
[09:46] <dholbach> awesome
[09:47] <dholbach> cjwatson: done, muchas gracias! :)
[09:47] <mvo> joaopinto: oh, do you have a example repo? i have a squid runing here
[09:47] <bryce> siretart, waldo was the last guy actively working on xdg-utils last I checked
[09:47] <bryce> dunno if he's still working on it, probably not
[09:48] <siretart`> bryce: it seems to me that xdg-utils is one of the last freedesktop projects that still use CVS. and the last commits are years ago, so I'm unsure about its status
[09:48] <siretart`> perhaps I should just go ahead and fork it in some git or bzr branch
[09:48] <joaopinto> mvo, now that I think on it, the person is using apt-cacher-ng as the proxy, it could be an apt-cacher-ng issue
[09:48] <joaopinto> mvo, deb http://ftp.heanet.ie/mirrors/www.getdeb.net/getdeb/ubuntu/ karmic-getdeb apps
[09:49] <joaopinto> ops, that's a directly link sorry
[09:49] <bryce> siretart, go for it
[09:49] <joaopinto> mvo, deb http://archive.getdeb.net/ubuntu karmic-getdeb games
[09:49] <bryce> siretart, if you need help understanding how it works or the design I'd be happy to field questions
[09:50] <bryce> it's been quite a few years since I looked at it, but might be of some use
[09:51] <joaopinto> mvo, it's an apt-cacher-ng issue, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556234, sorry :P
[09:51] <siretart`> bryce: don't expect results from me on xdg-utils this year. I'm already pretty busy at work and with implementing symbol versioning in ffmpeg upstream and debian.
[09:51] <mvo> joaopinto: thanks, ok
[09:51] <siretart`> I guess I could start working on that in january of february
[09:52] <siretart`> bryce: but thanks for the offer!
[09:52] <bryce> yep, I suppose we're all going to turn into pumpkins within a week or so ;-)
[09:53] <joaopinto> mvo, btw, we are using apt with http redirect on playdeb/getdeb in a large scale, it has been reliable
[09:55] <mvo> joaopinto: sweet, I'm happy to hear that
[09:58] <dholbach> could anybody give a session about setting up daily builds at  https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep ?
[10:00] <joaopinto> dholbach, hey, hard job this week, heads hunting :)
[10:00] <dholbach> joaopinto: so far things are looking quite good :)
[10:12] <mathiaz> soren: hi!
[10:12] <mathiaz> soren: are you looking after https://wiki.ubuntu.com/AutomatedServerTestingSpec?
[11:31] <gp> hello my laptop Mother board just went off ...how do i recover my data
[11:31] <gp> my home directory was encrypted
[11:32] <jpds> gp: User support in #ubuntu.
[12:37] <jb-laptop> I need to do a sync request for several packages that have newer versions in Debian. Would an archive admin require them as single bugs, one for each package, or one bug for all packages?
[12:40] <cjwatson> jb-laptop: it's easier as single bugs because then our scripts can take care of more of it for us
[12:41] <cjwatson> jb-laptop: we have a script to which we feed bug numbers (after manual verification) and it does the sync and closes the bug; this doesn't work with multiple syncs in one bug
[12:42] <jb-laptop> cjwatson: thanks for the clarification
[12:44] <soren> mathiaz: That's the idea, yes.
[12:44] <mathiaz> soren: ok - thanks
[13:36] <apw> cjwatson, who looks after the .ddeb magic ?
[13:38] <dholbach> apw: pitti :)
[13:38] <apw> thanks ... seems they have been found, all is well
[13:40] <qense> Bug 486024 looks a bit like a duplicate of bug 466575 , but the error message in the first says the device is busy, the latter that it can't be found. Anyone here who knows a lot of devicekit and could help?
[13:41] <seb128> qense, try asking to pitti when he's around he might know but he's not there today
[13:42] <qense> ok, thx
[13:43] <persia> I wouldn't think they are duplicates.
[13:43] <persia> I get the symptoms of 486024 all the time just because I forget to stop programs, etc.
[13:44] <persia> But 466575 looks like some issue with the device
[13:44] <qense> It does have a duplicate
[13:44] <qense> which is bug 495462
[14:16] <Whoopie> pitti: Hi, how can we proceed with bug 481448?
[14:17] <Whoopie> pitti: I got the ACK from jdong
[14:22] <smoser> Keybuk, is there a way in 'init.conf' to have the same effect as '--verbose' or '--debug' on kernel command line?
[14:23] <smoser> slangasek, gave me a job that ran on 'starting' that did 'initctl' which was basically good enough, but now i'm just wondering what exactly init.conf expects in it. is it "just another job" ?
[14:28] <jdstrand> Keybuk: hi, I want ufw to be running before any network devices start receiving packets. I had "start on net-device-added INTERFACE=lo", but lo may start after eth0. Is "start on net-device-added" what I want instead? (since upstart won't keep starting a started job)
[14:29] <jdstrand> Keybuk: I thought I wanted "start on starting network interface", but that didn't work (on karmic anyway)
[14:31]  * jdstrand tries "start on starting network  interface"
[14:31]  * jdstrand tries "start on starting network-interface"
[14:34] <Keybuk> smoser: there is no init.conf
[14:35] <smoser> init.conf is mentioned by the man page, and the upstart daemon in lucid acknowledges it, complaining about bad syntax
[14:35] <smoser> there is no default file, no
[14:36] <jdstrand> a '-' seems to make all the difference
[14:36] <smoser> Keybuk, what did you mean by "there is no init.conf" ?
[14:36] <Keybuk> smoser: there's no such thing
[14:37] <jdstrand> Keybuk: revised question: is "start on starting network-interface" ok to do in ufw.conf to achieve my goal and generally not screw things up?
[14:37] <smoser> $ dpkg-query --show upstart
[14:37] <smoser> upstart 0.6.3-11
[14:37] <smoser> $ man init | grep init.conf
[14:37] <smoser>        /etc/init.conf
[14:38] <Keybuk> jdstrand: as long as that's *all* you have
[14:38] <smoser> $ echo "foo bar" | sudo tee /etc/init.conf
[14:38] <smoser> foo bar
[14:38] <Keybuk> jdstrand: and as long as you do things in pre-start like network-interface-security
[14:38] <smoser> $ tail -n 1 /var/log/daemon.log
[14:38] <smoser> Dec 16 14:37:57 ubuntu init: /etc/init.conf:1: Unknown stanza
[14:38] <Keybuk> otherwise your script will be run *every*single*time* a network interface comes up
[14:38] <smoser> maybe i'm way off base ? but it sure looks like init is responding to an init.conf
[14:38] <jdstrand> Keybuk: my pre-start is: pre-start exec /lib/ufw/ufw-init start
[14:38] <Keybuk> smoser: it's kinda lying :p
[14:38] <jdstrand> Keybuk: that's it
[14:39] <Keybuk> jdstrand: that should be fine - no "task" in the job?
[14:39] <jdstrand> Keybuk: there is no task in the job, no
[14:39] <Keybuk> cool
[14:39] <Keybuk> should work then
[14:39] <Keybuk> you might want or starting networking or starting network-manager in there too
[14:39] <Keybuk> like the n-i-s one
[14:40] <jdstrand> Keybuk: ok, I'll test that here on systems with and without nm, and upload if it works ok
[14:40] <jdstrand> Keybuk: thanks
[14:41] <smoser> so, the gist of the above is that 'init.conf' is undefined behavior, and if i want to enable debug early, i should do a 'start on startup' task with initctl exec. is that right, Keybuk ?
[14:42] <Keybuk> smoser: initctl log-priority you mean?
[14:42] <smoser> right
[14:42] <Keybuk> you may as well just add --verbose to your kernel command-line though ? :)
[14:43] <smoser> on ec2 you can't change kernel params
[14:43] <smoser> but i can write a file and reboot
[14:46] <Keybuk> smoser: there's increasing numbers of justifications for having init.conf do something useful
[14:46] <Keybuk> log priority being one
[14:46] <Keybuk> default environment another
[15:26] <SEJeff> jcastro, ping
[15:30] <jcastro> SEJeff: pong
[15:31] <SEJeff> jcastro, Can you move the ip of gnomejournal.org? Redhat relocated all of the gnome infrastructure to a new colo
[15:32] <jcastro> SEJeff: already did it just now, paul got ahold of me
[15:32] <SEJeff> jcastro, If you just make it a cname to window.gnome.org you won't have to update it the next time something like this happens. Otherwise, the new ip is 209.132.180.167
[15:32] <SEJeff> jcastro, Ah sorry for bothering you then.
[15:32] <jcastro> no worries, doublechecking is always appreciated!
[15:32] <SEJeff> thanks
[16:22] <seb128> is there anybody who feel like reviewing a short patch to fix a libdvdnav locking issue on this channel?
[16:23] <seb128> bug #466389
[16:23] <seb128> comment #21 on the bug
[16:30] <seb128> hum
[16:30] <seb128> slangasek, ^? ;-)
[16:30] <seb128> mterry, hey
[16:30] <seb128> mterry, dunno if you read alex comment but the nautilus patch you submitted recently had an annoying bug
[16:31] <seb128> mterry, just in case you were shipping it somewhere you might want to fix it
[16:40] <slangasek> seb128: dvdnav_clear() tries to call pthread_mutex_lock() a second time; trivially correct
[16:40] <seb128> slangasek, ok thanks
[16:40] <seb128> slangasek, want to sponsor it since you reviewed the change? ;-)
[16:41] <slangasek> Keybuk: confused by the initramfs-tools 0.92bubuntu56 changelog - surely anything that would interrupt the initramfs and cause you to need to type should use the correct keymap, with or without fb?
[16:41] <slangasek> seb128: tricksy!
[16:42] <slangasek> seb128: yeah, I can do that
[16:42] <seb128> lol
[16:42] <seb128> slangasek, thank you ;-)
[16:42]  * seb128 is trying clean a bit the sponsoring queue before holidays
[16:42] <Keybuk> slangasek: that's a hell of an edge case
[16:43] <slangasek> seb128: oh, except that patch has already been accepted into lucid via unstable :)
[16:43] <Keybuk> it's not like anything in the initramfs understands chinese ;)
[16:44] <slangasek> Keybuk: but it understands azerty quite well
[16:44] <seb128> slangasek, oh, good, I should have checked that first
[16:44] <seb128> slangasek, thanks ;-)
[16:44] <Keybuk> slangasek: that should still work once I've finished these changes
[16:44] <Keybuk> all I've done is removed the script that sets the keymap in the normal sequence
[16:45] <Keybuk> not the code that does it in the failure case
[16:45] <slangasek> Keybuk: ok
[16:45] <Keybuk> there's some joining-up to do still
[16:45] <Keybuk> but you shouldn't need to type, unless you get the panic shell, right?
[16:45]  * Keybuk checking he hasn't missed something
[16:46] <slangasek> Keybuk: well, I will need to type, with or without splash, to type my passphrase; but I guess I'm guaranteed to always have the fb there, even with nosplash set?
[16:46] <slangasek> --> with splash not set
[16:46] <Keybuk> slangasek: correct
[16:46] <Keybuk> and splash not set doesn't mean plymouth won't start
[16:46] <Keybuk> it just means plymouth will use a text renderer instead of a graphical one
[16:47] <slangasek> that's the only non-failure case I know of when you need to type in the initramfs, then
[16:47] <slangasek> assuming break=foo is treated as "failure"
[16:47] <Keybuk> yeah it is
[16:47] <Keybuk> basically idea is anything that calls panic() will set up the keymap
[16:48] <Keybuk> actually it does run_scripts /scripts/panic
[16:48] <Keybuk> because that's where I'm putting the plymouth quit thing
[16:48] <Keybuk> rather than hardcoding in the initramfs
[16:48] <Keybuk> so the keymap stuff will be in there too
[16:48] <slangasek> cool
[16:49] <stgraber> btw, I was wondering, is the plymouth from yesterday supposed to stop and prompt for the passphrase (it doesn't here, it simply continues booting without the encrypted partition)
[16:49] <slangasek> stgraber: if you also have the cryptsetup from yesterday?
[16:50] <stgraber> yeah, I basically updated everything this morning
[16:50] <stgraber> I see it's showing some cryptsetup thing on top of the plymouth splash but boots without prompting for the key, then I get gdm and no /home mounted ;)
[16:50] <slangasek> stgraber: bug report wanted, then - please attach /etc/crypttab and /etc/fstab, and tell me which device (if there's more than one) fails to decrypt
[16:51] <stgraber> ok, will do
[16:51] <slangasek> eh, really?
[16:51] <slangasek> gdm was always supposed to wait on /home, per mountall
[16:51] <slangasek> Keybuk: ^^ did that change recently?
[16:52] <Keybuk> slangasek: no
[16:52] <slangasek> funfun
[16:53] <Keybuk> plymouth doesn't go in until I'm happy it won't regress our boot speed
[16:54] <Keybuk> so the mountall that deps on it won't go in either
[16:54]  * slangasek nods
[16:56] <Keybuk> want to make sure the whole cryptsetup and friendly recovery stuff works nicely too obviously
[17:21]  * Ng taps finger at grub-probe. my disks haven't changed since the last kernel postinst you ran in a few seconds ago, but you go nuts and eat all my CPU
[17:29] <slangasek> stgraber: um... you have /home marked 'noauto' in /etc/fstab? :)
[17:31] <stgraber> slangasek: that'd explain some things ... ;)
[17:31] <slangasek> followed up on the bug... thanks for sending me an easy one ;)
[17:32] <stgraber> slangasek: hehe, rebooting now, there can still be an actual bug (other than a user one ;))
[17:38] <firatcan> Headphone jack detection doesn't work on my mbp. I am trying to write a script to change mixer levels when the headphone is plugged. How can I detect the HPs are plugged in?
[17:38] <stgraber> slangasek: sorry, looks like I have an actual bug :)
[17:38] <stgraber> now it justs get stuck at the ubuntu splash logo and does nothing
[17:38] <slangasek> doh!
[17:39] <stgraber> if I start without the splash, it prompts for the key but doesn't seem to take the input
[17:39] <stgraber> so I had to press ESC and set it to noauto again so I'd be able to boot (that's probably I had it commented already ;))
[17:39] <slangasek> stgraber: what version of cryptsetup?
[17:39] <stgraber> 2:1.1.0~rc2-1ubuntu5
[17:40] <slangasek> ok
[17:40] <slangasek> can you send me /var/log/udev.log?
[17:40] <stgraber> maybe something has a different behavior when the root isn't encrypted ?
[17:40] <stgraber> sure, want that attached to the bug ?
[17:40] <slangasek> yes, please
[17:41] <slangasek> hmm, so without splash you see the prompt
[17:41] <slangasek> if you hit ESC at the splash logo, what do you see?
[17:43] <zul> kees: when you get a chance can you review libcap-ng?
[17:44] <stgraber> I'll need to reboot for that, IIRC I saw a sda2_crypt (failed) and then the bash prompt but I'm not 100% sure
[17:44] <kees> zul: still slogging through email backlog.
[17:44] <stgraber> I also remember the shell being broken so I had to "reset" it so I'd see what I'm typing
[17:44] <kees> zul: but yeah, if it's been assigned to me, I'll hit it.
[17:44] <zul> kees: ok
[17:45] <stgraber> Yeah !! Just received my N900 :)
[17:51] <jjardon> hello, the VCS imports of GTK is suspended: https://code.launchpad.net/~vcs-imports/gtk/head. I tried to change the location of the sources from http://svn.gnome.org/svn/gtk+/trunk to git://git.gnome.org/gtk+ but I don't have the required permissions, Could someone fix this?
[17:54] <beuno> jjardon, git:// branches aren't allowed
[17:54] <beuno> they need to be http/https
[17:54] <beuno> (I can update it for you)
[17:58] <jjardon> hello beuno, I think git:// directions worked well for other projects I've imported. But anyway, It'd be great if you update the gtk+ project (also, I think a lot of gnome project need and update to point to the new git repos)
[18:06] <beuno> jjardon, I get: The URI scheme "git" is not allowed. Only URIs with the following schemes may be used: http, https, svn
[18:06] <beuno> jelmer, would you know anything about this?
[18:07] <beuno> I'll try http://git.gnome.org/gtk+
[18:07] <jjardon> beuno, I've used this form: https://code.launchpad.net/+code-imports/+new
[18:07] <jelmer> beuno: you need to switch to git
[18:07] <jelmer> beuno: It sounds like the import is still set to svn
[18:08] <beuno> jelmer, you should have access to change tehat now
[18:08] <beuno> could you take a peak?
[18:08] <beuno> maybe there isn't anything on the web UI to specify svn/git?
[18:09] <beuno> (or it can't be changed)
[18:10] <jelmer> doesn't look like there is a way to change the kind of the import
[18:10] <jelmer> I'll have to remove the existing one and create a new import
[18:12] <jelmer> jjardon: is it ok if I remove the existing import
[18:14] <jelmer> jjardon: ?
[18:14] <jjardon> jelmer, https://code.launchpad.net/~jjardon/gtk/trunk ? sure
[18:15] <jjardon> https://code.launchpad.net/~vcs-imports/gtk/head is already suspended
[18:15] <jelmer> jjardon, the error for your import failing seems different
[18:16] <jjardon> jelmer, Anyway, I didn't want have my own branch, I only wanted to update the main repo to the new git sources
[18:18] <jelmer> jjardon: ok
[18:19] <jjardon> Also, I'd like to help to move all the existing Gnome projects to the new git repos
[18:20] <ion> Only allowing http:// in preference to git:// is pessimal. For Git, http is greatly inferior.
[18:21] <jjardon> jelmer, so, If you need help, please ping me ;)
[18:22] <beuno> ion, we do offer git://, I got confused by the UI  :)
[18:23] <jelmer> ion: in fact, we don't support imports over http for git repos
[18:23] <beuno> heh
[18:25] <ion> Ok, good
[18:31] <james_w> acpi-support is a native package?
[18:32] <james_w> i.e. lp:~ubuntu-core-dev/acpi-support/trunk is the canonical upstream trunk?
[19:12] <bigon> hi, any reasons the locales files have been split out of eglibc pkg? the file are not in sync and this lead to some issues like bug #497497
[19:32] <malev> Hi, is Steve Langasek here?
[19:32] <malev> ... or maybe: Steve Langasek is here? :D
[19:33] <ScottK> malev: He's slangasek
[19:33] <malev> ScottK, thanks.
[19:33] <ScottK> You're welcome
[19:34] <malev> slangasek, hi, I'm malev from the bugsquad. You've reported a bug some days ago, and I'm watching it. I've asked about it in the channel, but we are not sure about it.
[19:39] <bdmurray> malev: I've updated the bug with what I've discovered.
[19:39] <malev> checkin it
[19:39] <bdmurray> I believe that slangasek was checking very early
[19:40] <malev> bdmurray, nice research!!
[19:40] <malev> awesome
[20:20] <ebroder> How does DEP-3 interact with the "## DP:" comments in dpatches?
[20:21] <ebroder> (Is there an example of a dpatch that follows DEP-3 somewhere?)
[20:55] <ion> keybuk: http://launchpadlibrarian.net/36876612/initramfs-tools_0.92bubuntu56_0.92bubuntu57.diff.gz +rm "${DESTDIR}/lib/modules/${version}/modules.*map"
[20:56] <ion> keybuk: Probably shouldn’t have "" around the *
[20:56] <Keybuk> oh good point
[20:56] <Keybuk> meant to close them before the "
[20:56] <Keybuk> will fix that tomorrow
[20:56]  * Keybuk finally made a big step towards figuring out why gdm won't start sometimes
[20:57] <ion> What seems to be the problem?
[20:57] <Keybuk> the local-filesystems event gets blocked
[20:57] <Keybuk> not sure by which yet
[20:57] <Keybuk> but it won't complete
[20:57] <Keybuk> so mountall is still waiting for it
[20:57] <ion> Ok
[21:03] <smoser> anyone able to suggest kvm invocation of lucid guest that will avoid going into graphics mode , so i can use '-curses' ?
[21:04] <smoser> i'm trying: -append "root=/dev/sda ec2init=0 nomodeset" -nographic -curses
[21:30] <slangasek> pitti: "fix daemon.log to not be written synchronously" - er, no?
[21:33] <slangasek> pitti: if things are triggering writes to daemon.log during normal operation, /that/'s a bug that we should fix; but daemon.log is the Secure Record of People Doing Stuff To The System, it's synchronous intentionally and this shouldn't be changed to save a µW :)
[21:35] <slangasek> Keybuk: why would you expect "recreating" the lvm device in the real system (bug #456274) to require re-entering a passphrase?
[21:35] <slangasek> (which is the only part that cryptsetup is responsible for)
[21:36] <Keybuk> slangasek: I wouldn't, but I'm guessing that cryptsetup is blocking udev's operation somehow
[21:37] <Keybuk> ie. when udev says the underlying block device is ready, cryptsetup will be run
[21:37] <Keybuk> and normally that would create the /dev/mapper device
[21:37] <Keybuk> but I'm guessing that because it already exists (because it was created in the initramfs), things don't work out that way
[21:37] <Keybuk> and that somehow blocks the uevent for the mapper device too
[21:37] <slangasek> Keybuk: there's also no "when udev says the underlying block device is ready" in karmic
[21:37] <Keybuk> in the old days, waiting 3 minutes tended to work
[21:38] <Keybuk> slangasek: huh?
[21:38] <Keybuk> there is
[21:38] <Keybuk> it's called a uevent
[21:38] <slangasek> a uevent that cryptsetup pays no attention to
[21:39] <Keybuk> that's where the whole thing gets confusing
[21:39] <Keybuk> the fact is that this works on every dm device *except* cryptsetup ones
[21:39] <Keybuk> so the problem must be with cryptsetup
[21:39] <Keybuk> even if it's somewhere else
[21:40] <slangasek> it works for dm devices *including* cryptsetup ones
[21:40] <Keybuk> but please do debug
[21:40] <slangasek> I have the exact setup the submitter describes
[21:40] <Keybuk> and it works for you?
[21:40] <slangasek> and it works for me
[21:40] <Keybuk> I have an LVM kees-approved setup
[21:40] <Keybuk> and it works for me there too
[21:40] <slangasek> I really think the problem he's having is that he has a broken / line in /etc/fstab
[21:40] <Keybuk> that shouldn't matter
[21:40] <Keybuk> mountinfo overrides fstab
[21:41] <slangasek> there've been other me-tooers on the bug that don't even use cryptsetup
[21:41] <Keybuk> so what was mounted when the initramfs exits is what mountall really uses
[21:41] <Keybuk> mountall gets me-tooers from just about everyone :(
[21:41] <slangasek> hum; then surely mountall is wrong regardless, because in that case it should never be waiting for /?
[21:41]  * kees snickers
[21:42]  * kees imagines running around with a rubber "approved" stamp for VG configs
[21:42] <Keybuk> slangasek: yes
[21:42] <Keybuk> it has to wait for the device to exist and be probed before it can remount it read/write
[21:42] <Keybuk> otherwise if blkid is running, and it's on lvm, etc. you end up with "device in use" issues
[21:42] <slangasek> ah
[21:42] <Keybuk> you can't just mount it read/write willy nilly
[21:42] <Keybuk> and you can't leave it read/only :)
[21:43] <Keybuk> if you don't have an initramfs (which we support)
[21:43] <Keybuk> than you also have the issue where the kernel may have mounted the root device
[21:43] <Keybuk> but it doesn't actually exist in /dev yet
[21:43] <slangasek> right
[21:45] <Keybuk> it's all a bit confusing really
[21:46] <Keybuk> this is stuff that should just work
[21:46] <Keybuk> all mountall is waiting for is the uevent from udev to say the device is made
[21:46] <Keybuk> (and no helpers are running on it anymore)
[21:46] <Keybuk> if that doesn't happen, it means udev doesn't know about the device
[21:46] <Keybuk> which means it shouldn't exist in /dev :p
[21:47] <slangasek> well, I don't see how what cryptsetup is doing could break that
[21:47] <Keybuk> causing pain
[22:23] <ebroder> Can anybody point me at a dpatch that follows DEP-3?
[22:25] <Keybuk> ebroder: any in gdm
[22:27] <ebroder> Keybuk: Huh? gdm's patches appear to be simple-patchsys, not dpatch
[22:30] <Keybuk> so? they still have patch tags at the top
[22:36] <james_w> ebroder: "For patch-systems like dpatch that require the patch to be a standalone script, the shebang line is ignored and it is possible to put those fields in comments. The line should then follow the format “# <field>”. For multi-line fields, the subsequent lines should start with “#  ” (hash followed by two spaces) so that they start with a space once “# ” (hash followed by a space) has been stripped from the beginning."
[22:36] <ebroder> Right, I saw that - I wasn't sure how that interacts with dpatch's support for "## DP:" and such, though
[23:30] <kirkland> slangasek: Keybuk: I have a upstart question that I'm sure I will phrase poorly
[23:32] <slangasek> kirkland: "turquoise"
[23:34] <syn-ack> slangasek: What if he likes "lavender" better? ;) /me runs
[23:34] <kirkland> slangasek: so there's a general "eucalyptus" upstart script
[23:34] <kirkland> slangasek: the other controllers start on started eucalyptus
[23:34] <slangasek> syn-ack: sorry, not supported
[23:35] <syn-ack> slangasek: I merely kid. :P
[23:35] <kirkland> slangasek: and in all of the current cases (sans node-controller), there's an exec of eucalyptus-cloud, which daemonizes, and the eucalyptus upstart script starts happily
[23:35] <kirkland> slangasek: i've ported the eucalyptus-nc init script to upstart now
[23:35] <kirkland> slangasek: and have it set to start on started eucalyptus
[23:35] <kirkland> slangasek: however, in this case there is no eucalyptus-cloud daemon
[23:36] <kirkland> slangasek: so i'm conditionally execing sleep 999999999d
[23:36] <kirkland> slangasek: which works
[23:36] <kirkland> slangasek: but I'm guessing it ain't pretty
[23:36] <kirkland> slangasek: i figure there's got to be a better upstarty way of doing this
[23:36] <kirkland> slangasek: or "must" upstart daemonize something to consider the job "started" ?
[23:36] <slangasek> what is it that's execing sleep?
[23:37] <kirkland> slangasek: the upstart job
[23:37] <slangasek> /which/ upstart job?
[23:37] <kirkland> slangasek: eucalyptus
[23:37] <kirkland> slangasek: lemme pastebin
[23:37] <slangasek> ok
[23:38] <kirkland> ubuntu@beagle:/etc/init$ pastebinit eucalyptus.conf
[23:38] <kirkland> http://pastebin.com/f6c05156f
[23:38] <kirkland> ubuntu@beagle:/etc/init$ pastebinit eucalyptus-nc.conf
[23:38] <kirkland> http://pastebin.com/f2657fc5e
[23:38] <kirkland> ubuntu@beagle:/etc/init$ pastebinit eucalyptus-nc-publication.conf
[23:38] <kirkland> http://pastebin.com/fad45411
[23:39]  * kirkland crosses his arms, taps his foot, and stares coldly at Launchpad
[23:40] <syn-ack> kirkland: I'm still getting remarks that it's in ro mode
[23:40] <kirkland> syn-ack: hence my look of consternation
[23:40] <syn-ack> hah
[23:41] <slangasek> kirkland: so let me see if I understand the reason for this kludge
[23:41] <zul> james_w: when you get a chance can you import samba into bzr
[23:41] <slangasek> you have a eucalyptus job, on which the other jobs depend; but when eucalyptus-nc is installed, the eucalyptus job should be a no-op, but you still want all the other jobs that depend on it (including eucalyptus-nc) to start?
[23:43] <james_w> zul: queued
[23:43] <zul> james_w: meric
[23:43] <kirkland> slangasek: sort of ...
[23:43] <zul> james_w: thanks even :)
[23:44] <kirkland> slangasek: its more that the eucalyptus job is provided by the eucalyptus-common package
[23:44] <kirkland> slangasek: on which all other eucalyptus parts depend
[23:44] <kirkland> slangasek: thus it's installed everywhere
[23:44] <kirkland> slangasek: and makes for one stop shopping when you want to start/stop/restart/status your eucalyptus setup
[23:44] <kirkland> slangasek: so far that's fine and dandy for cloud/walrus/sc/cc
[23:45] <kirkland> slangasek: and today i'm adding support for nc
[23:45] <kirkland> slangasek: which doesn't really actually need the eucalyptus job to start any real daemons
[23:45] <kirkland> slangasek: but for the consistency with the other bits, i added the kludge
[23:45] <kirkland> slangasek: alternatively, i could have eucalyptus-nc start on [23]
[23:46] <slangasek> kirkland: does the eucalyptus job do anything that eucalyptus-nc needs to have happen before it starts?
[23:46] <kirkland> slangasek: but it would make for some inconsistency with the rest of the start/stop/restart eucalyptus which is used everywhere else
[23:46] <kirkland> slangasek: make /var/run/eucalyptus?
[23:46] <kirkland> slangasek: nothing terribly important
[23:46] <slangasek> so you can do one of two things
[23:47] <slangasek> refactor eucalyptus into a eucalyptus-base job and a eucalyptus job, with eucalytpus-nc and eucalyptus both depending on the -base job (which I guess just does the setup at that point, i.e., /var/run/eucalyptus)
[23:47] <slangasek> or get rid of the 'start on starting eucalyptus' from eucalyptus-nc, use something more correct (such as a runlevel start condition, yes) and mkdir -p /var/run/eucalyptus
[23:48] <kirkland> slangasek: hmm, okay
[23:48] <kirkland> slangasek: i have the latter working
[23:48] <slangasek> in any event, I'm sure you don't want to be adding artificial dependencies on things you don't actually need running in order to start the node controller :)
[23:49] <slangasek> and if you don't do that, the sleep is irrelevant
[23:49] <slangasek> btw, your new job will whine when the eucalyptus-nc package is removed but not purged
[23:49] <kirkland> slangasek: do i need "respawn" if i start on runlevel?
[23:50] <slangasek> Keybuk is eventually going to give us magic state to take care of that, but in the meantime I've been writing my jobs to key off a non-conffile shipped in the package
[23:50] <slangasek> kirkland: only if respawn is the behavior you want
[23:50] <slangasek> if the daemon dies, what do you want to have happen?
[23:50] <kirkland> slangasek: hmm, sure, respawn, i like it
[23:51] <kirkland> slangasek: okay, so about the package purging ....
[23:52] <kirkland> slangasek: i'm dropping the changes to the eucalyptus package
[23:52] <kirkland> slangasek: going with your runlevel start on suggestion
[23:52] <kirkland> slangasek: where am i keying on a conf file now?
[23:53] <slangasek> http://pastebin.com/f2657fc5e
[23:53] <Keybuk> yeah
[23:53] <slangasek> actually, I guess that job doesn't whine
[23:53] <Keybuk> basically I intend to work the xmas break on things like that
[23:53] <slangasek> it just /runs/, even when the package is removed :)
[23:53]  * Keybuk remembers when he had a life
[23:54] <slangasek> kirkland: actually, the job will get as far as trying to run euca_test_nc before it fails
[23:55] <slangasek> and then 'exit 1', meaning the job will show as failed instead of administratively stopped
[23:55] <slangasek> oh, and if you mark it respawn, upstart is going to try running it several times before giving up
[23:55] <kirkland> slangasek: so i should check $(which euca_test_nc) ?
[23:56] <slangasek> I'd write it as [ -x /usr/sbin/euca_test_nc ] || { stop; exit 0; }
[23:56] <slangasek> alternatively, you can wait for Keybuk's Christmas present
[23:56] <kirkland> slangasek: got it
[23:56] <kirkland> slangasek: i added that to the top of pre-start
[23:56] <Keybuk> ho ho ho
[23:56] <slangasek> (I myself have not been consistent about handling this case in the jobs I've written, fwiw)
[23:57] <kirkland> slangasek: any other feedback?
[23:57] <kirkland> Keybuk: i saw your note about wanting to look at new upstart scripts
[23:57] <slangasek> well, let me read the whole job then :)
[23:57] <kirkland> Keybuk: shall i paste them for you?
[23:57] <Keybuk> kirkland: e-mail them
[23:57] <Keybuk> for new ones, go ahead and upload
[23:58] <Keybuk> and I'll do post-review
[23:58] <Keybuk> it was more changing existing ones that was going badly wrong :p
[23:58] <Keybuk> because I suck at coding
[23:58] <slangasek> kirkland: "modprobe aoe" - nothing else does this for us?
[23:59] <Keybuk> aoe is one of those silly devices
[23:59] <Keybuk> you load the module when you want them
[23:59] <Keybuk> like ppp and tun
[23:59]  * slangasek nods
[23:59] <slangasek> #
[23:59] <slangasek>         echo -n 1 > /proc/sys/net/ipv4/ip_forward
[23:59] <slangasek> not /etc/sysctl.d?
[23:59] <kirkland> Keybuk: yeah, these are for eucalyptus, so shouldn't affect your boot speed stuff