[00:40] <crimsun> welp, got most of the NEW ones through gutsy.  I'll do another pass through the pre-hardy ones tomorrow.
[00:41] <crimsun> friggin firehose
[00:42] <maco> huh
[00:42] <maco> crimsun: could you clarify that?
[00:44] <crimsun> maco: the majority of unacknowledged (NEW) bugs against Ubuntu source packages older than hardy in Launchpad have been triaged
[00:45] <maco> ah ok
[00:45] <crimsun> pretty sad that there were about two dozen unacknowledged ones that are currently exploitable.
[00:45] <maco> O_O
[00:46] <crimsun> doesn't account for duplicates yet; I'll have to streamline that bit
[00:46] <maco> so you were looking through CVEs?
[00:47] <crimsun> all NEW bugs - some were crashers and had apport-produced attachments
[02:03] <pckchem> Hello All.
[03:04] <MTecknology> hi
[03:04] <MTecknology> So - how hard is it to be able to triage bugs?
[03:06] <RAOF> MTecknology: That's somewhat difficult to answer.  Somewhere between "pretty easy" and "manageable", generally.
[03:06] <MTecknology> RAOF: Wanna teach me how to do it?
[03:06] <MTecknology> I think I'm plenty comfortable with invalidating and asking for more information
[03:07] <jmarsden> MTecknology: https://wiki.ubuntu.com/Bugs/HowToTriage
[03:07] <MTecknology> ty
[03:09] <jmarsden> MTecknology: No problem
[03:09] <RAOF> Probably the most important thing to do when triaging is to think, and the most important thing to get on the bug is a step-by-step guide for making it happen.
[03:10] <MTecknology> So once it's been confirmed and there is a detailed explation to reproduce it, then it's worthy of triage?
[03:12] <bucket529> MTecknology: Is there any particular type of bug you are interested in (kernel, firefox, sound, etc)? Are you looking to stick your toe in the water, or get wet fast?
[03:13] <MTecknology> I think toe first
[03:14] <bucket529> Easy to start with are looking through a dozen-or-so needs-packaging bugs. Make sure they're not already in Ubuntu, not in Debian, license is okay, then post here to get is change to 'Wishlist'
[03:15] <MTecknology> I meant toe first in triage
[03:15] <MTecknology> I've done a few iwshlist
[03:18] <bucket529> You can pick your favorite package and see what needs to be done - linking upstream, asking for more, closing out ancient incompletes
[03:19] <MTecknology> bucket529: but closing out ancient incomplete isn't triage either. I've never done triage so I want to play with it a little so I can understand it better.
[03:19] <RAOF> MTecknology: Once it's been confirmed and there's a detailed explaination of how to reproduce it, it's /been/ triaged.
[03:20] <MTecknology> RAOF: and then the only step left to do is flag it that way?
[03:20] <RAOF> Yeah.  The flag is a convenient label, which is only really interesting for the busiest of developers.
[03:20] <MTecknology> ok
[03:20] <MTecknology> oh
[03:21] <RAOF> Setting the "triaged" status is much, much less important than getting all the rest.
[03:21] <MTecknology> For the ubuntu-bugcontrol team application they don't care whether the flag for triage was set or not, they just care that you did the footwork to get the information?
[03:22] <RAOF> Right.
[03:22] <MTecknology> hrm
[03:22] <MTecknology> does the application care whether or not I filed the bug? or just that I went through and got the information
[03:23] <RAOF> The developers largely don't care whether the 'triaged' state is set, either.  We care whether the bug has sufficient detail to be fixed.
[03:23] <MTecknology> So if I found the information needed to fix the bug or got that information out of the user, then it counts in that application?
[03:24] <RAOF> Right.
[03:24] <MTecknology> Don't take it as I'm trying to just meet the minimum for that team, I just wanna have a better idea what they're expecting when I submit that
[03:25] <RAOF> Of course, you don't necessarily need to get the information from the original reporter; it's entirely possible that you can duplicate the bug yourself, and describe how.
[03:25] <MTecknology> RAOF: How does this one count against the app? https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/172372
[03:26] <MTecknology> That thing's from a while ago
[03:26] <MTecknology> Actually, I could add a comment requesting it in the repos and flag as a wishlist?
[03:29] <RAOF> For that you'd want to be checking the Kernel team's triage guidelines (which are somewhat more specific than the rest of Ubuntu's).
[03:29] <RAOF> But generally maintaining drivers outside the kernel tree is a bit of a pain.
[03:29] <MTecknology> oh
[03:30] <MTecknology> would that one count for the application or is that not what they're looking for?
[03:30] <RAOF> It looks like it's in about the right state.
[03:32] <MTecknology> AH!
[03:32] <MTecknology> https://bugs.edge.launchpad.net/ubuntu/+source/pam/+bug/175686
[03:32] <RAOF> I'm not directly involved in bugsquad, so I don't know exactly what they're looking for (just what I'd like them to look for ;)).
[03:32] <MTecknology> How can I make somebody do something about this
[03:33] <pckchem> MTecknology How long have you been triaging?
[03:33] <RAOF> MTecknology: By doing something about it yourself.
[03:34] <MTecknology> idk - I don't really flag them as triaged. I've been working to get bugs fixed for about a year
[03:34] <pckchem> Whats your launchpad name
[03:35] <maco> RAOF: which is interesting, because acceptance by major distros is something upstream kernel.org looks at when considering whether or not to accept a new driver into the mainline kernel
[03:35] <MTecknology> RAOF: how do I do that? create a diff file, upload it, and ask somebody to look at it?
[03:35] <RAOF> That looks like something you could easily create a patch (or, better, debdiff), attach to the bug and subscribe ubuntu-main-sponsors.
[03:35] <MTecknology> <- pckchem
[03:35] <MTecknology> It's a good chance for me to learn how to diff files then :)
[03:36] <RAOF> maco: I didn't say get the driver upstream; I said incorporate into the (Ubuntu) kernel tree.  We've got various patches, incorporate different drivers, etc.
[03:36] <maco> MTecknology: do you mean more specifically than diff -u <oldfile> <newfile>?
[03:36] <MTecknology> maco: nope - that's what I meant
[03:36] <pckchem> exit
[03:36] <MTecknology> chatzilla... fun stuff
[03:37] <RAOF> MTecknology: https://wiki.ubuntu.com/SponsorshipProcess is the relevant wiki page for the whole process.
[03:39] <MTecknology> I'm gonna have a huge patch coming up. I'm trying to figure out whether to fix an application or completely rewrite it. I don't think I really have time for either right now.
[03:40] <MTecknology> bug 286820 is a lot of issues...
[03:41] <RAOF> Huge patches are probably more welcome upstream, where there'll be a more in-depth understanding of the current code.
[03:42] <MTecknology> It'll be completely rewritten probably. In order to fix the issues - it pretty much needs a daemon
[03:42] <MTecknology> or maybe split the two parts...
[03:43] <MTecknology> hrm - why am I not seeing a large majority of bugs I've reported
[03:45] <MTecknology> I've reported a lot more bugs that what's showing up :(
[03:45] <maco> MTecknology: go to advanced and tell it to show bugs that have been marked as duplicates
[03:46] <MTecknology> thanks
[03:47] <MTecknology> I'm still not seeing them :P
[04:15] <MTecknology> Well - as far as the application goes, I need to find about 1 more bug. I wonder if my past bugs got lost when I changed emails
[07:08] <ScarySquirrel> Will someone volunteer to help me out with a problem with the volume widget in GNOME 2.24.1?
[07:08] <ScarySquirrel> Do not everyone volunteer at once.
[07:12] <nellery> ScarySquirrel: support is in #ubuntu
[07:13] <ScarySquirrel> Well, it's catch as catch can over there.
[07:30] <dholbach> good morning
[11:22] <hggdh> hi seb128, do you want to add the patch for bug 205999 to Intrepid?
[11:23] <seb128> hggdh: let's wait for 2.24.2 to move to intrepid-updates before
[11:23] <seb128> an another upload would reset the counter
[11:23] <seb128> hggdh: is the patch confirmed to work correctly now?
[11:23] <hggdh> OK
[11:24] <hggdh> seb128, it is.
[11:24] <seb128> cool
[11:24] <hggdh> Jaunty with 2.25.2 already has it
[11:26] <seb128> jaunty doesn't have 2.25 yet
[11:26] <seb128> but it'll probably be uploaded this week
[11:26] <seb128> not worth doing a backport there
[11:26]  * Hobbsee is looking forward to dist-upgrading next week
[11:27] <seb128> Hobbsee: next week is uds so you should not get too many updates
[11:28] <Hobbsee> seb128: indeed.  and good bandwidth :)
[13:28] <xteejx> Afternoon everyone :)
[13:35] <xteejx> What are we to do with seriously old bugs that are needs-packaging, as many of the projects they want packaged aren't maintained anymore
[13:37] <xteejx> Am I right in assuming we invalidate them?
[14:53] <xteejx> Is there anyone here?
[14:54] <afflux> no
[14:54] <xteejx> lol
[14:54] <afflux> 127, to be exact
[14:54] <xteejx> Obviously, I menat is anyone available to help as hardly anyone ever answers...
[14:55] <afflux> I seem to have missed your question
[14:55] <xteejx> Question: What are we doing with the really old bugs that are needs-packaging, I come across quite a few that aren't maintained anymore, am I right in assuming Invalidating them is the right way?
[14:56] <xteejx> They're around 2 years old the packages, not bee ntouched since
[14:57] <afflux> hm, I think we discussed this not too long ago. Someone (was it james_w?) suggested to leave them as the packages are still not packaged and it has not been fixed.
[14:57] <afflux> it = the "bug"
[14:58] <james_w> I would say just leave them
[14:58] <xteejx> Even the ones that refer to packages/source that haven't been updated in 2 years?
[14:58] <james_w> if the homepage of the project has disappeared then they can probably be closed
[14:59] <james_w> it may be that they haven't been updated because they are perfect :-)
[14:59] <xteejx> A bugless package? I find that very hard to believe lol
[15:00] <afflux> for example, my code is always perfect :)
[15:00] <xteejx> What normally happens with the needs-packaging anyway, does someone adopt it and put it thru REVU, etc?
[15:01] <afflux> yes
[15:01] <xteejx> ok wicked, just clearing loose ends in my head :)
[15:01] <afflux> oh, I'm not sure about the what the motus do, but non-motus need to go through revu.
[15:02] <xteejx> thought so. no probs just wanted to clear that up :) thanks guys
[15:02] <afflux> you're welcome
[15:04] <bddebian> Boo
[15:21] <afflux> I don't get bug 304013. How is it possible that /etc/init.d/NetworkManager does not exist if the package was just unpacked right before?
[15:21] <james_w> it's a conffile
[15:21] <james_w> so I believe you can do it if you install the package, delete the file, remove (not purge) the package, then re-install it
[15:22] <james_w> or if it's an upgrade you can just have deleted it
[15:23] <afflux> james_w: it's failing in the post-installation, so I thought it would have been re-installed anyways
[15:41] <symptom> There is a bug with Totem where it enters a bad state when starting a video (.avi) while nautilus is moving a file from internal HDD (EIDE) to external (usb2.0) (file operation window open).  The video that you start playing resides on the external which is encrypted using truecrypt.  What ends up happening is totem stalls,  the video doesnt open, and it has to be "force quited."  Subsequent attempts to open a video using totem result
[15:41] <symptom> s in the same issue, with or without a file operation taking place.  Ubuntu 8.10 all updated standard packages on all except truecrypt.  I downloaded truecrypt from their site and installed it w/o apt, but I think the versions are still the same.  I would enter a bug, but I am really busy the next 3 weeks, and will be away from my system.
[19:06] <MrKanister> Hello. Can somebody please set this to "wishlist" : https://bugs.launchpad.net/ubuntu/+source/firefox-3.1/+bug/304060
[19:08] <bdmurray> done
[19:10] <MrKanister> bdmurray: Thank you
[19:10] <bdmurray> no problem
[19:15] <xteejx> Hey bdmurray, just a quick question. Is there any word on my Bug Control application yet? :)
[19:19] <bdmurray> xteejx: I was on holiday most of last week but will look at it again soon
[19:21] <xteejx> bdmurray: Great! Thanks a lot. How's the Isle of Man anyway :)
[19:43] <farmin> n
[20:13] <MrKanister> Hi. Can someone please set that bug to "wishlist" : https://bugs.launchpad.net/apport/+bug/304129/
[21:10] <MrKanister> Hi. Can someone please set that bug to "wishlist" : https://bugs.launchpad.net/apport/+bug/304129/
[21:13] <bdmurray_> MrKanister: Having that bug report in Launchpad seems fine as the scope of the feature is rather limited
[21:13] <bdmurray_> However, the retracer uses the debug packages anyway so I'm not certain what the reporter is looking for.
[21:14] <MrKanister> bdmurray_: You mean the hint to brainstorm.ubuntu.com? I was unsure if he knows about it and if he has more ideas thaht would me the best place
[21:15] <bdmurray> For some ideas brainstorm is the right place, it really depends on the idea.
[21:15] <MrKanister> You are right. To open an idea on this specific bug would be not soo good
[21:16] <MrKanister> thanks for setting sthis to wishlist
[21:17] <bdmurray> No problem, thanks for helping out.
[21:17] <MrKanister> with pleasure
[22:11] <xteejx> Question: Why are there so many New status needs-packaging bug reports? Are these meant to be set as confirmed if they're not in Ubuntu or Debian repos as per the wiki page?
[22:13] <bdmurray> xteejx: yes, confirmed if not in Debian or Ubuntu
[22:15] <xteejx> bdmurray: Cool thanks brian :)
[22:15] <xteejx> I assume I'm OK to go through all these seriously old ones in reverse order to clear out the crunf?
[22:19] <bdmurray> xteejx: for the needs packaging ones?
[22:21] <xteejx> bdmurray: No I'm going through ALL new status bugs in reverse order, I assume that's OK?
[22:22] <bdmurray> xteejx: that sounds fine depending on the actions you are taking
[22:22] <xteejx> Theres quite a few that are over 5 months old with no updates (reports)
[22:23] <xteejx> I'm following protocol not to worry :) incompleting them asking for more info, try it on intrepid, confirm if so, invalid if not etc etc
[22:23] <bdmurray> Yeah, that sounds great!
[22:24] <xteejx> Just thought it might be a good idea and should definately show better in our stats as they're adding up - so I'm off to work :)
[22:38] <jayson_r> xteejx: i've been doing the same thing the past few days
[22:38] <jayson_r> xteejx: i've gotten quite a few "thank you's" in the process and a couple of "i didn't think anyone cared"...
[22:52] <xteejx> jayson_r: Same here, it seems during Hardy quite a few bugs were ignored or missed