Add mplapack-interop 0.5.0

[nakatamaho]

Summary

Add the mplapack-interop 0.5.0 release to the Octave Packages index.

The release archive is a standard Octave package and includes DESCRIPTION, COPYING, INDEX, inst/, and src/Makefile. The archive was installed from a clean package context with Octave 11.1.0.

External dependency

The native extension requires the MPLAPACK MPFR pkg-config provider mplapack_mpfr, including mplapack_mpfr_precision.h. The entry therefore declares the proposed Ubuntu dependency libmplapack-mpfr-dev.

That package is not yet available in the standard Ubuntu repositories used by the package-index CI. This draft PR is intentionally opened to confirm the expected representation of this external dependency and whether the entry should wait for the Debian/Ubuntu MPLAPACK package.

Archive SHA256:

3c4e992516deb1266918c1c5bf6542cc9e1b7f301aeeb1f354dd64f2558f9e04

Related upstream release: https://github.com/nakatamaho/octave-mplapack/releases/tag/v0.5.0

[nakatamaho]

No Debian packaging files are included in this index contribution. Debian debian/* packaging will be maintained separately in the Debian Octave Group Salsa repository.

[nakatamaho]

Thanks for reviewing this draft.

The release archive is a normal Octave package and installs with pkg install. The only open question is the external MPLAPACK dependency:

• the native build requires the mplapack_mpfr pkg-config provider;
• the required interface includes mplapack_mpfr_precision.h;
• the intended Ubuntu/Debian development package is currently libmplapack-mpfr-dev;
• that dependency is being coordinated separately with Debian Science and the Debian Octave Group.

Could you advise whether an index entry may be merged before libmplapack-mpfr-dev is available in the Ubuntu 26.04 repositories, or whether this entry should remain pending until that package is available?

If the package name or the ubuntu2604 dependency declaration should be different, I will update the entry accordingly.

[mmuetzel]

Thank you for your contribution and for taking the time to explain the situation with the "missing" dependency on Debian.

Afaict, we have precedence for a similar situation with packages that are already on this index here (e.g., the libbiosig-dev dependency of the biosig package wasn't actually distributed by Ubuntu at least at some point if I recall correctly). That didn't stop us from including those packages on this index then. So I don't know why it should stop us now.

Having the dependencies in the yaml format is mainly for the CI here. (But I see that someone added fields for Fedora. Those aren't needed to set up the CI runner at all. So, I guess that list of non-Octave dependencies is also interesting for non-CI users.)

Having the CI run here is meant to at least partly serve the package developer as some sorts of final test that the package works at least on one system other than their own.
If I understand correctly, that test won't pass until a new package is distributed by the version of Ubuntu that is used in the CI run.
It is up to you to decide if that is acceptable for you as the package maintainer.

When it comes to how to indicate the package name of the (missing) dependency, I'd go for using the name the package will most likely get.
But that decision is up to you, too.

Please, let us know how you'd like to proceed.

[nakatamaho]

Dear mmuetzl, that is helpful. I would like to proceed with the index entry. Please keep "libmplapack-mpfr-dev" as the anticipated Ubuntu dependency name. I understand that the package installation test in the index CI cannot pass until this dependency is available in the Ubuntu repositories. I accept that limitation for now and will update the entry and rerun the test once the dependency is packaged. I will mark the PR ready for review. Best regards Nakata Maho

…

On Tue, Sep 22, 2026 at 4:58 PM Markus Mützel ***@***.***> wrote: *mmuetzel* left a comment (gnu-octave/packages#841) <#841 (comment)> Thank you for your contribution and for taking the time to explain the situation with the "missing" dependency on Debian. Afaict, we have precedence for a similar situation with packages that are already on this index here (e.g., the libbiosig-dev dependency of the biosig package wasn't actually distributed by Ubuntu at least at some point if I recall correctly). That didn't stop us from including those packages on this index then. So I don't know why it should stop us now. Having the dependencies in the yaml format is mainly for the CI here. (But I see that someone added fields for Fedora. Those aren't needed to set up the CI runner at all. So, I guess that list of non-Octave dependencies is also interesting for non-CI users.) Having the CI run here is meant to at least partly serve the package developer as some sorts of final test that the package works at least on one system other than their own. If I understand correctly, that test won't pass until a new package is distributed by the version of Ubuntu that is used in the CI run. It is up to you to decide if that is acceptable for you as the package maintainer. When it comes to how to indicate the package name of the (missing) dependency, I'd go for using the name the package will most likely get. But that decision is up to you, too. Please, let us know how you'd like to proceed. — Reply to this email directly, view it on GitHub <#841?email_source=notifications&email_token=ABET7PQWFUCGCJ4YGB47BAL5QIWIRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZXGMYDKOJVGY22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5773059565>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABET7PSLD4HSGBVF4TA4H2L5QIWIRAVCNFSNUABFKJSXA33TNF2G64TZHMZDQOJYG4YTMMJYHNEXG43VMU5TKNJTGM3TGNBTHA32C5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mmuetzel]

Sounds good to me. 👍

[nakatamaho]

Dear Markus, Thank you for reviewing and merging #841. I appreciate your guidance and your flexibility regarding the anticipated Ubuntu dependency. The 0.5.1 release also addresses compatibility with MPC 1.3.1, used by Ubuntu 26.04: it removes the direct mpc_log2 symbol dependency and routes complex log2 through gmpfrxx’s compatibility implementation. I opened follow-up PR #844 to add 0.5.1 while retaining the 0.5.0 entry. The package-install check will still need libmplapack-mpfr-dev to become available in Ubuntu’s repositories, as discussed. Best regards, Maho

…

On Wed, Sep 23, 2026 at 8:18 PM Markus Mützel ***@***.***> wrote: Merged #841 <#841> into main. — Reply to this email directly, view it on GitHub <#841?email_source=notifications&email_token=ABET7PU43RRVZGSD5YCXV6L5QOWRRA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMJWG4YDSOJVGEYDPJTSMVQXG33OUZQXK5DIN5ZKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#event-31670995107>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABET7PXNNF23GRAGVN2DDW35QOWRRAVCNFSNUABFKJSXA33TNF2G64TZHMZDQOJYG4YTMMJYHNEXG43VMU5TKNJTGM3TGNBTHA32C5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[nakatamaho]

Thanks, Markus, for merging #841 and helping get mplapack-interop into the Octave Packages index.