[00:00] <bdmurray> Okay, we've recently hired a couple of people so it'll be a bit for us to solidify roles and responsibilities and see how we are doing.
[00:01] <sectech> bdmurray,  I'll be around for a while... I usually stick with something if I like it...
[00:08] <nhandler> Does anyone know why the 5-a-day stats page is not giving me credit for one of the bugs that I fixed. If you look here: http://bazaar.launchpad.net/~5-a-day/5-a-day-data/main/revision/4412, you will see that I have fixed 15 bugs. However, the stats page is only listed 14. It was just updated, so it should list all 15, shouldn't it?
[00:32] <hggdh> nick hggdh|away
[00:32] <hggdh> duh
[00:35] <sectech> nhandler, I just added myself to the 5 a day team... where is the stat page?
[00:35] <nhandler> sectech: The stats page is here: http://daniel.holba.ch/5-a-day-stats/
[00:37] <sectech> nhandler,  do they have stats for the specific members? like how would I get my stats?
[00:37] <asac> hggdh|away: whats up?
[00:37] <nhandler> sectech: Start by reading the wiki page: https://wiki.ubuntu.com/5-A-Day. That will explain how to set up 5-a-day to submit your data.
[00:38] <sectech> asac, He was curious if you meant to wishlist bug #209258
[00:39] <asac> sectech: i didnt ment anything. just moved it to firefox 3 for now
[00:39] <asac> :)
[00:39] <sectech> ahh that's what I thought.
[00:39] <asac> but well its a wishlist bug, yes.
[00:39] <asac> if there is no bug in bugzilla.mozilla.org, look in forums.mozillazine.org
[00:39] <sectech> K... that's what we were wondering early in the day
[00:39] <asac> most likely it was discussed before
[00:40] <asac> if not, open a wihslist bug agains the right component upstream and drop that bug id in the bug
[00:40] <sectech> Okay
[00:40] <asac> but only do that if you support that wishlist bug ;)
[00:41] <asac> i refuse wishlist bugs tha ti dont support. tell the reporter that wishlist bugs should be dealt with in forums.mozillazine.org
[00:41] <asac> :)
[00:42] <sectech> I know that the issue is annoying... BUT.... I don't know if I would put myself behind it... It is a working feature and I don't have any new suggestions.
[00:46] <asac> sectech: yeah. thats basically always the case. best thing you can do is keeping bug open, pushing reporter to go forums and if people cheer there, open an enhancement bug and drop the bug id
[01:12] <hggdh|away> asac hello, it was about this bug indeed
[01:14] <hggdh|away> bdmurray, ping
[01:14] <Nattgew> what exactly do you have to do with a bug for it to be one of your 5-a-day?
[01:15] <bdmurray> hggdh|away: pong
[01:15] <hggdh|away> bdmurray, asac just said something that makes sense -- if a bug is a wishlist, open upstream. Should we put it on the checklist for all?
[01:16] <persia> Nattgew: Take care of it sufficiently that it there's nothing else pending just now (for something that needs work).
[01:16] <persia> This might mean fixing it.  It might mean good triage.  It might mean passing upstream cleanly.  It might mean rejecting it.  There's lots of things that bugs need done to them.
[01:17] <Nattgew> is just a confirm sufficient?
[01:17] <hggdh|away> Nattgew: if there is enough data to confirm, yes
[01:17] <Nattgew> ok, thanks
[01:17] <persia> Nattgew: That's typically light: better if you can get it fully triaged: to the point where it's not only confirmed, but understood.
[01:18] <asac> hggdh|away: no i said: if its wishlist and you fully support it, make it your own bug and forward upstream
[01:18] <asac> otherwise tell user how he can do it on his own if he really cares enough
[01:18] <asac> and keep our bug open
[01:18] <asac> ask the user to drop the upstream bug id in case he filed one
[01:18] <asac> thats it ;)
[01:18] <persia> Anything going upstream needs someone to chase it, and if it's a new feature, likely needs someone to help rough out the feature spec and work with upstream to get it right.
[01:19] <hggdh|away> asac, thanks. bdmurray, what about adding it in?
[01:19] <hggdh|away> persia: I thought we would take care of it...
[01:19] <asac> maybe we should point people that just have "ideas" to brainstorm
[01:20] <asac> and close the wishlist bug ;)
[01:21] <hggdh|away> this is not a bad idea at all...
[01:21] <persia> hggdh|away: Sometimes we can.  Sometimes it's hard.  Imagine a user who opens a bug: gdm should let me log in by saying "Hello".
[01:22] <hggdh|away> OK, no need to go that far :-)
[01:22] <persia> Wouldn't this user, who might have a significant test case where this is required, be more qualified to work with upstream to get it right?
[01:22] <persia> (it's not that far: there are some voice-authentication systems out there, just not working properly in Ubuntu yet)
[01:23] <pwnguin> "My voice is my passport; verify me"
[01:23] <hggdh|away> yes, I get the picture. What I am trying to find out is how to describe the process to beginning triagers
[01:23] <persia> asac: That's a really good idea.
[01:23] <persia> Can brainstorm link to upstream enhancement requests?
[01:24] <asac> hard to say.
[01:24] <asac> i am not using it ;)
[01:24] <hggdh|away> but we can add a manual link
[01:24] <hggdh|away> worst scenario
[01:24] <asac> at least it should have a feature to make an ubuntu bug out of it once someone decides to seriously work on it
[01:24] <persia> Maybe someone who uses brainstorm could open an idea that brainstorm should support links to upstream enhancement requests :)
[01:25] <hggdh|away> or a bug
[01:25] <persia> asac: bug or blueprint?
[01:25] <hggdh|away> maybe we should open a bug for brainstorm to support a bug
[01:26] <Nattgew> if a bug filed on a previous kernel is fixed in the current version, can it closed?
[01:26] <persia> Let's just go for an ability to add links to external trackers.  That supports enhancement requests, specs, bugs, etc.
[01:26] <asac> persia: i think bugs (ubuntu/upstream) should not be opened before someone works on it. specifications could be linked before, true.
[01:27] <asac> but well. there might be uses for linking to bugs for sure
[01:27] <persia> asac: For Ubuntu, I agree.  For upstream, I think it depends on upstream.  I know several upstreams who use trac and collect enhancement requests on lists to then target for each development cycle.  These are somewhere between LP bugs and LP blueprints.
[01:42] <Nattgew> since bcm43xx is being replaced by b43, can bugs filed because of it be invalidated?
[01:45] <persia> Nattgew: For a few previous migrations like that, we tested the old bugs against the new system, and reported most of them solved by the migration.
[01:45] <persia> Those that applied to both, we re-triaged for the new system.
[01:45] <persia> It's a little more work, but it ensures that we get the best quality we can.
[01:46] <Nattgew> so the same goes for new kernel versions?
[01:49] <persia> Nattgew: Kernels are a little special, but I think the transition to the "linux" source package was intended to allow for a similar sort of thing (previously there was a separate source package name for each kernel version)
[01:52] <Nattgew> if a bug in an old version of a kernel or deprecated program/whatever is fixed in whatever supercedes it, is the bug fix released or invalid?
[01:52] <persia> Depends on the nature of the bug and the transition.  Sometimes it's Won't Fix.
[01:53] <persia> The general guideline is to provide a meaningful status to the reporter (and other subscribers)
[01:53] <persia> From what I've seen, Fix Released is most common, often with comments explaining the transition (if it isn't automated)
[01:56] <yuriy> what to do if a developer can't see apport bugs because they are private?
[02:00] <crimsun> bdmurray: would it be feasible to add me to ~ubuntu-bugcontrol?
[02:04] <persia> yuriy: Someone who can see them should review the content to make sure there is no private information.  Once done, if there's nothing private, it can be made public.
[02:05] <persia> Dangerous things would be undigested core dumps, private data (credit card numbers, etc.) in stack traces, tec.
[02:05] <yuriy> persia: OK, I think that is the case here
[02:05] <yuriy> persia: but if there was something private, would it be OK to subscribe/assign the developer of the application anyway if they aren't already?
[02:06] <persia> yuriy: If you know they can be trusted with that information.
[02:06] <yuriy> that is the case meaning these can be public. it's python stuff with no core dumps
[02:08] <persia> crimsun: There's been a recent change.  See http://lists.launchpad.net/ubuntu-bugcontrol/msg00025.html
[02:08] <persia> yuriy: Even python traces sometimes expose private informtion, but it's easier to tell :)
[02:09] <yuriy> would be quite interesting if you had to enter your credit card number to configure compiz :D
[02:09] <bdmurray> persia: the change hasn't been implemented yet
[02:10] <persia> bdmurray: Ah.  My misunderstanding.  Thanks for the clarification.
[02:10] <bdmurray> hopefully the discussion will go quick though. ;)
[02:10] <bdmurray> crimsun: sure, I can do that
[02:11] <bdmurray> crimsun: you're all set
[02:16] <mrooney> What is the criteria for fixing a bug in a package in Hardy? The bug must have certain attributes?
[02:19] <persia> mrooney: http://wiki.ubuntu.com/StableReleaseUpdates
[02:20] <mrooney> persia: thanks :)
[02:24] <mrooney> any idea if bug #237473 might be a candidate (ignore that it isn't filed against Ubuntu yet :)? it restores functionality via a trivial patch attached
[02:30] <persia> mrooney: It looks safe enough to me, but I can't speak to how critical it is.  You might ask if someone from MOTU SRU is available in #ubuntu-motu: these are the people who are authoritative about whether something can get in.
[02:32] <mrooney> yeah, I was wondering if the importance becomes less necessary as the trivialness of the patches increases
[02:32] <soonick_cancun> bdmurray: Hello bdmurray, are you busy?
[03:59] <Hobbsee> hggdh: pong
[03:59] <hggdh> ping Hobbsee
[04:00] <hggdh> Hobbsee: now I do not remember what it was anymore (your day is starting, mine is ending)
[04:00] <hggdh> :-(
[04:00] <hggdh> awfully sorry, Hobbsee
[04:01] <Hobbsee> hggdh: oh dear.
[04:01] <Hobbsee> it's 1pm here.  i guess that counts as starting :)
[04:02] <hggdh> ah, yes, I guess so. It's two pure malts too late, I would say ;-)
[04:03] <crimsun> persia: / bdmurray: thanks.
[04:13] <techno_freak> nice clip to confirm bug #235804, now someone needs to set the importance so it gets noticed
[04:18] <hggdh> techno_freak: can you also reproduce it?
[04:19] <hggdh> techno_freak: and -- what package does this apply?
[04:19] <techno_freak> hggdh, not me
[04:19] <hggdh> ubuntu, is *not* a valid package
[04:20]  * techno_freak looks into it
[04:21] <hggdh> techno_freak: apt-cache search trashapplet
[04:22] <techno_freak> ok
[04:22] <hggdh> it helps ;-)
[04:24] <techno_freak> gnome-applets :)
[04:24] <hggdh> techno_freak: yes
[04:25] <hggdh> but I would like to confirm the version of gnome-applets and gnome-panel before fully confirming it
[04:25] <techno_freak> ok, i will move it back to incomplete and ask for those information
[04:26] <hggdh> you could ask the reporters to run 'dpkg -l gnome-applets gnome-panel'
[04:26] <hggdh> techno_freak: otherwise, good work
[04:26] <hggdh> thanks
[04:26] <techno_freak> thanks hggdh
[04:28] <hggdh> finally, techno_freak -- it does sound like either gnome-applets or gnome-panel (or, perhaps something else ;-)), so I guess we could set it as gnome-applets since trashapplet belongs there
[04:28] <techno_freak> okay :)
[04:28] <hggdh> and, again, thank you for helping
[04:58] <techno_freak> bug #237809 seems to be a wishlist
[05:07] <pwnguin> that screenshot confuses me
[05:09] <RAOF> That screenshot looks crazy.
[05:14] <pwnguin> plus, my rhythmbox UI is like, three buttons on a gnome-panel applet: previous, pause/play and next
[05:15] <pwnguin> if rhythmbox ever implmements selectable default playlists, I'll never care what the ui look like again
[05:19] <darthanubis> Bug #235759
[06:35] <mrooney> pwnguin: what is a selectable default playlist?
[08:25] <pwnguin> mrooney: id like to be able to set which playlist comes up when rhythmbox starts up,
[15:25] <afflux> morning
[15:39] <bddebian> Boo
[15:40] <ogra> bee
[15:47] <sectech> I believe bug #234175 needs to be wishlisted, since it really isn't a bug and more of a request
[15:51] <james_w> sectech: hi, I'm not really sure what they are asking for?
[15:51] <james_w> they'd like some emoticons to be used there, but not others?
[15:52] <james_w> it's probably wishlist, yes, but I'd want some more details from the user first.
[15:52] <sectech> james_w,  The reporter was stating that _some_ emoticons can cause problems in the nickname line...  The problem is, how do you distingish
[15:52] <sectech> I understand what he means... would you like me to add a note clarifying?
[15:53] <james_w> that would help
[15:53] <sectech> Okay..
[15:56] <sectech> There, see if that helps
[16:01] <james_w> So you think they want a way to mark a custom emoticon such that it won't be shown in a user's name?
[16:02] <sectech> Exactly.... The problem is, it all depends on what emoticons the user has in his/her custom library... There might be one that causes no problem at all... It's very user specific
[16:02] <james_w> could you update the title of the report then please?
[16:02] <james_w> I'll mark it wishlist
[16:03] <james_w> another possibility would be to not substitute if the matching string is part of a word.
[16:03] <james_w> and take it out of incomplete as well please.
[16:04] <sectech> It was marked as new, I brought it to incomplete to ask in here... I know a lot of triagers don't like wishlisting bugs marked as new
[16:04] <sectech> I just confirmed it
[16:04] <james_w> thanks
[16:04] <sectech> The reporter had returned it to new after he replied a while back(pet peeve)
[16:05] <sectech> james_w, Thank you for your help :)
[16:05] <james_w> no problem, thanks for working on it.
[16:05] <sectech> james_w,  hey btw... I applied yesterday ;)
[16:06] <sectech> I know I said I wasn't going to for a while, but I believe I have the hang of it
[16:09] <james_w> we're just discussing changing the approval process a little, so I may get a chance to check over your application.
[16:09] <james_w> good luck :-)
[16:09] <sectech> thanks :)
[16:09] <sectech> bdmurray,  you around? (unrelated)
[16:16] <bdmurray> sectech: yep
[16:16] <sectech> Bug #228361 you changed from confirmed back to new... That was the one you helped me send upstream...
[16:17] <sectech> I'm just wondering why it would be "new" instead of confirmed...
[16:35] <elliotjhug> hi all, I've been doing bug triaging occasionally for a while. But one of the main prerequisite for going for ubuntu-bugcontrol is having a list of 5 'best' triaged bugs. Is there a definition for what a well triaged bug is or is it just a matter of following the guidelines for each bug and making up a list?
[16:38] <mrooney> elliotjhug: I don't think there is a specific guideline, but we like to see that you have followed the ubuntu code of conduct, been helpful/courteous to users and devs
[16:39] <mrooney> if you have edited the title/description to make it more useful, set the status to something useful, followed up/forwarded upstream if necessary
[16:40] <bdmurray> sectech: Looking at the timing of the change I may not have reloaded the bug's page after you changed the status
[16:40] <elliotjhug> mrooney: Great, thanks a lot
[16:41] <bdmurray> So I would have still had the New status.  Regardless it was unintentional.
[16:41] <sectech> bdmurray,  ahh okay...  Good thing I looked through my bug list
[16:42] <mrooney> bdmurray: it is almost like we need an AJAX-y Launchpad to check for updates and inform the user
[16:42] <mrooney> usually I try to refresh right before editing and have been glad that I have a few times
[16:42] <sectech> I fixed the status
[16:43] <sectech> of the ubuntu part of the bug anyway
[16:43] <bdmurray> sectech: great
[16:43] <bdmurray> mrooney: I don't think it happens that often
[16:43] <mrooney> yeah, it could just be me
[16:44] <mrooney> I always open bugs to look at/triage later
[16:44] <bdmurray> There are enough bugs for everybody. ;)
[16:45] <sectech> Wishlist, new shouldn't be an appropriate combination right?
[16:45] <sectech> for anything.
[16:45] <sectech> because new implies the bug hasn't been touched
[16:46] <mrooney> sectech: well, technically I think it implies the status hasn't been touched, but maybe you are correct
[16:46] <bdmurray> Generally speaking yes but there are corner cases for everything.
[16:46] <sectech> bdmurray,  of course... special cases excluded...
[16:46] <mrooney> what about #237809, for example?
[16:46] <mrooney> bug 237809...that is
[16:46] <bdmurray> bug 237809
[16:46] <sectech> I just had to fix a couple general bugs in my list that were wishlisted..
[16:47] <mrooney> I was going to mark it Invalid but seb128 beat me to triaging
[16:47] <mrooney> and I figured he knows way more than I do so I shouldn't change it
[16:49] <bdmurray> There are different ways of looking at feature requests and those can be quite subjective.
[16:50] <bdmurray> However, I think it should be Confirmed so people looking for new bugs won't run into it.
[16:57] <mrooney> bdmurray: in regards to elliotjhug's question, is that on a wiki anywhere? Your email just yesterday I think pertains to it
[16:57] <mrooney> about what people looking at BugControl applications should look for, criteria, et cetera
[16:57] <mrooney> that would be a good resource for applicants as well I suspect
[16:58] <sectech> If I get approved for bugcontrol am I going to have to go through all my bugs and assign a priority?
[16:58] <mrooney> sectech: nope I don't think so
[16:58] <mrooney> just because you can set a priority doesn't mean you always understand what it should be for every bug :)
[16:58] <sectech> thank god... that would be like 99 bugs I would have to change.
[16:59] <bdmurray> You wouldn't "have to" but it would helpful if you knew them
[16:59] <sectech> mrooney,  I would use the wiki as my guideline of course.
[16:59] <mrooney> but at the same time if you have already worked with them and are pretty confident of importances for some of them
[17:00] <mrooney> sectech: I found when I got approved I didn't have many Importances to set because I had already asked others to do so for me, explaining the reasoning
[17:00] <bdmurray> and if they are incomplete you'll get back to them and can set it eventually
[17:00] <sectech> indeed...
[17:00] <mrooney> sectech: I don't know if you knew but if you just paste a bug number here you can request that someone set an Importance if you explain why and they agree, of course
[17:01] <sectech> mrooney,  If I did that for all the issues I triaged this channel would have a ton more chatter from me...
[17:01] <bdmurray> mrooney: since the criteria are still under discussion I think we should wait before writing it up
[17:01] <sectech> I tend to take on 15 to 20 a day
[17:02] <mrooney> sectech: nothing wrong with chatting in a chatroom
[17:03] <mrooney> but I see what you mean, it could just be for the ones you are the most confident about
[17:03] <sectech> mrooney,  True... but I have a hard enough time requesting a wishlist on a day when the regulars arn't here.
[17:03] <elliotjhug> in regards to mrooney's question regarding my question it would be great if someone did find that wiki page
[17:05] <mrooney> elliotjhug: I think the conclusion was there isn't one yet
[17:05] <mrooney> elliotjhug: bdmurray was drafting it in the BugControl mailing list just yesterday
[17:05] <elliotjhug> mrooney: ah - fair enough
[17:05] <mrooney> about what criteria BugControl members should look for when reviewing applications
[17:06] <mrooney> but I was saying that would be great for applicants as well, so I imagine it will eventually find a home on the wiki!
[17:18] <sectech> hmm...
[17:19] <sectech> I know my input isn't really counted but I agree with the automatic bounce part if they don't give a status in there examples.
[17:19] <sectech> Considering the whole point of applying is to see if you understand them
[17:35] <elliotjhug> weird
[18:14] <soonick_cancun> bdmurray: hello bdmurray. Are you busy?
[18:15] <bdmurray> soonick_cancun: kind of but I'm waiting on some queries to run at the moment
[18:16] <soonick_cancun> bdmurray: so, do you have time?
[18:16] <soonick_cancun> just a little. I have some doubts
[18:16] <bdmurray> sure
[18:16] <soonick_cancun> bdmurray: do you remember me?
[18:17] <soonick_cancun> You helped me to confirm an abiword bug
[18:17] <bdmurray> soonick_cancun: we talked about abiword and how to triage on Tuesday
[18:17] <soonick_cancun> bdmurray: we didnt triage, we just confirmed it
[18:17] <soonick_cancun> but you have good memory :)
[18:17] <bdmurray> confirming is part of the triage process
[18:18] <soonick_cancun> bdmurray: I made some discoverings but i dont know if they are relevant
[18:18] <bdmurray> what was the bug number again?
[18:19] <soonick_cancun> Bug #20063
[18:21] <soonick_cancun> bdmuray: what i saw is that when i open abiword on a terminal and click on "Report a bug" i get sh: Syntax error: "(" unexpected
[18:22] <bdmurray> soonick_cancun: that's great and seems quite helpful
[18:24] <soonick_cancun> bdmurray: but there is something else i downloadedthe source to try to fix it but whe i compiled it i didn't get the error
[18:26] <soonick_cancun> is that a packaging error?
[18:26] <bdmurray> soonick_cancun: which source did you download?
[18:26] <soonick_cancun> i used apt-get source abiword
[18:27] <bdmurray> and you used make instead of debuild?
[18:27] <soonick_cancun> yes, i used make
[18:28] <pwnguin> is "string-fix" for po files only or can it be xml?
[18:29] <bdmurray> the po files are translations so I wouldn't use string-fix there.  Do you have an example?
[18:29] <bdmurray> soonick_cancun: hmm, that is interesting
[18:30] <pwnguin> http://gitweb.compiz-fusion.org/?p=fusion/plugins/colorfilter;a=commit;h=759fec
[18:30] <soonick_cancun> bdmurray: yes i tought that too
[18:31] <soonick_cancun> bdmurray: should i comment it in the bug. Should i try to package it myself?
[18:31] <bdmurray> soonick_cancun: I'd comment on both in the bug
[18:32] <soonick_cancun> bdmurray: do you think it is a packaging bug?
[18:34] <bdmurray> soonick_cancun: I'm really not certain.  What architecture are you using?
[18:34] <bdmurray> pwnguin: what am I looking at exactly?
[18:35] <pwnguin> its a diff to an xml file that controls a ccsm module
[18:35] <pwnguin> click on diff ;)
[18:35] <pwnguin> not a po file
[18:35] <bdmurray> okay, I guess I'm not certain the right way to spell either of those words - is one of them wrong?
[18:36] <pwnguin> no no
[18:36] <pwnguin> i'd like that patch in ubuntu
[18:36] <soonick_cancun> bdmurray: an lg notebook with a celeron M i386
[18:37] <pwnguin> the explaination of the tag on wiki/bugs/tags says non code stuff; i was curious if XML counted as non-code
[18:38] <bdmurray> bug 209049 is a good example of what a string-fix bug is
[18:38] <pwnguin> so its fixing an existing string
[18:39] <bdmurray> Basically they are typos or grammatical errors
[18:39] <bdmurray> pwnguin: that's correct
[18:39] <pwnguin> not nessecarily a fix by adding strings
[18:39] <pwnguin> anyone opposed if i edit the wiki to reflect that?
[18:40] <bdmurray> not I, that'd be great
[18:40] <pwnguin> also, does anyone use a tag to reflect patch availability?
[18:41] <bdmurray> It is possible to flag attachments as patches so that might be redundant
[18:42] <pwnguin> well, it's a patch in git; not sure it really needs to be broken out into a patch
[18:42] <bdmurray> which launchpad bug are you looking at?
[18:43] <pwnguin> bug #237848
[18:44] <bdmurray> hrm, if there were an upstream bug watch and that upstream bug were fixed it would be possible to search for that
[18:44] <pwnguin> i pinged upstream last night and they got it fixed
[18:45] <pwnguin> search for what?
[18:45] <bdmurray> bugs resolved upstream
[18:45] <pwnguin> i see
[18:46] <pwnguin> it was faster to just ask on irc ;)
[18:46] <pwnguin> rather than register a new account, ask a developer to look at it, link it on LP and so on =(
[18:47] <pwnguin> anyways, mvo says the package will likely be pulled from upstream again this cycle
[18:47] <bdmurray> I see your point there just isn't a good way to represent that this bug has a fix and for people to find it
[18:49] <pwnguin> at which point, it'll be fixed without many knowing it was ever a bug
[18:49] <bdmurray> and possibly fixed w/o the bug being closed which would be unfortunate
[18:50] <pwnguin> i'll keep a watch on it :)
[18:55] <soonick_cancun> bdmurray: i have a lg notebook with a celeron M i386 is that relevant?
[18:56] <pwnguin> does LP not track independent gforce installs very well?
[18:57] <bdmurray> soonick_cancun: the fact that you are using the i386 package and I'm using amd64 might be
[18:59] <soonick_cancun> bdmurray: that is true. But i find weird that when i compile it with make i dont get the bug
[18:59] <bdmurray> ah, right
[18:59] <bdmurray> I'm really at a loss now
[18:59] <bdmurray> jcastro: ping
[19:01] <Nattgew> hi i followed up on #69925, a workaround has been found, so i think it can be marked as triaged, can somebody do that?
[19:01] <pwnguin> bug #69925
[19:02] <pwnguin> kernel bugs have a slightly different work flow
[19:02] <soonick_cancun> bdmurray: ok i have reported what i found and ill try to test it on another amd64 computer to see if the arquitecture is causing the bug
[19:02] <soonick_cancun> thank you for your time ;)
[19:04] <bdmurray> soonick_cancun: no problem, thank you for helping out!
[19:05] <soonick_cancun> bdmurray: ;) see you
[19:05] <hggdh> Nattgew: this bug has a binary dsdt
[19:07] <jcastro> bdmurray: pong
[19:08] <bdmurray> jcastro: a triager who just left and I were looking at an abiword bug, nothing that exciting
[19:09] <jcastro> ah
[19:10] <jcastro> the 2.6 inclusion bug?
[19:10] <bdmurray> no, just some odd behaviour that I thought you might know someone who could help out with
[19:10] <Nattgew> hggdh what does that mean exactly?
[19:27] <sectech> Can someone wishlist bug #237941? It's been reported upstream... I have linked the bug to the report
[19:28] <sectech> I can't find a dup on launchpad for this issue
[19:32] <sectech> Hopefully I did that right...
[20:40] <derien> hi all
[20:41] <hggdh> hi derien
[20:42] <derien> is it possible to help you guys out? i allways wanted to get more involved into ubuntu
[20:42] <hggdh> it is possible, and you are welcome
[20:42] <derien> cool thx
[20:43] <hggdh> derien: if you wan tot help triaging bugs, you may want to read https://wiki.ubuntu.com/HelpingWithBugs
[20:45] <bdmurray> derien: if you have any specific questions feel free to ask
[20:46] <derien> oh, i have a lot of questions
[20:47] <derien> which programming languages are you using for fixing bugs?
[20:48] <persia> derien: Any and all.
[20:49] <derien> great. so i can learn a lot
[20:49] <persia> Mostly C, python, perl, shell, make though.
[20:49] <derien> no java? :-(
[20:49] <persia> Things like Java, Ruby, Haskell, OCaml, etc. tend to be less common.
[20:50] <derien> ok, good to know
[20:52] <derien> and you guys take charge of every bug in ubuntu? how many are there?
[20:52] <techno_f1eak> if i can't reproduce bug #237910, can i mark it as invalid? it works perfectly normal, as it should
[20:54] <bdmurray> techno_f1eak: possibly, I'm curious about their version of thunderbird though that line from apport is quite odd
[20:55] <bdmurray> techno_f1eak: you might also consider adding a screencast of what you did to make sure you and the reporter are on the same page
[20:57] <techno_f1eak> bdmurray: ok :)
[20:58] <derien> can everyone pick any bug in the launchpad?
[20:59] <pwnguin> well, no.
[20:59] <pwnguin> the most obvious case is "security bugs"
[21:00] <pwnguin> but basically, yea, anyone can work on bugs. you are one of the "many eyes making bugs shallow"
[21:00] <techno_f1eak> another one, bug #237905 can be due to the website being designed to work with certain versions of a browser, so what do i mark it as?
[21:00] <kees> well, "private" bugs.  security bugs can be worked on, they just have a slightly different work-flow
[21:01] <derien> could you explain me the "normal" work-flow? pick, patch and reup?
[21:05] <pwnguin> theres a wiki page that kinda outlines that
[21:06] <pwnguin> ubuntu's big enough that there are people who specialize in each of the three verbs you listed
[21:07] <pwnguin> some people triage bugs, making sure the bug exists and asks the submitter for more information etc
[21:09] <derien> and where shall i begin as a newcomer?
[21:09] <pwnguin> start with your own bugs ;)
[21:10] <pwnguin> if there's software in Ubuntu you'd like to see better overall, start looking at the bug reports there. especially troublesome are the reports that have seen no attention
[21:10] <pwnguin> "new/unconfirmed" type bugs
[21:11] <pwnguin> derien: the wiki page https://wiki.ubuntu.com/HelpingWithBugs is a good place to start reading. I'm sure #ubuntu-bugs will be happy to answer questions about it :)
[21:12] <derien> ok, i read it all night long.
[22:01] <leoquant> is this site off. supported by ubuntu (alan pope)? : http://screencasts.ubuntu.com/  its not really up=to-date (coming soon-button with the 8.04 version)
[22:04] <mrooney> leoquant: well, it is on the domain so it must be somewhat official, although it does appear very out of date
[22:05] <leoquant> mroony. that button on the left.......
[22:08] <leoquant> perhaps we tranform it into a 8.04.1 button.
[22:18] <dupondje> ogasawara: helloow
[22:18] <dupondje> :D
[22:19] <ogasawara> dupondje: hiya, I posted a quick update to your bug report
[22:19] <dupondje> I saw, i'm home now, next to the pc :)
[22:19] <dupondje> dunno what I can try :D
[22:20] <ogasawara> dupondje: refresh my memory which bug id your report is
[22:20] <dupondje> https://bugs.launchpad.net/ubuntu/+bug/235889
[22:20] <dupondje> upgraded to newest kernel that came out this week
[22:20] <dupondje> no fix
[22:21] <ogasawara> dupondje: yah, I wouldn't expect it to have been resolved
[22:21] <dupondje> me neither :) but ok, I tried it :P
[22:21] <ogasawara> dupondje: that basically had fixes for specific SRU's
[22:21] <ogasawara> dupondje: be right back . . .
[22:42] <mrooney> bug 237990, is there any known master for this?
[22:42] <mrooney> it links to a forum post, apparently updating from -proposed fixes it
[22:42] <mrooney> so that would seem to imply it has already been addressed
[22:44] <bdmurray> mrooney: you could check the changelog of the proposed package maybe
[22:45] <mrooney> the problem is I have no idea what package it is
[22:45] <mrooney> what package is the Appearances app?
[22:46] <mrooney> gnome-appearance-properties, got it :)
[22:52] <mrooney> bdmurray: got it... bug 236778, should I tag as metabug?
[22:53] <bdmurray> mrooney: that'd be great!
[23:40] <ogasawara> dupondje: sorry for the delay - while we're waiting for an Intrepid kernel to become available you may want to give the git bisect a try if you're comfortable
[23:40] <ogasawara> dupondje: we obviously don't expect bug reporters to know how to do that, but it will help
[23:41] <dupondje> I understand :)
[23:42] <dupondje> oki
[23:42] <dupondje> its a bug
[23:42] <dupondje> in ubuntu kernel patches ...
[23:42] <dupondje> compiled the kernel the Ubuntu kernels are based on
[23:43] <dupondje> and that one works
[23:45] <dupondje> linux_2.6.24.orig.tar.gz it is
[23:47] <dupondje> ogasawara ?
[23:48] <ogasawara> dupondje: so I think the hardy kernel was rebased with the 2.6.24.3 stable kernel from upstream
[23:49] <dupondje> http://packages.ubuntu.com/hardy/linux-image-2.6.24-16-generic
[23:49] <dupondje> here I got the tar from
[23:49] <dupondje> compiled without the ubuntu patch: works
[23:49] <dupondje> with patch: crash
[23:50] <ogasawara> dupondje: care to post your findings to the bug report?  It'll be easier for me to bring it to the attn of the kernel team
[23:50] <dupondje> i'll do
[23:51] <dupondje> there are changes in the scheduler.c
[23:51] <dupondje> in that patch
[23:51] <dupondje> so prolly something missed there
[23:53] <dupondje> comment added
[23:54] <ogasawara> dupondje: can you be specific about which patch too
[23:55] <dupondje> fixed
[23:55] <dupondje> :)
[23:55] <dupondje> going to sleep
[23:55] <dupondje> nite :D