[00:20] <bdmurray> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
[00:27] <bryceh> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[01:26] <Daviey> hallyn_: o/
[01:28] <Daviey> hallyn_: So i thought that debdiff was only required if we jumped to qemu 0.15, and the current version worked great with 0.14.. was i wrong?
[01:28] <bookpage> does anyone know if it is common for d3d programs to read from $DISPLAY?
[01:35] <hallyn_> Daviey: you were backward :)
[01:36] <hallyn_> Daviey: the ipxe that's in the archive right now will work with 0.15.  But our qemu is still 0.14.2 and it needs the old names
[01:36] <hallyn_> i don't know how i originally messed that up (but i did)
[01:36] <hallyn_> Daviey: i only realized that it was still wrong bc the libvirt qa-regression-testing from jdstrand failed :)
=== StevenK_ is now known as StevenK
=== kentb_ is now known as kentb-out
=== ScottSanbar is now known as SanbarComputing
=== SanbarComputing is now known as ScottSanbar
[02:42] <Daviey> hallyn_: Okay, if nobody beats me - i will upload it tommorrow morning.
[02:42] <Daviey> too tired to review it right now.
[02:42] <nigelb> s/tired/drunk/g
[02:42] <nigelb> :P
[02:43] <Daviey> hah
=== ScottSanbar is now known as SanbarComputing
[03:11] <slangasek> bdmurray: I haven't been able to reproduce bug #813065 with USB boot; I get a brief black screen, but no text. what boot log messages did you see?
[03:11] <ubottu> Launchpad bug 813065 in casper (Ubuntu) "Live session switches to VT console briefly" [High,Confirmed] https://launchpad.net/bugs/813065
[03:14] <slangasek> bdmurray: fwiw, architecturally we're always going to flash to black between the ubiquity menu and the "try ubuntu" session because there's no good way to hand off the X server between the two; but anything writing text to that console at boot probably needs to be fixed
[04:06] <pitti> Good morning
[05:34] <pitti> slangasek: can you please reupload your upower lucid SRU with a fixed bug ref in the changelog? (missing '#')
[05:47] <bdmurray> slangasek: probably stuff like starting bluetooth, pulseaudio is configured for per user seesions etc...
=== tkamppeter__ is now known as tkamppeter
=== rickspencer3__ is now known as rickspencer3
[06:07] <didrocks> good morning
[06:34] <infinity> mvo: I haz a question for you.
[06:36] <lifeless> mvo: and I (conflict checker is whining :P)
[06:36] <infinity> mvo: Me first, me first!
[06:36] <infinity> (It's bedtime for me, lifeless can suck it :P)
[06:37] <infinity> (That came out dirtier than I meant it)
[06:37] <lifeless> indeed
[06:38] <infinity> I think he joined IRC just to tease us.
[06:38] <infinity> And then ran off.
[06:39] <didrocks> infinity: yeah, it's the 1st part of the show right now, he'll be back in 30 minutes for the 2nd :-)
[06:43] <mvo> lifeless: conflictchecker just needs a new dpkg-dev I think with xz support
[06:43] <mvo> infinity: s'up?
[06:43] <mvo> infinity: (think of this as with my best german accent)
[06:44] <infinity> mvo: Oh dear.
[06:44] <infinity> mvo: So.  I've been looking at update-apt-xapian-index and its angry effect on ARM.  And then I read a manpage (crazy, I know), and found -u...
[06:44] <infinity> mvo: Is there any reason why we're not using '-u' in cron.daily/apt?
[06:45] <infinity> mvo: It brings run time down from 6 minutes to 30 seconds, and very limited I/O.
[06:46] <mvo> infinity: we used to do that, but it modifies the DB in-place and we had some (corruption) issues with software-center that looked releated to this. so we disabled it again, but I tihnk for P we should give it a try again as we found the db corruption bug in another spot
[06:46] <infinity> mvo: If you found the bug, can we flip it back? :/
[06:46] <infinity> mvo: This (literally) kills ARM desktops.
[06:46] <micahg> that might have saved lubuntu from dropping it as well
[06:48] <infinity> mvo: Like, we become completely unusable for those 6 minutes.
[06:48] <infinity> mvo: Which is extra special when it's one of the very first things a user sees (thanks to anacron kicking off cron.daily 5 minutes from first boot)
[06:49] <mvo> infinity: it runs with nice/ionice, it makes it unusable?!?
[06:49] <infinity> mvo: No amount of nicing or ionicing can help you when your storage is SD/MMC.
[06:50] <infinity> mvo: It brings the system to a halt.  DBUS connections time out.  Nothing can start.  Etc, etc.
[06:50] <infinity> mvo: '-u', on the other hand, seems very well-behaved.
[06:51] <mvo> infinity: *urgh* thats definitely bad. I really don't want to change this globally at this point and bring in potential regressions for i386/amd64, bt I understand that this is a big problem
[06:51] <infinity> mvo: We'd talked about it before, and you never mentioned -u, you just mentioned that it needed profiling.
[06:51] <infinity> mvo: So, I was a bit shocked to discover that it can play nicely. :P
[06:52] <infinity> mvo: Honestly, while I'm saying this with my ARM hat on, it's a big problem for any system that's "not fast".
[06:53] <infinity> mvo: My crappy Atom netbook does the same "grind to a halt" thing, just for slightly less time.
[06:53] <lifeless> mvo: any chance you can arrange that ? I'm swamped with new baby :)
[06:54] <infinity> mvo: is that a DC machine?
[06:54] <infinity> Err.
[06:54] <infinity> s/mvo/lifeless/
[06:54] <lifeless> infinity: yes
[06:54] <infinity> Then just file an RT ticket, they have dpkg with xz support, it's running on cocoplum.
[06:55] <mvo> infinity: it was me who actually added -u, its not my mission to make everything slow ;)
[06:55] <mvo> lifeless: yeah, I will file a rt
[06:55] <infinity> lifeless: 1.15.5.6ubuntu4.5.0.ISPATCHED.10.04
[06:55] <lifeless> mvo: awesome, thank you!
[06:55] <infinity> mvo: ^
[06:55] <mvo> lifeless: sorry, I would have done it earlier but the release (you know how it is)
[06:56] <infinity> mvo: I assumed it was you who added the flag, I just figured maybe you'd forgotten to get around to turning it (back) on.
[06:56] <lifeless> mvo: totally
[06:56] <infinity> mvo: And, again, if the DB corruption thing seemed to be a red herring (or, rather, a software-center bug), I'm all for bringing -u back. ;)
[06:58] <mvo> infinity: well, its not 100% clear that it was a red herring or actually a real bug. its possible there were two bugs, a) the in-place modification b) a threading bug that got later fixed
[06:59] <infinity> mvo: I'd also be willing to take the blame for doing something like "if [ "$(dpkg --print-architecture)" = "armel" ]; then $extra_args = '-u'; fi", if you're super scared about it breaking our primary arches.
[07:00] <mvo> infinity: that sounds good to me
[07:00] <mvo> infinity: I can add that now
[07:00] <infinity> mvo: That would be lovely.
[07:00] <infinity> mvo: *hug*
[07:00] <mvo> infinity: or feel free to just upload it yourself :)
[07:01] <infinity> mvo: Well, if I upload it myself, I'd have to not mix language syntax, as above.
[07:01] <infinity> But I think I can manage that. :P
[07:01] <infinity> mvo: You don't have any other apt stuff planned or lined up?
[07:02] <mvo> infinity: maybe pending, but its not clear yet if that should hit final or not (could be -updates too)
[07:02] <mvo> infinity: so I think a upload is fine
[07:02] <mvo> lifeless: rt filed
[07:03] <infinity> mvo: If you have -updatesish stuff pending and it's sane, I'd just as soon see it now.
[07:03] <infinity> (note the "if it's sane")
[07:03] <infinity> mvo: lp:apt the right branch?
[07:04] <infinity> Oh, the Sources file claims lp:~ubuntu-core-dev/apt/ubuntu
[07:05] <infinity> mvo: Is your pending stuff on the packaging branch?  If so, I'll have a look at it.
[07:05] <infinity> mvo: If not, give me a pointer to it, and I'll put on some other hats for a bit.
[07:06] <mvo> infinity: the only thing pending is a fix for 857472 but the best approach is not yet clear for this one
[07:06] <mvo> infinity: and yeah, lp:~ubuntu-core-dev/apt/ubuntu
[07:07] <infinity> mvo: Oh, the thing we "fixed" in stable release by just commenting it out? :P
[07:08] <mvo> infinity: *cough*
[07:08] <mvo> yes
[07:09] <infinity> mvo: Don't you just want check-sigs instead of list-sigs?
[07:11] <infinity> mvo: Ahh, I see, collision concerns when using the CLI.
[07:13] <mvo> infinity: yeah, thats the core of the problem, that there is no guard against collisions in gpg
[07:13] <infinity> mvo: vorlon's suggestion seems workable, though.
[07:14] <infinity> mvo: As long as you export and verify each new key individually, you can't collide.
[07:14] <infinity> mvo: (if you take the new keyring as a bundle, you have a weird vector as described by mdeslaur)
[07:14] <infinity> mvo: But keys are already signed, I think your wanting to sign the keyring is overengineering. :p
[07:15] <infinity> mvo: You just need to validate each one as an isolated entity.
=== smb` is now known as smb
[07:17] <infinity> mvo: (signing a keyring file that contains a bunch of signed keys is sort of like gzipping a level-9 compressed jpeg, as far as how useless both are)
[07:21] <mvo> infinity: right. overengineering> probably :) and yet the approach is pretty simple and bullet proof. but yeah, I think the individual export/verify is equally good
[07:21] <infinity> mvo: And you still want to switch --list-sigs to --check-sigs in add_keys_with_verify_against_master_keyring(), I suspect.
[07:21] <mvo> indeed
[07:23] <mvo> infinity: hrm, now you made me work on this and I'm not even finished with reading my mail this morning ;)
[07:23] <infinity> *cough*
[07:23] <infinity> I'm a bad man.
[07:23] <infinity> Is it worse if I tell you I'm going to bed now?
[07:24] <mvo> infinity: heh :) it must be like 3am or so for you now?
=== rickspencer3_ is now known as rickspencer3
[08:04] <dholbach> good morning
[08:04] <seb128> hey dholbach
[08:04] <dholbach> salut seb128
[09:17] <maniyadav> hi i'm making an application with quickly. how can i add application in games section with icon. this is my first deb application. please help
[09:31] <maniyadav> Hi all. How to add application to global menu from python code
[09:31] <maniyadav> please help
[09:35] <cjwatson> @pilot in
=== udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cjwatson
[09:35]  * dholbach hugs cjwatson
[09:36] <seb128> cjwatson, hey
[09:37] <seb128> cjwatson, robert_ancell was looking for you, I think he got the infos he needed from talking with pitti but it would be nice if you could check if http://bazaar.launchpad.net/~lightdm-team/lightdm/1.0/revision/1232 address the locale issue you are having
[09:38] <cjwatson> seb128: I doubt it, it'll find en_GB.iso88591 first
[09:38] <cjwatson> "an encoding" isn't good enough.  it needs to actually check locale aliases properly
[09:38] <seb128> pitti, ^
[09:38] <pitti> seb128: yes, that's what I said in #u-desktop
[09:39] <pitti> it should prefer an .utf8, and only fall back to "first match" if there isn't one
[09:39] <cjwatson> why can't it just try the locale that PAM gives it?
[09:39] <pitti> all this is just a rather horrible hack anyway, for a corner case
[09:39] <cjwatson> I can't imagine what possible benefit it gets from rummaging through 'locale -a' output when PAM has already given it a usable locale
[09:39] <pitti> cjwatson: it first tries pam, then falls back to accountsservice/.dmrc, and then to ~/.profile
[09:39] <cjwatson> it should only do this stuff if the locale it gets back from PAM isn't usable
[09:39] <pitti> yes, absolutely
[09:39] <cjwatson> pitti: that's not working
[09:39] <zarlino> I'm trying to package a Qt app. I'd like to depend on Qt>=4.5. I used shlibs:Depends and it automatically adds Qt4.7 to the dependencies. Should I remove completely shlibs:Depends? Should I set the dependencies by hand?
[09:39] <cjwatson> I can see plainly in my log that it gets a locale from PAM and then ignores it
[09:40] <pitti> all this heuristics stuff should only be done if there is no pam locale
[09:40] <cjwatson> well, except for chopping off the codeset and then poking around in 'locale -a' for something that looks similar
[09:40] <pitti> cjwatson: so that seems to be another bug then
[09:40] <cjwatson> pitti: that is this bug, IMO
[09:40] <seb128> ok, shame that robert_ancell left before you joined
[09:40] <cjwatson> I have a perfectly good preconfigured locale that it isn't using any more
[09:41] <cjwatson> [+8.46s] DEBUG: PAM returns environment 'GNOME_KEYRING_CONTROL=/tmp/keyring-JAW17p GNOME_KEYRING_PID=2592 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LANG=en_GB.UTF-8 LANGUAGE=en_GB.UTF-8:en'
[09:41] <cjwatson> [+8.47s] DEBUG: Using locale en_GB for language en_GB
[09:41] <pitti> cjwatson: presumably you have some language setting in your ~/.dmrc?
[09:42] <cjwatson> pitti: http://paste.ubuntu.com/702159/
[09:42] <pitti> (I'm just guessing here, based on the checks that robert mentioned)
[09:42] <sivang> sladen: around?
[09:42] <sivang> (hi all)
[09:43] <seb128> cjwatson, can you check in d-feet, org.freedesktop.Accounts, on your user account, the Language property?
[09:44] <seb128> pitti, ^ I think it uses user account first nowadays
[09:44] <cjwatson> seb128: en_GB
[09:45] <cjwatson> and in "User Accounts" it says "English (United Kingdom) [ISO-8859-1]" - I absolutely never set that
[09:45] <seb128> that seems to be the issue
[09:45] <cjwatson> and there is no option in that combo box for English (United Kingdom) [UTF-8]!
[09:45] <cjwatson> or even just "English (United Kingdom)"
[09:46] <seb128> weird
[09:46] <pitti> not that users should even be concerned about the encoding
[09:46] <cjwatson> sure, but it's given me the _wrong one_
[09:46] <pitti> I noticed that these days we generate the non-UTF8 locales as well
[09:46] <seb128> seems like an accountsservice issue then
[09:46] <cjwatson> pitti: even if we didn't, it would be wrong to assume they weren't there
[09:46] <pitti> in earlier releases we only generated the UTF-8 ones from /usr/share/i18n/SUPPORTED
[09:46] <cjwatson> I've probably generated these ones by hand
[09:46] <cjwatson> because it's useful for me for man-db testing
[09:46] <pitti> cjwatson: yes, true; just mentinoing that this could have uncovered a bug there
[09:47] <pitti> cjwatson: no, I have them as well, and it's a fairly clean install
[09:47] <cjwatson> (or, I mean, I probably would have generated them by hand if they weren't there by default)
[09:47] <pitti> I just noticed it while looking at robert's request; not blaming it for that actual bug
[09:47] <cjwatson> so why do we trust accountsservice over PAM?  it seems poorly-baked
[09:48] <GunnarHj> cjwatson, pitti, seb128: Hi guys!
[09:48] <pitti> I don't think we should
[09:48] <pitti> we even fixed accountsservice to write ~/.profile
[09:48] <sladen> sivang: dates.  Although I am not be in London.  I leave on ~Oct 15th and return on ~Novemeber 6th
[09:48] <seb128> hey GunnarHj
[09:48] <pitti> so there is little reason to not just use that
[09:48] <pitti> it doesn't need to try and craft a locale from that accountsservice value
[09:49] <cjwatson> all the other users on my system have the same broken value for Language
[09:49] <pitti> hey GunnarHj, how are you?
[09:49] <GunnarHj> Just noted that Robert disapproved a suggested fix of cjwatson's bug. I think he is missing something important.
[09:49] <seb128> seems like the redhat guys who worked on accountsservice didn't test it much with non-utf8 locales on the system
[09:50] <seb128> GunnarHj, that's what we are discussing
[09:50] <seb128> GunnarHj,
[09:50] <seb128> <seb128> cjwatson, can you check in d-feet, org.freedesktop.Accounts, on your user account, the Language property?
[09:50] <seb128> <cjwatson> seb128: en_GB
[09:50] <seb128> <cjwatson> and in "User Accounts" it says "English (United Kingdom) [ISO-8859-1]" - I absolutely never set that
[09:50] <seb128>  
[09:50] <seb128> so seems
[09:50] <seb128> - there is a bug in accountsservice that makes it pick the wrong non-utf8 locale
[09:51] <seb128> - there is a bug in lightdm that it prefers the accountsservice locale to the pam one
[09:51] <pitti> ^ or that it uses acccountsservice's one in the first place
[09:51] <pitti> <pitti> we even fixed accountsservice to write ~/.profile
[09:51] <pitti> <pitti> so there is little reason to not just use that
[09:51] <cjwatson> writing .profile is very irritating behaviour incidentally
[09:51] <cjwatson> those are my dotfiles, leave them alone
[09:52] <pitti> but unlike accountsservice language-selector has done that for ages
[09:52] <GunnarHj> Yes, I understand. I think I'm to blame for this confusion. The thing is that the Ubuntu specific patch of accountsservice I wrote sets values like "de" or "es_ES" as the "Language" property, not complete locale names.
[09:52] <pitti> we need to store the user language *somewhere*, and ~/.profile works reasonably well for that
[09:52] <cjwatson> fortunately I have .bash_profile so junk in .profile is ignored
[09:52] <cjwatson> automatically editing shell scripts is crazy
[09:52] <pitti> yes, it is, we just don't have something better
[09:53] <cjwatson> the user language should be set through PAM
[09:53] <pitti> cjwatson: where does PAM take it from, if not from the environment?
[09:54] <cjwatson> there has been a ~/.environment file for years
[09:54] <cjwatson> I think, let me check that assertion
[09:54] <pitti> GunnarHj: ^ interesting
[09:54] <pitti> that indeed sounds a lot better then
[09:54] <cjwatson> wait
[09:55] <pitti> anyway, we won't touch the ~/.profile thing for oneiric
[09:55] <pitti> it has worked reasonably for many years
[09:55] <cjwatson> sorry, ~/.pam_environment
[09:55] <pitti> and for P (gosh, name!) we want to drop language-selector anyway
[09:55] <cjwatson> pam_env.c:#define DEFAULT_USER_ENVFILE    ".pam_environment"
[09:55] <pitti> so in P we should change accountsservice to write to ~/.pam_environment instead of ~/.profile
=== Guest90900 is now known as Hobbsee
[09:56] <pitti> cjwatson: thanks
[09:56] <cjwatson> and if you do that it will actually be consistent across PAM sessions
[09:58] <pitti> cjwatson, GunnarHj: filed bug 866062
[09:58] <ubottu> Launchpad bug 866062 in accountsservice (Ubuntu P-series) "SetLanguage(): Write ~/.pam_environment instead of ~/.profile" [Medium,Triaged] https://launchpad.net/bugs/866062
[09:58]  * cjwatson goes back to being patch pilot as he's supposed to be :)
[09:58] <pitti> but either way, lightdm shoudln't ask accountsservice
[09:58] <pitti> at least not for oneiric yet
[09:59] <GunnarHj> pitti: yes, it should, but there is still an urgent need for a change in lightdm.
[09:59] <pitti> GunnarHj: right; above bug is a side issue, I targetted it to P
[09:59] <seb128> pitti, I'm not sure why robert_ancell did it this way, could you drop a comment in the bug for him or sort it with him tomorrow morning if he's still online?
[09:59] <pitti> GunnarHj: for oneiric's lightdm we should just drop the accountsservice query step IMHO
[10:00] <pitti> seb128: sure
[10:00] <seb128> danke
[10:00] <pitti> seb128: which bug # was that again?
[10:00] <seb128> 864618
[10:01] <GunnarHj> pitti: I'm not sure what you mean, now.
[10:03] <pitti> seb128, GunnarHj: I updated bug 864618
[10:04] <ubottu> Launchpad bug 864618 in lightdm (Ubuntu Oneiric) "UTF-8 locale no longer set" [Critical,In progress] https://launchpad.net/bugs/864618
[10:04] <seb128> pitti, thanks!
[10:05] <GunnarHj> pitti: The set_language() function in src/session.c simply make a mess of the locale settings in Ubuntu.
[10:05] <pitti> GunnarHj: but that part isn't the problem AFAICS
[10:05] <pitti> GunnarHj: it seems lightdm checks the Language property of accountsservice and uses that to override what it got from PAM
[10:06] <pitti> and it shouldn't do that IMHO
[10:06] <seb128> cjwatson, GunnarHj, pitti: btw we should still have an accountsservice bug open about the encoding issue since that's buggy in the g-c-c account capplet
[10:06] <seb128> i.e
[10:06] <seb128>  <cjwatson> and in "User Accounts" it says "English (United Kingdom) [ISO-8859-1]" - I absolutely never set that
[10:06] <GunnarHj> pitti: Maybe that's not the problem cjwatson encountered, but it's the problem I discovered thanks to cjwatson's bug.
[10:06] <seb128> that's orthogonal to the lightdm issue
[10:08] <pitti> so if the accountsservice property is wrong (due to whatever bug), it destroys the locale; and if it is correct, it will not actually change the resulting locale
[10:09] <GunnarHj> pitti, seb128: Right now lightdm overrides LANG with a locale that represents the selected language. It breaks the settings as soon as LANG != LC_MESSAGES.
[10:11] <GunnarHj> seb128: What's the problem you mentioned with the language setting in User Accounts?
[10:11] <seb128> GunnarHj, it's listing an iso locale as being selected and not give the choice to pick an non iso one
[10:12] <seb128> GunnarHj, i.e it's preferring the iso-8859-1 over the utf-8 one for cjwatson
[10:12] <seb128> GunnarHj, where his .dmrc, config, etc are utf-8
[10:13] <GunnarHj> But ... it does not set any locale directly, but lets accountsservice do it. And a-s certainly does not set any non-UTF-8 locale.
[10:13] <seb128> GunnarHj, well it's not "setting", it's what is displayed in the user account ui
[10:14] <GunnarHj> seb128: You don't see the locale name there, do you?
[10:15] <seb128> <cjwatson> and in "User Accounts" it says "English (United Kingdom) [ISO-8859-1]" - I absolutely never set that
[10:15] <seb128> <cjwatson> and there is no option in that combo box for English (United Kingdom) [UTF-8]!
[10:15] <seb128>  or even just "English (United Kingdom)"
[10:15] <seb128> GunnarHj, ^ that's what he wrote before
[10:15] <seb128> cjwatson, sorry for the highlights
[10:15] <GunnarHj> seb128: Weird. Have to take a look.
[10:17] <GunnarHj> seb128: What I see in the User Accounts UI is the output from /usr/share/language-tools/language-options
[10:17] <GunnarHj> i.e. as expected
[10:18] <pitti> but that doesn't output locales
[10:18] <pitti> at least not valid ones
[10:18] <pitti> but language names
[10:18] <pitti> (with country variants)
[10:18] <GunnarHj> pitti, seb128: No, and that's intentional. UA sets language, not locale. :)
[10:18] <pitti> lightdm tries to map that to a valid locale, using a rather hackish heuristics
[10:18] <pitti> GunnarHj: right
[10:19] <pitti> ligthdm iterates through `locale -a` to map that value to a locale, but doing that perfectly is nontrivial
[10:19] <seb128> GunnarHj, not quite, /usr/share/language-tools/language-options doesn't list fr options for me but I've "français (France)" is the ua ui
[10:19] <pitti> so my proposal was to drop that instead of trying to fix it
[10:19] <seb128> and "français" in the list
[10:20] <seb128> ok, sorry guys, I'm creating confusion there
[10:20] <seb128> let's do one issue at the time
[10:20] <seb128> I will let you sort the lightdm issue
[10:20] <seb128> we can discuss the accountsservice,user-account one later
[10:20] <GunnarHj> seb128, pitti: Yes, the lightdm issue is by far the most important right now.
[10:24] <GunnarHj> pitti: How do we proceed? Can you take a look at the MP for bug 864618?
[10:24] <ubottu> Launchpad bug 864618 in lightdm (Ubuntu Oneiric) "UTF-8 locale no longer set" [Critical,In progress] https://launchpad.net/bugs/864618
=== doko__ is now known as doko
[10:28] <pitti> GunnarHj: what does set_language() do?
[10:29] <GunnarHj> pitti: It sets LANG with a locale that represents the language.
[10:29] <pitti> GunnarHj: to what?
[10:29] <pitti> from the "Language" property in accountsservice?
[10:29] <GunnarHj> Yes, it's derived from there.
[10:30] <GunnarHj> And it happens after ~/.profile is sourced.
[10:32] <pitti> GunnarHj: followed up to MP, mostly directed towards Robert
[10:35] <GunnarHj> pitti: Ok, that sounds like valid questions. I'll try to recall the details and get back to you.
[10:37] <pitti> GunnarHj: cheers!
=== abhinav_ is now known as abhinav-
[10:42] <tumbleweed> pitti: is there a known problem with the retracers? (I can't see any related bugs) I just got an aborted oneiric retrace that looks like it was using natty dbgsyms
[10:43] <pitti> tumbleweed: the permanently known one is that dbgsyms keep vanishing, due to the very hackish way we retrieve and publish them
[10:43] <pitti> there is no known acute breakage with them otherwise
[10:46] <tumbleweed> err, yeah, that's it. Thanks
[10:52] <siretart> could anyone please copy sun-java6-jdk from natty-partner to oneiric-partner, please?
=== MacSlow is now known as MacSlow|lunch
=== Guest31871 is now known as gord
[11:01] <dholbach> Riddell, thanks muchly!
=== yofel_ is now known as yofel
[11:07] <jamespage> siretart: thats odd - it was there - I even have it installed
[11:17] <siretart> jamespage: probably from natty-partner?
=== dendro-afk is now known as dendrobates
[11:30] <jamespage> siretart: I don't think so - it have an oneiric version number
[11:32] <siretart> jamespage: interesting
[11:33] <jamespage> siretart: it may be related to the dlj changes that oracle have made - iamfuzz is the guy to ask but he's not around until later
[11:34] <siretart> jamespage: in the mean time, it would be great to have at least the natty package available
=== MacSlow|lunch is now known as MacSlow
[12:30] <jdstrand> so, it seems that almost any time I do an apt-get upgrade, at the end of it all, evolution spouts errors about losing connection to dbus
[12:30] <jdstrand> I have not pinpointed the issue yet
[12:31] <seb128> dobey, SpamapS: is bug #856810 the issue you were discussing yesterday?
[12:31] <ubottu> Launchpad bug 856810 in netcfg (Ubuntu) "Boot hangs at "Booting system without full network configuration..."" [Undecided,Confirmed] https://launchpad.net/bugs/856810
[12:31] <seb128> bug #864174
[12:31] <ubottu> Launchpad bug 864174 in lightdm (Ubuntu) "boot hangs waiting for lightdm after purging gdm" [Undecided,Confirmed] https://launchpad.net/bugs/864174
[12:31] <hrw> is there snapshot.debian.org service for ubuntu? I need gcc-snapshot 20110813 (removed by mistake)
[12:31] <Laney> you can get the old files from launchpad
[12:32] <seb128> jdstrand, there is a gconf bug which has been forwarded upstream where they asked for somebody to add a dbus-monitor log from when having the issue
[12:32] <seb128> jdstrand, if you want to get the info that could be useful
[12:32] <Laney> → changelog → version → [arch] → files produced from this build
[12:32] <Laney> hrw: ^
[12:33] <hrw> thx
=== dendrobates is now known as dendro-afk
[12:34] <jdstrand> seb128: looking for the bug.... can't seem to find it
[12:34] <seb128> jdstrand, it's the first one in the gconf2 list iirc
[12:34] <seb128> ups, gconf
[12:34] <jdstrand> ah, was looking at evo
[12:34] <seb128> bug #848198
[12:34] <ubottu> Launchpad bug 848198 in gconf (Ubuntu) "Sporadic gconf error messages" [High,Triaged] https://launchpad.net/bugs/848198
[12:34] <seb128> i.e https://bugzilla.gnome.org/show_bug.cgi?id=659835
[12:34] <ubottu> Gnome bug 659835 in gconf "Configuration server couldn't be contacted: D-BUS error: Method "Set" with signature "s(ii)" on interface "org.gnome.GConf.Database" doesn't exist" [Normal,Unconfirmed]
[12:35] <jdstrand> that's the one. thanks
[12:35] <seb128> oh, upstream got some new comments
[12:35] <Laney> ah
[12:36] <Laney> that's the same bug we're having with banshee https://bugzilla.gnome.org/show_bug.cgi?id=659841
[12:36] <ubottu> Gnome bug 659841 in general "Hang when GConf can't be called(?)" [Major,Unconfirmed]
[12:36]  * Laney thought it was a problem there
[12:36] <seb128> seems like ross just commented, maybe he will look at it ;-)
[12:36] <Laney> it can cause banshee to go into a cpu death spiral which is pretty unfortunate
[12:37] <jdstrand> ah, well, good then :)
[12:38] <jdstrand> that has been an annoying bug :)
[12:38] <seb128> it is indeed ;-)
[12:47] <pitti> file binary/casper/filesystem.squashfs
[12:47] <pitti> [...] created: Thu May 11 19:57:20 2084
[12:47] <pitti> Welcome to the world of tomorrow!
[12:48] <pitti> the officially built Chinese images are only from 2018, which clearly explains why they are bigger than they should be
[12:53] <pitti> cjwatson: ah, I found out why http://china-images.ubuntu.com/oneiric/daily-live/20111001/ is oversized
[12:53] <pitti> cjwatson: a local build is 690 MB, the official build is 714
[12:53] <pitti> cjwatson: the amd64 squashfs has 98 MB (uncompressed) /var/lib/apt/lists/
=== erward_ is now known as erward
[12:54] <pitti> I didn't check the i386 on
[12:54] <pitti> e
[12:55] <pitti> hm, seems our official images have the apt indexes as well
[12:55] <pitti> although both live-build and ubuntu-defaults-image make an effort to clean them
[12:56] <pitti> cjwatson: does cdimage slide any hook into ubuntu-defaults-image which causes an apt-get update?
[12:58] <pitti> cjwatson: ah, the difference is that our official CDs don't have universe _Packages (only main), while the daily Qin images also have universe; that's a gzip -9 delta of 21 MB
[13:01] <dobey> seb128: yes that's an instance of the bug; i think slangasek and SpamapS got it fixed last night, but don't know if the upload got accepted yet
[13:01] <seb128> dobey, ok
[13:08] <pitti> cjwatson: I followed up to the Qin status mail now
[13:13] <tkamppeter> pitti, how do I proceed with bug 867437, it is a CUPS package install failure but without terminal log.
[13:13] <ubottu> Launchpad bug 867437 in cups (Ubuntu) "package cups 1.4.6-5ubuntu1.4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/867437
[13:14] <cjwatson> pitti: cdimage does not and cannot do anything to the live filesystem build; you can look at livecd-rootfs
[13:15] <pitti> cjwatson: right, that calls apt-get update; I just wonder where the difference between local and cdimage build is
[13:16] <pitti> cjwatson: but anyway, at this point I suspect that the easiest solution would be to promote ubuntu-defaults-zh-cn to main and only build from main/restricted?
[13:16] <mdeslaur> cjwatson: uhm...so openssl security updates won't get the reboot notification anymore?
[13:17] <pitti> mdeslaur: the just accepted openssl update?
[13:17] <pitti> mdeslaur: that removes the notifications for anything _but_ upgrades
[13:17] <pitti> like first-time installs
[13:18] <ogra_> the changelog says that it still is there for "important upgrades"
[13:18] <ogra_> whatever that is :)
[13:18] <pitti> it just moves the notification check into the if [ ! -z "$2" ]
[13:19] <mdeslaur> pitti: let me check that for a sec, I though it was moving it into the major upgrade section ("if dpkg --compare-versions "$2" lt 0.9.8g-9 && dpkg --compare-versions "$2" gt 0.9.8c-4etch3; then")
[13:20] <cjwatson> mdeslaur: I can't understand how it can possibly make sense to nag people with a reboot-required message when we're not taking the effort to restart services we know how to restart
[13:20] <cjwatson> mdeslaur: at any rate it is certainly wrong to emit that message on fresh installs
[13:21] <cjwatson> mdeslaur: if you want to adjust it further, perhaps you could follow up to the bug; the previous state was wrong though
[13:21] <mdeslaur> cjwatson: because we don't want to automatically restart services when their security updates are being installed automatically, but we do want them to schedule their service restarts themselves, as it means they're running stuff with the insecure openssl
[13:21] <cjwatson> pitti: it does move it into the major upgrade section
[13:21] <cjwatson> mdeslaur: it would really, really, REALLY help if there were some COMMENTS about this
[13:22] <cjwatson> it is inscrutable
[13:22] <mdeslaur> cjwatson: agreed
[13:22] <cjwatson> and finding previous wrong code did not fill me with confidence that anyone had actually known what they were doing
[13:22] <cjwatson> so please do fix it up :-)
[13:23] <highvoltage> sabdfl_: howdy! It's getting to that point in the release where people have to say "P" or "Oneiric+1" way too much :)
[13:23] <SpamapS> dobey: have you updated your laptops yet? I think the change to upstart that Steve uploaded yesterday fixes your issues.
[13:23] <dobey> SpamapS: is it accepted/in-archive yet?
[13:23] <cjwatson> mdeslaur: so it sounds like moving it inside [ ! -z "$2" ] but not inside dpkg --compare-versions blah makes sense
[13:24] <SpamapS> dobey: yes
[13:24] <mdeslaur> cjwatson: yes, that's what I'll do, and I'll add some comments
[13:24] <dobey> SpamapS: and only one laptop is hitting that issue; the other laptop is a different problem, and network doesn't seem to work at all on it
[13:24] <cjwatson> thanks
[13:24] <SpamapS> dobey: that may be related
[13:24] <SpamapS> dobey: though I'd be curious to hear what the other issues
[13:24] <SpamapS> s/issues/issue is/
[13:25] <dobey> SpamapS: my other laptop boots up and i can log into gnome from lightdm and everything, but it just asays "Networking disabled" in the nm applet
[13:25] <seb128> SpamapS, hey
[13:26] <SpamapS> dobey: oh, that does sound different.
[13:26] <seb128> SpamapS, is the the issue slangasek fixed similar to bug #864174
[13:26] <ubottu> Launchpad bug 864174 in lightdm (Ubuntu Oneiric) "boot hangs waiting for lightdm after purging gdm (wrong default-display-manager)" [High,Confirmed] https://launchpad.net/bugs/864174
[13:27] <seb128> dobey, could you check on that one if ck-list-sessions lists your session active or not?
[13:27] <dobey> SpamapS: ifconfig shows all the interfaces though
[13:27] <dobey> seb128: on the no-network one?
[13:30] <seb128> dobey, yes
[13:31] <dobey> ok, in a minute
[13:33] <dobey> SpamapS: rebooting now with the upstart update
[13:36] <superm1> infinity, is there an armel PPA that can be used for test builds to see if things will compile properly on armel?
[13:36] <superm1> er a way to get a PPA activated for an account for that
[13:37] <dobey> SpamapS: hrmm, well i don't seem to get the network messages now
[13:37] <dobey> SpamapS: but alas, it just sits at the splash screen
[13:38] <SpamapS> dobey: and on tty1/tty7 ?
[13:39] <SpamapS> dobey: also try pgdn on the splash
[13:39] <dobey> i could switch to tty[1-6] and log in, and sudo service lightdm start
[13:40] <seb128> dobey, so the bugs I pointed before
[13:40] <seb128> dobey, #864174 mentioned issues on wrong /etc/X11/default-display-manager  content
[13:40] <seb128> dobey, what do you have in that file?
[13:41] <seb128> dobey, otherwise the other one has a comment saying that "Manual symlink of /var/run->/run and /var/lock-/run/lock fixed my issues."
[13:41] <dobey> it was "lightdm" last i looked
[13:41] <seb128> dobey, change it to "/usr/sbin/lightdm"
[13:41] <seb128> dobey, that seems the same issue
[13:41] <seb128> "This is because /etc/X11/default-display-manager ends up saying "lightdm" whereas /etc/init/lightdm.conf accepts "/usr/bin/lightdm" or "/usr/sbin/lightdm". The user sees the splash screen messages "Waiting for up to 60 more seconds for network configuration" and "Booting system without full network configuration"."
[13:41] <seb128> dobey, ^
[13:41] <seb128> dobey, it started working when set to /usr/sbin/lightdm for that user
[13:43] <dobey> what does having foo.dpkg-tmp mean?
[13:44] <dobey> seb128: i have a default-display-manager.dpkg-tmp which has "/usr/sbin/lightdm" in it; so clearly something broke on apt-get upgrade to cause this
[13:45] <cjwatson> dobey: sudo dpkg --configure -a
[13:45] <dobey> cjwatson: didn't fix it
[13:45] <cjwatson> that's usually a backup link from the previous version which hasn't been cleaned up yet because the new package hasn't been configured
[13:46] <cjwatson> ... actually, no, it happens when *unpacking* the new version was interrupted
[13:46] <cjwatson> so repeat the upgrade
=== Chipzz_ is now known as Chipzz
[13:47] <cjwatson> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[13:47] <dobey> hrmm, dpkg -S says nothing owns default-display-manager
[13:47] <cjwatson> probably not, it's shared among multiple packages so I expect it's probably handled by maintainer scripts
[13:47] <tjaalton> stgraber: ping, is there a way to prevent arkose from "crashing" when I hit ctrl-c?
=== dendro-afk is now known as dendrobates
[13:48] <cjwatson> in that case I have no idea why there'd be a .dpkg-tmp version of it
[13:48] <cjwatson> perhaps an old bug
[13:49] <stgraber> tjaalton: ? it doesn't seem to crash here, what part of arkose are you using? arkose / arkose-gui / arkose-wrapper-gui? and with what parameters?
[13:49] <tjaalton> stgraber: the snippet you blogged about, sudo arkose -n -h -c "cd $PWD; $SHELL"
[13:49] <seb128> dobey, nothing owning it is normal, it's created by the maintainer scripts
[13:49] <dobey> dpkg-reconfigure lightdm prints two warnings about missing env variables for dpkg-maintscript-helper
[13:50] <tjaalton> stgraber: using zsh if it matters
[13:50] <seb128> dobey, that's bug #706354
[13:50] <ubottu> Launchpad bug 706354 in lightdm (Ubuntu) "dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing" [Low,Triaged] https://launchpad.net/bugs/706354
[13:50] <stgraber> tjaalton: can you try starting bash instead?
[13:50] <tjaalton> stgraber: hum yeah, doesn't fail with bash
[13:51] <tjaalton> i get "zsh: error on TTY read: I/O-error"
[13:51] <dobey> seb128: hrmm
[13:52] <dobey> and lightdm.postinst only mucks with default-display-manager if the file doesn't exist
[13:52] <dobey> so i wonder how it got broken :(
[13:53] <stgraber> tjaalton: reproduced it. I'll see how I can try to handle that without breaking anything else... Can you file a bug against arkose?
[13:53] <tjaalton> stgraber: yep, will do
[13:53] <dobey> seb128: i deleted the default-display-manager and .dpkg-tmp file, and reconfigured lightdm, and now it boots up into lightdm fine
[13:54] <seb128> dobey, ok, so you got bug #706354
[13:54] <ubottu> Launchpad bug 706354 in lightdm (Ubuntu) "dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing" [Low,Triaged] https://launchpad.net/bugs/706354
[13:54] <dobey> oh joy, no unity
[13:54] <tjaalton> stgraber: and thanks, I'll use bash in the meantime :)
[13:54] <dobey> seb128: yes i definitely got that bug
=== kentb-out is now known as kentb
[13:58] <dobey> oh lovely
[13:58] <dobey> logged in, no unity; only a global menubar for nautilus; got a crash dialog about nautilus, clicked report; said the bug was already reported and would be in the browser; clicked ok, and i got a black screen with a mouse cursor i can't move
[13:59] <dobey> fun times :(
[14:00] <dobey> frozen solid system, but power button did the normal shutdown magic
[14:00] <ScottK> Good thing we aren't close to release ...
[14:00] <ScottK> :-(
[14:03] <Galantus> yo yo yiggity yo
[14:03] <Galantus> newb alert
[14:04] <didrocks> dobey: if you still reproduce it, can you please check in tty1 if ~/.xsession-errors isn't owned by root?
[14:04] <didrocks> dobey: that's one of the issue the lightdm upload was fixing
[14:06] <dobey> didrocks: nope, they aren't
[14:06] <didrocks> dobey: you have the compiz crash file then?
[14:07] <didrocks> (nautilus crashing nowdays seem to be trigger by u1 btw)
[14:16] <dobey> didrocks: i don't think compiz crashed. i think unity failed to load. there's no compiz crash file, and the apport dialog had window borders
[14:17] <didrocks> dobey: hum, interesting, can you pastebin ~/.xsession-errors?
[14:17] <didrocks> dobey: if a plugin fail to load, it normally makes compiz crash
[14:20] <dobey> didrocks: "unity-panel-service: no process found" is probably the only interesting message in it that i can see
[14:22] <didrocks> dobey: can you pastebin it?
[14:22] <didrocks> still, better than I can get the full context
[14:27] <dobey> and nautilus prints a billion criticals :-/
[14:29] <dobey> didrocks: https://chinstrap.canonical.com/~dobey/xsession-errors
[14:30] <didrocks> dobey: waow, that's really weird, unity started but you got nothing on screen?
[14:33] <bdmurray> cjwatson: can you mark some merge proposals as rejected or so?
[14:34] <dobey> didrocks: well my machine froze so i rebooted it and unity started fine now
[14:34] <cjwatson> bdmurray: yes
[14:34] <dobey> didrocks: but i have had it not come up a couple times
[14:34] <bdmurray> https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/blobby/833458-Spelling-Grammar-Fix/+merge/72817
[14:34] <cjwatson> I wish LP would fix that bug
[14:34] <bdmurray> https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/btanks/834098-Spelling-Grammar-Fix/+merge/72957
[14:34] <bdmurray> https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/biniax2/834199-Spelling-Grammar-Fix/+merge/72971
[14:34] <bdmurray> https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/alien-arena/834369-Spelling-Grammar-Errors-Fix/+merge/72985
[14:34] <didrocks> dobey: but your .xsession-errors is from the frozen ui launch, isn't it?
[14:34] <bdmurray> https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/extcalc/842339-Spelling-Error-Fix/+merge/74156
[14:34] <bdmurray> cjwatson: those 5 please
[14:35] <dobey> didrocks: it's both afaik
[14:35] <dobey> didrocks: does it get overwritten every time i log in?
[14:35] <didrocks> dobey: both?
[14:35] <didrocks> dobey: yeah
[14:35] <dobey> oh, then it's from a working session
[14:35] <didrocks> ok, makes sense :)
[14:35] <dobey> since i'm logged in now and it works
[14:36] <didrocks> if you get a frozen session, then please tty1, and pastebin it
[14:38] <cjwatson> bdmurray: done
[14:41] <dobey> didrocks: well, i couldn't switch to tty, since keyboard was also frozen; but i'll get an errors file from the broken unity session next time
[14:41] <dobey> huh
[14:42] <dobey> the top panel bit on the unlock screen is gone now
[14:42] <didrocks> dobey: thanks! (seems your issue is more serious than unity itself, I bet for a root .xsession-errors from lighttdm)
[14:42] <didrocks> dobey: yeah, it was patch to not look "gnome-shell like" in august AFAIK
=== dendrobates is now known as dendro-afk
[14:43] <dobey> …
[14:50] <bdmurray> cjwatson: I think part of why he wanted to capitalize the description in the control file is because he was looking at packages in software center and it seems to be inconsistent there
[14:50] <cjwatson> then that's a software-center bug
[14:51] <cjwatson> if it's out of step with the recommended way to write the synopsis ...
[14:51] <bdmurray> right of course
[14:51] <cjwatson> if the presentation in s-c is such that it needs it in sentence-case, it should sentence-case it itself
[14:51] <cjwatson> or rearrange so that that's not needed
[14:52] <cjwatson> but, I want to stop Paul from making things worse :)
[14:54] <bdmurray> mpt: is there a bug about inconsistent capitalization of software descriptions in software center?
[14:56] <mpt> bdmurray, there are bug reports about the descriptions of various packages. <https://bugs.launchpad.net/ubuntu/+bugs?field.tag=metadata> I don't know that any of them are about capitalization specifically.
[14:57] <bdmurray> mpt: it seems to me that the one-line description of packages sometimes starts with a capital letter and sometimes doesn't
[15:00] <mpt> bdmurray, maybe lintian or something should nag people who start it with a word that doesn't contain an upper-case letter
[15:01] <bdmurray> mpt: where does that come from?
[15:01] <mpt> ah, good point
[15:01] <mpt> It's the .desktop file for packages that have one, the synopsis (first line of the Description) for those that don't
[15:01] <mpt> bdmurray, https://wiki.ubuntu.com/SoftwareCenter#software-summary
[15:02] <bdmurray> mpt: cjwatson pointed out that the synopsis shouldn't have capitalization in it
[15:02] <bdmurray> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis
[15:02] <bdmurray> it'd seem to me that software center could title the synopsis if necessary
[15:02] <mpt> huh
[15:02] <mpt> I wonder why
[15:03] <cjwatson> because not using sentence case there allows strictly more flexibility - you can use it in the middle of a phrase, and things that need it in sentence case can title() it
[15:03] <cjwatson> it doesn't work the other way round
[15:04] <maco> fancy
[15:04] <mpt> cjwatson, is there software that uses it in the middle of a phrase?
[15:04] <cjwatson> mpt: I don't know, but it would not surprise me
[15:04] <cjwatson> mpt: anyway I'd counsel against trying to swim against the current here; it sounds like a lot of faff compared with a one-line software change
[15:05] <mpt> ok, if Debian won't go to the mountain ...
[15:07] <mpt> On the other hand, having an uncapitalized summary is a subtle hint that "this here is a geeky package"
[15:07] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516436 is the source of the current wording, although the general sense of the advice predates that
[15:07] <ubottu> Debian bug 516436 in developers-reference "6.2.2: talks nonsense about "appositive clauses"" [Normal,Fixed]
[15:09] <mpt> But on the other other hand, fonts etc will never have .desktop files, and they should still have decent titles
[15:12] <cr3> barry: quick python question for you: raise Exception("Foo: %s" % bar) returns an unprintable error unless I do bar.encode("utf-8"). I don't think I should have to encode unicode variables when raising exceptions though :(
[15:13] <barry> cr3: is the exception getting caught or is it propagating to the eval loop?  the encoding error is probably happening when the exception is printed rather than when it's raised
[15:14] <cr3> barry: it's probably getting caught and passed to logging.exception
[15:15] <tkamppeter> pitti, hi
[15:15] <barry> cr3: so then logging is raising the encoding exception when it tries to print it (probably to an ascii log file or something)
[15:15] <cr3> barry: another solution would be to use %s instead of %r, but that looks pretty ugly in the output: u"foo\xa0bar"
[15:15] <cr3> barry: what might be the right way to handle this?
[15:15] <cr3> err, %r instead of %s, I mean
[15:16] <cr3> barry: maybe I need to register a formatter with the logger to expect unicode strings
[15:17] <barry> cr3: interestingly, i found this: http://stackoverflow.com/questions/1545263/utf-8-in-python-logging-how
[15:19] <barry> cr3: which makes me think (without seeing your full code example) that you just need to get the encoding argument into the FileHandler
[15:20] <barry> cr3: it does not look like logging.basicConfig() has an option for this
[15:21] <slangasek> pitti: upower reuploaded, thanks
[15:21] <mpt> bdmurray, cjwatson: I updated the spec <https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=585&rev1=584> and reported bug 867588. Thanks for the suggestion.
[15:21] <ubottu> Launchpad bug 867588 in software-center (Ubuntu) "Title and summary are capitalized if from .desktop but not if from package synopsis" [Undecided,New] https://launchpad.net/bugs/867588
[15:21] <slangasek> bdmurray: ok, I'll see if I can work out how to keep this text from being written to the console then
[15:22] <cjwatson> mpt: thanks
[15:22] <cr3> barry: oddly, FileHandler has the argument but StreamHandler doesn't
[15:23] <barry> cr3: indeed.  i wonder if there are any open bugs on that.  but it does sound like you will have to write your own handler
[15:24] <barry> cr3: gotta run out now for lunch, but i'll be back later
[15:24] <bdmurray> slangasek: I can test again if necessary
[15:25] <slangasek> bdmurray: those messages are both from sysvinit-style init scripts, so it definitely gives me a place to start looking
[15:25] <cr3> barry: I'm trying something like: codecs.getwriter("utf-8")(log_stream)... anyways, good to know it seems like a real problem
[15:57] <lool> Would someone be so kind to reject logcheck in lucid-proposed?  (I have another patch to include)
[15:57] <lool> (the one in hardy-proposed is fine)
[16:03] <seb128> lool, https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=logcheck
[16:03] <seb128> it's not there?
[16:03] <ogra_> i think i saw it on -changes already
[16:06] <slangasek> smoser: when the infrastructure was upgraded (bug #833783), did that mean any changes to the 'console=' arguments being passed?
[16:06] <ubottu> Launchpad bug 833783 in udev (Ubuntu Oneiric) "boot failure: can't open /root/dev/console: no such file" [High,Confirmed] https://launchpad.net/bugs/833783
[16:13] <lool> ogra_: the oneiric one went through
[16:13] <lool> seb128: Hmm I wonder what happened
[16:13] <ogra_> Betreff: 	[ubuntu/lucid-proposed] logcheck 1.3.7ubuntu2 (Accepted)
[16:13] <ogra_> Datum: 	Tue, 04 Oct 2011 05:37:13 -0000 (04.10.2011 07:37:13)
[16:13] <ogra_> lool, ^^^
[16:13] <lool> ogra_: actually you're right
[16:13] <lool> ogra_: I see it on lucid-changes too
[16:13] <ogra_> else that would be a bad bug in evo :)
[16:14] <ogra_> (secretly generating changes mails or so)
[16:14] <lool> seb128: nevermind, it's already in -proposed, sorry about the noise  :-)
[16:14] <lool> I missed the accepted email for some reason, must be sleeping
=== beuno is now known as beuno-lunch
[16:18] <cr3> pitti: quick apport question you probably know on top of your head: does apport tag bugs with regression-proposed automatically when running a proposed kernel?
[16:32] <didrocks> slangasek: well, strictly speaking, the update-notifier upload isn't mandatory
[16:32] <didrocks> slangasek: we have update-notifier icons showing in unity and unity-2d, without the big icon bug
[16:32] <slangasek> didrocks: that depends on whose mandate we're following ;)
[16:33] <didrocks> I don't see how having indicator is mandatory, in that case, we should mandate all applications that we whitelist by default :)
[16:33] <slangasek> I don't want update-notifier to be setting a bad precedent for other software
[16:33] <slangasek> the *only* other stuff currently in the whitelist is stuff we can't change
[16:34] <didrocks> slangasek: scp-dbus-service ? (I don't really know this one)
[16:34] <didrocks> slangasek: and for java, we can ask the dx team to provide indicator support/bindings for java apps
[16:34] <didrocks> wine apps are exceptions though, agreed
[16:35] <slangasek> I don't know what that scp-dbus-service is either
[16:35] <slangasek> for java, providing the bindings doesn't ensure things will use it
[16:35] <slangasek> and some of the java stuff is again closed-source
[16:35] <didrocks> slangasek: well, same story for python, qt, C… :)
[16:36]  * didrocks still doesn't like this whitelist idea, it's not in forcing people that we achieve this goal, it's by giving them extra bounties in using our API
[16:42] <kees> 818177 is exciting
[17:16] <seb128> lool, no worry ;-)
=== beuno-lunch is now known as beuno
[17:30] <slangasek> kees: 818177> are you able to reproduce it? :P
[17:32] <kees> slangasek: I haven't tried, I'm afraid of it. :)
[17:32] <kees> slangasek: when did the udev kill vs --exit thing change?
=== Quintasan_ is now known as Quintasan
[17:36] <slangasek> kees: no idea
[17:43] <adam_g> kees: looks like it changed in udev 171-0ubuntu4 / Tue, 28 Jun 2011, to resolve http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624469
[17:43] <ubottu> Debian bug 624469 in udev "Fails to start: failed to bind control socket (address in use)" [Serious,Fixed]
[17:44] <kees> adam_g: hmpf
[17:45] <kees> slangasek, adam_g: ok, so I haven't been able to reproduce in the maybe 10 times I've rebooted since then.
[17:45]  * adam_g just hit it
[17:48] <adam_g> id be happy to poke at anything you think might of interest, tho the wifi here is bad.
[18:12] <stgraber> slangasek: for bug 813065, do you think http://paste.ubuntu.com/702368/ would be enough? It seems to work here (when changing ubiquity-dm from break=bottom)
[18:12] <ubottu> Launchpad bug 813065 in casper (Ubuntu Oneiric) "Live session switches to VT console briefly" [High,Confirmed] https://launchpad.net/bugs/813065
[18:13] <soren> doko: Wrt user-mode-linux.. I'm having trouble getting it to build on i386. amd64 works great. I guess that's better than ftbfs'ing entirely. :-/
[18:13] <slangasek> stgraber: don't we really want 'clear' rather than 'reset'?
[18:13] <stgraber> slangasek: actually, clear should be enough, no need to do a full reset of the console
[18:13]  * slangasek nods
[18:13] <doko> there also is clear_console
[18:14]  * slangasek digs into the code for context
[18:14] <doko> soren, sure, better than nothing
[18:14] <slangasek> doko: overkill, I think
[18:15] <stgraber> doing another test run with "clear", if I don't see any upstart messages during the switch, I'll push that
[18:17] <slangasek> stgraber: you seem to be clearing the screen after the X server has exited; we should do it before
[18:17] <slangasek> (just in case the X server is slow to return after switching to text mode)
[18:29] <stgraber> slangasek: hmm, I don't seem to be able to consistently reproduce that bug in a VM, so I'm not sure the fix actually works... I'll push it anyway as it doesn't seem to cause any harm and will ask for confirmation in the bug once uploaded.
=== Beret is now known as Dean
[18:34] <slangasek> stgraber: you can't reproduce it /at all/?  I would expect it to be racy, but not unreproducible
[18:37] <stgraber> slangasek: I saw it once on around 20 tries, so can't really know if the fix works or if I'm just lucky
[18:37] <slangasek> ah
[18:39] <stgraber> I'll try with another virtual video card, maybe that'll make a difference
[18:41] <niclas> Hi, if I need help to report a bug is this the place to ask? Or should I ask in a different room maybe? Don't know which package to file the bug against.
[18:42] <slangasek> niclas: we can help with that, go ahead and ask
[18:44] <niclas> Ok, I have a nfts drive connected with USB. I noticed that if a try to safely remove the disk when a program has a file on the disk open, the system freezes and a hard reboot is the only way to recover
[18:45] <niclas> And i'n running oneric
[18:45] <niclas> So, is it gvfs, ntfs-3g, kernel maybe?
[18:45] <maco> does alt+sysrq+b reboot the machine? if so, then i think thatd knock kernel off the list
[18:46] <maco> other bit to test would be mounting it with ntfs-3g manually (like on the command line) instead of through gnome, to try to rule out gvfs
[18:47] <maco> niclas: ^ do those suggestions for testing make sense?
[18:47] <niclas> Okay, well alt+sysrq+b does not help
[18:47] <niclas> the num lock light does not react when I'm pressing num lock either if it is to any help
[18:47] <niclas> yes it makes sence
[18:47] <maco> is it in that state right now?
[18:48] <maco> (if no and that sounded silly, its possible you have two computers)
[18:48] <niclas> Frozen? No it runs just fine right now
[18:48] <niclas> And yes, only one computer
[18:49] <slangasek> maco: that doesn't eliminate it being a kernel problem.
[18:49] <slangasek> but if it's locked up that hard, it clearly *is* a kernel problem
[18:49] <maco> slangasek: not responding to magic sysrq does seem to implicate the kernel or an errant module, in my mind
[18:49] <slangasek> yes
[18:50] <slangasek> but being able to reboot with SysRq+b isn't proof that it's *not* a kernel bug :)
[18:50] <maco> slangasek: fair enough
[18:50] <slangasek> niclas: so, please file the bug against the kernel
[18:50] <niclas> Okay, I will! Thanks
[18:50]  * maco makes note that sometimes a stupid kernel will still sysrq
[18:54] <slangasek> bryceh: hum, fortunately the application of the patch from bug #535172 seems to have been a no-op, because upstart already ships its own completion file...
[18:54] <ubottu> Launchpad bug 535172 in bash-completion (Ubuntu) "Bash completion for upstart" [Wishlist,Fix released] https://launchpad.net/bugs/535172
[19:16] <niclasl> slangasek, maco: Still there? I've done some testing now and I found that it has nothing to do with open files. If I let gvfs mount the disk and then tries to safely remove it, the system crashes even if it is the first thing I do after I log in. If I choose "unmount" instead of "safely remove", or if I manually mount and unmount the disk there is no crash
[19:16] <infinity> siretart: Your logrotate patch makes no sense.
[19:16] <niclasl> Is the kernel still the package I should file against?
[19:17] <infinity> siretart: Exiting the cronjob if there's no status file means you never create a status file.
[19:17] <infinity> siretart: So, ultimately, logrotate would never run.
[19:19] <siretart> infinity: so the first run is *expected* to throw some error? - anyway, point taken, I'll change that to create an empty file if it doesn't exist. ok?
[19:20] <infinity> siretart: A touch would work, perhaps, sure.  Just remove the status file (on a system you don't much care about logrotate consistency on) and actually test the cronjob a few times? :)
[19:21] <siretart> on my way
[19:22] <infinity> siretart: Actually, the status file MIGHT be created by logrotate.
[19:22] <infinity> siretart: If that's the case, then just wrapping the whole cleanup thing in a [ -e status ] would work.
[19:23] <infinity> siretart: But yeah.  Please investigate.  I'm not sure what the right solution is, I'm just positive that it's not "disable the cronjob entirely". ;)
[19:23] <siretart> infinity: I've now implemented the 'touch' suggestion, and it does the right thing on my laptop
[19:23] <maco> niclasl: if the kernel's wedging, id say yes
[19:24] <siretart> infinity: thanks for the review, I'll upload in a minute
[19:24] <maco> niclasl: someone from the kernel team will be able to sort out more particularly whats going wonky in the kernel
[19:25] <niclasl> maco: okay, thanks
[19:34] <bryceh> slangasek, done
[19:37] <dobey> hrmm; is it not possible to have a -dbg package defined in control, and also avoid having an install file?
[19:41] <slangasek> bryceh: the patch got added right back in via debian/patches/debian-changes-1:1.3-1ubuntu6 in this upload
[19:41] <slangasek> (so, rejecting)
[19:42] <slangasek> dobey: for a source package building only two binary packages (one of them the -dbg), I would expect that to work with dh_strip --dbg-package=foo-dbg
[19:44] <dobey> slangasek: hrmm; so i'm using cdbs; would i need to add that to the rules file in some way to make it DTRT in this case?
[19:44] <slangasek> dobey: you probably need to trick cdbs into doing that, but I don't know how
[19:45] <bryceh> slangasek, crap one sec
[19:46] <bryceh> bash-completion's packaging is annoying
[19:47] <bryceh> slangasek, it automatically adds this debian-changes file during debuild; is there a way to stop it from doing that?
[19:50] <slangasek> bryceh: run 'quilt unpatch' in the source package before removing the patch file from debian/patches
[19:51] <slangasek> (dpkg source v3 says all patches are applied at source unpack time, and any changes found outside debian/ at source build time get shoved into a new patch file)
[19:53] <infinity> siretart: Dude...
[19:53] <infinity> siretart: Your changelog still claims the cronjob works the old way. :)
[19:54] <bryceh> slangasek, hmm, 'quilt unpatch' just returns a usage message
[19:55]  * bryceh quilt pops
[19:55] <infinity> siretart: On the other hand, I'm having fun pressing the reject button, so that's pretty neat. ;)
[19:55] <slangasek> bryceh: right, that's what I meant, sorry :)
[20:02] <bryceh> slangasek, done
[20:07] <dobey> slangasek: hmm, found some clue to use DEB_DH_STRIP_ARGS, but adding the --dbg-package=foo-dbg didn't seem to work :-/
[20:08] <slangasek> dobey: pointer to the package?
[20:09] <dobey> slangasek: lp:ubuntu/ubuntuone-client-gnome
[20:10] <slangasek> dobey: ok.  why are the autogenerated .ddebs not sufficient for debugging, btw?
[20:11] <slangasek> (you know that all packages in main have symbols split off automatically in the archive and dropped to ddebs.ubuntu.com?)
[20:11] <dobey> slangasek: i think they are. i just want to get rid of the debian/install file
[20:11] <slangasek> oh
[20:12] <dobey> and i also want to do this for our nightlies packages, so we'd have to build the -dbg there anyway since we don't get auto-ddebs magic for being in main with those
[20:12] <slangasek> right
[20:12] <dobey> but if i just remove the debian/install file and rebuild, the package is empty :(
[20:13] <slangasek> dobey: if I can replace your debian/rules with a shorter dh(1) rules file that does the right thing, would you take it? :-)
[20:13] <dobey> slangasek: for ubuntu proper i don't care much in that regard, but i don't think we can do that for our nightlies builds
[20:14] <slangasek> why not?
[20:15] <slangasek> if nightly builds have a dependency on cdbs, then somebody's doing it wrong :P
[20:16] <dobey> because using pure dh would mean making a much longer rules file than with cdbs, and i don't really feel like reimplementing a bunch of what cdbs does, just to use pure dh
[20:17] <dobey> slangasek: for some other packages we could, but for things using autotools, it's not so easy :)
[20:17] <slangasek> dobey: huh?
[20:17] <micahg> dh_autoreconf?
[20:17] <slangasek> what is cdbs doing here that dh isn't?
[20:17] <dobey> micahg: no.
[20:17] <dobey> slangasek: DEB_CONFIGURE_SCRIPT = $(CURDIR)/$(DEB_SRCDIR)/autogen.sh
[20:18] <slangasek> dobey: oh - I don't see that in the branch you pointed me to, I guess that's only in the nightly build branch?
[20:18] <dobey> slangasek: right, because we don't need to run autogen.sh for tarball releases; but we do for building from bzr trunk
[20:18]  * slangasek nods
[20:19] <slangasek> well, it might be longer then, but not *much* longer
[20:19] <dobey> which is why i said i'm not fussed about the ubuntu branch, but the nightlies one i am :)
[20:19] <slangasek> besides which, the reason we're having this conversation is that cdbs isn't working ;)
[20:19] <dobey> and either way, dh_strip doesn't seem to be the solution to this problem
[20:21] <slangasek> no, I think the problem is something particular to cdbs
[20:35] <slangasek> dobey: DEB_DESTDIR = $(CURDIR)/debian/ubuntuone-client-gnome
[20:36] <slangasek> dobey: not a cdbs-specific problem after all, it's deeper than that - debhelper in fact
[20:36]  * infinity wonders idly why "apt-cache show libc6" gives long descriptions, but "apt-cache show libc6:i386" doesn't.
[20:36] <slangasek> when debian/control lists one binary package, debhelper will do everything in debian/tmp and there's no need to use dh_install at all
[20:37] <infinity> slangasek: Do you know enough about apt multiarch internals to grok why we're only getting long descriptions for the dpkg arch?
[20:37] <slangasek> when debian/control lists more than one binary package, the install target still aims at debian/tmp by default, but dh_install with no arguments doesn't know what bits you want copied where - even when one of the packages is a -dbg package
[20:37] <slangasek> dobey: so try as I might, I can't blame this one on cdbs ;)
[20:37] <slangasek> infinity: not that part of it, no
[20:38] <dobey> slangasek: thanks! that does seem to work. :)
[20:51] <slangasek> stgraber: oh man, hilarious - when testing on nouveau, I *never* get a console switch to text between ubiquity-dm and lightdm; on intel, I *always* do...
[20:52] <stgraber> slangasek: guess what I've been using for testing :)
[20:52] <slangasek> nouveau, by chance? :)
[20:52] <slangasek> never get a console switch> I know this because the X cursor stays on the screen the whole time
[20:53] <stgraber> yeah, Lenovo R61 with nvidia quadro
[20:53] <slangasek> we should still be clearing the console regardless
[20:53] <stgraber> can you check that the call to "clear" does what it's supposed to?
[20:53] <slangasek> but it means I'll have even more fun teasing keithp tonight
[20:53] <slangasek> stgraber: still working on validating that
[20:54] <slangasek> stgraber: btw, it's not "upstart messages" at issue here, but "boot-time messages" (these don't come from upstart at all)
[20:54] <slangasek> I was going to fix the comment up, but maybe you'll beat me to it
[20:56] <stgraber> slangasek: updated
[20:57] <slangasek> cheers :)
[20:58] <stgraber> slangasek: I'm ready for an ubiquity upload. Tested current trunk on ubuntu, xubuntu and kubuntu. Just let me know when you're done testing the ubiquity-dm change and if it works, I'll upload.
[20:58] <slangasek> stgraber: ack
[21:17] <Heimi> hi, does someone know howto create a (Python-based) Indicator, that directly reacts on a click on the icon (means that does not have menus)
[21:18] <RAOF> Heimi: I believe the answer is: you don't, because that's a design anti-goal for indicators.
[21:20] <Heimi> @RAOF: well, I think that I understand the goals somewhat - but to just have an Indicator  "Lock button" I think a menu is overkill
[21:20] <udevbot_> Error: "RAOF:" is not a valid command.
[21:22] <RAOF> Heimi: There's already a lock button under the power indicator - just above ?Log out?
[21:24] <Heimi> yes, I know that (and would usually say that this is sufficient), but a client asked (unfortunately) for a separate button
[21:24] <Heimi> I think that this can also be helpful for other scenarios - think about the old "force quit" Gnome2 bonobo applet ...
[21:25] <ScottK> What an error message: "Something wicked happened resolving 'archive.ubuntu.com"
[21:25] <stgraber> ScottK: what gave you that? :)
[21:25] <ScottK> apt-get source.
[21:26] <ScottK> The rest of the error was: http' (-5 - No address associated with hostname)
[21:33] <RAOF> Heimi: Would a button on the launcher work?  It wouldn't be hard to whip up a .desktop file to lock the screen.
[21:34] <Heimi> RAOF: yes, also thought about that - seems to be the only possible / workable solution ... and this is an easy one - just creating a .desktop file
[21:53] <slangasek> stgraber: I have the distinct impression that interrupting the initramfs to make my changes to ubiquity-dm is permuting the boot in such a way that I get no messages on the console P
[21:53] <slangasek> :P
[21:55] <sladen> h
[21:56] <bryceh> slangasek, hey do you know if there's a command line tool that'll retrieve the .dsc for a given source package name from Debian unstable
[21:56] <slangasek> bryceh: apt-get source + chdist?
[21:56] <ion> I just have deb-src for unstable and experimental in my sources.list. :-)
[21:56] <micahg> bryceh: pull-debian-source
[21:57] <slangasek> or that ^^
[21:57] <Laney> pull-debian-
[21:57] <Laney> yeah
[21:57] <bryceh> ok will try (yeah I was poking at chdist)
[21:58] <bryceh> micahg, perfect, thanks
[21:59] <micahg> bryceh: you're welcome
[21:59]  * micahg also happens to be able to do apt-get source -t unstable foo, but not everyone needs to deb-src entries
[22:04] <slangasek> stgraber: ok, tested and this clear command is *not* sufficient
[22:04] <slangasek> stgraber: I think we need to redirect clear's stdin/stdout to the X VT
=== jjohansen is now known as jj-afk