[00:10] hi [00:20] Howdie smspillaz [00:20] What's going down in groove town? [00:34] groove town ? [00:34] its perth [00:34] nothing happens here [00:39] 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] this is the one thing that makes me hate C++ [00:39] Yup. [00:40] 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] its not really fighting its more like [00:41] forcing you to do things properly [00:41] except that nobody ever did things "properly" in compiz [00:41] so you pretty much end up rewriting the whole thing [00:56] smspillaz: hey. can i convince you to use the compiz bell plugin as a procrastination strategy to avoid writing tests? === desrt_ is now known as desrt [01:02] desrt: lol [01:02] desrt: but then I'd have to write tests for the bell plugin! [01:03] desrt: and then tests for the tests! [01:03] Move Xig! For great justice! [01:03] lol [01:03] smspillaz: you could invoke proverbs to avoid writing a test for the bell plugin [01:03] who would question the knowledge or proverbs? [01:03] desrt: proverbs [01:03] *of [01:03] ? [01:03] smspillaz: commit message: 'ask not for whom the bell tolls' [01:03] lol [02:29] RAOF, configure.ac:36: error: must install xorg-macros 1.14 or later before running autoconf/autogen - any ideas? [03:56] robert_ancell: Got xutils-dev installed? That's where xorg-macros lives. [03:57] RAOF, that's what I'm looking for, thanks! [03:58] 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] i hope you're not planning on doing anything that would make it more difficult for me to run starcraft! [04:00] and spell good [04:00] desrt, does starcraft use colormaps? [04:00] yes [04:00] via wine? [04:00] well [04:00] it uses windows colourmaps [04:00] "256 color mode" [04:01] i think wine may automatically convert if the X server is running in 24/32bit [04:01] which generally causes the game to run much slower [04:01] Right. [04:01] since it can't just memory map straight through anymore [04:01] No one uses colormaps. [04:01] but has to perform a mapping on each pixel [04:01] Because no one uses 8bpp. [04:02] starcraft is the most important thing you can do with your computer [04:02] Technically, the Composite extension allows you to divorce the bitdepth of the windows from the bitdepth of the framebuffer. [04:02] we should really have someone dedicated to making sure it runs efficiently [04:02] So, if you wanted fast starcraft what you should do is to propose an extension to Composite, and implement it. [04:02] hmmmmm [04:03] on the premise that mutter/compiz would be able to do the colour mapping faster than wine? [04:03] (probably a pretty good premise, actually) [04:03] Right. [04:03] is starcraft not fast enough anyway? I mean, it was designed in the early pentium era right? [04:03] 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] robert_ancell: having to map every single pixel as it's written to the screen is a non-trivial undertaking [04:04] even if there's only 640x480 of them :p [04:04] Actually, its really eas. [04:04] As long as you're allowed to use a GPU. Which seems reasonable :) [04:04] right. wine uses the cpu :) [04:04] and i think it does it on the same core as the game is already running on [04:04] It totally should be creating 8bit palletised textures. [04:04] so no help there [04:04] hah [04:04] It's a supported GL format :) [04:05] (Which I think (a) no-one uses and hence (b) no-one cares that it's slow) [04:05] i don't think it has that level of information from starcraft [04:05] i think it just sees a giant field of pixels [04:05] No, but Compiz certainly could. [04:05] ah [04:06] you mean dynamically update a 640x480-sized 8bit texture with the framebuffer content from the game [04:06] ya. that would probably work rather well [04:06] 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] 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] t wine: plz haz 8bit pixmap [04:08] - love, compiz [04:08] Failing anything else, colourspace conversion is the poster-child for pixel shaders. [04:08] Which everything non-ancient has. [04:08] 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] I've already got an X extension on my plate, and it's not Composite :P [04:09] btw [04:09] did you see ajax finally pushed the xfixes extension for selective property notifications? [04:10] i don't care what version of X you're shipping this cycle, you need to pick that patch [04:12] I did see that, yes. [04:17] actually, now that i read the email, i don't care for it that much [04:17] it falls short in a couple of areas [04:17] but it's still a million times better than the current situation [04:18] and it fits with the nature of X better than my own suggestion did [04:18] RAOF, ooh, which extension is that? [04:19] Something for DX. [04:19] RAOF: how about my grab-detecting extension? :) [04:20] that would actually be useful... [04:20] (well... the starcraft thing would be useful too... but i can understand if it's a bit of a hard sell) [04:21] ((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] learning more about X really makes the old stuff in GTK+ make a lot more sense [04:27] but also makes you want to kill it with fire all the more... [04:28] colourmaps and visuals leaking out of the toolkit = pretty broken abstraction [04:35] RAOF, No package 'xf86driproto' found ? [04:36] x11proto-dri-dev? [04:36] Ah, sorry. x11proto-xf86dri-dev [04:36] * RAOF is apparently today's apt-file replacement ☺ [04:37] so much friendlier than apt-file :) [04:47] lol === pitti_ is now known as pitti [05:35] Good morning [07:09] good morning [07:09] hey didrocks [07:10] guten morgen pitti === geser_ is now known as geser [07:59] Moin Desktopers! [07:59] hey Sweetshark, how are you? [07:59] didrocks: enjoyed your first "free" weekend? :-) [08:01] 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] but video games week-end can be nice sometimes… [08:01] didrocks: erk, how did that come? [08:01] didrocks: the video gaming sure, but certainly not the body pain? [08:03] 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] pitti: and you? how was your week-end? Went to Dresden? [08:07] didrocks: no, to Halle; we had a family thing there (my in-law's parents) [08:08] but we went back on Saturday evening [08:08] ah ok, was a short visit then :) [08:08] 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] heh, nice :) === highvolt1ge is now known as highvoltage [08:17] didrocks: weird, you have the same thing that I had last week [08:18] smspillaz: oh, really? [08:18] yeah, had a really stiff spine last week [08:18] pain to do anything [08:19] * smspillaz wonders if there was something going around in orlando [08:24] 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] 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] 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] ... great for drugged up technocrowd that run around like duracellbunnies. [08:28] hehe [08:28] 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] rickspencer3: hey, I think that you wanted to assign the dx team for the compiz bug, isn't it? bug #897829 [08:44] 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] didrocks, well, I thought the desktop team might want to hide the option since it doesn't work [08:45] didrocks, but just reassign as desired [08:45] rickspencer3: sorry, read ccsm :) [08:45] not g-c-c [08:45] yeah, you're right, or maybe I can bind the key to a compiz one, let me check [08:46] didrocks, you don't *have* to respond === Guest37602 is now known as jpds [09:18] good morning desktop team [09:25] hey chrisccoulson, how are you? [09:25] hey chrisccoulson [09:37] hey [09:37] bonjour seb128, ca va? [09:37] salut seb128 [09:37] hey pitti, I'm good thanks, how are you? [09:37] lut didrocks [09:38] 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] hi didrocks, pitti, seb128 [10:05] hey chrisccoulson, how are you? [10:05] seb128, yeah, not too bad thanks. how are you? [10:06] I'm good thanks [10:06] Sweetshark: could you please upload a new openoffice.org which doesn't build openoffice.org-base on armel? [10:06] Sweetshark: it only exists on amd64, i386, powerpc [10:07] 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] Sweetshark: I'll just fix oo.o [10:57] hello [10:59] hey rodrigo_, how are you? [11:02] hi seb128 [11:08] Sweetshark: does http://paste.ubuntu.com/760293/ look ok to you? [11:10] pitti: yes, looking good [11:10] Sweetshark: ok, hanks [11:10] thanks === MacSlow is now known as MacSlow|lunch [12:34] hehe [12:34] " mbiebl, is it really wise to switch to totem 3.2 in this situation? [12:34] Np237: looks bad, here at least. [12:34] Do we need to package totem 3.0 as totem-fallback too? o_O" [12:34] \o/ for not jumping on the clutter based version ;-) [12:36] seb128: :) [13:12] lunch, bbl === MacSlow|lunch is now known as MacSlow [14:19] 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] seb128: oh, please :) [14:19] that's likely a good candidate for a sru as well [14:20] 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] seb128: so these don't appear on http://reports.qa.ubuntu.com/reports/sponsoring/ :( [14:21] pitti, no, because there are against a team vcs [14:21] 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] didrocks, pitti: can we please not block those sru regression fixes on precise work? [14:22] if we don't have to push the SRU to precise, it's fine [14:22] otherwise, we really can't push it [14:22] it's already embarassing enough that we broken those and didn't fix them in over a month of time [14:23] 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] didrocks: ok for me, but really unusual [14:24] pitti: thanks Martin :) === m_conley_away is now known as m_conley [14:28] seb128, empathy package does not seems to install mcp-account-manager-goa.so [14:29] it should go to /usr/lib/mission-control-plugins.0/ [14:29] in precise [14:30] also I guess it needs to do some magic to make apparmor let mission-control load that plugin [14:30] because just installing it manually doesn't work [14:30] xclaesse: if this is in the default install, please file a bug and assign it to me [14:31] jdstrand, copied package into a oneiric ppa [14:31] kenvandine, ^ [14:31] xclaesse, you better ping kenvandine about empathy packaging issues, he's the one doing most of the packaging work on it [14:31] seb128, ok thx :) [14:31] i can fix that [14:32] kenvandine, cool, thanks :) [14:32] np [14:32] kenvandine, FYI that plugin makes MC import accounts setup in gnome-online-account [14:32] so if you have a gtalk account in goa, it gets into empathy automatically [14:32] cool [14:32] xclaesse, what about accounts already in empathy? [14:32] does it detect the dupe? [14:33] no [14:33] you'll just get both [14:33] bummer [14:33] ok [14:34] 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] ok [14:35] didrocks: I assigned the precise tasks of these two to you, please assign to teh correct person in DX; thanks! [14:35] pitti: excellent, thanks! [14:50] 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] 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] seb128: oh, we have a bzr for oneiric? [14:51] seb128, this one https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz-plugins-main/fix-regressions [14:51] this branch also have the fix for 876591 [14:51] pitti, no, we usually don't create a new serie if precise didn't get a newer version [14:51] seb128: so you mean s/screwed/incomplete/, or is it actually broken as-is? [14:52] om26er, how come you didn't propose that one for sponsoring? [14:52] seb128: we can reject this, and upload that other branch instead, fine for me [14:52] pitti, no, it just doesn't contain one of the fixes, so incompletes [14:52] sorry, I didn't check trunk bzr, just the MP [14:52] it was creating a very big diff like a few thousand lines [14:52] om26er, you were proposing it against the wrong serie I guess? [14:53] presumably http://bazaar.launchpad.net/~compiz/compcomm-plugins-main/ubuntu is a custom branch [14:53] while om26er's MP was against the UDD one [14:53] pitti, don't bother, we will get the other bug fixed in the next one I guess [14:53] you can't merge them to each other [14:53] i cant propose my branch to https://code.launchpad.net/~compiz/compcomm-plugins-main/ubuntu there is no option [14:53] I will just unsubscribe from the bug meanwhile [14:54] om26er: no, as I said you can't merge UDD branches against debian/ only ones, and vice versa [14:54] they are two entirely different things [14:55] pitti, alright so where should i propose https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz-plugins-main/fix-regressions now? [14:56] om26er: you can't propose it anywhere else [14:56] om26er: if you branch from UDD, you have to merge to UDD [14:56] 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] om26er: but as seb128 said we can get to that patch in the next round [14:57] pitti, waouh, down to 23, good job (to you and others, 37 was already low, it was around 70 until recently) [14:58] om26er, or do another merge request just for this one [14:58] 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] seb128, sure, I can do that now [14:59] om26er, thanks [14:59] pitti, thanks for clearing things :-) [14:59] seb128, :-) [15:07] pitti: Hi, are you busy now? [15:07] jincreator: I'm always busy, it's a matter of what I'm busy with :) [15:08] pitti: I saw you remove 69-language-selector-ko-kr.conf. [15:09] jincreator: right, you said it was obsolete as we are using nanum now? [15:09] pitti: Yes, but only for when Un fonts is default at Korean font. Sorry for make confusing. [15:10] jincreator: I thought the hack was for unfonts? [15:10] pitti: Yes, it is. But we are trying to change default font from unfonts to fonts-nanum. [15:11] jincreator: right; so if the hack only applies to unfonts, why do we need it if we are using nanum? [15:12] 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] 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] jincreator: right, that's the issue we talked about [15:15] 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] jincreator: I think fixing the bug is better, as it will also unbreak other ttf-* packages [15:17] jincreator: and NB that language-selector is going away, so we'll need to drop the hacks anyway [15:17] or at least minimizing them so that we can port them to whatever replacement [15:17] but seems like a much better option than these static hacks, as they will be prone to being wrong [15:17] you might have more than user on a machine, etc. (think universities, etc.) [15:22] pitti: You mean language-selector is no more exists at Precise? [15:23] 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] with adding enough functionality to the gnome-control-center module to replace it [15:23] l-s is quite horrible and unmaintainable code [15:28] 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] jincreator: I thought making work would do the trick? [15:30] whatever breaks it, we should just fix that IMHO [15:33] good night everyone! [15:33] pitti: good night! [15:41] have a good night pitti :) [15:52] 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] didrocks: should we drop the ZEITGEIST_DAEMON test from configure.ac? it seems unused [15:53] lool: that's more than possible that it's not shipped anymore with the new vala zg [15:53] mhr3: I think you see both sides of this piece there ^ [15:55] didrocks, i'm not sure why files lens checked that [15:55] lool: let's wait on kamstrup then [15:56] 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] lool: yeah, I think it's better to directly fix that upstream and less than a burden :) [15:58] lool, didrocks, ok, it will be fixed upstream [15:58] thanks :) [15:58] mhr3: Thanks [15:58] files lens doesn't need the check though [15:58] mhr3: I can even propose a merge req if you want :) [15:59] mhr3: will be the perfect time to boostrap the file lens automerge [15:59] didrocks, merge req for files lens? [15:59] yep [15:59] didrocks, sure, why not [15:59] mhr3: ok, will do that just after the call [15:59] it'll fail though :P [15:59] because of new libunity? [15:59] yes :) [16:00] ok, I'll let you do the libunity stuff first :) === m_conley is now known as m_conley_away