[00:00] I'll leave some bugs for you then. ;) [00:00] :-) thanks [00:04] bug 263533 [00:04] Launchpad bug 263533 in ubuntu "Intrepid: MacBook Pro screen is missing in choose screen system menu" [Undecided,New] https://launchpad.net/bugs/263533 [00:04] anybody have a guess at what menu they are talking about? [00:13] perhaps hardware choice? [00:14] it's a mystery to me - could be screen resolution too [00:23] Sorry if slightly off-topic, but does anyone know details of UDS Sponsorship such as who reviews applications (is it a team?), and a general magnitude for how many people are being sponsored? [00:23] Also if there is a better channel I can ask there :) === eddie is now known as Guest51834 [00:27] mrooney: there will be a few people reviewing the applications [00:27] sponsorship is probably of the order of 50 people [00:27] maybe not quite that many [00:27] though it could all be different this time [00:28] james_w: Okay, I am just trying to get an idea of, if the people reviewing will know me or not, and if I have any chance :) [00:29] the people reviewing won't know everyone [00:29] but they would ask the relevant people who would know them [00:30] sounds good [00:30] Hi guys, haven't been on here in a LONG time, but can someone have a quick look at LP#:269193 please? [00:30] bug 269193 [00:30] Launchpad bug 269193 in ubuntu "[hardy] Realtek 8187 wifi overheating problems" [Undecided,New] https://launchpad.net/bugs/269193 [00:30] ahhh is that the syntax now [00:31] xteejx: :) [00:31] mrooney: thanks :) [00:31] james_w: I have started to get into development a little (I'm a CS major) and was thinking UDS was a great way to really get into the mix [00:31] mrooney: it would be [00:32] however, lots of people obviously want to go [00:32] I haven't a clue why the wifi is overheating could it be a kernel problem with this particular brand setting the TX power too high causing it to overheat? [00:32] it seems like this time there is more emphasis on getting attendees to lead sessions and drive ideas [00:33] mrooney: is ubotu part of your application? [00:34] bdmurray: hm, I don't think I put it in there, though it's on my wiki which is linked to from my launchpad [00:34] james_w: I know, I'd really love to lead a discussion / present on alternate desktop input schemes [00:34] mrooney: your plans for it might be interesting [00:34] like new docks and launchers and input paradigms [00:35] bdmurray: that's true, could you recommend an email address to follow up with re: my application? I wanted to include some more stuff, and a brief synopsis of where I think EeeBotu could go would be neat [00:51] Hello again guys... is bug 269193 formatted out ok I tried to get all teh info I could but I didn't know what package to assign it to - kernel or network-manager wasn't sure [00:51] Launchpad bug 269193 in ubuntu "[hardy] Realtek 8187 wifi overheating problems" [Undecided,New] https://launchpad.net/bugs/269193 [00:51] xteejx: probably kernel [00:52] james_w: Thanks! Is there any way for now I can reduce the tx power to stop it happening as a kinda 'quick fix'? [00:52] If you know...:) [00:53] I don't know, sorry [00:54] Ok no problem, does anyone else know how to change the TX power on a wifi card within the terminal as a short-term solution for bug 269193? [00:54] Launchpad bug 269193 in ubuntu "[hardy] Realtek 8187 wifi overheating problems" [Undecided,New] https://launchpad.net/bugs/269193 [00:55] It might be an option to the kernel module look at 'modinfo modulename' [00:55] bdmurray: OK I'll have a look, thanks :) [00:56] You could also try Intrepid with a Live CD! :-) [00:56] True, but the problem is the Ubuntu PC is half a mile away and its 12:56am lol [00:57] that's an interesting predicament [00:57] you'd probably have to unload and reload the module to be able to set an option [00:57] Hmm, it is...it's actually my partners machine, so I can't get to it. [00:57] How do I do that, sorry I'm a bit rusty... [00:58] rmmod; modprobe module option [00:59] ahhhh thanks hehe :) [01:04] One question, how do I find out which wifi driver is in use? Sorry [01:04] look at the output of lsmod and guess? [01:04] thanks! [01:05] removing the module will drop the wifi connection though [01:05] Its kool I know that one lol I'm not that rusty ;) [01:25] bdmurray: would you mind checking out https://wiki.ubuntu.com/MikeRooney/EeeBotuSpec and seeing if the there are any use cases I missed under subscriptions or if I should change anything? [01:35] mrooney, not that it helps any, but I like it [01:36] although I am not sure how censoring could be enforced [01:37] what about the ability to route bugs to specialised channels (e.g., xorg bugs with its channel, Evolution with its own, etc) [01:38] hggdh: thanks! I thought I covered that in the first bullet point, maybe it wasn't clear [01:39] yes, could be a bit expanded [01:39] hggdh: would you mind doing it? then it can have a different viewpoint! [01:39] by the way, is there anything new I should push to bzr? [01:40] no, not yet (got busy earning a life) [01:41] but I was thinking it might be a good idea to move IRC read to something more complete. With your plan, it now makes a lot of sense [01:41] like twisted-words, for example [01:41] mrooney, darn it! You put me back with my programmer helmet (which I thought I had already retired from) ;-) [01:42] mrooney, you would like t=me to add the text to the wiki? [01:43] hggdh: :) sure if you don't mind, just so it has explanations from two viewpoints [01:43] so more people "get it" [01:43] :-) [01:43] np [01:52] mrooney, first try in. I also added picking up on bugs from other common BTSs [02:07] i have a bug for you guys... [02:08] how come the font on this page looks so messed up? http://mpt.net.nz/archive/2008/08/01/free-software-usability [02:10] Guest51834, thank you, but I am unsure what this has to do with us. Could you please expand a bit? [02:25] sorry, [02:26] on my ubuntu systems the font rendering on that page is fubared [02:26] on my friends mac it's not [02:26] the text looks normal and is readable there [02:26] hence, i'm assuming there's a bug somwhere [02:29] Guest51834, the best bet would be to open a bug, describe what browser you use (and its version), your Ubuntu version, and add -- ideally -- screenshots [02:30] yeah, been thinking about it but i dont know how to do a bug report [02:30] if you could get screenshots from your friend's mac, it would be even better [02:30] it looks the same in both firefox and opera [02:31] already have one :) [02:31] go to https://bugs.launchpad.net; also please read https://help.ubuntu.com/community/ReportingBugs === Guest51834 is now known as AbtZ [02:32] too much to read at 3.30 am :( [02:32] on firefox you can use Help/Report a problem to open the bug [02:33] this will add all necessary version information; then it is just attaching the screenshot(s), and -- of course -- describing what happens [02:33] sweet [02:34] i forget the name of the font though [02:35] ah, think it's palatino [02:35] don't worry about it, although you can always use the "view source" of the browser to look for the font [02:38] what's the html syntax that defines the font to be used? [02:38] i searched the source for "font", but didn't get any results [02:41] also, it seems like i can only attach one screenshot? [02:46] nvm, made a second post [02:46] https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/269226 [02:46] Launchpad bug 269226 in firefox-3.0 "Web page font rendering issues (palatino font)" [Undecided,New] [02:46] no, you can attach one file per time [02:47] there i filed my first bug report [02:48] good. One small step, etc ,etc [02:48] hehe [02:48] i can live with that particular page being rendered improperly [02:48] what i don't like is that the font renders quite well on my snotty friends mac ;) [02:49] if it helps any, mine displays the same thing yours does [02:49] so you are not alone [02:50] yes, i'm assuming this is an ubuntu/linux problem [02:50] hum [02:50] interesting [02:51] I was playing around on the page, and suddenly my ffox started displaying it extremely nice [02:52] oh? [02:52] how did you solve it? [02:52] nah, just a result of mesing around showing style sheets, css, etc [02:52] it is now back to normal (which is to say, ugly) [02:53] but it really seems like the rendering is bad [02:54] ah well. bed calls me now [02:54] hmm [02:54] all right [02:54] thanks for you help [02:55] hopefully someone who knows takes a look at the report [02:55] AbtZ, lets see if someone with the necessary knowledge looks at it soon [02:55] yes === hggdh is now known as hggdh|away [02:55] g'night [02:55] g'night === nhandler_ is now known as nhandler === nhandler_ is now known as nhandler [04:13] question for bug control: I have confirmed bug 269226 and it appears there is enough information for it to be triaged. I wonder if this is something I can hand off to you guys (to set to triage) or if its something that should be sent upstream (and if so, should I take care of this) [04:13] Launchpad bug 269226 in firefox-3.0 "Web page font rendering issues (palatino font)" [Undecided,Confirmed] https://launchpad.net/bugs/269226 [04:19] hmmm [04:19] check through dupes, couldn't find anything [04:20] just so I know, how do you find out what font is being used by Firefox in that case? [04:23] i use firebug to see whats coded into the pages [04:23] but i know theres a program that tells you whats being sent between the server and firefox.. i can't remember it [04:23] that may tell you [04:23] not sure thoug [04:23] h [04:23] thanks bcurtiswx [04:24] np [05:33] so what's convention when a bug is confirmed but there's not enough info to mark the package? if you ask for info and mark it incomplete, should it be marked off the bug day list to avoid repeating the same bugs, or should it be left alone? [05:41] maco: I think that counts as "hugged" [05:43] mrooney: ok [05:45] good morning [05:46] morning...in your area [05:47] maco: I'm not going to say "good morning to you Daniel, hello there techno_freak, good night bdmurray, good afternoon persia, etc" :-) [05:49] dholbach: mmm? oh sorry, i meant that as a reply "good morning in your time zone" better? [05:49] oh ok, np :-) [05:49] maybe I need some more coffee :) [05:49] the internet is funny like that [06:55] there are usually hugday stats showing how many bugs changed over how much time during hug day and whatnot, aren't there? [06:56] oh wait, i see it on the last one. when do those usually get posted? === dholbach_ is now known as dholbach === bdmurray changed the topic of #ubuntu-bugs to: Ubuntu BugSquad | http://wiki.ubuntu.com/BugSquad | Documentation: http://wiki.ubuntu.com/HelpingWithBugs | If you have been triaging bugs for a while, please apply to https://launchpad.net/~ubuntu-bugcontrol/ | Want to report a bug? Read https://help.ubuntu.com/community/ReportingBugs | User support (not related to triage) is in #ubuntu === BugMaN1 is now known as BugMaN === dholbach_ is now known as dholbach [09:44] Ping seb128 : quick one RE bug 256494 [09:44] Launchpad bug 256494 in compiz "compiz turned on again during update after I had desktop effects turned off" [Undecided,Incomplete] https://launchpad.net/bugs/256494 [09:51] nullack: hi [09:51] seb128 Hi mate [09:51] nullack: about your crashes discussion on the list [09:51] sure, shoot [09:51] - debug version by default wouldn't work, we could build CDs [09:51] - the apport bugs are automatically retraced using debug symbols [09:52] Whats missing in the retrace to see bug squaders then marking it as invalid due to no backtrace? [09:53] see bug #267014 for example [09:53] Launchpad bug 267014 in gconf-editor "gconf-editor crashed with SIGSEGV in gconf_value_copy()" [Medium,Triaged] https://launchpad.net/bugs/267014 [09:53] nullack: sometimes the retracing fails for some reason (versions changed, crash while upload issue, etc) [09:54] not sure why, the debugging toolchain is not trivial [09:54] there is just case or the crashdump doesn't give you a good stacktrace [09:55] Yeah, or it might be an optimised compile that cant be [09:55] in some case that a retracer bug, in some case that's gdb not doing a good job, in some case that's there is upload issues [09:55] right [09:55] I'm not sure what issue you try to address there [09:55] Basically I see a problem, and Im interested in us trying to identify an easier way for users to respond [09:55] we close bugs which don't have enough informations to be worked on, which seems fair enough [09:56] right now they dont, the devs dont get the feedback they need and the problem doesnt get resolved [09:56] let's formulate this way (random numbers for the example) [09:56] ubuntu gets 300 crash report a week [09:57] thanks dholbach! [09:57] 260 of those are good and not close [09:57] closed [09:57] we have the manpower to work on 10 of those [09:58] do you think the not-good ones handling is the issue? [09:58] we still have 250 good bugs we don't work on already [09:58] why should we spend effort trying to figure details about the few which are broken if we have plenty of good ones already we could work on [09:59] Because your missing one key thing [09:59] The user experience and how it is broken should be the determining factor [09:59] And for a number of the not-good bugs, someone provides hints on how to generate a good bug. One of the annoyances about the crash reporting system is that each new report is a new bug, even when it's just a refreshed report to generate good symbols. [10:00] persia: that's a detail, we can dup easily [10:00] The criteria to decide what bug gets worked on shouldnt be driven by complexities with backtraces - it should be about how seriously it effects the user experience [10:00] nullack: right and we consider that [10:00] And what I see is these sorts of bugs get reported but dont go anywhere because the users get confused about backtracing and dont provide it [10:00] but a bug which happened one and has no debug information is not worth spending a debugging day [10:01] nullack: well, if we don't have enough informations to work on the bug why should we keep the bug open? [10:01] Agreed Sebastien, which is why I am suggesting a debate about what is needed to be done to overcome that [10:01] there is no debate needed [10:01] There seems to be ideas that would help the problem [10:01] which ones? [10:01] The other two ideas I mentioned in my mail [10:02] From the others [10:02] Or, my idea, though I think personally the other ideas seem better [10:04] nullack: alright, so [10:04] "tells the user the situation and downloads a debug [10:04] version of the package and waits for it to occur again." [10:04] why? [10:05] the debug retracing happens automatically on the server side [10:05] So then why are users being told they have to backtrace it under a debug build? [10:06] nullack: because the crashdump doesn't work for some reason [10:06] there is no garanty that it'll work next time [10:06] could be that gdb doesn't work correctly in this situation [10:06] Right, so lets make it easy for them because what I see happening consistently is that the users dont respond and the bug sits there [10:06] those reply are usually a "we don't know why retracing didn't work but it didn't, could you try that in case" [10:07] I think we need to more automate the get a debug build thing and help users walk through replication [10:07] they don't sit there, they are closed [10:07] Sitting there or being closed the net effect is it isnt resolved :) [10:07] the issue is not the lack of debug build [10:08] it's that gdb doesn't work in all case [10:08] and what do we do in cases where it doesn't work and we have no clue why [10:09] I don't know what is required to get a good stacktrace in some case [10:09] I like the idea of sending a user a debug build and capturing the problem, with apport resending the complete backtrace back to the existing bug that didnt have enough info [10:09] but I know the bug is not useful [10:09] what would you do with the bug? [10:10] again we have debug builds [10:10] and user "capturing the problem" would not make a difference [10:10] a possible solution could be to have a wikipage for each package which describes what debug-symbols are needed and point the user to it? [10:10] there is case where gdb is just not good at providing what we need [10:10] and we have no better tool [10:10] Ampelbein: again the issue is not the debug symbols [10:11] the question is [10:11] "what do we know when debugging an issue require a way to trigger if for somebody who has real clues" [10:11] it [10:12] gra [10:12] "what do we do when debugging an issue require a way to trigger it for somebody who has real clues" [10:13] there is just cases where automatic or manual gdb use will not give you enough [10:13] Can I say, you wont always be able to replicate serious user experience problems in house. [10:13] i guess this is experience. when you concentrate on few packages you will learn what the developers need in special cases. [10:13] Essentially, we need a means by which to verify/analyse the steps required to reproduce. Unfortunately, it's not simple to descrbe these, as there are too many factors involved. [10:13] So, then it becomes a matter of giving users tools to diagnose it and send it to people with those clues [10:13] nullack: right, but we don't have the manpower to spend a week on a bug [10:14] nullack: we don't write softwares, we distribute those [10:14] seb128 : well I think you would spend a week on a bug if it broke enough users machines seriously enough :) But I understand your point about limited resources [10:14] nullack: it's not our responsability to track tricky upstream bugs [10:14] So heres an idea [10:14] Well, that's arguable. As much as I don't mind closing bugs that aren't useful, I think it's worth tracking all the bugs, and linking upstream. [10:15] Maybe the approach is something like "this is technical thing to fix and instruct the user how to go upstream?" [10:15] I think one problem is that ubuntu ships old software. Most issues are solved upstream allready [10:15] Right now, users get confused about techno gooble double speak about backtracing [10:15] persia: right, that's a different topic, I often ask people with tricky issue to open a bug on the upstream bug tracker too in case upstream has a better idea about the issue [10:15] If Ubuntu cant fix it, why not just be honest to he reported and say go upstream [10:16] nullack: what I just wrote [10:16] seb128: And you are also incredibly dilligent about passing bugs upstream when they are well described :) [10:17] Yes he is [10:17] well, I try to pass bugs upstream when I judge them good enough to be worked [10:17] So can I summarise your view point sebastien so Im clear [10:17] my issue is what to do when I know the bug is not good enough to be worked [10:17] nullack: sure [10:17] Your saying we shouldnt ask for bracktraces anymore [10:17] nullack: Part of the issue is defining what "Ubuntu can't fix it" means. Some upstreams are also involved with Ubuntu. There are a number of upstream fixes that come from Ubuntu users. It all depends on who looks at the bug, and how many people who can fix it desire to do so in Ubuntu. [10:17] We should ask them to go upstream [10:18] Essentially scrap the standard boilerplate backtrace bug squad response [10:18] no, it's not as simple [10:18] Ok, please explain [10:18] do you have a bug number example which is an issue for you? [10:19] Yep, hang on [10:19] what I'm saying is basically we have [10:19] - bugs which are good and have enough information -> we send those upstream [10:19] - bugs which don't have enough information -> we try to get those informations [10:21] - bugs which might have enough information, that looks upstream issues but where we are not sure what is the issue -> we try to ask users to open those directly upstream where they have a better change to get a reply [10:21] the thing is that a good stacktrace is often enough information [10:22] but in case of tricky bugs debugging often requires interaction with somebody having the issue [10:22] seb128 : this bug isnt a serious user experience one but just to give an example : 204272 [10:22] so forwarding doesn't work very well in such cases, that's where we encourage whoever has the issue to open the bug upstream too [10:22] bug 204272 [10:22] Launchpad bug 204272 in pulseaudio "totem-gstreamer crashed with SIGSEGV in pa_stream_write()" [High,Confirmed] https://launchpad.net/bugs/204272 [10:22] that's a pulseaudio issue ;-) [10:23] this bug is not closed [10:23] we just have nobody really looking at pulseaudio in ubuntu [10:23] it should be sent upstream by somebody [10:23] preferably by somebody who get the bug and can reply to upstream questions on how to trigger it [10:24] Can we go back to the bit about not being able to look at backtraces. [10:24] especially that such bugs might depend of the audio configuration [10:24] Maybe the bug squadders need new instructions [10:24] right [10:24] do you have examples? [10:24] easier to comment based on a concrete example [10:24] nullack: Better instructions are usually good, but it's a matter of getting them right. [10:25] yes I had one about totem crashing that had 9 made invalid incomplete I dont have the number of it with me right now [10:25] well, most likely this bug has: [10:26] - no instruction on how to trigger the crash [10:26] persia and seb128 : what I see is this boilerplate thing being put about needing backtrace, but now we find that devs like Sebastien are point out that it may not be Ubuntus role to fix it [10:26] - no debug stacktrace [10:26] what do you suggest to do? [10:26] I think maybe we should better instruct users about going upstream [10:27] Currently they get this response about installing special debug packages, they get confused and they dont do it [10:27] nullack: In every case where we can't get a stacktrace? [10:27] nullack: Sometimes the crash isn't an upstream issue at all. [10:27] persia : I think only when the trace from apport is no good [10:27] often upstream gets an higher number of crashers that we do and have very low tolerance to incomplete bugs [10:27] persia : So how does Seb figure out its not upstream if the backtrace wont tell him what he needs to know? [10:27] at least for GNOME [10:28] I'm fine sending them to bugzilla but the bug will be closed there in a way similar to what we do [10:28] nullack: OK. I worked a bug on hydrogen a while back. I couldn't get a stacktrace, but I could reproduce. It came from the way hydrogen was patched, and I fixed it. Debian did the same, and fixed it differently. Upstream never had the issue. [10:29] Well what does MS do? They seem to get by with a user friendly way of getting the technical details of crashes back to them. [10:29] One of the responses to my mail was about that [10:29] When someone is triaging a bug that is a crash but has no stacktrace, they should try to reproduce, and collect enough information from the developer. In cases where it can't be reproduced reliably, and we have no symbols, it's probably not interesting upstream either. [10:30] persia : sometimes I find that apport has given a dump but then it comes back with need a stack trace [10:30] MS collecting crashes is similar to what we do with apport. As MS doesn't make their bug DB available, we don't know how they triage them once received. [10:30] nullack: Yep. Sometimes it doesn't work. The solution is probably to improve apport, or try other means to find the bug, not to blindly pass upstream. [10:31] persia : I like the sound of that [10:31] seb128 and persia : my biggest problem is what I see the current situation to be the user is asked to do stuff they dont know how to do, they dont do it, and the issue goes unresolved [10:33] The point of my mail was to explore how this might be fixed given everyone agreed its a problem [10:33] nullack: Can't really help that. The triager can do it, but if the triager can't reproduce, it may require something special on the submitter's system. [10:34] nullack: there is just no way to investigate some issue without the help of somebody having the issue [10:34] Markus has ideas about improving apport to make it easie [10:34] *easier [10:34] But, the issue then turns too this [10:34] Is it worth doing that [10:34] I don't see a real problem in the current system [10:34] If devs like Sebastien are too thin on the ground and it should be analysed upstream anyway [10:35] if the user doesn't reply an another will do [10:35] Which Ive done, and you and I have gone upstream, but thats rare [10:36] seb128 : surely you agree that the current systems hit rate is very low [10:36] "hit rate"? [10:36] seb128 : actually getting another back trace back after the user has installed debug packages and compiled with the request for backtrace [10:37] let's say I've enough valid bugs to be busy full week so I'm not looking to invest too much on incomplete bugs [10:37] I just reply using the stock reply [10:37] We've probably got enough reproducible crashes to fix before we try _too_ hard to fix heisenbugs. [10:37] if they can figure how to get extra details good [10:37] seb128: So I say again that shouldnt be the case [10:37] if not we close the bug and move on [10:38] seb128: The criteria for working on bugs should be how much it effects the user experience [10:38] Not the difficulty in debugging [10:38] sure [10:38] we will consider bugs which have lot of duplicates differently [10:38] see bug #252174 [10:38] Launchpad bug 252174 in gvfs "gvfsd-trash crashed with SIGSEGV in g_main_context_dispatch()" [High,Triaged] https://launchpad.net/bugs/252174 [10:38] it has no good stacktrace [10:39] and no detail on how to trigger it [10:39] nullack: Bugs are ranked in both senses. We want as much *total* user experience as possible, so something that affects 10,000 people and requires an hour to fix is more important than something that affects 20,000 people and takes 10 hours to fix. [10:39] it's a frequent crasher though, I've sent it upstream and it's milestoned [10:39] persia : I see, thanks [10:39] Also, if a developer can't get enough information to fix it, no amount of time will result in a fix. [10:39] nullack: we will investigate bugs which get a dup a week or something [10:40] I'll no put days efforts on something which one user ran into once and which has no detail [10:40] seb128 : I think thats fair, but thats not what I am getting at [10:41] If the problem cant be replicated by the dev [10:41] It seems to me the process of getting a user to replicate it with the required debug package and all the rest is difficult [10:41] People have suggested atleast two ways we can improve the process [10:42] which ones? [10:42] Markus with changing apport and the other bloke about copying what MS does [10:43] But what MS does appears to be basically a subset of apport. [10:43] So lets stick with Markus' idea then [10:43] Actually, we have no idea what MS does after the upload: it could well be all of apport. [10:44] nullack: changing apport to do what? [10:44] seb128 : its in his email and I summarised it in mine [10:44] I'd quite like a "install a dbgsym package for each package in the dependency chain of $PACKAGE" tool; that could be useful. [10:44] nullack: could you summarize it there? [10:44] nullack: It's having a button "install dbgsym package", right? [10:44] Yes Chris [10:45] to me it looks like "install debug packages and wait for the crash to happen again" [10:45] That too [10:45] what do you think that would bring? [10:45] we have apport-retrace which does that now [10:45] how would that be different? [10:45] Well bug squadders are saying in bug reports that its needed [10:45] For one, some packages may not be able to be debugged due to compiler options [10:46] no, what they say is "gdb didn't work on your bug for some reason" [10:46] So in that case, its needed for a debug compile to diagnose [10:46] Seb128: I see them putting the boilerplate do a backtrace message [10:46] nullack: sure, but the bugsquadders probably have no idea what they are and arent' supposed to be doing now - there's a lot of obsolete info. [10:46] right, which is a lame way to say "try again, maybe it was a random error" [10:47] seb128: can we focus on what you just said [10:47] nullack: ie, an easy way to send those bugs away [10:47] seb128: Because what then happens is the user gets confused/afriad to install these types of packages and typically gives up [10:47] Thats what I mean about the hit rate being poor [10:47] I use that as "this bug is not useful, I'm too busy to work with you on getting details, read that and try if you figure something or we will close it" [10:48] nullack: right, which is somewhat what I expect to be honest [10:48] that's "either figure by yourself or to make it useful or let's close the bug" reply for me [10:48] s/or/how [10:48] I think we need to come up with a better message because thats not what it means to a user that isnt experienced [10:49] I could as well close it as "retracing didn't work, I'm closing the bug, try sending it again next time you get the issue" [10:49] To me, that makes more immediate sense [10:49] And the benefit is the user isnt left at a quandry about what do next [10:50] and what do we do if the next one is still not better? ;-) [10:50] Id like to think in the meantime the community could be encouraged to improve the debugging tools to make real differences there [10:51] right [10:51] seb128: its not just you that does the boilerplate response, it happens with others too, so please dont think Im pointing the bone my friend :) [10:51] I know, but other do it for the same reason [10:51] we just don't want to keep useless bugs open [10:52] So it seems like we might be able to agree on two points [10:52] but we don't have the resource to spend one day on each bug [10:52] it comes to what you expect from the bug tracker [10:52] 1. Debugging tools need to be improved over FOSS and there is limits right now [10:52] either that's a way for user to describe their issues [10:53] 2. There should be a change to the boiler plate response to better show the user what the real situation is [10:53] or that's a way for maintainers to work on problems which are described well enough to be worked [10:53] right [10:53] persia? RAOF? those two points sound fair? [10:54] I think having a page explaining what the retracing does [10:54] why it doesn't work sometime [10:54] and how similar work can be done manually [10:54] would make sense [10:55] As a third item, right [10:55]