=== rsalveti_ is now known as rsalveti === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [16:02] it's a shame there doesn't seem to be a way to link sourceforge bug reports into launchpad [16:04] how so? [16:04] penguin42, if there's an upstream tracker i think it can be linked? [16:04] if the upstream project is set to use external stuff [16:04] and then you provide a link... [16:04] no? [16:07] but if there is no upstream project in lp, if it's just a bug in an ubuntu package for which the upstream is in sf? [16:07] good question. [16:07] i'd just link "upstream"'s bug as a comment [16:08] so its somewhere in the bug it was upstreamed. [16:08] but... that's if it doesn't exist in LP [16:09] yeh, I'm just going through universe type things that haven't seen any updates in years, some of them have sourceforge projects with bug trackers [16:10] penguin42, were they synced form Debian? [16:10] from* [16:10] i know of a few upstream projects that only listen to the Debian BTS and don't bother chekcing Ubuntu's [16:11] TheLordOfTime: Yeh, although I think in a lot of these cases the upstreams are pretty much dead [16:11] which package if I might ask? [16:12] TheLordOfTime: bug 376859 [16:12] (I know there's one package, display-dhammapadda, of which i'm apparently their go-to bugcontroller, which was recently taken over by someone, and its upstream tracks debian, LP, and fedora) [16:12] Launchpad bug 376859 in cccc (Ubuntu) "CCCC crashed on AMD64" [Medium,Triaged] https://launchpad.net/bugs/376859 [16:12] penguin42, https://launchpad.net/ubuntu/+source/cccc [16:12] there's changes to the package over time... [16:12] albeit minor changes... [16:12] and looks like Colin has created an upstream bug for it, 3 years ago https://sourceforge.net/tracker/?func=detail&aid=2880497&group_id=7763&atid=107763 [16:12] ah okay. [16:12] if upstream's dead, well... [16:12] then upstream's dead :P [16:13] was this imported/checked from Debian? [16:13] yep, they're all debian imports [16:13] but I've got a small collection of others as well [16:13] wonder if this is reported there. [16:14] didn't see this one reported in debian [16:14] may want to consider reporting it there. [16:14] (just so debian's aware the bug exists) [16:14] since it appears these're debian imports, so a fix'd hit Debian before it hits Ubuntu. [16:14] but... [16:14] * TheLordOfTime yawns [16:14] bleh, i need more coffee. [16:15] TheLordOfTime: It looks like Colin is the maintainer for the package anyway, but hey Erwan put a bug in there 3.5 years ago - it seems a shame not to merge it [16:15] mhm [16:15] penguin42, any idea how widely used this is? [16:15] if upstream's dead, well... [16:16] nope, no idea [16:16] "C and C++ Code Counter, a software metrics tool" [16:16] nod [16:17] I've been doing a bunch of universe fixes for crashers lately - but then I started looking at the patch queue, there's about 1500 bugs with patches that aren't going anywhere === yofel_ is now known as yofel [23:37] Could someone explain to me why bug #225732, a kernel null-ptr dereference resulting in system crash, is only assigned 'medium' priority? [23:37] Launchpad bug 225732 in linux (Ubuntu) "Unable to handle kernel paging request at ffff88087eee2ff8 RIP:; RIP: e030:[] [] :cpufreq_stats:cpufreq_stats_update+0x40/0x70" [Medium,Confirmed] https://launchpad.net/bugs/225732 [23:38] * penguin42 looks [23:38] aiee, i meant bug #1089794 [23:38] Launchpad bug 1089794 in linux (Ubuntu) "kernel null pointer dereference on dell pe r210s" [Medium,Confirmed] https://launchpad.net/bugs/1089794 [23:38] oh an ancient one as well [23:39] oh [23:42] garyseven: https://wiki.ubuntu.com/Bugs/Importance are the guidelines, I personally would have set as a High, but Joseph owns a lot of the kernel stuff so I'll bow to his judgement [23:44] yeah, i read that. i thought that it should be high, as well, as it "Renders essential features or functionality of the application or dependencies broken or ineffective" [23:44] or possibly critical, in that it "Crashes the entire operating system" [23:44] nod, or I would have quoted the has a severe impact.... [23:46] garyseven: The problem to some degree is that every oops ends up being a critical if you aren't careful, so you then don't end up separating the 'oopses for a small number of people/rare occasions' from the oopses for most people [23:50] I don't understand. This bug would affect *all* people running a similar configuration on identical hardware. I can reproduce it on over a dozen servers. [23:50] It is a show-stopper, in that it renders the systems completely unusable. [23:51] The only real reason more people aren't affected is that it doesn't exist upstream, or in Precise. [23:51] garyseven: ok, but you agree that say a bug that nuked the installation should be higher, or one that happened for most users should be higher? [23:52] Not really. I don't see the benefit of being able to complete an installation only to boot into an unsusable system. [23:52] garyseven: Most people using Quantal aren't hitting that oops [23:52] And I suspect that the only reason more users aren't affected is because most users only take LTS releases. But I'd really not have to wait until 14.04 to see this fixed. [23:53] garyseven: I realise for you that doesn't help, but I'm just saying in the scale of things there are worse bugs out there that affect more people [23:53] garyseven: Looking at the logs, can I ask, are you using Xen? [23:53] Yah. [23:54] garyseven: Certainly the 2nd part of the oops looks xen specific, so probably only a small proportion of users use xen and thus hit it; it's a bit harder to tell whether the first part is due to xen [23:55] I've only seen it happen under xen. But, it's still a kernel oops, Xen remains up and responsive during and after. [23:59] garyseven: Anyway, so given you've found a version that it works on, what Joseph will probably ask you to do is to try a few kernel versions in between to see which one fixed/broke it