[00:08] desrt: hey - do you know of any other sample code that would show how to deconstruct a dbus msg as gvariant which has a(sv)? I don't seem able to pull it off successfully, and most tutorials seem to stick to 'as' [00:08] (i'm trying with http://paste.ubuntu.com/7772700/ ) [00:10] * hallyn suspects desrt is in a currently-asleep tz :) [02:35] hallyn: a(sv) or a{sv}? [02:58] desrt: a(sv) [02:58] weird! [02:58] what is this? [02:58] like, what data is in there? [02:58] one does not typically see the a(sv) type.... [02:59] desrt: it's the StartTransientUnit from systemd. Each element of the array has s for the description, then v is just an s with the value [02:59] seemed rather silly to me, suppose it's meant to be future-proof [02:59] typically you use a{sv} unless you really care about the order [03:00] which is difficult to imagine in this situation... [03:00] anyway... did you figure it out? [03:00] "" [03:00] nope [03:00] i mean i get a valid list, but the n_elements is always 0 [03:00] so what do you have there? [03:01] you're implementing this inside the shim? [03:01] yeah [03:01] http://paste.ubuntu.com/7773201/ [03:01] so you have name mode properties aux [03:01] that's the chunk i'm using right now [03:02] so typically you whack out all the parameters at once [03:02] something like so: [03:02] const gchar *name, *mode; GVariantIter *properties, *aux; [03:02] g_variant_get (parameters, "(&s&sa(sv)a(s(a(sv)))", &name, &mode, &properties, &aux); [03:03] then properties will be an iter? [03:03] yes [03:03] while (g_variant_iter_loop(iter, "(s@v)", &str1, &v)) { [03:03] this is weird [03:03] i dumped aux actually bc systemd in 208 wasn't yet sendin git [03:03] if you do that then the "v" will contain a value of type 'v' [03:03] you want only to have "(sv)" or even better "(&sv)" with a const gchar *str1 [03:04] ok i'll try that, thx. (stuff going on so will take a few mins) [03:06] g_variant_iter_n_children() yuck [03:06] i can't believe i let chpe convince me into adding that API :p [03:06] i guess it helps in your case, at least... [03:07] introspection ftw :) [03:08] will i still need to use g_variant_iter_free? i assume so [03:09] yes [03:10] it's not possible to use stack-allocated iter here because something needs to keep alive the value that you are iterating over [03:10] which was itself only extracted from the parent [03:10] desrt: yay, i get contents, thanks! [03:16] desrt: and, yay, it has the info i need to connect the TransientUnit to the owner, so i should be able to do the proper cgroup config (tomorrow :) [03:38] hallyn: i'll probably take a look over the dbus-specific parts of this patch and may clean them up a bit [03:38] just make sure the cgroup stuff is solid... i don't know a thing about it, and i don't want to start learning :) [03:41] desrt: I get to the point where my nonexistant cgroup code says: cgmanager_create_all: called for /user/1000.user/c11.session [03:41] \o/ [03:42] btw: i'm going on vacation pretty much immediately after work on friday... i'll be gone for a week [03:42] desrt: so yeah, i'll hook in cgmanager code (which uses nih-dbus, boy thsi will be a beautiful frankenstein :), then toss you a git tree so you can sob at waht i've done and fix up the glib dbus parts :) [03:42] desrt: oh, hm. well i'll try to get this done tomorrowmorning - at least enough for you to look at the glib-dbus part [03:43] sure thing... otherwise, i guess no big deal if it takes an extra week? [03:43] desrt: well debian-devel is crying already, so it may be a big deeal to them :) [03:43] okay [03:43] what's your TZ, btw? [03:43] desrt: so yeah i'll toss you a git tree in the morning (in about 14 hours) [03:44] US central [03:44] its' 22:45 here [03:44] cool. toronto time here. [03:44] oh! i thought you were in nl for some reason [03:44] nope [03:44] although toronto and amsterdam have a bit in common :) [03:45] oh? [03:45] not something i'd ever heard [03:45] ya... just similar feel [03:45] ultra-progressive, etc [03:45] nice - i only ever went into nl as a kid when we went shopping there (from be). i need to go spend some time there [03:46] anyway! tty i nthe morning, thx again for your help [03:46] sleep well [04:11] desrt: well, i went ahead and pushed it to github.com/hallyn/systemd-shim #cgm.1 [04:11] * hallyn out [05:03] Good morning === NCommand` is now known as NCommander === NCommander is now known as Guest2749 === Guest2749 is now known as NCommander [05:26] infinity: did you happen to see the glibc autopkgtest failure? It fails to build on "../include/stap-probe.h:24:22: fatal error: sys/sdt.h: No such file or directory" [05:26] infinity: obviously that didn't happen on the real buildds, do you have an idea why that could be? [05:33] pitti: Debian bug #748694? [05:33] Debian bug 748694 in systemtap "sys/sdt.h is architecture specific, and causing issues on unsupported architectures" [Serious,Fixed] http://bugs.debian.org/748694 [05:36] slangasek: ah, thanks; we don't seem to have that in Ubuntu yet (at least not in the changelog) [05:36] https://launchpad.net/ubuntu/+source/systemtap/2.3-2ubuntu1 sounds related though [05:37] but isn't, glibc just failed again [05:42] pitti: It's entirely possible the 'fixes' broke glibc's build. I can look tomorrow. [05:42] oh, that way around [05:42] infinity: thanks; not urgent, I was just wondering why it fails on this build but not the other [05:42] infinity: it counts as "always failed" now, so doesn't block anything [05:43] (due to the package rename) [05:43] pitti: Oh, ugh. Yeah, we should get it fixed at least once so it stops behaving that way. [05:43] pitti: I'll look tomorrow after I knock off a few more urgent items. [05:54] pitti: Test build started now, so I have something to play with in the morning. [05:55] * infinity says, as it fails 5 seconds in... [05:57] pitti: Oh, failure is obvious. [06:05] pitti: Fix testbuilding, will upload in the morning if it's all good here. [07:01] good morning === Mirv_ is now known as Mirv [08:42] @pilot in === 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: mvo_ === Eisbrecher_xnox is now known as xnox === doko_ is now known as doko [09:49] mlankhorst, Has libxi had it's breaks long enough that we can sync again? [09:52] Noskcaj: sure, it was just needed until the lts === Zic is now known as Guest96198 === psivaa-off is now known as psivaa === MacSlow is now known as MacSlow|lunch === Guest96198 is now known as Zic === ara is now known as Guest56630 === apachelogger is now known as octopus === octopus is now known as apachelogger === MacSlow|lunch is now known as MacSlow === pete-woods is now known as pete-woods_lunch === _salem is now known as salem_ === pete-woods_lunch is now known as ptet-woods [12:51] pitti: could you please apply http://paste.ubuntu.com/7775018/ to the pm-utils git repo its a trivial typo? reference is bug 1299975 [12:51] bug 1299975 in pm-utils (Ubuntu) "wireless script checks wrong sys file" [Undecided,Confirmed] https://launchpad.net/bugs/1299975 [12:53] mvo_: will apply in Debian; I don't have upstream commit [12:53] pitti: ok, there is a debdiff in the bug if thats easier [12:53] right, that's the one I'm looking at [12:53] pitti: ok, I will do a trusty SRU for that then and we get utopic via the next debian sync :) [12:54] mvo_: thanks! [12:55] pitti: thank you! I assume forwarding this to upstream via their bts make sense (I assume they are responsive)? [12:55] mvo_: no, it's been dead upstream for ages, so don't bother [12:55] pitti: ok, good to know [12:55] mvo_: I think mbiebl_ has commit rights, but he can also pick them from the debian package [12:55] mvo_: I'll add a DEP-3 header [12:56] pitti: \o/ thanks! [12:56] * mvo_ writes the test case etc stuff in the meantime [12:58] mvo_: I'll do a Debian upload now, so that it'll be fixed in utopic soon [12:59] hallyn: why the conditionals? [12:59] (in configure) [13:01] mvo_: (done) [13:01] thanks pitti [13:16] wow! MoM seems broken again [13:17] cjwatson, ;) [13:17] sil2100, did you see upstream for lucene? they fixed the gtest stuff [13:17] I asked for a new release [13:23] LocutusOfBorg1: sigh. hopefully fixed [13:26] desrt: yeah i was undecided on that. at first i was going to not have them and make it depend on cgmanager [13:26] i suppose i should do it that way [13:27] bc also supporting cgfs would be very complicating and not nearly as safe [13:28] cjwatson, thanks as usual :) [13:28] I would like to do some merge, can I send to somebody the debdiffs instead of opening a bug, wait for somebody and so on? [13:29] like gccxml, gambas3, wxwidg [13:29] they are all trivial to sync [13:29] s/sync/merge [13:29] curl [13:31] wxwidgets3.0 can't be synced so I'm not sure I believe you :) [13:31] Nor can gccxml [13:32] Oh, merges, right, don't have time for that right now sorry ... [13:32] Reviewing merges is generally harder work than just doing them [13:33] LocutusOfBorg1: You should always talk to the person who uploaded the package last in the first instance, anyway; please don't just steal other people's merges [13:36] cjwatson, I mean wx2.8 [13:36] not 3.0 [13:37] and s/sync/merge [13:37] cjwatson, ok [13:37] just sometimes is bad to see ubuntu so much behind debian [13:37] I hope to see merges done when freeze approaches :) [13:38] I will offer my help again at that time :D [13:38] LocutusOfBorg1: Like I say, help may be welcome but please talk to the people who touched it last rather than just firing diffs at people [13:38] LocutusOfBorg1: Sometimes they're working on it, or sometimes there's a reason not to move forward that you're not aware of [13:39] yes of course [13:39] Or sometimes it's just not important :) [13:39] I'm wondering about some programs like gambas [13:39] the rebuild against llvm 3.2 in debian failed on all archs because of a cmake problem [13:40] why the ubuntu rebuild did not fail? llvm 3.4 is in ubuntu since trusty [13:40] s/3.2/3.4 [13:40] anyway not a problem :) [13:53] xnox: what is your opinion about lp:~zctgbhu/plymouth/bug-1339954 ? it seems for Chinese we need a better font than the current dejavu and the suggested fonts-droid would add 4.4mb uncompressed into the initrd [13:56] xnox: is lp:~ubuntu-mate-dev/ubiquity/ubiquity-marco sane enough for merging to our ubiquity? [14:15] slangasek: stgraber: infinity: do i recall correctly y'all said the tp x240 kbd sucks? === timrc is now known as timrc-afk [14:17] popey: need to test and merge. Can't remember if it's safe to set keys which are not universal in all flavours. [14:17] hallyn: I'm not so concerned by the keyboard as it's mostly similar to the x230 except for the lack of an insert key. The one with the terrible keyboard is the X1 carbon. [14:17] hallyn: the main problem I've got with the x240 is the very low amount of RAM and no possible upgrade there. You either get 4GB or 8GB, that's it. [14:17] stgraber: ah, ok. x240 has much longer batt life and is slightly cheaper, so it's catching my eye right now [14:17] mvo_: i'd rather include it conditionally. We are including ubuntu font i think, is that pretty in chinese or not? [14:17] (though i do like thinness. i'm vain) [14:18] i'm used to netbooks, so 8G will suffice if i' not spending too much [14:18] hallyn: so far, the least sucky haswell range thinkpad I'm aware of is the t440s which is a bit bigger (14" instead of 12.6") but comes with a keyboard with an insert key and has one so-dimm slot so you can upgrade it to 12GB if you want to. [14:18] but that display resolution! [14:19] hm, yeah. i *do* need an insert key [14:19] t440. will look, thx [14:19] hallyn: also, the x240 isn't so cheap once you switch to a reasonable screen, IIRC the low price is with the 1366x768 non-IPS display. It's an extra $150 for 1366x768 IPS or an extra $300 for 1920x1080 IPS display. [14:19] waht is that like 12lb? [14:20] t440 also has the low-res though. sad [14:20] t440s is around 3.5lbs I believe, surprisingly light when I was checking out wgrant's at the last sprint [14:21] hallyn: note, there's a big difference in quality between the t440 and t440s, so make sure you look at the latter [14:21] wgrant: any experience to tell me whether t440 screen is reasonable outdoors? [14:21] stgraber: ok [14:22] hallyn: also, when offered, take the IPS screen option, otherwise you get a TN display and those usually look bad. If the IPS is similar to that on my x230, you can read it fine outside, it's pretty bright. [14:22] 3 cell battery? is that a joke? [14:22] ev_, bdmurray: do you still remember why ubuntu-bug needs to check /etc/apport/autoreport and exec whoopsie-upload-all if it exists? [14:22] hallyn: no, there are two 3 cell batteries [14:22] stgraber: wrote that down, thx [14:22] oh, ok :) [14:22] ev_, bdmurray: cause that doesn't make sense at all when you try and actually use it (bug 1339663) [14:22] bug 1339663 in apport (Ubuntu) "ubuntu-bug fails with "whoopsie-upload-all: error: unrecognized arguments" when /var/lib/apport/autoreport exists" [Medium,Triaged] https://launchpad.net/bugs/1339663 [14:22] hallyn: so you can swap one while you are on battery if needed [14:22] so hopefully at least 5 hrs batt lfie [14:23] ev_, bdmurray: this completely breaks reporting bugs, and crashes should be uploaded automatically anyway; at most, ubuntu-bug could check if /etc/apport/autoreport is on and then point that out instead of processing a .crash file [14:23] (that's a bit hackish though) [14:24] hallyn: it's got a front 3cell battery and a back battery that can be 3 or 6 cell. Haswell should be better at power management than Ivy Bridge and my x230 (ivy bridge) with a 9-cell battery lasts 7-8 hours on wifi (like at sprints) and up to 12 without wifi (when traveling) [14:25] ev_, bdmurray: oh, that's for adding the extra apport info to .crash files and creating the whoopsie stamp [14:25] hallyn: oh, and not sure if that matters to you, but all the new thinkpads no longer have physical mouse buttons, so if you were used to the trackpoint + physical mouse buttons with the touchpad disabled, it's going to be a bit trickier... [14:25] ev_, bdmurray: but that's a totally different operation than reporting a bug or uploading a single .crash file, so I think if you want to do that you shoudl just call whopsie-upload-all? [14:26] (or we even cron that) [14:26] stgraber: it'll annoy me, but every laptop is a compromise these days [14:26] stgraber: so with 9 cell batt and IPS display i'm around $1300. compared to $300 for chromebook. but much nicer, and hopefully useful otuside. will think a bit. thanks :) [14:26] maybe is hould buy a used x230 :) [14:27] hallyn: yeah... I need to change laptop by October and so far I'm pretty disappointed, they all suck in different ways... [14:27] hallyn: that's what slangasek ended up doing earlier this year :) [14:27] hallyn: well, not used, but an x230 rather than current gen thinkpad [14:27] "need to change by october" ? [14:28] heh, amazon still sells x230 [14:28] hallyn: yeah, a family member already bought my current laptop and we agreed I'd give it to her in October ;) [14:28] xnox: apparently not, eog https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1339954/+attachment/4149207/+files/UK14.04 show some missing chars [14:28] Ubuntu bug 1339954 in plymouth (Ubuntu) "Unable to display Chinese in Plymouth-lable" [Undecided,New] [14:28] stgraber: lol [14:29] hallyn: I've not ruled out buying another x230 though, I'd like to have an haswell laptop, but I also would really like to keep trackpoint with physical mouse buttons... [14:29] course i don't use mouse all that much, and could get a mini-mouse for when i need it, i guess [14:30] stgraber: would the default x230 screen compare to the IPS screen on t440s i wonder [14:30] hallyn: the only downside of the x230 is that you can only find it with the 1366x768 IPS display, the variant with the 1920x1080 IPS display is pretty much impossible to find. So it's a bit lowres (like most laptops...) but the display quality is very good. [14:30] again, especially for outdoors [14:30] ok - i care more about visibility outdoors than i do resolution [14:31] @pilot out === 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: [14:32] right, so I believe the x230 was only sold with IPS, so then that's the same I've got here which is pretty bright and fine outdoors [14:32] hm, nice [14:33] I once had some problem reading it in direct sunlight but that day was very very bright, it was the early afternoon, no shade whatsoever, the laptop got pretty hot and I got sunburnt, so that may have been a sign that I shouldn't have been staying there :) [14:34] but being stubborn you stayed out an extra 30 mins just to tell the sun off :) [14:34] well, I ended up staying there for maybe 2 hours, my dark terminals were a problem to read but firefox (or anything with a bright background) was fine [14:35] mdeslaur: do you have any particular interest in merging file 5.19 from debian to fix LP: #1340212 ? i ask since you did the last merge. [14:35] Launchpad bug 1340212 in file (Ubuntu) "file 5.18 incorrectly identifies mime type of zip files" [Undecided,New] https://launchpad.net/bugs/1340212 [14:35] barry: I was just looking at file security updates. Are you volunteering? [14:36] :) [14:36] barry: else, yes, I will do 5.19 [14:36] mdeslaur: well, it's moderately blocking me, but i think i can work around it :) [14:36] mdeslaur: but hey, that sounds like you volunteer :) [14:38] barry: hehe, I'll do it this afternoon [14:41] mdeslaur: awesome, thanks === roadmr is now known as roadmr_afk [14:55] hallyn: yes, the x240 keyboard sucks :) [14:59] slangasek: not nearly as much as the new X1 carbon's (not sure if you ever saw that one, it's the weird one with split keys and where they shuffled stuff around quite a bit too just for fun) [14:59] pitti: that sounds reasonable to me, but I think bdmurray wrote that code, so let's see what he thinks. [14:59] all I care about is that the phones automatically send crash reports [14:59] not that ubuntu-bug does anything fancy :) [15:00] ev_: you wrote the initial one in apport-bug with the apport-noui backend, but that behaved much more like the others; whoopsie-upload-all doesn't do at all [15:00] ev_: I'm not sure what /etc/apport/autoreport should mean -- i. e. automatically upload all crashes unreviewed, or something else [15:01] if so, it should have something like a cron job which calls whoopsie-upload-all if that flag exists [15:01] oops :) [15:01] autoreport should mean automatically send all crashes [15:01] there's no reviewing on the phone [15:01] you either send them or you don't [15:01] if it has another semantics which involves ack'ing crashes by the user, then we need some interactivity and ubuntu-bug integration [15:01] ok, thanksk [15:01] so that means that it doesn't really belong into ubuntu-bug, which you have to call manually (and then for different reasons) [15:02] yeah, indeed [15:02] I don't know why I did it, but I admit it was wrong [15:02] and apologies to bdmurray for thinking it was his code [15:02] ev_: well, it was quite right back then with apport-noui [15:03] it just got mashed up with moving to whoopsie-upload-all in r2686 [15:03] oh [15:03] yay, not a complete muppet [15:04] ev_: ok, so ISTM that we should kick that out of ubuntu-bug, and we instead need a cron job/upstart hook/whoopsie integration/etc. to call w-u-all if that flag exists? [15:04] cron runs on the phone, so in theory we could just use that [15:04] isn't that what the apport-noui job does? [15:04] oh! [15:04] ev_: yes, that very [15:05] :) [15:05] ev_: so that fix is simple then: remove 4 lines of shell, done :) [15:05] high five! [15:05] ev_: thanks for the heads-up, wanted to make sure I understand how these bits are working [15:05] if only our jobs were always so easy [15:05] delete code, upload, drink beer [15:05] I'm just going to sit around and delete code all day [15:05] (and watch soccer) [15:05] lol [15:06] you forget that there are ou's in my words now. You can safely call it football around me. ;) [15:06] but after next Sunday, that madness is over at least [15:06] * pitti hugs ev_ [15:07] :D [15:09] pitti: I don't think cron runs on the phone [15:09] bdmurray: it does (I just checked), but that file-triggered apport-noui.conf upstart job is better indeed [15:09] bdmurray: so it's all good now [15:11] pitti: okay, while you are here I noticed a call to apt.apt_pkg.SourceRecords() in backends/packaging-apt-dpkg.py and it seems to me that isn't in the sandbox cache [15:11] pitti: so if source package contents change between releases there will be an issue [15:12] bdmurray: oh, you mean that doesn't use the rootdir= ? [15:12] ouch, yes [15:13] it looks to me like SourceRecords doesn't take any arguments [15:13] so we can't pass the cache [15:14] mvo_: is there some way of getting the SourceRecords from an apt.Cache(rootdir=) object, isntead of apt.apt_pkg.SourceRecords()? [15:14] stgraber: heh, i think both gaughen and rharper have the x1, it *looks* sleek from a distance [15:15] hallyn, yes I have the x1 carbon. I love it. [15:15] pitti: it should setup all the config so that happens automatically after you create the binary cache, is that not the case for you? [15:15] hallyn, and we know people who could get us corporate discounts on said laptop [15:15] mvo_: I haven't tried myself, bdmurray just pointed it out [15:16] mvo_: ah, so the intent is that once you instantiate a Cache(rootdir=), everything else uses that config? [15:16] gaughen: oh, they could do same on a t440s? [15:17] who are these mythical creatures? (msot ppl i knew have fled :) [15:17] hallyn, I still have people. let me know and I shall get you a serial # [15:17] hallyn, Nivedita for one [15:17] pitti: yeah [15:17] mvo_: ok, thanks [15:18] bdmurray: did you actually see that break? [15:18] pitti: it should be this way, if not, please let me know [15:18] mvo_: danke [15:18] yw [15:18] gaughen: can i also use that for hotel discount? :-) [15:19] gaughen: ok i may have to take you up on that! i really need a new laptop [15:19] * hallyn hopes smoser will keep his mouth shut [15:19] hallyn, I have just gone around with confidence and pretended I deserve the corporate rate and it has worked [15:19] pitti: I thought it might be the cause of bug 1336062 [15:19] bug 1336062 in apport (Ubuntu) "apport-retrace on precise confused by source package name changing" [Undecided,New] https://launchpad.net/bugs/1336062 [15:20] bdmurray: ok, thanks; I opened that in a tab, will look at it [15:20] just need to run out for a bit now [15:21] bdmurray: in a meeting right now, I check once its finished [15:28] barry: merged and uploaded [15:29] mdeslaur: you rock, thanks === roadmr_afk is now known as roadmr === timrc-afk is now known as timrc === mhall119_ is now known as mhall119 [15:57] stgraber: for systemd-shim. i want to depend on apiversion >= 5, so the shim can just use controller "all" instead of enumerating the controllers. Trusty doesn't yet have that version. Preference? [15:57] should I SRU apiversion 5, or have extra code ins ystems-shim to list all the controlelrs? [15:58] hallyn: we don't need systemd-shim for trusty do we? [15:58] stgraber: good point === kentb is now known as kentb-afk [16:43] feh. wishing i had done remove_on_empty for group controllers [16:48] stgraber: yay, shim is putting me into cgroups [16:49] nice! [16:49] would be nice if they sometimes got removed (i' [16:49] m on c27.session now :) [16:51] if i could only remember why i decided not to do autremove for "all" controllers [16:51] really can't think of a good rason. 'get_value' and 'set_value' make sense [16:51] * hallyn goes to think about it === Dr_Who is now known as Guest91519 [17:24] all right i'll just implement it then [17:29] and, yay, we have autoremove. [17:29] desrt: let me wrap this up into a clean commit and push it to git so you can yell at m^W^W^Wreview [17:31] :) [17:34] desrt: github.com/hallyn/systemd-shim cgm.1 (to work it requires an update to cgmanager which i'll push shortly) [17:35] desrt: and apologies for dumping this so late when i know you're leaving in a few hours [17:35] hallyn: i'm still here until tomorrow [17:36] oh! i thought you were out tomorrow :) ok then i can relax a bit :) [17:36] all right, going out for a walk, bbl [17:37] hallyn: i notice you still take a conditional depend on the cgroups stuff... [17:38] +AM_CONDITIONAL([ENABLE_CGMANAGER], [test "x$enable_cgmanager" = "xyes"]) [17:38] ...even if you never actually use the conditional [17:38] i guess i'd be happier if you just took the pkg-config depend like usual [17:38] desrt: do i ? i thought i removed that [17:39] oh huh [17:39] also: your inclusion of nih/nih-dbus/dbus is not required [17:39] why? [17:40] the pkg-config on libcgmanager will pull them in automatically [17:40] oh. you copy-paste a big chunk of code here that actually uses this stuff..... [17:40] i thought you were only going to make calls to libcgmanager... [17:41] desrt: ok, i pushed the trivial drop of that AM_CONDITIONAL; [17:41] i'd definitely prefer that you rewrite this rather small use of nih dbus into gdbus [17:41] no, i'm using the autogenerated cgmanager-client library code [17:41] but i guess i can do that for you [17:41] desrt: that would *rock* [17:42] pretty sure that woudl take me days [17:42] okay [17:42] i'll look into that this afternoon [17:42] just send me the cgmanager update.... [17:42] desrt: but let me say in favor of keepign it as is, that it then uses the same client library code that upstart, lxc, and the older logind are using [17:42] desrt: cgmanager update is building in utopic [17:42] (and is applied in git://github.com/cgmangaer/cgmanager) [17:42] ah. nice. [17:43] so the issue is that cgmanager_get_api_version_sync() wants to take a nih dbus connection? [17:43] a proxy, i guess, rather... [17:43] this is some very bad API :( [17:44] desrt: well you should be able to just get the API version using dbus without a proxy - you can do it with dbus-send [17:44] desrt: the API is designed to do things that simple dbus cannot :) [17:44] so this entire client library is just codegen'd dbus client calls? [17:44] desrt: in particular, if you want to weep, look at how the *_scm work [17:45] i notice "scm" does not appear in your patch [17:45] desrt: yes. which uses half of the acutal dbus calls [17:45] right [17:45] so will you depend on the non-dbus-call parts of the library? [17:45] or could i just rewrite it all to straight dbus calls? [17:45] not from systemd-shim, no. [17:45] go for it [17:45] k. i prefer to do that, then [17:45] wait, hm. [17:46] trying to think if you need to pass any fds... but i guess not, no. so yeah that should be fine [17:46] gdbus does fd passing just fine... [17:46] (yea but not SCM passing :) [17:47] yeah but the issue i had was that if you didn't FORCE fd passing early enough, the call woudl fail [17:47] but i don't think that is an issue here [17:47] so are we on the same page? i rewrite everything in straight-up dbus and drop the nih/libcgmanager deps? [17:47] desrt: yup [17:47] cool. [17:47] desrt: thanks! [17:47] hopefully i can have that for you by tomorrow morning [17:48] perhaps in the meantime i should be looking at cgmanager for debian, [17:48] slangasek: ^ we're just about there [17:48] stgraber: I'm going for that walk now, but may have some sysv questions for you when i get back [17:49] hallyn: do we care about scm from systemd-shim? I mean we should only talk to either the host cgmanager or to a proxy, never to host cgmanager directly from a container [17:49] hallyn: so in theory it's all standard dbus, none of our weird fd + creds fancy thing [17:50] stgraber: right, [17:50] stgraber: i was just defending the "that's bad API" :) [17:50] but we dont' need that at all for systemd-shim [17:51] hallyn: just about where? :) [17:51] slangasek: i've got systemd-shim doing cgroup setup for me [17:51] sweet [17:51] (well, cgroup creation and putting me in it; not configuration of cpusets and such) [17:52] slangasek: do we really only care about this with upstart, or do we care about sysv people? [17:52] hallyn: well, as I figured out yesterday only after you ask, we do care in Debian about it for sysv because of the wheezy->jessie upgrade case [17:53] hallyn: but it's also ok to say "here's the code, Debian, please wire up the sysvinit scripts" [17:54] slangasek: ok thanks. (the stuff's not un-subtle wrt starting up proxy and manager, so may be better to provide the scripts) [17:55] * hallyn out [17:55] (well, back later, of course) === kentb-afk is now known as kentb [18:18] stgraber: I really enjoy my x1, but it's the older model with dedicated mouse buttons. the new keyboard is rather strange; not sure if I could adapt to that one. [18:19] right, the older x1 was pretty nice, it's the new one that's just weird :) [19:07] stgraber: I send an email to the DMB that's stuck in moderation, can you let that through? [19:09] mhall119: sure [19:10] thanks [19:11] pitti: I've noticed that libmirclientplatform-android-dbgsym is missing from Packages for main and universe on ddebs.ubuntu.com but the package is there [19:11] pitti: Could you look into that? [19:24] stgraber: got another one in moderation [19:25] mhall119: processed [19:32] thanks again [19:38] doko: is there a roadmap for what's missing for replacing python2 with python3? [19:38] doko: or, who can i talk to to help on this? [19:40] barry: ^^ [19:45] nxvl: that's a pretty general question :) can you narrow that down a bit? [19:46] what's the work that needs to be done to get rid of python2, and get python3 by default [19:46] i want to help getting that done [19:46] and see python3 in 14.10 [19:46] so, basically, what can i do to help? [19:47] what do you mean with by default? [19:47] it already is default on the iso or? === roadmr is now known as roadmr_afk [19:47]