On 16/06/2025 21:54, Nicholas D Steeves wrote:
Lee Garrett <deb...@rocketjump.eu> writes:
On 15/06/2025 20:57, Nicholas D Steeves wrote:
Lee Garrett <deb...@rocketjump.eu> writes:
Thank you for your work doing various cleanup. Are you aware that the
release team may look at the diff and say "these are too many changes,
so we're refusing the unblock"? In particular, how do you know that the
proposed autopkgtests won't cause borgbackup to fall out of trixie due
to new failing autopkgtests on arm64? Potentially requiring a second
upload to fix the first, and a second upload...do you think that meets
the criteria for the hard freeze?
borgbackup is a key package, so it won't get removed unless a release manager
does it manually. IMHO, if the autopkgtests fail on arm64, it would be good to
take a very close look why they fail, since this could very well mean that borg
is broken on arm64.
Yes, this is what things look like from a borgbackup maintainer
perspective, but the other side of things is that it will require
multiple teams to look at why the release of trixie has been delayed for
an potential autopkgtest issue in borg. I have additionally
specifically asked the release team about this case.
Autopkgtests should be enabled in experimental during the hard freeze,
and post trixie release merged to sid. At this time we can use DebCI
for experimental to inform us of potential issues in trixie. This might
justify further targeted fixes, or the release team might defer the
fixes to a stable-update after the release of trixie.
Sounds sensible to me. Note that I have added autopkgtests in the past
post-release, and the release team was fine with that. So that is a good option.
Since we'll have to backport security patches over the support cycle of trixie
(3y + some more for LTS), I believe having good test coverage is essential for
being able to confidently support it.
The principle is thus: we want to unblock the package people have been
using and the one whose behaviour has data on buildd, reprobuilds,
DebCI, etc. Changes that don't have supporting data from these sources
introduce risk, even if they're good changes! :)
I don't intend to change the way the package builds. Currently, only
simplesession-nofuse is even running on debci, since tests with
isolation-container restrictions are skipped. Having better autopkgtests ensures
that any regressions due to (build) dependency updates will be noticed. And
especially elbrus is happy when there are more autopkgtests. :)
:) Yes, thank you again for working on this, and this is true for
uploads to sid/unstable when we're not in hard-freeze, but it's too late
for trixie now. I'm sorry if this is demotivating, but I've double
checked with the release team, and at this point in the freeze cleanups
are not ok, and even the addition of good things is too late. Now we
only get to fix release-critical issues, make documentation changes that
won't be translated, and add or fix translations.
All good, not the least bit demotivating :). It's good to see that you're also
interested in maintaining borgbackup, thanks for that!
And yes, you can of course be added to Uploaders for trixie! :)
Ditto :)
I'm in the process of preparing a minimal fix to NEWS as well as
documenting the upstream changes so that the release team can assess the
potential risk of unblocking the release. I'll push to a debian/trixie
branch. I will wait to upload until everyone hears back from you,
because that's the collaborative approach.
I'm happy to push my changes for you to review before upload. I'd wait with the
debian/trixie branch until the release, to avoid debian/latest and debian/trixie
to become out of sync.
Sorry, it looks like I pushed to trixie rather than debian/trixie.
Please don't move that to debian/trixie yet, because debian/trixie
should be a protected branch. The reason I started a minimum changes
branch is because I believed debian/latest was already inadmissible to
trixie.
gitlab does not allow for moving/renaming branches, so just delete it and push
it again. However, for now, let's keep it in a separate namespace (e.g. sten/*)
to discuss the changes.
I didn't see your latest (today's) changes on debian/latest. Would you
please push them?
Also, all changes must be fully documented, and all changes to trixie
will need to be justified vis à vis the no-changes definition of a
hard-freeze.
I have pushed my changes to g...@salsa.debian.org:debian/borgbackup.git -b
lgarrett/debian/latest before I saw your mail. I'm fine with adding the
autopkgtests after the release via s-p-u.
After seeing your arguments I propose the following changes slated for 1.4.1-3:
from lgarrett/debian/latest:
keep:
1c797b44 Update metadata (Vcs-Git/gbp.conf) to point to trixie branches
bf30a142 Skip build tests when running with DEB_BUILD_OPTIONS=nocheck.
^^-- this fixes the override in debian/rules. Before the change, some tests
would always unconditionally run, which is incredibly annoying when building the
package. We could also pull it in post-trixie, but IMHO good to have now already.
ff408906 Add borgbackup-doc lintian overrides
4450318b Typo fix
32994538 Bump Standards-Version (no changes needed)
d1f6fd10 Add myself to uploaders
^^-- add you, too
62827af0 Switch packaging repo to DEP-14 layout.
c0988a56 d/watch: Limit uscan to the 1.x releases
delay after trixie:
6a6f2dd1 Update changelog
^^-- merge this with yours
0a805bde Add unit tests to autopkgtest
79011b23 Remove symlink in borgbackup-doc
from trixie branch:
42061bca (origin/trixie, trixie) Git shortlog of Debian-facing upstream changes
between upstream's…
^^-- I didn't interpret RM's message as we should list all commits from upstream
in the changelog. In the past, "New upstream release x.y.z" is enough, and we
already have that in 1.4.1-1. I understand it rather as "Don't do any changes to
the package (debian/*) unless you have documented the reason, because we're
manually reviewing the debdiff and we'll rather reject it than ask follow-up
questions."
75eb3450 Update debian/NEWS: Upstream introduced less alarming and easier to…
^^-- this looks good. I was confused at first because the CVE was fixed in
1.2.5, but I see that upstream simplified the upgrade procedure in the following
bugfix releases. Full ACK!
Kind regards,
Nicholas
Best regards,
Lee
