| mterry | robert_ancell, http://paste.ubuntu.com/8254607/ | 00:02 |
|---|---|---|
| mterry | worth the wait! | 00:02 |
| robert_ancell | mterry, hmm, so that log looks good. There's definitely a logind session open and we activated it | 00:03 |
| robert_ancell | mterry, have you tried running loginctl and checking everything looks happy there? | 00:04 |
| mterry | robert_ancell, it does yes | 00:04 |
| mterry | robert_ancell, it's a cgroup thing as far as I can tell | 00:04 |
| mterry | root@ubuntu-phablet:/# cat /proc/`pidof unity8`/cgroup | 00:04 |
| mterry | 4:name=systemd:/ | 00:04 |
| mterry | 3:freezer:/user.slice/user-32011.slice/session-c1.scope | 00:04 |
| mterry | 2:cpuacct:/user.slice/user-32011.slice/session-c1.scope | 00:04 |
| mterry | 1:cpu:/user.slice/user-32011.slice/session-c1.scope | 00:04 |
| robert_ancell | mterry, right, but the cgroups are all set by pam_systemd aren't they? | 00:05 |
| robert_ancell | mterry, have you confirmed 1.11.7 works fine? | 00:05 |
| mterry | robert_ancell, it does for me yes | 00:05 |
| mterry | let me try downgrading on this same image to double confirm | 00:06 |
| cjwatson | siretart: right, cool, I'll just keep ploughing through the equivalent rebuilds then ... | 00:08 |
| * cjwatson wants binNMUs | 00:08 | |
| ScottK | +1 | 00:09 |
| robert_ancell | mterry, can you get a lightdm.log from 1.11.7 so we can diff | 00:09 |
| mterry | robert_ancell, yup, downgrading works fine | 00:09 |
| robert_ancell | there's just nothing significant in the diff in how we interact with PAM... very odd... | 00:10 |
| mterry | robert_ancell, http://paste.ubuntu.com/8254652/ | 00:10 |
| mterry | and more relevantly: | 00:10 |
| mterry | root@ubuntu-phablet:/# cat /proc/`pidof unity8`/cgroup | 00:10 |
| mterry | 4:name=systemd:/user.slice/user-32011.slice/session-c1.scope | 00:10 |
| mterry | 3:freezer:/user.slice/user-32011.slice/session-c1.scope | 00:10 |
| mterry | 2:cpuacct:/user.slice/user-32011.slice/session-c1.scope | 00:10 |
| mterry | 1:cpu:/user.slice/user-32011.slice/session-c1.scope | 00:10 |
| robert_ancell | mterry, that's on a good run? | 00:11 |
| robert_ancell | What does "loginctl session-status $XDG_SESSION_ID" say on a good and bad run | 00:11 |
| mterry | robert_ancell, right | 00:11 |
| mterry | root@ubuntu-phablet:/# loginctl session-status c1 | 00:12 |
| mterry | Failed to query ControlGroup: No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/systemd1/unit/session_2dc1_2escope | 00:12 |
| mterry | c1 - phablet (32011) | 00:12 |
| mterry | Since: Fri 2014-09-05 00:07:59 UTC; 4min 11s ago | 00:12 |
| mterry | Leader: 1439 (lightdm) | 00:12 |
| mterry | Seat: seat0; vc1 | 00:12 |
| mterry | Service: lightdm-autologin; type unspecified; class background | 00:12 |
| mterry | State: active | 00:12 |
| mterry | Unit: session-c1.scope | 00:12 |
| mterry | that's a bad run | 00:12 |
| mterry | Would need to reflash to get good run | 00:12 |
| mterry | robert_ancell, like I said, logind thinks everything is fine | 00:12 |
| mterry | robert_ancell, the problem is that apps don't think they are part of the active session | 00:13 |
| robert_ancell | not sure about "class background" | 00:13 |
| mterry | robert_ancell, I don't know what that means either | 00:13 |
| robert_ancell | mterry, you can't just update lightdm back to 1.11.8? | 00:13 |
| mterry | robert_ancell, oh right! ahem | 00:14 |
| mterry | robert_ancell, I forgot I had downgraded in fact | 00:14 |
| mterry | robert_ancell, so this is from a good run | 00:14 |
| mterry | let me upgrade again | 00:14 |
| robert_ancell | rsalveti, did we confirm if your krillin does the PK stuff right with lightdm 1.11.8? | 00:14 |
| mterry | robert_ancell, I'm a little loopy right now | 00:14 |
| robert_ancell | no worries | 00:14 |
| mterry | root@ubuntu-phablet:/# loginctl session-status c1 | 00:16 |
| mterry | Failed to query ControlGroup: No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/systemd1/unit/session_2dc1_2escope | 00:16 |
| mterry | c1 - phablet (32011) | 00:16 |
| mterry | Since: Fri 2014-09-05 00:15:09 UTC; 44s ago | 00:16 |
| mterry | Leader: 1359 (lightdm) | 00:16 |
| mterry | Seat: seat0; vc1 | 00:16 |
| mterry | Service: lightdm-autologin; type unspecified; class background | 00:16 |
| mterry | State: active | 00:16 |
| mterry | Unit: session-c1.scope | 00:16 |
| mterry | robert_ancell, that's the bad | 00:16 |
| mterry | seems identical | 00:16 |
| robert_ancell | yeah | 00:16 |
| hallyn | will be really curious to see how lightdm could cause it | 00:16 |
| robert_ancell | hallyn, if we were setting up PAM incorrectly that would do it, but I can't see any significant change there | 00:17 |
| robert_ancell | mterry, could you do a bisect? | 00:17 |
| robert_ancell | mterry, also, is it just you or is this widespread? | 00:17 |
| mterry | robert_ancell, widespread | 00:17 |
| mterry | on krillin | 00:17 |
| mterry | robert_ancell, sure, I can bisect... let me get a build env set up for krillin | 00:18 |
| robert_ancell | It's got to be either r2037+r2038 or r2041 | 00:19 |
| mterry | ok, will check those explictly | 00:21 |
| mterry | robert_ancell, looks like it wasn't 2041 | 00:45 |
| robert_ancell | mterry, how's it going with the bisecting? | 01:22 |
| mterry | robert_ancell, good but ran into a problem with re-running a debuild without cleaning (didn't seem to like that) | 01:22 |
| mterry | robert_ancell, I'm now testing the 2037/2038 commits | 01:22 |
| robert_ancell | so to confirm - it works with 2036 (1.11.7) and not 2043 (1.11.8) | 01:23 |
| robert_ancell | what other revs? | 01:23 |
| siretart | cjwatson: thanks. let me know if you encounter problems! | 01:23 |
| cjwatson | siretart: jitsi and lightspark are my undiagnosed failures so far | 01:24 |
| mterry | robert_ancell, it does not work with 2040 | 01:25 |
| mterry | robert_ancell, and I'm testing 2038 now | 01:26 |
| siretart | cjwatson: jisti is debian bug #759835 | 01:27 |
| ubottu | Debian bug 759835 in src:jitsi "jitsi: FTBFS: [javadoc] /«PKGBUILDDIR»/lib/src/jsip/src/gov/nist/javax/sip/header/AuthenticationHeader.java:443: error: unmappable character for encoding ASCII" [Serious,Open] http://bugs.debian.org/759835 | 01:27 |
| mterry | robert_ancell, as expected, 2038 doesn't work either | 01:28 |
| cjwatson | siretart: is it? seems to be a warning in our build ... | 01:28 |
| mterry | robert_ancell, is it worth trying 2037 specifically? | 01:28 |
| cjwatson | siretart: oh, sorry, apparently I can't read | 01:28 |
| robert_ancell | mterry, have you tried a locally built 2036? | 01:28 |
| mterry | robert_ancell, yes, it worked | 01:28 |
| robert_ancell | you should probably try for completeness, but 2038 is probably the candidate | 01:29 |
| siretart | lightspark looks kindof unrelated to libav: /build/buildd/lightspark-0.7.2/src/scripting/abc.cpp:38:36: fatal error: llvm/Analysis/Verifier.h: No such file or directory | 01:30 |
| cjwatson | sure, unrelated but nevertheless a blocker | 01:31 |
| cjwatson | relatedness is irrelevant if it's in the list :) | 01:32 |
| cjwatson | there was a recent llvm change I think ... | 01:32 |
| cjwatson | (no details, I just saw it go by in my mirror update) | 01:32 |
| robert_ancell | mterry, what method are you using to build on your device? Remount rw then bzr-buildpackage? | 01:32 |
| mterry | robert_ancell, uh, I put the device in rw mode sure. Not remounting each time though | 01:33 |
| mterry | robert_ancell, and then debuild sure | 01:33 |
| robert_ancell | mterry, you just do a "# mount / -o,remount,rw" to go from a stock image? No other special tricks? | 01:34 |
| === Ursinha is now known as Ursinha-afk | ||
| mterry | robert_ancell, there's a file you can put in /userdata that makes the image rw on boot | 01:34 |
| robert_ancell | ah, what is that? | 01:35 |
| mterry | robert_ancell, than I can do normal stuff like apt-get build-dep lightdm etc | 01:35 |
| mterry | robert_ancell, uh I think the file is .writable_image, but I usually just run "phablet-config writable-image" from my host device | 01:35 |
| robert_ancell | awesome, thanks | 01:35 |
| mterry | robert_ancell, do you have a krillin? | 01:36 |
| siretart | cjwatson: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-March/071087.html indicates that Verfier.h moved post 3.4 to llvm/IR/Verifier.h | 01:36 |
| robert_ancell | mterry, no, I was hoping I might be able to reproduce on mako | 01:36 |
| mterry | robert_ancell, I have not been able to myself | 01:36 |
| robert_ancell | :( | 01:36 |
| cjwatson | siretart: ah, plausible | 01:37 |
| robert_ancell | mterry, The only thing I can think of now is to manually start removing parts of r2038 to find out what's actually triggering it. | 01:38 |
| mterry | robert_ancell, nothing seems especially suspicious to you? | 01:39 |
| siretart | cjwatson: https://github.com/lightspark/lightspark/commits/master/src/scripting/abc.cpp indicates that upstream didn't port it to llvm 3.5 yet | 01:39 |
| robert_ancell | mterry, I've been reading through the code here and there's nothing that stands out. We listen to move D-Bus events from logind, we activate sessions slightly differently (but from reading the systemd source both methods should have the same outcome) and we check CanGraphical on the seat. But the logs indicate that's always TRUE in your case so it should be the same behaviour as previously | 01:40 |
| robert_ancell | mterry, dmesg doesn't show logind complaining about anything does it? | 01:42 |
| mterry | [ 9.925763] (1)[1099:systemd-logind]systemd-logind[1099]: New seat seat0. | 01:43 |
| mterry | [ 11.310221] (0)[1099:systemd-logind]systemd-logind[1099]: Failed to start unit user@32011.service: Unknown unit: user@32011.service | 01:43 |
| mterry | [ 11.311741] (0)[1099:systemd-logind]systemd-logind[1099]: Failed to start user service: Unknown unit: user@32011.service | 01:43 |
| mterry | robert_ancell, but those are normal errors I think | 01:43 |
| robert_ancell | yeah, I get them here | 01:43 |
| robert_ancell | mterry, I have a "New session c1 of user lightdm." on my desktop, do you get those on a good run? | 01:44 |
| siretart | what's going on with llvm in ubuntu? it seems to me that debian testing has both llvm 3.4 and 3.5, whereas ubuntu dropped 3.4 already. why is that? | 01:44 |
| mterry | robert_ancell, hold on, testing 2037 | 01:44 |
| robert_ancell | k | 01:44 |
| mterry | robert_ancell, 2037 is good | 01:45 |
| robert_ancell | well, that confirms it, 2038 it is | 01:45 |
| mterry | robert_ancell, you have that message in your dmesg? | 01:45 |
| robert_ancell | mterry, on my desktop | 01:45 |
| mterry | robert_ancell, I don't here, even on a good run | 01:46 |
| mterry | robert_ancell, ok... shall I start disassembling 2037? | 01:46 |
| mterry | *2038 | 01:46 |
| robert_ancell | yes please | 01:47 |
| === Ursinha-afk is now known as Ursinha | ||
| cjwatson | siretart: I'll finish uploading the remaining rebuilds tomorrow. sleep now, night | 01:49 |
| cjwatson | I've probably loaded up the buildds enough for a while anyway :) | 01:53 |
| siretart | cjwatson: sure, thanks for your help, and have a good night! | 01:53 |
| RAOF | robert_ancell: Are you trying to work out why sound doesn't work now? :) | 01:56 |
| robert_ancell | mterry, ^? | 01:56 |
| robert_ancell | is the symptom no sound? | 01:57 |
| RAOF | On the desktop. | 01:57 |
| robert_ancell | RAOF, sound works for me.. | 01:57 |
| RAOF | Maybe you don't VT switch enough :) | 01:58 |
| mterry | no that's a separate issue I think :) | 01:58 |
| mterry | from this krillin thing | 01:58 |
| robert_ancell | RAOF, still works after VT switch | 01:58 |
| RAOF | Hm. *Something* was messing with my logind sessions, because I didn't have an X11 session and none of my sessions were marked as active. | 02:02 |
| robert_ancell | RAOF, what version of lightdm? | 02:05 |
| RAOF | 1.11.8 | 02:05 |
| RAOF | robert_ancell: ck-list-sessions output: http://paste.ubuntu.com/8255328/ | 02:06 |
| robert_ancell | RAOF, don't you mean loginctl? | 02:07 |
| RAOF | Apparently not :) | 02:08 |
| robert_ancell | loginctl show-session to show the current session properties | 02:08 |
| RAOF | http://paste.ubuntu.com/8255346/ | 02:09 |
| RAOF | Well, that's all of them. | 02:09 |
| RAOF | Obviously I can't run that command in the failing case :) | 02:09 |
| RAOF | Well, not now. | 02:09 |
| robert_ancell | RAOF, you're c2 right? | 02:10 |
| robert_ancell | That's the active session | 02:10 |
| RAOF | Right. I *gained* an active session by running ck-launch-session | 02:10 |
| robert_ancell | That would have been c4 - it's the last session added | 02:11 |
| RAOF | But it was run on vt7 | 02:12 |
| mterry | robert_ancell, ah hrm... I looked in the folder I built my 2038 bisect in, and it wasn't valid -- rebuilding 2038 and it works. | 02:18 |
| robert_ancell | mterry, ah | 02:19 |
| robert_ancell | mterry, so where does that leave the range of possibilities? | 02:19 |
| robert_ancell | RAOF, can you check lightdm --show-config | 02:19 |
| mterry | robert_ancell, I no longer have my 2040 folder lying around. But assuming I did do that one right, either 2039 or 2040 are broken | 02:20 |
| robert_ancell | mterry, 2040 was reverted in 2042 | 02:20 |
| robert_ancell | mterry, and 2039 is only test changes | 02:20 |
| mterry | hrm. Then let me redo my 2040 bisect | 02:21 |
| RAOF | robert_ancell: http://paste.ubuntu.com/8255461/ | 02:21 |
| robert_ancell | RAOF, urgh, how did you get a (null) in there... | 02:21 |
| robert_ancell | RAOF, are you in unity8? | 02:22 |
| RAOF | No. | 02:22 |
| RAOF | Heh. This was after removing a .dpkg-bak file in /etc/lightdm/conf.d that was causing lightdm to segfault on startup... :) | 02:23 |
| * RAOF needs to go out and get lunch; back later. | 02:23 | |
| mterry | robert_ancell, 2040 works too, will try 2041 | 02:38 |
| mterry | which I'm guessing will fail? | 02:38 |
| robert_ancell | that's the guess | 02:39 |
| mterry | robert_ancell, OK 2041 seems to work too... Are the later commits risky? | 02:51 |
| mterry | Or am I just screwing up my bisects | 02:52 |
| robert_ancell | 2042 is a reversion and 2043 is the release | 02:52 |
| mterry | :( | 02:53 |
| robert_ancell | is 2043 working now? | 02:54 |
| mterry | grr, it better not be | 02:54 |
| mterry | robert_ancell, ok 2043 did not work | 03:12 |
| mterry | so that's good I guess | 03:12 |
| robert_ancell | I guess? | 03:12 |
| mterry | Assuming my 2041 test was valid, which I'm not guaranteeing, I'll test 2042 next... Is that likely to be a problem commit? | 03:13 |
| mterry | You indicated no | 03:13 |
| * mterry is beginning to doubt his ability to bisect | 03:15 | |
| * mterry tries 2041 again -- that really should be the problem commit | 03:16 | |
| robert_ancell | mterry, how goes 2041? | 03:37 |
| mterry | robert_ancell, it was good again | 03:37 |
| mterry | robert_ancell, trying 2042 for the lulz | 03:37 |
| robert_ancell | mterry, do you have all the packages built so you can easily switch between? | 03:37 |
| mterry | robert_ancell, I unfortunately have been building the .debs over each other. But I have the build directories sitting there so could regenerate debs in relatively shorter order | 03:38 |
| mterry | robert_ancell, and 2042 predictably fails (if it worked and 2043 failed, I'd just give up) | 03:39 |
| mterry | robert_ancell, so assuming my 2041 tests have been valid, and I did redo it... That means 2042 is the problem | 03:40 |
| robert_ancell | that makes no sense | 03:41 |
| mterry | robert_ancell, I do see something about add_login1_seat in that commit... any chance that is odd? | 03:41 |
| mterry | s/odd/buggy/ | 03:42 |
| robert_ancell | 2042 = "Revert globbing changes - there are problems with it" | 03:42 |
| mterry | right... so we're going back to historical behavior | 03:42 |
| robert_ancell | only has changes in src/lightdm.c regarding configuration loading | 03:43 |
| robert_ancell | And they only relate to multi-seat anyway, which is not being used on krillin | 03:43 |
| mterry | robert_ancell, :( | 03:44 |
| mterry | robert_ancell, so I'm guessing I mis-tested 2041... twice | 03:44 |
| robert_ancell | mterry, does repeated runs have the same result? | 03:45 |
| mterry | robert_ancell, it always has in the past | 03:45 |
| robert_ancell | mterry, So to summarise: LightDM 1.11.8 is breaking PolicyKit on krillin, but not mako. 1.11.7 doesn't break PolicyKit on krillin, but does have a race-conditn triggered crash. The bisect it indicating r2042 could cause the problem, but it doesn't make sense. There's been some inconsistency in the bisecting | 03:51 |
| robert_ancell | I should also say "not mako or desktop" | 03:51 |
| mterry | robert_ancell, the inconsistency in the bisecting so far was just me building the wrong revisions -- not actual inconsistencies in results observed -- i.e. so far each revision has exhibited reliable behavior | 03:52 |
| mterry | I think | 03:53 |
| mterry | robert_ancell, I take that back -- I built the same 2041 deb and this time it is broken | 03:53 |
| mterry | so maybe I need to do more reboots before declaring a given revision as "clean" | 03:54 |
| robert_ancell | I have to head out soon, and you must be almost falling asleep. What do you think we should do? | 03:54 |
| mterry | I'll go back and test the 2040 revision | 03:54 |
| mterry | robert_ancell, I think the likely culprit is 2041 -- but if this problem isn't 100% reproducable, I need to retest my older bisects | 03:55 |
| mterry | robert_ancell, but my 2041 test has proven that the problem existed in at least 204 | 03:55 |
| mterry | 2041 | 03:55 |
| mterry | even if it doesn't always show up | 03:55 |
| mterry | robert_ancell, I am about to fall asleep, so I'm going to bed. I can continue testing tomorrow. But I'm not sure I'm qualified to fix it, especially since I don't have the context for the original 2041 commit | 03:56 |
| robert_ancell | mterry, 2041 is the fix for bug 1364725 | 03:57 |
| mterry | robert_ancell, and it's tough for you to investigate without a krillin | 03:57 |
| ubottu | bug 1364725 in lightdm (Ubuntu Trusty) "logind session ID not used due to race condition" [High,In progress] https://launchpad.net/bugs/1364725 | 03:57 |
| robert_ancell | yeah, I'm just guessing here | 03:57 |
| mterry | robert_ancell, so I can continue tomorrow and work on it myself | 03:58 |
| mterry | robert_ancell, but if you have any guesses, email them to me and I can try | 03:58 |
| robert_ancell | mterry, an option is trying r2040.1.1 which is the sticking plaster solution to the above bug instead of the proper solution in r2041 | 03:58 |
| mterry | robert_ancell, OK, will try that tomorrow | 03:58 |
| robert_ancell | mterry, thanks for staying up. bye | 03:59 |
| mterry | but first I should probably stress test r2040 itself to make sure that it doesn't exhibit the bug | 03:59 |
| mterry | it's annoying that it creeped back | 03:59 |
| mterry | I thought it was always reproducable | 03:59 |
| mterry | anyway, bye | 03:59 |
| pitti | doko_: pgrouting> ah right; thanks for the sync | 04:34 |
| pitti | doko_: I'll sort out postgis | 04:34 |
| pitti | doko_: I wedged the mysql-5.5 result for gcc-4.9, will go in now | 05:24 |
| pitti | (new mysql-5.5 version itself will still stay in -proposed) | 05:25 |
| === catbus is now known as Guest90389 | ||
| dholbach | good morning | 07:01 |
| mlankhorst | morning | 07:49 |
| mlankhorst | doko_: don't you mean llvm 3.5 final? | 07:49 |
| === Tribaal_ is now known as Tribaal | ||
| robert_ancell | RAOF, who is the nvidia person who I should subscribe bug 1365336 to? And which package collects nvidia issues? | 08:07 |
| ubottu | bug 1365336 in lightdm (Ubuntu) "Lightdm update=No desktop" [Undecided,Confirmed] https://launchpad.net/bugs/1365336 | 08:07 |
| robert_ancell | It has some udev rules to make nvidia cards work with logind and CanGraphical | 08:07 |
| dholbach | zul, lamont: happy birthdays! :) | 08:08 |
| seb128 | robert_ancell, try tseliot or mlankhorst | 08:10 |
| mlankhorst | alberto milone | 08:10 |
| seb128 | robert_ancell, did you figure out/resolve that "lightdm not working" issue that started this week? I saw a few people mentioning it, including kenvandine | 08:11 |
| robert_ancell | seb128, there seem to be a few issues | 08:11 |
| seb128 | seems sil2100 might have issues as well (but I missed the start of the irc discussion so just assuming there) | 08:11 |
| seb128 | robert_ancell, ken said lightdm failed to start (or start a session) where gdm is working | 08:12 |
| seb128 | that was yesterday | 08:12 |
| robert_ancell | need bugs and information... | 08:12 |
| seb128 | the bug you just listed doesn't have info? | 08:12 |
| robert_ancell | seb128, that one does, don't know if they have the same issue | 08:13 |
| seb128 | k | 08:15 |
| sil2100 | Not sure if my bug is related | 08:16 |
| sil2100 | Since I get Unity launching, I can see that I can actually do stuff on it (as the mouse cursor changes and such), but nothing refreshes the screen | 08:17 |
| sil2100 | i.e. Unity always stays like a screenshot | 08:17 |
| sil2100 | If I restart unity I can see the new changes, like Nautilus or terminals that I open, but it hangs again and nothing refreshes | 08:18 |
| sil2100 | Even though I clearly am able to move around the windows that I open (as per cursor) | 08:18 |
| Saviq | ogra_, no mtp (or adb for that matter) on boot latest mako, had to toggle developer mode back'n'forth, that expected? | 08:19 |
| Saviq | ogra_, is passlock required for mtp? | 08:19 |
| ogra_ | Saviq, only for adb | 08:19 |
| Saviq | ok yeah, no mtp here | 08:19 |
| sil2100 | I didn't see anything useful in logs though... | 08:19 |
| ogra_ | Saviq, i'm just writing an announcement mail :) | 08:19 |
| Saviq | ogra_, maybe hold off on that :D | 08:19 |
| ogra_ | Saviq, ?? | 08:20 |
| Saviq | ogra_, I've dev mode enabled (even though I have no passcode... so can't disable) | 08:20 |
| Saviq | ogra_, mtp nowhere to be seen | 08:20 |
| ogra_ | why would one have anything to do with the other ? | 08:20 |
| ogra_ | is mtp-server running ? | 08:20 |
| ogra_ | also what device ? | 08:21 |
| Saviq | ogra_, now I added passcode, disabled devmode, MTP up | 08:21 |
| Saviq | ogra_, mako r223 | 08:21 |
| * Saviq reboots | 08:21 | |
| Saviq | ogra_, the problem seems to be that you can disable passcode without disabling devmodwe | 08:26 |
| Saviq | devmode | 08:26 |
| ogra_ | Saviq, known bug | 08:26 |
| ogra_ | next on my list | 08:26 |
| Saviq | ogra_, that results in no mtp or adb | 08:26 |
| Saviq | kk | 08:26 |
| ogra_ | mtp shouldnt be affected at all, could you file a bug ? | 08:26 |
| Saviq | ogra_, yeah, will do, against what? | 08:27 |
| * ogra_ needs to see if he can reproduce that | 08:27 | |
| ogra_ | Saviq, heh, good question, thats most likely the gadget driver itself (property settings) | 08:27 |
| ogra_ | start with dbus-property-service ... not really accurate but the closest i can think of | 08:28 |
| sil2100 | I'll be in the meeting in a moment, just need to fetch the HO link | 08:30 |
| Saviq | ogra_, devmode toggles on for me on reboot... | 08:52 |
| Saviq | ogra_, yeah, I can't seem to disable devmode so that it would stick across a reboot... | 08:54 |
| ogra_ | Saviq, yeah, thats still hardcoded until we have found all issues | 08:55 |
| ogra_ | (the boot toggle) | 08:55 |
| Saviq | ogra_, so it's always enabled on boot, that explains things... | 08:55 |
| ogra_ | yeah, that needs a change on the android side | 08:55 |
| ogra_ | which will be the very last step in landing this | 08:56 |
| Saviq | kk | 08:56 |
| Saviq | ogra_, bug #1365911 | 08:58 |
| ubottu | bug 1365911 in dbus-property-service (Ubuntu) "MTP not working on boot if passcode not set" [Undecided,New] https://launchpad.net/bugs/1365911 | 08:58 |
| ogra_ | thanks | 09:00 |
| === sgnb` is now known as sgnb | ||
| rbasak | infinity: I tried a dist-upgrade from my (now built) PPA with C/R today. That wants to also remove mysql-server :-( | 10:16 |
| rbasak | infinity: so I don't see any way to make progress on this now, save for uploading and keeping the window for processing NBS short, and telling people caught in that window to re-install mysql-server manually again. | 10:25 |
| jamespage | doko: my latest mysql-5.5 upload should resolve the autopkgtest failure | 10:29 |
| jamespage | hopefully that unblocks your stuff | 10:29 |
| jamespage | rbasak, mysql-5.6 is suffering from the same problem as mysql-5.5 - are you planning an upload? | 10:36 |
| rbasak | jamespage: yes. I'll cherry-pick your patch shall I? | 10:46 |
| jamespage | rbasak, yes please - I'm also looking at the main.ctype_uca failure - seems it does not like running as a non-root user | 10:46 |
| rbasak | jamespage: I'm not sure about the dep8 test failures for 5.6 though. They failed previously though, so I didn't see it as a regression to prioritise the migration first. | 10:47 |
| rbasak | jamespage: I'm also doubtful about the benefit they provide anyway, since they're not package integration tests. | 10:47 |
| jamespage | rbasak, there are three - my patch resolves two of them | 10:47 |
| jamespage | rbasak, I'd suggest we skip the ctype_uca test for now in the autopkgtests - it wants to write a file to the CHARSETSDIR which bad | 10:50 |
| === MacSlow is now known as MacSlow|lunch | ||
| rbasak | jamespage: do I want fix-func_math-test-failure.patch for 5.6 in Ubuntu? | 10:52 |
| rbasak | Just noticed a merge conflict in series. | 10:53 |
| rbasak | (hence I'm wondering)( | 10:53 |
| rbasak | and fix-mysqlhotcopy-test-failure.patch doesn't apply either :-/ | 10:53 |
| * rbasak investigates | 10:53 | |
| jamespage | rbasak, lemme push it to the debian git repo - you can pick from there if you like | 10:54 |
| rbasak | Thanks | 10:56 |
| jamespage | rbasak, ok - added three commits - http://anonscm.debian.org/cgit/pkg-mysql/mysql-5.6.git/log/ | 11:02 |
| rbasak | (hence I'm wondering)(r 5.6? | 11:04 |
| rbasak | Argh | 11:04 |
| rbasak | jamespage: ah, so dep8 tests now pass for debian on 5.6? | 11:04 |
| jamespage | rbasak, testing now but they should I think | 11:04 |
| rbasak | Nice. Thanks! | 11:04 |
| jamespage | rbasak, they don't get run anywhere automatically right now due to being in experiemtnal only | 11:05 |
| rbasak | I'm still not convinced we want them at all though. If the tests being run on package build are different, can we shove this test run into the build also? | 11:05 |
| rbasak | Or would regressions in dependencies actually cause a test failure? | 11:06 |
| jamespage | rbasak, they do indeed cause failures - the hotcopy ones where due to the perl 5.20 bump | 11:06 |
| rbasak | Fair enough | 11:07 |
| rbasak | That's enough for me. | 11:07 |
| jamespage | rbasak, I don't think you need the func_math one with mysql-5.6 - can't see that failing | 11:07 |
| rbasak | OK | 11:07 |
| rbasak | jamespage: Bjoern applied my apport patch to Debian. Is that right, or is that an issue? | 11:09 |
| rbasak | Makes it easier for me in Ubuntu mind. | 11:09 |
| jamespage | rbasak, he did indeed | 11:09 |
| rbasak | Also it's all flattened into one commit? :-/ | 11:09 |
| rbasak | I suppose it does no harm to install something into /usr/share/apport/package-hooks/ into Debian. I don't know if that's really allowed though. | 11:10 |
| ogra_ | Saviq, your mtp issue will be fixed in the next image ... fix uploaded | 11:10 |
| jamespage | rbasak, hrm yes it is | 11:10 |
| jamespage | rbasak, I was justing thinking about that | 11:10 |
| jamespage | its pretty easy to scope that to derives-from ubuntu | 11:10 |
| rbasak | Yeah that would work well. | 11:10 |
| rbasak | And then there's the postinst debhelper change, which I was just a little concerned about for Debian and SysV. I don't know the implications, since there was presumably a reason it was removed in the first place. | 11:11 |
| jamespage | rbasak, let me make that change | 11:11 |
| rbasak | jamespage: please do. It looks like I can just upload from Debian VCS then, or sync if you upload to experimental. | 11:11 |
| rbasak | (when we're ready) | 11:11 |
| rbasak | There's still this upgrade path question for infinity, but I don't see that as a problem in experimental. | 11:12 |
| rbasak | jamespage: oh, one more thing though. infinity said that Conflicts/Replaces is more correct than Breaks/Replaces here. I checked each Breaks and they all should be changed to Conflicts. I've done that in my PPA, but that needs committing to Debian, too. | 11:13 |
| jamespage | rbasak, how does this look - http://paste.ubuntu.com/8258806/ | 11:14 |
| rbasak | jamespage: that looks fine. I wouldn't include the unrelated noise in 21/22 in that commit, but it doesn't matter. | 11:15 |
| rbasak | jamespage: also, shouldn't the tag line in 11 change? Again, doesn't matter. | 11:15 |
| jamespage | rbasak, nah - team upload | 11:16 |
| rbasak | OK | 11:16 |
| jamespage | not released yet - that can still change tho | 11:16 |
| jamespage | rbasak, will use of Conflicts break the swap out variants stuff? | 11:17 |
| infinity | rbasak: I disagree that you changed all your relationships. | 11:17 |
| infinity | rbasak: mysql-client-core-5.6 has no Conflicts, only Breaks. | 11:18 |
| infinity | rbasak: And if you run the upgrade with "-o Debug::pkgProblemResolver=true", you can see that's where it starts to fall down. | 11:18 |
| infinity | jamespage: "Swap out variant stuff"? | 11:19 |
| infinity | jamespage: Fundamentally, nothing has changed here as far as co-installability. YOu had unversioned Breaks (usually a sure sign you're doing something wrong), so those packages couldn't be co-installed anyway. | 11:19 |
| infinity | jamespage: But all those virtuals should be C/P/R, not B/P/R, and the straight upgrades should be C/R, not B/R | 11:20 |
| jamespage | infinity, no - co-installability was not supported, but installing say mariadb-server would swap out mysql-server automatically | 11:20 |
| infinity | jamespage: This won't make anything worse. Doing it right will make some things better, though. | 11:21 |
| jamespage | infinity, OK - nice to have another pair of eyes on that stuff | 11:21 |
| infinity | rbasak: So, yeah, your claim that you changes all the Breaks to Conflicts in your PPA is a blatant lie, from the PPA I'm testing. ;) | 11:21 |
| infinity | rbasak: Which would explain why it no workie. | 11:22 |
| infinity | Or, at least, would be one of the reasons. | 11:22 |
| * rbasak looks | 11:22 | |
| rbasak | infinity: https://launchpadlibrarian.net/184032264/mysql-5.6_5.6.19-1~exp1ubuntu1~dev3_5.6.19-1~exp1ubuntu1~dev4.diff.gz | 11:22 |
| infinity | Oh, wait, there's three versions published in here. | 11:23 |
| infinity | THAT'S NOT CONFUSING ME AT ALL. | 11:23 |
| rbasak | The changelog is wrong mind, since it didn't fix it. But I didn't know that when I uploaded. | 11:23 |
| rbasak | I thought older versions got superceded? | 11:23 |
| rbasak | https://launchpad.net/~racb/+archive/ubuntu/experimental/+packages only shows me the latest. | 11:24 |
| infinity | If anything went NBS, they'll stick around. | 11:24 |
| rbasak | Oh | 11:24 |
| infinity | Plus, things stick around for a short while regardless. | 11:24 |
| rbasak | I'd never considered NBS inside a PPA before. | 11:24 |
| rbasak | They're sort of hidden from the web view. | 11:25 |
| infinity | Anyhow, I think I need to unwind this (and maybe tag-team with mvo) when I'm more awake. | 11:25 |
| rbasak | OK | 11:25 |
| rbasak | Do you mind extending your FFe deadline in the bug though, please? | 11:25 |
| infinity | But if I don't get to anything interesting by Monday, let's opt for uploading something that's mostly correct and make sure we sort it before release. | 11:25 |
| infinity | Feel free to copy and paste the above. :P | 11:26 |
| rbasak | OK, thanks. | 11:26 |
| rbasak | I will check again, but I believe it'll be sorted by release just by processing NBS. | 11:27 |
| jamespage | rbasak, oh - we need to fix the arm64 build failure for 5.6 as well | 11:27 |
| jamespage | well workaround it at least | 11:28 |
| rbasak | Maybe drop to -O1 for arm64 universally? Probably easier than messing with the buildsystem to pick out one file. | 11:28 |
| cjwatson | I noticed recently that it's possible to fiddle with optimisations on a per-function basis | 11:29 |
| jamespage | rbasak, yes - that was my thinking but if we can apply something like cjwatson suggests that might be nice | 11:29 |
| rbasak | Ah, so patch in a #if defined(arm64) #pramga? | 11:29 |
| infinity | rbasak: No, "just processing NBS" doesn't magically make the bug go away. It's not actually entirely uncommon for people to have multiple releases in sources.list, and we certainly don't stop people from doing so. | 11:30 |
| rbasak | It'll be annoying to test though. I don't have access to an arm64 machine right now. | 11:30 |
| cjwatson | __attribute__ ((optimize ("O1")) | 11:30 |
| rbasak | infinity: OK. I didn't think that case was one that we considered. If we do, then I guess we need to dig further. | 11:30 |
| cjwatson | or __attribute__ ((optimize ("no-tree-dce"))) or whatever | 11:30 |
| rbasak | Thanks cjwatson | 11:31 |
| cjwatson | (oh yes I missed a ")" off my previous example) | 11:31 |
| infinity | rbasak: Well, define "we". Some people don't, some people do. It's a bug if that breaks, but probably not as horrendous a bug as not being able to upgrade at all. | 11:31 |
| infinity | rbasak: But, more to the point, anything that breaks like that is also either a sign of messy dependencies that make apt think too hard, or an apt bug, and the latter would want fixing, while the former should be made less scary to not make upgrades needlessly complex. | 11:32 |
| infinity | (Cause the more complex you make an upgrade, the more likely you are to have things like this happen) | 11:32 |
| rbasak | OK, that makes sense. | 11:33 |
| infinity | The curious thing in a debug run is that it gets the first couple of swaps right, then starts choking. So, it needs a closer look. | 11:33 |
| infinity | Which I'll try to get to when I'm not asleep. | 11:34 |
| rbasak | Given the binary package structure we have at the moment, I'm not sure how to declare things any better or in a way that would fix things without being wrong. So I'll wait for you to take a look. | 11:34 |
| rbasak | It may be that the set of binary packages we have is needlessly complex (I think it is, anyway), but I'd like some justification to start messing with it (and it's extra work). | 11:34 |
| infinity | I'm curious why you suddenly sprouted a new mysql-common-N.N package. | 11:34 |
| rbasak | That's one thing I can get rid of. | 11:35 |
| rbasak | It's because mysql-common was previously provided by src:mysql-5.5. | 11:35 |
| rbasak | (I presume; I didn't do it). | 11:35 |
| rbasak | The mysql-common package is pretty broken in itself IMHO. I don't think it makes sense for a single binary package from one variant's source package to be providing a my.cnf for all variants' packages. | 11:36 |
| rbasak | The variants shouldn't be sharing the same /etc/mysql either, IMHO. | 11:36 |
| rbasak | It's a mess. | 11:36 |
| infinity | It is indeed. | 11:36 |
| infinity | But even weirder to still have both the unversioned and versioned one when you're taking over the former. | 11:36 |
| infinity | So, I assume you want that to become just mysql-common | 11:36 |
| infinity | And drop -5.6 | 11:37 |
| rbasak | Yes. I can do that. | 11:37 |
| rbasak | I was trying to address this, but with release timing it seemed easier to drop 5.5 and reduce the complexity that way first. | 11:37 |
| infinity | I doubt that'll magically make apt happy, but any subtle change in dependencies (and this would drop a dep) might help. :P | 11:37 |
| rbasak | So I was trying to do the minimal thing to get the 5.6 move done without messing with the other pieces at the same time. | 11:38 |
| infinity | Well, you're messing the the other pieces anyway... | 11:38 |
| infinity | You're taking over mysql-common. | 11:38 |
| infinity | *and* shipping a new mysql-common-5.6 that depends on it. | 11:38 |
| infinity | Which is weird. | 11:38 |
| rbasak | Sure. I was just going for the minimal change. | 11:38 |
| rbasak | If you think it might help, I'll fold the two packages together as well. | 11:39 |
| rbasak | I'll experiment now. | 11:39 |
| infinity | Doesn't actually matter if it'll help or not (though that would be nice), let's not upload half-finished stuff. ;) | 11:39 |
| infinity | Take those packages over with purpose and zeal. | 11:39 |
| rbasak | I see fixing up mysql as a multi-release gradual improvement. I don't think it's feasible to do it all at once. | 11:40 |
| rbasak | There's some debate in Debian over the best way to do this as well, because all the other variants are tangled up in it (since they depend on mysql-common) | 11:40 |
| rbasak | And so there are other maintainers involved. | 11:41 |
| rbasak | Hence the glacial pace. | 11:41 |
| infinity | rbasak: Also, I'm sure you have done this, but can you be explicit in the bug as to how you've made sure upstream didn't break ABI in their supposedly-the-same SONAME library? | 11:43 |
| infinity | rbasak: Maybe Debian's yelled at them enough over the years and they get it now, but they've broken ABI a few times in the past without bumping. | 11:44 |
| rbasak | infinity: I just believed them. I'll ask upstream to comment in the bug confirming it. | 11:44 |
| infinity | rbasak: Well, or actually run an ABI checker against the libraries. | 11:44 |
| rbasak | infinity: can you point me to a tool? Happy to do that, but I should ask as presumably ABI can break even if no symbols have disappeared? | 11:46 |
| rbasak | Or is there a tool that can check prototypes from the source also? Though that will has the same catch. | 11:46 |
| infinity | rbasak: Symbols can remain but argument sizes/positions can change, for example. | 11:46 |
| infinity | rbasak: xnox gave a talk about this at Debconf actually. :P | 11:46 |
| infinity | rbasak: IIRC, abi-compliance-checker is the tool he was recommending for checking both binaries and headers. | 11:48 |
| rbasak | Thanks | 11:48 |
| * infinity decides to try harder to sleep, starting with not typing. | 11:49 | |
| === MacSlow|lunch is now known as MacSlow | ||
| === jincreator is now known as 6A4AAKWKH | ||
| cjwatson | siretart: I'm working around the lightspark thing | 13:03 |
| mterry | jamesh, hello! How can I get debug output from upstart itself about job timings and such? | 13:03 |
| cjwatson | siretart: also working on jitsi, so that's all the build failures I currently know about | 13:07 |
| jodh | mterry: Run upstart with --debug' (or 'initctl log-priority debug' for an already booted system). However, Upstart doesn't keep timestamp information itself. But pid 1 uses kmsg so dmesg. For session init jobs, try 'sudo apt-get install upstart-monitor && upstart-monitor -n'. Alternatively, just listen for the D-Bus EventEmitted signal yourself and timestamp their receipt. | 13:11 |
| mterry | jodh, thanks! | 13:12 |
| mterry | jodh, I guessed wrong on what your nick was ;) | 13:12 |
| pitti | rbasak, jamespage: FTR, apport is in Debian as well, so I don't think it's a really bad thing to install hooks in Debian | 13:19 |
| rbasak | Ah, I didn't realise that. Thanks! | 13:19 |
| * rbasak wonders if the hook itself is Ubuntu-specific though | 13:19 | |
| jamespage | pitti, awesome | 13:19 |
| mterry | jodh, I'm trying to monitor bootup sequencing, how do I pass --debug to upstart on boot? | 13:20 |
| jamespage | rbasak, reverted that commit | 13:20 |
| jodh | mterry: add --debug to the kernel command-line via the bootloader | 13:20 |
| === _salem is now known as salem_ | ||
| mterry | jodh, fair enough, thanks! | 13:20 |
| jodh | mterry: what specifically are you trying to do? | 13:20 |
| mterry | jodh, there is some race between lightdm and *something* which triggers on krillin but not on mako. I'm trying to see if it's an upstart job (though I think it may be a dbus-activated issue) | 13:21 |
| jodh | mterry: is there an bug number? | 13:24 |
| mterry | jodh, bug 1365095 righ tnow | 13:24 |
| ubottu | bug 1365095 in unity8 (Ubuntu) "Greeter not asking for pin code in image 11 (krillin)" [High,Confirmed] https://launchpad.net/bugs/1365095 | 13:24 |
| === udevbot_ is now known as udevbot | ||
| pitti | jamespage: "error 9,11,2304,255" -- strangest error code list ever :) | 13:34 |
| pitti | jamespage: thanks for fixing mysql! | 13:34 |
| jamespage | pitti, np and yes its odd | 13:34 |
| mterry | hallyn, hello again! So remember my cgroup oddity from the other day? | 13:58 |
| mterry | hallyn, still having problems, but now I've traced it down to a possible race with lightdm... | 13:59 |
| === JanC_ is now known as JanC | ||
| lagzilla | Sorry is this is the wrong place to ask but I can't seem to find it on google. Where can I find the build flags used to make the bind9 package. | 14:00 |
| pitti | lagzilla: the build log should provide a good first start: https://launchpadlibrarian.net/174230080/buildlog_ubuntu-utopic-amd64.bind9_1%3A9.9.5.dfsg-4_UPLOADING.txt.gz | 14:01 |
| pitti | lagzilla: from https://launchpad.net/ubuntu/+source/bind9 -> current version -> architecture of your choice -> "build log" | 14:02 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| pitti | lagzilla: otherwise you see the package specific flags in debian/rules (after apt-get source bind9) | 14:03 |
| pitti | lagzilla: i. e. the flalgs which are different from the defaults (call dpkg-buildflags to see those) | 14:03 |
| lagzilla | pitti: Thank you!! | 14:04 |
| LocutusOfBorg1 | cjwatson, may I ask you something? | 14:17 |
| cjwatson | just ask, don't ask to ask | 14:18 |
| LocutusOfBorg1 | can you please instead of rebuilding hedgewars for libav11 just sync from debian? | 14:18 |
| hallyn | mterry: so when you login, exactly what is it that calls pam to setup login session? is it the init --user? is it lightdm? | 14:18 |
| === mpt_ is now known as mpt | ||
| mterry | hallyn, lightdm does that | 14:19 |
| LocutusOfBorg1 | the two changes between the utopic verion are: enable --parallel switch, patch cmake to work with cmake 3.0 (two " " added) | 14:19 |
| LocutusOfBorg1 | it will build I hope in less time, and with cmake 3.0 compatibility | 14:20 |
| cjwatson | LocutusOfBorg1: sure, done | 14:20 |
| LocutusOfBorg1 | thanks | 14:20 |
| LocutusOfBorg1 | I hope in the next release when I'll upgrade to utopic to install cmake 3.0 | 14:23 |
| hallyn | mterry: I assume this is an autologin? Is there a way to logout and log back in? | 14:26 |
| mterry | hallyn, not really no, Touch just does one autologin the whole time | 14:27 |
| hallyn | mterry: i saw you were bisecting last night - can you paste a debdiff of the last good and first bad? | 14:27 |
| hallyn | mterry: does sleeping 10 secs before doing the actual login make a difference? | 14:28 |
| mterry | hallyn, yes, sleeping for 5 seconds before running the session command fixes it. *but* sleeping for 5 seconds before launching lightdm does not | 14:28 |
| mterry | in the upstart job | 14:28 |
| mterry | hallyn, http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/revision/2041 is the troublesome commit | 14:29 |
| hallyn | so you mean 5 seconds before calling or at top of session_set_pam_service? | 14:29 |
| mterry | hallyn, we think the change in session-child.c to not call a dbus command changed the timing enough to expose this problem | 14:29 |
| hallyn | mterry: one thing to possibly try would be to create an upstart job to start systemd-shim, start on starting lightdm | 14:30 |
| mterry | hallyn, in that diff, I added sleep(5) to where we get the XDG_SESSION_ID var from pam | 14:30 |
| hallyn | thx looking at the diff | 14:30 |
| mterry | hallyn, but pam-systemd would start logind and all that shim stuff, right? | 14:31 |
| pitti | smoser, jamespage: hm, I just noticed that our cloud images still use grub-legacy? I tried to change kernel params in /etc/default/grub and /etc/default/grub.d/50-cloudimg-settings.cfg, but they still don't become active in /boot/grub/menu.lst | 14:32 |
| pitti | smoser, jamespage: what's the appropriate place to set them? | 14:32 |
| pitti | apparently update-grub doesn't update menu.lst from the files above | 14:32 |
| cjwatson | smoser,jamespage: speaking of which, pv-grub2 is making progress again, see #759018 | 14:32 |
| cjwatson | er that's Debian #759018 | 14:32 |
| ubottu | Debian bug 759018 in src:grub2 "please provide prebuilt grub-xen binaries for host (dom0) use" [Wishlist,Open] http://bugs.debian.org/759018 | 14:32 |
| hallyn | mterry: in login.c, could you add a sanity check to make sure that session->priv->login1_session and console_kit_cookie are right? | 14:33 |
| cjwatson | so hopefully we'll eventually be able to actually use that :) | 14:33 |
| hallyn | i dunno that's reaching tough | 14:34 |
| pitti | smoser, jamespage: I tried to call update-grub-legacy-ec2 explicitly and that also said "Updating /boot/grub/menu.lst", but apparently still doesn't take GRUB_CMDLINE_LINUX_DEFAULT into account? | 14:34 |
| mterry | hallyn, the values are right in the child session at least | 14:34 |
| mterry | hallyn, I checked /proc/pid/environ | 14:34 |
| jamespage | pitti, I'd defer to smoser or utlemming - this is more their area if expertise! | 14:34 |
| pitti | jamespage: ah, thanks | 14:34 |
| pitti | smoser, utlemming: it seems that menu.lst doesn't even have the options that we set by defualt -- console=tty1 console=ttyS0 ? | 14:35 |
| mterry | hallyn, systemd-shim isn't a job? | 14:36 |
| pitti | mterry: it's d-bus activated | 14:36 |
| mterry | pitti, what does it do different from logind or whatnot? | 14:36 |
| pitti | mterry: I'm not sure it's sensibly comparable to logind; but it only offers a D-BUS API and doesn't need to run all the time, so D-BUS activation seems fine? | 14:37 |
| mterry | pitti, sure I'm just trying to figure out whether it might be related to my problem. not sure what it did | 14:37 |
| pitti | mterry: it mostly just translates requests like "start unit suspend" or "create a cgroup" into calling "pm-suspend" or cgmanager | 14:37 |
| mterry | pitti, ooh... that cgroup thing sounds related | 14:38 |
| pitti | mterry: so if you look for it, it shouldn't run most of the time (it times out after 10 s of not talking to it) | 14:38 |
| hallyn | pitti: not for long :( | 14:38 |
| pitti | mterry: so you'll only see it on new logins (or logouts), or suspend/resume etc. | 14:38 |
| mterry | hm. but if it's dbus-activated, I'm not sure what the timing issue would be | 14:38 |
| hallyn | mterry: it'd be a bug in logind or libdbus i guess, not waiting unti lit actuall starts up to return a nerror | 14:39 |
| hallyn | mterry: what is v2 of the login protocoal? | 14:39 |
| pitti | hm, we've been using d-bus activation for years with tons of stuff; quite unlikely that d-bus activation still has such blatant bugs | 14:40 |
| pitti | systemd-shim could of course still have bugs, the cgmanager integration is still rather new | 14:40 |
| hallyn | seems to demand extra newlines. | 14:40 |
| pitti | only a few days ago there was a race condition between lightdm starting earlier (or too early) than cgmanager; stuff of that sort | 14:40 |
| mterry | hallyn, v2 returns both logind and consolekit cookies, rather than just the appropriate one | 14:41 |
| mterry | hallyn, one of which is now always NULL | 14:41 |
| pitti | wow, are we still concerned about CK? | 14:41 |
| mterry | pitti, lighdm is | 14:41 |
| pitti | ah, interesting | 14:41 |
| hallyn | pitti: looking at the process table yesterday cgmanager and cgproxy definately started before lightdm on the bad krilin system | 14:42 |
| pitti | right, that shoudl work now | 14:43 |
| hallyn | but, the cgproxy.log doesnt' show any requests on behalf of lightdm | 14:43 |
| hallyn | might rebuild libpam-systemd with some introspection (fprintfs :) added to see if it's being called at all | 14:43 |
| pitti | have you tried modifying /etc/pam.d/common-session to append "debug=true" to pam_systemd.so? | 14:44 |
| pitti | then you get some nice debugging in /var/log/auth.log | 14:44 |
| ogra_ | if i use dh_installudev in debian/rules and have multiple packages, does the order of the dh_installudev commands matter ? (i.e. if the generic one comes last will it override the named ones above ?) | 14:44 |
| pitti | ogra_: you mean you call it with different -p options? | 14:45 |
| mterry | pitti, good point, will try that | 14:45 |
| pitti | order shouldn't matter at all | 14:45 |
| ogra_ | verride_dh_installudev: | 14:45 |
| ogra_ | dh_installudev --name=android-tools-adbd --priority=98 | 14:45 |
| ogra_ | dh_installudev --priority=70 | 14:45 |
| ogra_ | pitti, like that | 14:45 |
| ogra_ | oh, crap | 14:45 |
| pitti | ogra_: ah; still,order shouldn't matter at all, as long as the files are named correctly | 14:46 |
| ogra_ | indeed i did use --name not -p | 14:46 |
| pitti | ah :) | 14:46 |
| ogra_ | hmm | 14:46 |
| rbasak | infinity: I've folded mysql-common-5.6 into mysql-common now, but apt still wants to remove mysql-server :-( | 14:46 |
| ogra_ | it doesnt know -p | 14:46 |
| pitti | ogra_: then you should call the other with -Nandroid-tools-adbd | 14:46 |
| ogra_ | according to the manpage | 14:46 |
| pitti | ogra_: or --remaining-packages | 14:46 |
| pitti | ogra_: otherwise the second command will install debian/android-tools-adbd.rules again with prio 70 | 14:47 |
| pitti | ogra_: as by default it acts on all pacakges | 14:47 |
| ogra_ | pitti, right, it ends up with 70 currently | 14:47 |
| pitti | ogra_: right, so in that regard the order matters, if you install a rules several times with different prio | 14:48 |
| mterry | hallyn, pitti: yeah libpam-systemd is being called, can see the output in auth.log. I mean, it was returning the correct XDG_SESSION_ID to lightdm already. Logind thinks everything is fine, the session is active, etc. No problem with logind. It's just that the session doesn't have proper cgroup paths defined, they are all the root path | 14:49 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| smoser | pitti, update-grub-legacy-ec2 does not do that. | 14:56 |
| smoser | and i wouldn't plan on it doing that. | 14:56 |
| pitti | smoser: yeah, I just tried it as the usual update-grub didn't | 14:56 |
| smoser | it *should* correctly allow you to edit /boot/grub/menu.lst | 14:56 |
| smoser | the way things used to work with grub 0.97 | 14:57 |
| pitti | smoser: ah, so I'm supposed to edit that file directly? | 14:57 |
| smoser | i think that file has information in it on how to update it | 14:57 |
| smoser | its "legacy" | 14:57 |
| hallyn | mterry: can you build a version of systemd-shim with the src/cgmanager.c call to cgmanager_call("RemoveOnEmpty") commented out? | 14:57 |
| smoser | but it should behave the same way grub 0.97 did. ie, what was that , prior to lucid ? | 14:57 |
| pitti | smoser: ok, WFM, thanks; sorry, I have completely forgotten how grub-legacy works, it seem s:/ | 14:58 |
| LocutusOfBorg1 | have a nice weekend | 14:58 |
| pitti | smoser: I'll do that then | 14:58 |
| pitti | smoser: it's nothing permanent anyway; I'm writing tests for booting with systemd as init | 14:58 |
| didrocks | hey barry, do you need any help for nose-cov? (I can ship the file if you +1 on it) | 14:59 |
| barry | didrocks: you'd be shipping an init_cov_core.pth file in nose-cov? that doesn't seem right. would you mind filing a bug on cov-core in debian describing the issue? i will take a look at it and test it when i do a cov-core update, and i will try to get to that today | 15:02 |
| didrocks | barry: sorry, I meant cov-core actually. I can open a bug, sure | 15:03 |
| barry | didrocks: awesome, thanks | 15:03 |
| bdmurray_ | slangasek: Did you setup a test for whoopsie with daisy.staging.ubuntu.com? | 15:03 |
| didrocks | yw! | 15:03 |
| mterry | hallyn, yeah ok I could try that | 15:03 |
| === bdmurray_ is now known as bdmurray | ||
| slangasek | bdmurray: I didn't | 15:10 |
| mterry | hallyn, didn't help | 15:10 |
| slangasek | bdmurray: is that something you were expecting me to do, or did somebody do this and you're trying to figure out who? | 15:10 |
| hallyn | mterry: mterry or maybe build with http://paste.ubuntu.com/8260445/ (so we can also see if it's getting called) | 15:10 |
| hallyn | mterry: oh. ok, well that's good on the one hand, at least we know it's not that race again | 15:10 |
| mterry | hallyn, shall I try that debdiff still? | 15:11 |
| hallyn | mterry: yeah, and then pastebin /tmp/debug and ps -ef output so we can check whether shim is being called to set the cgroups | 15:11 |
| bdmurray | slangasek: I was thinking of this https://code.launchpad.net/~vorlon/ubuntu-test-cases/better-whoopsie-testing/+merge/229152 | 15:15 |
| didrocks | barry: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760583 FYI | 15:16 |
| ubottu | Debian bug 760583 in cov-core "cov-core should ship the generated .pth file to enable subprocess coverage tracking with nose-cov" [Normal,Open] | 15:16 |
| mterry | hallyn, http://paste.ubuntu.com/8260524/ | 15:18 |
| mterry | hallyn, those cgroup paths look right! | 15:18 |
| mterry | hallyn, so... process 1450 has the right cgroup paths | 15:19 |
| mterry | hallyn, but the session it spawns (init --user) does not | 15:20 |
| barry | didrocks: got it | 15:20 |
| barry | let me work on that now | 15:20 |
| didrocks | thanks :) | 15:20 |
| mterry | hallyn, the session is created by a fork() in that same function I mentioned adding a sleep(5) to earlier | 15:22 |
| mterry | hallyn, is process 1450 granted the cgroup info after the fork? | 15:22 |
| mterry | hallyn, how does cgroup assignment work? | 15:22 |
| mterry | hallyn, I don't even know where the call to the shim to create the cgroup is made... | 15:24 |
| slangasek | bdmurray: oh - /that/ test, yes, I did point the smoketesting at staging, sorry | 15:26 |
| bdmurray | slangasek: was it ever merged though? | 15:27 |
| slangasek | bdmurray: hmm - it was merged somewhere, but that MP suggests that the target branch is some ancient thing | 15:29 |
| mterry | pitti, can you explain a little bit about who calls the shim for cgroup stuff? I'm confused on when/where cgroups are created | 15:29 |
| pitti | mterry: logind calls shim's (or systemd's) StartTransientUnit() which creates a new group, and then that contains the new session | 15:29 |
| pitti | mterry: I don't know much detail about that though, that'd be desrt or hallyn | 15:30 |
| slangasek | bdmurray: so it was merged, but I think someone rearranged the branches | 15:30 |
| mterry | pitti, ah... ok thanks | 15:30 |
| desrt | hi :) | 15:30 |
| slangasek | bdmurray: apparently the new branch target is https://code.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch | 15:30 |
| mterry | desrt, hello! I'm investigating some race we have with lightdm and cgroups.... let me do a little investigation first | 15:31 |
| desrt | mterry: can you ping again in half an hour or so? in a meeting.... | 15:31 |
| slangasek | bdmurray: but my change isn't merged there either. so I really don't know what happened here | 15:31 |
| * pitti waves good bye, enjoy the weekend everyonr | 15:31 | |
| mterry | desrt, sure! | 15:31 |
| mterry | pitti, bye! | 15:31 |
| === catbus is now known as Guest37301 | ||
| mterry | hallyn, so yeah... "cgroups being set for the process" racing with the fork() call fits the facts... any ideas if that's possible? | 15:38 |
| tedg | hallyn, Do you have a reviewer for the systemd-shim MR? | 15:41 |
| hallyn | mterry: that really shouldn't be possible. pam should be synchronous | 15:44 |
| mterry | hallyn, yeah looking at all the logind calls into cgmanager, it certainly seems all sync | 15:45 |
| mterry | hallyn, is some part of our cgmanager daemon async? | 15:46 |
| hallyn | mterry: only removeonempty | 15:46 |
| hallyn | jodh: ^ is it possible that 'init --user' spawned by lightdom as phablet user could be doing a movepidabs? | 15:46 |
| hallyn | I only see one such call, in init/cgroup.c:cgroup_create, | 15:47 |
| hallyn | and it only does it if ! user_job | 15:47 |
| hallyn | so is that considered a user job? | 15:47 |
| hallyn | (but really, why would that change with lightdm version?) | 15:48 |
| jodh | hallyn: only system-level cgroup jobs do that, so no. | 15:48 |
| hallyn | yeah that cna't be it | 15:48 |
| hallyn | so something in that lightdm delta must be changing the synchronous flow | 15:48 |
| mterry | hallyn, well the lightdm change just affected the timing we think | 15:49 |
| hallyn | so that the fork is happening before the call to pam_session_init | 15:49 |
| mterry | hallyn, like I said, if I add a sleep(5) it goes back to working behavior | 15:49 |
| mterry | hallyn, pam_start is called far before the fork | 15:51 |
| hallyn | but yo uput the sleep at the top of pam-start right? not the fork? | 15:51 |
| hallyn | is it always the case that lightdm --session-child is in the right cgroup and init --user is not? | 15:52 |
| mterry | hallyn, I can test more | 15:52 |
| mterry | hallyn, I put the sleep between pam_start/pam_open_session and the fork | 15:53 |
| hallyn | mterry: ok so I guess I haven' tlooked at that part of the logind code itself. pam itself should be completely synchronous, and shim and cgmanager in that part are. But i guess i'ts possible that logind sets everything else up, queues a task to do the dbus call to shim, and immediately returns | 15:56 |
| * hallyn goes to look | 15:56 | |
| mterry | hallyn, the seemingly most relevant code is in src/session-child.c | 15:56 |
| === salem_ is now known as _salem | ||
| mterry | hallyn, certainly seems like the session-child/init cgroup delta is consistent (when the problem occurs -- it's not 100% consistent) | 15:57 |
| hallyn | mterry: no, src/login/logind-dbus.c:manager_start_scope() blocks on the return from StartTransientUnit, so that's not it | 15:58 |
| hallyn | (that is, no, logind is not th eprolbem) | 15:58 |
| bdmurray | plars: how can we get this merged / going? https://code.launchpad.net/~vorlon/ubuntu-test-cases/better-whoopsie-testing/+merge/229152 | 15:59 |
| mterry | hallyn, sometimes init --user has 3 cgroups set, just not the systemd one. Other times it is missing all 4 | 15:59 |
| mterry | (and sometimes it has all 4) | 15:59 |
| desrt | mterry: systemd-shim!!!! | 16:00 |
| desrt | whoever wrote this shit... my god... | 16:00 |
| mterry | desrt, agreed! | 16:01 |
| plars | bdmurray: I was looking for your ack on it. If you are happy with it, then I can get it merged | 16:01 |
| mterry | desrt, so I don't know how much you've been following, but... | 16:01 |
| desrt | i already have a theory | 16:01 |
| desrt | systemd-shim, in the name of efficiency, submits cgroup requests to cgmanager async | 16:02 |
| mterry | desrt, it seems like there's a race between lightdm/cgmanager/logind/something | 16:02 |
| desrt | all at the same time | 16:02 |
| mterry | desrt, aha! an async achille's heel | 16:02 |
| desrt | which means that systemd-shim is capable of returning to its caller "okay! all done!" before the cgroup is properly setup | 16:02 |
| hallyn | feh | 16:02 |
| hallyn | i forgot it did that | 16:02 |
| hallyn | iow i lied to mterry | 16:02 |
| desrt | i wrote the code in such a way that it would be easy to change if this became a problem | 16:03 |
| desrt | ie: should only need to patch one place | 16:03 |
| hallyn | desrt: i don't know if you've been following the Abandon discussoin as well, but systemd-shim now has to become long-lived actually | 16:03 |
| slangasek | plars: surely, this was already merged and that's why the whoopsie smoke test has been failing? I don't understand what happened with that particular MP though, which is not (no longer?) targeting the correct branch. http://ci.ubuntu.com/smokeng/utopic/touch/mako/222:20140904.1:20140903.1/10220/default/1631128/ | 16:03 |
| desrt | hallyn: :( | 16:03 |
| desrt | hallyn: what about the idea of poking through sysfs to find the state we need? | 16:03 |
| hallyn | desrt: for what? | 16:03 |
| plars | slangasek: sec, it's been a while since I looked at it, let me check | 16:03 |
| desrt | the idea is that we can shutdown existing transient units, right? | 16:03 |
| desrt | those transient units will be recorded as state in the kernel in the form of cgroups visible in sysfs | 16:03 |
| plars | slangasek: the mp was against the wrong branch, so that could be why it didn't automatically go away | 16:04 |
| bdmurray | plars: well, I've approved it now fwiw | 16:04 |
| mterry | desrt, is this in cgmanager_call()? | 16:04 |
| desrt | mterry: probably. | 16:04 |
| desrt | "Avoid round-trip delays: issue all calls at once and report errors..." | 16:04 |
| desrt | so you have two options | 16:04 |
| hallyn | desrt: no the problem is that we have to listen to object path org.freedesktop.systemd.unit.session_2d${sessionid}_2d.scope | 16:05 |
| desrt | one is to add a counter and block until that counter is reached | 16:05 |
| hallyn | that's where Abandon gets sent | 16:05 |
| desrt | this would involve using a private maincontext probably | 16:05 |
| desrt | the other is to just convert it to using sync calls | 16:05 |
| desrt | will hurt performance, but this isn't exactly an operation that is happening once per second | 16:05 |
| slangasek | plars: yes - but I also can't seem to figure out the right branch | 16:05 |
| hallyn | desrt: add the counter in shim, right? | 16:05 |
| desrt | hallyn: we can do that.... and you can also use a subtree watch | 16:05 |
| desrt | hallyn: ya... i'm not totally keen on the counter idea | 16:06 |
| mterry | desrt, I will certainly test the fix with a sync call, testing now | 16:06 |
| desrt | i've seen these sorts of things go off the rails before... they're hard to get right | 16:06 |
| desrt | mterry: be sure to unref the return value | 16:06 |
| bdmurray | slangasek: maybe its failing because of the run in foreground change? | 16:06 |
| hallyn | desrt: but we can't use a subtree for dbus activation right? | 16:06 |
| mterry | desrt, ok. I've lived in qt land too long already, unref'ing things seems quaint | 16:06 |
| plars | slangasek: yeah, it's kind of a pain. I'll check on it right after this call but I suspect you're right that it's already merged | 16:07 |
| desrt | mterry: welcome back, man! | 16:07 |
| slangasek | bdmurray: I really don't know why it's failing; help understanding this is appreciated | 16:07 |
| desrt | hallyn: we certainly can | 16:07 |
| desrt | hallyn: one merely has to register the subtree watch before taking the bus name | 16:07 |
| hallyn | desrt: ! if so then we can far simply my mp against lp:ubuntu/utopic/systemd-shim | 16:07 |
| desrt | so that it's already there by the time we start receiving messages | 16:07 |
| desrt | man | 16:08 |
| desrt | you guys have been busy :) | 16:08 |
| desrt | so a bit of theory: on dbus, it's the well-known names that are activated | 16:09 |
| hallyn | ok well i need to go back to server-land for a few hours. | 16:09 |
| hallyn | hm, | 16:09 |
| desrt | the object paths are solely a concern of the process that owns that name | 16:09 |
| desrt | and that process has a chance to setup whatever object paths it wants to during its activation | 16:09 |
| hallyn | but that never worked for me | 16:09 |
| desrt | so when it comes online it already has a full set | 16:09 |
| desrt | so we could even do things like scan sysfs on startup to decide which objects to export, if we wanted | 16:09 |
| desrt | "exporting" an object is even a bit of a misnomer... we actually do nothing to "export" it... we only make a note to ourselves, that if somebody asks about this object in the future, then we handle it in such a way.... | 16:10 |
| hallyn | i registered the org.freedesktop.systemd1.Scope name, but never received the org.freedesktop.systemd1.unit.session*.Abandon methods, | 16:10 |
| hallyn | and logind said no such interface | 16:10 |
| desrt | the bus itself has absolutely no concept of objects | 16:10 |
| * hallyn rereads | 16:10 | |
| desrt | is org.freedesktop.systemd1.Scope a name or an interface? | 16:10 |
| hallyn | that is the interface | 16:10 |
| desrt | so how it works is that you register an object with a particular interface, right? | 16:11 |
| hallyn | right. long as i'm running that works fine | 16:11 |
| desrt | you have to register the object path before we take the name... | 16:11 |
| hallyn | i cna't know the object path | 16:12 |
| desrt | ie: in shim_bus_acquired | 16:12 |
| desrt | but you can do subtree... | 16:12 |
| desrt | which will watch all paths below /x/y/z/* | 16:12 |
| hallyn | on the object path tree? | 16:12 |
| hallyn | ok, and for the dbus activation, what Name do I use - interface or path subtree? | 16:12 |
| hallyn | (i.e. org.freedesktop.systemd1.Scope or org.freedesktop.systemd1.unit) | 16:12 |
| desrt | neither? | 16:13 |
| desrt | bus activation is always based on bus names | 16:13 |
| desrt | which is probably always going to be org.freedesktop.systemd1 | 16:13 |
| hallyn | ok | 16:13 |
| desrt | interfaces are also not a concern of the bus | 16:13 |
| desrt | all of this stuff is only interpreted by the client _after_ it has activated | 16:14 |
| hallyn | so i get dbus-actviated for Abandon (not sure that was working, but imght have), then i register subtree for org.freedesktop.systemd1.unit? | 16:14 |
| hallyn | I think I only ever tried org.freedesktop.systemd1.Scope | 16:14 |
| desrt | strictly, you get dbus-activated because someone tried to send a message to org.freedesktop.systemd1 | 16:14 |
| hallyn | right | 16:14 |
| desrt | then you set stuff up... | 16:14 |
| desrt | then you claim the name | 16:14 |
| desrt | then you get the message | 16:14 |
| hallyn | i can't claim the name until i know what the name is, | 16:14 |
| desrt | only at that point do you start making sense of interface, object, method, etc. | 16:14 |
| desrt | but the name is always org.freedesktop.systemd1 | 16:15 |
| hallyn | oh | 16:15 |
| desrt | the other things are interface/object/method | 16:15 |
| hallyn | ok, so i can try all this this way again on monday hopefuly, | 16:15 |
| desrt | welcome to dbus -- the land of confusion :) | 16:15 |
| hallyn | if you wanted to take a stab, the actual cgroup code we wnat is in my mp | 16:16 |
| desrt | k. i might get a chance to take a look after lunch | 16:16 |
| hallyn | lp:~serge-hallyn/ubuntu/utopic/systemd-shim/shim-abandoncg | 16:16 |
| desrt | this approach seemed to work well last time :) | 16:16 |
| desrt | you deal with cgmanager, i deal with dbus :) | 16:16 |
| hallyn | i would SO much rather get the activation to work tha make shim long-lived! | 16:17 |
| hallyn | great to have you back :) | 16:17 |
| desrt | same. | 16:17 |
| hallyn | thanks much, ttyl | 16:17 |
| desrt | ta | 16:17 |
| mterry | desrt, seems to be fixing it | 16:17 |
| desrt | mterry: win! | 16:17 |
| mterry | desrt, trying more runs to reduce the chance I've just been getting lucky | 16:17 |
| desrt | of course, with races, one never truly knows.... :) | 16:17 |
| desrt | mterry: do you want me to just make the chance here and push it? | 16:18 |
| mterry | desrt, it was happening about 4 out of 5 before, I've run 3 times without it | 16:18 |
| desrt | or should i use your patch? | 16:18 |
| mterry | desrt, my patch is what you'd imagine -- moving the callback code up to the call itself | 16:18 |
| desrt | (did you do the error handling correctly, etc?) | 16:18 |
| desrt | k | 16:18 |
| desrt | i'll just do it locally then | 16:18 |
| mterry | desrt, 5 successes so far | 16:19 |
| hallyn | \o/ | 16:19 |
| mterry | desrt, yeah, I'm getting tired of rebooting, 7 successes in a row, I'll take it as fixed | 16:22 |
| desrt | awesome | 16:22 |
| mterry | desrt, bug 1365095 is where I've been tracking it | 16:23 |
| ubottu | bug 1365095 in unity8 (Ubuntu) "Greeter not asking for pin code in image 11 (krillin)" [High,Confirmed] https://launchpad.net/bugs/1365095 | 16:23 |
| mterry | desrt, I'll add a comment to the bug, but just if you write a changelog entry | 16:23 |
| desrt | can you take a quick look at http://ur1.ca/i4id7 ? | 16:23 |
| desrt | i'm about to push that -- just want to make sure this is the same fix as you had :) | 16:23 |
| * mterry looks | 16:25 | |
| desrt | for somewhat silly reasons, i am currently unable to login to launchpad :p | 16:25 |
| mterry | desrt, that is the exact same patch, awesome | 16:26 |
| mterry | only so many ways to do that :) | 16:26 |
| desrt | (long story: i attached my yubikey to my dorm-room keyring at debconf... and when i left, i turned it in...) | 16:26 |
| desrt | okay. pushed upstream. | 16:26 |
| mterry | desrt, :) | 16:27 |
| desrt | they were nice enough to drop it in the mail... but now i wait :) | 16:27 |
| desrt | https://github.com/desrt/systemd-shim/commit/80e9dc98b733a4386c0cca78861892506b2cfae2 | 16:27 |
| mterry | desrt, you need a second key! | 16:27 |
| desrt | ya | 16:27 |
| desrt | i want to wait until their next model comes out, though | 16:27 |
| desrt | since their website is doing a good job of convincing me not to buy the existing one by saying "next model will support new auth spec. CURRENT MODEL NOT UPGRADABLE" | 16:28 |
| mterry | desrt, :) | 16:28 |
| mterry | desrt, so what's the path into Ubuntu's archive for this package? This fix is something I'd like to land in shorter order rather than waiting on bundling other shim fixes | 16:29 |
| desrt | talk to pitti, i think? | 16:29 |
| desrt | i have no idea how that half of it works :/ | 16:29 |
| desrt | maybe slangasek could also help... i think he was involved in the debian side? | 16:30 |
| bdmurray | plars: if you find the branch containing the test let me know as I'd like to make some changes to it. | 16:30 |
| plars | bdmurray: yes, I was just about to check it, one sec | 16:30 |
| plars | bdmurray: confirmed, it was merged already | 16:31 |
| slangasek | desrt, mterry: I'm happy to cherry-pick a change into Debian and sync to Ubuntu today. But we should also resolve https://code.launchpad.net/~serge-hallyn/ubuntu/utopic/systemd-shim/shim-abandoncg/+merge/233280 today | 16:32 |
| bdmurray | plars: and what branch contains the test so I can make a change to it? | 16:32 |
| desrt | slangasek: if you want to vendor-patch that as well, go ahead... but i'd rather not take it upstream without a closer look first | 16:32 |
| slangasek | desrt: well, I'm also not vendor patching it without taking it a closer look than I have so far :) but it's critical urgency | 16:33 |
| plars | bdmurray: lp:ubuntu-test-cases/touch | 16:33 |
| desrt | okay | 16:33 |
| mterry | slangasek, sure if that's critical too then I have no issues with bundling them | 16:33 |
| desrt | so let me move it from my "i might take a look at it this afternoon" list to "i will take a look at it" :) | 16:33 |
| hallyn | slangasek: desrt was going to do a cleaner version of my mp - that lets systemd-shim still timeout | 16:33 |
| bdmurray | plars: got it, thanks | 16:34 |
| slangasek | hallyn: oh. Should I hold off then? | 16:34 |
| hallyn | slangasek: so given that, i'd prefer to not have my mp make it into any package if possible :) | 16:34 |
| hallyn | slangasek: yeah | 16:34 |
| slangasek | desrt: ^^ is that on your plate for today? | 16:34 |
| desrt | slangasek: yes. | 16:34 |
| desrt | had a few other things, but none of them could be described by anyone as 'critical' | 16:34 |
| slangasek | desrt: ok, then I'll step back from that and just look at the other cherry pick. that's https://github.com/desrt/systemd-shim/commit/80e9dc98b733a4386c0cca78861892506b2cfae2 ? | 16:34 |
| desrt | yes | 16:35 |
| desrt | if i land the other thing today i'll probably also do a new release, though | 16:35 |
| desrt | there is a pitti patch for changing a typesignature there as well | 16:36 |
| cjwatson | siretart: landing libav; after that's in I'll demote jitsi and sort out ubuntustudio-meta | 16:47 |
| cjwatson | that should hopefully be enough | 16:47 |
| desrt | cjwatson: what ever came of this ffmpeg discussion? | 16:50 |
| cjwatson | desrt: nothing very concrete as yet | 16:50 |
| desrt | hello debian :) | 16:50 |
| ScottK | I think we understand once again why there was a fork. | 16:51 |
| desrt | that's helpful, at least | 16:52 |
| ScottK | Those of us who were around then, weren't particularly confused on that point. | 16:53 |
| === _salem is now known as salem_ | ||
| awe_ | slangasek, quick question... if a bug is filed in LP because of a crash, it's marked as private by default. Can anyone besides the owner look at the bug, or must the owner make it public first? | 17:23 |
| jtaylor | I think bug control members can see it | 17:29 |
| unstable | I want to maintain a change management process for updating deb packages on a lot of ubuntu machines. I know koji/bodhi for rpm based systems works really well ( https://admin.fedoraproject.org/updates / http://koji.fedoraproject.org/koji/ ), or pulp. Is there an equivalent to these systems that the ubuntu team uses? | 17:38 |
| === Mikee_C_ is now known as Mikee_C | ||
| desrt | hallyn: hey... are you around again? | 17:42 |
| slangasek | awe_: what jtaylor said, I think | 17:43 |
| awe_ | all good now, but thanks | 17:44 |
| hallyn | desrt: for 10 mins | 17:45 |
| desrt | hallyn: any reason why you didn't explore the sysfs tree of cgroups yourself? | 17:45 |
| hallyn | desrt: you mean /sys/fs/cgroup/freezer etc? | 17:45 |
| desrt | was just easier to use the dbus api and get cgmanager to do it for you? | 17:45 |
| hallyn | that usually is not mounted | 17:45 |
| hallyn | no, it's because cgroup fs acces is not guaranteed, | 17:45 |
| hallyn | especially not in nested unpriv containers | 17:46 |
| desrt | interesting. | 17:46 |
| hallyn | (cgmanager's raison d'etre) | 17:46 |
| desrt | i suppose that makes sense. thanks. | 17:46 |
| * desrt is glad he asked :) | 17:46 | |
| hallyn | yeah it slows things down a bit, especially through a proxy. but it's necessary given cgroup kernel maintainer's view on fs access delegation | 17:46 |
| desrt | ya... i've read about these views :) | 17:47 |
| desrt | makes sense, though | 17:47 |
| desrt | feels slightly odd that we delegate the delegation, ... but meh | 17:47 |
| desrt | it is a shim, after all | 17:48 |
| hallyn | desrt: heh, just wait until we put an fs on top of cgmanager :) | 17:48 |
| hallyn | s/we/stgraber/ | 17:48 |
| desrt | i guess we will not do that soon? | 17:49 |
| hallyn | i think we will | 17:49 |
| desrt | (or ever...)? | 17:49 |
| desrt | post 14.10, aren't we supposed to hop to systemd entirely? | 17:49 |
| hallyn | that will allow systemd to run using it's current fs accesses | 17:49 |
| stgraber | desrt: not this cycle, but we should have this for 15.04 | 17:49 |
| hallyn | yeah, and systemd uses fs access | 17:49 |
| desrt | but i mean... don't we stop using cgmanager then? | 17:49 |
| stgraber | that's so we can start systemd in an unprivileged container which isn't allowed to mount cgroupfs itself so systemd in that container can still do any cgroup configuration it needs | 17:49 |
| hallyn | desrt: no, then a fuse fs will talk to cgmanager to present what looks like cgroupfs to systemd in a child container | 17:50 |
| hallyn | you thought dbus was bad :) | 17:50 |
| desrt | i'm making a face | 17:50 |
| desrt | if this was a videochat, you'd see my face | 17:50 |
| hallyn | a happy on ei'm sure | 17:50 |
| desrt | "wince" would probably be the best description | 17:50 |
| desrt | google helpfully gives this result for image search: http://mocoloco.com/art/upload/2007/10/wince/greenberg_wince_oct07.jpg | 17:51 |
| desrt | i assume that we've communicated with systemd upstream and they are not interested in implementing this in a more reasonable way? | 17:52 |
| hallyn | desrt: it's always possible that at plumber's we'll come to a magical consensus that stops the need for that | 17:52 |
| desrt | i certainly hope so | 17:52 |
| desrt | makes me wish i didn't turn down my invite to plumbers :( | 17:52 |
| hallyn | desrt: i'm giving a talk on cgmanager at linuxcon.eu and hoping to talk to systemd folks after that | 17:52 |
| hallyn | nice fangs btw | 17:53 |
| hallyn | oh didn't look clsely enough, tguess that's not what they are | 17:53 |
| desrt | sigh. | 17:53 |
| desrt | maybe i ought to go after all :/ | 17:53 |
| desrt | too much travel in this month.... | 17:54 |
| hallyn | yes, oct/nov seems to be busy for everyone travel-wise | 17:54 |
| hallyn | but my goal is to just come to an agreement of how we can get to what we need - unprivileged containers running systemd in a way safe for the host. | 17:56 |
| === roadmr is now known as roadmr_afk | ||
| bdmurray | plars: https://code.launchpad.net/~brian-murray/ubuntu-test-cases/autoreport-check/+merge/233571 | 18:13 |
| plars | bdmurray: ok, we need to talk to slangasek about that one... I did have that in there before after our last discussion, and slangasek said it used to be needed but shouldn't be anymore, and having it there could hide problems | 18:14 |
| plars | bdmurray: actually this is slightly different, you're just checking for it, I was previously creating it | 18:14 |
| plars | bdmurray: so maybe you intend for this to be just a test case, rather than saying the test can't run unless something else sets up autoreporting? | 18:15 |
| slangasek | bdmurray, plars: I'm ok with this change, as the test will still fail and if it's failing due to the lack of this file it's better to explicitly report that problem | 18:16 |
| plars | ack | 18:16 |
| slangasek | plars: I guess we can have the philosophical argument about whether this is part of a test case for whoopsie vs. something else :) | 18:16 |
| plars | slangasek: I don't think that's necessary :) | 18:17 |
| plars | slangasek: it's a problem that affects whoopsie, nobody is suggesting that a failure here is necessarily caused by whoopsie | 18:17 |
| slangasek | bdmurray: are you adding this check because you're seeing /var/lib/apport/autoreport missing in practice? | 18:18 |
| bdmurray | slangasek: no, because the test is failing and we don't know why and it would if autoreport didn't exist. | 18:19 |
| slangasek | bdmurray: ok. FWIW in my own testing I had ruled this out as the cause of the failures | 18:20 |
| === roadmr_afk is now known as roadmr | ||
| === Guest86602 is now known as NCommander | ||
| === NCommander is now known as Guest6455 | ||
| === Guest6455 is now known as NCommander | ||
| bdmurray | slangasek: another issue is that the whoopsie-test.sh removes all _bin_sleep.0.* files in /var/crash/ so the .uploaded file can be removed before whoopsie-upload-all notices it so it can keep running until its timeout | 19:15 |
| bdmurray | the second it being whoopsie-upload-all | 19:15 |
| desrt | hallyn, stgraber: might it be possible to get an API on cgmanager to dump out all of the cgroups? | 19:32 |
| desrt | and/or one to let me find a cgroup by its basename? | 19:32 |
| desrt | ie: i put in session-1.scope and it tells me about user.slice/user-1000.slice/session-1.scope | 19:32 |
| desrt | because right now, this sort of sucks.... | 19:33 |
| desrt | also, in light of containers, my approach to this problem may actually be dangerous | 19:36 |
| hallyn | desrt: the code i'd proposed looks under user.slice/* for all children, and looks to see which one has session-1.scope | 19:36 |
| hallyn | bc we know that session-1.scope will be unique system-wide | 19:36 |
| desrt | right | 19:36 |
| desrt | except in case of containers.. | 19:36 |
| hallyn | ? | 19:36 |
| desrt | where one of the containers could have a nested session-1.scope | 19:36 |
| desrt | but that wouldn't be inside user.slice | 19:37 |
| hallyn | the container would talk to its own slice no? | 19:37 |
| hallyn | i mean its own shim | 19:37 |
| desrt | yes | 19:37 |
| desrt | but from the outside, we might find it by accident | 19:37 |
| hallyn | you mean with what you were proposing? | 19:37 |
| desrt | if we just naively looked for the first thing we find with the name "session-1.scope" | 19:37 |
| hallyn | right | 19:37 |
| desrt | i might have an even better idea, though | 19:37 |
| desrt | we can parse /run/systemd/sessions/1 to find out the user | 19:38 |
| desrt | it's ugly... but hey... this is systemd-shim, after all :) | 19:38 |
| hallyn | c1? | 19:38 |
| desrt | c1? | 19:38 |
| hallyn | seems ok to me | 19:39 |
| hallyn | on my ssystem it's /run/systemd/sessions/c1. oh, that's for console, i guess, | 19:39 |
| desrt | interesting. | 19:39 |
| desrt | do you also have a session-c1.scope, then? | 19:39 |
| mdeslaur | mvo_: I'm curious if there's been any progress on bug 1098738 | 19:39 |
| ubottu | bug 1098738 in apt (Ubuntu) "apt-get source only checks md5 hashes in Sources files" [High,In progress] https://launchpad.net/bugs/1098738 | 19:39 |
| hallyn | right when i ssh in i get a '15' in there | 19:39 |
| hallyn | yeah, session-c2.scope | 19:39 |
| hallyn | which actually would break my code i think | 19:40 |
| desrt | ya... | 19:40 |
| desrt | you need to stop using scanf :) | 19:40 |
| hallyn | or dbus | 19:40 |
| desrt | this is something like a red flag when i'm reading code | 19:40 |
| hallyn | nonsense | 19:40 |
| hallyn | i agree it shouldn't be used in glib code, but i couldn't find the glib thing to use | 19:40 |
| hallyn | i really meant for the mp to just be a (working) poc | 19:40 |
| desrt | hmm | 19:41 |
| desrt | seems that logind often changes what goes in this file | 19:41 |
| desrt | that's enough to make me think twice about using it | 19:41 |
| hallyn | it's probably also free to change the path layouts though | 19:41 |
| hallyn | you could keep /run/shim/scopes with all the info | 19:41 |
| desrt | that's not the worst idea i've ever heard.... | 19:41 |
| desrt | that's actually a pretty nice idea | 19:42 |
| desrt | really all we would need is a mapping of scope names to cgroup paths | 19:43 |
| desrt | so what happens, then? | 19:43 |
| desrt | logind Abandons the scope? | 19:43 |
| desrt | why not shut it down entirely? | 19:44 |
| hallyn | what do you mean? | 19:44 |
| hallyn | you mean why not use StopUnit? | 19:44 |
| desrt | yes | 19:44 |
| desrt | Abandon seems ... meaningless, really | 19:44 |
| hallyn | <shrug> screen and tmux? | 19:44 |
| desrt | ah. interesting. | 19:45 |
| hallyn | well, we set removeonempty so the cgroups will eventually go away | 19:45 |
| hallyn | i think abandon is there to recognize the design flaw :) | 19:45 |
| desrt | well, rather, i think screen/tmux are the ones with the design flaw :) | 19:45 |
| desrt | although they can't be blamed | 19:45 |
| desrt | probably in the future these things will need to be moved to a more robust system | 19:45 |
| hallyn | for that matter, on a fedora systemd system, is it set to use abandon? | 19:46 |
| desrt | no idea | 19:46 |
| hallyn | or is #KillUserProcesses=no something we add on | 19:46 |
| desrt | i guess so... | 19:46 |
| desrt | i never noticed problems with screen... | 19:46 |
| hallyn | well it's trivial for screen to be patched to move to another cgroup, of course. though it the needs privs | 19:47 |
| desrt | i was thinking rather that it would switch to some mechanism like dbus activation | 19:50 |
| hallyn | huh | 19:50 |
| desrt | the client would contact the service via dbus | 19:50 |
| desrt | which would start in a new cgroup | 19:50 |
| desrt | disconnected from the session... | 19:50 |
| desrt | it could even be considered a new login session, if you think about it | 19:50 |
| hallyn | still would require privilege - or help from logind/libpam - to create that new cgroup, but that's an interesting idea | 19:50 |
| hallyn | right | 19:51 |
| hallyn | that makes sense | 19:51 |
| desrt | once we have proper 'user' kdbus, it won't need any help | 19:51 |
| desrt | since processes launched this way are associated directly with the user -- not the session | 19:51 |
| hallyn | i guess i'll have to go watch the kdbus talk | 19:51 |
| desrt | more reasons to go to plumbers... | 19:51 |
| desrt | sigh | 19:51 |
| hallyn | hah - see you there :) | 19:51 |
| desrt | what did you mention was coming up in november, btw? | 19:51 |
| hallyn | hm, there's openstack early, then a sprint the server team needs to be at later | 19:52 |
| desrt | ah | 19:52 |
| hallyn | and lots of time off on my part | 19:52 |
| desrt | neither one that i should care about :) | 19:52 |
| * desrt goes back to beating on cgmanager | 19:53 | |
| desrt | btw: what is the problem with setting Remove at the start? | 19:54 |
| desrt | and just ignoring Abandon? | 19:54 |
| desrt | seems like this might be a massively easier approach to the issue | 19:57 |
| desrt | if people wanted us to kill, then of course we'd still need to handle StopUnit | 19:57 |
| desrt | but since that's turned off.... | 19:58 |
| * desrt wonders if he has fundamentally misunderstood something | 19:58 | |
| desrt | btw: your killtasks code is racy... | 19:59 |
| desrt | if a fork() goes between our list of the pids and the kill() command, you will leave some pids in the cgroup | 19:59 |
| desrt | hallyn: ^ ? | 20:03 |
| hallyn | desrt: so if you just do Remove, and there are active tasks in the cgroup, then the remove will fail, and the cgrou will never be removed | 20:08 |
| hallyn | i do removeonempty first, so that if it's not empty now but becomes empty while i'm working, it'll be deleted | 20:09 |
| hallyn | then i remove any subdirectories and then itself; if it's empty, that will remove it (and, in that case, autoremove would not, bc it only happens when it *becomes* empty) | 20:09 |
| desrt | right... that's what i mean | 20:09 |
| desrt | can we just remove-on-empty at the start? | 20:09 |
| desrt | and then ignore abandon? | 20:09 |
| hallyn | start of what? | 20:09 |
| desrt | this seems like a __much__ easier approach, and i can't imagine anything wrong with it | 20:10 |
| hallyn | sessoin create? | 20:10 |
| desrt | when we first create it | 20:10 |
| desrt | ya | 20:10 |
| hallyn | we did that before, and it *does* go wrong :) bc of upstart | 20:10 |
| desrt | why? | 20:10 |
| hallyn | upstart creates the same cgroup for pre-start, start, and post-stop | 20:10 |
| hallyn | so when pre-start is done, autoremove fires, | 20:10 |
| hallyn | then start tries to create the cgroup which already exists, | 20:10 |
| hallyn | then remove-onempty handler kicks in (kernel-run), | 20:10 |
| hallyn | cgroup is removed, now start tries to move the task into cgroup and fails | 20:11 |
| desrt | is there any way we could delay the autoremove call until after we know the session is fully logged-in? | 20:11 |
| desrt | ugh.. this is truly dreadful stuff :( | 20:12 |
| hallyn | we (systemd-shim) would have to know whose behalf we are working on | 20:12 |
| hallyn | i think what i had generally is ok - other than you're right i'm not working hard enough to kill everything | 20:12 |
| desrt | we can know that, but i'd prefer not to :) | 20:12 |
| hallyn | so yes we should loop over the killtasks until no tasks are left | 20:12 |
| desrt | so after we get Abandon... | 20:13 |
| hallyn | (and then fo rgood measure, if remove fails, re-try the kills I suppose) | 20:13 |
| desrt | do we know that nobody will ever make a call to this again? | 20:13 |
| desrt | (seems that cgmanager should have a kill-and-remove call) | 20:13 |
| hallyn | i think that makes sense for cgmanager | 20:14 |
| desrt | a recursive-autoremove might also be nice :) | 20:14 |
| hallyn | yeah. | 20:15 |
| hallyn | so maybe the thing to do is not fret too much over the code going into shim/src/cgmanager.c today, and then port those fns over to using the right cgmangaer call when available | 20:15 |
| hallyn | (we'll have to check the cgmanager api_version for the support :( ) | 20:15 |
| desrt | my primary concern now is about the stateful thing | 20:15 |
| desrt | nah -- we can just depend on the higher version | 20:16 |
| hallyn | right. so what's your thought on the /run/shim/sessions file? is ther ea downside? | 20:16 |
| desrt | there is absolutely no point in using the new API at all if we would have to keep the old code around | 20:16 |
| hallyn | ok | 20:16 |
| desrt | no downside as long as everything stays in sync | 20:16 |
| desrt | which i think it should | 20:16 |
| desrt | since these files represent units | 20:16 |
| desrt | not random cgroups | 20:17 |
| hallyn | well i've got two other fns to implement in cgmanager. since i don't have to spend monday working on longevity of systemd-shim, i can work on those monday :) | 20:17 |
| desrt | cool | 20:17 |
| desrt | i'll try to have something for you by then | 20:17 |
| desrt | but this is rapidly spinning into a not-done-by-today sort of task | 20:17 |
| desrt | might be able to find a bit of weekend time for it | 20:18 |
| hallyn | excellent. so meanwhile will you push just your earlier commit to pkg for slangasek ? | 20:18 |
| desrt | that's up to slangasek | 20:18 |
| * hallyn expects to lose power soon, storms... | 20:18 | |
| desrt | it's already in master... | 20:18 |
| desrt | and i don't maintain the debian package... | 20:18 |
| Noskcaj | Can someone please tell me why usb-modeswitch-data hasn't migrated to utopic? | 20:35 |
| infinity | mlankhorst: Along with that mesa 10.3 (when you're ready to upload), can you pull this patch? http://lists.freedesktop.org/archives/mesa-dev/2014-August/064711.html | 20:39 |
| hallyn | desrt: btw 'Prune' was listed as a low priority method to implement eventually in org.linuxcontainers.cgmanager.xml. (that's the recursive_rmdir) maybe that should take too booleans, 'kill' to say kill tasks, and 'recursive' to do recursive rmdir. | 20:48 |
| hallyn | stgraber: ^ any opinion on best methods from api point of view? | 20:48 |
| stgraber | hallyn: hmm, not sure it should be cgmanager's job to kill stuff though... recursive remove makes sense because the alternative is a crazy amount of queries to cgmanager, but kill, it's just getTasks + kill() so the clients can do it and can do it in a saner way (send sigterm, wait, send sigkill, ...) and if they want the cgroup to go away when they're done, they can set remove on empty | 21:00 |
| hallyn | stgraber: but to kill all tasks reliably you have to keep redoing the getTasks to make sure nothing forked | 21:08 |
| stgraber | hallyn: hmm, indeed | 21:08 |
| hallyn | and really, if you're going ot recursively remove-and-kill a cgroup, you'll still hae to getTasks in al lchild cgroups | 21:08 |
| hallyn | really the code doing that was pretty clean on the clien tside, | 21:09 |
| hallyn | and i have concerns about cgmanager being able to tell whether the calling task has the rights to kill | 21:09 |
| hallyn | in fact, there's no way for cgmangaer to be able to check whether the kill would be allowed by apparmor/yama/etc | 21:10 |
| stgraber | indeed, that'd completely bypass apparmor's signal filtering | 21:11 |
| hallyn | So I guess we can't do that. and if we can't do that, i'm not sure recursive rmdir makes much sense. | 21:12 |
| hallyn | well, it does, | 21:12 |
| hallyn | if it does removeon_empty recursively first, then remove recursively | 21:12 |
| slangasek | bdmurray: that's only a risk if a prior instance of whoopsie-test.sh has triggered, right? Anyway, doesn't this tie into my proposed apport branch for changing the semantics of the upstart job? | 21:15 |
| slangasek | desrt: which commits should I be looking at in master that fix our critical problem? | 21:16 |
| desrt | slangasek: none yet | 21:16 |
| slangasek | oh | 21:16 |
| desrt | you can take the patch from hallyn but i want to substantially rework it before taking it upstream | 21:16 |
| hallyn | the critical problem mterry was having? that's upstream right? | 21:17 |
| slangasek | I thought you said "it's already in master" - a different "it"? | 21:17 |
| desrt | i plan to do that over the weekend | 21:17 |
| desrt | slangasek: ah.. the mterry race problem is already upstream | 21:17 |
| bdmurray | slangasek: well if there was some other crash before starting the testing, but my change wouldn't help that. | 21:17 |
| desrt | i thought when you said "critical" earlier you were speaking of the Abandon thing | 21:17 |
| slangasek | bdmurray: I think the case for /bin/sleep crashing on its own is an ignorable corner case | 21:17 |
| slangasek | desrt: er, that is what I'm talking about | 21:17 |
| desrt | the Abandon thing is not ready | 21:18 |
| slangasek | ok | 21:18 |
| desrt | unless you want to take hallyn's patch | 21:18 |
| desrt | the race condition thing is fixed, though | 21:18 |
| slangasek | no, I was just trying to interpret the highlights in my scrollback :) | 21:18 |
| bdmurray | slangasek: I mean any crash would cause whoopsie-upload-all to run. | 21:18 |
| desrt | i mean... in a certain sense, everything is great... because we have a patch for the one problem and as of today we discovered the cause of and patched the other | 21:18 |
| slangasek | bdmurray: ok - true, but if I'm not misremembering, my apport branch changes the job so that it will trigger for each new file | 21:19 |
| bdmurray | slangasek: okay, I haven't looked at it in a bit | 21:19 |
| slangasek | bdmurray: this problem you describe is certainly precisely one of the things I was trying to fix, I just don't remember now what I concluded about the right way to fix it :) | 21:20 |
| bdmurray | slangasek: well you should revisit the branch then ;-) | 21:21 |
| slangasek | yes, it's on my todo for this afternoon... :) | 21:22 |
| slangasek | the other thing was, ev raised it to my attention this morning that whoopsie+apport disagree about inotify and file modes | 21:23 |
| slangasek | which I need to read scrollback to understand, but is possibly an argument for my approach to atomic file replacements in spite of pitti's objection | 21:23 |
| cjwatson | Noskcaj: makes usb-modeswitch uninstallable | 21:24 |
| mvo_ | mdeslaur: yes, the fix is in experimental, it breaks ABI unfortunately | 21:24 |
| Noskcaj | ok | 21:24 |
| mvo_ | mdeslaur: it will be in with the next abi break in ubuntu | 21:25 |
| cjwatson | Noskcaj: because Breaks: usb-modeswitch (<< 2.2.0) | 21:25 |
| cjwatson | (and usb-modeswitch Depends: usb-modeswitch-data, of course) | 21:25 |
| cyphermox | Noskcaj, cjwatson, I will be fixing usb-modeswitch either tonight or this weekend | 21:35 |
| Noskcaj | :) | 21:35 |
| cyphermox | that is, unless someone beats me to it, but I don't wish it on anyone :-) | 21:35 |
| cyphermox | Noskcaj is it breaking something for you? | 21:37 |
| cyphermox | It's always useful to have some help with testing, I don't have the new Huawei devices that need the new code | 21:37 |
| Noskcaj | cyphermox, I was just looking at the email to ubuntu-devel, and not looking at the control file for -data before i asked here | 21:37 |
| cyphermox | OK. It is kind of broken how it is, perhaps the new data should not break things, and instead usb-modeswitch could (and does, I think) ignore the bits it doesn't understand and still do almost the right thing | 21:40 |
| Saviq | so, who's a make guru? say I have targets like foo1-bar1, foo2-bar1, foo2-bar2 etc., can I make a single rule to make those, with foo? and bar? being available as variables in that rule? | 22:00 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
