Re: Removing freeplane 1.7.x from Debian?
hello Sebastiaan, Tony, Thorsten, Emmanuel, Sebastiaan Couwenberg writes: > On 4/1/24 8:49 AM, Felix Natter wrote: >> tony mancill writes: >>> In my opinion we should be remove the outdated freeplane package from >>> Debian. >> the only thing that speaks against this is the user comment in #1030150 >> [1]. Is it true that "as Debian (and many derivates) still ship with old >> JDK"? [2] > > It might be feasible to patch freeplane to use Maven for the Debian package > build. This was suggested in the Gradle packaging status thread some time > ago [0]. > > Osmosis 0.49 also required a more recent Gradle to build, and adding a > patch to use Maven for the Debian package build was reasonably simple. > > [0] https://lists.debian.org/debian-java/2022/08/msg00010.html thank you for the suggestion. In addition to a complex gradle build system [1] using the latest features, there are also a number of new dependencies. The biggest one (I think) is twemoji [2]. [1] https://github.com/freeplane/freeplane/blob/1.11.x/freeplane/build.gradle etc. [2] #878875 (Freeplane >= 1.9 can add any unicode emoji as an icon) I *might* succeed packaging Freeplane with maven, but then it might not be compatible at all due to some missing gradle build system quirks, which I think is worse than using the upstream .deb. @Thorsten: Yes, having a 100% free build in Debian is nice, but I do not see this happening :( I agree with @Emmanuel that the upstream .deb is the best solution we can get (and given the nature of java, this is extremely easy to install for users and upstream to provide) :) However, in #1030150 Alex says: > as Debian (and many derivates) still ship with old JDK, there is in my eyes > no reason to remove > Freeplane because of that. Also it would be a shame if it maybe would vanish > from it, in that way. Is this really true for Debian [3]? [3] https://packages.debian.org/search?keywords=jre=names=stable=all I think that if we do not remove freeplane from Debian, people are "forced" to keep old unsupported JDK/JRE versions, which is a security risk IMHO. Do you agree, or is an outdated Debian package even more secure than an up-to-date upstream package as "Rpnpif" says in #1030150: > I would agree with alex. Encouraging users to take packages out of > Debian's repositories is a security risk for their OS. The current case > with xz demonstrates this. My opinion does not mean that upstream should > not offer an alternative and packages. Cheers and Best Regards, Felix -- Felix Natter
Re: Removing freeplane 1.7.x from Debian?
tony mancill writes: > On Sun, Mar 31, 2024 at 04:53:17PM +0200, Felix Natter wrote: >> Dear java team, >> >> the current freeplane package only works with an old JRE [1]. >> [1] https://bugs.launchpad.net/ubuntu/+source/freeplane/+bug/2034752 >> >> I think that not many users figure out how to set JAVA_CMD or >> FREEPLANE_JAVA_HOME, and even if they did, it would be a security risk >> due to an old JRE. I cannot package freeplane 1.11.x because it requires >> gradle >= 7.x. >> >> Since it is easy to install the upstream .deb... >> - https://sourceforge.net/projects/freeplane/ >> - select "Files" >> - select "freeplane stable" >> - select freeplane_1.11.11~upstream-1_all.deb >> - install with "sudo apt install >> /path/to/freeplane_1.11.11~upstream-1_all.deb" >> >> ... I wonder whether it is better to remove freeplane now? >> What do you think? > > Hi Felix, hello Tony, > In my opinion we should be remove the outdated freeplane package from > Debian. the only thing that speaks against this is the user comment in #1030150 [1]. Is it true that "as Debian (and many derivates) still ship with old JDK"? [2] [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030150#25 [2] https://packages.debian.org/search?keywords=jre=names=stable=all Cheers and Best Regards, Felix -- Felix Natter debian/rules!
Removing freeplane 1.7.x from Debian?
Dear java team, the current freeplane package only works with an old JRE [1]. [1] https://bugs.launchpad.net/ubuntu/+source/freeplane/+bug/2034752 I think that not many users figure out how to set JAVA_CMD or FREEPLANE_JAVA_HOME, and even if they did, it would be a security risk due to an old JRE. I cannot package freeplane 1.11.x because it requires gradle >= 7.x. Since it is easy to install the upstream .deb... - https://sourceforge.net/projects/freeplane/ - select "Files" - select "freeplane stable" - select freeplane_1.11.11~upstream-1_all.deb - install with "sudo apt install /path/to/freeplane_1.11.11~upstream-1_all.deb" ... I wonder whether it is better to remove freeplane now? What do you think? Best Regards, Felix -- Felix Natter
Re: Gradle packaging status update
hello Markus and everyone else, Markus Koschany writes: > Am Samstag, dem 20.08.2022 um 18:27 +0200 schrieb Thorsten Glaser: >> On Sat, 20 Aug 2022, Phil Morrell wrote: >> >> > Hi all, documenting my observations as of today because it's not looking >> > promising for bookworm. >> > >> > * kotlin FTBFS because of changes to support openjdk 17 #1012214 >> >> If gradle depends on kotlin, it’s not eligible for stable anyway >> because kotlin currently depends on two unsupported JDKs that are >> available in unstable for bootstrapping and (old…‑)stable support >> but nothing else. > > I agree, help with Kotlin would be really appreciated. At some point it > started > to FTBFS and this should be the first point of investigation. After that we > should try to package a newer version that builds with and supports Java 17. > > I'm making only slow progress with Gradle 6.x because of the long feedback > loop > (changing something, rebuilding and testing takes forever) but the goal is > still to replace Grade 4. thank you! > My conclusion so far is that Debian would be better off if we started to use > different build systems whenever possible. Most of the time it would be a > realistic task because many projects upload their artifacts to maven.org and > we > could port those Gradle projects to Maven based projects. I have started to > work on a few projects and sometimes you could really just use javahelper to > build an artifact and in the end building from source is the only thing we > need. > > Gradle might be a fantastic tool for visual and GUI driven developers and > large > projects which also use it as a project management tool. In Debian we just > need > something to build source code from the command line and Gradle is simply > overkill in this regard. I can speak for Freeplane and as an ex-java-Developer: Gradle is used for complex build systems, and I like it because it allows scripting via groovy (with my limited knowledge of maven, you have to add a plugin for _many_ things). For Freeplane there are many quirks and fixes in gradle and it would be very hard to map all these (ok, some things like generating installers are not needed for a Debian build) to i.e. maven. It would be easier to downport to gradle4, but even that is far from being easy (you need to track errors that do not occur in upstream which may be subtle). That's why I do not have the resources to package freeplane on my own. Not having gradle is a pity for d-java, and anyway, thanks for the effort you all put into it! Cheers and Best Regards, Felix -- Felix Natter
Freeplane 1.9.x package challenges (looking for co-maintainer(s))
hello Java maintainers, I consider upgrading freeplane from 1.7.10 to 1.9.x. Unfortunately, there are quite a few challanges (some might not be valid and some might be missing): - gradle 6.x (7.x?) -> that's why I haven't started yet. I realize you are working hard on this. - redo patches for gradle build system - additional/new dependencies: - twemoji (unicode emojis): dependency twemoji-parser which depends on a twitter scala library (2-3 teams involved) -> see the lengthy discussion @ #878875 plus links - knopflerfish 8.0.4->8.0.11 -> _might_ need to update libknopflerfish-osgi-framework-java - org.freeplane.dpolivaev.mnemonicsetter:mnemonicsetter 0.5->0.6 (easy) - com.github.robtimus:data-url: 1.0.1->2.0 - com.bulenkov:darcula: 2018.2->2021.7 - new: com.twelvemonkeys.imageio:imageio-jpeg:3.6.4 - commons-io and commons-codec now pull an older version -> don't know why, maybe needs patches - org.freeplane.lightdev:simplyhtml: 0.17.3->0.18.5 (easy) - https://repo.spring.io/plugins-release: probably just debug helper - 'org.xbib.gradle.plugin.jflex' version '1.2.1' (downgraded??) - :jsyntaxpane-0.9.6~r156-7 -> https://github.com/Sciss/SyntaxPane (fork!) - new: io.github.gitbucket:markedj:1.0.16 (markdown) - jmapviewer:2.14->2.15 - org.codehaus.groovy:groovy-all: 2.4->3.0.8 (fp might update to 4.x soon) - org.apache.ivy:ivy:2.4.0->org.apache.ivy:ivy:2.5.0 - batik: 1.10->1.14 (1.12 is in Debian) - fop: 2.2->2.6 (2.5 is in Debian) - new: 'org.apache.pdfbox:fontbox:2.0.23' (moving target: new/updated dependencies all the time) - OSGi: bnd invocation compatible (5.0.1->5.3.0)? - new logos, licenses, ... - does not work with Java >=16 currently (as of freeplane 1.9.7) (like many other packages I guess) -> will be fixed upstream Is there anyone who would consider to join the freeplane packaging? It is a popular package [1] (although its popularity has decreased because the package is outdated), so I think it is quite nice to have it updated in Debian -> you will have many grateful users :-) [1] https://qa.debian.org/popcon.php?package=freeplane Cheers and Best Regards, Felix -- Felix Natter
Re: Can you help? (ITP: opencensus-java -- Stats collection and distributed tracing framework)
ersion}",
spring_context:
"org.springframework:spring-context:${springVersion}",
spring_context_support:
"org.springframework:spring-context-support:${springVersion}",
prometheus_simpleclient:
"io.prometheus:simpleclient:${prometheusVersion}",
protobuf:
"com.google.protobuf:protobuf-java:${protobufVersion}",
opencensus_proto:
"io.opencensus:opencensus-proto:${opencensusProtoVersion}",
gson: "com.google.code.gson:gson:${gsonVersion}",
httpcomponents:
"org.apache.httpcomponents:httpclient:${httpcomponentsVersion}",
// Test dependencies.
guava_testlib: "com.google.guava:guava-testlib:${guavaVersion}",
junit: 'junit:junit:4.12',
mockito: 'org.mockito:mockito-core:2.28.1',
spring_test: "org.springframework:spring-test:${springVersion}",
truth: 'com.google.truth:truth:1.0',
spring_boot_test:
"org.springframework.boot:spring-boot-starter-test:${springBootTestVersion}",
spring_boot_test2:
"org.springframework.boot:spring-boot-starter-test:${springBoot2Version}",
dropwizard:
"io.dropwizard.metrics:metrics-core:${dropwizardVersion}",
dropwizard5:
"io.dropwizard.metrics5:metrics-core:${dropwizard5Version}",
sprint_boot_starter_tomcat:
"org.springframework.boot:spring-boot-starter-tomcat:${springBoot2Version}",
javax_servlet:
"javax.servlet:javax.servlet-api:${javaxServletVersion}",
So if you want to package the whole thing, you have to package most of
these (ca. 50) non-test dependencies (some of them are already packaged, of
course and as noted, some can be replaced by small patches).
> and added some of the modules I was able to detect from the gradle cache
> but this did not helped much. I would be happy if someone could lend a
> helping hand since I have the feeling that my attempt looks a bit
> fruitless. The package is relevant to get bazel packaged which would
> open the chance to package tensorflow which is used in several packages
> that help fighting COVID-19 and thus is part of the Debian Med COVID-19
> sprint.
This is an ambitious goal :-)
Cheers and Best Regards,
--
Felix Natter
Re: Help to detect java classes in drop-seq (covid-19 relevant) needed
Andreas Tille writes: > Hi, hello Andreas, > On Wed, May 20, 2020 at 10:07:48PM +0200, Andreas Tille wrote: >> >> Thanks. This was pretty helpful. Now I need to package the >> remaining JAR which is not yet packaged from >> >>http://la4j.org/ > > I made some progress and also uploaded libla4j-java[1] to new. With > this I tried to build drop-seq[2] and stumbled upon two issues: > > At first a lintian issue: > > W: drop-seq-tools: classpath-contains-relative-path > usr/share/java/dropseq-2.3.0.jar: lib/FastInfoset-1.2.12.jar, > lib/FastInfoset.jar, lib/FastInf > N: > N:The classpath listed in the jar file refers to a potential missing jar > N:file. This could be the remnants of a build-time classpath that are not > N:relevant for a JAR bundled in a Debian package. > N: > N:Alternatively, the classpath may be correct, but the package is lacking > N:a jar file or a symlink to it. > N: > N:Note, Lintian assumes that all (relative) classpaths pointing to > N:/usr/share/java/ (but not subdirs thereof) are satisfied by dependencies > N:as long as there is at least one strong libX-java dependency. > N: > N:Severity: warning > N: > N:Check: languages/java > > I have no idea what this means. A `grep -Ri fastinfoset` inside the source > tree remains empty. > The (current) problem is this in the jar-executable target: This causes the classpath for the runnable jar to be prefixed with lib/, but /usr/share/java/lib/... (or lib/...) does not exist. Please try to change it to: > The other one is a runtime error of the wrapper script: > > $ drop-seq > Error: Could not find or load main class > org.broadinstitute.dropseqrna.cmdline.DropSeqMain > Caused by: java.lang.NoClassDefFoundError: > picard/cmdline/PicardCommandLine This is a likely consequence of the lintian above: the dropseq jar does not refer to the correct classpath entry for picard.jar. If it still does not work, please post the META-INF/MANIFEST.MF contents of the usr/share/java/dropseq-2.3.0.jar (you can rename it to .zip, then open it with an archiver). Cheers and Best Regards, -- Felix Natter debian/rules!
Re: Help to detect java classes in drop-seq (covid-19 relevant) needed
Andreas Tille writes:
> Hi,
hello Andreas,
> I've started packaging of drop-seq[1] and replaced those JARs that are
> replacable by Debian packaged versions. I also have set CLASS_PATH in
> d/rules, but it seems to be ignored. I have dealt with similar cases by
> patching it into build.xml but here I have not found the relevant place
> to do so. I'm aware that I did not yet added all needed classes to
> CLASS_PATH, but currently I get
>
>
>dh_auto_build
> ant -Duser.name debian
> Buildfile: /build/drop-seq-2.3.0+dfsg/build.xml
> [taskdef] Could not load definitions from resource testngtasks. It could
> not be found.
>
> compile-src:
> [mkdir] Created dir: /build/drop-seq-2.3.0+dfsg/classes
> [javac] Compiling 201 source files to /build/drop-seq-2.3.0+dfsg/classes
> [javac]
> /build/drop-seq-2.3.0+dfsg/src/java/org/broadinstitute/dropseqrna/TranscriptomeException.java:28:
> error: package htsjdk.samtools does not exist
> [javac] import htsjdk.samtools.SAMException;
> [javac] ^
> [javac]
> /build/drop-seq-2.3.0+dfsg/src/java/org/broadinstitute/dropseqrna/TranscriptomeException.java:34:
> error: cannot find symbol
> [javac] public class TranscriptomeException extends SAMException
> [javac] ^
> [javac] symbol: class SAMException
> ...
Since the upstream jars were in ${lib}, you need to point ${lib} to
/usr/share/java/:
diff --git a/debian/patches/debian_packaged_libs.patch
b/debian/patches/debian_packaged_libs.patch
index 1d3790c..4fc1ed9 100644
--- a/debian/patches/debian_packaged_libs.patch
+++ b/debian/patches/debian_packaged_libs.patch
@@ -1,6 +1,6 @@
--- a/build.xml
+++ b/build.xml
-@@ -35,7 +35,7 @@
+@@ -35,13 +35,15 @@
@@ -9,3 +9,13 @@
+
+-
+-
++
++
++
++
+
+
+
You have to add more libraries like these.
Cheers and Best Regards,
--
Felix Natter
debian/rules!
Re: any updates to kotlin ?
hello Emmanuel and debian-java, Emmanuel Bourg writes: > Le 06/10/2019 à 19:02, shirish शिरीष a écrit : > >> I had read Saif blog posts and it seems some of the parts are stuck in >> the NEW queue. Does anybody have any idea or have people prodded the >> ftp-masters to see what is holding up the introduction to the archive >> ? > > The remaining dependencies prepared by Saif are all in the NEW queue > now. But that isn't the limiting factor, there are issues left with the > kotlin package. It does build, once installed the REPL works fine, but > it fails to build itself. The compilation breaks with a nasty exception. > > The other issue is the kotlin-boostrap package, it contains prebuilt > binaries that we have to build from sources (at least the kotlinx > artifacts). Would it help if I would package one (or more) of the kotlinx libraries? The question is: which one? https://salsa.debian.org/m36-guest/kotlin-bootstrap/-/tree/master/kotlinx -> contains kotlinx-coroutines-core, kotlinx-metadata-jvm and kotlinx-serialization-runtime jars. but none of these is still active: https://github.com/Kotlin/ -> so would it make sense to look at kotlinx.coroutines (contains kotlinx-coroutines-core module) or kotlinx.serialization (contains a runtime module) now? (kotlinx.coroutines has 10 dependencies, so I wonder whether it is feasible for debian-java to package all kotlin libraries where each has a number of sub-dependencies?) Cheers and Best Regards, -- Felix Natter debian/rules!
Re: OpenJDK 14 (ea) entering testing
tony mancill writes: > Hi Felix, > > I haven't taken a look at it yet but will do so this weekend. Would you > mind filing a wishlist bug against groovy regarding the update? Sure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951831 Thanks and Best Regards, -- Felix Natter
Re: OpenJDK 14 (ea) entering testing
Lilian BENOIT writes: > Hello, hello Lilian, Hans, Tony, > In july, a message "OpenJDK 13 (ea) entering testing" has been sended on > this > mailing-list. (https://lists.debian.org/debian-java/2019/07/msg9.html) > There was a question : Would anybody be interested in setting up a machine > to check builds with interim OpenJDK versions? > > Please give more information for that ? What would be idea ? I am the 'freeplane' package maintainer. Upstream has informed me that they will soon upgrade to groovy 3.1, because groovy 2.x supposedly (I cannot find supporting evidence) does not work with Java14. @Hans, @Tony: Is there already a plan to bring groovy to 3.x? Can I help with some small tasks? Cheers and Best Regards, -- Felix Natter debian/rules!
Re: Build with Maven - Example
Mechtilde Stehmann writes: > Hello, hello Mechthilde, > Can someone give me a hint to a java project which builds with maven and > have leveral binary from one source package? jaxb has a lot of binary packages, but it's not a straightforward package. Still it may be helpful: https://salsa.debian.org/java-team/jaxb Cheers and Best Regards, -- Felix Natter debian/rules!
Re: darcula and dependency libiconloader-java
tony mancill writes: > Hi Felix, hello Tony, thanks for looking into this. > On Sat, Oct 19, 2019 at 08:13:34PM +0200, Felix Natter wrote: >> hello Tony, >> >> as discussed, here are two more dependencies of freeplane-1.7.10 >> (darcula and its dependency iconloader from the same author). >> >> 1. https://salsa.debian.org/java-team/libiconloader-java >> >> The upstream is at https://github.com/bulenkov/iconloader.git, which is >> not active and has no releases, so I packaged git HEAD (@Markus: >> unfortunately there is no alternative to this). >> >> It uses a simple ant build system. >> >> JDK11 does not have sun.reflect.ConstructorAccessor (at compile time), >> so I replaced it with new String(...) (which is used by upstream if >> ConstructorAccessor cannot be instantiated). Could you please review >> this patch [1]? >> I also disabled apple code (third patch). >> >> [1] >> https://salsa.debian.org/java-team/libiconloader-java/blob/master/debian/patches/02_replace_ConstructorAccessor.patch > > In order to preserve the semantics of createShared(), maybe it's better > to go ahead and instantiate an array of char[] and then return that cast > to a String? (I'm not sure what the original code was hoping to > accomplish.) Then the underlying storage is mutable if some application > really expects the underlying bytes to be shared. Or we could go with > your patch and adjust if we encounter any problems. I did it this way because this seemed to be the behavior of createShared() when ourConstructorAccessor.newInstance fails to execute. Now I see you refer to "backed by 'char' array". But (from [1]): String(char[] value) Allocates a new String so that it represents the sequence of characters currently contained in the character array argument. -> thus my solution is not correct. "String.class.getDeclaredConstructor(char[].class, boolean.class)" -> I cannot find the mentioned String(char[], boolean) constructor in [1]. [1] https://docs.oracle.com/javase/9/docs/api/java/lang/String.html -> I don't know how the code can work, and how to make the patch create a String backed by the array. A cast from char[] to String does not work. > One other comment about libiconloader-java... It would be nice to add > .idea to Files-Excluded in debian/copyright and regenerate the > orig.tar.gz. The .idea files can be regenerated IntelliJ if needed. I've removed (repacked) them. We only package the L anyway so far. Thanks and Best Regards, -- Felix Natter debian/rules!
Re: RFS: libdata-url-java/1.0.1-1 [ITP] -- Support for data URLs according to RFC 2397
tony mancill writes: > On Sat, Oct 19, 2019 at 05:18:33PM +0200, Felix Natter wrote: >> >> Package: sponsorship-requests >> Severity: wishlist >> >> Dear mentors, >> >> I am looking for a sponsor for my package "libdata-url-java" > > Hi Felix, hello Tony, > The initial review looks good. I will sponsor this upload (probably > later this evening). > >> @debian-java: Can I post the darcula package and its dependency >> (remaining two dependencies for freeplane-1.7.10) directly on d-java, or >> shall I do it via mentors? > > Send me an email whenever you're ready and I will look at this one too. 2x Many Thanks! > Cheers, > tony Cheers and Best Regards, -- Felix Natter debian/rules!
darcula and dependency libiconloader-java
hello Tony, as discussed, here are two more dependencies of freeplane-1.7.10 (darcula and its dependency iconloader from the same author). 1. https://salsa.debian.org/java-team/libiconloader-java The upstream is at https://github.com/bulenkov/iconloader.git, which is not active and has no releases, so I packaged git HEAD (@Markus: unfortunately there is no alternative to this). It uses a simple ant build system. JDK11 does not have sun.reflect.ConstructorAccessor (at compile time), so I replaced it with new String(...) (which is used by upstream if ConstructorAccessor cannot be instantiated). Could you please review this patch [1]? I also disabled apple code (third patch). [1] https://salsa.debian.org/java-team/libiconloader-java/blob/master/debian/patches/02_replace_ConstructorAccessor.patch 2. https://salsa.debian.org/java-team/darcula I packaged from https://github.com/ice1k/darcula/ instead of the original https://github.com/bulenkov/Darcula because it is maintained, has releases, a gradle build system and upstream (freeplane, ...) uses it. One problem is that darcula merges the iconloader jar classes into its darcula jar. Thus iconloader does not appear in the darcula pom. I can easily change this, but I didn't because upstream uses it and iconloader does not seem to change often. Also, darcula needs jetbrains-annotations, but most probably not at runtime, but it's a compile dependency in the pom, so darcula users needlessly ship this package. Both packages are mostly lintian-clean, work in pbuilder and with freeplane-1.7.10. Many Thanks and Best Regards, -- Felix Natter debian/rules!
RFS: libdata-url-java/1.0.1-1 [ITP] -- Support for data URLs according to RFC 2397
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libdata-url-java" * Package name: libdata-url-java Version : 1.0.1-1 Upstream Author : Rob Spoor (mail address not known) * URL : https://robtimus.github.io/data-url/ * License : Apache-2.0 * Vcs : https://salsa.debian.org/java-team/libdata-url-java Section : java It builds those binary packages: libdata-url-java - Support for data URLs according to RFC 2397 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libdata-url-java Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libd/libdata-url-java/libdata-url-java_1.0.1-1.dsc Changes since the last upload: * Initial release. (Closes: #941916) It is a simple maven package which is a dependency of freeplane-1.7.10. The only thing to mention is that I replaced the i18n-maven-plugin (from the upstream author) by String.format (see 01_replace_i18n_maven_plugin.patch). @debian-java: Can I post the darcula package and its dependency (remaining two dependencies for freeplane-1.7.10) directly on d-java, or shall I do it via mentors? Cheers and Best Regards, -- Felix Natter
Re: Packaging from Maven repo
Mechtilde Stehmann writes: > Hello, hello Mechthilde, I am answering because it seems like none of the experts answers. > I try to package xmlunit-core which I need as a dependency. > > I get it from > https://repo1.maven.org/maven2/org/xmlunit/xmlunit-core/2.6.3/xmlunit-core-2.6.3-sources.jar I think you should package from the source repository: https://github.com/xmlunit/xmlunit (https://github.com/xmlunit/xmlunit/releases) because it contains a complete build system (should be easier). I couldn't immediately make it work with mh_make either. There are many maven modules involved. > the pom.xml isn't in the root directory. It is in > META-INF/maven/org.xmlunit/xmlunit-core/ > > I used mh_make in that directory. When I used mh_make in the root > directory mh_make couldn't find the POM file. > > Then I copied the directory > META-INF/maven/org.xmlunit/xmlunit-core/debian/* to debian/* and changed > the entry into debian/.poms into the whole path. > > when I run gbp-buildpackage I get the message: can't find > debian/ > There must be something wrong when I copied it. But what is wrong? When using the github release, pom.xml already is on toplevel, so you won't have this problem. Which package needs xmlunit-core? Are you sure it isn't a test dependency that can be ignored? Cheers and Best Regards, -- Felix Natter debian/rules!
Re: any updates to kotlin ?
shirish शिरीष writes: > Dear all, hello Debian-java, > I had read Saif blog posts and it seems some of the parts are stuck in > the NEW queue. Does anybody have any idea or have people prodded the > ftp-masters to see what is holding up the introduction to the archive > ? > > Looking forward to seeing kotlin in Debian. I know it's one of things > that is needed for the new version of gradle to come through in > Debian. I have a similar question: The gradle OSGi plugin is deprecated [1] and will be removed in a future gradle version (6.0?). That's why freeplane upstream wants to migrate to the bnd gradle plugin. This, however, seems to require gradle 5 (from [2]): "The biz.aQute.bnd.gradle jar contains the Bnd Gradle Plugins. These plugins requires at least Gradle 4.0 for Java 8, at least Gradle 4.2.1 for Java 9, at least Gradle 4.7 for Java 10, and at least Gradle 5.0 for Java 11." -> I think my three options are: - make the upstream change on a separate branch, and kindly ask upstream not to merge it until Debian has gradle 5 (probably not going to happen) or - use a huge patch undoing all the gradle-osgi->bnd-plugin changes or - hope that the gradle bnd plugin works to some extent on gradle 4.4.1 with java11 -> the final question is: Is there an estimate for when gradle >= 5 will be available? [1] https://docs.gradle.org/current/userguide/osgi_plugin.html [2] https://github.com/bndtools/bnd/blob/master/biz.aQute.bnd.gradle/README.md Many Thanks and Best Regards, -- Felix Natter debian/rules!
uscan: git repo without releases/tags
hi debian-java, I am starting to package libiconloader-java but unfortunately, there are no releases or tags in the respository: https://github.com/bulenkov/iconloader I kindly asked for a release, but the author does not respond for weeks now. How can I deal with this? Shall I write a debian/rules target 'get-orig-source' that clones the repo and creates a .tar.gz from that (duplicating the Files-Excluded: mechanism)? Is the upstream version 0.0+20191003 ok? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Resources folder is not installed in JAR file
Cyril Richard writes:
hi Cyril,
>> I can help fix this in your package if you want me to.
>
> Oh yes !!! 10 000 yes :).
> I used to program in C. Java is new to me, so I appreciate your help !
Here is the diff:
diff --git a/debian/rules b/debian/rules
index 0276245..5074d52 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,3 +6,9 @@
override_jh_build:
jh_build --javacopts="-source 1.8 -target 1.8" --javadoc-opts="-source
1.8" spview.jar sources
+
+override_dh_install:
+# hack to get all files into the jar (jh_build can only include *.class)
+(cd resources && jar uf ../spview.jar *)
+dh_install
+
I could not test this because gbp buildpackage -us -uc failed due to a
missing upstream/... tag. Maybe you need to "git push --tags"?
Cheers and Best Regards,
Felix
> -----
> De: "Felix Natter"
> À: "Cyril Richard"
> Cc: "debian-java"
> Envoyé: Lundi 30 Septembre 2019 16:44:22
> Objet: Re: Resources folder is not installed in JAR file
>
> Cyril Richard writes:
>
>> Hello,
>
> hi Cyril,
>
>> After some difficulties, I think I'm almost done with my deb packaging of my
>> java application [1].
>> Now, the last thing I did not mannage to do is to install all my resource
>> folder in the JAR file.
>>
>> My project tree looks like that:
>>
>> test
>> resources
>> sources
>>
>> I would like to include the directory resources inside my JAR file, like I
>> created the JAR with eclipse.
>> To do that, I tried several ways in the d/rules file.
>>
>> Currently, the file is like that (not in the repo, on my laptop):
>>
>> #!/usr/bin/make -f
>> # debian/rules for spview
>>
>> %:
>> dh $@ --with javahelper
>>
>> override_jh_build:
>> jh_build --javacopts="-source 1.8 -target 1.8" --no-javadoc spview.jar
>> sources
>>
>> I tried to add
>> export JH_JAR_EXTRA=resources
>> at the beginning of the file
>>
>> I also tried to write:
>> override_jh_build:
>> jh_build --javacopts="-source 1.8 -target 1.8" --no-javadoc spview.jar
>> sources resources
>>
>> or
>>
>> dh $@ --with javahelper --sourcedirectory=resources
>>
>> with also no succes.
>
> man jh_build does not mention resources:
>
> jh_build [debhelper options] jarfile source [... source]
>
> so it is still not supported, see #700196.
>
> There is a workaround by adding the resources manually using jar uf
> ("update file") [1]:
>
> override_dh_install:
> (cd && jar uf .../foo.jar
> ...)
> dh_install
>
> like this [2] (which could be refactored):
>
> override_dh_install:
> # hack to get all files into the jar (jh_build can only include
> *.class)
> (cd src/main/resources&& jar uf
> ../../../jsyntaxpane.jar META-INF)
> (cd src/main/resources/META-INF/services/ && jar uf
> ../../../../../jsyntaxpane.jar `find -name "config.properties"`)
> (cd src/main/resources/ && jar uf
> ../../../jsyntaxpane.jar `find -name "Bundle*properties"`)
> dh_install
>
> [1] https://docs.oracle.com/javase/tutorial/deployment/jar/update.html
> [2]
> https://salsa.debian.org/java-team/libjsyntaxpane-java/blob/master/debian/rules
>
> I can help fix this in your package if you want me to.
>
> Cheers and Best Regards,
> --
> Felix Natter
> debian/rules!
>
--
Felix Natter
debian/rules!
Re: Resources folder is not installed in JAR file
Cyril Richard writes:
> Hello,
hi Cyril,
> After some difficulties, I think I'm almost done with my deb packaging of my
> java application [1].
> Now, the last thing I did not mannage to do is to install all my resource
> folder in the JAR file.
>
> My project tree looks like that:
>
> test
> resources
> sources
>
> I would like to include the directory resources inside my JAR file, like I
> created the JAR with eclipse.
> To do that, I tried several ways in the d/rules file.
>
> Currently, the file is like that (not in the repo, on my laptop):
>
> #!/usr/bin/make -f
> # debian/rules for spview
>
> %:
> dh $@ --with javahelper
>
> override_jh_build:
> jh_build --javacopts="-source 1.8 -target 1.8" --no-javadoc spview.jar
> sources
>
> I tried to add
> export JH_JAR_EXTRA=resources
> at the beginning of the file
>
> I also tried to write:
> override_jh_build:
> jh_build --javacopts="-source 1.8 -target 1.8" --no-javadoc spview.jar
> sources resources
>
> or
>
> dh $@ --with javahelper --sourcedirectory=resources
>
> with also no succes.
man jh_build does not mention resources:
jh_build [debhelper options] jarfile source [... source]
so it is still not supported, see #700196.
There is a workaround by adding the resources manually using jar uf
("update file") [1]:
override_dh_install:
(cd && jar uf .../foo.jar
...)
dh_install
like this [2] (which could be refactored):
override_dh_install:
# hack to get all files into the jar (jh_build can only include *.class)
(cd src/main/resources&& jar uf
../../../jsyntaxpane.jar META-INF)
(cd src/main/resources/META-INF/services/ && jar uf
../../../../../jsyntaxpane.jar `find -name "config.properties"`)
(cd src/main/resources/ && jar uf
../../../jsyntaxpane.jar `find -name "Bundle*properties"`)
dh_install
[1] https://docs.oracle.com/javase/tutorial/deployment/jar/update.html
[2]
https://salsa.debian.org/java-team/libjsyntaxpane-java/blob/master/debian/rules
I can help fix this in your package if you want me to.
Cheers and Best Regards,
--
Felix Natter
debian/rules!
Freeplane 1.7.9 update
hello debian-java, there is a simple new upstream release of freeplane (1.7.9): freeplane (1.7.9-1) unstable; urgency=medium * New upstream release * Update/refresh patches * Do not try to build freeplane_mac * Bump standards-version to 4.4.0 (no changes) * Update version in man page -- Felix Natter Wed, 17 Jul 2019 17:42:39 +0200 The VCS is on salsa: g...@salsa.debian.org:java-team/freeplane.git Could someone please consider uploading this? Cheers and Best Regards, Felix -- Felix Natter
Re: Buster soft freeze question
Markus Koschany writes: > Hi, hello Markus, hello Tony, > Am 30.01.19 um 20:55 schrieb Felix Natter: >> hi Debian-java, >> >> I would like to get freeplane-1.7.5-1 into buster, because it contains >> important fixes. Unfortunately, upstream is still fixing regressions. >> >> For stretch, a soft freeze is described as: >> "no new packages, no re-entry, normal migrations" [1] >> >> I think that means that I can get freeplane-1.7.5-1 into buster until >> beginning of March (by full freeze)? >> >> [1] https://wiki.debian.org/DebianStretch >> >> Many Thanks and Best Regards, > > The important part for our soft freeze is: Many thanks for the explanation! I was lucky, freeplane-1.7.5 was just released, and I prepared the update: freeplane (1.7.5-1) unstable; urgency=medium * New upstream release * Add new dependency ivy * Declare conformance with standards version 4.3.0 (no changes) * Update man page -- Felix Natter Sun, 03 Feb 2019 15:47:47 +0100 This is the repo: https://salsa.debian.org/java-team/freeplane There is one thing worth noting: The 1.7.2 uploads's .orig tarball contains class files, because the upstream build system did not take into account that the lead developer now uses the IntelliJ IDE, which puts classes into /out/**.class. This is fixed now, so 1.7.5[-1] will not contain class files in the orig tarball. @Tony: Would you consider sponsoring freeplane-1.7.5-1? Thanks and Best Regards, -- Felix Natter debian/rules!
Buster soft freeze question
hi Debian-java, I would like to get freeplane-1.7.5-1 into buster, because it contains important fixes. Unfortunately, upstream is still fixing regressions. For stretch, a soft freeze is described as: "no new packages, no re-entry, normal migrations" [1] I think that means that I can get freeplane-1.7.5-1 into buster until beginning of March (by full freeze)? [1] https://wiki.debian.org/DebianStretch Many Thanks and Best Regards, -- Felix Natter debian/rules!
Please sponsor Freeplane fix
hello debian-java, I have a trivial bug fix for a Freeplane FTBFS (thanks to Emmanuel for the maven.rules hint!): freeplane (1.7.2-2) unstable; urgency=medium * Add maven rule for pulling javax.servlet:javax.servlet-api:3.1 instead of javax.servlet:javax.servlet-api:debian (Closes: #915889) -- Felix Natter Fri, 21 Dec 2018 21:31:46 +0100 The repo is here: https://salsa.debian.org/java-team/freeplane/ Could someone please sponsor this? Tony, since you sponsored 1.7.2-1? Cheers and Best Regards, -- Felix Natter debian/rules!
Please sponsor freeplane-1.7.2
hello Debian-java, there is a new major release of freeplane (1.7.2), which among many other things has an API layer and full support for Java11. The repo is on salsa: https://salsa.debian.org/java-team/freeplane Here is the changelog entry: freeplane (1.7.2-1) unstable; urgency=medium * New upstream release, compatible with Java11 * Require java8 * Drop secure groovy patch (securegroovy no longer used upstream; upstream updated to groovy 2.5.x, Debian also has patched groovy) * Update all patches (major build system update) * Bump standards-version to 4.2.1 (no changes) * Update man page -- Felix Natter Sat, 24 Nov 2018 19:07:20 +0100 Many Thanks and Best Regards, -- Felix Natter debian/rules!
Minor update to libsvgsalamander-java
hello Debian-gis, for svgSalamander 1.1.2, a fix for CVE-2017-5617 [1] (#853134) was upstreamed by Vincent Privat. [1] https://security-tracker.debian.org/tracker/CVE-2017-5617 However, upstream included the patch modified [2], with a flag in the "global data object" SVGUniverse, with the default being "allow it": [2] https://github.com/blackears/svgSalamander/commit/a0cdd694cb917de303b08117e2544a352fc2cb58 > private boolean imageDataInlineOnly = false; I wonder whether this is good (enough) for Debian (and the rest of the world), since we would need to make sure that this is set to true: SVGUniverse svgUniverse = new SVGUniverse(); svgUniverse.setImageDataInlineOnly(true); in all projects using svgSalamander (which does not seem to be much for Debian): $ apt-cache rdepends libsvgsalamander-java libsvgsalamander-java Reverse Depends: freeplane freeplane josm games-java-dev If we agree, then I will create an upstream issue. Also, is there value in updating svgSalamander from 1.1.1 to 1.1.2? (I fixed a bug triggered in Freeplane in upstream, but Freeplane contains a workaround). I can offer to do this, if we have an agreement for the above issue. Cheers and Best Regards, -- Felix Natter
Please sponsor freeplane-1.6.15-1
hello debian-java, there is a minor update for freeplane (among others export fixes): freeplane (1.6.15-1) unstable; urgency=medium * New upstream release. * Point VCS-* urls to salsa * Declare conformance to standards-version 4.1.4 * Update patches * Restore old dependency config for plugin_svg * Add NEWS entry for long running export workaround -- Felix Natter Thu, 31 May 2018 19:33:28 +0200 Could someone please upload this? https://salsa.debian.org/java-team/freeplane I added a NEWS entry (see thread: "Freeplane/batik/fop font export issue"): freeplane (1.6.15-1) unstable; urgency=medium Sometimes the PDF Export takes very long. In 1.6.15, you can change the following option in order to work around this: [x] Tools->Preferences->Environment->Export ->Convert texts to shapes in exported PDF -- Felix Natter Sat, 26 May 2018 12:47:35 +0200 Does that look ok to you? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Freeplane/batik/fop font export issue
Felix Natter <fnat...@gmx.net> writes: > Thorsten Glaser <t.gla...@tarent.de> writes: > >> On Mon, 21 May 2018, Felix Natter wrote: >> >>> Is this the right place? Otherwise: manpage (probably no one reads >>> this)? > > hi Thorsten, > > thanks for the quick answer. > >> More people read the manpage than README.Debian, but >> perhaps a NEWS entry might help in getting it seen by >> people? > > Yes, NEWS was what I meant. > >> If not the more drastic option to patching the software >> to enable it by default (which may have bad, far-reaching >> consequences). > > Since it does not occur always, and may make pasting from the PDF > harder, I think a NEWS entry is better: > Sorry, dpkg-parsechangelog complained, here is the corrected version: freeplane (1.6.15-1) unstable; urgency=medium Sometimes the PDF Export takes very long. In 1.6.15, you can change the following option in order to work around this: [x] Tools->Preferences->Environment->Export ->Convert texts to shapes in exported PDF -- Felix Natter <fnat...@gmx.net> Sat, 26 May 2018 12:47:35 +0200 Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Freeplane/batik/fop font export issue
Thorsten Glaser <t.gla...@tarent.de> writes: > On Mon, 21 May 2018, Felix Natter wrote: > >> Is this the right place? Otherwise: manpage (probably no one reads >> this)? hi Thorsten, thanks for the quick answer. > More people read the manpage than README.Debian, but > perhaps a NEWS entry might help in getting it seen by > people? Yes, NEWS was what I meant. > If not the more drastic option to patching the software > to enable it by default (which may have bad, far-reaching > consequences). Since it does not occur always, and may make pasting from the PDF harder, I think a NEWS entry is better: freeplane (1.6.15-1) unstable; urgency=medium Sometimes the PDF Export takes very long. In 1.6.15, you can change the following option in order to work aroujnd this: [x] Tools->Preferences->Environment->Export ->Convert texts to shapes in exported PDF -- Felix Natter <fnat...@gmx.net> Sat, 26 May 2018 12:47:35 +0200 Agreed? Thanks and Best Regards, -- Felix Natter debian/rules!
Freeplane/batik/fop font export issue
Hello d-java, freeplane for quite some time has the issue that the PDF/SVG export (using batik/fop) takes ages on GNU/Linux, due to the fact that text is not converted to shapes (note that this issue is at least worse with the batik/fop in debian). I am currently packaging freeplane 1.6.15. Shall I add a README.Debian entry, which tells the user to set the new pref option: [x] Convert text to shapes that fixes this (at the expense of not being able to copy+paste from pdf, which is also restricted without this option)? Is this the right place? Otherwise: manpage (probably no one reads this)? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: libjsyntaxpane-java: Java9 fix
tony mancill <tmanc...@debian.org> writes: > On Tue, May 01, 2018 at 03:47:53PM +0200, Felix Natter wrote: >> hello Debian-java, >> >> I have added a patch against libjsyntaxpane-java which fixes a Java9 >> issue, ported roughly from here: >> >> https://github.com/nordfalk/jsyntaxpane/commit/5fc75594f8bc4df6e8f7096d4a440490b768fd46 >> (which has the same license as jsyntaxpane) >> >> >> >> The update is here: >> https://salsa.debian.org/java-team/libjsyntaxpane-java >> >> Could someone please sponsor this? > > Hi Felix, hi Tony, > Uploaded and tagged. Many Thanks for both uploads! Cheers and Best Regards, -- Felix Natter debian/rules!
libjsyntaxpane-java: Java9 fix
hello Debian-java, I have added a patch against libjsyntaxpane-java which fixes a Java9 issue, ported roughly from here: https://github.com/nordfalk/jsyntaxpane/commit/5fc75594f8bc4df6e8f7096d4a440490b768fd46 (which has the same license as jsyntaxpane) Here are the changes: libjsyntaxpane-java (0.9.6~r156-7) unstable; urgency=medium * Fix java 9 problem (ported from https://github.com/nordfalk/jsyntaxpane) * Patch out pom.xml to avoid maven build * Use debhelper compat level 11 * Add myself to Uploaders: * Declare conformance with standards-version 4.1.4 * Update Vcs-* to point to salsa * Overide bad-jar-name and obsolete-url-in-packaging lintians * Ignore embedded-javascript-library lintian for javadoc output for now, see #883981 -- Felix Natter <fnat...@gmx.net> Tue, 24 Apr 2018 19:43:37 +0200 The update is here: https://salsa.debian.org/java-team/libjsyntaxpane-java Could someone please sponsor this? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Push rights for salsa/java-team
Markus Koschany <a...@debian.org> writes: > Hi Felix, > > Am 01.05.2018 um 13:57 schrieb Felix Natter: > [...] >> Can I (fnatter-guest) be added to team-java, or did I do something >> wrong? > > Sure, please request membership at salsa.debian.org and I will add you > to the team. Done, thank you. -- Felix Natter debian/rules!
Push rights for salsa/java-team
hello Debian-java, after having added my ssh key, I get this git url in gitlab: g...@salsa.debian.org:java-team/libjsyntaxpane-java.git When trying to push, I get this message: $ git push Enter passphrase for key '/home/felix/.ssh/id_rsa': GitLab: You are not allowed to push code to this project. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Can I (fnatter-guest) be added to team-java, or did I do something wrong? Thanks and Best Regards, -- Felix Natter debian/rules!
Small bug fix for knopflerfish
hello debian-java,
I have created a small bug fix release for:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895885
("freeplane does not start up without (exactly) java 9")
The change is here:
https://anonscm.debian.org/cgit/pkg-java/knopflerfish-osgi.git
Previously, -target/-source was not set, so it would not run with java<9
(or even java!=9). Strangely, it *did* work with freeplane and java8 if
java9 was installed (and not selected)!
Could someone please upload this?
Thanks and Best Regards,
--
Felix Natter
debian/rules!
Re: Question regarding libjsyntaxpane-java on alioth
Markus Koschany <a...@debian.org> writes: > Hi, > > Am 23.04.2018 um 21:44 schrieb Felix Natter: >> Felix Natter <fnat...@gmx.net> writes: >> >>> hello Debian-java, >> >> hello again, >> >>> when accessing libjsyntaxpane-java I get "Bad object id:" on each commit: >>> https://anonscm.debian.org/gitweb/?p=pkg-java/libjsyntaxpane-java.git >> >> I tried to clone the repo and I can make a (local) commit. >> So I guess just the web interface is misconfigured. >> >> Does anybody see a problem with my patching libjsyntaxpane-java >> even though the above issue exists? >> >> Thanks and Best Regards, hello Markus, > The correct VCS-URL is > https://anonscm.debian.org/cgit/pkg-java/libjsyntaxpane-java.git > > and the VCS-Git address is > > https://anonscm.debian.org/git/pkg-java/libjsyntaxpane-java.git. > > Maybe that's the reason why you see those error messages. Try to push > your changes and if it doesn't work you could still use > mentors.debian.org as a temporary workaround and someone else will try > to import it into Git. That was the case, thanks! Cheers and Best Regards, -- Felix Natter debian/rules!
Re: Question regarding libjsyntaxpane-java on alioth
Felix Natter <fnat...@gmx.net> writes: > hello Debian-java, hello again, > when accessing libjsyntaxpane-java I get "Bad object id:" on each commit: > https://anonscm.debian.org/gitweb/?p=pkg-java/libjsyntaxpane-java.git I tried to clone the repo and I can make a (local) commit. So I guess just the web interface is misconfigured. Does anybody see a problem with my patching libjsyntaxpane-java even though the above issue exists? Thanks and Best Regards, -- Felix Natter debian/rules!
Question regarding libjsyntaxpane-java on alioth
hello Debian-java, when accessing libjsyntaxpane-java I get "Bad object id:" on each commit: https://anonscm.debian.org/gitweb/?p=pkg-java/libjsyntaxpane-java.git Does anybody know what causes this? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Java app: Thread name displayed in GNOME3 task list
Emmanuel Bourg <ebo...@apache.org> writes: > Le 19/05/2016 à 21:23, Felix Natter a écrit : hello Debian-java, >> Does anyone have a solution for this? There is some discussion [1], >> but it seems without a solution. >> [1] >> https://www.bountysource.com/issues/7713930-window-title-is-java-lang-thread-instead-of-actual-application-name >> >> Can this possibly be solved on a GNOME level? > > Interesting, I wasn't aware of this issue. This looks more like a JDK > bug. Did you see the workaround implemented in Netbeans? > > https://netbeans.org/bugzilla/attachment.cgi?id=119183=diff > https://netbeans.org/bugzilla/show_bug.cgi?id=183739 > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6528430 Unfortunately this will not continue to work, as I'm seeing this on sid (even already with java8): WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.freeplane.launcher.Launcher (file:/usr/share/freeplane/freeplanelauncher.jar) to field sun.awt.X11.XToolkit.awtAppClassName WARNING: Please consider reporting this to the maintainers of org.freeplane.launcher.Launcher WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Does someone have a way to fix this? Shall I report an OpenJDK or GNOME3 bug? Thanks and Best Regards, -- Felix Natter debian/rules!
Freeplane 1.6.13-1 update
hello Debian-java, I have packaged a simple bugfix update for freeplane: https://anonscm.debian.org/cgit/pkg-java/freeplane.git Changes are: freeplane (1.6.13-1) unstable; urgency=medium * New upstream release. * Update/refresh patches, update man page. * Update standards-version to 4.1.3 (no changes) -- Felix Natter <fnat...@gmx.net> Sat, 10 Feb 2018 14:00:05 +0100 Could someone please upload it? Many Thanks and Best Regards, -- Felix Natter
Please upload freeplane-1.6.10
hello debian-java, I have updated freeplane to 1.6.10 which fixes + reenables the popular SVG and PDF export: https://anonscm.debian.org/cgit/pkg-java/freeplane.git freeplane (1.6.10-1) unstable; urgency=medium * New upstream release. * PDF/SVG export fixed and re-enabled * depend on jlatexmath >= 1.0.6 * re-worked plugin-svg dependencies * bump version in man page -- Felix Natter <fnat...@gmx.net> Sat, 04 Nov 2017 10:41:23 +0100 I smoke tested, it is lintian clean and pbuilder tested. Could someone please upload this? BTW: I am making slow progress on https://wiki.debian.org/DebianMaintainer. Cheers and Best Regards, -- Felix Natter debian/rules!
Re: Freeplane needs rebuild
tony mancill <tmanc...@debian.org> writes: > On Wed, Oct 04, 2017 at 09:26:47PM +0200, Felix Natter wrote: >> 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? > > Hello Felix, hi Tony, > Nice fix - uploaded. I verified that the build now includes the missing > MANIFEST.MF reported in #877729 [1] and my local testing of 1.6.6-3 on > sid seems fine. Thanks, I just downloaded the 1.6.6-3 and it works fine. Cheers and Best Regards, -- Felix Natter debian/rules!
Re: Freeplane needs rebuild
hello Debian-java, Felix Natter <fnat...@gmx.net> 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 <fnat...@gmx.net> Wed, 04 Oct 2017 21:14:57 +0200 Many Thanks! -- Felix Natter debian/rules!
Re: Freeplane needs rebuild
Thorsten Glaser <t.gla...@tarent.de> writes: > On Tue, 3 Oct 2017, Felix Natter wrote: > >> Could someone please sponsor a trivial 1.6.6-2 upload? > > Will do. Thanks. Best Regards, -- Felix Natter debian/rules!
Re: Freeplane needs rebuild
Felix Natter <fnat...@gmx.net> writes: > hello D-java, hello again, > 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). Thanks and Best Regards, -- Felix Natter debian/rules!
Freeplane needs rebuild
hello D-java, 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)? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Please upload freeplane-1.6.6-1
Markus Koschany <a...@debian.org> writes: hello Markus, > Am 16.09.2017 um 21:07 schrieb Markus Koschany: >> Am 16.09.2017 um 20:57 schrieb Felix Natter: >>> hello Debian-java, >>> >>> I have prepared an update for freeplane-1.6.6-1 and related packages >>> (simplyhtml-0.17.3-1 and knopflerfish-6.1.1-1): >>> >>> https://anonscm.debian.org/cgit/pkg-java/freeplane.git >>> https://anonscm.debian.org/cgit/pkg-java/simplyhtml.git >>> https://anonscm.debian.org/cgit/pkg-java/knopflerfish-osgi.git >> >> [...] >> >>> Would someone please sponsor this? > > I have uploaded knopflerfish-osgi a few minutes ago. Thanks! > There is one issue > with simplyhtml. Please remove JavaHelpTOC.jar from the sources and Done, it looks like this isn't needed (simplyhtml in freeplane does not use the help feature, and the help contents in standalone simplyhtml still work without this) > change the compat level to 10 and Standards-Version to 4.1.0 for > freeplane. I have already changed that for the other two packages. The > rest looks good. I have done this, except for standards-version 4.1.0 in freeplane. I am not sure about the reproducibility which is required. I will read on this, check it and fix it in the next 1.6.x release (which will follow soon). I think there are some Debian reports that help me? Cheers and Best Regards, -- Felix Natter debian/rules!
Please upload freeplane-1.6.6-1
hello Debian-java, I have prepared an update for freeplane-1.6.6-1 and related packages (simplyhtml-0.17.3-1 and knopflerfish-6.1.1-1): https://anonscm.debian.org/cgit/pkg-java/freeplane.git https://anonscm.debian.org/cgit/pkg-java/simplyhtml.git https://anonscm.debian.org/cgit/pkg-java/knopflerfish-osgi.git Here are the changelog entries: freeplane (1.6.6-1) UNRELEASED; urgency=medium * New upstream release. * PDF/SVG export disabled upstream due to incompatibility with svgSalamander (Closes: #856058, LP: #172) * Java9 compatible (Closes: #873220) * Fix patches * Depend on groovy-2.4.8-2 with security fix for GROOVY-8163 (and remove the upstream "securegroovy" invocation) * Add jython build dep which is needed for compiling against libbatik-java-1.9 * Update man page * Update standards-version (no changes) -- Felix Natter <fnat...@gmx.net> Fri, 15 Sep 2017 20:19:16 +0200 simplyhtml (0.17.3-1) UNRELEASED; urgency=medium * New upstream version * Refresh 01_build.patch, remove deprecated gradle feature (<<) * Upgrade standards-version to 4.0.0 (no changes) * Update copyright years -- Felix Natter <fnat...@gmx.net> Thu, 24 Aug 2017 17:07:40 +0200 knopflerfish-osgi (6.1.1-1) unstable; urgency=medium * New upstream release * Java9 support * Update standards-version (no changes) * Drop 20_versioned_jar.patch (no longer necessary) * Add 10_javac_encoding.patch * Build with libosgi-annotation-java -- Felix Natter <fnat...@gmx.net> Sat, 16 Sep 2017 10:10:35 +0200 These packages are java9-compatible. We have fixed a security issue with freeplane groovy scripts (GROVY-8163) by patching groovy (2.4.8-2), so this version should be safe. We will work on backporting this fix to stretch. Would someone please sponsor this? Can I apply for DM so I can upload _these_ packages myself? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: jlatexmath
Sylvestre Ledru <sylves...@debian.org> writes: > Hello, hello Sylvestre, > Le 12/09/2017 à 20:31, Felix Natter a écrit : > > hi, > > I would like to take over and update jlatexmath. I'm pretty sure > that Sylvestre is no longer involved in Debian. > > As a first thing I would like to move the packaging to git. > Does anybody object to this? > > I am still involved (a lot on llvm) in Debian & in jlatexmath > upstream, but happy to have a co maintainer :) Good to hear! So do you agree with moving the packaging to git and packaging 1.0.6? (I seem to remember that in the past you were against moving away from svn?) Cheers and Best Regards, -- Felix Natter debian/rules!
jlatexmath
hi, I would like to take over and update jlatexmath. I'm pretty sure that Sylvestre is no longer involved in Debian. As a first thing I would like to move the packaging to git. Does anybody object to this? Cheers and Best Regards, -- Felix Natter debian/rules!
Re: libbatik-java: Changed artifacts?
Christopher Hoskin <mans0...@debian.org> writes:
> Dear Felix,
hello Christopher,
> Another option would be for me to switch to using maven to build
> batik. I've had a go at this here:
>
> https://anonscm.debian.org/cgit/pkg-java/batik.git/?h=maven-build
>
> In this case, batik-i18n and batik-constants are created as jars in
> their own right under /usr/share/java rather than being bundled into
> other jars. Upstream supports building with maven, although I presume
> they are still using ant for their own binaries as they don't have
> batik-i18n and batik-constants jars?
Thank you for analyzing and fixing the issue with freeplane.
I will fix this in the new release which is already in the pipeline.
> I haven't uploaded the maven build as I don't know if this approach
> might have a negative impact on other reverse dependencies expecting
> the ant layout build?
I would stick with the old (ant) build system, as this means much less
work fixing the r-deps. But whatever you choose is ok for me.
We still should test-build all r-deps to see whether they build though.
>> batik-i18n gets included in the batic-util.jar, but the pom file for
>> batic-util includes:
>>
>>
>> ${project.groupId}
>> batik-constants
>> ${project.version}
>>
>>
>> ${project.groupId}
>> batik-i18n
>> ${project.version}
>>
>>
>> So my first thought is that this is a problem with the upstream pom files.
>>
>> If I comment out these dependencies and add jython to the build
>> dependencies for freeplane, then the freeplane package builds okay.
Do the people on d-java agree that this is a good solution?
It seems good to me.
One suggestion: If you update a library, it would be good to test
whether any r-dep fails to build. There are not many for the case of
batik.
Cheers and Best Regards,
--
Felix Natter
debian/rules!
libbatik-java: Changed artifacts?
No cached version of org.apache.xmlgraphics:batik-i18n:debian available for offline mode. > No cached version of org.apache.xmlgraphics:batik-i18n:debian available for offline mode. > Could not resolve org.apache.xmlgraphics:batik-rasterizer-ext:debian. Required by: project :freeplane_plugin_svg > org.apache.xmlgraphics:batik-all:debian > No cached version of org.apache.xmlgraphics:batik-rasterizer-ext:debian available for offline mode. > No cached version of org.apache.xmlgraphics:batik-rasterizer-ext:debian available for offline mode. > Could not resolve org.apache.xmlgraphics:batik-squiggle-ext:debian. Required by: project :freeplane_plugin_svg > org.apache.xmlgraphics:batik-all:debian > No cached version of org.apache.xmlgraphics:batik-squiggle-ext:debian available for offline mode. > No cached version of org.apache.xmlgraphics:batik-squiggle-ext:debian available for offline mode. > Could not resolve org.apache.xmlgraphics:batik-svgbrowser:debian. Required by: project :freeplane_plugin_svg > org.apache.xmlgraphics:batik-all:debian project :freeplane_plugin_svg > org.apache.xmlgraphics:batik-all:debian > org.apache.xmlgraphics:batik-squiggle:debian > No cached version of org.apache.xmlgraphics:batik-svgbrowser:debian available for offline mode. > No cached version of org.apache.xmlgraphics:batik-svgbrowser:debian available for offline mode. > Could not resolve org.apache.xmlgraphics:batik-svgrasterizer:debian. Required by: project :freeplane_plugin_svg > org.apache.xmlgraphics:batik-all:debian project :freeplane_plugin_svg > org.apache.xmlgraphics:batik-all:debian > org.apache.xmlgraphics:batik-rasterizer:debian > No cached version of org.apache.xmlgraphics:batik-svgrasterizer:debian available for offline mode. > No cached version of org.apache.xmlgraphics:batik-svgrasterizer:debian available for offline mode. > Could not resolve org.python:jython:debian. Required by: project :freeplane_plugin_svg > org.apache.xmlgraphics:batik-all:debian > org.apache.xmlgraphics:batik-script:debian > No cached version of org.python:jython:debian available for offline mode. > No cached version of org.python:jython:debian available for offline mode. I tried oonly batik-swing: problem occurred evaluating project ':freeplane_plugin_svg'. > Could not resolve all dependencies for configuration > ':freeplane_plugin_svg:runtime'. > Could not resolve org.apache.xmlgraphics:swing:1.7. Required by: project :freeplane_plugin_svg > No cached version of org.apache.xmlgraphics:swing:1.7 available for offline mode. > No cached version of org.apache.xmlgraphics:swing:1.7 available for offline mode. I have looked at osmium and figtree (r-deps) to see how they depend on batik jars, but that didn't help. Is there an r-dep that depends on batik for swing/SVG rendering, preferrably with a gradle build system, that I could copy/learn from? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Security issue in groovy<2.5.0
hello Debian-java, Emmanuel Bourg <ebo...@apache.org> writes: > Le 17/08/2017 à 20:18, Felix Natter a écrit : > >> So the question is: Can I package freeplane without the 'securegroovy' >> library, expecting that groovy 2.5 will be released soon, and will >> shortly after be packaged for Debian? > > Yes ignore securegroovy, we have to directly patch or upgrade our groovy > package in this case. I have backported the single GROOVY-8163 [1] [2] commit (plus a missing import), and pushed the result here: https://anonscm.debian.org/cgit/pkg-java/groovy.git [1] https://issues.apache.org/jira/browse/GROOVY-8163 [2] https://github.com/apache/groovy/commit/0305a38a0cc8f4190a1486c460ebc6f712ad1a07 I have tested this extensively with freeplane. Could someone please consider sponsoring this? I assumed a QA upload because lintian complains about missing Uploader: and because of Paul Wise's advice. Shall I revert to team upload? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Security issue in groovy<2.5.0
殷啟聰 | Kai-Chung Yan <seamli...@gmail.com> writes: > Hello Natter, hi Kai, thanks for the reply. s/Natter/Felix/g ;-) (my first name is Felix) > Since it's just one commit, I suggest you put it as a patch in > `debian/patches`. When someone is updating the package to 2.5.0, she > can just remove it. There is already a 2.4.8-2 in the git pipeline (unreleased) by Miguel Landaeta (CC): https://anonscm.debian.org/cgit/pkg-java/groovy.git In the corresponding bug for 2.4.8-2 (#871857) Miguel says: "I removed myself from uploaders list and prepared a tentative QA upload but I didn't upload it to the archive since the resulting package would be in violation of Debian Policy (§3.3 and §5.6.3). I'd appreciate if somebody else can step in as maintainer." Policy §5.6.3 says: "This is normally an optional field, but if the Maintainer control field names a group of people and a shared email address, the Uploaders field must be present and must contain at least one human with their personal email address." --> groovy currently only has: Maintainer: Debian Java Maintainers <pkg-java-maintain...@lists.alioth.debian.org> (no Uploader:) which seems to violate §5.6.3. So how can we make a policy-compliant team upload without becoming maintainer (I'd like to avoid taking over groovy maintainership if possible)? Shall we set Maintainer: Debian QA Group <packa...@qa.debian.org> according to Policy §3.3, even if we usually do team uploads? Other than that: @Miguel, @Emmanuel, @Kai: do you agree to make a simple 2.4.8-2 release with Miguel's changes only adding that patch? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Security issue in groovy<2.5.0
hello Emmanuel, Felix Natter <fnat...@gmx.net> writes: >> Le 26/08/2017 à 18:14, Felix Natter a écrit : >> >>> The problem is that it may take weeks/months for groovy 2.5 to be >>> released, and weeks/months until it's packaged for Debian. >> >> How big is the fix for Groovy? Do you know which commits should be >> backported? > > It's a single (but nontrivial) commit: > https://github.com/apache/groovy/commit/0305a38a0cc8f4190a1486c460ebc6f712ad1a07 > > The groovy people decided not to backport to groovy 2.4.x, so I am not > sure whether we shall do it? Is there any update on this? What shall I do? I don't mean to be impatient, I was just not sure whether you've seen this. Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Security issue in groovy<2.5.0
Thorsten Glaser <t.gla...@tarent.de> writes: > On Sat, 26 Aug 2017, Felix Natter wrote: hi Thorsten, >> OTOH, this is for Debian unstable/testing... > > Debian unstable is where you upload things to that you expect > to be part of the next Debian stable, and thus in an appropriate > shape; it might make sense for experimental though? This post is about considering to patch groovy-2.4 to fix a sandbox escape in that version, which the groovy people did not want to patch in 2.4.x, but it will be part of 2.5.x. I meant that we might consider using the patch on Debian testing/unstable, because unlike upstream groovy 2.4.x it won't be used in a stable environment soon (i.e. until 2.5.0 is released). Of course, this might neglect Ubuntu releases. Best Regards, -- Felix Natter debian/rules!
Re: Security issue in groovy<2.5.0
Felix Natter <fnat...@gmx.net> writes: > Emmanuel Bourg <ebo...@apache.org> writes: > > hi Emmanuel, > >> Le 26/08/2017 à 18:14, Felix Natter a écrit : >> >>> The problem is that it may take weeks/months for groovy 2.5 to be >>> released, and weeks/months until it's packaged for Debian. >> >> How big is the fix for Groovy? Do you know which commits should be >> backported? > > It's a single (but nontrivial) commit: > https://github.com/apache/groovy/commit/0305a38a0cc8f4190a1486c460ebc6f712ad1a07 > > The groovy people decided not to backport to groovy 2.4.x, so I am not > sure whether we shall do it? OTOH, this is for Debian unstable/testing... Cheers and Best Regards, -- Felix Natter
Re: Security issue in groovy<2.5.0
Emmanuel Bourg <ebo...@apache.org> writes: hi Emmanuel, > Le 26/08/2017 à 18:14, Felix Natter a écrit : > >> The problem is that it may take weeks/months for groovy 2.5 to be >> released, and weeks/months until it's packaged for Debian. > > How big is the fix for Groovy? Do you know which commits should be > backported? It's a single (but nontrivial) commit: https://github.com/apache/groovy/commit/0305a38a0cc8f4190a1486c460ebc6f712ad1a07 The groovy people decided not to backport to groovy 2.4.x, so I am not sure whether we shall do it? Thanks and Best Regards, -- Felix Natter
Re: Security issue in groovy<2.5.0
Emmanuel Bourg <ebo...@apache.org> writes: > Le 17/08/2017 à 20:18, Felix Natter a écrit : hi Emmanuel, >> So the question is: Can I package freeplane without the 'securegroovy' >> library, expecting that groovy 2.5 will be released soon, and will >> shortly after be packaged for Debian? > > Yes ignore securegroovy, we have to directly patch or upgrade our groovy > package in this case. The problem is that it may take weeks/months for groovy 2.5 to be released, and weeks/months until it's packaged for Debian. I would like to package freeplane 1.6.5 this/next week, and I guess freeplane users expect that this version is safe. So shall I package securegroovy, and throw it away soon? Cheers and Best Regards, -- Felix Natter
Re: byte-buddy
Felix Natter <fnat...@gmx.net> writes: > tony mancill <tmanc...@debian.org> writes: > > hello Tony, hello debian-java, >>> [ERROR] Failed to execute goal >>> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile >>> (default-compile) on project byte-buddy-dep: Compilation failure >>> [ERROR] Could not instantiate an instance of processor >>> 'lombok.launch.AnnotationProcessorHider' >> >> Which is essentially the same thing. Is the package building for you in >> a clean sid chroot? > > Sorry, I see this in a pbuilder chroot as well. I also tried the patch > mentioned > in [1], and I got: > > [ERROR] Could not instantiate an instance of processor > 'lombok.launch.AnnotationProcessorHider$AnnotationProcessor' > > This class is in the Debian lombok jar. > > I also tried to change the scope of lombok from provided to compile. > I do not think it is related to the lombok version (1.16.16 vs 1.16.8). > > Has anybody got an idea? As Tony is already the liblombok-java maintainer, shall I ask upstream? Any other idea? Thanks and Best Regards, -- Felix Natter
Re: knopflerfish-osgi 6.1.0 (java9)
Felix Natter <fnat...@gmx.net> writes:
> hello debian-java,
>
> --- a/osgi/framework/build.xml
> +++ b/osgi/framework/build.xml
> @@ -43,7 +43,7 @@
>
>
>
> - location="${topdir}/annotations/osgi.annotation-6.0.1.jar"/>
> + location="/usr/share/java/osgi.annotation.jar"/>
>
>
>
> But I still get:
> [javac]
> /home/felix/knopflerfish-osgi-unstable/knopflerfish-osgi/osgi/framework/src/org/osgi/framework/Constants.java:19:
> error: package org.osgi.annotation.versioning does not exist
It seems the property is ignored, solved by creating a symlink:
ln -s /usr/share/java/osgi.annotation.jar
osgi/annotations/osgi.annotation-6.0.1.jar
Best Regards,
--
Felix Natter
knopflerfish-osgi 6.1.0 (java9)
hello debian-java, I have started to prepare a java9-capable update of knopflerish-osgi: 6.1.0 (needed for java9 support of freeplane), development version pushed here: https://github.com/fnatter/knopflerfish-osgi-debian (I can give you commit rights if you want) The new release requires libosgi-annoation-java, and I added a patch (60_osgi-annotation.patch) to include /usr/share/java/osgi.annotation.jar in the classpath: --- a/osgi/framework/build.xml +++ b/osgi/framework/build.xml @@ -43,7 +43,7 @@ - + But I still get: [javac] /home/felix/knopflerfish-osgi-unstable/knopflerfish-osgi/osgi/framework/src/org/osgi/framework/Constants.java:19: error: package org.osgi.annotation.versioning does not exist Could someone please look into this? Thanks and Best Regards, -- Felix Natter
Re: freeplane auto removal
Sebastiaan Couwenberg <sebas...@xs4all.nl> writes: > On 08/19/2017 10:11 AM, Felix Natter wrote: >>> Am 18.08.2017 um 21:26 schrieb Sebastiaan Couwenberg <sebas...@xs4all.nl>: >>> >>>> On 08/18/2017 09:13 PM, Felix Natter wrote: >>>> What am I missing? >>> >>> The mailer on your system is likely not sending the mails the bts >>> utility generates correctly. >>> >> >> I have used bts(1) on Thursday. However, >> yesterday it worked. > > Because my mailer works correctly. :-) I thought bts(1) would contact the BTS directly instead of trying to send a mail ;-) A mail with empty subject to cont...@bugs.debian.org with these lines in the body: bts severity 870103 important bts tags 870103 + moreinfo unreproducible (and a signature) should have worked? Thank you and Best Regards, -- Felix Natter
Re: freeplane auto removal
> Am 18.08.2017 um 21:26 schrieb Sebastiaan Couwenberg <sebas...@xs4all.nl>: > >> On 08/18/2017 09:13 PM, Felix Natter wrote: >> What am I missing? > > The mailer on your system is likely not sending the mails the bts > utility generates correctly. > I have used bts(1) on Thursday. However, yesterday it worked. Best Regards, Felix > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 >
Re: freeplane auto removal
Felix Natter <fnat...@gmx.net> writes: > done, thank you both (at least I triggered it, should be updated soon). I did this yesterday (and again, a minute ago): bts severity 870103 important bts tags 870103 + moreinfo unreproducible But the bug report still has severity grave and no tags. What am I missing? Thanks and Best Regards, -- Felix Natter
Re: freeplane auto removal
Markus Koschany <a...@debian.org> writes: > Am 17.08.2017 um 21:01 schrieb Felix Natter: > [...] >> --> So what do I do with #870103, which is grave, but is not >> reproducible and it seems it does not affect all users? > > Hi, hi Bas, hi Markus, > I suggest to lower the severity to important and tag the bug as > "moreinfo". Apparently it is not a general issue and maybe more subtle. > Usually you will see that more people complain about an unusable package > especially when we talk about packages with a significant popcon value. > If the bug reporter does not reply to your questions, the only thing you > can do is wait for more information from other users. done, thank you both (at least I triggered it, should be updated soon). Cheers and Best Regards, -- Felix Natter
freeplane auto removal
hi, I wonder whether the auto-removal of freeplane due to a issue [1] that I can't reproduce does make sense (14 days left)? I have a guess at a workaround, but the reporter does not react. Also, my QA page [2] reads like it would be removed from stretch as well? I guess this is just a display problem since the "1.5.18-1" box exists only once.. --> So what do I do with #870103, which is grave, but is not reproducible and it seems it does not affect all users? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870103 [2] https://qa.debian.org/developer.php?login=fnat...@gmx.net Thanks and Best Regards, -- Felix Natter
Security issue in groovy<2.5.0
hello debian-java, freeplane 1.5/1.6 added a library [1] which uses byte-buddy to fix a security problem in groovy < 2.5.0 [2]. The fix will be included in groovy 2.5, which should be released soon (currently at 2.5.0-beta-2). So the question is: Can I package freeplane without the 'securegroovy' library, expecting that groovy 2.5 will be released soon, and will shortly after be packaged for Debian? [1] https://github.com/dpolivaev/securegroovy/ [2] https://issues.apache.org/jira/browse/GROOVY-8163 (freeplane maps include groovy scripts which can escape the sandbox) Thanks and Best Regards, -- Felix Natter
Re: freeplane deb - was: freeplane SNAP / gradle-debian-helper: option for turning off --offline
Oliver Kopp <kopp@gmail.com> writes: > Hi, hi Oliver, > 2017-08-12 10:57 GMT+02:00 Emmanuel Bourg <ebo...@apache.org>: > >> I think it would be easier to simply run gradle directly and build the >> .deb with jdeb. > > Thank you for the pointer. jdeb cannot do gradle (see > https://github.com/tcurdt/jdeb/issues/132). But there is > gradle-ospackage-plugin from Netflix: > https://github.com/nebula-plugins/gradle-ospackage-plugin. Felix, > maybe this could worth a try? This looks really good, I'll try it :-) Cheers and Best Regards, -- Felix Natter
Re: byte-buddy
tony mancill <tmanc...@debian.org> writes: hello Tony, >> [ERROR] Failed to execute goal >> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile >> (default-compile) on project byte-buddy-dep: Compilation failure >> [ERROR] Could not instantiate an instance of processor >> 'lombok.launch.AnnotationProcessorHider' > > Which is essentially the same thing. Is the package building for you in > a clean sid chroot? Sorry, I see this in a pbuilder chroot as well. I also tried the patch mentioned in [1], and I got: [ERROR] Could not instantiate an instance of processor 'lombok.launch.AnnotationProcessorHider$AnnotationProcessor' This class is in the Debian lombok jar. I also tried to change the scope of lombok from provided to compile. I do not think it is related to the lombok version (1.16.16 vs 1.16.8). Has anybody got an idea? Thanks and Best Regards, -- Felix Natter
byte-buddy
hello Debian-java, https://anonscm.debian.org/cgit/pkg-java/libbyte-buddy-java.git has been superseded by: https://anonscm.debian.org/cgit/pkg-java/byte-buddy.git How can I remove the first one? Just do a: - cd /git/pkg-java - mv libbyte-buddy-java.git /tmp on git-debian.org? Also, could we do a new upload of 1.7.1+dfsg1-1? byte-buddy (1.7.1+dfsg1-1) UNRELEASED; urgency=medium * fix watch file (releases instead of tags, dversionmangle) * remove precompiled content from orig-source -- Felix Natter <fnat...@gmx.net> Sat, 29 Jul 2017 13:03:14 +0200 Many Thanks and Best Regards, -- Felix Natter
freeplane SNAP / gradle-debian-helper: option for turning off --offline
hello Debian-java, as a last resort, I would like to provide up-to-date freeplane .debs for LTS Debian/Ubuntu systems which use the maven artifacts [1]. The easiest way to do this [2] is to build the package without patches and without gradle --offline. Could we consider adding such an option to gradle-debian-helper? I know it's non-free, but the alternative is that users install the freeplane binary package, which is essentially the same thing, but without mime mappings, a bit harder to install etc. Of course the package will only be provided by upstream. [1] In almost each release, there are file format changes, so for some users, it is necessary to have the latest release installed in order to be able to exchange data with other users. [2] I tried snap/snapcraft, but this requires the JRE to be included in the package which creates a ~100Mb package. Cheers and Best Regards, -- Felix Natter
Re: Notes from the DebConf 17 Java BOF
hello Debian-java, thanks for the work done in the BoF! Markus Koschany <a...@debian.org> writes: > new ideas of packaging Java applications in general. Maybe flatpack or > other packaging formats may be a way for us to provide some Java apps at > all. That might be not perfect but better than nothing. Some notes: I tried to snap/snapcraft for freeplane: - there is a gradle plugin - some hacking with a wrapper script is needed - not sure if it can read config from $HOME/.config (maybe some more hacking is needed) - unfortunately, the jdk _must_ be included, that's why I dropped it Best Regards, -- Felix Natter
Re: Bug#866134: RFS: jajuk/1:1.10.9+dfsg2-3
Gianfranco Costamagna <locutusofb...@debian.org> writes: > Hello Felix, hello Gianfranco, >>I am looking for a sponsor for my package "jajuk". This fixes a simple >>classpath error reported against Ubuntu. > > > sponsored, but... Thanks! > debdiff jajuk_1.10.9+dfsg2-*.dsc > > dpkg-source: error: file /tmp/jajuk_1.10.9+dfsg2.orig.tar.gz has size 2897335 > instead of expected 2900755 > Use of uninitialized value $from in stat at /usr/share/perl/5.24/File/Copy.pm > line 211. > Use of uninitialized value $from in string eq at > /usr/share/perl/5.24/File/Copy.pm line 64. > Use of uninitialized value $from in -d at /usr/share/perl/5.24/File/Copy.pm > line 96. > Use of uninitialized value $_[0] in substitution (s///) at > /usr/share/perl/5.24/File/Basename.pm line 180. > fileparse(): need a valid pathname at > /usr/share/perl/5.24/File/Copy.pm line 51. I think the reason was that I built first without -sa, then dput mentors complained, and I built again with -sa, without clearing .. --> Could that be the reason? I apologize! Best Regards, -- Felix Natter
RFS: jajuk/1:1.10.9+dfsg2-3
Package: sponsorship-requests Severity: normal Dear mentors, hello Markus, I am looking for a sponsor for my package "jajuk". This fixes a simple classpath error reported against Ubuntu. * Package name: jajuk Version : 1:1.10.9+dfsg2-3 Upstream Author : Bertrand Florat <bertr...@florat.net> and The Jajuk Team * URL : http://www.jajuk.info * License : GPL-2+ Section : sound It builds those binary packages: jajuk - advanced jukebox and music organizer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/jajuk Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/j/jajuk/jajuk_1.10.9+dfsg2-3.dsc Changes since the last upload: jajuk (1:1.10.9+dfsg2-3) unstable; urgency=medium * Include jgoodies-common.jar in classpath (LP: #1650019) * Update standards-version to 4.0.0 (no changes) -- Felix Natter <fnat...@gmx.net> Tue, 27 Jun 2017 16:45:50 +0200 Regards, -- Felix Natter
Re: openjfx usage in megan-ce
Andreas Tille <andr...@an3as.eu> writes: > Hi Felix, Hello Andreas! > On Sat, May 20, 2017 at 04:23:31PM +0200, Felix Natter wrote: >> > I had a first packaging centric look on megan-ce[1]. While there >> > are several problems I stumbled upon several compile errors like >> >> I cannot currently build this because my libjloda-java is at 0.0+20161018. > > It is in experimental due to freeze policy. Ok, pulled it, thanks. >> > [javac] >> > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:28: >> > error: package javafx.geometry does not exist >> > [javac] import javafx.geometry.Insets; >> > [javac] ^ >> > [javac] >> > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:29: >> > error: package javafx.scene does not exist >> > [javac] import javafx.scene.Scene; >> > [javac]^ >> > [javac] >> > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:30: >> > error: package javafx.scene.control does not exist >> > [javac] import javafx.scene.control.*; >> > [javac] ^ >> > [javac] >> > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:31: >> > error: package javafx.scene.layout does not exist >> > [javac] import javafx.scene.layout.BorderPane; >> > [javac] ^ >> > [javac] >> > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:32: >> > error: package javafx.scene.layout does not exist >> > [javac] import javafx.scene.layout.HBox; >> > [javac] ^ >> > >> > To solve this I added libopenjfx-java Build-Dependency but this does not >> > seem to help. Any idea how I could fix this? >> >> You have put the wrong openjfx jar into debian/manifest: >> >> $ jar tf /usr/share/java/openjfx/lib/javafx-mx.jar | grep javafx.geometry >> >> >> $ jar tf /usr/share/java/openjfx/jre/lib/ext/jfxrt.jar | grep javafx.geometry >> [...] >> javafx/geometry/Insets.class >> [...] > > Sounds convincing. :-) > >> This simple patch should work: >> >> diff --git a/debian/manifest b/debian/manifest >> index 9b9c713..5b60c58 100644 >> --- a/debian/manifest >> +++ b/debian/manifest >> @@ -1,3 +1,3 @@ >> /usr/share/java/megan-ce.jar: >> Main-Class: megan-ce.MeganRun >> - Class-Path: /usr/share/java/jloda.jar /usr/share/java/colt.jar >> /usr/share/java/commons-math3.jar /usr/share/java/gson.jar >> /usr/share/java/openjfx/lib/javafx-mx.jar >> + Class-Path: /usr/share/java/jloda.jar /usr/share/java/colt.jar >> /usr/share/java/commons-math3.jar /usr/share/java/gson.jar >> /usr/share/java/openjfx/jre/lib/ext/jfxrt.jar It seems the CLASS_PATH in debian/rules is not used during build, we need to patch "build.classpath" in antbuild/build.xml, like this (last patch): --- a/antbuild/build.xml +++ b/antbuild/build.xml @@ -21,7 +21,10 @@ - + + + + (or, as an alternative, succeed in making build.xml use CLASS_PATH) Note that you need to include all these libraries in debian/manifest too, otherwise the program will fail during runtime (which might not be noticed until a particular functionality is used). > I've just pushed > As I said this is in experimental. I also noticed that there is not > only trouble with javafx: > > ... > [javac] > /build/megan-ce-0.0+20170515/antbuild/src/megan/biom/BiomData.java:21: error: > package com.google.gson does not exist > [javac] import com.google.gson.Gson; > [javac] ^ > [javac] > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:22: > error: package javafx.application does not exist > [javac] import javafx.application.Application; > [javac] ^ > [javac] > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:23: > error: package javafx.beans.value does not exist > [javac] import javafx.beans.value.ChangeListener; > ... > > So Gson is also not found. :-( gson and javax are found, now that we change the correct classpath, but several other libraries are used: build1.log:53:[javac] import malt.align.SimpleAligner4DNA; build1.log:56:[javac] import malt.util.MurmurHash3; --> there is only 'smalt' in Debian? build1.log:59:[javac] import Jama.Eigen
Re: openjfx usage in megan-ce
hello Andreas, Felix Natter <fnat...@gmx.net> writes: > This simple patch should work: > > diff --git a/debian/manifest b/debian/manifest > index 9b9c713..5b60c58 100644 > --- a/debian/manifest > +++ b/debian/manifest > @@ -1,3 +1,3 @@ > /usr/share/java/megan-ce.jar: > Main-Class: megan-ce.MeganRun > - Class-Path: /usr/share/java/jloda.jar /usr/share/java/colt.jar > /usr/share/java/commons-math3.jar /usr/share/java/gson.jar > /usr/share/java/openjfx/lib/javafx-mx.jar > + Class-Path: /usr/share/java/jloda.jar /usr/share/java/colt.jar > /usr/share/java/commons-math3.jar /usr/share/java/gson.jar > /usr/share/java/openjfx/jre/lib/ext/jfxrt.jar Sorry, this is for runtime only. You probably know that you also need to change debian/rules. Cheers and Best Regards, -- Felix Natter
Re: openjfx usage in megan-ce
Andreas Tille <andr...@an3as.eu> writes: > Hi, hello Andreas, > I had a first packaging centric look on megan-ce[1]. While there > are several problems I stumbled upon several compile errors like I cannot currently build this because my libjloda-java is at 0.0+20161018. > [javac] > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:28: > error: package javafx.geometry does not exist > [javac] import javafx.geometry.Insets; > [javac] ^ > [javac] > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:29: > error: package javafx.scene does not exist > [javac] import javafx.scene.Scene; > [javac]^ > [javac] > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:30: > error: package javafx.scene.control does not exist > [javac] import javafx.scene.control.*; > [javac] ^ > [javac] > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:31: > error: package javafx.scene.layout does not exist > [javac] import javafx.scene.layout.BorderPane; > [javac] ^ > [javac] > /build/megan-ce-0.0+20170515/antbuild/src/megan/blastclient/BlastProgram.java:32: > error: package javafx.scene.layout does not exist > [javac] import javafx.scene.layout.HBox; > [javac] ^ > > To solve this I added libopenjfx-java Build-Dependency but this does not > seem to help. Any idea how I could fix this? You have put the wrong openjfx jar into debian/manifest: $ jar tf /usr/share/java/openjfx/lib/javafx-mx.jar | grep javafx.geometry $ jar tf /usr/share/java/openjfx/jre/lib/ext/jfxrt.jar | grep javafx.geometry [...] javafx/geometry/Insets.class [...] This simple patch should work: diff --git a/debian/manifest b/debian/manifest index 9b9c713..5b60c58 100644 --- a/debian/manifest +++ b/debian/manifest @@ -1,3 +1,3 @@ /usr/share/java/megan-ce.jar: Main-Class: megan-ce.MeganRun - Class-Path: /usr/share/java/jloda.jar /usr/share/java/colt.jar /usr/share/java/commons-math3.jar /usr/share/java/gson.jar /usr/share/java/openjfx/lib/javafx-mx.jar + Class-Path: /usr/share/java/jloda.jar /usr/share/java/colt.jar /usr/share/java/commons-math3.jar /usr/share/java/gson.jar /usr/share/java/openjfx/jre/lib/ext/jfxrt.jar If you need more help with this package, please tell me how to get libjloda-java (>= 0.0+20170502). Cheers and Best Regards, -- Felix Natter
Aw: Re: Help needed for tn-seqexplorer Java package
hello Olivier, hello Andreas, > I do not know how to include resources in jar with jh_build, never did > it before, but Java team should be able to answer this See this rules file: https://anonscm.debian.org/cgit/pkg-java/libjsyntaxpane-java.git/tree/debian/rules Cheers and Best Regards, Felix
Re: freeplane-1.5.18-2: Fix for PDF Export
Markus Koschany <a...@debian.org> writes:
> Am 12.03.2017 um 17:35 schrieb Felix Natter:
>> hello debina-java,
>>
>> I just fixed a freeplane PDF Export problem that was reported for
>> stretch and Ubuntu 16.10 (Debian: #856058, LP: #172).
>>
>> The VCS is here:
>> https://anonscm.debian.org/cgit/pkg-java/freeplane.git
>>
>> Of course it is lintian-clean and pbuilder-tested.
>>
>> I've targeted experimental in the changelog because I don't know whether
>> this should make it into stretch. The fix is simple:
>>
>> https://anonscm.debian.org/cgit/pkg-java/freeplane.git/commit/?id=bd9473fe5de7cd81487de27b717462277df737cf
>> but it "only" concerns PDF export.
>
> Hi Felix,
hello Markus,
> I can sponsor your package. I think the broken PDF export feature is
> worth to be fixed in Stretch too. Let's upload to unstable and ask for a
> freeze exception.
Please ignore this request for now (!). I just tested again on two machines
and now I get an infinite loop (without log output) on PDF export with
1.5.18-2.
It's not that bad since in 1.6.x freeplane will use svgSalamander which
breaks batik-SVG/PDF export, and thus people will have to use a pdf
printer ("apt-get install printer-driver-cups-pdf") anyway.
Thanks and Best Regards,
--
Felix Natter
freeplane-1.5.18-2: Fix for PDF Export
hello debina-java, I just fixed a freeplane PDF Export problem that was reported for stretch and Ubuntu 16.10 (Debian: #856058, LP: #172). The VCS is here: https://anonscm.debian.org/cgit/pkg-java/freeplane.git Of course it is lintian-clean and pbuilder-tested. I've targeted experimental in the changelog because I don't know whether this should make it into stretch. The fix is simple: https://anonscm.debian.org/cgit/pkg-java/freeplane.git/commit/?id=bd9473fe5de7cd81487de27b717462277df737cf but it "only" concerns PDF export. Risk is low because the changes only concern the SVG/PDF plugin, which was completely broken in 1.5.18-1. The first export takes unsually long, but I don't think I can change this. BTW: During push to alioth, I got this: remote: Sending notification emails to: pkg-java-comm...@lists.alioth.debian.org remote: Pushing changes to the GitHub mirror https://github.com/Debian/freeplane... remote: remote: Repository not found. remote: fatal: repository 'https://debian-bot:cb3b939bbf5eedc5ce62337388459998f3ea3...@github.com/Debian/freeplane.git/' not found To git+ssh://git.debian.org/git/pkg-java/freeplane.git 70ba8dc..bd9473f master -> master --> Shall I report this? Thanks and Best Regards, -- Felix Natter
Re: "Width (0) and height (0) must be non-zero occurred while creating cursor CopyDrop.32x32"
Thorsten Glaser <t.gla...@tarent.de> writes: > On Tue, 31 Jan 2017, tony mancill wrote: > >> 5.x). At this point I think the behavior is isolated to VirtualBox. >> However, I am not aware of a work-around. > > I’ve talked to a VirtualBox engineer (then Sun) at LinuxTag > about emulation bugs related to BSD. He said they were aware > of certain bugs, but as they don’t get paid to fix them, and > their only targets to emulate correctly were Windows and Solaris, > that’s all they care about. (It got so bad (also, users com‐ > plaining about the “bug”) the MirBSD installer now refuses > operation under VirtualBox, although it seems to be slightly > better if you have “hardware acceleration” enabled.) > > So, in short, I’d not care about bugs that only occur due > to broken emulation. Thank you both for confirming it's a virtualbox issue. A workaround that seems ok is to switch the desktop environment: I just switched from xfce4 to e17 and the problem is gone (for a short amount of time?). Otherwise: Which sid virtualization do you use for building/testing packages? I guess Xen would be very efficient. But is it a risk to run Xen (Dom0?) on a production desktop machine? And I can run a "remote desktop" server on a Xen instance to test GUI programs? Cheers and Best Regards, -- Felix Natter
"Width (0) and height (0) must be non-zero occurred while creating cursor CopyDrop.32x32"
corator.display(Unknown Source) at org.jajuk.services.startup.StartupGUIService$6.run(Unknown Source) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.awt.EventQueue.dispatchEvent(EventQueue.java:726) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) Caused by: java.lang.RuntimeException: failed to load system cursor: DnD.Cursor.CopyDrop : cannot load system cursor: CopyDrop.32x32 at java.awt.dnd.DragSource.load(DragSource.java:135) at java.awt.dnd.DragSource.(DragSource.java:148) ... 22 more Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: Could not initialize class java.awt.dnd.DragSource at org.jajuk.ui.helpers.TableTransferHandler.(Unknown Source) at org.jajuk.ui.views.AbstractTableView.createGenericGUI(Unknown Source) at org.jajuk.ui.views.WebRadioView.shortCall(Unknown Source) at org.jajuk.util.UtilGUI$5.done(Unknown Source) at javax.swing.SwingWorker$5.run(SwingWorker.java:737) at javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(SwingWorker.java:832) at sun.swing.AccumulativeRunnable.run(AccumulativeRunnable.java:112) at javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(SwingWorker.java:842) at javax.swing.Timer.fireActionPerformed(Timer.java:313) at javax.swing.Timer$DoPostEvent.run(Timer.java:245) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.awt.EventQueue.dispatchEvent(EventQueue.java:726) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- Felix Natter
Re: Please upload freeplane-1.5.18-1
Markus Koschany <a...@debian.org> writes: > 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. Hello Markus, thanks for the upload! However, there seems to be a problem due to the fact that freeplane 1.5.16-3 did not yet migrate to testing before we uploaded 1.5.18-1 to unstable: - https://qa.debian.org/excuses.php?package=freeplane: should migrate in 7 days - https://udd.debian.org/cgi-bin/autoremovals.cgi says that freeplane will be removed in 16.7 days. Do we need to act here? Many Thanks and Best Regards, -- Felix Natter
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: Freeplane and latest jgoodies-forms: strange runtime error
hello debian-java, (here are the pastebins which do not expire: http://paste.debian.net/900764/ http://paste.debian.net/900765/) I think the problem was simply that freeplane needed to be recompiled with the new jgoodies-forms [1]. First we made freeplane-1.5.16-2 compatible with the new jgoodies-forms-1.9.0, then we uploaded the new jgoodies-forms, which apparently did not trigger a rebuild of freeplane. How does debian work here, when are rebuilds triggered? So for these types of changes (the type of Borders.DLU2 changed from Borders to Paddings, see decompiled code above), I always need to provide a freeplane update? [1] https://docs.oracle.com/javase/7/docs/api/java/lang/NoSuchFieldError.html Thanks and Best Regards, Felix Felix Natter
Freeplane and latest jgoodies-forms: strange runtime error
tion (converted to relative paths). For example, the jgoodies deps look like [3]: [...] /commons-codec-debian.jar, ../../../maven-repo/com/jgoodies/jgoodies- forms/debian/jgoodies-forms-debian.jar, ../../../java/idw.jar, ../../ ../maven-repo/com/lightdev/app/shtm/simplyhtml/SimplyHTML/debian/Simp lyHTML-debian.jar, ../../../maven-repo/com/jgoodies/jgoodies-common/1 .x/jgoodies-common-1.x.jar [...] which looks ok to me. [3] /usr/share/freeplane/core/org.freeplane.core/META-INF/MANIFEST.MF Decompilation of jgoodies-forms-debian.jar yields (on a system where freeplane does not start due to above error): Borders.java: http://paste.debian.net/900749/ Paddings.java: http://paste.debian.net/900750/ Which looks good, but in theory the static initializer of Borders could run before the static initializer of Paddings, in which case DLU2 could not be initialized? (on the other hand, the problem is not reproducible upstream, and the upstream's maven artifact for jgoodies-forms-1.9.0 looks similar when decompiled) Any hints are appreciated! Many Thanks and Best Regards, -- Felix Natter
Aw: ~twerner/jar-content.txt.bz2
hello Oliver, maybe this is it? https://ftp-master.debian.org/users/twerner/jar-content.txt.gz I can help with gradle and gradle packaging. Cheers and Best Regards, Felix Felix Natter Gesendet: Sonntag, 16. Oktober 2016 um 23:52 Uhr Von: "Oliver Kopp" <kopp@gmail.com> An: debian-java@lists.debian.org Betreff: ~twerner/jar-content.txt.bz2 Hi, I'm Oliver, the main maintainer of JabRef. Together with Gregor and Tony, I'm trying to update JabRef from 2.10 to 3.7 (released soon) in Debian. The progress is tracked at https://github.com/koppor/jabref/issues/135 . I checked https://wiki.debian.org/JavaPackagingFAQ, where http://ftp-master.debian.org/~twerner/jar-content.txt.bz2 is linked. However, this file is 404. Is this still the way to check for existing JARs in Debian? Finally, may I just ask whether there is a gradle packaging expert around here? O:) Cheers, Oliver
Re: knopflerfish-osgi 5.2.0-1 breaks freeplane
Emmanuel Bourg <ebo...@apache.org> writes: > Hi Felix, hello Emmanuel, > I think I spotted the issue. The 'exports' file is missing from the > knopflerfish jar. In the previous version it was included in the > upstream tarball and the code to regenerate it was disabled by > 30_fix_jar_build.patch. In the latest version the exports file is no > longer in the tarball. I enabled the build of the Ant task, this allowed > me to remove the patch and now the exports file is properly generated. > > Could you try building knopflerfish-osgi from the current HEAD of the > Git repository and test again with freeplane please? If it works well > I'll upload the update. Works great. Good work, thank you! Could you please also close this bug with the upload, too? https://bugs.launchpad.net/ubuntu/+source/freeplane/+bug/1631361 Many Thanks and Best Regards, -- Felix Natter
Re: knopflerfish-osgi 5.2.0-1 breaks freeplane
Felix Natter <fnat...@gmx.net> writes: > hello Emmanuel, > > your knopflerfish-osgi-5.2.0-1 update breaks freeplane: > > felix@debianunstable:~$ freeplane > org.knopflerfish.framework.readonly=true > org.knopflerfish.gosg.jars=reference:file:/usr/share/freeplane/core/ > org.freeplane.basedirectory=/usr/share/freeplane > java.security.policy=/usr/share/freeplane/freeplane.policy > org.osgi.framework.storage=/usr/share/freeplane/fwdir > Knopflerfish OSGi framework launcher, version > Copyright 2003-2016 Knopflerfish. All Rights Reserved. > See http://www.knopflerfish.org for more information. > > java.lang.IllegalArgumentException: Failed to read exports: > java.io.FileNotFoundException: /home/felix/exports (No such file or directory) > at > org.knopflerfish.framework.SystemBundle.addSysPackagesFromFile(SystemBundle.java:699) > at > org.knopflerfish.framework.SystemBundle.initSystemBundle(SystemBundle.java:557) > at > org.knopflerfish.framework.FrameworkContext.init(FrameworkContext.java:402) > at org.knopflerfish.framework.SystemBundle.doInit(SystemBundle.java:622) > at org.knopflerfish.framework.SystemBundle.init(SystemBundle.java:152) > at org.knopflerfish.framework.Main.assertFramework(Main.java:446) > at org.knopflerfish.framework.Main.handleArgs(Main.java:546) > at org.knopflerfish.framework.Main.start(Main.java:224) > at org.knopflerfish.framework.Main.main(Main.java:156) > at org.freeplane.launcher.Launcher.run(Launcher.java:115) > at org.freeplane.launcher.Launcher.launch(Launcher.java:80) > at org.freeplane.launcher.Launcher.main(Launcher.java:67) > Error: Command "-istart org.freeplane.core" failed, Failed to read exports: > java.io.FileNotFoundException: /home/felix/exports (No such file or directory) > > Could you please help me resolve this? > > Freeplane is a bit special in that it does use extracted OSGi jars: > > felix@debianunstable:/$ find /usr/share/freeplane/core/org.freeplane.core/ > /usr/share/freeplane/core/org.freeplane.core/ > /usr/share/freeplane/core/org.freeplane.core/lib > /usr/share/freeplane/core/org.freeplane.core/lib/freeplaneeditor-1.5.jar > /usr/share/freeplane/core/org.freeplane.core/lib/jortho-1.5.jar > /usr/share/freeplane/core/org.freeplane.core/lib/freeplaneviewer.jar > /usr/share/freeplane/core/org.freeplane.core/lib/freeplaneosgi-1.5.jar > /usr/share/freeplane/core/org.freeplane.core/META-INF > /usr/share/freeplane/core/org.freeplane.core/META-INF/MANIFEST.MF > > Shall I create a bug (RC?) to avoid that the package migrates to > testing? On the other hand, it has already been included in Ubuntu 16.10 > [1]. > > How about asking upstream [2]? This looks like an upstream problem with freeplane's extracted OSGi "jars", so I created an upstream issue: https://github.com/knopflerfish/knopflerfish.org/issues/4 Following Markus' advice, I create an RC critical bug to avoid that knopflerfish-osgi-5.2.0-1 migrates to testing: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840130 Can we tell the Ubuntu (16.10) people to revert to the old knopflerfish-osgi until we fixed this? Cheers and Best Regards, -- Felix Natter
freeplane-1.5.16-1
hello Debian-Java, I have updated freeplane to 1.5.16, which fixes among others a HTML persistency problem. Would someone please consider sponsoring this? The VCS is here: https://anonscm.debian.org/cgit/pkg-java/freeplane.git No dependency / build system changes, no lintians, tested with pbuilder. Many Thanks and Best Regards, -- Felix Natter
Re: RFS: freeplane/1.5.15-1
Markus Koschany <a...@debian.org> writes: > On 27.08.2016 14:08, Felix Natter wrote: >> >> Package: sponsorship-requests >> Severity: normal >> >> Dear mentors, >> >> I am looking for a sponsor for my package "freeplane" > > Hi Felix. > > Thanks for the update. I've just uploaded freeplane. > > By the way you don't need to file sponsorship-requests for pkg-java > packages. Asking on debian-java is sufficient. Thank you, have a nice weekend! -- Felix Natter
RFS: freeplane/1.5.15-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "freeplane" * Package name: freeplane Version : 1.5.15-1 Upstream Author : Dimitry Polivaev <dpoliv...@gmx.de> * URL : http://freeplane.org * License : GPL-2+ Section : editors It builds those binary packages: freeplane - Java program for working with Mind Maps freeplane-scripting-api - Java program for working with Mind Maps (groovy scripting API) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/freeplane Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/freeplane/freeplane_1.5.15-1.dsc More information about hello can be obtained from http://freeplane.org Changes since the last upload: freeplane (1.5.15-1) unstable; urgency=medium * New upstream version * Use compile instead of mergedViewerDependencies for mnemonicsetter since we don't use the applet (signature required!) and to avoid possible upgrade issues. -- Felix Natter <fnat...@gmx.net> Sat, 27 Aug 2016 13:16:18 +0200 Packaging VCS is available at: https://anonscm.debian.org/cgit/pkg-java/freeplane.git https://anonscm.debian.org/git/pkg-java/freeplane.git Many Thanks and Best Regards, -- Felix Natter
Re: Bug#832985: RFS: svgsalamander/1.0.0+dfsg1-1
Sebastiaan Couwenberg <sebas...@xs4all.nl> writes: > Hi Felix, hi Sebastiaan, > Thanks for your changes. > > On 08/06/2016 04:35 PM, Felix Natter wrote: >> Sebastiaan Couwenberg writes: >>> Consider adding the --parallel option to dh in debian/rules to enable >>> the use of parallel builds with DEB_BUILD_OPTIONS="parallel=". >> >> done. (although compilation takes less than a few seconds). > > The benefit of parallel builds for small packages is limited, adding the > --parallel option is mostly a best practice because without it debhelper > won't enable parallel support even when it's beneficial. I maintain a > couple of big packages for which you don't won't non-parallel builds as > those take several hours, instead of under an hour with > DEB_BUILD_OPTIONS="parallel=3". Yes, I agree it's best practice. > debhelper compat level 10 defaults to --parallel for all buildsystems > that support parallel building, which is a nice improvement. But compat > level 10 is not well supported in stable yet. Good to know. >>> The watch file can also be improved to handle common issues [0], like >>> the attached version for example. >> >> I added your watch file, thank you. >> So that I understand this: >> - version=3 is preferred >> - make archive type variable >> - make dversionmangle more general (backports etc.) >> - make uversionmangle more general: >> +uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/;s/RC/rc/,\ >> --> is this best practice for github tarballs? Otherwise I think this is >> difficult because every upstream project has different terminology. >> >> --> Maybe the uscan man page should be extended regarding this? >> (it contains a github example hard-coded for tar.gz) > > Because uscan in jessie doesn't support version=4 yet, I prefer > version=3 watch files until stretch is stable. The downgrade for > svgSalamander is appreciated. Ok, thanks for the explanation. > The uversionmangle is a best practice in general, and is documented on > the wiki [0]. Because the gbp import-orig complains about uppercase RC > that is additionally translated to lowercase. > > Because the version captured in debian/watch included non-digets > (\d+\S+) you need to handle pre-releases with the uversionmangle rule, > otherwise version 1.0.0-rc1 will not precede version 1.0.0. > > [0] https://wiki.debian.org/debian/watch#Common_mistakes I'll read that page again. >>> Also consider adding upstream metadata [1]. >> >> I added this. > > I've committed a few improvements to the upstream metadata before > sponsoring the upload. Most importantly fixing the Repository URL to > include the .git suffix required for `git clone`. I've also added the > Repository-Browse field (without the .git suffix). Ok seems I was too quick copying from an existing example ;-) > I've also added a gbp.conf file to use pristine-tar by default, to not > require the --(git-)pristine-tar options for the git-buildpackage > commands. Ok, great. Many Thanks for the fixes and for sponsoring, Cheers and Best Regards, -- Felix Natter
Re: Bug#832985: RFS: svgsalamander/1.0.0+dfsg1-1
Sebastiaan Couwenberg <sebas...@xs4all.nl> writes: > Hi Felix, hello Bas, thank you very much for the detailed review. > I've had a look at your package and some comments follow. In general the > package looks good, but there is room for improvement. > > Please consider bumping the debhelper compatibility to 9. done + cme fix dpkg-control. > Also change the LGPL-2.0 shortname to LGPL-2+ to better reflects the "or > (at your option) any later version" clause. done. > The Forwarded header in > 0004-Use-system-awt-gradient-instead-of-the-embedded-batik.patch & > 0006-modify-broken-upstream-pom.patch can also be improved. For the > former "not-needed" is more appropriate than "no" with note, not-needed > is probably also appropriate for the latter. done. Upstream knows about the broken POM (0006), so I put in not-needed there. > The README.source should be updated to reflect the change to GitHub > tarballs. done. I put in both "signatures", since some stuff is from Nicolas. [...] See the get-orig-source target for debian/rules to fetch a clean tarball. -- Felix Natter <fnat...@gmx.net> Sat, 6 Aug 2016 15:41:00 +0200 -- Nicolas Dandrimont <nicolas.dandrim...@crans.org>, Sun, 6 Mar 2011 15:07:47 +0100 > Consider adding the --parallel option to dh in debian/rules to enable > the use of parallel builds with DEB_BUILD_OPTIONS="parallel=". done. (although compilation takes less than a few seconds). > The watch file can also be improved to handle common issues [0], like > the attached version for example. I added your watch file, thank you. So that I understand this: - version=3 is preferred - make archive type variable - make dversionmangle more general (backports etc.) - make uversionmangle more general: +uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/;s/RC/rc/,\ --> is this best practice for github tarballs? Otherwise I think this is difficult because every upstream project has different terminology. --> Maybe the uscan man page should be extended regarding this? (it contains a github example hard-coded for tar.gz) > Also consider adding upstream metadata [1]. I added this. New Changelog: svgsalamander (1.0.0+dfsg1-1) unstable; urgency=medium * New upstream version, now on github * Update README.source (source pulled from github release) * Add watch file (from Sebastiaan Couwenberg <sebas...@xs4all.nl>) * Use Files-Excluded: instead of repack script * Do not call netbeans ant targets by setting mkdist.disabled * Fix the pom to be installed by maven-repo-helper (version=1.0.0, no deps) * Update standards-version to 3.9.8 (no changes) * Fix license short names (BSD->BSD-3-clause, LGPL-2.0->LGPL-2+) * Fix lintians * Add DEP3 patch headers * Add upstream metadata * Bump debhelper compat to 9 -- Felix Natter <fnat...@gmx.net> Sat, 06 Aug 2016 16:16:37 +0200 Many Thanks and Best Regards, -- Felix Natter
RFS: svgsalamander/1.0.0+dfsg1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "svgsalamander" * Package name: svgsalamander Version : 1.0.0+dfsg1-1 Upstream Author : Mark McKay <m...@kitfox.com> * URL : https://github.com/blackears/svgSalamander/ * License : LGPL-2.0 or BSD-3-clause Section : java It builds those binary packages: libsvgsalamander-java - SVG engine for Java libsvgsalamander-java-doc - SVG engine for Java (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/svgsalamander Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/svgsalamander/svgsalamander_1.0.0+dfsg1-1.dsc More information about svgsalamander can be obtained from https://github.com/blackears/svgSalamander/ Changes since the last upload: svgsalamander (1.0.0+dfsg1-1) unstable; urgency=medium * New upstream version, now on github * Add watch file * Use Files-Excluded: instead of repack script * Do not call netbeans ant targets by setting mkdist.disabled * Fix the pom to be installed by maven-repo-helper (version=1.0.0, no deps) * Update standards-version to 3.9.8 (no changes) * Fix license short name (BSD->BSD-3-clause) * Fix lintians * Add DEP3 patch headers -- Felix Natter <fnat...@gmx.net> Sat, 30 Jul 2016 11:28:28 +0200 I built this with pbuilder and tested with the r-dep jsom. Thanks and Best Regards, -- Felix Natter
RFS: svgsalamander/1.0.0+dfsg1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "svgsalamander" * Package name: svgsalamander Version : 1.0.0+dfsg1-1 Upstream Author : Mark McKay <m...@kitfox.com> * URL : https://github.com/blackears/svgSalamander/ * License : LGPL-2.0 or BSD-3-clause Section : java It builds those binary packages: libsvgsalamander-java - SVG engine for Java libsvgsalamander-java-doc - SVG engine for Java (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/svgsalamander Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/svgsalamander/svgsalamander_1.0.0+dfsg1-1.dsc More information about svgsalamander can be obtained from https://github.com/blackears/svgSalamander/ Changes since the last upload: svgsalamander (1.0.0+dfsg1-1) unstable; urgency=medium * New upstream version, now on github * Add watch file * Use Files-Excluded: instead of repack script * Do not call netbeans ant targets by setting mkdist.disabled * Fix the pom to be installed by maven-repo-helper (version=1.0.0, no deps) * Update standards-version to 3.9.8 (no changes) * Fix license short name (BSD->BSD-3-clause) * Fix lintians * Add DEP3 patch headers -- Felix Natter <fnat...@gmx.net> Sat, 30 Jul 2016 11:28:28 +0200 I built this with pbuilder and tested with the r-dep jsom. Thanks and Best Regards, -- Felix Natter
Re: Please review freeplane/1.5.11-1 and simplyhtml/0.16.17-1
Hello Emmanuel, many thanks for sponsoring! Please upload 1.5.11. 1.5.12 requires a new version of simplyhtml and there will be many freeplane releases in quick succession. BTW: I will soon apply for DM hoping to take some load off d-java. Cheers and Best Regards, Felix > Am 20.07.2016 um 14:02 schrieb Emmanuel Bourg <ebo...@apache.org>: > >> Le 17/07/2016 à 11:47, Felix Natter a écrit : >> >> I prepared new upstream versions (using new gradle build systems) of >> freeplane (mind mapping tool) and simplyhtml (the HTML-editor for >> freeplane). > > Hi Felix, > > I uploaded simplyhtml but I noticed that freeplane 1.5.12 has just been > released. Should I upload freeplane 1.5.11 or do you prefer to update > the package first? > > Emmanuel Bourg >
Re: Upgrading svgSalamander
nico...@dandrimont.eu writes: > Hi, > > Feel free to take over the package completely. > > Sorry for not replying to your earlier mail, and thanks for taking over. Thank you for the quick answers :-) Cheers and Best Regards, -- Felix Natter
