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: RFS: guerillabackup/0.0.0-1
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 cherry-picking new stuff. Two commits are really not that much, seems like an inactive project. Is it the case? Please note: I maintain borgbackup, that I think is really more powerful (complete) than your tool (please have a look at it). G.
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 halfdog, 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. 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 because then you need to build them with the lowest > supported capability set of the architecture (which itself is > likely hard to do). In short, the debian way is to just rm *.pyc *.pyo > and trust the helpers to do the right thing. Same argument as with security considerations below: availability, stability in those bordercases might not be a relevant issue for the first version of the package. So .pyc objects are now generated the same
Bug#849754: RFS: guerillabackup/0.0.0-1
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/guerillabackup_0.0.0-1.dsc [...] > > 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" 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'm hoping DEP14 can instead be a replacement solution for handling this (and also other reasons). > > * (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. > > * 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 because then you need to build them with the lowest supported capability set of the architecture (which itself is likely hard to do). In short, the debian way is to just rm *.pyc *.pyo and trust the helpers to do the right thing. Below is a full packaging review with some pointers, hope it helps: Vcs-* -> should point to debian packaging repository, not upstream. (Note: does not have to be a separate repository. See DEP14 branch naming scheme for example. Still, Vcs-* fields should point to Debian specific parts. For information pointing to upstream see https://wiki.debian.org/UpstreamMetadata ) Section -> please consider looking up the correct section for backup utilities at https://packages.debian.org/unstable/ (Please note the section name is not the one on the list, click the link to see the actual name.) python2 only is unfortunate. Please note that porting everything in Debian to python3 was already a goal for this release. If you're not using python3 in a new package at this point that leaves me wondering about your chances for ever being part of the next release. (Python is not by strongest side though, specially not debian packaging of it, so please find more advanced advice on this from someone else.) dh compat 9 -> consider using latest dh compat 10 instead. This automatically includes dh-systemd, etc. It will also use 'restart /after/ upgrade' by default. * DEP14 rather than copying packaging during configure. * restart instead of
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
