[00:38] <sectech> Found a workaround....
[00:38] <sectech> pci=nomsi
[00:39] <sectech> I am not into kernel options or hardware much so I don't really know how it will impact my system...
[00:39] <sectech> but it works at least
[00:47] <zyx386> hi
[00:47] <secretlondon> hi
[00:47] <zyx386> is the bug in gedit fixed or in Snipets plugin?
[00:48] <zyx386> you most manual add shortcut for tags list
[00:48] <secretlondon> zyx386, do you know what number it was?
[00:48] <zyx386> wait
[00:51] <zyx386> 136876
[00:51] <secretlondon> bug #136876
[00:52] <zyx386> isnot fixed
[00:52] <zyx386> that worked no more
[00:52] <zyx386> http://www.youtube.com/watch?v=yuAR6NxiEgQ
[00:53] <zyx386> you most add manual the shortcute
[00:53] <secretlondon> zyx386, are you using gutsy or hardy?
[00:53] <zyx386> hardy
[00:54] <secretlondon> is it the same bug? I have no idea how that is supposed to work
[00:54] <zyx386> i report new bug
[00:55] <secretlondon> zyx386, okay. I do not know the program so I cannot say if you have the same bug
[01:02] <zyx386> i do it :)
[01:02] <zyx386> bug #228006
[03:35] <no0tic> bug 478135
[03:35] <secretlondon> bug #478135
[03:35] <no0tic> secretlondon, thanks
[03:35] <no0tic> uhm, probably it is not on lp?
[03:35] <secretlondon> waits for the bot..
[03:36] <secretlondon> not one of our bugs?
[03:36] <no0tic> trying to update util-linux apt-listbugs lists two bugs on it
[03:36] <no0tic> #478135 - util-linux: CVE-2008-1926 argument injection passed to audit (Fixed: util-linux/2.13.1.1-1)
[03:36] <no0tic> #479131 - util-linux: hwclock always uses UTC regardless of the config in /etc/default/rcS
[03:36] <no0tic> I don't know where they are reported
[03:37] <secretlondon> I think ubottu should have responded even if it's not our bug
[03:39] <greg-g> for all util-linux bugs: https://bugs.launchpad.net/ubuntu/+source/util-linux/
[03:40] <secretlondon> debian bug for the first one
[03:40] <secretlondon> http://groups.google.se/group/linux.debian.bugs.rc/browse_thread/thread/157a0f5c82bba92d?fwc=1
[03:40] <secretlondon> and for the second (found via google)
[03:41] <secretlondon> http://news.gmane.org/group/gmane.linux.debian.devel.bugs.general/last=/force_load=t
[03:41] <greg-g> ah yeah, they aren't in Launchpad
[03:41] <no0tic> thanks secretlondon, I wonder if ubuntu package is affected too, probably it is not
[03:42] <secretlondon> for the first one with the cve we should def check
[03:44] <secretlondon> we have a list of cve bugs
[03:45] <greg-g> according to http://security-tracker.debian.net/tracker/CVE-2008-1926  it was fixed in 2.13.1-3, we have -5
[03:46] <greg-g> wait, that might be wrong...
[03:47] <greg-g> sid has 2.13.1.1-1, hardy-updates has 2.13.1-5ubuntu2
[03:47] <no0tic> http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commitdiff_plain;h=8ccf0b253ac0f4f58d64bc9674de18bff5a88782
[03:48] <no0tic> to verify the problem try to login appending addr=xyz.com
[03:50] <no0tic> our package doesn't seem to be affected
[03:52] <greg-g> good deal
[06:55] <mr-russ> How might I further triage https://bugs.launchpad.net/php/+bug/218891
[07:37] <ligemeget> rpedro_: I've tried forwarding bug 117382 upstream - am I doing it right?
[07:41] <rpedro_> ligemeget: I'm probably not the person your looking for? :)
[07:41] <ligemeget> Damn, where's the other Pedro, then? :)
[07:42] <ligemeget> Oops, I was looking for pedro_ :D
[07:47] <ligemeget> Q: What to do with a bug like bug 152657 ?
[07:56] <ligemeget> anyone?
[07:58] <ligemeget> hej awen_
[07:59] <awen_> hey ligemeget
[09:31] <ogra> james_w, i do all the merges with my name next to it on merges.ubuntu.com, so yes, i did tuxpaint, sadly there is some mess with the .desktop file i need to clean up to fix a ftbfs
[09:32] <james_w> ogra: cool, thanks.
[09:33] <ogra> i actually wanted to ask secretlondon if she has anythink that i consider for SRU in hardy for the tux* stuff (she'S so deep into it :) i trust her more with these packages than myself )
[09:33] <ogra> *that i should consider
[09:44] <wolfger> good morning, bug squishers
[09:44] <ligemeget> morning
[09:44] <wolfger> I'd like to convert https://answers.launchpad.net/ubuntu/+question/4272 to a bug... any suggestions?
[09:45] <wolfger> is that a kernel issue?
[09:46] <james_w> wolfger: looks like one to me, but I'm no kernel expert.#
[09:46] <james_w> looks like the sort of thing that may already have a bug reported, I don't know.
[09:49] <lucent> wolfger: USB support kind of sucks, I mean generally
[09:49] <lucent> I know you're looking for a decision on whether it's a kernel bug or not
[09:49] <lucent> In my experience, this is most definitely a kernel bug, or malfunctioning hardware
[09:49] <lucent> it doesn't look like user error to me
[09:50] <lucent> so, rule out hardware error first
[09:51] <wolfger> well, the same hardware worked for me on Gutsy
[09:51] <lucent> wolfger: one particular USB keyboard I own on a certain USB powered hub, will cause these messages on my own computer
[09:51] <wolfger> only after upgrading to hardy did I have this issue
[09:51] <lucent> it only happened since a kernel update sometime last year
[09:51] <lucent> also for me, my media reader stopped working completely since a kernel update 2 years ago
[09:52] <lucent> I've been too lazy to follow up with LKML about this
[09:52] <wolfger> and my issue is slightly different from the one in the question, but the same solution fixed me, so... same issue
[09:52] <lucent> yeah
[09:52] <lucent> what you'd have to do is find the regression
[09:52] <lucent> I don't think another person will do that work for you
[09:52] <wolfger> I should probably search for an existing bug on this, though. there probably is one
[09:53] <wolfger> alright, thanks
[10:50] <afflux> morning
[10:51] <thekorn_> tach afflux
[11:00] <qense> hello
[11:03] <afflux> morning qense and thekorn
[11:03] <thekorn> hey qense
[11:06] <qense> is hardy doing well? (low number of critical bugs?)
[11:15] <afflux> I didn't hear much complaints from my friends, except that one onboard network card just doesn't work.
[13:36] <pedro_> hey folks today is hug day so feel free to grab any bug out the list: https://wiki.ubuntu.com/UbuntuBugDay/20080508
[14:05] <sectech> is someone around that can review a bug for me? bug#227397... I am currently triaging it and I'm not sure what package to assign it to...
[14:05] <sectech> It has nothing to do with the title, I am changing that now
[14:28] <norsetto> sectech: use bug 227397 so that ubottu can give us the link
[14:28] <sectech> sorry about that.
[14:30] <sectech> norsetto,  I won't know until the reporter answers the latest questions I posted but this looks like it could be directly related to the nvidia non-free driver... In which case we really can't do too much about.
[14:30] <sectech> it
[14:31] <norsetto> sectech: we can report it upstream though
[14:32] <sectech> norsetto,  if it does seem like it is the case is there anything special I need to do to report it upsteam (I am a new bug triager)
[14:33] <norsetto> sectech: just check if there is a similar bug uupstream already (or in Debian if applicable), if not report it in the upstream bug tracker and link it to the LP bug report
[14:34] <sectech> Okay I'll start with Debian and see if there is anything there
[14:36] <jibel> Hi bugsquad
[14:37] <jibel> could someone at bugcontrol switch importance of bug 159362 to wishlist. Thanks
[14:38] <qense> I can do that :)
[14:39] <sectech> norsetto, I don't see anything similar in debian...  I can report it there if it's appropriate though?
[14:39] <norsetto> sectech: no need in this case
[14:40] <sectech> norsetto,  I can't assign it to nvidia though in Ubuntu...
[14:40] <sectech> and right now I removed the assignment because it isn't an openoffice problem
[14:41] <norsetto> sectech: that would be restricted-drivers
[14:41] <sectech> ahhh thank you!
[14:44] <humbolto> Anybody working on the evolution-alarm-notify bug?
[14:44] <humbolto> I have some info that might help
[14:46] <sectech> norsetto,  I assigned it to linux-restricted-modules-2.6.24
[14:54] <pedro_> don't forget the hug day https://wiki.ubuntu.com/UbuntuBugDay/20080508 :-)
[14:54] <sectech> Hey indeed... today is a hug day
[14:56] <sectech> pedro_,  I don't think I have access to make the changes to hug a bug, do I?
[14:56] <pedro_> sectech: you need to login first :-)
[14:56] <sectech> I am logged in... lol
[14:56] <pedro_> everybody with a lp account is able to make changes to that wiki page
[14:57] <pedro_> maybe someone else is writing on it
[14:58] <Hobbsee> come on wiki, don't die on me.
[14:58] <pedro_> haha
[14:58] <sectech> I might follow a few bugs to see how other triagers work before I make any major changes....
[14:58] <pedro_> sectech: editmoin is a pretty good tool for edit the wiki pages
[15:00]  * Hobbsee asks if https://wiki.ubuntu.com/Bugs/HowToTriage#head-89f23324471028da4ff2dc496f0bdd299d72c093 in general makes sense to people
[15:00] <sectech> pedro_,  I might be a little too new to this....   at the moment I have to be very selective on which bugs to triage just because of lack of experience.... Some I can triage with no problems, others I don't know what to ask for sometimes.
[15:02] <sectech> I have picked up a lot though over the few days I have been doing this...
[15:02] <pedro_> that's totally ok :-)
[15:02] <sectech> It will be a while before I start asking for access to mark bugs as triaged myself ;)
[15:03] <persia> Hobbsee: How about "Please promote <package> to <component>" and "Please demote <package> to <component>"?
[15:03] <Hobbsee> persia: ahhh, good.
[15:03] <Hobbsee> persia: what's the mir team name?
[15:03] <Hobbsee> ubuntu-mir?
[15:03] <persia> https://launchpad.net/~ubuntu-mir
[15:04] <james_w> Hobbsee: nice. Thanks for doing that.
[15:05] <Hobbsee> james_w: no problem.  that should stop people fiddling with thsoe bugs, i hope.
[15:05] <Balachmar> Hi, I games like supertux2, chromium and fishfillets hang when I try to shut them down.
[15:05] <persia> It at least provides a reference regarding the issue, as opposed to the previous assumption that it would be understood by osmosis.
[15:06] <Balachmar> They also consume a lot of cpu then, also a game written with pygame hangs on shutdown as well.
[15:06] <james_w> Balachmar: can you get an strace of the apps?
[15:06] <Balachmar> james_w: How would I do that?
[15:06] <james_w> Balachmar: if you have one hanging now then you need to open a terminal, and run "ps aux | grep <name-of-game>"
[15:07] <Hobbsee> persia: well, yeah.  it was always supposed to be fixed.
[15:07] <james_w> Balachmar: note the number in the second column of the row that corresponds to the game
[15:07] <james_w> Balachmar: and then run "strace -o dump.txt -p <number-you-noted>"
[15:08] <james_w> Balachmar: you can then put "dump.txt" in a pastebin
[15:08] <sectech> Is there a wiki on how to setup your system for bug testing?  I just bought a new sata drive yesterday just so I could have some VM's going for this....
[15:08] <sectech> I'll be setting them up today
[15:08] <sectech> ran into some stupid sata error yesterday... easy work around though
[15:09] <Balachmar> It says interupt to quit, should I kill the proces now?
[15:09] <sectech> or rather fix not work around
[15:09] <james_w> Balachmar: yup, should be enough. If it's not you can run the process from the start under strace.
[15:10] <Balachmar> this is the trace: http://pastebin.com/m731069d1
[15:10] <Balachmar> Not much in there
[15:11] <james_w> yup, not too helpful as we don't know what that futex is.
[15:11] <james_w> Balachmar: can you please run "strace -o dump.txt <name-of-game>" and then quit and kill it after a few seconds of hanging
[15:11] <james_w> Balachmar: not that it will run a lot slower like this
[15:12] <bddebian> Boo
[15:16] <Balachmar> james_w: hmmm it seems that if I run them from the terminal that they are not as likely to hang...
[15:17] <Balachmar> james_w: that assumption was wrong :)
[15:19] <Balachmar> james_w: the whole dump is too long for pastbin
[15:19] <Balachmar> whould I just send the last bit?
[15:20] <james_w> Balachmar: yeah, start with the last bit, it may be enough.
[15:22] <Balachmar> james_w: http://pastebin.com/m7fdb6ad8
[15:23] <james_w> Balachmar: that's still not enough to say really
[15:24] <james_w> Balachmar: can you run "grep b63e1bd8 dump.txt > dump2.txt" and pastebin the second file please?
[15:25] <Balachmar> james_w: http://pastebin.com/d541b0930
[15:25] <james_w> Balachmar: thanks.
[15:26] <james_w> Can you try the strace command again, this time with "-f" as well?
[15:26] <Balachmar> Well, you are helping me out :)
[15:26] <Balachmar> sure
[15:26] <james_w> it tells it to follow children as well, and it looks like it might be a problem in a child.
[15:26] <james_w> the last bit of the trace will hopefully all that is needed from this one.
[15:27] <Balachmar> so I don't need to do the grep stuff
[15:28] <Balachmar> http://pastebin.com/m3be4c4aa
[15:30] <Balachmar> james_w: It only happens if I close the window with the cross instead of the quit game option
[15:31] <james_w> Balachmar: ok, so this time we need to grep for " = 5", would you do that please? It might be a lot more lines this time though, but we are looking for a particular one, so I may need to see them all.
[15:31] <james_w> If it is loads then we can probably trim it down though.
[15:31] <james_w> Balachmar: that's interesting. Is there some similarity in these games, you mentioned pygame, do all of the games use that?
[15:32] <Balachmar> I don't know, the ones I am experiencing problems with so far are: Chromium, supertux2, fishfillets and my own, but that is still in development
[15:33] <gnomefreak> mvo_: is ther ean easy way to lock a package version with apt. i did it with synaptic but it doesnt apply to apt it seems
[15:33] <Balachmar> http://pastebin.com/m641a83d2
[15:35] <Balachmar> james_w: Actually with fish fillets it does end nicely with the cross, but not with the in game option...
[15:36] <james_w> Balachmar: there's not enough there I'm afraid, can you email me the trace?
[15:37]  * DShepherd is now bug man
[15:37] <Balachmar> the last one, and then the full version? ofcourse
[15:37] <james_w> I want the one you created with -f please
[15:38] <Balachmar> yes, I meant that one
[15:40] <DShepherd> https://wiki.ubuntu.com/Bugs/Responses -- is it ok if i use these as a guideline in responding to bug reports?
[15:40] <Balachmar> james_w: it is 34 MB...
[15:40] <sectech> DShepherd,  that's what I was told to use
[15:40] <DShepherd> sectech, i guess that is a yes then :-)
[15:41] <DShepherd> sectech, thanks
[15:41]  * DShepherd calls on the power of ten bug-men!
[15:41] <Balachmar> I'll put it online and send you the link
[15:41] <james_w> Balachmar: that works too. Feel free to compress it
[15:42] <Balachmar> *slams himself on the head* compress it, smart thinking!
[15:44] <Balachmar> james_w: you've got mail...
[15:45] <james_w> why, yes I do, thank you.
[15:47] <Balachmar> james_w: Well, thank you! I have to go now, but I will be back. Or you can always mail me for more info
[15:47] <james_w> sure, ping me when you're back
[15:48] <Balachmar> it won't be today though...
[15:49] <james_w> no problem
[15:49] <Balachmar> Well, thanks for the help, bye
[16:23] <Iulian> Hey
[16:27] <DShepherd> hey
[16:27] <Iulian> Hi DShepherd
[16:28] <DShepherd> Hi Iulian
[16:28] <Pici> no boo?
[16:38] <james_w> anyone know what's going on here? http://bobthegnome.blogspot.com/2008/05/apportbug-buddy-disabled-in-ubuntu-804.html
[16:39] <james_w> I didn't think bug-buddy would be active on any Ubuntu systems.
[16:45] <ruiboon> hi. may i know when a bug has a strace attached and the way to reproduce the bug is stated, what should its status be?
[16:48] <james_w> ruiboon: that depends on other things
[16:48] <james_w> ruiboon: probably New or Confirmed, depending on whether anyone else has seen it yet.
[16:48] <james_w> ruiboon: do you have a bug number so that I can have a look?
[16:49] <ruiboon> https://bugs.launchpad.net/ubuntu/+source/roxterm/+bug/227685
[16:49] <ruiboon> james_w: i have tagged it as incomplete at first as there was not enough information.
[16:50] <ruiboon> james_w: but i am not sure of what to do now since there is a strace file attached.
[16:51] <ruiboon> james_w: the submitter is also not using the latest version of the program. should we ask him to update it?
[16:51] <james_w> ruiboon: what we really want is a backtrace
[16:51] <james_w> it appears to be the most recent to me, 1.8.0-1
[16:52] <ruiboon> james_w: erm... the latest release at the left side of the launchpad page seems to mention that it is 1.11.1-1
[16:53] <ruiboon> james_w: will ask the submitter for a copy of the backtrace
[16:54] <Pici> !newpackage | Belisarivs
[16:54] <james_w> ruiboon: that's probably intrepid,
[16:54] <james_w> ruiboon: I'd keep it as incomplete until they can provide a backtrace
[16:54] <james_w> https://wiki.ubuntu.com/Backtrace
[16:54] <james_w> https://wiki.ubuntu.com/DebuggingProgramCrash
[16:54] <james_w> are the two links that are useful there.
[16:55] <ruiboon> james_w: ok.
[16:55] <ruiboon> james_w: Thanks for your help!
[16:55] <james_w> no problem.
[17:02]  * Hobbsee fumes
[17:02] <Hobbsee> james_w: wiki edit reverted :(
[17:02] <Hobbsee> james_w: so you'll just have to guess over what you're supposed to do, or not.
[17:03] <james_w> Hobbsee: why?
[17:03] <Hobbsee> james_w: see the ubuntu-bugs ML.
[17:04] <james_w> Hobbsee: ah, I see. That's a shame.
[17:04] <Hobbsee> james_w: a shame is one phrase for it.  that wasn't the one i was thinking of.
[17:06] <thekorn> hi all
[17:06] <james_w> hi thekorn
[17:06] <thekorn> hey james_w
[17:06] <Iulian> Hello thekorn
[17:06] <thekorn> and Iulian
[17:07]  * Hobbsee wasn't aware that missing documentation now required going through a canonical QA review.
[17:07] <Hobbsee> seeing as most people are following it anyway, and all.
[17:08]  * Hobbsee is sure heno will do well in finding all the solutions at UDS, with those who go.
[17:08] <_stink_> is the ubuntu-bugs ML archived anywhere? https://lists.ubuntu.com/archives/ubuntu-bugs/ only shows months up to March 2007, and many/all of the directories are empty anyway.
[17:09] <heno> Hobbsee: you are welcome to participate by phone
[17:09] <Hobbsee> heno: at very early hours of the morning, yes.
[17:11] <james_w> _stink_: it should be, I'm not sure if it has fallen behind for some reason.
[17:15]  * Hobbsee also thought that the 'discussion' had moved onto triaging tools to make it easier for triagers, with the greasemonkey scripts, and wasn't talking about policy anymore.
[17:15] <Hobbsee> apparently not.
[17:25] <pochu> _stink_: no, they're not because the bugs are also in Launchpad and there were disk space issues IIRC with the archives. but the mailing list we were talking about isn't ubuntu-bugs, but ubuntu-bugsquad
[17:28] <pochu> heno: btw, https://blueprints.edge.launchpad.net/soyuz/+spec/sync-workflows should remove the need of using the bug tracker for syncs... except for those people needing sponsorship, but those are very few I believe and we could look at some other way to track them
[17:29] <Hobbsee> pochu: what about merges / removals / everything else listed there?
[17:29] <pochu> Hobbsee: we could change the policy of the involved teams to assign those bugs to those teams
[17:30] <pochu> if that's appropriate...
[17:30] <pochu> I can't see why not, but I guess there may be a reason why that's not the case right now :)
[17:30] <Hobbsee> pochu: there are reasons.
[17:31] <heno> There needs to be some better process than just 'stay away from <this growing list> of bug types'
[17:31] <pochu> that way the policy change is minor (s/subscribe/assign/g)
[17:31] <Hobbsee> pochu: mainly being that a particular member actually does the merge, etc, nto someone in the group, so it's easier to track that way.
[17:31] <pochu> heno: well, people have mentioned if the bug has an assignee or is InProgress, the bugs won't be listen in the triagers searches, so assigning the teams which will need to approve/reject/do the work sounds like a possible solution to me
[17:32] <Hobbsee> pochu: so, you really can't say "someone in the group is working on this, (like, the contributor), but we need the release team to be subscribed, to give an ack.
[17:32] <Hobbsee> at teh end of the day, the contributor is responsible for the bug, once they have their ack.
[17:32] <pochu> ah, I see the case for the release team
[17:32] <Hobbsee> pochu: sponsorship teams are similar.
[17:32] <pochu> I was mostly thinking in u-u-s/u-m-s
[17:33] <Hobbsee> pochu: mir's are also similar.
[17:33] <heno> pochu: I agree that could work
[17:33] <pochu> well, in that case then the team is subscribed, there's a debdiff attached
[17:33] <pochu> and for mirs, the mir team is actually doing the work
[17:33] <Hobbsee> sometimes.  depends if it's been bumped back for more info, but i see your point.
[17:33] <james_w> do any of the teams use a status change in their work?
[17:33] <pochu> so assigning the bug to them sounds reasonably to me (I don't know what the team members would think though)
[17:33] <Hobbsee> they do the final override.
[17:34] <Hobbsee> pochu: it breaks filters and doc and stuff, every time you change the workflow.
[17:34] <pochu> sure, I know... but not switching it will mean we won't solve this issue
[17:34] <pochu> so there's a need to fix this, one way or another
[17:35] <pochu> this is not 'lets change the policy for the sake of changing it!' :)
[17:35] <Hobbsee> pochu: also, it breaks the sponsorship case where people rely on email only, and so think, once the team has been unsubscribed (that the team is no longer the assignee), that there's been no progress on the bug - whereas that's not the case - it's a sponsor that has taken it out of the queue, and has done it.
[17:35] <Hobbsee> pochu: these are the main reasons for subscription, which is, in fact, more painful than an assignee (more screens).
[17:36] <_stink_> pochu: thanks for the mailing list info
[17:36] <Hobbsee> heno: would the list really grow that large?
[17:37] <james_w> Hobbsee: not everything is covered by that list though unfortunately.
[17:37] <pochu> Hobbsee: sorry, I didn't understand how it breaks the sponsorship case... I'm no native speaker :(
[17:37] <heno> Hobbsee: don't know, but it has been growing since the discussion started
[17:38] <james_w> there was a case the other day where a developer had filed a quick report on friday so they could attach a debdiff and apply for an SRU on monday, and over the weekend there was nothing to indicate that it was going to be an SRU bug
[17:38] <Hobbsee> pochu: some people process the queue only by email.
[17:38] <pochu> oh
[17:38] <Hobbsee> pochu: assigning a team, instead of subscribing them, breaks.
[17:38] <Hobbsee> pochu: saves launchpad loads, etc.
[17:38] <james_w> so, while we use bug reports for this sort of thing we are probably always going to have some cases where it is not obvious.
[17:39] <Hobbsee> james_w: true.  i guess you're relying on the fact that a triager probably won't find your particular bug, in a stream of otherwise important bugs.
[17:39] <pochu> so you mean that since the team would still be assigned even if the bug is 'Incomplete', the ML would still receive mean which should mean that the bug needs sponsorship, were actually it means the bug needs more work in that specific case?
[17:39] <heno> surely sponsorship requests would be 'In progress' or at least Triaged
[17:39] <Hobbsee> pochu: no, if the assignee would be changed to be who was actually uploading it, i presume.  seeing as they're responsible now.
[17:40] <Hobbsee> pochu: which would stop the bugmail to the team for that bug.
[17:40] <pochu> heno: except when the sponsor asks the contributor to fix some things or change others...
[17:40] <james_w> Hobbsee: yep, or make it clear what you are doing, or set an appropriate status.
[17:40] <Hobbsee> james_w: i like triaged for that.  it speaks of "leave my bugs alone, i'm in -qa"
[17:40] <james_w> hi secretlondon
[17:40] <Hobbsee> (whether it's actually triaged or not, if people aren't supposed to modify it)
[17:40] <secretlondon> hi james
[17:41] <secretlondon> hi james_w
[17:41] <heno> But if it's being worked on at that level the problem itself is generally understood, so at least Triaged
[17:41] <pochu> Hobbsee: ah, right, then we are good?
[17:41] <Hobbsee> heno: bugsquaders were still picking off triaged bugs, afaik.
[17:41] <james_w> Hobbsee: yeah, I think triaged would be fine. We have to rely on developers to set it in that case, but it would work fine.
[17:41] <james_w> secretlondon: ogra was wondering if you knew of any tuxpaint related bugs that would be worthy of an SRU in to hardy.
[17:41] <heno> Hobbsee: interesting. examples?
[17:42] <Hobbsee> heno: people setting the wishlist flag on sync requests.
[17:42]  * ogra waves to secretlondon 
[17:42] <heno> triagers should tend to focus on the New -> Triaged region
[17:42] <Hobbsee> i think that some of them may have been motu hopefulls, but i don't think they all were.
[17:42] <secretlondon> james_w not really, we are two versions behind anyway
[17:42]  * secretlondon waves at ogra
[17:43] <secretlondon> james_w and I caught them before freeze anyway
[17:43] <james_w> secretlondon: great, nice work.
[17:43] <ogra> great :)
[17:43] <heno> asking triagers to generally not modify Triaged state bugs sounds like sensible policy
[17:43] <james_w> Hobbsee: I'm not trying to be argumentative, but does the wishlist flag for a sync request affect the workflow, or is it just noise for those subscribed?
[17:44] <heno> but asking them to not touch New bugs doesn't IMO
[17:44] <Hobbsee> james_w: it's needless noise.
[17:44] <james_w> Hobbsee: yep
[17:45] <Hobbsee> heno: that's going to lead to abuse of triaged, though, where the bug does require more information.
[17:45] <Hobbsee> heno: obviously, the mir team, archive teams, etc, are only going to look at triaged and above
[17:45] <heno> that sounds like an LP email handling or filtering problem (the noise)
[17:45] <Hobbsee> heno: how do you then propose to differentiate between triaged-so-bug-squad-leaves-it-alone-but-not-ready-yet, and triaged-has-all-information?
[17:46] <heno> Hobbsee: abuse how? It can only be set by bug-control who should read the triage docs
[17:46] <Hobbsee> heno: by the developers filing workflow bugs, going "please leave this alone"
[17:46] <heno> Hobbsee: why should those be different?
[17:47] <Hobbsee> heno: to the triagers?  they shouldn't.  to the archive admins, and those who are processing the bugs if they're in a ready state?  htey do.
[17:47] <heno> that's not an appropriate use of the bug tracking system IMO
[17:47] <Hobbsee> heno: so, what do you propose as a way of saying "leave this alone", which doesn't involve a tag?
[17:48] <Hobbsee> seeing as your last proposal was "set it as triaged", afaik.
[17:48] <heno> Triaged, In Progress or Wishlist
[17:48] <Hobbsee> granted.
[17:48] <Hobbsee> but the question still stands.
[17:48] <heno> ok, so we are agreed :)
[17:49] <heno> what question?
[17:49] <Hobbsee> [02:48] <Hobbsee> heno: so, what do you propose as a way of saying "leave this alone", which doesn't involve a tag?
 Triaged, In Progress or Wishlist
[17:49] <Hobbsee> oh, you're saying to stick all bugs as in progress, if we don't want bugsquad to touch them
[17:49] <ruiboon> may i know why the use of tags are not preferred?
[17:49] <heno> if it needs more info that can go in the description
[17:50] <heno> Hobbsee: yes
[17:50] <Hobbsee> ruiboon: because they suck, they add to the tag cloud, and it requires yet another screen to actually add them.  in addition, you can't add tags while filing a bug, on the standard form.
[17:50] <gautierh> Hello all, I have a process (pidgin/14629) that takes all CPU available, seems to ignore SIGTERM, SIGKILL, and which I don't see the window on X.
[17:50] <gautierh> When it happened I had firefox and virtualbox opened, since I suppose there is a bug somewhere I didn't stop virtualbox in order to get more information.
[17:50] <gautierh> I come to you because `gcore 14629` with sudo says "ptrace: Operation not permitted."
[17:50] <gautierh> This is the output of `ps -f 14629` :
[17:50] <gautierh> UID        PID  PPID  C STIME TTY      STAT   TIME CMD
[17:50] <gautierh> gautier  14629     1 29 08:54 ?        Dl   161:59 pidgin
[17:50] <gautierh> (I use Ubuntu 8.04, with linux 2.6.24-16-generic).
[17:50] <heno> because it's easier to educate a smaller group
[17:51] <heno> and we are talking about the fringe exception cases here
[17:52]  * Hobbsee fails to see how a sync request being thrown back, so set to 'in progress' is a valid use of that state, either.
[17:52] <Hobbsee> or merge or removal request, or anything else.
[17:52] <ruiboon> Hobbsee: i see the issue
[17:53] <Hobbsee> because it may well not *be* in progress, if the OP does not do anything about it.
[17:53] <heno> These workflow tickets are not bugs. If they are going to live in the bugtracker anyway they must be adjusted to coexist peacefully with the bulk use case of the tracker
[17:53] <Hobbsee> and surely, if it's thrown back, the OP should be the one sayign "i'm working on this now, or real soon now", not whoever threw it back.
[17:54] <heno> not teach the whole world to take special consideration of these non-bugs
[17:55] <Hobbsee> heno: i presume you have a better place that they should go.
[17:56] <Hobbsee> heno: and, i presume you don't mean that as soon as something si a debdiff, it no longer is a bug, but a workflow ticket, and so should be in that better place, too....
[17:56] <heno> Hobbsee: no. but I can live with Triaged, In Progress or Wishlist
[17:57] <pochu> heno: what do you think about putting the team/person working on the bug as the assignee? would that work for the bugsquad?
[17:57] <heno> debdiff should never be New right?
[17:57] <heno> pochu: probably
[17:57] <Hobbsee> no
[17:57] <Hobbsee> but it may well be incomplete, if it's wrong, and requires more info.
[17:58] <Hobbsee> nor is it legitimately a wishlist either, as it fixes a bug, so is not a wish, imo.
[17:58] <heno> so it needs more triage ...
[17:58] <Hobbsee> not by bugsquad, though.
[17:58] <Hobbsee> unless a requirement of bugsquad is to contribute code fixes too now.
[17:59] <heno> asking again for the requested info is valid triage
[17:59] <Hobbsee> which the sponsor has already done, no?
[18:00] <Hobbsee> oh, presumably this falls in the newfangled "requested info, no response" thing.
[18:02] <heno> it's not new
[18:04] <Hobbsee> newish.
[18:05] <Hobbsee> it's since the "launchpad took upwards of 40 seconds to load, so i didn't do much bugwork in it, and turned more to email", so classes as new in my books :)
[18:09] <thekorn> In my opinion all this problems can be easily solved by adding an option to launchpad to restrict the write-access to bug tasks
[18:11] <pochu> thekorn: but that would only work for SRUs, not for sync/merges/mirs/removals/etc...
[18:11] <Hobbsee> thekorn: i was thinking an "i know what i'm doing" checkbox.
[18:11] <Hobbsee> but yes
[18:11] <pochu> since those don't have stable tasks
[18:12] <pochu> I guess that checkbox won't actually work
[18:13] <pochu> since either you make it public to everyone, in which case it will be abused, or you restrict it to some special team, in which case people needing sponsor teams may not have access to it
[18:13] <thekorn> let's say only an assignee is allowed change the attributes of a task,
[18:13] <pochu> I say
[18:14] <pochu> but for that case, you already need to have an assignee, and that should solve this by itself :)
[18:14] <pochu> so no need to restrict the status
[18:15] <thekorn> yup, that's right
[18:15] <pochu> gtg, I'll read the backscroll later :)
[18:15] <thekorn> so it's all about: don't touch task with an assignee
[18:18] <thekorn> or using a "do-not-change-attributes-of-this-bug" tag :)
[18:20] <thekorn> but I also think that people from launchpad have to be involved in solving this kind of problems
[18:37] <gnomefreak> mvo_: does dpkg --clear-selections work to unpin a package from terminal?
[18:50] <sectech> Can someone review bug 228303 and possibly wishlist it please
[18:53] <mvo__> gnomefreak: no, that is a different mechanism (dpkg vs. apt) - I will need to leave shortly, we can talk about it tomorrow maybe?
[18:53] <gnomefreak> mvo_: yeah no problem
[18:53] <gnomefreak> mvo_: thanks
[18:54] <heno> sectech: I moved it
[18:54] <sectech> thank you
[19:10] <sectech> heno can you review a bug for me and provide feedback to me?
[19:10] <sectech> bug 228297
[19:11]  * heno looks
[19:11] <sectech> I marked it as confirmed because the reporter does have a point.... As soon as alt is pressed it shouldn't matter if shift comes next or tab
[19:11] <sectech> The problem is I don't know what the standard documented order is
[19:12] <sectech> heno,  Thank you
[19:13] <sectech> I looked to see if is a dup (and it possibly still could be) but I haven't found anything
[19:14] <heno> sectech: there would be less noise if you asked here first and then commented on the bug :)  Confirmed is fine (if you have tested and can confirm it), but please try to also find the package
[19:15] <sectech> heno,  true enough.... I'll see what I can find
[19:15]  * heno wanders off for a bit
[19:18] <blueyed> I've asked in the duplicate bug 222425 already:
[19:19] <blueyed> Any chance you had answered "No" to the following question, which would abort installation/upgrades?
[19:19] <blueyed>  Proceed with virtualbox-ose upgrade despite losing snapshots?
[19:19] <blueyed>  You are currently upgrading virtualbox-ose to a new upstream version. All
[19:19] <blueyed>  snapshots will be discarded by this upgrade, because snapshots are
[19:19] <blueyed>  version-specific.
[19:19] <blueyed> It seems so, looking at main.log:
[19:19] <blueyed> 2008-04-25 06:16:13,537 WARNING no activity on terminal for 240 seconds (Preparing virtualbox-ose)
[19:19] <blueyed> 2008-04-25 07:46:21,759 ERROR got an error from dpkg for pkg: '/var/cache/apt/archives/virtualbox-ose_1.5.6-dfsg-6ubuntu1_i386.deb': 'subprocess pre-installation script returned error exit status 1
[19:19] <blueyed> '
[19:19] <blueyed> sry.
[19:19] <blueyed> I've meant to ask: Isn't language-pack-XX installed by default?
[19:24] <sectech> Can someone wishlist bug 189774 for me please
[19:26] <thekorn> sectech, why should it be set to 'wishlist' as it is already marked as invalid?
[19:27] <blueyed> sectech: you've set it to invalid..?
[19:27] <sectech> He commented on the bug after I set it to invalid a couple days ago... I just got the email
[19:29] <sectech> It technically isn't a bug... then after my comment he commented with a request
[19:29] <sectech> or how he thought it should be
[19:30] <sectech> should have I marked it as incomplete again and then asked?
[19:34] <blueyed> sectech: sounds like "confirmed, wishlist" then.
[19:34] <pochu> thekorn: that sounds like a good idea... if we have a session for this issue in UDS, we should invite some lp/malone folks to it
[19:35] <thekorn> sectech, setted to wishlist,confirmed
[19:35] <thekorn> pochu, do you now how and where sessions are planned for this UDS?
[19:35] <sectech> I don't understand why it would be confirmed....  If it asks for the password once isn't that the standard procedure?
[19:36] <pochu> thekorn: nope, I don't think the schedule is available yet
[19:36] <pochu> thekorn: but heno said there was going to be a session about this I think
[19:36] <thekorn> pochu, ok
[19:37] <sectech> thekorn,  why would it be confirmed?
[19:38] <thekorn> sectech, what other status would make more sense?
[19:39] <sectech> thekorn,  .... Okay yeah I guess with the options given....  When I see confirmed I think "yes the program shouldn't act that way"
[19:40] <sectech> I guess there really isn't anything else to set it to...
[19:40] <sectech> thekorn,  so anything that is to be on the "wishlist" should be marked as confirmed first?
[19:41] <thekorn> sectech, I'm not sure about that in general
[19:42] <thekorn> but as far as I understand this, every other status does not fit here
[19:43] <sectech> thekorn,  After looking at what I had to choose from I understand.... I just wanted to know what the proper procedure was,  that way I am not screwing up bugs
[19:43] <pochu> it could also be unconfirmed if you hadn't looked at seahorse at all
[19:44] <thekorn> sectech, as long as you discribe what you have done everything is ok
[19:44] <sectech> Okay... thanks thekorn and pochu
[19:44] <sectech> I do realize I am asking a lot of questions....
[19:45] <sectech> I generally only need to be told once though thankfully
[19:45] <pochu> :)
[19:47] <thekorn> pochu, what do you think about sharing a taxi from the airport to the hotel on 18 May, as I see on the Attendees table you will arrive at 2100,
[19:47] <thekorn> and if I remember correctly I will arrive at 2045 or something
[19:49] <pochu> thekorn: that would be cool :)
[19:49] <thekorn> ;)
[19:49] <pochu> thekorn: we can also ask Andrew Hunter, which is an ubuntustudio guy and arrives at 20:50
[19:50] <thekorn> sure
[19:51] <pochu> lol, too many Andrew Hunters around... Andrew Hunter
[19:51] <pochu> err, http://en.wikipedia.org/wiki/Andrew_Hunter
[19:53] <thekorn> pochu, hehe, I would really like to meet the Canadian-Jamaican Basketball player
[19:56] <pochu> heh
[20:32] <aantn> hello
[20:32] <sectech> Can someone wishlist bug #228292
[20:32] <aantn> has anyone noticed dbus problems after recent upgrades
[20:32] <aantn> dbus activation seems to be broken
[20:39] <aantn> argh
[20:39] <aantn> I hate working around other people's bugs
[20:47] <qense> have you read the blog at Planet Ubuntu about DeviceKit?
[20:47] <qense> it looks promising
[20:48] <sectech> qense,  who?
[20:48] <james_w> sectech: pitti
[20:49] <qense> I'm curious if it's going to be included in interpid
[20:50] <james_w> if it's ready by then it probably will
[20:50] <james_w> the author said that he plans to have it in F10, so it will probably be in a usable state for intrepid.
[20:51] <qense> and we were told at the announcement that intrepid will be a surprising release, so it would make a lot of sense to include it
[20:51] <qense> it's an official devicekit that's really going to replace HAL like david wrote in that mailist post? Or did he start it on his own
[20:52] <james_w> I'd believe what david says
[20:59] <blueyed> It's not easy to report a bug from a LiveCD (and fresh install?)..
[20:59] <sectech> you found a bug with the livecd?
[21:00] <blueyed> well.. yes.. some.. ;) - but wanted to report a problem when upgrading to -proposed.
[21:00] <blueyed> The other one is that there's an error about some gnome daemon not starting.
[21:01] <blueyed> with -i386 and -amd64.
[21:01] <sectech> ahh ok
[21:02] <blueyed> ..and it does not detect my evoluent vertical mouse buttons correctly.
[21:02] <sectech> I am in the process of installing vm's....  I have ubuntu 32 bit, 64 bit and kubuntu going
[21:02] <blueyed> With virtualbox-ose?
[21:02] <sectech> yep...
[21:02] <blueyed> Wanted to test on -amd64.. a virtualbox-ose-modules bug.. :)
[21:02] <sectech> I spent most of the morning trying to get the damn thing out of 800x600.... I ended up giving up on that
[21:03] <sectech> what's the bug, I can see if I can reproduce it
[21:04] <sectech> It's funny because I have been over the virtualbox manual.... I have installed the guest additions...changed xorg.conf.... nothing
[21:05] <sectech> 800x600 will do though just for bug testing...
[21:08] <sectech> hey,  just out of curiosity...  How easily could a bugsquad member get approved as an ubuntu member?
[21:09] <sectech> Would be nice to be included as I am working to improve the distro....
[21:09] <blueyed> Then just apply.. :)
[21:09] <james_w> sectech: bugsquad work would count I would expect. Are you a member of bugcontrol yet?
[21:10] <sectech> james_w, Not a member of bugcontrol yet....   I am still asking a lot of questions on procedures so I imagine I have a little ways to go yet...
[21:10] <awalton__> what's the difference between bugsquad and bugcontrol.. so many teams!
[21:11] <sectech> awalton__,  bugcontrol can set the importance and officially "triage" bugs.
[21:11] <awalton__> a-ha.
[21:11] <james_w> awalton__: bugcontrol is a subset of bugsquad that is allowed to set certain statuses, and set importance.
[21:11] <awalton__> I was wondering about that...
[21:12] <awalton__> so how does one join bugcontrol?
[21:12] <james_w> so it's a recognition of ability and commitment to triage. I presume that if you wanted to apply for memebership on the basis of bug triage they would like to see you in bugcontrol first.
[21:12] <sectech> Unless someone decides to tell me to knock it off with the questions I am aiming to be a bugcontrol member.
[21:12] <james_w> awalton__: https://launchpad.net/~ubuntu-bugcontrol has links to an explanation
[21:12] <awalton__> thanks james_w.
[21:12] <james_w> awalton__: basically do good work and answer a few questions.
[21:12] <sectech> james_w, true....
[21:13] <james_w> sectech: the more questions the better.
[21:13] <sectech> I wish I had a mentor though lol, I feel like I'm annoying you guys sometimes...
[21:13] <bdmurray> sectech: that is an interesting idea - what would a mentor do?
[21:14] <james_w> not me. I think it's better to ask a question to everyone rather than one person though.
[21:14] <jjesse> um mentor?
[21:14] <jjesse> :P
[21:14] <sectech> bdmurray,   basically look at how a person handles bugs and makes recommendations on a better way or to at least let the person know they are on the right path
[21:15] <sectech> some of the bugs I marked as invalid were changed to confirmed...  I don't always have a clear view on some of the complex bugs on what to ask for....
[21:16] <sectech> A triager probably should go from oldest to newest when looking at bugs.... for simplicity sake I am going newest to oldest....
[21:17] <bdmurray> I personally think working on more recent bugs makes the most sense, as you are more likely to get a response and personally be able to recreate something on Hardy compared to Feisty.
[21:17] <secretlondon> I agree, many of the really old bugs are not that useful
[21:18] <bdmurray> sectech: have you seen https://wiki.ubuntu.com/BugSquad/Contacts ?  there are some points of contact for specific packages
[21:18] <jjesse> then won't the old bugs just get older? and staler?
[21:18] <jjesse> if an old bug doesn't exist in current version then check to see if it exists in a supported bersion
[21:18] <sectech> true enough...
[21:18] <sectech> hahaha bdmurray - everything
[21:19] <sectech> Hey this helps!
[21:19] <sectech> Even if I was a member of bugcontrol, I wouldn't mark things I was unsure about as triaged... I would ask regardless if I am doing this a month or a year
[21:20] <secretlondon> sectech, can you give an example of a bug you marked as invalid which was subsequently set as confirmed?
[21:21] <sectech> hmmm.... let me go through my list....
[21:21] <blueyed> sectech: Asking is always good. In fact, I've said "Confirmed, Wishlist" in the bug mentioned earlier, but only from quickly scanning the bug and your "intention".
[21:23] <secretlondon> I rarely set bugs as invalid tbh, I'm pretty cautious
[21:24] <sectech> secretlondon,  I know there was at least one in my list, but I can't find it at the moment...
[21:24] <secretlondon> ok
[21:25] <sectech> I am learning not to make a sudden judgement... It seems better to mark the bug as incomplete and let it sit for day or two because the reporter sometimes adds things....
[21:25] <sectech> I do however think that there should be something in place stating who is triaging the bug....
[21:26] <sectech> Or rather that the person triaging is either from bugsquad or bugcontrol
[21:33] <blueyed> sectech: ﻿bug 221736 is the one I wanted to test on amd64. have you upgraded the kernel from -proposed already?
[21:33] <sectech> blueyed, yes I have
[21:33] <blueyed> went smooth?
[21:34] <blueyed> sectech, would you like to help me out with virtualbox-ose/-modules bugs? :)
[21:34] <sectech> blueyed, sure...
[21:35] <sectech> It did for me... I'll try it again though, doesn't hurt
[21:37] <blueyed> well, then.. I'm subscribed to bugmail from those packages. I don't think it's easy to reproduce though - still downloading for me.
[21:38] <sectech> I have xubuntu installing at the moment... Once it's done I'll throw on ubuntu 64 bit and test it again
[21:39] <blueyed> Wow.. I get now all the bugs I could not verify before.. "Apport cannot start firefox" now.
[21:44] <sectech> was that bug reported before? I can put it in my list of things to reproduce this evening
[21:44] <blueyed> Which one? I think a lot down boils to hal not running.
[21:45] <sectech> firefox
[21:47] <blueyed> bug 198195
[21:48]  * pedro_ kicks podsleuth
[21:48] <pedro_> jcastro: does the new banshee (from the ppa) works with your ipod?
[21:48] <pedro_> ahoj andre___
[21:50] <andre___> čau pedro!
[21:54] <sectech> blueyed,  That bug about virtualbox-ose...  Did you mean upgrade the kernel from proposed then try and run virtualbox?
[21:54] <sectech> or install virtualbox rather
[21:54] <bdmurray> pedro_: I was just looking at the Bugs/Assignment wiki page - in what cases does the desktop team want bugs assigned to them?
[21:55] <blueyed> sectech: the upgrade of the virtualbox kernel module fails.. and there are reports where "modprobe" does not work, but only "insmod".
[21:55] <blueyed> sectech: and strange depmod errors during post installation (where i386 appears to get scanned).
[21:56] <sectech> blueyed, Odd because my main system is the 64 bit and I was able to install virtualbox and it's modules with no problems.
[21:56] <jcastro> pedro_: I have an mtp device, and it works, ipod should work too.
[21:56] <sectech> I did get an error while trying to create new vm's though...
[21:56] <pedro_> bdmurray: to desktop-bugs you mean? in almost all the times, so we can keep a better tracking of them
[21:56] <pedro_> if there's someone on the team working on the issue that's assigned to the person
[21:57] <sectech> like I said I'll try it again and see what it does though
[21:57] <pedro_> so everything regarding the desktop packages->desktop-bugs
[21:57] <pedro_> jcastro: mm then i managed to broken my conf... again
[21:58] <bdmurray> pedro_: okay, thanks
[21:58] <jcastro> pedro_: make sure podsleuth is installed
[21:58] <pedro_> bdmurray: you're welcome
[21:58] <pedro_> jcastro: i have it, but i've played with hipo recently and it seems that after close it, its broken my conf
[21:59] <jcastro> ah
[21:59] <pedro_> No iPods were found in the HAL device tree <- woohoo
[21:59] <pedro_> dammit hipo developers.
[21:59] <jcastro> sounds like the hipo guy broke your thing.
[21:59] <blueyed> sectech: I have no problems with vboxdrv, too, during the upgrade on 64bit. And it went fine for you, too. Can you leave a comment at the bug?
[21:59] <jcastro> I hear that guy is crazy!
[21:59] <sectech> Sure
[22:00] <blueyed> Why isn't there no "Report bug" entry available more convient? (LiveCD)
[22:00] <pedro_> yeah he's mad :-/
[22:02] <sectech> blueyed, wait a min.... This is a gusty -> hardy upgrade
[22:02] <sectech> I didn't do an upggrade... I just installed hardy directly....
[22:03] <sectech> I _can_ do a gusty - > hardy upgrade in a vm if you wish though
[22:03] <sectech> with gusty vbox modules to be upgraded
[22:04] <blueyed> sectech: I've went through Gutsy, too, but only on i386. Please try.
[22:04] <sectech> Okay.... I'll get back to you with the results when I have them....
[22:15] <sectech> What does [need-packaging] bugs get marked as? wishlist?   Bug #228373
[22:17] <crimsun> sectech: yes
[22:17] <sectech> Alright.... can someone mark that one please?
[22:18] <sectech> Also Bug #228361 should be marked as wishlist...
[22:18] <sectech> Considering it is a request...
[22:19] <sectech> crimsun, Do I mark them as confirmed first if they are "new"?
[22:20] <bdmurray> sectech: not for needs-packaging
[22:20] <sectech> bdmurray,  what about the other one,  the guy is requesting md5sums be optional with k3b
[22:21] <bdmurray> Are you sure there isn't a way?
[22:22] <sectech> I'll look into it quickly but I don't believe there is.... It takes forever for DVD md5sums to be done, I think I tried to find a way to turn those off before...
[22:28] <sectech> bdmurray,  you made me think.... but no, there isn't a way that you can turn off md5sums
[22:30] <bdmurray> Okay, so we could set it to wishlist but that would really accomplish much.  It'd be better if we were to forward it to the project's maintainers.
[22:31] <sectech> I have never done anything like that before....
[22:32] <bdmurray> the documentation is a bit sparse - https://wiki.ubuntu.com/Bugs/Upstream/KDE
[22:34] <bdmurray> Basically you'll want to report it at bugs.kde.org and then create a relationship between the two bug reports and let the reporter know what you did and where they can find their upstream bug
[22:35] <sectech> Okay... give me a few min... I'll create an account on bugs.kde.org and I'll just do a quick search to see if there are any dups...
[22:36] <bdmurray> okay, let me know if you have any specific questions
[22:43] <sectech> Okay I have the kde bug number... How do I link it with the launchpad bug?
[22:43] <bdmurray> Click on "Also affects: Project" underneath the Affects table
[22:44] <bdmurray> Screenshots at https://wiki.ubuntu.com/Bugs/Watches
[22:45] <bdmurray> Or that's how you link the Launchpad bug with the upstream bug report
[22:46] <sectech> Okay... I added the upstream bug... do I change the status to confirmed from new?
[22:47] <sectech> I'll also leave a note for the reporter
[22:47] <bdmurray> Yes, confirmed is correct
[22:49] <sectech> There....
[22:49] <sectech> Want to verify that I did it right?
[22:50] <sectech> So anything kde gets sent upstream...
[22:50] <bdmurray> Looks great, I might have used a url in the upstream bug report to make it easier for them but other than that I think it looks good.
[22:50] <sectech> I could add the lauchpad bug link to the upstream report if you like...
[22:51] <bdmurray> Regarding upstreaming, no not really.  It really depends on the bug report.  As this one was a feature request and not something we would patch the Ubuntu package for it made sense to forward it.
[22:51] <sectech> true... no point in wishlisting something if no one will see it
[22:51] <bdmurray> Some bugs may only exist in the Ubuntu version of the package so shouldn't be forwarded.
[22:52] <sectech> ahh ok
[22:52] <sectech> thanks for your help
[22:53] <bdmurray> Thank you for helping out!
[22:53] <sectech> I don't mind at all...
[23:13] <blueyed> sectech: I don't think the k3b one is really a bug.. but it appears to be confusing.. - you can skip this check. I've left comments in the bugs.
[23:13] <sectech> Okay
[23:14] <sectech> blueyed,  I know you can skip the check,  but on a slow system even having the check start can bog down the system a lot.
[23:15] <sectech> Your guaranteed 100% cpu usage on a slower system or a system with not a lot of memory
[23:16] <blueyed> but the system shouldn't get unusable because of this. maybe this is related to the scheduler kernel issues (the released one), if k3b uses another user for doing this. Anyway, the bug appears to need some rephrasing then.. :)
[23:30] <blueyed> You cannot boot amd64 in virtualbox 1.5.x? What a pity.
[23:31] <sectech> after the install?
[23:31] <sectech> I can test that right now...  I am still waiting for gusty 64 bit to come in for the other test
[23:33] <sectech> Whooo crash and burn
[23:34] <sectech> blueyed, Does AMD64 gusty boot?
[23:35] <sectech> I have 26 min before I can test gusty AMD64
[23:36] <blueyed> I've tried to boot hardy amd64 from a hardy amd64 livecd (the livecd image actually)
[23:37] <sectech> blueyed, I have an AMD64 machine and it won't even boot in virtualbox
[23:39] <LimCore> hello
[23:39] <LimCore> how to report a general error like "my computer resets" ?
[23:39]  * LimCore is on https://bugs.launchpad.net/bugs/+filebug
[23:40] <blueyed> sectech: the host machine won't boot in vbox?
[23:42] <sectech> so much for that.
[23:50] <LimCore> how to report a general error like "my computer resets" ?
[23:51] <bdmurray> Do you have any information about the conditions under which it resets?
[23:51] <bdmurray> What exactly do you mean by resets?
[23:52] <secretlondon> LimCore: does it go back to the login screen?
[23:52] <secretlondon> LimCore: or does it go through reloading everything again
[23:52] <LimCore> secretlondon: all frezzes, scren turns off
[23:53] <LimCore> secretlondon: keyboard dont respond (capslock)
[23:53] <LimCore> I guess its a kernel problem, or my hw is broken
[23:54] <LimCore> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/228417
[23:54] <secretlondon> LimCore, first think you need to do is run memtest
[23:55] <secretlondon> LimCore, then we have a page on DebuggingSystemCrash
[23:55] <LimCore> yeah I run it
[23:55] <LimCore> memtest is ok
[23:55] <secretlondon> LimCore, for how long?
[23:56] <secretlondon> random lockups are _very_ hard to debug
[23:56] <LimCore> it worked without such hangs for a year on smae memory sticks
[23:56] <secretlondon> LimCore: https://help.ubuntu.com/community/DebuggingSystemCrash
[23:56] <RAOF> LimCore: Does that crash require compiz?  Do you have a dual-core system?  Does it go away if you disable a core?
[23:57] <LimCore> secretlondon: sys-rq- don't work
[23:57] <LimCore> dual core.  I guess compiz is mostly disabled now
[23:57] <LimCore> but I <3 my dual core :'(
[23:57] <LimCore> well ok whats grub option to disable smp?
[23:57] <LimCore> or install other kernel?
[23:57] <RAOF> LimCore: nvidia introduced a SMP bug somewhere in their drivers which causes random hard-locks while using GL on certain cards, and I don't think it's been fixed yet.
[23:58]  * LimCore slaps nvidia ceo
[23:58] <secretlondon> so that could be workedround by running nv?
[23:58]  * LimCore throws ballmer's chair @ nv
[23:58] <RAOF> secretlondon: Yeah, probably.
[23:58] <LimCore> nv is so slow it makes me sad, plus I use 3d
[23:59] <LimCore> * 3d opengl apps. (well, games ;)
[23:59]  * secretlondon ended up running vesa by mistake *oops*
[23:59] <RAOF> The bug I'm thinking of isn't necessarily the bug you're seeing.
[23:59] <LimCore> how to disable this SMP?  anyone got link to that nvidia bug?
[23:59] <RAOF> LimCore: maxcpus=1, or nosmp, or just disabling a core by writing "0" to something under /sys.
[23:59] <secretlondon> random freezes can have all sorts of causes