Bug#1039604: glusterfs: Drop support for 32-bit architectures

[Sergio Durigan Junior]

Source: glusterfs
Version: 10.3-5
Severity: important

Hi,

Upstream glusterfs has given several indications that they do not
care about/support 32-bit architectures, as can be seen in this
(non-exhaustive) list of issues:

- https://github.com/gluster/glusterfs/issues/3911

- https://github.com/gluster/glusterfs/issues/702

Moreover, in Ubuntu, where glusterfs is built for armhf, some issues
have been filed about problems related to this lack of 32-bit support,
like:

- https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1991441

- https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1951408

The underlying issue in these two bugs happen to be correlated:
glusterfs requires that the host supports 64-bit atomic operations, but
armhf and other 32-bit architectures don't offer such feature.

Therefore, I would like to request that the support for 32-bit
architecture in Debian's glusterfs package be dropped, please.

A quick investigation tells me that these packages will likely need to
be adjusted because they depend on glusterfs:

Reverse-Build-Depends
* fio (for libglusterfs-dev)
* libvirt (for libglusterfs-dev)
* nfs-ganesha (for libglusterfs-dev)
* qemu (for libglusterfs-dev)
* qemu (for glusterfs-common)
* tgt (for libglusterfs-dev)
* uwsgi (for libglusterfs-dev)

Reverse-Build-Depends-Arch
* samba (for libglusterfs-dev)

Let me know if there's anything I can do to help here.

Thanks,

--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

[Patrick Matthäi]

Hey,

(@debian-release, pls CC me)

OK I think this is a realy bad situation, also just so short after the
bookworm release..

@Release team:
What is your opinion about it, should we remove glusterfs on 32 bit
platforms from bookworm? How should we coordinate it also with the other
reverse dependencies? Or should we leave it as it is (for bookworm) and
change it for the upcoming releases?

[Patrick Matthäi]

*ping* (also adding some other maintainers of reverse depends)

[Michael Tokarev]

14.07.2023 20:02, Patrick Matthäi wrote:
> *ping* (also adding some other maintainers of reverse depends)

I don't remember seeing this before.

Yes, I use libglusterfs-dev in Build-Depends of samba and qemu.
I think it is already reduced to 64bits on ubuntu for samba (or,
rather, i386 is excluded).

The question is: how to specify dependencies properly and more important,
how to specify lists of files to install?

Right now I have:

d/control: Build-Depends: libglusterfs-dev
d/foo.install: /usr/lib/foo/gluster.so

I can change the first one to be something like

Build-Depends: libglusterfs-dev [amd64 arm64]

(with a few questions remaining: what is the complete list? How
about non-linux?). But what to do with the second, - move the
handling to d/rules, like

if [ -f debian/tmp/usr/lib/foo/gluster.so ]; then
install -D debian/tmp/usr/lib/foo/gluster.so -t debian/foo/usr/lib/foo/
fi

?

Thanks,

/mjt

[Patrick Matthäi]

Hello,

Am 15.07.2023 um 08:54 schrieb Michael Tokarev:
>
> Yes, I use libglusterfs-dev in Build-Depends of samba and qemu.
> I think it is already reduced to 64bits on ubuntu for samba (or,
> rather, i386 is excluded).
>
> The question is: how to specify dependencies properly and more important,
> how to specify lists of files to install?

I have uploaded glusterfs 11.0-1 to experimental, it is limited to these
architectures:
amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64

So if nobody rises up I would start to fill bugs for the reverse
dependencies in the next days and after that uploading glusterfs 11.x to
unstable.

What happens with stable, there I do not have an answer, yet.

>
> Right now I have:
>
>  d/control: Build-Depends: libglusterfs-dev
>  d/foo.install: /usr/lib/foo/gluster.so
>
> I can change the first one to be something like
>
>   Build-Depends: libglusterfs-dev [amd64 arm64]

So in your depends you should use:

    libglusterfs-dev [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x
ia64 sparc64]

>
> (with a few questions remaining: what is the complete list? How
> about non-linux?).  But what to do with the second, - move the
> handling to d/rules, like
>
>  if [ -f debian/tmp/usr/lib/foo/gluster.so ]; then
>    install -D debian/tmp/usr/lib/foo/gluster.so -t
> debian/foo/usr/lib/foo/
>  fi
>

IMO the best way would be continue to use dh_install, there you can also
limit the architectures:
    [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64]
debian/tmp/usr/lib/foo/gluster.so

You way would work, too. But if you want to build the glusterfs module,
but it is not available (for whatever reason) you wouldnt notice it.

[Michael Tokarev]

20.07.2023 11:40, Patrick Matthäi wrote:
..

> I have uploaded glusterfs 11.0-1 to experimental, it is limited to these architectures:
> amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64

Build-Depends: architecture-is-64-bits

fwiw, anyway. Ok.

> So if nobody rises up I would start to fill bugs for the reverse dependencies in the next days and after that uploading glusterfs 11.x to unstable.

It's an unfortunate timing: I uploaded new qemu a few minutes
before this your reply. Sure thing it went in without the
gluster-related changes. I now fixed the [architecture]
list in there in qemu - next upload will have no deps on
gluster on 32bits.

Doing the same for samba as well now, - next samba will have
no deps on glusterfs on 32bits too.

> What happens with stable, there I do not have an answer, yet.

What's about stable? the version of gluster in stable should
not be affected.

> IMO the best way would be continue to use dh_install, there you can also limit the architectures:
>     [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64] debian/tmp/usr/lib/foo/gluster.so

That's dh-exec, but yes. Somehow I dislike dh_exec personally :)

/mjt

[Michael Tokarev]

So, it looks like after dropping support for 32bit architectures from this
package, but did you file ANAIS bug report against ftp.debian.org?
Without such a bug report, new glusterfs will never migrate to testing due
to missing builds on 32bit architectures, and this will hold all dependent
packages in unstable too.

/mjt

[Michael Tokarev]

26.08.2023 12:04, Patrick Matthäi wrote:
...

>> Without such a bug report, new glusterfs will never migrate to testing due
>> to missing builds on 32bit architectures, and this will hold all dependent
>> packages in unstable too.
>

> Yes sorry it is now removed

Thank you!

FWIW, loong64 is not 32-bits :)

/mjt

[Patrick Matthäi]

Hey

Yes sorry it is now removed

--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer

Blog: https://www.linux-dev.org/
E-Mail: pmat...@debian.org
pat...@linux-dev.org
*/