eyfour | Who do I contact in order to get bug fixes for init scripts pulled into the repos? | 09:51 |
---|---|---|
eyfour | The maintainer of the package in question is an upstream Debian developer, and the bug was fixed a couple of years ago in Debian. | 09:51 |
eyfour | Bug link: https://bugs.launchpad.net/ubuntu/+source/postgrey/+bug/981789 | 09:52 |
ubot5 | Launchpad bug 981789 in postgrey (Ubuntu) "Postgrey does not stop after 'sudo service postgrey stop'" [Undecided,Confirmed] | 09:52 |
=== hikiko is now known as hikiko|bbi | ||
=== hikiko|bbi is now known as hikiko|bbl | ||
=== hikiko|bbl is now known as hikiko | ||
cprofitt | this bug was marked a duplicate: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1510339 | 17:10 |
ubot5 | Launchpad bug 1585863 in network-manager (Ubuntu) "duplicate for #1510339 WiFi malfunction after suspend & resume stress" [High,Confirmed] | 17:10 |
teward | cprofitt: okay? | 17:10 |
cprofitt | not sure that this is a duplicate -- but if it is shouldn't the duplicate be reversed and the later bug be marked the duplicate | 17:11 |
cprofitt | your thoughts teward -- I was thinking of chaning the duplicate status... the original bug likely should have be marked will not fix -- since 15.04 is not an LTS | 17:16 |
teward | cprofitt: the question is not what the bug was filed under. the question is if the bug still exists in a supported release. | 17:20 |
teward | if I filed a bug under 9.04, but nothing's moved to fix it and it continues to exist in 16.04 and 16.10 then the bug is still valid | 17:20 |
teward | that said i'm not qualified to touch on a network-manager bug | 17:20 |
teward | i avoid those like the plague :) | 17:20 |
teward | (same for kernel bugs, unless they directly torpedo something I work on) | 17:21 |
cprofitt | I could reverse the duplicate status... | 17:21 |
teward | i'd honestly wait for more opinions | 17:21 |
teward | i'm least qualified to comment in this case (network-manager bugs are weird...) | 17:21 |
cprofitt | teward: thanks I will try to ask Martin -- he is the one who marked the duplicate... | 17:23 |
cprofitt | thanks for the advice | 17:23 |
teward | cprofitt: it may be the case they're the same underlying problem though | 17:24 |
teward | that said, I will say 100% that you should *not* reverse the dupes, if they're not the same then that's one thing, but switching which is a dupe of which makes no sense | 17:25 |
teward | that's my opinion | 17:25 |
cprofitt | teward: why would the dups not be reversed -- I was always taught newer bugs were makred as duplicates of older bugs... has that changed? | 17:27 |
cprofitt | I was taught that when devs are looking at fixing bugs having the original report was important due to that establishing the original date of the issue. | 17:28 |
teward | i'm not sure who taught you that, but consider I have a handful of bugs that are 'recent' but have an 'old' bug they're marked to. | 17:29 |
teward | the original report is the one yours is marked as a dupe of by date alone | 17:29 |
teward | oop i misread the years | 17:29 |
cprofitt | yep | 17:29 |
teward | cprofitt: the second consideration is which one has more 'useful data' | 17:29 |
teward | i've actually switched dupe status from an older to a newer when the older had zero debug data but the newer had a lot more, and the core issue was the same | 17:30 |
teward | there's a few cases of that on the nginx bugs, though i have handled so many you'd have to dig to find the xpecific examples | 17:30 |
teward | bleh i can't type | 17:30 |
teward | cprofitt: Personally, if they're the same issue, I suggest leaving it alone, I see more debug data on the newer one than the older | 17:30 |
* cprofitt nods I can agree with that | 17:30 | |
teward | assuming they're the same issue (checking with Martin wouldn't hurt) | 17:30 |
teward | the only reason *I* would change it is if I knew they weren't the same issue. | 17:31 |
cprofitt | the newer one has more activity... though not the same file uploads... | 17:31 |
cprofitt | I never change my own bugs status -- makes it look petty, but wanted to understand what happened here since it ran counter to what I had been taught. | 17:32 |
cprofitt | in the end -- getting the bug fixed is important. | 17:32 |
teward | actually i just thought of an example of the issue - there's older bugs closed as Invalid for "Address already in use" for nginx. Ther'es now a 'master' bug that was created detailing the signature | 17:33 |
teward | and that's now in apport dupe detection | 17:33 |
teward | and I put all the old bugs as dupes of the new one :P | 17:34 |
teward | not because it's an 'issue that still exists' but because the master is the new 'master' for those types of issues. A little irregular, but it slices down the annoyingness of all the invalid bugs, and points to detailed reasoning for the problem and how to fix it | 17:34 |
* teward shrugs | 17:34 | |
cprofitt | cool... it has been a while since I have done bug reports... so if that is the new process that is cool. Want to make sure I do not cause issues for not being up to speed. | 17:34 |
teward | the process 'varies' | 17:34 |
teward | cprofitt: if it were anything under my direct radar, though, yours would have been closed as a dupe of the newer one which has more info, but that's just me. Feel free to poke Martin though since they closed it in the first place | 17:35 |
teward | or take it to the mailing list | 17:35 |
* teward goes back to poking two servers to try and get them to talk to each other | 17:35 | |
cprofitt | teward: poking rarely works ;) | 17:36 |
cprofitt | for servers. | 17:36 |
teward | (read as: "Threaten the servers with digital violence should the networking not come up") | 17:36 |
teward | nah, it's probably me fubaring the firewall ACLs :P | 17:36 |
cprofitt | oh... that works at times. | 17:36 |
cprofitt | firewalls are fun :) | 17:37 |
cprofitt | really ;) | 17:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!