Fix problem where cmake fails to detect compiler

[vector76]

I believe this is why the builds began failing around March 12th. It appears the version of Cmake changed from 3.13.4-1 to 3.16.3-3~bpo10+1.

I found this fix while examining why v1pi was failing to build. Apparently current cmake (3.16) fails with the GLOB operation and it sounds like it's related to this issue https://gitlab.kitware.com/cmake/cmake/-/issues/20568 According to that thread, this is a consequence of an update within 3.15, and (probably) fixed sometime before 3.19.

[guysoft]

Its building fine here since 2021-03-19

It seems to be using cmake armhf 3.16.3-3~bpo10+1

[vector76]

Perhaps I am looking in the wrong place. I see failures here: https://github.com/guysoft/OctoPi/actions

and in the raw logs I am seeing cmake failing to detect the compiler 2021-03-22T00:11:39.7336586Z -- The C compiler identification is unknown

The last successful compile in the github actions was 3-11 and that one used a different version of cmake.

I tried manually (via CustomPiOS) building the v1pi image which includes OctoPi and I see the same failures that show in the github actions unless I specify the cmake version, in which case it succeeds.

This system is new to me so it's possible I'm looking in the wrong place. Am I misinterpreting the failures?

[guysoft]

Strange, my local builds on jenkins work fine. Attaching the build log. Its using the same version of cmake. consoleText.txt

[guysoft]

Ok, found something,

Starting custompios-watcher ... error

Perhaps my local builds were not updating the custompios container right. Does not allign with this commit, but it is something to detect

[vector76]

Ok, for what it's worth, the mjpg-streamer builds fine on the pi itself, even with the updated cmake. From the thread on kitware, it sounds like it's something to do with 64-bit inode values overflowing, which is not a problem on the target but is potentially a problem in qemu. From that I'm guessing it might not be deterministic.

I suppose I got lucky that I was able to reproduce the error in my Ubuntu host (no container), as there might not be a guarantee that the issue would manifest.

It's a bit beyond me so I'd suggest scanning the kitware thread and see if you arrive at a similar conclusion.

[guysoft]

kitware thread?

[vector76]

Sorry, first post: https://gitlab.kitware.com/cmake/cmake/-/issues/20568

Kitware are the maintainers of cmake.

What caught my eye in particular was someone suggested "it turns out that the readdir sets errno to EOVERFLOW, so this may not reproduce depending on the magnitude of the (inode?) numbers in the filesystem". https://gitlab.kitware.com/cmake/cmake/-/issues/20568#note_755570

This is assuming that this is the same issue. Elsewhere in that thread they indicate that the change that would have produced this issue began in 3.15 which is consistent with my observation that 3.16 exhibits the issue and 3.13 does not.

[guysoft]

Looks like this solves the issue for other people too. So I am merging it: https://github.com/guysoft/CustomPiOS/issues/120

[guysoft]

This breaks the arm64 build though :-/

0 upgraded, 0 newly installed, 0 to remove and 118 not upgraded.
+ apt-get -y --force-yes install python3 python3-virtualenv python3-dev git screen subversion cmake=3.13.4-1 cmake-data=3.13.4-1 avahi-daemon libavahi-compat-libdnssd1 libffi-dev libssl-dev libatlas3-base
Reading package lists...
Building dependency tree...
Reading state information...
W: --force-yes is deprecated, use one of the options starting with --allow instead.
E: Version '3.13.4-1' for 'cmake' was not found
E: Version '3.13.4-1' for 'cmake-data' was not found

[foosel]

Am I right in assuming this issue can be considered resolved in cmake 3.18.4 if I can successfully build mjpg-streamer with that in qemu? It seems like 3.13 won't be available in bullseye, so as soon as we start building against bullseye based images the build will break due to this pinned version.

[foosel]

@guysoft so the question above arose because back then I was experimenting with building against the alpha version of what has now become the official Raspberry Pi Bullseye image, and the build against that is now indeed broken as visible in the current action runs here. Can this be removed? If so I can send in a patch with what I figured out back then to get the build going...

diff --git a/src/modules/octopi/config b/src/modules/octopi/config
index 5064055..b39f19a 100755
--- a/src/modules/octopi/config
+++ b/src/modules/octopi/config
@@ -20,9 +20,6 @@
 # HAProxy
 [ -n "$OCTOPI_INCLUDE_HAPROXY" ] || OCTOPI_INCLUDE_HAPROXY=yes

-# WiringPi
-[ -n "$OCTOPI_INCLUDE_WIRINGPI" ] || OCTOPI_INCLUDE_WIRINGPI=yes
-
 # yq
 [ -n "$OCTOPI_YQ_DOWNLOAD" ] || OCTOPI_YQ_DOWNLOAD=$(wget -q -O - https://api.github.com/repos/mikefarah/yq/releases/latest | grep "browser_download_url" | grep "yq_linux_arm" | cut -d : -f 2,3 | tr -d \" | tr -d ,)

diff --git a/src/modules/octopi/start_chroot_script b/src/modules/octopi/start_chroot_script
index 7c07a27..11b981b 100755
--- a/src/modules/octopi/start_chroot_script
+++ b/src/modules/octopi/start_chroot_script
@@ -34,12 +34,7 @@ echo "removing:" $remove_extra
 apt-get remove -y --purge  $remove_extra
 apt-get autoremove -y

-if [ "${BASE_DISTRO}" == "ubuntu" ]; then
-    apt-get -y --force-yes install python3 python3-virtualenv python3-dev git screen subversion cmake cmake-data avahi-daemon libavahi-compat-libdnssd1 libffi-dev libssl-dev libatlas3-base unzip
-else
-    apt-get -y --force-yes install python3 python3-virtualenv python3-dev git screen subversion cmake=3.13.4-1 cmake-data=3.13.4-1 avahi-daemon libavahi-compat-libdnssd1 libffi-dev libssl-dev libatlas3-base
-fi
-
+apt-get -y --force-yes install python3 python3-virtualenv python3-dev git screen subversion cmake cmake-data avahi-daemon libavahi-compat-libdnssd1 libffi-dev libssl-dev libatlas3-base unzip

 echo " - Reinstall iputils-ping"
 apt-get install --reinstall iputils-ping
@@ -154,12 +149,6 @@ EOT
     rm /etc/ssl/private/ssl-cert-snakeoil.key /etc/ssl/certs/ssl-cert-snakeoil.pem
   fi

-  if [ "$OCTOPI_INCLUDE_WIRINGPI" == "yes" ]
-  then
-    echo "--- Installing WiringPi"
-    apt-get -y install wiringpi
-  fi
-
   # fetch current yq build and install to /usr/local/bin
   wget -O yq $OCTOPI_YQ_DOWNLOAD && chmod +x yq && mv yq /usr/local/bin

[guysoft]

1. You want to remove wiring pi? I think one needs it for Ubuntu, ot might be better to set the variable when ubuntu, and to no when rpios.
2. There are ububtu packages there in the if that.ks removed, are they identical now or did you just remot the 'if'?

[foosel]

1. I have to remove wiringpi because it no longer is available (and actually also no longer being maintained). The thing is sadly dead.
2. The only difference between the two lines after removing the cmake version pin is the added unzip dependency, which on other platforms than ubuntu (read: raspbian) is already there, turning this into a no-op.

PR is #757. My goal with that is to first and foremost get it building under the major OS it's build against again, if there are any issues with these changes under ubuntu it would be lovely if someone who actually builds against that could check and confirm and I'll be happy to adjust (I'm not set up for this and frankly lack the time to change that as well). As things are right now the whole build is broken against the primarily used base image.

[guysoft]

1. Ok shame, didnt know, then I guess we should remove it.
2. Then perhaps its a good idea to add an "if Ubuntu then install unzip". Whether as a variable that is appended as an arg or some other method you like.

Ubuntu currently is the to-be-released official 64bit distro until Rpi Foundation decide its not experimental (see https://github.com/RPi-Distro/pi-gen/issues/481 ). I am testing and building nightly builds against it since Jan, the related issue on OctoPi issue tracker why Ubuntu is here: #711 Frankly I have a feeling Ubuntu might be a better candidate for predictable builds in the long run. Bullseye being released and causing havoc is what I am trying to avoid in the future. I am not sure if you knew of a release date on your end, I didn't.