Bug#799990: Bug#794214: org.apache.batik.dom.svg.SVGDOMImplementation
Hello, Sorry, I'm still very much overworked. Packaging the next version requires some effort because the build system was switched from ant to maven for the new version; furthermore I don't keep the gpg key on my usual work machines but I have to power up an older desktop instead. So I figured the auto-removal is okay, requalification through testing will not be hard. As is, people should just get the .jar from the upstream download site instead. I'm not sure why the autoremoval date was bounced. I have filed #802959 to ask for removal from testing to speed up batik. Regards, Erich On Sat, Oct 24, 2015 at 2:19 PM, Mathieu Malaterre wrote: > On Sat, Oct 24, 2015 at 2:06 PM, Samuel Thibault wrote: >> Hello, >> >> Erich Schubert, le Mon 17 Aug 2015 10:28:27 +0200, a écrit : >>> I will take care of uploading a new ELKI package (probably end of the >>> month, or beginning of september). >>> It will have a version number of at least "0.7.0~20150817-1", which is >>> > 0.6.5, so above breaks is okay. >>> I assume that libfop-java 1:2.0+dfsg-1 in experimental is expecting >>> the new Batik version. >> >> Ping? >> >> This is preventing the batik migration, and thus the fop and jaxe >> migrations too, at least. > > I was sure elki would get removed today ? See my post: > > https://lists.debian.org/debian-java/2015/09/msg00092.html > > Someone must have change the auto-removal date :(
Bug#794214: org.apache.batik.dom.svg.SVGDOMImplementation
Hello Mathieu, The annoying part is that even the Batik documentation still contains the old package name: https://xmlgraphics.apache.org/batik/using/dom-api.html It is well possible that many of the dependencies do not use this class. I'm not sure if there might be indirect dependencies that rely on one of these direct dependencies to pull in Batik... they could still use that class; although many will not build a SVG document on their own. Loading a document from a file should not be a problem, I believe this class is only needed to be able to manipulate the SVG documents e.g. for animation and interaction. According to find -type f -name "*.jar" -print | while read l; do unzip -c "$l" | grep -q SVGDOMImplementation && echo $l; done the only packages I have installed that use this class are Batik, FOP and ELKI. It may well be that the other reverse dependencies do not use this class. Scilab for example seems to use GenericDOMImplementation, which was not moved to a different package. I suggest to add these for the unstable upload: Breaks: elki (<= 0.6.5) Breaks: libfop-java (<< 2.0) + add a notice to the README that the class has moved, since this is not well documented. I will take care of uploading a new ELKI package (probably end of the month, or beginning of september). It will have a version number of at least "0.7.0~20150817-1", which is > 0.6.5, so above breaks is okay. I assume that libfop-java 1:2.0+dfsg-1 in experimental is expecting the new Batik version. Regards, Erich On Sun, Aug 16, 2015 at 1:33 PM, Mathieu Malaterre wrote: > Erich, > > Thanks for the report about batik API compat. Could you be a little more > verbose on what was needed to fix ELKI ? I see that that > > import org.apache.batik.dom.svg.SVGDOMImplementation; > > is still used in the ELKI (from sid). > > I am trying to understand if this is possible to upload 1.8 to sid with a > debian-specific fix, then progressively upgrade dependencies to match > upstream (removing reference to SVGDOMImplementation). > > Thanks much,
Bug#794214: org.apache.batik.dom.svg.SVGDOMImplementation
On Sun, Aug 16, 2015 at 1:53 PM, Erich Schubert wrote: > Hi, > ELKI now tries to load the class dynamically, from different packages. I > don't know if this is the proper way to get the DOM implementation, but it > was the only one I got working. > > It is not yet fixed in the Debian package. We're in the process of > preparing the next release. > > Maybe a simple compatibility hack would be to include two copies of the > class, in both the old and the new location, but that bears the danger of > people continuing to use the old location... > > I wish there was a well-documented solution. > > For reference: http://stackoverflow.com/a/30250306/136285
Bug#794214: org.apache.batik.dom.svg.SVGDOMImplementation
Erich, Thanks for the report about batik API compat. Could you be a little more verbose on what was needed to fix ELKI ? I see that that import org.apache.batik.dom.svg.SVGDOMImplementation; is still used in the ELKI (from sid). I am trying to understand if this is possible to upload 1.8 to sid with a debian-specific fix, then progressively upgrade dependencies to match upstream (removing reference to SVGDOMImplementation). Thanks much,
