Re: Bug#1027215: Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
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)?
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)?
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.)
Re: Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Hi Rebecca, Am Wed, Mar 01, 2023 at 10:41:23PM + schrieb Rebecca N. Palmer: > I agree that switching to Aesara is probably the only reasonable option > other than removal. (I'd given up on trying to fix 1.0, and was intending > to let removal happen.) > > However, it's a much bigger change than is normally allowed in bookworm at > this point. (1.1 includes multiple breaking changes, which is why it's in > experimental, but a quick codesearch suggests these parts *may* not be used > in keras/deepnano. https://github.com/aesara-devs/aesara/releases?page=8 ) 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. > Do you want to ask release team for permission to do this? If it would have build smoothly on all architectures, yes. But we have the first trouble on arm64[1] > Or do you want > to try the same patches on 1.0? (I suspect that that won't work, but I > haven't actually tried it.) > > (Also, you might not want numpy1p24_compat.patch - the v1p0 branch is > currently in whatever state it was in when I gave up on it, and my vague > memory is that this was a failed experiment, though I don't know if that > meant "actively bad" or just "not a (full) solution".) I've found some patches inside numpy1p24_compat.patch that were also in Aesara. Since the package did not fully build with this patch alone I've added a separate patch with the only goal to build and pass the test suite. Kind regards Andreas. [1] https://buildd.debian.org/status/fetch.php?pkg=theano=amd64=1.1.2%2Bdfsg-4=1677751828=0 -- http://fam-tille.de
Re: Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
I agree that switching to Aesara is probably the only reasonable option other than removal. (I'd given up on trying to fix 1.0, and was intending to let removal happen.) However, it's a much bigger change than is normally allowed in bookworm at this point. (1.1 includes multiple breaking changes, which is why it's in experimental, but a quick codesearch suggests these parts *may* not be used in keras/deepnano. https://github.com/aesara-devs/aesara/releases?page=8 ) Do you want to ask release team for permission to do this? Or do you want to try the same patches on 1.0? (I suspect that that won't work, but I haven't actually tried it.) (Also, you might not want numpy1p24_compat.patch - the v1p0 branch is currently in whatever state it was in when I gave up on it, and my vague memory is that this was a failed experiment, though I don't know if that meant "actively bad" or just "not a (full) solution".)
Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Control: tags -1 pending Hi, > Andrius Merkys wrote: > That said, it is OK to omit keras in bookworm if need be, but I would > like to see it back for trixie. I've spent some time into theano and it builds and runs its test suite in Salsa CI[1]. Since despite some tests are failing in my local pbuilder environment I'd be happy if someone else could run some test build before uploading. I decided for the latest upstream that was prepared by Rebecca and I also sneaked into the aesara fork[2] to copy some solutions they found for numpy 1.24 compatibility. I think we can not really loose much by taking this code from experimental since if we break something it can be removed which is the consensus we've somehow found before. In case it might work we have saved something for bookworm. Regarding future releases we should probably check whether those packages we want to save will work with aesara. Kind regards Andreas. [1] https://salsa.debian.org/science-team/theano/-/pipelines/506598 [2] https://github.com/aesara-devs/aesara -- http://fam-tille.de
Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Hi Thiago, Am Mon, Jan 16, 2023 at 11:08:35AM -0300 schrieb Thiago Franco Moraes: > Done! I removed both python3-theano and python3-keras. Thanks for the quick response. Autopkgtest currently fails due to Bug #1027851 pytorch FTBFS with Python 3.11 as default version I think, I'll wait a bit until this is clarified. Kind regards Andreas. -- http://fam-tille.de
Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Hi Andreas, Done! I removed both python3-theano and python3-keras. Best regards. Em seg., 16 de jan. de 2023 às 09:54, Andreas Tille escreveu: > Hi Thiago, > > Am Sat, Jan 14, 2023 at 07:50:27PM -0300 schrieb Thiago Franco Moraes: > > Hi Rebecca, > > > > InVesalius can work without Theano (and Keras). It will use Pytorch. > > Would you mind updating the packaging without Theano? Currently its in > its Build-Depends. Would it be sufficient to drop this Build-Depends? > If yes, I would upload a fixed package. > > Kind regards >Andreas. > > -- > http://fam-tille.de >
Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Hi Thiago, Am Sat, Jan 14, 2023 at 07:50:27PM -0300 schrieb Thiago Franco Moraes: > Hi Rebecca, > > InVesalius can work without Theano (and Keras). It will use Pytorch. Would you mind updating the packaging without Theano? Currently its in its Build-Depends. Would it be sufficient to drop this Build-Depends? If yes, I would upload a fixed package. Kind regards Andreas. -- http://fam-tille.de
Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Hello, On 2023-01-14 13:12, Rebecca N. Palmer wrote: theano has been mostly abandoned upstream since 2018. (The Aesara fork is not abandoned, but includes interface changes including the import name, so would break reverse dependencies not specifically altered for it.) Its reverse dependencies are keras, deepnano and invesalius. It is currently broken, probably by numpy 1.24 (#1027215), and the immediately obvious fixes weren't enough (https://salsa.debian.org/science-team/theano/-/pipelines). Is this worth spending more effort on fixing, or should we just remove it? keras is needed to train evaluation models for qmean [1] which I intend [2] to package eventually. qmean is a quite popular protein model evaluation tool, personally I use it a lot and I believe it would be useful to have it in Debian. That said, it is OK to omit keras in bookworm if need be, but I would like to see it back for trixie. [1] https://git.scicore.unibas.ch/search?search=keras_source=navbar_id=69_id=25_code=true_ref=master [2] https://bugs.debian.org/976981 Best, Andrius
Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Hi Rebecca, InVesalius can work without Theano (and Keras). It will use Pytorch. Best regards. Em sáb., 14 de jan. de 2023 às 08:12, Rebecca N. Palmer < rebecca_pal...@zoho.com> escreveu: > theano has been mostly abandoned upstream since 2018. (The Aesara fork > is not abandoned, but includes interface changes including the import > name, so would break reverse dependencies not specifically altered for it.) > > Its reverse dependencies are keras, deepnano and invesalius. > > It is currently broken, probably by numpy 1.24 (#1027215), and the > immediately obvious fixes weren't enough > (https://salsa.debian.org/science-team/theano/-/pipelines). > > Is this worth spending more effort on fixing, or should we just remove it? > > >
Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
Currently, I'd say PyTorch and TensorFlow are the two most popular libraries. And I even worry google is trying to write something new like Jax to replace TensorFlow in some aspects. On Sat, 2023-01-14 at 11:12 +, Rebecca N. Palmer wrote: > theano has been mostly abandoned upstream since 2018. (The Aesara fork > is not abandoned, but includes interface changes including the import > name, so would break reverse dependencies not specifically altered for it.) > > Its reverse dependencies are keras, deepnano and invesalius. > > It is currently broken, probably by numpy 1.24 (#1027215), and the > immediately obvious fixes weren't enough > (https://salsa.debian.org/science-team/theano/-/pipelines). > > Is this worth spending more effort on fixing, or should we just remove it? >
Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
On Sat, Jan 14, 2023 at 11:12:07AM +, Rebecca N. Palmer wrote: > theano has been mostly abandoned upstream since 2018. (The Aesara fork is > not abandoned, but includes interface changes including the import name, so > would break reverse dependencies not specifically altered for it.) > > Its reverse dependencies are keras, deepnano and invesalius. keras is already orphaned, it needs to be updated either now or later. And it depends heavily on tensorflow, python bindigs of which are still not in yet. deepnano is also kind of abandoned. Last commit is from 2017. On grepping the code for invesalius, I see that it only uses theano as an option for backend. There are three backends as far as I can see, torch, plaidml (not in debian) and theano. So as long as torch works, this _probably_ should do fine here. In any case, the upstream for this package is active and we can ask them. -- Best, Nilesh signature.asc Description: PGP signature
How much do we lose if we remove theano (+keras, deepnano, invesalius)?
theano has been mostly abandoned upstream since 2018. (The Aesara fork is not abandoned, but includes interface changes including the import name, so would break reverse dependencies not specifically altered for it.) Its reverse dependencies are keras, deepnano and invesalius. It is currently broken, probably by numpy 1.24 (#1027215), and the immediately obvious fixes weren't enough (https://salsa.debian.org/science-team/theano/-/pipelines). Is this worth spending more effort on fixing, or should we just remove it?
