-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-04-04 16:04, Vincent Fourmond wrote: > Package: lintian > Version: 2.5.0~rc1 > Severity: wishlist > Tags: patch > > Hello, >
Hi Vincent > Currently lintian does not cover at all the java packaging policy, > and that's probably one of the reasons why it is not very well > respected (especially since there are some quite devious tricks > there). > Thanks for your interest in improving the coverage of the Java policy. It was also my original intention when I joined Lintian (I admit being a bit carried away :P ). Have you also had a look at http://wiki.debian.org/Java/QATools ? It is possibly a bit outdated, but I think most of the suggestions are still worth considering. Also feel free to add the things you are working on; hopefully that will avoid duplicated work. :) > I have started an implementation of that in a clone of the git > repository. I have attached a patch containing some of my work. Please > note that this patch addresses #575447 but also a lot more. > What is classpath-contains-relative-path about? I have never heard any security issues with related to relative classpaths (nor do I recall any request to have the Java policy amended to take care of this). Could you provide a reference to this issue? Then there is the /usr/share/ part, which I am not too sure about anymore. I originally thought that swt was the only one of its kind but eclipse turned out to contain a lot of them actually. Of course this is (in itself) no excuse for the rest of the arch independent jars to be installed outside /usr/share. Maybe we can start with a lower severity/certainty and then bump it to an error later. Also you/we need to set up the java policy in data/output/manual-references so we can use java 2.2 and java 2.3 in checks/*.desc ref fields. > I plan to go on working on that, if that's fine by you. Anyway, > there are a lot of things that still need to be implemented. What is > the workflow of the lintian team ? Shall I send you regularly batches > of git format-patch ? (which I haven't done this time). How can I > actually join the lintian team ? > I am not too sure of the general work flow, but feel free to send patches e.g. via bugs if you have more tags/changes. Personally I would prefer if you used git format-patch (easier for me). I believe you can test it by using: LINTIAN_ROOT='.' frontend/lintian-info -t <tag> Assuming you did not know it, you can also use frontend/lintian in a similar fashion to test your changes without having to build and install lintian. > Cheers, > > Vincent > > -- System Information: Comments on the patch itself (aside from the questions about some of the tags above): Why the "use" of common_data and File::Basename? The check does not appear to use either. Why is the check "binary only" but the collection "binary + udeb"? I doubt we have any udebs with jar files, so I think it is safe to make both "binary only". I believe that the java_info sub in Lintian::Collect::Binary needs a # sub java_info Needs-Info java-info line. There is an automated test to check for this stuff. Secondly it needs POD documentation (see the bottom of the file). @jarwrapper_or_equivalent could be turned into a string - if we get alternatives we can use "jarwrapper | alternative". This is what we do with (e.g.) $PYTHON_DEV in checks/fields. Please add automated tests for the tags (see t/tests/README or existing tests for more information). We are trying to keep t/COVERAGE as empty as possible. :) I have no strong preference to whether the tests should be in the same patch or not, so do what is easiest for you. You can test individual tests by using: debian/rules runtests onlyrun=<name-of-test> - OR - debian/rules check-tag tag=<name-of-tag> Note the name of the test is the one listed in its desc file - if you copy/paste a desc file and forget to update the name in it, you may see some "funny" results. Please make sure that the test-scripts still pass with your patch. You can check this by running: debian/rules runtests and wait for: """ t/scripts/<something> [...] ok All tests successful. Files=37, Tests=9640, [...] Result: PASS """ You also ought to run the entire tests to ensure your new tags are not triggered in the test suite (causing other tests to fail), but I have feeling we do not have a lot of jar files in our test suite (yet). :) Finally, we are planning to release 2.5.0~rc2 soon and I am hoping to merge a branch shortly after the release. *If* this branch is merged your collection will need to depend on two new collections (index and fields), since these will provide the "index" file and the "fields/" directory (respectively) in that branch. If you check for the index file instead of fields/package, then you can avoid the fields dep as far as I can see. The check will also need a Needs-Info on fields ($info->relation). ~Niels -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNmzesAAoJEAVLu599gGRCVhoQAJGTGUt3KrQF0uk6Chs7cSCB cwf3Rm5JggBmq+MBKJqrZiaTGqashSOFjTCYFgYD26C+jCv7n9AHlGPwpee8Ugja EkzRZ59w6OhhT9/ny973pDXR5oqcwSy5RxozR1e2dqApy8R6Lt5qeT7TxaP2Hnj/ 3xAuiiQAX0/flYHu218MI7vKd69FvpCUBueHllv9a+UObQPHlVoEJUKceRhPMiDs VK9YSnAs8qB3WzqULt4J+LDC5eKMN4A2eLrgeLlGGhi4AEeC2Id2N3/uRP8PVgIl k5Fx1b8MFJpibafOeS1nYlKjdn8/IZqudyxG/uEDtFiF5CMl86kDrSLI0pyGyqyU 9j63hOm2prR176DAO96pzXq6qIl1ugpNjgswjcrOD/qT0SyUm7qO1MNdegMc5Tqm uFpvCpMLJ17hM93NM/YKKrRA13FzVYgCgbBgdrkJpy9PZX8dapV5gG022wVGhbc4 14BKiooh8qWGomU9csDZa7TU7/u+8H6MgBj4AwwwmfkdzxQFEtksXz6vDzh4AkUO vv+V8uRhJYHZXxt9/yV91Hk2fJfI5xtcA+SjyfBB8A/u/BXUflNX6LRiTrFWD66s gFFM66lC/GcuZGkhihR6zp5UTn9tbtGXL+Vte6FQhS7Qv6Yiu6m3GAZ8Nry+AcDc hD4oynIS0O4lbfM8MD3T =UMxP -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
