FYI: I am just one of a team in Debian, not 'the' maintainer, Luigi is that. So I am just auditing the patch as presented for inclusion to Debian.
On Thu, 30 Mar 2017 14:26:59 +0200 Christian Ehrhardt wrote: > On Thu, Mar 30, 2017 at 1:28 PM, Amos Jeffries wrote: > > > Thank you. > > > > Biggest issue I see is a bunch of License problems - which will affect > > Ubuntu inclusion in similar ways IMHO: > > > > I agree and thank you as nobody ever spotted (or cared about) that. > But I know the Authors and can ask about a proper relicensing of those bits. > > TL;DR summary of the license todo: > * debian/tests/test-squid.py is GPLv2 should be proper GPLv2+ > * debian/tests/testlib.py bad copy of GPLv2+ should be proper GPLv2+ > - edit hints that authors actually wanted it to be the incompatible? > * debian/tests/testlib_httpd.py is GPLv3 should be GPLv2+ > * debian/tests/squid add an explicit GPLv2+ License > > > > [...] > > would make the .deb package and everything inside it a GPLv3-only > > offering. Even assuming tat is okay, a v3-only .deb makes the above > > v2-only script issues worse. > > > > I'm not a lawyer, but I think in the python + test case this is even more > special. > As there is no classic linking involved, but more important the tests are > only part of the source, but not part of the .deb being produced. > Never the less I clearly want to sort that out - thanks for bringing it up! I think the fact the Debian/Ubuntu ship source tarballs makes that an issue. I wrote .deb but meant the source package (.debs?). IANAL myself, just have enough experience to spot collisions. If the technical packaging rearrangement and authors does not resolve that cleanly it may be something to pass to the Debian legal team to suggest a solution. > - this appears to be a large and generic python library. Do we really > > need to embed it anyway? can it not be pulled from some other package or > > provided by the QA infrastructure itself? > > > > It is part of a much bigger testsuite, therefore the bigger libraries. > > A package would only make sense if it would be packaged but it is not, the > right way would be to pull from their git or such. > But then that gets us back into the connectivity issues from DebCI/Ubuntu > Test infrastructure. > > The benefit of taking the libs as-is was to be able to later on update them > by copying in the newer versions / cherry-picking changes. IME the opposite is actually true. Synchronising N copies of some generic code copy-n-pasted across an unknown number of packages is a major PITA to work with variations - even using VCS tools to do it. Having one library package with easily identified dependencies that can be coordinated with API changes is far better. In the short term I find it better to propose and wait a while to seeif the CI can be fixed. Debian is in freeze now so no urgency on updating squid yet. > Changes are needed over time as Distributions change every so slightly. > > Yet I agree that it might need only a small subset, would you be ok with me > trimming that code down to the point that it will be only the test-squid.py > with just the functions needed moved into it and a proper relicense from > the original Authors? Personally, yes. But as mentioned I'm fairly new to Debian processes. > > I think a few basic changes to the test logic should be made to avoid > > Internet access being required to send traffic to what are bogus URL > > domains anyway. > > > > It only goes to localhost/127.0.0.1 in what I sent, could you elaborate > where you still see Internet access being required? I was being fooled by the script documentation. By my reading it says what the test is supposed to be checking. If the documentation not matching what is actually being done that would still be an issue needing a fix, just different. Taking a closer look I dont actually see squidguard.conf being created anywhere, and squidguard is not listed as a test dependency. So maybe the SG test is not even happening ? I dont see squid.conf being setup anywhere for the tests either. So maybe I am missing a major piece of the DEP8 process? > The only references I still see are in the the header which would be > removed in a cleanup anyway. FYI: From my perspective what I see with this bug repoort is that you submitted a patch requesting it be applied, with statements asserting that it was in successful active use as supporting evidence of it being useful and trustworthy. I am just auditing a patch proposed for merge. If that is not the final patch you want comitted, please clean it up before even applying - or make it very clear that further work is needed before applying. That is a good practice for submitting patches to any project, anywhere (sometimes even a mandatory requirement). You are risking a maintainer just taking the patch as-is and applying it without any of your intended final changes. > Those headers refer mostly to its use in the wider QA suite and in the > scope of being a dep8 test make it misunderstandable at best. > > [...] > > Also squid.conf can load a custom hosts file > > to point any domains used at a server being run by the test > > infrastructure, eg the Apache being run for other tests anyway. > > > > I didn't know there was an apache around for such tests, but since the > current code is self sufficient on its local host that would not be needed. > And thereby would work also in e.g. local kvm based tests and such. debian/tests/control uses Depends on apache2 and the debian/tests/squid sets up its config file. The tests to localhost appear to be checking that squid->apache setup works with that config. > It would be nice If you could ack the approach of: > - clean .py files to be one file stripped to what is needed > - re-licence by original Authors as proper GPLv2+ Well, the re-license is only relevant if the code is going to be applied to squid packaging. If it turns out fine to package separately, then the problem vanishes enitirely. So I would start with the packaging options. > - add license to d/t/squid > - keep tests themselve as-is (vs localhost) I am puzzled by the squidguard stuff, what is actually going on there (nothing? redirect to fake domains as documented?). But overall I am definitely in favour of at least having the same tests in Debian and Ubuntu to reduce the diff. That cannot happen fully in squid-3 due to the freeze, but what I have been working on with Robbie Basak is for the squid-4 packages to be more identical in features supported. So these tests become very relevant there. > If you would do so I'd start getting in touch with the original Authors and > once I have their ack start the cleanup/merge of the code. FY: I'm not the authoritative maintainer for Debian. Just assisting in the team. Luigi is quite busy these years, so if you need a formal Ack you might be waiting a long while. Amos
