[01:16] doko,infiniti,jdstrand, curtin's MIR still requires a MIR team member review: 1220434 [01:21] Has anyone looked at bug 823254 recently? [01:21] bug 823254 in software-center (Ubuntu) "Port to python3" [Medium,Confirmed] https://launchpad.net/bugs/823254 [01:47] Laney: Yes. Please see my comment at https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1065979/comments/37. [01:47] Ubuntu bug 1065979 in gnome-settings-daemon (Ubuntu) "external/internal monitors mirrored on boot when laptop lid is closed" [Wishlist,Confirmed] === _salem is now known as salem_ === salem_ is now known as _salem === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [05:31] Good morning [06:32] o/ [07:12] good morning === doko_ is now known as doko [08:11] smoser: Can you get a team subscription to curtin set up? [08:40] infinity, did you see 1203496 in other packages too? [08:42] doko: I don't remember if I saw it elsewhere, sorry. [09:19] Hi! [09:19] I read about plans to include only Python 3 in Ubuntu 14.04 [09:20] I'd love to help, but don't know where to look === freeflying is now known as freeflying_away === MacSlow is now known as MacSlow|lunch [12:01] jamespage: could you add a server team (or whatever) bug subscription to curtin? [12:02] cjwatson, done [12:02] ta [12:20] infinity, done. === david is now known as Guest82446 [12:22] smoser: Danke. === _salem is now known as salem_ === freeflying_away is now known as freeflying === davidcal_ is now known as davidcalle [12:53] xnox: Hi Dmitrijs [12:54] Latest ubiquity build fails on amd64, see https://launchpad.net/ubuntu/+source/ubiquity/2.15.25 [12:56] It would be nice if you update ubiquity-debconf translations from Launchpad in next build - Lithuanian translation is missing in Ubuntu one step because of bug #1235192 [12:56] bug 1235192 in ubiquity (Ubuntu Saucy) "Strings in U1 window for 13.10 installer are not in pot file" [High,Fix released] https://launchpad.net/bugs/1235192 [12:57] I'm currently finishing translation of missing strings in Ubiquity-debconf template === MacSlow|lunch is now known as MacSlow [12:59] cjwatson: few years ago you helped us to update ubiquity-debconf translations from Launchpad, could you help again ? ;) [13:05] mantas-baltix: Too late [13:05] mantas-baltix: That's an arm64 build failure, not amd64. ubiquity/arm64 is not yet expected to work. [13:07] mantas-baltix: And I updated translations four days after the non-language-pack translation deadline, I don't think that's unreasonable ... [13:07] cjwatson: well the strings to be translated weren't there 4 days ago. [13:08] Although I know that those strings were only added four days after *that*, but I believe that was on the understanding that they weren't expected to be translated for release [13:08] ah, ok. [13:13] xnox: Did you figure out what the boost version for "T" is? [13:13] cjwatson: ok, sorry, our translation team isn't very fast... [13:13] mantas-baltix: I think this was just not expected to be translated; we accepted the bug-fix because having it untranslated and in the .pot is no worse than having it untranslated and not in the .pot, and gives translators more of a head-start for next release [13:14] mantas-baltix: If there's another build, I'll update, but I don't know of a cause for one at this point [13:14] ScottK: 1.54 with multiarch. [13:15] xnox: OK. That's probably worth a mail to u-devel or u-d-a. [13:15] ScottK: also thinking libav9, emacs24 as default. [13:15] ScottK: yeah I know, but I'm not yet preparing / evaluating for T opening yet. [13:15] perl 5.18 too [13:16] do we have a name yet btw ? [13:16] rickspencer3: ^- [13:16] no-name-yeT Tiger [13:16] :) [13:17] cjwatson, xnox: OK, thanks, Lithuanian users will be happy if you update ubiquity-debconf translations from Launchpad in next build - we will create localized Ubuntu 13.10 installation image next week using ubuntu-defaults-builder, it would be nice to see fully translated installation :) [13:17] tclk/tk 8.6 maybe. [13:17] mantas-baltix: I'll do it in bz rnow [13:17] *bzr now [13:17] *sigh* [13:17] every [13:17] single [13:17] time [13:17] :) [13:17] * mdeslaur votes for Tasty Turkey [13:17] sing it [13:17] lol [13:17] * xnox says Tasty TinTin [13:17] mdeslaur: don't still my adjective! [13:17] TinTin isnt an animal [13:18] if it helps to know, I made several suggestions last week, but they each got shot down [13:18] Terrific Tapir ! [13:18] Toxic Tuna [13:18] Quality LTS name :P [13:18] hehe [13:18] cjwatson: please wait 5 minutes, I'm finishing translation [13:19] mantas-baltix: *sigh* [13:19] don't ask before you're finished :) === barry` is now known as barry_ [13:28] barry`, lool I reported bug 1240516 [13:29] bug 1240516 in system-image (Ubuntu) "autopkgtest failure: test output goes to stderr" [Undecided,New] https://launchpad.net/bugs/1240516 === barry_ is now known as barry [13:30] jibel: will look [13:31] barry, I'm looking at the failure on amd64, it is a timeout in download.py but on different tests between my run and automated runs [13:32] jibel: thanks [13:32] jibel: sigh. i've been fighting this one for days. i think there's a weird problem with download manager [13:33] jibel: it's hard for me to tell from that jenkins page what exactly is going to stdout [13:34] *stderr [13:35] cjwatson: thanks for waiting, I've just finished :) [13:36] good luck with Ubuntu 13.10 :) [13:36] mantas-baltix: ok, re-requested a tarball [13:38] smoser: Is curtin itself (and python3-curtin) meant to be seeded to main, or are you happy with just the bits that maas depends on being in main? [13:39] i really dont care about 'curtin' and 'python3-curtin' themselves at the moment. [13:39] infinity, i have a related question though... [13:39] smoser: Alright, good. [13:40] smoser: What's the related question? [13:40] what is the reason why you'd have something split like that? [13:41] smoser: Because we only have binaries in main that are needed in main. [13:41] is there any real beneift? [13:41] since we have to support the source package anyway. [13:41] ok. thats fine. [13:41] smoser: The benefit is for times when a binary produced from a main package happens to be something we don't WANT to support, so we only have things in main explicitly. [13:41] smoser: nscd being the pathological case here. [13:42] infinity, ok. then one more related question. [13:42] give binary upackage 'foo', is there a way that i can easily [13:42] a.) know what the source package is (other htan 'apt-cache show') [13:42] b.) know if other binaries from that source are in main [13:42] infinity, i know you're busy [13:44] smoser: For (b), 'rmadison -S foo' works. [13:44] smoser: For (a), apt is the simplest method. [13:44] thanks infinity [13:47] xnox: While you're multi-arching boost, you might look at splitting the python binaries into python and python3 packages so they can have proper depends. [13:48] ScottK: maybe. but boost is already multi-arched. [13:48] ScottK: (1.53 in saucy) [13:48] Oh. [13:48] i just was going to multiarch 1.54 into debian and sync it. [13:48] In any case, it needs doing. [13:48] ScottK: true. but at the moment those boosts libs are still not abi-tagged and there is a request for dbg builds. [13:49] Yes, but they don't have correct python/python3 depends at all right now. [13:49] So even splitting py/py3 would be progress. [14:03] barry, ah, I pasted a link to the console, on https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-system-image/5/ARCH=i386,label=adt/ stderr is dsc0t-unittests-stderr [14:04] jibel: so *all* the test output is going to stderr? [14:04] barry, yes [14:04] jibel: okay [14:09] mvo_, hi, do you have five minutes to look at ? [14:14] mpt: hi, sure! done - sorry I saw your question yesterday but did not quite manage to get to it [14:14] thanks! [14:29] mvo_: Hi, I was wondering if you might have a look at bug 1024590. [14:29] bug 1024590 in update-manager (Ubuntu Saucy) "update-manager crashed with AttributeError in _on_download_changed(): 'NoneType' object has no attribute 'get_value'" [Medium,Confirmed] https://launchpad.net/bugs/1024590 [14:29] bdmurray: sure, I can do that later this evening, gtg now :) but thanks for the pointer to the report [15:06] jibel, didrocks, lool i'm uploading this change now: http://paste.ubuntu.com/6246069/ [15:07] barry: keep it for next release [15:07] lool: ? [15:07] barry: I mean it doesn't need to be uploaded [15:07] barry: we've forced system-image in [15:07] barry: unless you want to use uploads to debug autopkgtests issues [15:07] lool: ah, okay. no, i don't ;) [15:09] barry: there was another issue on the other arch too [15:10] lool: i haven't seen that. i'll bet it was a timeout error in the autopkgtest [15:10] barry: one has FAILED (SKIP=3, errors=1) [15:10] barry: the other one FAILED (SKIP=3, errors=4, failures=2) [15:10] lool: were those all timeouts? [15:10] barry: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-system-image/ [15:10] barry: jibel looked into reproducing these, you might want to sync with him to debug === gusch is now known as gusch|brb [15:11] lool: those are going to be extremely difficult to debug. we may need to enlist mandel to get more debugging out of u-d-m [15:15] barry: sounds good [15:15] lool: it'll be a fun project for tremendous tadpole [15:15] barry: cant wait for the fun [16:06] tedg, hey, do you know if anyone is looking at https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1230222 ? [16:06] Ubuntu bug 1230222 in unity (Ubuntu) "unity-panel-service assert failure: dbus_error.c:69: Unhandled error from nih_dbus_error_raise: Connection was disconnected before a reply was received" [Undecided,Confirmed] [16:06] not sure if that's a libnih or unity issue [16:06] that's the most reported unity bug in saucy [16:07] Hmm, no I don't know if anyone has. [16:07] im willing to upgrade its just that, im having trouble with my wificard not being supported properly [16:07] But it'd be a no-op. [16:07] tedg, wdym "no-op"? if the error is harmless we shouldn't bother users with apport prompt for it... [16:08] would the bcm4312 work fine in the beta? [16:08] seb128, yeah, I think that's the solution. [16:08] tedg, who would be the right person to own it? you? bregma? ;-) [16:08] seb128, Though, has it been in recent versions? I think slangasek was changing that code to fire-and-forget. [16:09] who am I firing and forgetting? [16:09] slangasek, The nih signals in unity [16:09] tedg, https://errors.ubuntu.com/problem/bdbd27d4a927ab7cb0fa8edbd1787564e7be8852 [16:09] tedg, yes, still happening [16:09] slangasek, ^ [16:09] "still happening" - seems unrelated to the changes we were making [16:09] I think that bug started happening when u-p-s was moved to an upstart job [16:10] dbus stops first, u-p-s barfs and dies [16:10] I think it's related to the indicator signals [16:10] Those are the only ones using libnih [16:11] slangasek, Oh, were you only changing the Unity8 ones? [16:12] tedg: that's the only code we touched [16:12] K [16:13] that's a strange backtrace - is it really throwing an error in an exit handler? [16:13] \o/ NIH! [16:15] Hmm, interesting, we're emiting the events sync... [16:18] slangasek: nih registers an atexit handled to make sure the app dealt with all errors. [16:19] ok [16:19] tedg: so basically, this backtrace can only occur when u-p-s is exiting, so why is u-p-s exiting? [16:20] slangasek, user logged out? [16:20] tedg, slangasek: all the calls need their return checking to ensure no NihErrors are lurking. [16:20] jodh, But they're all _sync calls. [16:20] jodh, Wouldn't that do that already? [16:20] tedg: the bug report says "Unity doesn't load, no Launcher, no Dash appears" - are we looking at a user-affecting bug here, or not? [16:21] tedg: a sync call just means you know immediately whether an error occurred; you still have to check the retval to handle the error itself, AIUI [16:22] slangasek, So we're checking to see if it's non-zero, but we need to remove it from the nih stack? [16:22] tedg: if we're talking about indicatorsmanager.cpp, nih_dbus_proxy_new() isn't checked and it can return an error and create an NihError in the process. That code doesn't handle the failure scenario by consuming the NihError if there is one. [16:22] jodh, We're talking about panel-service.c [16:22] right [16:23] tedg: package? [16:23] jodh, unity [16:24] the bug is confusing, because the stack dump is from unity-panel-service but he's complaining about Unity proper not working (which is unrelated)... then apport marked a bunch of other u-p-s crashes as dups [16:24] tedg: right - my comments still apply. [16:25] tedg: if priv->upstart = nih_dbus_proxy_new () fails, you need to call "NihError *err = nih_error_get(); nih_free (err);" [16:26] jodh, Okay, and the same for the emit events? [16:26] tedg: you may want to print err->message somewhere before freeing the object to get a human-readable message. [16:27] tedg: this is the only nih_dbus_* call in the code, FWICS, so the only place it needs to be handled. However, fixing that nih api issue will prevent apport crashes from being generated, but not actually get to the heart of why this error is happening [16:29] tedg: oh, but of course the upstart_* calls could also raise nih errors, yes [16:29] tedg: Looking at the auto-generated code, yes, it does seem to raise NihErrors on failure. [16:29] slangasek, Sure, this is probably masking another error, but we have to get this cleaned up before the other becomes visible. [16:29] tedg: well, no, because handling the error is going to give you the exact same message: "Connection was disconnected before a reply was received" [16:31] slangasek, Sure, but I'm fairly certain that's unrelated to the comment on the bug. Which is probably a different error. [16:31] right, that seems likely, since if upstart crashed I would expect the session to end [16:32] (crashed, was killed, whatever) [16:32] So does this look correct? https://code.launchpad.net/~ted/unity/nih-signals-complete/+merge/191457 [16:32] (for the proxy) [16:33] Do I need to check if nih_error_get() returns NULL? [16:33] I'm actually using https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1236720 to track that particular bug to avoid confusion [16:33] Ubuntu bug 1236720 in Unity 7.1 "unity-panel-service crashed with SIGABRT" [High,Triaged] [16:34] tedg: that code looks correct to me; none of the upstart code checks for a NULL return in that scenario, it's pretty safe to assume it won't be [16:38] Okay, now building Unity... we should have a fix by tomorrow. [16:38] :-) [16:41] tedg, thanks for working on that one ;-) [16:47] bdmurray, or any other coredev can one of you guys revert the fix that went in for 1150413... It seems to have cause a regression bug 1157643.. [16:47] bug 1157643 in procps (Ubuntu) "procps fail to start" [Undecided,Confirmed] https://launchpad.net/bugs/1157643 [16:55] chiluk: bug 1157643 seems to deal with a couple of different issues, can you explain what happened with your SRU to me? [16:55] bug 1157643 in procps (Ubuntu) "procps fail to start" [Undecided,Confirmed] https://launchpad.net/bugs/1157643 [16:55] bdmurray... I'm still trying to figure it out myself. [16:56] I just found out 5 minutes ago that a number of users are complaining about procps in bug 1157643 since yesterday when the update was released [16:56] bug 1157643 in procps (Ubuntu) "procps fail to start" [Undecided,Confirmed] https://launchpad.net/bugs/1157643 [16:56] I can run service start procps just fine.. [17:14] chiluk, bdmurray: I don't think it's a regression; I think 'service procps start' fails for these users every time they boot, but it doesn't block anything when it happens at boot [17:14] so the issue is that this is the first time they've upgraded procps since making whatever customizations they have made to /etc/sysctl* [17:16] slangasek: I agree I was just testing with an lxc container and the old version of the package had the same issue [17:16] phew... [17:17] chiluk: I'm here :) [17:17] hey [17:18] so my laptop is not booting anymore since today's update [17:18] is there a known issue in saucy? [17:18] verterok, slangasek and bdmurray think this is not a regression, but instead simply the first time procps has been upgraded [17:18] the boot stops on plymouth and displays "waiting for network" after a bit [17:19] bdmurray: it still seems an SRUable issue in its own right, but it's not a regression and trying to revert the change won't help ;) [17:19] chiluk: ah, that's likely yes. i mean, i do remember now trying to restart procps for some other reason and the start always failed [17:20] hum [17:20] seb128: "waiting for network" should only wait for 120 seconds max [17:20] intel driver fails to load as well... kernel issue? [17:20] shouldn't be any kernel changes in today's update [17:20] slangasek, I got bored enough 120s, went to a vt and did startx from there [17:21] looking to see what came in with the latest updates [17:21] new X packages yesterday [17:21] slangasek, well, I didn't update yesterday either [17:22] dmesg has [17:22] [ 16.371270] wlan0: Limiting TX power to 27 (30 - 3) dBm as advertised by 18:3 [17:22] 3:9d:16:e7:e0 [17:22] [ 17.492514] init: Failed to spawn nmbd main process: unable to execute: No su [17:22] ch file or directory [17:22] [ 128.597580] audit_printk_skb: 180 callbacks suppressed [17:22] sidnei, chiluk: so, what are our options here? fix lxc config to allow access to those sysctl keys? [17:22] "no such file or directory"? is your fs corrupted? :/ [17:23] or is the samba package in state 'rc'? [17:23] verterok: i think procps needs an update to fix the start/restart initscript target [17:23] verterok: or something along these lines [17:23] rc samba 2:3.6.9-1ubuntu1 i386 SMB/CIFS file, print, and login server for Unix [17:23] slangasek, yeah, I uninstalled it some days ago to test something [17:23] ok, so ignorable [17:24] hum, I wonder if uninstalling samba is what created the issue [17:24] verterok: although, yeah, the failure is because of perms [17:24] seb128: not sure how it would [17:24] slangasek, yeah, me neither... [17:25] ok, let me fsck and try old kernel (and need to get lunch) [17:25] bbiab [17:25] seb128: oh; except you're waiting for network, and the nmbd job starts on network, so if the job managed to get itself into a bad state... [17:25] well, timing [17:26] tedg: so I have a question about dbus best practices, maybe this is something you can help me with [17:27] sidnei: looks like the apparmor profile is the culprit [17:27] sidnei: /etc/apparmor.d/abstractions/lxc/container-base [17:27] tedg: we've been working on the memory leak in upstart, and jodh has succeeded in pinpointing the source of the leaking memory, and thinks he has a way around it - when we go to send messages, if the client still has one queued we drop instead of appending to the queue. [17:27] verterok: that's in the host? [17:28] sidnei: yes [17:28] tedg: but my question is... why are we sending these messages to all clients anyway. Apparently any time we see an upstart event we broadcast the message to all clients, and rely on the clients to filter out which events they care about... is that really the dbus way? Because this seems to me to be an awful lot of cycles wasted sending messages that the clients know they don't care about [17:29] verterok: uhm, that's not even installed on my machine, im using a precise host [17:30] sidnei: this is a saucy host [17:31] sidnei: probably in another file? [17:31] verterok: which line you think it's the culprit on that apparmor profile for saucy host? [17:31] deny @{PROC}/sys/kernel/*/** wklx ? [17:32] sidnei: yes: https://pastebin.canonical.com/99156/ [17:33] verterok: right, so /etc/apparmor.d/lxc/lxc-default in precise [17:33] sidnei: see the part: # deny writes in /sys except for /sys/fs/cgroup [17:34] verterok: so yes, while it's the apparmor profile that's blocking it, i don't think that needs to be changed. perhaps the fix is to not try to set those keys when running within lxc, or to fail gracefully instead. [17:35] sidnei: you'r probably right :) [17:36] and the files that try to set those keys are part of the procps package [17:37] smoser: did you see my comments in bug 1239893? [17:37] bug 1239893 in software-properties (Ubuntu) "PPAs added using GUI Software and Updates have an extra space added to repository line" [High,Triaged] https://launchpad.net/bugs/1239893 [17:38] verterok: so if i understand the whole context, procps start has always been broken in lxc, but when called from upstart the failure to start is ignored. dpkg is not as forgiving, so trying to upgrade the package blows up because the service start step blows up. [17:38] verterok: and we only hit this on lxc because of the apparmor profile [17:38] sidnei: I think that's the whole thing [17:38] chiluk: ^ dropping that into a bug, against procps i suppose? [17:41] bdmurray, it doesn't seem to make sense to me to ad dthe newline there. [17:41] (in your ocmment 8) [17:42] fwiw, i'm not terribly personally interested in this. i think its not good that there is apparently a regression (but i've never tested ppa: in the gtk box on raring). [17:42] i was primiarily concerned that i'd cauased a regression so thats why i initially jumped in. [17:44] thanks sidnei...I'm really not the one to decide where the fix needs to be .. [17:46] chiluk: i'll append that as a comment to the existing bug then, let someone else sort it out. [17:46] so sidnei if I understand this correctly this only happens in an lxc guest [17:47] chiluk: yes, best i can tell. [17:47] or some other virtualization guest... [17:47] that has sys mounted from the host? [17:47] chiluk: possibly, or anything that has an apparmor profile restricting /sys? [17:47] sorry, I haven't had much of a chance to play with lxc.. [17:48] alright.. I need to step away for a bit, but I'll take a look later today with this... at least document in the public bug what the understanding of the problem is. [17:51] slangasek: do you have any opinion on this? since the sysctl setup that's breaking under this environment is added by procps itself, but the failure only manifests under lxc (and apparently openvz too?) im unsure if the bug should be filed on procps or lxc. [17:55] sidnei: which option is breaking under lxc/openvz? [17:55] or are they all breaking? [17:55] In my case it was the kernel ones [17:56] what kernel ones are those? [17:56] slangasek: there's 3 of them, let me get you a list [17:56] kernel.printk [17:56] kernel.kptr_restrict [17:56] kernel.yama.ptrace_scope [17:56] ok [17:56] thanks bdmurray [17:57] np [17:57] stgraber, hallyn: ^^ so /etc/init/procps.conf does not work reliably in containers because lxc doesn't want us writing to /proc/sys/kernel (apparently). What should we do here? [18:00] slangasek: what's the problem caused due to LXC preventing writes in there? [18:00] slangasek: most of the files under /proc/sys/kernel aren't namespace aware so we certainly don't want to allow writing to them [18:00] (kernel.yama.ptrace_scope is one of those at least, I suspect the two others might be too) [18:00] accept that it might fail? not run in containers? what exactly is it failing on? [18:01] upgrading the procps package [18:01] which variables i mean [18:01] hallyn: see a couple lines above [18:01] i thought procps used to proceed if it couldn't st seomthing [18:01] stgraber: the problem is that we expect the sysctl command to be reliable, and the procps maintainer script expects the upstart job to be reliable, and so these writes, which are allowed in a normal system, will fail [18:02] there are cases where the sysctl ceases to exist too right? how are those handled? [18:03] hallyn: '-e': 'Use this option to ignore errors about unknown keys' [18:03] but that's specifically unknown keys, not "ignore errors when the kernel hates us" ;) [18:04] so if we want the upstart job to succeed we'll have to teach sysctl to ignore EACCESS [18:04] interesting, sysctl now has a --system option that makes the cat in /etc/init/procps.conf gratuitous [18:04] as there's no way we'll allow it writing to those files in a container [18:04] stgraber: and they can't be hidden in the container? [18:04] I guess you still want to be able to read them [18:04] unfortunately not, short of doing some very bad magic like using a fuse overlay on /proc [18:04] and indeed you still want read access [18:05] and some of those should actually be writable (and probably are, we unblock any entry that we know is namespace aware) [18:15] smoser: fwiw I tested software-properties in raring and it doesn't have the bug [18:16] so it is regression, probably shoudl tag that on the bug. [18:16] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/software-properties/saucy-proposed/revision/126 [18:16] in line 707 you can see a strip() [18:18] bdmurray, yeah, that would make sense. but i tested. [18:19] i tried with version before my changes. and it was present. [18:19] unless i just completely screwed that up [18:20] slangasek, So the clients set up filters in the dbus daemon, so it doesn't really send them to all clients. [18:21] slangasek, So from the perspective of the sender, they're going everywhere, but we're not waking everyone up. [18:21] in the case of a dbus daemon, right [18:21] but these are direct connections to the upstart server [18:21] tedg: what's the api for the client to set up the filter? [18:22] * tedg looks for a link [18:23] slangasek, http://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-add-match [18:24] slangasek, And then click on the match rules link to see the format of the string. [18:24] slangasek, Generally, point to point DBus interfaces don't install match rules. [18:24] tedg: got it, thanks. [18:24] slangasek, Is there a reason we're not putting the session Upstart on the session bus? [18:25] smoser: anyway, will you fix it or should I? [18:26] tedg: I don't know. Up to now, the clients of upstart's dbus service have been either upstart bridges or short-lived clients [18:26] so there probably was no perceived need [18:26] tedg: the session bus doesn't exist when upstart starts, though that's fixable with something like is done for the system bus. I think we just assumed it wouldn't gain us much since the socket address is exported to all sub-processes anyway [18:26] tedg: but even if we put it on the session bus, we would still have point-to-point clients (the bridges), for whom these emitted events are *also* a waste [18:26] Yeah, I was just noticing how the system bus worked there. Was thinking that might be a nicer solution. [18:26] bdmurray, you're welcome to. [18:27] slangasek, The bridges could send directed signals. [18:27] tedg: meaning the bridges become dependent on the dbus session bus [18:28] I'm probably more okay with everything being dependent on dbus than you are :-) [18:28] yep [18:28] stgraber: curiously, I see that all the bridges in the user session already 'start on started dbus' [18:28] stgraber: do you happen to know why that is? [18:29] stgraber, hallyn: as a result of this sysctl issue, anyone using (precise, at least) lxc containers has a broken system since procps landed on precise-updates yesterday. the maintainer script fails, and further apt invocations fail until that's resolved. [18:30] slangasek: no idea. I know that the first version of my event bridge was using upstart on session bus, but I changed that a bit later on. Maybe I forgot to change the start condition and everyone else copied it without thinking much about it? :) [18:31] sidnei: workarounds are possible (e.g., editing /usr/sbin/policy-rc.d to ignore requests for procps; or editing the config file in the container to comment out the problematic bits). A proper fix is going to take a bit. [18:31] and it's going to have to be fixed in procps, not in lxc. [18:31] stgraber: heh, could be [18:33] sidnei: is there an open bug to track that? [18:33] tedg: so you would argue for having upstart register on the session bus and moving its clients over there, where we get filtering for free and only have to send our signals to one "client" (dbus); and not for adding support to upstart for supporting matches, which in the common case would avoid us having to send any signals about upstart events? [18:33] hallyn: bug #1157643 seems like it could be it [18:33] bug 1157643 in procps (Ubuntu) "procps fail to start" [Undecided,Confirmed] https://launchpad.net/bugs/1157643 [18:34] slangasek, Yes, that would be my suggestion. [18:34] slangasek, I think it also masks sense for the "DBus in the kernel" possible future, where we wouldn't want that support in Upstart as well. [18:34] sidnei: th [18:34] x [18:34] bdmurray, please go ahead and apply your fix. [18:34] tedg: wouldn't want what support in Upstart? [18:35] i verify that it *was* broken by me. :-( [18:35] slangasek, The matches. It would be dead code as we'd use the kernel support. [18:35] tedg: I don't follow you at all [18:35] is moving to the kernel intended to change the API for matches? [18:36] slangasek, I'm just saying that adding support to Upstart to allow for matches on point to point connections wouldn't be used in the future. [18:36] still not following [18:36] having dbus in the kernel changes nothing about what interfaces upstart exposes [18:36] upstart is still a server that speaks dbus [18:37] slangasek: stgraber: so would teaching sysctl to check whether it is in a container, and, if so, check access(2) to the file, and not try writing if it gets EACCESS; seem reasonable? [18:37] Sure, the question would be whether it's a service that talks to a DBus server or supports more DBus server functionality on its own connection. [18:37] hallyn: the "check whether it's in a container" worries me a little [18:38] tedg: upstart will *always* support more on its own connection, there are privileged operations that upstart (as pid 1) only allows on its private socket, not from the system bus [18:38] slangasek: well we *could* just not do that. but /bin/running_in_container is supposed to be trustworthy... [18:38] i can see why that would be unsettling though [18:38] hallyn: I don't think sysctl should be shelling out to /bin/running_in_container [18:39] slangasek, Why is that? [18:39] hallyn: and I don't like having to invoke running_in_container, because I don't like it when things are different inside containers than out :) [18:39] tedg: because upstart doesn't trust the system bus ;) [18:39] slangasek, Does Upstart trust the kernel? :-) [18:39] tedg: not as far as it can throw it [18:39] * tedg may know the answer [18:40] slangasek: EACCESS is probably a good enough check. [18:40] the question is only, if you're on the *host*,. then you may want startup to actually break if you weren't able to set /proc/sys/FOO_i_rm-rf-/-if-unset [18:40] hallyn: just ignoring EACCESS seems reasonable, there's nothing sysctl can do about it, so just plain failing on it seems suboptimal. We can have it whine about it though. [18:41] stgraber: nothing it can do about it, but it *could* be a case where you're better off breaking boot (or upgrade) if it failed. [18:41] well, it wouldn't actually block startup though [18:41] then i guess it's worthless :) [18:41] ok lemme whip up a patch [18:41] (i assume noone else is yet?) [18:41] nothing appears to block on procps, so having it fail wouldn't really do anything [18:51] back from lunch [18:51] still no booting laptop though :/ [18:52] seb128: so I think you're right about nmbd being involved [18:53] slangasek, oh? [18:53] seb128: you're waiting for network, and the nmbd job starts on network, so if the job managed to get itself into a bad state, maybe it's blocked the static-network event [18:54] slangasek, how do I see what is blocked? [18:54] seb128: do you have interfaces configured through ifupdown besides lo? [18:54]