Re: 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 <malat@debian.org> wrote:
> On Sat, Oct 24, 2015 at 2:06 PM, Samuel Thibault <sthibault@debian.org> 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 :(
Reply to:
