Native linux packages

[adatum]

Are there plans to build rpm/deb packages of vorta, preferably for the default system repositories?

It's nice that a flatpak is available, though it requires a lot of large dependencies. Building from source is also an option, though it would be nice not to have to deal with dependencies manually.

In my case I'm using Fedora 30 and the pip3 install vorta method worked fine, but a native package would be more reassuring, especially with the system being able to keep it updated automatically.

[m3nu]

Actually I'm in the process of porting Vorta to Golang, which will be dynamically linked to your distro in Docker. Progress here: https://github.com/borgbase/vorta-go#deployment

I already tested it with macOS, Ubuntu and Archlinux. The files are very small and integrate well with your chosen distro. They are also easy to pack as rpm/deb.

I still need to implement some features in the Go version before this is ready for testing. I'll post new releases here every now and then.

The problem with the Python implementation was that the package we use, pyinstaller, doesn't know enough about Qt to package the right binaries. With Go cross-compiling and their Qt bindings, this is much cleaner.

[adatum]

That's great news. To clarify, is Docker necessary, or is it an option in addition to rpm/deb packages?

[m3nu]

Docker is just used to build the binary. You don't need to deal with it at all, if you just want to run the program.

Because Docker is lighter than a full virtual machine, it's a nice way to compile stuff for many different systems at once.

[daniel-k]

@m3nu Do you know https://github.com/mherrmann/fbs? I never used it myself, but their promise to have your application packaged in 15 minutes for Linux/Windows/Mac sounds tempting. Nevermind, found #126 just now ...

What's your plan with the python version, is it going to be deprecated soon? I'm thinking about investing some time to implement what's missing for me in the python version since it already ticks a lot of boxes for me and why reinventing the wheel? :)

[m3nu]

I'm actually working more on the Python version right now, because I found that some Go libraries aren't very mature yet. E.g. I couldn't get translations to work properly.

The package you suggested is just a Python wrapper around Pyinstaller. Simple enough to use it directly and being able to customize it.

[m3nu]

How is the Debian package coming along, @sten0? Anything else we can work on on our side? There is also this .desktop file that may be useful to reuse.

[sten0]

@m3nu, I'm making progress every day :-) Yes, I discovered that desktop file installed (by our pybuild helper) to /usr/lib/python3/dist-packages/vorta/assets/metadata/com.borgbase.Vorta.desktop. I'm not sure what the best solution would be, so I've started overriding the defaults by moving various things into valid system-wide paths; this is basically custom Makefile work to inject additional steps into the correct stages of the package creation sequence. After that's done I plan to submit patches for various minor integration issues (eg: the .desktop file needs some fixups). FYI, we have our own standard mechanism for autostarting applications: symlink or copy the desktop file to /etc/xdg/autostart

I don't want to bother you with minutia :-) If this work requires any changes to Vorta, would you like me to let you know?

[m3nu]

I don't want to bother you with minutia :-) If this work requires any changes to Vorta, would you like me to let you know?

Definitely! If there is anything we can improve to make it more standards-compliant or easier to package, please let us know. Removing qtdarkstyle and some hacks around it was a very good idea really.

[sten0]

Thank you :-) Here's an initial PR #488

[m3nu]

Debian status: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922961 (thanks to @sten0 )

[sudwhiwdh]

I don't quite understand yet, will this package in Debian be an official package,
whose integrity and up-to-dateness is directly ensured by the Vorta developers?

[sten0]

Hi sudwhiwdh, sudwhiwdh <[email protected]> writes:

I don't quite understand yet, will this package in Debian be an official package, whose integrity and up-to-dateness is directly ensured by the Vorta developers?

The Debian package is an official Debian package. I'm not sure what you mean by "integrity", but in addition to Manu, it means the software has been reviewed by myself, by whoever sponsors the Debian upload, and then one or two ftpmasters. The latest available version in Debian will typically lag a couple of days behind the latest tagged release, except during the "freeze" before a stable Debian release; during this time the Debian package is frozen and only release-critical bugfixes can be made. These bugfixes typically take for form of a patch series of backported commits. Another typical reason for a delay is the introduction of a new and difficult to package library when no one has any free time. The upstream Vorta project is not directly responsible for the Debian package, and should someone find any bugs in that package, those bugs should be reported to bugs.debian.org. If the those bugs are not Debian-specific (eg: caused by breakage introduced by a change in Debian's Python or Qt libraries) then they'll be forwarded here, because if they are Debian-specific there's no point in bothering Manu :-) Oh, and for derivatives such as Ubuntu, Pop!OS, Mint, Elementary, etc, bugs should be reported to their bugtrackers. From my perspective (maintainer of the Debian package) there is a good rapport between Vorta developers and myself, I feel like the Debian package has been "blessed" by them, and I'm committed to the correct functioning of that package--not just as its maintainer and not just because I want to see Vorta succeed, but because two of my family members and a couple of friends already use the package. I look forward to continuing collaboration! If having the latest tagged release at any given time is what you value most, then pip or flatpak are the distribution methods you'll most likely prefer. Regards, Nicholas P.S. From what I can tell, of all the Debian derivatives, Pop!OS is the most committed to flatpaks.

[samuel-w]

I created a PPA using @sten0's work, and updated it to 0.7.1.
The translations are excluded from the package for some reason, so its not ready for non-English use.

The deb file below has translations though.
https://github.com/samuel-w/vorta-1/raw/deb/vorta_0.7.1-5_all.deb

Repo here:
https://github.com/samuel-w/vorta-1/commits/ppa

[m3nu]

Good stuff. So to add this to the docs the steps would be:

sudo add-apt-repository ppa:samuel-w1/vorta
sudo apt-get update
sudo apt install vorta

?

[samuel-w]

It would be, but don't add it to the docs yet, need to fix the translations.

Edit: It's been added to the docs.

[samuel-w]

Since we now have deb files set up, we could use alien for deb -> rpm.
https://www.tecmint.com/convert-from-rpm-to-deb-and-deb-to-rpm-package-using-alien/
Example output: https://github.com/samuel-w/vorta-1/raw/ppa/vorta-0.7.1-12.noarch.rpm

[sten0]

Samuel, thank you for your work on this. Please note that alien is a "last resort" type of pseudo package and shouldn't be recommended in any official capacity, imho. The best multiplatform solution is probably OpenSUSE's OBS. It can also serve a repo of debs, but rpm is much easier. Sorry I can't help more at this time (no time) Meanwhile, we're still waiting for sponsorship for inclusion into the main Debian repo... I'm surprised it's taking this long

…

[sten0]

@samuel-w P.S. The translations weren't excluded; I just forgot to generate and install them. Sorry about that... I've fixed the issue and credited you in the commit. 'hoping to find time to finish preparing 0.7.1-1 sometime this week.

On that topic, please read deb-version(7). X.y-z is reserved for Debian packages, and this related to x.y-z~ubuntu or versions. Within a Debian+unofficial repository context I'd usually use x.y-0.1 (NMU style for a new upstream release) to insure smooth upgrades, but I'm not sure what suffix is conventional for Ubuntu PPAs. It's a small thing, but it defends against users complaining that a PPA breaks dependency resolution. If you package the next Vorta version before I do, please consider it (it's too late for 0.7.1).

And of course, you're welcome to do whatever you want ;-)

[sten0]

@samuel-w, P.P.S. if ever you're interested in contributing upstream to Debian, I'd be happy to help with your orientation :-)

[samuel-w]

The Ubuntu PPA packaging scheme seems to follow these rules: https://wiki.ubuntu.com/AutoStatic/PackagingVersioningScheme
I'll try to follow them in the future if I remember :).

[sten0]

Vorta for Debian (and its derivatives) is finally in NEW awaiting final review. https://ftp-master.debian.org/new.html

[m3nu]

Nice. Thanks for pushing this @sten0! 👏🎉

[sten0]

You're welcome :-) Sorry for the delay, notification for this message fell through the cracks. P.S. You can get an overview of native packaged versions across distributions here: https://repology.org/

OpenSUSE now has an official package in their main repository. Finally there's also a "not yet officially supported by Fedora Infrastructure" dnf (Fedora and Centos) repository here: https://copr.fedorainfracloud.org/coprs/luminoso/vorta/ I've read that Fedora is allegedly transitioning to Flatpak for user-facing GUI applications...but despite this, maybe it's worth reaching out to luminoso to see if he's interested in upstreaming his work to the Fedora project itself? With that, all the major distributions would be covered: Debian (and its derivatives such as Ubuntu), Fedora (and RHEL and compatible like CentOS and CentOS-replacements like Rock), OpenSUSE (and SLED), and of course Arch (and its derivatives). I don't have stats, but my feeling is that something like 90% of Linux users would have a native package available when the absence of Vorta in official Fedora repositories is resolved. That's of course not to say other distributions aren't important, only that most people use one of these distributions (or their derivatives), or Arch (and its derivatives).