[02:13] NCommander: Need some help on qt4-x11 on powerpc. [02:14] NCommander: slangasek figured a work-around for the ld segfault, we just need some help figuring out how to mangle the .pro files to make it apply to powerpc. === asac_ is now known as asac [02:35] is lucid stable enough to test yet? [02:35] in other words, is it worth in install , without having to hack the rest together? [02:36] WFM; YMMV [04:57] * hyperair just realized that file-roller doesn't seem to have been merged/synced from debian for a long time. is there a reason for that? === nxvl_ is now known as nxvl [04:58] Most likely no one did it. [04:58] it doesn't appear in merges.ubuntu.com either [04:58] hyperair: We have our version of it [04:58] and all the file-roller changelog entries are -0ubuntu1 [04:59] hyperair: IE, we handle the packaging of it, and don't want to use Debian's packaging [04:59] ah i see === dyfet` is now known as dyfet [05:04] Hello [05:05] Does anyone have any insight as to why do-release-upgrade would fail with no new release found on Jaunty at this time ? [07:01] didrocks: Hm. In the ubuntu-netbook-remix-default-settings postrm: if [ ! -d /var/lib/gconf/une.mandatory ]; then rm -rf /var/lib/gconf/une.mandatory ; fi [07:01] didrocks: Isn't that test backwards, and should be if [ -d ? [07:05] Good morning [07:06] Morning pitti! [07:06] hey StevenK [07:06] hm, a weekend and no pings in scrollback? must be Christmas.. [07:24] pitti: Haha! [07:34] pitti: Thanks for your help getting the fix for bug #223281 into Karmic... how do we now get it into Lucid? Officially it should have gone into Lucid first, but that doesn't seem to have happened in this case? Or am I just confused? [07:34] Launchpad bug 223281 in python2.6 "locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() )" [Medium,Fix released] https://launchpad.net/bugs/223281 [07:36] jmarsden: erm, it is? see comment 37, and hte lucid task is closed [07:36] $ LANG=en_AG python2.6 -c "import locale ; print locale.getdefaultlocale()" [07:36] ('en_AG', None) [07:36] ^ on lucid [07:36] I tested that when I sponsored [07:38] OK, I missed that comment. I read comment #36 and didn't realize you'd been able to get the patch to work in Lucid OK. Cool. [08:32] good morning [09:25] james_w: I trying to merge "dictionaries-common" the bzr way: bzr branch lp:ubuntu/lucid/dictionaries-common, bzr merge-package lp:debian/squeeze/dictionaries-common but I get "bzr: ERROR: No such tag: upstream-1.4.0". Did I something wrong or is this because it's a native package? [09:37] geser: merge-package is currently broken with native packages, you can use "bzr merge" until it is fixed. === mac_v is now known as kvc [09:39] james_w: thanks, this worked === kvc is now known as vish [10:34] pitti: kubuntu-dev approved Lure to for a per-package upload for digikam and kdegraphics, are you able to add those permissions for him? [10:34] Riddell: technically yes, but formally this has to be run by DMB [10:35] (since these packages are in main) [10:36] I agree that this is a bit weird, since you could give him even more permissions by adding him to kubuntu-dev without getting DMB ack [10:36] pitti: we weren't clear if we were empowered to do such things but since the packages are within the list of kubuntu-dev it would seem daft if we couldn't approve for a subset of kubuntu-dev [10:36] so eventually this policy needs to be cleaned up wrt. existing delegations [10:37] pitti: how do I contact the DMB then? [10:38] Riddell: developer-membership-board@lists.ubuntu.com [10:38] in that thread we should also discuss a general policy change for this delegation case [10:38] seems silly right now [10:58] slangasek: I'm not sure why you've marked "migrate apparmor to Upstart" as DONE when there's still clearly an init script [11:11] james_w: is there a standard way of importing just an upstream release tarball, given the upstream branch on which it's based? [11:12] cjwatson: "just" ? [11:12] well, I don't want to do a merge as well, like merge-upstream does - I just want the import step [11:13] there's no way currently [11:13] from the CLI at least [11:14] oh, how does it figure out the release tarball from just a branch? doesn't that require a watch file? [11:14] ok, so I guess I just unpack, 'bzr add --file-ids-from path-to-other-branch', and commit [11:16] pitti: in my case I'm talking about a manual operation for a package natively maintained in bzr [11:16] ah [11:16] I just imported openssh's CVS history :) [11:16] and glued it into the upstream import [11:50] Would an archive admin please reject karmic-proposed's alsa-lib_1.0.20-3ubuntu6.1? I'm reworking the SRU debdiff based on a newer patch by upstream (based on my submitted patch). [11:54] crimsun: done [12:06] pitti: thanks. SRU proposal updated and uploaded. [12:25] what's the CLI version to add a ppa to the sources.list? [12:28] add-apt-repository ppa:foo IIRC [12:30] ion: great - thanks [12:32] keybuk: https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid but unfortunately i’m unable to make a bootchart with this change, since plymouth just cancels any fscks in my VM. [12:41] how does plymouth cancel fscks? [12:43] (merged) [12:44] keybuk: I haven’t investigated it any further, but plymouth seems unable to display aything, and whenever mountall starts a fsck, it gets cancelled immediately. [12:44] I assumed it’s due to the user interaction code thinking the user pressed esc or somethig. [12:47] pitti, you about? wondering if you/anyone knows where the base corelimit is set [12:49] ion: possibly, am working on that code today a bit [12:49] Keybuk, ion? [12:49] apw: comes from the kernel, overridden by upstart "limit core" (if any), overridden by PAM /etc/security/limits.conf (if set), overridden by bash, etc. [12:50] ahh... a person :) [12:50] I think it basically ends up 0 all the way down [12:50] Keybuk, so where would i find limit core, in .conf files for upstart yes? [12:51] apw: I don't think we override it anywhere [12:51] ok so it must be 0 in the kernel then [13:01] Keybuk, ok if i needed to set rlimit core to 1 for 'everything' is that easy in upstart [13:07] meh, gdm still fails to start [13:07] apw: -1 you mean? [13:07] no, it's not easy [13:07] unless you want to patch the kernel? :p [13:07] no i mean 1 [13:07] it seems gdm and KMS start around the same time, and both lose [13:07] apw: it should be 0 by default, shouldn't it? [13:08] 1 is a tiny core limit? [13:08] apw: you can override it in /etc/security/limits.conf [13:08] it's 0 by default (as it should be) [13:08] apw: what are you trying to do? [13:09] pitti, well yes and no, a new mechanism to handle detect recursive core dumping by the core dump pipe process has changed the semantics of 0 for that case [13:09] in that i really does mean no dump ... any other value means infinity with pipe [13:09] ah, so that was it [13:09] yep [13:09] apw: if something in the kernel has changed what the default should be, change the kernel default to match ? [13:09] so one option would be to use 1 [13:10] Keybuk, the default is what its meant to be. no core. [13:10] just the meaning in the face of pipe has changed [13:10] apw: 1 would mean 0 for all practical cases, but enable pipe again? [13:10] apw: then the default throughout the system will also be "no core", right? [13:11] since ulimit -c in my shell says "unlimited", something must be setting it to -1 [13:11] pitti, my testing of that says so yes [13:11] (apparently my own .zshrc :p) [13:11] Keybuk, its returning 0 for me [13:11] right [13:11] it's 0 by default (as it should be) [13:12] Keybuk, the default is what its meant to be. no core. [13:12] ... [13:12] so we're all on the same page here? [13:12] the default is 0 (no core), and we all think it should be? [13:12] ack [13:12] basically we want no core without apport, and a core with apport right? [13:12] well, I don't particularly care about the exact value 0 [13:12] and we are using the way 0 worked to get that [13:12] just to not clutter the fs with core files by default [13:12] right, that is my understanding [13:12] no core files, but yes to core pipes [13:13] right ... so i think a dirty fix would be to have the default be 1 [13:13] that's what Neil Hormann recommended, too [13:13] (thanks for digging out that commit) [13:13] sounds reasonable [13:13] i do like the safety aspect of the 0 == die on recursion [13:13] so where the kernel sets 0 as the default, change that to 1 [13:13] so if we are happy 1 is good, we have to decide how to set it for us [13:14] well if its easy to change it in /etc/security/limits.conf that would be lower impact [13:14] apw: that won't work [13:14] (on me) :) [13:14] for a start, PAM is not used for system daemons [13:14] so those would still have 0 [13:14] that wouldn't catch early boot and daemons, though [13:14] right [13:14] you could set it in upstart, but that's a hacky code change to work around the fact we don't have the source to our kernel [13:14] (which we do) [13:14] you could set it in the initramfs, but then anyone not using an initramfs would have 0 [13:14] does apport start early enough to get cores there? [13:15] really, set it in the kernel ;P [13:15] apw: it doesn't matter when apport starts; apport isn't inherited [13:15] apport is either on or off [13:15] if you start a system daemon, then start apport, cores go to appor [13:15] +t [13:15] fair [13:15] also, I'd point out that any point you're trying to do this in the boot sequence is adding at least one syscall to our boot ;) [13:16] maybe even an entire shell script [13:16] etc. [13:16] just to work around changing a default in the kernel :P [13:16] heh all changes have risk, specially where noone has added an option for it (sadly) [13:28] who can I interest in giving a session at UDW? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep [13:36] pitti: are there any plans to change ia32-libs in lucid? I think I heard something about it but I'm not sure [13:37] tseliot: foundations is working on a real multiarch implementation, but right now I don't know whether that will land soon enough [13:38] pitti: ah, ok. I asked as I need to use alternatives in ia32-libs too. I think I'll just modify that package until a different solution is found [13:54] mathiaz: ping [13:54] sgallagh: hi! [13:55] sgallagh: I noticed sssd 1.0 had been released. [13:55] mathiaz: Long time no see. How was your vacation? :) [13:55] sgallagh: great! thanks :) [13:55] mathiaz: I was trying to reach you last week to get a build done of the pre-release code to make sure nothing was broken for you, but you were away and I didn't know who was filling in. [13:56] So hopefully 1.0.0 doesn't break anything for you, but we can work out a patch if needed. === freeflyi1g is now known as freeflying [13:56] sgallagh: right - that's ok. I may have some more spare cycle in the new year to make sure things are all good for 1.0.0 [13:56] sgallagh: I'll let you know if I run into some issues with 1.0 [13:57] mathiaz: Please do. [13:57] mathiaz: I also wanted to know: did you ever build either of the pre-releases (0.99.0 and 0.99.1)? Because we discovered a security bug in them. [13:57] (It's fixed in 1.0.0) [13:57] sgallagh: nope [13:57] mathiaz: ok, great [13:58] The bug wasn't present in 0.7.1 or earlier, so Karmic is probably safe. [13:58] sgallagh: good to know === ArneGoet1e is now known as ArneGoetje [14:25] tseliot, ion: did you notice that plymouth starts on the wrong VT> [14:27] Keybuk: no, as I haven't used Lucid for a while. Does it start on vt1? [14:27] well [14:27] that's the funny thing [14:27] I haven’t really got around to looking at plymouth yet. [14:27] it switches to vt7 [14:27] but then appears on vt1 [14:27] I think this is why the input is screwed up [14:27] and think this is why the X transition is screwed up [14:27] Ah [14:29] Keybuk: does this happen only on boot? [14:29] no [14:29] start plymouth on the console does it too [14:29] (assuming X isn't running :p) [14:29] it ends up over your current VT [14:31] hopefully gdb will help us see what's grabbing vt1 [14:31] * Keybuk gets karmic deja-vu [14:31] debugging filesystem progress notification results in debugging the splash screen [14:32] :-/ [14:32] it's all good really [14:32] it all needs debugging [14:32] and at least it's not usplash :p [14:33] heh [14:33] :-) [14:33] I made mountall not depend on plymouth anyway [14:34] if plymouth isn't running, it pretends that the broken filesystem had "nobootwait" in it :p [14:35] I'll have more time to spend on plymouth as soon as I'm done with nvidia [14:35] * tseliot -> doctor === sommer_ is now known as sommer [15:24] anyone have an update to date archive mirror that they can 'du -sm' for me ? i'm just mirroring and want to see what I'm shooting for. currently i've got 268332 [15:24] i think i've got to be close === vish is now known as mac_v [15:27] Keybuk, i think you mentioned a way once to me that I could ensure that I ran before a given upstart job. [15:28] explicitly, I want to ensure that I run before rc-sysinit.conf [15:28] on starting rc-sysinit ? [15:29] incidently: gdm doesn't start after booting in recovery mode and selecting 'continue normal boot'; one has to run gdm-binary by hand [15:41] ion: try current mountall [15:41] (trunk) [15:42] smoser: http://www.mirrorservice.org/sites/archive.ubuntu.com/ubuntu/ [15:53] Keybuk: because I can never keep apparmor and apport straight [15:53] even between one terminal window and the next [15:53] slangasek: Really? It's easy - one of them reports bugs, and the other one creates bugs [15:55] anyone know how to clean/delete previous conversation in empathy ? === robbiew is now known as robbiew_ [15:58] pitti: Would you please rescore gcc-4.4 on ia64 down to 2000? We're about to upload a complete KDE release and we'll have fewer failures/retries later if it doesn't get blocked behind gcc. [16:02] ScottK: done [16:03] pitti: Thanks. [16:05] keybuk: http://heh.fi/tmp/mountall/ [16:06] keybuk: The prioritization seems to work fine with plain ioprio_set. [16:06] Keybuk, so right now, rc-sysinit.conf is "filesystem and net-device-up IFACE=lo" [16:06] keybuk: I wonder why mountall uses so much CPU at the end? [16:07] in the end (maybe this works now) I want my script to be "(mounted MOUNTPOINT=/ and net-device-up IFACE=eth0)" [16:07] but for now, i have "(local-filesystems and net-device-up IFACE=eth0)" [16:07] smoser: your script will *halt* filesystem mounting and stuff until it finishes [16:07] you know that, right? :p [16:07] i want to some how say "make sure this runs before the rc-sysvinit" [16:07] don't look at the rc-sysinit.conf [16:07] because it's broken [16:08] Keybuk, right. i know it will do that. [16:08] ok, so i see that if i run early and block i will obviously run before sysvinit [16:08] ion: probably parsing the fsck -C output and handing it to mountall [16:09] but is there a way to genericlly, from one script say "i have to run before another" [16:09] smoser: no [16:09] right now i'm trying to debug, i want to insert a script that runs before anothe rone [16:09] smoser: you can say "I have to run when another is started", but that's quite, quite different [16:09] oh, i guess i can just do on starting for that [16:09] riht [16:09] right [16:09] so i think on starting is sufficient for what i need right now. [16:11] keybuk: http://heh.fi/tmp/mountall/hot-host-cache.png mountall’s highest CPU usage seems to be at the end, with no apparent correlation with fscks. [16:11] keybuk: http://heh.fi/tmp/mountall/cold-host-cache.png as well [16:12] pitti: I'll need your help to trigger a server Cd respin, whenever amd64 gets built at https://launchpad.net/ubuntu/lucid/+source/eucalyptus/1.6.2~bzr1103-0ubuntu3 [16:13] I don't see that here atm [16:14] keybuk: Dunno whether running under VirtualBox screws with the graphs, though. [16:16] ttx: bumped build score for now [16:16] anyone know how to clean/delete previous conversation in empathy ? [16:16] ttx: please ping me when it's published, then I'll trigger a rebuild of the CD [16:16] pitti: will do , thanks [16:19] Keybuk, sorry to keep pestering you, but you keep answering :). one more question. If i want to run at "old school 'rc.local'" what would you recommend for implementing that [16:23] on stopped rc RUNLEVEL=[2345] [16:29] Keybuk: can you generate an upstart event with additional data? Ex: cloud-yaml-config CFGFILE=/etc/cloud/config.yaml ? [16:29] yes [16:30] Keybuk: so that upstart jobs that start on cloud-yaml-config would have access to CFGFILE? [16:30] yes [16:30] smoser: ^^ [16:30] Keybuk: awesome thanks [16:31] pitti: Would you also reduce the score on openjdk-7 from doko's toolchain PPA to ~2000 on IA64 only (for the same reason). [16:32] mathiaz, that is good, yeah. so i think that is important to pass that from the event. [16:32] Keybuk: do you get a ply_trace ("deactivating on vt change") if you enable tracing and reproduce the bug in plymouth? [16:33] ScottK: no need, will fail after unpack [16:33] doko: Thanks. pitti: Nevermind. [16:33] o [16:33] k [16:33] tseliot: haven't tried [16:34] Keybuk: that would be a way to see when it switches vt and maybe track down the issue [16:35] problem is that all the tracing output mucks up the output ;) [16:35] so you can't tell whether it's working or not [16:36] the tracing output go into a file [16:36] (in theory) [16:39] yeah, there's lots of "theory" here ;) [16:39] I figured out why all fscks get cancelled with plymouth running [16:39] plymouth sends garbage back repeatedly when you use watch keystroke [16:42] Keybuk, i think i read somewhere that at some point you expect 'script' section to allow for interpreters other than 'sh -e' is that correct? [16:42] if so, how reasonable is that that that would happen in lucid [16:43] wait, maybe its not that bad to live with out it. [16:43] no, it won't happen in lucid [16:43] I haven't decided it's definitely going to happen yet [16:44] Keybuk, so you take the 'script' section put it in a file, and then 'sh -e file' ? [16:44] is that right? [16:46] no, but close enough [16:47] Keybuk: garbage? Maybe vt related? [16:47] tseliot: I'm thinking that this whole plymouth goes on the wrong vt is our fundamental problem [16:47] it'd explain why fedora don't see it (they like it on vt 1 :p) [16:47] if VT7 is in KD_GRAPHICS but VT1 is in KD_TEXT [16:47] and plymouth is scanning out its fb to VT1 [16:47] Keybuk, i dont understand why you wouldn't implement it. it seems like a lot of bang for a very small amoutn of buck [16:48] it'd explain why fbcon scans over the top [16:48] it'd explain why input is fu'd [16:48] it'd explain why our X transition screws up (there's a VT switch in there ) [16:48] but i guess its fairliy easy to work around at the moment: [16:48] http://paste.ubuntu.com/344173/ [16:48] smoser: because, for example in that case, Upstart now needs to worry about whether /usr is mounted [16:49] upstart doesn't need to worry about that [16:49] both most commonly requested "other" interpreters are on /usr [16:49] upstart needs to care about them failing [16:49] any more than it needs to worry that the users shell script is not terribly bogus [16:49] not its job [16:49] also because I think writing jobs in anything other than shell is probably wrong [16:49] thinking of all the hassles of allowing maintainer scripts to be written in other languages [16:49] (it'd slow down boot for a start ) [16:50] Keybuk, it could also speed up boot [16:50] how does starting the entire python interpreter "speed up" boot? :p [16:50] python is enormous [16:51] because bin/sh scripts will typically fork loads of times to do something that could be done in perl., python, without forking [16:51] and insert-interpreter-here isn't necissairly slow [16:51] Keybuk, is there a particular reason not to switch to VT1 by default in Ubuntu though? [16:52] superm1: cjwatson and slangasek don't want to :) [16:52] heh === robbiew_ is now known as robbiew [16:52] * cjwatson doesn't want to be hunting and destroying old documentation for the rest of his life when there's no real need to [16:53] i personally dont think that that is the right place to enforce policy of "write maintainer scripts in /bin/sh" or "write startup scripts so they are fast" [16:54] smoser: noted [16:54] thanks [16:54] :) [16:55] pitti: I'm about to stop for dinner and the amd64 build is still going to start in "1 minute"... will you be around this evening, and if not, could you set up a magic trigger ? === robbiew is now known as robbiew_ [16:57] ttx: slangasek has a magic trigger for this; slangasek, here by chance? would you mind passing your script which triggers a CD build when a particular package is published? [16:59] pitti: steve should be around later, I'll check the build in a few hours and ask him to trigger if necessary [16:59] pitti: worse case scenario, we'll trigger it tomorrow morning before taking coffee :) [17:00] ttx: I'm off for dinner now, too, but I'll be around until 1930 CET [17:00] pitti: ok === dendro-afk is now known as dendrobates [17:22] * mpt wonders if we have a FTRFB (Fails to Run From Binary) to go with our FTBFS === deryck is now known as deryck[lunch] [17:40] pitti: better would be if I finally factor that trigger out into a script... [17:46] Keybuk: where's the evidence that bug #497299 is linked to bug #447654? The submitter of this bug had a broken interfaces file, that's hardly related. [17:46] Launchpad bug 497299 in upstart "upstart not starting init-scripts (event net-device-up IFACE=lo missing)" [Undecided,Confirmed] https://launchpad.net/bugs/497299 [17:46] Launchpad bug 447654 in nfs-utils "init: using 'and' and 'or' operators together causes hangs" [High,Fix released] https://launchpad.net/bugs/447654 [17:47] Keybuk: and there's no 'instance' here, so from your earlier description, this doesn't fit the and+or problem [17:49] slangasek: it's still the same problem [17:49] how? [17:49] because you block ifup from finishing until filesystems are mounted [17:49] which means if you have anything requiring a network interface to mount filesystems [17:49] like [17:49] say [17:49] NFS [17:49] you're going to fuck them [17:51] Keybuk: ah; I don't see why you would lump that in with bug #447654, but I think that problem can (and should) be addressed by making /etc/network/if-up.d/upstart use --no-wait ? [17:51] Launchpad bug 447654 in nfs-utils "init: using 'and' and 'or' operators together causes hangs" [High,Fix released] https://launchpad.net/bugs/447654 [17:51] slangasek: that would be a bug for different reasons [17:51] we have things (EC2 for example) *relying* on the fact that it's not --no-wait [17:51] howso? [17:52] how about you stop rushing to fix things in a blind panic ? [17:52] I was deliberately not fixing that bug for a reason [17:52] because all of the ways I could think of were worse [17:53] you mean the bug that was brought up as part of a session at UDS, and that you and I subsequently discussed on IRC? [17:53] that's "a blind panic"? [17:53] yes, and I kept saying that there were bad things that could happen with it [17:53] and then you uploaded a "fix" anyway [17:53] you must have figured that there was _some_ reason I was holding back? [17:54] 08-12-2009 12:10:24 < Keybuk!n=scott@quest.netsplit.com: why not add "and net-device-up IFACE=lo" to the rc-sysinit.conf file ? [17:54] that doesn't look like "holding back" to me [17:55] it was a suggestion for testing [17:55] not a "go ahead and upload as an SRU" [17:55] now I've had more than 6s to think about it, it's clearly wrong [17:56] how and why does EC2 rely on ifup being synchronous? [17:56] slangasek: because it does [17:56] and I want that net-device-up to be synchronous [17:56] great, thanks for the insight [17:57] oh, sorry [17:57] you're quite right [17:57] I should drop everything I'm doing right now and explain to you how everything works [17:57] jeez, guys, chill out [18:08] Keybuk: would a kernel patch to start on tty7 help (or hurt :-P )? [18:08] tseliot: it's not that [18:08] because the current vt looks a bit like 7 [18:08] it's a bit more strange [18:08] ? [18:08] I don't know how to describe the behaviour I'm seeing [18:09] because it doesn't make rational sense [18:10] because it keeps switching to vt1? [18:10] * tseliot scratches head [18:11] right [18:11] I can watch it switch to vt7 [18:11] and then, it's like it gets there [18:11] and all is fine [18:12] but it's on vt1 [18:12] it's like vt7 becomes a magic portal to vt1 [18:12] or something [18:12] very weird [18:13] can it be that it copies the content of vt7 to vt1 and then switches to vt1? === beuno is now known as beuno-lunch [18:15] in effect, I think that's what's happening [18:15] but I think it's more at the drm/fb layer [18:15] like it's on VT7, but scans out the framebuffer for vt1 [18:16] which the kernel lets happen [18:16] (but probably shouldn't have) [18:16] so the first framebuffer scan out partially switches vt === deryck[lunch] is now known as deryck [18:20] yes, of course I was referring to the drm stuff [18:20] and then you end up in an odd situation [18:20] where /dev/console is pointed at tty7 [18:20] but the framebuffer is being scanned out to vt1 [18:20] and that framebuffer is going onto the screen [18:21] which means you're in KD_TEXT on that vt, not KD_GRAPHICS [18:21] which is why fbcon can spam over the top [18:21] and in order to start X, you need a VT switch [18:21] which is why we don't get the smooth transition without scanning out to fbcon too [18:21] etc. [18:21] that's my best guess [18:25] Can I talk any ubuntu-sru types into looking at bug #497606? [18:25] Launchpad bug 497606 in cupsys "lpstat in CUPS 1.3 can't list jobs on CUPS 1.4 servers" [Undecided,New] https://launchpad.net/bugs/497606 [18:27] slangasek: right, so... [18:27] you know that events in upstart have both a start and a completion, right. [18:27] ? [18:28] Keybuk: yes, I think that's more or less what's happening. I'll have another look at the drm code [18:31] Keybuk: yes [18:31] slangasek: everything reacts to the start of the event, so if you have lots of jobs that say "start on foo" - then they all get that kick at the same time [18:31] the completion of the event doesn't happen until everything that was kicked is either started (services) or finished (tasks) [18:32] completion only matters to the process that emitted the event [18:32] Keybuk: did you read my comment on bug #493480 before assigning it back again, or are you just playing bug pong? [18:32] Launchpad bug 493480 in cryptsetup "[Karmic, security] Encrypted /tmp no longer mounting after upgrade to karmic" [Undecided,New] https://launchpad.net/bugs/493480 [18:33] slangasek: I put it on my procmail file that reassigns bugs back to where they came from [18:33] Keybuk: where do I file bug reports against your buggy procmail file? [18:33] pitti: do you think that bug 229370 could be related to bug 463347 or maybe bug 469837? I reckon it probably is somewhere in devicekit-disks, but I'm not sure if it is a duplicate of an already reported bug. [18:33] if it's an encrypted /tmp, it's a cryptsetup bug [18:33]