[00:08] <hallyn> 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] <hallyn> (i'm trying with http://paste.ubuntu.com/7772700/ )
[00:10]  * hallyn suspects desrt is in a currently-asleep tz :)
[02:35] <desrt> hallyn: a(sv) or a{sv}?
[02:58] <hallyn> desrt: a(sv)
[02:58] <desrt> weird!
[02:58] <desrt> what is this?
[02:58] <desrt> like, what data is in there?
[02:58] <desrt> one does not typically see the a(sv) type....
[02:59] <hallyn> 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] <hallyn> seemed rather silly to me, suppose it's meant to be future-proof
[02:59] <desrt> typically you use a{sv} unless you really care about the order
[03:00] <desrt> which is difficult to imagine in this situation...
[03:00] <desrt> anyway... did you figure it out?
[03:00] <hallyn>      "<arg name='properties' type='a(sv)' direction='in'/>"
[03:00] <hallyn> nope
[03:00] <hallyn> i mean i get a valid list, but the n_elements is always 0
[03:00] <desrt> so what do you have there?
[03:01] <desrt> you're implementing this inside the shim?
[03:01] <hallyn> yeah
[03:01] <hallyn> http://paste.ubuntu.com/7773201/
[03:01] <desrt> so you have name mode properties aux
[03:01] <hallyn> that's the chunk i'm using right now
[03:02] <desrt> so typically you whack out all the parameters at once
[03:02] <desrt> something like so:
[03:02] <desrt> const gchar *name, *mode;  GVariantIter *properties, *aux;
[03:02] <desrt> g_variant_get (parameters, "(&s&sa(sv)a(s(a(sv)))", &name, &mode, &properties, &aux);
[03:03] <hallyn> then properties will be an iter?
[03:03] <desrt> yes
[03:03] <desrt>   while (g_variant_iter_loop(iter, "(s@v)", &str1, &v)) {
[03:03] <desrt> this is weird
[03:03] <hallyn> i dumped aux actually bc systemd in 208 wasn't yet sendin git
[03:03] <desrt> if you do that then the "v" will contain a value of type 'v'
[03:03] <desrt> you want only to have "(sv)" or even better "(&sv)" with a const gchar *str1
[03:04] <hallyn> ok i'll try that, thx.  (stuff going on so will take a few mins)
[03:06] <desrt> g_variant_iter_n_children() yuck
[03:06] <desrt> i can't believe i let chpe convince me into adding that API :p
[03:06] <desrt> i guess it helps in your case, at least...
[03:07] <hallyn> introspection ftw :)
[03:08] <hallyn> will i still need to use g_variant_iter_free?  i assume so
[03:09] <desrt> yes
[03:10] <desrt> 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] <desrt> which was itself only extracted from the parent
[03:10] <hallyn> desrt: yay, i get contents, thanks!
[03:16] <hallyn> 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] <desrt> hallyn: i'll probably take a look over the dbus-specific parts of this patch and may clean them up a bit
[03:38] <desrt> 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] <hallyn> desrt: I get to the point where my nonexistant cgroup code says: cgmanager_create_all: called for /user/1000.user/c11.session
[03:41] <hallyn> \o/
[03:42] <desrt> btw: i'm going on vacation pretty much immediately after work on friday... i'll be gone for a week
[03:42] <hallyn> 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] <hallyn> 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] <desrt> sure thing... otherwise, i guess no big deal if it takes an extra week?
[03:43] <hallyn> desrt: well debian-devel is crying already, so it may be a big deeal to them :)
[03:43] <desrt> okay
[03:43] <desrt> what's your TZ, btw?
[03:43] <hallyn> desrt: so yeah i'll toss you a git tree in the morning (in about 14 hours)
[03:44] <hallyn> US central
[03:44] <hallyn> its' 22:45 here
[03:44] <desrt> cool.  toronto time here.
[03:44] <hallyn> oh!  i thought you were in nl for some reason
[03:44] <desrt> nope
[03:44] <desrt> although toronto and amsterdam have a bit in common :)
[03:45] <hallyn> oh?
[03:45] <hallyn> not something i'd ever heard
[03:45] <desrt> ya... just similar feel
[03:45] <desrt> ultra-progressive, etc
[03:45] <hallyn> 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] <hallyn> anyway!  tty i nthe morning, thx again for your help
[03:46] <desrt> sleep well
[04:11] <hallyn> desrt: well, i went ahead and pushed it to github.com/hallyn/systemd-shim #cgm.1
[04:11]  * hallyn out
[05:03] <pitti> Good morning
[05:26] <pitti> 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] <pitti> infinity: obviously that didn't happen on the real buildds, do you have an idea why that could be?
[05:33] <slangasek> pitti: Debian bug #748694?
[05:36] <pitti> slangasek: ah, thanks; we don't seem to have that in Ubuntu yet (at least not in the changelog)
[05:36] <pitti> https://launchpad.net/ubuntu/+source/systemtap/2.3-2ubuntu1 sounds related though
[05:37] <pitti> but isn't, glibc just failed again
[05:42] <infinity> pitti: It's entirely possible the 'fixes' broke glibc's build.  I can look tomorrow.
[05:42] <pitti> oh, that way around
[05:42] <pitti> infinity: thanks; not urgent, I was just wondering why it fails on this build but not the other
[05:42] <pitti> infinity: it counts as "always failed" now, so doesn't block anything
[05:43] <pitti> (due to the package rename)
[05:43] <infinity> pitti: Oh, ugh.  Yeah, we should get it fixed at least once so it stops behaving that way.
[05:43] <infinity> pitti: I'll look tomorrow after I knock off a few more urgent items.
[05:54] <infinity> 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] <infinity> pitti: Oh, failure is obvious.
[06:05] <infinity> pitti: Fix testbuilding, will upload in the morning if it's all good here.
[07:01] <dholbach> good morning
[08:42] <mvo_> @pilot in
[09:49] <Noskcaj> mlankhorst, Has libxi had it's breaks long enough that we can sync again?
[09:52] <mlankhorst> Noskcaj: sure, it was just needed until the lts
[12:51] <mvo_> 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:53] <pitti> mvo_: will apply in Debian; I don't have upstream commit
[12:53] <mvo_> pitti: ok, there is a debdiff in the bug if thats easier
[12:53] <pitti> right, that's the one I'm looking at
[12:53] <mvo_> pitti: ok, I will do a trusty SRU for that then and we get utopic via the next debian sync :)
[12:54] <pitti> mvo_: thanks!
[12:55] <mvo_> pitti: thank you! I assume forwarding this to upstream via their bts make sense (I assume they are responsive)?
[12:55] <pitti> mvo_: no, it's been dead upstream for ages, so don't bother
[12:55] <mvo_> pitti: ok, good to know
[12:55] <pitti> mvo_: I think mbiebl_ has commit rights, but he can also pick them from the debian package
[12:55] <pitti> mvo_: I'll add a DEP-3 header
[12:56] <mvo_> pitti: \o/ thanks!
[12:56]  * mvo_ writes the test case etc stuff in the meantime
[12:58] <pitti> mvo_: I'll do a Debian upload now, so that it'll be fixed in utopic soon
[12:59] <desrt> hallyn: why the conditionals?
[12:59] <desrt> (in configure)
[13:01] <pitti> mvo_: (done)
[13:01] <mvo_> thanks pitti
[13:16] <LocutusOfBorg1> wow! MoM seems broken again
[13:17] <LocutusOfBorg1> cjwatson, ;)
[13:17] <LocutusOfBorg1> sil2100, did you see upstream for lucene? they fixed the gtest stuff
[13:17] <LocutusOfBorg1> I asked for a new release
[13:23] <cjwatson> LocutusOfBorg1: sigh.  hopefully fixed
[13:26] <hallyn> desrt: yeah i was undecided on that.  at first i was going to not have them and make it depend on cgmanager
[13:26] <hallyn> i suppose i should do it that way
[13:27] <hallyn> bc also supporting cgfs would be very complicating and not nearly as safe
[13:28] <LocutusOfBorg1> cjwatson, thanks as usual :)
[13:28] <LocutusOfBorg1> 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] <LocutusOfBorg1> like gccxml, gambas3, wxwidg
[13:29] <LocutusOfBorg1> they are all trivial to sync
[13:29] <LocutusOfBorg1> s/sync/merge
[13:29] <LocutusOfBorg1> curl
[13:31] <cjwatson> wxwidgets3.0 can't be synced so I'm not sure I believe you :)
[13:31] <cjwatson> Nor can gccxml
[13:32] <cjwatson> Oh, merges, right, don't have time for that right now sorry ...
[13:32] <cjwatson> Reviewing merges is generally harder work than just doing them
[13:33] <cjwatson> 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] <LocutusOfBorg1> cjwatson, I mean wx2.8
[13:36] <LocutusOfBorg1> not 3.0
[13:37] <LocutusOfBorg1> and s/sync/merge
[13:37] <LocutusOfBorg1> cjwatson, ok
[13:37] <LocutusOfBorg1> just sometimes is bad to see ubuntu so much behind debian
[13:37] <LocutusOfBorg1> I hope to see merges done when freeze approaches :)
[13:38] <LocutusOfBorg1> I will offer my help again at that time :D
[13:38] <cjwatson> 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] <cjwatson> 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] <LocutusOfBorg1> yes of course
[13:39] <cjwatson> Or sometimes it's just not important :)
[13:39] <LocutusOfBorg1> I'm wondering about some programs like gambas
[13:39] <LocutusOfBorg1> the rebuild against llvm 3.2 in debian failed on all archs because of a cmake problem
[13:40] <LocutusOfBorg1> why the ubuntu rebuild did not fail? llvm 3.4 is in ubuntu since trusty
[13:40] <LocutusOfBorg1> s/3.2/3.4
[13:40] <LocutusOfBorg1> anyway not a problem :)
[13:53] <mvo_> 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] <popey> xnox: is lp:~ubuntu-mate-dev/ubiquity/ubiquity-marco sane enough for merging to our ubiquity?
[14:15] <hallyn> slangasek: stgraber: infinity: do i recall correctly y'all said the tp x240 kbd sucks?
[14:17] <xnox> 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] <stgraber> 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] <stgraber> 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] <hallyn> stgraber: ah, ok.  x240 has much longer batt life and is slightly cheaper, so it's catching my eye right now
[14:17] <xnox> mvo_: i'd rather include it conditionally. We are including ubuntu font i think, is that pretty in chinese or not?
[14:17] <hallyn> (though i do like thinness.  i'm vain)
[14:18] <hallyn> i'm used to netbooks, so 8G will suffice if i' not spending too much
[14:18] <stgraber> 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] <hallyn> but that display resolution!
[14:19] <hallyn> hm, yeah.  i *do* need an insert key
[14:19] <hallyn> t440.  will look, thx
[14:19] <stgraber> 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] <hallyn> waht is that like 12lb?
[14:20] <hallyn> t440 also has the low-res though.  sad
[14:20] <stgraber> t440s is around 3.5lbs I believe, surprisingly light when I was checking out wgrant's at the last sprint
[14:21] <stgraber> hallyn: note, there's a big difference in quality between the t440 and t440s, so make sure you look at the latter
[14:21] <hallyn> wgrant: any experience to tell me whether t440 screen is reasonable outdoors?
[14:21] <hallyn> stgraber: ok
[14:22] <stgraber> 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] <hallyn> 3 cell battery?  is that a joke?
[14:22] <pitti> 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] <stgraber> hallyn: no, there are two 3 cell batteries
[14:22] <hallyn> stgraber: wrote that down, thx
[14:22] <hallyn> oh, ok :)
[14:22] <pitti> ev_, bdmurray: cause that doesn't make sense at all when you try and actually use it (bug 1339663)
[14:22] <stgraber> hallyn: so you can swap one while you are on battery if needed
[14:22] <hallyn> so hopefully at least 5 hrs batt lfie
[14:23] <pitti> 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] <pitti> (that's a bit hackish though)
[14:24] <stgraber> 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] <pitti> ev_, bdmurray: oh, that's for adding the extra apport info to .crash files and creating the whoopsie stamp
[14:25] <stgraber> 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] <pitti> 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] <pitti> (or we even cron that)
[14:26] <hallyn> stgraber: it'll annoy me, but every laptop is a compromise these days
[14:26] <hallyn> 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] <hallyn> maybe is hould buy a used x230 :)
[14:27] <stgraber> hallyn: yeah... I need to change laptop by October and so far I'm pretty disappointed, they all suck in different ways...
[14:27] <stgraber> hallyn: that's what slangasek ended up doing earlier this year :)
[14:27] <stgraber> hallyn: well, not used, but an x230 rather than current gen thinkpad
[14:27] <hallyn> "need to change by october" ?
[14:28] <hallyn> heh, amazon still sells x230
[14:28] <stgraber> hallyn: yeah, a family member already bought my current laptop and we agreed I'd give it to her in October ;)
[14:28] <mvo_> xnox: apparently not, eog https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1339954/+attachment/4149207/+files/UK14.04 show some missing chars
[14:28] <hallyn> stgraber: lol
[14:29] <stgraber> 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] <hallyn> course i don't use mouse all that much, and could get a mini-mouse for when i need it, i guess
[14:30] <hallyn> stgraber: would the default x230 screen compare to the IPS screen on t440s i wonder
[14:30] <stgraber> 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] <hallyn> again, especially for outdoors
[14:30] <hallyn> ok - i care more about visibility outdoors than i do resolution
[14:31] <mvo_> @pilot out
[14:32] <stgraber> 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] <hallyn> hm, nice
[14:33] <stgraber> 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] <hallyn> but being stubborn you stayed out an extra 30 mins just to tell the sun off :)
[14:34] <stgraber> 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] <barry> 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] <mdeslaur> barry: I was just looking at file security updates. Are you volunteering?
[14:36] <mdeslaur> :)
[14:36] <mdeslaur> barry: else, yes, I will do 5.19
[14:36] <barry> mdeslaur: well, it's moderately blocking me, but i think i can work around it :)
[14:36] <barry> mdeslaur: but hey, that sounds like you volunteer :)
[14:38] <mdeslaur> barry: hehe, I'll do it this afternoon
[14:41] <barry> mdeslaur: awesome, thanks
[14:55] <slangasek> hallyn: yes, the x240 keyboard sucks :)
[14:59] <stgraber> 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] <ev_> pitti: that sounds reasonable to me, but I think bdmurray wrote that code, so let's see what he thinks.
[14:59] <ev_> all I care about is that the phones automatically send crash reports
[14:59] <ev_> not that ubuntu-bug does anything fancy :)
[15:00] <pitti> 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] <pitti> ev_: I'm not sure what /etc/apport/autoreport should mean -- i. e. automatically upload all crashes unreviewed, or something else
[15:01] <pitti> if so, it should have something like a cron job which calls whoopsie-upload-all if that flag exists
[15:01] <ev_> oops :)
[15:01] <ev_> autoreport should mean automatically send all crashes
[15:01] <ev_> there's no reviewing on the phone
[15:01] <ev_> you either send them or you don't
[15:01] <pitti> if it has another semantics which involves ack'ing crashes by the user, then we need some interactivity and ubuntu-bug integration
[15:01] <pitti> ok, thanksk
[15:01] <pitti> 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] <ev_> yeah, indeed
[15:02] <ev_> I don't know why I did it, but I admit it was wrong
[15:02] <ev_> and apologies to bdmurray for thinking it was his code
[15:02] <pitti> ev_: well, it was quite right back then with apport-noui
[15:03] <pitti> it just got mashed up with moving to whoopsie-upload-all in r2686
[15:03] <ev_> oh
[15:03] <ev_> yay, not a complete muppet
[15:04] <pitti> 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] <pitti> cron runs on the phone, so in theory we could just use that
[15:04] <ev_> isn't that what the apport-noui job does?
[15:04] <pitti> oh!
[15:04] <pitti> ev_: yes, that very
[15:05] <ev_> :)
[15:05] <pitti> ev_: so that fix is simple then: remove 4 lines of shell, done :)
[15:05] <ev_> high five!
[15:05] <pitti> ev_: thanks for the heads-up, wanted to make sure I understand how these bits are working
[15:05] <ev_> if only our jobs were always so easy
[15:05] <pitti> delete code, upload, drink beer
[15:05] <ev_> I'm just going to sit around and delete code all day
[15:05] <pitti> (and watch soccer)
[15:05] <ev_> lol
[15:06] <ev_> you forget that there are ou's in my words now. You can safely call it football around me. ;)
[15:06] <pitti> but after next Sunday, that madness is over at least
[15:06]  * pitti hugs ev_
[15:07] <ev_> :D
[15:09] <bdmurray> pitti: I don't think cron runs on the phone
[15:09] <pitti> bdmurray: it does (I just checked), but that file-triggered apport-noui.conf upstart job is better indeed
[15:09] <pitti> bdmurray: so it's all good now
[15:11] <bdmurray> 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] <bdmurray> pitti: so if source package contents change between releases there will be an issue
[15:12] <pitti> bdmurray: oh, you mean that doesn't use the rootdir= ?
[15:12] <pitti> ouch, yes
[15:13] <bdmurray> it looks to me like SourceRecords doesn't take any arguments
[15:13] <bdmurray> so we can't pass the cache
[15:14] <pitti> mvo_: is there some way of getting the SourceRecords from an apt.Cache(rootdir=) object, isntead of apt.apt_pkg.SourceRecords()?
[15:14] <hallyn> stgraber: heh, i think both gaughen and rharper have the x1, it *looks* sleek from a distance
[15:15] <gaughen> hallyn, yes I have the x1 carbon. I love it.
[15:15] <mvo_> 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] <gaughen> hallyn, and we know people who could get us corporate discounts on said laptop
[15:15] <pitti> mvo_: I haven't tried myself, bdmurray just pointed it out
[15:16] <pitti> mvo_: ah, so the intent is that once you instantiate a Cache(rootdir=), everything else uses that config?
[15:16] <hallyn> gaughen: oh, they could do same on a t440s?
[15:17] <hallyn> who are these mythical creatures?  (msot ppl i knew have fled :)
[15:17] <gaughen> hallyn,  I still have people. let me know and I shall get you a serial #
[15:17] <gaughen> hallyn, Nivedita for one
[15:17] <mvo_> pitti: yeah
[15:17] <pitti> mvo_: ok, thanks
[15:18] <pitti> bdmurray: did you actually see that  break?
[15:18] <mvo_> pitti: it should be this way, if not, please let me know
[15:18] <pitti> mvo_: danke
[15:18] <mvo_> yw
[15:18] <hallyn> gaughen: can i also use that for hotel discount?  :-)
[15:19] <hallyn> 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] <gaughen> hallyn, I have just gone around with confidence and pretended I deserve the corporate rate and it has worked
[15:19] <bdmurray> pitti: I thought it might be the cause of bug 1336062
[15:20] <pitti> bdmurray: ok, thanks; I opened that in a tab, will look at it
[15:20] <pitti> just need to run out for a bit now
[15:21] <mvo_> bdmurray: in a meeting right now, I check once its finished
[15:28] <mdeslaur> barry: merged and uploaded
[15:29] <barry> mdeslaur: you rock, thanks
[15:57] <hallyn> 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] <hallyn> should I SRU apiversion 5, or have extra code ins ystems-shim to list all the controlelrs?
[15:58] <stgraber> hallyn: we don't need systemd-shim for trusty do we?
[15:58] <hallyn> stgraber: good point
[16:43] <hallyn> feh.  wishing i had done remove_on_empty for group controllers
[16:48] <hallyn> stgraber: yay, shim is putting me into cgroups
[16:49] <stgraber> nice!
[16:49] <hallyn> would be nice if they sometimes got removed (i'
[16:49] <hallyn> m on c27.session now :)
[16:51] <hallyn> if i could only remember why i decided not to do autremove for "all" controllers
[16:51] <hallyn> really can't think of a good rason.  'get_value' and 'set_value' make sense
[16:51]  * hallyn goes to think about it
[17:24] <hallyn> all right i'll just implement it then <shrug>
[17:29] <hallyn> and, yay, we have autoremove.
[17:29] <hallyn> 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] <desrt> :)
[17:34] <hallyn> desrt: github.com/hallyn/systemd-shim cgm.1   (to work it requires an update to cgmanager which i'll push shortly)
[17:35] <hallyn> desrt: and apologies for dumping this so late when i know you're leaving in a few hours
[17:35] <desrt> hallyn: i'm still here until tomorrow
[17:36] <hallyn> oh!  i thought you were out tomorrow :)  ok then i can relax a bit :)
[17:36] <hallyn> all right, going out for a walk, bbl
[17:37] <desrt> hallyn: i notice you still take a conditional depend on the cgroups stuff...
[17:38] <desrt> +AM_CONDITIONAL([ENABLE_CGMANAGER], [test "x$enable_cgmanager" = "xyes"])
[17:38] <desrt> ...even if you never actually use the conditional
[17:38] <desrt> i guess i'd be happier if you just took the pkg-config depend like usual
[17:38] <hallyn> desrt: do i ?  i thought i removed that
[17:39] <hallyn> oh huh
[17:39] <desrt> also: your inclusion of nih/nih-dbus/dbus is not required
[17:39] <hallyn> why?
[17:40] <desrt> the pkg-config on libcgmanager will pull them in automatically
[17:40] <desrt> oh.  you copy-paste a big chunk of code here that actually uses this stuff.....
[17:40] <desrt> i thought you were only going to make calls to libcgmanager...
[17:41] <hallyn> desrt: ok, i pushed the trivial drop of that AM_CONDITIONAL;
[17:41] <desrt> i'd definitely prefer that you rewrite this rather small use of nih dbus into gdbus
[17:41] <hallyn> no, i'm using the autogenerated cgmanager-client library code
[17:41] <desrt> but i guess i can do that for you
[17:41] <hallyn> desrt: that would *rock*
[17:42] <hallyn> pretty sure that woudl take me days
[17:42] <desrt> okay
[17:42] <desrt> i'll look into that this afternoon
[17:42] <desrt> just send me the cgmanager update....
[17:42] <hallyn> 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] <hallyn> desrt: cgmanager update is building in utopic
[17:42] <hallyn> (and is applied in git://github.com/cgmangaer/cgmanager)
[17:42] <desrt> ah.  nice.
[17:43] <desrt> so the issue is that cgmanager_get_api_version_sync() wants to take a nih dbus connection?
[17:43] <desrt> a proxy, i guess, rather...
[17:43] <desrt> this is some very bad API :(
[17:44] <hallyn> 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] <hallyn> desrt: the API is designed to do things that simple dbus cannot :)
[17:44] <desrt> so this entire client library is just codegen'd dbus client calls?
[17:44] <hallyn> desrt: in particular, if you want to weep, look at how the *_scm work
[17:45] <desrt> i notice "scm" does not appear in your patch
[17:45] <hallyn> desrt: yes.  which uses half of the acutal dbus calls
[17:45] <hallyn> right
[17:45] <desrt> so will you depend on the non-dbus-call parts of the library?
[17:45] <desrt> or could i just rewrite it all to straight dbus calls?
[17:45] <hallyn> not from systemd-shim, no.
[17:45] <hallyn> go for it
[17:45] <desrt> k.  i prefer to do that, then
[17:45] <hallyn> wait, hm.
[17:46] <hallyn> trying to think if you need to pass any fds...  but i guess not, no. so yeah that should be fine
[17:46] <desrt> gdbus does fd passing just fine...
[17:46] <hallyn> (yea but not SCM passing :)
[17:47] <hallyn> yeah but the issue i had was that if you didn't FORCE fd passing early enough, the call woudl fail
[17:47] <hallyn> but i don't think that is an issue here
[17:47] <desrt> so are we on the same page?  i rewrite everything in straight-up dbus and drop the nih/libcgmanager deps?
[17:47] <hallyn> desrt: yup
[17:47] <desrt> cool.
[17:47] <hallyn> desrt: thanks!
[17:47] <desrt> hopefully i can have that for you by tomorrow morning
[17:48] <hallyn> perhaps in the meantime i should be looking at cgmanager for debian,
[17:48] <hallyn> slangasek: ^  we're just about there
[17:48] <hallyn> stgraber: I'm going for that walk now, but may have some sysv questions for you when i get back
[17:49] <stgraber> 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] <stgraber> hallyn: so in theory it's all standard dbus, none of our weird fd + creds fancy thing
[17:50] <hallyn> stgraber: right,
[17:50] <hallyn> stgraber: i was just defending the "that's bad API" :)
[17:50] <hallyn> but we dont' need that at all for systemd-shim
[17:51] <slangasek> hallyn: just about where? :)
[17:51] <hallyn> slangasek: i've got systemd-shim doing cgroup setup for me
[17:51] <slangasek> sweet
[17:51] <hallyn> (well, cgroup creation and putting me in it;  not configuration of cpusets and such)
[17:52] <hallyn> slangasek: do we really only care about this with upstart, or do we care about sysv people?
[17:52] <slangasek> 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] <slangasek> hallyn: but it's also ok to say "here's the code, Debian, please wire up the sysvinit scripts"
[17:54] <hallyn> 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] <hallyn> (well, back later, of course)
[18:18] <rharper> 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] <stgraber> right, the older x1 was pretty nice, it's the new one that's just weird :)
[19:07] <mhall119> stgraber: I send an email to the DMB that's stuck in moderation, can you let that through?
[19:09] <stgraber> mhall119: sure
[19:10] <mhall119> thanks
[19:11] <bdmurray> 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] <bdmurray> pitti: Could you look into that?
[19:24] <mhall119> stgraber: got another one in moderation
[19:25] <stgraber> mhall119: processed
[19:32] <mhall119> thanks again
[19:38] <nxvl> doko: is there a roadmap for what's missing for replacing python2 with python3?
[19:38] <nxvl> doko: or, who can i talk to to help on this?
[19:40] <nxvl> barry: ^^
[19:45] <barry> nxvl: that's a pretty general question :)  can you narrow that down a bit?
[19:46] <nxvl> what's the work that needs to be done to get rid of python2, and get python3 by default
[19:46] <nxvl> i want to help getting that done
[19:46] <nxvl> and see python3 in 14.10
[19:46] <nxvl> so, basically, what can i do to help?
[19:47] <jtaylor> what do you mean with by default?
[19:47] <jtaylor> it already is default on the iso or?
[19:47] <barry> jtaylor: not for desktop
[19:47] <jtaylor> oh, whats missing?
[19:47] <nxvl> jtaylor: according to https://wiki.ubuntu.com/Python/3 it's not
[19:48] <slangasek> it is "the default" :)
[19:49] <barry> one thing to start with is to review https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AiT4gOXSkmapdGdFejk0MjFydUlNMDVoMXNRdGdkbFE&pli=1#gid=0
[19:50] <barry> to see if that's still accurate
[19:51] <barry> another thing is to work on getting python3 as default in debian, which is blocked on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732644
[19:52] <barry> it's been a few months since i reviewed status, but it should be true today that python2 is banished from touch, removed from default server iso or very nearly so, and still has a ways to go on desktop (hopefully not too far, but there may be big blockers)
[19:53] <nxvl> who might know better?
[19:53] <barry> nxvl: nobody ;)
[19:53] <nxvl> ohhh, it's good to be back :D
[19:54] <barry> nxvl: it's just a matter of continually reviewing status and updating the relevant docs, etc.  things change quickly!  e.g. i have been uploading a *ton* of stuff to debian and syncing to ubuntu to improve py3 library support where upstream supports it
[19:54] <barry> nxvl: good to have you back, and really glad you want to help!
[19:55] <nxvl> ok, i'll review the doc and update it
[19:56] <barry> nxvl: cool, thanks.  e.g. it would be good to know what the current state of upstream twisted is.  i haven't seen any announcements, but that doesn't mean stuff isn't available
[19:56] <barry> now
[19:56] <barry> nxvl: e.g.x2: i'm hoping that once zope.untrustedpython clears new and lands, that will unblock a bunch of the ztk stack from proposed
[19:57] <barry> (dep8 tests are all passing for me locally, but depend on python-zope.untrustedpython which was split out from the zope.security source package & upstream)
[19:57] <barry> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[19:58] <nxvl> just reading "update excuses" on the url makes me not want to open the link
[19:58] <nxvl> :P
[19:58] <barry> :)
[19:58] <nxvl> (did i already mention how i missed this open source chaos?)
[20:00] <barry> nxvl: how's the real world? :)
[20:00] <nxvl> barry: booooooooooring
[20:02] <bdmurray> wgrant: Would you have any idea about Packages files being incomplete on ddebs.ubuntu.com?
[20:30] <jtaylor> is it just my system or does valgrind not have a apport exception for segfaults?
[20:30] <jtaylor> everytime my app crashes as expected in valgrind the ubuntu bug reporter pops up :(
[21:00] <hallyn> stgraber: thanks for the help with sysv scripts.  Not yet tested, but I' pushed what I have to github.com/hallyn/cgmanager initscripts.1 .  bbl
[21:01] <bdmurray> pitti: I've submitted a merge proposal for bug 1336062
[22:05] <wgrant> bdmurray: Afraid not, that's all pitti AFAIK.
[22:06] <bdmurray> wgrant: okay, slangasek thought you might have an idea
[22:09] <wgrant> hallyn: My T440s has the 1080p touch screen because it was cheaper than the non-touch version, and it's a bit glossy but still very usable outside. AIUI the non-touch version is matte. It's by no means a classic ThinkPad, but it's very good and still the best option AFAIK.
[22:25] <hallyn> wgrant: matte should be easier to read outside ?
[22:26] <wgrant> hallyn: Right.
[22:26] <hallyn> k :)
[22:28] <wgrant> The screen is lovely, the keyboard is great except for the lack of dedicated media buttons and the weird Print Screen location, and the touchpad/trackpoint aren't as bad as I initially thought, very usable once correctly configured.
[22:29] <hallyn> wgrant: which batteries do you have?
[22:30] <hallyn> i think i'm sold, tbh
[22:30] <wgrant> hallyn: I have the external 3-cell and 6-cell. I normally run with the 3-cell, as the 6-cell is fairly hefty.
[22:30] <hallyn> will probably get an ssd and memory on amazon as stgraber had suggested
[22:30] <wgrant> But nothing compared to the old 9-cell that sticks out the back.
[22:30] <wgrant> Yeah, I stuck an 8GiB SODIMM in mine as soon as I got it.
[22:31] <hallyn> wgrant: so you bought both? i may get3 cell in back and both 3 and 6 cell for back
[22:31] <hallyn> wgrant: for the lazy and disaster-prone, do you have the model # somewhere for the simm you got? :)
[22:32] <wgrant> halfie: Afraid not, but I think it was Crucial.
[22:32] <wgrant> Opening the case can be a bit challenging. Make sure you watch the videos and have some plastic phone opening tools around.
[22:33] <hallyn> can't be worse than the vostro i recently did surgery on :)
[22:33] <hallyn> thanks wgrant.
[22:33] <desrt> hallyn: hey... what's the purpose of all this work?
[22:34] <desrt> you said it's so debian can land the new systemd version, right?
[22:34] <hallyn> desrt: right
[22:34] <desrt> but aren't they also landing systemd-as-pid-1?
[22:34] <desrt> or do they keep some sysv backcompat option for the time being?
[22:34] <hallyn> desrt: slangasek says we promised to provide what is needed for running upstart
[22:34] <hallyn> yes, i think so
[22:35] <desrt> so i'm helping people to run upstart on debian?
[22:35] <desrt> how perverse :)
[22:35] <hallyn> desrt: perverse?  what is your preference i wonder? :)
[22:36] <desrt> i can state it in two non-words: systemd asap
[22:36] <hallyn> but also sysv
[22:36] <desrt> i wonder how we ended up holding this particular bag...
[22:36] <desrt> seems like the systemd advocates should have had to do the work there......
[22:37] <hallyn> side effect of arguments and promises made during the debian vote
[22:37] <desrt> ...which we lost :/
[22:37] <hallyn> yup
[22:38] <desrt> i won't pretend to understand :)
[22:39] <hallyn> but you prefer systemd anyway
[22:39] <desrt> ya.... i'm just wondering how we lose the right _and_ have to do the extra work :p
[22:40] <hallyn> desrt: bc we're good folks and we want to support people who still want choice
[22:40] <hallyn> hm, my debian sid system doesn't want to mount a memory cgroup.  what on earth...
[22:40] <desrt> that strikes me as a good enough reason
[22:40] <desrt> hallyn: sure it's not mounted anywhere else?
[22:41] <hallyn> yup
[22:41] <hallyn> custom kernel courtesy of rackspace, maybe it's wonky
[22:48] <desrt> hallyn: so far you only use create_all and remove_all... i guess you will expand this soonish?
[22:49] <hallyn> desrt: create_all also moves the tasks in there.  But yes, the intent is to also respond to requests to set memory and cpu limits
[22:49] <hallyn> if that's what you mean
[22:50] <desrt> i don't really grok how all of this works... but do you have a race here?
[22:50] <desrt> specifically, what if some process fork() after you collect unit->pid but before you cgm_enter() the list of pids?
[22:53] <hallyn> desrt: logind won't do that
[22:53] <hallyn> what you describe is a race in how libcgroup does it (bc it detects 'firefox is running', grabs the pid, and reclassifies it - which can't be done in non-racy wya.  which is why libcgroup is dead)
[22:54] <hallyn> but logind will take the pids, ask us to setup, and only after that proceed to let the user login
[22:54] <hallyn> i'm processing the 'array of pids' but it is always only one pid,
[22:54] <hallyn> for ssh it's the root-owned sshd which becomes parent of the user's sshd and shell
[22:54] <desrt> the use of a(sv) here is really deeply annoying.... prevents use of all of the nice convenient APIs we have :(
[22:55] <hallyn> in the StartTransientUnit you mean?
[22:55] <desrt> btw: for types like "au" we have g_variant_get_fixed_array() that returns a guint*
[22:55] <desrt> ya...
[22:55] <desrt> this is a very strange dbus api...
[22:55] <hallyn> well it only gets worse :)
[22:55] <hallyn> in later systemd we'll have to add the processing of the
[22:56] <hallyn> 'aux'
[22:56] <desrt> another btw: g_object_new() doesn't fail
[22:56] <hallyn> oh, good :)
[22:56] <desrt> another minor btw: doing initialisation of the object after g_object_new() returns is considered bad form
[22:56] <hallyn> stgraber: have you ever seen /proc/cgroups have 'num_cgroups 0' ?
[22:56] <hallyn> http://paste.ubuntu.com/7777549/
[22:57] <hallyn> i think i'll just have to try elsewhere bc ihave no idea what's going on
[22:57] <desrt> another: g_free() on a GObject is a no-no :)
[22:57] <Unit193> hallyn: "with 204-14 being the first version where libpam-systemd will pull in systemd-sysv , I figured a few more days to wait to see how the dust settles wouldn't be so bad"  So will this by chance be completed soon enough for the Debian changes?
[22:58] <hallyn> Unit193: i'm hoping so
[22:59] <Unit193> hallyn: Great, if you happen to be on OFTC, heads up in -systemd might be handy, no?
[22:59]  * Unit193 goes back to lurking now. :)
[22:59] <hallyn> Unit193: debian-systemd?
[22:59] <Unit193> Mhm.
[22:59] <hallyn> or just #systemd?
[23:00] <Unit193> 10:OFTC/#debian-systemd
[23:01] <Unit193> hallyn: Thanks and sorry for the bother. :)
[23:02] <hallyn> Unit193: thx for the pointer
[23:02] <Unit193> Sure.
[23:10] <Unit193> hallyn: I have 213 in a utopic VM, I presume there's no testing I can help with?
[23:11] <hallyn> Unit193: I suspect 213 will need  a 1-line patch to the systemd-shim patch actually
[23:11]  * desrt is mid-rewrite :)
[23:17] <hallyn> desrt: look at systemd.git commit 86b8d289717bad2800342efca0a5023aa8374e9c
[23:17] <hallyn> adds 3 lines which do
[23:17] <hallyn> +        r = sd_bus_message_append(m, "a(sa(sv))", 0);
[23:17] <hallyn> +        if (r < 0)
[23:17] <hallyn> +                return r;
[23:17] <hallyn> adding something which the listener didnt' want anyway
[23:35] <hallyn> ok this is a general debian thing.  any sid image, i can't mount memory cgroup.  'mount -t cgroup cgroup /mnt' mounts everythign but memory.  what on earth?
[23:37] <hallyn> huh, GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"
[23:37] <hallyn>  helped
[23:55] <desrt> cgroups!  what do they do?  why are they here?  have i lost my mind?!
[23:55] <desrt> nobody knows...