crash with interface connection but without internet

(EDIT: I actually think this is a python bug, but the PR work-around avoids the crash) I use a portal often, that means I have an interface connection, but until I login through the portal, I dont actually have an internet connection. The auto check fails at startup, way down deep inside a python library. NOTE: this does not happen when I dont have an interface connection (eg if I disconnect wifi or ethernet).

Traceback (most recent call last):
  File "/usr/lib/python3.7/urllib/request.py", line 1324, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "/usr/lib/python3.7/http/client.py", line 1244, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1290, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1239, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1026, in _send_output
    self.send(msg)
  File "/usr/lib/python3.7/http/client.py", line 966, in send
    self.connect()
  File "/usr/lib/python3.7/http/client.py", line 1407, in connect
    server_hostname=server_hostname)
  File "/usr/lib/python3.7/ssl.py", line 412, in wrap_socket
    session=session
  File "/usr/lib/python3.7/ssl.py", line 853, in _create
    self.do_handshake()
  File "/usr/lib/python3.7/ssl.py", line 1117, in do_handshake
    self._sslobj.do_handshake()
OSError: [Errno 0] Error

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/pi/CommanderPi/src/main.py", line 22, in <module>
    main()
  File "/home/pi/CommanderPi/src/main.py", line 18, in main
    start = g.Window()
  File "/home/pi/CommanderPi/src/gui.py", line 710, in __init__
    up.check_update()
  File "/home/pi/CommanderPi/src/update.py", line 50, in check_update
    with urllib.request.urlopen(url) as f:
  File "/usr/lib/python3.7/urllib/request.py", line 222, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 525, in open
    response = self._open(req, data)
  File "/usr/lib/python3.7/urllib/request.py", line 543, in _open
    '_open', req)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 1367, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "/usr/lib/python3.7/urllib/request.py", line 1326, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 0] Error>

I have patched the startup to accept a auto_check = false setting in the cpi.config file as a work-around. I believe this to be a useful setting on some systems/situations. However, looking at the code, and the TODO lists in the code, I would prefer to move all config stuff to a seperate config_cpi.py and use import config_cpi as cf (if thats acceptable). I will submit a PR so you can see why I think it should be split off into a seperate file. (Also there is a issue with version in the cpi.config)

[paulwratt]

I kinda thought that was the case.

I will retract that PR and put something together in the next few days.

Apart from the changes mentioned here, there are only aesthetic things (eg the network dialog, & change [ESC] text to button on all dialogs) - ie how things look (like the CPU output I fixed originally). Maybe get it to work on PC version of RaspberryPi OS (but I dont have a PC atm - could always use qemu I guess)

back soon …

[paulwratt]

I added auto_update for a remote system, or an automated system. It was to be run from main.py so it can update the files before it started the GUI. It was just an idea, and I personally probably would not use it (except maybe on a remote server that also had X-windows installed, which I now have) (EDIT: and I just noticed that update.py is already setup to run as a shell script).

auto_check was from the original patch/PR that allows a workaround for the networking issue.

one reason to have version in ../cpi.config is that you can force an update by changing it.

yes, updateCPiConfig() is used for color_mode changes, at the beginning of change_theme() (and after update_cpi(), because the version has changed). so the update is done from one function in a single file, that would be imported into each other file. As opposed to separate config write functions in multiple files, so they config cant get out of sync.

I was going to leave a '0.0.0' in a line with app_version in resources.py, so no matter how old any version currently installed, the update check would still work for old versions.

DEFAULT is a section header, the rest are key/value pairs (as described in dictionary and keyed array lists), ie its a parent object whose value is a list of other objects.

According to python docs, section does not have a value (INI style sections). I did think about changing DEFAULT to CommanderPi just incase the config is lying around without associated files, but either way its just human readable.

I used # cos thats what is used in config.txt and .py files (and shell scripts), ; is most common in microsoft INI format files (eg windows device drivers, and window setup file lists) - its a way of teaching people “this is how you remark/comment on linux” by example.

One good reason not to keep version= in resource.py is that configcpi.py is only 4kb, so the update check will be extremely quick (which also happens to be the smallest disk block size on linux, mac and windows - yes 512 bytes is emulated for almost 10 years now) - ie resources.py is just over 11k. There should not be any need for anything else in configcpi.py except more configuration settings (some for not RPI4 and not RPi maybe).

EDIT: another reason to keep everything in configcpi.py is that it could be added to c_desktop.py to write the config at installation time

the changes to update_cpi() would include removing ::-1 - the first time I ever installed CommanderPi I could not get it to update because of the way it does the string matching. As a by-product of not checking app_version, the line can be evaluated in Python using exec, so the code knows what the new version is when it is changed, which is why it can be written back to the config. Actually, unless version is ever going to be a tuple (number value as opposed to current string value) its name can be anything.

one final note (I hope you tested the creating and rewriting properly, I only found the write problem by accident) - the way I constructed that read+create & update config sections, it will work if the filesystem is read-only (cant create) and/or the config file is read-only (cant update)

EDIT: BTW if its specific to the configcpi.py code, we can deal with details over on that PR (GH does save all even after me removing fork repo)