Christopher Bertels wrote: > Hi, > > I was just wondering, if there is any interest at all to include the packages > into Debian? > > Cheers, > Christopher. > Hi Since most of our Java DDs (Debian Developers) appears to be busy, I have taken the liberty of reviewing your packages. Though I am not a DD, so with any disagreement between my review and comments of DDs, you are better off listening to the respective DD. Also, I am not familiar with the maven-build parts nor our helper tools for it. I looked at how they were used in the debian/rules and assumed they were fine - though my assumption may be wrong. I have attached the full review (as review.txt) along with the build-order[1]. There are three major points I would like to highlight: First, a some of the packages have issues with the debian/copyright file; ranging from wrong copyright years listed to listing the wrong license. Secondly, most of the packages are lacking a description. Third, two of the packages Fail To Build From Source (FTBFS). One of them are missing dependencies (listed in the file). The other failure was beyond me to figure out but did not look java-related. There are other things you should consider dealing with listed in review.txt. I hope you find it usefully, ~Niels [1] Mostly intended to assist others testing your package.
Generally build in listed order, though other than [Higher level] you should be able to build them in any other inside their own level. [First level] libaduna-commons-concurrent-java libaduna-commons-i18n-java libaduna-commons-io-java libaduna-commons-lang-java libaduna-commons-net-http-server-embedded-java libaduna-commons-text-java [Second level] libaduna-commons-iteration-java -> libaduna-commons-concurrent-java libaduna-commons-net-java -> libaduna-commons-text-java libaduna-commons-webapp-java -> libaduna-commons-lang-java, libaduna-commons-text-java libaduna-commons-xml-java -> libaduna-commons-text-java [Third level] libaduna-commons-platform-java -> libaduna-commons-net-java libaduna-commons-collections-java -> libaduna-commons-iteration-java, libaduna-commons-concurrent-java [Higher level] libaduna-appbase-java -> A lot. sesame2-java -> A lot. soprano-backend-sesame -> sesame2-java.
**** General case ****
The following applies to most (but not necessarily all) packages.
[Debian Files]
* Al dsc files were not signed by a key.
* debian/control:
- Missing description for binary package.
- Vcs-* is pointing to upstream and not Debian VCS.
- Empty suggests in binary package - (No reason to
have empty fields).
* debian/rules:
- clean target appears to be redundant (or could be
removed by using dh compat 7).
* debian/watch: looks ok.
- Could not test (got time-outs).
* debian/copyright:
- In some files Aduna claims copyright back to 1996,
whereas the copyright says 2001-2008. The copyright
file should be updated in packages where this is
the case. [#1]
[(Build-)Depends]
* Depends on openjdk6.
- It is prefered to (build-)depend on default-jdk
where possible. Though it is/has been a common
case that a specific jdk is required to properly
build/run a package. Though on most platforms
default-jdk is openjdk6 anyway.
* Missing runtime depends on a jre.
- java library packages should depend on a
suitable runtime. [#2]
* Some packages has Build-Depends on lib-java-packages
that they do not runtime depend on.
- This is very unusual for java packages; however
if the package's core functionallity works
without these java-packages, this is not a
problem; though a regular Recommends or Suggest
would probably be a good idea/required.
[lintian]
* Uploader name mismatch -> lintian thinks it is an NMU.
- Correct name in debian/control or in debian/changelog.
* Gets a "should close itp-bug" - though this is probably
irrelevant in this case.
[Other]
* No doc-package even though install instructions
for them exists in debian/rules.
- Missing doc-base files.
- The doc is actually built in most packages (12/15)
as far as I could tell, just not included.
* Some packages had eclipse configuration files
left in them (.settings/).
- I have ignored these, but you may want to
update the fetch scripts to exclude them or
ask upstream not to commit them to the
repository.
**** Specific packages ****
[src:libaduna-commons-concurrent-java]
* Missing pom file.
- All other java packages have one; probably forgot
to add this one.
[src:libaduna-commons-i18n-java]
* debian/copyright: **COPYRIGHT MISMATCH**
- 6 out of the 7 files are copyrighted by "Hewlett-Packard
Development Company, LP" and not "Aduna"
- License is phrased differently for these files.
licensecheck recognises these BSD licenses unlike the
Aduna version - however it is not a complete match with
/usr/share/common-licenses/BSD either.
* Contains a "poms" file for a different package.
[src:libaduna-commons-net-http-server-embedded-java]
* debian/copyright: **LICENSE MISMATCH**
- The listed license (from LICENSE.txt) does not match
the license of the source-files.
- Source file says BSD.
- LICENSE.txt + debian/copyright says OSL v. 3.0
* This entire package only contains a single source-file
aside from a single javascript that looks more like a
test than source.
[src:libaduna-commons-webapp-java]
* debian/copyright does not mention css file which
appears to be a complete copy of an w3 appendix.
- file:war/src/main/webapp/styles/w3-html40-recommended.css
- No license/copyright information in it nor via the link
listed inside the file - it is a part of an appendix to a
w3 publication.
- Unsure if it should be mentioned debian/copyright.
* (Build-)Depends on libservlet2.4-java.
- libservlet2.5-java is available in testing.
- Consider rebuilding against the new version if possible.
- This is a mere recommendation.
[src:libaduna-appbase-java]
* Direct modifications to source without using patches.
- It changes the newlines of at least one source file,
which makes it difficult to notice that it also make
an other change to the source (substituting one
method call with another).
[src:sesame2-java]
* debian/copyright: **LICENSES MISSING** [#3]
- Does not list all licenses - some non-java have a different
license.
- Does not list all copyright holders. Some files have more
than one copyright holder.
* FTBFS:
- Cannot find symbols.
- Missing (Build-)Depends:
+ libcommons-httpclient-java
+ libcommons-fileupload-java
* Build warns about the following unknown substitutions:
- ${shlibs:Depends}
+ To the best of my knowledge this is not needed for
arch-indep packages.
- ${sameVersionDep:libsoprano-dev}
+ Does not even Build-Depend on libsoprano-dev.
* debian/control:
- Depends on java2-runtime and also default-jre-headless |
java2-runtime-headless. java2-runtime-headless is a
subset of java2-runtime, so there is a redundant depends.
Furthermore java2-runtime is a virtual package and thus
should have a non-virtual alternative. Relates to [#2].
[src:soprano-backend-sesame]
* Contains precompiled class file.
* Outdated standards version.
* FTBFS - errors outside my domain.
- "Could not find X11".
* Clean target gives errors.
* Minimal review.
- Mixed package that is mostly beyond my field of
knowledge.
**** Footnotes ****
[#1] I used
grep -r "Copyright" src/
to determine this, since licensecheck does not
report the years.
[#2] Usually default-jre-headless | java1-runtime-headless |
java2-runtime-headless for library not requiring
X11 support; though your milage may vary.
Note that the current java policy says a package must
Suggest java-virtual-machine, though the current
practiceses contradicts this and this clause is removed
the drafts of the revised policy.
[#3] The following command may be of aid to find these.
grep -r "Copyright" compliance/ core/ testsuites/ | grep -v .settings | grep -v Aduna
Attachment:
signature.asc
Description: OpenPGP digital signature