Re: Bug#947923: RFS: opendkim/2.11.0~beta2-1 -- Milter implementation of DomainKeys Identified Mail
On 02/01/2020 08:30, I wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "opendkim" Forgot to add this little explainer: At last, the new upstream release. Unfortunately, there is a diff of ten thousands of lines, because upstream has stopped packaging (possibly by mistake) certain Autotools-generated files. To review, it is perhaps easiest to use a git diff in the repo, try this: https://salsa.debian.org/debian/opendkim/compare/929b50f...master
Bug#947923: RFS: opendkim/2.11.0~beta2-1 -- Milter implementation of DomainKeys Identified Mail
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opendkim" * Package name: opendkim Version : 2.11.0~beta2-1 Upstream Author : The Trusted Domain Project * URL : http://www.opendkim.org/ * License : BSD-3-clause and SOSL * Vcs : https://salsa.debian.org/debian/opendkim Section : mail It builds those binary packages: opendkim - Milter implementation of DomainKeys Identified Mail opendkim-tools - Set of command line tools for OpenDKIM libopendkim11 - Library for signing and verifying DomainKeys Identified Mail signatures libopendkim-dev - Headers and development libraries for the OpenDKIM library libvbr2 - Library for RFC 5518 Vouch By Reference (VBR) libvbr-dev - Headers and development libraries for the OpenDKIM VBR library librbl1 - Library to support a DKIM based RBL system librbl-dev - Headers/development libraries for the OpenDKIM RBL library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opendkim Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/opendkim/opendkim_2.11.0~beta2-1.dsc Changes since the last upload: * New upstream release. - Refresh patches, delete patch "openssl_1.1.0_compat.patch" incorporated upstream - Update symbols files, add Build-Depends-Package metadata - Drop outdated --enable-poll and --with-test-socket configure options * debian/rules: Build with hardening flags (patch by Christian Göttsche ; closes: #878058) * opendkim.service.generate script: Fix permissions of generated override files (patch by Christophe Siraut ; closes: #859797) * miltertest: Add patch fixing undefined behaviour in mt.eom_check() (Closes: #946397) * libopendkim-dev: Install only HTML files as documentation, and do so directly in /usr/share/doc/ (no subdirectory) as does upstream * Install convert_keylist.sh script in its documented location at /usr/bin/opendkim-convert-keylist, but keep old name around as a symlink * Replace all uses of /var/run with /run (Closes: #859706) * Add VCS repository coordinates * Bump standards version to 4.4.1 without further change Thank you! -- David
Bug#947920: RFS: pdf2djvu/0.9.15-1 [NMU] -- PDF to DjVu converter
On Thu, Jan 2, 2020 at 6:09 AM Hsieh-Tseng Shen wrote: > Moreover, I'd like to take over this package but I'm not sure if I have > to solve some bugs or just by changing debian/control. Btw, I already > asked maintainer for this from https://bugs.debian.org/945185. The O in the title of this bug means the package is orphaned. If you would like to be the new maintainer, you can follow this procedure to adopt the package: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package -- bye, pabs https://wiki.debian.org/PaulWise
Bug#947920: RFS: pdf2djvu/0.9.15-1 [NMU] -- PDF to DjVu converter
Package: sponsorship-requests Severity: normal Tags: upstream Dear mentors, I am looking for a sponsor for my package "pdf2djvu" * Package name: pdf2djvu Version : 0.9.15-1 Upstream Author : Jakub Wilk * URL : http://jwilk.net/software/pdf2djvu * License : GPL-2 * Vcs : https://salsa.debian.org/debian/pdf2djvu Section : text It builds those binary packages: pdf2djvu - PDF to DjVu converter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pdf2djvu Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pdf2djvu/pdf2djvu_0.9.15-1.dsc Changes since the last upload: * Non-maintainer upload. * New upstream release. Moreover, I'd like to take over this package but I'm not sure if I have to solve some bugs or just by changing debian/control. Btw, I already asked maintainer for this from https://bugs.debian.org/945185. Regards, -- Woodrow Shen (Hsieh-Tseng Shen) 4FA0 D159 803F F8B6 34E9 5A38 3970 FE24 7CB6 9685 woodrow.s...@gmail.com signature.asc Description: PGP signature
Re: Request for Infrastructure Projects Mentorship
On Thu, Jan 2, 2020 at 4:33 AM ansimita wrote: > I'd like to try my hand at Debian's Infrastructure Projects. I'm not entirely clear what you mean by Infrastructure Projects, you could mean core distribution projects like apt and dpkg or you could mean some of Debian's services: https://wiki.debian.org/Services Is there any particular project or area you are interested in? If you aren't sure: The dak project is probably the most important service for Debian, it manages the Debian apt repositories. https://wiki.debian.org/Services/Debian%20Archive I'm been looking for a regular collaborator on the Debian derivatives census. The project is a mix of social and technical work, mainly written in Python with some parts in Perl/shell/make. https://wiki.debian.org/Services/DerivativesCensus https://wiki.debian.org/Derivatives/Integration > I'm comfortable with C, Go, Python 3, and shell scripting Many of Debian's services use Python, only two use Go (manual pages, codesearch). dpkg uses C and apt uses C++. > I'm not comfortable with web technologies. Most of Debian's services are mostly web based, but there are some such as dak that are mostly not web based. > I lurk on a few of the Debian IRC channels at irc.debian.org and > I'll be able to join the #debian-mentors IRC channel if necessary. Much of the discussion on #debian-mentors is packaging related, but infrastructure discussion is definitely accepted there, so please feel free to join the channel and ask questions. -- bye, pabs https://wiki.debian.org/PaulWise
Request for Infrastructure Projects Mentorship
Hi, I'd like to try my hand at Debian's Infrastructure Projects. I'm comfortable with C, Go, Python 3, and shell scripting but I'm not comfortable with web technologies. For reference, my GitHub page is https://github.com/ansimita I lurk on a few of the Debian IRC channels at irc.debian.org and I'll be able to join the #debian-mentors IRC channel if necessary. Happy New Year, ansimita
Bug#947898: RFS: zope.schema/4.9.3-1 [QA] -- zope.interface extension for defining data schemas
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "zope.schema" * Package name: zope.schema Version : 4.9.3-1 Upstream Author : Zope Foundation and Contributors zope-...@zope.org * URL : https://pypi.python.org/pypi/zope.schema * License : Zope-2.1 * Vcs : None Section : zope It builds those binary packages: python3-zope.schema - zope.interface extension for defining data schemas To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zope.schema Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/z/zope.schema/zope.schema_4.9.3-1.dsc Changes since the last upload: * QA upload * New upstream release * d/watch - Use secure URI * d/control - Change to debhelper-compat - Bump debhelper to 12 - Update Standards-Version to 4.4.1 - Priority: change from extra to optional - Add Rules-Requires-Root - Secure URI on homepage * d/copyright - Use secure URI - Remove Files-Excluded, not included upstream. * d/rules - Enable testsuite Regards, Håvard
Bug#947888: RFS: transaction/3.0.0-1 [QA] -- Transaction management for Python
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "transaction" * Package name: transaction Version : 3.0.0-1 Upstream Author : Zope Foundation and Contributors * URL : https://pypi.python.org/pypi/transaction * License : Zope-2.1 * Vcs : None Section : zope It builds those binary packages: python3-transaction - Transaction management for Python To access further information about this package, please visit the following URL: https://mentors.debian.net/package/transaction Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/transaction/transaction_3.0.0-1.dsc Changes since the last upload: * QA upload * New upstream release * d/watch secure URI * d/control - Secure URI on homepage - Bump debhelper to 12 - Update Standards-Version to 4.4.1 - Add Rules-Requires-Root: no * Change to debhelper-compat * d/copyright - Update to correct format URI - Use secure URI's * d/rules add PYBUILD_NAME Regards, Håvard
Re: gbp import-orig after upstream force update
On Wed, Jan 01, 2020 at 11:45:02AM -0500, Tong Sun wrote: > - From the source side, everything is ready. It is only when it comes > to Debian building, I found that I need do trivial updates to the > upstream. In which case, I'd do that trivial update, and put it a debian patch, pending the next upstream release. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: gbp import-orig after upstream force update
On Tue, Dec 31, 2019 at 7:38 PM Mattia Rizzolo - mat...@debian.org wrote: > > On Tue, Dec 31, 2019 at 06:28:55PM -0500, Tong Sun wrote: > > How to do gbp import-orig after upstream did *force* push/update with > > the same tag? > > > > While doing packaging, there will always some trivial things I found I > > need to update the upstream source (I'm the author for both upstream > > and Debian packaging). > > > > However, if I have to give a new tag each time I do such trivial > > updates, then they'll go very fast for very trivial changes, which > > does not look good. So I always force push/update with the same tag. > > At the same time, it looks *horribly* from my side every time I see such > things. > > Don't tag things until you really want to release, and by then you ought > to have tested things well enough. If it's really trivial changes, then > it can just wait for whenever you feel like doing a new release. Totally, I would avoid such problems as much as possible. However the situation is, - From the source side, everything is ready. It is only when it comes to Debian building, I found that I need do trivial updates to the upstream. - The problem is that, `gbp import-orig` is looking for upstream tarball, which is only available when I do tagging, and this is exactly why I'm asking the question. I know I can go entirely manual, to do everything on my own without using tools like `gbp import-orig`, but that's the route I want to avoid. That being said, Thanks to your help anyway.
How to enforce non-standard permissions on files/directories
(Please CC me as I am not subscribed) I'm updating swapspace and figured I should enforce correct permissions on the swapfile directory. By default, debhelper seems to install directories as 755 which is what Debian Policy says to do. However, the swapfile directory (/var/lib/swapspace) probably should be 700, because no one but root has any need to access it. In 1.14-1 I removed the postinst script that enforced these permissions, assuming that upstream changes to enforce these permissions when installing would work. This was incorrect, so I will need to enforce these permissions differently. (And yes, I should have confirmed that this worked before removing this script, my mistake) I looked into how other packages do this and found NetworkManager, which uses a simple chmod: https://sources.debian.org/src/network-manager/1.14.6-2+deb10u1/debian/network-manager.postinst/#L28 Swapspace originally used dpkg-statoverride: https://sources.debian.org/src/swapspace/1.10-4/debian/postinst/ Lintian warns me about using dpkg-statoverride without checking if the override exists first (https://lintian.debian.org/tags/unconditional-use-of-dpkg-statoverride.html ), and policy says "There is one type of situation, though, where calls to dpkg-statoverride would be needed in the maintainer scripts, and that involves packages which use dynamically allocated user or group ids." (10.9.1) This would imply that I shouldn't use it for changing permissions in this way, though the beginning of this section also says "This section is not intended as policy, but as a description of the use of dpkg-statoverride." So which approach should I be using? chmod or dpkg-statoverride? Or should I just leave the permissions as they are? There's no security issue here, as swapspace ensures all files it creates are only readable/writable by root, and any user can see what swapspace is currently used with the swapon command. Thanks, Jacob
Bug#947880: RFS: zope.proxy/4.3.3-1 [QA] -- Generic transparent proxies for Python
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "zope.proxy" * Package name: zope.proxy Version : 4.3.3-1 Upstream Author : Zope Foundation and Contributors * URL : http://pypi.python.org/pypi/zope.proxy * License : Zope-2.1 * Vcs : None Section : zope It builds those binary packages: python3-zope.proxy - Generic transparent proxies for Python To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zope.proxy Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/z/zope.proxy/zope.proxy_4.3.3-1.dsc Changes since the last upload: * QA upload * New upstream release * Change to debhelper-compat * Bump debhelper to 12 * Update Standards-Version to 4.4.1 * Add Rules-Requires-Root: no * Use secure URI on homepage * Remove Files-Exluded from debian/copyright, files dont exist upstream * Use Secure URI in debian/watch * Add hardening in debian/rules * Disable tests Regards, Håvard
