Hi again, Just pushed the new tag/release. I was waiting for the macOS release to build, but I'll just add that later.
https://github.com/borgbase/vorta/releases/tag/v0.7.5 Nice to see the tests working. 👍 APScheduler has an upper bound, but I'll remove that dependency soon. Else no upper bounds. > On Mar 3, 2021, at 12:13, Nicholas D Steeves <nstee...@gmail.com> wrote: > > Control: tags -1 + upstream pending > > Hi Manuel, > > Manuel Riel <m...@snapdragon.cc> writes: > >> That's good news. We won't add new features until March 10 then. >> >> I'll also do a release 0.7.5 to get more users to test this. Commits from >> Mar 1 >> are all bug fixes. >> > > Thanks, much appreciated. In hindsight I ought to have asked sooner, > not fun as that would have been. P.S. I'm not sure if it's a Travis or > Github lag, but I don't see the new 0.7.5 tag. > >>> Unfortunately, even if we do everything right, the release-team still >>> has the right to say "these are too many changes"...which is >>> demotivating... For my part, I'm sorry to have not been able to help >>> out more. >>> >>> One thing that concerns me about 0.7.4 (plus 824707c) is that amd64 >>> builds have regressed and now sometimes timeout: >>> >>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/vorta.html >>> > > Gah, as ever, I can't reproduce this locally with the-yet-untagged > 0.7.5. 'hopefully that means it's resolved... > >>> Armhf builds are thankfully failing more visibly than before, with many >>> "QThread::start: Thread termination error (No such process)". I'm >>> looking forward to testing if the thread and lock-related changes in >>> 6d8ad90 will solve this: >>> >>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/vorta.html >> >> Yes, 6d8ad90 could solve this. It also makes keyring selection more >> reliable. We later >> found that many users have multiple keyring installed, so it's prioritized >> by the kind >> of desktop env now. >> > > Preliminary tests on an armhf porterbox confirms success for 5/5 > attempts. :-D Finally! > >>> Given that you had previously mentioned what sounded like database >>> infelicities, I also upgraded Peewee to 3.14.1, which contains these >>> fixes: > <snip> >> >> No problem to require a newer peewee, if this makes a change. >> > > At this time, this is a FYI thing I'm sharing for the purposes of > reproducibility, but it might become significant if there are corner > cases that effect Vorta using << 3.14.1. eg: > flatpak/dependencies/python3-peewee.json requests `3.11.2`. If you'd > like, at a later date I can compare Vorta's flatpack dependencies to > what we're use in Debian, check for Debian-specific patches, and then > make recommendations for an updated dependency stack. If you're > interested, don't forget to remind me, I will surely forget! > > Let me take this opportunity to say thank you for not declaring an upper > version boundary for your Python dependencies--this is really nice to see, > and a refreshing change from many projects. There's a decent article on > the topic here: > > https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ > > Spread the word! > Cheers, > Nicholas
