Closed source binary for arm64 incompatible with plugin

[flupes]

oeserverd for linuxarm64 is version 1.09c while latest version for other platforms is 1.14.
The command line options seem to have changed between these revisions, making the latest version of the plugin inoperable for arm64 platform: plugin freezes at the first call with -s option.

Committing a v1.14 build of the closed source binaries for arm64 would fix the issue for users of RockPi 4, Pine64 and other SBCs with 64bit ARM architectures.

Ubuntu on x86_64:

p***e@rosvm:~/devel/oesenc_pi$ uname -a
Linux rosvm 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
p***e@rosvm:~/devel/oesenc_pi$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
p***e@rosvm:~/devel/oesenc_pi$ git rev-parse HEAD
50f628c7aef0c33d6622a0fe7afed7c17b4da942

p***e@rosvm:~/devel/oesenc_pi$ oeserverd -a
oeserverd Version 1.14

p***e@rosvm:~/devel/oesenc_pi$ oeserverd -s
1
p***e@rosvm:~/devel/oesenc_pi$ oeserverd -t
18***55

Armbian on aarch64

p***e@rockpi:~/source/oesenc_pi$ uname -a
Linux rockpi 4.4.198-rockchip64 #3 SMP Tue Nov 19 00:05:14 CET 2019 aarch64 aarch64 aarch64 GNU/Linux
p***e@rockpi:~/source/oesenc_pi$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
pl***@rockpi:~/source/oesenc_pi$ git rev-parse HEAD
50f628c7aef0c33d6622a0fe7afed7c17b4da942

p***e@rockpi:~/source/oesenc_pi$ oeserverd -a
oeserverd Version 1.09c

p***e@rockpi:~/source/oesenc_pi$ oeserverd -s
p***e@rockpi:~/source/oesenc_pi$ oeserverd -t
p***e@rockpi:~/source/oesenc_pi$ oeserverd -h
e4:B******E
e4:2******3

[gromain]

Hi,
Is there a chance to have an update to oeserverd for arm64? More and more devices are running Raspbian 64 bits, and it would be great to have this! Anything that can be done to help on this?

[bdbcat]

oeserverd is not dependent on 32/64 differences. The 32 bit binary runs fine on ARM64.
What is the results of "oeserverd -a" for your oesenc_pi current installation?

[gromain]

I'm using packages from the Arch User Repository for the plugins, I'm having a look now at how to use the Plugin Manager (that doesn't seem to give me any packages). I'll open an issue for this if needed, and I'll have a look then to answer your question!

[gromain]

Also, I just tried to run oeserverd -a on the latest version available in this repo at https://github.com/bdbcat/oesenc_pi/blob/master/libs/oeserverd/linuxarm64/oeserverd gives oeserverd Version 1.17.
Seems up to date to me. This issue can be closed I believe. (Also, oeserverd for arm from https://github.com/bdbcat/oesenc_pi/blob/master/libs/oeserverd/linuxarm64/oeserverd don't want to run on my Rpi4 running a 64bit ManjaroARM)

[bdbcat]

On the Manjaro...
Please report results of

$ldd oeserverd -a

Thanks
Dave

[gromain]

On the Raspberry:

linux-vdso.so.1 (0x0000ffff87c53000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x0000ffff87ba7000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x0000ffff87b93000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0000ffff8798f000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x0000ffff8796a000)
libc.so.6 => /usr/lib/libc.so.6 (0x0000ffff877f6000)
/lib/ld-linux-aarch64.so.1 => /usr/lib/ld-linux-aarch64.so.1 (0x0000ffff87c22000)
libm.so.6 => /usr/lib/libm.so.6 (0x0000ffff8774a000)

[hreuver0183]

The issue mentioned by gromian:
$ /usr/local/bin/oeserverd -a
oeserverd Version 1.17
$ file /usr/local/bin/oeserverd
/usr/local/bin/oeserverd: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=2c38c815bbb7261171deb9851bf419277ab6e1f5, stripped.
=> native arm64!

I believe there were issues of including the oeserverd in the deb-package for the last few releases.
Frankly I am fine with that behaviour. It forces me to download oeserverd en libsglarm64 straight from github.
But if I do this with a script the package will contain no closed source binaries, which makes distribution of the oesenc_pi wrapper GPL-compliant (which allow me to use some repositories for free). And I can include installing the libusb-0.1-4 dependency with the script.

[hreuver0183]

The original problem has been solved a long time ago.
We have a binary arm64 driver since june 2020.

This issue should really be closed.

[gromain]

The problem was not having the driver or not, it was that it was not distributed properly when building the packages manually.

People who wants to use the plugin are not just going to try and find where to go download the right executable, where to install it. Everything needs to be packaged properly. If this means that this plug-in package cannot be distributed in a gpl-compliant way, so be it.

I believe this is fixed for flatpak packages at least, and through the plugin manager too. So probably this can be closed, if all oeserverd version are the same (since that was the original issue here).

Ping @flupes, can this be closed now?

[hreuver0183]

For me the bigger problem is the distribution of a closed source package.
Installing a script with the package is not really hard.

Putting the binaries in the right place is one, configuring udev is two but and including the right dependencies is three. If you are using deb-files in the old-fashioned way this should all be in the deb (without having to run a script manually). But I think you also experienced the missing oeserverd and the sglock-udev-rule issue.

Not to say that currently the deb-package is broken, but it is in dire need of some maintenance. But with the ocharts_pi on the way I ask myself if it is worth putting much time into it.

For oesenc_pi the script with the after-installation commands is pretty straightforward:
#!/bin/sh
mkdir tmp_oesenc
pushd tmp_oesenc
wget https://github.com/bdbcat/oesenc_pi/blob/master/libs/oeserverd/linuxarm64/libsglarm64-2.31.0.0.so
wget https://github.com/bdbcat/oesenc_pi/blob/master/libs/oeserverd/linuxarm64/oeserverd
sudo cp libsglarm64-2.31.0.0.so /usr/local/bin
sudo cp oeserverd /usr/local/bin
sudo apt install libusb-0.1-4
sudo echo 'ATTRS{idVendor}=="1547", ATTRS{idProduct}=="1000", MODE="660", GPOUP="dialout"' >
/etc/udev/rules.d/98-sglock.rules
popd
rm -rf tmp_oesenc

[gromain]

not really hard

I disagree. For most users, the command line is already scary. We cannot ask them to write or run a script to install something (as a normal way of doing things I mean). Maybe click on something that will launch a prewritten script is OK (because there is still the issue of installed udev rules for the Flatpak distribution).

And even more importantly, this all need to be documented somewhere. For now, doc is missing a lot regarding those issues.

But with the ocharts_pi on the way I ask myself if it is worth putting much time into it.

If users are expected to switch to ocharts with the new release of OpenCPN, I agree.

[bdbcat]

"If users are expected to switch to ocharts with the new release of OpenCPN, I agree."
And they are.
As an "official" OpenCPN policy, deb packages of plugins for OpenCPN are deprecated. They will not be further maintained.

[gromain]

Fair enough. The plugin manager is working well and is a very fine replacement IMO. Solves a lot of troubles with packages too.

…

On Sat, Jun 5, 2021, 15:44 bdbcat ***@***.***> wrote: "If users are expected to switch to ocharts with the new release of OpenCPN, I agree." And they are. As an "official" OpenCPN policy, deb packages of plugins for OpenCPN are deprecated. They will not be further maintained. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQWMVJ65HF4AN5GRRHYLB3TRIS4VANCNFSM4JVUTPOA> .