[00:08] <TomJaeger> is there a bug #?
[00:09] <Keybuk> not sure :p
[00:09] <Keybuk> I don'
[00:09] <Keybuk> I don't track things using LP
[00:11] <TomJaeger> but usplash is the plan for fixing the issue at hand?
[00:12] <Keybuk> no idea
[00:12] <Keybuk> don't have a plan yet
[00:17] <TomJaeger> there's also the issue that if X is started while cryptsetup is asking for a password, it'll activate its own virtual terminal.
[00:18] <Keybuk> yes, that's fine
[00:18] <Keybuk> cryptsetup is asking with usplash on vt8
[00:19] <Keybuk> X starts on vt7
[00:20] <TomJaeger> won't X switch to vt7?
[00:20] <Keybuk> yes
[00:21] <TomJaeger> how is this not a problem?
[00:23] <Keybuk> it is
[00:23] <Keybuk> do you have a solution?
[00:23] <TomJaeger> no
[00:25] <Keybuk> me neither ;)
[00:27] <TomJaeger> okay then, thanks for your input, I'll go ahead and post the relevant parts of the conversation on the bug tracker, so that everybody is on the same page.
[00:57] <ion> keybuk: http://bazaar.launchpad.net/~ion/ubuntu/karmic/mountall/fsck-locking/revision/109
[00:59] <Keybuk> ion: that looks a bit hairy :-/
[01:00] <ion> keybuk: Please elaborate.
[01:02] <Keybuk> as in that's O M G that's a large patch
[01:02] <Keybuk> I'm scared to apply that without a massive amount of testing
[01:07] <ion> The deletions basically rip out the queuing, so that checks are started in parallel again, and the additions basically keep a list of active checks sorted by priority and call setpriority and ioprio_set, which are allowed to fail.
[01:10] <Keybuk> right, that's what I'm worried about ;)
[01:49] <sadmac2> ion: did you have an ioprio_set from glibc? last time I used it it was a manual syscall(__NR_ioprio_set)
[01:49] <ion> I used syscall()
[01:50] <sadmac2> ion: yeah. someone should send patches for that.
[13:11] <ion> keybuk: How about putting the patch to ~ubuntu-boot PPA and trying to get a lot of people to test it? :-P
[17:15] <katre> I'm having some trouble trying to grab the upstart source (to track down a bug in upstart on sparc)
[17:15] <katre> Anyone mind helping me figure what's up?
[17:19] <Keybuk> how are you trying to grab it?
[17:19] <katre> so I have a machine (also sparc) running Jaunty
[17:20] <katre> I installed bzr, which grabbed version "Bazaar (bzr) 1.13.1"
[17:20] <katre> I then ran "bzr get https://code.launchpad.net/upstart/trunk"
[17:20] <katre> and got an error: bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n'
[17:20] <Keybuk> you almost certainly need bzr 2.0
[17:20] <Keybuk> there you go then
[17:20] <katre> okay, is that installable on jaunty?
[17:20] <Keybuk> yes
[17:20] <Keybuk> http://bazaar-vcs.org/
[17:20] <katre> how would I do that?
[17:21] <katre> is that installable on jaunty from a package?
[17:21] <Keybuk> the documentation is on the bazaar website
[17:21] <Keybuk> it is, yes
[17:21] <katre> because, let me be frank, if I cannot use the current release of ubuntu to do ubuntu development, that is amazingly limited
[17:23] <Keybuk> for Upstart, my rule tends to be that it should compile and build on the current stable release
[17:23] <Keybuk> but you might need the current *development* release to run it
[17:23] <Keybuk> since the next stable release actually uses upstart much more fully than before, that's going to be increasingly true
[17:23] <katre> yeah, I can't install the development release, because of this sparc bug I'm looking into
[17:24] <Keybuk> *nods*
[17:24] <Keybuk> bzr is a bit of a special case sadly
[17:24] <Keybuk> the bzr devs have pushed 2.0 quite strongly
[17:24] <Keybuk> and there are lots of strange issues when interoperating
[17:24] <katre> so, anyway, I don't see a package for bzr 2.0. where do I grab it?
[17:24] <Keybuk> not to mention LP has already been upgrade to 2.0
[17:24] <katre> yeah
[17:25] <Keybuk> katre: if you're on sparc, you may have to grab the source from the PPA and build it youself
[17:25] <Keybuk> https://edge.launchpad.net/~bzr/+archive/ppa certainly has the 2.0 source package
[17:29] <ion> keybuk: So... What to do with the fsck priority patch? Do you see a way to make it considerably smaller or to get enough testing, or should i just forget about it? :-P How about putting a it to the ubuntu-boot PPA for testing?
[17:29] <katre> thanks
[17:30] <Keybuk> ion: I just don't see myself being able to convince the release manager to let me ship that the day before we freeze
[17:30] <Keybuk> especially since, right now, it looks like we've fixed all the bugs
[17:31] <Keybuk> we literally freeze tomorrow, from then on it's all about getting a set of cd images that work
[17:31] <Keybuk> introducing changes like that ... difficult to sell
[17:31] <ion> Alright
[17:31] <Keybuk> but I'll certainly merge it straight into lynx ;)
[17:31] <ion> Yeah
[17:43] <katre> Geez, bzr wants to install 61 packages as build dependencies?
[17:43] <katre> including x windows fonts, I see
[17:45] <katre> probably due to wanting graphviz, I guess
[18:23] <katre> Okay, so now I have a working bzr, I can grab the upstart trunk and the libnih trunk.
[18:24] <katre> How do I build those? Neither the README nor the HACKING files actually answers that
[18:24] <katre> the README refers to an INSTALL file that does not exist
[18:26] <katre> I tried running 'autoconf' in each, and it rana  bit and then errored out
[18:26] <katre> (I can provide the error message if that helps)
[18:37] <katre> actually, I misspoke. autoconf runs fine, then ./configure runs a bit and finally gives "configure: error: cannot find install-sh or install.sh in "." "./.." "./../..""
[18:40] <sadmac> katre: you configure libnih first. Then you go into the upstart folder and do ../relative/path/to/libnih/nihify and then you configure upstart.
[18:40] <sadmac> see if that helps
[18:41] <katre> sadmac: Thanks. I get the same error for libnih
[18:41] <sadmac> katre: then its a system thing. what platform is this that you had to compile your own bzr?
[18:41] <katre> Looks like my problems are firstly that libtool isn't installed and didn't get pulled in as part of build-dep
[18:42] <sadmac> oh. that'll do ya
[18:42] <katre> and secondly that I've never used autoconf before and there's no documentation of the exact commands to run to get from a fresh source tree to something compilable
[18:42] <katre> sadmac: I'm on sparc
[18:42] <sadmac> katre: what distro?
[18:42] <katre> ubuntu server, jaunty
[18:43] <sadmac> katre: autoreconf -i
[18:43] <katre> thanks
[18:44] <katre> autoreconf wants cvs? okay, let's install that
[18:45] <sadmac> wat
[18:46] <katre> it gave an error that cvs wasn't found. I installed it and now it's running
[18:46] <katre> between that and bzr pulling in all of X I've installed a heck of a lot of stuff just to build upstart
[18:53] <katre> I feel like I'm getting closer
[18:53] <katre> autoreconf looks like it worked fine, but when I run configure it ends with this error
[18:53] <katre> | /configure: line 20354: PKG_PROG_PKG_CONFIG: command not found
[18:53] <katre> | ./configure: line 20367: syntax error near unexpected token `0.22'
[18:54] <katre> | ./configure: line 20367: `PKG_PROG_PKG_CONFIG(0.22)'
[18:55] <katre> I did run aclocal before I ran autoreconf
[18:57] <katre> Ah, google suggests an unresolved dependency on pkg-config
[18:57] <katre> let's try it...
[18:58] <katre> nope
[19:00] <sadmac> katre: sounds like a missing macro... Scott's really better with this stuff...
[19:03] <katre> yeah, I had to re-run aclocal and autoreconf
[19:03] <katre> and now it dies complaining it needs a newer dbus
[19:03] <katre> I give up
[19:03]  * sadmac thought autoreconf -i did the aclocal thing
[19:03] <katre> if I can't actually build upstart in the currently released ubuntu distro, I can't do it
[19:03] <sadmac> ubuntu doesn't ship the newer dbus either?
[19:03] <sadmac> hmm
[19:03] <katre> maybe it does, I'm deep into cargo cult compiling right now
[19:03] <sadmac> Fedora didn't, but I'dve thought ubuntu did
[19:04] <katre> | checking for DBUS... configure: error: Package requirements (dbus-1 >= 1.2.16) were not met
[19:04] <katre> | apt-cache policy dbus: Candidate: 1.2.12-0ubuntu2.1
[19:04] <sadmac> katre: upstart uses a lot of dbus that other applications never have. A result has been that we found problems with dbus that nothing else ever stumbled on. That dbus release has the resulting pile of fixes
[19:05] <katre> Sure
[19:05] <katre> I don't doubt there's a good reason
[19:05] <katre> I just know that I've been banging at this for a bit and determined that there's no easy way to get into mupstart development
[19:06] <sadmac> katre: what version of upstart do you have on the system now?
[19:06] <katre> and since no one else seems particularly worried that the next version of upstart crashes on sparc, it'll stay until someone else tries to fix it
[19:06] <katre> apt-cache policy says 0.3.9-8
[19:06] <katre> this all started when I tried upgrading my sparc system to karmic, and the new upstart crashed in the install
[19:07] <katre> so I will either keep these servers at jaunty or find a new distro that actually supports sparc (I am aware that sparc is not officially supported by ubuntu but it's been fine til now)
[19:08] <sadmac> katre: how did you end up building upstart because karmic crashed?
[19:08] <sadmac> katre: fedora's sparc support is semi-official. that's a bit of an improvement...
[19:09] <katre> I grabbed the upstart source from bazaar, thinking if I can at least build it I could try and run down the problem
[19:10] <katre> but apparently I can't build upstart on jaunty without installing, so far, about 70 packages and building bazaar from source
[19:10] <sadmac> katre: wait, how did the new upstart crash the install?
[19:10] <katre> I could try grabbing dbus-1 and building that too, but frankly I give up, this is too frustrating
[19:10] <katre> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/436758
[19:11] <katre> I was trying to get to the point where I can run 'make check' and see if I can duplicate the failure mentioned here
[19:12] <katre> (I did grab the source for the 0.3.9 version in jaunty and it passes all checks, as expected)
[19:15] <sadmac> katre: you could disable the dbus check in the makefile. you'll get piles of errors in make check though (since it'll trip over all those bugs that were fixed)
[19:16] <katre> yeah
[19:17] <sadmac> katre: you could also try a scratch-install of karmic on a vm.
[19:17] <sadmac> katre: or you could mount a drive from a karmic live cd (if they make such things for sparc)
[19:18] <katre> they don't
[19:23] <sadmac> katre: I'd find whoever told Scott that make check failed and have him reproduce it wherever he reproduced it
[19:25] <katre> yeah
[19:26] <katre> Thanks very much for the help
[19:27] <sadmac> np
[19:31] <ion> Misc. rambling: instead of a ‘startup’ event, 0.10 should have a ‘system’ state. Instead of ‘start on startup’, jobs would have ‘while system’. Shutdown/reboot would happen by running ‘stop system ACTION=reboot’; all ‘while system’ jobs would stop and there would be a halt.conf job that looks something like ‘around system’, ‘post-stop exec if [ "$SHUTDOWN_ACTION" = reboot ]; then reboot -f; else halt -f; fi’.
[19:31] <sadmac> ion: there's neither. to start on startup you just don't put any while or on stanzas
[19:32] <sadmac> ion: a job with no on stanzas starts a soon as its conditions are met.
[19:32] <ion> How about if you only want to start a job manually?
[19:32] <sadmac> ion: you set the job in manual mode via a separate configuration file.
[19:33] <ion> A ‘system’ state would be an elegant solution for halting IMO. :-P
[19:35] <sadmac> ion: maybe
[19:36] <sadmac> ion: its actually a nice addition to the current mechanism. All your crash-only jobs that don't need to be killed before cutting the power can just omit the while system stanza
[19:36] <sadmac> ion: so "while system" is how a job indicates its sensitive to sudden power evaporation
[19:38] <ion> True, true
[19:39] <ion> How to tell the halt job whether to halt or reboot? I’m not sure whether environment from the ‘stop system’ command should be available to halt.conf’s post-stop script.
[19:40] <sadmac> ion: it would be as of now
[19:40] <ion> Oh? Alright :-)
[19:40] <sadmac> ion: it would /not/ be in 0.3. We fixed this.
[19:49] <ion> In fact, Upstart wouldn’t really need to treat the system state in a special way, there could simply be an empty /etc/init/system.conf that comes with the package. People would just be told to point to that for anything that requires some action before halting the system.
[19:55] <sadmac> ion: maybe. There could be advantages to internalizing it too, since it starts so friggin early
[19:55] <sadmac> ion: an idea: suppose upstart ran from initrd
[19:56] <sadmac> ion: system pre-start becomes the core script of dracut as it is now. when system itself starts, upstart re-execs on the new root.
[19:59] <ion> Yeah
[21:41] <ion> keybuk: A summary of what we discussed above: a ‘system’ state in 0.10 could provide an elegant way to handle shutdown. Any job that requires some action just before halt/reboot would do ‘while system’ and possibly have a pre/post-stop script, whereas on-startup jobs that don’t mind the computer suddenly disappearing would not have any while/on stanzas. To reboot, one could run ‘stop system SHUTDOWN_ACTION=reboot’; halt.conf could contain something ...
[21:41] <ion> ... like ‘around system’, ‘post-stop exec if [ "$SHUTDOWN_ACTION" = reboot ]; then reboot -f; else halt -f; fi’. In fact, Upstart wouldn’t necessarily need to handle the ‘system’ state in any special way, a standard /etc/init/system.conf with no contents would suffice, but an implicit job would be nicer IMHO. sadmac pointed out that Dracut’s core script could be a pre-start script for the system job if Upstart is started from initramfs.
[21:42] <Keybuk> how would you deal with unmounting the root filesystem?
[21:42] <Keybuk> which needs all processes killed?
[21:43] <Keybuk> can you mail the log to the ML so I can digest? :p
[21:43] <ion> I’m probably missing something, but couldn’t one do a lazy unmount?
[21:43] <Keybuk> if events had before/after periods and you had priorities that could really work
[21:44] <Keybuk> ion: no, you can't lazy remount <g>
[21:53] <sadmac> Keybuk: this is just before shutdown?
[21:56] <Keybuk> yes
[22:07] <ion> The filesystem state could have ‘while system and stuff’ and anything that needs to close files would have ‘while filesystem’. stop system → anything depending on filesystem would stop, the filesystem job would stop (handle unmounts etc. here), the system job would stop, the halt job would stop (and shutdown the system).
[22:14] <ion> keybuk: https://lists.ubuntu.com/archives/upstart-devel/2009-October/001097.html
[22:15] <Keybuk> after system
[22:15] <Keybuk> mount -o ro,remount /
[22:15] <Keybuk> reboot -f
[22:15] <Keybuk> type thing?
[22:16] <ion> That could actually be just in system.conf’s post-stop script, no real need to have another job just for that.
[22:18] <Keybuk> good point
[22:21] <ion> I’d probably like Upstart to internally initialize a ‘system’ job with an empty job with no while/on conditions (so that it simply starts immediately), but anything in system.conf would extend that (e.g. the post-stop script to shutdown the box).
[22:22] <ion> If system.conf is missing for any reason, any jobs with ‘while system’ would still start.
[22:23] <Keybuk> not a bad idea
[23:39] <Keybuk> ion: that fits a pattern I've been thinking about
[23:40] <Keybuk> have init parse its arguments, and each "word" is the name of a job that will be started
[23:40] <Keybuk> if a config exists, it's started with the config
[23:40] <Keybuk> otherwise it's just started with no config
[23:40] <Keybuk> ie. you'd end up with system states for "quiet", "splash", "emergency", "single", etc.
[23:40] <ion> Good idea
[23:41] <Keybuk> we could just build in system like that