=== kermiac_ is now known as kermiac
=== kermiac is now known as kermiac_
=== kermiac_ is now known as kermiac
[08:44] <vish> yofel_: could you ping me when you are available for triaging a few kubuntu bugs ? :)
[10:35] <andersk> Bug 586711 had importance High before being marked as a duplicate of bug 546794.  In that case, can someone set the latter to importance High as well?
[10:35] <ubot2> Launchpad bug 586711 in bash-completion (Ubuntu) "[Maverick] Errors whenever opening a terminal (dup-of: 546794)" [High,Triaged] https://launchpad.net/bugs/586711
[10:35] <ubot2> Launchpad bug 546794 in bash-completion (Ubuntu) (and 1 other project) "[revert, causes errors] Smarter lib* aware autocompletion? (affects: 15) (dups: 3) (heat: 110)" [Undecided,Confirmed] https://launchpad.net/bugs/546794
[12:52] <SalmonSam> could anyone help me with running nautilus through valgrind?
[15:18] <pascalFR> any clue on this Bug #587226
[15:18] <ubot2> Launchpad bug 587226 in virt-manager (Ubuntu) "virt-manager cannot start module libvirt not found (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/587226
[15:24]  * wise_crypt is away: need a rest, tired looking a fast channel :)
[15:25] <nigelb> wise_crypt: if thats an auto-away, can you please disable it.
[17:51] <MichaW> Hi?
[17:51] <crimsun> yes?
[17:52] <MichaW> I raised a bug in Ubuntu a few days ago and was wondering if there's any way to get it looked at.
[17:52] <MichaW> Upstream already fixed it (after we notified them).
[17:53] <nigelb> bug #?
[17:53] <MichaW> https://bugs.launchpad.net/ubuntu/+source/gnustep-base/+bug/585179
[17:53] <ubot2> Launchpad bug 585179 in gnustep-base (Ubuntu) "gnustep - parsing of XML property lists broken (affects: 1) (heat: 6)" [Undecided,New]
[17:53] <MichaW> Reason being we're getting ready to release a new version of Oolite and this bug affects it on Lucid.
[17:54] <nigelb> do you have an upstream bug number or commit ?
[17:54] <MichaW> https://savannah.gnu.org/bugs/index.php?29955
[17:54] <MichaW> Upstream already mentioned they won't backport the fix to gnustep-base1.19
[17:54] <MichaW> So Debian/Ubuntu would have to do so. Unless they are prepared to upgrade gnustep-base to 1.20 in Lucid.
[17:54] <nigelb> ok, then its get murkier
[17:55] <nigelb> unless its an isolated patch that fixes this particular bug, its difficult
[17:55] <MichaW> Looking at their commit diff, it's very isolated.
[17:55] <crimsun> gnustep-base has a ton of reverse deps, so upgrading to 1.20 seems rather a long shot
[17:56] <MichaW> That's what I thought :)
[17:56] <crimsun> it'd be much more feasible to cherry-pick fix(es) if possible
[17:57] <nigelb> ugh, I hate cvs
=== edson is now known as ecanto
[17:57] <MichaW> I can make (&test) a suitable patch if this would assist.  Just wondering what the normal turnaround-time is for bugs in Ubuntu.
[17:58] <MichaW> Incidentally, the patch I submitted upstream was NOT used by upstream.
[17:58] <vish> heh
[18:00] <siefca> Hi, is the problem with mountall and encrypted partitions a common problem in Lucid? (Initialization hangs just after LUKS partition had been mounted and I need to press 'S')..
[18:00] <nigelb> MichaW: if you're willing to do the work, the turn around time is lower
[18:01] <aburch> But it could still take forever :/
[18:01] <MichaW> nigelb: Ok.  We'd be pretty interested in getting this fixed as Oolite runs fine on all versions of Ubuntu prior to Lucid. In fact, the version of Oolite included in the normal Ubuntu repositories is broken by this bug too.  And most likely other gnustep based software.
[18:02] <nigelb> aburch: +1 to that ;)
[18:02] <nigelb> MichaW: ok, first thing would be fix it for maverick.  Then you can propose an SRU for this bug for lucid.
[18:03] <nigelb> Unless its fixed in maverick, its tough to get a fix for lucid.
[18:03] <MichaW> Yikes. Even though Lucid is a LTS?
[18:04] <MichaW> Ok, anyway I'll see about getting a patch for maverick together this weekend then.
[18:04] <nigelb> You have to understand that if things go wrong, it might introduce a very bad regression
[18:05]  * MichaW nods.
[18:05] <MichaW> Looks like regression testing failed to pick it up in the first place though :) (By upstream as well as distros).
[18:06] <nigelb> So, SRU team needs a lot of documentation.  How it works.  If it introduces regressions, etc
[18:06] <penguin42> there is a 10.04.1 due sometime, there's an OOo bug I have that's been marked for that
[18:06] <nigelb> I would suggest pushing it to a PPA for lucid, so you can test and others can test and check if there are regressions.
[18:07] <nigelb> !sru
[18:07] <nigelb> err.. what was the one for sru?
[18:07] <hggdh> MichaW: why wass the patch rejected by upstream?
[18:08] <hggdh> httpsdon't remember the fatoid, but here's the source: https://wiki.ubuntu.com/StableReleaseUpdates
[18:08] <MichaW> hggdh: I just reverted their changes which introduced the bug.  They decided to fix it in their changes rather than revert to their original code.
[18:09] <nigelb> thanks hggdh :)
[18:09] <nigelb> MichaW: the custom library thing?
[18:09] <hggdh> MichaW: oh, so it was just a revert. Be sure to state what your patch is doing, and what are the consequences
[18:10] <MichaW> nigelb: Yes. They were using it anyway in case the xml2 parser failed. Apparently there's some bad XML files from Apple which don't parse properly using a 'real' XML parser.  Their custom parser works for that.
[18:10] <nigelb> MichaW: ah, ok
[18:10] <MichaW> hggdh: The patch I'd prepare for Ubuntu would be their changes, not the changes I supplied to them.
[18:11] <nigelb> Just so that you know SRU needs a *lot* of ground work, so be prepared with everything thrown at you :)
[18:11] <hggdh> MichaW: OK, even better
[18:11] <MichaW> Well, it needs fixing :) So I'll see if I can work my way through the bureaucracy.
[18:12] <penguin42> what's the right thing to do with a bug that looks valid but is obviously against the wrong package?
[18:12] <nigelb> Its not bureaucracy per se.  Just making sure that things are going to be fine after this patch.  The last time I did an SRU, I introduced a bad regression and had to run around a bit
[18:12] <hggdh> set it to the correct package, penguin42
[18:13] <nigelb> penguin42: ask which is the right package :)
[18:13] <penguin42> hggdh: It's a suspend/resume display issue so I guess either linux or the xserver, but since he's reported it against firefox it has no useful information on the hardware
[18:13] <MichaW> nigelb: Yes, I understand. Just the 'be prepared to handle everything thrown at you' comment sounded like there might be a lot of 'paperwork' involved.
[18:14] <penguin42> is there a tag for suspend/resume issues?
[18:17] <hggdh> penguin42: IIRC it will be against linux. Please ask the OP to 'ubuntu bug linux <bug#>'
[18:17] <penguin42> OP?
[18:18] <hggdh> penguin42: or just reset the package to linux, and the OP runs 'ubuntu-bug <bug#>´
[18:18] <hggdh> OP == Oroginal Poster
[18:18] <hggdh> Original, even
[18:18] <hggdh> the reporter, I mean
[18:18] <penguin42> ah, I didn't know you could run ubuntu-bug with the number
[18:18] <hggdh> darn! I should have respected Saturday
[18:19] <hggdh> cannot write anytihng
[18:19] <hggdh> hell
[18:19] <hggdh> hey nigelb, how did the python go?
[18:23] <MichaW> nigelb: One more question.  Do I raise a separate bug for maverick, and attach my proposed patch to that?
[18:24] <penguin42> does anyone know what size size_t is on 32bit?
[18:24] <hggdh> MichaW: raise the bug to Maverick, and nominate it for Lucid. When Maverick gets the fix, lucid will be in for SRU
[18:24] <hggdh> penguin42: 32?
[18:25] <penguin42> that's what I'd assume
[18:25] <nigelb> hggdh: apparently, running from subprocess always makes problems.  going for a new approach now
[18:26] <MichaW> nigelb, hggdh: Many thanks for your assistance with this.
[18:26] <nigelb> MichaW: no problem  :)
[18:27] <nigelb> hggdh: I'm going to get python to send the mail to debian btw directly
[18:27] <nigelb> bts even
[18:27] <nigelb> arrg, can't type today I guess
[20:35] <stenten> Question: Let's say I tell someone to enable Apport and recreate their resume X crash. Will Apport allow the report to be appended to the bug report, or will it create a new one?
[20:45] <penguin42> stenten: apport-collect can add, not sure if that's the best way
[20:58] <dgtombs> stenten: no, it'll create a new report
[20:58] <dgtombs> but in that case it might be better to file the new one and made an old one a dupe
[20:58] <dgtombs> anyone here into kernel triaging?
[21:04] <dgtombs> well, whenever anyone shows up: bug #376793 has been tested in upstream kernel and doesn't exist. according to KernelTeamBugPolicies, i think it should now go into the Triaged status
[21:04] <ubot2> Launchpad bug 376793 in linux (Fedora) (and 2 other projects) "HP 2140 Lid Close Not Detected (affects: 16) (heat: 110)" [Unknown,Unknown] https://launchpad.net/bugs/376793
[21:05] <dgtombs> i also suggest that the importance is Low and not Medium
[21:07] <BUGabundo> evening slackers & weekenders
[21:10] <SalmonSam> I'm trying to get some information about a memory leak in nautilus with valgrind however the log doesn't appear to contain much information ( http://paste.ubuntu.com/441466/ ) , do I need to install more debug symbols?
[21:41]  * wise_crypt is away: sleeping 
[21:46]  * wise_crypt is back (gone 00:05:37)
[21:47]  * wise_crypt is away: 
[22:24] <stenten> What package should I assign bugs to where the keyboard is unresponsive on boot?
[22:25] <stenten> I figured it was either 'linux' or 'xorg-server'
[22:35] <penguin42> stenten: If it isn't just X then I'd say linux
[22:35] <penguin42> stenten: Can you ssh in?
[22:39] <stenten> penguin42: Not sure. I'm just assigning bugs that don't have any packages.
[22:39] <penguin42> can you show me the bug?
[22:40] <stenten> #583613
[22:41] <stenten> bug #583613
[22:41] <ubot2> Launchpad bug 583613 in ubuntu "Upgrading super os 9.10 to 10.04 will not reboot from harddrive after install (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/583613
[22:42] <penguin42> stenten: It says command line so I think it is linux
[22:42] <penguin42> it sounds like X didn't start
[22:42] <stenten> Ah. Because X isn't running if it spits you into a command line?
[22:43] <penguin42> however, it's possible X started and crashed
[22:43] <penguin42> yeh
[22:44] <stenten> My thought was that even if it's an X issue, it'd be a KMS issue so it'd be linux anyway.
[23:20] <penguin42> not necessarily, it could just be a duff X driver - KMS only switches modes, it doesn't actually do most drawing
[23:22]  * penguin42 gently wonders about the origin of the phrase 'mode' for a screen resolution - I know the old Acorn machines had it back in '82 but was that the 1st? (OT)
[23:43] <RunePhilosof> Would it be acceptable to sru a package even though the fix is rolling back the fix for another (less important) bug?
[23:47] <lifeless> case by case