[07:26] <seb128> good morning desktopers!
[07:26] <pitti> bonjour seb128
[07:26] <pitti> bonjour tout le monde
[07:26] <seb128> pitti, hey, wie gehts?
[07:26] <pitti> seb128: geht so -- ich habe bis um 1:00 gehackt :)
[07:26] <pitti> seb128: et toi ?
[07:27] <seb128> ça va bien !
[07:27] <seb128> what did you hack on?
[07:27] <seb128> oh, systemd
[07:28]  * seb128 just reading g+
[07:29] <larsu> hehe
[07:29] <larsu> good morning!
[07:37] <seb128> hey larsu
[07:37] <seb128> hey dednick
[07:47] <dednick> seb128: hi
[07:48] <seb128> dednick, how are you today?
[07:50] <dednick> seb128: fine thanks. you? taken a look at the usc branch. wondering why we're doing this rather than supporting translations.
[07:50] <dednick> seb128: since the only branch to change is usc.
[07:50] <seb128> dednick, Saviq was arguing that usc shouldn't have translations for some reasons
[07:50] <seb128> dednick, it's also a smaller change/easier/give us a translated string, so works better for rtm
[07:51] <dednick> seb128: well, this isn't really any diff. I think Saviq was arguing that we shouldn't have translatable strings at all
[07:51] <seb128> dednick, if we enable translations in usc now the langpacks are going to miss the string and it's going to take some time before it's there and used
[07:52] <seb128> dednick, I'm fine working on enabling translations in usc next, that just seems the best rtm friendly solution
[07:52] <dednick> seb128: if we're changing u8 to translate the "Call back" and "Send" strings, i'd rather put a passthrough property to that "Reply" string which u8 needs to set
[07:53] <dednick> seb128: this bug isn't going to get rtm'ed though is it? it's not on the critical list
[07:53] <seb128> dednick, https://code.launchpad.net/~tiagosh/telephony-service/add-translation-strings/+merge/240643
[07:54] <seb128> dednick, I'm going to ask Pat about it, that's a visible string and bq ships in a non english country
[07:54] <seb128> it's going to be at least ota1 I guess
[07:55] <dednick> seb128: ok.
[07:55] <dednick> seb128: i think the u8 fallback strings need to be translated anyway.
[07:55] <seb128> dednick, well, feel free to reject, but as said that's a temporary workaround until we properly enable translations
[07:55] <seb128> dednick, ok, I can mp that as well
[08:01] <didrocks> morning
[08:01] <seb128> lut didrocks, en forme ?
[08:01] <dednick> seb128: cool. in that case, can you add a property to the usc SnapDecision for the replyPlaceholderText ? and override in u8?
[08:02] <seb128> dednick, ok, rather than enabling translations in usc?
[08:02] <didrocks> seb128: toujours en train de tousser :/ mais sinon, ça va, et toi ?
[08:02] <dednick> seb128: yah. there are still some requests for translations in there, but for the quick fix i think it's better.
[08:02] <seb128> didrocks, ça va bien, merci !
[08:03] <dednick> seb128: should probably just remove the default strings all together from usc.
[08:03] <seb128> dednick, well, the easiest one is the one I proposed ... you don't want that in as step1 ?
[08:03] <seb128> dednick, it's the only solution that is going to give us a translated string on the UI without needing a langpacks update
[08:04] <seb128> we can do the proper one in vivid then
[08:04] <dednick> seb128: need to update the lang packs for the other strings though.
[08:04] <seb128> yeah, but 1 is better than nothing
[08:04] <seb128> and that's a cheap one liner
[08:06] <pitti> seb128: systemd-shim to be precise
[08:06] <pitti> Laney: I tested gnome-terminal from the PPA, profile migration still doesn't work at all
[08:06] <seb128> pitti, yeah, saw your post
[08:06] <dednick> seb128: heh. if we're landing 2 packages and lang packs, is 3 much worse?
[08:06] <seb128> shrug
[08:06] <pitti> Laney: with 3.6 and no gconf I switched the color schema (black on yellow) and a smaller font, then upgraded, restarted g-t, it was back on the defaults (white on black, big font)
[08:07] <dednick> you could use the domain translate in u8 if you really want :)
[08:07] <seb128> dednick, the point is that I doubt we are going to have an unity8 or langpack landing for rtm
[08:07] <seb128> but well, I feel like I spent more time trying to argue than 1 liner than it's worth it
[08:07] <dednick> seb128: as far as i know, there's loads of u8 langing
[08:07] <seb128> so your call
[08:07] <dednick> landing
[08:07] <seb128> it's a 1 char change
[08:07] <seb128> tr->dtr
[08:08] <seb128> not sure why you push back so much on it
[08:08] <dednick> seb128: because we have to change it later!
[08:08] <seb128> we have to do another changeset to enable translation anyway
[08:08] <seb128> which I'm working on
[08:08] <seb128> and which is going to revert the workaround
[08:09] <seb128> but meanwhile it doesn't hurt to land the workaround
[08:09] <seb128> imho
[08:09] <dednick> seb128: bah. whatever. ok, as long as you do the mps to fix properly now as well.
[08:09] <seb128> yeah, that's on my todolist
[08:10] <seb128> dednick, so do you think translations in usc are needed?
[08:10] <seb128> there are more strings with i18n.tr()
[08:10] <seb128> not sure they are used anywhere though
[08:10] <dednick> seb128: no, they shouldn't be
[08:10] <seb128> or would you just do the property thing and let unity8 define that?
[08:10] <dednick> ya. property thing. all the strings are context sensitive
[08:10] <seb128> k
[08:11] <seb128> what happens if unity8 tries to use a non existant property?
[08:11] <seb128> or asked differently, do we need to land usc before/in sync with unity8?
[08:11] <dednick> seb128: hm. i think so. i think the component may not load
[08:11] <dednick> cant remember
[08:12] <seb128> I'm going to try
[08:12] <seb128> but I might just land usc first
[08:12] <dednick> or just get a "property does not exist"
[08:12] <seb128> then update unity8
[08:12] <seb128> easier than trying to land them in sync
[08:13] <dednick> seb128: ok. well the u8 one should technically not be needed at this point since the telephony-service is proving the "Send" & "Call back" strings now
[08:13] <seb128> right
[08:13] <seb128> but I mean for the proper fix
[08:13] <dednick> ok
[08:13] <seb128> 1. add the property to usc
[08:13] <seb128> 2. make unity8 set it
[08:13] <dednick> yup
[08:14] <seb128> dednick, thanks for the discussion
[08:14] <seb128> I'm going to work on that/put mps up for review
[08:14] <dednick> seb128: sorry for the arguement :)
[08:14] <seb128> no problem!
[08:31] <seb128> dednick, can you change the mp status to approved as well, for the workaround
[08:32] <dednick> seb128: done
[08:32] <seb128> thanks
[08:59] <willcooke> morning
[09:00] <didrocks> hey willcooke
[09:02] <Laney> hey hey
[09:03] <seb128> hey ukers
[09:03] <seb128> how are you?
[09:04] <seb128> willcooke, the fix for the unity8 lockscreen/liveCD issue landed in vivid, we can update whatever instructions you had which suggested the "go to vt, change password" workaround
[09:04] <seb128> didrocks, ^ fyi
[09:04] <willcooke> seb128, excellent, thanks!
[09:05] <willcooke> mhall119, we can remove the note from your blog post ^^^
[09:05] <seb128> willcooke, didrocks, also, workaround for non starting unity8 is to remove qtubuntu-media
[09:05] <willcooke> yeah, I saw conversations about that - very strange
[09:05] <seb128> they are working on a proper fix
[09:05] <seb128> but meanwhile
[09:06] <seb128> willcooke, not so strange, it's back to the conversation we had in Washington with Jim, media-hub needs to be made to work on desktop as well
[09:06] <seb128> though yeah, weird that it segfaults now when it was working
[09:06] <willcooke> seb128, it sounded like Jim expected us to port media hub?
[09:06] <seb128> well, you sort of told him we would do it...
[09:07] <seb128> or that we could have a look
[09:07] <seb128> imho we don't have the cycles to handle that
[09:07] <willcooke> I agree
[09:07] <didrocks> seb128: ah removing then!
[09:11] <seb128> dpm, hey, can you review https://code.launchpad.net/~seb128/ubuntu-system-settings/build-translations-template/+merge/240696 ? if/when that lands, what do we need to change to the project setup so it prefers the ubuntu template to the trunk one?
[09:21] <Laney> pitti: ah, it seems to be a problem with the default profile
[09:22] <Laney> http://people.canonical.com/~laney/weird-things/g-t.mp4 <- non-"Default" working
[09:24] <larsu> (a) transparent terminal?!
[09:24] <Laney> best feature ever
[09:24] <larsu> (b) why is that profile dialog so wide?
[09:24] <larsu> another wide-window bug I haven't caught yet?
[09:24] <Laney> i'm running gtk 3.14 there
[09:24] <Laney> also I had to hack the .ui file to get the profile dialog to open ...
[09:25] <Laney> Invalid property: GtkHScale.update_policy on line 2311
[09:26] <larsu> hm, I wonder if that was ever a property...
[09:28] <larsu> gtkrange apparently had it in the 1.x days
[09:28] <larsu> ah, 2.x as well
[09:28] <larsu> makes sense
[09:30] <larsu> Laney: master doesn't have that
[09:31] <Laney> I know
[09:31] <Laney> but the gnome-terminal we have in the archive does
[09:31] <larsu> gnome-3-14 branch also doesn't
[09:31] <larsu> do you know where that comes from?
[09:31] <Laney> we have 3.6
[09:32] <larsu> oh, in _that_ version, right
[09:49] <dpm> seb128, reviewed and added a comment
[09:50] <seb128> dpm, thanks, that came before and is probably something we should look at
[09:53] <dpm> seb128, as per the question of the project setup, there is nothing you need to change really. Optionally, you can disable the upstream translations, if you want, but if you could leave enabled there for a while, you'd do me a favour, as the stats page cannot yet count the stats from source packages, as I'm pending on an export from LP
[09:54] <seb128> dpm, well, since the translations are shared, what template is going to "win"?
[09:54] <dpm> seb128, ah, no template "wins" - it doesn't matter where you do the translation, they are changed instantly on both sides
[09:55] <seb128> dpm, right, but what if the template in trunk is outdated and the one in ubuntu has extra strings?
[09:55] <seb128> do we get 2 different lists depending of where you go on launchpad?
[09:55] <seb128> isn't that going to confuse translators?
[09:57] <dpm> seb128, ah, sorry. So there are two templates then, and only the identical strings are shared. But as soon as both templates are in sync, then the translations are fetched from the database and populated on both sides. Indeed, it's not an ideal situation, that's why I'm asking for it to be temporary.
[09:58] <seb128> k
[09:58] <seb128> dpm, I though it would make sense to disable the trunk template and use the ubuntu one as shared to avoid the confusion
[10:01] <dpm> seb128, yeah, but if you could leave it there for a while, that'd be great, as u-s-s takes a big chunk of the translations stats. I'm trying to get a stats export from LP to get the stats counted from the source packages, but it's not there yet
[10:01] <dpm> so let me ping Colin about this again
[10:02] <seb128> dpm, ok
[10:02] <dpm> thanks seb128
[10:02] <seb128> yw, thanks for the review!
[10:02] <dpm> np, my pleasure to get more automation in translations :)
[10:16]  * didrocks upgrades to vivid!
[10:17] <didrocks> after doing a lot of removal to avoid getting rpm3 ;)
[10:40] <ochosi> hey folks, quick question, does anybody here know when status.ubuntu.com will switch to V? (it still redirects to -u by default)
[10:40] <Laney> ochosi: maybe dpm knows
[10:41] <ochosi> seb128: btw, thanks for the pointer, robert_ancell said he'll improve the patch for simple-scan
[10:41] <Laney> I think it's his team which does that?
[10:41]  * Laney guesses semi wildly
[10:42] <dpm> Laney, ochosi, I don't know, sorry. It's generally cjohnston who does (or used to do) that
[10:42] <ochosi> ok, thanks Laney :)
[10:43] <ochosi> dpm: used to? i hope you're not abandoning it, it's quite a useful tool to keep an overview
[10:43] <seb128> ochosi, yw!
[10:43] <ochosi> dpm: thanks for the heads up anyway, at least now i know who i should go after :)
[10:43] <seb128> ochosi, don't worry about status, it's not abandoned
[10:43] <seb128> willcooke plans to use it for our team this cycle
[10:43] <ochosi> yeah, was just guessing because i saw that kubuntu doesn't use it anymore
[10:43] <seb128> so he's likely going to make sure that things work
[10:43] <ochosi> ok cool
[10:43] <seb128> ochosi, what is kubuntu using?
[10:43] <ochosi> trello afaik
[10:44] <ochosi> we also evaluated it this cycle vs. launchpad
[10:44] <ochosi> launchpad is really great and blueprints make sense and all, but it feels quite slow and heavy at times
[10:44] <seb128> k
[10:44] <ochosi> but yeah, we still decided to go back to it
[10:44] <seb128> well, the main advantage is that it's integrated in our process
[10:44] <ochosi> its benefits by fair outweigh the performance penalty
[10:44] <seb128> like you can make launchpad bugs part of the blueprint items
[10:44] <ochosi> yeah, exactly
[10:46] <ochosi> i saw a few nice mockups on how to meaningfully integrate the burndown chart in websites targeted at developers/potential contributors
[10:46] <ochosi> would be nice to see something like it on the ubuntu website too
[10:49] <dpm> ochosi, sorry, I didn't mean it like that. I meant "cjohnston used to do it", as in "I don't know if someone else does it now"
[10:50] <ochosi> dpm: ok, thanks :)
[11:03] <Laney> pitti: no, sorry, it's working for the default profile for me now
[11:03] <Laney> maybe someone else could try it and see
[11:20] <Laney> blargggggggggggg
[11:20] <Laney> now it doesn't work
[11:20] <Laney> what is going on here
[11:21] <pitti> Laney: ah
[11:22] <pitti> Laney: yeah, I was pretty sure it worked for me a few weeks ago too
[11:22] <pitti> Laney: where "me" is "fresh user account, do the same config changes in g-t, then upgrade"
[11:22] <pitti> Laney: so, if that's somehow specific to my system, I don't mind reconfiguring my terminal
[11:22] <pitti> but I guess if it happens for most/all users it's a bit awkward
[11:23] <pitti> Laney: if you  have a succeeding case, what's the output of gnome-terminal-migrate? does that say more than just the three lines?
[11:24] <Laney> what's gnome-terminal-migrate?
[11:24] <Laney> I've just been running the server
[11:44] <Laney> haha
[11:44] <Laney> my grep was wrong so I didn't see the binary
[12:03] <mlankhorst> oh seb128 here?
[12:06] <Laney> pitti: aaaaaaha
[12:06] <pitti> Laney: that sounds like enlightenment?
[12:06] <Laney> If you gconftool --recursive-unset
[12:06] <Laney> then it removes /apps/gnome-terminal/global which isn't always recreated
[12:07] <Laney> and if this isn't there the migration doesn't happen
[12:07] <Laney> so in old g-t if I go to Profiles and get that re-created then it migrates
[12:08] <pitti> ah! so gnome-terminal-migration needs to do/fake that?
[12:08] <Laney> maybe it can assume "Default" if there's no value there
[12:09] <Laney> or if there's only one profile then this must be the default one
[12:24] <mlankhorst> who do I poke for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1388738 ? I don't think it's a driver bug. although initially screen cursor is apparantly not set
[12:32] <mdeslaur> seb128: is there a better way of doing this? http://paste.ubuntu.com/8835187/
[12:32] <seb128> hey mdeslaur
[12:32] <mdeslaur> seb128: or is getenv still the good way
[12:32] <mdeslaur> seb128: oh! you just got here, hi!
[12:33] <seb128> mdeslaur, getenv is still the good way, and IRC dropped during lunch not sure why
[12:34] <mdeslaur> seb128: are we getting proper support in vivid soon, or is it worth uploading and SRUing to utopic?
[12:34] <seb128> I didn't look at the gnote ui/code, but for e.g evince we keep the headerbar, we just don't set it as a titlebar and hide the close button, so it becomes a toolbar
[12:34] <seb128> it might make the patch smaller to do that if you can
[12:35] <seb128> mdeslaur, http://bazaar.launchpad.net/~ubuntu-desktop/evince/ubuntu/view/head:/debian/patches/unity_normal_titlebar.patch
[12:35] <seb128> just for reference
[12:35] <mlankhorst> seb128: who do I poke about gsd cursor bugs?
[12:35] <seb128> mlankhorst, what sort of bugs? that seems xorg related so yourself? ;-)
[12:35] <seb128> but otherwise we don't have an assigned maintainer, just ask on the channel
[12:36] <seb128> usually it's Laney, robert_ancell or myself looking at such issues
[12:36] <mlankhorst> ok
[12:36]  * larsu offers to help as well
[12:36] <mlankhorst> I'll try to reproduce it first, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1388738
[12:36] <mdeslaur> seb128: ah, interesting, I'll see if I can do something similar, thanks
[12:37] <seb128> larsu, sorry for not listing you there
[12:37] <seb128> that's what you get when you list names ;-)
[12:38] <seb128> mdeslaur, otherwise "proper" support is coming in vivid, that's probably not going to be SRUed
[12:38] <larsu> no worries!
[12:38] <mdeslaur> seb128: so not worth uploading then?
[12:39] <seb128> mdeslaur, knowing that "proper" support means that those should have borders, etc, they are still going to look/act slightly inconsistently compared to native decoration, but we don't plan to patch the universe, mostly the default apps to have a good out of the box experience
[12:39] <seb128> mdeslaur, you have it ready, upload, it's going to take some time before unity changes land imho
[12:40] <mdeslaur> seb128: ok, thanks. I'll work on a better patch, and I'll upload
[12:40] <seb128> thanks
[13:00] <Saviq-codedive> anyone else's laptop not allowing screen brightness adjustment any more in vivid?
[13:00] <Saviq-codedive> neither Fn+Sun keys or the control center work (no slider at all there)
[13:02] <Laney> wee, looks like this works... maybe...
[13:02]  * Laney PPAifies
[13:05]  * Laney goes for a celebratory lunch at the cafe
[13:05] <Laney> biab
[13:11] <willcooke> Saviq-codedive, thinkpad?
[13:12] <Saviq-codedive> willcooke, no, XPS12
[13:12] <willcooke> Saviq-codedive, not this then: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1308674
[13:13] <willcooke> which smells like a kernel issue to me
[13:13] <Saviq-codedive> willcooke, no, no dock available here
[13:13] <Saviq-codedive> willcooke, weird thing is, I got the /sys/ thingies, and can echo into them to change brightness, there's just no UI
[13:13] <willcooke> oh, totally different thing then, sorry
[13:13] <willcooke> good luck with fixing it ;D
[14:21] <Laney> pitti: care to try ppa1?
[14:21] <pitti> Laney: doing
[14:22]  * Laney suddenly remembers to sign seb128's key
[14:22] <seb128> Laney, :-)
[14:22] <Laney> where's that slip ...
[14:22] <pitti> oh, right!
[14:23] <pitti> seb128: hang on, did I already do that? ^ I don't have the slip any more
[14:23] <pitti> ah yes, I did
[14:24] <seb128> pitti, yes you did, thanks ;-)
[14:24] <pitti> Laney: *hug*
[14:24] <pitti> Laney: working great now!
[14:24]  * pitti tries with his own user account, brb
[14:25] <Laney> haha
[14:25] <Laney> had been through the wash
[14:25] <Laney> still more or less readable if I can unfold without it turning to dust
[14:26] <pitti> Laney: works mostly well, too (profile migration)
[14:26] <pitti> Laney: the one thing that's annoying is that it now eats Alt+<Number> apparently
[14:26] <pitti> i. e. I can't switch between channels in weechat any more
[14:27] <pitti> Laney: but other than that, ship it! :-)
[14:27] <Laney> hmm
[14:27] <pitti> meh, alt+j too?
[14:27] <Laney> that's supposed to be migrated too, global shortcuts?
[14:27] <pitti> it's not a gnome shortcut
[14:27] <Laney> global to all of g-t
[14:27] <Laney> Preferences->Enable mnemonics or so?
[14:27] <pitti> it's supposed to go to the app that runs in the terminal
[14:28] <Laney> also other shortcuts in there
[14:28] <Laney> like Switch to Tab x
[14:28] <pitti> Laney: ah, it does have that (but so did the old g-t)
[14:28] <Laney> yes, these should be migrated
[14:28] <pitti> if I had tabs, alt+n switched between those
[14:28] <pitti> but if I didn't have tabs, alt+<n> worked
[14:29] <Laney> if not then it's a bug
[14:29] <pitti> ... I mean, were passed to the app
[14:29] <pitti> Laney: that's not a migration issue (that part works fine)
[14:29] <pitti> I didn't change them in gconf or anywhere, that was the default behaviour
[14:29] <Laney> you hadn't unbound alt-<numbers> in old gt?
[14:29] <pitti> no
[14:30] <pitti> also, alt+j isn't defined as shortcut but is also eatn
[14:30] <pitti> and apparently the same is true for just about any alt+<something>
[14:30] <Laney> tried the mnemonics setting?
[14:31] <pitti> not sure what that is (need to restart in English)
[14:31] <pitti> but almost everything (except F10 for the menu) is off
[14:31]  * Laney tries
[14:33] <Laney> wfm :(
[14:33] <pitti> Laney: alt+something?
[14:34] <Laney> same as in 3.6 for me
[14:34] <Laney> alt+X switches tabs by default, happens on my utopic system too
[14:34] <Laney> alt-j works, takes me to #debian-derivatives, alt-q to #ubuntu-motu
[14:35] <Laney> and if I clear the keybindings they migrate to disabled properly, then alt-X works to switch to 0-9
[14:38] <pitti> Laney: confirmed, if I disable the keybindings for "switch to tab", they start workin in IRC
[14:38] <pitti> before, they kind of worked in both
[14:38] <pitti> I bet it's a feature, "consistency"
[14:38] <pitti> if there was no tab, older g-t sent alt+n to the application
[14:39] <Laney> it's weird because in 3.6 I cleared those keybindings for just this reason
[14:39] <Laney> ahh, in the no tabs case
[14:39] <pitti> alt+j is still broken, though
[14:39] <Laney> indeed, confirmed
[14:39] <pitti> Laney: anyway, don't just block it on this issue; we need to get away from this ancient version and gconf at some point, and such stuff is fixable
[14:40] <larsu> is this the last thing using gconf?
[14:40] <pitti> on my system, anyway
[14:41] <pitti> oh, and .gconf/apps/nm-applet/%gconf.xml
[14:41] <pitti> (WTH)
[14:41] <pitti> although I'm not sure whether that's real
[14:41] <pitti> <entry name="stamp" mtime="1415034936" type="int" value="3"/>
[14:41] <larsu> indicator-network is ready for desktop any day now!
[14:41] <pitti> that's the only line in it (aside from <gconf> and xml version)
[14:44] <Laney> larsu: can you try the ppa version?
[14:45] <larsu> Laney: do I need vivid for that?
[14:45] <larsu> in any case: yes I will
[14:45] <larsu> if I need vivid, it might take a bit longer
[14:45]  * larsu hasn't upgraded yet
[14:45] <Laney> you should be able to manually install the debs on utopic
[14:46] <Laney> https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ppa/+packages
[14:47] <Laney> I quite like the hideous theme I created while testing migrations
[14:47] <Laney> semi transparent red background with size 26 text
[14:47] <willcooke> ship it
[14:47] <Laney> needs moar wingdings
[14:47] <larsu> hot dog theme!
[14:47] <Laney> woah
[14:47] <Laney> getting a cool dash bug
[14:48] <Laney> hope this screencasts
[14:48] <larsu> ooh, a menu bar
[14:48] <larsu> (ooh, that's my override)
[14:49] <larsu> Laney: it's transparent, even though I have tht option off before
[14:49] <Laney> hmm
[14:50] <larsu> ah, it only has "use transparency from system theme" checked
[14:50] <larsu> which didn't exist before?!
[14:50] <larsu> also showing scrollbar, which I hadn't before
[14:51] <Laney> http://people.canonical.com/~laney/weird-things/dash.mp4
[14:52] <willcooke> :/
[14:53] <larsu> awesome!
[14:53] <seb128> kenvandine, do you keep the "drop dialog hack" from kalikiana out of u-s-s landings for a reason?
[14:53] <kenvandine> seb128, yes...
[14:53] <kenvandine> it depends on a uitk version that hasn't landed in vivid yet
[14:54] <kenvandine> unless they've landed something this week
[14:54] <kenvandine> last i checked it was way outdated in vivid
[14:54] <seb128> shrug
[14:54] <kenvandine> yeah, still not there
[14:55] <kenvandine> :/
[14:55] <Laney> larsu: hmm, not confirmed, solid background is migrated here
[14:55] <kenvandine> it needs a version that landed in rtm on the 15th i think
[14:55] <Laney> also I made it set that theme one to false when migrating unconditionally
[14:55] <Laney> did you get ppa1?
[14:56] <seb128> kenvandine, sorry for the stupid question, I didn't think vivid could be behind rtm, that's stupid
[14:56] <kenvandine> indeed
[14:56] <kenvandine> i said the same thing when i tried to land it last week
[14:56] <larsu> Laney: yes
[14:57] <Laney> hmm
[14:58] <Laney> larsu: if you do /usr/lib/gnome-terminal/gnome-terminal-migration --clean --force --verbose do you see it migrating your profile and does it then work?
[14:58] <kenvandine> seb128, i loved seeing your update pot branch...
[14:58] <Laney> kill the server if it's running
[14:58] <kenvandine> seb128, my only question is what about getting the updated pot committed back to trunk?  or does this mean we can drop it in trunk?
[14:59] <seb128> kenvandine, eparse
[14:59] <seb128> kenvandine, oh
[14:59] <larsu> Laney: yes, that worked
[14:59] <Laney> okay
[14:59] <Laney> did you run 3.12 before?
[14:59] <larsu> Laney: my other profile is back now, too
[14:59] <seb128> kenvandine, I discussed that earlier with dpm, basically he wants to keep trunk for stats until launchpad can pull stats from ubuntu
[14:59] <Laney> maybe when testing rishi's patch last cycle
[14:59] <seb128> kenvandine, but basically we are going to turn the trunk one off and use the ubuntu template
[15:00] <larsu> Laney: yes, I about-boxed. I did have a 3.6 instance on another desktop running
[15:00] <larsu> Laney: oh, _before_. Yes I did
[15:00] <larsu> thanks for the work!
[15:00] <Laney> it probably didn't re-run the migration then
[15:00] <larsu> seems likely
[15:00] <Laney> this seems shippable
[15:00] <Laney> do you have the alt-j bug that pi_tti was reporting?
[15:01] <dpm> ah, seb128, I think that's something I asked already a while ago, but can't remember what the plan was - is u-s-s going to eventually be migrated to a click package?
[15:02] <seb128> dpm, I think that's wanted, I don't know of any plan to make that actually happen, so dunno
[15:02] <seb128> kenvandine, ^?
[15:02] <dpm> ok
[15:02] <larsu> Laney: how can I find out?
[15:03] <larsu> hm, command line is different now
[15:03] <larsu> no more --class and --disable-factory
[15:03] <Laney> e.g. irssi window switching
[15:03] <kenvandine> seb128, it's been talked about... but not something i'm excited about
[15:03] <seb128> kenvandine, same here
[15:03] <seb128> dpm, I guess "not in the near futur" then
[15:04] <larsu> Laney: argh, Alt+N is broken
[15:04] <seb128> dpm, I guess we need to revisit the pot update if/when that happens though
[15:04] <larsu> Laney: Alt+<number>
[15:04] <Laney> yeah, we discussed that
[15:04] <Laney> you need to clear the shortcuts
[15:04] <dpm> seb128, exactly, that's why I was asking
[15:04] <kenvandine> it wouldn't be trivial to make it click
[15:04] <seb128> kenvandine, let's no worry about it and enjoy auto pot update meanwhile then
[15:05] <kenvandine> and with convergence... i see uss as something that needs to stay deb
[15:05] <kenvandine> indeed
[15:05] <kenvandine> seb128, to prevent confusion, i'd like to remove the pot file from trunk
[15:05] <larsu> Laney: that's annoying... how can I disable them completely without setting a new one?
[15:05] <ogra_> kenvandine, what makes you think desktop "stays deb" ?
[15:05] <Laney> backspace
[15:05] <kenvandine> dpm, when do you think we can do that?
[15:06] <kenvandine> ogra_, well... i mostly mean keep it updated via the system update
[15:06] <kenvandine> etc
[15:06] <ogra_> yeah
[15:06] <Laney> maybe this is fixable
[15:06] <kenvandine> like it shouldn't be in the click store
[15:07] <tedg> desrt, Can we change g_variant_print() to take in a const variant? It sucks that I have to cast away my const to print it.
[15:07] <seb128> kenvandine, dpm wants to keep it for the stats, at least until launchpad get fixed to get stats from the ubuntu package as well (or something around those lines, not sure I understood the stats details)
[15:08] <desrt> tedg: there's no such thing as a const GVariant
[15:08] <kenvandine> seb128, understood
[15:09] <tedg> desrt, I'm confused, aren't there functions that don't modify the contents of the variant?
[15:09] <desrt> tedg: probably not
[15:10] <desrt> GVariant internally is a rather complicated state machine that can undergo all sorts of transitions at almost any time
[15:10] <desrt> in response to relatively innocent API requests
[15:11] <tedg> You're making me nervous about printing them…
[15:11] <desrt> i considered at one point using 'const' to mark "you don't own the ref to this" (which is the only meaningful thing to consider talking about since GVariant is always immutable from a value identity standpoint) but i abandoned it on account of not *strictly* being true by the C sense of the word 'const'
[15:11] <desrt> tedg: even refcounting modifies the struct...
[15:12] <desrt> tl;dr: never write 'const GVariant *'
[15:12] <desrt> same way we never have const on GtkWidget or anything else
[15:13]  * desrt doesn't pass around const GHashTable just because he only plans on doing lookups...
[15:13] <tedg> It's also a compiler optimization, i.e. if I know it won't change I can parallelize.
[15:14] <desrt> the compiler has no idea what's happening once you do the function call and it's a opaque type so you can't access it yourself anyway
[15:14] <desrt> so it can't possibly make a difference
[15:16] <desrt> we could argue for annotating some GVariant functions with pure/const if you're concerned about performance/optimisation
[15:16] <desrt> but i haven't really heard any calls for that sort of thing since most GVariant code tends to be pretty straight-up
[15:16] <desrt> (not like GObject stuff where you may do multiple typechecks of the same instance due to preconditions, casts, etc)
[15:17] <tedg> I think that probably the more practical case for not having const actually is that most functions do a ref_sink()/unref() pair on any variants coming in.
[15:17] <desrt> most don't, actually
[15:18] <desrt> just the ones that 'build'
[15:18] <desrt> but it is a good illustrative example indeed...
[15:18] <desrt> you would expect to be able to put a GVariant into a container without "modifying" it
[15:18] <desrt> but indeed this is definitely a refcounting operation at the least
[15:19] <desrt> (ditto setting a value to gsettings, sending a dbus message, etc etc)
[15:19] <desrt> fwiw i considered the 'const' thing specifically because i was sure it wouldn't change the compiler's behaviour
[15:19] <desrt> ie: we probably would have gotten away with lying
[15:19] <desrt> but it just seemed so evil.... and didn't match existing practice with other types in glib
[15:20] <tedg> Well, I never encourage lying, that always gets you into #ifdef SOLARIS_1_2 type code real quick.
[15:20] <desrt> #ifdef COMPILER_IS_WISE_TO_US ...
[15:20] <desrt> ya... i was imagining the promised future of whole program optimisation
[15:20] <desrt> still waiting on that ;)
[15:21] <tedg> It'll come right before the year of the Linux Desktop, it's what's holding us back.
[15:21] <desrt> but uh... imagine this as a thought exercise:
[15:21] <desrt> void gv_func(GVariant *x) { ... }
[15:21] <desrt> void gv_const_func (const GVariant *x) {
[15:21] <desrt>   GVariant *y = NULL;
[15:21] <desrt>   while (y != x) y++;
[15:21] <desrt>   gv_func (y);
[15:21] <desrt> }
[15:22] <desrt> this is the sort of thought exercise i was considering at the time...
[15:22] <desrt> ie: even if you pass a const pointer to a function, it's still possible to imagine a function that could modify what's at the end of that pointer without any 'evil' casts
[15:22] <desrt> you could even do it 'efficiently' by having a global hashtable of all references and do a lookup
[15:23] <tedg> Sure, but that's arguably as "evil". I don't think that should be expected to work. It's like all conventions, they're breakable, but then people don't trust you.
[15:23] <desrt> tl;dr: never write 'const GVariant *'  :)
[15:24] <tedg> Heh
[15:31]  * Laney ships gnome-terminal
[15:31] <Laney> I think the alt-numbers thing might be annoying but we'll see
[15:32] <larsu> Laney: \o/
[15:32] <Laney> I'll note it in the changelog anwyay
[15:33] <Laney> larsu: oh I noticed that if you have transparency on then the inactive tab has a transparent background
[15:33] <Laney> using gtk 3.14, don't know if that makes a difference there
[15:34] <larsu> it does
[15:34] <larsu> bug bug bug
[15:34] <larsu> hm, transparent bg + tabs looks _really_ ugly
[15:34] <larsu> no wonder it's not upstream anymore ;)
[15:35] <larsu> it might be better in adwaita
[16:13] <kenvandine> seb128, fyi, i've prepared updates for syncevolution and libsynthesis for vivid, but won't upload until i get a thumbs up from renato
[16:13] <kenvandine> seb128, i merged from debian first then updated to the latest release which has some interesting fixes for us
[16:14] <kenvandine> seb128, just in case that's on someone's list of desktop updates to do :)
[16:14] <seb128> kenvandine, great!
[16:15] <kenvandine> i guess i could put that on the etherpad, do you guys still use that?
[16:15] <Laney> I recommend the versions page or MoM
[16:15] <kenvandine> haha... i guess not :)
[16:15] <Laney> (that is to say: no)
[16:15] <kenvandine> things to not forget for R
[16:16] <kenvandine> ancient
[16:16] <Laney> someone set -t so that we can purge that from the topic
[16:18] <Laney> seb128: /msg chanserv op #ubuntu-desktop /mode #ubuntu-desktop -t plz
[16:35] <seb128> Laney, " #ubuntu-desktop t ntcs :MODE cannot be set due to channel having an active MLOCK restriction policy"
[16:35] <Laney> what is that
[16:35] <seb128> dunno
[16:36] <seb128> have fun ;-)
[16:37] <Laney> seb128: try this /msg chanserv set #ubuntu-desktop mlock +
[16:37]  * Laney googles
[16:37] <Laney> winning
[16:37] <seb128> Laney, seems that worked
[16:37] <seb128> there we go
[16:41] <dednick> seb128: hey. any more review comments on the USS check sync branch?
[16:42] <dednick> seb128: trying to get it in a silo
[16:42] <dednick> asap
[16:42] <seb128> dednick, let me have a look now
[16:42] <dednick> seb128: ta
[16:42] <seb128> kenvandine, ^ if you want to look at that one as well
[16:42] <seb128> dednick, yw, sorry that review is taking time
[16:54] <Laney> oh good, I started a let's complain about gnome-terminal thread
[16:55] <willcooke> someone had to do it
[16:55] <willcooke> ;p
[16:57] <didrocks> Laney: nice! :)
[17:09] <mhall119> didrocks: ping
[17:10] <seb128> we still have people doing contentless pings here?
[17:10] <seb128> mhall119, you can do better than that ;-)
[17:10] <mhall119> :-P
[17:10] <mhall119> I wanted to make sure he was around before typing something long
[17:11] <mhall119> my fingers are lazy
[17:11] <didrocks> mhall119: pong
[17:11] <seb128> mhall119, lame excuse ;-)
[17:11] <didrocks>  /quit ;)
[17:11] <mhall119> seb128: fingers are too lazy to form a good excuse
[17:12] <mhall119> didrocks: I used udtc to install android studio, created a new project, but right off the bat it's giving me Gradle sync errors, am I missing something?
[17:13] <didrocks> mhall119: hum, no, you shouldn't, are you trying on utopic?
[17:13] <didrocks> mhall119: it's downloading Gradle on first launch
[17:13] <didrocks> and which version of android studio?
[17:14] <didrocks> (they changed some Gradle things in the latest, forcing Gradle to update, but it was working for me on trusty)
[17:17] <didrocks> mhall119: ?
[17:18] <mhall119> didrocks: sorry got pulled away to the kitchen
[17:18] <mhall119> 0.8.14 of android studio
[17:18] <mhall119> and yes I'm on utopic
[17:19] <didrocks> was it the version you just installed or upgraded from an older one?
[17:19] <mhall119> I installed it yesterday (I think, could have been Monday)
[17:19] <didrocks> ok, so you just downloaded the latest Gradle option and got in the "no automatic SDK configuration" though
[17:20] <didrocks> what is the error you are seeing?
[17:20] <mhall119> I never did anything that specified gradle
[17:20] <mhall119> I ran "udtc android"
[17:20] <didrocks> you started android studio! and that's what is installing gradle :)
[17:20] <mhall119> ah, ok
[17:20] <didrocks> (it's their build system)
[17:20] <didrocks> in beta
[17:21] <mhall119> well it did something wrong, want me to pastebin the idea.log?
[17:21] <didrocks> sure
[17:21] <mhall119> as long as it's not Maven, I'll use the beta
[17:21] <didrocks> you can as well bet it's the download which failed
[17:21] <didrocks> so you can:
[17:21] <didrocks> stop android studio
[17:21] <mhall119> didrocks: http://paste.ubuntu.com/8838579/ looks like I installed it yesterday
[17:21] <didrocks> rm ~/.gradle
[17:21] <didrocks> -r
[17:22] <mhall119> then re-run studio?
[17:22] <didrocks> yep
[17:22] <didrocks> it will redownload and resetup gradle
[17:22] <didrocks> I don't see any error on your last launch, what is it telling you exactly?
[17:22] <mhall119> not much
[17:23] <didrocks> the error that you saw? :)
[17:23] <mhall119> let me get it up again and I'll tell you
[17:23] <didrocks> ok
[17:23] <mhall119> it starts with "Gradle project sync in progress...." in a yellow bar above the editor pane
[17:24] <didrocks> yeah, and that will take some time the first time
[17:24] <mhall119> and some Gradle info messages going on in the bottom bar
[17:24] <didrocks> that's "normal"
[17:24] <didrocks> (only on first launch while you let the gradle configuration happening until the end)
[17:25] <didrocks> mhall119: it can be quite long, gradle is ~500M
[17:25] <mhall119> didrocks: https://www.dropbox.com/s/73jvfl7aaqg5sbx/Screenshot%20from%202014-11-05%2012%3A24%3A47.png?dl=0
[17:25] <mhall119> easier to show a screenshot than to try and describe it
[17:26] <didrocks> ah, that's different :)
[17:26] <didrocks> you don't have downloaded the support library
[17:26] <mhall119> Error:Failed to find: com.android.support:support-v4:20.+
[17:26] <mhall119> <a href="openFile">Open File</a><br><a href="open.dependency.in.project.structure">Open in Project Structure dialog</a>
[17:26] <didrocks> you have set a newer sdk
[17:26] <mhall119> I guess that's the important bit
[17:26] <didrocks> and you wanted to support older ones
[17:26] <mhall119> I used the default option
[17:26] <didrocks> so you want the "backport of features"
[17:26] <didrocks> yep
[17:26] <didrocks> that was installed by default before this week-end release
[17:26] <didrocks> (as they don't install the sdk by default anymore :/)
[17:27] <didrocks> I guess you had fun with that one (see my blog post about it)
[17:27] <didrocks> so, ok, to install it:
[17:27] <didrocks> Tools -> Android -> SDK manager
[17:27] <mhall119> ok
[17:27] <didrocks> in Extras, check:
[17:27] <didrocks> Android Support Repository and Android Support Library
[17:28] <didrocks> then press Install
[17:28] <mhall119> installing...
[17:29] <mhall119> is this the "use newer APIs on older versions of Android" package?
[17:29] <didrocks> right
[17:29] <didrocks> like having headerbar in Android 2.x
[17:29] <mhall119> ok, downloading slowly, might take a few
[17:30] <didrocks> basically, they backport the new APIs in a library for older version of Android
[17:30] <didrocks> just a world of warning, the import differs
[17:30] <mhall119> yeah,  I'd read about that
[17:30] <didrocks> but the template by default, if you checked the "use newer…" have the right imports
[17:30] <didrocks> and the API can slightly differ
[17:30] <didrocks> they often have "compat" in their names
[17:30] <mhall119> fragmentation fun
[17:30] <didrocks> yeah, not sure why the API is different
[17:31] <didrocks> apart from the one you have to import
[17:31] <didrocks> like instead of Activity, it's FragmentActivity
[17:31] <didrocks> to get Fragment support in 2.x
[17:31] <didrocks> (and believe me, you want it :))
[17:37] <mhall119> I just read an anti-Fragments blog post
[17:38] <didrocks> interesting, the guy is anti-progressive-enhancement as well and anti-convergence? :)
[17:40] <mhall119> it was more of a "This is a great idea in theory, but in practice it just makes things harder"
[17:41] <mhall119> I'm not sure I'll be using Fragments anyway
[17:42] <didrocks> the thing is that it's really easy to use it wrong
[17:42] <didrocks> but if you read content on how to use it right, it helps moving the abstraction at the right position
[17:42] <didrocks> level*
[17:43] <didrocks> (basically one fragment shouldn't know about any other fragment, but just about the API that they require their containing activity implements)
[17:47] <didrocks> mhall119: ok, I'm heading out. Do not hesitate if you have any questions or you need any help on your project!
[17:56] <willcooke> quitin' time
[17:56] <willcooke> g'night
[17:57] <ogra_> enjoy
[18:20] <Laney> me too
[18:20] <Laney> fireworks tonight
[18:23] <seb128> Laney, what occasion?
[18:23] <seb128> Laney, enjoy!
[19:35] <czajkowski> seb128: Guy fawkes over here
[19:35] <czajkowski> much fireworks
[20:08] <davmor2> I have some going off over the road  very nice display :)
[22:17] <robert_ancell> desrt, how are you generating debian/patches/mir-backend.patch using git?
[23:04] <desrt> robert_ancell: git format-patch --stdout
[23:04] <robert_ancell> desrt, yeah, but how do you combine all the mir patches and backport to 3.14?
[23:05] <desrt> robert_ancell: i backported the one that was on master
[23:05] <desrt> robert_ancell: but larsu already made a new package
[23:05] <robert_ancell> I've done two updates to it
[23:05] <desrt> two more commits, you mean?
[23:06] <robert_ancell> yep
[23:06] <desrt> did you put them on master upstream?
[23:06] <robert_ancell> yep
[23:06] <desrt> so then you can combine them with git-format-patch HEAD^^ (two ^^ for two patches)
[23:06] <robert_ancell> but they're interleaved with other changes...
[23:07] <desrt> you can use any commit-range specification with format-patch
[23:07] <desrt> so if the commit is abcd then abcd^..abcd would work
[23:07] <robert_ancell> so if I have changes a b and c I can do something like a^..a b^..b c^..c?
[23:08] <desrt> i think you'd have to do that as 3 separate commands
[23:08] <robert_ancell> so how do I make one patch with git?
[23:08] <desrt> rebase squash
[23:08] <robert_ancell> cherry pick the three changes to a local branch then merge them?
[23:08] <desrt> sounds good
[23:08] <desrt> you could also do git-diff on the subdir but you won't get the nice format for the patch
[23:13] <robert_ancell> desrt, can we maintain a 3.14 branch on GNOME git with the backported changes? i.e. can you do a rebase and push without screwing up other users of that branch?
[23:13] <robert_ancell> In bzr I'd maintain a branch with bzr merges and use bzr diff --old to make this patch
[23:13] <robert_ancell> Not sure if there is git equivalent
[23:19] <desrt> robert_ancell: interesting question
[23:19] <desrt> you want to follow 3.14 but with our changes?
[23:19] <robert_ancell> we need that for vivid
[23:20] <robert_ancell> I have a local branch which I just used to generate an updated patch, but it would be nice to share that with everyone else
[23:20] <desrt> what we could do is create a new branch from what you have now and regularly merge in 3.14
[23:20] <desrt> and also cherry-pick from master to the same branch
[23:21] <desrt> that would be fast-forward friendly
[23:21] <robert_ancell> desrt, can we rebase then push that?
[23:21] <desrt> why rebase?
[23:21] <robert_ancell> To keep the last commit just the Mir changes
[23:21] <desrt> ahh
[23:22] <desrt> you're right -- this is tricky :)
[23:22] <robert_ancell> That would be frowned upon in bzr (you'd have to do a bzr push --overwrite)
[23:22] <desrt> what we could always do is diff that branch to 3.14 stock that we just merged in
[23:22] <desrt> which would give us only the mir changes, by definition
[23:22] <robert_ancell> But bzr diff --old (parent branch) would make the nice diff for us
[23:22] <robert_ancell> oh, can you just diff two branches?
[23:23] <desrt> yes
[23:23] <robert_ancell> syntax for that?
[23:24] <desrt> git diff branch1 branch2
[23:24] <desrt> or in general two commit ids
[23:25] <robert_ancell> yeah, that makes it minus the nice header
[23:25] <robert_ancell> git format-patch gtk-3-14..mir-3-14 seems to work too
[23:25] <desrt> neat
[23:25] <desrt> what does it put in the commit message, though?
[23:25] <desrt> or does it just make a huge series of patches?
[23:26] <robert_ancell> No format-patch makes two patches so that wont work
[23:26] <robert_ancell> I guess we just use git diff and put a DEP header on it
[23:26] <desrt> ya so like.... diff
[23:27] <desrt> because really, what would you expect to be int he commit message of the nicely-formatted one?
[23:27] <robert_ancell> I hoped it might prompt me :)
[23:27] <desrt> you surely joke :)
[23:27] <desrt> this is meant to be used as part of a pipe
[23:27] <desrt> (also:... git doesn't ask questions) ;)
[23:28] <robert_ancell> The nicer plugins/functions do e.g. rebase
[23:28] <robert_ancell> It's the old grumpy basic ones that don't
[23:51] <desrt> >:|
[23:52] <sarnold> desrt:  < robert_ancell> The nicer plugins/functions do e.g. rebase < robert_ancell> It's the old grumpy basic ones that don't
[23:52] <robert_ancell> sarnold, ta
[23:55] <RAOF> robert_ancell, desrt: You gents wouldn't happen to know offhand if there's anything that would usefully call gtk_window_set_transient_for() multiple times? I can't think of a usecase for it.
[23:55] <robert_ancell> RAOF, i.e. an application?
[23:55] <RAOF> robert_ancell: Oh, I meant for the same window.
[23:56] <robert_ancell> RAOF, yeah, but an application calling that or GTK+ itself?
[23:56] <RAOF> robert_ancell: Either.
[23:56] <desrt> RAOF: this seems like an odd question.  why do you ask it
[23:56] <robert_ancell> I can't think of anything needing to migrate transient status
[23:56] <RAOF> desrt: I want to know if there's any need to allow reparenting.
[23:56] <robert_ancell> I could imagine badly written apps might call it multiple times
[23:57] <desrt> RAOF: let's go with no
[23:57] <desrt> we have a warning in gtk right now that if you try to create a dialog without a parent you get a warning
[23:57] <desrt> we could probably add one for trying to reparent a shown window
[23:57] <RAOF> Superb.
[23:57] <desrt> file a bug about that maybe?
[23:58] <RAOF> GNOME bugzilla?
[23:58] <desrt> ya
[23:58] <desrt> the new warning would be similar in spirit to one we already have (and even more sensible, in my opinion)