Re: jmol: diff for NMU version 12.2.32+dfsg2-1.1
+Vincent, the jalview maintainer Andreas Tille: > On Sat, Dec 10, 2016 at 03:37:00PM +, Ximin Luo wrote: >> [..] >> >> That depends on what DebiChem, Debian Med, and the Debian Java Team >> collectively want. >> >> jmol has three reverse dependencies. The new upload, jmol 14, breaks all of >> them. >> >> - biojava3-live can feasibly be dropped from Debian. > > I have asked Olivier about this. > >> - biojava4-live is currently being worked on by the upstream developer. >> We're waiting to hear back from them. > > Olivier has just uploaded a recent BioJava 4 version. I think this one > should be kept in Debian in any case. > >> - jalview's current version doesn't work with jmol 14, but the new version >> does. I started packaging it, but it adds several other dependencies not in >> Debian. Most of them seem bio related: > > From my *personal* and *uneducated* view its better to have a recent > Jmol than an outdated Jalview. While having also an updated Jalview > would be the optimal approach I'm not sure (in other words I doubt) > whether we will manage to package the missing dependencies: > >> https://anonscm.debian.org/cgit/pkg-java/jalview.git/tree/debian/TODO >> >> fr.orsay.lri.varna.* >> htsjdk.samtools.* > > This should be inside the libhtsjdk-java package. > >> org.biodas.jdas.* >> org.jfree.graphics2d.svg.* >> >From popcon: 600 https://qa.debian.org/popcon.php?package=jmol 300 https://qa.debian.org/popcon.php?package=jalview 70 https://qa.debian.org/popcon.php?package=biojava4-live 90 https://qa.debian.org/popcon.php?package=biojava3-live >> So we have a few options: >> >> 1. Keep everything old in Debian, and SageMath out of Debian stable. > > No. > Thanks for this input, I also feel it doesn't make sense to add software that is already 4 years old to Debian stable, where newer versions exist. They will be 6 years old by the time a new stable comes out, the value to users would be very low. >> 2. Update Jmol in Debian, with a chance of SageMath entering Debian stable, >> but drop biojava4 and jalview from Debian stable. (They can remain broken in >> unstable, with a chance of fixing them later, ofc) >> 3. Update Jmol in Debian, and update biojava4 and jalview as well. > > 4. Update Jmol in Debian, and update biojava4 and drop outdated jalview >(by at least starting the new dependencies and trying to upgrade >jalview) and have the chance of SageMath entering Debian stable. > >> If I work on (3) I don't think I will have any time to properly work on (2), >> but that is where my main personal interest lies. I'm also wondering what >> you all prefer, too. > > May be 4 is a sensible compromise if we could live with backporting > the latest version of Jalview later. > I agree and I'll be happy to move forward on this. Reminding everyone of the release schedule: https://lists.debian.org/debian-devel-announce/2016/11/msg2.html - The deadline for packages-in-testing to be updated by a newer unstable version is ~Jan 25 - The deadline for new packages to enter testing, is ~Dec 25. - This includes packages that are in unstable, that were/will removed from testing for QA reasons. (e.g. Jmol 12) - This also includes time passing through the NEW queue, for new packages. In summary: - Jmol 14 must be uploaded to unstable by ~Dec 25 - biojava4, jalview must be uploaded to unstable by ~Jan 25 - jalview's extra dependencies must be uploaded to unstable (NEW) by ~Dec 20 or ideally earlier, to give FTP masters a few days to process it. So it's much harder to make this work for jalview. Apologies in advance to any jalview Debian stable users that might be reading this. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Re: [Debian-science-sagemath] jmol: diff for NMU version 12.2.32+dfsg2-1.1
Ximin Luo: > Andreas Tille: >> 4. Update Jmol in Debian, and update biojava4 and drop outdated jalview >>(by at least starting the new dependencies and trying to upgrade >>jalview) and have the chance of SageMath entering Debian stable. >> >> [..] > > I agree and I'll be happy to move forward on this. Reminding everyone of the > release schedule: > https://lists.debian.org/debian-devel-announce/2016/11/msg2.html > > - The deadline for packages-in-testing to be updated by a newer unstable > version is ~Jan 25 > - The deadline for new packages to enter testing, is ~Dec 25. > - This includes packages that are in unstable, that were/will removed from > testing for QA reasons. (e.g. Jmol 12) > - This also includes time passing through the NEW queue, for new packages. > > In summary: > > - Jmol 14 must be uploaded to unstable by ~Dec 25 > - biojava4, jalview must be uploaded to unstable by ~Jan 25 > - jalview's extra dependencies must be uploaded to unstable (NEW) by ~Dec 20 > or ideally earlier, to give FTP masters a few days to process it. > Actually, we will have to upload Jmol 14 earlier, in order to "activate" the Jan 25 deadline for biojava4. This is because biojava4 is also QA-scheduled to be removed on Jan 4 (because of buggy-deps Jmol https://udd.debian.org/cgi-bin/autoremovals.cgi) So we'd have to upload it on Dec 22 or earlier, to give some time for biojava4's AUTORM flag to get cancelled. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Re: Packing a new Java package
Hi, mh_make is not supposed to use the jar files in the subdirectories of your project. If your project depends on additional jar files, those need to be provided by other packages. A lot of them are already packaged, but you need to install those, before running mh_make. If there are unpackaged dependencies you need to package those first. >From the mh_make man page To have mh_make working properly, you need first to install on your system as many dependencies for your project as possible. Those dependencies should also contain the required Maven metadata (POM files and jars in the /usr/share/maven-repo repository) Note, that some dependencies might be ok to be ignored (e.g. code metrics). To get more insight into packaging you should take a look at some package which use maven-debian-helper. You can get a list by first installing ubuntu-dev-tools and then running reverse-depends -b maven-debian-helper Regards Benjamin On Sat, 2016-12-10 at 13:37 +0100, 1...@gmx.us wrote: > Hi, > > How can I link jar files that are in a sub-directory of the project > to mh_make? > > I keep on getting "This dependency cannot be found in the Debian > Maven > repository. Ignore this dependency?" messages. > > Thanks, > nkr > -- Please do not send any email to ben...@gmx.net -- all email not originating from the mailing list will be deleted. Use the reply to address instead.
Please upload freeplane-1.5.18-1
hello Debian-Java, could someone please upload freeplane-1.5.18-1 from git? https://anonscm.debian.org/cgit/pkg-java/freeplane.git It's a new upstream release (and probably the last for stretch). Many Thanks and Best Regards, -- Felix Natter
Re: JavaCC update
Hi, I have prepared a javacc 6.1.3 package and recompiled some of its dependencies. So far three packages fail to compile (there are probably more): * css-parser * lucene-solr * lucene2 All three packages are a couple of years behind the latest upstream version. Is there an easy way to autobuild the reverse-depends of a package to test the other packages? Something like a buildd light? The only reverse-build-dep of cssparser (libcssparser-java) is htmlunit (libhtmlunit-java) which apparently has no reverse-build-dep/reverse- deps and a low popcon, so it could probably removed. In contrast lucene-solr is used quite a bit and lucene2 is a reverse- build-dep of eclipse. Probably more recent upstream versions would work fine with javacc6, but packaging those and updating their rdepends seems like a major undertaking. I now see several options: * update javacc to 6 and create a javacc5 package, patching all the packages which do not compile with 6.1.3 (requires a team effort) * update javacc to 6.1.3 and upload to experimental, filing FTBS bugs against the packages which do not build * create a javacc6 package to be used by those packages requiring javacc6 I have no experience in library transitions so guidance on the best/recommended way would be appreciated. Since my only reason for updating javacc in the first place was to update umlet (popcon: installs 829, 0.43%), there is no need to do any of this before stretch. Here is the list of packages I have built against 6.1.3 so far. Build Tested application * cdk pass * cssparser fail * javacc-maven-plugin pass * jing-trang pass * ognl pass * olap4j * surefire * svgsalamander * alter-sequence-alignment * bsh pass
Re: Please upload freeplane-1.5.18-1
On 11.12.2016 14:42, Felix Natter wrote: > hello Debian-Java, > > could someone please upload freeplane-1.5.18-1 from git? > https://anonscm.debian.org/cgit/pkg-java/freeplane.git > > It's a new upstream release (and probably the last for stretch). > > Many Thanks and Best Regards, > Uploaded. Cheers signature.asc Description: OpenPGP digital signature
Re: JavaCC update
Le 11/12/2016 à 15:45, Benjamin Mesing a écrit : > I now see several options: > > * update javacc to 6 and create a javacc5 package, patching all the > packages which do not compile with 6.1.3 (requires a team effort) +1 for this solution. I can help switching the broken packages back to javacc5. Note that some packages probably work with javacc4, if we are lucky creating a new javacc5 package may not be necessary. Emmanuel Bourg
