Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1270171 > unrolled thread

Bug#1106814: 9 NMUs + multiple upstream versions = Unmaintained pkg & salvaging candidate

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1106814: 9 NMUs + multiple upstream versions = Unmaintained pkg & salvaging candidate Antoine Beaupré <anarcat@debian.org> - 2025-11-14 20:10 +0100
    Bug#1106814: 9 NMUs + multiple upstream versions = Unmaintained pkg & salvaging candidate Nicholas D Steeves <sten@debian.org> - 2025-11-19 01:20 +0100
      Bug#1106814: 9 NMUs + multiple upstream versions = Unmaintained pkg & salvaging candidate Antoine Beaupré <anarcat@debian.org> - 2025-11-19 20:40 +0100
        Bug#1121156: , RFC: provide better UX for recurring breaking changes Nicholas D Steeves <sten@debian.org> - 2025-11-21 23:50 +0100
          Bug#1121156: , RFC: provide better UX for recurring breaking changes Simon Pilkington <simonp.git@mailbox.org> - 2025-11-28 08:20 +0100
            Bug#1121156: , RFC: provide better UX for recurring breaking changes Nicholas D Steeves <sten@debian.org> - 2025-11-29 03:30 +0100
              Bug#1121156: , RFC: provide better UX for recurring breaking changes Simon Pilkington <simonp.git@mailbox.org> - 2025-11-29 07:30 +0100

#1270171 — Bug#1106814: 9 NMUs + multiple upstream versions = Unmaintained pkg & salvaging candidate

On 2025-06-05 16:36:41, Nicholas D Steeves wrote:
> Hi Andrej and Lee!
>
> Thank you for the quick reply and sorry for the delay in mine.
>
> "Andrej Shadura" <andrew@shadura.me> writes:
>
>> On Fri, 30 May 2025, at 00:12, Nicholas D Steeves wrote:
>>> Where do we go from here?  If there's some kind of unofficial "The
>>> Borg Collective is open to all DDs, like the debian/collab-maint
>>> group" that should be documented, but I don't think the silence is ok.
>>> If it's an approved inside joke, can we at least put an easter egg
>>> somewhere?
>>>
>>> Would it be alright if Geoffroy and I officially joined the team?
>>
>> You have been assimilated. Resistance is futile 🙂
>
> Hahaha, and how is this different from how Debian usually acquires
> labour? ;)
>
>> More seriously though, yes, you're part of the team^W collective if you do the work and care about the packages. That said, I personally never used borgmatic, I mostly sponsored it or did some maintenance because someone had to.
>
> Wonderful!  Yeah, I know what you mean.
>
>> Do you have the necessary Salsa access?
>
> I just checked, and surprisingly yes!  It appears that anyone who can
> write to the Debian (old collab-maint) group can also write to bormatic
> and borgbackup, and....oh!  It's because The Borg Collective is under
> this namespace.  I wonder if all the other DDs know that they've already
> been assimilated?
>
> Lee, I noticed you've recently become an Uploader.  Would you please
> open acknowledge all the NMUs in debian/changelog?  There is more info
> about this at various places (Policy, Developers Reference, etc.).  You
> can also close this bug in that changelog entry.

Hey folks, so this has been flying about for a couple of months now,
what's the current status?

Is someone willing to own this bug and merge everything?

I might take some time to do so in a week or two if no one else steps
up...

Would be a shame to leave borgmatic like this in Debian! :)

And thank you for people for all the NMUs, we're lagging, but not that
far behind upstream, thanks to that awesome work...

a.
-- 
Man is, at one and the same time, a solitary being and a social being,
                       - Albert Einstein

[toc] | [next] | [standalone]

#1270734

[Multipart message — attachments visible in raw view] — view raw

Antoine Beaupré <anarcat@debian.org> writes:

> Hey folks, so this has been flying about for a couple of months now,
> what's the current status?
>
> Is someone willing to own this bug and merge everything?
>
> I might take some time to do so in a week or two if no one else steps
> up...

I'd appreciate if you would review my WIP (which I finally pushed).  In
particular, I'd appreciate your perspective on that potential UX
enhancement and am wondering if there's a better way to do it and to
support upstream's efforts to make config migration less painful.  The
obvious downside to upstream's current implementation is that it erases
comments in the config.

> Would be a shame to leave borgmatic like this in Debian! :)

Agreed.

> And thank you for people for all the NMUs, we're lagging, but not that
> far behind upstream, thanks to that awesome work...

Would you like to be assimilated into the borg collective? ;)  As Andrej
said, if you show up and do the work then you're part of the collective,
and the project is under the salsa/collab-maint group so you already
have access.  I've been testing 2.0.9, but feel free to our package
forward to 2.0.11 if you prefer.

Cheers,
Nicholas

[toc] | [prev] | [next] | [standalone]

#1270850

On 2025-11-18 19:14:35, Nicholas D. Steeves wrote:
> Antoine Beaupré <anarcat@debian.org> writes:
>
>> Hey folks, so this has been flying about for a couple of months now,
>> what's the current status?
>>
>> Is someone willing to own this bug and merge everything?
>>
>> I might take some time to do so in a week or two if no one else steps
>> up...
>
> I'd appreciate if you would review my WIP (which I finally pushed).  In
> particular, I'd appreciate your perspective on that potential UX
> enhancement and am wondering if there's a better way to do it and to
> support upstream's efforts to make config migration less painful.  The
> obvious downside to upstream's current implementation is that it erases
> comments in the config.

Hmm... I'm not sure. First, I think this should be gated on a `[ -d
/etc/borgmatic ]` otherwise it could crash the postinst on an
unconfigured system:

    for i in /etc/borgmatic/*.yaml; do

Did you actually this in a clean install?

I'm not sure we should be doing this for our users though... It seems a
little daring! But why not...

>> And thank you for people for all the NMUs, we're lagging, but not that
>> far behind upstream, thanks to that awesome work...
>
> Would you like to be assimilated into the borg collective? ;)

Not particularly, in fact. I was part of the borg for a while, and I am
happy to have regained my individuality.

> As Andrej said, if you show up and do the work then you're part of the
> collective, and the project is under the salsa/collab-maint group so
> you already have access.  I've been testing 2.0.9, but feel free to
> our package forward to 2.0.11 if you prefer.

Well, it's pretty much how the python team works too...

I see you have things well in hands, I'll leave you to it and bash at
this again if I see it needs a hand! :)

a.

-- 
Our scientific power has outrun our spiritual power. We have guided
missiles and misguided men.
                        - Martin Luther King, Jr.

[toc] | [prev] | [next] | [standalone]

#1271101 — Bug#1121156: , RFC: provide better UX for recurring breaking changes

[Multipart message — attachments visible in raw view] — view raw

Hi Antoine and team/collective,

Antoine Beaupré <anarcat@debian.org> writes:

> On 2025-11-18 19:14:35, Nicholas D. Steeves wrote:
>> Antoine Beaupré <anarcat@debian.org> writes:
>>
>> I'd appreciate if you would review my WIP (which I finally pushed).  In
>> particular, I'd appreciate your perspective on that potential UX
>> enhancement and am wondering if there's a better way to do it and to
>> support upstream's efforts to make config migration less painful.  The
>> obvious downside to upstream's current implementation is that it erases
>> comments in the config.
>
> Hmm... I'm not sure. First, I think this should be gated on a `[ -d
> /etc/borgmatic ]` otherwise it could crash the postinst on an
> unconfigured system:
>
>     for i in /etc/borgmatic/*.yaml; do
>
> Did you actually this in a clean install?

I had not gotten there yet, because this was a POC focused on existing
users.  Yes, you're of course right and I've fixed the WIP.

> I'm not sure we should be doing this for our users though... It seems a
> little daring! But why not...

The problem as I see it is upstream keeps breaking existing user configs
(see https://bugs.debian.org/1099802), and backups that aren't painless
and automatic have a tendency to not be updated...

That said, does rewriting, updating, and implicitly checking/validating
a config on upgrade violate the principle of least surprise more than
this:

a)
  1. Provide a rewritten & valid $n.dpkg-dist for each config file on
  each upgrade.
  2. In Debian.NEWS, when there are breaking changes, point the user to
  this file.
  -- hopefully errors with obsolete and invalid config when users ignore
  D.NEWS...and users are provided with a template generated by their
  site-specific config

vs

b) (My WIP POC)
  1. Back up each config file to $n.dpkg-old and rewrite /e/borgmatic/$n
  2. In Debian.NEWS, when there are breaking changes, remind the user.
  that dpkg-old exists in case the auto-migrated config missed
  something.
  -- hopefully doesn't miss source data due to dropped obsolete and
  invalid config when users ignore D.NEWS.

c)
  1. Back up each config file to $n.dpkg-old and rewrite
  /e/borgmatic/$n, and stop bothering use with Debian.NEWS (this assumes
  that upstream migration tool isn't buggy)
  2. Stop bothering the user and interrupting upgrades
  -- hopefully doesn't miss source data due to dropped obsolete and
  invalid config; assumes users tend to ignore D.NEWS.

d)
  1. Continue shipping D.NEWS, when needed, and do nothing more
  -- NEWS interrupts upgrade, but users will ignore NEWS,  users have
  broken config (hopefully errors...)

What do you think is the least bad option?  I initially chose "b"
because I was optimistic and chose to have faith in upstream and their
migration tool.

Regards,
Nicholas

[toc] | [prev] | [next] | [standalone]

#1271925 — Bug#1121156: , RFC: provide better UX for recurring breaking changes

On 21/11/2025 23:46, Nicholas D Steeves wrote:

Hi Nicholas,

> The problem as I see it is upstream keeps breaking existing user configs
> (see https://bugs.debian.org/1099802), and backups that aren't painless
> and automatic have a tendency to not be updated...

As a system administrator I'd prefer it if maintainer scripts didn't create
potentially junk files on every upgrade, especially since there is no way to
opt-out of their execution. I've successfully self-managed my configs since I
started using borgmatic (years ago), and don't recall a case when an
intervention was needed because backups stopped working.

> 
> That said, does rewriting, updating, and implicitly checking/validating
> a config on upgrade violate the principle of least surprise more than
> this:
> 
> a)
>   1. Provide a rewritten & valid $n.dpkg-dist for each config file on
>   each upgrade.
>   2. In Debian.NEWS, when there are breaking changes, point the user to
>   this file.
>   -- hopefully errors with obsolete and invalid config when users ignore
>   D.NEWS...and users are provided with a template generated by their
>   site-specific config
> 
> vs
> 
> b) (My WIP POC)
>   1. Back up each config file to $n.dpkg-old and rewrite /e/borgmatic/$n
>   2. In Debian.NEWS, when there are breaking changes, remind the user.
>   that dpkg-old exists in case the auto-migrated config missed
>   something.
>   -- hopefully doesn't miss source data due to dropped obsolete and
>   invalid config when users ignore D.NEWS.
> 
> c)
>   1. Back up each config file to $n.dpkg-old and rewrite
>   /e/borgmatic/$n, and stop bothering use with Debian.NEWS (this assumes
>   that upstream migration tool isn't buggy)
>   2. Stop bothering the user and interrupting upgrades
>   -- hopefully doesn't miss source data due to dropped obsolete and
>   invalid config; assumes users tend to ignore D.NEWS.
> 
> d)
>   1. Continue shipping D.NEWS, when needed, and do nothing more
>   -- NEWS interrupts upgrade, but users will ignore NEWS,  users have
>   broken config (hopefully errors...)> 
> What do you think is the least bad option?  I initially chose "b"
> because I was optimistic and chose to have faith in upstream and their
> migration tool.

If a user ignores NEWS, then an automatically upgraded config file (as in a)
won't help because the user won't know about it. b) and c) are both problematic
(c more so) because bugs can and do happen. Moreover, automatic config upgrade
has already proved clunky as per #1121514.

Therefore I prefer d). Not ignoring NEWS is the user's responsibility, as is
making sure critical services (such as backup) are still working after a
software update.

> 
> Regards,
> Nicholas

Regards,
Simon

[toc] | [prev] | [next] | [standalone]

#1272039 — Bug#1121156: , RFC: provide better UX for recurring breaking changes

[Multipart message — attachments visible in raw view] — view raw

Hi Simon,

Simon Pilkington <simonp.git@mailbox.org> writes:

> On 21/11/2025 23:46, Nicholas D Steeves wrote:
>
> Hi Nicholas,
>
>> The problem as I see it is upstream keeps breaking existing user configs
>> (see https://bugs.debian.org/1099802), and backups that aren't painless
>> and automatic have a tendency to not be updated...
>
> As a system administrator I'd prefer it if maintainer scripts didn't create
> potentially junk files on every upgrade, especially since there is no way to
> opt-out of their execution. I've successfully self-managed my configs since I
> started using borgmatic (years ago), and don't recall a case when an
> intervention was needed because backups stopped working.

It sounds like you were and are using the core, stable features that
didn't change, and I understand the desire for an escape hatch for
someone who doesn't want any config-handling niceties.  How do you
manage all the other .dpkg-dist and .dpkg-old files, by the way?

[snip definitions of options]

> If a user ignores NEWS, then an automatically upgraded config file (as in a)
> won't help because the user won't know about it. b) and c) are both problematic
> (c more so) because bugs can and do happen.

As someone who tracks sid or testing, you are part of the noble class of
users who defend those of Debian stable+1 from this class of "bugs can
and do happen".  If nobody tests config file migration then Debian
stable users have no real-world coverage for this feature.

> Moreover, automatic config upgrade
> has already proved clunky as per #1121514.

How else do you realistically interpret "preliminary support" (see
changelog)?  Release early, release often, there will be bugs, get
feedback, compromise, and make it better.  Would you please review the
update[s] to #1121514 before your next reply to this UX one?  Andrey
mentioned a feature that I realised could be used to provide a fifth
option, and I'll think you'll like it! :)

> Therefore I prefer d). Not ignoring NEWS is the user's responsibility, as is
> making sure critical services (such as backup) are still working after a
> software update.

Noted.  Since Debian is the Universal Operating System, it seems like we
would have to continue to do this in order to accommodate users who use
the new fifth option (at #1121514).  That said, following NEWS is too
hard for the users I support, and I don't believe that it's necessary to
gatekeep functioning backups to users who are capable of navigating
breaking changes when there is upstream support for migrating a
deprecated or obsolete (and broken) configuration to a working one.  The
worst case scenario here is

  1. User dist-upgrades oldstable to stable, doesn't understand NEWS.
  2. Does a bunch of important irreplaceable work.
  3. Catastrophic hardware failure occurs.
  4. Backups are out-of-date.

I believe we can do better.

Regards,
Nicholas

[toc] | [prev] | [next] | [standalone]

#1272048 — Bug#1121156: , RFC: provide better UX for recurring breaking changes

Hi Nicholas,

On 29/11/2025 03:21, Nicholas D Steeves wrote:
> Hi Simon,
> 
> Simon Pilkington <simonp.git@mailbox.org> writes:
> 
>> As a system administrator I'd prefer it if maintainer scripts didn't create
>> potentially junk files on every upgrade, especially since there is no way to
>> opt-out of their execution. I've successfully self-managed my configs since I
>> started using borgmatic (years ago), and don't recall a case when an
>> intervention was needed because backups stopped working.
> 
> It sounds like you were and are using the core, stable features that
> didn't change, and I understand the desire for an escape hatch for
> someone who doesn't want any config-handling niceties.  How do you
> manage all the other .dpkg-dist and .dpkg-old files, by the way?
> 

In almost all other cases when dpkg finds a modified config, it notifies the
user and asks if the new config should be installed or the existing one kept
(thus creating the aforementioned files). When this happens I'll inspect what's
changed in the packaged config, alter mine as needed and then dispose of the
.dpkg-* files.

Here the idea seems to have been to produce them on every upgrade which seemed
like a lot of junk files to me. I don't find the idea of .dpkg-* files
objectionable per se.

> [snip definitions of options]
> 
>> If a user ignores NEWS, then an automatically upgraded config file (as in a)
>> won't help because the user won't know about it. b) and c) are both problematic
>> (c more so) because bugs can and do happen.
> 
> As someone who tracks sid or testing, you are part of the noble class of
> users who defend those of Debian stable+1 from this class of "bugs can
> and do happen".  If nobody tests config file migration then Debian
> stable users have no real-world coverage for this feature.

Don't worry, I do use the config migration function (I believe often enough that
any bug I find wouldn't escape testing). I'd just rather not have it run
automatically on every package upgrade.

> 
>> Moreover, automatic config upgrade
>> has already proved clunky as per #1121514.
> 
> How else do you realistically interpret "preliminary support" (see
> changelog)?  Release early, release often, there will be bugs, get
> feedback, compromise, and make it better.  Would you please review the
> update[s] to #1121514 before your next reply to this UX one?  Andrey
> mentioned a feature that I realised could be used to provide a fifth
> option, and I'll think you'll like it! :)

Yes, fair point about preliminary support. I'm of the opinion that by trying to
handle too many situations automatically we end up creating problems instead of
solving them so I ended up latching onto an example too early.

I checked your message on #1121514 (not quoting here) and you're right, I like
it. Thumbs up. If you leave borgmatic.d alone, that takes care of my objections.
Another option I'd be fine with is to migrate borgmatic.d but leave any subdirs
in it alone.

> 
>> Therefore I prefer d). Not ignoring NEWS is the user's responsibility, as is
>> making sure critical services (such as backup) are still working after a
>> software update.
> 
> Noted.  Since Debian is the Universal Operating System, it seems like we
> would have to continue to do this in order to accommodate users who use
> the new fifth option (at #1121514).  That said, following NEWS is too
> hard for the users I support, and I don't believe that it's necessary to
> gatekeep functioning backups to users who are capable of navigating
> breaking changes when there is upstream support for migrating a
> deprecated or obsolete (and broken) configuration to a working one.  The
> worst case scenario here is
> 
>   1. User dist-upgrades oldstable to stable, doesn't understand NEWS.
>   2. Does a bunch of important irreplaceable work.
>   3. Catastrophic hardware failure occurs.
>   4. Backups are out-of-date.
> 
> I believe we can do better.

No objections to this but it just makes me wonder if a config-driven command
line backup tool is the best option for non-technical users when more
user-friendly alternatives possibly exist. (e.g. vorta is in Debian.)

Either way, carry on. I appreciate your maintaining borgmatic. I was getting
tired of packaging new versions for myself. :)

> 
> Regards,
> Nicholas

Regards,
Simon

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web