[00:05] hmm...this run is much better, but disk utilization is still really high after ureadahead finishes [00:46] if I look at broder's bootchart, will my X server crash again [00:48] slangasek: Mine didn't, so I don't think yours will :) [00:48] did...one of my other bootcharts crash your X server? [00:48] Firefox loves itself some huge X pixmaps. [00:49] broder: you have non-trivial I/O from fsck and update-motd-updates-available; is this reproducible across boots, or did you just get lucky with this bootchart that everything needed to be done at boot? [00:49] broder: no, someone else's bootchart did [00:49] it's an X server bug [00:49] (not a firefox bug at all) [00:49] slangasek: that was my second reboot after installation, so it may have just been an immediately-post-install thing [00:50] hmm [00:50] I wouldn't expect a fsck on the second reboot after install [00:50] do you have the matching /var/log/boot.log? [00:51] i rebooted the machine one more time after the chart i sent to ubuntu-desktop. let me see what i can get off the disk [00:51] (i will also have one more bootchart so we can see if the i/o was spurious) [00:57] slangasek: http://paste.ubuntu.com/702524/ is the boot.log that's there, but i assume that's from boot #3, not #2 [00:58] slangasek: the round 3 bootcharts are also in http://web.mit.edu/broder/Public/livecd-bootchart/ - they seem to have very similar disk i/o from fsck and update-motd === Shadows` is now known as SoulShadow [03:14] smspillaz: I managed to get my launcher hiding behind my desktop again [03:15] Alt-F1 or the Meta key still makes it pop out, but the edge reveal doesn't work, nor does it show when I alt-tab to the Desktop [03:19] Ctrl-Alt-arrow keys to a blank desktop works and if I unmaximize my windows I'm ok too, but I like maximized windows on a relatively small screen [04:06] broder: which one of those is the round-three boot chart? [04:07] slangasek: bah, round 3 is the middle one [04:07] (it ends in -3, not that you can see that) [04:08] broder: hrm, how is that comparable disk i/o? [04:08] slangasek: i'm comparing http://web.mit.edu/broder/Public/livecd-bootchart/postinstall-oneiric-20111004-2.png and http://web.mit.edu/broder/Public/livecd-bootchart/postinstall-oneiric-20111004-3.png [04:09] which is 2nd boot after installing and 3rd boot, respectively [04:09] well now I'm confused [04:09] because I swear this isn't the boot chart I looked at earlier :) [04:09] yeah, the...filename ordering was not ideal [04:09] err, right. sorry [04:10] the first bootchart i sent to the channel was one that was broken, because way too much I/O was happening after ureadahead [04:10] oh [04:10] but i had already purged the drive i was using when i realized that [04:10] hah, ok [04:10] and started over [04:10] I thought that's still what we were debugging :) [04:10] yeah, sorry [04:11] i wish i still had it, because it was kind of strange [04:11] but i'm assuming something just went horribly wrong with ureadahead's collection mode [04:11] ureadahead isn't going to collect on behalf of fsck :) [04:11] well, it should for the minimum amount of reading fsck does on every boot [04:11] since mountall always does an fsck, it just usually doesn't do much [04:12] nor update-motd-updates-available, which a) doesn't happen every boot, b) does writing more than reading [04:12] right, but that boot chart showed a *non*-minimal fsck [04:13] are you sure it wasn't just a slow minimal fsck that was slow enough that bootchart caught the child in the act? [04:14] yes, because unless you're turning your disk by hand, there's no reason a fsck of a clean disk would take > 1s [04:14] not even bad i/o scheduling? [04:15] bad i/o scheduling wouldn't have shown up as solid red attributed to fsck on the bootchart :) [04:15] (bootchart knows *which* process is actively engaged in i/o and colors the process appropriately - if it's just waiting its turn, it wouldn't have been red) [04:16] i think that's light red - there's a modprobe further down that's dark red you can compare it against [04:17] right, when I said "red" I mean "red that I can meaningfully distinguish from the background" :) [04:17] * broder shrugs [04:18] i'll take your word for it - my bootchart reading ability is pretty minimal [04:18] http://web.mit.edu/broder/Public/postinstall-oneiric-20111004-2.png - red fsck, not a no-op [04:20] bryceh, RAOF, is rootless X back in scope for 12.04? [04:20] robert_ancell: As in - not running X as root? Probably not. [04:20] RAOF, what's blocking it? [04:21] It's the continuing saga of input routing. [04:21] RAOF, i.e. udev? [04:22] No - the problem is that when user switching you have no way of knowing that the old X server *actually* gave up it's read access to the tty, and isn't sitting pretty, nabbing all your passwords. [04:22] Bah. Apostropheing. [04:23] RAOF, this is where the central wayland compositor fits in? [04:23] Right. [04:23] :) [04:23] It's the trusted input router. [05:46] good morning [05:47] Hey, ho, didrocks! [05:49] Ho, hey, RAOF ;) [05:55] RAOF: we should track bug #830949 at UDS to have a session on those configurations with dx [05:55] Launchpad bug 830949 in xserver-xorg-video-intel "[Intel N10 Graphics] Plugging in external monitor to VGA port makes both displays corrupted with thick slanted lines " [Undecided,Invalid] https://launchpad.net/bugs/830949 [05:55] RAOF: (hint hint, blueprint, blueprint ;)) [05:56] didrocks: I don't think there's a whole lot to discuss - they know what they need to implement, it just needs to be implemented. [05:57] RAOF: yeah, but there was already a "we should do that" last cycle, if we don't mark it down somewhere, it won't be done next cycle either. Maybe not a session, but being part of one (multi-monitor enhancement, maybe?) [05:57] I guess it could be useful for workitem tracking. [05:57] right, the discussion itself won't, just tracking and not forgetting :) [05:57] Right. [06:14] mmmm telepathy-mission-control 5.9.3 is out today [06:25] Good morning [06:25] robert_ancell: still here? [06:25] guten morgen pitti [06:25] pitti, yes, on phone, will talk when off [06:26] bonjour didrocks [06:26] robert_ancell: great, thanks [06:27] pitti: we're not disabling the login sound for oneiric, right? [06:27] jbicha: too late now, I think (unfortunately) [06:27] Morning pitti [06:28] hey RAOF [06:28] pitti: this is one guide for users to disable it: http://maketecheasier.com/disable-login-sound-in-ubuntu-oneiric-quick-tips/2011/09/15 [06:28] jbicha: it's quite easy to do in the audio control panel [06:28] we could make it simpler by removing the NoDisplay line but seb128 didn't like that by default Startup Applications would have one choice [06:29] well that affects all sound effects, I like the other ones :) [06:30] we did have a login preferences window in 11.04 with a 1-click login sound on/off button === tkamppeter_ is now known as tkamppeter [06:31] too bad this wasn't proposed sooner, I've not been a fan of the login noise for a few releases now [06:31] jbicha: oh, right, gnome-session-properties [06:31] jbicha: you like the other one? waow, we found one! :-) [06:31] jbicha: but it doesn't seem to be there [06:32] pitti: we dropped Login Preferences when we switched to GDM 3 as we didn't feel like rewriting it [06:32] jbicha: ah, that one (gdmsetup); I thought the autostart one [06:33] the gdmsetup one was only the login sound only for gdm [06:33] the "tadada" [06:37] pitti, hey, about the LANG thing? [06:39] didrocks, I just closed mumble and it caused my workspace to get visually garbled [06:39] would this be at all a useful bug for me to log? [06:40] *sigh* [06:40] pitti, better get in quick before I log off... [06:40] it seems to be that my desktop image is now mapped to my browser window [06:43] rickspencer3: yeah, this bug is known and fixed for compiz [06:43] thanks didrocks [06:43] rickspencer3: I didn't want to push it yesterday, because it's risky [06:43] and we know what happens when there is a change in the stacking code :) [06:43] didrocks, np [06:43] indeed [06:43] rickspencer3: so basically first SRU, with a day of staging [06:43] a week* [06:43] robert_ancell: whoops, notify fail [06:43] robert_ancell: I just followed up to the MP and to the bug [06:44] robert_ancell: so, the updated MP is rather bad IMHO (aside from the fact that it has a security vulnerability) [06:44] robert_ancell: I still don't understand why lightdm has to set $LANG in the first place, and second, why setting $LANGUAGE instead wouldn't be enough [06:44] robert_ancell: I thought the original idea was "control center and gdm only set a language, not a complete locale; if you want to have full control over locales you need langauge-selector" [06:46] pitti, so the case is "systems that don't only use .dmrc and don't have a language changer need to set the language". They have a Language defined in ~/.dmrc, and LightDM maps that to a locale (by scanning locale -a) and sets LANG overriding the system default set in PAM. If you do use accountsservice then it is overriden by the values set in ~/.profile [06:47] robert_ancell: but that doesn't seem to be cjwatson's bug [06:47] robert_ancell: cjwatson's .dmrc had complete locales [06:47] pitti, the case that cjwatson was getting, is he had both en_GB and en_GB.utf8 as valid locales, and lightdm picked the former meaning he was using the wrong locale. 1.0.0 changed this to pick a locale with a codeset over one without [06:47] cjwatson's bug is that lightdm assigns $LANG to the "Language" property in accountsservic3e [06:48] robert_ancell: right, which made it just differently wrong [06:48] robert_ancell: but the Language property is not a locale [06:48] pitti, I didn't touch base with him, but he must have had "en_GB" in the output of locale -a (I don't) [06:48] robert_ancell: yes, he did [06:48] so in his case, en_GB was a valid locale [06:48] yes, but nowhere did it say that it was his selected locale [06:48] .dmrc said en_GB.UTF-8 [06:49] and accountsservice doesn't have a locale [06:49] robert_ancell: I think the part of .dmrc is okay [06:49] which is for the "derivatives" case, AFAIUI [06:49] pitti, now that is weird. It should have contacted accountsservice and that should have returned "en_GB" [06:49] robert_ancell: right, it did [06:50] robert_ancell: but that is *not* a locale [06:50] it's a language name [06:50] German would have said "de" [06:50] pitti, correct, and lightdm uses set_language to map that to a locale name [06:50] pitti, not de_DE? [06:50] yes, and that's the very bug :) [06:50] robert_ancell: no, because it is not a locale :) [06:51] robert_ancell: English and Spanish are special because the country specific dialects are so far apart [06:51] so for English, Spanish, and Portugese we also need the country dialect [06:51] but all other languages are similar enough to only have one name [06:51] e. g. German in Austria or French in Belgium are so close that they don't warrant a separate set of translations [06:51] robert_ancell: and you cannot select a country in control-center, i. e. you can never pick a locale there [06:52] i. e. I can't say "I'm in Austria" [06:52] I can just say "I speak German" [06:52] and that concept is $LANGUAGE, while "I'm in Austria" is a locale [06:52] pitti, so is accountsservice different to dmrc? [06:53] robert_ancell: I'm not entirely sure how different login managers handled .dmrc; it was a giant pile of underdefined mess [06:53] robert_ancell: but from what cjwatson had, it had a complete locale, i. e. for $LANG [06:53] and _also_ a language list in a different key [06:53] hang on, looking for his pastebin [06:53] robert_ancell: but at least accountsservice is defined to only be a language name, i. e. for $LANGUAGE (not for $LANG) [06:54] it would have helped immensely if $LANG was called $LOCALE, FWIW [06:54] pitti, hang on, lets set up etherpad and write this out in a table [06:54] robert_ancell: http://paste.ubuntu.com/702159/ <- cjwatson's .dmrc [06:54] Language=en_GB.UTF-8 [06:54] Langlist=en_GB:en [06:54] LCMess=en_GB.UTF-8 [06:55] which maps to $LANG, $LANGUAGE, and $LC_MESSAGES in that order [06:55] robert_ancell: sure, want to create one, or want me to? [06:55] pitti, but that's wrong isn't it - shouldn't Language be "en_GB" [06:55] pitti, you create one, I'm still trying to find the link to it [06:56] robert_ancell: http://pad.ubuntu.com/locale-handling [06:58] brb [06:59] pitti: could you merge https://code.launchpad.net/~jbicha/ubuntu/oneiric/jockey/update-help-link/+merge/77782 [07:09] robert_ancell: I'm not sure what kind of language configuration tool derivatives use [07:09] robert_ancell: we didn't use to have one before hardy either, we just had the installer, and then people edited .profile [07:09] pitti, they used to rely on the greeter, but if the DM doesn't set LANG, then nothing does [07:09] robert_ancell: sure, /etc/default/locale does [07:09] pitti, yes, nothing per user [07:11] pitti, so it sounds like the concept of the MP is right - we should set LANG="Language" from .dmrc if dmrc is used, and do nothing if accountsservice is used? [07:14] robert_ancell: yes [07:15] robert_ancell: setting the language from .dmrc is kind of deprecated now, at least from teh GNOME side, right? [07:16] pitti, and the current behaviour is safe I *think* in that it will at worst set LANG to the value in .profile anyway [07:16] robert_ancell: no, it's not safe, as it sets $LANG from accountsservice's Language property [07:16] pitti, yes, the LANG stuff in lightdm is a compromise for legacy system [07:16] i. e. it derives a locale from a language name, which can't work [07:17] robert_ancell: the bug we must fix is setting $LANG from Language; presumably the ~/.dmrc stuff is alright (haven't tested it, though) [07:17] those are two orthogonal issues [07:17] pitti, is there an example that it will break. If a-s Language=de, lightdm will run locale -a, look for de.* and then de, if it exists, set LANG to that otherwise do nothing [07:17] robert_ancell: nonono [07:18] don't do all that locale -a stuff [07:18] it can't work [07:18] that is the very bug [07:18] pitti, I'm just running through what it does right now [07:18] pitti, if you've never set a language it will do nothing as "Language" from a-s will be blank [07:18] if you have set a language with the GUI, then .profile will be updated anyway and will override whatever lightdm set [07:19] robert_ancell: that case needs to be checked, of course; i. e. dont set $LANGUAGE to that empty field, just leave it alone [07:19] pitti, I think we're safe as is for release though? [07:20] robert_ancell: I think the only thing that we need to fix for the release is bug 864618 [07:20] Launchpad bug 864618 in lightdm "UTF-8 locale no longer set" [Critical,In progress] https://launchpad.net/bugs/864618 [07:20] the .dmrc stuff is probably alright [07:20] robert_ancell: i. e. we need to drop all that `locale -a` parsing and setting $LANG from accountsservice [07:21] right now that's a rather grave bug [07:21] pitti, cjwatson should have LANG=en_GB.UTF-8 in lightdm 1.0.1 right? He had LANG=en_GB in 1.0.0 [07:21] I'm not sure why https://code.launchpad.net/~gunnarhj/gnome-control-center/non-utf8-confusion/+merge/78140 exists and why we need it [07:21] robert_ancell: no, he doesn't [07:22] robert_ancell: you don't look for .UTF-8 [07:23] robert_ancell: it'll find en_GB.iso88591 first [07:23] pitti, but I do in 1.0.1! [07:23] oh [07:23] robert_ancell: but even then, you only look at the locale name, which can be anything [07:23] really, we need to drop that code [07:23] looking for .UTF-8 is just equally wrong [07:23] well, I'm ok to drop it, and SRU the proper fix in later [07:24] many locales are UTF-8 and don't have such a suffix, and then have another encoding with a suffix [07:24] hy_AM UTF-8 [07:24] hy_AM.ARMSCII-8 ARMSCII-8 [07:24] for example [07:24] pitti, you just need to comment out set_language() [07:24] robert_ancell: right, that was the original MP, AFAIUI [07:25] robert_ancell: what does that do exactly? [07:25] pitti, but it will break it for derivatives [07:25] robert_ancell: set $LANG from accountsservice? or also handle .dmrc? [07:25] we need to drop the first, and keep the second [07:25] * pitti RTFS [07:25] pitti, a-s and dmrc are the same inside lightdm, so both fields are being treated as a language code [07:26] the proper fix is to have a locale property and a language property on the user object, the former set if using dmrc and the latter if using a-s. If user.locale != null then set LANG [07:27] and if user.language != null, then set LANGUAGE (but that's optional as long as we write ~/.profile, but should be done later on) [07:27] pitti, I think we just need to match the old GDM behaviour of setting LANG only. If you want proper language support then use ~/.profile or ~/.pam_environment [07:28] this is just a sticking plaster for desktops that haven't sorted out their language configuration [07:28] robert_ancell: that's easier indeed [07:28] so the long-term simple design is that lightdm/gdm don't set anything, and just make sure to source in .profile and .pam_environment [07:28] right? [07:28] pitti, can you make the change? (do we still have time) [07:28] yes [07:28] robert_ancell: yes, this is a critical bug milestoned for final, we make time for these :) [07:29] robert_ancell: NB that if I upload it, I need to wait some time for someone else to review it, and then have the same conversation all over again [07:29] but Gunnar's original MP was correct, I think I can just sponsor that without the second /tmp/foo stamp stuff [07:29] robert_ancell: so yes, can do that ^ [07:29] ok. thanks pitti! [07:30] pitti, I have to go, is there anything else you need me to do? [07:31] pitti, also you probably want to disable user_set_language in greeter.c as that will set the language wrong [07:32] (only occurs if you've enabled the legacy language selector (in the gtk greeter)) [07:32] Moin Desktoppers! [07:32] robert_ancell: checking [07:33] robert_ancell: hm, that's an unrelated bug, though? [07:33] hey Sweetshark [07:33] pitti, yeah, it's just the opposite of the other bug though [07:33] robert_ancell: so user_set_language gets passed a locale instead of a langauge name? [07:34] pitti: 3.4.3-3ubuntu1~natty1 would fix postgres for natty, but needs pg 9.1 it seems. what should we do? [07:34] pitti, I can't remember off hand, but it passes the same value to a-d and .dmrc so it will be wrong in one [07:34] Sweetshark: uh, how so? does it have server-side extensions, or does it actually use new API from libpq 9.1? [07:34] to a-s rather [07:34] robert_ancell: right [07:35] pitti: it uses the new api [07:35] robert_ancell: I think that's SRUable, though, as it only breaks when writing, not already when starting the session? [07:35] pitti, yes [07:35] Sweetshark: so, I guess we can leave it broken then [07:36] pitti, anything else? [07:37] pitti: ok [07:38] pitti, I have to go, email me and I'll check tonight if it's urgent [07:38] robert_ancell: good to go now, I think [07:39] jasoncwarner_: nothing on my list for 1-1 today, just a ton of stuff to sort out for oneiric, so I wouldn't mind dropping it [07:39] pitti: done [07:47] morning [07:53] hey rodrigo_ [07:53] hi didrocks [08:05] good morning seb128 [08:05] hey [08:06] salut seb128 [08:06] lut didrocks [08:06] hey micahg [08:06] seb128: I was wondering, can we switch the Ubuntu Desktop team owner to the DMB so that the DMB doesn't have to be a member and therefore does not get extra upload rights? [08:07] micahg, what is the dbm? what does that mean? why the dmb needs to own the team? [08:07] seb128: the DMB is the Developer Membership Board which delegates to the desktop team the right to confer upload rights [08:08] hum, I though we were entitled to decide who join our team? [08:08] hey seb128 [08:08] seb128: yes, you are, that's the delegation :) [08:08] micahg, there is probably a reason but I don't understand what issue you try to solve [08:08] hey pitti ;-) [08:09] seb128: right now the DMB members who are not core-dev can upload from the desktop packageset, I'm trying to prevent that [08:09] micahg, why does the DMB need to have rights on the desktop set? [08:09] micahg: as long as some of the team members are admins, that makes sense indeed [08:09] seb128: the most probably case would be for removals [08:10] seb128: otherwise, I don't see us touching it, we're already admins on the team though, so no increase in permissions for us [08:10] in fact, this reduces our permissions [08:11] seb128: pitti and you would remain admins to manage as usual [08:12] I've no strong opinion, it feels a bit weird to have the ownership moved to a team which has nothing to do with desktop but if pitti is ok feel free to do it [08:12] seb128: core-dev is owned by DMB as well [08:12] i.e I don't understand why DMB needs to have rights in a team well administrated but there is probably a reason ;-) [08:12] seb128: that's the point -- we want to _remove_ right :) [08:13] pitti, well they can ping any admin for that as long as we have active admins ;-) [08:13] owner = modify membership w/out being a member [08:13] seb128: no, the thing micah wants to remove is DMB members being able to upload desktop packages [08:13] well I don't see DMB has "owning" desktop [08:14] pitti, well, just unsubscribe DMB from the team? [08:14] seb128: they need to be able to add/remove members to it, as per delegation policy [08:14] seb128: should we make a separate team just for the upload rights? [08:14] but if that's the standard way it's done for other team just do it for desktop [08:14] it just feels weird ;-) [08:14] micahg: ubuntu-desktop is the team for the upload rights, by and large [08:14] micahg, that's what the team is about already, uploads [08:15] ok [08:15] we have desktop-bugs for bug triagers, and gnome3-team for new crack [08:15] seb128: i. e. drop DMB as a member, but make it an owner; that's the standard way other teams are set up these days [08:15] pitti, micahg: ok, please do it then ;-) [08:15] yeah, I'm just doing some cleanup that should've been done a while ago [08:15] seb128: can't, you are the owner [08:15] lol [08:15] oh, I see, you are trying to kick me out :p [08:16] micahg, pitti: ok, I will change the owner [08:16] seb128: heh, you're still a full admin for the team [08:17] no worry, I think the misunderstanding comes from my lack of understand of what is the "owner" role exactly for a team [08:17] but I will trust you guys ;-) [08:18] yeah, the role names can be confusing [08:21] are we going to use a brand new PPA for the GNOME 3.2 extra backport stuff? [08:21] pitti, seb128: so, what do we do with the rejected Recommends: mesa-utils in control-center? [08:21] rodrigo_: I think just keep what we have at this point [08:22] rodrigo_, yeah, I blame it on bryceh and RAOF that glxinfo is in universe [08:22] pitti, ok, I'll remove that part and re-upload [08:22] jbicha, I would recommend using gnome3-team? [08:22] jbicha, just use the oneiric pocket of the current ppa? [08:22] rodrigo_, can you get Gunnar's fix as well? [08:23] rodrigo_, https://code.launchpad.net/~gunnarhj/gnome-control-center/non-utf8-confusion/+merge/78140 [08:23] hi everyone [08:23] hey ricotz [08:23] seb128, sure [08:23] hey seb128 [08:23] rodrigo_, though I'm not sure the patch is right [08:23] looking [08:23] well there's 161 packages in the PPA, for Oneiric we might not use more than 10% of that number! [08:24] seb128, hmm, doesn't look good to me neither [08:24] I was thinking a new PPA would be simpler, without needing to filter by series [08:25] jbicha, that is the purpose of filtering ;) [08:25] i dont see a need for a new one here [08:25] ricotz: yes but it's clutter that was just for Natty and we don't need that baggage [08:26] jbicha, well nobody will see the ppa content, user just add one serie to their source [08:26] but I see it! ;-) [08:27] filter it! ;) [08:27] well, we can clean the natty packages once oneiric is out [08:28] oh ok, I like that solution :) [08:28] seb128, mhh, i would wait for that a few months [08:28] seb128, pitti: with Gunnar's patch in https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/864618 there's no need for the "fix" in g-c-c, right? [08:28] Launchpad bug 864618 in gnome-control-center "sets $LANG to a language name" [Low,In progress] [08:29] the fix in g-c-c is https://code.launchpad.net/~gunnarhj/gnome-control-center/non-utf8-confusion/+merge/78140 [08:29] ricotz: well we want to discourage users from attempting to do GNOME 3 in Natty though [08:29] which looks wrong to me [08:29] rodrigo_, there is still I think [08:29] rodrigo_, but it's very low importance, let's not bother for oneiric [08:29] seb128, ok, so I upload without this? [08:29] rodrigo_, it seems that the user account can pick an iso8859 encoding when the locale doesn't reflect that [08:29] rodrigo_, right [08:30] ok [08:30] rodrigo_, seb128: hang on, on the phone [08:30] jbicha, ok, but some people doesnt upgrade instantly here, and i would wait for some later revisions of 3.2.x to land before cleaning it [08:31] rodrigo_: I'm not sure what that "confusion" MP is all about [08:31] rodrigo_: probably better to ask Gunnar directly (in the MP or on IRC) [08:31] yes [08:31] ricotz: I just think that GNOME 3 in Oneiric is far better than it was in Natty though [08:32] pitti, it's what cjwatson mentioned on #ubuntu-devl yesterday, he had "english (iso-8859-1)" in the user admin combo where his locale is not an iso one [08:32] rodrigo_, seb128: FYI, that's where much of this confusion came from: accountsservice and control-center do NOT select a locale, or encoding, or anything; just a language [08:32] yeah [08:32] seems the lightdm part is ok now, right? [08:32] ricotz, jbicha: well, cleaning the natty ppa will not uninstall GNOME3 from natty boxes which installed it from the ppa, just prevent new users to installit [08:32] the concept of encodings, iso, locales all don't apply to control-center [08:32] rodrigo_: it's not ok yet, but at least that part is [08:32] ok [08:33] rodrigo_: lightdm stopped setting $LANG from accountsservice's Language property [08:33] which was the main bug [08:34] * pitti bbl [08:34] seb128, i know, still leaving it some weeks active doesnt hurt here [08:35] ricotz, right, it's not useful but doesn't hurt a lot, out of the fact that I start having enough getting gnome-icon-theme bugs from people who try the ppa and try to roll back using ppa-purge :p [08:35] seb128, i am still relying on this ppa as build-dep for mine [08:35] it hurts me!! :) [08:36] ricotz: that is the purpose of copy packages :) [08:36] jbicha: no, not really, that just wastes space on the servers [08:38] seb128, jbicha, please leave it too me to clean the natty pocket [08:38] ok [08:38] ok with me too [08:40] alright, i will wait some weeks then, to see if the download counts are dropping [08:41] any idea when kenvandine comes in? :) he still needs to patch mission-control [08:43] dupondje, he's u.s based, it's like 3am for him [08:43] dupondje, so in a few hours [08:43] heh ok :) [08:44] ricotz, there are still lot of users installing it? just curious ;-) [08:44] seb128, yes, at least updating from it [08:45] what are the numbers? I don't think I've seen them [08:51] jbicha, it might not be that accurate but it is like 800 downloads per day [09:36] pitti: we don't use the desktop cache anymore? Seems /usr/share/applications/desktop.fr_FR.utf8.cache is out of date for me [09:37] didrocks: right, we didn't get it ported to the new gnome-menus, and didn't find it to be important any more for boot speed [09:38] didrocks: as we don't actually use gnome-panel any more, etc. [09:38] pitti: ok, thanks or confirming :) [09:48] didrocks, pitti: we should perhaps make gnome-menus clean those on upgrade? [09:48] seb128: yes, right [09:49] seb128: btw, thanks for getting the pad restored [09:49] seb128: I'll upload a gnome-menus with that cleanup [09:50] pitti: seb128: there was no use of it for unity-place-applications? [09:50] kamstrup: ^ [09:50] didrocks: there probably was, but we just didn't get around to porting the patch [09:50] gnome-menus 3.2 got changed pretty thoroughly [09:51] pitti, didrocks: yes, u-l-a uses libgmenu [09:52] butit is started lazily by unity [09:53] didrocks, seb128: filed as bug 868219 [09:54] Launchpad bug 868219 in gnome-menus "Needs to remove old menu caches" [Medium,In progress] https://launchpad.net/bugs/868219 [09:54] hi everyone [09:54] hey chrisccoulson [09:54] seb128, did you know that we can't switch users from the lock dialog? [09:54]