Bug#958509: RFS: swtpm/0.4.0~dev1-1 [ITP] -- Libtpms-based TPM emulator
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "swtpm" * Package name: swtpm Version : 0.4.0~dev1-1 Upstream Author : Stefan Berger * URL : https://github.com/stefanberger/swtpm * License : BSD-3-clause * Vcs : https://salsa.debian.org/kkamagui-guest/swtpm Section : misc It builds those binary packages: swtpm - Libtpms-based TPM emulator swtpm-libs - Common libraries for TPM emulators swtpm-dev - Include files for the TPM emulator's CUSE interface swtpm-tools - Tools for the TPM emulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/swtpm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/swtpm/swtpm_0.4.0~dev1-1.dsc Changes since the last upload: * New maintainer (Closes: #941199) * Added Standard-Version 4.5.0 to debian/control * Updated debhelper version to 12 in debian/control * Added Rules-Requires-Root to debian/control * Added Vcs-Browser and Vcs-Git to debian/control * Changed postinst interpreter to /usr/bin/sh * Converted debian/copyright to dep5-copyright format * Changed /usr/bin/swtpm_setup.sh to /usr/bin/swtpm_setup_helper * Added debian/watch file * Added lintian-override for manpage-without-executable, script-with- language-extension, and package-has-unnecessary-activation-of-ldconfig- trigger for upstream code Regards, -- Seunghun Han
Re: Question about naming
On 2020-04-22 15:13 -0400, Aaron Boxer wrote: > > > Thanks a lot, Wookey! I think I will just change my library name. At this > stage, no other libraries > that I'm aware of are relying on the name. Right. If you are upstream and can do this, then yes just picking a non-clashing name is the best plan, removing all difficulties. There is a basic assumption that all pubic library names are unique. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#955323: marked as done (RFS: atomic-chrome-el/2.0.0-1 [ITP] -- edit a web-browser text entry area with Emacs)
Your message dated Wed, 22 Apr 2020 16:23:47 -0400 with message-id <87imhrtgks@curie.anarc.at> and subject line Re: Bug#955323: RFS: atomic-chrome-el/2.0.0-1 [ITP] -- edit a web-browser text entry area with Emacs has caused the Debian Bug report #955323, regarding RFS: atomic-chrome-el/2.0.0-1 [ITP] -- edit a web-browser text entry area with Emacs to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 955323: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955323 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Control: block 909336 by -1 Dear mentors, I am looking for a sponsor for my package "atomic-chrome-el" Package name: atomic-chrome-el Version : 2.0.0-1 Upstream Author : alpha22jp URL : https://github.com/alpha22jp/atomic-chrome License : GPL-2+ Vcs : https://salsa.debian.org/emacsen-team/atomic-chrome-el Section : editors It builds this binary package: elpa-atomic-chrome - edit a web-browser text entry area with Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/atomic-chrome-el Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/atomic-chrome-el/atomic-chrome-el_2.0.0-1.dsc Alternatively, sponsor from git: git clone g...@salsa.debian.org:emacsen-team/atomic-chrome-el.git uscan -v --download-current-version Changes since the last upload: * Initial release. (Closes: #909336) Regards, Nicholas --- End Message --- --- Begin Message --- On 2020-04-22 16:07:48, Nicholas D Steeves wrote: > Hi Antoine! > > It seems I forgot to push my work on this package from early 2020 :-/ > Probably fell asleep...I'm truly sorry for wasting your time in the > initial review. It's alright... just be more careful next time: if you refer to the git repo, do update it! :) I uploaded the latest git, hopefully that will pass new shortly... a. -- It is capitalism and government which stand for disorder and violence. Anarchism is the very reverse of it; it means order without government and peace without violence. - Alexander Berkman--- End Message ---
Bug#955323: RFS: atomic-chrome-el/2.0.0-1 [ITP] -- edit a web-browser text entry area with Emacs
Hi Antoine! It seems I forgot to push my work on this package from early 2020 :-/ Probably fell asleep...I'm truly sorry for wasting your time in the initial review. Reply follows inline; feel free to skip the rest of this email if you're busy. The package should meet your standards @a69fbc3. OT, I wish the sponsorship template would insert commit:@foo...that would have prevented this, and I think the pkg on mentors was @a69fbc3... Antoine Beaupré writes: > i am not sure, but i suspect it is a mismatch between the > debian/changelog and debian/control package names. indeed, with the > following patch: > [snip] > -atomic-chrome (2.0.0-1) unstable; urgency=medium > +atomic-chrome-el (2.0.0-1) unstable; urgency=medium [snip] > ... the package compiles. > Indeed. Fixed 1 Jan 2020 (many apologies, I forgot to push). > The other issue I found is what now seems to be a recurring disagreement > between us. :) This is the tarball that `uscan` gives me when I run the > above command: > [snip] > There are a few things wrong here: > > 1. we should not needlessly differ from the upstream tarball > Yeah... I did special-case your preference 29 March 2020 (forgot to push). [1a] That said, in addition to what we discussed before, I'm finding that more and more projects release less-than useful tarballs eg: missing tox.ini or other things for self-tests. Fundamentally, the only reason I use a tarball check in the watch file is to reduce the load on the system that runs uscan (daily?). I would move everything over to pure git (with a quilt patch series, if necessary) in a heartbeat if using git in the watch file wouldn't make people grumble. > 2. if we really have to, `uscan` should allow us to reconstruct our > tarball reproducibly, or at least `README.source` should explain > how. at minimum, `README.source` should explain *why* we differ > [2a] I'm still not convinced of the value of this when it's fetchable with 'apt source', 'dgit clone', or 'dget'. That copy is gpg signed via the changes and/or dsc, and benefits from our (Debian) identity verification. Re: README.source, I don't know about this one...Lamby convinced me not to use README.source for this purpose some time ago. I used to always document when I was using a git tag rather than upstream release tarball :-) > 3. even if we insist on using `xz` (and I don't see why we do in this > case), we don't need the maximum compression level. this is a small > package and there's not reason to "crank it up to 11", so to speak :) > [3a] :-) I agree with you that it doesn't have much practical value for a package of this size, but there is a reason: establishing policy. I think it was spwhitton who impressed on me the value that the accumulation of packaging decisions affects trends, consensus, and ultimately Policy. The practical value is that if maintainers are willing to "crank it up to 11" even for little packages, then it's fair to expect the same from maintainers of packages where the diff is large. I'd give up on this with proof that weaker compression resulted in less net electricity consumption (including ongoing storage and transmission) than what is required for compression and decompression of xz. If you know, please share! > The following patch should fix the problem: > > From a9dc9a10a4c1ea9024a70335232dd837d36738d1 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= > Date: Fri, 17 Apr 2020 21:01:14 -0400 > Subject: [PATCH] remove superfluous diff with upstream tarball > Thank you for the patches, I sincerely appreciate that you took time to write them. Once again, sorry for not realising I hadn't pushed... > I feel uncomfortable sponsoring a package if it doesn't use the upstream > tarballs. I hope you'll understand. > Definitely! I've been mentoring some new Emacsen Team members, and wrote up a short hierarchy of priorities. The standards of one's sponsor are #1, unless they contradict Policy. Anyways, it has both conceptual and practical dimensions. Here's a practical one you'll appreciate: tldr (pithy synopsis), don't drain your sponsor with unnecessary arguments or they'll be too drained to review and sponsor your work ;-) If you're interested in reading it and/or if you think such a thing would make a good addition to an existing doc, please let me know! Cheers, Nicholas signature.asc Description: PGP signature
Bug#954050: RFS: persist-el/0.4+dfsg-1 [ITP] -- persist variables between Emacs Sessions
Hi Thomas, Reply follows in-line: Thomas Koch writes: > Hi Nicholas, > > I just uploaded persist-el. Thank you and sorry for the delay. This > was my first sponsorship and I also had to setup a new laptop. I'm > just waiting for the confirmation mail for the upload. > Thank you for sponsoring! Best of luck with the toil of getting the new laptop setup (eg: MUA line wrapping, and weird trailing white-space in lintian output). Did you upload twice btw? [22-04 edit: Oh! Sébastien, thank you!] > There are a few nitpicks and I'd be grateful if you could track them, > e.g. in bugs.d.o after the package enters the archive: > > - It's a pity that we can not include the info file due to the > license. Could you ask upstream to consider another license? Sure thing, I've added it to my TODO. BTW, because it's a GNU ELPA project I'm pessimistic they'll relicense the docs... > - As long as the doc is not included, I think you don't need to build > depend on texinfo. Agreed, I'll either drop it for the -2 upload, or if upstream relicenses their texinfo source then I'll build the info file. > - If upstream also uses Git, I prefer to track upstreams master branch > as upstream branch in the packaging repo. You could still merge their > branch in your existing repo or restart the repo? I also prefer to track upstream's master branch; however, persist.el is part of the GNU ELPA mondo-repo, which contains many other packages, and our team uses one repo per source package. > - Lintian also had two nitpicks, see below. I'm guilty of the "wrong" > section myself for elpa-editorconfig. What is the teams stand on this? > I've discussed similar issues with the team before, and the consensus is that it's not worth the trouble of a section change. Having filed a couple of section change requests in the past, an ftpmaster sometimes moved them to weird/generic sections...eg: I requested a move for Elpy (Python IDE) to Development from either Lisp or Editors, and they moved it to Text... Dh-make-elpa also used to use section "lisp" but now uses section "editors", and this is also a case where where "editors" seems to be team-endorsed (via dh-make-elpa), and I think the team consensus is that lintian's claim is wrong. IIRC the "info" severity is a compromise between our team and whoever believes all packages that are implemented in lisp should be in section lisp... When it was a warning I filed a bunch of section change requests (editors-to->lisp) that ftpmasters didn't seem to appreciate. That said, upon further consideration I agree that "lisp" might have been the most appropriate section, because persist.el has no interactive functions and is thus more of a library than an editor. If there's a way to attach a note to the ftpmaster review, then let's do that! I'm of course happy to happy to correct the package's classification in control so that it matches the archive. > I: persist-el source: public-upstream-key-not-minimal > upstream/signing-key.asc has 1 extra signature(s) for keyid 066DAFCB81E42C40 > > N: > > > N:The package contains a public upstream signing key with extra > > > N:signatures. The signatures are unnecessary and take up space in the > > > N:archive. > > > N: > > > N:Please export the upstream key again with the command: > > > N: > > > N: $ gpg --armor --export --export-options export-minimal,export-clean > > > N: > > > N:and use that key instead of the key currently in the source package. > > > N:
Bug#958482: RFS: pygresql/1:5.1.2-1 [QA] -- PostgreSQL module for Python3
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pygresql" * Package name: pygresql Version : 1:5.1.2-1 Upstream Author : PyGreSQL team * URL : https://www.pygresql.org/index.html * License : PostgreSQL * Vcs : https://salsa.debian.org/debian/pygresql Section : python It builds those binary packages: python3-pygresql - PostgreSQL module for Python3 python-pygresql-doc - Python Pygresql (common documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pygresql Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pygresql/pygresql_5.1.2-1.dsc Changes since the last upload: * QA upload. * New upstream version 5.1.2 Regards, Håvard
Bug#958480: RFS: python-pyperclip/1.8.0-1 [QA] -- Cross-platform clipboard module for Python3
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-pyperclip" * Package name: python-pyperclip Version : 1.8.0-1 Upstream Author : Al Sweigart * URL : https://github.com/asweigart/pyperclip * License : BSD-3-clause * Vcs : https://salsa.debian.org/debian/python-pyperclip Section : python It builds those binary packages: python3-pyperclip - Cross-platform clipboard module for Python3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-pyperclip Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-pyperclip/python-pyperclip_1.8.0-1.dsc Changes since the last upload: * QA upload. [ Debian Janitor ] * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse. . [ Håvard Flaget Aasen ] * New upstream version 1.8.0 * Update Standards-Version to 4.5.0 * Add Upstream-Contact in d/copyright Regards, Håvard
Re: Question about naming
On Wed, Apr 22, 2020 at 12:22 PM Wookey wrote: > On 2020-04-22 11:13 -0400, Aaron Boxer wrote: > > Hello!, > > > > I have created a new package for a library (grok) with the same name as > an > > existing debian package, so I have named my package grok-jpeg2000, > because it > > is an image coder for the JPEG 2000 standard. Will this mismatch between > my > > library name and my package name be a problem getting the package > accepted ? > > No. You can call the package whatever is reasonable, and of course > avoiding name clashes is necessary. And the source package name can be > nearly anything. > > However you can't (easily) just rename the library itself, because > things that depend on it will look it up by name and fail to find > it. This is fine - that package can be grok-jpeg200 (I see arch linux > has used the same name), and the library libgrok-jpeg200 or > libgrokn-jpeg2000, but the _binaries_ it installs are > /usr/lib//libgrok* > > That means that even with the binary package name clash avoided it > will not be co-installable with the other libgrok, because both > provide /usr/lib//libgrok. That may or may not be a problem > in practice (would anyone ever want both?) In this case you should > mark both packages as conflicting. Not idea, but hard to fix. > > You could fix this by using a different library name and fixing up the > name in all packages that depend on it, but that would still be a > problem for compiling external projects that depend on this libray. > > They may have wildly differing sonames and rates of change that are > likely to avoid filename clashes that way (i.e there would be > /usr/lib//libgrok.so.1 in libgrok1 and > /usr/lib//libgrok.so.23) in libgrok23, and not much danger of > the first putting out 22 more versions without the 2nd advancing, > although there is always some risk of that going wrong one day. > > The best thing to do depends on the popularity and satbility of these > projects and how many other packages/external projects use > them. Contacting the grok maintainer to discuss what would be best is > in order IMHO > Thanks a lot, Wookey! I think I will just change my library name. At this stage, no other libraries that I'm aware of are relying on the name. Aaron > > Wookey > -- > Principal hats: Linaro, Debian, Wookware, ARM > http://wookware.org/ >
Re: A question about uscan and MUT with different versions
Hi Leopold, > salsa ci build the package but other test fails and I don't know if it's > a package issue or salsa ci. Unfortunately, I don't know the cause of those failures. Considering how early the jobs failed I'd guess your package wasn't even involved yet, though. > > FWIW, the --download-current-version option does indeed not work for > > MUT packages with different version numbers; the package only has one > > current version. > > but this option is configured in salsa, right? The CI job runs origtargz from devscripts [1]. It tries several things to find/reproduce the .orig.tar. That uscan command is the last thing it tries [2]. [1] https://salsa.debian.org/science-team/soqt/-/jobs/685582#L205 [2] https://salsa.debian.org/debian/devscripts/-/blob/master/scripts/origtargz.pl#L304 Regards, Robin
Re: Question about naming
On 2020-04-22 11:13 -0400, Aaron Boxer wrote: > Hello!, > > I have created a new package for a library (grok) with the same name as an > existing debian package, so I have named my package grok-jpeg2000, because it > is an image coder for the JPEG 2000 standard. Will this mismatch between my > library name and my package name be a problem getting the package accepted ? No. You can call the package whatever is reasonable, and of course avoiding name clashes is necessary. And the source package name can be nearly anything. However you can't (easily) just rename the library itself, because things that depend on it will look it up by name and fail to find it. This is fine - that package can be grok-jpeg200 (I see arch linux has used the same name), and the library libgrok-jpeg200 or libgrokn-jpeg2000, but the _binaries_ it installs are /usr/lib//libgrok* That means that even with the binary package name clash avoided it will not be co-installable with the other libgrok, because both provide /usr/lib//libgrok. That may or may not be a problem in practice (would anyone ever want both?) In this case you should mark both packages as conflicting. Not idea, but hard to fix. You could fix this by using a different library name and fixing up the name in all packages that depend on it, but that would still be a problem for compiling external projects that depend on this libray. They may have wildly differing sonames and rates of change that are likely to avoid filename clashes that way (i.e there would be /usr/lib//libgrok.so.1 in libgrok1 and /usr/lib//libgrok.so.23) in libgrok23, and not much danger of the first putting out 22 more versions without the 2nd advancing, although there is always some risk of that going wrong one day. The best thing to do depends on the popularity and satbility of these projects and how many other packages/external projects use them. Contacting the grok maintainer to discuss what would be best is in order IMHO Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Question about naming
Hello!, I have created a new package for a library (grok) with the same name as an existing debian package, so I have named my package grok-jpeg2000, because it is an image coded for the JPEG 2000 standard. Will this mismatch between my library name and my package name be a problem getting the package accepted ? Thanks! Aaron
Re: Git bare debian repository format and python packages
On 2020-04-22 13:28 +0200, Birger Schacht wrote: > Hi *, > > I am a fan of the git bare debian repository format. I am using gbp to > build my packages: > gbp buildpackage --git-builder=sbuild -A -v -d unstable > --source-only-changes > > Usually that works without problems, but with python packages, when > dh_auto_clean is run *before* the sources are extracted that leads to > the build process being stopped :( > dh_auto_clean runs pybuild --clean (in my case its set to use distutils > as buildsystem) which does not find a `setup.py` which leads to an error > which stops the whole build process. > Is there a recommended way of handling this situation? It is a feature of the way sbuild works that 'debian/rules clean' is run in the containing OS, not in the chroot, in order to make the source. Lots of packages have dependencies used in the clean rule, and these are not declared separately from the normal build-dependencies. To build these with sbuild you need to have those dependencies installed in the outside OS, and hope that the likely differences in version between inside and outside do not matter. Fortunately there is a farily small set of packages that will let you run the clean rule on the vast majority of debian packages. I am not aware of any better solution than simply installing those dependencies in the containing OS. I would be useful to maintain a list somewhere, or even a metapackage, so people who wanted to reliably build every package using sbuild had an automated way of doing it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Git bare debian repository format and python packages
Hi *, I am a fan of the git bare debian repository format. I am using gbp to build my packages: gbp buildpackage --git-builder=sbuild -A -v -d unstable --source-only-changes Usually that works without problems, but with python packages, when dh_auto_clean is run *before* the sources are extracted that leads to the build process being stopped :( dh_auto_clean runs pybuild --clean (in my case its set to use distutils as buildsystem) which does not find a `setup.py` which leads to an error which stops the whole build process. Is there a recommended way of handling this situation? (I seem to remember that a solution for this problem was mentioned once in the git repository layout discussions, but I fail to find the email...) thanks, Birger signature.asc Description: OpenPGP digital signature
Re: A question about uscan and MUT with different versions
Hi Robin, first of all thanks for the reply. El 21/4/20 a les 20:32, Robin Gustafsson ha escrit: > Hi Leopold, > >> However, when I push it to salsa and run ci, the command executed is this: >> >> uscan --download --download-current-version >> >> and fails because the "data" modules has different version number that >> the original main or this is what I understand [2]. >> >> Some of you knows how to manage this situation or complete the watch >> file to make it works? > > I think the real problem is on line 123: >> gbp:error: upstream/1.6.0+ds1 is not a valid treeish good catch!!! > > You've probably forgotten to push that tag. Yes, now it's done. > With that tag present, gbp can recreate the .orig.tar files using > pristine-tar and then origtargz won't try to use uscan at all. salsa ci build the package but other test fails and I don't know if it's a package issue or salsa ci. > FWIW, the --download-current-version option does indeed not work for > MUT packages with different version numbers; the package only has one > current version. but this option is configured in salsa, right? Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? signature.asc Description: OpenPGP digital signature
Bug#954050: RFS: persist-el/0.4+dfsg-1 [ITP] -- persist variables between Emacs Sessions
On 21/04 20:23, Thomas Koch wrote: > I just uploaded persist-el. Thank you and sorry for the delay. As I had announced in my previous email, I already did that; see msg=19 of #954050, and https://ftp-master.debian.org/new/persist-el_0.4+dfsg-1.html. I'll most definitely be out of your way for the next uploads of persist-el. Cheers, -- Seb
