[00:01] <RAOF> Damn. Where's robert_ancell when you need to ask a Vala question!
[00:44] <RAOF> Gah. Don't switch from boost::shared_ptr to std::shared_ptr in an SRU, damnit!
[00:48] <tsimpson> meh, std::shared_ptr is mostly a copy+paste+cleanup of boost::shared_ptr anyway ;)
[00:48] <bryce> RAOF, mind approving jockey in precise-proposed's unapproved queue?  I'm nearing eod but would like to verify alberto's fix.
[00:51] <RAOF> bryce: Done.
[00:52] <RAOF> tsimpson: Yeah, I know that. But I wouldn't be totally amazed if there was a subtle difference in behaviour due to bugs or whatever, and it's not exactly a minimal change.
[00:53] <RAOF> Incidentally, is canonical IRC down for anyone else?
[00:53] <lifeless> RAOF: its down for me :P

[00:54] <sarnold> RAOF: worksforme
[00:56] <RAOF> lifeless: :P
[01:04] <TheMuso> Its up for me.
[01:12] <RAOF> Huh. My route to irc.canonical.com dies inside of level3.net, apparently.
[01:13] <sarnold> RAOF: very odd; my route to irc.canonical.com goes through level3.net just fine -- san jose, new york, london
[01:13] <RAOF> Mine dies at ae-2-52.edge5.London1.Level3.net
[01:14] <micahg> mine goes through there
[01:14] <sarnold> my next hop from that goes through SOURCE-MANA.edge5.London1.Level3.net
[01:15]  * micahg has the same as sarnold
[03:45] <pitti> Good morning
[03:45] <RAOF> Good morning pitti!
[03:46] <pitti> hey RAOF, how are you?
[03:46] <RAOF> Annoyed at the Unity SRU in quantal-unapproved.
[03:47] <RAOF> Apart from that, pretty good.
[03:47] <RAOF> No longer as tired as I was this morning!
[03:47] <pitti> RAOF: oh, lots of "fun" changes?
[03:48] <pitti> RAOF: not tired any more> see? the refreshing effect of processing SRUs :-)
[03:48] <RAOF> Not _lots_ of fun changes, but they appear to have switched from boost::* to std::* for absolutely no reason.
[03:48] <pitti> !?
[03:48] <pitti> this seems like a good change for trunk indeed, but in an SRU?
[03:48] <RAOF> Well, I guess it's not *absolutely* no reason; now that they can use C++11 that's fine, but it's NOT fine in an SRU.
[03:49] <RAOF> Also there's some questionable code in there, like:
[03:49] <RAOF> +          // FIXME: although this pretends to be generic, we're just making
[03:49] <RAOF> +          // sure that icons requested to have 96px will be 64
[03:49] <RAOF> +          base_icon_width = max_width > 0 ? max_width * 2 / 3 : max_width;
[03:50] <pitti> urgh - /me accidentally hits the "show desktop" in alt+tab
[03:50] <pitti> this is such a mess, there's no obvious undo to that
[03:50] <RAOF> Hit show desktop again.
[03:50] <RAOF> It's totally undiscoverable, but show desktop is self-inverse.
[03:51] <pitti> ah, so it is
[03:51] <pitti> I wonder why we still even have that
[03:57] <RAOF> For a certain kind of user I'm pretty sure it's the bee's knees.
[03:57] <RAOF> Of course, I'm not sure if that kind of user knows how to get at it ☺
[04:03] <TheMuso> Its worth noting that modern versions of Windows have the desktop in the alt-tab switcher.
[04:03] <TheMuso> I.e from Vista and later.
[05:00] <RAOF> Dear vala: hurry up and write a gcc frontend, so I don't have to wade through your indecipherable C for SRUs.
[06:27] <RAOF> Why does unity-lens-photos have a .desktop file at all?
[06:34] <desrt> RAOF: hilariously, we were discussing exactly this last night
[06:34] <desrt> except we favoured an llvm frontend :)
[06:35] <RAOF> Whatever; kindly be making its internal guts transparent to me :)
[06:37] <RAOF> (Or I guess just acknowledge that what you really want is C#, and make mono more awesome :P)
[06:38] <kenvandine> RAOF, shhh... i've been getting harassed this week for my mono sticker on my laptop
[06:39]  * desrt contributes
[06:39] <kenvandine> grrr
[06:39] <RAOF> kenvandine: I avoid this by not having any stickers on my laptop :)
[06:39] <BigWhale> Good morning all.
[06:39] <kenvandine> hey BigWhale
[06:40] <desrt> RAOF: let me get you a 'sarah palin 2016' sticker
[06:40] <RAOF> Well, except for the one which says “This is a HWE laptop that can't be certified”
[06:40] <BigWhale> hey kenvandine. you're up early ... or late ... I'm guessing you're already in Europe? :)
[06:40] <kenvandine> yeah
[06:40] <kenvandine> been here all week :)
[06:40] <desrt> HWE?
[06:41] <kenvandine> hardware enablement?
[06:41] <BigWhale> UDS starts on 29th? right?
[06:41] <desrt> yes
[06:41] <desrt> mon-thu
[06:41] <RAOF> Yeah, hardware enablement.
[06:41] <RAOF> didrocks: Yo!
[06:41] <RAOF> didrocks: Good morning!
[06:42] <didrocks> RAOF: hey! how are you? :)
[06:42] <RAOF> didrocks: Sadly, I'm about to make it a little less good for you :(
[06:42] <didrocks> RAOF: sniffff ;)
[06:42] <didrocks> RAOF: what happened on the SRU front?
[06:42] <pitti> salut didrocks, ça va?
[06:42] <RAOF> didrocks: Would you kindly be shouting at PS that switching from boost::stuff to std::stuff is not an appropriate SRU change?
[06:42] <didrocks> pitti: ça va bien, et toi?
[06:43] <pitti> didrocks: je vais bien, merci!
[06:43]  * desrt thinks that a ç looks and sounds like a lop-sided s
[06:43]  * pitti is on a code slaughter quad-damage trip
[06:43] <didrocks> RAOF: I think popey can find the exact kind words for it :)
[06:43] <popey> which sru is that?
[06:43] <didrocks> RAOF: this is only for unity package itself, isn't it?
[06:43] <RAOF> Unity
[06:43] <didrocks> RAOF: the rest is good?
[06:44] <RAOF> Compiz isn't; I've commented on the bug.
[06:44] <didrocks> RAOF: I can see a little tear on popey's face just 1 meter away from me :)
[06:44] <RAOF> unity-lens-photos isn't, but I've apparently forgotten why.
[06:44] <didrocks> oh?
[06:44] <popey> sorry, I'll stop laughing
[06:45] <RAOF> didrocks: Oh, no. That's right.
[06:45] <RAOF> didrocks: I wasn't accepting unity-lens-photos until I knew why it's got a desktop file at all.
[06:46] <didrocks> popey: on compiz, can you look with duflu about the comment on bug #1060171
[06:46] <ubot2> Launchpad bug 1060171 in compiz (Ubuntu Quantal) "gtk-window-decorator crashed with SIGSEGV in g_hash_table_lookup_node() from g_hash_table_remove_internal() from event_filter_func() from gdk_event_apply_filters()" [High,Triaged] https://launchpad.net/bugs/1060171
[06:46] <didrocks> RAOF: let me look at u-l-p
[06:46] <RAOF> Good work, gnome-keyring. A stable release that fixes bugs *and* has a test suite!
[06:47] <popey> sure
[06:48] <RAOF> didrocks, popey: Oh, also, while browsing through the unity changes I saw something that seemed strange to make through code review; the comment says “ensure we return 64px icons, the code returns max_size * 3 / 4.
[06:48] <didrocks> RAOF: u-l-p:
[06:48] <didrocks> https://code.launchpad.net/~davidc3/unity-lens-photos/unexpected-geeqie-crasher/+merge/130044
[06:48] <RAOF> Sorry; max_width * 2 / 3.
[06:49] <RAOF> didrocks: Ah, ok. So, it's for the benefit of software-center.
[06:50] <RAOF> I guess that should be fixed to be better, but I'll accept u-l-p.
[06:50] <seb128> didrocks, hey, how are you? thanks for doing SRU review! ;-)
[06:50] <didrocks> RAOF: thanks :)
[06:50] <RAOF> seb128: A geary SRU? Really?
[06:50] <desrt> uh
[06:50] <desrt> isn't 'u' for 'update'?
[06:50] <seb128> RAOF, why not? ;-)
[06:51] <RAOF> It's an awesome idea, but it barely works? :)
[06:51] <desrt> RAOF: who cares?  we ship thunderbird and evolution, don't we? :)
[06:53] <RAOF> I'm very much behind the idea of geary, and have the daily PPA build installed. I'm surprised it's in universe, though; it's currently litte more than a broken toy :{
[06:53] <RAOF> Baby attack!
[06:53] <seb128> RAOF, it's mostly to be nice to the yorba guys
[06:55] <pitti> bonjour seb128!
[06:55] <seb128> pitti, hey, wie gehts?
[06:55] <pitti> seb128: gut, danke! happily dropping loots of code
[06:56] <seb128> pitti, sprint^Wautomn cleaning? :-)
[06:56] <pitti> seb128: indeed! just landed some more patches which remove ~ 1400 LOCs
[06:56] <seb128> nice
[07:11] <Mirv> RAOF/didrocks: I can't see removed xml files in lp:ubuntu/compiz - the line about disabled test was removed by didier to not erronously refer to the bug, but probably only the bug number should have been removed
[07:11] <Mirv> (regarding bug #1060171 note)
[07:11] <ubot2> Launchpad bug 1060171 in compiz (Ubuntu Quantal) "gtk-window-decorator crashed with SIGSEGV in g_hash_table_lookup_node() from g_hash_table_remove_internal() from event_filter_func() from gdk_event_apply_filters()" [High,Triaged] https://launchpad.net/bugs/1060171
[07:12] <didrocks> Mirv: I agree about the disabling test, RAOF, we have manual tests and agrees on those
[07:13] <didrocks> RAOF: this version was tested by popey's team and I for more than a week now and we can ensure there is no visible regressions
[07:13] <didrocks> RAOF: also, like in GNOME, we don't list every commits
[07:13] <didrocks> only those which have a visible impact on user experience, with opened bugs
[07:13] <didrocks> I don't see PS work different here
[07:13] <didrocks> so re:compiz: is it acceptable for you?
[07:14] <Mirv> ah sil2100 commented on the bug as well regarding the cherry-picks (ie. xml files were removed already earlier)
[07:14] <didrocks> for unity, let popey's team (I looked for the commit id) giving you an answer
[07:15] <RAOF> didrocks: As far as I'm aware PS doesn't have a blanket MRE?
[07:16] <didrocks> RAOF: sorry, I don't understand MRE :)
[07:16] <RAOF> GNOME gets a pass because it's got a MRE; it might be appropriate that unity/compiz/etc get a Micro Release Exception, but they currently don't, so we want just bug fixes, and only changes which fix bugs.
[07:17] <didrocks> RAOF: it didn't work like that in the past, I think the SRU team trusted what we pushed because it was tested
[07:17] <didrocks> not sure how pitti dealt with compiz and unity SRUs in the past
[07:17] <pitti> pretty much like "stick fingers in ears and press the knob", really
[07:18] <RAOF> Heh.
[07:18] <pitti> not that I was happy about that approach, but these diffs were usually way too big for a sane review anyway
[07:18] <didrocks> and I don't think in 3 years we pushed buggy updates in a SRU (we had one regression AFAIK on the dozen of uploads)
[07:18] <didrocks> yeah, and every merge requests already have at least one reviewer
[07:18] <didrocks> that + the tests
[07:18] <didrocks> so, I'm happy that we can answer on the things that looks wrong to you
[07:19] <RAOF> I'm all for various PS projects getting a micro release exception (although perhaps *after* getting the message that boost::*→std::* is *not* a stable release candidate).
[07:19] <didrocks> (like boost versus std: change)
[07:19] <pitti> but large structural code changes like that give me the creeps, too
[07:19] <pitti> especially stuff like boost -> std
[07:19] <pitti> was this really tested on arm, powerpc, etc.? this cold lead to all sorts of interesting regressions
[07:19] <didrocks> not sure about mandating every commit (which have been checked by distro to fit for a SRU, or would have been reverted) to get all noticed
[07:19] <didrocks> pitti: yep, there have been a test on arm
[07:20] <didrocks> but let us get an answer on boost -> std
[07:20] <pitti> and powerpc?
[07:20] <pitti> and armel?
[07:20] <didrocks> pitti: no those 2 AFAIK
[07:20] <didrocks> amrhf had though
[07:20] <RAOF> didrocks: Basically, you're arguing for a MRE - I'm sure the technical board would be receptive, given that everything's nicely tested.
[07:21] <didrocks> RAOF: right, I have a session about it at UDS
[07:21] <lifeless> meal ready to eat?
[07:21] <didrocks> RAOF: but the additional commits in compiz ar really wondering you?
[07:21] <didrocks> are*
[07:21] <didrocks> worrying*
[07:21]  * didrocks needs coffee
[07:21] <RAOF> didrocks: Yes! I worry when an SRU removes files without any mention of why!
[07:22] <Mirv> RAOF: like indicated in the bug report now, those were already removed as cherry-picks in the previous release
[07:22] <didrocks> hence it's not indicated again
[07:22] <didrocks> in the changelog
[07:22] <RAOF> So why is it in the debdiff?
[07:23] <didrocks> RAOF: one sec, checking
[07:24] <didrocks> I remember to have asked Mirv  to remove the line because it was already in ubuntu, but let me check, the SRU was pushed more than one week ago in -proposed and didn't get touch…
[07:26] <didrocks> so the fix was for https://bugs.launchpad.net/compiz/+bug/1057955
[07:26] <ubot2> Launchpad bug 1057955 in Compiz 0.9.8 "Removed schema keys still used in keybindings and automated tests" [Undecided,Fix committed]
[07:27] <sil2100> Yes, I commented on the bug regarding this
[07:27] <Mirv> it looks ok in lp:ubuntu/compiz, but I think Adam's 1:0.9.8.4-0ubuntu3 upload added them back?
[07:27] <Mirv> 1:0.9.8.4-0ubuntu3 is also not in the packaging branch at all
[07:27] <RAOF> Yeah, the compiz we're shipping in Quantal includes those xml.in files.
[07:28] <RAOF> Check out apt-get source.
[07:28] <didrocks> Mirv: hum, in fact, it's a different story
[07:28] <didrocks> http://launchpadlibrarian.net/117994551/compiz_1%3A0.9.8.2%2Bbzr3377-0ubuntu1_1%3A0.9.8.4-0ubuntu1.diff.gz
[07:28] <didrocks> they were removed from the install
[07:28] <sil2100> So something is wrong
[07:28] <didrocks> not in upstream tarball
[07:29] <didrocks> Mirv: does it sound right to you? ^
[07:31] <Mirv> didrocks: they were removed in ubuntu1, yes, but possibly erronously put back in ubuntu3 which is missing from lp:ubuntu/compiz as well
[07:31] <didrocks> Mirv: no, there were not removed if I'm correct (look at the debdiff), there were just not *installed*
[07:31] <didrocks> which is the same for the end user experience
[07:31] <didrocks> which is what we should focus on I guess
[07:32] <Mirv> hmm, yes, true, regardless of how it is
[07:32]  * RAOF goes and has a nice relaxing bath
[07:32] <didrocks> -  50-compiz-launchers.xml.in
[07:32] <didrocks>    50-compiz-navigation.xml.in
[07:32] <Mirv> and lp:ubuntu/compiz is fine now
[07:32] <didrocks> -  50-compiz-screenshot.xml.in
[07:32] <didrocks> -  50-compiz-system.xml.in
[07:32] <Mirv> (after bzr pull)
[07:33] <didrocks> Mirv: yeah, seems the move to raring branches missed it (it was in the proposed one)
[07:33] <didrocks> Mirv: so I grabbed and pushed
[07:33] <didrocks> RAOF: can we have a conscensus on that?
[07:33] <didrocks> (for compiz, again, we'll check with upstream for the boost -> std on unity)
[07:34] <Mirv> also the compiz-gnome I've installed with the packaging is fine
[07:39] <sil2100> RAOF: regarding the offending commit...
[07:39] <tsdgeos> how do we get the upstream fix for https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1064992 in? do we want it in i guess?
[07:39] <ubot2> Launchpad bug 1064992 in gtk+3.0 (Ubuntu) "Unity menubar crashes when activating a submenu in LibreOffice while using Orca screen reader" [Undecided,In progress]
[07:40] <sil2100> RAOF: if the boost->std switch is not good, we can revert this switch indeed...
[07:40] <sil2100> RAOF: and stick with boost for now
[07:41] <seb128> tsdgeos, subscribe ubuntu-sponsors to the bug and get the SRU infos if you can to help the update
[07:41] <didrocks> sil2100: can we get that merged in 6.0 and then, we just cherry-pick it?
[07:41] <didrocks> (now that the branch is in sync again ;))
[07:41] <sil2100> didrocks: yes, I just asked bschaefer_ to do that
[07:41] <sil2100> :)
[07:41] <didrocks> excellent, thanks sil2100!
[07:41] <Mirv> thanks sil2100!
[07:41] <sil2100> Sorry about that, it's really ugh, I feel ashamed, I could have remembered that SRU==no-big-changes
[07:41] <seb128> tsdgeos, SRU infos: impact, test case, regression potential
[07:41] <sil2100> Since I basically approved it ;p
[07:42]  * bschaefer should have known that as well
[07:42] <didrocks> sil2100: can you look at:
[07:42] <didrocks> 08:48:31          RAOF | didrocks, popey: Oh, also, while browsing through the unity changes I saw something that seemed strange to
[07:42] <didrocks>                        | make through code review; the comment says “ensure we return 64px icons, the code returns max_size * 3 / 4
[07:42] <didrocks> sil2100: can help you with bzr annotate just to find the correct person :)
[07:43] <sil2100> didrocks: will try! ;)
[07:43] <didrocks> sil2100: keep me posted if you need help
[07:43] <didrocks> so I think unity is on the right track
[07:43] <didrocks> we need to have a decision on compiz itself
[07:43] <didrocks> I can document "removal of upstream files in the source that we already don't install upstream and downstream"
[07:43] <didrocks> but:
[07:43] <didrocks> 1. there is nothing to check
[07:44] <didrocks> 2. reverting that will make us diverging from the rarring branch for no reason
[07:44] <sil2100> I'll just get a drink
[07:47] <tsdgeos> seb128: ok, done
[07:53] <RAOF> didrocks: If we're certain they're not installed I don't need a comment in debian/changelog
[07:58] <sil2100> RAOF: we'll remove the boost->std switch and cherry-pick it ASAP
[07:58] <RAOF> sil2100: Ta
[07:58] <sil2100> RAOF: sorry about that
[07:58] <RAOF> 'sok.
[07:59] <RAOF> I just have to reject uploads, which I don't particularly like doing :/
[07:59] <didrocks> RAOF: yeah, I can ensure you for 100% it's not installed ;)
[07:59] <didrocks> RAOF: hit me hard at UDS if it's the case :)
[07:59] <RAOF> didrocks: Then full steam ahead!
[07:59] <didrocks> RAOF: so agree on me pushing compiz again?
[07:59] <didrocks> RAOF: I can promise you a beer, which is a lot in that country (I'll sell my car for it :p)
[08:00] <RAOF> didrocks: Yeah, push compiz again.
[08:00]  * didrocks dput -f ;)
[08:01] <didrocks> RAOF: done! thanks again! We are fixing unity now (thanks for spotting it!)
[08:01] <seb128> kenvandine, cassidy is pinging about https://bugs.launchpad.net/ubuntu/+source/adium-theme-ubuntu/+bug/959084 ... webkitish issue, do you have an idea could you have a look to?
[08:01] <ubot2> Launchpad bug 959084 in empathy (Ubuntu) "empathy-chat consistently uses 9-10 % CPU" [Low,Triaged]
[08:08] <dupondje> Got a really strange issue with LightDM, sometimes when I boot, I see the console cursor on tty7 (trough the lightdm window). If I then switch to tty1 for example, I still see lightdm visible (only partly). Is that a known bug?
[08:09] <sil2100> bschaefer: did you submit a merge for the std->boost switch already maybe? ;)
[08:09] <bschaefer> sil2100, working on it, had to recompile some things :(
[08:10] <sil2100> bschaefer: ok, just give me a poke once it's submitted, so that I won't miss it!
[08:10] <bschaefer> sil2100, will do!
[08:16] <sil2100> didrocks: for the max_height * 2 / 3 change, it seems mhr3 was the author
[08:16] <sil2100> https://code.launchpad.net/~mhr3/unity/respect-icon-size-hint-6.0/+merge/129123
[08:16] <seb128> dupondje, not known
[08:16] <didrocks> sil2100: he's not far from here! I saw him, take your knife and run after him ;)
[08:16] <seb128> dupondje, seems like a kernel,xorg,video issue
[08:16] <sil2100> didrocks: let's molest him about this change
[08:16] <sil2100> mhr3: !
[08:17] <didrocks> sil2100: you can as well just ask him, seems less risky and it may work ;)
[08:17] <sil2100> mhr3: RAOF doesn't like the part that's under FIXME ;)
[08:18] <RAOF> sil2100, mhr3: Particularly: I don't see why it calculates a value, rather than just returning 64L
[08:18] <RAOF> Ahem. 64.
[08:19] <RAOF> That just seems begging for an unrelated change to make things look bad later on.
[08:19] <mhr3> RAOF, it's not in a component that should use such hardcoded values
[08:19] <bschaefer> sil2100, https://code.launchpad.net/~brandontschaefer/unity/fix-1046201-6.0/+merge/131140
[08:20] <RAOF> mhr3: But you're essentially hardcoding 64 there?
[08:20] <sil2100> bschaefer: thanks! Building, testing and then approving
[08:20] <mhr3> RAOF, although the fixme suggests that, no
[08:20] <bschaefer> sil2100, awesome thanks!
[08:20] <RAOF> mhr3: So is 2/3 of whatever max_width is right for all values of max_width?
[08:20] <bschaefer> sil2100, the diff will be smaller after the cherry pick :)
[08:21] <mhr3> RAOF, well... no :) but hardcoding 64 isn't correct either
[08:21] <mhr3> for things we use it with 2/3 works
[08:21] <sil2100> bschaefer: I think I'll even change it to Needs Review, since the decision is that we include it if it's working ok ;)
[08:21] <bschaefer> sil2100, sounds good
[08:23] <RAOF> mhr3: If hardcoding 64 is wrong, but 2/3rds is also wrong, isn't 64 more *obviously* wrong and so more likely to be changed when appropriate? I picked up on this partially because I'm grumpy about the boost::→std:: change ☺.
[08:23] <bschaefer> sil2100, ugg i missed a change in the test
[08:23]  * bschaefer goes to fix it
[08:23] <sil2100> bschaefer: no problem, still updating my chroot ;)
[08:23] <bschaefer> :)
[08:25] <mhr3> RAOF, bottom line, i don't see any way to make it "better" atm, and hardcoding won't make it better
[08:27] <RAOF> I think that hardcoding makes it more *obviously* wrong, so more likely to be fixed later. That said, it's not a blocker for SRU acceptance. I just reserve the right to say “I told you so” later on, should someone make a change that breaks it ☺
[08:29] <mhr3> fwiw we're already starting to refactor that whole component ;)
[08:30] <bschaefer> sil2100, pushed the fix
[08:31] <sil2100> bschaefer: ok, pulling
[08:44] <didrocks> RAOF: I'm sure you have a personal tomboy note with the "I told you so" examples :)
[08:48] <sil2100> bschaefer: ok, working nicely, I'll just check something and approve ;)
[08:48] <bschaefer> sil2100, cool!
[08:50] <gema> sil2100: I am sending you an email with some pics of my new problem this morning
[08:51] <gema> sil2100: some of my windows half break to show what's underneath
[08:51] <popey> gema what's up?
[08:51] <gema> hey popey not much, I think it is compiz, but I am not sure, so looking for a second opinion :)
[08:52] <popey> I'd also like to see those
[08:52] <gema> popey: forwarding
[08:52] <popey> thanks
[08:53] <RAOF> popey: Oh, if we're soliciting random bug reports - I've got a problem when there's a window that's been greyed out for being unresponsive.
[08:53] <popey> oh?
[08:54] <RAOF> The unity overlays (dash, alt-tab, top-bar-shadow) flicker at roughly 30Hz between being there and not being there when they're over an unresponsive window.
[08:55] <RAOF> I've got a video of it, but haven't yet attached it to a bug.
[08:55] <RAOF> Want to see?
[08:55] <sil2100> gema: thanks!
[08:55] <popey> ping us the bug when you do
[08:55] <sil2100> Will look into it a bit later
[08:55] <gema> sil2100: no prob
[08:56] <popey> gema, that loooks like a video driver issue to me
[08:57] <popey> gema, what video card does that machine have, with 3 heads?
[08:57] <sil2100> didrocks: for the change from std back to boost - should we create a new bug for it and link it to it, or just in the changelog write it down without a bug number when cherry-picking?
[08:59] <gema> popey: Radeon HD 5800
[09:00] <gema> popey: it used to work fine with precise
[09:04] <gema> popey: it may well be the new kernel then playing games on me, I will look into it
[09:05] <RAOF> I now have a shiny new Radoon HD 7870 that supports 4 monitors; I should see if jasoncwarner_ will let me expense 3 extra monitors to test :)
[09:05] <gema> RAOF:  :D
[09:07] <RAOF> popey: Enjoy! https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1070735
[09:07] <ubot2> Launchpad bug 1070735 in unity (Ubuntu) "When Unity UI elements are above an unresponsive window, they flicker" [Undecided,New]
[09:17] <gema> popey, sil2100: using gnome classic for a while to discard unity and make sure it's a graphics issue
[09:22] <popey> thanks RAOF
[09:38] <sil2100> didrocks: !
[09:45] <sil2100> didrocks: https://code.launchpad.net/~sil2100/unity/ubuntu_6.10_cp_std <- the cherry-picked branch for unity
[09:46] <sil2100> didrocks: I didn't know if I should revert it to UNRELEASED from quantal-proposed or not, so I just left it as it is
[09:46] <sil2100> didrocks: hope the changelog entry is ok
[09:46] <sil2100> didrocks: oh, and there's also one more branch I'd like you to check
[09:46] <didrocks> sil2100: let me have a look
[09:46] <didrocks> sil2100: it's fine to keep it as it is, no UNRELEASED for this special process :)
[09:51] <sil2100> didrocks: https://code.launchpad.net/~sil2100/unity-lens-applications/vala_bump <- the other branch, since pstolowski has a merge that bumps the requirement for libgnome-menu and also valac
[09:52] <jasoncwarner_> RAOF "to test" ;)
[09:52] <sil2100> didrocks: https://code.launchpad.net/~stolowski/unity-lens-applications/use-libgnome-menu3/+merge/130509 <- this merge
[09:52] <sil2100> I've been told it's a necessary change ;)
[09:53] <sil2100> didrocks: thanks for checking those out!
[09:55] <didrocks> sil2100: running the new unity, seems good to me :)
[09:55] <didrocks> sil2100: looking at u-l-a then!
[09:56] <didrocks> sil2100: unity in -proposed
[09:57] <didrocks> RAOF: ^
[09:57] <sil2100> didrocks: ta ;)
[10:01] <sil2100> gema: looking at the bug pictures now
[10:02] <gema> sil2100: so far my gnome classic experience is good, my graphics card is working fine here
[10:02] <gema> sil2100: so I doubt is a driver issue
[10:03] <gema> sil2100: or maybe it's a driver issue with unity
[10:03] <Laney> try gnome-shell, it's likely to be closer to unity in terms of driver usage
[10:04] <sil2100> gema: we think it's rather a driver issue, since the code related to it is rather fragile - but we'll be looking at it ;)
[10:04] <gema> Laney: I will try gnome-shell
[10:05] <gema> sil2100: thanks!
[10:06] <didrocks> sil2100: pushed and approed
[10:07] <sil2100> didrocks: awesome!
[10:48] <sil2100> didrocks: did you push u-l-a distro update to lp:ubuntu/u-l-a?
[10:49] <sil2100> Since I can't see it in the bzr branch I just did
[10:49] <sil2100> And the merge is still failing
[11:00] <seb128> cool website: http://upstream-tracker.org/index.html
[11:01] <seb128> it lists api changes in quite some libs
[11:01] <seb128> on that lunch time
[11:58] <cyphermox> good morning!
[12:09] <didrocks> 14:06:48      didrocks | sil2100: hum, I did bzr push
[12:09] <didrocks> 14:08:02      didrocks | sil2100: oh, it's telling me it diverged
[12:09] <didrocks> 14:08:47      didrocks | sil2100: let me merge your change
[12:10] <sil2100> Awww, maybe because the branch was from Monday...
[12:10] <sil2100> didrocks: thanks!
[12:10] <didrocks> sil2100: yeah, your branch is outdated, no worry :)
[13:37] <attente> desrt: ping
[13:40] <kenvandine> qengho, did you see the webkit bug i assigned to you?
[13:43] <kenvandine> qengho, i tried to bisect it, testing all the previous versions of the adium theme and still got the same behavior
[13:43] <kenvandine> so sounds like something that webkit caused
[13:47] <jibel> webapps seem to make firefox use a lot of cpu
[13:51] <qengho> kenvandine: got it.  lp#959084.
[13:51] <kenvandine> thanks
[13:52] <kenvandine> sounds like it has to be something that webkit introduced... so have fun diving in that :)
[13:55] <desrt> attente: pong
[13:56] <attente> desrt: can you take a quick look at this? http://fpaste.org/eHsH/
[13:57] <desrt> attente: SHOW ME THE CODE!!!
[14:03] <desrt> attente: we've seen this bug before.......
[14:03] <attente> desrt: we have?
[14:03] <desrt> libreoffice was crashing with a very similar trace
[14:04] <attente> the only thing i can tell is that the menu passed in is NULL
[14:04] <desrt> so either you are doing the same thing they were (they fixed the bug on their side) or it's my fault :)
[14:05] <attente> to unrealize the GtkMenu, all i did was remove it from the parent container
[14:06] <attente> then re-realize it by adding it back in
[14:13] <attente> desrt: do you know how they fixed it?
[14:14] <attente> (or what they did in the first place)
[14:24] <mhr3> didrocks, seb somewhere close to you?
[14:25] <mhr3> didrocks, i need to cry to him that bustle-dbus-monitor doesn't work
[14:25] <mhr3> seb128, , i need to cry to you that bustle-dbus-monitor doesn't work
[14:26] <mhr3> guess it's the change in Q where the monitoring apps need to set some flag now
[14:30] <seb128> mhr3, the eavedropping thing?
[14:30] <mhr3> seb128, that'd be my guess
[14:33] <desrt> attente: sorry.  was asking lars about it and got into a big discussion
[14:34] <desrt> attente: we're planning how to make seb128 lose his will to live
[14:34] <Laney> yeah looks like our bustle is quite out of date
[14:34] <seb128> Laney, want to have a look at updating it?
[14:34] <kenvandine> desrt, want to make ubuntu spicier?
[14:34] <attente> desrt: oh. ok then
[14:34] <Laney> can do
[14:35] <desrt> attente: anyway... not sure what the issue is
[14:35] <seb128> desrt, be careful, I'm watching you
[14:35] <desrt> if i had your code and could reproduce it locally it would help a lot
[14:35] <desrt> seb128: creep
[14:35] <attente> desrt: i emailed it to you
[14:35] <desrt> oh.  good.
[14:35] <seb128> larsu, hey, long time not seen, how are you?
[14:35] <desrt> you should get that in git....
[14:35] <Laney> mhr3: you probably want these https://bugs.freedesktop.org/show_bug.cgi?id=39140#c12
[14:36] <ubot2> Freedesktop bug 39140 in General "add eavesdrop=true to rule(s)" [Normal,Resolved: fixed]
[14:36] <larsu> seb128, pretty good. What's up?
[14:36] <attente> is there a remote i can push to?
[14:36] <seb128> attente, lp:~huaw/+junk/yourcode? :p
[14:36] <seb128> attente, bzr!
[14:36] <seb128> ;-)
[14:36] <attente> heh
[14:37] <mhr3> Laney, yep, looks that way
[14:38] <desrt> attente: put it on chinstrap?
[14:38] <desrt> or github...
[14:38] <desrt> or gitorious
[14:38] <seb128> tarball & email :p
[14:38]  * desrt has dconf-qt on gitorious
[14:38] <kenvandine> usb stick in an envelope ?
[14:39] <Laney> oh wow, bustle is haskell: /me gets excited
[14:39] <kenvandine> Laney, you're sick
[14:39] <kenvandine> :-D
[14:39] <mhr3> Laney, just the latest version
[14:39] <seb128> Laney, mhr3 was mentioning that, I though you would like it :p
[14:39] <desrt> attente: could put it on gnome.org
[14:39] <lamalex> bryce, RAOF hey guys- im having very bad nvidia/nouveau problems. if you of you are around could you lend me a hand?
[14:40]  * mlankhorst looks away innocently
[14:41] <mlankhorst> lamalex: what kind?
[14:41] <lamalex> with the proprietary driver, after the splash screen my screen goes black and stays that way
[14:42] <lamalex> with nouveau it seems to be munging registers and rendering my wireless disabled, and also causing me to hardlock
[14:42] <lamalex> lots of dmesg errors from it
[14:42] <mlankhorst> pastebin?
[14:42] <mlankhorst> precise or quantal btw
[14:43] <lamalex> quantal
[14:43] <lamalex> precise works great
[14:44] <lamalex> but im on the webapps team, which rather requires using q
[14:44] <lamalex> and r before long
[14:46] <desrt> larsu: <seb128> shit
[14:46] <mlankhorst> pastebin your dmesg then
[14:46] <lamalex> mlankhorst, http://paste.ubuntu.com/1302653/
[14:46] <larsu> desrt, what?
[14:46] <mlankhorst> hm looks like some crap in the 3d engine going wrong :P
[14:47] <seb128> desrt, you are tired man
[14:48] <mlankhorst> lamalex: though couldn't say for sure whether by the DDX or by mesa
[14:48] <desrt> attente: not seeing the crash
[14:49] <attente> really?..
[14:49] <attente> running ./hello
[14:49] <desrt> i guess i should disable my dbusmenu-enabled gtk :/
[14:49] <mlankhorst> lamalex: can you boot without starting X, then start X, export LIBGL_ALWAYS_SOFTWARE=1 and do DISPLAY=:0 /etc/X11/Xsession ?
[14:50] <lamalex> what's the best way to boot without starting X
[14:50] <mlankhorst> recovery mode
[14:50] <mlankhorst> but with nomodeset removed
[14:50] <lamalex> should i set those vars before starting X?
[14:50] <mlankhorst> doesn't affect X
[14:51] <lamalex> k
[14:51] <lamalex> so take nomodeset out from grub, then start in recovery mode
[14:52] <mlankhorst> yeah
[14:52] <lamalex> aye aye
[14:52] <lamalex> be back in a moment
[15:04] <lamalex> mlankhorst, unsuccessful
[15:04] <lamalex> im not sure what i did wrong but exactly but i didn't really get anywhere
[15:04] <desrt> larsu: http://www.fpaste.org/PwuQ/
[15:05] <mlankhorst> lamalex: yeah it's probably ddx feeding crap
[15:07] <lamalex> what is dd
[15:07] <lamalex> x
[15:08] <mlankhorst> erm the xorg driver
[15:08] <lamalex> ah
[15:08] <lamalex> very frustrating
[15:10] <mlankhorst> BEGIN_END_ACTIVE - You tried changing stuff while begin/end was active.
[15:10] <mlankhorst> hmz
[15:20] <mlankhorst> feeling adventerous? :P
[15:26] <mlankhorst> if not the easy fix is disabling exa by specifying option "noaccel" in xorg.conf for nouveau driver
[15:46] <desrt> attente: hey.  got a job for you :)
[15:47] <attente> desrt: sure :) what is it?
[15:47] <desrt> attente: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1070905
[15:47] <ubot2> Launchpad bug 1070905 in gnome-control-center (Ubuntu) "a11y panel calls g_settings_new() on (uninstalled) overlay scrollbar schema" [Undecided,New]
[15:47] <desrt> it's caused by a patch we have in our gnome-control-center package
[15:48] <desrt> it's now possible to check if a particular schema is installed via g_settings_schema_source_get_default() -> g_settings_schema_source_lookup()
[15:48] <desrt> so you should do this before it tries to do g_settings_new()
[15:48] <attente> ok, sounds easy enough
[15:49] <seb128> attente, good opportunity to play with our workflow ;-)
[15:49] <qengho> kenvandine: that empathy-chat bug goes away the instant that the chat history vertically fills the allotted space.  I'm betting on some scroll-bar hackiness.
[15:49] <seb128> attente, https://wiki.ubuntu.com/DesktopTeam/Bzr is worth reading
[15:49] <desrt> seb128: i gave him this bug because it's the perfect chance :)
[15:50] <kenvandine> oh
[15:50] <kenvandine> interesting
[15:50] <attente> seb128: thanks
[15:50] <kenvandine> qengho, ok... well it couldn't be overlay scrollbars
[15:50] <kenvandine> cassidy said he gets it on fedora with our theme
[15:53] <mlankhorst> lamalex: can you try "[PATCH] nouveau: Do not use nva3 engine for 0xaf chipset" ?
[15:53] <mlankhorst> probably can get it off ml somewhere
[15:54] <lamalex> mlankhorst, https://patchwork.kernel.org/patch/1272971/ ?
[15:54] <mlankhorst> assume so
[15:55] <lamalex> is there a guide somewhere to patching my kernel?
[15:55] <lamalex> never done this
[15:56] <mlankhorst> https://help.ubuntu.com/community/Kernel/Compile
[16:01] <seb128> attente, https://launchpad.net/~huaw is your launchpad id right*k
[16:02] <seb128> *k->?
[16:02] <attente> ~attente
[16:02] <seb128> crap
[16:02] <attente> i think that's my old one
[16:02] <attente> from way back when
[16:02] <desrt> we had a workstation in 229
[16:02] <seb128> attente, ok, I found ~huaw, I added the wrong one to our team :p
[16:02] <seb128> changing it
[16:02] <desrt> with english/french labels on all of the buttons, canadian style
[16:03] <desrt> one of them was labelled "attente"
[16:03] <desrt> it stuck
[16:03] <attente> thanks, seb128
[16:41] <orpok> how can i start x in safe mode? using ubuntu 12.10 and tried to use amd's drivers, now compiz crashes
[16:41] <orpok> oops wrong channel
[17:22] <xclaesse> I've got a belgian bluetooth keyboard, every time I reboot its layout is reset to qwerty
[17:22] <xclaesse> instead of azerty
[17:22] <xclaesse> in gnome-control-center it still says it's belgian
[17:23] <xclaesse> is that known problem? any workaround?
[18:44] <bryce> xclaesse, check launchpad.
[18:59] <desrt> attente: hey.  we're back from dinner.  how goes it?
[19:00] <attente> uh, it's going
[19:00] <attente> i have some questions
[19:00] <attente> why allow g_settings_new to crash if the schema isn't available?
[19:01] <kenvandine> haha
[19:02] <attente> :)
[19:02] <kenvandine> desrt's fault
[19:03] <dobey> haha
[19:06] <attente> the other question is
[19:06] <attente> do we have to check for all of the other settings schema too?
[19:07] <attente> like org.gnome.desktop.wm.preferences?
[19:11] <kirkland> okay, upgraded to Quantal and when I hit my browser back button on my thinkpad, the stupid unity launcher pops up
[19:11] <kirkland> how do I disable that?
[19:12] <kirkland> looks like this bug, perhaps?  https://bugs.launchpad.net/unity-2d/+bug/968840
[19:12] <ubot2> Launchpad bug 968840 in unity-2d "HUD gets activated by Thinkpad USB Keyboard's back and forward buttons" [Medium,Fix released]
[19:16] <kirkland> http://irclogs.ubuntu.com/2012/04/24/%23ubuntu-desktop.html
[19:16] <kirkland> there we go;  I knew I had to work around this previously
[19:17] <kirkland> okay, sweet, fixed (again)
[19:17] <kirkland> this setting got lost on upgrade to 12.10, fwiw
[19:19] <seb128> jbicha, hey, is "Nathanel Titane" doing IRC?
[19:20] <seb128> attente, I just joined and don't have the backlog for your question, but is that for g-c-c?
[19:20] <seb128> in which case, no need to check for those, g-c-c depends on gsettings-desktop-schemas, that package is not optional
[19:20] <attente> seb128: ok, cool
[19:21] <attente> ls
[19:26] <jbicha> seb128: I don't think he's logged on now, but he's used nathaneltitane before
[19:26] <seb128> jbicha, ok
[19:27] <seb128> jbicha, topic like "use current nautilus" are not very useful if you are not looking at forking the whole stack
[19:27] <seb128> jbicha, if the library change interface it's going to force you to fork every single app using libnautilus
[19:27] <seb128> jbicha, if the new nautilus depends on some other GNOME components it's going to create issues as well
[19:28] <seb128> e.g thing nautilus-sendto
[19:28] <seb128> well, not my call but I would recommend strongly against going this way
[19:28] <seb128> it's going to bite back
[19:34] <jbicha> seb128: hmm? I think I'm missing some context
[19:34] <seb128> jbicha, speaking about https://blueprints.launchpad.net/ubuntu/+spec/gnome-nautilus-gnomebuntu
[19:36] <jbicha> first I saw that, but yeah that topic isn't very useful
[19:37] <jbicha> "This would provide the essential, unaltered, out of the box experience Ubuntu is known for"
[19:39] <seb128> jbicha, well, I'm just saying you are up to fork the whole GNOME stack in a conflicting/co-installable way, including gtk
[19:40] <seb128> it might be easier to just create a derivative distro rather than a flavor if you try to do this
[19:41] <jbicha> seb128: I think the blueprint is just reaction to Ubuntu including Nautilus 3.4; of course next cycle will be worse for shipping the latest GNOME but at least we'll have nautilus 3.6
[19:42] <seb128> jbicha, yeah, maybe I understand the purpose of the blueprint, it sounds like "ship the latest GNOME in the archive somewhere even if Ubuntu stay on the n-1 version"
[19:43] <seb128> bryce, hey, I'm changing the approver of https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-xorg-general to me, feel free to pick somebody else but we usually try to have a different people for drafter and approver (it doesn't make sense to have the writer being the one approving himself as well)
[19:47] <bryce> seb128, the xorg-general blueprint is really just for the discussion, if any actual project work comes out of it then that would be done as separate blueprints.
[19:48] <seb128> bryce, ok, fair enough, I was making the comment as it might apply to other specs as well
[19:48] <bryce> seb128, we could set chris as the drafter if that would be more proper, but really nothing will be drafted (just misc. work items that don't fit into bp's)
[19:49] <seb128> bryce, well, your call, typically (from pitti's time) the default approver is the team lead/tech lead since those are the ones doing the review of the team load, etc after UDS
[19:49] <seb128> so we have sort of kept doing it this way
[19:49] <seb128> we can discuss it next week if you think we should do it differently
[19:55] <bryce> seb128, right, and as per jason's email does it not make the most sense for that to be the X team tech lead?  unless you just enjoy the extra paperwork.  ;-)
[19:56] <seb128> bryce, I'm not enjoying extra paperwork no ;)- but we decided that we stay one team with one chart for the team and not 3 charts ... anyway as I first say just pick different people for drafter and reviewer, your call who those are then ;-)
[20:18] <bryce> seb128, alright looks good
[20:19] <bryce> seb128, maybe canonical-desktop should not be subscribed to blueprints to cut down on blueprint update spam?
[20:19] <Laney> indeed
[20:20] <seb128> where is it subscribed?
[20:20] <bryce> seb128, printer dialog
[20:21] <seb128> bryce, Laney: oh, apparently tkamppeter did that ... unsubscribed, thanks for pointing it,
[20:22] <seb128> tkamppeter, please don't subscribe teams to blueprints, just the people who should be there
[20:23] <seb128> attente, thanks for patch, please take some time to read the wiki page I pointed and http://developer.ubuntu.com/packaging/html/
[20:24] <seb128> attente, it seems a good opportunity to see a bit of packaging and our workflow
[20:24] <desrt> attente: i also left some comments about the patch itself
[20:24] <seb128> attente, e.g do a debian/patches patch, generate a debdiff etc
[20:24] <seb128> doing a merge request
[20:24] <attente> ok
[20:24] <seb128> well it's usually either a debdiff or merge request, but it's useful to see how both are working ;-)
[20:26] <bryce> hrm, many of these gaming blueprints I'm not sure there's really going to be one hour's worth of discussion
[20:26] <attente> desrt: i'm not sure why it didn't crash when i tested it, if the second point applies
[20:27] <desrt> attente: did you actually try changing the theme?
[20:27] <desrt> the code only runs in that case
[20:29] <attente> ah ok
[20:29] <desrt> see the crash now?
[20:29] <desrt> (or critical?)
[20:29] <attente> well, i need to figure out how to change the theme first
[20:29] <desrt> it's at the top of the a11y dialog
[20:29] <desrt> Contrast:
[20:30] <desrt> low/normal/high/high-inverse
[20:31] <bryce> seb128, given that most of the gaming blueprints are set to priority low or medium, I think it doesn't make sense to devote so many uds slots esp. since we have only 4 days.  I would suggest merging the two audio BPs, and merge the process cleanup BP in with the graphics one.  maybe others could be merged.
[20:36] <seb128> bryce, yeah, that's a good point, dpm registered the topics he had on his list I think, feel free to do some editing and reject the non needed one from uds-r
[20:36] <seb128> bryce, though I guess e.g the audio ones will have a few people who will probably not have so many sessions to join so if we have enough rooms it shouldn't create much conflicts
[20:39] <seb128> ok, time to call it at day, 'night everyone
[20:39] <desrt> lies
[20:39] <desrt> seb is going for more beer now
[20:40] <desrt> quoth seb "i'm calling it a day.... on the work side"
[22:30] <doomlord> anyone here?
[22:45] <sarnold> doomlord: irc tends to work best if you just ask whatever question may be on your mind :)