| TomJaeger | is there a bug #? | 00:08 |
|---|---|---|
| Keybuk | not sure :p | 00:09 |
| Keybuk | I don' | 00:09 |
| Keybuk | I don't track things using LP | 00:09 |
| TomJaeger | but usplash is the plan for fixing the issue at hand? | 00:11 |
| Keybuk | no idea | 00:12 |
| Keybuk | don't have a plan yet | 00:12 |
| 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:17 |
| Keybuk | yes, that's fine | 00:18 |
| Keybuk | cryptsetup is asking with usplash on vt8 | 00:18 |
| Keybuk | X starts on vt7 | 00:19 |
| TomJaeger | won't X switch to vt7? | 00:20 |
| Keybuk | yes | 00:20 |
| TomJaeger | how is this not a problem? | 00:21 |
| Keybuk | it is | 00:23 |
| Keybuk | do you have a solution? | 00:23 |
| TomJaeger | no | 00:23 |
| Keybuk | me neither ;) | 00:25 |
| 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:27 |
| ion | keybuk: http://bazaar.launchpad.net/~ion/ubuntu/karmic/mountall/fsck-locking/revision/109 | 00:57 |
| Keybuk | ion: that looks a bit hairy :-/ | 00:59 |
| ion | keybuk: Please elaborate. | 01:00 |
| 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:02 |
| 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:07 |
| Keybuk | right, that's what I'm worried about ;) | 01:10 |
| 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:49 |
| sadmac2 | ion: yeah. someone should send patches for that. | 01:50 |
| === h\h is now known as haraldh | ||
| ion | keybuk: How about putting the patch to ~ubuntu-boot PPA and trying to get a lot of people to test it? :-P | 13:11 |
| === robbiew-afk is now known as robbiew | ||
| === Keybuk_ is now known as Keybuk | ||
| 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:15 |
| Keybuk | how are you trying to grab it? | 17:19 |
| katre | so I have a machine (also sparc) running Jaunty | 17:19 |
| 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:20 |
| 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:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:29 |
| 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:30 |
| 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:31 |
| katre | Geez, bzr wants to install 61 packages as build dependencies? | 17:43 |
| katre | including x windows fonts, I see | 17:43 |
| katre | probably due to wanting graphviz, I guess | 17:45 |
| katre | Okay, so now I have a working bzr, I can grab the upstart trunk and the libnih trunk. | 18:23 |
| 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:24 |
| 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:26 |
| 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:37 |
| 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:40 |
| 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:41 |
| 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:42 |
| sadmac | katre: autoreconf -i | 18:43 |
| katre | thanks | 18:43 |
| katre | autoreconf wants cvs? okay, let's install that | 18:44 |
| sadmac | wat | 18:45 |
| 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:46 |
| 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:53 |
| katre | | ./configure: line 20367: `PKG_PROG_PKG_CONFIG(0.22)' | 18:54 |
| katre | I did run aclocal before I ran autoreconf | 18:55 |
| katre | Ah, google suggests an unresolved dependency on pkg-config | 18:57 |
| katre | let's try it... | 18:57 |
| katre | nope | 18:58 |
| sadmac | katre: sounds like a missing macro... Scott's really better with this stuff... | 19:00 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| katre | (I did grab the source for the 0.3.9 version in jaunty and it passes all checks, as expected) | 19:12 |
| 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:15 |
| katre | yeah | 19:16 |
| 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:17 |
| katre | they don't | 19:18 |
| sadmac | katre: I'd find whoever told Scott that make check failed and have him reproduce it wherever he reproduced it | 19:23 |
| katre | yeah | 19:25 |
| katre | Thanks very much for the help | 19:26 |
| sadmac | np | 19:27 |
| 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:31 |
| 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:32 |
| ion | A ‘system’ state would be an elegant solution for halting IMO. :-P | 19:33 |
| sadmac | ion: maybe | 19:35 |
| 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:36 |
| ion | True, true | 19:38 |
| 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:39 |
| 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:40 |
| 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:49 |
| 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:55 |
| 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:56 |
| ion | Yeah | 19:59 |
| 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:41 |
| Keybuk | how would you deal with unmounting the root filesystem? | 21:42 |
| Keybuk | which needs all processes killed? | 21:42 |
| 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:43 |
| Keybuk | ion: no, you can't lazy remount <g> | 21:44 |
| sadmac | Keybuk: this is just before shutdown? | 21:53 |
| Keybuk | yes | 21:56 |
| 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:07 |
| ion | keybuk: https://lists.ubuntu.com/archives/upstart-devel/2009-October/001097.html | 22:14 |
| Keybuk | after system | 22:15 |
| Keybuk | mount -o ro,remount / | 22:15 |
| Keybuk | reboot -f | 22:15 |
| Keybuk | type thing? | 22:15 |
| ion | That could actually be just in system.conf’s post-stop script, no real need to have another job just for that. | 22:16 |
| Keybuk | good point | 22:18 |
| 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:21 |
| ion | If system.conf is missing for any reason, any jobs with ‘while system’ would still start. | 22:22 |
| Keybuk | not a bad idea | 22:23 |
| Keybuk | ion: that fits a pattern I've been thinking about | 23:39 |
| 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:40 |
| Keybuk | we could just build in system like that | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!