| hallyn | desrt: they're like the NSA, they track you | 00:13 |
|---|---|---|
| desrt | ya... i get the general gist of the thing... but i have no idea why it has to be so complicated | 00:13 |
| desrt | with different cgroups for all different things plus this pseudofs to track it all... | 00:14 |
| stgraber | hallyn: you mean enabled == 0 right? the paste you gave me shows num_cgroups == 1 for all of them | 00:38 |
| hallyn | yeah | 00:42 |
| hallyn | desrt: ack | 02:05 |
| hallyn | stgraber: http://paste.ubuntu.com/7778221/ if a package installs real init and upstart scripts, upstart will DTRT and ignore the sysv scripts, rigth? (seems to be working here) I usually see sysvinit *wrapper*s cripts and had expected the package to only install the upstart scripts... | 02:13 |
| hallyn | but I guess qemu-system-x86 also has a real sysv script, so must be ok | 02:13 |
| hallyn | anyway i'm thinking of pushing that to utopic so if you see any problems with that pls shout | 02:13 |
| desrt | hallyn: one more big btw: g_error() terminates the calling process :) | 02:14 |
| desrt | it's quite strange to see free() calls after this :) | 02:15 |
| === ikonia is now known as Guest70019 | ||
| === kgunn is now known as Guest2511 | ||
| === hyperair is now known as Guest84654 | ||
| === neunon is now known as Guest28427 | ||
| stgraber | hallyn: yes, it'll do the right thing | 02:26 |
| hallyn | cool, thx, will probabablyh push to utopic tonight then | 02:32 |
| hallyn | desrt: wtf? g_critical terminating the process makes sense. g_error? it's just an error... so waht's the recommended way to just log something? | 02:33 |
| hallyn | all tests still pass both on host and in container. pushing | 02:43 |
| === _salem is now known as salem_ | ||
| desrt | hallyn: g_warning | 02:44 |
| desrt | hallyn: btw... UserUnit has slice_path (char*), which it passes to cgmanager_create_all, which is expecting a ScopeUnit* | 02:45 |
| hallyn | desrt: i could be mixing the terms up in my head, but i swear when i looked at a gnome page this morning it said g_critical and g_warning could both end the program | 02:45 |
| desrt | that's obviously not right... but it's also not clear what is the correct thing to do here | 02:46 |
| desrt | hallyn: they can, but typically don't | 02:46 |
| hallyn | hm, that sounds like something i fixed this morning | 02:46 |
| desrt | you can set G_DEBUG=fatal-criticals or fatal-warnings | 02:46 |
| hallyn | (the ScopeUnit pasing) | 02:46 |
| * hallyn checks | 02:46 | |
| desrt | but in general: g_error > g_critical > g_warning > g_message > d_debug | 02:47 |
| desrt | g_error = fatal, always | 02:47 |
| desrt | g_critical = you made a programmer error and it's somewhat likely that your internal state was compromised | 02:47 |
| desrt | g_warning = something bad happened, but it may not have been the programmer's fault | 02:47 |
| hallyn | desrt: oh, the .h file doesnt' match the .c, that's all :) | 02:47 |
| desrt | g_message = fyi | 02:47 |
| hallyn | i had updated cgmanager.c and scope-unit.c | 02:47 |
| desrt | hallyn: awesome... | 02:47 |
| hallyn | i wont' fix it now since i assume you ahve a buttload of other fixes | 02:48 |
| desrt | scope-unit has the wrong code, though.... | 02:48 |
| hallyn | and wouldnt' want to merge those | 02:48 |
| hallyn | why? | 02:48 |
| hallyn | cgmanager_create_all(pu); | 02:48 |
| desrt | sorry... user-unit | 02:48 |
| desrt | my eyes are starting to cross from the scope/service/slice terms :) | 02:48 |
| hallyn | oh. feh. | 02:48 |
| desrt | most importantly: what pids would i pass here? | 02:49 |
| desrt | none? | 02:49 |
| hallyn | in cgmanager_create_all? | 02:49 |
| desrt | yes | 02:49 |
| desrt | this API looks a bit different now... | 02:49 |
| hallyn | the pids which we pulled out of the StartTransientUnit msg, i.e. what logind sent us | 02:49 |
| hallyn | came as a a(sv) where v was a ai | 02:50 |
| hallyn | uh, au | 02:50 |
| hallyn | each u is a pid to be moved; but again there's only ever 1 afaict | 02:50 |
| desrt | okay | 02:50 |
| desrt | so the properties handling should be done for both types of units, then | 02:50 |
| desrt | right now you're only doing it for the one... | 02:51 |
| hallyn | regarding naming - blah i completely agree, i was trying ot make sense of the names being used by systemd, but still don't fully understand | 02:51 |
| hallyn | i guess a scope limits all of a user's sessions; | 02:51 |
| hallyn | a session describes a sesssion, and there' sa slice for each session; a service is i think something that doesn't make sense for non-systemd to do | 02:51 |
| hallyn | right, i'm doing it for the one pid | 02:51 |
| hallyn | so, the user-unit proably should just do something different, or nothing at all | 02:52 |
| hallyn | it depends on whether a scope will soemtimes come with a slice; if so, then we'll need another function in cgmanager.c to create the cgroups for it (and pass it the UserUnit) | 02:53 |
| desrt | fwiw, here's how things are shaping up: http://ur1.ca/hq27o | 02:54 |
| desrt | i'm not exactly sure how you want the error handling to look here.... | 02:54 |
| desrt | like, if we fail to move one pid, do we fail the entire operation? | 02:54 |
| desrt | do we try to do back-out? | 02:54 |
| desrt | or do we just assume that the rest will be OK and continue? | 02:54 |
| hallyn | i think we log and continue | 02:55 |
| hallyn | then at least user has a chance to see that something went wrong | 02:55 |
| desrt | k. that's what i'm doing. | 02:55 |
| desrt | it also speeds things up: we can issue all the async calls pipelined | 02:55 |
| desrt | no need to wait for the replies | 02:55 |
| hallyn | cool | 02:56 |
| hallyn | where are you intending to open the connection to cgmanager? around each create_all/remove_all? | 02:57 |
| desrt | no. only once ever. | 02:57 |
| hallyn | (actually we should probably just drop remove_all) | 02:57 |
| desrt | i store it in a static | 02:57 |
| hallyn | if cgmanger restarts, will the connection auto-reestablish? | 02:57 |
| desrt | see the (buggy) 'initialised' code | 02:57 |
| desrt | no. | 02:57 |
| desrt | that can probably be fixed | 02:58 |
| desrt | but it raises an interesting question: what if we try to connect to it for the first time while it is mid-restart? | 02:58 |
| hallyn | oh, i see now, i glossed over the _call before | 02:58 |
| desrt | should we keep trying each time we get a new request and spam on g_warning() each time? | 02:58 |
| desrt | the idea that this thing could restart under us is slightly horrifying.... | 02:59 |
| * desrt <- hates races, no matter how theoretical | 02:59 | |
| hallyn | true. if it were going to stick aroudn longer term we might consider re-exec upstart-style | 02:59 |
| hallyn | but i do hope cgmanger becomes a relic soon. meaning systemd starts to offer what we need. | 03:00 |
| desrt | well the good news is that systemd-shim auto-exits... | 03:00 |
| hallyn | oh, to answer, yeah; i thin krestart and spam warnings | 03:00 |
| hallyn | nothing wrong with spam warnings, if bad things are in fact happening | 03:00 |
| hallyn | auto-exits? | 03:00 |
| desrt | ya | 03:00 |
| desrt | after a period of inactivity | 03:00 |
| desrt | it's stateless | 03:01 |
| desrt | so why hang around? | 03:01 |
| hallyn | oh, good. and how the heck does it get started! | 03:01 |
| desrt | dbus activation | 03:01 |
| hallyn | i think you mean, magic | 03:01 |
| desrt | :) | 03:01 |
| desrt | dbus activation is really very nice.... arguably the best part about dbus, in fact | 03:01 |
| desrt | you just send a message to the service... | 03:01 |
| desrt | if it's there... great | 03:01 |
| desrt | if not -- it will be :) | 03:01 |
| desrt | and it's all race-free | 03:02 |
| sarnold | ahhh, memories of inetd <3 | 03:02 |
| desrt | ya. more or less... | 03:02 |
| hallyn | you say race-free, | 03:02 |
| desrt | well, actually | 03:02 |
| desrt | there's one teensy tiny race | 03:02 |
| desrt | but i'm the only one who ever noticed it..... | 03:02 |
| desrt | and nobody else seems to care | 03:02 |
| hallyn | i say 'threading with nih-dbus seems to break' | 03:02 |
| desrt | but it is fixed with kdbus, at least | 03:03 |
| desrt | libdus-1 is a single-thread library as far as i'm concerned... | 03:03 |
| desrt | there are some nominal attempts at thread safety inside of it, but they didn't make it far enough .... and no real testing | 03:03 |
| hallyn | yeah, i read some of the history on it :( | 03:04 |
| desrt | gdbus on the other hand is a multithread monster | 03:04 |
| desrt | this is some seriously awesome example of how to handle threading properly | 03:04 |
| desrt | ....and the trouble that you can get naive programmers into when you do so | 03:04 |
| desrt | turns out because of it's "threads are awesome" approach, there are some things that 'just work' in dbus-1 that are much harder in gdbus :( | 03:04 |
| desrt | classic example is registering object paths after successfully acquiring a bus name | 03:05 |
| desrt | in dbus-1 world this is perfectly logical, and there is no race: you don't return to the mainloop to process the incoming message queue until after the object is already registered from the same thread | 03:06 |
| desrt | in gdbus you have trouble: another thread is already processing the incoming messages before you have a chance to register your objects | 03:06 |
| desrt | sometimes stupid is better...... | 03:06 |
| hallyn | complexity is complex | 03:07 |
| * hallyn wonders how long until we're talkign about capabilities, esp since sarnold is around | 03:07 | |
| desrt | linux style "capabilities" are evil :( | 03:08 |
| hallyn | itym POSIX :) | 03:08 |
| desrt | nope | 03:09 |
| desrt | fortunately, there was never agreement about this stuff at POSIX | 03:09 |
| sarnold | itym posix-draft :) | 03:09 |
| desrt | (not for lack of trying....) | 03:09 |
| hallyn | eh | 03:09 |
| hallyn | well, as maintainer of capabilitiesin the kernel, when something appropriate comes along i'll ack the patch removing posix caps :) | 03:09 |
| hallyn | we'll see when that happens | 03:09 |
| desrt | give me seccomp or give me death :) | 03:09 |
| hallyn | peopel are always trying. but the alternative is always worse | 03:10 |
| * hallyn points to lxc WE GOT SECCOMP :) | 03:10 | |
| * desrt <3 capsicum | 03:10 | |
| hallyn | ah, but it attaches capabilities to fds :) | 03:10 |
| hallyn | but yes i'm attracted to capsicum | 03:10 |
| desrt | i wonder if you've seen memfd ;) | 03:10 |
| sarnold | hallyn: man who did you upset to get stuck with maintaining caps in the kernel? :) | 03:10 |
| hallyn | sarnold: amorgan | 03:11 |
| desrt | we have these new things called "seals" that you can apply to fds now, via fcntl | 03:11 |
| desrt | introduce a few more seals, mix in some seccomp, and we more or less have capsicum :) | 03:11 |
| hallyn | yeah there are presentations coming on capsicum in linux, i'm hopeful | 03:12 |
| desrt | that would be such a win | 03:12 |
| hallyn | well, we'll see whether people end up able to use them properly. but again i'm hopeful | 03:12 |
| === Ursinha is now known as Ursinha-afk | ||
| hallyn | slangasek: ok so i just pushed a new cgmanager (_0.26-0ubuntu6) to utopic which has the sysvinit scripts so should be usable for debian. There is an existing ITP with an old version by dba with very different packaging. Is there a protocol for, i dunno, replacing/updating the ITP with the utopic version or something close to it, for jessie? | 03:16 |
| slangasek | hallyn: the protocol is that you ask me to upload it; ITPs are advisory locks only | 03:19 |
| desrt | hallyn: so did that file look OK to you? | 03:20 |
| desrt | fwiw, i'm having trouble telling the difference between scope unit and user unit if they both take the same transient parameters | 03:21 |
| desrt | seems that they only used a different scheme for cooking up the path.... | 03:21 |
| desrt | /user/%d.user/c%d.session vs. /user/%d.user | 03:22 |
| desrt | which raises another question: can we create the session one without having first created the user one? | 03:22 |
| === Ursinha-afk is now known as Ursinha | ||
| hallyn | slangasek: oh - in that case i'll do a bunch more testing and get back to you thx :) | 03:24 |
| hallyn | desrt: so yes, we *can* (and do bc of the bug you found in the user_scope) create teh session one without the user one, | 03:25 |
| desrt | what happens if we come along and create the other one later? | 03:25 |
| hallyn | desrt: and since we currently don't do actual cgroup configuration, it'll be no different for now; | 03:25 |
| desrt | retroactive containment? | 03:25 |
| hallyn | nothing; it' sjust an mkdir in the cgroupfs returning EEXIST | 03:26 |
| hallyn | but i think it's possible for the /usr/%d.user one to have some basic containment, | 03:26 |
| hallyn | which all sessions shoudl be subject to. | 03:26 |
| hallyn | so at some point we'll want to have both properly handled; | 03:26 |
| hallyn | but i've mainly looked at the session code so i'm guessing; lemme look at the logind code for the user scopes | 03:27 |
| hallyn | that is, the /user/%d.user cgroups | 03:27 |
| hallyn | ok, i dont' see any code in systemd doing anything like it though | 03:29 |
| hallyn | desrt: so if you wanted to just remove the user-unit.c altogether (for now) it might be just as well | 03:32 |
| desrt | well | 03:32 |
| hallyn | if systemd/logind every does slice configuration of /usr/%d.user then we can add it | 03:32 |
| desrt | i think that maybe we should have a new type of cgroup unit or something | 03:32 |
| desrt | since these two different types are really very similar | 03:32 |
| desrt | the only annoying bit is the way the Slice property is handled... | 03:33 |
| hallyn | really i'm in no way attached to how i structured any of it - it fell out from how i discovered what the logidn protocol was doing | 03:33 |
| hallyn | what's wrong with how the Slice property is handled? | 03:34 |
| === salem_ is now known as _salem | ||
| hallyn | slangasek: all right if we're going for itp then perhaps a new upstream cgmanager release is in order | 03:44 |
| slangasek | as you wish :) | 03:45 |
| * desrt tries sleep for a bit | 03:56 | |
| desrt | hopefully i will be better equipped to figure out some better way of dealing with *.scope and *.slice without special cases in the morning :) | 03:57 |
| pitti | Good morning | 04:17 |
| pitti | bdmurray: yes, I'll have a look | 04:17 |
| pitti | bdmurray: MP> cool, thanks! | 04:20 |
| pitti | stgraber: hm, that lxc autopkgtest regression looks "real" (deluser: The user `usernic-user' does not exist.), but the same version succeeded before | 04:29 |
| pitti | stgraber: could that be due to the new cgmanager? | 04:29 |
| pitti | (that's at least what britney is holding back) | 04:30 |
| pitti | ah, cgmanager itself is failing, too | 04:30 |
| hallyn | cgmanager tests are passing for me locally; where is it failing? also 'deluser usernic-user' should only happen at end of tests, after we've purposely created it... | 04:32 |
| pitti | hallyn: you shold have gotten a mail about it, didn't you? | 04:32 |
| pitti | https://jenkins.qa.ubuntu.com/job/utopic-adt-cgmanager/25/ARCH=i386,label=adt/console | 04:32 |
| pitti | test 14 failed | 04:33 |
| pitti | it's not very verbose why it fails unfortunately | 04:33 |
| hallyn | pitti: do those tests not get run in ppas? | 04:34 |
| pitti | hallyn: we have one or two manual autopkgtest jobs for PPAs (firefox), but not in general, no | 04:35 |
| hallyn | pitti: can you re-fire the tests somehow? | 04:36 |
| pitti | hallyn: yes, I can, if that was a transient failure | 04:36 |
| pitti | hallyn: running | 04:37 |
| hallyn | i'm hoping - bc liek i say i can't reproduce locally. i coudl also just push the 0.27-0ubuntu1 version (which is basically identical and i was going to push anyway)... | 04:37 |
| hallyn | i'm testing both on vm and in container in same vm... | 04:37 |
| pitti | I also restarted LXC, just to confirm | 04:37 |
| hallyn | i did at one point notice a weird error msg (an hour or two ago) about apport failing to upgrade, bad sysvinit script; | 04:38 |
| hallyn | pitti: i'm still afraid i may have done something bad with the sysvinit scripts for cgmanager... would you mind taking a quick look at debian/*init and debian/rules (which i did not chnage) in the failed cgmanager version? | 04:40 |
| hallyn | oh, here: | 04:40 |
| hallyn | update-rc.d: warning: default stop runlevel arguments (0 1 6) do not match apport Default-Stop values (none) | 04:40 |
| pitti | err, apport? curious | 04:41 |
| hallyn | oh, is that complaining about the upstart.vs.sysvinit stop values? | 04:41 |
| hallyn | it's stop on runlevel [!2345] in upstart, no stop values in sysv | 04:42 |
| pitti | hallyn: no, that's usually a complaint that your init.d LSB header has different stop levels than the update-rc.d call in postinst | 04:43 |
| hallyn | oh | 04:43 |
| pitti | hallyn: which init.d script is that? | 04:43 |
| hallyn | /etc/init.d/apport ? | 04:43 |
| pitti | hallyn: ah, I thought we are still talking about cgmanager (as you wanted me to have a look there) | 04:44 |
| hallyn | heh, sorry. yeah it's just coincidence | 04:44 |
| hallyn | well i suppose it caught my eye bc it came up while i was tryign out the cgmanager sysvinit script patch | 04:45 |
| pitti | hallyn: right, thanks; I'll fix that | 04:45 |
| hallyn | cool | 04:45 |
| pitti | (it's just a warning though) | 04:46 |
| pitti | hallyn: cgmanager failed again | 04:46 |
| hallyn | hm. and lxc? | 04:48 |
| pitti | still running | 04:48 |
| pitti | FAIL: lxc-tests: /usr/bin/lxc-test-unpriv | 04:48 |
| pitti | --- | 04:48 |
| pitti | /usr/sbin/deluser: The user `lxcunpriv' does not exist. | 04:48 |
| pitti | hallyn: but it's already past that, so will fail again | 04:48 |
| pitti | so, same error | 04:49 |
| pitti | that doesn't sound like cgmanager, but it also doesn't look like a flaky test | 04:49 |
| hallyn | what is the testbed here? | 04:49 |
| pitti | but there's a lot of stuff in -proposed | 04:49 |
| hallyn | runs in a container? | 04:49 |
| pitti | hallyn: QEMU | 04:49 |
| pitti | (http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test) | 04:50 |
| * pitti runs cgmanager locally | 04:51 | |
| * hallyn sets up an environment | 04:52 | |
| hallyn | bah - 'booting vm to run cloud-init' :) | 04:54 |
| pitti | hallyn: well, yes -- anything wrong with that? | 04:54 |
| pitti | these VMs use the cloud images, so they might as well use its setup machinery | 04:54 |
| hallyn | pitti: only that they're not using lxc for the basic setup :) i'm on a rather slow temp laptop | 04:55 |
| pitti | hallyn: oh, you can of course also run them in LXC | 04:55 |
| hallyn | yeah but i don't want any delta from what's ahppening in archive | 04:56 |
| hallyn | so i'll take the hit | 04:56 |
| pitti | hallyn: so it succeeded locally here | 04:56 |
| hallyn | with proposed enabled? | 04:56 |
| pitti | the test 14 doesn't say what it failed on, so hard to say | 04:56 |
| pitti | yes | 04:56 |
| hallyn | hm. | 04:57 |
| pitti | adt-run --apt-pocket=proposed -U cgmanager --- qemu /home/martin-scratch/adt-utopic-amd64-cloud.img | 04:57 |
| hallyn | well i coudl push a version with more verbosity in test 14 | 04:57 |
| hallyn | could the base test image be bad on the tester? | 04:57 |
| pitti | so this could be dependent on system load, or time zone, or whatever | 04:57 |
| hallyn | system load is plausible | 04:57 |
| pitti | hallyn: it's working fairly well for other tests, and it failed the same way 4 times now (on different machines) | 04:58 |
| hallyn | but do those machines use shared (ceph) storage to store the canonical image? | 04:58 |
| pitti | no, it's just a normal local ext4 | 04:59 |
| hallyn | well scratch that idea then | 04:59 |
| pitti | hallyn: do you have VPN set up? | 04:59 |
| hallyn | no | 04:59 |
| hallyn | halp - the OS a chance to collect more entropy! (Need 187 more bytes) | 05:00 |
| pitti | hm, we install haveged into the VMs, where do you see this? | 05:01 |
| hallyn | running adt-run on my laptop | 05:01 |
| hallyn | finally got past it | 05:01 |
| pitti | oh, for adt-run key creation | 05:01 |
| pitti | I should fix that to only run if you want to run local binaries | 05:02 |
| hallyn | hm, fails on | 05:12 |
| hallyn | Errors were encountered while processing: rsync | 05:12 |
| pitti | hallyn: sorry, missed your reply; rsync where? on package install? | 05:29 |
| hallyn | right, during setup i guess | 05:32 |
| hallyn | i was doing adt-run --apt-pocket=proposed -U cgmanager --- qemu ~/adt-utopic-amd64-cloud.img | 05:32 |
| hallyn | pitti: so it never got to actual cgmanager test running | 05:32 |
| pitti | i. e. the rsync package failed to install? (do you have a log?) | 05:32 |
| pitti | that worked here | 05:33 |
| pitti | hallyn: so if you tell me how to squeeze more info out of test14, I'm happy to run it on the CI machine | 05:34 |
| pitti | (set -x or something?) | 05:34 |
| hallyn | pitti: no, sorry i killed the term | 05:34 |
| hallyn | pitti: oh i was just going to add some echos to show which 'exit 1' was happening | 05:34 |
| pitti | or that; set -x is quite nice for tests which don't use shunit or something else with verbose failures | 05:35 |
| hallyn | i've got a hunch that it's exiting bc Remove xxx is succeeding when xxx/b exists, and it shouldn't | 05:35 |
| hallyn | except if that happens there it hsould happen for us | 05:35 |
| hallyn | pitti: there's not some weird environment where the test run with -e right? (exiting on command failure?) | 05:35 |
| pitti | hallyn: your test script determines that | 05:36 |
| hallyn | pitti: ok my test script doesnt' set it | 05:36 |
| pitti | hallyn: i. e. if it's doing set -e or #!/bin/sh -e | 05:36 |
| pitti | TBH I consider set -e pretty much a must for every shell script | 05:36 |
| pitti | hallyn: but anyway, if your debian/tests/foo doesn't use it, it won't be implied from anywhere; there's on magic /bin/sh in the testbed | 05:37 |
| pitti | hallyn: so if your autopkgtest has allow-stderr, it's probably simplest to just add set -x | 05:37 |
| hallyn | pitti: yeah if you can run with -x that'd be great | 05:37 |
| hallyn | allow-stderr? dunno stgraber hooked that up, | 05:38 |
| * hallyn checks | 05:38 | |
| hallyn | yeah it's set | 05:38 |
| pitti | hallyn: oh, debian/tests/exercise does have set -eu | 05:39 |
| pitti | so it's well behaved | 05:39 |
| pitti | hallyn: so runtests.sh is indeed run under dash and -e | 05:39 |
| pitti | as debian/tests/exercise sources it, not execute | 05:39 |
| hallyn | pitti: oh. well then i don't see how it ever passed. bc it does things like | 05:40 |
| hallyn | cmd \n if [ $? -eq 0 ]; then fail; fi | 05:40 |
| pitti | hallyn: hm, I don't think we are looking at the same script | 05:41 |
| pitti | grep eq tests/runtests.sh -> no hit | 05:41 |
| pitti | oh, that's running test/*.sh | 05:41 |
| hallyn | dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.Remove string:'memory' string:"xxx" int32:0 > /dev/null 2>&1 | 05:41 |
| hallyn | if [ $? -eq 0 ]; then exit 1 | 05:41 |
| pitti | hallyn: right, ok; so runtests.sh runs with set -e, but it execs tests/test*.sh which don't | 05:41 |
| hallyn | oh, ok | 05:42 |
| hallyn | phew. not that running with -e woudl bother me, but i just wouldn't have understood hwo it ever passed before | 05:42 |
| hallyn | so if you could just run with -x maybe we can figure it out | 05:42 |
| hallyn | though i'm about to head to bed | 05:42 |
| pitti | hallyn: yes, doing now | 05:43 |
| pitti | hallyn: I can mail you the output | 05:43 |
| pitti | hallyn: I'll reply to the jenkins failure mail | 05:44 |
| hallyn | pitti: thanks! | 05:46 |
| pitti | hallyn: sent | 05:55 |
| hallyn | pitti: just reproduced it on jessie container. looks like it's a real bug | 05:58 |
| hallyn | but i don't undestand it. well, hopefully tomorrow - gnight | 05:59 |
| hallyn | oh ffs. no. NO! ti stopped reproducing. this is ridiculous | 06:00 |
| === doko_ is now known as doko | ||
| pitti | hallyn: could perhaps be because the DC is running trusty's qemu? | 06:25 |
| FourDollars | Hi, who is willing to sponsor my patch for https://bugs.launchpad.net/gnome-desktop/+bug/1340544? | 06:49 |
| ubottu | Ubuntu bug 1340544 in gnome-desktop3 (Ubuntu) "gnome-rr: The minimum brightness can not be 0." [Undecided,New] | 06:49 |
| doko | seb128, Laney: do you know http://www.infinality.net/blog/infinality-freetype-patches/ ? | 07:09 |
| seb128 | doko, no, why? | 07:10 |
| seb128 | doko, but slangasek is the freetype maintainer | 07:10 |
| doko | heh | 07:10 |
| Whoopie | pitti: Hi, thanks for applying my patch for LP 1299975? Can you also sponsor the upload to trusty? | 07:39 |
| ubottu | Launchpad bug 1299975 in pm-utils (Ubuntu Trusty) "wireless script checks wrong sys file" [Undecided,Fix committed] https://launchpad.net/bugs/1299975 | 07:39 |
| Whoopie | pitti: sorry, found it in https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text= | 07:41 |
| Whoopie | pitti: Thanks!!! | 07:41 |
| Saviq | xnox, hey, should a Architecture: all package have Multi-Arch: foreign? like suru-icon-theme? | 07:43 |
| pitti | Whoopie: yw; mvo sponsored it to trusty yesterday | 07:59 |
| xnox | Saviq: yes, see e.g. ttf-ubuntu-font-family | 08:38 |
| xnox | Saviq: there is an open dpkg feature request to treat transitive arch:all packages as m-a:foreign but there are concerns if that's actually always correct to do. | 08:39 |
| Saviq | xnox, mhm, got it | 08:39 |
| Saviq | xnox, can you please have a look at https://code.launchpad.net/~saviq/ubuntu-themes/fix-multiarch/+merge/226418 | 08:46 |
| xnox | Saviq: i wonder if I should try silo release that straight away. | 08:48 |
| Saviq | xnox, you mean bypassing silos? be my guest | 08:48 |
| xnox | Saviq: nah, as in me assigning the silo and doing it. | 08:49 |
| Saviq | xnox, yeah lets | 08:49 |
| Saviq | ' | 08:49 |
| Saviq | xnox, lemme add a line | 08:49 |
| Saviq | ugh if only gdocs wouldn't log me out all the time | 08:50 |
| seb128 | Saviq, wait | 08:50 |
| Saviq | oupf | 08:50 |
| * Saviq waiting | 08:51 | |
| seb128 | Saviq, if you do a themes landing, we might want to include some bugfixes ... can you give me some minutes to check that? | 08:51 |
| Saviq | seb128, sure | 08:51 |
| seb128 | Saviq, or do you prefer to do separate landings? | 08:51 |
| Saviq | seb128, is fine | 08:51 |
| Saviq | seb128, lemme know | 08:51 |
| xnox | seb128: i'd prefer separate. It's a packaging change only, which unblocks cross-building. | 08:51 |
| xnox | seb128: no theme changes at all, thus not blocked on testing that =) | 08:51 |
| Saviq | should be a quick one, too | 08:52 |
| Saviq | you guys decide :) | 08:52 |
| seb128 | xnox, it's not like theme bugfixes need lot of testing | 08:52 |
| seb128 | xnox, that's gtk themes, so desktop only | 08:52 |
| xnox | seb128: hm, there are a bunch approved. It's not desktop only, there are suru icons as well. | 08:53 |
| seb128 | xnox, we don't need to list them all | 08:53 |
| xnox | ~mhr3/ubuntu-themes/fix-suru-inheritance looks simple | 08:54 |
| Saviq | and we should land it, yeah | 08:54 |
| seb128 | that would be nice to get yes | 08:54 |
| xnox | ~sil2100/ubuntu-themes/osk_design_icon_association_change | 08:55 |
| xnox | looks sensible as well (needs osk testing) | 08:55 |
| seb128 | https://code.launchpad.net/~larsu/ubuntu-themes/three-twelve/+merge/225982 | 08:55 |
| seb128 | would be nice to get as well | 08:55 |
| xnox | ~larsu/ubuntu-themes/three-twelve | 08:56 |
| xnox | yeap. | 08:56 |
| * xnox goes to adjust the landing line | 08:56 | |
| seb128 | thanks | 08:56 |
| Saviq | how about https://code.launchpad.net/~tiheum/ubuntu-themes/suru-icons/+merge/226325 ? | 08:57 |
| Saviq | well, it's waiting for Jouni's ACK, so let's maybe let it wait... | 08:58 |
| xnox | seb128: Saviq: huh, i don't have powers to change spreadsheet.... but have acls to assign silos. | 08:58 |
| cjwatson | We're pretty low on silos right now | 08:58 |
| Saviq | xnox, are you logged in? google logs me out all the time recently | 08:58 |
| xnox | Saviq: I can't review ~tiheum branch above. I'd wait on it. | 08:59 |
| Saviq | yeah | 08:59 |
| xnox | cjwatson: did notice, only one was free. probably best to wait for a few to clear out. | 08:59 |
| seb128 | Saviq, xnox: I added the inherit and the gtk 3.12 ones ... anything else? | 09:00 |
| Saviq | seb128, looks fine to me | 09:01 |
| didrocks | xnox: granted | 09:01 |
| * didrocks shares ownership at the same time | 09:01 | |
| didrocks | sil2100: you owne the spreadsheet now, congrats! | 09:02 |
| didrocks | (we can only have one owner) | 09:02 |
| xnox | seb128: tweaked tests and description | 09:03 |
| sil2100 | didrocks: uh oh, I do?! | 09:03 |
| sil2100 | didrocks: thank you ;p? | 09:03 |
| xnox | didrocks: only one owner -> webscale bus factor =) | 09:03 |
| didrocks | sil2100: yw | 09:03 |
| didrocks | xnox: isn't it? ;) | 09:03 |
| xnox | didrocks: i'm lovin it! | 09:04 |
| didrocks | I guess the domain owner can reclaim ownership though | 09:04 |
| didrocks | well, at least, I hope :) | 09:04 |
| seb128 | xnox, thanks | 09:04 |
| didrocks | other you fork it and create a "new new spreadsheet" | 09:04 |
| didrocks | sil2100: btw, reminder that I guess you can rename the spreadsheet now to remove the new :) | 09:04 |
| xnox | didrocks: yeah, i'd think so too. I think on my googleapps as an admin i can revoke an app permission and thus transfer ownership of everything elsewhere. | 09:05 |
| didrocks | I think nobody is using the old dead one | 09:05 |
| xnox | didrocks: and then reactivate app for that user. | 09:05 |
| didrocks | yeah, would make sense | 09:05 |
| Laney | my awesomebar still remembers the old one | 09:05 |
| Laney | and I reinforce that by always picking it first :( | 09:05 |
| * didrocks looks if we can delete the old one | 09:05 | |
| didrocks | one sec | 09:05 |
| Laney | been trying to go to wiki/citrain lately | 09:06 |
| didrocks | Laney: nuked | 09:07 |
| Laney | nice | 09:07 |
| * xnox thinks there is something wrong with libtool | 09:55 | |
| xnox | current=3, age=1, revision=0 yet soname 2.1.0 | 09:55 |
| pitti | current-age == 2 | 09:56 |
| pitti | xnox: don't try to think about these numbers too hard; it'll melt your brain | 09:56 |
| xnox | pitti: yes, yes, i remember that now. | 09:57 |
| xnox | pitti: so upstream broke abi but didn't bump the numbers. | 09:57 |
| pitti | I think the resulting version number is (current-age).age.revision or so | 09:57 |
| * xnox runs git log -p on configure.ac to verify | 09:57 | |
| pitti | xnox: ordinarily that's done in Makefile.am | 09:58 |
| pitti | xnox: grep for -version-info | 09:58 |
| pitti | (and yay for not using GNU option syntax, but meh) | 09:58 |
| xnox | pitti: well, in their case, they use variables in -version-info which are set in configure.ac as constants. | 09:58 |
| pitti | xnox: ah ok, osrry | 09:58 |
| xnox | pitti: last abi bump was by slangasek .... who is not upstream, so yeah upstream have no clue. | 09:58 |
| xnox | seems weird -> i should bump current by one and reset age to 0 | 10:11 |
| xnox | but that makes it jump from 2.1.0 to 4.0.0 | 10:11 |
| pitti | I had a nice page which explained all that the other day, but apparently I lost the bookmark | 10:11 |
| xnox | well, last time steve bumped both current and age by +1 | 10:12 |
| xnox | i'll do the same here. | 10:12 |
| pitti | xnox: https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html | 10:12 |
| pitti | xnox: I thought you'd just set age to 0 on changed/removed API? | 10:13 |
| pitti | but meh, this might be wrong too; I wish libtool wasn't trying to be "helpful" and let one just specify the soname :) | 10:14 |
| xnox | seems odd though. If interfaces are added, then next time age is bumped (4.0.0 -> 3.1.0), then one more adds happen (3.1.0 -> 2.1.0) ?! | 10:16 |
| xnox | ah, no, cause current will have to be bumped as well. | 10:16 |
| xnox | nevermind me. | 10:16 |
| xnox | pitti: any advice as to which abi version number to use between upstream fixing it and me packaging it? | 10:49 |
| * xnox tries to use 2a | 10:49 | |
| xnox | libtool hates that. | 10:50 |
| rbasak | Is https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/1340294 an actual problem? It means that binaries linked against libsdl in the archive will actually be under the terms of the GPL, but that would still be DFSG-free, right? | 11:05 |
| ubottu | Ubuntu bug 1340294 in libsdl1.2 (Ubuntu) "Library linking leads to incompatible licenses." [Undecided,New] | 11:05 |
| * rbasak doesn't see an actual incompatibility here | 11:06 | |
| xnox | rbasak: the problem is, that everything that links libsdl1.2 now needs to be GPL compatible, instead of just LGPL. It's the same bug that prevented migration to e.g. the new gnutls. | 11:13 |
| xnox | rbasak: e.g. anything that links to openssl, cannot also link to libsdl1.2 anymore, since transitively GPL code would be linked to OpenSSL which are incompatible. | 11:14 |
| === MacSlow is now known as MacSlow|lunch | ||
| xnox | previously that was not a problem. (i'm assuming there is no openssl exception in libcaca) | 11:14 |
| xnox | s/libcaca/libslang/ | 11:15 |
| smb | hallyn, It does not seem like anybody wants to be helpful on bug 1321365. Would you think that this version of libvirt could go into updates anyway? Then my follow up might be accepted into trusty-proposed... | 11:22 |
| ubottu | bug 1321365 in libvirt (Ubuntu Trusty) " virsh (ppc) fails with "missing /proc/device-tree/cpu "" [Critical,Fix committed] https://launchpad.net/bugs/1321365 | 11:22 |
| debfx | imho that bug should be moved to libcaca which can disable the slang backend. | 11:22 |
| === MacSlow|lunch is now known as MacSlow | ||
| === Guest70019 is now known as ikonia | ||
| pitti | xnox: I don't even know which package you talk about :) | 11:38 |
| xnox | pitti: plymouth made an upstream release 0.9.0 | 11:38 |
| xnox | pitti: debian doesn't package shared libraries, but we do. Cause casper and mountall use them. | 11:39 |
| pitti | xnox: oh, I was about to ask whether we can at least coordinate that with debian | 11:39 |
| xnox | pitti: the APIs they use, have not changed, but others have been removed. And upstream forgot to bump abis. | 11:39 |
| pitti | xnox: so if it only affects ubuntu, then I guess the shlib name doesn't matter, so appending an 'a' sounds fine to me | 11:39 |
| pitti | xnox: do we use any of the removed API? | 11:40 |
| xnox | pitti: do you know any past examples where that was done? | 11:40 |
| xnox | pitti: no, we do not use any of the removed APIs | 11:40 |
| pitti | xnox: I don't remember; we usually avoid changing soname downstream at all costs | 11:40 |
| pitti | we rather just ported stuff and added strict dependencies | 11:40 |
| MacSlow | anybody seen something like this with recent updates pulled on utopic -> https://bugs.launchpad.net/ubuntu/+bug/1340710 | 12:17 |
| ubottu | Ubuntu bug 1340710 in Ubuntu "/var/log/kern.log gets spammed with rfkill messages" [Undecided,New] | 12:17 |
| xnox | cyphermox_: ^ | 12:27 |
| === _salem is now known as salem_ | ||
| === psivaa is now known as psivaa-lunch | ||
| cyphermox_ | xnox: thanks | 13:08 |
| stgraber | hallyn: allow-stderr was probably a copy/paste from lxc where we have harmless messages going to stderr | 13:23 |
| stgraber | pitti: the deluser message would indicate that the test failed before it created the user. We have a cleanup hook which attempts to kill the test container, remove the user, ... so I suspect that error message comes from the cleanup hook and is a sign of a problem earlier on | 13:25 |
| pitti | stgraber: ah, thanks | 13:33 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === psivaa-lunch is now known as psivaa | ||
| hallyn | BenC: hi, you do ppc stuff right? would you be able to (have someone) verify the fix for bug 1321365 ? Othewise as smb said we should probably just promote anyway | 14:19 |
| ubottu | bug 1321365 in libvirt (Ubuntu Trusty) " virsh (ppc) fails with "missing /proc/device-tree/cpu "" [Critical,Fix committed] https://launchpad.net/bugs/1321365 | 14:19 |
| BenC | hallyn: Already verified | 14:20 |
| hallyn | BenC: oh! could you set the verificatin-done tag? | 14:21 |
| hallyn | pitti: why would trusty | 14:21 |
| hallyn | trusty's qemu be the problem? | 14:21 |
| pitti | hallyn: no particular reason, it's just one obvious difference to running locally | 14:21 |
| BenC | hallyn: How do I add that tag? | 14:22 |
| hallyn | oh. no, this laptop here is trusty too. (my utopic one is the one that died) | 14:22 |
| pitti | hallyn: another is that in the CI lab there is a pretty heavy network firewalling | 14:22 |
| hallyn | BenC: at bottom of description is the lsit of tags - edit it to change verification-needed to verification-done | 14:22 |
| pitti | hallyn: ah, good; I sent you the set -x output, but I suppose you'll need some more logs | 14:22 |
| hallyn | or just make a note in the bug and i'll change it | 14:22 |
| pitti | hallyn: nothign in dmesg btw (not sure whether I wrote that) | 14:23 |
| BenC | hallyn: Done | 14:23 |
| hallyn | pitti: like i say i had a 30 sec window where i could reproduce it on my fast precise(+utopic kernel) host in a jessie container... so there' sdefinately *something* real to it | 14:23 |
| hallyn | BenC: thanks! | 14:23 |
| BenC | hallyn: And thank you | 14:23 |
| pitti | hallyn: ah, so it is a race condition of some sort, which is just very persistant on that machine | 14:25 |
| pitti | hallyn: FYI, these machines are pretty beefy (gazillion CPUs and GB of RAM), and the overlay runs on tmpfs | 14:25 |
| desrt | hallyn: hey... tearing down cgroups won't work | 14:28 |
| desrt | hallyn: due to the transient nature of the shim we can't "remember" the slice that a particular unit was located within | 14:29 |
| desrt | so for the /user/%d.user/c%d.session case we'll have forgotten the uid by the time the Stop call comes | 14:29 |
| desrt | and we will not be able to instruct cgmanager on which group to remove | 14:29 |
| hallyn | desrt: that's ok, we set autoremove ont he cgroups | 14:31 |
| hallyn | desrt: so they'll go away when the user logs out automatically | 14:31 |
| desrt | that logic seems a bit backwards | 14:31 |
| hallyn | at least, it worked on my tests | 14:31 |
| desrt | isn't the point of all of this cgroup stuff to allow systemd to forcably clean up a user session on logout? | 14:31 |
| * hallyn grumbles something he problably shouldn't ... | 14:32 | |
| hallyn | desrt: we're not yet handling the StopUnit are we? | 14:33 |
| desrt | i just checked.... systemctl stop session-37.scope for example kills all the processes in that scope | 14:33 |
| desrt | hallyn: no... we're not, and i think that maybe we can't :/ | 14:33 |
| hallyn | desrt: won't the dbus message for StopUnit list the both the session and slice? | 14:33 |
| desrt | no | 14:33 |
| hallyn | then how would systemd itself know? | 14:34 |
| desrt | it lists the session but the slice was given to the StartTransient only | 14:34 |
| desrt | systemd doesn't get restarted..... | 14:34 |
| hallyn | but session-2.scope is ambiguous | 14:34 |
| desrt | no. systemd is stateful. | 14:34 |
| desrt | it remembers what session-2.scope is | 14:34 |
| desrt | (and more importantly, where it is) | 14:34 |
| hallyn | uids 1000 and 2000 can both have session-2.scope | 14:34 |
| desrt | no... that's not possible | 14:34 |
| desrt | sessions are unique | 14:34 |
| hallyn | huh | 14:35 |
| desrt | by that token i guess we could spider the cgroups tree looking for the matching one | 14:35 |
| hallyn | well, there are ways to fix that (keep state somewhere) and I would claim that's somethign to worry about later | 14:35 |
| desrt | but ... yick | 14:35 |
| hallyn | if at all | 14:35 |
| desrt | so don't worry about stop? | 14:35 |
| hallyn | right - or rather, punt on stop for now | 14:35 |
| desrt | okay. you're the boss :) | 14:35 |
| hallyn | desrt: systemd may claims that "killing all tasks on logout" is the main feature, | 14:36 |
| hallyn | desrt: but the main feature for me is granting delegated cgroups for the user to use | 14:36 |
| hallyn | for unprivileged container use | 14:36 |
| desrt | this is why we chown... | 14:36 |
| hallyn | right | 14:36 |
| desrt | okay | 14:36 |
| desrt | so the code is shrinking :) | 14:36 |
| hallyn | desrt: love it :) | 14:37 |
| hallyn | desrt: feh, right you are. I really thought that the sessoins were per-user unique only | 14:37 |
| hallyn | of course that means we can more easily fix this if/when we want, | 14:37 |
| desrt | right -- we can walk the cgroup tree :/ | 14:38 |
| hallyn | or keep state in /var/run <shrug> if that doesnt' make you cry | 14:41 |
| desrt | i'd prefer to just use the state already in the kernel rather than make a copy of it | 14:42 |
| desrt | worth noting that also logind already does this... | 14:42 |
| hallyn | doesn't bother me :) | 14:42 |
| desrt | if you cat /run/systemd/sessions/1 for example you see UID=1000 in there | 14:43 |
| hallyn | pitti: oh your email clarifies what I missed last night - it's not failing the way i thought | 14:43 |
| hallyn | it | 14:43 |
| desrt | not sure if we can rely on that at the point that logind is already trying to tear the session down, though | 14:43 |
| hallyn | desrt: does logind walk the tasks list and kill them all? or does it now expect systemd-dbus to do it? | 14:44 |
| hallyn | pitti: i thought it was failing when it did 'rmdir xxx' (non-recursively) when xxx/b exists (which should fail). but it's actually failing on the recursive rmdir. that's more hopeful for being sane | 14:44 |
| desrt | hallyn: systemd does it, pretty sure | 14:45 |
| hallyn | k | 14:46 |
| desrt | hallyn: so our cgroup hierarchy is different from the systemd one, i guess? | 15:02 |
| desrt | we seem to call it like user/1000.user/42.session | 15:03 |
| hallyn | yes, we do. what does systemd do? | 15:03 |
| desrt | instead of user/user-1000.slice/session-42.scope ? | 15:03 |
| desrt | systemd names the cgroups after the requested names | 15:03 |
| hallyn | i'm just sticking with the terms stgraber had used in the earlier logind patches | 15:03 |
| hallyn | desrt: maybe systemd changed that after v204? | 15:04 |
| desrt | maybe? | 15:04 |
| hallyn | stgraber: ^ done on purpose? | 15:05 |
| hallyn | (I don't really care either way) | 15:05 |
| desrt | extracting the uid out of the unit name is ... interesting | 15:05 |
| desrt | because it's impure from the standpoint of what is happening here | 15:05 |
| desrt | i guess systemd doesn't do this :) | 15:05 |
| slangasek | doko: my position on the infinality patches is that freetype behavior changes give me enough problems without me diverging from mainline :) | 15:05 |
| desrt | unless it has some similar magic | 15:06 |
| desrt | hallyn: can you remind me again what the issue was about the JobRemoved business? | 15:28 |
| hallyn | stgraber: to be absolutely sure, the jenkins autotest runs are all done in their own private qemu, right? not in lxc? | 15:28 |
| desrt | and also what this get_state() thing is about? | 15:28 |
| desrt | you seem to try to pass "static" into a (o) parameter... which is not good :( | 15:28 |
| hallyn | desrt: I had no idea what get_state was :) I didn't add it | 15:28 |
| hallyn | I just cut-pasted from other units for that, | 15:29 |
| desrt | g_dbus_method_invocation_return_value (invocation, g_variant_new ("(o)", unit_get_state(unit))); <- you added this | 15:29 |
| hallyn | oh yeah. I wasn't sure if I should return the path of the cgroup to systemd or not | 15:29 |
| desrt | definitely not | 15:29 |
| hallyn | and never got around to reconsidering. | 15:29 |
| hallyn | ok | 15:29 |
| desrt | it may not be a valid dbus object path | 15:29 |
| hallyn | so systemd doesn't care? | 15:29 |
| desrt | in fact, certainly isn't... | 15:29 |
| hallyn | ok | 15:29 |
| desrt | since you can't have '-' in those | 15:29 |
| hallyn | always passing | 15:30 |
| hallyn | '/' just seemed weird | 15:30 |
| hallyn | (i'm missing a key so i keep accidentally hitting enter :( ) | 15:30 |
| desrt | it is :) | 15:30 |
| hallyn | desrt: what do you mean by JobRemoved business? | 15:30 |
| desrt | you conditionalise it not to run for 'user' units | 15:31 |
| desrt | slices, i guess? | 15:31 |
| hallyn | oh, yeah - what would it mean to remove that job? | 15:31 |
| desrt | i dunno | 15:31 |
| desrt | i think we added this code for the power units, as i mentioned... | 15:31 |
| hallyn | I was afraid it would mean systmed would log you out. | 15:31 |
| hallyn | I.e. it woudl see it as the slice beign removed | 15:32 |
| desrt | no idea :) | 15:32 |
| desrt | i guess we should only do this for power units, to be honest | 15:32 |
| hallyn | right, you did that to not re-suspend right? | 15:32 |
| desrt | although i think JobRemoved might actually mean "the process of starting this thing is now done" | 15:32 |
| * desrt checks that theory | 15:33 | |
| desrt | yup. it's true | 15:33 |
| desrt | /org/freedesktop/systemd1: org.freedesktop.systemd1.Manager.JobNew (uint32 14405, objectpath '/org/freedesktop/systemd1/job/14405', 'abc.slice') | 15:34 |
| desrt | /org/freedesktop/systemd1: org.freedesktop.systemd1.Manager.JobRemoved (uint32 14405, objectpath '/org/freedesktop/systemd1/job/14405', 'abc.slice', 'done') | 15:34 |
| hallyn | oh then it hsouldn't be conditional :) | 15:34 |
| desrt | maybe we should try harder to make up some decent-looking job names :) | 15:34 |
| hallyn | what are you showing there? | 15:34 |
| desrt | this is what real systemd says in response to me creating abc.slice | 15:34 |
| hallyn | oh | 15:34 |
| desrt | (gdbus monitor --system --dest org.freedesktop.systemd1) | 15:34 |
| cyphermox_ | pitti: hey, I'm asking you because you're apparently the last who touched acpi-support. is there a reason to still keep this? | 15:43 |
| stokachu | @pilot in | 15:44 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stokachu | ||
| === lisca is now known as zmoknute_lisca | ||
| desrt | hallyn: hey... trying to test this stuff now | 15:53 |
| desrt | where do i get the updated cgmanager? | 15:53 |
| * desrt needs to start moving toward the airport soonish.... | 15:56 | |
| hallyn | desrt: utopic-proposed | 16:01 |
| hallyn | or ppa:serge-hallyn/virt has it too | 16:01 |
| desrt | hmm | 16:04 |
| desrt | i have proposed | 16:04 |
| hallyn | you have 0.26-0ubuntu6? | 16:06 |
| hallyn | that should suffice | 16:06 |
| desrt | yes | 16:07 |
| desrt | hm. problem seems to be with my code ;) | 16:07 |
| * desrt was treating api_version as unsigned (not signed) int | 16:09 | |
| desrt | so... it's not creating the cgroups i ask for | 16:12 |
| desrt | or i am misunderstanding something | 16:12 |
| hallyn | if cat /proc/self/cgroups doesn't show your /user/$uid.user/c-$session.session, then it's not working :( | 16:20 |
| hallyn | desrt: you can put "cgmanager_opts="--debug"" in /etc/default/cgmanager and look in /var/log/upstart/cgmanager.log to see if it's getting requests at all | 16:21 |
| * hallyn changing locale for a mtg, bbiab | 16:21 | |
| desrt | hallyn: i'm getting a failure of MovePid | 16:28 |
| desrt | MovePid: Client fd is: 6 (pid=4054, uid=0, gid=0) | 16:29 |
| desrt | cgmanager:per_ctrl_move_pid_main: victim's cgroup is not under proxy's (p.uid 0) | 16:29 |
| stgraber | hallyn: correct | 16:30 |
| desrt | hallyn: in any case, i've pushed https://github.com/desrt/systemd-shim/tree/cgm.1 | 16:32 |
| desrt | i think it's mostly right... please take a look | 16:32 |
| desrt | it doesn't currently attempt to deal with cgmanager restarts | 16:33 |
| === timrc-afk is now known as timrc | ||
| hallyn | desrt: thanks, i plan to look in 1.5 hrs | 16:46 |
| desrt | hallyn: i probably won't get too much more of a chance to look at this | 16:46 |
| desrt | but i think any required fixes should be relatively minor at this point | 16:46 |
| hallyn | desrt: ok, i'll hack on it until it works, | 16:46 |
| hallyn | desrt: you're gone next week? | 16:46 |
| desrt | ya | 16:46 |
| desrt | i guess you guys can carry a patch until i return? | 16:46 |
| hallyn | desrt: hwo shoudl we proceed - should i take wahtever works and try to push to unstable? | 16:47 |
| desrt | alternatively, you could deal with pitti | 16:47 |
| hallyn | ah, ok, i'll ask pitti for guidance - thanks desrt ! | 16:47 |
| desrt | he knows his way around dbus/gobject and he has commit access to systemd-shim | 16:47 |
| desrt | pitti: might be nice if you review my code anyway.... i wrote it in a hurry :p | 16:49 |
| === roaksoax is now known as roaksoax_bbl | ||
| === ev_ is now known as ev | ||
| === kees_ is now known as kees | ||
| === luv_ is now known as luv | ||
| === tlyu_ is now known as tlyu | ||
| === ken_ is now known as kenvandine | ||
| === tarpman_ is now known as tarpman | ||
| === roadmr is now known as roadmr_afk | ||
| === zmoknute_lisca is now known as lisca | ||
| === roadmr_afk is now known as roadmr | ||
| === lisca is now known as klubko | ||
| hallyn | desrt: you're probably gone; but i'm using yoru s ystemd-shim and it seems to be working | 20:32 |
| hallyn | d'oh | 20:33 |
| hallyn | nm. i'm an idiot | 20:33 |
| hallyn | didn't built jessie's systemd on this box (thought i'd done that) | 20:33 |
| hallyn | stgraber: https://jenkins.qa.ubuntu.com/job/utopic-adt-cgmanager/29/ARCH=amd64,label=adt/console fascinating. apparently readdir(/run/cgmanager/memory/xxx) is not listing /run/cgmanager/memory/xxx/bbb, which does exist... i don't know if this is a new cgfs race, or what. guess i'll add a sleep in the testcase and see | 20:54 |
| stgraber | weird | 20:56 |
| hallyn | actually no a sleep won't help, | 20:56 |
| hallyn | bc the testcase already does a | 20:56 |
| hallyn | + dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.ListChildren string:memory string:xxx | 20:56 |
| hallyn | + grep -q bbb | 20:56 |
| hallyn | after the Create, so obviously the fs is settled by now | 20:56 |
| === cmagina_ is now known as cmagina | ||
| desrt | hallyn: at the airport | 21:27 |
| desrt | hallyn: got a bit of time if there's anything you need to tell me :) | 21:27 |
| hallyn | desrt: nah, unfortunately i'd forgotten to save away the systemd-208 changes i had to make to use it with the new shim; so i'm having to re-create those ona new test vm | 21:29 |
| desrt | OK | 21:30 |
| desrt | good luck :) | 21:30 |
| hallyn | thanks - have a good vacation! | 21:30 |
| hallyn | or trip or whatever it is :) | 21:30 |
| desrt | this crazy thing: http://ses.ikso.net/2014/sk/ | 21:31 |
| hallyn | wow | 21:34 |
| desrt | ya.... in retrospect, i'm not entirely sure why i'm doing it... | 21:37 |
| hallyn | desrt: exactly how did you test the shim? did you send your own dbus messages, or use logind? | 21:42 |
| desrt | sent my own messages | 21:43 |
| desrt | everything seemed to work except that MovePid gave that error i mentioned earlier | 21:43 |
| hallyn | dbus-send? | 21:43 |
| desrt | gdbus... | 21:43 |
| hallyn | did you run it as root? | 21:44 |
| desrt | yes | 21:44 |
| hallyn | ok. | 21:44 |
| desrt | is there some weird authentication step i need to take? | 21:47 |
| desrt | or does cgmanager know that i am root? | 21:48 |
| hallyn | it knows | 21:50 |
| hallyn | desrt: ok, took some finagling of logind (the packaging for systemd-208 will need work) and there was a several-seconds hang, but i *did* get cgroups, | 21:59 |
| hallyn | 6:devices:/user.slice/user-1000.slice/session-7.scope | 21:59 |
| === salem_ is now known as _salem | ||
| desrt | hallyn: did the MovePid work? | 22:07 |
| hallyn | desrt: yup | 22:07 |
| desrt | oh. nice. | 22:07 |
| desrt | all good then, i guess | 22:08 |
| hallyn | stgraber: https://jenkins.qa.ubuntu.com/job/utopic-adt-cgmanager/30/ARCH=amd64,label=adt/console oh, so it looks like there is a race so that after we rmdir xxx/bbb, xxx cant' be immediately freed. kernel bug it seems like. | 22:08 |
| hallyn | i'm afraid i'm out for the weekend - back sunday night hopefully - \o | 22:08 |
| desrt | hallyn: have a good one | 22:08 |
| hallyn | apw: ^ i may end up bugging you about the kernel bug | 22:08 |
| hallyn | desrt: you too :) | 22:08 |
| hallyn | apw: (assuming it is a kernel bug) | 22:09 |
| === slangase` is now known as slangasek | ||
| === pbn_ is now known as pbn | ||
| Saviq | Laney, FYI, welcome wizard is totally b0rked in the latest system-settings release :| | 22:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!