Dear Maintainer,

please ask the debian release team for an unblock, so that borgbackup
1.4.1 can enter trixie.

Thanks.

Hello Cacin,

cacin@allfreemail.net writes:

I agree that borgbackup 1.4.1 should be in trixie, and I've recently
joined the team who maintains borg.  Would you please ping/remind me to
file an unblock this next Wednesday 18th June?

Thank you for filing this bug,
Nicholas

Hi everyone,

I'm in the final stages of creating borgbackup 1.4.1-3 (some packaging fixes and
adding autopkgtests), I'll upload it today or tomorrow and then also file an
unblock request.

Greets,
Lee

Hi Lee,

Lee Garrett <debian@rocketjump.eu> writes:
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?

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'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.

Regards,
Nicholas

Hi Nicholas,

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.

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. :)

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.

All the best!
Lee

Lee Garrett <debian@rocketjump.eu> writes:

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.

:) 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.

And yes, you can of course be added to Uploaders for trixie! :)

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.

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.

Kind regards,
Nicholas

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.

All good, not the least bit demotivating :). It's good to see that you're also
interested in maintaining borgbackup, thanks for that!

Ditto :)

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 have pushed my changes to git@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!

Best regards,
Lee

Lee Garrett <debian@rocketjump.eu> writes:

I'm happy to contribute in a team context with team uploads :)

Thank you.  I reviewed your work before reading this email, for time
efficiency.

These aren't my arguments.  I double checked with the release team to
make sure that I wasn't being unusually harsh, and they said *no cleanup
changes*.

You had already made those changes by the time an unblock was requested;
thank you, that's fine, and is totally normal for the tip of a
debian/latest style development.  This is why we need to create a
trixie branch right now.  Also, totally fine, and it supports your
intent to move to DEP-14 style.

I've apologised in advance for writing potentially demotivating things
because most of what you're advocating isn't an unblock of 1.4.1-2 plus
essential fixups, but for your work on debian/latest to be part of the
trixie launch.  I'm sorry, but it's too late for that.

For the purposes of trixie, during the hard freeze, the basis of any
further work must be the version in unstable (the package from the
Debian Archive and end-user view).

Meanwhile, I want to position you as a maintainer of borgbackup for
trixie, so that you can make the case for your good work to be applied
at a time when the release team will have the time to be receptive to
it.

I had to modify this because you added an unnecessary complication.
Remember, the time to review must be as close to zero as possible.  No
future-facing cleanups at this time.  I'd be perfectly happy if you
erased me as committer, so go ahead and do so if you'd like.  To do so,
optionally do the following:

  fetch sten/debian/trixie
  $ git rebase --committer-date-is-author-date 710d730
  push it someplace new

Yeah, that's arguably a pedantic implementation detail, but I don't yet
know your preferences about this sort of thing.  If it looks good at that
time, feel free to create your changelog entries and finalise the
changelog.  I will of course be happy to sponsor the upload.

Release team hard nack for trixie launch, but I acknowledge it's nice to
have, and lamby especially appreciates it when people support both the
"nocheck" and "nodoc" (I forget if that's what it's called) build
profiles :)  Adding support for "nodoc" is something else you can do on
the debian/latest, since that's the development branch.

This is correctness/cleanup, so nack.

This is minimal and meets the criteria of user-facing documentation
(zero regression risk), and zero time to review.

This is cleanup, so nack.  It also takes time to review and isn't a
simple "bump".

I'm happy to do team uploads, for now, thanks :)

The important part of this is in your 1c797b44, which has been applied.
The time to introduce the more extensive changes in this and 1c797b44
will be post-trixie-launch.

How is this in a targeted fix that is relevant to a minimal change
unblock for a frozen release?  Uscan is for development.

Sebastinas was not ambiguous.  No cleanups, minimal [necessary] fixes
only, everything must be documented, and upstream's git shortlog is
desired if it saves time with its usefulness rather than wastes release
team review time with uselessness.

Excellent, I'm happy you understand its provenance and how this
adjustment should have been made sooner.  When thinking about this some
more, I realised that I could have done better than copy and paste from
the HTML docs, custom format them for clarity, and then minimise the
diff (ouf this busywork was not fun!)  So I've added a citation for
clarity and to make it clean that we're not plagiarising upstream's
docs.

Cheers,
Nicholas

Nicholas D Steeves <sten@debian.org> writes:

I have good news!  We've received a Release Team ack to add autopkgtests
for the trixie unblock *if* they've been first tested in experimental.

So we now need to preferentially target debian/latest.  I would have
generated your changelog entries and uploaded immediately; however,
there's an issue that I'm unwilling to sign-off on, and I feel like it
would be mean to just revert your work.  "Bump Standards-Version"
appears to have been gratuitous, and I'm not convinced that the package
is actually Policy 4.7.2-compliant at this time.  See §10.1  Yes, this
might alternatively be a deficiency of Policy, but I'd rather remove
this issue from consideration, at this time, in the interest of saving
time getting DebCI evidence for experimental ASAP so we can pursue the
unblock (with autopkgtests/DebCI enabled).  There's a proper order to
things though! :)

Cheers,
Nicholas

Good to hear.

Alright. Shall I release the sten/debian/latet branch as-is + autopkgtests?

Out of curiosity, what violation do you believe is there? Is it because
borgbackup-is-borgbackup2 also ships /usr/bin/borg{,fs}?

I don't care too much about the commit author info, it's fine either way. I see
that you have removed the change to "upstream-branch = upstream/trixie". I'd
argue that we'll have to do that at some point, because we might be pushing
upstream bugfix releases from 1.4.x. The way the commit is right now, it will
default to "upstream-branch = upstream", which does not exist. Thus any update
to e.g. 1.4.2 will fail.

ok

ok

ok

We can also introduce this later, but for trixie we want to track the 1.x, or
even the 1.4.x releases. uscan without will propose pulling in 2.0bX.

Fine by me.

+1

Hi Lee,

Sorry for the delay.  Life.

Lee Garrett <debian@rocketjump.eu> writes:
[snip]

Wh doyou think this is a matter for argument when the Release Team has
been immanently clear?  They maintain: no cleanups in unblock requests,
not even for generally good [future-facing] things.  What you're
proposing may be introduced if/when they need to be introduced if we
track upstream's security-supported 1.4.x branch directly rather than
cherry picking commits as quilt patches.

I'm advocating for a compromise to include whatever I can from the
changes you made two days before the hard freeze.  Once again, the only
things we are allowed to change are release critical bugs (and
essential documentation) in 1.4.1-3.

I'm happy to hear the rest looks good :)

Cheers,
Nicholas