Hi, I've chosen the package version that was first affected by an NMU, and since then there have been a total of 9 NMUs…at this point it looks like this package is being supported by the QA Team, and that Geoffroy Yourri Berret has become the defacto maintainer. This is a frankly bizarre state of affairs in Debian, so I've CCed everyone involved, and have also CCed the MIA team. In the past I've also reached out about the possibility of maintaining Vorta as part of the Borg Collective, and I seem to remember also reaching out about correcting the no-longer-necessary CVE-2023-36811 migration instructions (due to upstream changes), but have never received a reply. 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? Kind regards, Nicholas
You have been assimilated. Resistance is futile 🙂 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. Do you have the necessary Salsa access?
You have been assimilated. Resistance is futile 🙂 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. Do you have the necessary Salsa access?
Hi, I'm also going to chime in here and say I'd like to maintain borgmatic, as I also use it extensively for personal backups. Looking at the fact that the borg collective only maintains two packages, and one is not actively maintained, would it make sense to just put both packages in debian/collab-maint and dissolve the team? We can still keep the borg jokes for debconfs. Greets, Lee
Hello, The packages are already in the Debian group, so it’s just the Maintainer field and the corresponding Tracker team. Which are useful for notifications and grouping in general, so it makes sense to keep it. I will add you both to the Tracker team.
Hi Andrej and Lee! Thank you for the quick reply and sorry for the delay in mine. "Andrej Shadura" <andrew@shadura.me> writes: Hahaha, and how is this different from how Debian usually acquires labour? ;) Wonderful! Yeah, I know what you mean. 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. Cheers, Nicholas
Hi Andrej and Lee! Thank you for the quick reply and sorry for the delay in mine. "Andrej Shadura" <andrew@shadura.me> writes: Hahaha, and how is this different from how Debian usually acquires labour? ;) Wonderful! Yeah, I know what you mean. 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. Cheers, Nicholas
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.
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.
Perhaps the package could reside under the python team umbrella? Lots more eyes there (including mine). I'd be happy to be marked as an uploader there (and on borg, btw), as i use both packages on a daily basis now. A.
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. Agreed. 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
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...
Not particularly, in fact. I was part of the borg for a while, and I am
happy to have regained my individuality.
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.
Hi, Could we track this in a separate bug report? This one is specifically for discussing the maintainership of borgmatic. Thanks! Greets, Lee
Hi, CCing the Debian Python team for visibility. Are we/y'all interested in maintaining borg* packages within the team? Can we get a rough consensus on this? It seems like Antoine and I prefer it under the python team umbrella (we're both members), Andrej would like to keep it separate. I think the low threshold for fixing bugs and do-ocracy culture in the Debian python team would help keeping those packages in good shape. I'd be fine with keeping the borg collective if it weren't so small that its packages gets neglected for long periods of the release cycle. So I think the python team is the better option, until we start packaging borg tools in rust. ;) Greets, Lee
retitle 1106814 borgmatic: Please package a recent upstream version owner 1106814 ! thanks Lee Garrett <debian@rocketjump.eu> writes: Andrej replied to this bug within a day, which means that borgmatic ceases to be a salvaging candidate. He also made us both team members, which means this package is no longer unmaintained. Also, I don't think it's ok to "thanks for adding me to the borg team…this package is now DPT!" Regards, Nicholas
Hi Antoine and team/collective, Antoine Beaupré <anarcat@debian.org> writes: 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. 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
On 21/11/2025 23:46, Nicholas D Steeves wrote: Hi Nicholas, 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. 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, Simon
Hi Simon, Simon Pilkington <simonp.git@mailbox.org> writes: 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] 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. 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! :) 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
Hi Nicholas, 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. 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. 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. 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, Simon