[00:06] <Craig73> Newbie question - was just looking through 5-a-day and one of the bug lists I opened up was bugs that are expirable.  In the particular case, the user was having online video playback issues in 8.04.  I could contact the user to see if they are still having issues (considering 8.10 seems to have improved things a lot) but considering it was reported under 8.04 should I be doing much more?
[00:08] <Hobbsee> you can see if you can reproduce the bug on 8.10 yourself, and add that to the bug, too
[00:09] <Craig73> I was able to open the video myself (well best I could considering it was an issue with a live feed they raised at the time)
[00:10] <Craig73> And I will contact the user to see if they have upgraded, and if they are still having issues.
[00:11] <Hobbsee> good idea
[00:11] <Hobbsee> if they say they can't, or just don't respond, eventually you can probably close it, with a "please reopen this if you get this again, as no one else can reproduce this"-type response
[00:12] <Craig73> OK
[00:13] <Craig73> I figured being new I could just spent part of my time churning through old issues that look like they should have gone away,  but wanted to ensure I was handling them appropriately
[00:13] <Craig73> Thanks Hobbsee
[00:14] <Hobbsee> you're welcome
[00:35] <Craig73> When do I count 5-a-day?  After the status changes? (confirmed / closed / triaged)
[00:53] <persia> Craig73, Different people count differently.  Some count for every bug where there was any touch (comment, status, etc.).  Some count for bugs now fixed or invalidated.  Some are somewhere inbetween.  Pick a method that makes you feel good about having done 5 things.
[00:57] <nhandler> persia: Daniel said that they would be discussing 5-a-day at UDS. Do you have any idea what they decided about it?
[00:58] <persia> nhandler, I don't.
[00:59] <nhandler> persia: Ok, I'll ask him tomorrow
[01:06] <Craig73> ok thanks
[01:28] <crimsun> Craig73: the overarching idea is to be consistent, but yes, there needs to be a well defined procedure for applying 5AD
[01:46] <Craig73> crimsun/peria: Sure that makes sense.  I'll count it when the status changes and see how that works for me.  It means it might be a while until I count some of them, but really it's about getting them moving right...
[01:47] <nhandler> Craig73: Just remember to subscribe to the bug ;)
[01:48] <persia> Craig73, Right.  It's about getting them done.  5-a-day is just a means by which one can track how much one's done.
[01:48] <Craig73> @nhandler... yes - I did remember :-)
[01:49] <Craig73> The big pain right now is getting firefox to reconfigure to align with the original issue... it should be simple / but I guess it's learning the quirks
[03:28] <charlie-tca> y
[03:55] <mrooney> kenkku: unfortunately I would say that's WontFix
[03:55] <mrooney> oh sorry, was scrolled up
[03:55] <mrooney> :]
[03:56] <LaserJock> wow, almost 1500 people in ~bugsquad
[04:01] <LaserJock> shouldn't https://wiki.ubuntu.com/Bugs/Responses#Triage%20Successful be setting Triaged not Confirmed?
[04:26] <crimsun> LaserJock: yes
[04:29] <Hew> LaserJock: I think it says confirmed since most users cannot use triaged status. I personally change it to suit the situation.
[04:30] <persia> Having it say "Triaged" when all done isn't bad: maybe encourage those who can't to ask here for the Confirmed->Triaged adjustment.
[04:31] <persia> Well, for some values of done
[04:32] <LaserJock> so what exactly is the point of having Triaged if the triagers can't set it
[04:34] <persia> Dunno.  I don't really like it, personally.  To me it feels like dumping stuff in a bucket that can be ignored.
[04:35] <persia> Maybe there exist developers who perform custom searches for triaged bugs, and try to fix those, but I've not heard anyone claim they do this.
[04:35] <LaserJock> if Triaged is the end goal of triaging I don't understand why it would be ACL'd
[04:36] <persia> There was once talk of having "Confirmed" be handled with an ACL.  I believe this was a compromise.
[04:37] <LaserJock> now I'm confused
[04:37] <LaserJock> when I look at https://wiki.ubuntu.com/Bugs/HowToTriage#Confirming
[04:37] <LaserJock> it says: Are there sufficient log files and crash dumps
[04:38] <LaserJock> wouldn't that be more "Triaged"
[04:38] <persia> No.
[04:38] <persia> If one can't reproduce, but someone else can produce logs or dumps demonstrating the bug, then perhaps it's just hard to trigger, or requires a special setup.  Still really happens.
[04:39] <persia> That said, the set of logs and dumps required to demonstrate that a bug really happens is different than the set of logs and dumps that may be required to determine the solution.
[04:39] <persia> As much as I don't like "Triaged" very much, I believe the intent was to have bugs where the path forward was known carry this status.
[04:40] <LaserJock> https://wiki.ubuntu.com/Bugs/Status just has "Another reporter has experienced the same bug, this can come in the form of a duplicate bug or a bug comment"
[04:40] <persia> Hrm.
[04:40] <persia> Well, only one of those can be correct.
[04:41] <persia> Still, I would say that "Can you reproduce the bug yourself" is a subset of "Can this bug be reproduced", which Bugs/Status seems to imply.
[04:42] <LaserJock> Bugs/Status says specifically that you can't confirm your own bug
[04:43] <persia> Right.  Bugs/HowToTriage assumes that one is dealing with another's bug.
[04:44] <LaserJock> does this definition of "Wishlist" seem right? "Wishlist: a request to add a new feature to one of the programs in Ubuntu. "
[04:44] <persia> Well, that's one class of Wishlist.
[04:45] <persia> WIshlist is also "Please make the background a lighter shade of blue"
[04:45] <LaserJock> that sounds to me like the lowest an actual bug can go is "Low"
[04:45] <LaserJock> and why would a sync request, for instance, be wishlist. they're quite often pretty important
[04:46] <LaserJock> or should I just not mix process bugs with "normal" bugs
[04:46] <persia> No, the sync request itself is completely unimportant.  That said, it might fix an important bug.
[04:46] <persia> Or rather, there might be a fix for an important bug available, but whether that is a sync or not is irrelevant.
[04:47] <LaserJock> hmm, I think of syncs as one of the more important things we do
[04:47] <persia> And yes, mixing process bugs with package bugs is probably not ideal: process bugs exist mostly because of a lack of other effective tracking systems.
[04:48] <persia> syncs are important, yes, but if someone is looking for important bugs to work on, they shouldn't be selecting syncs.
[04:48] <LaserJock> ok, so looking at Bugs/Importance there is split between core and non-core apps
[04:48] <persia> One works the other bugs, and it might be that a sync is a way to address some of them.]
[04:48] <LaserJock> is that roughly Main and Universe or no?
[04:49] <persia> Given that ArchiveReorganisation seems to have led to a potential drop of the main/universe split, that may not be important.
[04:49] <LaserJock> seeded vs non-seeded?
[04:50] <LaserJock> or do we then just not care at all?
[04:50] <persia> Personally, I'd define "core" vs. "non-core" as applications that are required for other applications to work (e.g. X), vs. applications that just do stuff on their own (e.g. firefox).
[04:51] <LaserJock> this doesn't make much sense
[04:51] <LaserJock> Medium is defined for severe bugs on non-core apps
[04:51] <LaserJock> but High is "Has a severe impact on a small portion of Ubuntu users (estimated)"
[04:52] <LaserJock> wouldn't a severe bug on a non-core apps generally be a severe impact on, at least, a small portion of Ubuntu users
[04:53] <persia> I'd think so.
[04:54] <LaserJock> I *thought* we decided to do just per/package importance, rather than distro importance
[04:55] <persia> We did, in Prague.  Doesn't mean anyone updated the wiki.
[04:56] <nellery> I recall it being mentioned in the mailing list ages ago, that somebody was going to update it
[05:00] <LaserJock> .... ok
[05:01] <LaserJock> I've been trying to read up a bit on bug triaging policy, etc. so I could perhaps write an Edubuntu triaging guide
[05:01] <LaserJock> but I'm honestly getting more confused the more I read
[06:24] <andersk> I'm trying to prepare a massfile for bug 305901, and I can't get massfile to create a tag.
[06:24] <andersk> My instructions file is http://launchpadlibrarian.net/20680112/instructions
[06:25] <andersk> which is edited from /usr/share/doc/ubuntu-dev-tools/examples/massfile.instructions, the only source of massfile documentation I could find.
[06:25] <andersk> Does anyone know what's wrong with my template?
[07:15] <YoBoY> hi
[07:42] <Hew> Hi YoBoY
[08:12]  * Hew ponders what to do with a private bug that has a good stacktrace, yet contains X-rated strings
[08:13] <Ryan52> just to be safe, replace them? or would that screw up the stacktrace?
[08:14] <Hew> Ryan52: Yea I suppose I can remove the attachments and attach censored ones
[08:48] <dholbach> good morning
[08:50] <kenkku> morning
[08:50] <dholbach> hi kenkku
[09:35] <thekorn> good morning bugsquad
[09:42] <BUGabundo_work> guudddd morning everyone. and Merry x'tmas!
[09:44] <BUGabundo_work> who is in charge of moderating the devel ML?
[09:44] <BUGabundo_work> got two emails stuck there!
[11:07] <MrKanister> Hi. I very much like to join the UbuntuBugControl team. I have prepared an application and wonder if someone can have a quick look at it, because I am not a native speaker of English (http://paste.pocoo.org/show/96499/) Thanks in advance.
[11:37] <Hew> MrKanister: That looks good to me, except for your selected bugs you need to state the importance you would get them.
[11:39] <MrKanister> Hew: thanks for having a look at it. They all have an importance. I thought I only have to state the importance I would give them if they don't have already one?
[11:45] <Hew> MrKanister: I've just had a look at the bugs, and they seem fine. I guess if they all have importances already that you agree with, then there is no need to restate them.
[11:48] <MrKanister> Hew: Ok, good. Then I will apply to the UbuntuBugControl with that application. Thanks again.
[11:49] <Hew> MrKanister: No worries, good luck :-)
[13:07] <stwange> is there anything I can help with which is relatively small and written in either Perl, PHP or Java? If not, can you point me in the direction of somewhere that might need help?
[13:21] <Hew> stwange: This channel is for bug triage. Someone in #ubuntu-motu may be able to help you :-)
[13:55] <MrKanister> Shouldn't the entire "gnome-icon-theme" package be marked as "won't fix" (bug #209072)? Because the bug still appears in the search.
[13:57] <stwange> thanks Hew:)
[14:10] <Hew> MrKanister: As long as the fix wasn't specific to Hardy, then yes it should be closed. I'd ask about it in a comment first.
[14:11] <MrKanister> Hew: Ok
[14:12] <Craig73> Newbie Q:  When a bug is set to incomplete ... is that "closed enough"?  (I only ask because I was searching for an error I found one marked both incomplete and "marked for expiration 80 days ago")
[14:17] <Hew> Craig73: Incomplete is an 'open' status. "Marked for expiration" appears to be a useless Launchpad feature that should just be ignored.
[14:22] <Craig73> Hew: So what is a closed status? or does a 5-A-Day-er need to worry about that?  I have a ticket that the user said the issue is resolved (their theme in KDE was messing up Firefox) so I was trying to "close it".  Incomplete/Invalid seem like the only options.
[14:23] <Hew> Craig73: Invalid is a closed status. The other two are Won't Fix and Fix Released.
[14:24] <Hew> Craig73: If the reporter says the problem has just gone away, then you should mark it Invalid and leave an appropriate comment, such as the one at the Bugs/Responses page.
[14:25] <Hew> Craig73: https://wiki.ubuntu.com/Bugs/Status
[14:43] <bddebian> Boo
[14:45] <thekorn> hi bddebian!
[14:45] <bddebian> Hello thekorn
[14:54] <Craig73> (Thanks Hew)
[14:55] <Hew> No worries Craig73
[15:00] <BUGabundo_work> FOO
[15:04] <Lupine> what status should I assign to a bug, if I feel it's more of an Enhancement request, but I can duplicate the issue
[15:04] <Lupine> is there a wiki link that describes the proper procedure to responding to a bug report like that?
[15:05] <BUGabundo_work> wish bug, you mean Lupine?
[15:05] <Lupine> I believe so, yes.  I'm referring to this bug: https://bugs.launchpad.net/ubuntu/+source/pidgin-otr/+bug/310769
[15:06] <Lupine> I can duplicate this reporters issue, but it feels more like an enhancement
[15:07] <BUGabundo_work> yep
[15:07] <BUGabundo_work> I would agree
[15:07] <BUGabundo_work> its not a bug per si, but it's a wishlist bug
[15:07] <BUGabundo_work> file it, and submit it upstream too, please
[15:08] <Lupine> ahhh, I think I just found the documentation I was meaning: https://wiki.ubuntu.com/Bugs/HowToTriage#Feature%20Requests
[15:08] <Lupine> I should follow that process, correct?
[15:10] <BUGabundo_work> I would
[15:10] <BUGabundo_work> or at least I try to do it for my bugs
[15:10] <Lupine> hmmm, but the wiki doesn't state if I should change it to Invalid or Incomplete
[15:11] <Lupine> I guess don't change that, and just paste the standard comment as suggested
[15:11] <BUGabundo_work> but the main prob with wishbugs and upstream is that there are SO MANY already that it falls in empty
[15:11] <BUGabundo_work> well wish bugs should stay in NEW AFAIK
[15:11] <Lupine> ok thx
[15:12] <BUGabundo_work> but since I had an KDE dev telling me: "sure file one more wish bug... we already have 680 opened... one more won't make a diff"
[15:13] <BUGabundo_work> I feel a bit discourage to suggest improvements on a BTS
[15:13] <BUGabundo_work> if I don't follow it on IRC or ML
[15:17] <BUGabundo_work> welcome back doko
[15:18] <Lupine> BUGabundo_work, I would tend to agree...thanks for the info
[15:20] <BUGabundo_work> Lupine: my pleasure
[15:22] <itnet7> Bug #310801, Can someone please mark this wishlist, Thanks!
[15:30] <azo> when i forward something to upstream, what i must put in status?
[15:30] <BUGabundo_work> the same as upstream, I supposed
[15:32] <nhandler> azo: If you forward a bug upstream, create a bug watch. The Ubuntu bug most likely should be 'Confirmed'
[15:34] <Craig73> Process Question:  Is it policy to use the sample responses? Sometimes they feel a bit "canned" and impersonal, especially when dealing with a bug that someone hasn't looked at in almost 3 years
[15:34] <azo> nhandler: thank you. that was the info I needed!
[15:35] <BUGabundo_work> Craig73: humm yeah it's a 2 side knife!
[15:36] <BUGabundo_work> the samples are properly written and mean well
[15:36] <BUGabundo_work> are clear, and usually will not offend most users
[15:36] <BUGabundo_work> but, yeah, sometimes it sounds exactly like a can answer
[15:36] <nhandler> Craig73: Some of the responses are more appropriate than others. If I am closing old and incomplete bugs, I feel no problem using the canned responses. For other times, I usually try to right a more personal comment
[15:37] <BUGabundo_work> or help him to file better bugs
[15:39] <Craig73> OK Thanks.
[15:39] <nhandler> You're welcome Craig73
[16:02] <itnet7>  nhandler: do you have a second?
[16:02] <nhandler> Sure itnet7
[16:03] <itnet7> I am pretty new, and I have been wondering how to handle bugs like Bug#310787
[16:03] <nhandler> Bug #310787
[16:04] <itnet7> I think I know what needs to be done
[16:04] <itnet7> but not sure how to go about it
[16:04] <nhandler> Let me read the bug ;)
[16:04] <itnet7> Cool!
[16:04] <BUGabundo_work> humm
[16:04] <itnet7> I think that it needs to be made into a sync request
[16:05] <BUGabundo_work> some one asking for it to be upgrade
[16:05] <BUGabundo_work> would bem why gurest
[16:05] <BUGabundo_work> just a question of it being auto sync or manually merged
[16:06] <nhandler> It is already in ubuntu
[16:07] <nhandler> They have the package wrong
[16:07] <nhandler> boost1.37 is its own source package
[16:07] <nhandler> It should be fix released
[16:08] <itnet7> OH... cool, could you tell it was the wrong version by clicking on the included package and seeing the version difference?
[16:09] <nhandler> itnet7: I clicked on the link they provided. That was for a bunch of binary packages. If you click on one of them, (on the right) it will show you the source package. I then saw it was boost1.37. So I then went to https://edge.launchpad.net/ubuntu/+source/boost1.37 to see if it was in Ubuntu
[16:10] <itnet7> Oh, Thanks alot that really helps!!
[16:11] <nhandler> You're welcome itnet7. rmadison could have also been used to check if it was in ubuntu
[16:11] <itnet7> Oh, I will try and use rmadison first, In this Case I can just mark it Invalid and provide that same link then so Ryan will know it's included :-)
[16:12] <nhandler> I would mark it Fix Released
[16:12] <itnet7> cool thanks!
[16:32] <Craig73> Newbie Q:  How much effort do people put into investigating old issues (older than a year)?  Right now I'm just picking off the bugs that seem minor and confirming if it's still and issue for the user with the expectation they will be just closed.  Any one that seems serious (like QTParted partitioning the wrong partition seems worth further investigation).  Any other thoughts? (don't want to waste too much time / but do want t
[16:33] <persia> Craig73, IF it's still an issue, and in a package someone decides to clear of bugs, it can be a fair bit.
[16:33] <persia> I've personally spent as much as 5 days chasing an issue that had been around for a few years before I attacked it.
[16:33] <persia> That said, bugs get fixed in lots of ways, and older untouched bugs are more likely to have been already fixed by accident.
[16:34] <persia> It's worth checking to see if it's still present: I usually do a test on my own system before asking the submitter, just to avoid asking a question that gets the answer "of course, you idiot: it's obvious".
[16:37] <Craig73> what do you mean a "package that someone decides to clear of bugs"? / are you  meaning someone will pick a package and then go through all of them?
[16:38] <Craig73> I am planning on building a test VirtualBox image... and the issues I have been seeing are messages installing packages or keyboard layout issues; I have no desire to break my machine.
[16:39] <persia> Yes.  That's one of the ways that developers sometimes target bugs.  They will pick a package, and fix as many issues in that package as possible within their span of attention.
[16:46] <Craig73> So we are aiming for - if it's still an issue in a current package, even if the user doesn't care about it, leave it open.  It might not ever get fixed, but at least it's logged.  Even if it's fixed in Intrepid, it might effect someone with an older release (say 8.04 LTS) but until someone with an LTS raises the issue (ie - needs a backport) we can consider it closed.
[16:49] <Craig73> But if it's an old issue, that wasn't reported again, I can't reproduce it, and the user doesn't have an issue with it (even if they moved onto different packages/configurations) then we will close it.
[16:54] <Craig73> (Not trying to over think this... I just don't want to go and close a bunch and mask issues but want to balance that with appropriate time spent)
[16:55] <persia> Craig73, Right.  Ideally, we want the bugtracker to contain the list of known open issues in Ubuntu.
[16:56] <persia> If we can't reproduce it, and nobody else can, it's worth closing.  When closing it, please note that it's being closed because it can't be reproduced and nobody seems interested, and encourage reopening or filing a new bug if anyone can reproduce.
[17:01] <Craig73> ok thanks
[17:59] <skorasaurus> can someone set this bug set to wishlist https://bugs.launchpad.net/ubuntu/+source/scummvm/+bug/85019
[17:59] <skorasaurus> (and forward it upstream)
[18:19] <skorasaurus> hi, I'm triaging an old bug. So, i was going to run a backtrace on it. However, there are no debugging packages for it :/
[18:19] <skorasaurus> the bug in question is: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/85796
[18:22] <skorasaurus> however, I was going to use aptitude to install the program, and that has a debugging package, so I can still debug it following https://wiki.ubuntu.com/Backtrace ?
[18:40] <snap-l> greg-g: ping
[19:25] <MrKanister> Can someone mark the two nee-packaging bugs (bug #310975 and bug #310976) as "wishlist"? Thanks in advance
[19:34] <nhandler> MrKanister: Done :)
[19:34] <MrKanister> nhandler: Thank you
[19:35] <nhandler> You're welcome
[23:50] <daradib> Question: If a beta version of a game (warzone2100) is included in Ubuntu 8.10 (release), is it possible to SRU the final release of the game
[23:54] <crimsun> daradib: does the final release fix bugs? is it minimal impact?
[23:55] <crimsun> daradib: does the final release fix bugs? is it minimal impact?
[23:55] <daradib> or is backporting the only possibility
[23:55] <daradib> it fixes bugs
[23:55] <daradib> minimal impact: first of all it only affects a game
[23:56] <daradib> and debian moved it from unstable to testing
[23:56] <crimsun> daradib: "minimal impact" refers to the source changes; the fewer the changes (the smaller the unified diff), the easier it is to eyeball
[23:56] <daradib> crimsun: ah, thanks
[23:56] <daradib> not simple in that sense
[23:56] <daradib> no one simple patch, if that's what you mean
[23:57] <crimsun> daradib: right, if the diff/changeset is convoluted, that tends to make source verification a bit more difficult, but it certainly does not prevent an SRU from occurring
[23:58] <daradib> once final release of package spends some time in Jaunty, should I follow SRU process for the package
[23:58] <crimsun> daradib: at that point, one needs to weigh the severity of the bugs that the final version fix
[23:59] <daradib> there is a specific fix in release that fixes rendering on Intel GPU's
[23:59] <crimsun> any crashers?
[23:59] <daradib> the version of the package in 8.10 does not render properly with Intel GPU's
[23:59] <daradib> (so that's equivalent to a crash of the game, i guess)