=== ePirat- is now known as ePirat
=== mfisch is now known as Guest41550
[17:14] <teward> hey, stupid question, but is there a hierarchy of bug triage such that someone else in the chain has higher priority decision over bug importance / triage for a given package than others?
[17:18] <penguin42> teward: Well there is bugsquad and bug-control and the package-maintainers for a particular package, and then there is bdmurray
[17:19] <teward> penguin42: so essentially, higher-to-lower is... bdmurray (ultimate final authority), package-maintainers/uploaders, bug-control, bugsquad, in that order?
[17:19] <teward> 'cause i have issues with how Alberto handles triage
[17:20] <teward> trying to determine the hierarchy of authority for the package i have issues with how he handled the bug
[17:20] <penguin42> teward: I'm not sure what the formal way to moan is
[17:20] <teward> mmm
[17:20] <teward> well he's caused strife before... enough evidence of that lying around
[17:21] <penguin42> I've also had issues with some peoples triaging mechanisms, but I can't say I know how to referee it
[17:22] <penguin42> teward: If you've already asked nicely and not got anywhere, I'd say ask bdmurray, as the owner of bugcontrol team
[17:23] <teward> penguin42: you know what the problem is?  Alberto's a hard one to find
[17:23] <teward> i also think 'high' importance is dependent on being able to reproduce the bugs - I fail to see any evidence where Alberto went and actually did any reproduction tests
[17:23] <teward> meh, maybe i'm just griping for the sake of griping :/
[17:24] <penguin42> teward: I wouldn't necessary try to reproduce for a 'high' if the problem sounds grim enough
[17:24] <teward> penguin42: the big problem I have is systemd now - it doesn't actually output useful information
[17:24] <teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1447294 is the bug if you want to take a look
[17:24] <ubot5> Ubuntu bug 1447294 in nginx (Ubuntu Vivid) "package nginx-full 1.6.2-5ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete]
[17:24] <teward> i don't have an issue with "High" but there's zero useful data from the dpkg history
[17:24] <penguin42> teward: and anyway, if it's failing for a bunch of people but as a triager you can't reproduce it, then you can't dismiss the bug just because you can't reproduce it
[17:24] <teward> penguin42: two people is a bunch?
[17:25] <teward> penguin42: i'm not dismissing the bug - i'm dismissing Alberto's actions
[17:25]  * penguin42 looks
[17:25] <teward> penguin42: you can even see I asked for more information to try and deduce *what* caused dpkg to fail
[17:25] <teward> penguin42: also why i asked in -devel if there's a way to force apport to run certain additional commands to get information
[17:25] <teward> (if apport gave us information for nginx that actually helped debug it, that'd be one thing, but in this case, it gave us zero truly useful information)
[17:26] <teward> i agree that "High" is valid, but the problem being that there's no debug data of use (and Alberto should know this)
[17:27] <teward> is why i'm complaining.
[17:27] <penguin42> teward: I'd have to agree that a package like nginx failing to install/uninstall is probably a high
[17:27] <teward> *cough* [2015/04/25 13:26:52] <teward> i agree that "High" is valid, but the problem being that there's no debug data of use (and Alberto should know this)
[17:27] <teward> penguin42: i'm complaining that Alberto just set importance and did no additional triage work
[17:27] <penguin42> teward: Right, but the fact you don't have any debug data doesn't change the importance
[17:27] <teward> penguin42: at what point did i say that
[17:27] <teward> i'm complaining that alberto could have gone a step further and actually bothered to do triage work
[17:28] <penguin42> teward: I think it's OK to set importance and not to do further triage
[17:28] <teward> i think that's what annoys me most - i fail to see him doing anything else but setting importance and such
[17:28] <teward> maybe i'm biased by upload privs for it, but meh
[17:28] <penguin42> teward: While I'd agree it would be nice to do more triage, maybe he felt he doesn't know nginx well enough and it's better to leave it to those who do
[17:28] <teward> (the consideration point being, if users see an importance set they thin that means "Oh, nice, someone's actually working to test and reproduce." and gives them a false view on it.
[17:29] <teward> penguin42: IMO he should just stop touching server bugs, his focus seems to be GUI *shrugs*
[17:29] <teward> maybe i'm just having a bad week
[17:29] <teward> although he gets on my radar as an irritant far too often
[17:30] <penguin42> teward: It would be worse if he was to ask irrelevant questions on the package to triage it
[17:30] <teward> well, then i'd be bothering bdmurray and saying he shouldn't have bug control, but that's a different story altogether
[17:30] <penguin42> teward: If he knows he doesn't know the package but sees the bug looks important it seems reasonable to triage; and then let the package owner decide otherwise
[17:30]  * teward shrugs
[17:30] <teward> penguin42: what's interesting is the latest failures there are dpkg failures, either because they used nginx.org's packages, or because of a nondeterministic failue due to no debug info
[17:31] <teward> i really wish we could tell apport what to actually get for a given package's failures
[17:31] <teward> (i'd love the systemd status for bugs :/)
[17:31] <penguin42> teward: I'm not sure of the details of apport but I think you can add stuff
[17:31] <teward> mmm, i might suggest that to Debian, since that's their systemd script
[17:32] <penguin42> teward: A lot of package installation failures are random installation screwups, disk fulls etc - but sometimes you do get things where a package assumes things about the /etc config files for the package and fails to install/uninstall - and those are valid bugs
[17:32] <penguin42> brb - I just need to check on my sorbet
[17:32] <teward> penguin42: given that there's usable debug data, then yes
[17:32] <teward> however in a fresh installation like was above, where none of the apt history shows nginx being installed, that adds to the complexity
[17:34] <penguin42> hmm, still sorbifying
[17:35] <penguin42> teward: Well, it could be something like a missing dependency depending what packages people chose
[17:35] <teward> penguin42: well they installed nginx-full, which called in the dependency for nginx-common - and that did install (see the dpkgterminalhistory)
[17:36] <teward> based on the info available i really wish I could force Apport to get additional data, but meh
[17:36] <teward> (systemd is giving me headaches >.<)
[17:36] <penguin42> teward: I'm fairly sure that's possible; but need to check with the apport guys
[17:36] <teward> here's the journal errors...
[17:37] <teward> Apr 22 14:24:32 hostname systemd[1]: Failed to start A high performance web server and a reverse proxy server.     Apr 22 14:24:32 hostname systemd[1]: nginx.service failed.
[17:37] <teward> ^ nothing useful
[17:37] <teward> just like dpkg's output
[17:37] <teward> i think i need to talk to the apport people
[17:37] <penguin42> teward: I'd consider journalctl -u nginx   or something like that
[17:38] <penguin42> teward: but that depends where nginx sends it's logs
[17:38] <teward> penguin42: /var/log/nginx/* i think is still the log dir, but a service failure... no idea.
[17:38] <teward> the systemd stuff is new enough that it's a headahce :P
[17:38] <teward> (back later)
=== Guest41550 is now known as mfisch
=== wgrant_ is now known as wgrant
=== kees_ is now known as kees