Bug#768772: What is the status of the packaging ‘xkcdpass’?
On Sat, 13 Feb 2016 09:53:15 PM Ben Finney wrote: > On 13-Feb-2016, Dmitry Smirnov wrote: > > IMHO Git is not too hard to use unless you use git-buildpackage > > workflow. > > (That seems strange to me: hard to use if using ‘git-buildpackage’? That's right. IMHO packaging without GBP is much simpler and straightforward. GBP forces maintainer to do unnecessary things like to fiddle with "upstream" and "pristine-tar" branches which is a hassle for packages where DFSG repackaging is necessary. GBP implies profound competence with git which is an obstacle for those who understand packaging but not necessary confident with git. So many times merge conflicts in "gbp import-orig" left me frustrated... I tried GBP few times but found that I work faster and with more comfort without it. > I > think you mean the opposite sense “not too hard to use if you use > ‘git-buildpackage’ workflow”.) No I meant "easier without git-buildpackage". ;) Maybe that's just me... I like git though but I don't like GBP workflow... -- Best wishes, Dmitry Smirnov. --- Our difficulties and our dangers will not be removed by closing our eyes on them. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#768772: What is the status of the packaging ‘xkcdpass’?
On 13-Feb-2016, Dmitry Smirnov wrote: > On Sat, 13 Feb 2016 06:13:28 PM Ben Finney wrote: > > Even if the license conditions are deliberately the same as the > > “Files: *” paragraph? I thought one good reason to choose to grant > > license on ‘debian/*’ the same as the upstream work, was to not > > need those exceptions described. > > But you need to add your own copyright statement. It is better when > all licensing/copyright information is consolidated in > "debian/copyright". Ah, of course you're right. The copyright statement needs to be in a “Files: debian/*” stanza. > IMHO Git is not too hard to use unless you use git-buildpackage > workflow. (That seems strange to me: hard to use if using ‘git-buildpackage’? I think you mean the opposite sense “not too hard to use if you use ‘git-buildpackage’ workflow”.) Yes, I agree that in 2016, with upstream support effectively dead and with common workflows evolving beyond what Bazaar can do, maintaining packages in a Bazaar repository is only becoming more of a hindrance. I am steadily adapting each of my packages to Git. -- \“All persons, living and dead, are purely coincidental.” | `\ —_Timequake_, Kurt Vonnegut | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#768772: What is the status of the packaging ‘xkcdpass’?
On Sat, 13 Feb 2016 06:13:28 PM Ben Finney wrote: > Thank you for the offer! I'm happy to work with you to get this > package ready. :) > > * New upstream release: let's package it please. There are only 10 > > > > different files comparing to currently packaged version so there > > should not be much of an effort to update the packaging. > > Yes, that's my plan. I have begun work on packaging the newer > upstream, and also using Pybuild properly and other packaging > improvements. Awesome. Please let me know when package is ready. > > * changelog: please replace "Closes: bug#768772" with "Closes: > > #768772" (I'm not too sure if "bug#768772" works but as far as I can > > tell this notation is unusual. > > I prefer to follow the Policy §4.4 recommendation (“[…] by including > the string: closes: Bug#n in the change details.”). > > This is partly because it is the Policy recommendation, and partly > because “Bug#n” is more explicit and reads better IMO. OK. > > * rules: Ben, please move your copyright attribution to > > > > "debian/copyright". The latter should mention licensing for debian > > packaging. > > Even if the license conditions are deliberately the same as the > “Files: *” paragraph? I thought one good reason to choose to grant > license on ‘debian/*’ the same as the upstream work, was to not need > those exceptions described. But you need to add your own copyright statement. It is better when all licensing/copyright information is consolidated in "debian/copyright". That's OK if you insist to keep your copyright statement in "debian/rules" but "debian/copyright" is a better place for it. > > * rules: optional targets "get-(packaged-)orig-source" are > > > > redundant and merely invoke `uscan`. > > The ‘get-orig-source’ is strongly recommended by Debian Policy §4.9, > so I don't think it's a good idea to remove it until Policy no longer > has that clause. > > The ‘get-packaged-orig-source’ is needed because the Policy-conformant > ‘get-orig-source’ behaviour doesn't match what most people expect (and > the way ‘foo-buildpackage’ expects). > > So until Policy drops that recommendation, I'd prefer to keep those > targets in order to conform with Policy as much as feasible. As you wish. > > * control: Vcs links do not work. > > Thanks, I will fix this in the next release. > > > I'd very much like if you could consider converting repository to > > Git. > > Good, that's a medium-term goal. I learned Git only recently and most > of my packages are maintained in Bazaar still. > > I do plan to migrate them all to Git once I have a better handle on > the changes to the packaging workflow. I tried to checkout package using "git-remote-bzr" but it did not work probably because of incorrect Vcs-Bzr URL... IMHO Git is not too hard to use unless you use git-buildpackage workflow. Git repository may be helpful to your potential co-maintainers. > I am learning steadily with my packaging work on ‘dput’, which already > uses a Git repository. Perhaps you can sponsor my work on that too? I'll make no promises on that one but I'll have a look (when time allows) if you send me a separate email about that... Thank you. -- Regards, Dmitry Smirnov. --- Sometimes people don't want to hear the truth because they don't want their illusions destroyed. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#768772: What is the status of the packaging ‘xkcdpass’?
Howdy Dmitry, On 13-Feb-2016, Dmitry Smirnov wrote: > > I shall be happy to upload for you but few corrections are to be > made first: Thank you for the offer! I'm happy to work with you to get this package ready. For the changes you describe: > * changelog: let's upload to "unstable" instead of "experimental". Done now. “experimental” was IIRC only chosen because at the time of that package release, Jessie was in freeze. > * New upstream release: let's package it please. There are only 10 > different files comparing to currently packaged version so there > should not be much of an effort to update the packaging. Yes, that's my plan. I have begun work on packaging the newer upstream, and also using Pybuild properly and other packaging improvements. > * changelog: please replace "Closes: bug#768772" with "Closes: > #768772" (I'm not too sure if "bug#768772" works but as far as I can > tell this notation is unusual. I prefer to follow the Policy §4.4 recommendation (“[…] by including the string: closes: Bug#n in the change details.”). This is partly because it is the Policy recommendation, and partly because “Bug#n” is more explicit and reads better IMO. > * rules: Ben, please move your copyright attribution to > "debian/copyright". The latter should mention licensing for debian > packaging. Even if the license conditions are deliberately the same as the “Files: *” paragraph? I thought one good reason to choose to grant license on ‘debian/*’ the same as the upstream work, was to not need those exceptions described. > * rules: optional targets "get-(packaged-)orig-source" are > redundant and merely invoke `uscan`. The ‘get-orig-source’ is strongly recommended by Debian Policy §4.9, so I don't think it's a good idea to remove it until Policy no longer has that clause. The ‘get-packaged-orig-source’ is needed because the Policy-conformant ‘get-orig-source’ behaviour doesn't match what most people expect (and the way ‘foo-buildpackage’ expects). So until Policy drops that recommendation, I'd prefer to keep those targets in order to conform with Policy as much as feasible. > * control: Vcs links do not work. Thanks, I will fix this in the next release. > I'd very much like if you could consider converting repository to > Git. Good, that's a medium-term goal. I learned Git only recently and most of my packages are maintained in Bazaar still. I do plan to migrate them all to Git once I have a better handle on the changes to the packaging workflow. I am learning steadily with my packaging work on ‘dput’, which already uses a Git repository. Perhaps you can sponsor my work on that too? -- \ “Begin with false premises and you risk reaching false | `\ conclusions. Begin with falsified premises and you forfeit your | _o__) authority.” —Kathryn Schulz, 2015-10-19 | Ben Finney signature.asc Description: PGP signature
Bug#768772: What is the status of the packaging ‘xkcdpass’?
Hi Ben, On Sat, 13 Feb 2016 08:55:11 AM Ben Finney wrote: > The package has been examined and it's ready for upload, but still > needs a Debian Developer to sponsor its upload. > > The initial release is now at ‘mentors.debian.net’ again, seeking a > sponsor https://mentors.debian.net/package/xkcdpass>. > > A newer upstream version exists, but the 1.2.3-1 release works fine > now and can be uploaded without further work. Do you know a Debian > Developer who can help? I shall be happy to upload for you but few corrections are to be made first: * changelog: let's upload to "unstable" instead of "experimental". * changelog: please replace "Closes: bug#768772" with "Closes: #768772" (I'm not too sure if "bug#768772" works but as far as I can tell this notation is unusual. * control: Vcs links do not work. I'd very much like if you could consider converting repository to Git. * rules: Ben, please move your copyright attribution to "debian/copyright". The latter should mention licensing for debian packaging. * rules: optional targets "get-(packaged-)orig-source" are redundant and merely invoke `uscan`. Since those targets don't do anything useful on top of what `uscan` does I recommend to remove those targets. I'm guessing they were introduced to memorise uscan parameters? * New upstream release: let's package it please. There are only 10 different files comparing to currently packaged version so there should not be much of an effort to update the packaging. Thanks. -- All the best, Dmitry Smirnov. --- Reality is that which, when you stop believing in it, doesn't go away. -- Philip K. Dick signature.asc Description: This is a digitally signed message part.
Bug#768772: What is the status of the packaging ‘xkcdpass’?
On 12-Feb-2016, Ghislain Vaillant wrote: > Any news from this submission ? The package has been examined and it's ready for upload, but still needs a Debian Developer to sponsor its upload. The initial release is now at ‘mentors.debian.net’ again, seeking a sponsor https://mentors.debian.net/package/xkcdpass>. A newer upstream version exists, but the 1.2.3-1 release works fine now and can be uploaded without further work. Do you know a Debian Developer who can help? -- \“That's the essence of science: Ask an impertinent question, | `\and you're on the way to the pertinent answer.” —Jacob | _o__) Bronowski, _The Ascent of Man_, 1973 | Ben Finney signature.asc Description: PGP signature
