Re: Freeplane and latest jgoodies-forms: strange runtime error
On Thu, Dec 08, 2016 at 09:23:35PM -0800, tony mancill wrote: > On Tue, Dec 06, 2016 at 07:40:59PM +0100, Markus Koschany wrote: > > > > > I wouldn't worry to much about JGoodies now. We are already at the end > > of the Stretch release cycle but there is still one month left to clean > > everything up. Best and most time saving option IMO would be to ask the > > release team to binNMU all reverse-dependencies. I know transition > > freeze was on 5th of November but hey, let's talk to them and see how > > they react. Otherwise we just split the work between all active DDs and > > rebuild all reverse-dependencies. That should do the trick. > > Thanks to all who have contributed to the thread. I will start digging > into the r-deps this weekend so we have a list of what is affected at > runtime. If nothing else, that will allow me to explain myself to the > Release Team and understand the problem better. But I agree that we can > get rebuilds done if necessary. Thank you for the support. I have performed runtime checks on a sid system for all r-deps that I found in the archive for libjgoodies-[looks|forms]-java. With the exceptions of biomaj, which I wasn't sure how to test, and jitsi, which isn't currently installable, everything else appears to be okay with the versions of jgoodies packages in the archive. If there is evidence to the contrary, please send it my way. Thanks, tony signature.asc Description: PGP signature
Re: Freeplane and latest jgoodies-forms: strange runtime error
On Tue, Dec 06, 2016 at 07:40:59PM +0100, Markus Koschany wrote: > I wouldn't worry to much about JGoodies now. We are already at the end > of the Stretch release cycle but there is still one month left to clean > everything up. Best and most time saving option IMO would be to ask the > release team to binNMU all reverse-dependencies. I know transition > freeze was on 5th of November but hey, let's talk to them and see how > they react. Otherwise we just split the work between all active DDs and > rebuild all reverse-dependencies. That should do the trick. Thanks to all who have contributed to the thread. I will start digging into the r-deps this weekend so we have a list of what is affected at runtime. If nothing else, that will allow me to explain myself to the Release Team and understand the problem better. But I agree that we can get rebuilds done if necessary. Thank you for the support. Cheers, tony signature.asc Description: PGP signature
Re: Freeplane and latest jgoodies-forms: strange runtime error
On Wed, Dec 7, 2016 at 12:37 AM, Emmanuel Bourg wrote: > This one was really tricky, nobody could have anticipated it with our > current tools. We would need a kind of static analyzer that scans all > classes in the Debian packages and reports if any type, method of field > can't be resolved. Bonus point if we can couple that with Britney to > prevent the packages breaking the binary compatibility from > transitioning to testing. The package 'adequate' does this for C libraries, perhaps it could be extended to Java too. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Freeplane and latest jgoodies-forms: strange runtime error
On Tue, Dec 6, 2016 at 11:31 PM, tony mancill wrote: > And I didn't anticipate the run-time breakage. Long-term, I > think it is worth discussing how best to support Java applications in > main, since it often feels like we're swimming against the stream trying > to support system-level JARs for everything packaged for Debian. Probably the addition of more autopkgtests would help. Also, there is a Java API tracker here: https://github.com/lvc/japi-tracker -- bye, pabs https://wiki.debian.org/PaulWise
Re: Freeplane and latest jgoodies-forms: strange runtime error
On 06.12.2016 16:31, tony mancill wrote: > On Tue, Dec 06, 2016 at 11:22:46AM +0100, Thorsten Glaser wrote: >> On Mon, 5 Dec 2016, Felix Natter wrote: >> >>> 2. Could someone please help analyse the underlying problem >> >> I was also bitten by this problem: >> >> https://lists.alioth.debian.org/pipermail/pkg-java-commits/2016-December/062915.html >> >> On the other hand, Squirrel-SQL is not uploaded to Debian yet, >> so that’s nobody’s fault. >> >> But I think we basically have to assume that the exact contrary >> of what the jgoodies website states is true, i.e. that every new >> version breaks all rdeps, both at compile and at runtime. > > ... I'm frustrated by this because > I thought we had addressed the compile-time rdeps by building everything > and reaching out to package maintainers when there was compile-time > breakage. And I didn't anticipate the run-time breakage. Long-term, I > think it is worth discussing how best to support Java applications in > main, since it often feels like we're swimming against the stream trying > to support system-level JARs for everything packaged for Debian. > > But short-term, I'd like to ask for the team's input on what I needs to > do to clean up the mess I have made by introducing the new version. Is > it sufficient to rebuild all rdeps and then upload after a quick > run-time test? > > Thanks for the input, and sorry for the noise, Hi, I agree it is often difficult to bring the Java and Debian philosophies together and we should use only one version of a Java library whenever possible but we should also be flexible as Emmanuel already pointed out. We could write autopkg tests or implement some other QA system but most of the transitions are controllable, that means FTBFS issues are quickly detected (thanks to the reproducible builds effort or the QA team) or our own rebuilds. Runtime breakage is rather rare and it will be detected if nothing else by users in time for the next stable release. I wouldn't worry to much about JGoodies now. We are already at the end of the Stretch release cycle but there is still one month left to clean everything up. Best and most time saving option IMO would be to ask the release team to binNMU all reverse-dependencies. I know transition freeze was on 5th of November but hey, let's talk to them and see how they react. Otherwise we just split the work between all active DDs and rebuild all reverse-dependencies. That should do the trick. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Freeplane and latest jgoodies-forms: strange runtime error
On 06.12.2016 18:59, Thorsten Glaser wrote: > On Tue, 6 Dec 2016, Emmanuel Bourg wrote: > >> issues. if a package often breaks the compatibility and isn't security >> sensitive, then maintaining more than one version is probably more >> efficient (jgoodies and guava fall into this category). > > What is “security sensitive”? I’d not dare to put numbers to such > a denomination. Bouncycastle is a prime example of security sensitive Java software while qdox, ASM or any Java package that just provides some sort of API is less likely vulnerable. It's a matter of balancing the pros and cons and we have already removed duplicate libraries or reduced dependencies during the Stretch release cycle. See [1] for a quick overview for some of them. > No idea whether maintaining several versions is really worth it. > I mean, jgoodies looks upstream-dead, so this is a good argument > in favour of both JGoodies' upstream has discontinued to release his software as free software but he is still very active. [2] Hence we won't have to suffer from future JGoodies transitions, although the reason is rather sad. > ⓐ maintain multiple versions of our own > > ⓑ package the last version of it, maintain that, and patch > all applications to use it (and we expect no further/new > breakage, because there will be no new upstream version) I think we can expect that this is the last version of JGoodies, so maintaining it will become easier until the reverse-dependencies decide to switch to another library. Regards, Markus [1] https://wiki.debian.org/Java/Oldlibs [2] http://www.jgoodies.com/downloads/libraries/ signature.asc Description: OpenPGP digital signature
Re: Freeplane and latest jgoodies-forms: strange runtime error
On Tue, 6 Dec 2016, Emmanuel Bourg wrote: > issues. if a package often breaks the compatibility and isn't security > sensitive, then maintaining more than one version is probably more > efficient (jgoodies and guava fall into this category). What is “security sensitive”? I’d not dare to put numbers to such a denomination. No idea whether maintaining several versions is really worth it. I mean, jgoodies looks upstream-dead, so this is a good argument in favour of both ⓐ maintain multiple versions of our own ⓑ package the last version of it, maintain that, and patch all applications to use it (and we expect no further/new breakage, because there will be no new upstream version) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Freeplane and latest jgoodies-forms: strange runtime error
On Tue, 6 Dec 2016, tony mancill wrote: > and reaching out to package maintainers when there was compile-time > breakage. And I didn't anticipate the run-time breakage. Long-term, I I’d assume runtime breakage would also show at compile time, but apparently it’s worse than I thought when you checked that. As for Squirrel-SQL, well, it’s not yet uploaded to Debian proper (there’s a TODO list for that), so it’s not your fault. > think it is worth discussing how best to support Java applications in > main, since it often feels like we're swimming against the stream trying > to support system-level JARs for everything packaged for Debian. We are, but this is still the only way forward. And for a language as “enterprise” as Java™, there’s no excuse; the extremely large corpus of software written in C, C++, etc. manages that just fine. > But short-term, I'd like to ask for the team's input on what I needs to > do to clean up the mess I have made by introducing the new version. Is > it sufficient to rebuild all rdeps and then upload after a quick > run-time test? As I said, I’d think they would break at compile time, but if that’s not it, good question. I didn’t look at it in depth yet, but they may need source patches to work with the newer jgoodies (yes, string of expletives matches my feelings quite well when dealing with that piece of… software). bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Freeplane and latest jgoodies-forms: strange runtime error
Le 6/12/2016 à 16:31, tony mancill a écrit : > ... I'm frustrated by this because > I thought we had addressed the compile-time rdeps by building everything > and reaching out to package maintainers when there was compile-time > breakage. And I didn't anticipate the run-time breakage. This one was really tricky, nobody could have anticipated it with our current tools. We would need a kind of static analyzer that scans all classes in the Debian packages and reports if any type, method of field can't be resolved. Bonus point if we can couple that with Britney to prevent the packages breaking the binary compatibility from transitioning to testing. > I think it is worth discussing how best to support Java applications in > main, since it often feels like we're swimming against the stream trying > to support system-level JARs for everything packaged for Debian. We don't have many options if we want to stay within the bounds defined by the Debian rules. I think we have to find the balance between adapting the packages to the latest version of their dependencies, and maintaining several versions of the same package to avoid compatibility issues. if a package often breaks the compatibility and isn't security sensitive, then maintaining more than one version is probably more efficient (jgoodies and guava fall into this category). > But short-term, I'd like to ask for the team's input on what I needs to > do to clean up the mess I have made by introducing the new version. Is > it sufficient to rebuild all rdeps and then upload after a quick > run-time test? I think so. Emmanuel Bourg
Re: Freeplane and latest jgoodies-forms: strange runtime error
On Tue, Dec 06, 2016 at 11:22:46AM +0100, Thorsten Glaser wrote: > On Mon, 5 Dec 2016, Felix Natter wrote: > > > 2. Could someone please help analyse the underlying problem > > I was also bitten by this problem: > > https://lists.alioth.debian.org/pipermail/pkg-java-commits/2016-December/062915.html > > On the other hand, Squirrel-SQL is not uploaded to Debian yet, > so that’s nobody’s fault. > > But I think we basically have to assume that the exact contrary > of what the jgoodies website states is true, i.e. that every new > version breaks all rdeps, both at compile and at runtime. ... I'm frustrated by this because I thought we had addressed the compile-time rdeps by building everything and reaching out to package maintainers when there was compile-time breakage. And I didn't anticipate the run-time breakage. Long-term, I think it is worth discussing how best to support Java applications in main, since it often feels like we're swimming against the stream trying to support system-level JARs for everything packaged for Debian. But short-term, I'd like to ask for the team's input on what I needs to do to clean up the mess I have made by introducing the new version. Is it sufficient to rebuild all rdeps and then upload after a quick run-time test? Thanks for the input, and sorry for the noise, tony signature.asc Description: PGP signature
Re: Freeplane and latest jgoodies-forms: strange runtime error
On Mon, 5 Dec 2016, Felix Natter wrote: > 2. Could someone please help analyse the underlying problem I was also bitten by this problem: https://lists.alioth.debian.org/pipermail/pkg-java-commits/2016-December/062915.html On the other hand, Squirrel-SQL is not uploaded to Debian yet, so that’s nobody’s fault. But I think we basically have to assume that the exact contrary of what the jgoodies website states is true, i.e. that every new version breaks all rdeps, both at compile and at runtime. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Freeplane and latest jgoodies-forms: strange runtime error
Le 6/12/2016 à 08:08, Felix Natter a écrit : > 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? Hi Felix, You've been hit by a binary incompatibility between jgoodies-forms 1.6 and 1.9. The type of the Borders.DLU2 field changed from javax.swing.Border to com.jgoodies.forms.factories.Paddings.Padding. This modification is source compatible (Padding implements javax.swing.Border) but not binary compatible (the JVM attempts to match the exact signature), thus requiring the StyleEditorPanel class to be recompiled. There is no mechanism is Debian to detect this kind of incompatibility (that would be an excellent task for a GSoC student!), even the periodic rebuilds performed by the Reproducible Builds Team wouldn't be able to detect it. So rebuilding manually is the best thing you can do in this case. Emmanuel Bourg
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
hello Debian-Java,
I have two concerns:
1. Could someone please upload freeplane-1.5.16-3 which fixes an RC bug
(#846816):
https://anonscm.debian.org/cgit/pkg-java/freeplane.git
2. Could someone please help analyse the underlying problem
(freeplane-1.5.16-3 might only fix a symptom)?
Here is the problem which occurs when starting Freeplane
(I believe that this only occurs at runtime) [1]:
STDERR: Exception in thread "AWT-EventQueue-1"
STDERR: java.lang.NoSuchFieldError: DLU2
STDERR: at
org.freeplane.features.styles.mindmapmode.StyleEditorPanel.init(StyleEditorPanel.java:845)
STDERR: at
org.freeplane.features.styles.mindmapmode.StyleEditorPanel.access$2500(StyleEditorPanel.java:119)
STDERR: at
org.freeplane.features.styles.mindmapmode.StyleEditorPanel$1.hierarchyChanged(StyleEditorPanel.java:582)
STDERR: at java.awt.Component.processHierarchyEvent(Component.java:6700)
STDERR: at java.awt.Component.processEvent(Component.java:6319)
STDERR: at java.awt.Container.processEvent(Container.java:2236)
STDERR: at java.awt.Component.dispatchEventImpl(Component.java:4889)
STDERR: at java.awt.Container.dispatchEventImpl(Container.java:2294)
STDERR: at java.awt.Component.dispatchEvent(Component.java:4711)
STDERR: at java.awt.Component.addNotify(Component.java:6969)
STDERR: at java.awt.Container.addNotify(Container.java:2762)
STDERR: at javax.swing.JComponent.addNotify(JComponent.java:4740)
STDERR: at java.awt.Container.addNotify(Container.java:2773)
STDERR: at javax.swing.JComponent.addNotify(JComponent.java:4740)
STDERR: at java.awt.Container.addNotify(Container.java:2773)
STDERR: at javax.swing.JComponent.addNotify(JComponent.java:4740)
STDERR: at java.awt.Container.addNotify(Container.java:2773)
STDERR: at javax.swing.JComponent.addNotify(JComponent.java:4740)
STDERR: at java.awt.Container.addNotify(Container.java:2773)
STDERR: at javax.swing.JComponent.addNotify(JComponent.java:4740)
STDERR: at java.awt.Container.addImpl(Container.java:1121)
STDERR: at java.awt.Container.add(Container.java:467)
STDERR: at
org.freeplane.features.ui.FrameController.selectMode(FrameController.java:365)
STDERR: at
org.freeplane.features.mode.Controller.selectMode(Controller.java:171)
STDERR: at
org.freeplane.features.mode.Controller.selectMode(Controller.java:184)
STDERR: at
org.freeplane.main.application.FreeplaneGUIStarter.loadMaps(FreeplaneGUIStarter.java:372)
STDERR: at
org.freeplane.main.application.FreeplaneGUIStarter.loadMaps(FreeplaneGUIStarter.java:312)
STDERR: at
org.freeplane.main.application.FreeplaneGUIStarter.access$200(FreeplaneGUIStarter.java:87)
STDERR: at
org.freeplane.main.application.FreeplaneGUIStarter$2.run(FreeplaneGUIStarter.java:273)
STDERR: at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
STDERR: at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
STDERR: at java.awt.EventQueue.access$500(EventQueue.java:97)
STDERR: at java.awt.EventQueue$3.run(EventQueue.java:709)
STDERR: at java.awt.EventQueue$3.run(EventQueue.java:703)
STDERR: at java.security.AccessController.doPrivileged(Native Method)
STDERR: at
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
STDERR: at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
STDERR: at
org.GNOME.Accessibility.AtkWrapper$5.dispatchEvent(AtkWrapper.java:700)
STDERR: at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
STDERR: at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
STDERR: at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
STDERR: at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
STDERR: at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
STDERR: at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846816
In 1.5.16-3, this is "fixed" by replacing Borders.DLU2 with
Paddings.DLU2, which is the correct way ("@deprecated Replaced by {@link
Paddings}." [2])
-->
final DefaultFormBuilder rightBuilder = new DefaultFormBuilder(rightLayout);
-rightBuilder.border(Borders.DLU2);
+rightBuilder.border(Paddings.DLU2);
As you can see, Borders is deprecated in jgoodies-forms-1.9.0, but not
removed [2].
[2]
https://anonscm.debian.org/cgit/pkg-java/libjgoodies-forms-java.git/tree/src/main/java/com/jgoodies/forms/factories/Borders.java
A little explanation: The gradle build system of freeplane generates the
classpaths (jar references) in OSGi Manifests using gradle dependency
information (converted to relative paths). F
