Re: trends.debian.net updated
On Sun, Apr 12, 2020 at 09:11:57PM +0200, Ole Streicher wrote: > One could expect from maintainers that they check their packages for > compliance regularly and that they document that. For a package that had no > documented check for seven years it is OK to file an RC bug in order to > clarify the compliance. nope. that's a 'minor' issue according to https://www.debian.org/Bugs/Developer#severities -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#956607: ITP: cachy -- Provide a simple yet effective caching library
Package: wnpp Severity: wishlist Owner: Emmanuel Arias * Package name: cachy Version : 0.3.0 Upstream Author : Sébastien Eustace * URL : https://github.com/sdispater/cachy * License : MIT Programming Lang: Python Description : Provide a simple yet effective caching library Cachy provides a simple yet effective caching library. Cachy has the following advantages: simple but powerful API, thread-safety, decorator syntax and support for memcached, redis, database, file, dict stores. . Poetry package depends on this package. . This package can be maintained under DPMT umbrella.
Re: DKIM for Debian Developers
Hi On Mon, Apr 13, 2020 at 01:39:00PM +0100, Adam D. Barratt wrote: Hi, There's been a lot of discussion in various forums recently about mail authentication for @debian.org addresses. As an initial step in that direction, I'm pleased to announce that the db.debian.org mail gateway now allows DDs to configure DKIM keys [http://www.dkim.org/] for their account, using the "dkimPubKey" command. The command format to use to set keys is: dkimPubKey: where the selector name must end with ".your_uid.user" As an example, to configure a key for the DKIM selector "debian1.adsb.user", I might send: dkimPubKey: debian1.adsb.user MIIBIjANBgkqhkiG9w0BAQ... to cha...@db.debian.org. This will result in a TXT record for debian1.adsb.user._domainkey.debian.org. (i.e. a selector of "debian1.adsb.user") thanks to Adam and DSA for this! Multiple selectors can be added for a user by sending multiple "dkimPubKey" commands. Similarly to the existing SSH key functionality, any existing keys will be removed when adding new ones, so all required keys must be provided in the same mail. Some related resources which might be useful for configuring DKIM signing using popular MTAs: - https://exim.org/exim-html-current/doc/html/spec_html/ch-dkim_spf_and_dmarc.html#SECDKIMSIGN - https://debian-administration.org/article/718/DKIM-signing_outgoing_mail_with_exim4 - http://opendkim.org/opendkim-README As ever, please let us know if you have any comments on or issues with the new functionality. Regards, Adam for DSA -- IRC: gfa GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5 OLD GPG: 0x44BB1BA79F6C6333
Bug#956628: ITP: golang-github-microcosm-cc-bluemonday -- Go library for scrubbing user generated data of unapproved html
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org Package: wnpp Severity: wishlist Owner: Taowa Munene-Tardif * Package name: golang-github-microcosm-cc-bluemonday Version : 1.0.2 Upstream Author : Microcosm * URL : https://github.com/microcosm-cc/bluemonday * License : BSD-3-clause Programming Lang: Go Description : Go library for scrubbing user generated data of unapproved html Bluemonday takes untrusted user generated content as an input and returns HTML that has been sanitised against a whitelist of approved HTML elements and attributes. This can help prevent XSS attacks. Dependency of pat (#877030). -- Taowa Munene-Tardif taowa.ca Montréal
Bug#956632: ITP: python3-iniherit -- A ConfigParser subclass that allows inheritance.
Package: wnpp Severity: wishlist Owner: Henry-Nicolas Tourneur * Package name: python3-iniherit Version : 0.3.9 Upstream Author : Philip J Grabner, Cadit Health Inc * URL : https://pypi.org/project/iniherit/ * License : MIT Programming Lang: Python Description : A ConfigParser subclass that allows inheritance. Adds INI-file inheritance to ConfigParser. Note that although it effectively behaves very similarly to passing multiple files to ConfigParser’s read() method, that requires changing the code at that point. If that is not feasible, or the INI files should dictate inheritance themselves, then the iniherit package is a better alternative. Extra information on this packaging: - I wish to maintain this package together with DPMT - This library is a dependency for the authenticator gnome app which I would like to package as well once dependencies are resolved.
Bug#956634: ITP: golang-github-pd0mz-go-maidenhead -- Maidenhead Locator system in Golang
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org Package: wnpp Severity: wishlist Owner: Taowa Munene-Tardif * Package name: golang-github-pd0mz-go-maidenhead Version : 0.0~git20170221.faa09c2-1 Upstream Author : pd0mz * URL : https://github.com/pd0mz/go-maidenhead * License : Expat Programming Lang: Go Description : Maidenhead Locator system in Golang Maidenhead Locator system in Golang For packaging pat (#877030) -- Taowa Munene-Tardif taowa.ca Montréal
Re: trends.debian.net updated [request for additional groups/plots…inc. salvaged pkgs]
Hi Jonas and -devel, Jonas Smedegaard writes: > Quoting Mattia Rizzolo (2020-04-11 17:20:48) >> On Sat, Apr 11, 2020 at 11:10:48AM +0200, Wouter Verhelst wrote: >> > On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote: >> > > https://trends.debian.net/ was just updated (with data until April 1st). >> > >> > There is a significant bump in the number of co-maintained packages >> > during the buster release cycle. It is not at all clear to me what >> > happened there. >> > >> > Do you have any idea? >> >> My assumption is that the deprecation of alioth lead many "team" formed >> by 1 or 2 people to be replaced by simply comaintained packages. >> That, together with the the @packages.d.o maintainer address, I reckon >> those might also be considered "comaintained" instead of "team >> maintained". > > The introduction of the Salsa "debian" area - with its accompanying > explicit rules of being more team-ish than the similar area in Alioth - > was indeed a game changer for many packages which I had previously > maintained in smaller teams. I guess (and hope) that's the case for > others too. Not sure how, but it might be possible to check that thoery > if possible to gather statistics of how many packages was in the Alioth > debian area compared to the Salsa debian area. > If possible, I would also be interested in seeing the following plots on the Co-maintenance chart: 1. team-maintained 2. co-maintained Alioth collab-maint -> co-maintained salsa "debian" * shared plot 3. not co-maintained collab-maint -> not co-maintained "debian" * shared plot 4. co-maintained not in collab-maint nor "debian" group * shared plot 5. not co-maintained and not in collab-maint nor "debian" group That said, it seems like it might be potentially unkind and group-thinky to say that bus_factor=1 AND not in the "debian" group is a "smell"...since there are people who prefer to work alone...nonetheless, I'm curious how many of these packages exist! Possibly OT: it would also be cool to gather BTS stats for ITSs, and in particular it would be cool to see the rate of salvaging packages, and to see how many are going to teams, to "debian", and to somewhere else. We're coming up on two years of the existence of salvaging, so it feels like it might be a good time to do this. Cheers, Nicholas signature.asc Description: PGP signature
