Notes from installation on a Planet Cosmo about pygenda HOT 18 OPEN

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 :))

from pygenda.

Yes, that's exactly as I see it.

from pygenda.

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

from pygenda.

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

from pygenda.

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

from pygenda.

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

from pygenda.

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

from pygenda.

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

from pygenda.

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.

from pygenda.

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

from pygenda.

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.

from pygenda.

@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!

from pygenda.

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

from pygenda.

@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.)

from pygenda.

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.

from pygenda.

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

from pygenda.

Also @neilzone are you comfortable using virtualenvironments or venv?

from pygenda.

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

No

from pygenda.