Notes from installation on a Planet Cosmo

[neilzone]

cat /etc/debian_version returned 10.13.

I ran sudo apt install python3 python3-pip libgtk+3 using the default sources.lists. There are some missing dependencies (below).

I ran pip3 install --user pip==20.3.4 and it completed, but it was not clear to me why I'd pick 20.3.4 rather than 24.

Running pip3 install --user pygenda failed:

ERROR: Failed building wheel for pycairo

with the relevant bit being:

'pkg-config' not found.

So I ran sudo apt install libcairo2-dev pkg-config, re-ran pip3 install --user pygenda, and it worked.

(I also updated pip to v24 at this point.)

Running python3 -m pygenda, I get an error, which I have not attempted to debug:

(__main__.py:6347): Gtk-WARNING **: 18:38:23.382: Locale not supported by C library.
	Using the fallback 'C' locale.
Unable to init server: Could not connect: Connection refused
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/cosmo/.local/lib/python3.7/site-packages/pygenda/__main__.py", line 24, in <module>
    from .pygenda_gui import GUI
  File "/home/cosmo/.local/lib/python3.7/site-packages/pygenda/pygenda_gui.py", line 42, in <module>
    from .pygenda_calendar import Calendar
  File "/home/cosmo/.local/lib/python3.7/site-packages/pygenda/pygenda_calendar.py", line 44, in <module>
    from .pygenda_util import dt_lt, dt_lte, datetime_to_date, date_to_datetime, get_local_tz, dt_add_delta, utc_now_stamp
  File "/home/cosmo/.local/lib/python3.7/site-packages/pygenda/pygenda_util.py", line 53, in <module>
    _local_tz = get_localzone()
  File "/home/cosmo/.local/lib/python3.7/site-packages/tzlocal/unix.py", line 219, in get_localzone
    _cache_tz = _get_localzone()
  File "/home/cosmo/.local/lib/python3.7/site-packages/tzlocal/unix.py", line 196, in _get_localzone
    tz = zoneinfo.ZoneInfo(tzname)
  File "/home/cosmo/.local/lib/python3.7/site-packages/backports/zoneinfo/_tzpath.py", line 95, in find_tzfile
    _validate_tzfile_path(key)
  File "/home/cosmo/.local/lib/python3.7/site-packages/backports/zoneinfo/_tzpath.py", line 120, in _validate_tzfile_path
    f"ZoneInfo keys must be normalized relative paths, got: {path}"
ValueError: ZoneInfo keys must be normalized relative paths, got:

[Lewiscowles1986]

@neilzone the traceback looks truncated; but is it that it truly ends there, and there is no value / empty value?

[neilzone]

Yes, that's exactly as I see it.

[semiprime]

I guess {path} is empty, which might be the issue.

[Lewiscowles1986]

Hmm

paperless-ngx/paperless-ngx#1547
paperless-ngx/paperless-ngx#1551

Feels like it solves the exact same error; assuming it's a default fallback; or just a better error message

https://github.com/paperless-ngx/paperless-ngx/pull/1551/files#diff-fb7b32160ce6cb72df78b8d3a45c652b5e403634126bf4196ec406a39f99866aR132-R145

[Lewiscowles1986]

There is also https://github.com/paperless-ngx/paperless-ngx/blob/d9002005b1787445b71c61ef36e11f06d096e3ce/install-paperless-ngx.sh#L74C1-L84C3

and

https://github.com/paperless-ngx/paperless-ngx/blob/d9002005b1787445b71c61ef36e11f06d096e3ce/src/paperless/settings.py#L699

Lots of good ideas and prior work in the paperless-ngx repo

[Lewiscowles1986]

Could regebro/tzlocal#161 be the root-cause of the issue? It's definitely near the bottom of the traceback

[semiprime]

My current status: Not yet able to reproduce this.

Investigations: I'm on tzlocal v1.5.1 on my Gemini (unable to upgrade due to being on Python v.3.5). I tried v2.1, v3.0, v4.2, v4.3.1, v5.1 and v5.2 on my laptop (Slackware, Python v3.9). All these worked fine.

I also tried deleting /etc/localtime on both the Gemini and laptop to make it "not know" what timezone it was in. This didn't cause issues with Pygenda.

The closest I've got to the reported result is to replace /etc/localtime with an empty file. This gives errors in tzlocal: raise ValueError("Invalid TZif file: magic not found") -- similar, but not what was reported.

[semiprime]

@neilzone Could you let me know which version of tzlocal you're using? Since I might later want to know the versions of other date-related Python package dependencies, this command should get them all to save time:

pip3 list | grep -e tzlocal -e icalendar -e python-dateutil

In addition, what is your /etc/localtime file? I'd guess a softlink to something? Could you let me know, and check the file it's pointing to is timezone data (check with something like file /usr/share/zoneinfo/GB).

Thanks!

[neilzone]

Output of pip3 list | grep -e tzlocal -e icalendar -e python-dateutil:

icalendar          5.0.12
python-dateutil    2.9.0.post0
tzlocal            5.1

In terms of /etc/timezone:

cosmo@cosmocom:~$ ls -l /etc/timezone 
-rw-r--r-- 1 root root 8 Jun 10 08:45 /etc/timezone

and

cosmo@cosmocom:~$ cat /etc/timezone 
Etc/UTC

[semiprime]

@neilzone I was after /etc/localtime, rather than /etc/timezone. /etc/localtime should be a sym-link pointing to a timezone data file, probably in /usr/share/zoneinfo.

(I just tried with tzlocal 5.1 and /etc/localtime pointing to /usr/share/zoneinfo/Etc/UTC and Pygenda started without issue.)

[neilzone]

I was after /etc/localtime, rather than /etc/timezone.

Oops.

cosmo@cosmocom:~$ ls -l /etc/localtime 
lrwxrwxrwx 1 root root 27 Jun 11 11:49 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC

and

cosmo@cosmocom:~$ cat /usr/share/zoneinfo/Etc/UTC
TZif2UTCTZif2�UTC
UTC0

[semiprime]

As far as I can tell, the time configuration of the Cosmo seems valid (although it's set to UTC, which might not be what was desired). However, this combination of OS, Python version and libraries leads to an exception.

You could argue that this should be fixed in the underlying components, but since I've not been able to reproduce it (it might require Python 3.7, which I've not tried), Python 3.7 was EOL'ed almost a year ago, and it's on a non-official Debian on a niche device, I wouldn't blame the maintainers for NGTF it.

And even if it was fixed, the versions that give the exception would still exist. So I've decided to add code to Pygenda to handle exceptions from get_localzone(), and try another method of getting the timezone, at least on Linux.

This code is in the handle-get-localzone-exception branch on github. I've also pushed it to PyPI as a development release 0.3.4.dev0.

I've tested it on my devices, but @neilzone, I'd be grateful if you could test the fix by installing the dev version with:

pip3 install --user pygenda==0.3.4.dev0

[neilzone]

Here you go:

cosmo@cosmocom:~$ python3 -m pygenda

(__main__.py:5992): dbind-WARNING **: 07:32:56.841: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files

(__main__.py:5992): Gtk-WARNING **: 07:32:56.964: Theme parsing error: gtk.css:127:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(__main__.py:5992): Gtk-WARNING **: 07:32:56.964: Theme parsing error: gtk.css:128:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(__main__.py:5992): Gtk-WARNING **: 07:32:56.964: Theme parsing error: gtk.css:132:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/cosmo/.local/lib/python3.7/site-packages/pygenda/__main__.py", line 27, in <module>
    GUI.init()
  File "/home/cosmo/.local/lib/python3.7/site-packages/pygenda/pygenda_gui.py", line 145, in init
    cls._init_locale()
  File "/home/cosmo/.local/lib/python3.7/site-packages/pygenda/pygenda_gui.py", line 430, in _init_locale
    locale.setlocale(locale.LC_ALL, lang)
  File "/usr/lib/python3.7/locale.py", line 604, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

I'll try wiping and reinstalling the device when I get a moment, just in case something else, unrelated, is broken.

[semiprime]

Quick note: This is progress. It's got further, so it seems to have set a valid timezone. Now it's failing to set the language to use in the GUI. Unfortunately, it's not reporting what language it's trying to use - it might just be a case of installing the language files (Pygenda looks for the UTF8 version, so maybe the Cosmo has some other encoding installed.)

No need to wipe/reinstall.

I'm hoping to be able to get my hands on a Cosmo soon. In which case I'll be able to do my own digging.

[Lewiscowles1986]

If UTF8 were the fallback if a device doesn't have locale set; would that not be safe and available on all semi-modern Linux distro's such as the cosmo environment?

Also @neilzone have you tried using pyenv on the cosmo? https://github.com/pyenv/pyenv

[Lewiscowles1986]

Also @neilzone are you comfortable using virtualenvironments or venv?

[neilzone]

Also @neilzone have you tried using pyenv on the cosmo? https://github.com/pyenv/pyenv

No

[neilzone]

Also @neilzone are you comfortable using virtualenvironments or venv?

I tend to use pipx to make this easier, but I haven't tried it on the Cosmo.

( I'm not really using the Cosmo; it came out of retirement for me to see if I could get LUKS working (so far, I have failed), and now I basically only turn it on to test stuff here :))

[semiprime]

Progress report...

I've identified 3 issues here:

1. In the config tested in the report, get_localzone() threw an exception that Pygenda didn't handle.
2. If there was an error when trying to set the locale (which Pygenda does to support different languages) then Pygenda exited.
3. Gemian for Cosmo and Gemian for Gemini are very different. Hence the guide for Gemini was not suitable for the Cosmo.

I now have fixes for all these merged:

1. Was discussed above. I merged a fix, that was tested and seemed to work. See commit c0d757e
2. I've merged a change to fall back to the system default locale if loading a specific one failed (e.g. not installed, or installed but with a non-UTF-8 character set). See commit 8d19d8a
3. I bought a second-hand Cosmo so I could write a new install guide. Merged in commit 750a5cd

These should be in the next release, hopefully closing this issue. However, to test we'll need to wait until it's on PyPI, since that's the version the install guide gets. I'm leaving the issue open for now, awaiting testing.

[semiprime]

I released Pygenda v0.3.4 last weekend, containing all the relevant changes.

I have just re-installed Gemian on my Cosmo and gone through the Cosmo quickstart guide. It all seems to work for me, so I'm marking this issue as fixed. (I'm not sure who will be able to re-open this issue. If you think it needs re-opening, but can't do it yourself, please leave a comment.)

Thanks to all for their contributions and help.