Thank you. Biggest issue I see is a bunch of License problems - which will affect Ubuntu inclusion in similar ways IMHO:
* debian/tests/test-squid.py not being compatible with the .deb package License. Squid and the .deb packaging are at least GPLv2+. This script states v2-only. It will need to be relicenced compatible with GPLv2+ (preferrably to that license) to be added. * debian/tests/testlib.py has same GPLv2-only issues as above. However this one is invalid is it appears to be a copy-paste of GPLv2+ with (incorrect) editing to make it explicitly drop the "or later" permission. It is not the legal GPLv2-only disclaimer. The edit is also a strong hint that the authors actually want it to be the incompatible v2-only license version and may not agree to GPLv2+ etc. - 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? * debian/tests/testlib_httpd.py is GPLv3 (-only). which makes I believe 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. - it is another fairly generic library. So maybe an external package providing it could be the best way forward here. * debian/tests/squid script has no license at all. Given the above sorts of things happening I would be quite uncomfortable assuming they intended the .deb license to apply. It would be better for its author(s?) to explicitly pick a compatible (or same) license and state what they chose along with the author name(s?). 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. In debian/tests/test-squid.py there is no reason why the .com TLD needs to be sent by squidguard. It could send some .local TLD domain or at worst use sub-domains within the example.com/.net/.org domains which are registered for such things. 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. Personaly I would use something even more basic with hard-coded responses that can be tested explicitly against the squidclient output. Amos
