[00:00] <superm1> wasabii, bug 261977 possibly?
[00:00] <wasabii> nv isn't even chosen. xorg.conf just claims no devices
[00:02] <wasabii> will give te vesa thing a try
[00:06] <wasabi> Hmm. that fix thing just reruns dpkg-reconfigure
[00:06] <wasabi> which i'd already tried.
[00:10] <wasabi> there we go
[00:23] <kirkland> is it more customary for program usage statements to be printed to stdout or stderr?
[00:26] <kirkland> that seems like the type of question slangasek might be an authority on :-)
[00:26] <slangasek> I've seen a mix of each, actually
[00:27] <lifeless> kirkland: if you ask for help, then stdout
[00:27] <slangasek> I assume that if I want to capture --help output to a pager, I need to use 2>&1, because it's not reliable not to - but there are some that send to stdout
[00:27] <lifeless> kirkland: is better IMO
[00:27] <kirkland> okay, thanks, guys
[00:32] <lifeless> kirkland: bzr uses stdout for requested output and stderr for everything else
[00:32] <lifeless> kirkland: --help is requested out -> stdout
[00:32] <kirkland> lifeless: interesting, okay.
[00:32] <lifeless> the goal being that 2>/dev/null should never discard important information and that |less should never have cruft
[00:32] <kirkland> that seems reasonable
[00:50] <cjwatson> yeah, I'm definitely with lifeless on this one
[00:51] <kirkland> cjwatson: cool, thanks
[00:51] <cjwatson> I often end up with def usage(stream, exitcode): and call it as usage(sys.stdout, 0) or usage(sys.stderr, 1), or something along those lines
[00:51] <cjwatson> (if I'm not using a canned library)
[00:52] <kirkland> cjwatson: yeah, i'm trying to standarise some of the ecryptfs-* output (not for intrepid ... upstream work)
[00:58] <wasabi> See, perfect (if it works)
[00:58] <wasabi> First launch of evolution began to auto convert my summary folders.
[01:32] <GasFurnace> !ops
[01:33] <GasFurnace> you again
[01:33]  * calc hopes amd64 works properly on his laptop now, doing a full reinstall to see
[01:33] <calc> that would make it a lot easier to track down 64bit OOo bugs
[01:34] <GasFurnace> !ops
[01:35] <lifeless> GasFurnace: why are you doing that repeatedly; the answer won't change
[01:53] <calc> it works :)
[01:54] <calc> just doesn't resume well on the cd for some reason
[01:55]  * Hobbsee looks in
[01:59] <TheMuso> Hobbsee: Was that strictly necessary?
[01:59] <Hobbsee> TheMuso: yeah, i spoke to -ops - he's been trolling everywhere
[01:59] <TheMuso> Hobbsee: fair enough then.
[02:00] <cody-somerville> He got klined
[02:00] <cody-somerville> He isn't coming back :P
[02:00] <Hobbsee> TheMuso: i thought the nick looked familiar...
[02:00] <TheMuso> Hobbsee: No.
[02:00] <cody-somerville> TheMuso, He was doing the same thing in #xubuntu and #xubuntu-offtopic
[02:00] <TheMuso> cody-somerville: Fun.
[02:01] <Hobbsee>  and #kubuntu-offtopic, and ...
[02:01] <Hobbsee> the forums
[02:01] <TheMuso> I often wonder why people bother, knowing they'll just get banned.
[02:02] <lifeless> they don't know that
[02:02] <cody-somerville> "[21:33] <GasFurnace> i can do this all night"
[02:02] <lifeless> knowing that requires thinking about the machinery of maintaining a good discussion forum
[02:02] <calc> he can also get a k line :)
[02:02] <LjL> cody-somerville: now he's found out he can't
[02:02] <calc> ah i see he already did :)
[02:02] <lifeless> and some folk don't know how to think
[02:03]  * TheMuso is finding that some people don't know how to think more and more, and its shameful. :p
[02:04] <Hobbsee>  well, if he isn't coming back on that ip...
[02:05] <cody-somerville> Lets all hold hands for a moment, shall we?
[02:06] <StevenK> And sing Kumbaya?
[02:08] <philwyett> Morning all. Any of the release team to flag an RC bug too in the house?
[02:09] <cody-somerville> StevenK, I got a job for ya :)
[02:09] <cody-somerville> StevenK,
[02:09] <cody-somerville> erm
[02:09] <StevenK> cody-somerville: Thanks, I already have one.
[02:10] <Hobbsee> philwyett: which bug?
[02:10] <philwyett> https://bugs.launchpad.net/bugs/288461
[02:10] <StevenK> And how is it RC?
[02:10] <philwyett> StevenK: That is from an hour old 8.10 RC install.
[02:11] <StevenK> philwyett: No no, how is the bug release-critical?
[02:12]  * StevenK tries to reproduce
[02:12] <philwyett> StevenK:  It makes a core piece of software unusable on the desktop. So, I class that as fairly critical. ;-)
[02:12] <calc> grr the add location option no longer has a find location option
[02:12] <calc> er in the clock
[02:13] <calc> oh it text completes now, heh
[02:14] <StevenK> philwyett: Works fine for me with compiz
[02:15] <Aero> hi, per colin watson's instructions on ubuntu-devel-announce today, i'm looking for someone from ubuntu-release team to acknowledge a fairly serious bug
[02:15] <Aero> https://bugs.launchpad.net/ubuntu/+bug/259385
[02:15] <Aero> (to those in #ubuntu+1, sorry for repeating myself)
[02:15] <slangasek> -               &apos;linnuks&apos; is the heart of the Ubuntu operating system.
[02:15] <slangasek> +               &apos;li-nuks&apos; is the heart of the Ubuntu operating system.
[02:15] <Hobbsee> philwyett: I can't reproduce that.
[02:15] <slangasek> mdke: ^^ that looks like a regression to me...
[02:15] <philwyett> StevenK: Not tried yet with compiz enabled as not all people have it on. This happens using nv driver thus compiz not enabled.
[02:16] <StevenK> Hobbsee: With or without compiz?
[02:16] <Hobbsee> with
[02:16]  * Hobbsee can minimise individual windows though, which seems to solve the problem, too
[02:17] <Hobbsee> oh, i see.
[02:18] <philwyett> If you look at my screenshot, the gimp has only one entry on the panel at the bottom which is also odd.
[02:19] <Hobbsee> so it does.  Now, why doesn't mine have that?
[02:21] <ajmitch> metacity issue?
[02:21] <Hobbsee> i'm not sure.  or a nv issue
[02:21] <Hobbsee> Aero: which video card are those on?
[02:22] <Aero> looks like various
[02:22] <calc> for some reason a lot of files on a freshly installed intrepid have group 999
[02:22] <Aero> to my recollection, some people saying nvidia
[02:22] <Aero> i'm affected and i have intel integrated graphics, i can get you more specific info in a sec..
[02:22] <calc> slangasek: heard anything about that yet?
[02:23] <philwyett> Hobbsee: I will add my xorg log to the bug report.
[02:26] <Aero> i can't remember where in GNOME i go to get a list of hardware...
[02:29] <Aero> sorry, i must have been imagining things when i said nvidia
[02:29] <Aero> some saying ati, at least one other intel integrated like me
[02:30] <Hobbsee> lspci, iirc.
[02:30] <Hobbsee> strange.
[02:30] <Aero> maybe it's actually two similar bugs?
[02:31] <Hobbsee> could well be.
[02:31] <Hobbsee> would be interestingto know what mvo says about it
[02:32] <Aero> who's that?
[02:33] <Aero> i attached my lspci
[02:33] <StevenK> One of the Ubuntu developers, deals with compiz
[02:33] <Aero> have i done my duty, y'think?
[02:34] <Aero> eh, i'll hang 'round for another few hours.
[02:34] <Hobbsee> Aero: yes, thanks:)
[02:34] <Hobbsee> (to the having done your duty)
[02:36] <Hobbsee> philwyett: i'm sorry, but I don't regard that as Release Critical
[02:36] <Hobbsee> philwyett: does upstream have a patch, or a bug for it, yet anyway?
[02:36] <Hobbsee> itmay get pushed as a SRU if it's small
[02:37] <philwyett> Hobbsee: I will do some checking.
[02:38] <mneptok> *smewch*
[02:38] <Hobbsee> philwyett: https://bugs.edge.launchpad.net/ubuntu/+source/gimp/+bug/283115 is probably related to that (or a dupe).  erk.
[02:38] <calc> cjwatson_: i gave you bug 288479
[02:38] <Hobbsee> mneptok: oh, thanks
[02:39] <calc> anyone else notice the gid 999 files on a freshly installed intrepid system?
[02:40] <philwyett> Hobbsee: That is a bug and related, but not exactly a dupe. I will subscribe to that one too.
[02:51] <philwyett> Hobbsee: Aha, this looks like the devs doing silly things and trying to confuse users again. :-/ http://bugzilla.gnome.org/show_bug.cgi?id=556896#c4 Using TAB will minimize and maximize the two dialogs.
[02:52] <StevenK> cody-somerville: Uploading
[02:52] <StevenK> cody-somerville: s/ing/ed/
[02:53] <cody-somerville> StevenK, \o/
[02:54] <ScottK> StevenK: Would you please sync gnupg2 to fix Bug 288061.  Hobbsee OK'ed it for ubuntu-release.
[02:55] <StevenK> Only if slangasek okays it
[02:55] <StevenK> syncs bypass the unaprroved queue
[02:55] <ScottK> OK.  I thought it was anybody in the release team.
[02:55] <Hobbsee> bug 281610
[02:55] <Hobbsee> StevenK: so they do?  darn.
[02:56] <ScottK> StevenK: I'll upload it then so it gets in queue for his review.
[02:56] <StevenK> ScottK: I'd prefer it was sync
[02:56] <StevenK> sync'd
[02:56] <ScottK> OK.  I was gonna use syncpackage to make it turn out like one.
[02:57] <ScottK> But if you say not, I won't.
[02:58] <Hobbsee> Aero: i'm not sure what relevance https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/281610 currently has to your bug.
[03:05] <icanhas> pitti: *poke*
[03:06] <TheMuso> icanhas: pitti would be asleep at the moment. Maybe you should try and catch him when he is awake and around.
[03:07] <icanhas> TheMuso: i thought people wake up when you poke them :(
[03:07] <Hobbsee> icanhas: depends how loud their pc is....
[03:07] <Hobbsee> icanhas: and the WAF of that is pretty low...
[03:08] <calc> pitti will probably be around in ~ 5h
[03:09] <icanhas> You devels really look out for each other, lol.
[03:09] <icanhas> thank you :)
[03:09] <kirkland> emgent_: hey dude, congrads ;-)
[03:14] <kirkland> slangasek: still around?
[03:15] <kirkland> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/259631
[03:15] <kirkland> slangasek: users complaining about their ecryptfs private dir not available on login/reboot
[03:15] <kirkland> slangasek: i got one of them to post their /etc/pam.d/common-session
[03:15] <kirkland> slangasek: http://launchpadlibrarian.net/18812515/common-session
[03:16] <kirkland> slangasek: that ain't gonna cut it ;-)
[03:16] <kirkland> slangasek: i'm guessing their answered the pam-config question "poorly" (/me says in his best Last-Crusade voice)
[03:17] <kirkland> slangasek: can you drop a comment or two in that bug, as to how these users might get their pam configs back in tip top shape?
[03:20] <philwyett> Aero: Can you add your xorg log to the bug you are concerned with. The lspci -vvnn is throwing up a flag as it shows a vga controller but no sub display controller.
[03:24] <calc> grr, i still can't run 64bit guests in vmware since my cpu doesn't have VT support :(
[03:24] <calc> so upgrading to 64bit ubuntu didn't really help me that much
[03:42] <ScottK> StevenK: Would you please do the sync in Bug 287697.  It's Universe, so I can OK it.  It fixes a remote excecution exploit.
[03:46] <StevenK> ScottK: Done
[03:53] <Aero> Hobbsee: come to think of it, my PS/2 keyboard and mouse broke at one point. they worked immediately after installing the beta, but an update broke them. i fixed by installing xorg-input-all, or something like that
[03:53] <Hobbsee> Aero: yeah, that'll be a lack of -evdev installed.
[03:54] <Hobbsee> that should have been fixed, too.
[03:54] <Hobbsee> seems that it is
[03:54] <Aero> shall i uninstall the input package and find out?
[03:55] <Hobbsee> don't think that would be overly wise
[03:56] <Aero> k
[03:58] <ScottK> StevenK: Thanks.
[03:58] <Hobbsee> ScottK: https://bugs.edge.launchpad.net/ubuntu/+source/seahorse/+bug/284044 is collateral damage of the old gnupg2, isn't it?
[03:58] <Hobbsee> or am i not reading it properly
[03:58]  * ScottK looks
[04:00] <ScottK> Hard to say.  The particular bug I was wanting gnupg2 sync'ed for I don't think is that.
[04:01] <ScottK> I do think there is something going on in the environment though because I've run into people with similar problems with pinentry-qt4 although it works fine for me.
[04:03] <Aero> philwyett: done.
[04:04] <Aero> or did you mean a different log? i assumed .xsession-errors
[04:04] <Aero> but it looks like i attached that to my dupe already
[04:07] <ScottK> StevenK: But 286622 looks like another good sync to do.
[04:12] <philwyett> Aero: No, your /var/log/Xorg.0.log please.
[04:13] <Aero> is that log only valid for the last login/boot? i've since logged in with metacity
[04:14] <philwyett> Aero: I am after general info of what is going on from boot.
[04:14] <Aero> ah, okay
[04:15] <slangasek> calc: uh.  group 999? no...
[04:15] <slangasek> StevenK: Hobbsee can approve exceptions for the release team
[04:16] <Aero> done.
[04:17] <Hobbsee> bug 286622
[04:19] <Hobbsee> ScottK: yes, it does.
[04:19] <slangasek> kirkland: commented
[04:19] <StevenK> Hobbsee, ScottK: I'll sync 288061 and 286622
[04:19] <kirkland> slangasek: thanks a lot
[04:20] <Hobbsee> StevenK: thank you.
[04:27] <ScottK> StevenK: Thanks.
[04:28] <Aero> i'm out - if i can be of any further help, leave me a note on the ticket.
[04:59] <calc> slangasek: unfortunately i can't retest the amd64 install since my cpu apparently is too crap for vmware 64bit
[05:01] <StevenK> calc: Missing a flag?
[05:01] <calc> StevenK: i have no VT :\
[05:01] <calc> apparently its required to get around a deficiency in the intel cpus, and mine doesn't even have taht
[05:01] <calc> er that
[05:02] <ScottK> StevenK: Would you please do the sync in bug 288515
[05:05] <StevenK> ScottK: Done.
[05:06] <ScottK> StevenK: Thanks.
[05:06] <ScottK> I've got maybe one more that's building now and then I'm going to bed.
[05:08] <calc> anyone happen to know where evolution stores its config data?
[05:09] <calc> is it in .evolution or somewhere else?
[05:09] <calc> for the accounts
[05:10] <calc> ah its in gconf
[05:11] <ScottK> Nevermind.  Going to bed.
[05:12] <pabs3> does Ubuntu have the capability to sync packages from Debian experimental?
[05:12] <ScottK> pabs3: Yes.
[05:13] <pabs3> ah, cool, thanks
[05:13] <ScottK> Be sure to explicitly specify that's where the needed package comes from.
[05:13] <calc> crap i killed my evolution config :\
[05:13] <calc> doh
[05:13]  * calc should have backed it up before reinstalling
[05:13] <ScottK> calc: A sign you should be using Kmail.
[05:14] <calc> really a sign i should be asleep instead of doing things without backups :\
[05:14] <calc> at least all my mail is on imap so i didn't lose anything :)
[05:18]  * calc now remembers he also lost his filters and curses
[05:19] <ScottK> StevenK: There's a stack of Universe sync requests in the archive queue.  Except for 286374, I think they're all worth doing.
[05:19] <ScottK> Now off to bed.
[05:54] <slangasek> calc: which install method did you use, and what files wound up as group 999 (some examples)?
[05:55] <calc> slangasek: amd64 desktop manual partition reformatted my linux partition
[05:55] <calc> slangasek: i don't remember which all files but definitely /cdrom /initrd.img /vmlinuz did as well as some others i can't recall now :(
[05:55] <slangasek> ok, so this could be a livefs, kernel, or ubiquity bug...
[05:56] <calc> something that was very odd was (at least iirc) the gid on the symlinks was 999 even when the files pointed to weren't
[05:56] <calc> aren't the uid/gid supposed to match the pointed to file?
[05:57] <cjwatson> uid/gid on symlinks is almost meaningless
[05:57] <slangasek> no; you can create symlinks to files you don't own, and the symlink will be owned by you
[05:57] <calc> oh ok
[05:57] <slangasek> on Linux, it used to be that all symlinks were owned by root, IIRC
[05:57] <calc> either of you know how to reset email password?
[05:58] <slangasek> nope, sorry
[05:58] <calc> i seem to have forgotten mine
[05:58] <slangasek> I think you need to get IS to do it for you
[05:59] <calc> ok, they seem asleep atm, i guess i will get them to fix it in the morning, already midnight here
[06:01] <cjwatson> calc: thanks for the report, I've put it on ubiquity for now and will look at it
[06:03] <calc> cjwatson: ok
[06:03] <calc> cjwatson: from what i recall it seemed to only be files that would likely be changed during an install, and the root symlinked files
[06:04] <calc> eg not unpacked packages
[06:04] <cjwatson> mm, odd though because we copy off the squashfs
[06:04] <calc> iirc it wasn't more than 10-20 files total
[06:04] <cjwatson> and we do it as root ... it must be a pretty creative bug somewhere :)
[06:05] <calc> unfortunately i can't easily attempt reproduce the bug since i don't have VT support in my cpu :(
[06:05] <TheMuso> cjwatson: I noticed today that the ubuntustudio disks are not installing ubuntu-standard. Ubuntu-standard and its deps are on the disks, but don't get installed. Where should I be looking to solve this one?
[06:05] <cjwatson> TheMuso: look in the Packages file - do the dependencies of ubuntu-standard have "Task: standard"?
[06:06]  * TheMuso checks.
[06:06]  * calc goes to bed, bbl
[06:07] <cjwatson> night
[06:08] <TheMuso> cjwatson: appears so.
[06:08] <TheMuso> I've only really looked on i386, but I'll have a look on amd64.
[06:08]  * TheMuso fires up a VM.
[06:08] <cjwatson> TheMuso: ok, look in /var/log/installer/syslog after installation and search for ubuntu-standard - is it even trying to install it?
[06:11] <TheMuso> cjwatson: no.
[06:11] <TheMuso> ubuntu-standard is not in syslog.
[06:11] <cjwatson> TheMuso: right. sounds like tasksel/limit-tasks is breaking it then.
[06:12] <cjwatson> which'll be a tasksel bug I suppose
[06:12] <TheMuso> Sounds like it.
[06:12] <cjwatson> well, either that or a workaround in cdimage, I'll look ...
[06:14] <TheMuso> cjwatson: Ok, thanks. I'm happy to help/poke myself if need be.
[06:17] <cjwatson> TheMuso: I need to think a bit about the other users of tasksel preseeding, and what the right semantics are here
[06:17] <cjwatson> TheMuso: can you file a bug about this?
[06:17]  * TheMuso nods.
[06:17] <TheMuso> cjwatson: No problem.
[07:10] <pitti> Good morning
[07:10] <geser> Guten Morgen pitti
[07:50] <tkamppeter> pitti, hi
[07:51] <tkamppeter> pitti, there is bug 288424
[07:52] <tkamppeter> and the Ghostscript source does not have a file list for ghostscript-x. The files are distributed to the binary package by moving them around via debian/rules.
[07:52] <tkamppeter> pitti, is this a bug of dpkg-buildpackage?
[07:57] <pitti> tkamppeter: it has got nothing to do with -buildpackage, it's on installation
[07:57] <pitti> tkamppeter: so  if at all, it's a bug in dpkg, but I really doubt that
[07:57] <pitti> tkamppeter: if the package installs well for you, it isn't a problem in the deb itself, and I'd assume a problem on the client side
[07:57] <geser> I can't reproduce it with -0ubuntu6 on AMD64
[07:58] <pitti> tkamppeter: such as full disk, corrupted memory, etc.
[07:59] <pitti> tkamppeter: worth asking to attach /var/lib/dpkg/info/ghostscript-x.files
[07:59] <pitti> and see how corrupted it is
[08:01] <[reed]> which is better to use? -dbg or -dbgsym?
[08:05] <pitti> [reed]: doesn't make much of a difference; -dbg is a bit easier, -dbgsym are available for more (ideally: all) packages
[08:05] <[reed]> ok, thanks
[08:14] <mdke> slangasek: it's discussed here: https://bugs.edge.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/275592 (but in any event, changing it is more trouble than it's worth because it would introduce an untranslated string)
[08:15] <mvo> doko_: should icedtea6-plugin the default when searching for a java plugin in gnome app install?
[08:23] <Mirv> mvo/doko_: since it's now impossible to install icedtea-plugin via g-a-i, I've reported it as bug 283950
[08:24] <Mirv> mdke: Dougie seemed to already change some of those, which resulted that there are already missing translations since the current templates in Rosetta don't allow for translating the changes strings
[08:25] <tkamppeter> pitti, I do not have a /var/lib/dpkg/info/ghostscript-x.files, but a /var/lib/dpkg/info/ghostscript-x.list containing all the files belonging to ghostscript-x. Mine is OK, so I will ask the user to attach his.
[08:25] <pitti> tkamppeter: sorry, that's it
[08:27] <mvo> Mirv: I fixed it in bzr already, just wanted to confirm with doko that this is the right onw (I'm pretty sure it is)
[08:27] <Mirv> mvo: right, I understood what you actually meant only after typing my message
[08:27] <davmor2> Anyone do you have intrepid on a machine with bluetooth and can you connect to a phone?
[08:28] <mdke> Mirv: what do you mean? The strings were uploaded to Rosetta a long time ago, no?
[08:29] <tkamppeter> pitti, for me it looks like some disk-full problem. Here perhaps a better handling by dpkg would be needed.
[08:30] <pitti> mvo: good morning
[08:30] <pitti> mvo: mmmm, API change in that update-manager upload?
[08:30] <Mirv> mdke: probably, but apparently the POT files at least didn't reach Rosetta since eg. the Ubuntu pronouncation in Rosetta is still "oo-BOON-too" while the English text is actually "oo-boon-too", thus no translation match
[08:30] <pitti> mvo: there are some places in the code which still seem to pass a prompt, not an answer
[08:30] <pitti> mvo: ./DistUpgrade/DistUpgradeViewGtk.py:        res = self.askYesNoQuestion(summary, msg)
[08:31] <pitti> mvo: oh, sorry, it's the second arg, no worries
[08:33] <mvo> pitti: yeah, the change was done a while ago, but it was missed in the textview unfortunately :/
[08:34] <pitti> mvo: ok, looks quite consistent now
[08:34] <mvo> thanks for the review!
[08:34] <mdke> Mirv: that's odd, I'm pretty sure I uploaded the file myself. Weird
[08:34] <pitti> mvo: EPARANOIA, sorry
[08:35] <mvo> pitti: that is the right mindset at this time
[08:35] <Mirv> mdke: yeah, no doubt, but I wouldn't be surprised at another import failure or something... maybe just for the about-ubuntu template or something
[08:36] <mdke> Mirv: actually, looking at the pot template in the package, it seems it wasn't updated. Sorry about that oversight. Anyway, it won't result in the string being untranslated, it just means the translations will be based on the old string
[08:37] <mdke> Mirv: I'll make sure it is updated for any post-release translations
[08:43] <pitti> Riddell: new upstream version of kvkbd is sanctioned?
[08:45] <pitti> kirkland: argh, password passing as CLI argument? oldest gotcha in the book... thanks for fixing that
[08:47] <pitti> kirkland: for upstream, the passing as argument should be entirely removed; it sticks not only in ps, but also in .bash_history, etc.
[08:52] <hunger> It would rock if somebody could add "OnlyShowIn=GNOME;XFCE;" into /etc/xdg/autostart/nm-applet.desktop before the release.
[08:52] <hunger> Currently that applet gets started in KDE in addition to knetworkmanager applet.
[08:52] <pitti> doko_: ca-certificates-java> the default file is installed as 644, making the cleartext password world-readable; and if you remove the default file, it suddenly uses a hardcoded default password ("changeit") instead of failing completely
[08:56] <directhex> java in "fail" shocker ;)
[08:58] <pitti> hunger: sounds like a good SRU
[09:00] <Mirv> mdke: Ah, ok. It seems that the (old) translation isn't shown, though. But if it's just about-ubuntu, it's not that bad vs. all pot files.
[09:06] <mdke> Mirv: yes, I think the problem should be limited to about-ubuntu
[09:11] <pitti> doko_: gfortran-4.2 gobjc-4.2 want to go to universe, that's ok?
[09:11] <pitti> doko_: libgcc4 libgcc4-dbg, too
[09:13] <seb128> pitti, slangasek: could you look at bug #283551?
[09:13] <hunger> pitti: Bug number is #268803 by the way.
[09:14] <hunger> pitti: I am at work, I can't do SRUs:-(
[09:15] <pitti> seb128: http://svn.gnome.org/viewvc/glibmm/trunk/gio/src/error.hg?r1=544&r2=735 -> nice trick :)
[09:16] <seb128> pitti: indeed!
[09:18] <pitti> seb128: http://launchpadlibrarian.net/18823096/changelog.diff looks reasonable to me
[09:18] <pitti> seb128: so please sync and close the bug
[09:19] <seb128> pitti: to me too, technically that's a GNOME 2.24.1 update but since sync bypass the queue I asked for reviewed there
[09:19] <seb128> pitti: will do, thanks
[09:19] <pitti> (ack'ed in bug report)
[09:24] <asac> doko_: what is icedtea-gcjplugin?
[09:25] <mvo> Mirv: could you please attach the full logs in /var/log/dist-upgrade/* to #287551 ?
[09:25] <asac> doko_: could you add the Npp- headers there too please?
[09:31] <Mirv> mvo: ok, done
[09:37] <mvo> thanks Mirv!
[09:39] <Mirv> mvo: umm. now that I look through the logs myself, I realized that I had upgraded X and Mesa to non-hardy versions. so possibly just my problem, unless there is something very obviously wrong that would be good for robustness.
[09:46] <mvo> Mirv: I checked and this problem comes from the change in the dependencies of language-support-fi - it now just suggests language-pack-fi instead of recommending it and that make apt think its a no longer used dependency
[09:47] <mvo> it seems rather strange that language-support-fi recommends language-support-translations-fi (that pulls in OOo-l10n) but not lang-pack-fi
[09:48] <pitti> mvo: in general, -support shouldn't pull in -pack
[09:49] <Mirv> mvo: ok, thanks for checking, then there's a real problem
[09:49] <pitti> mvo: so ideally -pack-fi should pull in -translations-fi, but we don't do that for known reasons (CD size)
[09:50] <Mirv> pitti: language-pack-fi doesn't fit on the CD either (not since 6.10), so it shouldn't really matter
[09:50] <mvo> right - I add a quirks handler that ensures that the right thing happens in u-m
[09:50] <Mirv> mvo: great!
[09:51] <Mirv> though the dependencies are probably same for most language packs?
[09:51] <mvo> Mirv: yes, I add something generic
[09:59] <davmor2> I found a regression from beta https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/288613 I can't get my pc to pair with my phone via bluetooth
[10:01] <pitti> hm, did we actually do rebuild tests for intrepid recently?
[10:02] <seb128> pitti: new yelp in the queue which has rosetta translations
[10:02] <pitti> seb128: how much bigger does the binary get?
[10:03] <pitti> seb128: hm, shouldn't yelp translations be in the langpacks?
[10:03] <pitti> libgphoto FTBFSes, yay
[10:04] <pitti> ../libtool: line 827: X--tag=CC: command not found
[10:04] <pitti> WTH?
[10:04] <persia> pitti, Which gtkmm2.4 do you have?  The 2.24.1 one?
[10:04] <seb128> pitti: run autoreconf rather than just autoconf to fix that
[10:05] <pitti> seb128: I didn't do anything, just apt-get source and debuild -b
[10:05] <persia> (and I believe the last rebuild test was for FeatureFreeze, and I'm not sure people chased all the discovered results)
[10:05] <seb128> pitti: langpacks -> no because the xml are generated during the build and not using gettext
[10:05] <pitti> persia: me? I don't have it installed
[10:05] <bigon> pitti, I get this issue some times too
[10:05] <seb128> pitti: there is likely a timestamp issue due to a patch which triggers autotools update no?
[10:05] <bigon> try with updating libtool script in the pkg
[10:06] <seb128> pitti: that's a "classic"
[10:06] <persia> pitti, Sorry.  Just there were a number of reports of bits of GNOME FTBFS with the older gtkmm.
[10:06] <pitti> -rwxr-xr-x  1 martin martin 219286 Oct 24 11:02 libtool
[10:07] <pitti> seems it does get touched during build
[10:07] <seb128> pitti: is there any patch changing a configure or makefile?
[10:07] <seb128> pitti: look at the build log but I bet the autotools are ran on your box
[10:07] <pitti> seb128: yes
[10:07] <pitti> so I should purge autoconf/libtool temporarily
[10:08] <seb128> either that or run autoreconf if your sources after applying the patches and debuild binary
[10:08] <seb128> if -> in
[10:08] <pitti> this will become an SRU, so I don't want to fiddle with that
[10:08] <seb128> ok, so remove automake
[10:08] <pitti>  gnome-common depends on libtool; however:
[10:08] <pitti>   Package libtool is to be removed.
[10:08] <pitti> ??
[10:09]  * pitti radiates hate towards autof**k and purges cdbs, glade-gnome-3, and other stuff which violently depends on it
[10:10] <seb128> pitti: remove automake might be enough
[10:10] <pitti> seb128: don't worry; purging autoconf feels soo good :-P
[10:10] <seb128> pitti: it'll only do the autotools update if automake is installed I think
[10:10] <seb128> ;-)
[10:10] <pitti> seb128: but good to know for the future, thanks muchly
[10:13] <seb128> pitti: you're welcome
[10:14] <seb128> pitti: the yelp update, installed size is not much of a difference, less than 300k, the documentation is static xml in the binary so no languagepack there
[10:18] <pitti> seb128: you mean 300 kB in addition? hm, that's likely to cost us yet another langpack :(
[10:18] <seb128> pitti: other alternative is to have the yelp start screen not translated
[10:19] <seb128> pitti: bug #281281
[10:20] <pitti> seb128: not much we can do for intrepid; stuff like this should eventually use gettext at runtime, I guess
[10:21] <pitti> seb128: so please upload
[10:22] <seb128> pitti: already did
[10:22] <seb128> pitti: it's waiting in the queue
[10:22] <seb128> pitti: just curious but what languagepacks are currently on the cd?
[10:23] <pitti> seb128: amd64: en and es
[10:23] <pitti> seb128: i386: en es de pt bn
[10:23] <seb128> urg
[10:23] <seb128> not a lot
[10:24] <lool> wow
[10:24] <seb128> I guess it's late now for the evolution documentation split
[10:24] <pitti> seb128: that's why I'm fighting for every byte :)
[10:27] <mvo> Mirv: how did you install the finish language support initially (in 8.04) ? via langauge-selector?
[10:28] <Keybuk> lifeless, cjwatson: I agree with both of you
[10:28] <Keybuk> kirkland: imo, if someone runs --usage or --help then the output should be sent to stdout
[10:28] <Keybuk> *but* if you give them usage instructions when they get something wrong, *that* should go to stderr
[10:29] <Mirv> mvo: well it's an update from gutsy I think, originally probably at install time by having internet connection available
[10:29] <pitti> seb128: in fact it's late for this kind of translation update, too (NonLanguagePackTranslationDeadline), but well...
[10:30] <Mirv> mvo: interesting/cause might be that I briefly tested (the broken) hardy-proposed language packs, then manually installed the hardy-updates language packs
[10:30] <cjwatson> pitti: well, that's the deadline for translators rather than for uploads, IIRC
[10:30] <seb128> pitti: right, as said that's either that or no translation, etoomuchtodo, we should have those listed in a "todo before freeze" or something
[10:30] <pitti> seb128: don't worry, it should be fine
[10:30] <seb128> not easy to keep track of everything
[10:30] <Mirv> mvo: (just occurred on my mind)
[10:30]  * pitti hugs seb128
[10:31] <mvo> Mirv: thanks, I'm trying to figure out what scope the problem is and it seems like its somewhat rare as installs via lanauge-selector should be fine, not sure about fresh installs yet
[10:33]  * seb128 hugs pitti
[10:40] <doko> pitti: will change ca-certificates-java
[10:40] <doko> pitti: g* is ok, libgcc4* is main (hppa only)
[10:40] <pitti> doko: out of interest, why does it need encrypted storage of certificates?
[10:40] <pitti> doko: ah, thanks
[10:40] <Keybuk> cjwatson: I have a bug for missing /dev/rtc - do we think that could be fixed before release or wait for SRU?
[10:42] <doko> pitti: java knows only one keystore, so if you only have public certs, it can be world readable, but if you store your own certificate, it has to go into the same keystore
[10:42] <cjwatson> Keybuk: do you know what's causing it?
[10:43] <pitti> doko: you mean for your own secret key? other SSL keys are just stored in plain text and protected by file access bits; so that doesn't work in java?
[10:43] <Keybuk> cjwatson: yes
[10:43] <Keybuk> the kernel now calls is /dev/rtc0
[10:43] <Keybuk> it needs a udev rule adding
[10:43] <Keybuk> SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos", SYMLINK+="rtc"
[10:43] <Keybuk> :p
[10:43] <cjwatson> clock-setup does:
[10:43] <cjwatson> # rtc-dev creates a /dev/rtc0, so set up a symlink
[10:43] <cjwatson> # XXX This won't be needed once a new udev (116) that
[10:43] <cjwatson> # handles the symlink gets into Debian.
[10:43] <cjwatson> if [ -e /dev/rtc0 ] && [ ! -e /dev/rtc ]; then
[10:43] <cjwatson>         ln -sf rtc0 /dev/rtc
[10:43] <cjwatson> fi
[10:43] <cjwatson> :-)
[10:43] <cjwatson> though that doesn't persist after installation, it's just for hwclock
[10:43] <Keybuk> where is clock-setup?
[10:44] <cjwatson> this seems like the sort of thing that will bite us with hwclock not running
[10:44] <cjwatson> so I'd say it should go into final
[10:44] <Keybuk> how do you mean?
[10:44] <Keybuk> it breaks vmware apparently
[10:44] <cjwatson> hwclock uses /dev/rtc, doesn't it?
[10:44] <Keybuk> not sure what hwclock uses
[10:44] <cjwatson> hwclock/hwclock.c:1184:#define RTC_DEV "/dev/rtc"
[10:45] <cjwatson> actually I think it might fall back to rtc0
[10:45] <cjwatson> yeah, it does
[10:45] <doko> pitti: yes, but you have only that one file, not separate files
[10:46] <doko> asac: what is icedtea-gcjplugin?
[10:46] <cjwatson> Keybuk: I think it can go into release though - it's trivial and we already know one thing it breaks, there could easily be others
[10:47] <pitti> Keybuk: buildds pretty much caught up with the backlog; I agree about obvious and safe patches, today is the best day to get them in
[10:47] <Keybuk> http://people.ubuntu.com/~scott/udev_124-8.debdiff
[10:47] <Keybuk> ^ review for my sanity plz
[10:48] <cjwatson> Keybuk: what happens if there manages to be more than one?
[10:49] <Keybuk> there cannot be
[10:49] <Keybuk> (reading the driver)
[10:49] <pitti> or if /dev/rtc already exists for some reason?
[10:49] <Keybuk> if there were, the first one allocated by that driver would win
[10:49] <pitti> SYMLINK will just gravefully fail then?
[10:49] <pitti> erm, "gracefully" *cough*
[10:49] <Keybuk> pitti: if /dev/rtc exists and is a device node, udev preserves it
[10:49] <Keybuk> if it's a symlink, it adjusts it
[10:49] <Keybuk> if it's a file, it spits out a "stop mucking around with /dev" kind of error
[10:49] <pitti> sounds good to me then
[10:50] <Keybuk> oh, unless /dev/rtc is a device node with the same stat as the one it would be symlinking
[10:50] <Keybuk> in which case it will replace it with the symlink
[10:51] <cjwatson> oh, right, limited by driver
[10:51] <cjwatson> Keybuk: fine then
[10:51] <cjwatson> oh, um
[10:51] <pitti> cjwatson: at which architectures does c-m look ATM?
[10:51] <cjwatson> Keybuk: I believe it's not always rtc_cmos though
[10:51] <cjwatson> isn't that arch-specific?
[10:51] <Keybuk> cjwatson: chatting to upstream, the rtc cmos driver is the old one
[10:52] <Keybuk> so it was the driver that used to be at /dev/rtc before
[10:52] <cjwatson> although I suppose worst case is that other arches don't get the symlink
[10:52] <Keybuk> the new drivers have different properties and behaviours
[10:52] <Keybuk> so with the new subsystem, you may have a /dev/rtc0 when you didn't have a /dev/rtc before
[10:52] <Keybuk> that rule won't symlink to /dev/rtc - but that seems correct to me - since it would never have been there before either
[10:53] <Keybuk> there's not a case where after upgrade, /dev/rtc "vanishes"
[10:53] <Keybuk> there just will be some systems where after upgrade, you have a /dev/rtc0 now
[10:53] <cjwatson> I was thinking of efirtc and such
[10:53] <Keybuk> I think that's covered in the rtc_cmos driver
[10:55] <cjwatson> if you say so - it seems a bit unlikely since EFI isn't "PC-style RTC"
[10:55] <Keybuk> possibly true
[10:55] <Keybuk> but then that means they don't necessarily support the same ioctls either
[10:55] <Keybuk> (according to Documentation/rtc.txt)
[10:56] <Keybuk> I'm wary of just doing KERNEL=="rtc0", SYMLINK+="rtc"
[11:02] <cjwatson> Keybuk: I think the rtc_cmos limitation is probably good enough
[11:02] <Keybuk> at least that won't break anything that worked before ;)
[11:03] <cjwatson> right
[11:31] <tkamppeter> pitti, can you have a look at bug 288570? What would you say about its severity? SRU, Release notes entry? Or eben stopper for Intrepid?
[11:41] <Riddell> pitti: kvkbd is good from me
[12:05] <Mirv> mdke: hi. the new yelp didn't fix "Assistive Tools". do you remember/know what should still be done to translate that topic like before? upload ubuntu-modifed accessibility-guide instead of default?
[12:34] <sebner> StevenK: ah mighty steven. thx for your comment on twiki. the problem is that there are only 6 days left until release and we are not sure what to do now (especially myself because I'm not that a web/server guy). any suggestion?
[12:46] <emgent_> kirkland: ?
[13:55] <pitti> cjwatson: apparently component-mismatches doesn't look at ia64 and hppa (otherwise it'd not complain about the -hppa kernel/ooo-dummy-ia64 stuff); it seems it does look at sparc, though? the inkscape and gcc-4.1 bits are done for i386/amd64/powerpc, just inkscape FTBFSed on sparc (some boost portability issue, it seems)
[13:59] <tkamppeter> pitti, can you have a look at bug 288570? What would you say about its severity? SRU, Release notes entry? Or eben stopper for Intrepid?
[13:59] <pitti> tkamppeter: havent' forgotten about it, it's in my work queue :)
[14:00] <pitti> tkamppeter: not a showstopper by any means, it only affects a small percentage of use cases, and such things can very well be fixed in an SRU
[14:01] <pitti> tkamppeter: but as long as there isn't even a solution yet, we can't start an SRU either
[14:03] <tkamppeter> pitti, so we simply wait for the upstream developers to fix it for now.
[14:03] <persia> That, or work on it, and send the patches upstream.
[14:05] <alkisg> Hi, on an acer 5920G laptop the "brightness-up" key does change the brightness, but it increases it 2 times, and also echoes a "±" character. It worked fine in Hardy. It does this both on X and on plain console. Which package could be the cause of this?
[14:05] <StevenK> pitti: Please check and accept linux-lpia at your convience
[14:06] <pitti> StevenK: done
[14:06] <StevenK> pitti: \o/
[14:14] <sladen> alkisg: once in hardware, once in software?  Or once via ACPI and once via  brightness-key -> gnome-settings-daemon?
[14:15] <alkisg> sladen, I just press Fn+right key on keyboard, and I see the brightness going up twice. But the main problem is the ± character which is echoed. Here's a more detailed description: https://bugs.launchpad.net/ubuntu/+source/hotkey-setup/+bug/281951
[14:15] <alkisg> So I wanted to try to debug this, but I don't know where to start
[14:15] <sladen> alkisg: the character is the 177 keycode being sent
[14:16] <alkisg> sladen, yes, but why does it send 6 keycodes? It should only send 2.
[14:16] <alkisg> (like it did on Hardy)
[14:20] <alkisg> sladen, what is between the kernel (which I assume works OK) and the showkey application? evdev?
[14:21] <sladen> alkisg: grep -rE 'e0(4c|4e|54)' /usr/share/hotkey-setup/
[14:21] <alkisg> sladen, /usr/share/hotkey-setup/atkbd.hk:setkeycodes	e04c	$KEY_MACRO
[14:21] <alkisg> /usr/share/hotkey-setup/atkbd.hk:setkeycodes	e04e	$KEY_KPPLUSMINUS
[14:21] <alkisg> /usr/share/hotkey-setup/atkbd.hk:setkeycodes	e054	$KEY_RESERVED
[14:22] <sladen> alkisg: yes, they're 3 keys that are already defined in a normal keymap
[14:23] <alkisg> This is the one I'm using? I thought it was acer.hk...
[14:23] <sladen> atkbd is the base map, the kernel defaults
[14:24] <alkisg> Uh, I see... but why 6 keycodes?
[14:24] <sladen> alkisg: however, those 3 keys are already defined as doing $something_else,  and they are not overriden for your acer;  So create a new  acer-2500.hk  (copy the -1600) and add those three in to that file
[14:25] <sladen> alkisg: not sure why six.  Either it's (1) Fn-down, Left, Something.  or (2) If a cyclic loop between gnome-power-manage and bak to ACPI
[14:25] <alkisg> sladen, and I should map the first one to the brightness, and 'discard' (=RESERVED) the rest two?
[14:26] <alkisg> sladen, and where do I declare that I want to use acer-2500.hk?
[14:26] <sladen> alkisg: add a match to /etc/init.d/hotkey-setup
[14:26] <alkisg> sladen, thank you very much! :)
[14:27] <sladen> alkisg: see what effect nulling (RESERVED) each of those out has
[14:27] <sladen> alkisg: and then we can move on to tackling HAL so that you get brightness notifications, but not a double change
[14:28] <alkisg> sladen, thanks, I'll try it
[14:31] <sladen> alkisg: ideally keep notes on the bug report as you go along, particularly so that things like this IRC conversation don't get lost
[14:32] <alkisg> sladen, I'll post my finding (if any) on the bug report
[14:33] <alkisg> sladen, for quicker testing, does setkeycodes take effect immediately?
[14:34] <sladen> alkisg: setkeycodes does;  but if you do sudo /etc/init.d/hotkey-setup restart   that will cleanly save and resave the keymap
[14:34] <alkisg> sladen, thanks again
[14:35] <pitti> StevenK: octave-gpc was unfixable, you said? at this point I'm just going to ignore it and kill libhdf5-serial-1.6.5-0 (NBS)
[14:35] <sladen> alkisg: which if you're testing different combinations is much more useful than doing random scibbles and not knowing what is currently in effect
[14:35] <StevenK> pitti: Right
[14:35] <StevenK> pitti: It's unfixable with octave3.0
[14:35] <pitti> final house cleaning :)
[14:35] <sladen> alkisg: plus, it'll close the DEFINES for the key names;  setkeycodes only knows about numbers
[14:45] <superm1> davmor2_lunch, pong
[14:45] <pitti> mvo: bug 231371 - has that actually been done?
[14:45] <pitti> mvo: I mean the manual copying
[14:46] <davmor2> superm1: did you work with the bluez-gnome package?
[14:46] <superm1> davmor2, yeah a fair deal
[14:47] <mvo> pitti: no manual copy, I work around the lack of this in the meta-relase file by setting explict version. bad but works
[14:47] <davmor2> superm1: https://bugs.launchpad.net/bugs/288613 I'm after trying to figure out what is going on with it.  Just after beta when the new applet came in it worked fine.
[14:48] <pitti> mvo: ok, *phew*; that scared me for a bit
[14:49] <superm1> davmor2, so you've paired the same phone at beta, was that with the same install?
[14:49] <mvo> pitti: it would be cool if that bug would be fixed in soyuz, but for now the workaround is doing its job, fortuantely the meta-release stuff is flexible enough
[14:50] <mvo> hm, what was the url again to see the launchpad translations export queue?
[14:50] <pitti> mvo: ok, so I can unsub u-archive@ from it?
[14:50] <davmor2> superm1: No I'm a tester so I'm constantly re installing
[14:50] <mvo> pitti: fine with me
[14:50] <pitti> mvo: *export* queue?
[14:50] <superm1> davmor2, hum okay.  are you sure you've removed the old pairing "from the phone"?
[14:50] <davmor2> yeap
[14:52] <superm1> davmor2, okay then the best thing you can do is stop the init script (/etc/init.d/bluetooth stop) and run sudo bluetoothd -nd from a command line and attach that output.  i'm at quite a loss where a regression may have developed.
[14:53] <davmor2> superm1: Okay thanks for the help :)
[14:54] <mvo> pitti: I'm wonder where my update-manager export is :)
[14:54] <mvo> pitti: the translations export for it I mean
[14:54] <superm1> davmor2, given that you're doing testing, if you can identify the versions of the packages that "did" work by running those live disks again and ensuring pairing works, it might help narrow down the regression.  i'm fearful that it might have been something in the kernel module that got updated though, since I don't recall any patches the last two weeks to bluez or bluez-gnome that would be expecting this to happen.
[14:54] <pitti> mvo: might be the same fate as general ubuntu langpack exports -- takes aaaaages
[14:55]  * mvo weeps a bit silently
[14:55] <davmor2> superm1: dvd-rw's unfortunatley.  I downloaded the beta but that has the old applet in.  So it must of been shortly after that.
[14:56] <superm1> davmor2, ah too bad.
[15:02] <MacSlow> argl... why doesn't type-head/lookup in a GtkListView no longer work?
[15:02] <MacSlow> know bug or disabled intentionally?
[15:02] <davmor2> superm1: Meh It's not even finding the phone now I'll remove the bluez-compat package and try again
[15:03] <persia> bluez-compat may well cause issues for those who don't *need* it.
[15:08] <pitti> BenC: http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html -> l-b-m-virtual depends on linux-backports-modules-2.6.27-7-virtual, which doesn't exist; should it exist, or should the metapackage be dropped?
[15:09] <BenC> pitti: ah, it should depend on lbm-x.x.x-server
[15:09] <davmor2> superm1: Would Can't set link policy on hci0: Connection timed out (110) have anything to do with it?
[15:10] <pitti> BenC: ok, that's just a simple linux-meta upload then; can you prepare it, please? (if you are busy, I can do it as well, I figure)
[15:10] <superm1> davmor2, most definitely.  If it times out connecting, there's an issue there :)
[15:11] <BenC> pitti: I can
[15:11] <pitti> BenC: cheers
[15:11] <pitti> BenC: then you have the honor of doing the upload which will make intrepid_probs empty :)
[15:11] <davmor2> superm1: but it didn't happen on the older version of the applet in beta, I re-tried it and it connects flawlessly
[15:13] <superm1> davmor2, well the only other thing that you can easily do to identify where the regression developed is to grab the older bluez and bluez-gnome packages off launchpad in reverse sequential order
[15:15] <davmor2> superm1: I've added the out put from sudo bluetoothd -nd to the bug
[15:15] <BenC> pitti: cool, done :)
[15:16] <kwwii> mdke: sorry to say it, but I have to remove the panel background in Intrepid, so the screenshots of the panel/full desktop need to be redone
[15:22] <davmor2> superm1: looking at it, it was probably the 30/09/08 that worked and the 07/10/08 that doesn't
[15:26] <superm1> davmor2, 09/30/08?  I'd be doubtful there, bluez 4.x wasn't introduced until 10/7/08
[15:26] <superm1> https://edge.launchpad.net/ubuntu/+source/bluez
[15:27] <StevenK> superm1: So, he's saying it worked with 3.x and doesn't with 4.x?
[15:27] <superm1> StevenK, well he said he paired with the new GUI, and the new GUI didn't work with 3.x
[15:33] <davmor2> StevenK: I have it working fine with 3.x and when the new version came to the desktop I noticed the cahnge and tried it again.  That time it worked fine went through all the pages and gave me a pin to type into my phone, it then connected and I could browse.  Now it isn't
[15:35] <davmor2> superm1: so how do I go about installing the older version?
[15:35] <superm1> davmor2, you should be able to click versions on that link i just posted and get direct debs
[15:35] <superm1> and just install them using dpkg -i
[15:36] <davmor2> superm1: will I need to get the newer version off first or will it over ride it?
[15:36] <superm1> it'll override it when you dpkg -i
[15:37] <superm1> davmor2, i've got to step out, lets continue over pm though.  we probably should have earlier
[15:37] <alkisg> sladen, I created an acer5900.hk and it solved the "±" character problem (but not the gnome-power-manager cyclic loop, I'll try to look into this later). I'm thinking of generating a correct acer5900.hk with all my laptop special keys (some other keys don't work).
[15:37] <alkisg> sladen, to do this, I'm thinking of (1) dumping the original keycodes, (2) modifying the keycodes to match my laptop, (3) save these differences as acer5900.hk. Is this method correct? I mean, are all the differences I see specific to my laptop model, or maybe some belong to another .hk file?
[15:37] <alkisg> sladen, then I'll upload the acer5900.hk to the bug report, commenting how I created it
[15:48] <sladen> alkisg: stop hotkey-setup,  use showkey -s  and go around your keyboard, record the results
[15:56] <bluefoxicy> 8.10 beta isssn't reading my CF reader anymore
[15:56] <bluefoxicy> [88017.013901]  sdc: sdc1
[15:56] <bluefoxicy> [88017.029588] sd 9:0:0:0: [sdc] Attached SCSI removable disk
[15:56] <bluefoxicy> bluefox@icebox:~$ ls /dev/sd*
[15:56] <bluefoxicy> /dev/sda   /dev/sda5  /dev/sda7  /dev/sdb   /dev/sdb2 /dev/sda1  /dev/sda6  /dev/sda8  /dev/sdb1
[15:57] <bluefoxicy> honestly, I don't know what's going on.  The kernel seems to understand, udev maybe?
[15:59] <Keybuk> bluefoxicy: anything in /sys/block/sdc ?
[16:01] <zul> whats the kde file manager called?
[16:02] <dendrobates> zul: dolphin
[16:02] <zul> dendrobates: thanks
[16:10] <dholbach> argh, how many times I already hit ctrl-alt-backspace accidentally
[16:11] <jdong> there must be a more elegant way to hack this kernel config, but I haven't had enough coffee yet.
[16:11] <jdong> bye bye, abi-check-*
[16:11] <cjwatson> pitti:         for arch in [ "i386", "amd64", "powerpc", "ia64", "sparc", "lpia" ]:
[16:12] <cjwatson> pitti: (re architectures in component-mismatches)
[16:13] <munckfish> cjwatson: is it at all possible to do a one off daily build of the ports CDs so I can verify finally if install/boot is going to be possible on PS3?
[16:14] <cjwatson> munckfish: alternate or desktop?
[16:15] <directhex> it's a little late for it, but can i suggest demoting mono-dbg to universe? it contains managed debug symbols (i.e. nothing gdb can use), and i'm pretty sure none of ubuntu's fancy apport stuff deals with those. mono-jit-dbg is the package for crashes of mono itself, with stuff in /usr/lib/debug
[16:16] <munckfish> cjwatson: ummm both?
[16:16] <directhex> and that one's in main already
[16:16] <cjwatson> munckfish: ok, running
[16:16] <munckfish> cjwatson: although to be honest, I wasn't aware the live/desktop version was even possible on PS3, I've been testing the alternate
[16:16]  * munckfish doesn't hold out much hope for the desktop version
[16:16] <cjwatson> certainly used to be
[16:17] <cjwatson> I put some work into that :)
[16:17] <munckfish> cjwatson: ok well sincerely sorry I didn't give it any attention
[16:18] <munckfish> cjwatson: How long do you think they need to run?
[16:18] <munckfish> cjwatson: ie when should I look to download em?
[16:18] <cjwatson> munckfish: alternate should be ready in 15/20 minutes or so
[16:18] <directhex> the PS3 has enough RAM for live?
[16:18] <munckfish> ok cool
[16:19] <cjwatson> directhex: just
[16:19] <munckfish> directhex: no it defaults to install not live apparently
[16:19] <cjwatson> well, that's still live in a sense
[16:19] <munckfish> cjwatson: live? seriously?
[16:19] <munckfish> ok
[16:19] <cjwatson> that may not be necessary any more mind you
[16:19] <cjwatson> live should only need 256MB in 8.10 rather than 384MB in 8.04
[16:19] <directhex> does intrepid at least boot though? that was kinda a downer for hardy
[16:19] <munckfish> cjwatson: yay! you mean you managed to get it back down again!
[16:20] <munckfish> cool
[16:20] <munckfish> well there's something to try out in Jaunty I guess
[16:20] <munckfish> directhex: yes it does, just
[16:20] <munckfish> by the skin of our teeth it does
[16:20] <munckfish> although we've just had to disable usplash
[16:20] <ScottK> NCommander: I just pushed your fetchmail patch for Intrepid.  That's for assembling it.
[16:21] <munckfish> directhex: it was working fine until about a week & a 1/2 ago
[16:21] <directhex> munckfish, handy :|
[16:21] <munckfish> directhex: but yes it will be installable and working
[16:22] <directhex> munckfish, how many "nice things" have filtered down into ps3 linux yet? is switching from wired to wireless still a colossal pain in the read end? sensible ways to change resolution?
[16:24] <bluefoxicy> bluefox@icebox:~$ ls /sys/block/sdc/
[16:24] <bluefoxicy> bdi	    dev     holders  queue  removable  sdc1  slaves  subsystem
[16:24] <bluefoxicy> capability  device  power    range  ro	       size  stat    uevent
[16:24] <bluefoxicy> Keybuk: ^^^^^
[16:24] <bluefoxicy> Keybuk:  (sorry, was trying to play Metallica)
[16:25] <Keybuk> bluefoxicy: if you disconnect it and reconnect it while running "sudo udevmonitor -e" what do you get?
[16:26] <bluefoxicy> sudo: udevmonitor: command not found
[16:27] <bluefoxicy> Keybuk:  there's a udev update available.  Should I try updating?  (Can I do it without rebooting)
[16:27] <pitti> lool, StevenK: that korou upload, is that sanctioned?
[16:28] <Keybuk> sorry
[16:28] <Keybuk> udevadm monitor
[16:28] <lool> pitti: sanctionned?
[16:28] <Keybuk> the udev update should not be relevant
[16:28] <munckfish> directhex: the feature list for Intrepid on PS3 was: 1) installable, 2) working anything else is a bonus. There weren't too many folk contributing to it in this last cycle
[16:28] <pitti> lool: "new upstream release", sounds a bit scary; I heard it's a mobile-ish package
[16:28] <lool> pitti: It fixes very important bugs, notably one of the milestoned ones
[16:28] <bluefoxicy> bluefox@icebox:~$ sudo udevadm monitor -e
[16:28] <bluefoxicy> udevmonitor will print the received events for:
[16:28] <bluefoxicy> bind failed: Address already in use
[16:28] <lool> pitti: It's a new upstream release because StevenK is upstream for it, but we're the only users
[16:28] <Keybuk> sounds like you're already running it somewhere else?  check ps
[16:28] <lool> pitti: It's just bug fies
[16:28] <lool> fixes
[16:29] <bluefoxicy>  3003 ?        00:00:01 udevd
[16:29] <bluefoxicy>  3009 ?        00:00:00 udevadm
[16:29] <pitti> lool: oh, see #u-release
[16:29] <Keybuk> bluefoxicy: interesting, kill that 3009 :p
[16:29] <bluefoxicy> Keybuk:  parent is init.
[16:29] <Keybuk> yeah, I suspect it's the one from udev's init script - curious that it's still running
[16:29] <bluefoxicy> Keybuk:  did I mention it takes me 3:30 to boot?
[16:30] <bluefoxicy> I viciously remove 'quiet' from  my menu.lst because I freaking hate the "let's show a non-moving status bar for however long it takes to run one init script so the system looks like it's hanged" bit
[16:30] <Keybuk> sounds like you have some system problems ;)
[16:30] <bluefoxicy> it hangs for 3 minutes at "Loading hardware drivers" or something :x  I filed a bug.  Could this be related?
[16:31] <Keybuk> most likely
[16:31] <Keybuk> what was the bug# ?
[16:32] <bluefoxicy> Malone #288173
[16:32] <Keybuk> ah yes, and it's waiting for information from you ;)
[16:32] <Keybuk> this looks like a lot of the same problem
[16:33] <bluefoxicy> ah cool.
[16:36]  * bluefoxicy sighs.  All this just 'cause he wanted to upload photos of the beer he drank.
[16:37] <Keybuk> if I were to hazard a guess, I would say that vol_id is failing on /dev/sdc1
[16:37] <Keybuk> and that's stalling your boot
[16:37] <Keybuk> and preventing the device from appearing as well
[16:37] <bluefoxicy> hmm
[16:38] <bluefoxicy> I just updated to the beta yesterday, when this started happening.
[16:38] <davmor2> superm1: I need to go now but I've found out by upgrading from beta that 4.12-0ubuntu1 works ubuntu2 doesn't
[16:38] <Keybuk> what if you mknod /dev/sdc and /dev/sdc1 yourself, and run vol_id on them by hand?
[16:38] <bluefoxicy> Keybuk:  I'm not entirely sure the major/minor numbers I need.
[16:38] <Keybuk> 8, 32 and 8, 33 :p
[16:39] <bluefoxicy> brw-rw---- 1 root disk 8, 16 2008-10-23 23:36 /dev/sdb
[16:39] <bluefoxicy> mmm, ok
[16:39]  * bluefoxicy tries that then.
[16:40] <bluefoxicy> Keybuk:  fdisk -l /dev/sdc hangs.  o_o
[16:40] <bluefoxicy> bluefox@icebox:~$ sudo fdisk -l /dev/sdc
[16:40] <bluefoxicy> ^C^C^C^Z^Z
[16:40] <bluefoxicy> ................. wow.
[16:40] <Keybuk> I suspect that's the real problem ;)
[16:40] <Keybuk> that block device is not working properly
[16:41] <bluefoxicy> yet it works in 8.04?
[16:41] <Keybuk> it's a CF reader you say?
[16:41] <Keybuk> can you disconnect it
[16:41] <bluefoxicy> yes
[16:41] <bluefoxicy> .... disconnecting it, oddly enough, deletes /dev/sdc*
[16:41] <cjwatson> munckfish: back down> ogra got compcache integrated, which did the trick
[16:42] <Keybuk> that's consistent at least
[16:42] <bluefoxicy> Keybuk:  could it be a kernel bug?
[16:43] <Keybuk> very likely
[16:43] <Keybuk> do things work normally with your CF disconnected?
[16:43] <Keybuk> is your boot normal speed?
[16:43] <bluefoxicy> though oddly, fdisk hangs while the kernel reports [90857.562138]  sdc: sdc1
[16:43] <bluefoxicy> I haven't tried
[16:43] <munckfish> cjwatson: I don't understand?
[16:43] <Keybuk> please try
[16:43] <bluefoxicy> alright, let me clean up here and prepare for shutdown <_<
[16:44] <bluefoxicy> Keybuk:  amuse yourself with this until I get back.  http://www.theonion.com/content/news/dollar_bill_on_floor_sends_wall
[16:45] <munckfish> cjwatson: oh you mean the memory requirements - yes I see good
[16:48] <bluefoxicy> Keybuk:  aside from me aborting a routine check of /dev/sda7, boot time was fast without that drive plugged in.
[16:48]  * bluefoxicy installs kernel update and newer udev.
[16:52] <cjwatson> munckfish: right
[16:59] <bluefoxicy> Keybuk:  no luck here.  Updated the kernel and udev and no good.
[16:59] <Keybuk> it's certainly a kernel issue
[17:02] <bluefoxicy> Keybuk:  still better than Microsoft on a 6 year release cycle.
[17:20] <munckfish> cjwatson: that desktop ports cd build anywhere near done? My bandwidth ain't so good at home and not long before I get my bus home :)
[17:26] <cjwatson> munckfish: dunno, my shell hasn't come back yet
[17:26] <munckfish> cjwatson: :S
[17:27] <cjwatson> a live filesystem build tends to take around 45 minutes, and I can't remember if the powerpc and powerpc+ps3 ones parallelise
[17:27] <cjwatson> so it could be an hour or so more
[17:27] <munckfish> cjwatson: that's cool, I'll bag em from home later
[17:27] <bluefoxicy> Keybuk:  confirmed the drive works by plugging it into another computer with 8.04.  http://photos-g.ak.facebook.com/photos-ak-snc1/v347/161/112/1033398210/n1033398210_168206_4776.jpg  :D
[17:27] <munckfish> I got the alternate one already
[17:36] <mdz> asac: I can reproduce bug 278095 here if I can be of help
[17:37] <glatzor> evening mvo
[17:38] <piquadrat> Any kernel devs around? I noticed a bug (launchpad #286285) which I consider to be quite serious. It fully loads the processor and grows kern.log, syslog and messages extremly fast.
[17:45] <asac> mdz: how?
[17:47] <mdz> asac: see the bug; it happens every time I run firefox to open a new tab in an existing window
[17:48] <asac> mdz: any idea when that started for you?
[17:49] <mdz> asac: I'm afraid not
[17:50] <piquadrat> "extremely fast"  is at a combined 1.3MByte/sec for all three logs, to be precise
[17:50] <mdz> asac: my best guess would be that char **environ is corrupted somehow
[17:52] <asac> mdz: could you please try at-spi and drop the memory leak patch there (e.g. 01_from_svn_fix_memory_leaks.patch)
[17:52] <mdz> asac: confirmed, there's an invalid pointer in char **environ
[17:52] <asac> (if that makes the other patches not apply, just drop all)
[17:52] <asac> hmm
[17:54] <asac> the dupes start on 1st october
[17:54] <asac> and that patch landed on 16th
[17:54] <asac> so thats not it
[17:54] <asac> there was an upload on 30th sep
[17:57] <mdz> asac: it looks like something called putenv() with a string which is no longer mapped into memory
[17:57] <asac> hmm firefox ;)?
[17:59] <mdz> asac: I think it could be caused by, e.g., a shared library calling putenv() and then being unloaded
[18:02] <pitti> mvo: can you please have a look at bug 288696?
[18:02] <mdz> asac: does firefox use putenv()?
[18:02] <asac> mdz: unfortunately, have to go now. thanks for getting that info so far.
[18:02] <asac> mdz: http://mxr.mozilla.org/mozilla/search?string=putenv
[18:02] <asac> mdz: also maybe http://mxr.mozilla.org/mozilla/search?string=PR_SetEnv
[18:03] <asac> (note: a bunch of code isnt in firefox/xulrunner that is searched on mxr)
[18:04] <asac> mdz: but the remove client is quite a tiny piece of software
[18:04] <asac> s/remove/remote/
[18:04] <james_w> asac: you might be able to reproduce if you turn on accessibility in GNOME
[18:05] <asac> james_w: good point ;) ... where?
[18:05] <asac> mdz: maybe its a bad idea to access environ ina g_atexit callback?
[18:05] <james_w> asac: /desktop/gnome/interface/accessibility
[18:05] <mdz> asac: I wondered
[18:05] <asac> mdz: i think we should try to get that env on startup
[18:05] <asac> and hope that its fixed then
[18:06] <james_w> asac: or System->Preferences->Assistive Technologies, and check "Enable assistive technologies"
[18:06] <james_w> asac: it will require a log out
[18:08] <asac> james_w: thanks. will try
[18:08]  * asac logs out
[18:12] <asac> james_w: mdz: ok so enabling assitive stuff triggers this. if you are not first i will try the workaround a suggested and maybe investigate whether putenv is used somewhere during a remote client run - over weekend
[18:13] <calc> i upgraded from rc today and now evolution doesn't know i have any email config!
[18:13] <calc> and i just finished setting up my filters, argh!
[18:14]  * calc brb, rebooting hoping the upgrade didn't kill his evolution completely
[18:14] <slangasek> mdke: right, I'm not suggesting it should be changed again for intrepid, but thank you for the bug pointer - I'm inclined to follow up and re-open, because the current "pronunciation" guide is useless to an English speaker
[18:16]  * calc trying to start evolution again, /me crosses his fingers
[18:16] <calc> argh!!!!!!!!!!!
[18:16] <calc> the setup assistant came up again
[18:18] <calc> seb128: heard from anyone that the new evolution update ate their setup?
[18:19] <seb128> calc: no
[18:19] <calc> hmm actually it doesn't look like it updated today
[18:19] <calc> i wonder how it made my setup vanish :\
[18:20] <calc> seb128: do you know where it stores the account settings?
[18:21] <seb128> calc: gconf
[18:22] <calc> seb128: do you know where in gconf: apps/evolution ?
[18:22] <seb128> yes
[18:22] <seb128> which is in .gconf on your disk
[18:22] <calc> ok
[18:22] <seb128> it has the server name, etc there but not the passwords, those are in the gnome-keyring
[18:22] <calc> its all gone
[18:22] <calc> :(
[18:23] <seb128> disk corruption?
[18:23] <seb128> try grepping in .gconf to see if that's still somewhere
[18:23] <calc> doubtful everything was working fine until i reinstalled
[18:23] <seb128> there is no reason an upgrade should change your user configuration
[18:23] <seb128> reinstalled? I though you upgraded?
[18:23] <calc> i did a reinstall, not just upgrade, yesterday, but after updating today and restarting evolution it lost all the data
[18:23] <calc> well both
[18:24] <seb128> you kept your user directory?
[18:24] <calc> 1. i reinstalled last night with rc, 2. setup evolution and filters etc 3. updated from rc to todays packages
[18:24] <calc> i completely reinstalled last night i just copied over a few things i needed
[18:24] <seb128> gconf being one of those?
[18:25] <calc> no just left it as it was, so yes i had to completely resetup evolution last night/early this morning
[18:25] <calc> but then after updating from RC files to todays files all the config went away
[18:25] <seb128> try grepping .gconf just to be sure but that's weird
[18:25] <calc> but it looks like evolution didn't even update
[18:25] <seb128> nothing touch user datas on upgrade
[18:26] <seb128> that's only the gconf config? nothing else
[18:26] <calc> grep -r -i gmail *  shows nothing and same for canonical
[18:26] <seb128> evolution didn't change between rc and now
[18:26] <calc> directly under .gconf
[18:26] <calc> yea, weird stuff, if it happens again i will try to look at it closer
[18:26] <calc> or if you hear any other reports maybe its not just my weird laptop ;-)
[18:27] <calc> i'm going to immediately backup evolution as soon as i am done this time :)
[18:28] <calc> at least all my filters are still there so i don't need to set them up again, just have to reassociate them to the right account once i resetup
[18:41] <mvo> pitti: re #288696 - are you working on this right now? (I see yiu assigned yourself)
[18:41] <mvo> pitti: (sorry for the late reply I was having dinner)
[19:43] <RainCT> kees: Hey. You said on http://pthree.org/2008/10/23/shadowed-passwords/ that $6$ is the default for Intrepid, but I have $1$ here (clean install)
[19:43] <RainCT> kees: or was the change done just a few days ago?
[19:45] <kees> RainCT: well that's highly strange.
[19:46] <kees> what does "grep pam_unix.so /etc/pam.d/common-password" show?
[19:46] <kees> RainCT: ^^
[19:47] <RainCT> kees: password[success=1 default=ignore]pam_unix.so obscure sha512
[19:47] <RainCT> kees: but /etc/shadow says  rainct:$1$.....
[19:48] <kees> RainCT: interesting.  well, if you change your password (or add a new user) it should switch to $6$.  I'll have to dig into the installer -- there must be something in there.
[19:49] <RainCT> kees: oh, right, it changed now
[19:51] <kees> evand: any idea how the installer builds the initial user's password hash?
[19:52] <Mithrandir> I think it might be using chpasswd or perl
[19:52] <Mithrandir> I can't remember, though
[20:02] <lool> Good WE folks
[20:27] <calc> cjwatson: bdmurray managed to reproduce the 999 issue
[20:28] <calc> cjwatson: or rather he saw it earlier this past week
[21:04] <maxb_> The X ABI issue which meant Intrepid needed a new fglrx... does that also cut the other way, and mean the old nvidia drivers are no longer compatible with the new X?
[21:04] <maxb_> I just tried to downgrade to nvidia-glx-96 to see if it affects some graphics issues I was having, and got ABI errors.
[21:05] <maxb_> In which case, the old nvidia-glx-NN packages probably need to be pulled from Intrepid?
[21:06] <bryce> maxb_: yes, the two oldest -nvidia's have the same problem
[21:06] <maxb_> Not much point shipping them in Intrepid, then?
[21:06] <bryce> maxb_: I thought superm1 or tseliot had already removed them but you may want to ask them specifically
[21:07] <maxb_> No, they have not been removed
[21:07] <bryce> I'm fairly sure there is code in place to move upgraders with those drivers over to -nv
[21:07]  * maxb_ wonders if mvo is around for a quick ack/nack on that question.
[21:07] <bryce> maxb_: no I mean you should ask them for why they were not removed
[21:07] <superm1> bryce, it sounds like those two packages need to be explicitly not providing the new abi
[21:08] <superm1> like how tjaalton had fglrx for a little bit
[21:08] <superm1> they're sticking around I believe in case NV decides to fix them so that they are SRU'able
[21:08]  * tseliot nods
[21:08] <maxb_> The problem at the moment is that the "Hardware Drivers" applet will happily let you switch to them
[21:09] <tseliot> maxb_: https://bugs.launchpad.net/ubuntu/+bug/288662
[21:10] <tseliot> it was fixed in jockey 0.5~beta3-0ubuntu5
[21:10] <maxb_> aha, it's all in hand
[21:15] <mvo> maxb_: yes
[22:27] <leagris> hello
[22:27] <leagris> Yet again, latest upgrade killed french locales for Firefox 3.0.3
[22:28] <leagris> that's enough of this, sorry to rant, I'm tired. How can I help non english speaking friends family old aunt with this. To this regard it realy suck.
[22:29] <leagris> that is the second time in 3 months the french translation for firefox dissepear
[22:29] <leagris> Hardy heron is supposed stable, isn't it ?
[22:40] <persia> leagris, There's a bit of a delay between the publication of an updated package and the publication of the updated language packs.  If you want to be sure to avoid that, wait until there is a language pack update when upgrading.
[22:41] <persia> If you have any ideas how to better coordinate updates of translations for updated packages, we'd be glad to hear it, but for now, there's just no easy way to do it.
[22:42] <leagris> persia, indeed. Each time I show the update icon on task bar, I click update and voila. My old aunt do the same because I told her Ubuntu has to be kept up to date to be ok and secure ;D
[22:42] <ScottK> persia: If we didn't have a process that fundamentally seperated packages from translations then it might work out better.
[22:44] <slangasek> even FF upstream fundamentally separates the software from the translations, though, so I don't think you'll get much help there
[22:44] <slangasek> also, they don't use gettext --> fail
[22:44] <leagris> thanks all, sorry for writing my frustration here
[22:46] <persia> ScottK, True, although I like the extra megabytes for an image.
[22:47] <ScottK> persia: The current system has advantages, but it has a lot of negative too.  In Kubuntu there are still obscure languages like German for which there is not yet a language pack (at least last I heard it was still pending).
[22:48] <persia> ScottK, Isn't that just a problem for intrepid?  Has there been a history of it being broken?  (And yes, I agree it's *very* bad)
[22:50] <pochu> do firefox stable updates break translations?
[22:50] <ScottK> Well template acceptance was late (which is a common problem) but that masked a specific problem with the KDE4 templates that then got us where we are now.
[22:50] <ScottK> So it has some unique factors, but they only aggravated a generally fragile situation.
[22:50] <persia> pochu, All SRUs break translations.
[22:51] <slangasek> pochu: firefox's l10n model is special
[22:51] <slangasek> persia: er, no?
[22:51] <persia> pochu, Or rather, all SRUs in main do.  firefox is *especially* bad, for various reasons.
[22:51] <persia> slangasek, No?  Do you mean no because not all SRUs include string changes, or is there a mechanism I don't understand?
[22:52] <slangasek> Normal packages only break translations when they break the source strings
[22:52] <slangasek> firefox is special because its translations are bundled together with other stuff that breaks across minor revisions
[22:53] <ScottK> I'm starting to feel we might be better off just to enable the upstream update method for FF and leave it at that.
[22:53] <persia> So if people used konqueror and epiphany, they'd have less translation skew pain?
[22:53] <persia> ScottK, That's a very slippery slope.
[22:53] <ScottK> persia: Well they are pretty uniquely hard to deal with.
[22:54] <superm1> pitti, have you been setting tags at all for non critical things in hal-info to make sure that you remember to close out bugs when the fixes land upstream?
[22:54] <persia> ScottK, Well, yes, but allowing *anything* to have third-party updates seems dangerous to me.
[22:55] <ScottK> True.  Perhaps we shouldn't ship it all then.
[22:55] <slangasek> persia: yes, konqueror and epiphany have less translation skew pain.  At a minimum, anything that uses gettext for translation gets the benefits of partial translation for those source strings that haven't been changed.
[22:55] <ScottK> My choice (if it were up to me) would be to turn the branding off and treat it like a normal package.
[22:56] <ScottK> Also when we patch those packages it's usually our patch, not an entire upstream release.
[22:57] <persia> leagris, As a partial solution for today, you might try the alternate browsers then.
[22:59] <leagris> persia, I can use firefox in english, not realy impacting for myself. I just got a coll from my aunt telling me somthing like "help, I don't know what I did wrong but my firefox speaks english and its confusing. Would you please come and fix it when you are available?"
[23:01] <persia> leagris, I understand.  Short term fix is epiphany for Ubuntu Desktop and konqueror for Kubuntu Desktop.  Longer term fix is waiting for firefox to go back to french.
[23:02] <leagris> thanks all for your kindness
[23:02] <leagris> especially persia
[23:03] <leagris> have a nice weekend
[23:32] <wgrant> Can I tell do-release-upgrade that I know what I'm doing and that it should get its hands off my damn sources.list?
[23:33]  * davidm is away: 
[23:39] <mvo> wgrant: is your sources.list all intrepid already? it is a bit stupid when it comes to this, there is no such option at this point, you could hack it in though
[23:50] <calc> how do i switch to the guest user in intrepid?
[23:50] <calc> i need to test a bug
[23:52] <persia> fusa, as long as you have gdm-guest-session installed.
[23:52] <calc> so it doesn't work with just regular login?
[23:53]  * calc just added the fusa to test it out
[23:53] <persia> Oh, should work for that too, but that's the answer to "How do I log into a guest user session in intrepid"
[23:53] <persia> For switching, you want fusa.
[23:53] <calc> ok