[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#958185: meta-kde: Don't depend on cantor, RC buggy and prevents hdf5 migration



In data domenica 19 aprile 2020 15:27:23 CEST, Sebastiaan Couwenberg ha scritto:
> On 4/19/20 3:16 PM, Pino Toscano wrote:
> >> Please apply the attached patch to not depend on cantor, it's RC buggy and
> >> prevents the hdf5 transition from completing, see:
> >>
> >>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954654#56
> > 
> > Sorry, but I do not agree with this fix.
> > 
> > First of all, there are no bug reports against cantor, so knowing
> > about it would be a nice thing. Second, it seems like the actual
> > problem is scilab that FTBFS on amd64 (#955694). Cantor is definitely
> > *not* RC buggy.
> > 
> > So please contact the scilab maintainers about this, and let them fix
> > it if possible. If not, then we can (temporarly?) drop the scilab
> > backend from cantor, with no need to drop it from the kdeedu
> > metapackage.
> 
> The problem is that kdeedu Depends on cantor which Depends on scilab. To
> quote the linked post in the hdf5 transition bugreport:
> 
> "
>  Basically we could remove cdo, ruby-hdfeos5 (or wait for it to be a
>  candidate but I would remove it now to finish this) and scilab.
>  Unfortunately after checking with dak, I found that tasksel depends on
>  meta-kde, which depends on cantor, which depends on scilab, which means
>  that scilab is going to need a fix for #955694 in order for this
>  transition to finish.
> "

Yes, I did read that, and it even says what I wrote, i.e. that scilab
requires a FTBFS fix. Before adding more work on our (qt-kde) side, can
you please ping again the scilab maintainers (Julien Puydt in
particular), and wait a couple of days for an answer?

> Since a fix for scilab is not forthcoming, we need a different solution
> to allow hdf5 to migrate to testing. The next best thing is for meta-kde
> to not Depends on cantor which won't make it nor its dependencies like
> scilab a key package.

No, the next best thing is what I wrote earlier, i.e. drop the scilab
backend from cantor. I don't see a reason to drop cantor from testing
altogether just because one part of it might not be usable because of
other packages.

-- 
Pino Toscano

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: