[07:25] <tjaalton> duflu: hey, about bug 927168, should I send it upstream to the mesa guys, or is it a compiz bug?
[07:27] <duflu> tjaalton: Still not 100% but seems very likely a compiz bug. I just approved a potential compiz fix
[07:28] <tjaalton> duflu: oh cool, I could give it a try as well, easy to reproduce :)
[08:04] <jibel> om26er_, about bug 1052345, I don't have unity-window-decorator running but gtk-window-decorator. Is it the process I should kill ?
[08:14] <om26er_> jibel, yeah, sorry that was meant to be gtk-window-decorator
[08:15] <om26er_> there is a leak in gtk-window-decorator so i thought your issue maybe the same
[08:15] <jibel> om26er_, np, I commented on the report. The desktop is more responsive again.
[08:58] <dholbach> hiya
[08:58] <dholbach> do we have some docs for how to "integrate a program into the HUD"?
[08:58] <dholbach> http://daniel.holba.ch/blog/2012/09/ubuntu-dev-hangouts/#comment-653338925
[09:05] <didrocks> popey: FYI: https://bugs.launchpad.net/shotwell/+bug/1052375
[09:05]  * popey clicks
[09:08] <didrocks> popey: it's just a FYI, I just spent some time to sort that out between the different team
[09:08] <popey> thanks
[09:25] <didrocks> popey: do you have a status on compiz release/migration?
[09:25] <didrocks> popey: also, I think it will be good to backport latest commits from compiz as distro cherry-picks
[09:26] <popey> didrocks, ted kindly had a deep look at the migration issue, and identified some interesting stuff but not a conclusion, he's offered to look further
[09:27] <popey> didrocks, I agree..
[09:27] <popey> ^ Mirv :)
[09:27] <didrocks> popey: thanks!
[09:38] <Mirv> I've already cherry-picked the two additional compiz bug fixes that are targeted to beta-2. PPA (and packaging url) at https://launchpad.net/~timo-jyrinki/+archive/compiz-quantal-testing2
[09:39] <Mirv> or the other compiz bug fix is to a bug fix in unity that is targeted to beta-2, so essentially needed
[09:39] <didrocks> Mirv: excellent!
[09:40] <didrocks> Mirv: so rev 377 and rev 3376 are in?
[09:40] <didrocks> Mirv: I think rev 3374 is interesting as well
[09:40] <didrocks> so maybe better to merge tip on top of your content?
[09:42] <popey> thanks Mirv
[09:42] <Mirv> 3372 and 3376. tip would be nice, but as usual creates a risk of detecting late regressions when testing everything at once, and then we might miss beta 2 if we end into a loop of finding new bugs, trying to get them fixed etc, while 0.9.8.2 + cherry-picks have already been successfully tested
[09:44] <Mirv> there'll always be time for 0.9.8.4
[09:44] <Mirv> (3368 and 3373 are also in the packaging branch)
[09:50] <didrocks> Mirv: rev 3376 is fixing a critical bug for beta2
[09:50] <didrocks> Mirv: so we need at least this one
[09:51] <Mirv> yep, it's in, although apparently needs more than just that commit
[09:51] <didrocks> Mirv: ok, I'll let you decipher this :)
[10:07] <duflu> Mirv: You mean 3374, not 3373?
[10:07] <duflu> 3374 is getting lots of duplicate crash reports
[10:49] <Mirv> no, 3373 since it prevents unity from building.
[10:50] <Mirv> 3374 can be picked up as well
[14:14] <Mirv> I'm going the "tip" route...
[14:15] <didrocks> Mirv: sounds safe to me
[14:56] <didrocks> popey: Mirv: any news from ted on the migration?
[14:56] <didrocks> popey: Mirv: I think we won't have time to deal with those with tomorrow's release, so better to have that tackled before
[15:03] <popey> didrocks, sorry, was afk. just catching up
[15:08] <popey> didrocks, no movement yet
[15:08]  * popey hugs tedg 
[15:08]  * didrocks starts to be concerned
[15:08] <didrocks> really concerned
[15:13] <popey> not sure who else we can recruit/press-gang into helping tbh
[15:13] <didrocks> not sure, everyone is really busy…
[15:13] <didrocks> tedg: no time for that?
[15:14] <didrocks> popey: you have 4 people in your team, nobody can help Mirv? seems blocking on a transitional issue for 2 weeks shouldn't happen
[15:15] <popey> I am reaching out to tedg because he seems to have the knowledge to help. others do not.
[15:54] <tedg> didrocks, Yeah, unfortunately I end up in meetings :-)
[15:55] <didrocks> tedg: tell that your mic is broken dude! :-)
[15:55] <tedg> didrocks, Heh
[15:55] <didrocks> tedg: did you find anything yesterday?
[15:55] <tedg> didrocks, BTW, why is this a blocker?  Can we just say "eh, new configuration, you get defaults"?
[15:55] <didrocks> tedg: I didn't test is on my machine, so can't really tell
[15:55] <tedg> didrocks, There's some oddities, but I haven't found a final "this is what it is"
[15:55] <didrocks> tedg: well, gold rule is to keep user config
[15:56] <didrocks> tedg: like, if they tweak switching ws
[15:56] <didrocks> and it's reset to the default
[15:56] <tedg> didrocks, It seems the writer is going later than we'd like.
[15:56] <didrocks> this shows a bad quality product
[15:56] <tedg> didrocks, Sure, and we wouldn't touch their old config :-)
[15:56] <didrocks> well, we do with the gconf -> gsettings transition :)
[15:56] <tedg> didrocks, It seems like a "nice to have" and a "should do" but not a blocker.
[15:57] <didrocks> tedg: so, at worst, the user has the default config?
[15:57] <tedg> didrocks, Yes
[15:57] <didrocks> tedg: no binary corruption of the gsettings blob?
[15:57] <didrocks> like if there is a writing and a revert
[15:57] <didrocks> (this is what happens, right?)
[15:57] <tedg> It seems like there is a write and a revert, but the revert goes back to the default value.
[15:58] <tedg> I haven't seen any corruption, but I'd double check with Mirv to be sure he hasn't.
[15:58] <Mirv> no, I haven't seen any corruptions at any point
[15:59] <didrocks> well, ok, I think at this point we can keep as it is then
[15:59] <didrocks> let's keep the migration script
[15:59] <didrocks> tedg: did you talk to desrt?
[15:59] <didrocks> tedg: maybe he would have some inputs
[15:59] <didrocks> as it's clearly a dconf issue :)
[15:59] <tedg> didrocks, I asked him a couple of questions, but haven't pulled him in completely :-)
[16:00] <tedg> It is a bit odd that the gsettings migration tool doesn't force a sync, but I added that and it didn't help.
[16:00] <tedg> Well, it didn't solve it.
[16:00] <didrocks> tedg: you can tell him that you have so many "desrt" files and path on your system that he has to do the support now :p
[16:00] <tedg> I blame him for every bug in GTK+
[16:00] <didrocks> oh gsettings-data-convert doesn't force a sync?
[16:00] <didrocks> tedg: you sure probably do :)
[16:01] <tedg> didrocks, Nope.  I've got a patch, but it didn't solve this problem.
[16:01] <tedg> Not sure if we should add it just because it makes sense though.
[16:01] <didrocks> tedg: probably, well, no hurry though
[16:01] <didrocks> tedg: if you can get more info at some not that crazy time point from desrt, I would be interesting
[16:01] <didrocks> tedg: thanks for checking
[16:02] <didrocks> Mirv: popey: so I think we can go on, with the migration, as we are
[16:02] <didrocks> Mirv: popey: let's forget about the corner case, we will be blame, but seeing the unity release coming…
[16:12] <Mirv> ok. the new compiz snapshot packaging branch is at lp:~timo-jyrinki/ubuntu/quantal/compiz/ubuntu.0982bzr3377
[16:12] <Mirv> it's a shame it can't be released without a unity rebuild which cannot be done without updating unity and libunity...
[16:12] <didrocks> Mirv: libunity as well?
[16:12] <didrocks> Mirv: unity is because of at-spi2, right?
[16:12] <didrocks> but libunity?
[16:13] <Mirv> didrocks: the unity version that brings at-spi2 (if not cherry-picking) happens to also require newer libunity
[16:13] <didrocks> Mirv: can we cherry-pick the unity at-spi2 commit only?
[16:14] <Mirv> didrocks: we could, although then that combo should be also tested
[16:14] <Mirv> and the whole stack will need testing tomorrow as well
[16:14] <Mirv> I can prepare such a PPA anyway which has compiz + unity 6.4+at-spi2
[16:15] <didrocks> Mirv: no need I guess, if we are confident that the whole stack would be ready by tomorrow
[16:15] <didrocks> Mirv: how many additional commit is compiz trunk?
[16:16] <didrocks> Mirv: compared to latest tests
[16:17] <Mirv> didrocks: well I'll prepare. I'm not 100% confident of all of this, but I tend to be on the cautious side. 14 commits since latest was tested.
[16:18] <didrocks> Mirv: yeah, 14 is a lot
[16:19] <Mirv> at least I'll check if unity 6.4 + a11n cherry-pick + latest compiz would be one functional combination
[16:19] <didrocks> Mirv: so, let's get one stack tested
[16:19] <didrocks> ok :)
[16:19] <didrocks> thanks Mirv
[16:19] <Mirv> no prob
[16:27] <conscioususer> mpt: have some minutes to talk about https://bugs.launchpad.net/dbusmenu/+bug/541472?
[16:28] <mpt> conscioususer, hey! I'm in a meeting, but in about 30 min
[16:28] <conscioususer> mpt: ok, I'll stay around
[17:06] <Mirv> ok unity 6.4 + a11n cherry-pick alone was not successful unfortunately https://launchpadlibrarian.net/116530817/buildlog_ubuntu-quantal-amd64.unity_6.4.0-0ubuntu7~test1_FAILEDTOBUILD.txt.gz
[17:08] <mpt> conscioususer, yo
[17:08] <conscioususer> mpt: hi
[17:09] <conscioususer> mpt: hope the meeting went well :)
[17:09] <mpt> no comment
[17:09] <mpt> but seriously, it was good
[17:09] <conscioususer> ah, you got me worried for a moment there
[17:10] <conscioususer> so, icons!
[17:10] <conscioususer> if I understood correctly, you guys want to invest in auto-resizing according to font size?
[17:13] <conscioususer> mpt: how would the approach to scaling be, considering there is a set of discrete sizes?
[17:14] <mpt> conscioususer, I don't know, but I imagine it would be choosing the nearest discrete size up to a certain level, and thence scaling the scalable/largest
[17:14] <mpt> So graphed, like a staircase followed by a ramp
[17:14] <conscioususer> mpt: the nearest *larger* than the font, I suppose
[17:15] <mpt> I don't know
[17:15] <conscioususer> mpt: hmm, or maybe the smaller one, so it's aesthetically better to keep all items with the same height
[17:15] <mpt> maybe
[17:16] <conscioususer> mpt: anyway, IIRC one problem with your proposal on the report is that changing the constant (supposing that is even possible) will not auto-update the icons
[17:16] <conscioususer> mpt: I think the size is read when the pixbuf is read, and never again
[17:18] <mpt> conscioususer, could you comment about that in the bug report? I don't really know what a pixbuf is. :-)
[17:18] <conscioususer> mpt: will do
[17:18] <mpt> thanks!
[17:19] <conscioususer> mpt: the GNOME HIG (leaving aside the fact that it needs a new version) simply says "menu icons should be 16x16" and leaves it at that http://developer.gnome.org/hig-book/3.5/icons-types.html.en
[17:19] <conscioususer> mpt: so I'm not sure what is the position of GNOME/GTK devs on this
[17:19] <conscioususer> mpt: but leaves me pessimistic as to how easy it will be to reach the goal
[17:19] <mpt> conscioususer, desrt is going to report it upstream for starters
[17:20] <conscioususer> mpt: current version of polly resizes icons, but I use exact sizes instead of restricting itself to the discrete ones... that ended up in blurring disaster, won't keep that for the gtk3 port
[17:21] <mpt> What do you mean by "instead"? The discrete sizes are exact sizes, no?
[17:25] <conscioususer> mpt: I meant I don't necessarily choose one of the discrete ones... so it's possible to have 20x20, 21x21, 23x23, 25x25, etc.
[17:26] <conscioususer> mpt: wrote on the report
[17:26] <mpt> thanks
[19:08] <njin> Hallo, this is my live session of quantal today build amd64, running on amd2800+, 1,6 GHz, 2Gram, Geforce 6100 onboard, http://www.youtube.com/watch?v=bC-9OZmI4XI&feature=youtu.be
[19:10] <njin> is this compiz, unity, gtk or whatelse ?
[19:15] <njin> this machine before was working well on 2D, not fast but working.
[19:17] <njin> before I mean 12.04