You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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.
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?
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.
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?
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.
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.
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?
Activity
jongough commentedon Jan 14, 2022
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 commentedon Jan 14, 2022
...and amd64
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 commentedon Jan 14, 2022
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 commentedon Jan 15, 2022
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 commentedon Jan 15, 2022
So we have four environments for debian:
buster-armhf
buster-arm64
bullseye-armhf
bullseye-arm64
leamas commentedon Jan 15, 2022
No. It's buster-armhf, buster-amd64, bullseye-armhf, bulllseye-amd64.
arm64/aarch64 is Flatpak territory.
rgleason commentedon Jan 15, 2022
Don't know how you guys keep track of the many varieties!
jongough commentedon Jan 16, 2022
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 commentedon Jan 16, 2022
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 commentedon Jan 16, 2022
Good morning.
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 commentedon Jan 16, 2022
Why use Flatpak for arm64? Its bigger and more complicated than running the whole environment native.
leamas commentedon Jan 16, 2022
OpenCPN/plugins#372
jongough commentedon Jan 16, 2022
Cloudsmith alpha has the first pass at debian builds.
rgleason commentedon Jan 22, 2022
Jon, is this done and testplugin pretty well setup for me to start using? Thanks. Also maybe this can be closed?
jongough commentedon Jan 23, 2022
Version 1.0.189.3 is now in master and should build armhf/arm64 using ubuntu and debian.
rgleason commentedon Jan 23, 2022
Thanks Jon, you as owner and Leamas as OP can close this now.
jongough commentedon Jan 26, 2022
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 commentedon Jan 26, 2022
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 commentedon Jan 26, 2022
So do you want TP template plugins to build this, but not push to opencpn/plugins?
leamas commentedon Jan 26, 2022
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 commentedon Jan 26, 2022
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 commentedon Jan 27, 2022
Roadmap is shown here in this post, but testplugin isn't checked yet for armhf and amd64 plugins.
OpenCPN/OpenCPN#2502 (comment)
jongough commentedon Jan 27, 2022
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 commentedon Jan 27, 2022
Jon, thanks, sounds very good to me, but I would'nt know.