Re: Gradle problems when building adql-java package
Hi Ole,
On 2023-12-08 13:03, Ole Streicher wrote:
I am trying to update the adql-java package to the newest upstream
(beta) version. As it is my first project using gradle, I sumbled upon a
number of problems:
One is that the plugin org.javacc.javacc is not available. I guess this
is because it is not packaged yet, right? My solution here is that I
call javacc in d/rules before running dh_auto_build; is this the way to
go?
After this, dh_auto_build completes, but the tests fail with
> Could not resolve junit:junit:4.13.1.
Required by:
project :ADQLLib
> No cached version of junit:junit:4.13.1 available for offline mode.
which is caused by
dependencies {
testImplementation 'junit:junit:4.13.1'
testImplementation 'org.slf4j:slf4j-simple:1.7.25'
}
in the main build.gradle (right?) junit4 is however a build dependency
(currently 4.13.2 in unstable). What should I do here? Are the versions
here minversions? Removing the complete dependency will cause junit4
classes missing in the test, also setting the CLASSPATH environment
variable doesn't help. What is the proper solution here?
I guess you could patch 'junit:junit:4.13.1' with 'junit:junit:4.x' to
avoid this overly strict dependency version checking.
In some projects I maintain I got fed up with gradle and switched to
plain jh_build. An example could be found in lucene9 [1]. I even found a
way to build and run tests, but I did not succeed in doing so for
lucene9, need to refresh my memory why.
[1] https://sources.debian.org/src/lucene9/9.4.2%2Bdfsg-2/debian/rules/
Hope this helps,
Andrius
antlr 4.10 released [Was: Re: packaging Go runtime for ANTLR4]
Hello, Some time ago there was a discussion about the need to coordinate uploads of antlr and its runtime packages, as in Debian they are split into several source packages across several teams: On 2021-07-29 10:09, Andrius Merkys wrote: > Maybe an antlr4 packaging team could be set up to coordinate > synchronized version bumps? antlr 4.10 has just been released. How should we proceed with packaging? What are the constrains? I maintain antlr4-cpp-runtime. I plan to upload updated package to experimental (needs to clear NEW) and wait for antlr 4.10 to appear in unstable. Best, Andrius
Re: maven-*-helper JAR placement seems to contradict Java policy
Hi Alexandre, On 2022-03-23 16:33, Alexandre Rossi wrote: > Seems to work: > > $ ls -la /usr/share/java/htmlcleaner* > lrwxrwxrwx 1 root root 15 18 mars 18:20 > /usr/share/java/htmlcleaner-2.26.jar -> htmlcleaner.jar > -rw-r--r-- 1 root root 176219 18 mars 18:20 /usr/share/java/htmlcleaner.jar > $ sudo dpkg -i > oss/debian/davmail/libhtmlcleaner-java_2.26-1+fix+bad+jar+name+1_all.deb > [...] > $ ls -la /usr/share/java/htmlcleaner* > -rw-r--r-- 1 root root 176219 23 mars 15:27 > /usr/share/java/htmlcleaner-2.26.jar > lrwxrwxrwx 1 root root 20 23 mars 15:27 > /usr/share/java/htmlcleaner.jar -> htmlcleaner-2.26.jar Many thanks for the proposed patch. It seems we need a decision now on which one is actually buggy: maven-debian-helper or java-policy. I would vote for upholding the java-policy if only the symlink placement switch does not break anything (neither reverse dependencies not the update mechanism). Having versionless symlinks parallels nicely lib*-dev shlib scheme and there might be situations where this is beneficial for Java too. Unluckily enough, there are >700 source packages now directly affected by this [1]. [1] https://lintian.debian.org/tags/bad-jar-name Best, Andrius
Re: maven-*-helper JAR placement seems to contradict Java policy
Hi, On 2021-10-18 10:31, Alexandre Rossi wrote: >>> Not sure though what is the impact of this policy inversion. Most of >>> Java-related software seems to read both regular files and symbolic >>> links transparently. >> >> There isn't much impact, both styles are fine in my opinion. > > This seems to trigger https://lintian.debian.org/tags/bad-jar-name Exactly. Thus lintian seems to follow the current Java policy and correctly emit warnings. I am trying to understand if this is a bug in maven-*-helper, or a result of overly strict policy. One of these should be changed. Best, Andrius
Bug#996727: ITP: ciftools-java -- Java library to read and write CIF files
Hi Pierre, On 2021-10-17 22:18, Pierre Gruet wrote: > * Package name: ciftools-java > Version : 3.0.0 > Upstream Author : Sebastian Bittrich > * URL : https://github.com/rcsb/ciftools-java > * License : Expat > Programming Lang: Java > Description : Java library to read and write CIF files Thanks for an interesting ITP. I am very interested in CIF parsers. Could you please add me as an uploader for ciftools-java next to yourself? Best, Andrius
Re: maven-*-helper JAR placement seems to contradict Java policy
Hi Markus, On 2021-10-15 14:34, Markus Koschany wrote: > Indeed, that looks like a bug in libcommons-lang3-java or rather maven-debian- > helper to me. I have just checked some other Maven packages and there the > policy is implemented correctly. The bug in libcommons-lang3-java could be > related to the relocation feature in the poms file but I haven't looked closer > yet. Thanks for giving it a look. However, it think that maven-debian-helper should not be placing files against the policy by default. I usually use mh_make for initial packaging, and now I see that most of my packages are violating MUST of a policy because of that. I took a quick look at my /usr/share/java, and these seems to be quite some packages with versionless JARs and versioned symbolic links [1], just to name a few (out of 125): libantlr3-runtime-java libcompress-lzf-java libhttpclient-java libmorfologik-stemming-java libsurefire-java Not sure though what is the impact of this policy inversion. Most of Java-related software seems to read both regular files and symbolic links transparently. [1] $ comm -1 -2 <(find /usr/share/java/ -type l | grep -P '[-][\.0-9]+\.jar$' | xargs -n1 dpkg -S | cut -d : -f 1 | sort) <(find /usr/share/java/ -type f | grep -P '[-][^\.0-9]+\.jar$' | xargs -n1 dpkg -S | cut -d : -f 1 | sort) | uniq Best, Andrius
maven-*-helper JAR placement seems to contradict Java policy
Hello,
Java policy on Java libraries (Ch. 2.4.) reads [1]:
Their classes must be in jar archive(s) in the directory /usr/
share/java, with the name packagename[-extraname]
-fullversion.jar. The extraname is optional and used internally
within the package to separate the different jars provided by the
package. The fullversion is the version of that jar file. In some
cases that is not the same as the package version.
Some package must also provide a symbolic link from
packagename-extraname.jar to the most compatible version of the
available packagename-extraname-version.jar files.
However, it seems that packages built with maven-{debian,repo}-helper
default settings contain the opposite: JAR archives are named
packagename-extraname.jar, and packagename-extraname-version.jar are
symbolic links to packagename-extraname.jar. For example see
libcommons-lang3-java.
This looks like a contradiction to me. Or am I just misreading the policy?
[1] /usr/share/doc/java-policy/debian-java-policy.txt.gz, java-policy 0.57
Best,
Andrius
Re: Old Gradle version
Hi, On 2021-09-15 00:59, Philippe De Neve wrote: > I was wondering why the Gradle version in buster/bullseye/bookworm/sid > is 4.4.1. Latest release is 7.2. Please see these bug reports for reference: https://bugs.debian.org/926714 https://bugs.debian.org/933264 Best, Andrius
Re: Divergence in salsa.debian.org/java-team/xom
Hi Sebastiaan,
On 2021-08-25 12:32, Sebastiaan Couwenberg wrote:
> Import the changes from the NMU:
>
> gbp import-dsc /tmp/xom_1.2.10-1.1.dsc
>
> Review the changes since -1:
>
> git diff debian/1.2.10-1{,.1} debian/
>
> Restore changes that were reverted by the NMU import.
Thanks, I will do as you have suggested.
Best,
Andrius
Divergence in salsa.debian.org/java-team/xom
Hello, I want to make an upload for xom package with a couple of fixes. I want to use its packaging repository on salsa [1], but it is in somewhat diverged state. The newest Debian version of xom is 1.2.10-1.1, but repository on salsa has 1.2.10-1 (note incorrect git tag) plus a pair of commits on top of that which are not included in 1.2.10-1.1. To fix the history on salsa these two commits have to be discarded and changes of 1.2.10-1.1 have to be applied on top of clean 1.2.10-1. However, I do not know how to do that without force-pushing (forbidden on a protected branch). Any ideas how to solve this? [1] https://salsa.debian.org/java-team/xom Best, Andrius
Re: packaging Go runtime for ANTLR4
Hello, Maintainer of antlr4-cpp-runtime here. On 2021-07-28 22:36, Nilesh Patra wrote: > 2) Do "$something-else" for all these packages to stay in sync - again, > probably bumping versions only when needed. > With this approach, I do not see a problem in introducing a Go runtime > source package there I was not aware of out-of-sync problem, thanks for pointing it out. Maybe an antlr4 packaging team could be set up to coordinate synchronized version bumps? Best, Andrius
Re: Java packages and autopkgtest
Hello, On 2020-12-07 18:52, Thorsten Glaser wrote: > On Tue, 8 Dec 2020, Roger Shimizu wrote: > >> do you have any suggestion on such case, the autopkgtest for java or >> just maven library pkg? > > Sorry but really none. Those packages I’ve seen so far only worked > because they disabled the tests anyway (mostly because the tests > would have required tons more dependencies). > > You’ll probably have to get maven to prepare the test resources and > compile the tests, but to not compile the rest, and to add the in‐ > stalled library instead to the classpath. But this probably involves > some advanced hackery or writing a Maven extension… Some time ago I embarked on the primitive hackery of Maven in order to develop a generic tool to support autopkgtests for Maven [1]. I managed to hack together a proof-of-concept implementation [2], which actually worked with some of Maven projects I tried. My idea was to disable the build of "all", remove the sources, patch the pom.xml to use system-provided JARs and run 'mvn' as debhelper would do. However, the more Maven projects I tested, the more complicated the autopkgtest runner grew, to the point I abandoned it. However, looking back it seems worth revisiting, and I would be very happy if someone would pick it up and turn it into something usable in Debian. At least for very simple Maven packages. Please see [1] for very valuable comments from Emmanuel Bourg. [1] https://salsa.debian.org/java-team/maven-debian-helper/-/merge_requests/2 [2] https://salsa.debian.org/merkys/maven-debian-helper/-/blob/autopkgtest-pkg-maven/share/maven-debian-helper/autopkgtest-runner Hope this helps, Andrius
Re: Building r-cran-rcdk with cdk [Was: Re: Upgrading freehep to latest upstream (needed by cdk and probably others)]
Hi Tony, On 2020-07-29 06:41, tony mancill wrote: > Fair enough... In the long run, it is likely that porting r-cran-rcdk > is a better use of time. However, I got interested in it and here is > the status so far: > > 1) I updated jgrapht0.6 to install a pom file and uploaded a new > package to unstable. Indeed, this prevented building the legacy pom. > 2) I updated the cdk source package to build-dep on the javacc maven > plugin and re-enabled the legacy pom. > > 3) I used ratt to build packages that build-depend on cdk. The > new package addresses the issue with r-cran-rcdk, but cinfony fails: > > 2020/07/28 20:27:10 PASSED: r-cran-rcdklibs > 2020/07/28 20:27:10 FAILED: cinfony (see buildlogs/cinfony_1.2-4) > > However, the cinfony failure on my system is for: > > unsat-dependency: python-indigo:amd64 > > And it also fails when built against cdk_2.3.134.g1bb9a64587-1, so I > don't think this is related to my change. cinfony has py2removal issues, I would say we can safely ignore it for now. > I created a merge request [1] so you can take a look. I'm happy to > prepare an upload if it looks okay to you. > [1] https://salsa.debian.org/java-team/cdk/-/merge_requests/4 The MR looks good to me. I posted a tiny suggestion to depend on jgrapht0.6 with a version to prevent well-known FTBFS. Otherwise it's good to go. Feel free to upload. Thanks a lot for looking into this! Andrius signature.asc Description: OpenPGP digital signature
Re: Building r-cran-rcdk with cdk [Was: Re: Upgrading freehep to latest upstream (needed by cdk and probably others)]
Hi Tony, On 2020-07-27 16:50, tony mancill wrote: > On Mon, Jul 27, 2020 at 08:51:49AM +0300, mer...@debian.org wrote: >> What is more, the subtree tool/smsd/ contains only pom.xml, what might >> be the reason of codeless jar. It seems to me that cdk-smsd is legacy >> now, and I would suggest asking the upstream for advice how to port code >> depending on it. > I still plan to take a look at what it would take to compile the > legacy/pom.xml. Sure, please do. However, I would not count too much on this pom, as it may get removed in the upcoming cdk releases. Best, Andrius signature.asc Description: OpenPGP digital signature
Building r-cran-rcdk with cdk [Was: Re: Upgrading freehep to latest upstream (needed by cdk and probably others)]
Hello, On 2020-07-27 08:38, tony mancill wrote: >> It actually seems that org/openscience/cdk/smsd/Isomorphism is not >> part of the currently packaged CDK. Any idea how to solve this? > I am just starting to take a look a this, but I think we need to spend > some more time with CDK. That class is found in the "legacy" directory > of the sources: > > ➜ cdk-2.3.134.g1bb9a64587 find . -name Isomorphism.java > ./legacy/src/main/java/org/openscience/cdk/smsd/Isomorphism.java > > But the legacy pom is ignored: > > > https://salsa.debian.org/java-team/cdk/-/blob/master/debian/libcdk-java.poms#L91 Indeed, cdk-smsd pom is ignored (I made that so). However, if I remove the '--ignore' instruction, the built jar is codeless: W: libcdk-java: codeless-jar usr/share/java/cdk-smsd.jar What is more, the subtree tool/smsd/ contains only pom.xml, what might be the reason of codeless jar. It seems to me that cdk-smsd is legacy now, and I would suggest asking the upstream for advice how to port code depending on it. Best, Andrius signature.asc Description: OpenPGP digital signature
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi Andreas, On 2020-07-23 17:55, Andreas Tille wrote: > Would you mind to update cdk package (which was the original issue > I stumbled upon freehep)? I have updated cdk yesterday. The cdk-depict module is built now. Best, Andrius
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hello, On 2020-07-22 22:00, Giovanni Mascellani wrote: > Thanks, I just pushed geogebra. Thanks! By the way, could you please also initiate removals of obsolete freehep source packages? They are the following: freehep-graphics2d freehep-graphicsio freehep-graphicsio-emf freehep-graphicsio-java freehep-graphicsio-pdf freehep-graphicsio-ps freehep-graphicsio-svg freehep-graphicsio-swf freehep-graphicsio-tests Best wishes, Andrius
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hello, On 2020-07-19 15:40, Giovanni Mascellani wrote: > I have no problem with your changes, but since merkys should be back > shortly we can leave it to him to do the upload. Once that is done, I > will push geogebra with the updated patches. I have uploaded freehep to unstable today, please go on with patching geogebra. cdk, however, will have to wait, as it currently FTBFSes in sid (#963435). Best, Andrius
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi, On 2020-07-10 15:59, Giovanni Mascellani wrote: > Great, then I revoke the intention of RMing geogebra and close the > corresponding bug. As soon as freehep-vectographics is available, I will > bump patches and dependencies on geogebra and everything should be find. Sure, I will ping you once freehep-vectographics clears the NEW queue. Best, Andrius
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi, On 2020-07-10 09:49, Giovanni Mascellani wrote: > There is no need for this step. I have already a patched version that > compiles with the new FreeHEP. The thing I ask you is to add this patch > to freehep-vectorgraphics: [snip] Glad to hear that, and thanks for the patch. I have added it to the packaging repository on salsa. I confirm that FreeHEP builds and passes tests with this patch. > Notice that this patch is harmless to other reverse dependencies of > freehep-vectorgraphics, because it makes a field available to > subclasses, but doesn't change the behavior for subclasses that don't > touch it. Noted. Best, Andrius
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hello, On 2020-07-02 18:40, Giovanni Mascellani wrote: > On second thought, it seems that it would not be too difficult to port > GeoGebra to the new FreeHEP, so maybe we can consider this a little bit > more carefully. I agree that porting GeoGebra is much better than removing it altogether. I would suggest the following course of action: * As soon as new FreeHEP is accepted to experimental, I initiate the appropriate transition. * As GeoGebra will FTBFS with the new FreeHEP, I will ask to remove the former from testing to complete the transition. * This way GeoGebra stays on sid, and anyone will be free to step up and port it to the new FreeHEP. What do you think? Best, Andrius
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi Andreas, On 2020-07-01 12:30, Andreas Tille wrote: > Thanks for this. I've added it to the COVID-19 relevant list of packages > in new[1] > [1] > https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/NEW-Requests > Thanks for doing so! Best, Andrius
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi, On 2020-07-01 10:46, Giovanni Mascellani wrote: > Sorry, I completely lost track of this thread. Here is the RM bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964070 Thanks a lot for the information. I have uploaded freehep-vectorgraphics to experimental, waiting for it to clear NEW. Best, Andrius
Re: Help to detect java classes in drop-seq (covid-19 relevant) needed
Hi Andreas, On 2020-05-20 14:20, Andreas Tille wrote: > Any hint how to take this hurdle would be welcome. Try setting the CLASSPATH in your d/rules like this: export CLASSPATH := $(DEBJAR)/htsjdk.jar:$(DEBJAR)/picard.jar:$(DEBJAR)/commons-collections4.jar I did this in one of packages and it seemed to work. Hope this helps, Andrius
Re: Looking for advice about json-simple 3 transition
On 2020-05-14 11:27, Gilles Filippini wrote: > I think I could try this indeed. Would a versioned 'Breaks' field > listing the few reverse dependencies be useful then? No, this is not needed, libsimple-json-java upload for v3.0.0 shouldn't be any different from the other uploads. However, please explain the situation in transition bug report prior to uploading libsimple-json-java v3.0.0 to unstable. There might be other gotchas, thus it's better to ask for release team guidance. Best, Andrius signature.asc Description: OpenPGP digital signature
Re: Looking for advice about json-simple 3 transition
Hello, On 2020-05-14 10:07, Gilles Filippini wrote: > I won't maintain 2 source packages. The deprecated one (version 2.x) > should be dropped. The 'Conflicts' field is needed during the transition > only. The new package would have: > * 'json-simple' as source package name (unchanged) > * 'libjson-simple3-java' as binary java package name, conflicting with > previous one 'libjson-simple-java' > * 'libjson-simple-doc' as documentation package name (unchanged). Got it. I assume you need a different binary package name just for the transition. However, this seems avoidable as well. The following Ben tracker seems sufficient for me: Affected: .depends ~ /\blibjson-simple-java\b/ Good: .depends ~ /\blibjson-simple-java\b/ >= "3.0" This way all reverse dependencies will be listed as affected, but only the ones that explicitly say that they depend on json-simple-java >= 3.0 will be treated as already migrated ones. Hope this helps, Andrius signature.asc Description: OpenPGP digital signature
Re: Looking for advice about json-simple 3 transition
Hello, On 2020-05-13 16:46, Gilles Filippini wrote: > I'd like to push json-simple 3.1.1 into unstable, but I'm not sure how I > should handle the transition. The 3.x releases are not backward > compatible with 2.x. > > A whole set of deprecated classes has been removed: >> * Deprecated JSONParse and JSONValue in favor of Jsoner. >> * Deprecated JSONStreamAware and JSONAware in favor of Jsonable. >> * Deprecated JSONObject in favor of JsonObject. >> * Deprecated JSONArray in favor of JsonArray. Maybe it wouldn't be too difficult to patch the dependencies to work with 3.x release? There are ~15 source packages, so I'd say it should be doable provided the API changes are not too drastic. This would allow to retain the same binary package name. > I think about renaming the binary package to libjson-simple1-java but > keeping the jar file name as json-simple.jar. It implies setting > Conflicts: libjson-simple-java. Name libjson-simple3-java would be better, as it reflects the upstream version. However, I would recommend against having conflicting JAR names, as this would effectively forbid coexistence of packages depending on different versions of json-simple. If having both v2 and v3 JARs could not be avoided, I'd suggest providing /usr/share/java/json-simple-2.x.jar in libjson-simple-java and /usr/share/java/json-simple-3.x.jar in libjson-simple3-java. Packages junit [1] and junit4 [2] are made to coexist in a similar manner. [1] https://packages.debian.org/sid/all/junit/filelist [2] https://packages.debian.org/sid/all/junit4/filelist Hope this helps, Andrius signature.asc Description: OpenPGP digital signature
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi Giovanni, On 2020-04-21 10:40, Giovanni Mascellani wrote: > So I have no problems in removing GeoGebra to allow FreeHEP to be > updated (maybe it turns out that GeoGebra also works with FreeHEP's new > version, but I believe it is unlikely), but then at the same time I give > up as FreeHEP maintainer, because I would have no interest any more in > it. I don't know what other rev deps of current FreeHEP need, though. I have successfully tested rebuilding of FreeHEP reverse dependencies [1]. All but GeoGebra builds fine with FreeHEP 2.4. So if you are really OK with having GeoGebra removed, could you please file the removal request? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956845 Best wishes, Andrius
Re: [covid-19] Gradle help for nextflow needed
Hi Andreas, On 2020-04-30 15:27, Andreas Tille wrote: > I wonder whether this fits into Debian packaging policy at all and > whether I need to avoid this in favour of packaging proper JARs? I believe it is the latter. Capsules seem to embed all their dependencies, and this is something to avoid. Best wishes, Andrius
Re: [covid-19] Gradle help for nextflow needed
Hi Andreas,
On 2020-04-28 12:05, Andreas Tille wrote:
> Any help for a kickstart would be really appreciated.
I have almost no idea what nexus-staging plugin does, but it may be not
essential for building the package. You can try to patch it out by
removing the following lines from build.gradle:
8<
plugins {
id "io.codearte.nexus-staging" version "0.21.2"
}
8<
and
8<
nexusStaging {
packageGroup = 'io.nextflow'
delayBetweenRetriesInMillis = 10_000
}
8<
Hope this helps,
Andrius
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hello, On 2020-04-21 10:40, Giovanni Mascellani wrote: > So I have no problems in removing GeoGebra to allow FreeHEP to be > updated (maybe it turns out that GeoGebra also works with FreeHEP's new > version, but I believe it is unlikely), but then at the same time I give > up as FreeHEP maintainer, because I would have no interest any more in > it. I don't know what other rev deps of current FreeHEP need, though. GeoGebra fails to build with FreeHEP v2.4 due to missing EMFPlusGraphics2D class. After patching it out, I ran into other incompatibilities – GeoGebra seems to require patching FreeHEP source, and that is not nice. Apart from GeoGebra, scilab and sweethome3d are the only source packages depending on FreeHEP. I have not yet tested building them with FreeHEP v2.4, but will do that. If that succeeds, maybe GeoGebra could be indeed removed to make way for new FreeHEP. Best wishes, Andrius
Re: Upgrading freehep to latest upstream (needed by cdk and probably others)
Hi Andreas, On 2020-04-15 15:53, Andreas Tille wrote: > This made me wonder about the status of the freehep-* packages that did > not had a new upload since the move from Alioth. It seems the new version > of freehep can be found at > > https://github.com/freehep > > and the structure of the classes has changed a bit (like > freehep-graphicsio is now freehep-vectorgraphics). I wonder whether > we should follow upstream freehep to support recent software. Some time ago I had attempted packaging new freehep-vectorgraphics, with considerable success. However, I dropped the ball and did not upload it. I have pushed my packaging to salsa [1]. There is one issue, though. Old freehep-* JARs are split into multitude of source and binary packages, while my packaging uses single source package (I find it more convenient than splitting and linking) and currently puts all the JARs in one binary package. One of the following options has to be chosen: 1. Have only one binary package. This would have to replace all old binary packages with Conflicts+Replaces. 2. Split JARs to resemble old binary packages. AFAIK, this would require epoch (1:) for the new binary packages, as they would come from different source package. I would probably go with the option 2. Best, Andrius [1] https://salsa.debian.org/java-team/freehep-vectorgraphics
Re: Help needed to upgrade cdk
Hi Egon, On 2019-12-31 16:02, Egon Willighagen wrote: > I saw that CDK 2.3 is now in unstable! Great news! Many thanks for > your time during the BioHackathon, and others for their effort to make > this happen. Very much appreciated. Yes, it's finally in! :) Hope to get the CDK's depiction part working in near future. Happy New Year! Andrius
Re: freehep-graphicsio update
Hello, On 2019-11-23 12:30, Giovanni Mascellani wrote: > I am not against this, but I think I would happily give away maintenance > of these packages. I never used them directly, just needed them as > GeoGebra dependencies. > > That said, before updating I would suggest to consider exactly what does > one expects from these packages: do we consider them useful in Debian in > themselves, or do we value them just as reverse dependencies (of > GeoGebra and figtree)? Personally, I don't think they have much value by > themselves; they are unmaintained upstream anyway and I doubt they are > the best Java library for exporting images. Also, the average Java > programmer is more probably going to use them from Maven, Gradle or > whatever dependencies management tool happens to be à la page that month. I totally agree with you. I've stumbled upon a package depending on freehep-graphicsio, thus I'm inquiring about its status. > As of using them as dependencies, I think upgrading needs some care: > vectorgraphics has been developed in a very discontinuous way lately, > and I believe it could have introduced a lot of API breakages. I think > that at least one package already has GeoGebra-specific patches, because > unfortunately that's how things happen in the Java ecosystem. So I would > suggest whoever wants to upgrade the packages to check carefully that > upgrading is not introducing bugs in GeoGebra and figtree. > > These are the reasons why, in the end, I never decided to upgrade. YMMV, > and in this case no problem upgrading the packages, especially if you > can also take maintenance. But please check carefully you are not > breaking rev deps. This sounds tedious. We may end up patching geogebra, figtree and sweethome3d to accommodate the API changes. I'll talk to the upstream about the possibility to use different software to generate images. Thanks, Andrius
freehep-graphicsio update
Hello, New version of freehep-graphicsio is out (in 2014 [1]), and I would like to see it packaged. However, packaging of freehep-graphicsio is split in a dozen of source packages, and update maintaining this split would be tedious. Maybe merging the source packages (retaining the upstream tarball integrity) would make sense? [1] https://github.com/freehep/freehep-vectorgraphics/releases Best, Andrius
Re: Help needed to upgrade cdk
Hi Egon, On 2019-11-21 11:27, Egon Willighagen wrote: > Awesome! Plz let me know if I can answer any questions around > dependencies, or impact of missing dependencies. I have made it to a successful cdk build today! I had to exclude three artifacts due to compilation problems (mostly dependencies missing in Debian): storage/iordf/pom.xml legacy/pom.xml app/depict/pom.xml Depict depends on freehep-graphicsio-* which need updates in Debian. I gave these packages a quick glance, but I ran into problems with getting their source, so I gave up for now. Somewhy some built non-test jars of cdk ended up codeless after the build: W: libcdk-java: codeless-jar usr/share/java/cdk-annotation.jar W: libcdk-java: codeless-jar usr/share/java/cdk-bundle.jar W: libcdk-java: codeless-jar usr/share/java/cdk-ionpot.jar W: libcdk-java: codeless-jar usr/share/java/cdk-qm.jar W: libcdk-java: codeless-jar usr/share/java/cdk-qsarionpot.jar W: libcdk-java: codeless-jar usr/share/java/cdk-smsd.jar I will investigate the reason a bit later. Best, Andrius
Re: Help needed to upgrade cdk
Hi Andreas, On Wed, 20 Nov 2019, 22:19 Andreas Tille, wrote: > I have no idea what restrictions the lack of cmlxom might imply. > I have packaged and uploaded cmlxom today. Will do so with the rest of dependencies. Would you take over and upload your changes? If not please push and > let me know if some further work might be needed. > I can take it for now. I will keep you updated. Best wishes, Andrius
Re: Help needed to upgrade cdk
Hi, I have managed to get around the most of the build problems. However, a lot of the artifacts depend (transitively) on org.xml-cml.cmlxom, which is not packaged yet. For the time being I can skip these artifacts, but in the long run it would be great to have cmlxom packaged. Best, Andrius
Re: Help needed to upgrade cdk
Hi, On 2019-11-19 19:40, Andreas Tille wrote: > I've sat together with Egon Willighagen who is member of CDK upstream > team to update the cdk package[1]. So far the switch from ant to maven > seems to have basically succeeded. However, for some reason it does not > build modules in the correct sequence and thus we are running into: [...] The build failure is indeed caused by inability to establish the correct ordering of artifacts in Debian build (not sure why this happens). I usually solve such problems manually. Ignoring cdk-test gets the build process a little further, but there are still dependencies to disentangle. I will give it a look. Best wishes, Andrius
Java packages and autopkgtest
Hello, Java Team's page [1] states that some help/information is needed regarding the autopkgtest. I haven't seen much Java packages having autopkgtests, but to me it seems possible at least for packages using maven-debian-helper. Maybe there are gotchas that I am not aware of? Workflow of an autopkgtest as I see it: 1. Remove the sources of the package, but leave tests (i.e. 'rm -f src/main'); 2. Patch POMs to make tests depend on built artifacts; 3. Run the Debian package build process as usual, omitting the dh_auto_build step. I have tested this workflow manually for a simple package, and it seemed to work. Such autopkgtest would help to detect breaking changes in dependencies at least. I assume this could be automated into something like autopkgtest-pkg-maven or like. Any thoughts? Andrius [1] https://wiki.debian.org/Java/Packaging#autopkgtest
dependencies.dependency.version is missing in pom.xml
Hi all, Recently I have ran into maven-built package with POMs lacking '...' properties for its dependencies. This however seems to fail the build process: [ERROR] [ERROR] Some problems were encountered while processing the POMs: [ERROR] 'dependencies.dependency.version' for junit:junit:jar is missing. @ line 121, column 15 I don't know much about POMs, so my first question is: Is this allowed/usual? I have managed to get around the problem by patching the POMs by adding 'debian'. Maybe there is a better way to deal with such cases? If not, could the mh_patchpoms be modified to add 'debian' where they are missing? Best, Andrius
Re: Status of sbt package
Hi Thomas, I have managed to get around Scala FTBFS problem [1] for now, will continue looking into your script. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941211 On 2019-09-27 02:07, Thomas Finneid wrote: > 1- The scala library depenencies are hardcoded, so it doesnt find the > correct version of them, Still it compiles, which is wierd, but wont > run, mostlikely because of an AbstractMethodException or something > similar. Its a bootclasspath issue again. > 2- The external dependencies are not met, in this case jline. jline v2.14.6 is in Debian as libjline2-java, wouldn't this work? By the way, how are the jars under $BUILDMODULEPATH built? Best wishes, Andrius
Re: Status of sbt package
Hi Thomas, On 2019-09-25 23:03, Thomas Finneid wrote: > Sorry for the delay in answering, I'm on daddy-leave so time is > scarce. (and sorry for the long mail... :) ) Thank you for finding some time to contribute to packaging Scala/sbt! :) > I have some more good news :) After battling with my own and other > demons I have managed to create a shell script for compiling Scala > 2.12.0-M1. The experiences from that can probably be used to create a > similar script for Sbt. Fantastic! > You can have a look at what I have done at > > https://bitbucket.org/tfinneid/scala-build-process/src/default/build-2.12.0-M1.sh > I have cloned your repo and started playing around. AFAIK, your build script requires jars built from earlier version of Scala (akka-actor.jar and friends). Thus I've tried building Scala and ran into a FTBFS [1]. I will have to figure it out before moving to Scala 2.12.0-M1. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941211 > I think one of the bigger issues for creating a working sbt debian > package is: > - sbt downloads the projects correct sbt version and other > dependencies and compiles the compiler interface for the correct scala > version before making the project available on sbt command line > - Setting that up correctly for the installed package, might not be > as easy as one thinks. > - I experienced some problems with that when testing the existing > sbt package in debian on a minor test project I created. > - I found that project dependencies was only retrieved from local > files installed by the package, not from the network as it should > (this applies to the completed and installed binary package, not the > building of the package > - other than that sbt external build dependencies must either exist as > jar files in debian or be created as separate packages (or included as > a separate pre-compile step in the sbt build script. > > Also, check what version of the jvm Sbt was originally built with. > Scala 2.12 is built using Java 8 and hence only properly compatible > with that. Scala 2.12.10 (at least) and 2.13 supports jdk11, but its > still built with jdk8 (not target argument, but actual jdk8 release). Ack. > sbt 0.13 is required for Scala 2.12, while sbt 1.0 is required for > Scala 2.13 builds. I dont know if that is important information yet, > it depends on the strategy for moving forward. However, this strategy is for the time being tedious due to sbt not migrating to testing. Otherwise it would sound really tempting. Many thanks for sharing your scripts and experience! I will let you know as soon as I manage to build Scala 2.12.0-M1. Best wishes, Andrius
Re: Status of sbt package
Hi Frédéric and Thomas, Sorry for the delay. I must admit I wasn't aware the dogfooding problem is so difficult to avoid. On 2019-08-17 07:53, Thomas Finneid wrote: > The good news is that after talking with some of the maintainers of > Sbt and Scala, they would be very interrested in getting a script that > could build Sbt or Scala from command line, using just Java and similr > tools. This solution sounds the best. Do you know whether the upstream would be willing to help with writing and maintaining such a script? Building sbt from 0.13.13 incrementally would be an option too, should the previous one fail. However, to build sbt incrementally one would probably need to demote its dependencies to make them compatible with this ancient version of source. Not sure where to start, though. Thanks for sharing your experience. Best, Andrius
Re: Status of sbt package
On 2019-08-08 17:48, Emmanuel Bourg wrote: > I don't think there is a repository yet. I've just created an empty one > on Salsa if that helps. Thanks - I'll push once I have something. Best, Andrius
Re: Status of sbt package
Hi Emmanuel, On 2019-08-08 10:33, Emmanuel Bourg wrote: > sbt is in sid but hasn't been bootstrapped properly yet, it still uses > libraries not built from sources. Nobody is actively working on it, feel > free to give it a try. Thanks, I'll give it a look. By the way, the source package does not have VCS-* fields, neither it is on Salsa. Do you know where its packaging repository is? Best wishes, Andrius signature.asc Description: OpenPGP digital signature
Status of sbt package
Hello, I am writing regarding the status of sbt Debian package. Version 0.13.13 is in sid, but it had never entered testing. Version 1.3.0-RC3 has already been released, are there any plans to update the package? If not, I would be willing to try my luck. Best wishes, Andrius
Re: [OT] Cannot use the Java offline utility given at https://www.incometaxindiaefiling.gov.in/downloads/offlineUtilities?lang=eng
Dear Shirish, On 2019-04-17 10:19, shirish शिरीष wrote: > ~/Documents/ITR-1_2019_170419$ jar -tvf ITR-1_AY201920_PR1.jar | grep > ThreeRedLightsIlluminate > 1699 Mon Apr 15 19:26:26 IST 2019 > com/itd/efiling/offline/common/player/ctrl/ThreeRedLightsIlluminate$1.class > 3599 Mon Apr 15 19:26:26 IST 2019 > com/itd/efiling/offline/common/player/ctrl/ThreeRedLightsIlluminate.class OK, my wild guess did not work here. I hope someone with more experience in Java could help you. Best wishes, Andrius
Re: [OT] Cannot use the Java offline utility given at https://www.incometaxindiaefiling.gov.in/downloads/offlineUtilities?lang=eng
On 2019-04-17 09:52, shirish शिरीष wrote: > ~/Documents/ITR-1_2019_170419$ cat ITR.sh > java -jar ITR-1_AY201920_PR1.jar OK, this means that all required classes should be there in the JAR file. Could you check what does 'jar -tvf ITR-1_AY201920_PR1.jar | grep ThreeRedLightsIlluminate' say? Best, Andrius
Re: [OT] Cannot use the Java offline utility given at https://www.incometaxindiaefiling.gov.in/downloads/offlineUtilities?lang=eng
Hello, On 2019-04-17 09:35, shirish शिरीष wrote: > I don't think it's just an openjdk issue, it's probably something to > do with the class as it shows - > > com.itd.efiling.offline.common.player.ctrl.ThreeRedLightsIlluminate to me this looks like a problem with the CLASSPATH. Does ThreeRedLightsIlluminate.java come with the downloaded ZIP file? Is there any CLASSPATH setting (might be using '-cp' option to Java call) in the ITR.sh? Best, Andrius
Re: Request to join Debian Java Packaging Project
On 2019-04-01 17:37, Emmanuel Bourg wrote: > Also, don't forget to use the repository creation script [1], it ensures > all the Java Team repositories are configured the same way. Yes, I've noticed this requirement on project's page on Salsa. Thanks for reminding. Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Request to join Debian Java Packaging Project
Dear Markus, On 2019-04-01 16:39, Markus Koschany wrote: > You just needed the "maintainer" status. I've granted it a minute ago. > Welcome on board! Thanks a lot for adding me! Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania signature.asc Description: OpenPGP digital signature
Request to join Debian Java Packaging Project
Hello, I have recently been granted Developer rights in Debian Java Project on Salsa (as 'merkys'). However, I am unable to create new repositories there, and I am willing to upload a couple of new packages. Are there additional requirements for repo creation rights? I have read and I accept the project rules [1]. Best wishes, Andrius [1] https://java.debian.net/developers.html -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Help needed with morfologik
Hi Andrej, On 2018-12-30 02:57, Andrej Shadura wrote: > You can find the source here: > https://salsa.debian.org/java-team/morfologik-stemming the packaging repository lacks pristine-tar branch, is this intentional? Also, 'make -f debian/rules get-orig-source' fails with: uscan --download-version 1.9.0+dfsg --force-download --rename uscan warn: In debian/watch no matching hrefs for version 1.9.0+dfsg in watch line https://github.com/morfologik/morfologik-stemming/releases .*/archive/(.*)\.tar\.gz make: *** [debian/rules:10: get-orig-source] Error 1 Do you have any ideas how to fix this? I would like to investigate the issue myself, but cannot figure out how to get to the build. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Help needed with morfologik
Hi, On 2019-01-02 09:31, Andrej Shadura wrote: > In fact, > just to build the package, you don’t need the tarball, you can > `fakeroot debian/rules clean binary` directly. ah, indeed, I need only this part. With package libmorfologik-stemming-java installed I was able to reproduce your problem. After removing libmorfologik-stemming-java I have run into the same interdependency issue as mine: [ERROR] Failed to execute goal on project morfologik-fsa-builders: Could not resolve dependencies for project org.carrot2:morfologik-fsa-builders:bundle:2.1.5: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.carrot2:morfologik-fsa:jar:debian has not been downloaded from it before. -> [Help 1] I manage to get past this by manually linking morfologik-fsa POM and JAR into debian/maven-repo before running 'fakeroot debian/rules binary': andrius@amalas:~/debian-packages/morfologik-stemming$ ls -l debian/maven-repo/org/carrot2/morfologik-fsa/debian/ total 4 lrwxrwxrwx 1 andrius andrius 64 Jan 2 03:18 morfologik-fsa-debian.jar -> ../../../../../../morfologik-fsa/target/morfologik-fsa-2.1.5.jar lrwxrwxrwx 1 andrius andrius 40 Jan 2 03:17 morfologik-fsa-debian.pom -> ../../../../../../morfologik-fsa/pom.xml Thus this might be used to solve the interdependency problem. However, this method looks more like a hack and I expect maven-debian-helper to have some built-ins for this. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: java: building interdependent artifacts with maven
Hi Andrej, I have seen your e-mail regarding morfologik, but I am not sure whether our issues are the same, though. In my case if I install the built opennlp-tools binary deb package, I am later able to build it with the opennlp-morfologik-addon successfully. (I could of course split them into separate source packages, but I wonder if there is a way to avoid it.) Have you tried building without morfologik-fsa-builders and installing built binary before build with morfologik-fsa-builders? Best, Andrius On Sun, 30 Dec 2018, 11:45 Andrej Shadura Hi Andrius, > > On Wed, 12 Dec 2018 at 10:30, Andrius Merkys > wrote: > > I am preparing a package for apache-opennlp [1]. Building it results in > six artifacts, one of them, > org.apache.opennlp:opennlp-morfologik-addon:jar:1.9.0, depends on another > artifact org.apache.opennlp:opennlp-tools:jar:debian which is built before > the former. However, opennlp-tools is not found by > opennlp-morfologik-addon, possibly because it is not installed in local > maven-repo, nor placed in CLASSPATH: > > > > [ERROR] Failed to execute goal on project opennlp-morfologik-addon: > Could not resolve dependencies for project > org.apache.opennlp:opennlp-morfologik-addon:jar:1.9.0: Cannot access > apache.snapshots (http://repository.apache.org/snapshots) in offline mode > and the artifact org.apache.opennlp:opennlp-tools:jar:debian has not been > downloaded from it before. -> [Help 1] > > > > Is there a standard way to deal with such problem? > > I also ran into this issue trying to update morfologik itself, and I > have so far been unable to find a solution. > > -- > Cheers, > Andrej >
Re: Now we have antlr 4.6 - any chance to get 4.7 soon (Was: beast-mcmc2: Cannot find symbol CharStreams.fromString(newick))
On 10/24/18 1:40 PM, Emmanuel Bourg wrote: > I've uploaded mojo-executor and string-template-maven-plugin, they are > awaiting in the NEW queue for the FTP masters approval. Thanks a lot > Andrius. Many thanks for reviewing and uploading the packages! Best, Andrius
Re: Now we have antlr 4.6 - any chance to get 4.7 soon (Was: beast-mcmc2: Cannot find symbol CharStreams.fromString(newick))
Hi Andreas, On 2018-10-16 17:03, Andreas Tille wrote: > Very good. Let me know if I could be of any help (which basically would > boil down to testing and if needed sponsoring). updating antlr4 to 4.7 requires two new Debian packages, libmojo-executor-java (ITP #911286) and libstring-template-maven-plugin-java (ITP #911302). I have pushed their packaging to Salsa: * https://salsa.debian.org/merkys-guest/mojo-executor * https://salsa.debian.org/merkys-guest/string-template-maven-plugin (build-depends on libmojo-executor-java) It would be great if you could review and, if possible, sponsor them. Meanwhile I will work on splitting antlr4 Java and Cpp source packages, as suggested by Emmanuel in #911371. Best wishes, Andrius [#911286] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911286 [#911302] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911302 [#911371] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911371 -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Now we have antlr 4.6 - any chance to get 4.7 soon (Was: beast-mcmc2: Cannot find symbol CharStreams.fromString(newick))
Hi Andreas, On 10/16/18 5:03 PM, Andreas Tille wrote: > Very good. Let me know if I could be of any help (which basically would > boil down to testing and if needed sponsoring). Many thanks! I will turn to you once I get the updated package build. > Interesting. You might like to join the Debian Med sprint in March 2019 > which will happen in Vilnius[1] (no better details yet). Thanks, I will be there. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Now we have antlr 4.6 - any chance to get 4.7 soon (Was: beast-mcmc2: Cannot find symbol CharStreams.fromString(newick))
Hi Andreas, On 10/15/2018 12:54 PM, Andreas Tille wrote: > when I tried last time we had antlr 4.5. I now tried with 4.6 but it > seems 4.7 is really needed. Any chance to get this soon? I am interested in packaging antlr 4.7 (with Cpp support, needed for #902798), I am working on it right now. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
