[00:08] is there a bug #? [00:09] not sure :p [00:09] I don' [00:09] I don't track things using LP [00:11] but usplash is the plan for fixing the issue at hand? [00:12] no idea [00:12] don't have a plan yet [00:17] 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] yes, that's fine [00:18] cryptsetup is asking with usplash on vt8 [00:19] X starts on vt7 [00:20] won't X switch to vt7? [00:20] yes [00:21] how is this not a problem? [00:23] it is [00:23] do you have a solution? [00:23] no [00:25] me neither ;) [00:27] 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] keybuk: http://bazaar.launchpad.net/~ion/ubuntu/karmic/mountall/fsck-locking/revision/109 [00:59] ion: that looks a bit hairy :-/ [01:00] keybuk: Please elaborate. [01:02] as in that's O M G that's a large patch [01:02] I'm scared to apply that without a massive amount of testing [01:07] 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] right, that's what I'm worried about ;) [01:49] ion: did you have an ioprio_set from glibc? last time I used it it was a manual syscall(__NR_ioprio_set) [01:49] I used syscall() [01:50] ion: yeah. someone should send patches for that. === h\h is now known as haraldh [13:11] keybuk: How about putting the patch to ~ubuntu-boot PPA and trying to get a lot of people to test it? :-P === robbiew-afk is now known as robbiew === Keybuk_ is now known as Keybuk [17:15] I'm having some trouble trying to grab the upstart source (to track down a bug in upstart on sparc) [17:15] Anyone mind helping me figure what's up? [17:19] how are you trying to grab it? [17:19] so I have a machine (also sparc) running Jaunty [17:20] I installed bzr, which grabbed version "Bazaar (bzr) 1.13.1" [17:20] I then ran "bzr get https://code.launchpad.net/upstart/trunk" [17:20] and got an error: bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n' [17:20] you almost certainly need bzr 2.0 [17:20] there you go then [17:20] okay, is that installable on jaunty? [17:20] yes [17:20] http://bazaar-vcs.org/ [17:20] how would I do that? [17:21] is that installable on jaunty from a package? [17:21] the documentation is on the bazaar website [17:21] it is, yes [17:21] because, let me be frank, if I cannot use the current release of ubuntu to do ubuntu development, that is amazingly limited [17:23] for Upstart, my rule tends to be that it should compile and build on the current stable release [17:23] but you might need the current *development* release to run it [17:23] since the next stable release actually uses upstart much more fully than before, that's going to be increasingly true [17:23] yeah, I can't install the development release, because of this sparc bug I'm looking into [17:24] *nods* [17:24] bzr is a bit of a special case sadly [17:24] the bzr devs have pushed 2.0 quite strongly [17:24] and there are lots of strange issues when interoperating [17:24] so, anyway, I don't see a package for bzr 2.0. where do I grab it? [17:24] not to mention LP has already been upgrade to 2.0 [17:24] yeah [17:25] katre: if you're on sparc, you may have to grab the source from the PPA and build it youself [17:25] https://edge.launchpad.net/~bzr/+archive/ppa certainly has the 2.0 source package [17:29] 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] thanks [17:30] 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] especially since, right now, it looks like we've fixed all the bugs [17:31] we literally freeze tomorrow, from then on it's all about getting a set of cd images that work [17:31] introducing changes like that ... difficult to sell [17:31] Alright [17:31] but I'll certainly merge it straight into lynx ;) [17:31] Yeah [17:43] Geez, bzr wants to install 61 packages as build dependencies? [17:43] including x windows fonts, I see [17:45] probably due to wanting graphviz, I guess [18:23] Okay, so now I have a working bzr, I can grab the upstart trunk and the libnih trunk. [18:24] How do I build those? Neither the README nor the HACKING files actually answers that [18:24] the README refers to an INSTALL file that does not exist [18:26] I tried running 'autoconf' in each, and it rana bit and then errored out [18:26] (I can provide the error message if that helps) [18:37] 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] 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] see if that helps [18:41] sadmac: Thanks. I get the same error for libnih [18:41] katre: then its a system thing. what platform is this that you had to compile your own bzr? [18:41] Looks like my problems are firstly that libtool isn't installed and didn't get pulled in as part of build-dep [18:42] oh. that'll do ya [18:42] 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] sadmac: I'm on sparc [18:42] katre: what distro? [18:42] ubuntu server, jaunty [18:43] katre: autoreconf -i [18:43] thanks [18:44] autoreconf wants cvs? okay, let's install that [18:45] wat [18:46] it gave an error that cvs wasn't found. I installed it and now it's running [18:46] 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] I feel like I'm getting closer [18:53] autoreconf looks like it worked fine, but when I run configure it ends with this error [18:53] | /configure: line 20354: PKG_PROG_PKG_CONFIG: command not found [18:53] | ./configure: line 20367: syntax error near unexpected token `0.22' [18:54] | ./configure: line 20367: `PKG_PROG_PKG_CONFIG(0.22)' [18:55] I did run aclocal before I ran autoreconf [18:57] Ah, google suggests an unresolved dependency on pkg-config [18:57] let's try it... [18:58] nope [19:00] katre: sounds like a missing macro... Scott's really better with this stuff... [19:03] yeah, I had to re-run aclocal and autoreconf [19:03] and now it dies complaining it needs a newer dbus [19:03] I give up [19:03] * sadmac thought autoreconf -i did the aclocal thing [19:03] if I can't actually build upstart in the currently released ubuntu distro, I can't do it [19:03] ubuntu doesn't ship the newer dbus either? [19:03] hmm [19:03] maybe it does, I'm deep into cargo cult compiling right now [19:03] Fedora didn't, but I'dve thought ubuntu did [19:04] | checking for DBUS... configure: error: Package requirements (dbus-1 >= 1.2.16) were not met [19:04] | apt-cache policy dbus: Candidate: 1.2.12-0ubuntu2.1 [19:04] 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] Sure [19:05] I don't doubt there's a good reason [19:05] 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] katre: what version of upstart do you have on the system now? [19:06] 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] apt-cache policy says 0.3.9-8 [19:06] this all started when I tried upgrading my sparc system to karmic, and the new upstart crashed in the install [19:07] 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] katre: how did you end up building upstart because karmic crashed? [19:08] katre: fedora's sparc support is semi-official. that's a bit of an improvement... [19:09] 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] but apparently I can't build upstart on jaunty without installing, so far, about 70 packages and building bazaar from source [19:10] katre: wait, how did the new upstart crash the install? [19:10] I could try grabbing dbus-1 and building that too, but frankly I give up, this is too frustrating [19:10] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/436758 [19:11] 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] (I did grab the source for the 0.3.9 version in jaunty and it passes all checks, as expected) [19:15] 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] yeah [19:17] katre: you could also try a scratch-install of karmic on a vm. [19:17] katre: or you could mount a drive from a karmic live cd (if they make such things for sparc) [19:18] they don't [19:23] katre: I'd find whoever told Scott that make check failed and have him reproduce it wherever he reproduced it [19:25] yeah [19:26] Thanks very much for the help [19:27] np [19:31] 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] ion: there's neither. to start on startup you just don't put any while or on stanzas [19:32] ion: a job with no on stanzas starts a soon as its conditions are met. [19:32] How about if you only want to start a job manually? [19:32] ion: you set the job in manual mode via a separate configuration file. [19:33] A ‘system’ state would be an elegant solution for halting IMO. :-P [19:35] ion: maybe [19:36] 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] ion: so "while system" is how a job indicates its sensitive to sudden power evaporation [19:38] True, true [19:39] 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] ion: it would be as of now [19:40] Oh? Alright :-) [19:40] ion: it would /not/ be in 0.3. We fixed this. [19:49] 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] ion: maybe. There could be advantages to internalizing it too, since it starts so friggin early [19:55] ion: an idea: suppose upstart ran from initrd [19:56] 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] Yeah [21:41] 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] ... 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] how would you deal with unmounting the root filesystem? [21:42] which needs all processes killed? [21:43] can you mail the log to the ML so I can digest? :p [21:43] I’m probably missing something, but couldn’t one do a lazy unmount? [21:43] if events had before/after periods and you had priorities that could really work [21:44] ion: no, you can't lazy remount [21:53] Keybuk: this is just before shutdown? [21:56] yes [22:07] 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] keybuk: https://lists.ubuntu.com/archives/upstart-devel/2009-October/001097.html [22:15] after system [22:15] mount -o ro,remount / [22:15] reboot -f [22:15] type thing? [22:16] That could actually be just in system.conf’s post-stop script, no real need to have another job just for that. [22:18] good point [22:21] 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] If system.conf is missing for any reason, any jobs with ‘while system’ would still start. [22:23] not a bad idea [23:39] ion: that fits a pattern I've been thinking about [23:40] have init parse its arguments, and each "word" is the name of a job that will be started [23:40] if a config exists, it's started with the config [23:40] otherwise it's just started with no config [23:40] ie. you'd end up with system states for "quiet", "splash", "emergency", "single", etc. [23:40] Good idea [23:41] we could just build in system like that