Re: Bug#1027215: Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

2023-03-03 Thread Rebecca N. Palmer

On 03/03/2023 06:00, Andreas Tille wrote:

Ahh, so aesara is not really a "fork" but a "rename"?


The original is abandoned (no new development since 2017, and now mostly 
unmaintained, which is probably why it has this kind of bug).  Aesara is 
a continuation by a new upstream (possibly one that mostly wanted it for 
their own use), that chose to break compatibility.




Re: Bug#1027215: Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

2023-03-02 Thread Andreas Tille
Hi Rebecca,

Am Thu, Mar 02, 2023 at 09:00:14PM + schrieb Rebecca N. Palmer:
> 
> 1.1.2 isn't the latest version, just the latest that calls the module theano
> rather than aesara.  (I chose it to package because I didn't want to fully
> break compatibility, then abandoned it because I didn't like how much it did
> break.)

Ahh, so aesara is not really a "fork" but a "rename"?
 
> > If it would have build smoothly on all architectures, yes.
> 
> If you wouldn't want to do this work if it can't get into bookworm (possibly
> because you'd prefer to package 2.0 as aesara if you have to wait until
> trixie anyway), you might want to ask them first.

I admit I do not want to take over theano / aesara.  I simply wanted to
see what I can do to lend a helping hand on packages that are not yet
removed from testing.  I naively assumed that just numpy issues should
be solvable.
 
> > But we have
> > the first trouble on arm64[1]
> Sorry - I forgot that theano skips most of its tests on Salsa-CI (because
> there's enough of them to take several hours), which is probably why it
> "passed" that but failed the full build.
> 
> Given how many failures there are (everywhere), I don't consider this worth
> fixing, but you are of course free to disagree.

Considering my practical experience now I agree.

> (If you're planning to xfail tests, note that I consider *wrong-answer* bugs
> (though not crash bugs) in this kind of package to be RC.  I haven't checked
> whether we currently have any.)

I admit I'll give up here on that package where we decided that the
loose we have is acceptable.

Kind regards and thanks a lot for your work on this package as well as
your hints in this mail

 Andreas.

-- 
http://fam-tille.de



Re: Bug#1027215: Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

2023-03-02 Thread Rebecca N. Palmer

On 02/03/2023 10:38, Andreas Tille wrote:

I admit I do not see any good reason to stick to the old version if we
decided before that keras/deepnano are no real blockers to even drop
theano.  Thus I was considering it more promising to spent my time on
the latest version.


1.1.2 isn't the latest version, just the latest that calls the module 
theano rather than aesara.  (I chose it to package because I didn't want 
to fully break compatibility, then abandoned it because I didn't like 
how much it did break.)



Do you want to ask release team for permission to do this?


If it would have build smoothly on all architectures, yes.


If you wouldn't want to do this work if it can't get into bookworm 
(possibly because you'd prefer to package 2.0 as aesara if you have to 
wait until trixie anyway), you might want to ask them first.



But we have
the first trouble on arm64[1]
Sorry - I forgot that theano skips most of its tests on Salsa-CI 
(because there's enough of them to take several hours), which is 
probably why it "passed" that but failed the full build.


Given how many failures there are (everywhere), I don't consider this 
worth fixing, but you are of course free to disagree.


(If you're planning to xfail tests, note that I consider *wrong-answer* 
bugs (though not crash bugs) in this kind of package to be RC.  I 
haven't checked whether we currently have any.)