Arch Linux User Repository

I included some service files. I tested them and are working fine. However, the main branch (not the PKGBUILD) is outdated, and will not work; as stated here https://github.com/SamSchott/maestral-dropbox/issues/80 Until this bug is resolved, the main branch won't work. Good news is we are nearing a stable release!

If you want to install through pacman/aur helper right now; you can build this project and have it run without the Pyro5 cyclic import error by checking out the dev branch (in the PKGBUILD sources array, add '#branch=develop' at the end of the url.) I use aurutils, which lets you edit the PKGBUILD before building. This branch builds fine, but it will not work due to missing dependencies. The one that is needed to work is python-bugsnag, which is not packaged in arch. This, I won't package (since it is prob only needed for this specific branch and not master branches) so a solution right now is to install it from pypi (pip install --user bugsnag) which will make it so that the dev build runs.

There are two service files that I provided. One is for a single instance, the other one is for multiple instances running concurrently. If you have a single instance, enable and start the background daemon with 'systemctl --user enable --now maestral.service' . If you have multiple config files; run 'systemctl --user enable --now maestral-config@<NAME>.service' for each one you want running in the background. This way you have a daemon running in the background. You can interface with the daemon by running 'maestral status' or 'maestral gui' (optionally include --config-name <NAME>) I suggest putting an autostart file in .config/autostart/maestral-gui.desktop . I will provide an autostart file once I figure out how to auto-generate it.

I am not removing the python-systemd dependence; because it is needed during build to make maestral play nice with systemd. (Also it is a pain to get optdeps working in my clean chroot build script) The new dependencies you mentioned are in the develop branch only; and are there because the developer is logging a bunch of information. The changes probably won't make it in the main branch; if they do I will add the missing packages.

Also, @coxackie it is all adhoc info learnt along the way, and just doing file searches in github. It is fun to look into projects you are using; especially if you are planning on making your own software projects down the future.

many thanks @bbaserdem. you certainly seem to be way more knowledgeable on this - what I find peculiar is when I installed maestral using pip last week (per the instructions in the github page), it does not (at least to my recollection) install python-systemd. I can check again later and let you know for sure.

Edit: while I was writing this, 40 minutes ago, the requirements.txt was changed in the dev branch. python-systemd is not there anymore - but there is a bunch of other additions. I still think a systemd unit would make sense, though.

The dependency is pulled in using the requirements.txt; and my understanding is that is a list of pypi packages that are needed for the code to function. Hence, by design, it does not seem to be an optional dependency. (I agree that it should be, but the developer does not think so; and I will keep it that way for now.) As a comparison, pyqt5 is an optional runtime dependency, and is not on the requirements.txt for this reason. Also, as I understand, maestral checks if it is running under systemd, and arranges logging behavior accordingly. python-systemd is needed to check, even on computers without systemd (the dev works on a mac from what I understand so he certainly does not have systemd). This should not pose a problem; as the systemd package is not a dependency (only a make dependency for python-systemd) so should not be pulled in. You would need to provide a masking alternative for artix anyway, so python-systemd should work regardless on a system without systemd.

I was going to argue that maestral does not operate on a server-client model and thus does not need a systemd unit; but it does apparently. I will work on testing a unit to go along with it, but it will need to wait for a few days.

@bbaserdem many thanks for also packaging python-pyro5. Let's hope someone will take it up in Arch main soon. maestral runs quite well lately - and the dev mentioned he will be releasing 0.5.1 soon.

one thing, regarding dependencies: as it stands, python-systemd is actually not needed, unless a systemd service file is also included. Maybe it would be a good idea to create one - as I understand, there is good support for it in maestral.

@ bbaserdem The reality is that I also just use the native client now. I just want to follow the development, but it is easy to just pip install packages whenever needed. As you say, it may be better to wait until a stable release.

I published a python-pyro5-git package. And now, an additional AUR dependency is added (python-sdnotify). I will mention that although I will continue to support, I am not actively using this program; i switched to the native client due to rapidly changing dependencies. I will switch back however, as soon as the project has a stable release. So if there are any issues, I'll still try to look at them as fast as I can, but might need help fixing. Such as this; it seems the updated PKGBUILD builds, but I'm getting the following error;

Traceback (most recent call last):
  File "/usr/bin/maestral", line 11, in <module>
    load_entry_point('maestral==0.5.0', 'console_scripts', 'maestral')()
  File "/usr/lib/python3.8/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python3.8/site-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3.8/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3.8/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/maestral/cli.py", line 245, in gui
    from maestral.gui.main import run
  File "/usr/lib/python3.8/site-packages/maestral/gui/main.py", line 30, in <module>
    from maestral.sync.daemon import (
  File "/usr/lib/python3.8/site-packages/maestral/sync/daemon.py", line 17, in <module>
    from Pyro5 import server, client
  File "/usr/lib/python3.8/site-packages/Pyro5/server.py", line 18, in <module>
    from . import config, core, errors, serializers, socketutil, protocol, client
  File "/usr/lib/python3.8/site-packages/Pyro5/core.py", line 14, in <module>
    from . import config, errors, socketutil, serializers, nameserver
  File "/usr/lib/python3.8/site-packages/Pyro5/nameserver.py", line 269, in <module>
    @server.expose
AttributeError: partially initialized module 'Pyro5.server' has no attribute 'expose' (most likely due to a circular import)

I followed basic python package practices in the pyro5 pkgbuild, please comment there if it is a problem in the PKGBUILD. I would still like to fix this issue if it's my packaging, or submit a bug report on github if not.

@coxackie, I can't flag python-pyro in the community repo as outdated; getting CSRF verification failed. Request aborted.. Could you flag it so?

I don't feel like creating the python-pyro5 package for this project only; if you want you can create a pkgbuild for the up to date version and I can add it as a dependency.

I don't want to do a version check to the depends array, because apparently they officially released it under the name pyro5. I don't know if the arch devs will put it in a new package named python-pyro5, or will replace the current python-pyro with the version 5. I assume it is going to be the former since the versions are not compatible.

Maestral now depends on pyro v5, and in the arch repo python-pyro is v4. As a consequence, the package does not work.

@coxackie thank you for pointing out. I have been unable to build for some time, but also did not have access to my laptop with my aur ssh keys to submit the fix. I found out that multiple lines for the ssh key on aur account work so I was able to submit a fix. Builds fine in a clean chroot now.

@ bbaserdem: Note that the png file in master has changed to smallcap - please update the PKGBUILD to have install -Dm644 "${_name}/gui/resources/Maestral.png" "${pkgdir}/usr/share/pixmaps/${_name}.png"; otherwise, the build fails.