UnknownTimeZoneError ?

[xpseudonym]

$ vorta
2021-11-02 09:46:17,103 - vorta.i18n - DEBUG - Loading translation succeeded for ['en-GB', 'en-Latn-GB'].
2021-11-02 09:46:17,182 - root - CRITICAL - Uncaught exception, file a report at https://github.com/borgbase/vorta/issues/new
Traceback (most recent call last):
  File "/usr/bin/vorta", line 11, in <module>
    load_entry_point('vorta==0.7.8', 'gui_scripts', 'vorta')()
  File "/usr/lib/python3.6/site-packages/vorta/__main__.py", line 58, in main
    app = VortaApp(sys.argv, single_app=args.profile is None)
  File "/usr/lib/python3.6/site-packages/vorta/application.py", line 61, in __init__
    self.scheduler = VortaScheduler(self)
  File "/usr/lib/python3.6/site-packages/vorta/scheduler.py", line 22, in __init__
    super().__init__()
  File "/usr/lib/python3.6/site-packages/apscheduler/schedulers/base.py", line 61, in __init__
    self.configure(gconfig, **options)
  File "/usr/lib/python3.6/site-packages/apscheduler/schedulers/base.py", line 95, in configure
    self._configure(config)
  File "/usr/lib/python3.6/site-packages/apscheduler/schedulers/base.py", line 576, in _configure
    self.timezone = astimezone(config.pop('timezone', None)) or get_localzone()
  File "/usr/lib/python3.6/site-packages/tzlocal/unix.py", line 131, in get_localzone
    _cache_tz = _get_localzone()
  File "/usr/lib/python3.6/site-packages/tzlocal/unix.py", line 70, in _get_localzone
    return pytz.timezone(etctz.replace(' ', '_'))
  File "/usr/lib/python3.6/site-packages/pytz/__init__.py", line 172, in timezone
    raise UnknownTimeZoneError(zone)
pytz.exceptions.UnknownTimeZoneError: ''
$

(Hmm, I seem to be scribbling all over this blank page... :o))
Looking at that last line, I'm wondering if there's something amiss with what python3-tzlocal-1.5.1-2.fc28.noarch does?

Also, I thought it might be the relatively old f28 packages - and I guess it might be - but, nothing latter will upgrade (the following is with f30 & f32 enabled):

$ sudo dnf upgrade python3-tzlocal python3-APScheduler
Warning: failed loading '/etc/yum.repos.d/79CentOS-Linux-Media.repo', skipping.
Last metadata expiration check: 0:22:24 ago on Tue 02 Nov 2021 09:35:30 GMT.
Dependencies resolved.

 Problem 1: package fedora-obsolete-packages-32-57.noarch obsoletes python3-APScheduler < 3.5.3-4 provided by python3-APScheduler-3.5.3-3.fc30.noarch
  - cannot install the best update candidate for package python3-APScheduler-3.0.5-7.fc28.noarch
  - cannot install the best update candidate for package python2-pip-9.0.3-18.module_el8.4.0+642+1dc4fb01.noarch
 Problem 2: problem with installed package python3-certbot-1.20.0-1.el8.noarch
  - package python3-certbot-1.20.0-1.el8.noarch requires python3.6dist(pytz), but none of the providers can be installed
  - cannot install both python3-pytz-2018.5-2.fc30.noarch and python3-pytz-2017.2-9.el8.noarch
  - package python3-tzlocal-1.5.1-6.fc30.noarch requires python3.7dist(pytz), but none of the providers can be installed
  - cannot install the best update candidate for package python3-tzlocal-1.5.1-2.fc28.noarch
====================================================================================================================================
 Package                            Architecture              Version                             Repository                   Size
====================================================================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 python3-pytz                       noarch                    2018.5-2.fc30                       fedora30                     48 k
Skipping packages with broken dependencies:
 python3-tzlocal                    noarch                    1.5.1-6.fc30                        fedora30                     30 k

Transaction Summary
====================================================================================================================================
Skip  2 Packages

Nothing to do.
Complete!
$
$ sudo dnf upgrade --best --allowerasing python3-tzlocal python3-APScheduler
[sudo] password for admin: 
Warning: failed loading '/etc/yum.repos.d/79CentOS-Linux-Media.repo', skipping.
Last metadata expiration check: 1:42:35 ago on Tue 02 Nov 2021 09:35:30 GMT.
Error: 
 Problem: The operation would result in removing the following protected packages: dnf
(try to add '--skip-broken' to skip uninstallable packages)
$

It might be that python3-pytz & python3-tzlocal will need to be built against EL for vorta to work beyond Fedora - I don't know if the Magela or SUSE builds fair any better. Of course, I might be barking up the wrong tree - I'll see if I can find any info on what pytz.exceptions.UnknownTimeZoneError: might mean.

[xpseudonym]

tzlocal project seems to suggest that there's a problem with old versions of python3-tzlocal:

It requires Python 3.6 or later, and will use the backports.tzinfo package, for Python 3.6 to 3.8.

I've not been able to get to the bottom of the backports.tzinfo package - I can't find it anywhere and wonder if it's called something else?

[xpseudonym]

I noticed that the tzlocal PythonRepo also said:

This Python module returns a tzinfo object with the local timezone information under Unix and Windows. It requires either Python 3.9+ or the backports.tzinfo package, and returns zoneinfo.ZoneInfo objects.

(Which is of course a necessary implication of the above.)
But, also noticed:

$ sudo dnf list python3*
Last metadata expiration check: 3:40:40 ago on Tue 02 Nov 2021 09:35:30 GMT.
Installed Packages
python3-PyDrive.noarch                                   1.3.1-11.el8                                         @epel                 
python3-acme.noarch                                      1.20.0-1.el8                                         @epel                 
...
python3-zope-interface.x86_64                            4.6.0-1.el8                                          @epel                 
python36.x86_64                                          3.6.8-2.module_el8.4.0+790+083e3d81                  @AppStream            
python36-devel.x86_64                                    3.6.8-2.module_el8.4.0+790+083e3d81                  @AppStream            
Available Packages
python3-AWSIoTPythonSDK.noarch                           1.4.9-1.el8                                          epel                  
...
python38-wheel-wheel.noarch                              0.33.6-5.module_el8.4.0+647+0ba99ce8                 AppStream             
python39.x86_64                                          3.9.2-1.module_el8.4.0+720+bfbc1bcb                  AppStream             
python39-PyMySQL.noarch                                  0.10.1-2.module_el8.4.0+680+7b309a77                 AppStream             
...
python39-wheel.noarch                                    1:0.35.1-3.module_el8.4.0+694+cc446542               AppStream             
python39-wheel-wheel.noarch                              1:0.35.1-3.module_el8.4.0+694+cc446542               AppStream             
$

So, Python 3.9 was available to EL - I couldn't swap 3.6 for 3.9 for installed packages. So, installed it in parallel and set it as the default python3:

$ sudo alternatives --config python3
[sudo] password for admin: 

There is 2 program that provides 'python3'.

  Selection    Command
-----------------------------------------------
*+ 1           /usr/bin/python3.6
   2           /usr/bin/python3.9

Enter to keep the current selection[+], or type selection number: 2
$ python --version
Python 3.9.2
$

But, after reinstalling vorta with Python 3.9 as the default, it still installed under 3.6:

$ ls /usr/lib/python3.9/site-packages/
__pycache__
$ ls /usr/lib/python3.6/site-packages/ | grep vorta*
vorta
vorta-0.7.8-py3.6.egg-info
$

And, still failed.
Any help at setting Python 3.9 as the default for the vorta install might show whether running under 3.9 solves the problem as suggested on the tzlocal PythonRepo.
Thanks.

[luminoso]

I managed to run in CentOS 8 stream (fresh install) like this:

sudo dnf module install python39
pip3.9 install --user vorta

And then due to gnome wayland:
QT_QPA_PLATFORM=wayland vorta

[xpseudonym]

Thanks @luminoso - yes, I think I did the same, or similar, but didn't set env - actually, I notice you did module install for python39 - I don't think I included module - what does that do?

Edit: actually I did run module install... But, I did just pip3 install rather than pip3.9 install... Anyway, I guess setting the env doesn't make much sense when running over ssh
Edit Edit: OMG, can't remember what I'd done one day to the next - I actually did originally pip3.9 install forgot and did pip3 install - now I've uninstalled both and reinstalled pip3.9 install - and what I've actually been trying to workout is why the nightly scheduled back-up isn't working... Do scheduled BUs only run when vorta is open?

I found this in passing which I thought might be relevant - borgbase/vorta#1086 & borgbase/vorta#908 So, it looks like there a bit of stuff going on.

[luminoso]

Hum.. It looks like that from now on it is unrelated to packaging.

Since I've closed the EPEL6/7/8 repos, I don't think this is relevant anymore.
I still have to find out a way to programmatically make it wayland compatible

Unless something new comes up, I'm closing this ticket.