Bug#1030390: RFS: termpaint/0.3.0-2 -- low level terminal access
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "termpaint": * Package name : termpaint Version : 0.3.0-2 Upstream contact : Martin Hostettler * URL : https://termpaint.namepad.de/ * License : 0BSD or BSL-1.0 or MIT-0, BSL-1.0, BSD-3-clause, bzip2-1.0.6, BSD-2-clause, BSL-1.0 or Expat * Vcs : https://salsa.debian.org/debian/termpaint Section : libs The source builds the following binary packages: libtermpaint0a - low level terminal access - shared library libtermpaint-dev - low level terminal access - headers To access further information about this package, please visit the following URL: https://mentors.debian.net/package/termpaint/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/t/termpaint/termpaint_0.3.0-2.dsc Changes since the last upload: termpaint (0.3.0-2) unstable; urgency=medium . * Fix Vcs-Git URL in debian/control * Fix mismatched lintian override very-long-line-length-in-source-file * Add patch to enable building on armel supplied by upstream * Update out-of-date-standards-version to 4.6.2 Regards, -- Christoph Hueffelmann
Bug#1030307: RFS: posixsignalmanager/0.3-2 -- posix signal handling for qt
[upstream here] On Thu, 2 Feb 2023 16:13:41 +0100 Norwid Behrnd wrote: > > So long for a library, change the name. I don't see why library may not have a descriptive name instead of a short and cryptic one. And the debian package name follows the name of the library it contains. Which is by its pkg-config name: PosixSignalManager Yes, some may find that ugly and long, but it's the libraries name, and discussions on if that name is good should be held upstream. I'm not aware of any debian policy the package name might violate. Also this is a upload to package that recently entered testing but did not build for various release architectures due to tests build on amd64 centric assumptions, which should now be fixed. I think it's important to try to help debian to offer packages on as many architectures as feasable. > > It might be better to rename the package after bookworm became stable. > Given how near we are in the release cycle to the freeze for new packages to enter testing i agree that **if** the name needs changing it is more feasable to do that targeting bookworm+1, but i still think that the name is fine.
Bug#1029186: reply: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules
On Fri, Feb 03, 2023 at 07:55:08AM +, min sun wrote: > > Hi mentors! > > I packaged new version of libcommons-validator [1] and uploaded again to > debian mentors[2], please refer to Upload #2 . Hi! I will review and sponsor the upload soon. Thank you for your contribution to Debian! Cheers, tony
Re: Bug#1029186: reply: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules
Postscript: If you already edit `debian/changelog` (`UNRELEASED` -> `unstable`), the trailing spaces in this file equally can be removed in the same session, too.
Re: Bug#1029186: reply: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules
Hello Min Sun, is there a particular reason why you opt for / stick to distribution `UNRELEASED` for a package already monitored by the tracker?[1] It is the entry e.g., `dch -i` puts into file `/debian/changelog` when you start to work on a new version (increment) of a package. After all other other work on your side is done, an eventual change to the string `unstable` (then lower case only) is one of the keys necessary to let results of your work enter branch `unstable`, and later `testing`, etc. Regards, Norwid [1] https://tracker.debian.org/pkg/libcommons-validator-java
