Deluge fails on Raspbian Bullseye

[MichaIng]

On Raspbian Bullseye, starting the Deluge daemon fails with the error message:
-------
ModuleNotFoundError: No module named 'deluge.libtorrent'
-------
despite the fact that python3-libtorrent and libtorrent-rasterbar10 are installed.

A similar bug has been reported on Debian, but it was solved already: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975891

Probably the solution is not applicable on armv6hf or needs to be applied differently?

[MichaIng (michaing)]

The issue is still present, breaking Deluge effectively on Raspbian Bullseye. There is however a workaround available: https://github.com/MichaIng/DietPi/issues/4944#issuecomment-978817579
-------
apt install libatomic1
export LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libatomic.so.1
-------
So the "libatomic1" package is a missing dependency of the "python3-libtorrent" package. Indeed for armv7hf it is not required, but for armv6hf it is. On Debian, the armel and mipsel architecture packages have this dependency accordingly: https://packages.debian.org/bullseye/python3-libtorrent
Raspbian however uses sources for armhf, hence armv7hf from Debian.

But the library is not automatically loaded, as it has not been linked. Hence it needs to be preloaded. Doing so for the whole interactive shell and all subshells is probably not desired, so this should be done within a wrapper script, sysvinit or systemd service. For the latter, adding
-------
[Service]
Environment=LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libatomic.so.1
-------
does the trick.

[peter green (plugwash)]

> Raspbian however uses sources for armhf

Well there aren't really "sources for armhf" as such. Debian builds the binary packages for all architectures from the same source packages. Still yes we keep the armhf architecture name*. So if a package's build scripts do conditionals on the Debian architecture name they will do the same thing on Raspbian as on Debian armhf.

Not that it would have made any difference in this case if we had used a new Debian architecture name for Raspbian, since the list was a list of architectures to link with libatomic on, not a list of architectures to avoid linking with it on.

Anyway I'll try and get this fixed, thanks for the analysis.

* While I don't think it's explicitly stated anywhere, precedent both within Debian itself and from Ubuntu is that Debian architecture names specify a CPU family and an ABI but not a particular set of minimum CPU requirements. What does make Raspbian a bit unusual is that we lowered the minimum CPU requirements rather than raising them.

[MichaIng (michaing)]

> So if a package's build scripts do conditionals on the Debian architecture name they will do the same thing on Raspbian as on Debian armhf.

Ah yes, that is what I meant, thanks for clarifying.

> Debian architecture names specify a CPU family and an ABI but not a particular set of minimum CPU requirements.

Debian armhf == ARMv7 (minimum) in practice. The fact that there are no ARMv6 + hard-float builds on Debian is the whole point of Raspbian, isn't it? Usually untouched Debian sources build + run fine, otherwise often archive.raspberrypi.org ships armv6hf compatible builds, but there are the remaining rare broken cases. I remember libatomic being an issue more than once, and any OpenJDK above 8 fails :(.

> Anyway I'll try and get this fixed, thanks for the analysis.

Many thanks, that would be great. In case of Deluge and for our users, the workaround is done and simple, but "python3-libtorrent" is likely used by other packages or own Python projects as well. I hope keeping a patch for this in Raspbian does not cause too much long term maintenance.

Best regards,

Micha

[peter green (plugwash)]

>> Debian architecture names specify a CPU family and an
>> ABI but not a particular set of minimum CPU requirements.
> Debian armhf == ARMv7 (minimum) in practice. The fact that there are no
> ARMv6 + hard-float builds on Debian is the whole point of Raspbian, isn't it?

Yes it is the point of Raspbian.

What I mean is while a given release of a given Debian port will obviously have a set of minimum CPU requirements defined by Debian, those requirements can and do get raised over time without a change in the port name. For example the Debian i386 port's minimum CPU requirements have gradually increased from 386 to 686. The debian armel port's minumum requirements increased from armv4t to armv5t. I suspect other architectures had changes too though I didn't keep track of exactly what they were.

Similarly in the world of derivatives, Ubuntu often had higher minimum CPU requirements from Debian while maintaining the same architecture names.

On the other hand when the ABI was changed, the port name was changed. The "arm" port used the old ABI, the "armel" port uses the baseline version of EABI, and the "armhf" port uses the vfp variant of EABI.

So when Mike and I created Raspbian I felt (and still feel) that keeping the armhf architecture name was the correct thing to do. We were/are a little unusual in that we were reducing the CPU requirements not increasing them but I don't think that is a fundamental difference.

> Usually untouched Debian sources build + run fine

Indeed, and quite a few packages are patched so they build, but I don't have the resources to investigate every issue in depth. Nor do I even know what every issue is.

> otherwise often archive.raspberrypi.org ships armv6hf compatible builds

Archive.raspberrypi.org tends to be more about adding support for pi-specific stuff and/or about packaging software that raspberry Pi want which is not in Debian than about patching armv6 related bugs.

> but there are the remaining rare broken cases. I remember libatomic being an issue more than once

For compiled binaries the libatomic issue gets caught at link time, but for libraries (including things like plugins and modules for dynamic languages) it doesn't get necessarily get caught because the linker will allow building of shared libraries that have unresolved symbols (and indeed some plugin architectures rely on this).

> any OpenJDK above 8 fails :(.

Indeed, Java is a problem, sadly I lack the resources to fix it and getting rid of it isn't really an option either.

[MichaIng (michaing)]

> So when Mike and I created Raspbian I felt (and still feel) that keeping the armhf architecture name was the correct thing to do.

There is quite much criticism about this, as it allows APT/dpkg to automatically select incompatible packages from e.g. 3rd party repositories. We made a mistake to apply Ondrej's PHP repository on ARMv6 RPis to provide PHP7.3 on Raspbian Stretch that time, and it rendered the system unbootable. Okay usually an incompatible binary simply throws an error and good and I still do not sure why installing this PHP build could break the whole system (we reverted immediately instead of investigating), I guess it was due to other dependencies/libraries being upgraded from that repo, including libssl, if I remember right.

But avoiding such by using an own port name like "armv6hf" would have made things for developers/maintainers more complicated which do want to support Raspberry Pi with released binaries of their project: Currently usually "armhf" packages are shipped with do run on both, RPi ARMv6 and ARMv7, while with a dedicated port name two packages would have been required. And whether APT and dpkg accept custom port names without deeper changes or not is a different question.

And using armel would have meant to ignore hardware floating point support or break compatibility with Debian armel.

So I think with always limited time you did the best out of the situation that Debian did/does not support this ARMv6 hard-float ARM that RPi 1/Zero is :).

-------

We did some testing with the OpenJDK 11 (and 17) packages on ARMv6 RPis and it's the JVM itself which seems to be incompatible. There is a single Zulu JRE 11 build which does work, so it's at least not Java in general, but I fear a fix would require a larger patch. At least OpenJDK 8 is still kept available on Raspbian Bullseye.

Since v11 and v17 do work fine on RPi 2 and newer, they should be definitely kept. Probably the preinst script could get a uname -m check and in case abort with a meaningful message.

But all off-topic, sorry for that :).

[peter green (plugwash)]

Can you test with version 1.2.9-0.3+rpi1 and tell me whether it fixes your problem?

[MichaIng (michaing)]

Great, it works well now without the workaround. Also libatomic1 is now pulled as dependency by python3-libtorrent. Perfect, many thanks for the fix!