[09:51] <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:52] <eyfour> Bug link: https://bugs.launchpad.net/ubuntu/+source/postgrey/+bug/981789
[17:10] <cprofitt> this bug was marked a duplicate: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1510339
[17:10] <teward> cprofitt: okay?
[17:11] <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:16] <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:20] <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:21] <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:23] <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:24] <teward> cprofitt: it may be the case they're the same underlying problem though
[17:25] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <cprofitt> firewalls are fun :)
[17:37] <cprofitt> really ;)