[02:28] So... After a year and 3 days, we have another offocial pulse release. :) [02:28] official [02:28] Damn my typing is sucking today. [02:28] heh [02:29] Heh. I thought that'd take longer :) [02:32] I didn't know how long it would take. [02:32] But its easy to role snapshot tarballs from the stable bugfix branch anyway. [02:32] But it does mean version numbers can return to a cleaner state. [02:38] TheMuso: Would you be free to upload a simple mesa change to get it building on the buildds again? [02:39] RAOF: Sure. [02:39] Happy to do another test build for you if needed as well. [02:40] http://cooperteam.net/Packages/mesa_7.9+repack-1ubuntu2_source.changes [02:40] If you do a test-build you'll need to do a parallel test build to actually trigger the bug that caused the FTBFS. [02:41] Hrm ok. [02:41] Which is why it went up in the -1ubuntu1 revision in the first place :) [02:41] heh right. [02:41] Having DEB_BUILD_OPTIONS=parallel=8 in the environment you call sbuild works. [02:42] Ok [02:42] But I've run that with -1ubuntu1, verified that it fails, and then checked that -1ubuntu2 builds, so I'm confident it works now :) [02:43] Ok running anyway. [02:48] Hot weather sucks with computers, and cases that don't entirely have the best airflow... [02:49] Heh. [02:49] My desktop may also need a cleanout... [02:49] It's nice and cool down here! [02:49] Yeah its times like this I wish I was still on the mountains. [02:50] With today's weather, the mesa build is doing well enough to push my CPU to the point where the warning alarm is going off. :) [02:54] Ok now its gone, as we are at the package building stage. :) [02:54] s/we are/the machine is/ [02:57] RAOF: uploading. [02:57] TheMuso: Thanks muchly. [02:58] You're welcome... You know you ort to apply for core-dev one of these days. [03:02] Yes. === asac_ is now known as asac [04:41] TheMuso, did you have a look at yelp? [04:41] robert_ancell: There is not even orca support for it upstrea yet, and not all a11y bugs are fixed upstream yet, although there are only a few left. [04:42] So just put it in, as seb said last week, either way we're damned. :) [04:42] I think that is the safest strategy.. [07:29] Good morning [07:31] morning pitti! [07:31] ah, no robert any more [07:31] hey jasoncwarner, how are you? [07:32] Pretty good...watching my countrymen celebrate thanksgiving from a distance ! [07:37] Oh, wow. *That's* why IRC looks funky. The Ubuntu font seems to have grown a monospace. [07:40] heh [07:55] good morning [07:57] morning, didrocks... [07:57] hey jasoncwarner, how are you? [07:58] didrocks: pretty good...cooking up a really lame version of thanksgiving for my family ;) [07:58] jasoncwarner: hehe, the australian version now? :) [07:59] didrocks: I think even australians would be ashamed of what I call "food" :) [08:01] jasoncwarner: oh really? :) === almaisan-away is now known as al-maisan [08:12] hey didrocks, good morning [08:12] Guten Morgen pitti [08:12] didrocks: should we move some of your a1 WIs to a2? or do you still plan to land some updates on Monday? [08:13] pitti: oh, most of them will be closed today [08:13] oh, nice! [08:13] pitti: just wait a little, getting soon a compiz upload :) [08:13] and that unblock everything [08:13] didrocks: wasn't meant for hurrying, just to see how we stand for a1 [08:13] at this point, postponing to a2 is very cheap :) [08:13] * pitti hugs didrocks [08:13] pitti: I think from my WI, it should be good [08:13] * didrocks hugs pitti [08:15] pitti: the thing about our discussion yesterday on gnome-panel… [08:15] we infered that people either launch gnome-wm or compiz [08:15] .. (or metacity?) [08:16] well, we were talking about launching gnome-panel from there [08:16] or patching metacity for that as well? :/ [08:16] but people clicking on the gnome-appearance-properties capplet on the "none effect" have metacity set by default in the gconf key [08:16] (this is why I set the gnomewm thing is broken by design, it's of little use) [08:35] reboot, brb [09:24] hello everybody [09:24] hey dholbach [09:25] didrocks, pitti: how do you see chances of bug 574046 being put into lucid, maverick, natty? [09:25] Launchpad bug 574046 in gnome-system-tools (Ubuntu) (and 1 other project) "shares-admin doesn't "see" NFS and SMB installed (no support for Upstart jobs) (affects: 12) (dups: 4) (heat: 72)" [High,Triaged] https://launchpad.net/bugs/574046 [09:25] if you look at the upstream bug, you can see that upstream would be willing to merge it [09:26] 'lu seb128 [09:26] hey dholbach [09:26] sorry I was doing some testing [09:26] I should stay from now until I start upgrading unity and playing with that [09:26] no need to be sorry for that - at least somebody does some testing :-P [09:26] dholbach, how are you? [09:27] ça va bien - merci :) [09:27] seb128: don't upgrade [09:27] seb128: it's currently broken as sladen made a wrong fix… [09:27] didrocks, unity or grub? [09:27] I had a lot of fun doing my videocast yesterday - until a friend decided to visit me, the doorbell rang and Murphy started barking like crazy - everybody wanted to see the dog afterwards :) [09:27] or both? [09:27] unity [09:27] ok [09:27] I saw the update yesterday and I was sure you would complain :p [09:28] of course, he didn't use the vcs, uploaded unity without understanding "why there is no gconf schema" [09:28] dholbach, haha [09:28] "let's just remove it" [09:28] grrr… [09:28] seb128, I was just asking about bug 574046 - do you think it's wise to get it into lucid, maverick, natty? [09:28] Launchpad bug 574046 in gnome-system-tools (Ubuntu) (and 1 other project) "shares-admin doesn't "see" NFS and SMB installed (no support for Upstart jobs) (affects: 12) (dups: 4) (heat: 72)" [High,Triaged] https://launchpad.net/bugs/574046 [09:29] if you look at the upstream bug, upstream offers a deal: he'll merge it upstream if we put it into lucid, maverick and natty :) [09:29] dunno, ask the day patch pilot about it? [09:29] ;-) [09:31] dholbach: g-s-t will disappear from natty, and adding support for upstart jobs is outside the SRU range IMHO [09:31] the patch isn't that big :) [09:31] I thought shares-admin has been obsolete for a long time? we don't even install that any more, do we? [09:32] seems it's installed on my machine in maverick [09:32] it has been mostly deprecated by nautilus-share [09:33] dholbach: I'll have a look at it for lucid, but I don't think it makes much sense in natty, given nautilus-share [09:33] we still install it because people need to edit shares they maed with it though [09:33] or to be able to edit those [09:33] or delete those [09:33] nautilus-share doesn't share things the same way so it doesn't allow to edit those you did with it [09:33] you guys have given up from translating ~/Desktop in some point of time, right? [09:33] * hyperair needs to implement a UI for nautilus-share to do that. [09:33] * pitti puts into his queue today [09:34] also, anyone knows how to disable recently used list? I think it's managed by nautilus [09:36] RenatoSilva, no, it's translated [09:37] RenatoSilva, chmod .recently-used* [09:37] seb128: but for root it's Desktop, for my regular user it's Área de Trabalho [09:37] in a mode where it's not writable for your user [09:37] RenatoSilva, it's a service on session start which create those directories [09:37] you might have started with a C locale [09:37] or not started a session for the users but used sudo [09:38] hi [09:39] seb128: I just s/Área*/Desktop in ~/.config/user-dirs.dirs [09:39] seb128: there's another regular user for which it's Desktop and I don't know why [09:40] seb128: I think it was a very bad idea anyway, Área de Trabalho as a directory name is boring [09:40] * RenatoSilva starts using Desktop [09:46] can I have a review of this please -> https://code.launchpad.net/~rodrigo-moya/ubuntu/natty/gnome-settings-daemon/2_91_4_release/+merge/41911 (for the gnome3 ppa) === rodrigo__ is now known as rodrigo_ [09:54] how to get rid of xsession-error? [09:54] RenatoSilva, of the .xsession-errors file you mean? [09:55] rodrigo_: is it normal to have so many errors all the time? [09:55] rodrigo_: there should be no error [09:55] well, what errors? [09:55] rodrigo_: doesn't matter what [09:55] rodrigo_: should that file exist? [09:56] lots of session-started apps put their output there, so not all of that are errors [09:56] rodrigo_: the errors go there all the time [09:56] so, what errors do you see there? [09:56] rodrigo_: so it's normla to have that file with some errors? ok [09:56] RenatoSilva, no, it's not normal to have errors [09:56] rodrigo_: it's very big file, do you want to read it? [09:56] it's normal to have output of gnome-session and other session apps [09:57] rodrigo_: so what's normal? [09:57] RenatoSilva, if you pastebin somewhere, I can have a look [09:57] rodrigo_: on a file called ERROR? amazing! [09:57] yes, the name might be misleading, it contains output, not only errors [09:58] will that file have any sensistive information? [09:58] otehrwise can't be pasted [09:58] hmm, I think not [09:59] have a look at it first [09:59] hahahahahaha [09:59] * RenatoSilva reads 2890 lines, brb [10:00] :) [10:00] http://pastebin.com/raw.php?i=XQ0ZNY4T [10:05] seb128: chmod doesn't work, it's written regardless! [10:05] you didn't set the right mode [10:05] chmod -w? [10:06] seb128: -rw------- 1 => .recently-used.xbel [10:06] seb128: it's the only .recently-used* [10:07] seb128: something is +w it [10:07] RenatoSilva, most stuff in that pastebin are debug messages, and a few non-critical warnings, so they're not really critical errors [10:07] seb128: it was -r-------- 1 [10:07] RenatoSilva, only one is (nautilus:1633): GConf-CRITICAL **: gconf_value_free: assertion `value != NULL' failed [10:07] rodrigo_: so how to get rid of them, I don't like creating files endlessly [10:08] seems nautilus is calling that function with a NULL, which is wrong, but it's not critical [10:08] RenatoSilva, there's no way, just remove it when you log out, or something like that [10:09] rodrigo_: amazing! [10:09] considering there's no way to exec a command when I log out [10:09] RenatoSilva, chmod 0 it? [10:09] where log out means log out from gnome, not bash [10:10] seb128: the same for recently used? will try [10:10] if there was some .bash_logout equivalent for gnome (when I click log out), then I could remove these files there :( [10:12] rodrigo_: want me to look at your gsd branch? [10:12] pitti, if you can, yes, please [10:12] pitti, it's for merging to lp:~ubuntu-desktop/gnome-settings-daemon/ubuntugtk3 branch [10:13] pitti, and uploading to the gnome3 ppa [10:13] rodrigo_: sure, will do [10:13] ok thanks [10:13] rodrigo_: this isn't destined for natty yet? [10:13] pitti, no, not yet, just the ppa for now [10:17] seb128, you didn't upload the gnome-bluetooth package to the ppa, did you forget it or just that it needs more changes? [10:18] rodrigo_: merged and uploaded, thanks [10:18] pitti, yet -> ever [10:18] pitti, thanks [10:18] seb128: "ever" for natty? [10:18] we discussed with robert_ancell this week [10:19] we think that GNOME3 will stay out of natty [10:19] oh [10:19] sorry I meant to do a status update but didn't have time yet [10:19] well, we will decide at the rally [10:19] and we still want GNOME3 in the ppa [10:19] ah, ok, I thought we were going to decide later in the cycle [10:19] but it turns to be a dump of everything in the ppa or nothing [10:19] rodrigo_: GConf-CRITICAL **: gconf_value_free: assertion `value != NULL' failed. This is a bug? [10:20] rodrigo_, " well, we will decide at the rally" [10:20] yes ;-) [10:20] RenatoSilva, yes [10:20] rodrigo_, but our feeling is that it's going to be lot of word for little benefit for users [10:20] seb128, right, I was answering to your "ever" thing :) [10:20] we don't think we have time to tackle that work [10:21] we will need to focus on unity now since it will be usable enough for that [10:21] pitti, ^ [10:21] GNOME3 doesn't bring a lot on the user perspective [10:22] the work is mostly done to port to new technologies [10:22] with some redesign [10:22] the main different is the control-center [10:25] well, at some point we need to do the jump to gsettings, etc., and we should not do it in an LTS cycle [10:25] so in the olympic oyster there is our last chance? [10:30] pitti, it's going to be next cycle yes [10:30] pitti, well we do use gsettings already in some components [10:30] pitti, GNOME3 will be out this cycle and ready in the ppa [10:31] so we can dump it in oyster from day one [10:31] we have 2 cycles then to deal with cleaning [10:31] dholbach: ok, the patch looks quite straightforward, I'll sponsor it to lucid and natty then [10:31] seb128: *nod* [10:31] pitti, thing is that GNOME3 has bugs [10:31] * dholbach hugs pitti [10:31] what do you think about maverick? [10:31] pitti, they dropped the gnome-appaerance-properties for example [10:31] pitti, so we could need to redo the desktop effect capplet [10:32] dholbach: forward-porting the patch, as for natty, I guess? [10:32] not sure if we care about having a way to set themes for our users [10:32] etc [10:32] pitti, there is a lot of details to sort and I would rather not drive ressources away from unity [10:32] seb128: right, makes sense [10:32] ah, so maverick and natty are the same? [10:33] right [10:33] ok, super :) [10:34] seb128: maybe make xsession-errors a link to /tmp/username-xsession-errors? I'll try that [10:35] seb128, about the desktop effects, isn't unity what should be providing that now? [10:36] rodrigo_, it could be, it's just that they are things we need to sort [10:36] and patches we will need to redo or update that we commented for now [10:36] rodrigo_, well, GNOME3 itself is almost a full time job for the cycle if we want to do it right [10:36] but the priority is unity this cycle [10:37] so I don't think we can get both done in a rocking way [10:37] imho we will should focus on unity and keep the GNOME3 ppa running on best effort basis [10:37] it might be easier to get community help and to update after freezes etc in the ppa [10:37] so it's not especially an issue [10:39] so, 11.10 is the next LTS release? [10:41] rodrigo_, 6.06, 8.04, 10.04, so I'd assume the next one would be 12.04 [10:41] ok [10:46] seb128: the recently used is echo "gtk-recent-files-max-age=0" > ~./gtkrc-2.0, will test now [10:46] rodrigo_, yes [10:46] ups [10:46] I'm tried [10:46] what dholbach said [10:46] :) [10:47] thanks all [11:09] hi pitti, would you mind adding mozvoikko to the mozilla packageset please :) [11:14] chrisccoulson: done [11:16] pitti - excellent, thanks [11:16] * chrisccoulson uploads a working version now [11:19] mpt: hi, just noticed something funny in SC : have SC running in the background and accept to install an update in update manager. while updating, we suddenly have SC showing "In Progress" … o.0 bug or a feature? [11:20] confused the heck outta me for a min and wondered what was installing/removing.. [11:20] I didn't specify it, and I'm kind of ambivalent about it [11:20] It does help in explaining why USC isn't doing anything else, if you had asked it to do anything else [11:20] but, it is a bit weird [11:21] apt-daemon … [11:21] oops! [11:21] * vish files bug.. [11:28] apt-get source openoffice.org [11:28] Need to get 507 MB of source archives [11:28] !!!!! [11:28] Good job I freed up some disk space! [11:28] :) [11:29] chrisccoulson: oh, you want to rebuild it? [11:29] if you're going to compile it, start now, so that you get it on monday :D [11:29] that's what buildds are for! [11:30] chrisccoulson: if you want to do an upload, please do it before Monday [11:30] chrisccoulson: as the armel builders will take about two days for it, and Thursday is alpha-1 time [11:30] chrisccoulson: (but an upload will be appreciated, as it will drop about 8 MB from the CDs!) [11:31] pitti - i didn't want to do an upload, i'm just curious to figure out why it has a build-depend on xulrunner-dev, and whether i can drop it [11:31] i don't want to end up maintaining OO.o too ;) [11:33] has anybody tried building OO.o with the new toolchain? [11:33] chrisccoulson: I don't think so; until we get a real OO.o maintainer, I guess we'll build it against gcc/g++ 4.4 [11:33] (if we need an upload before) [11:33] yeah, that's probably the best idea [11:34] it's bad enough trying to make something small like firefox work with it ;) [11:36] ok, I hate python it's decided [11:36] or rather our python packaging [11:36] lol [11:36] why does it keeps breaking [11:36] i hate python too! :) [11:36] update-manager doesn't start there [11:36] and the amd64 retracer broke again after upgrade [11:36] can't import wadllib [11:37] hate hate hate [11:37] wait, we're Ubuntu, I thought we loved Python [11:37] i hate it when i spend 30 minutes debugging an issue, only to find it's caused by indentation ;) [11:41] chrisccoulson, python -tt helps there :) [11:42] dholbach, oh, cool. thanks! :) [11:49] pitti: Re language fixes, should we take a step backwards and talk some more about what we want to achieve? === al-maisan is now known as almaisan-away === MacSlow is now known as MacSlow|lunch [12:24] hmm, does anyone know if there is a backport repo for pulseaudio for maverick? [12:27] seb128: hrm, hrm, hrm, I check out u-m [12:28] seb128: but yeah, we do not do well [12:39] hmm, so how do I merge-upstream for 1st time packaging of a new thing? [12:50] GunnarHj: hello, how are you? [12:50] GunnarHj: I thought from my POV gdm should just set $LC_MESSAGES and $LANGUAGES, and language-selector does everything permanently (writing configuration files, etc.) [12:51] pitti: Fine, thanks. You too, I hope. [12:51] GunnarHj: I'm great, thanks [12:52] pitti: Trying to get a grasp of Empathy, which I haven't used before. Did you see the question I posted a few minutes ago? [12:52] GunnarHj: the "Re language fixes, step back..."? yes [12:52] GunnarHj: that's the one I answered to [12:52] (but I was out at lunch) [12:52] ...another channel [12:55] pitti: Ok, now I see it. I'll try to write down my thoughts on that particular issue, and get back to you. Think we need to reach consensus on that before discussing the code. :-) [12:55] GunnarHj: I'd just desperately avoid anything in gdm which is expensive or changes files [12:59] pitti: But don't you think that the fact that nothing expensive happens except when the user actually changes language is good? Btw, considering the tiny amounts of data we are talking about, "expensive" isn't the word I would have chosen. [13:01] GunnarHj: ah, terminology :) calling grep and sed are already in the "expensive" category wrt. CPU usage for me [13:01] GunnarHj: also, we should avoid writing files, since it can be utterly slow if your home directory is on NFS or similar [13:01] mvo, it's not update-manager being broken [13:02] mvo, it's just that python-things get broken for random reason [13:02] until you --reinstall or upgrade them [13:02] GunnarHj: and I think it shoudl actually be sufficient to just set LC_MESSAGES and LANGUAGE, since after all that's what matters in the end? [13:02] the depends system is broken as well [13:02] like update-manager started using 2.7 without pulling in version of python-things it needs [13:06] im finally able to properly test unity now thanks to that upload yesterday :) [13:08] pitti: Did you notice my objection on the merge proposal, where I pointed out that one of the disadvantages with not writing the new setting to disk is that LANGUAGE and LC_MESSAGES would first be set when ~/.profile is read, and a couple of micro seconds later be set again based on dmrc and GDM_LANG[UAGE]? That might well happen at many logins, which in the long run would probably result in more CPU time. [13:10] didrocks: just made supprisingly the only bug I found so far other than the dash not being up Bug: 681780 [13:10] bug #681780 [13:10] Launchpad bug 681780 in unity (Ubuntu) "Unity [compiz] top panel doesnt hide when another app is in full screen (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/681780 [13:10] GunnarHj: but it needs to run these checks anyway? [13:10] pitti, hey [13:10] yep, juste not yet implemented [13:11] just for info I got a natty amd64 retracer running [13:11] I'm upgrading the i386 one next [13:11] Its working very well I have to say [13:11] pitti, we probably want retracing working to get nice unity bugs [13:11] so I figured we could start those now [13:11] fagan: heh, thanks to the dx team :) [13:11] seb128: you mean enable apport by default now? [13:11] pitti, no [13:11] pitti, just retrace the crashes we get [13:12] we first need natty chroots [13:12] ah [13:12] pitti, I plan to add "enable apport" in the unity debug wiki [13:12] pitti, we first need natty chroots [13:12] pitti, well what I was saying is "done for amd64" [13:12] "i386 on its way" [13:13] seb128: oh, I thought that referered to adding maverick-updates ddebs [13:13] seb128: thanks! [13:13] pitti, you're welcome ;-) [13:13] brb, testing new plymouth [13:13] pitti, I fixed the maverick ones as well [13:13] they both have updates sources [13:15] pitti, from launchpadlib.errors import HTTPError [13:15] hate hate python [13:15] pitti, I'm fixing the i386 one [13:15] it crashes on broken python imports [13:16] pitti: Without the checks it would need to _always_ set LANGUAGE and LC_MESSAGES, which reasonably cannot be more efficient in the long run. That's the point (no, one of the points) with writing to disk, i.e. normally gdm would only need to compare a couple of variables. [13:19] pitti: Btw, technically we are now talking about code belonging to language-selector, but it would be read and run by Xsession... [13:19] GunnarHj: but setting an env variable costs no time; the checks are the important bit here, and I don't see how we can drop them [13:25] pitti: Maybe I misunderstood you about dropping checks. But setting LANGUAGE and LC_MESSAGES out from dmrc/GDM_LANG[UAGE] costs, if gdm shall not destroy the LANGUAGE list each time and to ensure that LC_MESSAGES is assigned a valid locale. [13:27] GunnarHj: LC_MESSAGES is cheap (just =$GDM_LANG), LANGUAGE would only take some changes if it actually differs from $LANG/$GDM_LANG [13:27] I think that's an overhead we need to live with [13:27] I think it's just badly wrong for a session to mess with your configuration files [13:28] (and cf. problems on NFS and the like) [13:39] good morning! [13:47] hey cyphermox, how are you? [13:48] hey pitti, pretty good, and you? [13:48] I'm fine, thanks! [13:48] * pitti is patch piloting [13:51] pitti: We have been here before, I think. ;-) For a number of reasons I can't currently get the pieces together without writing to disk. [13:51] 1. Since dmrc no longer is set based on a pure list of available locales, GDM_LANG[UAGE] may well contain 'en.utf8' or some other non-valid locale, so the lookup using locale -a etc. is needed. [13:51] 2. Without saving the language to disk if it's set by the gdm greeter, ~/.profile and ~/.dmrc may disagree, so you would need to fiddle with the LANGUAGE list at each login. [13:51] 3. What has LANG to do with it? Isn't separating LANG from LANGUAGE/LC_MESSAGES the main purpose with the fix? [13:51] Personally I feel that this is too complex to deal with via instant messaging only. I'd like to go back, think it over and write up my thought more systematic. [13:52] GunnarHj: well, language-selector can (and should) write to the disk [13:52] there you are in a running session, without the danger of not being able to log in, and performance doesn't matter either [13:53] GunnarHj: $LANG shouldn't be touched any more; sorry, typo of mine [13:54] GunnarHj: I think the gdm changes should be very small; it should only set LC_MESSAGES instead of LANG, and do some additional magic to adapt LANGUAGES if $GDM_LANG != $LANG [13:54] (i. e. if you deviate from the system and user configuration) [13:54] does anybody have any idea what this patch is for in gjs: http://paste.ubuntu.com/536688/? [13:55] GunnarHj: I don't understand 1. The semantics and values from .dmrc or the language lists didn't change, i. e. "no longer" is confusing tome [13:55] it seems to have been inherited from debian, but there's nothing at all in the changelog [13:55] chrisccoulson: we have g-i from git head, so it might no longer apply [13:55] (based on the patch comment) [13:56] pitti - ok, i'll drop it for now then. it doesn't apply to the new source tarball anyway [13:56] (but I don't understand the patch at all) [13:56] me neither. i just want to get gjs built against the latest spidermonkey version ;) === MacSlow|lunch is now known as MacSlow [14:14] pitti: About dmrc and "no longer": Up to now, dmrc has been reflecting LANG, which has been set in the non-language tab in language-selector. That drop-down list seems to contain valid locales only, which is why Language in dmrc always has been a valid locale. I suggest that dmrc shall refect LANGUAGE instead, which is set in the language tab of language-selector. That drop-down list includes both language-country and lang [14:14] uage only items. Furthermore, if you pick a language only item in language-selector, the drop down list in the greeter starts displaying that item as well. Hope that explains it. [14:14] As regards risks with writing to disk: gdm obviously writes to both /var/cache/gdm/$USER/dmrc and ~/.dmrc already when the user picks some other language from the greeter than the preselected one. Why would it be more dangerous to write to ~/.profile at those, normally very few, occations? === almaisan-away is now known as al-maisan [14:16] GunnarHj: .dmrc has a fixed structure and is "owned" by gdm, while ~/.profile is a free-form shell script and a full programming language [14:16] it's bad enough that we need to touch it in language-selector, but we shouldn't duplicate that code out to several places [14:17] cyphermox: after the update it works for me. [14:17] cyphermox: I haven't roamed with it yet but it all appears to work so far [14:17] GunnarHj: also, changing ~/.profile carefully requires a lot of checks [14:18] GunnarHj: but right, changing ~/.dmrc would give the same problems on NFS and the like (which is why it's got a local cache file); I don't want to make this twice as bad by writing another (and much more complex) file [14:18] GunnarHj: if we can stop language-selector from writing profile and only write ~/.dmrc, that'd be ideal IMHO, but I'm not sure whether it's feasible [14:19] GunnarHj: .dmrc is used by other *dms as well, so we can't just redefine the meaning of "Language" there; it needs to stay a valid locale [14:36] grrr internet [14:36] does anybody know how to use launchpadlib to delete tags? [14:36] jcastro, thanks [14:36] bug.tags.remove('need-amd64-retrace') [14:36] seb128: apport does that [14:37] jcastro, I'm finishing up cleaning up my patch so that it may be upstreamable [14:37] pitti, let me read the source [14:37] then I'll upload one last copy of it to my ppa, then it will be ready for upload [14:37] seb128: x = bug.tags[:] # LP#254901 workaround [14:37] x.remove(self.arch_tag) [14:37] bug.tags = x [14:37] try: [14:37] bug.lp_save() [14:37] except HTTPError: [14:37] pass # LP#336866 workaround [14:38] seb128: unfortunately there are two launchpad bugs to work around for this operation :/ [14:38] ok [14:38] I tried [14:38] if need-i386-retrace in bug.tags: [14:38] bug.tags.remove('need-i386-retrace') [14:38]