Package Details: borgmatic 1.3.13-1

Git Clone URL: (read-only)
Package Base: borgmatic
Description: Simple, configuration-driven backup software for servers and workstations
Upstream URL:
Licenses: GPL3
Submitter: nylocx
Maintainer: devopsdeluxe (witten, nicoulaj)
Last Packager: nicoulaj
Votes: 25
Popularity: 0.423870
First Submitted: 2016-02-18 13:48
Last Updated: 2019-07-29 15:43

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

evana commented on 2018-12-29 22:20

I figured out the issue.

See here:

The path must be prepended, otherwise the version of borgmatic that is already installed on the machine is called instead of the new package version. Change the line to

export PATH="${_pytestdir}/usr/bin:${PATH}"

devopsdeluxe commented on 2018-12-29 22:17

Mind pasting the PKGBUILD you're using, as well as details on how you're building the package (are you using a helper)?

subprocess.CalledProcessError: Command '('borgmatic', '--version')' returned non-zero exit status 2.

Looks like the new borgmatic isn't ending up in your $PATH during the build, causing the tests to fail.

evana commented on 2018-12-29 22:03


This is what I have on my machine.

tests/end-to-end/ F

tests/integration/commands/ ........................F

Full output:

devopsdeluxe commented on 2018-12-29 19:35


Which tests are failing?

Locutus commented on 2018-12-29 12:31

Is there a solution for the failing tests? I still can't seem to be able to get past that stage in the latest release.

devopsdeluxe commented on 2018-12-27 01:26

We'd be giving up most of the purported reproducibility benefits by falling through to system dependencies.

That's exactly what we want! ;)

The CI environment may differ from a user's local environment, and we want to fail if our local dependencies cause the test suite to fail.

What happened to borgmatic.timer?

I nixed it on accident. I'll push a fix for it momentarily.

bjo commented on 2018-12-27 00:46

What happened to borgmatic.timer?

witten commented on 2018-12-27 00:07

Got it.. Thanks for the explanation. I know that tox has a sitepackages configuration option, described here: .. There's also a corresponding tox --sitepackages command-line flag.

Using one of those may allow the created tox environment to "fall through" to any system packages. That could be one way to still use tox while testing against system dependencies.

I did a quick test of this behavior, and with --sitepackages in use, the tox install log includes lines like:

Requirement already satisfied: appdirs==1.4.3 in /usr/lib/python3.7/site-packages (from -r test_requirements.txt (line 1)) (1.4.3)

.. which is what you'd want to see if you want system dependencies to be used.

The only real benefit of this approach, though, would be to leverage the existing tox machinery around test environment creation and invoking py.test. We'd be giving up most of the purported reproducibility benefits by falling through to system dependencies.

devopsdeluxe commented on 2018-12-26 22:37

Is there no way to run tests with tox for this?

As far as I am aware, no.

The reason being is that one would want to run the test suite with their system's dependencies rather than those from a virtualenv to ensure that the install will work on their system.

witten commented on 2018-12-26 21:52

FYI tox is used to run tests because it creates a moderately reproducible test environment regardless of where it's run, which is a nice property to have in either development or CI.

I'm not super familiar with AUR packaging.. Is there no way to run tests with tox for this? That would take care of both creating a test environment and setting the PATH appropriately.