practical testing of what will become borg 1.2

[ThomasWaldmann]

do practical testing with master branch code (or some alpha release).

report anything you find on the issue tracker (as a separate issue), check first if the issue already has been reported. you can post "works for me" in this ticket here.

see end of this ticket for current betas / rc (or directly check the github releases page).

do not run master branch code or borg pre-releases against production repos, always use fresh repos made by borg init!

[fantasya-pbem]

I have tested master branch (borg 1.2.0a3.dev3+g81f9a8cc) with empty repo on davfs2.

• borg init -e keyfile-blake2
• borg create --exclude-from $exclude --exclude-caches --compression lz4 (> 1 h 45 min)
• borg check (> 44 min)

Everything worked perfectly. 83 segments total.

                       Original size      Compressed size    Deduplicated size
All archives:               41.16 GB             32.78 GB             31.31 GB
                       Unique chunks         Total chunks
Chunk index:                  194392               251139

davfs cache_size: 5000 MiB / davfs table_size: 1024

works for me

[ThomasWaldmann]

alpha 3 is out. \o/

[fantasya-pbem]

Tested latest master branch (borg 1.2.0a3.dev8+gde151cd3) with my 31.31 GB repo from yesterday on davfs2.

• borg create --exclude-from $exclude --exclude-caches --compression lz4 (~ 4 min)
• borg check (> 37 min)

No errors occurred. 87 segments total.

                       Original size      Compressed size    Deduplicated size
All archives:               81.83 GB             65.08 GB             31.85 GB
                       Unique chunks         Total chunks
Chunk index:                  195405               501636

Interesting: davfs didn't respect cache_size of 5 GB, all segments were cached until cache was 30 GB. When borg exited (rc 0), cache was cleaned to < 5 GB, which is expected behaviour when open files are closed.

works for me

[ThomasWaldmann]

@fantasya-pbem the age threshold of the new lrucache is 4min, so it would be interesting to test >>4min. Also, the code is avoiding to use old file handles, but otoh does not actively search for them and close them.

[fantasya-pbem]

I did several more tests in the last two days, with a production repository I used for half a year until some days ago:

• dedup size: 117 GB, 2233 segments (original size 7.6 TB)
• initial backup consists of 181 segments, ~77 GB dedup size

First some tests with 5 GB limited DavFS cache (which is on its own LVM volume that had ~45 GB free space).

As expected, borg 1.2.0a3.dev8+gde151cd3 crashed when DavFS cache was full (45 GB).
After that I tested a patched borg 1.1.10.dev5+g7a7e04a4.d20190227 from the 1.1-maint branch with deactivated LRU fd cache. borg check was fine and DavFS cache was constantly at 5 GB until segment 131 when it crashed with KeyError / Input/Output error.

Therefore I increased DavFS cache to 25 GB limit.

borg 1.1.10.dev5+g7a7e04a4.d20190227 check then finished without errors.

Now I tested borg 1.2.0a3.dev8+gde151cd3 again. DavFS deleted the "metadata files" from its cache but no segment files when the 25 GB threshold was exceeded.
BUT – when cache reached 40 GB (that was when segment file 100 was downloaded) DavFS started to delete segments (seg 1 first, then 2, ...). This was 31 minutes after I started the check.
Cache stayed at 40–41 GB until segment 182 (first seg of 2nd backup in repo). DavFS now deleted a bunch of files fast and could manage to hold 25 GB until end of borg check.

This is a very interesting behaviour, but I cannot see a plausible explaination why DavFS cache growth stopped at 41 GB after 31 minutes. I can only draw the conclusion that one needs a reasonably large DavFS cache for borg checks, but I does not need to be as big as the borg repo.

[ThomasWaldmann]

@fantasya-pbem i opened #4427 for further work on the lrucache. if you like to help with testing, add a comment there.

[ThomasWaldmann]

Just released 1.2.0 alpha4 to pypi.

[fantasya-pbem]

Just for protocol: Tested borg-1.2.0a5 today. Works for me.

[ThomasWaldmann]

@fantasya-pbem did you also test some of the new features (see changelog)?

[fantasya-pbem]

I did a "borg compact --cleanup-commits" which did what it should. I ran a "borg check" afterwards which succeeded too. (Test repo has 5 archives. Will do more tests later with a production repo copy.)

I did search for information about the borg check "--max-duration". It seems that this option is not explained in detail anywhere. I'm wondering what would be good and bad max duration values. There should be a section in the docs where this option is discussed.

[ThomasWaldmann]

--max-duration should be listed with a brief description in the borg create reference docs.

Good values depend a bit on your repo size and also on speeds and overheads. But I guess usually one would take enough time to make a decent amount of progress related to the overall time needed to check the whole repo.

E.g. if whole repo would take 100h to check, you could:

• run a 48h check at the weekend, if backups are only made made Mo..Fr
• run a 4h check each night, if are created every day and enough time for them is left.
• ...

[fantasya-pbem]

I tested "borg compact", "borg prune" and "borg check" with my big repo on DavFS. Compact and prune worked well (prune's applied-rule output is nice!). Check did crash after 90 segments, but I think this was because of small DavFS cache (5 G) which may be too less for the network throughput of my server and Borg's FD timeout. With 10 G cache borg check did succeed. I had such problems before occasionally with 5 G. So again – 1.2.0a5 works for me.

Regarding --max-duration: It is mentioned in "borg check" with one sentence: "do only a partial repo check for max. SECONDS seconds (Default: unlimited)".
There is no further explaination why and when this option could be used. I assume that instead of one full long-running check Borg can run multiple partial checks that last --max-duration until the whole repo is checked. But this fact doesn't seem to be expressed with this clarity in the docs. It should be mentioned in borg check.

[ThomasWaldmann]

@fantasya-pbem thanks for testing, created #4473 for the docs issue.

[fantasya-pbem]

Executed borg compact --cleanup-commits, and borg check was fine without errors found. Creating a new backup also worked well. Only borg info is still very slow.

[ThomasWaldmann]

@m3nu borg compact behaves the same no matter from where you invoke it (on client or on server).

It will just physically remove everything that logically is already deleted. So delete and prune basically mark stuff as deleted, but the data is still physically present in old segment files (but these old segment files have "logical holes" where this deleted data is stored, because there is already a later DELETE committed for that chunk of data).

borg compact then cleans up and removes all these logical holes by writing only the stuff that is still in use to new segment files (but skipping the deleted stuff). there is a default threshold so that this data shuffling does not occur if there is too little to compact.

So, delete and prune do not immediately free space (that's why prune and delete is much faster). But a compact done afterwards will.

And compact will reject to run if the repo is in append-only mode.

[ThomasWaldmann]

@m3nu yeah, good idea, borg hosting providers could offer off-peak-hours compacting:

• let the user enable this (default disabled, because the user might want to have temporary-append-only behaviour)
• alternatively, let the user forbid it
• consider timezones, maybe run compact at weekend-everywhere (like between Sat 12:00 and Sun 12:00 UTC 24h clock)?
• clever scheduling reduces hdd head thrashing
• if user runs out of quota (or rather: better a bit before that happens), run compact if not forbidden.

[ThomasWaldmann]

About the create --stats speed: let's continue in #6259.

[ThomasWaldmann]

Hmm, thinking about it, guess it makes a difference whether the append-only is enforced by repo config or by borg serve commandline option (e.g. in .ssh/authorized_keys). The latter of course is only active IF compact is invoked via a client that uses that ssh key.

[m3nu]

whether the append-only is enforced by repo config or by borg serve

Should be fine, if ‘borg compact’ is rejected for both options. I see the main difference in how both options are enforced. Server-side, vs user-side. The latter is like making my own file RO to avoid deleting it. Stops accidents, but doesn’t add security.

Also thanks for the additional background. Will add compaction as opt-in feature.

[fantasya-pbem]

I noticed that 1.2 now prints out a warning like „file changed while we backed it up“, which seems to be the cause for return code 1 (warning). I never experienced that in 1.1. This might be generated because I add --progress or --stats but this changed behaviour might be considered a breaking change.

[ThomasWaldmann]

@fantasya-pbem well, a warning is not an error and warnings are kind of expected if you back up an active filesystem.

i don't remember whether we have the same code in 1.1 (or backported the change from master to 1.1-maint), but master/1.2 checks the file stat before and after reading an input file and notices if it has changed while we read it (which can mean that we backed up inconsistent crap). iirc tar also emits a similar warning for this case.

for files you do not really care about inconsistency might be acceptable, but borg does not known whether you do or not. you can also exclude unimportant changing files if your goal is a warning free run.

i don't think this warning is related to --progress or --stats.

[ThomasWaldmann]

OK, just wanted to tell that there is about 1 week left before 1.2.0 official release.

Also, all tickets in 1.2.0 milestone (except "testing it", this one) were closed or moved to future milestones.

So, please use the remaining time for more stress testing and feedback.

[fantasya-pbem]

In the last couple of days I had one backup per day, a borg prune, a borg compact and a check afterwards. Everything without issues.

[ThomasWaldmann]

had to do some late code changes in #6301 and #6306, hopefully no regressions.

[fantasya-pbem]

Maybe release one more RC, esp. for #6306? I cannot estimate the impact, is this fix relevant for special use cases? ("race condition")

[ThomasWaldmann]

One is doing a low-level change about how borg deletes files (e.g. segment files in the repo, but also other stuff). that truncate-unlink method used there previously had bad consequences if somebody tried to be clever and hardlink-copied a repo (see my discussion post / PSA).

The "usual" case of this is just successfully deleting the file (unlink). The more interesting case is if the delete (os.unlink) fails with ENOSPC (no space left). Then it tries the truncate first IF there is no other hardlink and then another unlink operation.

The SaveFile fix (race conditions) is only relevant under rather special circumstances, e.g. when running borg init in parallel on a fresh machine that has no borg cache dir yet. We had that code since longer and it took some years until someone found this failing in their setup. Most borg ops running in parallel deal with different pathes because they deal with different repos and the repo id is part of the path. The top level borg cachedir (and the CACHETAG in there) is likely the only exception.

Not sure it makes sense to create another RC for just a few days testing.

[ThomasWaldmann]

https://github.com/borgbackup/borg/tree/1.2.0 i just tagged 1.2.0 in the repo.

if somebody has a development setup for borg and wants to give the release some pre-release testing, that's the tag to fetch.

i still have to do the platform testing (using vagrant), so the tag might change to another changeset later if anything needing a fix comes up.

Twosday late evening is release time. :-)

[ThomasWaldmann]

platform testing with vagrant was successful!

https://paste.thinkmo.de/7ikN34mK#borg-1.2.0-packages here are the currently planned release files for 2022-02-22 22:02:22

Please give them a try before I officially upload them to github and pypi.

The upper ones are the pyinstaller-made fat binaries for misc. OSes and the lower 2 files are the pypi package (each plus gpg signature).

[bket]

Once again tested on OpenBSD:

• builds, and passes all regression tests
• tested against fresh, and a couple of 'production' repos. Tried several options all of which behave as expected

[ThomasWaldmann]

@LocutusOfBorg @FelixSchwarz ^^^

[FelixSchwarz]

@ThomasWaldmann I'll try to get Fedora's spec file updated and run a test build this evening. Might be just in time before beta cutoff for F36 (Feb 22).

[ThomasWaldmann]

Last minute! :)

[FelixSchwarz]

Tested on Fedora rawhide:

• builds ok, test suite passes
• creating a simple repo works (+ restore)

What I'd need for real Fedora build is a tarball (+ ideally a GPG signature). I generated a tarball manually from a git checkout due to setuptools_scm issues but that won't fly for a real distro package.

[szpak]

@FelixSchwarz It would be good to have it confirmed by @ThomasWaldmann , but the aforementioned link contains a (digitally signed) tarball - borgbackup-1.2.0.tar.gz (second from the bottom) which - as I understood - will be the official one (assuming no disasters reported :-) ).

[FelixSchwarz]

@szpak Thanks, I completely missed the link.

[ThomasWaldmann]

Yeah, that is the plan: release that stuff "as is" if no major issues are reported.

[LocutusOfBorg]

Hello, I'll have a test too

[LocutusOfBorg]

I did test on Debian sid and Ubuntu jammy (openssl 3.0.1). Build was fine after adding some new dependencies (dateutil, pkgconfig).
I got some "deprecated warnings" with new openssl, but nothing that prevented build/tests from working.

src/borg/platform/posix.c: In function '__pyx_pf_4borg_8platform_5posix_2swidth':
src/borg/platform/posix.c:1502:3: warning: 'PyUnicode_AsUnicode' is deprecated [-Wdeprecated-declarations]
 1502 |   __pyx_t_2 = __Pyx_PyUnicode_AsUnicode(__pyx_v_s); if (unlikely((!__pyx_t_2) && PyErr_Occurred())) __PYX_ERR(0, 19, __pyx_L1_error)
      |   ^~~~~~~~~
In file included from /usr/include/python3.9/unicodeobject.h:1026,
                 from /usr/include/python3.9/Python.h:93,
                 from src/borg/platform/posix.c:19:
/usr/include/python3.9/cpython/unicodeobject.h:580:45: note: declared here
  580 | Py_DEPRECATED(3.3) PyAPI_FUNC(Py_UNICODE *) PyUnicode_AsUnicode(
      |                                             ^~~~~~~~~~~~~~~~~~~
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 -ffile-prefix-map=/borgbackup=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.9/src/borg/platform/posix.o -o /borgbackup/.pybuild/cpython3_3.9/build/borg/platform/posix.cpython-39-x86_64-linux-gnu.so
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/borgbackup=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Isrc/borg/crypto -I/usr/include/python3.9 -c src/borg/crypto/low_level.c -o build/temp.linux-x86_64-3.9/src/borg/crypto/low_level.o
src/borg/crypto/low_level.c: In function '__pyx_pf_4borg_6crypto_9low_level_10_AEAD_BASE_10decrypt':
src/borg/crypto/low_level.c:10318:149: warning: passing argument 4 of 'EVP_CIPHER_CTX_ctrl' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
10318 |     __pyx_t_6 = ((!(EVP_CIPHER_CTX_ctrl(__pyx_v_self->ctx, EVP_CTRL_GCM_SET_TAG, __pyx_v_self->mac_len, (((unsigned char const *)__pyx_v_idata.buf) + __pyx_v_hlen)) != 0)) != 0);
      |                                                                                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
In file included from src/borg/crypto/low_level.c:644:
/usr/include/openssl/evp.h:684:71: note: expected 'void *' but argument is of type 'const unsigned char *'
  684 | int EVP_CIPHER_CTX_ctrl(EVP_CIPHER_CTX *ctx, int type, int arg, void *ptr);
      |                                                                 ~~~~~~^~~
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 -ffile-prefix-map=/borgbackup=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.9/src/borg/crypto/_crypto_helpers.o build/temp.linux-x86_64-3.9/src/borg/crypto/low_level.o -lcrypto -o build/lib.linux-x86_64-3.9/borg/crypto/low_level.cpython-39-x86_64-linux-gnu.so
building 'borg.compress' extension
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/borgbackup=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Isrc/borg -I/usr/include/python3.9 -c src/borg/compress.c -o build/temp.linux-x86_64-3.9/src/borg/compress.o
src/borg/compress.c: In function '__pyx_pf_4borg_8compress_4ZSTD_2_decide':
src/borg/compress.c:6113:31: warning: comparison of integer expressions of different signedness: 'size_t' {aka 'long unsigned int'} and 'int' [-Wsign-compare]
 6113 |   __pyx_t_2 = ((__pyx_v_osize < __pyx_v_isize) != 0);
      |                               ^
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 -ffile-prefix-map=/borgbackup=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.9/src/borg/compress.o -llz4 -lzstd -o build/lib.linux-x86_64-3.9/borg/compress.cpython-39-x86_64-linux-gnu.so
building 'borg.hashindex' extension
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/borgbackup=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Isrc/borg -I/usr/include/python3.9 -c src/borg/hashindex.c -o build/temp.linux-x86_64-3.9/src/borg/hashindex.o
In file included from src/borg/cache_sync/cache_sync.c:19,
                 from src/borg/hashindex.c:642:
src/borg/cache_sync/unpack.h: In function 'unpack_callback_array_end':
src/borg/cache_sync/unpack.h:276:70: warning: pointer targets in passing argument 2 of 'hashindex_get' differ in signedness [-Wpointer-sign]
  276 |         cache_entry = (uint32_t*) hashindex_get(u->chunks, u->current.key);
      |                                                            ~~~~~~~~~~^~~~
      |                                                                      |
      |                                                                      char *
In file included from src/borg/hashindex.c:641:
src/borg/_hashindex.c:552:54: note: expected 'const unsigned char *' but argument is of type 'char *'
  552 | hashindex_get(HashIndex *index, const unsigned char *key)
      |                                 ~~~~~~~~~~~~~~~~~~~~~^~~
In file included from src/borg/cache_sync/cache_sync.c:19,
                 from src/borg/hashindex.c:642:
src/borg/cache_sync/unpack.h:290:52: warning: pointer targets in passing argument 2 of 'hashindex_set' differ in signedness [-Wpointer-sign]
  290 |             if(!hashindex_set(u->chunks, u->current.key, cache_values)) {
      |                                          ~~~~~~~~~~^~~~
      |                                                    |
      |                                                    char *
In file included from src/borg/hashindex.c:641:
src/borg/_hashindex.c:562:54: note: expected 'const unsigned char *' but argument is of type 'char *'
  562 | hashindex_set(HashIndex *index, const unsigned char *key, const unsigned char *value)
      |                                 ~~~~~~~~~~~~~~~~~~~~~^~~
In file included from src/borg/cache_sync/cache_sync.c:19,
                 from src/borg/hashindex.c:642:
src/borg/cache_sync/unpack.h:290:58: warning: passing argument 3 of 'hashindex_set' from incompatible pointer type [-Wincompatible-pointer-types]
  290 |             if(!hashindex_set(u->chunks, u->current.key, cache_values)) {
      |                                                          ^~~~~~~~~~~~
      |                                                          |
      |                                                          uint32_t * {aka unsigned int *}
In file included from src/borg/hashindex.c:641:
src/borg/_hashindex.c:562:80: note: expected 'const unsigned char *' but argument is of type 'uint32_t *' {aka 'unsigned int *'}
  562 | hashindex_set(HashIndex *index, const unsigned char *key, const unsigned char *value)
      |                                                           ~~~~~~~~~~~~~~~~~~~~~^~~~~
src/borg/hashindex.c: In function '__pyx_pf_4borg_9hashindex_7NSIndex_2__setitem__':
src/borg/hashindex.c:4680:95: warning: passing argument 3 of 'hashindex_set' from incompatible pointer type [-Wincompatible-pointer-types]
 4680 |   __pyx_t_5 = ((!(hashindex_set(__pyx_v_self->__pyx_base.index, ((unsigned char *)__pyx_t_4), __pyx_v_data) != 0)) != 0);
      |                                                                                               ^~~~~~~~~~~~
      |                                                                                               |
      |                                                                                               uint32_t * {aka unsigned int *}
In file included from src/borg/hashindex.c:641:
src/borg/_hashindex.c:562:80: note: expected 'const unsigned char *' but argument is of type 'uint32_t *' {aka 'unsigned int *'}
  562 | hashindex_set(HashIndex *index, const unsigned char *key, const unsigned char *value)
      |                                                           ~~~~~~~~~~~~~~~~~~~~~^~~~~
src/borg/hashindex.c: In function '__pyx_pf_4borg_9hashindex_10ChunkIndex_2__setitem__':
src/borg/hashindex.c:6027:95: warning: passing argument 3 of 'hashindex_set' from incompatible pointer type [-Wincompatible-pointer-types]
 6027 |   __pyx_t_5 = ((!(hashindex_set(__pyx_v_self->__pyx_base.index, ((unsigned char *)__pyx_t_4), __pyx_v_data) != 0)) != 0);
      |                                                                                               ^~~~~~~~~~~~
      |                                                                                               |
      |                                                                                               uint32_t * {aka unsigned int *}
In file included from src/borg/hashindex.c:641:
src/borg/_hashindex.c:562:80: note: expected 'const unsigned char *' but argument is of type 'uint32_t *' {aka 'unsigned int *'}
  562 | hashindex_set(HashIndex *index, const unsigned char *key, const unsigned char *value)
      |                                                           ~~~~~~~~~~~~~~~~~~~~~^~~~~
src/borg/hashindex.c: In function '__pyx_f_4borg_9hashindex_10ChunkIndex__add':
src/borg/hashindex.c:7818:80: warning: passing argument 3 of 'hashindex_set' from incompatible pointer type [-Wincompatible-pointer-types]
 7818 |     __pyx_t_1 = ((!(hashindex_set(__pyx_v_self->__pyx_base.index, __pyx_v_key, __pyx_v_data) != 0)) != 0);
      |                                                                                ^~~~~~~~~~~~
      |                                                                                |
      |                                                                                uint32_t * {aka unsigned int *}
In file included from src/borg/hashindex.c:641:
src/borg/_hashindex.c:562:80: note: expected 'const unsigned char *' but argument is of type 'uint32_t *' {aka 'unsigned int *'}
  562 | hashindex_set(HashIndex *index, const unsigned char *key, const unsigned char *value)
      |                                                           ~~~~~~~~~~~~~~~~~~~~~^~~~~
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 -ffile-prefix-map=/borgbackup=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.9/src/borg/hashindex.o -o build/lib.linux-x86_64-3.9/borg/hashindex.cpython-39-x86_64-linux-gnu.so
src/borg/platform/posix.c: In function '__pyx_pf_4borg_8platform_5posix_2swidth':
src/borg/platform/posix.c:1502:3: warning: 'PyUnicode_AsUnicode' is deprecated [-Wdeprecated-declarations]
 1502 |   __pyx_t_2 = __Pyx_PyUnicode_AsUnicode(__pyx_v_s); if (unlikely((!__pyx_t_2) && PyErr_Occurred())) __PYX_ERR(0, 19, __pyx_L1_error)
      |   ^~~~~~~~~
In file included from /usr/include/python3.9/unicodeobject.h:1026,
                 from /usr/include/python3.9/Python.h:93,
                 from src/borg/platform/posix.c:19:
/usr/include/python3.9/cpython/unicodeobject.h:580:45: note: declared here
  580 | Py_DEPRECATED(3.3) PyAPI_FUNC(Py_UNICODE *) PyUnicode_AsUnicode(
      |                                             ^~~~~~~~~~~~~~~~~~~
creating build/lib.linux-x86_64-3.9/borg/platform

[ThomasWaldmann]

Thanks for testing! The openssl-related warnings might be interesting.

IIRC, dateutil is only needed for the tests.

When "pyx" shows up in warnings: that is code generated by Cython and besides using the latest Cython release, we can't do much about it.

_hashindex.c is hand-made C code, we can look at whether we can get rid of some warnings (e.g. by adding casts), but as far as I have seen yet, warnings are harmless.

[ThomasWaldmann]

1.2.0 is released - let's continue in the related discussion / new github tickets.