Bug#849754: RFS: guerillabackup/0.0.0-1

[halfdog <me@halfdog.net>]

Hello Gianfranco,

Gianfranco Costamagna writes:
> control: owner -1 !
> control: tags -1 moreinfo
> Hello,
> 
> >I am looking for a sponsor for my package "guerillabackup"
> 
> I would really like to see the package working, but I see the
> upstream repo is lacking the history, this makes the Debian
> work less efficient in cherrypicking new stuff.
> Two commits are really not that much, seems like an inactive project.

Well, one commit (the first one is the github creation commit).
The software is the Python2 port of a quite old project, so just
rewriting it, comparing result with old program by unit tests
and committing the result to github resulted in a single commit.

All other changes are from the request to transform it to Python3
(some earlier review), fixes for problems introduced by that changes,
which were then added as a diff for packaging the initial release
version

If it would help, I could move those changes from my local branch
(which is used to create the patches for the Debian package by
comparing it to the github trunk) also to the github trunk. This
would then create a new github trunk (upstream) version, thus
starting a new RFS process I guess (due to version change). Then
there would also be more upstream commits.

> Is it the case?

Yes and no: it is working on all my machines without any flaws
or major changes for more than a year or so now and as long as
I do not change my setup to expose new bugs (which I do not plan
to do) or someone else reports bugs from his setup (which would
require solid packaging to have new users), so long there is no
real need for further development.

While the RFS was running, all changes went to the Debian packaging
repository and now the new salsa repository, which should build
the package using "gbp", hence also no upstream changes. But I
did not manage to get gbp running from the documentation, e.g.
trying the following did not work out and the various (sometimes
contradictory) recommendations from IRC did not really improve
the situation. You can test with:

git clone https://salsa.debian.org/halfdog-guest/guerillabackup.git
cd guerillabackup
git config user.email "me@halfdog.net"
git config user.name "halfdog"
gbp buildpackage

So I stopped trying with salsa/gbp. Maybe in some years when alioth/
salsa transition has progressed, documentation will be more conclusive
for packaging noobs and make that step easier.

> Please note: I maintain borgbackup, that I think is really more
> powerful (complete) than your tool (please have a look at it).

Now I had time to check that one out. If I understand correctly,
it could be a nice preprocessor for the guerillabackup:

* borgbackup: does local file deduplication, uses nearby storages
  (similar trust zone, high bandwidth, reliable connections)
  to create repository with or without symmetric encryption

* guerillabackup: performs assymetric encryption of borgbackup
  outputs (e.g. the borgbackup repositories or changesets exported
  from the repository), distribution of redundant copies of those
  outputs to remote cloud storage with lower trust (other trust
  zones, low bandwith, unreliable connections)

hd