search

jongough / testplugin_pi

Pluing to test JSON and ODAPI
GNU General Public License v3.0
3 stars 9 forks source link

CI build environment: debian #303

Closed rgleason closed 1 year ago

rgleason commented 1 year ago

Bdbcat wrote:

Here is a build of shipdriver, using a CCI debian/Bullseye docker image, AFICT: https://app.circleci.com/pipelines/github/Rasbats/shipdriver_pi/912/workflows/1b332e1d-3750-4172-a425-33668b0a8da9/jobs/8090

It may be that there is no CCI image for bookworm yet, in which case I think shipdriver is using ubuntu 22.04 as a substitute.

Jon wrote:

As far as I can see it is using a ubuntu environment:

Build-agent version 1.0.167442-c2c298be (2023-04-14T17:51:19+0000) System information: Server Version: 20.10.18 Storage Driver: overlay2 Backing Filesystem: xfs Cgroup Driver: cgroupfs Cgroup Version: 1 Kernel Version: 5.15.0-1030-aws Operating System: Ubuntu 20.04.5 LTS OSType: linux Architecture: x86_64

based on the config.yml this entry appears to be ubuntu:

build-bookworm: machine: image: ubuntu-2004:2022.04.1 resource_class: medium environment:

This is not an debian environment. The code in shipdriver is pure ubuntu as circleci does not support debian any more just ubuntu. So now a docker image inside a ubuntu machine is needed. So why are we doing this? The whole thing is more complicated?

Jon wrote:

I have cobbled together a bookworm build using ubuntu with a debian docker and created, I think, a module that could be used. It is currently in the testplugin-alpha repository. I need to clean up the build scripts a bit, but I hope this may work. Can anyone try it out?

Rick wrote:

Maybe we should ask on the forum? It appears to be going to cloudsmith testplugin-alpha

So doing a search in cloudsmith testplugin-alpha using "1.0.232 wx32 debian bookworm"

I guess the most recent should be used? I will post this request in the forum.

Posted https://www.cruisersforum.com/forums/f134/tp-template-testing-needed-275176.html#post3770389

bdbcat commented 1 year ago

In the actual buildlog of Shipdriver, for bookworm, we see:

+ docker run -e CLOUDSMITH_STABLE_REPO -e CLOUDSMITH_BETA_REPO -e CLOUDSMITH_UNSTABLE_REPO -e CIRCLE_BUILD_NUM -e TRAVIS_BUILD_NUMBER -v /home/circleci/project:/ci-source:rw debian:bookworm /bin/bash -xe /ci-source/build.sh
Unable to find image 'debian:bookworm' locally
bookworm: Pulling from library/debian

So looks like debian (in a docker) to me.

jongough commented 1 year ago

It is a docker version of debian under a ubuntu circleci machine. I did have one working a few builds ago, but it is having to install a large amount of packages to make it work. It would appear that shipdriver is using a customised version of debian. Testplugin did this before to try and reduce the load on the circleci, and hence the processing required, as there is a limited amount of resources that individuals can consume.

I am trying to get the build flow working, but only have limited time to do so. I can see if I can get a version working without all the new builds needed and then try to get the new builds working with a new version number. This process is really in the alpha phase even though I did generate a beta version for limited testing.

rgleason commented 1 year ago

https://github.com/CircleCI-Public/cimg-base cimg/base Latest version: 2023.04 A base Ubuntu Docker image built to run on CircleCI

cimg/base is an Ubuntu Docker image created by CircleCI with continuous integration builds in mind. As its name suggests, this image is designed to serve as a base image for other CircleCI Convenience Images (images prefixed with cimg/).

This image is also very useful for CircleCI users to use as a base for their own custom Docker images.

This image contains the minimum tools required to operate a build on CircleCI (such as git) as well as extremely popular and useful tools in CircleCI (such as docker).

jongough commented 1 year ago

Yep, using that image (or versions of it) for some builds. It is the debian image that is nolonger supported by circleci so a ubuntu image is needed with a docker instance inside it. This then has potential issues for you building multiple plugins. The resources taken to get it up to spec for a build are OK for a single plugin but are likely to cause you to be locked out for multiple plugins. I had used some docker images updated as needed and put back in my 'area' that cut down on this issue. But that takes time to arrange/sort out, which at the moment I don't really have.

rgleason commented 1 year ago

3 weeks ago: https://circleci.com/docs/images/linux-vm/16.04-to-20.04-migration/#switching-to-a-supported-image

Docker layer caching? https://circleci.com/docs/concepts/#docker-layer-caching Docker layer caching (DLC) caches the individual layers of Docker images built during your CircleCI jobs. Any unchanged layers are used on subsequent runs, rather than rebuilding the image each time.

In the .circle/config.yml snippet below, the build_elixir job builds an image using the ubuntu-2004:202104-01 Dockerfile. Adding docker_layer_caching: true below the machine executor key ensures CircleCI saves each Docker image layer as the Elixir image is built.

On subsequent commits, if the Dockerfile has not changed, DLC pulls each Docker image layer from cache during the build Elixir image step and the image builds significantly faster.

See the Docker layer caching page for more information. https://circleci.com/docs/docker-layer-caching/

Don't know if this will help.

jongough commented 1 year ago

I have added the docker caching to the jobs and will see how that goes. I have currently commented out the bookworm-w32 builds to get something into master that can be used. I will then try them to see how it goes.

rgleason commented 1 year ago

It looks like caching didn't fail. I hope this is working. It looks like it all built in 7m except appveyor.

Notes on Cloudsmith searches on Testplugin Alpha "1.0.235.0 metadata" compared to TP Template Table I find this process to be quite complex and the only way I can understand what we are building is to check testplugin-alpha against the TP Template and compare the results. I hope this is a helpful guide.

OpenCPN 5.8 Plugins (wxWidgets 3.2.2.1) "wx32"

MacOS and Windows - OK

1.0.235.0 flatpak metadata need flatpak-aarch64-22.08-arm64

1.0.235.0 debian buster wx32 metadata Not Needed - (Remove from TP Template Table) debian-wx32-armhf-10-gtk3-buster debian-wx32-armhf-10-buster debian-wx32-x86_64-10-buster

1.0.235.0 debian bullseye wx32 metadata We DO need these to support Jammy debian-wx32-arm64-11-bullseye debian-wx32-armhf-11-bullseye debian-wx32-x86_64-11-bullseye

1.0.235.0 debian bookworm wx32 metadata 3 Products - OK

OpenCPN 5.6.2 Plugins (wxWidgets 3.1.2)

MacOS and Windows - OK

1.0.235.0 flatpak metadata 2 products -OK

1.0.235.0 debian buster metadata missing debian-arm64-10-buster

1.0.235.0 debian bullseye metadata 3 products - OK

1.0.235.0 raspbian stretch metadata 1 product - OK

1.0.235.0 ubuntu armhf metadata 2 products - OK - (should be commented out when done).

LennartG-Sve commented 1 year ago

Compiled GPS Odometer version 0.7.0.3, using the latest TP 1.0.235. Local compile ok. Excluded Android and Windows and uploaded to git Cloudsmith Beta.

All builds worked ok but I reached a concurrency limit on 'build-macos-wx32'. Should be ok though as it has worked before and, to my knowledge, has not changed. Then tested the tar.gz packages for 'build-focal-gtk3' and 'build-jammy' on my local 5.8.0 systems.

1/ Ubuntu focal works as expected. 2/ Ubuntu jammy still indicates 'Incompatible import plugin detected'.

That is what I can verify.

rgleason commented 1 year ago

Thanks Lennart, I posted this test request on the forum Jon may need more detail.

jongough commented 1 year ago

As first pass I did not build most of the -wx32 versions as I am not sure the file names and xml are correct. Some of the file names seem correct and the xml seems to have the correct tuple, but.... I have put 1.0.235 in master but have only built for alpha and beta. I have put a pull request into plugins for this version.

rgleason commented 1 year ago

@bdbcat can you please advise about this? Jon wrote:

I did not build most of the -wx32 versions as I am not sure the file names and xml are correct

We reviewed the entire list in an iterative process which resulted in this TP Template List

Are any of the debian builds listed under O58 and O562 incorrect in TP Template List ? If so, please clarify, because Jon thinks there is some problem....

bdbcat commented 1 year ago

Rick... Sorry, I had not reviewed the final edit of the template list. Changes required:

  1. We do not need to build any Debian 10 Buster wx32.
  2. We do not need to build any Debian 11 Bullseye wx32.

For debian Buster and Bullseye, wx32 is not available at all, O580 uses wx30 for these platforms.

As usual, it is up to the plugin dev to decide whether to treat a plugin as "frozen" for these platforms, or to make new wx30 builds for these platforms. How to decide? If the plugin contains significant new features or bug fixes that one wants to make available to users of this plugin, then make a new build for them. For example, I'm thinking about StatusBar plugin. When we fix the existing problems on this plugin, we will certainly want to make new wx30 builds so that we can re-introduce it to the catalog.

rgleason commented 1 year ago

@bdbcat @jongough OK, thank you Dave. I've modified the post above accordingly

For debian Buster and Bullseye, wx32 is not available at all, O580 uses wx30 for these platforms.

Before I make changes to the TP Template Table since this has been an iterative process, if you could take a look at:

Item 8. Debian 11 always uses gtk3. Item 9. Debian 11 exists in two versions, debian and debian-wx32._

which I now find is in conflict with

Item 13.  Debian uses wx32 from version 12 (in Debian-wx32-11 it is explicitly stated)
Other Debian ABI:s use wx30

Also, Since this is somewhat complex, if you would take a look at your post from Lennarts Issue, and confirm again what you advised in the post just above, we will follow your lead and gladly remove those debian from the list.

Thank you Dave and thank you Jon for bringing this it to our attention.

bdbcat commented 1 year ago

Rick...

  1. Debian-11+ always uses gtk3.
  2. Correct
  3. Correct.

So, contrary to my previous post, we DO need debian-11-wx32 plugins. This is mainly to support ubuntu Jammy, which is something of a hybrid. Sorry for the mis-statement earlier. Dave

rgleason commented 1 year ago

Thanks very much. There is a lot going on!

rgleason commented 1 year ago

I am removing these builds from TP Template Table

Debian 10 Buster wx32 DO NOT BUILD THESE
debian-wx32-arm64-10-buster Buster* wx32 gtk3 O58 ADD
debian-wx32-armhf-10-gtk3-buster Buster* wx32 gtk3 O58 ADD
debian-wx32-armhf-10-buster Buster* wx32 gtk3 O58 ADD
debian-wx32-x86_64-10-buster Buster* wx32 gtk3 O58 ADD
rgleason commented 1 year ago

After the changes this is what TP Temple Table looks like. I changed the files for "Debian Bookworm" removing the wx32 because it is assumed, and there is no wx30 version, however the metadata and tarball file names can both be "named" with a "-wx32" which is not used by PIM as the to help me with identification of O58 and O562 metadata, which I will need.

jongough commented 1 year ago

I am having difficulty finding arm(hf/64) libwxgtk3.2-dev installable package for bullseye. It appears not to be in the standard repository, whereas libwxgtk3.0-dev does. So it would appear that we are not following the debian default. Looking in Shipdriver it is using a customised version maintained by the developer. Is this what we are supposed to be doing or is OCPN going to make the wxWidgets files available for plugins to build against?

rgleason commented 1 year ago

@bdbcat In addition to Jon's question above, have I got this right now? TP Template Table

bdbcat commented 1 year ago

Jon... First, understand that wx32 on Bullseye is a "special case". It it made specifically to support Ubuntu Jammy, which is something of a hybrid of debian 11 and 12. The reason we have to do this is because jammy identifies as being based on debian 12, but does not offer wx32 in its base repos. A question of release timing, I think. This kind of thing happens... The PPA made by @leamas has been copied verbatim to the OCPN Release PPA. It contains the wx32 libs used to build OCPN 58 on jammy. The PPA also contains the required runtime libs. So it is the "official" source for wx32 on debian Bullseye, wherever required. You should us it in the same way that shipdriver does.

bdbcat commented 1 year ago

Rick... TP Template Table looks correct now. Thanks

jongough commented 1 year ago

I am having difficulty in getting the ppa working on bullseye-arm64 (the test environment I am using). The latest is a series of errors from the ppa

+ add-apt-repository -y ppa:opencpn/opencpn
gpg: keybox '/tmp/tmp_3q6me2f/pubring.gpg' created
gpg: /tmp/tmp_3q6me2f/trustdb.gpg: trustdb created
gpg: key 67E4A52AC865EB40: public key "Launchpad PPA for OpenCPN" imported
gpg: Total number processed: 1
gpg:               imported: 1
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
gpg: no valid OpenPGP data found.
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.9/threading.py", line 892, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 688, in addkey_func
    func(**kwargs)
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 386, in add_key
    return apsk.add_ppa_signing_key()
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 273, in add_ppa_signing_key
    cleanup(tmp_keyring_dir)
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 234, in cleanup
    shutil.rmtree(tmp_keyring_dir)
  File "/usr/lib/python3.9/shutil.py", line 718, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib/python3.9/shutil.py", line 675, in _rmtree_safe_fd
    onerror(os.unlink, fullname, sys.exc_info())
  File "/usr/lib/python3.9/shutil.py", line 673, in _rmtree_safe_fd
    os.unlink(entry.name, dir_fd=topfd)
FileNotFoundError: [Errno 2] No such file or directory: 'S.gpg-agent.ssh'
+ apt-get -y --allow-unauthenticated update
Hit:1 http://deb.debian.org/debian bullseye InRelease
Hit:2 http://deb.debian.org/debian-security bullseye-security InRelease
Hit:3 http://deb.debian.org/debian bullseye-updates InRelease
Hit:4 http://deb.debian.org/debian bullseye-backports InRelease
Ign:5 http://ppa.launchpad.net/opencpn/opencpn/ubuntu mantic InRelease
Err:6 http://ppa.launchpad.net/opencpn/opencpn/ubuntu mantic Release
  404  Not Found [IP: 185.125.190.52 80]
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/opencpn/opencpn/ubuntu mantic Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
+ echo Stopping

Really not sure where `ubuntu mantic' is coming from.

jongough commented 1 year ago

There appear to be dependency problems when trying to build for debian arm64 bullseye wx32. The latest, using the widgets at ocpn ppa is the following:

The following packages have unmet dependencies:
 libwxbase3.2-1 : Depends: libc6 (>= 2.34) but 2.31-13+deb11u6 is to be installed
                  Depends: libstdc++6 (>= 11) but 10.2.1-6 is to be installed
 libwxgtk3.2-1 : Depends: libc6 (>= 2.33) but 2.31-13+deb11u6 is to be installed
                 Depends: libjpeg8 (>= 8c) but it is not installable
                 Depends: libstdc++6 (>= 11) but 10.2.1-6 is to be installed

I will comment out the arm(hf/64) debian bullseye wx32 builds to allow this process to be used for all other builds. When the dependency issues have been sorted out then these can be re-enabled.

This version is in master as version 1.0.237.0 .

rgleason commented 1 year ago

Jon, thank you for your efforts to get us aligned with what is needed! I really appreciate it. We wish you safety and enjoyment in your next journey. We will figure out bullseye once the dust settles and perhaps some other eyes have a chance to look at the problem. Meanwhile the rest of the builds appear to be good, so we should just start building plugins!

jongough commented 1 year ago

The issue for multiple builds of multiple plugins may be the resource that is going to be used in circleci. I notice that the docker images being used need a large number of updates to get them to the build level. This is the reason some of FE2 uses docker images which I have upgraded, the ones with jongough as the first part of the name. I will have a look at doing similar 'upgrades' for the newer builds when I can.

Good luck with the builds.