| === asac_ is now known as asac | ||
| Stemp | Hi all, I have a problem with bug #123916. It affect Hardy and the problem is fixed in Debian. | 02:26 |
|---|---|---|
| ubottu | Launchpad bug 123916 in fail2ban "fail2ban will not start if fail2ban socket is present" [Undecided,Confirmed] https://launchpad.net/bugs/123916 | 02:26 |
| Stemp | I built it in my PPA, but what should I do now ? requesting a Sync is only for Intrepid, right ? | 02:27 |
| mrooney | Stemp: right, what you want is one or both of 1) backport the updated package, 2) patch the current package to fix the bug | 02:42 |
| Stemp | As the actual package is a copy of an old Debian version, I guess it's better to ask for backport. So in fact there is nothing I have to do in launchpad bug ? | 02:44 |
| RAOF | Stemp: Verify that it's fixed in intrepid is nice. | 02:46 |
| Stemp | it is, the new version is in Intrepid | 02:47 |
| RAOF | Stemp: Right. So, it'll only be fixed in Hardy with a SRU - Stable Release Update. If you want that to happen, you need to ask nicely. | 02:49 |
| RAOF | And, by ask nicely, I mean: follow... | 02:49 |
| RAOF | !sru | 02:49 |
| ubottu | Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates | 02:49 |
| Stemp | thanx RAOF | 02:50 |
| Stemp | Ok I did my 1-a-day :p Good night | 03:02 |
| dholbach | good morning | 08:00 |
| techno_freak | morning dholbach | 08:02 |
| dholbach | hi techno_freak | 08:02 |
| ma10 | shouldn't incomplete bugs turn automatically invalid after a while? how long does it take? | 11:33 |
| persia | ma10: There's some debate about whether they should do so or not, but 60 days is the configured value. | 11:56 |
| ma10 | persia: https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=date_last_updated&search=Search&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patc | 11:58 |
| ma10 | there are bugs untouched since years! | 11:59 |
| ma10 | This bug report was marked for expiration 243 days ago. | 11:59 |
| persia | ma10: RIght. The automatic expiry appears to be off, yet the expiry clock is on. | 11:59 |
| ma10 | persia: mhh.. would it be ok to set incomplete with the "old untouched" standard response all new (and maybe confirmed) bugs untouched for one year or so? | 12:02 |
| persia | ma10: I don't think the bugs become incomplete with age. On the other hand, most of them could do with some triage. | 12:03 |
| Ampelbein | ma10: thats what i do with those. | 12:03 |
| persia | I suspect a lot of them are fixed. | 12:03 |
| ma10 | i'm trying to think of some ways to reduce the clutter | 12:03 |
| persia | Ampelbein: How is that helpful to ensure the distribution is bug free? | 12:03 |
| persia | ma10: Triage the bugs? | 12:03 |
| ma10 | yes.. 100% the submitter doesn't care anymore | 12:04 |
| Ampelbein | persia: if the issue is no longer there | 12:04 |
| persia | Ampelbein: If the issue is no longer there, the correct status is Fix Released, not Invalid. | 12:04 |
| === Initial_1 is now known as Edge_31 | ||
| Ampelbein | persia: not saying anything against it. | 12:05 |
| persia | ma10: Even if the submitter doesn't care, is it not worth checking to see if the bug is present, and either closing it, or ensuring it is complete? | 12:05 |
| Ampelbein | persia: thats what the "old untouched" response is for. if the submitter says its corrected with an update: Fix Released. | 12:05 |
| persia | Ampelbein: Ah. In that case, I'm misunderstanding the terminology. Please forgive the rant. | 12:06 |
| === Edge_31 is now known as Initial_M | ||
| Ampelbein | persia: no problem. but according to https://wiki.ubuntu.com/Bugs/Responses#Bugs%20resolved%20after%20update%20or%20config%20change, the status should be set to invalid. | 12:06 |
| persia | Also, for many bugs with some information on how to reproduce, it's often easier to try to reproduce oneself than to ask the submitter. | 12:06 |
| persia | That URL crashes my browser, but from the title, I disagree. If it was fixed by a config change, and we don't ship that by default, someone else will encounter the bug. | 12:07 |
| persia | If it was fixed by an update, it should be Fix Released. | 12:07 |
| Ampelbein | persia: i think the wiki has a point there. it could be anything that corrected the issue, including a hardware change, config change or the update. | 12:08 |
| Ampelbein | https://wiki.ubuntu.com/Bugs/Responses | 12:08 |
| persia | Indeed, but is it not worth trying to figure out what happened, and reporting it correctly? | 12:08 |
| Ampelbein | persia: depends on the severity. | 12:08 |
| persia | We mark a lot of bugs Invalid. This has generated a fair amount of press that we don't care about bugs. | 12:08 |
| persia | I think we care about bugs, and it's worth spending a couple minutes to say "Yep, we fixed it, finally" so that the submitter feels like they should submit more bugs, and we can fix those as well. | 12:09 |
| Ampelbein | if its a minor bug that can't be reproduced in any of the new releases i don't see the point in trying to figure out why it happened in the first place. | 12:09 |
| ma10 | the problem is that there are 21073 new unassigned bugs | 12:09 |
| ma10 | do we have the manpower to do things "properly"? | 12:10 |
| persia | ma10: No. The problem is that Ubuntu has bugs. That is the thing that should be fixed. Reducing the number of bugs doesn't mean anything at all. | 12:10 |
| persia | TO take an example, Microsoft's public bug tracker for Word doesn't have any bugs shown. Does that mean there are no bugs in Word? | 12:10 |
| Ampelbein | you are right. but if we reduce the number of open bugs by checking which ones are still in the packages we could concentrate on the important things. | 12:11 |
| persia | Yes, but I'd also like to get more good bugs reported. If someone has an issue, I'd like them to have a good experience reporting a bug. I think it's worth a couple minutes to check the changelog for the affected package and verify it was fixed. | 12:12 |
| Ampelbein | and i think a response saying that the submitters bug has been fixed with a new release is better than no response at all. | 12:12 |
| persia | Generally there will be some mention of the fix. | 12:12 |
| persia | Precisely, and that encourages the submitter to upgrade, and report more bugs, and generally improves the quality of Ubuntu. | 12:12 |
| persia | I just think the appropriate bug status for "Fixed in a new release" is "Fix Released" and not "Invalid" | 12:13 |
| Ampelbein | so the first thing to do is check IF its still an issue. either by reproducing or by asking the submitter (status: incomplete). if its not an issue anymore we try to look in changelog. if mentioned there: status: fixreleased. if not mentioned: status invalid. | 12:14 |
| ma10 | persia: i think the wiki says invalid for bugs whose cause was never understood | 12:14 |
| persia | Cool. I was worried it was something else. Thanks for the confirmation. I'll try to turn off the rant button :) | 12:14 |
| Ampelbein | persia: sometimes its good to be ranted at. can bring oneself to think about it ;-) | 12:15 |
| persia | ma10: Yes, it does. My main concern is the case of NEW Unconfirmed bugs of significant age, that we ought at least try to understand the cause. | 12:15 |
| persia | Ampelbein: That's a delightfully refreshing attitude :) | 12:16 |
| ma10 | persia: ok policy received | 12:18 |
| ma10 | but i still think it would be useful to have an automatic procedure that does something like: for old bugs, ask if it's still a problem, make incomplete, if someone replies turn back to new. And have a working auto expiry | 12:22 |
| persia | At the last UDS there was talk about having things go from incomplete to NEW when someone replied, but it needs more work, so we have to wait for the LP devs to do something. | 12:23 |
| ma10 | yes i saw that on the mail from the lp team to motu where they asked to prioritize features | 12:23 |
| persia | My memory (which may be flawed) is that auto-expiry was turned off because the bugsquad only processes ~2500 bugs a week, and there's some backlog (it used to be a lot smaller), so using auto-expiry would expire some people's bugs just because someone was too busy to get back when the person answered. | 12:24 |
| ma10 | but there was nothing about "auto respond to old bugs" | 12:24 |
| persia | You might propose it. I believe the best way to do this is to file a bug against launchpad, but I may be mistaken. | 12:25 |
| ma10 | (2500 bugs a week) that's not bad! | 12:25 |
| hggdh | ma10, indeed not bad -- but only if you have enough people to work on them! | 12:26 |
| ma10 | ok, i'll think about filing a bug.. maybe someone already has | 12:27 |
| persia | ma10: Yep. 2500 bugs is actually a number to be celebrated, but it's hard to compete with the flow we get after some good press story, or a new release. | 12:28 |
| ma10 | yeah i guess we could see it that way: more bugs more users more success :) | 12:29 |
| hggdh | ma10, auto-respond to old bugs does not really help any: if the bug was not been looked at before, it will probably not be looked at after an auto-query | 12:29 |
| ma10 | hggdh: what i want to happen is that if the user does not respond the bug auto-expires | 12:30 |
| hggdh | and what if the user *does* respond, but nobody looks at it? | 12:30 |
| persia | That's why the expiry feature is less interesting until we can automatically turn off the clock when someone responds. | 12:31 |
| hggdh | I would personally find this very rude -- "are you still interested" -- "yes, I am" -- silence | 12:31 |
| ma10 | turns automatically new and the cycles begins again.. the poor user is pinged over and over :) should not be too much of an annoymnet if it's once every 2 months | 12:32 |
| ma10 | turns automatically new and the cycles begins again.. the poor user is pinged over and over :) should not be too much of an annoymnet if it's once every 2 months.. | 12:32 |
| ma10 | turns automatically new and the cycles begins again.. the poor user is pinged over and over :) should not be too much of an annoymnet if it's once every 2 months.. | 12:32 |
| persia | Except it's a reminder every two months that one's bug is being ignored. | 12:32 |
| ma10 | sorrry!!!! :( | 12:32 |
| persia | No, you've demonstrated the problem precisely :) | 12:32 |
| hggdh | it is not the frequency, but what persia jut said (darn, persia *again* preempted me ;-) | 12:32 |
| ma10 | sorry for the multi-send | 12:32 |
| * persia leaves the next several responses to hggdh :) | 12:33 | |
| * hggdh is too slow to compete | 12:33 | |
| ma10 | don't know i'm thinking.. i guess you're right anyway | 12:37 |
| ma10 | i started this discussion because i'm beginning to mantain packages and the first thing i had to do was clean up a lot of old bugs before i could understand what i *really* had to fix | 12:38 |
| Ampelbein | ma10: another thing about automated expiry is that people would then think: why should i care about filing bugs, when i get an automated reply after X months to verify that i still have the issue. | 12:47 |
| Ampelbein | if the reply actually comes from a human being thats not so bad. | 12:48 |
| Ampelbein | because then the submitter sees that someone is taking care of the report. | 12:48 |
| Ampelbein | of course the next action after verification that the bug still exists should not be to set status new and leave it be ;-) | 12:49 |
| ma10 | Ampelbein: that's true.. if you do it you subscribe and when he replies you have to care | 12:49 |
| ma10 | lol :) this way you act no better than a bot | 12:50 |
| ma10 | ok so what i learned is "care about the user, live with the clutter" :) | 12:54 |
| ma10 | thanks | 12:54 |
| ma10 | for the explanations! | 12:55 |
| persia | ma10: Thanks for cleaning up the clutter in the packages you examined to figure out what work needed to be done. | 12:58 |
| hggdh | ma10, still -- thank you for your proposal (even if not accepted): you are helping, and we we are all thankful for that. | 13:04 |
| hggdh | (and do not fell alone -- I have had some of my own ideas shot down, sometimes very fast ;-) | 13:05 |
| * Hobbsee loads her bubblegun, and points it in hggdh's general direction | 13:06 | |
| * hggdh wonders if there is *any* kind of effective protection | 13:34 | |
| hggdh | Hobbsee, ping | 13:35 |
| Hobbsee | hggdh: pong | 13:36 |
| hggdh | should I run for my life? | 13:36 |
| hggdh | :-) | 13:36 |
| bokey | wheres grendal? | 13:38 |
| bokey | :P | 13:38 |
| Hobbsee | heh | 13:54 |
| Hobbsee | not unless you fear a bubble attack... | 13:54 |
| Hew | Is there an easy way to know which dbgsym packages to install? Apport-retrace does a great job, but is there a single command or something that just targets a package and pulls the required packages? | 15:26 |
| afflux | Hew, no, apport-retrace looks at the ProcMaps field in the crash report, looks for the loaded libraries, searches for the packages they belong to, and pulls the dbgsym packages for them. | 15:34 |
| Hew | afflux: Ah ok, I assumed it just pulled all the dbgsym packages for the dependencies. Thanks for the info. | 15:35 |
| afflux | Hew: no problem. You still can find out which dbgsym packages you need by using some shell magic | 15:38 |
| afflux | Hew: like: cat /proc/9604/maps | awk '{ print $6 }' | sort | grep -v '^$' | grep -v '^\[' | while read p; do dpkg -S $p; done | cut -d':' -f1 | sort -u | 15:38 |
| afflux | Hew: where cat /proc/9604/maps could be changed to point to the file containing the ProcMaps | 15:38 |
| Hew | afflux: I'm trying to triage bug 252174, which requires a valgrind log. Someone has (finally) produced one, but it's missing symbols. Is there something easy to tell the user? What info am I looking for in the valgrind.log? | 15:42 |
| ubottu | Launchpad bug 252174 in gvfs "gvfsd-trash crashed with SIGSEGV in g_main_context_dispatch()" [High,Confirmed] https://launchpad.net/bugs/252174 | 15:42 |
| afflux | Hew: are you running hardy? | 15:44 |
| afflux | oh wait, the report is for intrepid | 15:44 |
| afflux | never mind | 15:44 |
| Hew | afflux: Yes, this is an Intrepid bug. I was wondering how it's possible to look at a valgrind.log and work out which dbgsym packages it needs. Do I just look for all the "within /lib/libpthread-2.8.90.so" parts, and find which packages contain these files? | 15:48 |
| afflux | Hew: to make sure it will be complete, you look at the ProcMaps.txt file at the beginning of the report, and make sure that all libraries mentioned there have debug symbols. | 15:49 |
| Hew | afflux: ah of course, I should be able to work it out from there. Thanks again! | 15:50 |
| afflux | Hew: I'll have a list ready in a minute | 15:50 |
| Hew | afflux: wow thanks, even better than working it out myself! :P | 15:51 |
| afflux | Hew: you'll definetly need libc6-dbgsym libglib2.0-0-dbgsym and gvfs-dbgsym, maybe gvfs-backends-dbgsym and libgvfscommon0-dbgsym, unlikely are the ones for: libdbus-1-3, libgnome-keyring0, libpcre3 and libselinux1 | 15:53 |
| Hew | afflux: Excellent, I'll post a comment and let the guy know! | 15:55 |
| afflux | thanks! | 15:55 |
| === mcas_away is now known as mcas | ||
| mcas | hello | 17:17 |
| Hew | mcas: hi | 17:18 |
| mcas | if there are bugs "please upgrade to newer version" or "please sync from debian" | 17:18 |
| mcas | are these bugs "wishlist"? i think they are but i want to ask bevor doing something wrong | 17:19 |
| Hew | mcas: Yes, they are wishlist. | 17:19 |
| mcas | ok :-) | 17:20 |
| mcas | thank you Hew | 17:20 |
| Hew | mcas: no worries, thank you for helping out :-) | 17:21 |
| persia | mcas: Hew: Please don't set the status of those bugs to "Wishlist". | 17:27 |
| persia | While it is often accurate, it's not always accurate (as sometimes we get a critical bugfix through a merge or a sync) | 17:27 |
| persia | Also, those are mostly filed by developers, and some of the developers complain about extra bugmail just for setting them wishlist. | 17:27 |
| persia | My understanding is that as the Launchpad API improves, the tool the developers use to file those bugs will automatically set them to the right Importance, but it doesn't do that yet. | 17:28 |
| Hew | persia: Sure thing. I know that wishlist isn't a blanket policy, but I was thinking the case here was probably a user asking for a new feature like most sync bugs. I suppose I should have asked for more detail. | 17:30 |
| Hew | mcas: Which bug are you working on? | 17:30 |
| Hew | mcas: or was it just a general question? | 17:31 |
| persia | Hew: Yeah, it gets confusing when users who aren't developers file what should be upgrade bugs and use the sync format. | 17:31 |
| xnevermore | Hey guys. I filed a bug (#255976) and provided a package for a new upstream version for sponsoring about three weeks ago, and have heard very little since. Is there any more I should do to get it noticed? | 17:34 |
| persia | bug #255976 | 17:34 |
| ubottu | Launchpad bug 255976 in keytouch "Keytouch 2.4.1 Package" [Wishlist,Confirmed] https://launchpad.net/bugs/255976 | 17:34 |
| Ampelbein | Hi! What about a bug like #74807, where the poster found a solution himself? What is the correct status to set the bug to? Personally I would say "Confirmed", have the documentation edited to represent the problem and then "Fix Released". What is the right way here? | 17:34 |
| Ampelbein | bug #74807 | 17:35 |
| ubottu | Launchpad bug 74807 in acpi "Audio stops working after resume" [Undecided,New] https://launchpad.net/bugs/74807 | 17:35 |
| mcas | i need some help with bug 260244 | 17:35 |
| ubottu | Launchpad bug 260244 in kdebase "seg-fault while rendering page" [Undecided,Incomplete] https://launchpad.net/bugs/260244 | 17:35 |
| persia | xnevermore: You've done everything you need. The sponsor queue is a bit clogged right now. | 17:35 |
| mcas | i can confirm the problem with konqueror3 and don't have the problem with konqueror4 | 17:36 |
| mcas | what should i do with this bug. | 17:36 |
| mcas | should i mark it as triaged? | 17:36 |
| persia | Ampelbein: I'd call that Triaged, as the solution is known for that hardware. Mind you, it may not be trivial to integrate into the packaging because it may be that different hardware needs different settings, but that really needs a developer to investigate. | 17:37 |
| mcas | with a comment with my information? | 17:37 |
| xnevermore | persia: awesome. I just found it a bit strange. If I file a regular bug, I usually hear back from folks fairly soon, but when I release fixes, they seem to go unnoticed. | 17:37 |
| xnevermore | bug #257110 is another example | 17:37 |
| ubottu | Launchpad bug 257110 in libgems-ruby "libgems-ruby1.8 conflicts with rubygems1.8" [Undecided,New] https://launchpad.net/bugs/257110 | 17:37 |
| Ampelbein | persia: ok, then i would need someone of bug-control have set this. thanks for the info. | 17:38 |
| persia | xnevermore: Yeah, in the past we were better about pushing fixes, and less good about reviewing bugs. We've tried to fix the reviewing bugs bit, but we're falling behind on the including fixes bit :( | 17:38 |
| xnevermore | lol | 17:39 |
| xnevermore | i see | 17:39 |
| asomething | xnevermore: I think a big part of that is that there are a lot of people triaging that aren't devs, so if you post a bug that needs more info people will ask you about it but when you have something that needs to be acted on it can take a little while longer for a response | 17:40 |
| persia | mcas: That's a tricky one. You might ask in #kubuntu-testers if someone can reproduce with an earlier version, or maybe if they have any guidance on whether such bugs should be considered fixed. | 17:40 |
| xnevermore | persia: yeah, that makes sense. | 17:41 |
| mcas | persia: i tried it with a konqueror from kde4.0 not 4.1 | 17:41 |
| persia | asomething: That's precisely it. We seem to get about the same percentage of new people each cycle, but depending on which area is behind, that area gets more recruiting, so we're never quite perfectly balanced. | 17:41 |
| persia | mcas: Still, unless someone answers here, your choices are really to ask there, or find another bug for now. | 17:42 |
| mcas | ok | 17:42 |
| xnevermore | asomething: maybe the focus should be to motivate triagers and packagers to move up the later to become MOTU, etc. | 17:42 |
| persia | xnevermore: Last time we did that we ran out of triagers :) It's all a matter of balance :) | 17:43 |
| xnevermore | persia: good point =P | 17:45 |
| jcastro | bdmurray: you do needs-packaging bugs as confirmed,wishlist right? | 19:09 |
| bdmurray | jcastro: correct, provided it isn't already packaged and minimal information about the software is provided | 19:12 |
| jcastro | https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=needs-packaging&field.tags_combinator=ANY&fiel | 19:12 |
| jcastro | might be a good 5-a-day target to clean these out then | 19:12 |
| greg-g | ugly link! | 19:13 |
| jcastro | sorry! | 19:13 |
| greg-g | heya | 19:13 |
| bdmurray | that's probably scriptable | 19:13 |
| jcastro | welcome back greg! | 19:13 |
| greg-g | jcastro: not quite, closer though, I'm in Minneapolis | 19:13 |
| jcastro | ah | 19:13 |
| jcastro | we need a bug jam. kubuntu-de is pulling away! | 19:13 |
| greg-g | getting there, next weekend, this weekend is the gf's sister's wedding | 19:14 |
| greg-g | jcastro: oh noes! | 19:14 |
| greg-g | we'll do one once some students are back in town, see if I can poster some geek hangouts | 19:14 |
| asomething | jcastro: if you do a hug day or something for those, one good thing to ask people to do is check if there is also a Debian ITP bug filed and link it, so as to not duplicate work | 19:18 |
| jcastro | asomething: good idea | 19:19 |
| greg-g | +1 | 19:19 |
| bdmurray | asomething: I've written a script that looks for those | 19:19 |
| jcastro | hey ... you know how we link bugs to debian, etc ... | 19:19 |
| jcastro | I wonder if it would be useful if lp let you link to ITPs | 19:19 |
| bdmurray | jcastro: you can as though are filed in the debian bts about the wnpp pseudo-package | 19:20 |
| bdmurray | s/though/those/ | 19:20 |
| jcastro | ahh | 19:20 |
| jcastro | now can you script /that/? | 19:20 |
| bdmurray | jcastro: yes, I wrote something that does that last weekend | 19:20 |
| jcastro | man, everytime I think of something you've already got a script | 19:21 |
| bdmurray | I'm still actively working on it but I've affected 76 needs-packaging bug reports so far | 19:21 |
| jcastro | hot | 19:22 |
| bdmurray | Yeah, I was / am really excited about it | 19:23 |
| greg-g | pretty soon bdmurray will write a script to come up with new script ideas | 19:28 |
| bdmurray | lol | 19:28 |
| greg-g | karma for code commits means that each time I commit to my 5-a-day branch I'm getting karma? :) | 19:37 |
| jcastro | extra motivation | 19:37 |
| jjesse | greg-g: don't know how that is working cause i've been commit to branches and haven't seen my karma go up yet | 19:37 |
| greg-g | jjesse: hmm | 19:37 |
| jjesse | doesn't even show in the karma summary section | 19:37 |
| jjesse | i see bugs, but no commits | 19:38 |
| greg-g | hmmm | 19:38 |
| bdmurray | james_w: still around? | 21:21 |
| === mcas is now known as mcas_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!