[00:41] <bdmurray> james_w: that person really did have a package for me
[00:42] <james_w> wow
[12:28] <thekorn> hmm, is wiki.ubuntu.com slow/down for anybody else, or is it just me?
[12:29] <jpds> thekorn: Fails with a Squid error here.
[12:30] <thekorn> right, same here
[12:33] <jpds> thekorn: Might want to tell #canonical-sysadmin - but I think that they're on holiday.
[12:37] <thekorn> jpds, ok, it magically works again now,
[12:37] <jpds> thekorn: GReat.
[12:37] <jpds> great*
[15:29] <skorasaurus> hi, I accidentally created a new 'project' in launchpad. https://bugs.launchpad.net/easytag
[15:29] <skorasaurus> I was triaging a bug for easytag, and I looked back on it today, and saw that was created page was created. I don't know if that should have been created.
[15:30] <skorasaurus> because there's also this page - https://bugs.launchpad.net/ubuntu/+source/easytag
[15:31] <thekorn> skorasaurus, I think it is all right, you "created" this project when you linked this bug to the sf bug tracker
[15:32] <skorasaurus> thekorn, okay, thank you.
[15:43] <skorasaurus> i have a question: why does the status of a bug on launchpad not correspond with the upstream status ? For example, https://bugs.launchpad.net/brasero/+bug/187657
[15:44] <Ryan52> because upstream and ubuntu don't always agree? it may be more important to one than another?
[15:44] <skorasaurus> on the upstream (gnome's bugzilla), it is marked [unconfirmed, normal]
[15:55] <charlie-tca> skorasaurus: the bug is triaged for Ubuntu, not for upstream.
[15:56] <charlie-tca> Sometimes it takes a while for upstream status to catch up on launchpad
[16:01] <skorasaurus> k
[17:50] <hggdh> skorasaurus, upstream status depend on upstream work. A triaged bug on LP will still need to be confirmed upstream
[17:51] <hggdh> these are completely separated BTSs; it may be that upstream has some other requirements before confirming, it may be a dup, etc
[17:54] <persia> There are also many cases where a bug is fixed upstream, but still present in Ubuntu, or vice-versa.
[17:58] <hggdh> BTW, 'BTS' means Bug Tracking System
[22:30] <Rocket2DMn> ok guys, im finishing triage on bug 308978 but i cant decide if its xorg or linux
[22:30] <Rocket2DMn> or even hal i suppose
[22:34] <charlie-tca_> Suspend to ram is acpi-support, isn't it? Otherwise, it is linux, since it happens after suspend
[22:34] <Rocket2DMn> its like a nightmarish mix of all of the above
[22:34] <Rocket2DMn> a usb device that works before suspend, but not after
[22:35] <Rocket2DMn> well it sorta works, just doesnt recognize the language i guess
[22:35] <Rocket2DMn> I guess I should ask if it works after the user restarts X after a resume
[22:36] <Rocket2DMn> if it doesnt, then its not a X problem
[22:38] <charlie-tca_> Is it hibernate being called suspend? If so, it is linux
[22:38] <charlie-tca_> as in the kernel team works that
[22:38] <Rocket2DMn> its not hibernate, its suspend to ram
[22:38] <Rocket2DMn> (standby)
[22:39] <Rocket2DMn> thats initially why i set the bug to xorg instead of linux
[22:48] <charlie-tca_> That should be acpi-support then
[22:48] <charlie-tca_> acpi-support is the package for suspend to ram bugs
[23:09] <Rocket2DMn> ok thanks charlie-tca_
[23:12] <crimsun> err, that's not entirely correct. we need to update it.
[23:13] <crimsun> acpi-support and pm-utils are scripts. if it's a kernel problem, the source package affected needs to be linux.
[23:13] <crimsun> if we're failing to twiddle something in the scripts, however, yes, either acpi-support (old) and/or pm-utils (new).
[23:15] <crimsun> (the situation becomes even more hairy when one considers hal-info)
[23:16] <Rocket2DMn> crimsun, the thought had crossed my mind with hal
[23:17] <Rocket2DMn> have a look at bug 308978 and let me know what package you think is appropriate
[23:17] <Rocket2DMn> the problem with the usb kb only appears after a suspend/resume
[23:19] <crimsun> it's a linux bug.
[23:19] <crimsun> nothing in acpi-support, pm-utils, or hal-info twiddles keyboard locales [because there's no such functionality there]
[23:20] <crimsun> also, note that the reporter's laptop keyboard works fine
[23:21] <crimsun> the symptom is only reproducible using a usb keyboard _post_-resume-from-*
[23:21] <crimsun> the other possibility is that there's a bios issue; perhaps ask the reporter if he's running the appropriate (latest?) bios
[23:25] <LimCore> hi.. kmail crashes ALWAYS when downloading.. how epic is that lol :/
[23:25] <crimsun> it's known
[23:26] <LimCore> the one in 8.10 right? oh meh.. :/
[23:26] <LimCore> how to have a version that does NOT crash now then? im on 8.10
[23:27] <joumetal> does bug 312554 have enough information?
[23:28] <crimsun> LimCore: i really have no idea; most mail clients really frustrate me. i tend to use mutt or some smartphone.
[23:29] <LimCore> btw... why we do not have an OBVIOUS field like ubuntu version and app version in the bug tracker?
[23:29] <LimCore> like.. [ubuntu 8.10] [amd64]  [kmail 4.2.1-...] etc.  most can be auto-filled from user agent
[23:30] <crimsun> LimCore: well, apport does include that. it's a question worth posing on ubuntu-devel-discuss
[23:31] <charlie-tca_> joumetal: the video card from lspci perhaps? Also, what version of ubuntu?
[23:31] <crimsun> joumetal: if that's as much of the trace as you can capture, then unfortunately, yes
[23:31] <crimsun> joumetal: it'd be better if you could grab the entire kernel ring buffer up to that point, perhaps via serial console