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
