Please build Debian armhf and amd64 plugins

[leamas]

There is an roadmap to simplify plugin management by using Debian plugins in the whole Debian/Ubuntu/Raspbian universe here

The second part is to make sure we build Debian plugins for both amd64 and armhf. The proposed time schedule is to have this done before next OpenCPN release in late March.

[jongough]

So for ubuntu we only do armhf, for debian we do both armhf and arm64?
What are the targets in the xml that are going to be accepted?

[leamas]

So for ubuntu we only do armhf

...and amd64

What are the targets in the xml that are going to be accepted?

For Debian packaging the goal is that we will end up in debian-armhf and debian-amd64 only. ubuntu-armhf is used in the transition phase we currently are in.

For various reasons using Debian plugins on Ubuntu (and Raspbian) is more consistent and robust than current arrangement, where we use Ubuntu plugins on Debian and Raspbian. This is really what this is all about. Please see the roadmap for details

[jongough]

The values in the xsd is what I need to know. The fact that there is a gtk3 in the middle of the value for ubuntu focal caused a problem for the previous conversion. I just need to know what the values plugin manager is going to check for and accept.

[leamas]

debian-armhf is already in the xsd, and that is what we should use. Luckily, we have not introduced anything like debian-gtk3.

This also means that on buster/10, the only version supporting both wxWidgets/gtk2 and wxWidgets/gtk3 we always use gtk2.

[jongough]

So we have four environments for debian:
buster-armhf
buster-arm64
bullseye-armhf
bullseye-arm64

[leamas]

No. It's buster-armhf, buster-amd64, bullseye-armhf, bulllseye-amd64.

arm64/aarch64 is Flatpak territory.

[rgleason]

Don't know how you guys keep track of the many varieties!

[jongough]

Well the debian images are for armhf and arm64, amd64 is an amd processor not an arm processor, so it is the wrong hardware architecture. So you want debian-amd64 on arm64? Isn't that just causing confusion?

[jongough]

I am trying to avoid the issues that arose with ubuntu and the need to put gtk3 in the middle of the target. Also trying to understand how amd software runs on arm hardware without a compatability layer in there.
https://github.com/docker-library/official-images#architectures-other-than-amd64

[leamas]

Good morning.

So you want debian-amd64 on arm64?

No, no, nothing like that. I just listed -amd64 to get the complete list of Debian plugins. amd64 runs on processors with the amd64 instruction set which also is used on Intel 64-bit processors. And only there.

Which means that the only Debian plugins we build for arm is armhf. On arm64/aarch64 we run Flatpak.

[jongough]

Why use Flatpak for arm64? Its bigger and more complicated than running the whole environment native.

[leamas]

OpenCPN/plugins#372

[jongough]

Cloudsmith alpha has the first pass at debian builds.

[rgleason]

Jon, is this done and testplugin pretty well setup for me to start using? Thanks. Also maybe this can be closed?

[jongough]

Version 1.0.189.3 is now in master and should build armhf/arm64 using ubuntu and debian.

[rgleason]

Thanks Jon, you as owner and Leamas as OP can close this now.

[jongough]

Frontend2 now builds for debian-armhf, but it appears that this is well ahead of where OCPN is. So the effort to get this working is premature to say the least. Why was this issue raised if plugin manager and OCPN not even being built for these environments?

[bdbcat]

Jon....
debian-armhf is part of our longer term plan to move OCPN upstream from ubuntu, to debian.

Here is the "definitive" roadmap:
(OpenCPN/OpenCPN#2502 (comment))

You are right, OCPN56 today cannot use debian-armhf plugins. But we will begin testing this target in OCPN master branch shortly, so it would be useful to have some plugins built for it. The plan is to release OCPN core support for debian-armhf plugins in the next maintenance release, probably in March.

That is why we ask for it now.

[rgleason]

So do you want TP template plugins to build this, but not push to opencpn/plugins?

[leamas]

Just push it. OpenCPN main builds does not support them right now, but this is no problem.

When they are in the catalog, we can test the new OpenCPN builds from master branch. This way, everything is tested when we get next maintenance release out of the doors.

[rgleason]

Ok, Thanks. This is going to take awhile. Also I have some plugins that need other fixes for various OS, like the Preferences not working for Flatpak.

[rgleason]

Roadmap is shown here in this post, but testplugin isn't checked yet for armhf and amd64 plugins.
OpenCPN/OpenCPN#2502 (comment)

[jongough]

v1.0.189.4 should build all the required versions. There is a build for flatpak 2008 beta which should build with wxWidgets 3.15 in 1.0.190.0. What is missing?

[rgleason]

Jon, thanks, sounds very good to me, but I would'nt know.