Bug#903270: RFS: sharness/1.0.0-1 [ITP] shell library for running tests
Hello Sergio, Am Fri, 13 Jul 2018 12:28:10 -0400 schrieb Sergio Durigan Junior : > Created: > > https://salsa.debian.org/debian/sharness > > And added you as a Developer there. Thank you! I pushed my repository to its new location. I will remove the old project after the next packaging upload. Additionally I tagged (and signed) the commit that was used for the upload (debian/1.0.0-1). And I committed the changes of the Vcs-* fields in preparation of the next upstream release. Thank you for your pleasant guidance on the way to my first new package! Cheers, Lars
Bug#903270: RFS: sharness/1.0.0-1 [ITP] shell library for running tests
Hello Sergio, > After I sent you the reply I saw that you're actually packaging on top > of upstream's git repo. I personally don't like this option, but that's > a matter of taste. If you haven't yet, I recommend you read: > > > https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html > > which covers your case. I am not yet accustomed to the modern git based packaging tools. And I was not sure, if/whether there is a canonical approach. I will take my time to digest the one above. Thank you for sharing. > > I uploaded another source package for another round ... > > Thanks. I noticed you've rewritten the history of your git repo. > That's fine for now because the package hasn't been uploaded yet, but > it's something pretty much frowned upon by everybody, so avoid doing > that. yes, indeed. I fell into that trap, as I was previously tagging my packaging proposals prematurely. You fixed this brain-bug of mine now, thus I won't touch rebase again :) > When you're ready, please contact me and I can create the sharness > repository under the 'debian' namespace on salsa, so you can migrate it. Please go ahead. Or is there anything, I need to do? Thank you! Cheers, Lars
Bug#903270: RFS: sharness/1.0.0-1 [ITP] shell library for running tests
Hello Sergio, Am Thu, 12 Jul 2018 21:11:50 -0400 schrieb Sergio Durigan Junior : > [..] > Hm, it seems you removed an important line, [..] stumbling upon my own feet :( > 1) Since this is the first release of the package, a d/changelog with an > entry like: > [..] > would have been enough. Good to know - thank you. > 2) A word about git tags. I noticed you only have the "debian/1.0.0-1" > tag, but no "upstream/1.0.0" tag in your git repo. git-buildpackage > should have created that for you; it's worth checking to see if you > didn't forget to push. gbp ist still quite new to me ... I tagged the upstream release now. > Also, we usually don't create the "debian/xyz" tags until the package > has been uploaded and accepted into the archives. Good to know! > Hm, alright. The "aggregate-results.sh" may be useful to some users; it > provides a way to display the results in a nicer way, right? Indeed, the code looks like that. But I also expected it to adjust its exit code in case of errors. Thus it feels like a tool just for humans and not for testing. We will see, how upstream responds ... > Maybe you could install it under /usr/share/doc/sharness/contrib/, since it's > not an example script, but doesn't seem *that* important to justify polluting > the PATH. What do you think? That sounds good. I suggested this location in the discussion with upstream: https://github.com/chriscool/sharness/issues/78#issuecomment-404706089 Now I install this file via dh_install in the above location. But dh_install seems to remove the executable flag from the file (as the target path indicates a documentation file, I guess). Do you think, this is acceptable? Or would an "override_dh_auto_install" target be justified for a chown operation? I uploaded another source package for another round ... Thank you! Cheers, Lars
Bug#903270: RFS: sharness/1.0.0-1 [ITP] shell library for running tests
Hello Sergio, thank you for reviewing my packaging attempt! Am Wed, 11 Jul 2018 23:21:05 -0400 schrieb Sergio Durigan Junior : > [..] > 1) On d/copyright, you don't list the files under the "debian/" > directory. These should be listed, and you should be the author. I > recommend choosing the same license as upstream, just to make things > simpler. > > 2) On d/control, Standards-Version should now be 4.1.5. > > 3) Better safe than sorry: on d/control, the Vcs-* fields should point > to your salsa.d.o repo. Done (1-3). > 4) On d/rules, you can remove the "override_dh_auto_install" target if > you're not using it. Done. I am a bit embarrassed, that I overlooked that cruft ... My recent upload contains another change besides the ones above: for now I removed the helper script "aggregate-results.sh". I started a discussion with upstream in order to decide whether that file needs to be included at all (https://github.com/chriscool/sharness/issues/78). > Otherwise, the package looks good to me. Let me know when you address > these issues and I'll be happy to upload it. Thank you for your kind offer! I just uploaded my updated source package: https://mentors.debian.net/debian/pool/main/s/sharness/sharness_1.0.0-1.dsc Cheers, Lars
Bug#903270: RFS: sharness/1.0.0-1 [ITP] shell library for running tests
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "sharness" Package name: sharness Version : 1.0.0-1 Upstream Author : Christian Couder URL : https://github.com/chriscool/sharness License : GPL-2 or later Section : devel It builds those binary packages: sharness - shell library for automated tests with TAP output Sharness is used by a few Debian packages as part of their DEP8 tests (via autopkgtest): * gearmand * git-reintegrate * git-remote-bzr * git-remote-hg * hiera-eyaml * jemalloc * mod-gearman * munin * pass-otp * puppet-lint * puppet-module-puppetlabs-concat * puppet-module-puppetlabs-ntp * puppet-module-puppetlabs-stdlib (the list was assembled via https://codesearch.debian.net) Currently these packages embed a copy of the sharness.sh file below debian/tests. I will file bug reports against these packages (including patches) after the sharness package is available, in order to help them getting rid of their embedded code copies. I am part of the munin packaging team, thus the munin package would benefit immediately from this new package. I plan to maintain the sharness package for the foreseeable future. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sharness Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sharness/sharness_1.0.0-1.dsc Cheers, Lars
Re: RFS: pycam
Dear mentors, just as a ping: would there be anybody willing to do the upload of PyCAM? (a toolpath generator for 3-axis machines - http://pycam.sourceforge.net) cheers, Lars -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101126112213.787e0...@erker
Re: RFS: pycam
Hi, btw: what did you do to generate these spelling warnings? I could not find any reference to a spell checker in lintian ... I simply ran lintian -I on the .deb file, I don't think there's anything special to do to get these warnings; maybe you're using an older version (I have 2.4.3)? now I got it: I ran lintian on the .dsc file before - this did not emit any spelling warnings. Using lintian with the .changes files (or the .deb) did the trick. I can't upload it, but I'm sure someone else will. Good luck! ok - thanks for your efforts, anyway! Would there be anybody else willing to do the upload? cheers, Lars -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116124256.017ff...@erker
Re: RFS: pycam
Hi, I just realized, that there could be issues with the current changelog file. Please comment on these, before considering any upload. Thanks! 1) I forgot to close the ITP bug (#600779) in the changelog file. Is it OK to close the ITP bug manually? Or should I create a new package with the missing changelog-statement? 2) the changelog file contains three older changelog entries, that I used for manual packaging before (without uploading these to the debian archive). Should I remove them? 3) Since I changed some packaging details according to Benoît's suggestions, I created a second revision of the package (before: 0.4-1; now: 0.4-2). Is it acceptable for a NEW package to have a debian revision greater than one? You find the current changelog attached to this mail. Thanks in advance for your comments! cheers, Lars changelog Description: Binary data
Re: RFS: pycam
Hi Sandro, Would you be interested in joining[1] the PAPT[2] and maintain this package with us (you might also fall in love with other packages we maintain and help ;) )? thanks for this invitation! Yes - I think this is interesting for me and I will get in contact with the group ... cheers, Lars -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116011919.636a0...@erker
Re: RFS: pycam
Hi Benoît,
Here are the few issues I spotted in your package:
thank you for taking the time!
- You have debian/{postinst,prerm} scripts, but they do not do
anything. You should just delete them.
removed
- In debian/copyright, there is no email address for either of the
maintainers (and Sebastian Kuzminsky's email is not formatted
correctly). While you're at it, you should also add yourself to the
packaging copyright.
You may also want to use the DEP-5 format [1] for that file.
[1] http://dep.debian.net/deps/dep5/
I changed the copyright file according to DEP5. I did not know DEP5 before - so
thanks for pointing this out!
- lintian -I gives the following warnings:
[...]
I added the missing patch descriptions and created a watch file.
I: pycam: spelling-error-in-manpage usr/share/man/man1/pycam.1.gz
[...]
I fixed these spelling mistakes upstream. The changes will go into the debian
package of the next release of PyCAM.
btw: what did you do to generate these spelling warnings? I could not find any
reference to a spell checker in lintian ...
I guess, now the package should be in a good shape.
I would be happy, if anybody would be willing to upload it.
cheers,
Lars
PS: you don't need to CC me - I am subscribed to the mentors list
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101114165353.68287...@erker
RFS: pycam
Dear mentors, I am looking for a sponsor for my package pycam. * Package name: pycam Version : 0.4-1 Upstream Author : Lode Leroy, Lars Kruse (that's me) * URL : http://pycam.sourceforge.net * License : GPL3 Section : python It builds these binary packages: pycam - CAM program library written in Python PyCAM is a toolpath generator for 3-axis machines (e.g. mills). The package appears to be lintian clean. I am currently one of the maintainers of the clearsilver package in Debian. I would like to see PyCAM included in Debian, because: 1) it would be the first toolpath generating program in the repository (python-opencam is only a library and currently not usable) 2) I want to simplify the life of PyCAM's users :) 3) I want to get more involved in Debian development The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pycam - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/p/pycam/pycam_0.4-1.dsc I would be glad if someone uploaded this package for me. cheers, Lars -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101113011649.38b54...@erker
Re: [RFS] qterm: BBS client for X Window System written in Qt
Hi, It's not lintian and linda clean. lintian report following warnings[2], linda report similar warnings. [2] $ lintian qterm_0.4.0pre4-1_source.changes W: qterm source: dh-make-template-in-source debian/manpage.1.ex W: qterm source: dh-make-template-in-source debian/manpage.sgml.ex [/2] why don't you fix these warnings? In this case, it should be _really_ easy, to get rid of them ... (try lintian -i ... for a verbose description of the warning) regards, Lars -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc signature.asc Description: PGP signature
