borgbackup

Edit Package borgbackup
No description set
Refresh
Refresh
Source Files
Filename Size Changed
borgbackup-1.1.1.tar.gz 0002988023 2.85 MB
borgbackup.changes 0000029262 28.6 KB
borgbackup.spec 0000004247 4.15 KB
Revision 7 (latest revision is 47)
Dominique Leuenberger's avatar Dominique Leuenberger (dimstar_suse) accepted request 535956 from Hans-Peter Jansen's avatar Hans-Peter Jansen (frispete) (revision 7)
- Update to borgbackup 1.1.1
- Compatibility notes:
  * When upgrading from borg 1.0.x to 1.1.x, please note:
    * read all the compatibility notes for 1.1.0*, starting from 1.1.0b1.
    * borg might ask some security-related questions once after upgrading.
      You can answer them either manually or via environment variable.
      One known case is if you use unencrypted repositories, then it will ask
      about a unknown unencrypted repository one time.
    * your first backup with 1.1.x might be significantly slower (it might
      completely read, chunk, hash a lot files) - this is due to the
      --files-cache mode change (and happens every time you change mode). You
      can avoid the one-time slowdown by using the pre-1.1.0rc4-compatible mode
      (but that is less safe for detecting changed files than the default).
      See the --files-cache docs for details.
  * The deprecated --no-files-cache is not a global/common option any more, but
    only available for borg create (it is not needed for anything else).
    Use --files-cache=disabled instead of --no-files-cache.
  * The nodump flag ("do not backup this file") is not honoured any more by
    default because this functionality (esp. if it happened by error or
    unexpected) was rather confusing and unexplainable at first to users.
    If you want that "do not backup NODUMP-flagged files" behaviour, use:
    borg create --exclude-nodump ...
- Fixes:
  * borg recreate: correctly compute part file sizes. fixes cosmetic, but
    annoying issue as borg check complains about size inconsistencies of part
    files in affected archives. you can solve that by running borg recreate
    on these archives.
  * bsdflags support: do not open BLK/CHR/LNK files, avoid crashes and slowness
  * recreate: don't crash on attic archives w/o time_end
  * don't crash on repository filesystems w/o hardlink support (forwarded request 535946 from alarrosa)
Comments 13

Alex Sinev's avatar

There is a problem with the last build of borgbackup because of renamed package python3-msgpack-python to python3-msgpack. It needs older python3-msgpack-python package to work properly. Look here:

https://github.com/borgbackup/borg/issues/3515#issuecomment-368881167


Alex Sinev's avatar

There is a problem with Fuse support in version 1.1.9, it does not work with python3-msgpack >= 0.5.6 (the current python3-msgpack version in Main Repository (OSS) is 0.6.1). Please, see here: https://github.com/borgbackup/borg/issues/4465


Hans-Peter Jansen's avatar

With version 1.1.10, the borg mount issue is solved from upstream (by bundling a "good" python3-msgpack).

Assimilation wasn't more serious fun, ever :-)

Sorry for taking so long, though...


Alex Sinev's avatar

Hi! There is Python 3.8 problem with borgbackup-1.1.10-2.2.x86_64 https://github.com/borgbackup/borg/issues/5028

And there is borgbackup 1.1.11 release https://github.com/borgbackup/borg/releases

Could you please upgrade it?


Alex Sinev's avatar

Hi! Is there any solution for unsupported llfuse?

borg mount not available: loading FUSE support failed [ImportError: No module named 'llfuse']

https://github.com/borgbackup/borg/issues/4122


Hans-Peter Jansen's avatar

Well, not until upstream releases a version, that supports pyfuse3.

At the time being, only some patches are floating around.


Markus Banfi's avatar

According to the SPEC file borg does not include python-msgpack anymore since version 1.2.0. But borg has very specific (as in limited) and hardcoded requirements for the version of python-msgpack. This could potentially cause borgbackup (and borgmatic) not to function every time there is an update of python310-msgpack in TW.

Currently the versions borgbackup-1.2.0-3.1 and python310-msgpack-1.0.4-1.1 in TW (20220622) do not match because borg 1.2.0 wants python-msgpack v1.0.3 (https://github.com/borgbackup/borg/blob/1.2.0/src/borg/helpers/msgpack.py#L182). The latest release of borg (1.2.1) allows python-msgpack v1.0.4. But again very specifically and hardcoded. Guess with the next update of python310-msgpack it potentially breaks again.

I'm not sure how this situation can be mitigated. In my opinion this is an upstream problem. If borg wants a version of python-msgpack that specific it should bundle it. For now a version bump of the borgbackup package to 1.2.1 will fix it.


Hans-Peter Jansen's avatar

There is a specific reason for not including the msgpack dependency in the package: it includes the msgpack since some time.

Do you have any specific reasons that point to problems with borg?


Markus Banfi's avatar

Sorry, I guess my message was not phrased too well.

I'll try to describe the issue again:

  • TW package borgbackup-1.2.0-3.1 has a dependency on python3-msgpack.
  • python3-msgpack is currently python310-msgpack-1.0.4-1.1.
  • borg has a hardcoded check in /usr/lib64/python3.10/site-packages/borg/helpers/msgpack.py:185 that raises an error if the version of msgpack is higher than 1.0.3.
  • The same file in borg version 1.2.1 would raise this check to allow msgpack up to 1.0.4.

In my opinion this very specific version check (instead of maybe allowing all 1.0.x versions of msgpack) has the potential to make borg fail with an error message every time there is an update of python3-msgpack in TW to a version that does not yet match the checked version of borg. Of course there is nothing that the TW package maintainers for the borgbackup package can do about it other than version bump the package often.

I will keep an eye on updates to borgbackup and python310-msgpack on my system from now on and always check the borg changelog online before updating.


Markus Banfi's avatar

My workaround for now was to download the python310-msgpack-1.0.3-1.3 RPM package and downgrade. Now I can make backups.


Benjamin Greiner's avatar

I will keep an eye on updates to borgbackup and python310-msgpack on my system from now on and always check the borg changelog online before updating.

With https://build.opensuse.org/request/show/985025 zypper will do that for you.


Hans-Peter Jansen's avatar

With Ben's change in place, zypper will enforce a resolution for any conflicts that arise and as a consequence will not allow the upgrade of msgpack to an unsupported version with respect to borg.

If you still have issues, let me know.


Markus Banfi's avatar

Great! Thanks for the fast resolution.

openSUSE Build Service is sponsored by