# Patrick Lauer <patrick@gentoo.org> (09 Apr 2014) # Dead upstream, has known dataloss bugs. # Please use something more sane: rsnapshot, backuppc, obnam, ... app-backup/rdiff-backup app-backup/pybackpack sys-fs/rdiff-backup-fs Doesn't look like the mask is going to disappear, so we should (lastrite and) remove them.
I'm not sold on this one, but we've switched away for other reasons, so I don't care that much anymore. The two open Gentoo bugs have fixes: bug #409947 was a client/server version mismatch, and bug #463362 is automagic dependencies (I updated the ebuild). There are still people using rdiff-backup, and it works fine. Patrick just had a bad experience, and upstream is pretty much dead, but not gone. Having switched to obnam, I promise you run into just as many "haha your backups are gone, rm -rf the repo and start over" situations.
Personally I don't care much but I'd like to know whether the Python support in those packages is worth forward-porting.
Eh, just kill them if they're going to require work. I can always revive rdiff-backup if need be.
If mask persist from beginning of April and nobody complains, i am sure that our userbase is pretty low But last time when i used rdiff-backup-fs(which i am maintain) - it was pretty fine. (In reply to Michał Górny from comment #2) > Personally I don't care much but I'd like to know whether the Python support > in those packages is worth forward-porting. I quickly looked as app-backup/pybackpack ebuilds - does not look like something hard to port to new eclasses(but i did not look closer) Maybe we should double check all things, as open bugs do not look critical enough to lastrite that useful piece of software
I vote for keeping rdiff-backup (still using it without any issues). What work would be required to keep it as is?
(In reply to Alex Brandt from comment #5) > I vote for keeping rdiff-backup (still using it without any issues). What > work would be required to keep it as is? Maybe you could go ahead and directly maintain it :/
(In reply to Pacho Ramos from comment #6) > Maybe you could go ahead and directly maintain it :/ Sure, does anyone from app-backup have any objections? If not I'll add myself as maintainer this coming Saturday. Can I get a link to the "known data loss bugs?" Is removing the mask an acceptable action as well?
(In reply to Alex Brandt from comment #7) > Can I get a link to the "known data loss bugs?" Probably this: http://savannah.nongnu.org/bugs/?35655 I can confirm that it happens, but you don't have to start over from scratch if your backup repo is huge. This was a few years ago, but IIRC you could fix it by deleting a small number of corrupted archives. Please also include the fix I posted to bug #463362. We don't want people removing xattr support (by uninstalling dev-python/pyxattr) after they've backed up some extended attributes.
(In reply to Michael Orlitzky from comment #8) > http://savannah.nongnu.org/bugs/?35655 Thanks! I'll follow up on that bug and see if I can get more information. If it's only due to the use of LVM snapshots it may be a corner case but definitely merits investigation. > I can confirm that it happens, but you don't have to start over from scratch > if your backup repo is huge. This was a few years ago, but IIRC you could > fix it by deleting a small number of corrupted archives. Do you mind adding that to the aforementioned upstream bug? > Please also include the fix I posted to bug #463362. We don't want people > removing xattr support (by uninstalling dev-python/pyxattr) after they've > backed up some extended attributes. Sounds good. I'll add that bug to my list of tasks. What should happen with this bug in light of all this?
(In reply to Alex Brandt from comment #9) > > > I can confirm that it happens, but you don't have to start over from scratch > > if your backup repo is huge. This was a few years ago, but IIRC you could > > fix it by deleting a small number of corrupted archives. > > Do you mind adding that to the aforementioned upstream bug? I don't really have anything useful to add. When this happened to me, I googled the error message and probably tried deleting whatever file was mentioned in the exception. Something or other eventually worked, but I don't remember the details (it was a long time ago). Once it was fixed I lost interest =) > What should happen with this bug in light of all this? Just close it as WONTFIX?
As app-backup herd, and the last person to bump it; if somebody else wants to keep it alive, go right ahead and take it over.
Thanks Robin, I've added myself as maintainer and will update the package with the other concerns as soon as I'm caught up. Once the other issues are taken care of, I'll unmask and close this bug.
Thanks for taking care of the bugs Alex :)
Alright, I have an updated version in my overlay ready for some acceptance testing. See bug 463362 for details. Closing this as WONTFIX and using the other bug as the discussion of problems with the bump version. Once the other bug is resolved I shall remove the mask.
