Making OctoPi build on Ubuntu 64bit so we have 64bit builds

[guysoft]

Ok, so following what was going on in #692 . We are thinking about using Ubuntu to make 64bit builds. And also testing to see how using a distro with predictable release cycles works with OctoPi (we might actually like this long-term).

Current status:

• There is a build at: http://unofficialpi.org/Distros/OctoPi/nightly-arm64/2021-01-11_octopi-20.10-preinstalled-server-arm64+raspi-0.18.0.zip md5: b0296e50919cc16d1d84bfb0e15e0b2c

It seems to load but

1. There is an Ubuntu user and also the Pi user (can be fixed).
2. Pi user has no sudo
3. HA proxy does not load. I get:

   /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -S /run/haproxy-master.sock
   [NOTICE] 010/111929 (4074) : haproxy version is 2.2.3-2
   [NOTICE] 010/111929 (4074) : path to executable is /usr/sbin/haproxy
   [ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:35] : The 'reqrep' directive is not supported anymore since HAProxy 2.1. Use 'http-request replace-path', 'http-request replace-uri' or 'http-request replace-header' instead.
   [ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:36] : The 'reqadd' directive is not supported anymore since HAProxy 2.1. Use 'http-request add-header' instead.
   [ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:37] : The 'reqadd' directive is not supported anymore since HAProxy 2.1. Use 'http-request add-header' instead.
   [ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:43] : The 'reqrep' directive is not supported anymore since HAProxy 2.1. Use 'http-request replace-path', 'http-request replace-uri' or 'http-request replace-header' instead.
   [ALERT] 010/111929 (4074) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg
   [ALERT] 010/111929 (4074) : Fatal errors found in configuration.

   Possible fix by @CRCinAU at: https://github.com/guysoft/OctoPi/issues/692#issuecomment-757891021

[guysoft]

@foosel looks like a plugin manager bug?

[foosel]

@guysoft Negative, the plugin manager isn't involved anymore at this point, that's a failing pip install during intake of a dependency.

[ping-localhost]

Here are my version, in case it helps (they are the same):

pi@octopi:~$ /home/pi/oprint/bin/python -m pip --version
pip 21.0.1 from /home/pi/oprint/lib/python3.8/site-packages/pip (python 3.8)
pi@octopi:~$ /home/pi/oprint/bin/python --version
Python 3.8.6 

pi@octopi:~$ python3 -m pip --version
pip 21.0.1 from /home/pi/.local/lib/python3.8/site-packages/pip (python 3.8)
pi@octopi:~$ python3 --version
Python 3.8.6 

[werdnum]

I'm currently testing/using the latest nightly build 2021-02-23_octopi-20.10-preinstalled-server-arm64+raspi-1.0.0.zip on my RPI4 8GB and PSU control (and GPIO Control/anything that uses RPi.GPIO) fails to be installed due to the following error:

2021-02-23 21:52:16,545 - octoprint.plugins.pluginmanager - ERROR - Reason: UnicodeEncodeError('latin-1', '  source/c_gpio.c: In function ‘setup’:\n', 31, 32, 'ordinal not in range(256)')

I've some logs available as a gist here: https://gist.github.com/ping-localhost/aad12f9619b13deaf5e2d6810407a0f5

As far as I can tell, this seems to be a silly error wherein the command-line output is being converted from Unicode to latin1 to strip out the colour control characters, and the string doesn't work as latin1 because the output contains non-latin1 characters. I hacked around it in my installation by just editing the offending file (/home/pi/oprint/lib/python3.8/site-packages/octoprint/util/commandline.py) to change line 57 from this:

 return _ANSI_REGEX.sub(b"", line.encode("latin1")).decode("latin1")

to this:

 return _ANSI_REGEX.sub(b"", line.encode("latin1", "namereplace")).decode("latin1", "namereplace")

and restarting octoprint. You could also use ignore instead of namereplace probably, but I didn't test that because it doesn't actually matter very much what the command-line output is, as long as it doesn't throw an error.

[guysoft]

This is part of the nightly build and is planned to be released when we release. So new bugs should go in a separate issue. Closing.