Looks like ofBorg failure is a real build failure for octave

Funny I haven't noticed that when writing the PR. Now everything is fixed, including a fix to the sundials version - now we use 2.7.0 instead of 2.7.5.

Oof, is there a reason why we need to use such an old version of sundials?

IIRC, sundials_3 also was only in there because of bmcage/odes#98, so it could probably be dropped by now, too.

Oof, is there a reason why we need to use such an old version of sundials?

I couldn't get any other newer version of sundials to satisfy the ./configure script - it always complains that ODEs will not work with the current sundials because the API got changed between 2.7.0 and any other newer version.

I honestly tried drilling into Octave's bug reports but I couldn't get a clear view as for the status of it, see https://savannah.gnu.org/search/?words=sundials&type_of_search=bugs&Search=Search&exact=1 . I'll glad to get some help regarding this if you'd care so much to insist.

@doronbehar it's not me insisting being extremely picky here, but linking old packages to upstream issues ensures we're not stuck with that old version forever, and know where to check for compatibility.

https://savannah.gnu.org/bugs/?func=detailitem&item_id=52475 suggests we should be able to build with sundials 3.1.0 at least with d94876e7a0aa - which would allow us to switch over to the (still existing) sundials_3 derivation.

I don't see a bug report for latest sundials version, and if it doesn't work with that, would encourage to open one.

https://savannah.gnu.org/bugs/?func=detailitem&item_id=52475 suggests we should be able to build with sundials 3.1.0 at least with d94876e7a0aa - which would allow us to switch over to the (still existing) sundials_3 derivation.

@flokli this thread (https://savannah.gnu.org/bugs/?func=detailitem&item_id=52475 ) is from 13 March 2019 - meaning octave 5.2.0 should include the linked patch http://hg.savannah.gnu.org/hgweb/octave/rev/d94876e7a0aa .

I don't see a bug report for latest sundials version, and if it doesn't work with that, would encourage to open one.

You are totally right, I've submitted the following bug report on octave's end: https://savannah.gnu.org/bugs/index.php?57854

Update: Upstream confirms my findings - that octave 5.x is compatible with sundials 2.x only: https://savannah.gnu.org/bugs/?57854#comment1 :

I'm closing this as a bug report, since everything that is intended to work is working as far as I know, Octave verion 5 builds and works with SUNDIALS version 2.x, and Octave version 6 builds and works with SUNDIALS version 3.x (partially) and 4.x (fully).

We'll wait for octave 6 and see what's up with sundials 5.x then.

Thanks for asking back upstream - In that case, I propose to just go with an explicit sundials_2 version.

FYI, sundials_3 cleanup is happening in #80540.

@doronbehar with #80540 merged, can you give this a rebase and apply the python3 changes suggested there?

Sure, rebased and cleaned up the git log a little bit.

I feel like comments in all-packages.nix isn't really a good idea because it gets mangled frequently, and not convenient or an immediately obvious place to look for documentation.

I feel like comments in all-packages.nix isn't really a good idea because it gets mangled frequently, and not convenient or an immediately obvious place to look for documentation.

I tend to agree @worldofpeace . Where do you think would be a better place to place these comments? I think they are better put somewhere then nowhere :)

Maybe explicitly passing all the options is better than passing only the non-default options and also writing this full printout? The explanations of the options naturally live in default.nix

@doronbehar I believe what @7c6f434c said sounds correct.

Agree, sent a fix.