build: Rebuild nvim Against Unibilium 2.1.4

[thekpaul]

Forces build-time and runtime requirements for the unibilium library to a lower-bounded version of 2.1.4 (latest release), which contains a malformed-SONAME fix. The prior nvim artifact linked against unibilium 2.1.2, whose malformed SONAME produced a libunibilium.so.. DT_NEEDED entry. Requiring 2.1.4 in both host and cross-build dependencies forces relinking against the corrected libunibilium.so.4 SONAME.

Incrementing the build number makes solvers prefer the rebuilt artifact. The unibilium run exports generate the matching runtime constraint, so no explicit run dependency is necessary.

---

This would also affect previous release versions once the updated unibilium library is used there;
if the maintainers would also like to rebuild past releases, I am willing to help out wherever necessary :)

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Ensured the license file is being packaged.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

[xhochy]

We should instead fix the global unibilium pin

[anjos]

Thanks for this. I'd not go as far as doing all point releases of nvim to pin this. May be just the latest 0.11.x one? Frankly, I'm not 100% sure on this.

[xhochy]

The problem is that the latest unibilium has libunibilium.4.0.2.dylib whereas all previous releases had a broken libunibilium.so...

We can fix this via:

1. Remove the changes made in this PR and simply rebuild.
2. Add a repodata patch for all old nvim releases to unibilium<2.1.4
3. Change the global pin to unibilium=2.1.4 and add a comment about the issue.

[thekpaul]

Thank you for your feedbacks. I've reverted the pinning for this feedstock so that only the build number is bumped, without enforcing any pins here. I will instead proceed with the global-pin bumping and repodata-patch PR, linking back to this PR to provide further info if necessary.

I've checked with past versions of Neovim on conda-forge, and it turned out that all versions from v0.9.0 to v0.12.5 depend on unibilium (either unconstrained or >=2.1.2, <2.2.0a0), so it looks as though the repodata patch would have to apply to ALL of those releases. I've drafted a repodata patch based only on the release timestamp as follows:

if:
  name: nvim
  has_depends: "unibilium?( *)"
  timestamp_lt: 1787544213485 # Contains up to latest Neovim artifact release (v0.12.5, build 0)
then:
  - add_depends: "unibilium <2.1.4"

PR Submitted

• Pin unibilium to 2.1.4 conda-forge-pinning-feedstock#8910 from https://github.com/thekpaul/conda-forge-pinning-feedstock-nvim-unibilium/commit/22ed0a8ef1463a265a432a91efbb063e7fe0f2bd
• Patch nvim unibilium SONAME Dependency conda-forge-repodata-patches-feedstock#1242 from https://github.com/thekpaul/conda-forge-repodata-patches-feedstock-nvim-unibilium/commit/e986e9a85bbf8a148146ab48781a13792ad80ab8

[mjsteinbaugh]

I can confirm that I can reproduce this issue on Ubuntu

[anjos]

@xhochy: Can you or somebody from the core team please review the two linked PRs above? Will we need a rebuild after that?

[mschilli87]

Will this fix the

nvim: error while loading shared libraries: libunibilium.so..: cannot open shared object file: No such file or directory

I get on a fresh install or should I open a separate issue for this?

[ashwinvis]

Until this lands get fixed, the workaround I have is to do

pixi global install nvim --with 'unibilium<2.1.4'

I agree with what was mentioned here #56 (review), it probably just needs a rebuild.

[carterbox]

I have merged the repodata patch and global pinning.

[anjos]

@conda-forge-admin: please restart ci

[carterbox]

Please rerender to ensure that the new build picks up the new pinnings!

[anjos]

@conda-forge-admin: please rerender