=== popey0 is now known as popey
=== sem2peie- is now known as sem2peie
=== bandali is now known as mab
[20:04] <arraybolt3> Eickmeyer: Earlier when you helped sponsor python--etcd3gw, you fixed a runtime-test-file-uses-supported-python-versions-without-test-depends Lintian gripe and mentioned that the lack of the python3-all test dependency was a violation of Debian policy. Where exactly is that in the manual? I'm having a hard time finding it.
[20:05] <Eickmeyer> arraybolt3: Any time lintian gripes about something with a warning, look at lintian-explain-warnings for that tag. That will tell you where to find it.
[20:05] <arraybolt3> It doesn't tell me anything about Debian policy.
[20:05] <Eickmeyer> s/lintian-explain-warnings/lintian-explain-tags
[20:06] <arraybolt3> It does tell me what the issue is and how to fix it, but not a policy manual section or even a reference to the manual.
[20:06] <Eickmeyer> arraybolt3: Any time it's a warning in lintian, it's a policy violation. It merely needs to be cited there.
[20:07] <Eickmeyer> Warnings in lintian don't mean there's a package build issue or that there's something functionally wrong, just that something *should* happen that's not happening.
[20:07] <arraybolt3> Eickmeyer
[20:07] <arraybolt3> oops
[20:07] <arraybolt3> hit enter rather than colon
[20:07] <Eickmeyer> heh
[20:08] <arraybolt3> Eickmeyer: Are you sure all legitimate Lintian warnings are policy violations? I don't even see where the policy manual mentions autopkgtests at all. The Python Policy doesn't mention them either. Without a section to cite, I can't report the bug as being "serious".
[20:09] <arraybolt3> gah, Debian's "search" feature for the policy manual *stinks*
[20:10] <arraybolt3> I guess it's just a package relationship though since it's a "depends" in a control file (though not *the* control file).
[20:10] <Eickmeyer> arraybolt3: You might have to search through the Debian Python Packaging manual for exactly where it's covered. I honestly think it's a bit of a bug in lintian that it doesn't cite an entry in the manual (it usually does) but if it's throwing a warning, it needs to be fixed, full-stop.
[20:10] <arraybolt3> Agreed.
[20:11] <arraybolt3> I'm not arguing about fixing it, I'm just trying to find where the manual says something so I have a value to punch in when reportbug asks me for it.
[20:11] <arraybolt3> (It actually makes you cite a section of the manual when reporting a policy violation, which on the one hand makes sense, and on the other hand is a bit frustrating :P)
[20:11] <Eickmeyer> You might just have to copy-paste the line from lintian-explain-tags. ¯\_(ツ)_/¯
[20:12] <Eickmeyer> s/line/lines/
[20:12] <Eickmeyer> Either way, they shouldn't ignore it as ignoring warnings is policy violation in and of itself.
[20:13] <arraybolt3> I think I'll use 7.2, "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." I think that's the policy that's being mentioned.
[20:13] <arraybolt3> Eickmeyer: Agreed.
[20:13] <Eickmeyer> 7.2 is close enough.
[20:13] <arraybolt3> hmm, but that's a  "should", not a must...
[20:13]  * arraybolt3 continues hunting
[20:14] <Eickmeyer> That said, this is more specifically *Python Packaging* policy than the overall *Debian Packaging* policy.
[20:14] <Eickmeyer> There is a whole section on Python Packaging.
[20:14] <arraybolt3> yeah, I'm grepping through it
[20:15] <Eickmeyer> arraybolt3: should vs must is the difference between warning and error.
[20:16] <arraybolt3> right, which is the difference between severity "serious" and severity "normal". I'm splitting hairs at this point trying to get things perfect :P normally I would just be like "meh, close enough", slap "normal" on there and cite the manual section, but I'm trying to do this exactly right since I'm aiming for MOTU :P
[20:16] <arraybolt3> really I should just proceed with normal
[20:16] <Eickmeyer> arraybolt3: I'd throw "serious" on it because ignoring a warning in and of itself is a policy violation.
[20:17] <Eickmeyer> At minimum, they should have a lintian override with an explanation.
[20:17] <Eickmeyer> But they don't, and it's an easily fixed warning.
[20:19] <arraybolt3> Eickmeyer: I can't see where ignoring a Lintian warning is a policy violation at all. I even found a full PDF of the latest version of the manual that's super easy to search through - searching for "lintian" and "warning" doesn't show anything about it.
[20:20] <Eickmeyer> arraybolt3: Ok, I'll give you that, but we all know that there's a warning and that it's not being overridden and it's easily fixed. So where does that land? Do we let it slide? Also, we know that everything in lintian is policy (except pedantic and experimental), right?
[20:20] <arraybolt3> and of course Debian has taken everything related to Lintian documentation, put it in a box, and shaken it vigorously, so now lintian.debian.org is down permanently and now I can't find the user manual for it :P
[20:21] <Eickmeyer> man lintian :P
[20:21] <arraybolt3> Eickmeyer: Of course we don't let it slide. But I don't want to specify bug severity "serious", cite something in the manual that doesn't exist, and then get told not do to that :P
[20:22] <Eickmeyer> DESCRIPTION: Lintian dissects Debian packages and reports bugs and policy violations.
[20:22] <arraybolt3> If the severity is "normal" despite the fact that we'd like it to be "serious", we probably should just live with that and call it "normal" IMO. ("serious" is a release-critical severity, so I can see why the docs would make it not so easy to assign that severity.)
[20:22] <Eickmeyer> If you think it should be normal, go with normal.
[20:23] <arraybolt3> Eickmeyer: well yes, man lintian will work, I was just looking for something I had seen in the online docs before.
[20:23] <arraybolt3> anyway, sorry to bother you, thanks for your help :)
[20:24] <Eickmeyer> arraybolt3: No problem. BTW, other examples for the same bug use "normal" so go ahead with normal.
[20:25] <arraybolt3> +1
[20:26] <Eickmeyer> arraybolt3: See Debian bug 955799
[20:26] -ubottu:#ubuntu-devel- Debian bug 955799 in lintian "lintian: misfired runtime-test-file-uses-supported-python-versions-without-python-all-build-depends" [Normal, Open] https://bugs.debian.org/955799
[20:26] <arraybolt3> perfect
[21:28] <pconst167> hi
[21:34] <arraybolt3> Silly question, but is there a reason that there's not a "produce-merge" utility in ubuntu-dev-tools? It would be mighty handy to be able to have a local tool for doing the equivalent of a Merge-O-Matic merge even if MoM hasn't picked up the packages that need merging.
[21:34] <arraybolt3> hmm, I answered my own question
[21:35] <arraybolt3> MoM doesn't pick up packages that have no base version, and you need a base version to do a merge at all, so nvm
[21:35]  * arraybolt3 shuffles off to fight with a package manually
[22:23] <mkukri> arent everyone doing merges in git-ubuntu now? ;)
[22:29] <tsimonq2> mkukri: I mean, Lubuntu has our own lightweight non-orig Git approach, and some people just prefer pull-lp-source/apt source/dget. :P
[22:30] <tsimonq2> Honestly though, I find myself using it a lot more. It's debatably faster than pull-lp-source, depending on whether Launchpad had enough sleep the night before.
=== mab is now known as bandali
[23:24] <arraybolt3> Anyone have a copy of britney-indexes-ppa they can shoot me? wget http://people.canonical.com/~pitti/scripts/britney-indexes-ppa is giving me a 403 Forbidden, and I'm instructed to download that file by https://wiki.ubuntu.com/ProposedMigration/LocalSetup.
[23:24] <arraybolt3> (assuming it has no sensitive contents that is)
[23:32] <arraybolt3> bdmurray: ^ (someone suggested you might know the answer to this)