[04:47] <attente> happyaron: hey
[04:48] <attente> happyaron: i uploaded a modified unity-settings-daemon, unity-control-center and indicator-keyboard to the fcitx-transition ppa
[04:49] <attente> happyaron: it's got a long way to go.. but it's a start at least
[05:23] <happyaron> attente: thanks, what are the changes included?
[06:29] <didrocks> pitti: bonjour !
[06:37] <mvo> hey pitti and didrocks!
[06:37] <pitti> Bonjour tout le monde !
[06:37] <pitti> hey didrocks, hallo mvo
[06:39] <didrocks> pitti: how are you?
[06:39] <larsu> good morning pitti, didrocks!
[06:39] <didrocks> hey mvo, larsu!
[06:39] <larsu> oh hi mvo
[06:40] <pitti> didrocks: je vais bien, merci ! j'ai mangé beaucoup de fraises à ce matin
[06:40] <pitti> hallo larsu
[06:40] <didrocks> pitti: elles étaient bonnes ?
[06:41] <pitti> didrocks: bien sûr ! we plucked them ourselves
[06:41] <didrocks> oh nice :)
[06:42] <mvo> hey larsu :)
[06:44] <didrocks> pitti: je voulais te demander (si tu as déjà rencontré cette situation) : I want to add some check after each test of all my tests. However, it's part of the test themselves (for instance, ensuring that there has been no log.warning() or log.error()), so not really for a super class running setUp() tearDown() to inherit instead of unittest. Do you know what's the most correct way to implement this?
[06:44] <didrocks> or would you just add the assert() in tearDown() of a super class?
[06:45] <pitti> didrocks: you can add the assert to tearDown(), but that will of course short-circuit any "real" cleanup that you do there
[06:45] <pitti> didrocks: so if you can live with that, it's fine
[06:48] <didrocks> pitti: yeah, that's part of my worrying (well, even if the failure shouldn't happen often ;) so I can live with temp files not cleaned), but if you think of no other easy way…
[06:48] <didrocks> I don't really want to decorate each test_*() :)
[06:50] <pitti> didrocks: you can clean up first, and then do the assertions
[06:52] <didrocks> pitti: yeah, will do that I guess. I another way is to use __get_attr__ I guess and match on "test_*", but unsure it worths that magic
[08:02] <Laney> hey hey hey
[08:03] <seb128> good morning desktopers
[08:03] <didrocks> hey Laney, salut seb128 !
[08:03] <seb128> hey Laney, wie gehts?
[08:03] <seb128> lut didrocks
[08:04] <Laney> nicht schlecht danke, und dir?
[08:04] <Laney> hey didrocks
[08:05] <Laney> been learning to knit this morning ;-)
[08:07] <seb128> Laney, auch gut, danke ;-)
[08:08] <seb128> Laney, doing an U.K scarf for the worldcup or something? ;-)
[08:08] <Laney> haha
[08:08] <Laney> man that would involve mixing colours and everything, complex
[08:08] <seb128> hehe
[08:09] <Laney> maybe by the next world cup i might be able to do that
[08:09] <mvo> hey Laney - how come you started to learn to knit?
[08:09] <Laney> hey mvo
[08:09] <Laney> my girlfriend does it all the time
[08:09] <seb128> good morning mvo ;-)
[08:09] <Laney> so decided to teach me ...
[08:09] <mvo> nice
[08:09] <mvo> hey seb128, good morning
[08:09] <Laney> i think my technique is rubbish though
[08:09] <seb128> Laney, oh, so she might be able to knit the scarf for this one!
[08:09] <Laney> i'm getting a bit of cramp after 2 rows
[08:10] <seb128> need to train the muscles!
[08:11] <Laney> i think it's because you end up holding it too tight
[08:11] <Laney> otherwise the stitches fall off and stuff
[08:29] <Laney> looks like -next got packagekit today
[08:33] <seb128> great
[08:34] <seb128> I'm going to try that in a bit to see if that's enough to make click install out of the box
[08:55] <mhr3_> seb128, hilfe!
[08:56] <mhr3_> seb128, got an issue, i'm trying to install libunity-scopes2 which conflicts with libunity-scopes1, but when i try to remove libunity-scopes1 it's trying to remove half of unity8, even though the direct deps are just scopes
[08:57] <mhr3_> how can i see a nice graph or something which would tell me why is it doing that?
[08:58] <seb128> mhr3_, where is that new scopes2 binary?
[08:59] <mhr3_> seb128, on my machine
[08:59] <seb128> no ppa with it?
[08:59] <mhr3_> not yet
[08:59] <seb128> mhr3_, well, you can apt-cache rdepends --show-installed=yes libunity-scopes1
[08:59] <seb128> then rdepends on those results
[09:00] <seb128> but having a ppa would allow you to use apt and make debugging easier
[09:00] <Laney> does it need to conflict?
[09:00] <mhr3_> yes
[09:00] <Laney> library transitions don't usually
[09:01] <seb128> Laney, libunity-scopes1 has binaries and upstart jobs
[09:01] <seb128> that's wrong
[09:01] <mhr3_> can i force dpkg to install stuff even though it breaks something?
[09:01] <seb128> mhr3_, you should split that binary in unity-sopes and libunity-scopes2
[09:01] <seb128> mhr3_, --force-depends
[09:01] <mhr3_> we should
[09:01] <seb128> dpkg -i --force-depends deb
[09:01] <mhr3_> thanks
[09:01] <seb128> yw
[09:02] <seb128> then apt-get -f install to let apt bring back sanity
[09:02] <seb128> or try to
[10:18] <Sweet5hark> moin!
[10:19] <seb128> Sweet5hark, hey, you missed the meeting!
[10:20] <seb128> Sweet5hark, could you send a summary next time that happens and maybe state that you are not going to be able to join
[10:21] <Sweet5hark> seb128: urgh, indeed. I was so mindwrapped in the last call I completely forgot.
[10:24] <Sweet5hark> seb128: status update would have been: 4.2.5~rc2 bumped to the ppa, 4.2.4 special update prepared, 4.3.0~beta1 and 4.3.0~beta2 updated and build to the prereleases ppa. The latter still has some stability issues, which is slightly worrying. I had to temporarily disable tests and witnessed some wierd behaviour. We are still early in the cycle though.
[10:24] <Sweet5hark> seb128: really sorry about that one.
[10:25] <seb128> Sweet5hark, no worry, thanks for the update ;-)
[10:25] <seb128> no reply from infinity on the SRU build fix so far I guess?
[10:25] <Sweet5hark> seb128: that mean btw the FTBFS issue on trusty/utopic against FF30 should be resolved.
[10:27] <Sweet5hark> seb128: nope, nothing explicitly onfirmingits all good. I had a short chat with infinity after the Firefox fix -- as in "will review it now".
[10:28] <seb128> k
[10:30] <Sweet5hark> seb128: its a one line change though ;)
[10:32] <Sweet5hark> seb128: the guy on bug 1308771 wants a new binary package SRUed into trusty? What does our redtape say about that?
[10:33] <Sweet5hark> seb128: from a technical perspective its likely low risk, but ... its a new package without the MIR-dance etc.
[10:34] <seb128> Sweet5hark, is that a new source or just a new binary?
[10:35] <Sweet5hark> seb128: new binary only.
[10:36] <seb128> Sweet5hark, that doesn't need MIR or anything, looks fine to me for a SRU but you might still want to check with the SRU team what they think
[10:37] <seb128> attente, hey, seems like indicator-keyboard fails to build in utopic (could be due to the new vala version), could you have a look (that's the error the ppa had, http://paste.ubuntu.com/7663029/)
[10:37] <seb128>   VALAC    indicator_keyboard_service_vala.stamp
[10:37] <seb128> glib-2.0.vapi:967.28-967.43: error: Access to instance member `length' from nullable reference denied
[10:37] <seb128> 		if (str_array != null || str_array.length > 0 || (str_array.length == -1 && str_array[0] != null)) {
[10:37] <seb128> could be a glib issue as well
[10:37] <seb128> Laney, desrt: ^ do you know?
[10:42] <Sweet5hark1> seb128: well, we will SRU 4.2.4 now, given the latency of SRU, I think we skip 4.2.5 (PPA only), so the next earliest trusty SRU will be 4.2.6 (August, 3) or 4.2.7 (October, 20), so no hurry there.
[10:49] <Laney> seb128: looks like a vala bug
[11:01] <seb128> Sweet5hark1, ok
[11:02] <seb128> Laney, hum, k, wouldn't be vala if things would be stable and working I guess
[11:02] <Laney> indicator-keyboard turns on an experimental feature
[11:02] <Laney> which is apparently buggy with something in the glib vapi
[11:02] <Laney> gnome bug #728656
[11:03] <seb128> that was working in trusty
[11:03] <seb128> I wonder if that's a regression in vala itself
[11:03] <Laney> it is, that's what I said
[11:03] <seb128> or if glib changed and makes it unhappy
[11:03] <Laney> no
[11:03] <Laney> it is a change to the vapi
[11:03] <seb128> k
[11:05] <Sweet5hark1> ricotz: btw I just copied the 4.3.0~beta2 to libreoffice-prereleases. Note that version is still quite unstable for me (thus the disabled tests). Feel free to backport to trusty though.
[11:06] <Sweet5hark1> ricotz: _If_ you backport, I would be interested if its more stable on trusty: e.g. do the tests succeed although they fail on utopic.
[11:08] <Sweet5hark1> ricotz: Or if (simple testcase) 1/ opening writer 2/ typing "dt<F3>" for the delauft dead text crashes office like it does on utopic ;)
[11:11] <ricotz> Sweet5hark1, hi, i see, in case of 4.3 i will wait for the rc1 :)
[11:12] <Sweet5hark1> ricotz: which was tagged today ;) -- I will try to get a build of that still, but be aware I will be on vacation next week, so if there is no build on Friday there likely wont be one for some time ;)
[11:13] <ricotz> Sweet5hark1, alright, i will keep that in mind ;)
[12:24] <desrt> seb128: looks like they're stepping up vala's null checking
[12:25] <desrt> that might be my fault -- but only very very indirectly :)
[12:25] <ricotz> Sweet5hark1, the missing l10n package for 4.3b2 is intended?
[12:25] <seb128> desrt, hey
[12:25] <seb128> desrt, Laney pointed to http://bugzilla.gnome.org/show_bug.cgi?id=728656
[12:25] <ricotz> seb128, desrt, hey :)
[12:25] <seb128> desrt, do we have anyone we can ping to get vala patches reviewed? ;-)
[12:26] <Laney> it doesn't compile, as the comment notes
[12:26] <desrt> yes.  Leathalman or nemequ.
[12:26] <desrt> or ricotz sometimes :)
[12:26] <Laney> fix compiler plz
[12:26] <seb128> hey ricotz
[12:26] <desrt> poke the bug and let evan know you're in trouble
[12:26] <seb128> ricotz, ^ do you have any opinion on that bug?
[12:28] <ricotz> desrt, better test it against the broken snippet and poke nemequ
[12:28] <seb128> attente, ^ can you do the comment/poking, since it's your code, you might be in a better position to discuss the issue and possible changes or workarounds?
[12:29] <Laney> tried to work around it but all I did was create a segfault :P
[12:30] <Sweet5hark1> ricotz: pretty much. There is one in my staging ppa, if you want it. But a/ it ran out of disc space b/ at beta2 l10n is incomplete anyway, so I didnt bother too much.
[12:30] <ricotz> Sweet5hark1, ah ok
[12:31] <desrt> seb128: i poked in vala.... let's see if they have anything to say over the next littl ewhile
[12:31] <desrt> otherwise i can start looking closer myself
[12:32] <seb128> desrt, thanks
[12:32] <larsu> desrt: morning :)
[12:32] <desrt> larsu: hi :D
[12:32]  * larsu is patching gtk this afternoon
[12:36]  * didrocks streches his hairs on issubclass in python :/
[12:37] <seb128> larsu, https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-12&id=30e07a1f3df53d84e72440bde1a1bdef6db5e5d2 ... the since doesn't match the serie, not sure what's the rule for such backports?
[12:39] <larsu> seb128: ah, good point, I don't know what the rule is. Let's wait for desrt to yell at me
[12:39] <seb128> lol
[12:40] <desrt> looks good to me :)
[12:40] <desrt> i'm not sure what else you'd put there....
[12:41] <seb128> desrt, you could put 3.12.3
[12:41] <seb128> or that doesn't work?
[12:41] <seb128> desrt, it's weird to have a 3.12 release have a since that is > 3.12
[12:42] <seb128> "it's there, and yet it was added in a version newer than the one you are using and has it"
[12:42] <desrt> seb128: we only put major versions for since tags
[12:42] <desrt> and it's obviously not since 3.12
[12:42] <desrt> i guess the real answer here is "don't add API to the stable branch" :)
[12:44] <seb128> heh
[12:49]  * seb128 wonders how many lines didrocks had in buffer with that copy
[12:50] <larsu> seb128: a full jpeg, base64 encoded
[12:50] <seb128> we could be there all day long
[12:50] <seb128> didrocks, close you IRC, or reconnect!
[12:50] <larsu> ya... if only someone was operator
[12:50] <didrocks> seb128: really, still sending it for you?
[12:50] <seb128> didrocks, yes
[12:50] <larsu> didrocks: yes.
[12:50] <didrocks> tried to disconnect
[12:51] <seb128> didrocks, thanks
[12:51] <seb128> that worked
[12:58] <didrocks> phew, defeated issubclass()! \o/
[12:58] <Sweet5hark1> didrocks: What was the finishing move?
[12:58] <mterry> seb128, architectures!  Can't live with em, can't live without em
[12:59] <seb128> mterry, good morning! sorry you have to wake up to that again today!
[12:59] <didrocks> Sweet5hark1: forcing with importlib reloading some modules, however, not sure it's all 100% set
[13:00] <mterry> seb128, should be an easy fix
[13:00] <seb128> mterry, ;-)
[13:00] <Sweet5hark1> seb128, ricotz: by the way, since I will be on vacation soon you might negotiate the debian sync/MIR for librevenge. ricotz wrote most of the rationale already and I dont have any powe to MIR, sponsor or sync anyway :>
[13:01] <seb128> Sweet5hark1, oh, I had a comment earlier ... is there good content is 3.4.5?
[13:01] <seb128> shrug, 4.2.5 I mean
[13:01] <seb128> Sweet5hark1, you mentioned skipping it, but 4.2.6 is going to be after LTS .1
[13:01] <seb128> so we should maybe try to get .5 in there?
[13:02] <Sweet5hark1> well, some ~100 bugfixes as usual: https://wiki.documentfoundation.org/Releases/4.2.5/RC1 and https://wiki.documentfoundation.org/Releases/4.2.5/RC2
[13:02] <Sweet5hark1> seb128: but: it needs a mdds update or shipping our own copy ...
[13:03] <seb128> Sweet5hark1, well, that's going to be the same for .6 no?
[13:03] <Sweet5hark1> of course, thats also true for 4.2.6/7 but I didnt race for that SRU now for that reason.
[13:04] <seb128> shipping a copy sounds fine to me, if needed
[13:04] <Sweet5hark1> seb128: yep.
[13:04] <seb128> well, you are the one looking after lo
[13:04] <seb128> but I think having more bugfixes in the LTS .1 (which is when LTS users are prompted for upgrade) makes sense
[13:06] <Sweet5hark1> seb128: ok, well. 4.2.5~rc2 is in the PPA. Its gonna be 4.2.5 final on Thursday by upstream. If its been 2 weeks in the ppa without any reported regressions we can throw that version over the fence as SRU after my vacation.
[13:06] <seb128> Sweet5hark1, ok, your call
[13:06] <Sweet5hark1> well, maybe with the l10n stuff for swedish? dictionaries on top.
[13:09] <mterry> seb128, branch updated
[13:11] <seb128> mterry, looking
[13:12] <didrocks> ok, finally defeated now :)
[13:13] <mterry> seb128, btw, hardcoding 1 instead of using the symbol is what unity8 does.  I was trying to be more proper, this is what I get.  ;)
[13:13] <Laney> found a workaround for that vala bug btw
[13:13] <seb128> Laney, nice!
[13:13] <Laney> will update post-lunch
[13:13] <Laney> i-keyboard needs another non-null fix too
[13:14] <seb128> let's wait for attente to be around for that
[13:14] <Laney> lib/main.vala:802
[13:14] <seb128> or feel free to mp those fixes and he can review/ack them then
[13:14] <Laney> will do if someone else doesn't, that's the location
[13:14] <Laney> state can be null
[13:14] <Laney> biab
[13:16] <attente> seb128, Laney: hey
[13:17] <seb128> attente, hey
[13:17] <attente> i could just disable the experimental non-null falg
[13:17] <attente> *flag
[13:18] <seb128> well, I guess you turned that on for a reason?
[13:18] <pitti> seb128, Laney: btw, yesterday's u-next image boots fine here
[13:19] <pitti> seb128, Laney: in some way it's even more depressing as so many things (wifi, browser, weird mouse, etc.) are not yet working, but good to see Mir working :)
[13:20] <pitti> so, great job!
[13:20] <attente> only for strict null checking
[13:21] <seb128> attente, k, well your call on how you want to fix it, seems like Laney has a workaround for the vala bug, so that would work as well, let's wait for him to be back
[13:22] <seb128> pitti, wifi is just an small fix to indicator-network's upstart job, I'm going to mp that today
[13:22] <pitti> seb128: oh, nice
[13:22] <attente> oh, i see that problem
[13:22] <pitti> indeed I didn't see that at all
[13:22] <attente> i thought it was the glib vapi problem
[13:22] <pitti> seb128: do you know, is the browser not working due to being offline?
[13:22] <attente> i'll fix it
[13:23] <seb128> pitti, no, it's an issue with the elg backend and mir, chrisccoulson said he has a workaround, I tried to ping him to know when that's planned to land but he didn't pong yet
[13:23] <seb128> chrisccoulson, hey ;-)
[13:23] <seb128> attente, thanks
[13:26] <attente> happyaron: hi, the packages in the ppa just allow adding fcitx input methods the same way that ibus ones can be added
[13:28] <seb128> pitti, you can edit /usr/share/upstart/session/indicator-network.conf and change the "xubuntu-touch" to "xunity8-mir" and "start indicator-network" then
[13:28] <pitti> seb128: is there a way to get a terminal under Mir?
[13:28] <pitti> we apparnetly don't install terminal-app, or gnome-terminal
[13:33] <attente> seb128: we still need the bugzilla patch to vala though
[13:38] <chrisccoulson> hi seb128
[13:39] <seb128> pitti, bregma has one, I think he rebuilt the click for amd64 or something
[13:39] <seb128> attente, Laney is on that
[13:39] <seb128> chrisccoulson, hey! how are you?
[13:39] <chrisccoulson> seb128, yeah, not too bad thanks
[13:39] <seb128> chrisccoulson, do you have any idea when you webbrowser-app on unity8-mir-desktop fix is going to land?
[13:40] <chrisccoulson> the unity8 fixes were going to be in the next release (ie, not the current 1.0 release which is also being pushed to trusty shortly)
[13:40] <chrisccoulson> I guess I could backport them, but they depend on other changes as well, which is why I've not done it yety
[13:40] <chrisccoulson> *yet
[13:41] <bregma> pitti, use the terminal app from https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily
[13:41] <pitti> seb128: in theory, gnome-terminal should even work, no?
[13:41] <seb128> chrisccoulson, is the issue in unity8? I though you said it was in your bindings?
[13:41] <pitti> seb128: or does vte not get along with Mir?
[13:41] <pitti> bregma: ah, thanks
[13:42] <seb128> pitti, no it doesn't, we don't even have GTK/Mir landed yet
[13:42] <chrisccoulson> seb128, yeah, that's right
[13:42] <seb128> chrisccoulson, which one is right?
[13:42] <chrisccoulson> seb128, the fixes are in oxide
[13:43] <chrisccoulson> although the bug is caused by missing features in the mir egl backend in mesa ;)
[13:43] <bregma> chrisccoulson, is there a bug files against Mir?  This is a major blocker for unity 8 on desktop
[13:45] <seb128> chrisccoulson, do you plan to land those fixes soon?
[13:46] <seb128> pitti, oh, other desktop-next issue... what do you think we should do with langpacks there? use the touch ones?
[13:47] <pitti> seb128: if we intend this to allow installing debs, they should get the full ones IMHO
[13:48] <seb128> pitti, but are the "full ones" going to include things like the dialer or messaging app that are for unity8 only?
[13:48] <pitti> seb128: yes, they already do
[13:48] <seb128> k
[13:49] <seb128> pitti, btw, you getting the text plymouth logo is because the ubuntu-logo is not seeded (we started from the touch seed and they don't use plymouth there because it has issues on the phone stack)
[13:49] <seb128> I'm going to seed that one
[13:49] <pitti> seb128: ah, thakns
[13:50] <seb128> I just looked at that a bit earlier
[13:50] <seb128> yw!
[13:50] <chrisccoulson> seb128, they'll end up in the archive when we branch from trunk again (ie, when the next chrome release happens). I guess they could be applied as a distro patch to utopic, but I've not applied them to the current 1.0 release branch as they depend on 2 other disruptive patches and we're close to pushing this out as a security update to trusty
[13:51] <chrisccoulson> ie, the 4 changesets to make it work in unity 8 really also depend on http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/revision/587 and http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/revision/586 to apply cleanly
[13:51] <seb128> chrisccoulson, do you know when the next branching from trunk is likely to happen?
[13:52] <chrisccoulson> seb128, quite soon according to http://www.chromium.org/developers/calendar
[13:52] <chrisccoulson> it says this week, but I'm not sure if that's entirely accurate
[13:53] <seb128> chrisccoulson, ok, thanks
[14:02] <seb128> chrisccoulson, that sounds fine, I just wanted to make sure it's not "going to take ages before flowing back to distro"
[14:02] <chrisccoulson> seb128, yeah, it won't take ages :)
[14:15] <Laney> hey
[14:15] <seb128> Laney, wb!
[14:15] <Laney> cheers!
[14:16] <Laney> attente: yo, how's it going?
[14:16] <Laney> did you fix the line I pointed out?
[14:18] <seb128> kenvandine, hey
[14:18] <seb128> kenvandine, how are you?
[14:18] <seb128> kenvandine, do you have some free slots to discuss online account plugin packaging issues?
[14:22] <attente> Laney: hey, thanks, i proposed it here: https://code.launchpad.net/~attente/indicator-keyboard/use-get-state-instead, but it still needs the upstream vala patch
[14:22] <Laney> ya
[14:22] <Laney> lemme just put my workarounded version up
[14:25] <mterry> seb128, after this landing, I'm inclined to consider turning on the wizard -- any objections?
[14:26] <seb128> mterry, I need to do another round of testing, but no objection in principle no
[14:26] <mterry> seb128, cool.  And yeah, we'd probs have extra testing before flipping that switch
[15:01] <seb128> mterry, ok, so ... could you bump your changelog to 0.3? ;-)
[15:01] <nessita> didrocks, hola! hangout link added to the invite
[15:01] <mterry> seb128, looking
[15:02] <didrocks> nessita: hey, excellent ! fetching :)
[15:02] <seb128> mterry, thanks, and sorry about that
[15:02] <seb128> mterry, in fact we had the mp in a previous silo, and we reconfigured keeping the ppa, so we had the version bumped in that landing
[15:02] <seb128> mterry, https://launchpad.net/ubuntu/+source/ubuntu-system-settings/0.2+14.10.20140612-0ubuntu1
[15:02] <seb128> mterry, so we need to bump to 0.3 this time
[15:03] <mterry> seb128, ok, merged from trunk and bumped version
[15:03] <seb128> mterry, thanks
[15:11] <Saviq> seb128, charles, do we have an update on the session indicator for logging out?
[15:12] <seb128> Saviq, charles said earlier that he should have a fix today
[15:12] <Saviq> oh great
[15:12] <seb128> Saviq, I was pondering giving the silo back otherwise
[15:12] <charles> Saviq, I'm the holdup there. Fix should be today, as seb128 said
[15:12] <seb128> but let's see how that goes
[15:12] <Saviq> I'll rebuild unity8 there then, since we've landed things in between
[15:13] <seb128> Saviq, thanks
[15:13] <seb128> Saviq, btw, is suru ever going to land? ;-)
[15:16] <seb128> larsu, sorry, dropped your question from earlier ... are those gtk changes needed to fix the invisible gtkpopover widgets?
[15:17] <larsu> seb128: yes
[15:17] <larsu> seb128: I've linked the branches to the bug
[15:17] <seb128> larsu, ok, I'm going to backport them then
[15:17] <seb128> larsu, danke
[15:17] <larsu> seb128: actually, there'd be an easier fix, but I thought I'd do it right
[15:18] <seb128> larsu, what happens if we land the theme fix before the gtk one? does it create any other issue or just doesn't work?
[15:18] <larsu> thanks!
[15:18] <larsu> seb128: no other issue. It's just css
[15:18] <seb128> k
[15:18] <larsu> the rules won't apply to anything
[15:18] <seb128> so I'm putting a theme landing with some of the pending fixes as well
[15:18] <larsu> sounds good to me
[15:18] <seb128> larsu, should https://code.launchpad.net/~larsu/ubuntu-themes/lp1318821/+merge/219351 be deleted or rejected?
[15:18] <seb128> you just comment disapproved, but it's still in the list
[15:20] <larsu> should be deleted. I'll mark the branch as abandoned
[15:20] <larsu> I hope that removes it from the list
[15:20] <larsu> oh, it already is
[15:20] <larsu> I'll delete the mr then
[15:24] <seb128> thanks
[15:26] <seb128> larsu, I did resubmit the gtk change because gtk/ubuntu is gtk2, gtk/ubuntugtk3 is gtk3, it was targetting the wrong one
[15:27] <larsu> seb128: I will never get this right :/
[15:27] <larsu> thanks for fixing it
[15:27] <seb128> larsu, not your fault, we should probably change those series and made "gtk" the default one and gtk2 the weirdly named one
[15:46] <didrocks> larsu: I don't want to tell who, but people here who-was-elected-to-be-a-manager-by-the-team used harsh words like "CI Train" bugs where it's a feature for a corner case!
[15:46] <didrocks> the system even tells you that: 2014-06-12 16:35:56,147 INFO A version in the ppa (0.2+14.10.20140611-0ubuntu1) is higher than the proposed version in bzr (0.1+14.10.20140606-0ubuntu1) (previous tests/builds failing?). Basing on that one.
[15:47] <didrocks> on https://ci-train.ubuntu.com/job/landing-001-1-build/77/console, but don't look at who launched that build, it's the same unamed person who dared telling it was a possible bug in MY code! :)
[15:48] <seb128> lol
[15:49] <larsu> haha
[15:49] <seb128> didrocks, be nice, the same someone might manage to find a real bug in your code
[15:49] <seb128> wouldn't be the first time :p
[15:49] <didrocks> seb128: I would answer "not my problem anymore", you know, it's completely my behavior :)
[15:50] <seb128> heh
[16:01] <seb128> kenvandine, hey, moving here
[16:02] <kenvandine> hey
[16:02] <kenvandine> i'll be out for 2 weeks
[16:02] <seb128> kenvandine, so the issue was that unity8-desktop gets unity-control-center pulled in by libaccount-plugin
[16:02] <kenvandine> ugh
[16:02] <seb128> that's because e.g account-plugin-evernote depends on libaccount-plugin
[16:02] <seb128> could we make that a | u-s-s-o-a?
[16:03] <seb128> I saw some plugins have that
[16:03] <kenvandine> most likely...
[16:03] <seb128> but they ship some qml as well
[16:03] <seb128> which evernote doesn't do
[16:03] <kenvandine> i seem to recall some account plugins really needed that
[16:03] <kenvandine> actually, i don't think so anymore
[16:03] <kenvandine> the lib provided some of the common oauth stuff
[16:03] <kenvandine> but that got refactored out
[16:03] <seb128> so we could just add the | u-s-s-o-a there?
[16:04] <kenvandine> yeah
[16:04] <kenvandine> wb
[16:04] <kenvandine> :)
[16:04] <kenvandine> yes, that should be fine
[16:04] <kenvandine> iirc
[16:04] <seb128> kenvandine, sorry, hit ctrl-r on the wrong win
[16:04] <seb128> (hate that)
[16:04] <seb128> the oauth plugin has the same issue
[16:04] <seb128> depends on libaccount-plugin-1.0-0
[16:05] <seb128> which recommends u-c-c
[16:07] <seb128> kenvandine, thanks
[16:09] <kenvandine> seb128, you mean account-plugin-google or libaccount-plugin-google ?
[16:09] <seb128> kenvandine, account-plugin-generic-oauth
[16:10] <seb128> that depends on libaccount-plugin-1.0-0
[16:10] <seb128> which recommends unity-control-center-signon
[16:11] <kenvandine> yeah, ok i think that will work there
[16:11] <seb128> k, thanks
[16:11] <kenvandine> np
[16:13] <tsdgeos> guys, does https://code.launchpad.net/~agateau/libdbusmenu-qt/build-with-clang/+merge/223507 need CI-train'ing to land? or will it just autoland?
[16:16] <seb128> tsdgeos, it needs a lander, I'm happy to do that
[16:16] <seb128> tsdgeos, would be nice to batch https://code.launchpad.net/~agateau/libdbusmenu-qt/define-include-dir/+merge/223509 with it
[16:16] <tsdgeos> seb128: yeah, i'm waiting on someone with enough autority to ok the cmake version increase :D
[16:16] <tsdgeos> i was thinking on Pete
[16:17] <tsdgeos> since he is the one with the last two commits in there
[16:17] <seb128> tsdgeos, can you maybe ping him then?
[16:17] <tsdgeos> but then he's on holiday
[16:17] <seb128> oh
[16:17] <tsdgeos> until next week
[16:17] <tsdgeos> and i'm on holiday next week
[16:17] <seb128> Saviq, maybe?
[16:17] <tsdgeos> so it's a bit of a mess :D
[16:19] <tsdgeos> i'd say he's busy with more important things
[16:19] <seb128> right
[16:19] <seb128> so either we trust agateau and ack that and land it
[16:19] <tsdgeos> i kind of am too
[16:19] <tsdgeos> i'm just waiting for the phone image to install :D
[16:19] <seb128> or we land the other fix and delay that other one for another landing
[16:20] <tsdgeos> seb128: it does work, i've tried it, it's just if we're ok with dependeing in a newer cmake, i guess we are since we're shipping it
[16:20] <seb128> k
[16:20] <tsdgeos> so i'll approve i guess
[16:20] <seb128> let me approve it
[16:20] <seb128> we can always revert later if that's an issue
[16:20] <tsdgeos> cool
[16:20] <tsdgeos> tx
[16:20] <seb128> yw
[16:27] <seb128> mterry_, congrats on landing the wizard binary ;-)
[16:27] <mterry_> seb128, haha, thanks for your help
[16:28] <seb128> yw!
[16:50] <seb128> calling it a day
[16:50] <seb128> have a nice evening desktopers
[16:50] <seb128> see you tomorrow
[16:57]  * didrocks does the same
[16:57] <didrocks> see you guys :)
[16:59] <Laney> these continentals clocking off early!
[21:14] <robert_ancell> desrt, around?
[21:35] <desrt> robert_ancell: hi
[21:36] <robert_ancell> desrt, I'm blogging about GTK+ Mir, what's worth saying about the jhbuild stuff?
[21:41] <desrt> that mir is available and we're setup for when the branch lands
[21:41] <desrt> which is really the more interesting question
[21:42] <desrt> when do you think we should land the branch?
[21:42] <desrt> might make sense to land some initial version of it and keep working in the branch?
[21:42] <desrt> or switch over to master development entirely?
[21:43] <desrt> if you feel ready, we should start discussing that ...
[21:44] <robert_ancell> desrt, I guess it matters more how upstream feels about it - the branch is not particularly useful as it is, but that might not matter
[21:44] <robert_ancell> And it works better for us to be based off 3.12 because that's how we'll ship it
[21:45] <desrt> i suspect gtk won't care very much
[21:45] <robert_ancell> So we would need to maintain two branches
[21:45] <desrt> hmm
[21:46] <desrt> one thing that will not happen: landing the backend onto the existing stable branch :)
[21:47] <larsu> because how would we know which Since: tag to put on there...
[21:49] <desrt> larsu: :)
[21:49] <robert_ancell> well, yes
[21:50] <robert_ancell> desrt, can we get jhbuild to build from a branch?
[21:50] <desrt> yes
[21:50] <desrt> but if we want to take that approach then we should probably backport the mir setp to the gnome-3-12 jhbuild modulesets
[21:51] <desrt> since it builds everything out of 3.12....
[21:51] <robert_ancell> It sounds like it would make most sense to have jhbuild automatically testing against our 3.12 branch, then after 14.10 move development to master and bring the updates into ubuntu as we update GTK+
[21:51] <robert_ancell> and have jhbuild testing from trunk from then on
[21:52] <desrt> this is a bit odd
[21:52] <desrt> our intention is to maintain this upstream
[21:52] <desrt> but we lag upstream by enough that we're going to want to be doing manual merges of all the work we're doing there
[21:53] <robert_ancell> desrt, I just mean we wait one cycle before moving to master
[21:53] <desrt> we're going to have to do the work one way or the other, so why don't we just do it the usual way?  (ie: backporting)
[21:53] <robert_ancell> because there is likely to be significant changes required to backport if the GDK api changes
[21:54] <desrt> last time i checked, that wasn't the case
[21:54] <desrt> although i guess it's going to be getting worse this cycle...
[21:54] <robert_ancell> exactly
[21:54] <robert_ancell> And right now it's better to get it working well before tackling those changes
[21:54] <desrt> fair enough
[21:56] <robert_ancell> desrt, so I was going to say "we have support in jhbuild for Mir so we can automatically test our changes going forward" (+ a link to the git commit). Anything else worth mentioning?
[21:57] <desrt> not particularly
[21:57] <robert_ancell> mkay
[21:57] <desrt> thanks :)
[21:59] <robert_ancell> desrt, oh, I had another question you might know the answer to - is there a reason why we don't have a pam-xdg that starts the session bus etc rather than using Xsession?
[22:02] <desrt> because the way we do it now was the easiest way?
[22:02] <desrt> this is going to be fixed by systemd soon....
[22:02] <desrt> the bus will be at a well-known path relative to the xdg runtime dir and will be demand-activated
[22:18] <robert_ancell> desrt, so it will be controlled by logind?
[22:19] <robert_ancell> desrt, and I was wondering if that would mean we have a bus for text logins and if that's a good/bad thing
[22:19] <desrt> robert_ancell: by systemd, not logind
[22:20] <robert_ancell> desrt, there must be some interaction with logind to only allow session busses for each active session
[22:20] <desrt> robert_ancell: of course.... the xdg runtime dir doesn't even exist unless logind says it does
[22:20] <desrt> but it will be systemd holding the other end of the socket
[22:21] <robert_ancell> which part of systemd - init?
[22:21] <desrt> the session systemd instance
[22:21] <robert_ancell> ah
[22:21] <robert_ancell> k
[22:44] <desrt> X-Ubuntu-Touch=true ?
[22:44]  * desrt mumbles
[22:45] <desrt> would be better to expose this as an interface...
[22:47] <robert_ancell> desrt, that's how it is now
[22:47] <desrt> ifuncs are ruining my life :(
[22:50] <desrt> calling getenv() from inside of them appears to be a great way to confuse the libc into crashing
[22:52] <desrt> the sick thing is that i bet i could get away with opening /proc/self/environ and parsing it