[00:10] <smspillaz> hi
[00:20] <RAOF> Howdie smspillaz
[00:20] <RAOF> What's going down in groove town?
[00:34] <smspillaz> groove town ?
[00:34] <smspillaz> its perth
[00:34] <smspillaz> nothing happens here
[00:39] <smspillaz> RAOF: well, I am grooving out by writing tons and tons of classes and abstractions to make testing work in compiz but its like
[00:39] <smspillaz> this is the one thing that makes me hate C++
[00:39] <RAOF> Yup.
[00:40] <RAOF> Dynamic languages like python love unit-testing, and low level stuff like C also works fine.  It's the intermediate languages like C++ where unittesting means fighting language features.
[00:41] <smspillaz> its not really fighting its more like
[00:41] <smspillaz> forcing you to do things properly
[00:41] <smspillaz> except that nobody ever did things "properly" in compiz
[00:41] <smspillaz> so you pretty much end up rewriting the whole thing
[00:56] <desrt_> smspillaz: hey.  can i convince you to use the compiz bell plugin as a procrastination strategy to avoid writing tests?
[01:02] <smspillaz> desrt: lol
[01:02] <smspillaz> desrt: but then I'd have to write tests for the bell plugin!
[01:03] <smspillaz> desrt: and then tests for the tests!
[01:03] <RAOF> Move Xig!  For great justice!
[01:03] <smspillaz> lol
[01:03] <desrt> smspillaz: you could invoke proverbs to avoid writing a test for the bell plugin
[01:03] <desrt> who would question the knowledge or proverbs?
[01:03] <smspillaz> desrt: proverbs
[01:03] <desrt> *of
[01:03] <smspillaz> ?
[01:03] <desrt> smspillaz: commit message: 'ask not for whom the bell tolls'
[01:03] <smspillaz> lol
[02:29] <robert_ancell> RAOF, configure.ac:36: error: must install xorg-macros 1.14 or later before running autoconf/autogen - any ideas?
[03:56] <RAOF> robert_ancell: Got xutils-dev installed?  That's where xorg-macros lives.
[03:57] <robert_ancell> RAOF, that's what I'm looking for, thanks!
[03:58] <robert_ancell> RAOF, hey, does anyone use colormaps anymore?
[03:59]  * desrt eyes robert_ancell with a high level of suspicion
[04:00]  * robert_ancell looks innocnet
[04:00] <desrt> i hope you're not planning on doing anything that would make it more difficult for me to run starcraft!
[04:00] <robert_ancell> and spell good
[04:00] <robert_ancell> desrt, does starcraft use colormaps?
[04:00] <desrt> yes
[04:00] <robert_ancell> via wine?
[04:00] <desrt> well
[04:00] <desrt> it uses windows colourmaps
[04:00] <desrt> "256 color mode"
[04:01] <desrt> i think wine may automatically convert if the X server is running in 24/32bit
[04:01] <desrt> which generally causes the game to run much slower
[04:01] <RAOF> Right.
[04:01] <desrt> since it can't just memory map straight through anymore
[04:01] <RAOF> No one uses colormaps.
[04:01] <desrt> but has to perform a mapping on each pixel
[04:01] <RAOF> Because no one uses 8bpp.
[04:02] <desrt> starcraft is the most important thing you can do with your computer
[04:02] <RAOF> Technically, the Composite extension allows you to divorce the bitdepth of the windows from the bitdepth of the framebuffer.
[04:02] <desrt> we should really have someone dedicated to making sure it runs efficiently
[04:02] <RAOF> So, if you wanted fast starcraft what you should do is to propose an extension to Composite, and implement it.
[04:02] <desrt> hmmmmm
[04:03] <desrt> on the premise that mutter/compiz would be able to do the colour mapping faster than wine?
[04:03] <desrt> (probably a pretty good premise, actually)
[04:03] <RAOF> Right.
[04:03] <robert_ancell> is starcraft not fast enough anyway?  I mean, it was designed in the early pentium era right?
[04:03] <RAOF> There have been discussions on the xorg devel mailing list along the lines of “Yeah, this is totally possible, and I'll implement it.  Right after learning Portugese”
[04:03] <desrt> robert_ancell: having to map every single pixel as it's written to the screen is a non-trivial undertaking
[04:04] <desrt> even if there's only 640x480 of them :p
[04:04] <RAOF> Actually, its really eas.
[04:04] <RAOF> As long as you're allowed to use a GPU.  Which seems reasonable :)
[04:04] <desrt> right.  wine uses the cpu :)
[04:04] <desrt> and i think it does it on the same core as the game is already running on
[04:04] <RAOF> It totally should be creating 8bit palletised textures.
[04:04] <desrt> so no help there
[04:04] <desrt> hah
[04:04] <RAOF> It's a supported GL format :)
[04:05] <RAOF> (Which I think (a) no-one uses and hence (b) no-one cares that it's slow)
[04:05] <desrt> i don't think it has that level of information from starcraft
[04:05] <desrt> i think it just sees a giant field of pixels
[04:05] <RAOF> No, but Compiz certainly could.
[04:05] <desrt> ah
[04:06] <desrt> you mean dynamically update a 640x480-sized 8bit texture with the framebuffer content from the game
[04:06] <desrt> ya.  that would probably work rather well
[04:06] <RAOF> Yeah.  You'd advertise an 8bit window format to Wine, Wine would use it, and Compiz would do the upload as an 8bit palletised texture.
[04:07] <desrt> i can imagine that it could be the least-optimised codepath in the GPU/driver and still be capable of delivering full motion at 640x480 on intel hardware
[04:07] <desrt> t wine: plz haz 8bit pixmap
[04:08] <desrt>  - love, compiz
[04:08] <RAOF> Failing anything else, colourspace conversion is the poster-child for pixel shaders.
[04:08] <RAOF> Which everything non-ancient has.
[04:08] <desrt> RAOF: so.. how much free time do you have this cycle to dedicate to making starcraft awesomely fast while using 1% of the CPU?
[04:09] <RAOF> I've already got an X extension on my plate, and it's not Composite :P
[04:09] <desrt> btw
[04:09] <desrt> did you see ajax finally pushed the xfixes extension for selective property notifications?
[04:10] <desrt> i don't care what version of X you're shipping this cycle, you need to pick that patch
[04:12] <RAOF> I did see that, yes.
[04:17] <desrt> actually, now that i read the email, i don't care for it that much
[04:17] <desrt> it falls short in a couple of areas
[04:17] <desrt> but it's still a million times better than the current situation
[04:18] <desrt> and it fits with the nature of X better than my own suggestion did
[04:18] <robert_ancell> RAOF, ooh, which extension is that?
[04:19] <RAOF> Something for DX.
[04:19] <desrt> RAOF: how about my grab-detecting extension? :)
[04:20] <desrt> that would actually be useful...
[04:20] <desrt> (well... the starcraft thing would be useful too... but i can understand if it's a bit of a hard sell)
[04:21] <desrt> ((and honestly, would probably most easily be implemented as a nested X server which rendered itself using GL complete with scaling and the input mapping required to deal with that))
[04:27] <robert_ancell> learning more about X really makes the old stuff in GTK+ make a lot more sense
[04:27] <desrt> but also makes you want to kill it with fire all the more...
[04:28] <desrt> colourmaps and visuals leaking out of the toolkit = pretty broken abstraction
[04:35] <robert_ancell> RAOF, No package 'xf86driproto' found ?
[04:36] <RAOF> x11proto-dri-dev?
[04:36] <RAOF> Ah, sorry. x11proto-xf86dri-dev
[04:36]  * RAOF is apparently today's apt-file replacement ☺
[04:37] <robert_ancell> so much friendlier than apt-file :)
[04:47] <TheMuso> lol
[05:35] <pitti> Good morning
[07:09] <didrocks> good morning
[07:09] <pitti> hey didrocks
[07:10] <didrocks> guten morgen pitti
[07:59] <Sweetshark> Moin Desktopers!
[07:59] <pitti> hey Sweetshark, how are you?
[07:59] <pitti> didrocks: enjoyed your first "free" weekend? :-)
[08:01] <didrocks> pitti: well, not as much as I wanted. Unfortunatly since last Thursday, my neck is totally blocked (as the top of my body), so I can't really moved and the pain is quite severe :/ So, the week-end has been video games mostly, trying to move as few as possible
[08:01] <didrocks> but video games week-end can be nice sometimes…
[08:01] <pitti> didrocks: erk, how did that come?
[08:01] <pitti> didrocks: the video gaming sure, but certainly not the body pain?
[08:03] <didrocks> pitti: I'm not sure at all how it came, made a vasovagal episod Wednesday evening on the way back from the rock danse. Julie told me that I was quite straight during this, so maybe I hurted some muscles back then
[08:07] <didrocks> pitti: and you? how was your week-end? Went to Dresden?
[08:07] <pitti> didrocks: no, to Halle; we had a family thing there (my in-law's parents)
[08:08] <pitti> but we went back on Saturday evening
[08:08] <didrocks> ah ok, was a short visit then :)
[08:08] <pitti> so we spent yesterday with some gardening, and then when the storm/rain started, we just idled, did some reading, and I played Diablo II again :)
[08:10] <didrocks> heh, nice :)
[08:17] <smspillaz> didrocks: weird, you have the same thing that I had last week
[08:18] <didrocks> smspillaz: oh, really?
[08:18] <smspillaz> yeah, had a really stiff spine last week
[08:18] <smspillaz> pain to do anything
[08:19]  * smspillaz wonders if there was something going around in orlando
[08:24] <Sweetshark> pitti: Fine, thanks. I had some guests and we partied a bit (officially because of my election to deputy director, inoffically because it is fun). And I am getting to old for this, leaving the flat at midnight to continue on the Kiez ...
[08:25] <pitti> Sweetshark: heh, I symphatize; back then I usually got home when it was light outside again, but these days I just fall asleep around 2 on a Saturday night :(
[08:27] <Sweetshark> well, on the reeperbahn there are some clubs that open when everyone else closes to keep people partying until the others open again, so they can continue there ...
[08:28] <Sweetshark> ... great for drugged up technocrowd that run around like duracellbunnies.
[08:28] <pitti> hehe
[08:28] <pitti> but when it gets late, I also either need to go home or go dancing; just sitting and drinking doesn't work any more
[08:44] <didrocks> rickspencer3: hey, I think that you wanted to assign the dx team for the compiz bug, isn't it? bug #897829
[08:44] <ubot2> Launchpad bug 897829 in compiz "Assigning shortcut to "Move window to workspace X" doesn't ever take effect" [Low,New] https://launchpad.net/bugs/897829
[08:44] <rickspencer3> didrocks, well, I thought the desktop team might want to hide the option since it doesn't work
[08:45] <rickspencer3> didrocks, but just reassign as desired
[08:45] <didrocks> rickspencer3: sorry, read ccsm :)
[08:45] <didrocks> not g-c-c
[08:45] <didrocks> yeah, you're right, or maybe I can bind the key to a compiz one, let me check
[08:46] <rickspencer3> didrocks, you don't *have* to respond
[09:18] <chrisccoulson> good morning desktop team
[09:25] <didrocks> hey chrisccoulson, how are you?
[09:25] <pitti> hey chrisccoulson
[09:37] <seb128> hey
[09:37] <pitti> bonjour seb128, ca va?
[09:37] <didrocks> salut seb128
[09:37] <seb128> hey pitti, I'm good thanks, how are you?
[09:37] <seb128> lut didrocks
[09:38] <seb128> hum, my connection is laggy today it seems :-( took me a while to connect to IRC and reading imap on the canonical imap is slow
[10:05] <chrisccoulson> hi didrocks, pitti, seb128
[10:05] <seb128> hey chrisccoulson, how are you?
[10:05] <chrisccoulson> seb128, yeah, not too bad thanks. how are you?
[10:06] <seb128> I'm good thanks
[10:06] <pitti> Sweetshark: could you please upload a new openoffice.org  which doesn't build openoffice.org-base on armel?
[10:06] <pitti> Sweetshark: it only exists on amd64, i386, powerpc
[10:07] <pitti> Sweetshark: or alternatively, is the absence of libreoffice-base on armel a bug or can't it work on armel for some reason?
[10:55] <pitti> Sweetshark: I'll just fix oo.o
[10:57] <rodrigo_> hello
[10:59] <seb128> hey rodrigo_, how are you?
[11:02] <rodrigo_> hi seb128
[11:08] <pitti> Sweetshark: does http://paste.ubuntu.com/760293/ look ok to you?
[11:10] <Sweetshark> pitti: yes, looking good
[11:10] <pitti> Sweetshark: ok, hanks
[11:10] <pitti> thanks
[12:34] <seb128> hehe
[12:34] <seb128> "<Np237> mbiebl, is it really wise to switch to totem 3.2 in this situation?
 Np237: looks bad, here at least.
 Do we need to package totem 3.0 as totem-fallback too? o_O"
[12:34] <seb128> \o/ for not jumping on the clutter based version ;-)
[12:36] <pitti> seb128: :)
[13:12] <rodrigo_> lunch, bbl
[14:19] <seb128> pitti, there is https://code.launchpad.net/~mitya57/nautilus/ubuntu-fix-lp-795708/+merge/84370 on version if you feel like doing desktop sponsoring ;-)
[14:19] <pitti> seb128: oh, please :)
[14:19] <seb128> that's likely a good candidate for a sru as well
[14:20] <pitti> didrocks: ok for me to do https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz-plugins-main/fix-sru-regressions-2/+merge/83590, or do you want to handle compiz-y stuff yourself?
[14:21] <pitti> seb128: so these don't appear on http://reports.qa.ubuntu.com/reports/sponsoring/ :(
[14:21] <seb128> pitti, no, because there are against a team vcs
[14:21] <didrocks> pitti: just check that there are tests for both in trunk at least as we will need to copy c-p-m to precise and tests for compiz is part of the requirements
[14:22] <seb128> didrocks, pitti: can we please not block those sru regression fixes on precise work?
[14:22] <didrocks> if we don't have to push the SRU to precise, it's fine
[14:22] <didrocks> otherwise, we really can't push it
[14:22] <seb128> it's already embarassing enough that we broken those and didn't fix them in over a month of time
[14:23] <didrocks> agreed, but I asked confirmation about "not pushing anything not tested in precise", even if it's to fix a SRU, so if pitti agrees that it's only pushed to oneiric and not precise, that would be possible
[14:23]  * didrocks is between a rock and a hard place for this :/
[14:23] <pitti> didrocks: ok for me, but really unusual
[14:24] <didrocks> pitti: thanks Martin :)
[14:28] <xclaesse> seb128, empathy package does not seems to install mcp-account-manager-goa.so
[14:29] <xclaesse> it should go to /usr/lib/mission-control-plugins.0/
[14:29] <xclaesse> in precise
[14:30] <xclaesse> also I guess it needs to do some magic to make apparmor let mission-control load that plugin
[14:30] <xclaesse> because just installing it manually doesn't work
[14:30] <jdstrand> xclaesse: if this is in the default install, please file a bug and assign it to me
[14:31] <xclaesse> jdstrand, copied package into a oneiric ppa
[14:31] <seb128> kenvandine, ^
[14:31] <seb128> xclaesse, you better ping kenvandine about empathy packaging issues, he's the one doing most of the packaging work on it
[14:31] <xclaesse> seb128, ok thx :)
[14:31] <kenvandine> i can fix that
[14:32] <xclaesse> kenvandine, cool, thanks :)
[14:32] <kenvandine> np
[14:32] <xclaesse> kenvandine, FYI that plugin makes MC import accounts setup in gnome-online-account
[14:32] <xclaesse> so if you have a gtalk account in goa, it gets into empathy automatically
[14:32] <kenvandine> cool
[14:32] <kenvandine> xclaesse, what about accounts already in empathy?
[14:32] <kenvandine> does it detect the dupe?
[14:33] <xclaesse> no
[14:33] <xclaesse> you'll just get both
[14:33] <kenvandine> bummer
[14:33] <kenvandine> ok
[14:34] <xclaesse> kenvandine, goa also support facebook accounts (if build with an app secret key) and soon MSN (via XMPP!) as soon as davidz review my patch :)
[14:35] <kenvandine> ok
[14:35] <pitti> didrocks: I assigned the precise tasks of these two to you, please assign to teh correct person in DX; thanks!
[14:35] <didrocks> pitti: excellent, thanks!
[14:50] <seb128> om26er, pitti: the compiz sru is screwed :-( how come it doesn't include the fix for bug #876591 which is in the packaging vcs for some weeks?
[14:50] <ubot2> Launchpad bug 876591 in compiz-plugins-main "Ctrl-Alt-KP_9 adjusts window to upper half instead of top right corner (behaves like Ctrl-Alt-KP_8)" [High,Confirmed] https://launchpad.net/bugs/876591
[14:51] <pitti> seb128: oh, we have a bzr for oneiric?
[14:51] <om26er> seb128, this one https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz-plugins-main/fix-regressions
[14:51] <om26er> this branch also have the fix for 876591
[14:51] <seb128> pitti, no, we usually don't create a new serie if precise didn't get a newer version
[14:51] <pitti> seb128: so you mean s/screwed/incomplete/, or is it actually broken as-is?
[14:52] <seb128> om26er, how come you didn't propose that one for sponsoring?
[14:52] <pitti> seb128: we can reject this, and upload that other branch instead, fine for me
[14:52] <seb128> pitti, no, it just doesn't contain one of the fixes, so incompletes
[14:52] <pitti> sorry, I didn't check trunk bzr, just the MP
[14:52] <om26er> it was creating a very big diff like a few thousand lines
[14:52] <seb128> om26er, you were proposing it against the wrong serie I guess?
[14:53] <pitti> presumably http://bazaar.launchpad.net/~compiz/compcomm-plugins-main/ubuntu is a custom branch
[14:53] <pitti> while om26er's MP was against the UDD one
[14:53] <seb128> pitti, don't bother, we will get the other bug fixed in the next one I guess
[14:53] <pitti> you can't merge them to each other
[14:53] <om26er> i cant propose my branch to https://code.launchpad.net/~compiz/compcomm-plugins-main/ubuntu there is no option
[14:53] <seb128> I will just unsubscribe from the bug meanwhile
[14:54] <pitti> om26er: no, as I said you can't merge UDD branches against debian/ only ones, and vice versa
[14:54] <pitti> they are two entirely different things
[14:55] <om26er> pitti, alright so where should i propose https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz-plugins-main/fix-regressions now?
[14:56] <pitti> om26er: you can't propose it anywhere else
[14:56] <pitti> om26er: if you branch from UDD, you have to merge to UDD
[14:56] <pitti> om26er: i. e. the "correct" way would have been to branch from ~compiz/compcomm-plugins-main/ubuntu, do additional changes there, and propose to merge against that again
[14:56] <pitti> om26er: but as seb128 said we can get to that patch in the next round
[14:57] <seb128> pitti, waouh, down to 23, good job (to you and others, 37 was already low, it was around 70 until recently)
[14:58] <seb128> om26er, or do another merge request just for this one
[14:58] <seb128> it might be good to get in because ctrl-alt-kp9 seems to be quite visibly broken and we have users who wonder why the 1 liner is still not landing after a month ;-)
[14:59] <om26er> seb128, sure, I can do that now
[14:59] <seb128> om26er, thanks
[14:59] <om26er> pitti, thanks for clearing things :-)
[14:59] <om26er> seb128, :-)
[15:07] <jincreator> pitti: Hi, are you busy now?
[15:07] <pitti> jincreator: I'm always busy, it's a matter of what I'm busy with :)
[15:08] <jincreator> pitti: I saw you remove 69-language-selector-ko-kr.conf.
[15:09] <pitti> jincreator: right, you said it was obsolete as we are using nanum now?
[15:09] <jincreator> pitti: Yes, but only for when Un fonts is default at Korean font. Sorry for make confusing.
[15:10] <pitti> jincreator: I thought the hack was for unfonts?
[15:10] <jincreator> pitti: Yes, it is. But we are trying to change default font from unfonts to fonts-nanum.
[15:11] <pitti> jincreator: right; so if the hack only applies to unfonts, why do we need it if we are using nanum?
[15:12] <jincreator> pitti: Because fontconfig-config(and upstream at freedesktop) doesn't have setting for fonts-nanum. I report bug to fontconfig for add it, but it looks lots of time to applied.
[15:14] <jincreator> So fonts-nanum maintainer(in Debian) add fontconfig snippet to overwrite settings and make fonts-nanum as default font, but it seems not working at latest Ubuntu.
[15:14] <pitti> jincreator: right, that's the <lang> issue we talked about
[15:15] <jincreator> pitti: Yes, so if we patch fontconfig-config to add information about fonts-nanum, we can remove 69-language-selector-ko-kr.conf. But I think just modify 69-la... is easier and simple workaround. What do you think about it?
[15:16] <pitti> jincreator: I think fixing the <lang> bug is better, as it will also unbreak other ttf-* packages
[15:17] <pitti> jincreator: and NB that language-selector is going away, so we'll need to drop the hacks anyway
[15:17] <pitti> or at least minimizing them so that we can port them to whatever replacement
[15:17] <pitti> but <lang> seems like a much better option than these static hacks, as they will be prone to being wrong
[15:17] <pitti> you might have more than user on a machine, etc. (think universities, etc.)
[15:22] <jincreator> pitti: You mean language-selector is no more exists at Precise?
[15:23] <pitti> jincreator: still there, but we have tried to get rid of it for a few cycles now, and rodrigo is almost there now
[15:23] <pitti> with adding enough functionality to the gnome-control-center module to replace it
[15:23] <pitti> l-s is quite horrible and unmaintainable code
[15:28] <jincreator> pitti: Ok, I see. I'll try to find another method to make font-nanum as default Korean fonts without using l-s.
[15:30] <pitti> jincreator: I thought making <lang> work would do the trick?
[15:30] <pitti> whatever breaks it, we should just fix that IMHO
[15:33] <pitti> good night everyone!
[15:33] <jincreator> pitti: good night!
[15:41] <didrocks> have a good night pitti :)
[15:52] <lool> didrocks: Hey, zeitgeist-core used to ship zeitgeist-daemon.pc which unity-lens-files checks for in configure, but it's nowhere in the archive in precise
[15:52] <lool> didrocks: should we drop the ZEITGEIST_DAEMON test from configure.ac?  it seems unused
[15:53] <didrocks> lool: that's more than possible that it's not shipped anymore with the new vala zg
[15:53] <didrocks> mhr3: I think you see both sides of this piece there ^
[15:55] <mhr3> didrocks, i'm not sure why files lens checked that
[15:55] <didrocks> lool: let's wait on kamstrup then
[15:56] <lool> didrocks: Sure; give me a heads up if you want me to upload a packaging fix, but lazy as I am, fixing it upstream would be even nicer  :-)
[15:57] <didrocks> lool: yeah, I think it's better to directly fix that upstream and less than a burden :)
[15:58] <mhr3> lool, didrocks, ok, it will be fixed upstream
[15:58] <didrocks> thanks :)
[15:58] <lool> mhr3: Thanks
[15:58] <mhr3> files lens doesn't need the check though
[15:58] <didrocks> mhr3: I can even propose a merge req if you want :)
[15:59] <didrocks> mhr3: will be the perfect time to boostrap the file lens automerge
[15:59] <mhr3> didrocks, merge req for files lens?
[15:59] <didrocks> yep
[15:59] <mhr3> didrocks, sure, why not
[15:59] <didrocks> mhr3: ok, will do that just after the call
[15:59] <mhr3> it'll fail though :P
[15:59] <didrocks> because of new libunity?
[15:59] <mhr3> yes :)
[16:00] <didrocks> ok, I'll let you do the libunity stuff first :)