Re: scala-tools-sbinary_0.4.2+2.11.M5-1_amd64.changes REJECTED
Hi Andreas, On Wed, 4 Oct 2017, Andreas Tille wrote: I was asking on IRC #debian-ftp how we can deal with the current deadlock and lamby suggested to ping you again. We are just waiting for advise what to do next. If re-uploading as it was is a sensible thing to do please let us know. If not, what exactly do you expect us to do? as long as all sources are available in the upload, I think the "buildable from source"-requirement can be loosened for bootstrapping the package. If I remember correctly, the missing sources and the incomplete debian/copyright have been the only reasons for the rejection (except somebody else objects now). On Tue, Sep 05, 2017 at 09:19:44AM +0200, Frederic Bonnard wrote: If binary jars for compilation are a problem, what should be done when for example you have a font file (with DFSG compatible license) that is used for generating image files at build time and those generated images will be included in the binary package. Should that source package be refused because the project didn't include the source of the font file (which can come from another project) ? (that could be a font file or any image without the source but with a DFSG license still) Generally speaking, if you can not build each part of a binary package from source, this package can not be in main. Somehow you have to create that font file, afterwards you create the images and put them into the binary package. This doesn't sound much different from compiled sources!? Thorsten
Re: Freeplane needs rebuild
hello Debian-java, Felix Natter writes: >> I tested freeplane-1.6.6-1 on a sid VM and a testing laptop, and found >> that the OSGi plugins aren't loaded. >> >> This is fixed if I rebuild exactly the version with tag debian/1.6.6-1, >> also on the testing system. >> >> I don't know what caused this, but shall I trigger a rebuild? >> I think the best way is to fix a small error like #875322 (drop >> dependency on jython, which is no longer needed in batik-1.9-3)? > > Could someone please sponsor a trivial 1.6.6-2 upload? > > https://anonscm.debian.org/cgit/pkg-java/freeplane.git > > I only removed a build dep and updated standards-version. > I hope that this will remediate the problem on Debian (OSGi plugins not > started) and Ubuntu (LP: 1720670, missing MANIFESTS). I found out that the issue is the parallel build introduced in debhelper level 10. I can reproduce the broken package (now with the exact same problem as on Ubuntu artful, phew!) with --jobs=8. Could someone please sponsor the trivial freeplane-1.6.6-3 upload? https://anonscm.debian.org/cgit/pkg-java/freeplane.git freeplane (1.6.6-3) unstable; urgency=medium * Fix broken build on buildds by disabling parallel build -- Felix Natter Wed, 04 Oct 2017 21:14:57 +0200 Many Thanks! -- Felix Natter debian/rules!
Re: scala-tools-sbinary_0.4.2+2.11.M5-1_amd64.changes REJECTED
Hi Thorsten, I was asking on IRC #debian-ftp how we can deal with the current deadlock and lamby suggested to ping you again. We are just waiting for advise what to do next. If re-uploading as it was is a sensible thing to do please let us know. If not, what exactly do you expect us to do? Kind regards Andreas. On Tue, Sep 05, 2017 at 09:19:44AM +0200, Frederic Bonnard wrote: > Forwarding to the correct debian-java mailing list.. > > --- > > Hi Thorsten, > > thanks for working on that and everybody that answered to help this > topic to progress. I've been off my computer last week. > > > your package seems to consist mostly of jar files without the corresponding > > sources. So I am afraid I have to reject it. > > That's right, there are several jars that are part of the embedded sbt > binary distribution that is used to only build the current sbt. > All started here : > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639910#118 > > There Mehdi Dogguy explained we can bootstrap sbt this way as long as we > do not ship those binary jars in the Debian binary package. It seems > this process has been followed for other softwares. > > That looked ok for me since the spirit of Debian is there : the > different components to upload are DFSG compliant : the sources of sbt > are there (2) and licenses of all files are DFSG compliant (10) (other > DFSG points are ok too; no mention of specific distribution point or > restriction, classical licenses). > > The only thing is that in main the set of components that I've pushed > may Depends on each other for runtime, but a simultaneous push in main > of those should in theory be ok (2.2.1 : None of the packages in the > main archive area require software outside of that area to function.) > > If binary jars for compilation are a problem, what should be done when > for example you have a font file (with DFSG compatible license) that is > used for generating image files at build time and those generated images > will be included in the binary package. Should that source package be > refused because the project didn't include the source of the font file > (which can come from another project) ? (that could be a font file or > any image without the source but with a DFSG license still) > > Sorry to play the devil's advocate and being irritating, I'm not that > kind :), just willing to understand. > So, am I missing some clear and strict policy point or is that a > question of interpretation. > > F. > > > > > Thorsten > > > > > > > > === > > > > Please feel free to respond to this email if you don't understand why > > your files were rejected, or if you upload new files which address our > > concerns. > > -- http://fam-tille.de
Re: Review of fairsim, libjtransforms-java and libjlargearray-java
Am 04.10.2017 um 17:42 schrieb Carnë Draug: > On 3 October 2017 at 18:12, Markus Koschany wrote: >> Am 03.10.2017 um 17:30 schrieb Carnë Draug: >>> On 2 October 2017 at 00:21, Markus Koschany wrote: [...] You don't have to add the classpath to the library. The Lintian check that warned about this issue has recently been removed. >>> >>> Without the classpath, then users of the jar files need to figure out >>> the dependencies themselves which does not work. As someone that >>> routinely uses java libraries via Python and Octave, I find it >>> essential. >> >> It really depends on the build system. Since this is a Maven project >> dependencies are declared in pom.xml files. What you are referring to is >> Debian's way of installing jar files into /usr/share/java. This is meant >> for build systems like Ant where you can easily add a symlink to your >> package and reference the versionless jar file. That's fine if you want >> to support this use case but it is not essential to get another package >> working and it might even introduce unwanted side effects like [1]. > > I don't understand why the build system used by a project should > affect the end user of said project. > > I am also not referring to the Debian's way of installing jar files > into /usr/share/java. [...] Those libraries are Maven projects and they are intended to be used as dependencies for other Maven projects by upstream. I can't find any hint of support for other build systems in the original tarballs. What you are doing is adding support for other use cases by installing the jar files into /usr/share/java. That's absolutely fine and the historical way how Java projects were initially packaged for Debian. For a pure Maven project adding the Class-Path attribute to the manifest file would be unnecessary because the files in /usr/share/java are not used by Maven. > If you do it and use jh_classpath or the *.classpath file then you must specify the absolute path to the libraries otherwise they won't be found. >>> >>> Not true. The path can be relative to the directory of the jar file >>> that contains the manifest file. >> >> Let me rephrase this. It is possible but bad practice. Don't assume that >> your jar file is always in the same directory as your dependencies. The >> only way to ensure that is to use an absolute path. >> > > Why is that bad practice? Can you guarantee that your relative path is always unambiguous even if you copy the jar file into another project or install the jar file into a completely different directory? I have been working for the past five years in this team and I can tell you a lot of things can go wrong when it comes to class loading. It really helps if all packages behave identical hence you will find many, many packages in our team that use absolute paths when exporting the CLASSPATH variable or when modifying the Class-Path attribute. [...] >> >> I can reproduce your issue. This is related to upstream's unusual choice >> of options in the pom.xml file. First of all I'm not sure why he won't >> simply stick to the default Maven directory layout (src/main/...). > > Because he doesn't use or like maven. It's there only so that other > people can make use of it but he uses the Makefile for himself. That is not an excuse for writing bad pom files. > I can > also understand why one would find the default maven directory layout > too deep. Actually the coherent and logical structure of Maven projects is one of Maven's biggest strengths. > >> This >> would solve your problem immediately. The issue here is that he uses >> ./ which tells Maven to look into the >> root of your build directory and then it detects the patched class in >> the ~/.pc directory and the original class under org and fails. >> >> I would try to fix the build system (the pom.xml) but I don't have a >> patch at hand at the moment. Perhaps someone else on the list knows a >> better solution. >> > > I have tried to change the build system already but I can't figure out > the right maven magic to make it look only inside ".org" either. I > think it may have to do with how debian-maven-helper is used. Note > how I had to manually remove a java file from the source tree in > `rules` [2] even though `pom.xml` should clearly exclude it [3]. This is not an issue with maven-debian-helper because it simply invokes Maven which rightfully complains about duplicated classes. The pom.xml and the directory layout should be changed. Markus signature.asc Description: OpenPGP digital signature
Re: Review of fairsim, libjtransforms-java and libjlargearray-java
On 3 October 2017 at 18:12, Markus Koschany wrote: > Am 03.10.2017 um 17:30 schrieb Carnë Draug: >> On 2 October 2017 at 00:21, Markus Koschany wrote: >>> [...] >>> You don't have to add the classpath to the library. The Lintian check >>> that warned about this issue has recently been removed. >> >> Without the classpath, then users of the jar files need to figure out >> the dependencies themselves which does not work. As someone that >> routinely uses java libraries via Python and Octave, I find it >> essential. > > It really depends on the build system. Since this is a Maven project > dependencies are declared in pom.xml files. What you are referring to is > Debian's way of installing jar files into /usr/share/java. This is meant > for build systems like Ant where you can easily add a symlink to your > package and reference the versionless jar file. That's fine if you want > to support this use case but it is not essential to get another package > working and it might even introduce unwanted side effects like [1]. I don't understand why the build system used by a project should affect the end user of said project. I am also not referring to the Debian's way of installing jar files into /usr/share/java. I am saying that users of library X in Debian should not need to figure out which are the dependencies of library X and add it to the java classpath themselves. For example, to make use of libfairsim in Python without having the classpath defined in the manifest file, a user will have to add the JlargeArrays, JTransforms, and commons-math3 jar files to the classpath. As if that was not bad enough, the user will need to figure out himself this list of dependencies. This is not limited to use java libraries in Python. It also happens in Octave. And it is also an issue in ImageJ which is a Java application where plugins are the jar files in its plugins directory. That's simply not usable. Maybe Class-Path is not an ideal solution but is there an alternative to it? >>> If you do it and >>> use jh_classpath or the *.classpath file then you must specify the >>> absolute path to the libraries otherwise they won't be found. >> >> Not true. The path can be relative to the directory of the jar file >> that contains the manifest file. > > Let me rephrase this. It is possible but bad practice. Don't assume that > your jar file is always in the same directory as your dependencies. The > only way to ensure that is to use an absolute path. > Why is that bad practice? Is that in case another package uses a symlink to the jar file and uses it instead? My experience is that even when there's symlinks involved, the Class-Path will be relative to directory of the real file. Even if the other packages make symlinks to the jar, it will still find the dependencies. Or is that to cover the case the user copies the file and uses it somewhere else? >>> I also suggest to remove the --has-package-version flag from the *.poms >>> files. There was a recent change in maven-debian-helper that >>> automatically adds a versioned dependency to reverse-dependencies if one >>> of their build-dependencies uses this flag. In my opinion in most cases >>> this is too strict and not what you probably wanted. >>> >>> Regarding your failing patch I'm not sure. It doesn't sound like it is >>> Java specific. You can send me your patch and I can take a look though. >>> >> >> Here is the patch [1]. When I build with this patch, quilt will make >> a copy of the original org.fairsim.fiji.FairSim_ImageJplugin package >> in `.pc/set-git-build-id.patch/org/fairsim/fiji/FairSim_ImageJplugin.java` >> This causes a duplicate class error because both the original and copy >> are found. > > I can reproduce your issue. This is related to upstream's unusual choice > of options in the pom.xml file. First of all I'm not sure why he won't > simply stick to the default Maven directory layout (src/main/...). Because he doesn't use or like maven. It's there only so that other people can make use of it but he uses the Makefile for himself. I can also understand why one would find the default maven directory layout too deep. > This > would solve your problem immediately. The issue here is that he uses > ./ which tells Maven to look into the > root of your build directory and then it detects the patched class in > the ~/.pc directory and the original class under org and fails. > > I would try to fix the build system (the pom.xml) but I don't have a > patch at hand at the moment. Perhaps someone else on the list knows a > better solution. > I have tried to change the build system already but I can't figure out the right maven magic to make it look only inside ".org" either. I think it may have to do with how debian-maven-helper is used. Note how I had to manually remove a java file from the source tree in `rules` [2] even though `pom.xml` should clearly exclude it [3]. Carnë [2] https://github.com/carandraug/debian-fairsim/blob/master/debian/rul
