Bug#993996: RFS: guerillabackup/0.5.0-1 [ITP] -- resilient, distributed backup and archiving solution
Dear mentors, A new version of the package is uploaded at mentors with the following changes compared with the previous version uploaded: * Upstream integration of improvements from Debian RFS review process, see merge on previous version v0.4.0-1: https://salsa.debian.org/halfdog-guest/guerillabackup/-/merge_requests/1 Now I am looking for a sponsor for my package "guerillabackup": * Package name : guerillabackup Version : 0.5.0-1 Upstream contact : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc The source builds the following binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.5.0-1.dsc Changes for the initial release: guerillabackup (0.5.0-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- hd
Re: Newer upstream version packaged for RFS/ITP with old one still on mentors
Adam Borowski writes: > On Thu, Jan 19, 2023 at 04:00:47PM +0000, halfdog wrote: >> While there is the RFS/ITP 0.3.0-1 version package still on mentors >> >> https://mentors.debian.net/package/guerillabackup >> >> a new upstream release is available. I updated salsa (without >> pushing yet) and have all packages ready. >> >> Usually I would just retitle the RFS/ITP and upload the new >> packages to mentors. But this would make the bugtracker issue >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993996 >> >> diverge from the state in the file upload. >> >> Otherwise deleting the old package would keep bug and upload >> in sync, but also also delete an upload-comment (one that I do >> not see to have much importance to the RFS process, but still). > > Just append to the RFS, by mailing 000...@bugs.debian.org with the added > info. Package uploaded, RFS appended (and retitled), Salsa pushed Thanks, hd
Bug#993996: RFS: guerillabackup/0.4.0-1 [ITP] -- resilient, distributed backup and archiving solution
Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name : guerillabackup Version : 0.4.0-1 Upstream contact : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc Changes to the previous version: * Features: * StorageTool: * Added "Size" check policy to detect backups with abnormal size. * Improved messages for interval policy violations and how to fix. * Warn about files not having any applicable policies defined. * Made policy inheritance control more explicit, improved documentation. * Bugfixes: * BackupGenerator: * Fixed invalid executable path in systemd service templates. * Fixed backup generation pipeline race condition on asynchronous shutdown. * Applied pylint. * StorageTool: * Removed anti-file-deletion protection left in code accidentally. * Fixed Interval policy status handling when applying retention policies. * Fixed deletion mark handling with concurrent retention policies. * Fixed exception attempting element retrieval from nonexisting source
Newer upstream version packaged for RFS/ITP with old one still on mentors
Hello list, While there is the RFS/ITP 0.3.0-1 version package still on mentors https://mentors.debian.net/package/guerillabackup a new upstream release is available. I updated salsa (without pushing yet) and have all packages ready. Usually I would just retitle the RFS/ITP and upload the new packages to mentors. But this would make the bugtracker issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993996 diverge from the state in the file upload. Otherwise deleting the old package would keep bug and upload in sync, but also also delete an upload-comment (one that I do not see to have much importance to the RFS process, but still). So what is the preferred way to do it? Kind regards, hd
Bug#993996: RFS: guerillabackup/0.3.0-1 [ITP]: Updated package version for ITP, looking for sponsors
Dear mentors, A new version of the package is uploaded at mentors with the following changes compared with the previous version uploaded: * Include upstream support for backup policies checks both for quality (verify interval policy) but also regulatory/GDPR compliant retention policy. * Fixed Debian FHS violation pedantic lintian warning. Now I am looking for a sponsor for my package "guerillabackup": * Package name : guerillabackup Version : 0.3.0-1 Upstream contact : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc The source builds the following binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.3.0-1.dsc Changes for the initial release: guerillabackup (0.3.0-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- hd
Bug#993996: RFS: guerillabackup/0.2.0-1 [ITP] -- resilient, distributed backup and archiving solution
Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name: guerillabackup Version : 0.2.0-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc The source builds the following binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.2.0-1.dsc Changes for the initial release: guerillabackup (0.2.0-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, hd
Bug#993996: Updated package version for ITP
Reusing old bug report, not opening new one as discussed on IRC. Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name: guerillabackup Version : 0.1.1-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.1.1-1.dsc Changes for the initial release: guerillabackup (0.1.1-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- halfdog
Bug#1003768: RFS: guerillabackup/0.1.1-1 [ITP] -- resilient, distributed backup and archiving solution
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name: guerillabackup Version : 0.1.1-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.1.1-1.dsc Changes for the initial release: guerillabackup (0.1.1-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- halfdog
Bug#993996: RFS: guerillabackup/0.1.0-1 [ITP] -- resilient, distributed backup and archiving solution
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name: guerillabackup Version : 0.1.0-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.1.0-1.dsc Changes for the initial release: guerillabackup (0.1.0-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- hd
Re: Salsa upstream update
halfdog writes: > Hello list, > > halfdog writes: >> ... Could someone please give me a hint how to update a Salsa >> project to current upstream? >> >> I try to follow >> >> https://wiki.debian.org/Diaspora/Packaging/UpdateUpstream >> >> but it seems, that there is no upstream branch for "gbp >> import-orig". Therfore I believe I should follow >> >> https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.convert.html >> >> which recommends >> >> git branch upstream $(git log --format='%H' | tail -1) >> >> when the first Salsa commit is identical to the upstream commit >> (it is and has ID 40ec386c55a619f401ba92f592f78b65d009d7e1). >> >> Still import-orig is unhappy afterwards. >> >> Is there something obvious wrong or is the github upstream >> in an invalid state so that importing cannot work? >> >> >> Commands used: >> >> gbp clone --pristine-tar --debian-branch=debian/sid >> https://salsa.debian.org/halfdog-guest/guerillabackup.git >> cd guerillabackup git branch upstream >> 40ec386c55a619f401ba92f592f78b65d009d7e1 git branch --all >> gbp import-orig --pristine-tar --uscan --verbose >> >> gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: >> ['git', 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', >> 'rev-parse', '--git-dir'] gbp:debug: ['git', 'for-each-ref', >> '--format=%(refname:short)', 'refs/heads/'] gbp:debug: ['git', >> 'show-ref', '--verify', 'refs/heads/upstream'] gbp:debug: >> ['git', 'status', '--porcelain'] gbp:info: Launching uscan... >> gbp:error: Uscan failed - debug by running 'uscan --verbose' >> >> >> >> Also trying something like this does not help: >> >> git remote add upstream >> https://github.com/halfdog/guerillabackup.git git fetch upstream >> gbp import-orig --pristine-tar --upstream-branch upstream/master >> --uscan ... >> >> >> Any ideas? > > I think I found the solution by myself, at least it makes "gbp > buildpackage" build the package. > > Could anybody please confirm that those steps are the Debian > way to do it? The commands should run on any machine without > the need to have any access credentials, ... > > > > gbp clone --pristine-tar --debian-branch=debian/sid > https://salsa.debian.org/halfdog-guest/guerillabackup.git cd > guerillabackup git config user.email "[your-mail]" git config > user.name "[your-name]" git branch upstream > 40ec386c55a619f401ba92f592f78b65d009d7e1 > > git remote add --fetch -t master upstream > https://github.com/halfdog/guerillabackup.git > > git merge --strategy=recursive --strategy-option=theirs v0.0.2 > > > After this automatic merge/merge-commit, some manual changes > have to be done to follow upstream: > > * Fix merge error in "src/TransferService" line 89, delete > 5 duplicated lines due to unexpected git-merge result from > above. > > * Edit "debian/changelog" and bump version to "v0.0.2-1". > > * Copy "data/debian.template/guerillabackup.install" to > "debian/guerillabackup.install" to account for deleted > "Changelog.txt" > > * Edit "debian/patches/01-systemd-documentation" and remove > patch for "guerillabackup-transfer.service" (already done upstream). > > * Edit "debian/upstream/metadata" to have new "Changelog:" > reference > "https://raw.githubusercontent.com/halfdog/guerillabackup/master/data/debian.template/changelog"; > instead. > > > After that the changes can be commited to the Salsa repository, > package being built: > > git commit . --message="V0.0.2-1 merged with upstream" git > tag "v0.0.2-1" gbp buildpackage > > > > I uploaded the package to > "https://mentors.debian.net/package/guerillabackup"; and it > seems to be OK except for some lintian warnings, which seem > easy to fix. > > > > Should I push the changes from above to the Salsa repository > as a prerequisite for starting the sponsor search? I just pushed it, ran "gbp buildpackage" and uploaded the package to mentors.
Bug#973340: RFS: guerillabackup/0.0.2-1 [ITP] -- resilient, distributed backup and archiving solution
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name: guerillabackup Version : 0.0.2-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.0.2-1.dsc Changes for the initial release: guerillabackup (0.0.2-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, hd PS: I tried to address the hints from previous RFS for older version (see https://bugs.debian.org/849754) or from private mails, e.g. Miroslav Kravec (documentation improvements needed), various comments on mentors list/irc (regarding salsa, gbp use, debian-file changes).
Re: Salsa upstream update
Hello list, halfdog writes: > ... > Could someone please give me a hint how to update a Salsa project > to current upstream? > > I try to follow > > https://wiki.debian.org/Diaspora/Packaging/UpdateUpstream > > but it seems, that there is no upstream branch for "gbp > import-orig". Therfore I believe I should follow > > https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.convert.html > > which recommends > > git branch upstream $(git log --format='%H' | tail -1) > > when the first Salsa commit is identical to the upstream commit > (it is and has ID 40ec386c55a619f401ba92f592f78b65d009d7e1). > > Still import-orig is unhappy afterwards. > > Is there something obvious wrong or is the github upstream > in an invalid state so that importing cannot work? > > > Commands used: > > gbp clone --pristine-tar --debian-branch=debian/sid > https://salsa.debian.org/halfdog-guest/guerillabackup.git cd > guerillabackup git branch upstream > 40ec386c55a619f401ba92f592f78b65d009d7e1 git branch --all gbp > import-orig --pristine-tar --uscan --verbose > > gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', > 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', > '--git-dir'] gbp:debug: ['git', 'for-each-ref', > '--format=%(refname:short)', 'refs/heads/'] gbp:debug: ['git', > 'show-ref', '--verify', 'refs/heads/upstream'] gbp:debug: ['git', > 'status', '--porcelain'] gbp:info: Launching uscan... gbp:error: > Uscan failed - debug by running 'uscan --verbose' > > > > Also trying something like this does not help: > > git remote add upstream > https://github.com/halfdog/guerillabackup.git git fetch upstream > gbp import-orig --pristine-tar --upstream-branch upstream/master > --uscan ... > > > Any ideas? I think I found the solution by myself, at least it makes "gbp buildpackage" build the package. Could anybody please confirm that those steps are the Debian way to do it? The commands should run on any machine without the need to have any access credentials, ... gbp clone --pristine-tar --debian-branch=debian/sid https://salsa.debian.org/halfdog-guest/guerillabackup.git cd guerillabackup git config user.email "[your-mail]" git config user.name "[your-name]" git branch upstream 40ec386c55a619f401ba92f592f78b65d009d7e1 git remote add --fetch -t master upstream https://github.com/halfdog/guerillabackup.git git merge --strategy=recursive --strategy-option=theirs v0.0.2 After this automatic merge/merge-commit, some manual changes have to be done to follow upstream: * Fix merge error in "src/TransferService" line 89, delete 5 duplicated lines due to unexpected git-merge result from above. * Edit "debian/changelog" and bump version to "v0.0.2-1". * Copy "data/debian.template/guerillabackup.install" to "debian/guerillabackup.install" to account for deleted "Changelog.txt" * Edit "debian/patches/01-systemd-documentation" and remove patch for "guerillabackup-transfer.service" (already done upstream). * Edit "debian/upstream/metadata" to have new "Changelog:" reference "https://raw.githubusercontent.com/halfdog/guerillabackup/master/data/debian.template/changelog"; instead. After that the changes can be commited to the Salsa repository, package being built: git commit . --message="V0.0.2-1 merged with upstream" git tag "v0.0.2-1" gbp buildpackage I uploaded the package to "https://mentors.debian.net/package/guerillabackup"; and it seems to be OK except for some lintian warnings, which seem easy to fix. Should I push the changes from above to the Salsa repository as a prerequisite for starting the sponsor search? hd
Salsa upstream update
Hello list, Could someone please give me a hint how to update a Salsa project to current upstream? I try to follow https://wiki.debian.org/Diaspora/Packaging/UpdateUpstream but it seems, that there is no upstream branch for "gbp import-orig". Therfore I believe I should follow https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.convert.html which recommends git branch upstream $(git log --format='%H' | tail -1) when the first Salsa commit is identical to the upstream commit (it is and has ID 40ec386c55a619f401ba92f592f78b65d009d7e1). Still import-orig is unhappy afterwards. Is there something obvious wrong or is the github upstream in an invalid state so that importing cannot work? Commands used: gbp clone --pristine-tar --debian-branch=debian/sid https://salsa.debian.org/halfdog-guest/guerillabackup.git cd guerillabackup git branch upstream 40ec386c55a619f401ba92f592f78b65d009d7e1 git branch --all gbp import-orig --pristine-tar --uscan --verbose gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', '--git-dir'] gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/'] gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream'] gbp:debug: ['git', 'status', '--porcelain'] gbp:info: Launching uscan... gbp:error: Uscan failed - debug by running 'uscan --verbose' Also trying something like this does not help: git remote add upstream https://github.com/halfdog/guerillabackup.git git fetch upstream gbp import-orig --pristine-tar --upstream-branch upstream/master --uscan ... Any ideas? Thanks, hd
RFS: guerillabackup/0.0.1-1 [ITP] -- resilient, distributed backup and archiving solution
Dear mentors, I am looking for a sponsor for my package "guerillabackup". I have updated the Salsa repository to build on Debian Bullseye also removing mentors.debian.net lintian warnings on old versions. I have tested the package on Bullseye machines. * Package name: guerillabackup Version : 0.0.1-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.0.1-1.dsc Changes since the last upload: * Initial packaging of guerillabackup (Closes: #849714) Regards, hd
Bug#849754: Processed: RFS: guerillabackup/0.0.1-1 [ITP]
Hi, Debian Bug Tracking System writes: > Processing commands for cont...@bugs.debian.org: > > > retitle 849754 RFS: guerillabackup/0.0.1-1 [ITP] > Bug #849754 [sponsorship-requests] RFS: guerillabackup/0.0.1-1/0.0.1-1 [ITP] > Changed Bug title to 'RFS: guerillabackup/0.0.1-1 [ITP]' from 'RFS: > guerillabackup/0.0.1-1/0.0.1-1 [ITP]'. Thanks for correcting this one, seems I have misunderstood the documentation regarding bug naming. I uploaded a new test-build of the package to https://mentors.debian.net/package/guerillabackup to verify, that gbp/salsa-build still works and no new lintian errors/warnings due to new rules are reported. *** CAVEAT on sponsoring: I detected by chance, that outbound messages from bugs.debian.org were corrupted under some conditions, affecting some part of the mentoring/sponsorship communication process. If due to greylisting someone happened to read message from the bug tracker before receiving the message addressed directly (quite likely), the content of the message might have been largely truncated, thus looking like being an incomplete answer to mentor feedback. While the messages sent out from bugs.debian.org were corrupted, the bug tracker web interface will show the complete, unmodified message initially sent. If you were wondering about my strange replies, please check https://bugs.debian.org/849714 https://bugs.debian.org/849754 Sorry about the inconvenience! hd
Bug#849754: RFS: guerillabackup - new upstream version
Version v0.0.0 as indicated in initial RFS is obsolete. As discussed on #debian-mentors IRC, the related ITP bug can be reused for v0.0.1. What about the RFS? Close it or retitle it? Debian packaging data was moved to salsa, hopefully integrating all review recommendations from above. gbp seems to work now without problems. To build and review the package, following commands work: gbp clone --debian-branch debian/sid --upstream-branch upstream https://salsa.debian.org/halfdog-guest/guerillabackup.git cd guerillabackup git config user.email "your mail" git config user.name "your name" git checkout debian/sid gbp buildpackage --git-pbuilder --git-pbuilder-options=--source-only-changes --unsigned-source --unsigned-changes
Bug#849754: RFS: guerillabackup/0.0.0-1
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 "m...@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
Bug#849754: guerillabackup review
Hello Michael, Thanks for you detailed review. Michael Lustfield wrote: > I reviewed this packaging and came up with some issues: > > - The description does nothing to explain what makes this solution unique. > + Why is this special? > + How does it even work? > + This should be easily gleaned from the package description. This is the current description for reference. There is similar topic at the end of the mail, where improvements are discussed in detail. === The tool supports asynchronous, local-coordinated, distributed secure backup generation, forwarding, verification, storage and deletion even in rugged environments. The system is open to integration of own code. The codebase is very small and kept simple to ease auditing. . Unlike business backup solutions, guerillabackup also considers following conditions that might be encountered with private use: * infrastructure uptime below 99%, e.g. machines not always powered * poor network connectivity, e.g. mobile access, parallel video streaming * poor physical access and anti-theft protection of machines * no security monitoring of machines . See /usr/share/doc/guerillabackup/Design.txt.gz section "Requirements" for more information. === > - There is a lintian override for a legitimate mistake (unindented list)
Bug#849754: Update from IRC discussion
In response to discussion, packaging was adjusted: * Added lintian override to ignore non-standard directory perms explaining the read restrictions * Ignore possible-unindented-list-in-extended-description (false positive) * Added docstrings to systemd service files, reported when using lintian -EviIL +pedantic
Bug#849754: RFS: guerillabackup/0.0.0-1
Hello Mentors, While the package in question (see [0]) is working 24/7 on multiple machines without problems, having created and transfered about 10k of data elements so far, also surviving updates, reboots, both the inclusion process but also the purging of obsolete RFS seems stuck. Should another round for inclusion be attempted or should the 2 bugs and mentors-site entry be closed/removed? Kind regards, hd PS: Current state: you might find [1] useful, especially message #16 (Sun, 1 Jan 2017) with a good (and demanding) review from Andreas Henriksson and the list of changes in response in message #23 (Thu, 04 May 2017). [0] https://mentors.debian.net/package/guerillabackup [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849754
Bug#849754: RFS: guerillabackup/0.0.0-1
Hello Andreas, Andreas Henriksson writes: > ... > Sorry I have not had time to follow up to you. I simply don't have > time. Hopefully my previous comments has been of some use to you, > but I don't think I can help out anymore. In my opinion, your length review really helped me a lot to improve the quality of the package, especially it motivated me to review the Python2/Python3-requirements of the target machines and migrate to Python3 earlier than I would have done otherwise, even though it required lengthy burn-in tests afterwards. I regret, that I could not improve the situation about systemd: there were no responses from systemd list and I did not find ways to do better than now. The current configuration worked in all tests, survived all boots and updates but is not as clean as it should be. As from my point of view, that lightweight tool might also be useful for other Debian users, I hope, that someone else has the time to continue the review. The whole review state was captured in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849754 and should be good groundwork for the next review. Best regards, hd > On Thu, Aug 31, 2017 at 05:00:00AM +, halfdog wrote: > > Hello Andreas, > > > > I did not hear from you after the last mails, see messages from > > 04 May 2017 21:59, 23 Jun 2017 05:59. Are you still interested > > in doing the (quite tricky) review? > > > > I have now also tested the build procedures and the software on > > Debian Stretch, see today's upload of package to mentors.debian.org. > > > > Best regards, > > hd > > > > > > Regards, > Andreas Henriksson
Bug#849754: RFS: guerillabackup/0.0.0-1
Hello Andreas, I did not hear from you after the last mails, see messages from 04 May 2017 21:59, 23 Jun 2017 05:59. Are you still interested in doing the (quite tricky) review? I have now also tested the build procedures and the software on Debian Stretch, see today's upload of package to mentors.debian.org. Best regards, hd
Bug#849754: RFS: guerillabackup/0.0.0-1
Hi Andreas, It took me quite a while to address all your remarks... Andreas Henriksson wrote: > Hello halfdog, > > Thanks for your interest in debian packaging > > On Fri, Dec 30, 2016 at 03:16:55PM +, halfdog wrote: > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for my package "guerillabackup" > [...] > > dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guer > illabackup_0.0.0-1.dsc > [...] > > > > As also stated in comment to https://mentors.debian.net/package/guerillabac > kup > > to avoid reviewers wasting time searching for dirty little package > > secrets, here are some pointers to things, I had problems with, > > when creating the package. Reviewers might disagree with my proposed > > solution, any feedback is very welcome! > > > > * Upstream Debian file templates: to support building of native > > packages using only the upstream source, Debian package files > > and build instructions are included already in upstream. To > > avoid duplication of them when not (yet) needed, they are copied > > within "rules" in target "override_dh_auto_configure" > > Not a fan here. :P > From a Debian(-only) perspective this complicates things for no > real gain. If you package things in Debian it's probably very > unlikely people will get their packages from elsewhere, specially > if they need to both build it themselves and follow a procedure > for doing so that's completely alien.. (but what do I know > about the actual problem you're trying to solve.) I only hoped to perform some dedup, but ... > I'm hoping DEP14 can instead be a replacement solution > for handling this (and also other reasons). ... if I understand http://dep.debian.net/deps/dep14/ correctly, building for different vendors in future should follow another scheme anyway, where deduplication is not an option. So I removed that stuff and duplicated all relevant upstream debian/* files to the non-native Debian quilt files also. > > * (Re)starting units on upgrade: As stated in documentation, two > > services can be used also from commandline (on demand) or as > > non-root user, depending on end user use cases. Thus it is intended, > > that the two systemd units are not enabled by default. Also > > a user may start them manually without enabling them. With upgrade > > following problem may arise: with standard debhelper means it > > was not possible to > > 1) stop all running units and > > 2) after update start only those, that were running beforehand. > > Solution: > > 1) do not use debhelper for stopping/starting of units, > > 2) find out in "prerm" which units are currently running, stop them and > > 3) in "postinst" start only those, that were running in step 1) > > Pretty please do not try to reinvent systemd integration on your own. > This is just way to easy to get wrong. If the current helpers does > not work for you it's either likely because you're using them wrong > and/or because they should be improved. Anything else is likely just > causing extra work and pain. > > Please swing by either the irc channel or contact the mailing list > for the Debian systemd maintainers. They're very skilled and usually > happy to help (time permitting). They are likely also the people > you need to get to review your package anyway if you invent your > own maintainer script scheme. I tried to get response from the mailing list, see http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2017-March/014551.html Also got to the IRC channel "#debian-systemd" with same result. As there are no responses proposing better solutions and the conditional service restarting code works as expected, I would propose keeping the current solution until bugreports are received. If insufficient, I would try to contact them again. > > * Use of .pyc files: As I do not fully understand the consequences > > of using .pyc files, especially in conditions where backup might > > be more important, e.g. when disks start already failing and > > py/pyc files might fall out of sync, I decided not to use them > > until I understand the possible risks. As codebase is very small > > and program is long-running, overhead from JIT-compiling should > > be not an issue. > > Not an expert on python packaging myself, but I think Debian python > packaging helpers should generate postinst code to automatically > generate the .pyc files on install. I guess the reason you can't > ship them is bec
Bug#849754: RFS: guerillabackup/0.0.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "guerillabackup" * Package name: guerillabackup Version : 0.0.0-1 Upstream Author : halfdog * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3 Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.0.0-1.dsc More information about guerillabackup can be obtained from https://github.com/halfdog/guerillabackup Changes since the last upload: * Initial packaging of guerillabackup (Closes: #849714) As also stated in comment to https://mentors.debian.net/package/guerillabackup to avoid reviewers wasting time searching for dirty little package secrets, here are some pointers to things, I had problems with, when creating the package. Reviewers might disagree with my proposed solution, any feedback is very welcome! * Upstream Debian file templates: to support building of native packages using only the upstream source, Debian package files and build instructions are included already in upstream. To avoid duplication of them when not (yet) needed, they are copied within "rules" in target "override_dh_auto_configure" * (Re)starting units on upgrade: As stated in documentation, two services can be used also from commandline (on demand) or as non-root user, depending on end user use cases. Thus it is intended, that the two systemd units are not enabled by default. Also a user may start them manually without enabling them. With upgrade following problem may arise: with standard debhelper means it was not possible to 1) stop all running units and 2) after update start only those, that were running beforehand. Solution: 1) do not use debhelper for stopping/starting of units, 2) find out in "prerm" which units are currently running, stop them and 3) in "postinst" start only those, that were running in step 1) * Use of .pyc files: As I do not fully understand the consequences of using .pyc files, especially in conditions where backup might be more important, e.g. when disks start already failing and py/pyc files might fall out of sync, I decided not to use them until I understand the possible risks. As codebase is very small and program is long-running, overhead from JIT-compiling should be not an issue. Regards, hd
