[00:14] hey RAOF and bryceh , how are things looking in X/Mesa land where we are in the cycle? pretty stable? lots of bugs? any GPU giving us more trouble than expected? [00:15] jasoncwarner_, quite stable actually; very few bug reports open at the moment [00:15] bryceh: nice! [00:15] scattered problems here and there, mostly corner cases or non-X bits that are misbehaving [00:15] nothing trending that we should be keeping an eye out for? [00:15] jasoncwarner_: There seems to be some problem with fglrx and unity, but that's getting investigated. [00:16] jasoncwarner_, http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-oneiric.svg [00:16] * jasoncwarner_ almost mystified...starts looking over his shoulder... [00:16] RAOF: ok...I know we had some nvidia unity breakage, but Jason/DBO is looking into it [00:17] awesome...would love to not have x/mesa/video card problems this cycle! [00:17] Hm. We should pull in a new point release of the X server, now that 1.10.4 has been released. [00:17] I credit it partly with us being a bit more conservative this cycle than usual (e.g. no late-in-cycle xserver updates) and upstream being more stable than usual themselves [00:17] Yeah. I think intel particularly are getting better at stability. [00:17] yeah the fglrx black screen issue is bad but jay is discussing it with amd [00:18] jasoncwarner_, the scale on that graph goes up to 500 for a reason ;-) [00:19] jasoncwarner_, so having total bugs ~50 (and going down) is a nice change [00:19] :) [00:22] jasoncwarner_, I am? [00:22] anyone else's firefox blocking like crazy? [00:22] RAOF, nvidia driver trashes FBO's on suspend/resume... this is becoming a bigger and bigger problem [00:22] robert_ancell: when you say "blocking".... [00:23] DBO: er, I thought you were? is someone looking at the above? [00:23] jasoncwarner_, as in unresponsive [00:23] robert_ancell: ah, yes...I had that last week and asked chris about it...but it wasm ore that switching from one tab to the other took a literal second or two [00:24] he said it was nvidia related (it always seems to be!) [00:24] robert_ancell: My firefox isn't (but I'm still running an Aurora build), but compiz seems to stop updating for ~1sec every half hour or so. [00:24] I get "Some Gmail features have failed to load due to an Internet connectivity problem. If this problem persists, try reloading the page, or using the basic HTML version. Learn More." [00:24] before I could track it down it went away with a series of updates and reboots [00:24] it's >10s for me [00:24] jasoncwarner_, the biggest driver issue I am aware of is nvidia trashing FBO's. Nothing we can do about that, it breaks suspend/resume [00:24] robert_ancell: I only get that when my actual internet is saturated...like if I'm streaming music or video or something... [00:25] DBO: we can't do anything? are we talking to nvidia about it at all? and how often does it happen? [00:25] ^^ bryceh and RAOF [00:26] I believe I've pointed DBO and tselliot in the same direction; tselliot's who we'd want to ask, I believe. [00:26] note the issue only happens for me in firefox, not in chromium [00:27] robert_ancell: I got nothing then. [00:28] RAOF, I keep forgetting to ping him until I see you :P [00:28] DBO, he seems rarely on IRC; you'd be better to send an email or assign him a bug report [00:28] jasoncwarner_, it happens every time, 100% reproducible [00:29] DBO: where in the stack does this happen? is it nux, compiz, unity? elsewhere? reason I ask is why I would NOT get it on GNOME desktop but do on Unity. [00:30] the nvidia driver [00:30] they fixed it for GNOME Shell [00:30] specifically... [00:30] Im thinking fglrx hack style fixed it [00:31] DBO: who is "they" in the "they fixed it for GNOME Shell" above? Nvidia? [00:31] nvidia [00:32] http://www.nvidia.com/object/linux-display-amd64-275.09.07-driver.html [00:32] see the first item === Pici` is now known as Pici [00:33] DBO: ah, ok...thanks man [00:34] You should still be able to see it by plaing Civ V in wine, doing a suspend/resume, and noticing that everything's a pretty rainbow mess until the textures get updated ;) [00:37] DBO RAOF and bryceh ... as I understand it, we have to engage nvidia on this ? and tseliot is the guy who is doing that right now? [00:37] jasoncwarner_, that's correct [00:37] jasoncwarner_: YEs. [00:37] jasoncwarner_, affirmative [00:39] RAOF would you please own this from the desktop perspective and run it down with tseliot? I would like someone to be able to update us all on the status and what is going on...I can reproduce 100% of the time now and that is bad :/ [00:39] jasoncwarner_: Oh. The problem needs to be resolved by nvidia, and tseliot is our go-to liason with nvidia is true. I'm unsure if he's actually aware of this issue, though; DBO? [00:40] we did mention it last cycle too [00:40] jasoncwarner_: Certainly. [00:40] DBO: Do you have a bug reference handy? [00:40] RAOF: awesome, thanks. [00:40] this will be fun... [00:40] * DBO goes to launchpad [00:42] RAOF, this is the oldest version of it from a unity standpoint: https://bugs.launchpad.net/unity/+bug/676166 [00:42] Ubuntu bug 676166 in unity "Screen corruption when resuming from suspend" [Medium,Triaged] === asac_ is now known as asac [03:56] can someone do an apt-get source on shotwell and check if it compiles for them? [04:02] robert_ancell: In a chroot, I presume? [04:02] RAOF, just a debuild will do. It fails for me, I'm just wondering if I have something weird [04:03] Hm. Does libsane not have any hotplug notification capability? [04:05] RAOF, no, it's a bit crap like that [04:06] robert_ancell: Shotwell ftbfs here, too, with a couple of "don't copy delegates" warnings. [04:06] RAOF, damn, same problem.. [04:06] Why wouldn't you want to copy delegates? [04:07] You could always turn off -Werror, I guess; they're just warnings. [04:08] looks like vala is confused, it reports them as warnings but removing them makes the compilation work [04:09] valac's being called with --fatal-warnings; the failure looks correct. [04:10] RAOF, oh, interesting [04:36] RAOF, are there known problems with raedon 5400 in the current Oneiric? [04:37] robert_ancell: here [04:37] Are you using fglrx? If so, yes; it's known that your screen's black. I think this is being traced back to a compiz change confusing the hack in the fglrx driver that makes compiz work :) [04:37] RAOF, nxvl is having a boot issue after upgrade where you get a black screen and unable to VT switch. Blamed on lightdm as ususal: ) [04:38] RAOF, bug #? [04:39] Hm; it's not in those emails. Let me check launchpad. [04:40] robert_ancell, nxvl: bug #823588 is the one I'm thinking of. [04:40] Launchpad bug 823588 in fglrx-installer "Unity displaying with black overlay with fglrx driver" [High,Triaged] https://launchpad.net/bugs/823588 [04:41] oh, and btw i can't use unity3D [04:41] only 2D [04:41] and yes, i'm using fglrx [04:41] Ah. [04:41] Ok. This is the part where I ask for logs. [04:42] so, the most strange issue is: [04:42] Can I have some logs, please? /var/log/Xorg.0.log and dmesg are a good start. [04:42] if i boot using rescue system, and then hit resume [04:42] i will get a tty, run lightdm, and everything will work as expected [04:43] Iiiiinteresting. [04:43] well, despide the fact where i can't use unity3D [04:43] That might suggest that the radeon blacklist isn't working properly. [04:43] Logs! [04:44] That should be very obvious in dmesg, and Xorg.0.log would be interesting too. [04:45] sure, uploading [04:45] Ta. [04:46] http://people.canonical.com/~nxvl/nxvlLogs.tgz [04:48] if i run unity3D i get the same as the video in the bug [04:50] [ 4.048078] [drm] Initialized radeon 1.33.0 20080528 for 0000:01:00.0 on minor 0 [04:51] I'm surprised the fglrx kernel module can even load. I'd expect radeon to bind to the device and prevent that. [04:55] compiz hates ATI [04:55] or ATI hates compiz [04:55] every release there is an issue with it [04:56] Good morning [04:58] nxvl: What's your "sudo update-alternatives --config x86_64-linux-gnu_gl_conf" set to? [04:59] http://paste.ubuntu.com/672900/ [05:00] hi pitti! [05:00] 2 /usr/lib/pxpress/ld.so.conf 900 manual mode? Where'd that come from? [05:01] dunno [05:01] i just upgraded today [05:01] Anyway, that looks ok. Does /etc/modprobe.d have a file blacklisting radeon in it? [05:02] i just cntrl+c this? [05:02] or shall i enter 0 or just enter or whatever [05:03] http://paste.ubuntu.com/672904/ [05:03] Oh, either ctrl+c or enter will be ok. [05:04] Oh, looks like pxpress is the crazymad stuff done to make fglrx/intel hybrid graphics work. That's must be what it is. [05:04] * RAOF should stop beginning sentences with "Oh" [05:05] so, should i change something and test? [05:06] Um, I'm not sure. [05:06] Well, setting the mesa gl_conf alternative should get you to a useable radeon system, I think. [05:07] hmm, so i'm a security guy, you are talking chinnesse to me [05:07] :D [05:07] As to why radeon is loading and apparently breaking fglrx… could you pastebin /etc/modprobe.d/fglrx.conf? [05:07] nxvl [~] [05:07] Sylvester$ cat /etc/modprobe.d/fglrx.conf [05:07] blacklist radeon [05:08] sudo update-alternatives --config x86_64-linux-gnu_gl_conf - one of the options there was 3 - mesa. [05:08] And has that fglrx.conf made it into /boot/initrd? [05:09] hmm, if i use old kernel it breaks anyway [05:09] so i will say yes [05:10] And the old kernel worked, obviously. [05:10] yup [05:10] with no problems [05:10] until i upgraded [05:11] Hm. update-initramfs could still have refreshed your initrd. [05:12] bootchart is the only package i've ever seen that actually refreshes all initrds (as opposed to the latest one) [05:12] ok, updating [05:13] just updated? reboot and test? [05:13] Yeah, I guess so. [05:14] ok, brb, i hope [05:17] so, now i don't get X to work at all [05:17] but at least i get a tty [05:18] Hurray? [05:18] :) [05:18] Xorg.0 claims fglrx module does not exists [05:18] and i get a "No screens found" message as the error [05:18] in Xorg.0 [05:18] Oh, you've got an /etc/X11/xorg.conf? [05:19] yup [05:19] and Screen has just usual generic stuff [05:20] default screen, 24 defaultdepth and a display subsection [05:20] I think that if you remove /etc/X11/xorg.conf you'll get an Xserver back. [05:20] * nxvl tryes [05:21] now i get a different black screen as i previously did [05:21] last black screen was monitor off, this one is monitor on, black content [05:22] Woo! Eventually we'll exhaust all possible forms of brokenness and then it'll work. [05:22] would it be possible, in multi monitor mode, to get a 1-pixel offset on the right hand monitor ? [05:22] Xorg log now? [05:22] that way I could find the power off button easily ;) [05:22] no errors [05:23] same link as before, but Xorg.0.log instead of nxvlLogs.tgz [05:24] will reboot while you check [05:24] just in case [05:24] Hm. That looks like everything worked, rather than a blank black screen :) [05:25] * RAOF grabs some coffee during the reboot. [05:27] ok, now it works normally, at least i can boot [05:27] and get X [05:28] but i don't get unity3D [05:28] now we can woot [05:28] well, something like that [05:29] I'm surprised you don't get unity3d now; Xorg.0.log again? [05:30] robert_ancell: Hi Robert, can we come to a conclusion about https://code.launchpad.net/~gunnarhj/lightdm/langfix-oneiric/+merge/70969 ? [05:32] updating [05:32] http://people.canonical.com/~nxvl/Xorg.0.log [05:32] k, updated [05:35] GunnarHj, hi, sorry didn't reply to this today. I'm not sure what the correct behaviour is here. What sets LC_MESSAGES? [05:36] nxvl: Bah. That looks just fine. What's the output of glxinfo? [05:36] The program 'glxinfo' is currently not installed. You can install it by typing: [05:36] sudo apt-get install mesa-utils [05:36] :P [05:36] At first look, it shouldn't be part of lightdm, as it doesn't set any of these variables [05:37] http://paste.ubuntu.com/672916/ [05:38] GunnarHj: It's now accountsservice that writes to ~/.profile. OTOH, the suggested code is only related to the final step, i.e. the actual setting of the variables... [05:38] nxvl: Bah, sorry. LIBGL_DEBUG=verbose glxinfo [05:39] http://paste.ubuntu.com/672918/ [05:39] GunnarHj, sorry, have to go, but I'll get onto it first thing tomorrow [05:40] GunnarHj: That's ok. See you tomorrow. [05:41] Looks that I wrote to myself when trying to talk to Robert ... off for breakfast it is... [05:42] nxvl: I'm confused. It says "direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)", but you clearly *have* run it with that environment variable set. Is there anything remarkably crazy about your system? [05:43] RAOF: dude, it's linux, isn't that crazy enough? [05:43] but, no, i never configure basically anything other than what i need for packaging and stuff [05:43] but not a lot of ENV stuff [05:44] OH! [05:45] client glx vendor string: ATI [05:45] I see where we have the winner; it's our old friend, deadly neurotoxin. [05:45] maybe it's just standard output message and the info is there anyways [05:45] Or, alternatively, fglrx's libglx. [05:45] yeah, i'm starting to hate that i got a gamer machine for work, ATI is a PITA [05:46] Nah, there's different output when run with LIBGL_DEBUG=verbose [05:46] If I'd paid more attention to your Xorg.0.log I would have noticed that. [05:47] So, what I'd do now is to use jockey to remove the fglrx driver; once that's done things, even 3D, should work. [05:48] And then in a couple of day's time, when fglrx works with Unity again, come back and we can see if we can't coax fglrx into some form of life. [05:53] jockey doesn't work either [05:53] * nxvl shoots himself [05:54] pitti: ^^ [05:54] http://paste.ubuntu.com/672923/ [05:55] nxvl: sorry, didn't follow the conversation; you are trying to install a driver? [05:55] nope, removing [05:55] nxvl: Man, your system is all manner of pleasin', isn't it. [05:56] RAOF: yeah, please shoot me! [05:56] nxvl: sudo apt-get remove fglrx should work, however. [05:56] i'm going to go back to thinkpads and never look back again [05:56] And, given my recent track record of "should"s, it's *guaranteed* to have no problems! [05:57] yeah [05:57] nxvl: Ask desrt about how awesome _his_ thinkpad is :) [05:57] given the record i'm trying [05:57] RAOF: sacrificing chickens again ? [05:57] RAOF: i have always used thinkpads and never had a problem, but i gave Dell a try and it's giving me tons of headaches [05:58] lifeless: Apparently (a) blacklists aren't what they used to be and (b) dbus is for wimps. [05:58] k, rebooting [05:58] brb [06:02] ok, another certain should [06:02] 3D awesomeness is back [06:03] with HUGE fonts, but back [06:03] i will fix that in the morning [06:03] thanks for the help! [06:03] Yay! [06:03] pitti, good morning [06:03] hey bryceh, how are you? [06:04] pitti, I'm doing well, but I have a bug for you [06:04] I noticed that ubuntu-bug xkeyboard-config don't work [06:04] it gives "package not found", but obviously that's not right, it's just a source package - it's expecting xkb-data [06:05] pitti, digging into the source it appears the issue is apport uses apt.Cache() which allows looking up binary packages, but not source [06:05] correct [06:05] it's meant to work on binary packages [06:05] as we can't determine any packaging information otherwise [06:05] pitti, using apt_pkg, I could get it to look up the source package http://paste.ubuntu.com/672927/ [06:06] pitti, I wanted to see if that is at all a viable way to go about implementing a fix for this [06:06] well, I'm not sure whether there's something to "fix" [06:06] users only really see binary packages anyway, in apt, s-c, etc. [06:07] and for sources which produce more than one binary we usually want to know which [06:07] we could add a special case that if a source only produces one binary, and the names differ (which isn't the case usually), it would assume the only binary package name [06:07] pitti, well for instance if someone is commenting on a bug already filed against xkeyboard-config, and you tell them to file a new bug report, it's sensible to direct them to file against the source package [06:08] but that wouldn't even help here [06:08] we get into a similar situation filing bugs against xorg-server [06:08] bryceh: so, it's certainly possible, but nothign I can fix in 15 mins, I'm afraid [06:09] i. e. I don't think I'll have time to work on this in the next days, I'm swamped in the pygobject stuff and need to unbreak the retracers [06:09] pitti, well I'm more asking if you'd be opposed if I sent a patch [06:09] we need to teach apport about "Package:"-less reports, and be able to file them [06:10] and checking if the approach of using apt_pkg would be improper [06:10] bryceh: no, surely not, but it'll be a rather large one, unless you settle for the "small" special case above [06:10] or for a source with multiple binaries, it could pick a random one [06:10] ... which is actually installed [06:11] bryceh: no, backends/packaging-apt-dpkg.py already uses "apt", so you can use apt.apt_pkg [06:11] bryceh: it already has a get_source() method which maps a binary to a source package [06:11] ah ok [06:12] apport/ui.py does the command line processing [06:13] it probably needs to grow some magic to check if an argument is a source package name, if it doesn't exist as a binary package name [06:13] and then call an apport.packaging method to map that into an approptiate binary package name [06:13] backends/packaging-apt-dpkg.py coudl then implement this using an iteration over the binaries of the given source [06:13] yep [06:13] and pick the first one which is installed [06:14] yeah that's basically what I was thinking [06:15] I don't think it'll be a very big patch; half a dozen lines or so [06:16] integrating it will be a little more, as you need to update test cases, and add a generic API for that into the packaging class, but shouldn't be very complicated [06:18] hrm, maybe in that case I should just file a bug report [06:32] I'm off for about an hour for a bit of running [06:32] oh, there's already a bug - #359810 [06:33] pitti, ok thanks; I'm not sure what is involved with making a generic API, but will post a branch of what I've got to that bug report for you to consider some day when you have time [06:58] if you can give me more guidance on what you want for tests and api's I'd be willing to give that a shot; I read through the test code but wasn't clear on how it should be integrated there. [06:58] eod for me, tty tomorrow [07:11] bryceh: ok, thanks [07:43] morning [07:48] hey desktopers [07:48] hi seb128 [07:48] hey rodrigo_, how are you? [07:49] seb128, I'm fine, and you? [07:49] I'm great thanks [07:51] bonjour seb128 [07:51] hey rodrigo_ [07:52] hey pitti, wie gehts? [07:52] pitti, it's meeting reminder day! ;-) [07:52] seb128: ooh, indeed [07:52] hi pitti [07:56] seb128: apport retracer fixing day! [07:56] pitti, \o/ [07:59] pitti, btw you have the launcher not showing with mouse also right? [07:59] seb128: right, because they took away corner activation, and I disabled edge activation ages ago [07:59] pitti, you can fix it by running unity-preferences and picking edge rather than corner [07:59] right, I know [07:59] but edge activation is evil and gets in the way [07:59] I just use the windows key [07:59] well then you can pick the corner as an edge in ccsm [07:59] in the unity preferences [08:00] it let you pick any border or corner [08:01] oh, in ccsm; I thought you mean unity-preferences [08:01] that just has the simple radio button [08:01] bah, edge activation is still instantaneous [08:01] rodrigo_: Hello Rodrigo, can we continue where we stopped yesterday? I added a comment after you had disconnected: https://code.launchpad.net/~gunnarhj/gnome-control-center/langfix/+merge/71197 [08:02] seb128: hm, doesn't seem to work for me; I changed to the top left corner in ccsm, but doesn't work [08:02] pitti, ok, dunno then, that works for me, selecting edge in unity-preferences and then the corner in ccsm [08:03] not here, it keeps edge, too [08:03] pitti, ccsm also has the delay before showing the launcher [08:18] hey GunnarHj [08:39] meh, these fakechroots seem to be totally busted :( [08:41] pitti, on oneirc? yes [08:42] perhaps it's time to ditch fakeroot altogether and rework the retracing bits from the ground up to not use chroots in the first place.. [08:43] these days gdb has an option to specify a different debug symbol root path [08:44] it'll be a bit tricky to point it to the debug libraries, but with some symlink tricks it might work [08:46] pitti, seems like a lot of work [08:46] can we talk I.S into getting vms instances we can use? [08:46] kvm or other [08:46] that would help indeed [08:47] I'll do some experiments here to estimate how much work the gdb reorg would actually be [08:48] ok [09:04] RAOF, hey [09:05] RAOF, did you get anywhere with colord running as an user? [09:23] * pitti discovers gdb's "set solib-absolute-prefix" command and jumps for joy [09:24] you know, this could WORK! [09:26] pitti, waouh! [09:26] seb128: I now have a rather simple /tmp/chroot with just dpkg -x'ing the debs and ddebs, and adding a trick symlink [09:27] and can produce a nice stack trace with some magic gdb commands, using no root or fake* commands [09:27] pitti, that should work [09:27] this even works in a lucid chroot [09:27] great [09:49] seb128, I changed the font settings to a smaller font while compiz was running, now if compiz crashes, the fonts are changed back to a larger size. are there different settings? and if yes, where else do I have to change these? [09:50] doko, where did you change it? [09:50] usually is gnome-settings-daemon which apply xsettings [09:50] not compiz [09:51] seb128, gnome-tweak-tool [09:52] that should change the gsettings [09:52] dunno what compiz is doing... [09:52] great \o/ [10:27] seb128: Yeah, I think I've got colord running appropriately as a system user. I thought that perhaps there were permissions problems with my scanner, as it wasn't showing up when colord was initially started, but that turns out to be a combination of cups starting colord and libsane stupidity. [10:27] pitti, could you score up https://launchpad.net/~unity-team/+archive/compiz-testing/+sourcepub/1907196/+listing-archive-extra [10:27] ? [10:27] seb128: I'm just finishing wrangling a patch in an upstream-suitable fashion. [10:27] seb128: done [10:27] pitti, thanks [10:28] RAOF, when do you think it will land? beta freeze is soon and we have g-s-d and g-c-c depwaiting on it for over a week [10:28] which blocks other changes to land and be tested [10:29] I can land the changes kees wanted tomorrow; I think that should be enough to get the MIR signed off on? [10:30] RAOF, I will check with him today, thanks [10:31] pitti, https://launchpad.net/~unity-team/+archive/compiz-testing/+sourcepub/1907204/+listing-archive-extra as well please [10:31] pitti, danke ;-) [10:31] (one day we will get those compiz updates in Oneiric!) [10:31] nudged [10:32] pitti, thanks! ;-) [10:33] Sweetshark: what's the current blocker for the 3.4 upload? still mono? [10:35] GunnarHj, ping [10:41] rodrigo_: Now I'm here. :) [10:41] GunnarHj, :) [10:42] GunnarHj, ok, so I've built your branch, and I'm still not sure what it tries to accomplish [10:42] I see less locales in the selection of language than before [10:42] and still some duplicated ones [10:42] like "Spanish (Spain)", "Spanish (Mexico)" [10:43] I thought it was for just showing the language there? [10:43] rodrigo_: Less items is the goal. [10:43] Each item is a translation. [10:43] GunnarHj, ah [10:44] in git, btw, yesterday we pushed a fix to just show languages there [10:44] There is a separate Mexican translation, so they're not duplicates. [10:44] hi guys. Starting a Qt app loads a whole Gtk+ behind the scene (natty). Is there a way to disable that ? [10:44] GunnarHj, hmm, ok [10:44] in gnome all .es translations are in one place, why do we have separate ones in ubuntu? [10:45] but I understand now why it shows that [10:46] rodrigo_: they are not in one place [10:46] rodrigo_: Don't know the history. For some big languages, especially Spanish and English, there are separate teams. [10:46] pitti, in gnome? [10:46] rodrigo_: GNOME upstream has separate es_MX.po files as well [10:46] oh [10:46] those mexicans!! [10:46] rodrigo_: you are right that in most languages there should indeed just be a ll.po [10:46] rodrigo_: i. e. we generally don't want a separate de_AT.po [10:46] rodrigo_: but some languages have legitimate country variants [10:47] the .es translation team has been working hard to use a common translation for all spanish-speaking languages afaik [10:47] cassidy, not sure, would be a question for the qt guys, I guess it's the theming integration doing it [10:47] yeah [10:47] rodrigo_: these are mostly en (US vs. UK), es (ES vs. AR/MX), pt (PT vs. south america), and zh (CN vs. TW) [10:47] rodrigo_: ah, perhaps for .es; I don't know how different MX/AR Spanish is [10:48] rodrigo_: but I know that Brazilian and Portual Portugese are far enough apart to justify a split [10:48] pitti, I've never seen a es_* translation in any of the gnome modules I watch [10:48] rodrigo_: and traditional and simplified Chinese are very far aprt [10:48] "apart" [10:48] pitti, yeah, pt_BR and pt are indeed quite different [10:48] rodrigo_: well, then just keep 'es'? [10:48] rodrigo_: I thought you were asking in a more general context, as in "do we need country variants at all" [10:49] and we do [10:49] pitti, GunnarHj branch shows all languages that have specific languages, and MX/AR show up, so I guess we have variations on those [10:49] pitti, oh, no, just about the 'es' translation [10:50] rodrigo_, pitti: The algorithm that produces the language list is stupid - it doesn't know whether a directory contains a justified translation or not. [10:50] ah [10:50] in general we want to control that on the LP export side [10:51] pitti, rodrigo_There are some universe packages that pollute /usr/share/locale with many 'translations'. [10:52] ah right, we can't/don't filter these [10:53] I kind of suspect that some such translations are exact copies, but I have never checked it out. [10:53] pitti, can you score up https://launchpad.net/~unity-team/+archive/compiz-testing/+build/2738447 again please? thanks [10:53] seb128: done [10:53] danke [10:54] rodrigo_: So then you know the idea behind the list that is produced, Rodrigo. [10:54] GunnarHj, yes [10:56] rodrigo_: I suggest that you upload it as Ubuntu specific code for now. Then we can go on talking about how it should be handled in 12.04. [10:56] rodrigo_: Have to go now. Back about 16.00. [10:56]