i386: seed inclusion: libfuse-dev

[Alberto]

We need the i386 build of libfuse-dev which was present in 24.04 (noble)
https://ubuntu-archive-team.ubuntu.com/germinate-output/i386.noble/i386+build-depends
But which disappeared for 24.10 and 25.04
https://ubuntu-archive-team.ubuntu.com/germinate-output/i386.oracular/i386+build-depends
https://ubuntu-archive-team.ubuntu.com/germinate-output/i386.plucky/i386+build-depends
(It seems to have been there before as a build dependency for e2fsprogs, which was removed now)

Note libfuse2t64, as a dependency to libfuse-dev would also be needed.

Background, for our particular use-case:
A quite critical tool for us requires the 32bit version of libfuse-dev. This is used to provide FUSE mount access to a set of simulated embedded systems filesystems.
As most of us running Ubuntu (in CI or locally) are still running the 24.04 LTS we did not realize of this package being missing in the latest versions until recently.
But there is quite many users for this particular tool, as it is a key component for the Zephyr RTOS development.
Note we need to build this tool both in its 32 and 64bit variants, as the 32bit variant is required to emulate 32bit embedded systems (which are the majority of embedded systems out there which Zephyr targets).

I'm following the instructions from
https://wiki.ubuntu.com/i386#How_to_expand_i386_port_scope
to request this package be (re-)added hoping it is still the right procedure.

Related to:
* https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/2124272
* https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598/110
* https://discourse.ubuntu.com/t/32-bit-package-compatibility-question/68273
* https://answers.launchpad.net/ubuntu/+source/fuse/+question/822074

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Erich Eickmeyer (eeickmeyer)]

This is a request for adding the libfuse-dev package to the i386-allowlist, which can only be accomplished by archive administrators. Subscribing the Ubuntu Archive Administrators team.

[Jeremy Bícha (jbicha)]

Please also ask the developers of your tool to port it to fuse3. fuse3 is already built for i386. The old fuse 2 is targeted for eventual removal from new Ubuntu releases:

https://ubuntu-archive-team.ubuntu.com/transitions/html/fuse-to-fuse3.html

[Alberto (aescolar)]

Thanks for the input Jeremy, this was done a few days ago. Though 2 thoughts/notes:
* Even if the tool just adds support to use fuse3, the version of the tool users will be using will lag behind and therefore they will still need the fuse (2) library.
* It seems libfuse3 is also listed as a "Build-Depend", so I guess in principle it could also disappear in a future release (though hopefully much later given it has several dependents today)

[Simon Chopin (schopin)]

Hi, thank you for reaching out.

Unfortunately, Jeremy makes an excellent point. I don't think it would be a good idea for us to enable libfuse-dev in i386 moving forward. We cannot support every version of every third-party software in our releases.

If your users want to use the older, non-fuse3 version of your software, they'll have to use Ubuntu 24.04, which has standard support until 2029, and even further with the Pro subscription.

Regarding fuse3 support in i386, we can't really know what the future holds, but I'm still pretty sure that it'll be in 26.04. I'm entirely unwilling to commit to anything regarding future releases, though.

[Alberto (aescolar)]

Thanks for looking into this Simon,
I would hope you could reconsider.
Note libfuse (2) is not yet some weird obsolete package.
From the link Jeremy provided, it would seem quite a few Ubuntu distributed packages are still using it.
https://ubuntu-archive-team.ubuntu.com/transitions/html/fuse-to-fuse3.html#good,bad,partial,unknown,!notintesting
So in this regard, continuing to provide the i386 variant for a while longer would seem reasonable.

This would only require from the Ubuntu's side to continue packaging something is has been packaging for a very long while, and which it continues hosting for all other architectures.