Hi,
On 01/08/2019 21:47, Otto Kekäläinen wrote:
Forhttps://github.com/rdiff-backup/rdiff-backup you appear to have
forked Seravo's fork, which is a fork of Sol1's. Would it be better if
we deleted that repo and I can transfer the existing repo to the
rdiff-backup organisation? I think then we get an auto-redirect and no
"forked from" notation.
Sure. Please proceed with doing that.
@Andrew, yes, please do this, I don't have enough rights to do it myself.
Please ping me when you are done so I'll proceed by "upstreaming" the
patches done in Debian, and after that I'll finish Eric's PRs review.
Thanks, I'd really like to get it out of the way. Such a huge PR makes
me nervous.
As for the Debian patches, I guess you mean the ones under [1]?
* 01_fix_restricted_test-server_option.diff - seems to be already in master
* 02_python_2.6_deprecationwarning.diff - addressed with my PR
* 03_fix_hardlinks.diff - not sure what it fixes but why not. Could be
done after the Py3 merge though to avoid conflicts.
* extend--no-compress-files.patch - minor, why not, whenever.
* librsync2.patch - already addressed in master.
* rdiff-backup-enodata-fix.patch - I've encountered the issue it
addresses and am currently analyzing, just ignoring the ENODATA seems to
me to only hide a potentially deeper issue: I haven't yet understood how
it comes to this issue, which in my case comes when trying to regress a
failed repo with EAs and/or ACLs involved. I would recommend leaving it
open for now, until we know better what we're doing.
KR, Eric
[1]
https://salsa.debian.org/python-team/applications/rdiff-backup/tree/debian/master/debian/patches
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
