Bug#1070718: ITP: python-gfloat -- Python module of generic floating point encode/decode logic

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-gfloat
  Version : 0.1
  Upstream Contact: Andrew Fitzgibbon 
* URL : https://github.com/graphcore-research/gfloat
* License : Expat
  Programming Lang: Python
  Description : Python module of generic floating point encode/decode logic

 An implementation of generic floating point encode/decode logic, handling
 various current and proposed floating point types:
 .
   - IEEE 754: Binary16, Binary32
   - OCP Float8: E5M2, E4M3
   - IEEE WG P3109: P{p} for p in 1..7
   - OCP MX Formats: E2M1, M2M3, E3M2, E8M0, INT8, and the MX block formats.
 .
 The library favours readability and extensibility over speed - for fast
 implementations of these datatypes see, for example, ml_dtypes, bitstring, MX
 PyTorch Emulation Library.

I intend to maintain this as part of the Debian Python Team.  It's
needed to run tests for the newest version of python-bitstring.

Scott K

Bug#1063348: O: pdfkit

[Scott Kitterman]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: affects -1 src:pdfkit

I am no longer interested in this package and no else in the Debian
Python Team expressed interest it taking it over, so orphaning.

The package itself is in reasonable shape.  Upstream includes the
following warning in the Git version of the package README:

This library has been deprecated to match the wkhtmltopdf project status.

Scott K

Bug#1063317: O: django-anymail

[Scott Kitterman]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: affects -1 src:django-anymail

I'm no longer interested in the package and no one from the Debian
Python Team expressed interest in it, so orphaning.

I've updated the package to the current upstream and updated for the
switch to hatchling, so that package is in good shape for now.  Upstream
is moderately active.

Scott K

Bug#1063171: O: python-sparkpost

[Scott Kitterman]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: affects -1 src:python-sparkpost

I'm no longer interested in the package (it was only packaged to support
django-anymail, which is also about to be orphaned).

This is an interface to a proprietary mail service.  The company was
acquired in 2021 and nothing has happened with the package upstream
since then.

The package itself is in reasonably good condition.  There is one Python
3.12 related issue that will be addressed in the upload that orphans the
package.

Scott K

Bug#1063033: O: django-wkhtmltopdf

[Scott Kitterman]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: affects -1 src:django-wkhtmltopdf

I no longer use this package and no one in the Debian Python Team
expressed any interest in it, so orphaning.

At this time, the package is in reasonably good shape and does not
generally require a lot of attention.  It's not clear if upstream is
dead or moving slowly.

Scott K

Bug#1061447: O: django-maintenancemode

[Scott Kitterman]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: affects -1 src:django-maintenancemode

Orphaning the package on behalf of the Debian Python Team as the sole
uploader (no one else on the team expressed interest in taking over and
I no longer use the package).

The package itself is in reasonable shape.  Upstream is mostly dean, so
if you take over this package, expect to have to do more than just
package new upstream releases.

Scott K

Bug#1060463: O: django-impersonate -- Django module for superusers to impersonate accounts

[Scott Kitterman]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: affects -1 src:django-impersonate

Orphaning the package on behalf of the Debian Python Team as the sole
uploader (no one else on the team expressed interest in taking over and
I no longer use the package).

Currently the package is in good shape.  There is a new upstream release
available, which I will include in the upload that changes the maintainer to
Debian QA Group.

Scott K

Bug#1060406: O: django-organizations -- Django groups and multi-user account management module

[Scott Kitterman]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: affects -1 src:django-organizations

Orphaning the package on behalf of the Debian Python Team as the sole
uploader (no one else on the team expressed interest in taking over and
I no longer use the package).

Currently the package is in good shape.  There is a new upstream release
available, which I will probably include in the upload that changes the
maintainer to Debian QA Group.

Scott K

Bug#1053215: ITP: needrestart-gui -- web interface for needrestart

[Scott Kitterman]

On September 29, 2023 11:57:52 AM UTC, Thomas Goirand  wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Thomas Goirand 
>X-Debbugs-Cc: debian-de...@lists.debian.org
>
>* Package name: needrestart-gui
>  Version : 0.0.1
>  Upstream Contact: Axel Jacquet 
>* URL : 
>https://salsa.debian.org/openstack-team/third-party/needrestart-gui
>* License : most-permissive
>  Programming Lang: Python
>  Description : web interface for needrestart
>
> This package provides a Python implementation to monitor services and provides
> a GUI to show their status and package versions. It uses in the background the
> needrestart package.
>
Is this for any service that needs restart or just for Openstack services?  If 
it's the latter (and glancing at the code, it seems it might be) then that 
ought to be in the package description.

Scott K

Bug#1030835: ITP: ruff -- linter for Python, written in Rust

[Scott Kitterman]

On Wed, 08 Feb 2023 01:00:19 + James Addison  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: James Addison 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: ruff
>   Version : 0.0.243
>   Upstream Contact: Charlie Marsh
> * URL : https://github.com/charliermarsh/ruff/
> * License : MIT
>   Programming Lang: Rust
>   Description : linter for Python, written in Rust
> 
> Ruff is a linter for Python that includes implementations of many common
> checks implemented by flake8, flake8 plugins, and pylint.

It appears the original reporter is no longer active in Debian (Salsa account 
deactivated), so converting to RFP.  It would be nice to see this, but I do 
not intend to package it.

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#1042541: ITP: libmozilla-publicsuffix-perl -- Perl interface to the Mozilla Public Suffix List

[Scott Kitterman]

On July 31, 2023 2:30:33 PM UTC, gregor herrmann  wrote:
>On Sun, 30 Jul 2023 14:47:28 +0200, gregor herrmann wrote:
>
>> So in the end I guess we need to patch lib/Mozilla/PublicSuffix.pm to
>> read /usr/share/publicsuffix/effective_tld_names.dat dynamically …
>
>Done (in git) now.
>
>Thanks again for pointing me in the right direction :)
>
Sounds great.  Approximately all language environments have or will soon have 
an interface to the PSL.  Many of the issues are common across the different 
language implementations.  Glad I could help.

Scott K

Bug#1042541: ITP: libmozilla-publicsuffix-perl -- Perl interface to the Mozilla Public Suffix List

[Scott Kitterman]

On July 30, 2023 2:30:29 AM UTC, gregor herrmann  wrote:
>On Sun, 30 Jul 2023 02:06:03 +0000, Scott Kitterman wrote:
>
>> Debian provides a system PSL in the publicsuffix package. Please
>> depend on and use that rather than the bundled copy or the facility
>> the package provides for downloading a newer version.
>
>Thanks for the pointer.
>
>I'm now build-depending on publicsuffix and copying effective_tld_names.dat
>from the publicsuffix package over the shipped version in
>override_dh_auto_configure.
>(The perl bindings in /usr/share/perl5/Mozilla/PublicSuffix.pm are
>generated from effective_tld_names.dat at configure time.)

The publicsuffix package is often updated.  If you do it that way, you won't 
get the new version without rebuilding the package.  I'd suggest using Depends 
and installing a symlink to the file it provides, so you always get the current 
version's data.

Scott K

Bug#1042541: ITP: libmozilla-publicsuffix-perl -- Perl interface to the Mozilla Public Suffix List

[Scott Kitterman]

Debian provides a system PSL in the publicsuffix package.  Please depend on and 
use that rather than the bundled copy or the facility the package provides for 
downloading a newer version.

Scott K

Bug#1040556: ITP: aioquic -- Library for the QUIC network protocol in Python

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: aioquic
  Version : 0.9.21
  Upstream Author : Jeremy Lainé 
* URL : https://github.com/aiortc/aioquic
* License : BSD 3-Clause
  Programming Lang: Python
  Description : Library for the QUIC network protocol in Python

 Library for the QUIC network protocol in Python. It features a minimal TLS
 1.3 implementation, a QUIC stack and an HTTP/3 stack.
 .
 QUIC was standardised in RFC 9000 and HTTP/3 in RFC 9114. aioquic is
 regularly tested for interoperability against other QUIC implementations.

This is needed as a dependency for dnspython to support DoQ (DNS over
QUIC).

I intend to maintain this in the Debian Python Team

Bug#1040553: ITP: pylsqpack -- Python wrapper around the ls-qpack library

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: pylsqpack
  Version :  0.3.17
  Upstream Author : Jeremy Lainé 
* URL : https://github.com/aiortc/pylsqpack
* License : BSD 3-Clause
  Programming Lang: Python
  Description : Python wrapper around the ls-qpack library

 Wrapper around the ls-qpack library. It provides Python Decoder and Encoder
 objects to read or write HTTP/3 headers compressed with QPACK.

This is a dependency for aioquic, which is needed to support DoQ (DNS
over QUIC) in dnspython.

I intend to maintain this in the Debian Python Team

Bug#1040552: RFP: ls-qpack -- QPACK compression library for use with HTTP/3

[Scott Kitterman]

Package: wnpp
Severity: wishlist

* Package name: ls-qpack
  Version : 2.5.3
  Upstream Author : LiteSpeed Tech 
* URL : https://github.com/litespeedtech/ls-qpack
* License : MIT
  Programming Lang: C
  Description : QPACK compression library for use with HTTP/3

 Full-featured, tested, and fast QPACK library. The QPACK encoder produces
 excellent compression results based on an innovative mnemonic technique.
 It boasts the fastest Huffman encoder and decoder.
 .
 QPACK is the compression mechanism used by HTTP/3 to compress HTTP headers.
 It is in the process of being standardazed by the QUIC Working Group. The
 QPACK Internet-Draft is has been stable for some time and we don't expect
 functional changes to it before the final RFC is released.

dnspython uses the Python bindings for this library to support DoQ (DNS
over QUIC), which are distributed separately as pylsqpack.  I plan to
package pylsqpack, but I'm not up for maintaining another shared C
library, so it would be awesome if someone who is interested in HTTP/3
more generally might pick this up.

Scott K

Bug#1037250: ITP: fangfrisch -- Update and verify unofficial Clam Anti-Virus signatures

[Scott Kitterman]

On Saturday, June 10, 2023 2:49:29 AM EDT Paul Wise wrote:
> On Fri, 2023-06-09 at 12:46 +0200, Gürkan Myczko wrote:
> >Description : Update and verify unofficial Clam Anti-Virus
> > signatures This is a sibling of the Clam Anti-Virus freshclam utility. It
> > allows downloading virus definition files that are not official ClamAV
> > canon, e.g. from Sanesecurity, URLhaus and others.
> 
> I was under the impression that ClamAV itself now has options to
> download unofficial signatures, is that the case or was that removed?

It does, but I think Fangfrisch is still a useful thing to have in Debian.

Scott K


signature.asc
Description: This is a digitally signed message part.

Bug#1028467: ITP: borgbackup2 -- version 2.x of a deduplicating and compressing backup program

[Scott Kitterman]

On January 17, 2023 2:39:32 PM UTC, Helmut Grohne  wrote:
>Hi Jonathan,
>
>Thanks for your review.
>
>On Tue, Jan 17, 2023 at 02:12:10PM +, Jonathan Dowland wrote:
>> I'm not sure that alternatives is appropriate, if the commands are not
>> interchangeable. And they are not: if you have 1 & 2 installed on a
>> host, and have used one to create some backups, trying to use the other
>> could be disastrous, and mixing them up a very real possibility if
>> either could concretely own "borg". IMHO, borg1 got that name and should
>> keep it, and borg2 should exclusively use a different command name, even
>> though that makes us significantly divergent from upstream.
>
>I agree that alternatives are not 100% appropriate for this situation,
>but I think that it is a good trade-off.
>
>The chances or destroying your backups are fairly minimal. Practically,
>things will mostly stop working due to unknown options and commands.
>
>I think that before too long, people want to get rid of borg 1.x and
>forget about it. Keeping the 2 suffix is just making it painful down the
>road. As such, I want a way that allows us to drop it eventually.
>
>>From my point of view, there are three relevant scenarios:
>
>1. A borg server. Such a system wants both borg 1.x and borg 2.x
>   available to allow users to transitions their repositories when
>   they're ready. Users should be advised to set BORG_REMOTE_PATH to
>   something other than "borg" in this case.
>
>2. New users installing borg 2.x for the first time. We really want them
>   not to experience the transition cost. They should be able to use
>   borg as if there never was borg 1.x.
>
>3. Users upgrading from borg 1.x. Here, we want to decouple the borg
>   upgrade from the dist-upgrade. To do this, users will have to install
>   borg 2.x (not necessarily concurrently), transfer their repositories
>   and adapt a few command lines.
>
>Only in scenario 1 where the suffix is unavoidable and also being used
>by major borg providers such as rsync.net, borgbase or hetzner, we don't
>want to deal with suffixes.
>
>And with that I arrive at update-alternatives being the best available
>compromise. Do more people disagree with this plan?

It's not policy compliant, which may be okay in this instance, but it certainly 
isn't ideal.

Here's another approach:

Borg 1 gets a new binary, borg-is-borg1 that provides usr/bin/borg symlinked to 
borg1.  The existing package depends on it for Bookworm, so it's guaranteed to 
be installed.

The new borg2 package has a borg-is-borg2 binary which provides usr/bin/borg 
pointing to borg2.  These two packages conflict, so that only one usr/bin/borg 
provider can be installed.

After Bookworm is released, borg1/borg2 can recommend their usr/bin/borg 
provider and the user can pick.

Once borg1 is removed, the extra packages can be dropped too.

This might be a little more work and needs a trip through new, but I think it's 
policy compliant and a little lower risk.

Scott K

Bug#1026017: ITP: designate-tlds -- Designate TLDs population

[Scott Kitterman]

On December 13, 2022 10:01:13 AM UTC, Thomas Goirand  wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Thomas Goirand 
>X-Debbugs-Cc: debian-de...@lists.debian.org
>
>* Package name: designate-tlds
>  Version : 0.0.1
>  Upstream Author : Axel Jacquet 
>* URL : 
>https://salsa.debian.org/openstack-team/services/designate-tlds
>* License : Apache-2.0
>  Programming Lang: Python
>  Description : Designate TLDs population
>
>Designate provides DNSaaS services for OpenStack. It provides a multi-tenant
>REST API for domain & record management. It is Integrated with Keystone for
>authentication, and provides a framework in place to integrate with Nova and
>Neutron notifications (for auto-generated records). Designate supports
>PowerDNS and Bind9 out of the box.
>
>This package fill-up the Designate database with the global TLDs list
>downloaded from Mozilla.


Debian provides a system version of the PSL in the public suffix package.  When 
you package this, please depend on publicsuffix and use that system copy of the 
data instead of downloading it directly.

Scott K

Bug#1024660: ITP: ranges -- Command line program to extract ranges from various types of lists, e.g. integer numbers, dates, IP and MAC addresses.

[Scott Kitterman]

On Tuesday, November 22, 2022 2:32:11 PM EST Sandro-Alessio Gierens wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sandro-Alessio Gierens 
> 
> * Package name: ranges
>   Version : 1.0.0
>   Upstream Author : Sandro-Alessio Gierens 
> * URL : https://github.com/gierens/ranges
> * License : GPLv3
>   Programming Lang: C
>   Description : Command line program to extract ranges from various
> types of lists, e.g. integer numbers, dates, IP and MAC addresses.
> 
> ranges is a command line program written in C that extracts ranges from
> various types of lists. By default it parses signed decimal integer
> lists, but given the right argument it can work with unsigned
> hexadecimal, octal and binary numbers, dates, IPv4, IPv6 and MAC
> addresses. The list input is given over the standard input, so by pipe,
> and is assumed to be sorted, but can have duplicates.
> 
> Relevance
> 
> I work in a data center and recently had the problem that I needed to
> find out which IP addresses of a subnet were not yet assigned in
> a /etc/hosts file. Because there were already too many addresses to
> get a good overview, I began to wonder if there was any command line
> tool that would allow me to compile the list of IPs into a list of
> IP ranges, so the gaps and their size would be obvious. Unfortunately
> I only found stack overflow discussions suggesting writing a script,
> and this is what I did to back then too. While this usually doesn't
> take more than a couple of minutes, ranges has too advantages:
> It already implements a bunch of different list types including
> nasty things like dates for example, and therefore would spare
> people from replementing such scripts over and over again. Aside
> from that it is written in C and therefore fast. According to my
> tests it is, depending on the machine, 20 to 40 times faster than
> a comparable Python3 script. It can crunch 130 MB of IPv4 addresses
> in a second.
> 
> Eventhough I just published the initial release I've been working on
> this for a couple of weeks now and extensively checked that it is
> stable and secure. My test suite consists of 185 tests that verify
> the correct functionality of each mode and argument. Each test is
> first run without and then with valgrind memcheck, so there should
> not be any leaks or other memory errors.
> 
> Maintainance
> 
> As the upstream author of the software I would also maintain the
> package. This would be my first package, but I already have a make
> rules to build a deb package and check it with lintian, so I'm
> not unprepared :)

The package name is very generic.  I would pick something more specific.  Also, 
I suspect the speed advantage would be less significant if you used SubnetTree 
(python3-subnettree), which does all the hard work in C.  Is this really 
needed?

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#1021964: ITP: python-noseofyeti -- Module to create Python codec for tests using RSpec inspired DSL

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-noseofyeti
  Version : 2.3.1
  Upstream Author : Stephen Moore
* URL : https://github.com/delfick/nose-of-yeti
* License : MIT
  Programming Lang: Python
  Description : Module to create Python codec for tests using RSpec 
inspired DSL

 This is a project creates a custom Python codec that lets you write your
 tests using an RSpec inspired DSL (i.e. describe and it blocks).
 .
 It uses the fact that you can register a codec that is able to modify a
 Python file before executing it.  Using this when Python imports a file with
 a particular encoding as the first line of the file it will be intercepted
 and potentially rewritten into something else before the import continues.
 .
 nose-of-yeti uses this technique to translate from the DSL it defines, into
 Python classes and functions that then will be executed by your test
 framework of choice.

I plan to maintain this package as part of the Debian Python team.

It is needed to run the tests for python-dict2xml, which are now
provided in the upstream tarball.

Bug#916202: ITP: golang-github-mmarkdown-mmark -- Mmark: a powerful markdown processor in Go geared towards the IETF

[Scott Kitterman]

On Sun, 10 Nov 2019 23:22:21 -0700 Anthony Fok  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Anthony Fok 
> X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
> 
> * Package name: golang-github-mmarkdown-mmark
>   Version : 2.2.0-1
>   Upstream Author : Miek Gieben
> * URL : https://github.com/mmarkdown/mmark
> * License : BSD-2-Clause
>   Programming Lang: Go
>   Description : Mmark: a powerful markdown processor in Go geared 
towards the IETF
> 
> Rationale: There has been interests to see Mmark v2.0.0 packaged.

It would be really great to see this in Debian.  The defaults have changed 
between the older version last in Debian and the current package, so I'm 
running into problems using the old Debian version with Makefiles people are 
writing based on the current defaults.

Thanks for considering,

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#1004434: ITP: python-rangehttpserver -- SimpleHTTPServer with support for Range requests

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: python-rangehttpserver
  Version : 1.2.0
  Upstream Author : Dan Vanderkam 
* URL : https://github.com/danvk/RangeHTTPServer
* License : Apache 2.0
  Programming Lang: Python
  Description : SimpleHTTPServer with support for Range requests

 RangeHTTPServer is a Python module for running a simple HTTP server with
 support for range requests.  It is suitable for use in local testing, not
 Internet scale production use.
 .
 HTTP range requests ask the server to send only a portion of an HTTP message
 back to a client and are useful for clients like media players that support
 random access, data tools that know they need only part of a large file, and
 download managers that let the user pause and resume the download.

I will maintain this in the Debian Python Team.

It is required to make the serve option in clamav-cvdupdate work
(currently disabled until this gets in).  Also, it looks like there is
an embedded copy in python3-asdf, so perhaps it could be updated to use
a system version.

Bug#1004404: ITP: cvdupdate -- ClamAV Private Database Mirror Updater Tool

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: clamav-cvdupdate
  Version : 1.0.2
  Upstream Author : The Clamav Team 
* URL : https://github.com/Cisco-Talos/cvdupdate
* License : Apache 2.0
  Programming Lang: Python
  Description : ClamAV Private Database Mirror Updater Tool

 cvdupdate downloads the latest ClamAV databases along with the latest
 database patch files.
 .
 Run this tool as often as you like, but it will only download new content if
 there is new content to download. If you somehow manage to download too
 frequently (eg: by using cvd clean all and cvd update repeatedly), then the
 official database server may refuse your download request, and one or more
 databases may go on cool-down until it's safe to try again.
 .
 This replaces the clamdownloader.pl script formerly provided on clamav.net.

This is the upstream clamav official tool for maintaining a private
clamav data mirror, which users with a non-trivial number of
installations will need to do.  We should provide this in Debian.

Although implemented in Python, it's primary purpose is as an executable
tool, so I will maintain this in the ClamAV Team.

Bug#1000675: ITP: python-tomli-w -- lil' TOML witer for Python

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: python-tomli-w
  Version : 0.4.0
  Upstream Author : Taneli Hukkinen
* URL : https://github.com/hukkin/tomli-w
* License : Expat
  Programming Lang: Python
  Description : lil' TOML witer for Python

 Tomli-w is a Python library for writing TOML. https://toml.io/
 Tomli-w is fully compatible with TOML v1.0.0. https://toml.io/en/v1.0.0

I intend to maintain this within the Debian Python Team.

It's needed to update flit to the current version.

Scott K

Bug#961292: ITP: python-commentjson -- module for json that supports comments

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: python-commentjson
  Version : 0.8.3
  Upstream Author : Vaidik Kapoor <https://vaidik.in/>
* URL : https://pypi.org/project/commentjson
* License : Expat
  Programming Lang: Python
  Description : module for json that supports comments

 Comment JSON is a Python package that helps you create JSON files with Python
 and JavaScript style inline comments. Its API is very similar to the Python
 standard library's json module.
 .
 This is the Python 3 version of the package.

I intend to maintain this in DPMT.  It is needed to run tests for the
recently packaged python3-resolvelib package.

Scott K

Bug#961158: ITP: distlib -- Java library of statistical distribution functions

[Scott Kitterman]

On Thursday, May 21, 2020 12:08:44 AM EDT Andreas Tille wrote:
> Hi,
> 
> On Wed, May 20, 2020 at 04:30:47PM -0400, Scott Kitterman wrote:
> > On Wednesday, May 20, 2020 4:23:41 PM EDT Pierre Gruet wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Debian-med project 
> > > 
> > > * Package name: distlib
> > > 
> > >   Version : 0.9.1
> > >   Upstream Author : Peter N. Steinmetz
> > > 
> > > * URL : https://sourceforge.net/projects/statdistlib
> > > ...
> > > This package will be taken care of in Debian-med team, where it is
> > > needed as a dependency of SnpEff.
> 
> Very cool!  Pierre, thanks a lot!
> 
> > "distlib" is a very generic name.  Could the package be named java-distlib
> > or some other more specific term?
> 
> At least the name of the binary package should be
> 
> libdistlib-java
> 
> Choosing the same name for the source package as the binary package is
> frequently done.

That would certainly resolve my concern.

Thanks,

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#961158: ITP: distlib -- Java library of statistical distribution functions

[Scott Kitterman]

On Wednesday, May 20, 2020 4:23:41 PM EDT Pierre Gruet wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Debian-med project 
> 
> * Package name: distlib
>   Version : 0.9.1
>   Upstream Author : Peter N. Steinmetz
> * URL : https://sourceforge.net/projects/statdistlib
> * License : GPL-2
>   Programming Lang: Java
>   Description : Java library of statistical distribution functions
> 
> This is a library written in Java, providing probability density function,
> cumulative distribution function, quantiles and random variate generation
> for several common statistical distributions.
> 
> This package will be taken care of in Debian-med team, where it is needed as
> a dependency of SnpEff.

"distlib" is a very generic name.  Could the package be named java-distlib or 
some other more specific term?

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#959797: ITP: python-tomlkit -- style-preserving TOML library for Python

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: python-tomlkit
  Version : 0.6.0
  Upstream Author : Sébastien Eustace 
* URL : https://pypi.org/project/tomlkit
* License : Expat
  Programming Lang: Python
  Description : style-preserving TOML library for Python


TOML Kit is a 1.0.0rc1-compliant TOML (Tom's Obvious, Minimal Language)
library.
.
It includes a parser that preserves all comments, indentations, whitespace and
internal element ordering, and makes them accessible and editable via an
intuitive API.
.
You can also create new TOML documents from scratch using the provided
helpers.

I intend to maintain this package in the DPMT.

Upstream Python is moving to use of TOML in package configuration files.
There are three major TOML implementations used by various tools.  This
is the only one not in Debian.  It is the most feature complete (it is
the only one that can round trip TOML that includes comments) and will
be needed for packaging Python development tools.

Scott K

Bug#959397: ITP: python-resolvelib -- module to resolve abstract dependencies into concrete ones

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: python-resolvelib
  Version : 0.3.0
  Upstream Author : Tzu-ping Chung 
* URL : https://github.com/sarugaku/resolvelib
* License : ISC
  Programming Lang: Python
  Description : module to resolve abstract dependencies into concrete ones

 python3-resolvelib provides a `Resolver` class that includes dependency
 resolution logic. You give it some things, and a little information on how it
 should interact with them, and it will spit out a resolution result.

This is a new dependency for the next version of python-pip (upstream
vendors it, but does support unvendored packages which this will
provide).  It is used to support pip's new dependency resolver (not used
by default, yet).

This package will be maintained in the DPMT.

Scott K

Bug#956184: RFP: python3-sphinx-better-theme -- modified version of the default Sphinx theme

[Scott Kitterman]

Package: wnpp
Severity: wishlist

* Package name: python3-sphinx-better-theme
  Version : 0.1.5
  Upstream Author : Steve Johnson 
* URL : https://pypi.org/project/sphinx-better-theme
* License : Expat
  Programming Lang: Python
  Description : modified version of the default Sphinx theme

This theme is now used by psycopg2 for its documentation, so it would be
nice to see it in Debian so we could use it (instead of patching to use
the default Sphinx Theme.

 sphinx-better-theme is an update to the default Sphinx theme with the
 following goals:
 .
  - Remove frivolous colors, especially hard-coded ones
  - Improve readability by limiting width and using more whitespace
  - Encourage visual customization through CSS, not themeconf
Use semantic markup

Bug#953992: ITP: python-flit -- simple way to put Python packages and modules on PyPI

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: flit
  Version : 2.2.0
  Upstream Author : Thomas Kluyver 
* URL : https://github.com/takluyver/flit
* License : BSD 3-clause license
  Programming Lang: Python
  Description : simple way to put Python packages and modules on PyPI

Flit is a simple way to put Python packages and modules on PyPI. It tries to
require less thought about packaging and help you avoid common mistakes.
.
Flit supports PEP 517 Python packaging.
.
Make the easy things easy and the hard things possible is an old motto from
the Perl community. Flit is entirely focused on the easy things part of that,
and leaves the hard things up to other tools.
.
Specifically, the easy things are pure Python packages with no build steps
(neither compiling C code, nor bundling Javascript, etc.). The vast majority
of packages on PyPI are like this: plain Python code, with maybe some static
data files like icons included.

I intend to maintain this in PAPT (Python Applications Packaging Team).

PEP 517 style packages are becoming more common and while flit does
generate a setup.py file for non-PEP 517 build system use, it is not
particularly satisfying.  I'm motivated to package this after having had
to patch such a package to make it build complete metadata.  Debian will
be better off if we can use the upstream tools.

Upstream provides a good discussion of why flit in addition to other
Python oriented build tools:

https://flit.readthedocs.io/en/latest/rationale.html

Flit does use flit to build, but it includes a bootstrap script so it
can build itself without in archive bootstrapping.

Bug#953523: ITP: filetype.py -- Small module to infer binary file types via signature

[Scott Kitterman]

It's ok.  Python policy only addresses binary package name.

Scott K

Bug#953523: ITP: filetype.py -- Small module to infer binary file types via signature

[Scott Kitterman]

Based on the module name and Python policy, the binary package name should be 
python3-filetype.  That appears to be available.  I'd suggest using that as the 
source package name too to make your life easier.

Scott K

Bug#949796: ITP: python-publicsuffix2 -- Python3 module to get a domain suffix using the Public Suffix List

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: python-publicsuffix2
  Version : 2.20191221
  Upstream Author : nexB Inc. 
* URL : https://pypi.python.org/pypi/publicsuffix2
* License : Expat
  Programming Lang: Python,
  Description : Python3 module to get a domain suffix using the Public 
Suffix List

 This Python3 module allows you to get the public suffix of a domain name
 using the Public Suffix List from http://publicsuffix.org.
 .
 A public suffix is one under which Internet users can directly register
 names. Some examples of public suffixes are .com, .co.uk and pvt.k12.wy.us.
 Accurately knowing the public suffix of a domain is useful when handling
 web browser cookies, highlighting the most important part of a domain name
 in a user interface or sorting URLs by web site.
 .
 This module replaces the deprecated python3-publicsuffix package.

Upstream for python-publicsuffix recently published a new upstream
release recommending it not be used anymore.  This is one of the
recommended replacements.  Generally porting to the new lib is trivial
(changing imports from publicsuffix to publicsuffix2).

I maintain one of the two rdepends for python-publicsuffix in Debian and
I have already tested this replacement with it.

The package will be maintained in DPMT.

Scott K

Bug#949784: ITP: pep517 -- Specifies a standard API for systems which build Python packages

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: pep517
  Version : 0.7.0
  Upstream Author : Thomas Kluyver 
* URL : https://pypi.org/project/pep517/
* License : Expat
  Programming Lang: Python
  Description : Specifies a standard API for systems which build Python 
packages

 This package contains wrappers around the hooks specified by PEP 517. It
 provides:
 .
  - A mechanism to call the hooks in a subprocess, so they are isolated from
the current process.
  - Fallbacks for the optional hooks, so that frontends can call the hooks 
without
checking which are defined.
  - Higher-level functions which install the build dependencies into a
temporary environment and build a wheel/sdist using them.
 .
 This is the Python 3 version of the package.

 This is needed as a dependency for newer version of Python's pip.  It
 will be maintained in the DPMT.  There is a newer version available,
 but 0.7.0 is the version pip specifies as a requirement, so I intend to
 match that as there are no other users.  This is part of Debian's
 effort to not use vendored modules that upstream pip uses.

Scott K

Bug#948237: ITP: dnstwist -- domain name permutation engine

[Scott Kitterman]

On Sunday, January 12, 2020 6:50:09 AM EST Peter Wienemann wrote:
> Hi Scott,
> 
> On 05.01.20 21:17, Scott Kitterman wrote:
> > Upstream contains an embedded copy of the Public Suffix List (PSL):
> > 
> > https://github.com/elceef/dnstwist/blob/master/database/effective_tld_name
> > s.dat
> > 
> > In Debian, this is provided in the publicsuffix package:
> > 
> > https://salsa.debian.org/debian/publicsuffix/blob/debian/master/public_suf
> > fix_list.dat
> > 
> > Although renamed, it's the same file.  Please use the PSL from
> > publicsuffix rather than the embedded copy.  It'll be more up to date.
> thanks for your hint. I wasn't aware of this.
> 
> I guess the same holds for the GeoIP.dat file which seems to be provided
> by the geoip-database package in Debian.

Yes.  I'd forgotten about that one myself.

Glad to help.  It's things like this that are the reason that all ITPs get 
cc'ed to the d-devel mailing list.

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#948237: ITP: dnstwist -- domain name permutation engine

[Scott Kitterman]

On January 5, 2020 7:22:08 PM UTC, Peter Wienemann  wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Peter Wienemann 
>
>  Package name: dnstwist
>  Version : 20190706
>  Upstream Author : Marcin Ulikowski 
>  URL : https://github.com/elceef/dnstwist
>  License : Apache-2.0
>  Programming Lang: Python
>  Description : Domain name permutation engine
>
>For a given domain name, dnstwist generates a list of similarly
>looking domains and performs DNS queries for each of them (A, ,
>NS and MX). For MX records it checks whether there is an active mail
>server which could intercept misdirected emails. Moreover it
>estimates webpage similarity based on fuzzy hashes. This functionality
>might be helpful in discovering typosquatters, phishing sites or
>otherwise fraudulent services and corporate espionage.
>
>This package will be team-maintained by the Debian Security Tools
>Team.

Upstream contains an embedded copy of the Public Suffix List (PSL):

https://github.com/elceef/dnstwist/blob/master/database/effective_tld_names.dat

In Debian, this is provided in the publicsuffix package:

https://salsa.debian.org/debian/publicsuffix/blob/debian/master/public_suffix_list.dat

Although renamed, it's the same file.  Please use the PSL from publicsuffix 
rather than the embedded copy.  It'll be more up to date.

Scott K

Bug#935864: ITP: python-dict2xml -- module to output xml as a string from a python dictionary

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: python-dict2xml
  Version : 1.6
  Upstream Author : Stephen Moore 
* URL : https://pypi.org/project/dict2xml/
* License : MIT
  Programming Lang: Python
  Description : Utility module to convert a python dictionary to an xml 
string

 Super Simple utility to convert a python dictionary into an xml string.

This is a dependency of the latest version of xml2rfc.  I will only
package this for python3.

I intend to maintain this package as part of DPMT.

Scott K

Bug#922628: ITP: dt -- DNS tool - display information about your domain

[Scott Kitterman]

On February 18, 2019 3:52:55 PM UTC, "Antoine Beaupré"  
wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Antoine Beaupré 
>
>* Package name: dt
>  Version : 0.0.9
>  Upstream Author : Wim
>* URL : https://github.com/42wim/dt
>* License : Apache-2.0
>  Programming Lang: Go
>  Description : DNS tool - display information about your domain
>
> dt a DNS tool that displays information about your domain.
> .
> Features
> • common records scanning (use -scan)
> • validate DNSSEC chain (use -debug to see more info)
> • change query speed for scanning (default 10 queries per second)
> * diagnostic of your domain (similar to intodns.com, dnsspy.io)
> 
>
>
>This is a great tool. I worked on packaging a similar tool (dnsdiag,
>#824670) for Debian, but it stopped where dt begun:
>
>https://github.com/farrokhi/dnsdiag/issues/16
>
>So I would love to see this in Debian. As usual, I would co-maintain
>this in the golang team.

This is an incredibly generic package name.  Please pick something more 
descriptive.

Scott K

Bug#916331: O: libopendbx

[Scott Kitterman]

Package: wnpp
Severity: normal

Neither of the current uploaders have time/interest in continuing to work on
this package (in my case, I've just orphaned the rdepend that led me to
package it in the first place).

This package does not take alot of maintenance.  Upstream is either dead or
sleeping very deeply.  The most common task is dealing with symbols file
updates when g++ changes.

Maintaining this package does require a knowledge of library packaging in
general and C++ symbols files specifically (the package uses the pkgkde-
symbolshelper as there's really no other sane way to do it).

Scott K

Bug#900774: O: opendkim

[Scott Kitterman]

Updating to orphan the package, fundamentally I've lost motivation on this 
package.  I still think it's important, but I don't have the time/priority for 
it.  I should also have mentioned there is a shared library, so you have to 
know how to do shared library packaging.

> opendkim is the major open source C implementation of the DKIM (Domain Keys
> Identified Mail) protocol (see RFC 6376).  I believe it is important that it
> be in Debian and well maintained, but I am no longer using it, so my ability
> to test things and my motivation are not what they were.
> 
> The opendkim upstream effort is not dead, but a bit intermittent and slow.
> There is a single upstream developer who is quite busy and so loses focus on
> this project and then periodically jumps back in.
> 
> The project recently moved from Source Forge to GitHub and there is a new
> Beta that needs packaging.
> 
> Some understanding of DKIM is important to maintaining this package, but I
> do not think you need to be a protocol expert.  I am willing to provide
> advice and some assistance to a new maintainer (because I think opendkim is
> important to be in Debian and well maintained), so you won't be entirely on
> your own.

Scott K

Bug#914658: ITP: authheaders -- Python library for the generation of email authentication headers

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: authheaders
  Version : 0.10.0
  Upstream Author : Valimail Inc 
* URL : https://github.com/ValiMail/authentication-headers
* License : BSD like, ZPL 2.1, MPL 2.0
  Programming Lang: Python
  Description : Python library for the generation of email authentication 
headers

 Authheaders can generate both authentication results header fields and DKIM/
 ARC sighatures.  It can perform DKIM, SPF, and DMARC validation, and the
 results are packaged into a single Authentication-Results header.  It can
 also DKIM and ARC sign messages and output the corresponding signature
 headers fields.

It supports both python2.7 and python3 (tested with python3.6 and 3.7).

I intend to maintail it within the Debian Python Modules Team.

I am packaging this as a dependency for another project I expect to upload
relatively shortly.

Bug#913543: RFP: i3-py -- tools for i3 users and developers

[Scott Kitterman]

It's had no upstream commits in over 6 years.  Is it really suitable for 
introduction into Debian?

Also, it's not clear it works with a modern Python 3.  I'd also check if it 
does before considering it suitable.

New guess is if you package this, you'll end up effectively being upstream.  I 
wouldn't upload it unless you are prepared for this.

Scott K

Bug#902010: ITP: krop -- tool to crop PDF files

[Scott Kitterman]

Excellent.  Thanks,

Scott K

Bug#902010: ITP: krop -- tool to crop PDF files

[Scott Kitterman]

On June 21, 2018 1:01:48 PM UTC, Alex Mestiashvili  
wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Alex Mestiashvili 
>X-Debbugs-Cc: ames...@rsh2.donotuse.de, debian-de...@lists.debian.org
>
>* Package name: krop
>  Version : 0.5.0
>  Upstream Author : Armin Straub 
>* URL : https://github.com/arminstraub/krop
>* License : GPLv3+
>  Programming Lang: Python 3
>  Description : tool to crop PDF files
>
> simple graphical tool to crop the pages of PDF files. It is written
> in Python and relies on PyQT, python-poppler-qt4 and pyPDF for its
> functionality.

Please wait for the PyQt5 port.

We want to remove PyQt4 from the archive in Buster in support of Qt4 removal.  
We would prefer not to add new rdepends.

Scott K

Bug#900774: RFA: opendkim

[Scott Kitterman]

Package: wnpp
Severity: normal

opendkim is the major open source C implementation of the DKIM (Domain Keys
Identified Mail) protocol (see RFC 6376).  I believe it is important that it
be in Debian and well maintained, but I am no longer using it, so my ability
to test things and my motivation are not what they were.

The opendkim upstream effort is not dead, but a bit intermittent and slow.
There is a single upstream developer who is quite busy and so loses focus on
this project and then periodically jumps back in.

The project recently moved from Source Forge to GitHub and there is a new Beta
that needs packaging.  I may or may not get that done anytime soon.

Some understanding of DKIM is important to maintaining this package, but I do
not think you need to be a protocol expert.  I am willing to provide advice
and some assistance to a new maintainer (because I think opendkim is
important to be in Debian and well maintained), so you won't be entirely on
your own.

Scott K

Bug#892740: ITP: dkimpy-milter -- Python milter implementation of DomainKeys Identified Mail (DKIM)

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: dkimpy-milter
  Version : 0.9.5.1
  Upstream Author : Scott Kitterman <sc...@kitterman.com>
* URL : https://launchpad.net/dkimpy-milter
* License : GPL
  Programming Lang: Python
  Description : Python milter implementation of DomainKeys Identified Mail 
(DKIM)

 The dkimpy-milter is a Sendmail/Postfix Milter application that signs
 and verifies DKIM (DomainKeys Identified Mail).  It supports both traditional
 RSA (RFC 6376) signatures and the new ed25519 based signatures being
 developed by the IETF DCRUP (DKIM Crypto UPgrade) Working Group.
 .
 DKIM provides a way for senders to confirm their identity when sending email
 by adding a cryptographic signature to the headers of the message.
 .
 It uses the OpenDKIM configuration option naming and definitions, for the
 options it implements, to make it easy for OpenDKIM users to experiment with
 this alternative.

The primary alternative, which I also maintain, is opendkim.  Upstream isn't
dead, but it appears to be on life support.  I wrote this as an alternative so
I would have something modern and supported.  Currently it is the only DKIM
option for Postfix/Sendmail that supports ed25519 (there's also an unreleased
Exim implementation that this has been tested with to verify
interoperability).

Yes, it's python2.7, but the milter bindings it uses, python-milter, are not
yet avaialble for python3.  When they are, it'll be ported.

I plan to maintain this within the Python Applications Packaging Team.

Bug#887813: O: storm

[Scott Kitterman]

Package: wnpp
Severity: normal

There are no human maintainers/uploaders left for storm, so I orphan the
package.

Bug#885030: ITP: libnitrokey -- library to communicate with Nitrokey stick devices

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <sc...@kitterman.com>

* Package name: libnitrokey
  Version : 3.1
  Upstream Author : Nitrokey Team <i...@nitrokey.com>
* URL : https://github.com/Nitrokey/libnitrokey
* License : LGPL3
  Programming Lang: C++
  Description : library to communicate with Nitrokey stick devices

 library to communicate with Nitrokey Pro and Storage devices in a clean and
 easy manner. Written in C++14, testable with py.test and Catch frameworks,
 with C API, Python access.

 Needed for the newest version of nitrokey-app as well as other Nitrokey
 related software.

 If there is interest, I anticipate setting up a Nitrokey related team and
 maintaining this within that team.

Bug#869483: ITP: python3-ansi -- ANSI cursor movement and graphics

[Scott Kitterman]

On July 23, 2017 12:22:20 PM EDT, Muri Nicanor <m...@immerda.ch> wrote:
>hi,
>
>On 07/23/2017 05:31 PM, Scott Kitterman wrote:
>> 
>> 
>> On July 23, 2017 11:07:47 AM EDT, Muri Nicanor <m...@immerda.ch>
>wrote:
>[...]
>>> - this is a dependency of errbot (see #803347)
>>> - i plan to build the initial package myself and then get
>>>  in contact with the python team for RFS and joining or
>>>  handing over the package
>> 
>> Every package needs a human uploader.
>which can not be me, i'm not a DM

Uploader in this context (as opposed to Maintainer in debian/control) means 
roughly assist maintainer, not literally person that uploads the package. Sorry 
for not being clear.

>> There is no 'handing over'.
>sorry for me not being a native speaker, my wording was off, i didn't
>mean to offend anyone

Not a problem. No offense taken.

>> It looks like this would be reasonable to maintain as part of DPMT,
>but if you don't plan to keep it updated, don't upload it.
>i plan to keep it updated
>
>cheers,
>muri

Great.

Scott K

Bug#869483: ITP: python3-ansi -- ANSI cursor movement and graphics

[Scott Kitterman]

On July 23, 2017 11:07:47 AM EDT, Muri Nicanor  wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Muri Nicanor 
>
>* Package name: python3-ansi
>  Version : 0.1.3
>  Upstream Author : Wijnand Modderman-Lenstra 
>* URL : https://pypi.python.org/pypi/ansi
>* License : Expat
>  Programming Lang: Python
>  Description : ANSI cursor movement and graphics
>
>Various ANSI escape codes, used in moving the cursor in a text console
>or rendering coloured text.
>
>- this is a dependency of errbot (see #803347)
>- i plan to build the initial package myself and then get
>  in contact with the python team for RFS and joining or
>  handing over the package

Every package needs a human uploader.  There is no 'handing over'.  It looks 
like this would be reasonable to maintain as part of DPMT, but if you don't 
plan to keep it updated, don't upload it.

Scott K

Bug#868665: ITP: python-asgiref -- ASGI in-memory channel layer

[Scott Kitterman]

On Monday, July 17, 2017 01:43:44 PM Michael Fladischer wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Michael Fladischer 
> 
> * Package name: python-asgiref
>   Version : 1.1.2
>   Upstream Author : Django Software Foundation
>  * URL :
> https://github.com/django/asgiref/
> * License : BSD-3-clause
>   Programming Lang: Python
>   Description : ASGI in-memory channel layer
> 
>  Contains various reference ASGI implementations, including:
>  .
>   * A base channel layer, asgiref.base_layer
>   * An in-memory channel layer, asgiref.inmemory
>   * WSGI-to-ASGI and ASGI-to-WSGI adapters, in asgiref.wsgi

Please spell out ASGI somewhere in the long description.

Scott K

Bug#856672: ITP: python-dnslib -- A module to encode/decode DNS wire-format packets

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: python-dnslib
  Version : 0.9.7+hg20170303
  Upstream Author : Paul Chakravarti <paul.chakrava...@gmail.com>
* URL : https://bitbucket.org/paulc/dnslib
* License : BSD-2
  Programming Lang: Python
  Description : A module to encode/decode DNS wire-format packets

 This DNS encode/decode Python module provides:
 .
  - Support for encoding/decoding DNS packets between wire format, python
objects, and Zone/DiG textual representation (dnslib.dns)
  - A server framework allowing the simple creation of custom DNS resolvers
(dnslib.server) and a number of example servers created using this
framework
  - A number of utilities for testing (dnslib.client, dnslib.proxy,
dnslib.intercept)

In the future this will be a build-depenedency for dkimpy and probably other
packages that need to do DNS queries as part of their test suite.

Packaging an hg snapshot because the most recent release is missing license
and copyright information needed to make it suitable for Debian.

Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Scott Kitterman]

On Monday, January 16, 2017 05:37:45 PM Andreas Tille wrote:
> On Mon, Jan 16, 2017 at 11:44:45AM +0100, Andreas Tille wrote:
> > > I think the package name should indicate the field for which it is
> > > meant (freebayes-genetic-variance),
> > 
> > At least its good to know that ftpmaster is reading here to not accept
> > previously uploaded package wis unchanged name. ;-)
> > 
> > I'm fine with changing that one and will ask on Debian Med name whether
> > above suggestion sounds good.
> 
> When discussing the issue with a Debian Med sprint member I've got other
> good reasons to even keep the package name despite the fact that its
> quite generic.  When looking outside the Debian box other distributions
> might package the same software at best under the original name since
> they are not that picky about generic names and at worst under different
> names which would add more confusion than a less generic name might
> avoid.
> 
> Furthermore there is some effort called bio.tools[1] (members of this
> effort regularly joining Debian Med sprints) who are very keen on all
> the metadata that are assembled with Debian packages and can be easily
> fetched from UDD.  They consider taking the Debian Source package name
> as a key in their database.  While I'm personally not convinced that
> this is the best idea we probably should not artificially diverge from
> names that would be expceted by potential consumers of our data.
> 
> Finally when doing a websearch for freebayes the said project is the
> first hit which might be a further arguent to stick to the name that was
> choosen by upstream.

OK.  Would you at least discuss it with upstream?

Scott K

Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Scott Kitterman]

On January 15, 2017 12:35:57 PM EST, Andreas Tille <andr...@an3as.eu> wrote:
>Hi Scott,
>
>On Sun, Jan 15, 2017 at 04:34:40PM +, Scott Kitterman wrote:
>> >I fully agree with your generic name consideration.  The software is
>> >well known in this work field anyway so I'm hesitating a bit to
>rename
>> >it.  Would you consider this a strong issue that needs to be
>discussed
>> >with upstream or is it in a "not nice but acceptable" status?
>> 
>> I think it should be discussed with upstream, but we have broader
>namespace considerations that they may not understand or care about.
>
>Definitely.
> 
>> As long as a package search for freebayes returns this in the result
>set, I don't think it's critical to have the package name match exactly
>the upstream name.
>
>Do you care only about the *package* name or do you care as well about
>the name binary /usr/bin/freebayes?

I think they are both important.

Scott K

>> Not wearing my FTP team hat for this, consider it as a comment from
>another DD.
>
>Both is welcome.
>
>Kind regards
>
> Andreas.

Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Scott Kitterman]

On January 15, 2017 7:32:32 AM EST, Andreas Tille <ti...@debian.org> wrote:
>Hi Scott,
>
>On Fri, Jan 13, 2017 at 04:09:01PM -0500, Scott Kitterman wrote:
>> 
>> "freebayes" seems like a very generic name for something specific to
>such a 
>> narrow field.  Maybe freebayes-genetic-variance or some such instead.
>
>I fully agree with your generic name consideration.  The software is
>well known in this work field anyway so I'm hesitating a bit to rename
>it.  Would you consider this a strong issue that needs to be discussed
>with upstream or is it in a "not nice but acceptable" status?

I think it should be discussed with upstream, but we have broader namespace 
considerations that they may not understand or care about.

As long as a package search for freebayes returns this in the result set, I 
don't think it's critical to have the package name match exactly the upstream 
name.

Not wearing my FTP team hat for this, consider it as a comment from another DD.

Scott K

Bug#711388: ITP: scandir -- Better directory iterator that returns all file info the OS provides

[Scott Kitterman]

On January 14, 2017 6:32:07 AM EST, Julien Puydt  
wrote:
>Control: retitle -1 ITP: scandir -- Better directory iterator that
>returns all file info the OS provides
>
>I would like to package python-scandir, as newer versions of
>python-pathlib2 now depend on it.
>
>As I don't want to add new deps to the python-pathlib2 package now,
>I'll
>work in several steps :
>- close this ITP bug by packaging scandir ;
>- leave things as-is until stretch is out ;
>- get newer python-pathlib2 out with a depend on python-scandir (thus
>closing #851137).
>
>For reference, that is a backport of the scandir in Python 3 ; I know
>it's a wishlist item to stop packaging Python 2 modules, but since it's
>a new dep of an existing one, I think it still makes sense.

Scandir is pretty generic.  I'd suggest python-scandir or similar for the 
package name.

Scott K

Bug#849083: ITP: libmail-rbl-perl -- Perform queries to blacklists

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <sc...@kitterman.com>

* Package name: libmail-rbl-perl
  Version : 1.04
  Upstream Author : Luis E. Muñoz <luismu...@cpan.org>
* URL : http://search.cpan.org/dist/Mail-RBL/
* License : Artistic
  Programming Lang: Perl
  Description : Perl extension to access RBL-style host verification 
services

 Mail::RBL eases the task of checking if a given host is in the list. The
 methods available are described below:
 .
 - new(suffix, resolver): Creates a list handle
 - check($host): either a hostname or an IP address
 - check_rhsbl($host): queries RHSBLs instead of IP-based lists, useful for 
   using lists such as some of http://www.rfc-ignorant.org/

This is intended to be maintained in the Debian Perl Group.

Although not recently updated, it seems to do what it needs to do.  This is
required as a dependency for mt-policyd, which I'm also working on getting
into Debian (See #783067 for information on that).

Bug#849050: ITP: python-graphviz -- Simple Python 3 interface for Graphviz

[Scott Kitterman]

On December 22, 2016 2:33:23 AM EST, Diane Trout  wrote:
>
>> This naming would be unacceptable. Python 3 package should be named
>> as 
>> "python3-foobar", not "python-foobar".
>> 
>> There are already packages called "python{,3}-pygraphviz" and you may
>> want to 
>> take a look.
>
>The upstream source package name is graphviz and is hosted on pypi at 
>https://pypi.python.org/pypi/graphviz
>
>Obviously that conflicts with the original C language package grapvhiz,
>so I thought python-graphviz was the best alternative. I'm open to
>other suggestions. pypi-graphviz? 
>
>The binary package name would be python3-graphviz.
>
>And yes there is a pygraphviz, but that's a different package with a
>different API.
>
>But yes it is a bit silly there's so many different python graphviz
>apis.
>
>I'm guessing the reason the dask developers used the pypi graphviz is
>its pure python, unlike pygraphviz which is a C extension. But I'm not
>sure, I just tried to use the task visulaization and got an import
>error.
>
>dask uses the python graphviz library to generate plots like in this
>notebook.
>https://gist.github.com/mrocklin/b61f795004ec0a70e43de350e453e97e
>
>Diane

I think your original proposal is fine for the source package.

Scott K

Bug#845923: ITP: django-impersonate -- Django application to allow superusers to impersonate other accounts

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: django-impersonate
  Version : 1.1~a0+hg20161126
  Upstream Author : Peter Sanchez <petersanc...@gmail.com>
* URL : http://bitbucket.org/petersanchez/django-impersonate/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Django application to allow superusers to impersonate 
accounts

 Simple Django application to allow superusers to "impersonate" other
 non-superuser accounts.

I intend to maintain this in the Debian Python Modules Team.  The initial
upload is an unreleased snapshot since there is not a Django 1.10 compatible
final release yet.  I am expecting one well before the freeze.

Bug#845805: ITP: django-hstore -- Module for Django that integrates the PostgreSQL hstore extension

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: django-hstore
  Version : 1.5~alpha~git20161126
  Upstream Author : Djangonauts Organization <django-hst...@googlegroups.com>
* URL : https://github.com/djangonauts/django-hstore
* License : MIT/Expat
  Programming Lang: Python
  Description : Module for Django that integrates the PostgreSQL hstore 
extension

 django-hstore is a niche library which integrates the hstore extension of
 PostgreSQL into Django.
 .
 HStore brings the power of NoSQL key/value stores into PostgreSQL, giving us
 the advantage of flexibility and performance without renouncing to the
 robustness of SQL databases.
 .
 Features
 .
   * Postgis compatibility.
   * Nice admin widgets.
   * Possibility to define a schema and use the standard django fields

I intend to maintain this in the Debian Python Modules Team.

I'm uploading a git snapshot as the most recent release is not compatible
with Django 1.10.  I expect a final release well before our freeze.

Bug#845466: ITP: chargebee2-python -- Python library for integrating with Chargebee (API v2)

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: chargebee2-python
  Version : 2.1.9
  Upstream Author : ChargeBee <supp...@chargebee.com>
* URL : https://github.com/chargebee/chargebee-python
* License : MIT/Expat
  Programming Lang: Python
  Description : Python library for integrating with Chargebee (API v2)

 The python library for integrating with Chargebee Recurring Billing and
 Subscription Management solution.
 .
 Chargebee now supports two API versions - V1 and V2. This library is for the
 newer API version V2.
 .
 This package conflicts with chargebee-python which provides the V1 API in
 the same python module namespace.

Although licensed under a free license, this is only useful to integrate with
proprietary web services, so I intend to upload this to contrib.

I intend to maintain this with the Debian Python Modules Team.

The chargebee-python package mentioned above is in New and is similarly in
contrib.  I have reviewed policy 7.4 and concluded that in this case,
Conflicts is the best approach.

Bug#845454: ITP: chargebee-python -- python library for integrating with Chargebee (API v1)

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: chargebee-python
  Version : 1.6.3
  Upstream Author : ChargeBee <supp...@chargebee.com>
* URL : 
https://github.com/chargebee/chargebee-python/tree/chargebee-v1
* License : MIT/Expat
  Programming Lang: Python
  Description : python library for integrating with Chargebee (API v1)

 The python library for integrating with Chargebee Recurring Billing and
 Subscription Management solution.
 .
 Chargebee now supports two API versions - V1 and V2. This library is for the
 older API version V1.
 .
 This package conflicts with chargebee2-python which provides the V2 API in
 the same python module namespace.

Although licensed under a free license, this is only useful to integrate with
proprietary web services, so I intend to upload this to contrib.

I intend to maintain this with the Debian Python Modules Team.

The chargebee2-python package mentioned above will follow shortly and
similarly be in contrib.  I have reviewed policy 7.4 and concluded that in
this case, Conflicts is the best approach.

Bug#844675: ITP: django-anymail -- Django email backend for Mailgun, Postmark, SendGrid, SparkPost and more

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: django-anymail
  Version : 0.6.1
  Upstream Author : Mike Edmunds <medmu...@gmail.com>
* URL : https://github.com/anymail/django-anymail
* License : BSD 3 clause
  Programming Lang: Python
  Description : Django email backend for Mailgun, Postmark, SendGrid, 
SparkPost and more

 Anymail integrates several transactional email service providers (ESPs) into
 Django, with a consistent API that lets you use ESP-added features without
 locking your code to a particular ESP.
 .
 It currently fully supports Mailgun, Postmark, SendGrid, and SparkPost, and
 has limited support for Mandrill.
 .
 Anymail normalizes ESP functionality so it "just works" with Django's
 built-in `django.core.mail` package. It includes:
 .
   * Support for HTML, attachments, extra headers, and other features of
 `Django's built-in email
   * Extensions that make it easy to use extra ESP functionality, like tags,
 metadata, and tracking, with code that's portable between ESPs
   * Simplified inline images for HTML email
   * Normalized sent-message status and tracking notification, by connecting
 your ESP's webhooks to Django signals
   * "Batch transactional" sends using your ESP's merge and template features

Since this package only serves to connect to non-free services, I intend to
upload it to contrib.

I intend to maintain it in Debian Python Modules Team

Bug#844582: ITP: python-sparkpost -- Super-mega-official Python package for using the SparkPost API

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: python-sparkpost
  Version : 1.3.2
  Upstream Author : SparkPost <develop...@sparkpost.com>
* URL : https://github.com/SparkPost/python-sparkpost
* License : Apache 2.0
  Programming Lang: Python
  Description : SparkPost Python API client

 Super-mega-official Python package for using the SparkPost API.
 .
 Python and Python-Django integration with SparkPost's email transmission
 API.

This package is needed to run tests for Anymail:

 https://pypi.python.org/pypi/django-anymail/0.6.1

which I also intend to package.

Since this package is only useful to interact with SparkPost's proprietary
system, I plan to upload it to Contrib.

I plan to maintain this within the Debian Python Modules Team.

Bug#844471: ITP: pdfkit -- Python wrapper for wkhtmltopdf to convert HTML to PDF using Webkit

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: pdfkit
  Version : 0.5.0
  Upstream Author : Golovanov Stanislav <stgolova...@gmail.com>
* URL : https://github.com/JazzCore/python-pdfkit
* License : MIT/Expat
  Programming Lang: Python
  Description : Python wrapper for wkhtmltopdf to convert HTML to PDF using 
Webkit

 Python 2 and 3 wrapper for wkhtmltopdf utility to convert HTML to PDF using
 Webkit.
 .
 Wkhtmltopdf conversion and all wkhtmltopdf options are available in Python
 from this module

I intend to maintain this within the Debian Python Modules Team.

Bug#843934: ITP: django-redis-sessions -- Redis database backend for your sessions

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: django-redis-sessions
  Version : 0.5.6
  Upstream Author : Martin Rusev <mar...@amon.cx>
* URL : http://github.com/martinrusev/django-redis-sessions
* License : BSD
  Programming Lang: Python
  Description : Redis database backend for your Django sessions

 Session backend for Django that stores sessions in a Redis database 

I intend to maintain this within the Debian Python Modules Team.

Bug#843924: ITP: django-wkhtmltopdf -- Django module that provides views to wrap HTML to PDF conversions

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: django-wkhtmltopdf
  Version : 3.1.0
  Upstream Author : Incuna Ltd <ad...@incuna.com>
* URL : https://github.com/incuna/django-wkhtmltopdf
* License : MIT/Expat
  Programming Lang: Python
  Description : Django module that provides views to wrap HTML to PDF 
conversions

 Django Wkhtmltopdf provides Django views to wrap the HTML to PDF conversion
 of the `wkhtmltopdf <http://wkhtmltopdf.org>`_ binary.

I intend to maintain this in the Debian Python Modules Team

Upstream did neglect to include the LICENSE file in the tarball (it's in git).
I already sent them a pull request to fix it and I'll add it locally for now.

Bug#843915: ITP: django-organizations -- Django groups and multi-user account management module

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: django-organizations
  Version : 0.8.2
  Upstream Author : Ben Lopatin <b...@wellfire.co>
* URL : https://github.com/bennylope/django-organizations/
* License : BSD
  Programming Lang: Python
  Description : Django groups and multi-user account management module

 Django Organizations adds user-managed, multi-user groups to your Django
 project. Use Django Organizations whether your site needs organizations that
 function like social groups or multi-user account objects to provide account
 and subscription functionality beyond the individual user.
 .
   * Works with your existing user model, whether
  `  django.contrib.auth` or a custom model. No additional user
 or authentication functionality required.
   * Users can be belong to and own more than one organization (account, group)
   * Invitation and registration functionality works out of the box for many
 situations and can be extended as need to fit specific requirements.
   * Start with the base models or use your own for greater customization.

I intend to maintain this package in the Debian Python Modules Team

Bug#843889: ITP: django-maintenancemode -- django application that allows setting a site as down for maintenance (503)

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <deb...@kitterman.com>

* Package name: django-maintenancemode
  Version : 0.11.2
  Upstream Author : Remco Wendt <re...@maykinmedia.nl>
* URL : http://github.com/shanx/django-maintenancemode
* License : BSD
  Programming Lang: Python
  Description : django application that allows setting a site as down for 
maintenance (503)

 django-maintenancemode is a middleware that allows you to temporarily
 shutdown your site for maintenance work.
.
 Logged in users having staff credentials can still fully use the site as can
 users visiting the site from an IP address defined in Django's
 ``INTERNAL_IPS``.

I intend to maintain this withing the Debian Python Modules Team.

Bug#831456: ITP: policyd-rate-limit -- postfix policy daemon limiting the number of mails a user can send

[Scott Kitterman]

On Monday, July 18, 2016 08:34:33 PM Valentin Samir wrote:
> Le lundi 18 juillet 2016 à 01:57 -0400, Scott Kitterman a écrit :
> > I did take a quick look at the package.  One comment I'd make right
> > away is to 
> > be more verbose in your initial changelog entry, particularly explain
> > what the 
> > patch that's included is there for.
> > I don't do much sponsoring outside of a team context, but if you were
> > willing 
> > to maintain the package in PAPT, I would be willing to sponsor it.  
> > 
> > I also took a quick look at the upstream code since I'm also upstream
> > for a 
> > Python based policy server.  I noticed you're using netaddr.  The
> > ipaddress 
> > module included in python since 3.3 will easily do what you're using
> > netaddr 
> > for and would get rid of an external dependency.
> > 
> > Let me know if you're interested in PAPT.  If so, we'll go from
> > there.
> 
> I update upstream to use ipaddress according to your recommendations.
> I also added a phrase to explain the purpose of the patch to the
> changelog, tell me if it's enougth (updated package is on https://mento
> rs.debian.net/package/policyd-rate-limit).
> 
> I am interested in PAPT for maintaining the package. Should I join the
> team ? Could you instruct me what I have to do for that.

Now that you are in the team, I've added the package to the team SVN 
repository and will review it.  If you do IRC, please join #debian-python on 
OFTC.

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#832086: ITP: vrfydmn -- Milter for ensuring email message from matches mail from

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <sc...@kitterman.com>

* Package name: vrfydmn
  Version : 0.7.1
  Upstream Author : Christian Rößner <c...@roessner-network-solutions.com>
* URL : https://github.com/croessner/vrfydmn
* License : GPL 3+
  Programming Lang: Python
  Description : Milter for ensuring email message from matches mail from

 This milter is used with postfix or sendmail to either reject mail from/body
 from mismatches or to fix up the body from to match mail from.  This is
 intended for applications where local constraints on domains in use are
 required for sending mail.

 This package makes use of the python-milter bindings for the Sendmail
 libmilter.  I intend to maintain this with the Python Applications Packaging
 Team (PAPT).

Bug#831456: ITP: policyd-rate-limit -- postfix policy daemon limiting the number of mails a user can send

[Scott Kitterman]

On Monday, July 18, 2016 08:34:33 PM Valentin Samir wrote:
> Le lundi 18 juillet 2016 à 01:57 -0400, Scott Kitterman a écrit :
> > I did take a quick look at the package.  One comment I'd make right
> > away is to 
> > be more verbose in your initial changelog entry, particularly explain
> > what the 
> > patch that's included is there for.
> > I don't do much sponsoring outside of a team context, but if you were
> > willing 
> > to maintain the package in PAPT, I would be willing to sponsor it.  
> > 
> > I also took a quick look at the upstream code since I'm also upstream
> > for a 
> > Python based policy server.  I noticed you're using netaddr.  The
> > ipaddress 
> > module included in python since 3.3 will easily do what you're using
> > netaddr 
> > for and would get rid of an external dependency.
> > 
> > Let me know if you're interested in PAPT.  If so, we'll go from
> > there.
> 
> I update upstream to use ipaddress according to your recommendations.
> I also added a phrase to explain the purpose of the patch to the
> changelog, tell me if it's enougth (updated package is on https://mento
> rs.debian.net/package/policyd-rate-limit).
> 
> I am interested in PAPT for maintaining the package. Should I join the
> team ? Could you instruct me what I have to do for that.

Great,

Please see https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#831456: ITP: policyd-rate-limit -- postfix policy daemon limiting the number of mails a user can send

[Scott Kitterman]

On Sunday, July 17, 2016 10:34:56 PM Valentin Samir wrote:
> Le samedi 16 juillet 2016 à 13:11 -0400, Scott Kitterman a écrit :
> > I looked and did not see this on mentors.d.n, so maybe you have found
> > a 
> > sponsor already, but I thought I would mention the Debian Python
> > Applications 
> > Packaging Team (PAPT) [1] to you as a team that would be suitable for
> > this 
> > package.  It is generally easy to get sponsorship for team packages.
> 
> Thanks for looking,
> My package was locked in the upload queue on mentors.d.n. I receive the
> confirmation email just this morning 5:26 UTC.
> 
> It is now well available on https://mentors.debian.net/package/policyd-> 
> rate-limit, sorry for the delay.

I did take a quick look at the package.  One comment I'd make right away is to 
be more verbose in your initial changelog entry, particularly explain what the 
patch that's included is there for.

I don't do much sponsoring outside of a team context, but if you were willing 
to maintain the package in PAPT, I would be willing to sponsor it.  

I also took a quick look at the upstream code since I'm also upstream for a 
Python based policy server.  I noticed you're using netaddr.  The ipaddress 
module included in python since 3.3 will easily do what you're using netaddr 
for and would get rid of an external dependency.

Let me know if you're interested in PAPT.  If so, we'll go from there.

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#829630: O: pythonqt

[Scott Kitterman]

On Monday, July 04, 2016 10:08:47 PM Andreas Tille wrote:
> Package: wnpp
> Severity: normal
> 
> Hi,
> 
> the package pythonqt was once a dependency of a Debian Med package but
> this was removed.  Now pythonqt has no rdepends any more and is hard to
> maintain since it needs Qt4.  May be its the best to remove the package
> at all from Debian.  If anybody (may be Debian Python) might like to
> take over the package that's perfectly fine.
> 
> Currently the packaging remains in Debian Med SVN
> 
> svn://anonscm.debian.org/debian-med/trunk/packages/pythonqt/trunk/
> 
> I tried to convert it to Git but svn2git failed and I gave up since
> spending more time into the package does not sound sensible to me.

Removal sounds best to me.

Scott K

Bug#821301: ITP: backports-abc -- backport of "collections.abc" for Python 2

[Scott Kitterman]

On April 17, 2016 9:14:57 AM EDT, Julien Puydt <julien.pu...@laposte.net> wrote:
>Hi,
>
>On 17/04/2016 14:56, Scott Kitterman wrote:
>>
>>
>> On April 17, 2016 8:49:53 AM EDT, Julien Puydt
><julien.pu...@laposte.net> wrote:
>>> Package: wnpp
>>> Severity: wishlist
>>> X-Debbugs-CC: debian-de...@lists.debian.org
>>>
>>> * Package name: backports-abc
>>>Version : 0.4
>>>Upstream author : Stefan Bahnel et al.
>>> * URL : https://github.com/cython/backports_abc
>>> * License : Python-2.0
>>>Programming Lang: Python 2
>>>Description : Backport of the "collections.abc" stdlib module
>>>   This is a backport to Python 2 of recent additions to the
>>>   "collections.abc" in Python 3.5.
>>>
>>> It is a dep of newer versions of tornado, a sagemath dep.
>>>
>>> Cheers,
>>>
>>> Snark on #debian-python
>>
>> collections-abc is a very generic name.  I would suggest calling the
>source package python-collections-abc so it's not so generic.  That's
>what you'll end up calling the binary package anyway.
>>
>> Scott K
>
>The source package would be "backports-abc" and the binary package
>would 
>be "python-backports-abc".
>
>Would that do?


My suggestion is python-backports-abc for source and binary since backports-abc 
is such a generic name.

Scott K

Bug#821301: ITP: backports-abc -- backport of "collections.abc" for Python 2

[Scott Kitterman]

On April 17, 2016 8:49:53 AM EDT, Julien Puydt  wrote:
>Package: wnpp
>Severity: wishlist
>X-Debbugs-CC: debian-de...@lists.debian.org
>
>* Package name: backports-abc
>   Version : 0.4
>   Upstream author : Stefan Bahnel et al.
>* URL : https://github.com/cython/backports_abc
>* License : Python-2.0
>   Programming Lang: Python 2
>   Description : Backport of the "collections.abc" stdlib module
>  This is a backport to Python 2 of recent additions to the
>  "collections.abc" in Python 3.5.
>
>It is a dep of newer versions of tornado, a sagemath dep.
>
>Cheers,
>
>Snark on #debian-python

collections-abc is a very generic name.  I would suggest calling the source 
package python-collections-abc so it's not so generic.  That's what you'll end 
up calling the binary package anyway.

Scott K

Bug#817056: ITP: python-typing -- Type Hints for Python

[Scott Kitterman]

On Monday, March 07, 2016 09:01:30 AM Michael R. Crusoe wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Debian Med team 
> 
> * Package name: python-typing
>   Version : 3.5.0.1
>   Upstream Author : Guido van Rossum, Jukka Lehtosalo, Łukasz Langa
>  * URL :
> https://docs.python.org/3.5/library/typing.html * License : Python
> 2.0
>   Programming Lang: Python
>   Description : Type Hints for Python
> 
>  This is a backport of the standard library typing module to Python
>  versions older than 3.5.
> 
>  Typing defines a standard notation for Python function and variable
>  type annotations. The notation can be used for documenting code in a
>  concise, standard format, and it has been designed to also be used by
>  static and runtime type checkers, static analyzers, IDEs and other
>  tools.
> 
> This is a new dependency for python-schema-salad, and will be for any other
> Py2/Py3 package that contains typing hints. It will be maintained by the
> Debian-Med team but I'm happy to hand it over to other interested parties.

Please only package this for python(2).  We are in the process of dropping 
python3.4, so a python3 package isn't needed.

Scott K

Bug#815532: ITP: topmenu-qt -- Topmenu for Qt applications

[Scott Kitterman]

On February 21, 2016 10:52:30 PM EST, Mike Gabriel 
 wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Mike Gabriel 
>
>* Package name: topmenu-qt
>  Version : 0.2.1
>  Upstream Author : Javier S. Pedro
>* URL :
>https://git.javispedro.com/cgit/topmenu-qt.git/about/
>* License : GPL, LGPL
>  Programming Lang: C++
>  Description : Topmenu for Qt applications
>
>Topmenu is a standalone global menu bar (MacOS style) implementation.
>TopMenu uses
> XEmbed for exporting menu bars.
> .
> This is package provides a module for Qt(4) applications.

Please reconsider packaging this until it's ported to Qt5.  Qt4 is unsupported 
upstream and we are doing our best to reduce depending on it.  The Qt-KDE team 
would, I'm sure, appreciate it if you'd wait.

Scott K

Bug#796550: ITP: sonic-pi -- a new kind of musical instrument : teach programming and music

[Scott Kitterman]

On Fri, 15 Jan 2016 14:59:30 +0100 Petter Reinholdtsen  
wrote:
> Here is a small update on sonic-pi in Debian.  The dependency
> supercollider-sc3-plugins is now in Debian.  The next set of
> needed dependencies are Ruby gems, and
> http://debian.fosscommunity.in/status/?appname=sonicpi > show the
> status for those.  At the moment 15 of 36 packages are missing in Debian.
> And probably some more, if those 15 depend on other packages.

I'm interested in seeing this in Debian as well.  Please feel free to let me 
know if you need any help with the Qt5/Qmake aspects of the package.  Please 
do build it with Qt5, not Qt4, because Qt4 is no longer supported by upstream 
(Qt) and we are trying to minimize dependence on it in Stretch.

Scott K

Bug#797021: ITP: midicsv -- translate MIDI file to CSV

[Scott Kitterman]

On Saturday, August 29, 2015 11:24:12 PM Santiago Vila wrote:
 On Sat, Aug 29, 2015 at 04:46:05PM -0400, Scott Kitterman wrote:
  Was there a previous ITP bug?
 
 Everything boils down to an ITP bug?

Yes.  This one of the reasons we have them.
 
 I think this clearly shows my intent to package it:
 
 https://people.debian.org/~sanvila/wip/
 
 (not touched it in several days)
 
 And it is too much coincidence. Compare the timestamps.

Having looked at the package as uploaded and compared it to yours on p.d.o, 
it's clear to me that the packaging is independent.  Next time, write an ITP.

As I said before, offer to co-maintain it.

Scott K

Bug#797021: ITP: midicsv -- translate MIDI file to CSV

[Scott Kitterman]

On August 29, 2015 4:13:28 PM EDT, Santiago Vila sanv...@unex.es wrote:
On Wed, Aug 26, 2015 at 04:42:02PM -0700, Kamal Mostafa wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Kamal Mostafa ka...@debian.org
 
 * Package name: midicsv
   Version : 1.1
   Upstream Author : John Walker @ http://www.fourmilab.ch/
 * URL : http://www.fourmilab.ch/webtools/midicsv/
 * License : public-domain
   Programming Lang: C
   Description : translate MIDI file to CSV
 
 Midicsv reads a standard MIDI file and decodes it into a CSV
 (Comma-Separated Value) file which preserves all the information in
the
 MIDI file.  The ASCII CSV file may be loaded into a spreadsheet or
database
 application, or processed by a program to transform the MIDI data
(for
 example, to key transpose a composition or extract a track from a
 multi-track sequence).  A CSV file in the format created by midicsv
may be
 converted back into a standard MIDI file with the csvmidi program.

I can't believe this is just a coincidence

What kind of strange package hijacking is this?

I had this package at people.debian.org and it was going to be the
first package of Víctor Cuadrado.

Puzzled.

Was there a previous ITP bug?

Scott K

Bug#791376: ITP: cycler -- composable style cycles

[Scott Kitterman]

On July 3, 2015 10:01:11 PM EDT, Sandro Tosi mo...@debian.org wrote:
Package: wnpp
Severity: wishlist
Owner: Sandro Tosi mo...@debian.org

* Package name: cycler
  Version : 0.9.0
  Upstream Author : Thomas A Caswell
* URL : http://github.com/matplotlib/cycler
* License : BSD
  Programming Lang: Python
  Description : composable style cycles

it will be a dep for matplotlib in a future release

Cycler seems pretty generic.  Since the binaries will be python{3}-cycler, 
perhaps python-cycler would be a better source package name?

Scott K


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ecd07e63-d68b-4cd5-a293-488e1fd20...@kitterman.com

Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Scott Kitterman]

On Thursday, May 14, 2015 06:55:40 AM Tristan Seligmann wrote:
 On 14 May 2015 at 06:04, Scott Kitterman deb...@kitterman.com wrote:
  Why can't python-cryptography use python-ipaddr that's already in the
  archive?
 cryptography is python2/3 dual-source. Carrying a Debian-specific
 patch[1] that introduces a slew of fallback imports to ipaddr, solely
 to avoid uploading a new package, seems like a poor choice to me.
 
 Having said that, I just whipped up a proof-of-concept patch that adds
 import ipaddr as ipaddress fallbacks everywhere, and the related
 tests seem to pass (I still have some failures due to missing
 python-idna[3], so I don't have a clean test run yet), so it appears
 that this would be feasible without major changes.
 
  There are only two very small API differences and when you introduce
  ipaddress in python2, it can break code that's designed to use ipaddr in
  python2 and ipaddress in python3 (I've run into this in projects where
  I'm upstream).
 That is unfortunate, but unless the ipaddress backport is
 API-incompatible in some way with the Python 3 stdlib version, surely
 this just a bug in that code?
 
 (Incidentally, I was initially under the impression that the APIs were
 completely incompatible, as the API docs are severely out of date[2],
 but the current version is much closer, as you describe)

Is this 100% compatible with ipaddress from upstream now?  The problem I ran 
into before is that when importing ipaddress and it turned out to be this one 
and not the upstream one, the API was different, so it didn't work.  
Introducing this in the archive would, based on that experience, cause 
breakage in other packages.  It's completely trivial to use ipaddr with 
python2 and ipaddress with python3 [1], so this backport seems pretty 
pointless to me.

Scott K

[1] 
https://skitterman.wordpress.com/2013/05/16/new-ipaddress-module-in-python3-3/

  It seems somewhat odd to me to take ipaddr that was developed for python2
  and integrated upstream as ipaddress in python3 and then backport it to
  python2 as ipaddress.
 
 Well, blame the CPython maintainers for their fondness of arbitrarily
 changing the API of modules they import into stdlib...
 
  Also, the listed copyright holder in the code is Google, not Philipp
  Hagemeister.
 Yes, the copyright holder is Google, the code was contributed to
 Python under the PSF license. (I didn't mean to imply otherwise, I
 just copy/pasted the info from PyPI into the wnpp template, apparently
 without paying enough attention to what I was doing)
 
 [1] I don't see why upstream should be interested in such a patch.
 
 [2] http://pythonhosted.org//ipaddr/ as linked to from
 https://pypi.python.org/pypi/ipaddr/
 
 [3] https://bugs.debian.org/756388


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/6219373.C9HMBIgtkC@kitterma-e6430

Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Scott Kitterman]

On Thursday, May 14, 2015 05:42:56 AM Tristan Seligmann wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Tristan Seligmann mithra...@mithrandi.net
 
 * Package name: python-ipaddress
   Version : 1.0.7
   Upstream Author : Philipp Hagemeister
 * URL : https://github.com/phihag/ipaddress
 * License : PSF
   Programming Lang: Python
   Description : Backport of the ipaddress module from Python 3.3
 
 This is a new dependency of python-cryptography. I intend to maintain the
 package in DPMT.

Why can't python-cryptography use python-ipaddr that's already in the archive?  
There are only two very small API differences and when you introduce ipaddress 
in python2, it can break code that's designed to use ipaddr in python2 and 
ipaddress in python3 (I've run into this in projects where I'm upstream).

It seems somewhat odd to me to take ipaddr that was developed for python2 and 
integrated upstream as ipaddress in python3 and then backport it to python2 as 
ipaddress.  Also, the listed copyright holder in the code is Google, not 
Philipp Hagemeister.

It would be better to find a way to avoid introducing this.

Scott K


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1750910.CzdGCmdZbk@kitterma-e6430

Bug#784172: ITP: kronometer -- stopwatch application for KDE

[Scott Kitterman]

On May 3, 2015 2:53:59 PM EDT, Joao Eriberto Mota Filho eribe...@debian.org 
wrote:
Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho eribe...@debian.org

* Package name: kronometer
  Version : 1.6.0
  Upstream Author : Elvis Angelaccio elvis.angelac...@kdemail.net
* URL : http://www.aelog.org/kronometer
* License : GPL-2+
  Description : stopwatch application for KDE

Kronometer is a stopwatch (timer/chronometer) application built for the
 K Desktop Environment.
 .
 Kronometer’s main features are the following:
   * Start/pause/resume the stopwatch widget;
   * Laps recording: you can capture the stopwatch time when you want;
  * Lap times sorting: you can easily find the shortest lap time or the
 longest one;
   * Reset the stopwatch widget and the lap times;
   * Time format settings: you can choose the stopwatch granularity;
* Times saving and resuming: you can save the stopwatch status on a
file
 and resume it later;
* Font customization: you can choose the fonts for each of the
stopwatch
 digits;
* Color customization: you can choose the color for the stopwatch
digits;
 and the stopwatch background
* Lap times export: you can export the lap times on a file using the
XML;
 or CSV format.

The Qt-KDE team is hoping to remove Qt4 and thus kde4libs during this cycle. I 
see there's a Kf5 branch upstream.  What would you think  about waiting until 
that's ready. 

Scott K


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/c61521fb-bd48-4f77-9784-46f24b516...@kitterman.com

Bug#783833: ITP: python-obitools -- set of programs specifically designed for analyzing NGS data in a DNA metabarcoding contex

[Scott Kitterman]

On Thursday, April 30, 2015 05:13:03 PM Olivier Sallou wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Olivier Sallou osal...@debian.org
 
 * Package name: python-obitools
   Version : 1.1.16
   Upstream Author : Eric Coissac
 * URL : http://metabarcoding.org//obitools/
 * License : CeCILL-V2
   Programming Lang: Python
   Description : set of programs specifically designed for analyzing NGS
 data in a DNA metabarcoding contex
 
 The OBITools package is a set of programs specifically designed for
 analyzing NGS data in a DNA metabarcoding context, taking into account
 taxonomic information. OBITools enrich the Unix command line interface with
 a set of new commands dedicated to NGS data processing. Most of them have a
 name starting with the obi prefix. They automatically recognize the input
 file format amongst most of the standard sequence file formats (i.e. fasta,
 fastq, EMBL, and GenBank formats). Nevertheless, options are available to
 enforce some format specificity such as the encoding system used in fastq
 files for quality codes. Most of the basic Unix commands have their
 OBITools equivalent (e.g. obihead vs head, obitail vs tail, obigrep vs
 grep), which is convenient for scientists familiar with Unix. The main
 difference between any standard Unix command and its OBITools counterpart
 is that the treatment unit is no longer the text line but the sequence
 record. As a sequence record is more complex than a single text line, the
 OBITools programs have many supplementary options compared to their Unix
 equivalents.

According to the trove information on pypi [1] this is python only, not 
python3.  We were hoping to not increase the amount of python packages needing 
porting to python3.  Have you discussed python3 plans with upstream?

Scott K

[1] https://pypi.python.org/pypi/OBITools/1.1.16


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21039320.xThH8BtM62@kitterma-e6430

Bug#781870: ITP: ply -- Python implementation of the common parsing tools lex and yacc

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman deb...@kitterman.com

* Package name: ply
  Version : 3.4
  Upstream Author : David M. Beazley (Dabeaz LLC)
* URL : http://www.dabeaz.com/ply/
* License : BSD
  Programming Lang: Python
  Description : Python implementation of the common parsing tools lex and 
yacc

 python-ply is a 100% Python implementation of the common parsing tools lex and
 yacc. Here are a few highlights:
 .
  * very closely modeled after traditional lex/yacc.
 .
  * provides *very* extensive error reporting and diagnostic information to
assist in parser construction.
 .
  * provides full support for empty productions, error recovery, precedence
specifiers, and moderately ambiguous grammars.
 .
  * based on LR-parsing which is fast, memory efficient, better suited to large
grammars, and has a number of nice properties when dealing with syntax
errors and other parsing problems. Builds its parsing tables using the LALR
algorithm used in yacc.
 .
  * uses Python introspection features to build lexers and parsers. This greatly
simplifies the task of parser construction since it reduces the number of
files and eliminates the need to run a separate lex/yacc tool before running
your program.
 .
  * can be used to build parsers for real programming languages. Athough not
ultra-fast due to its Python implementation, can be used to parse grammars
consisting of several hundred rules (as might be found for a language like
C). The lexer and LR parser are also reasonably efficient when parsing
typically sized programs.

The package will be maintained in the DPMT.  It is a dependency of another
package I plan to upload.  If anyone else is interested in this, please let me
know and I'll add you to uploaders.

It supports (and will be packaged for) both python and python3.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150404030638.28664.53293.reportbug@kitterma-E6430

Bug#777337: RFA: python-softlayer

[Scott Kitterman]

On Sat, 07 Feb 2015 14:45:09 + Alessio Treglia ales...@debian.org wrote:
 Package: wnpp
 Severity: normal
 
 Hi,
 
 due to the lack of time I'd ask for someone else to
 maintain python-softlayer.
 
 The package is in good shape and upstream is actively
 working on it. I'll still be available to sponsor
 uploads too.

Alessio and I discussed this offline and I'll maintain it in the DPMT.

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#768096: [Python-modules-team] python mysqldb on python 3

[Scott Kitterman]

On Tue, 18 Nov 2014 13:55:57 +1100 Brian May br...@microcomaustralia.com.au 
wrote:
 On 5 November 2014 12:11, Collin Anderson cmawebs...@gmail.com wrote:
 
   There might be a problem because it looks like it conflicts with
  python-mysqldb.
  Yes, it's a 100% compatible fork intended to replace python-mysqldb. Same
  python package name and everything. We could decide to only include it for
  python3, or we could even have this completely replace the original
  python-mysqldb on python2.
 
 
 I don't much like the idea of having different code base for python2 and
 python3 versions.
 
 My current plan (unless anyone objects) is to replace the python-mysqldb
 package with the mysqlclient package, keeping the existing python-mysqldb
 (which makes sense as the python module name is unchanged).
 
 My initial upload will be to experimental.
 
 (as time permits)

The current package is pretty widely used:

Reverse-Recommends
==
* bauble
* bley
* griffith
* papercut
* pwman3
* pyaimt
* pyicqt
* python-adodb
* python-authkit
* python-scrapy
* python-springpython
* python-sqlkit
* python-tornado
* python-webpy

Reverse-Depends
===
* auth2db
* bauble
* blogofile-converters
* djagios
* emma
* epigrass
* neutron-common
* openmolar
* python-biopython-sql
* python-ceilometer
* python-cinder
* python-designate
* python-glance
* python-heat
* python-keystone
* python-mysqldb-dbg
* python-nova
* python-trove
* rddmarc
* viewvc-query
* zope-mysqlda

I'd suggest not just replacing it.  How about call your package python-
mysqlclient (as you had originally intended I believe) and have it conflict 
with python-mysqldb (since they both provide the same interface, conflicts is 
appropriate).  Maintainers can decide which they prefer and if we get a strong 
consensus for Stretch, then we can remove python-mysqldb and have python-
mysqlclient provide it.

I think this way would be much friendlier and lower risk.

Scott K


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/4499024.p5cSZFb7M0@kitterman-optiplex-9020m

Bug#768096: [Python-modules-team] python mysqldb on python 3

[Scott Kitterman]

On Tue, 18 Nov 2014 15:24:45 +1100 Brian May br...@microcomaustralia.com.au 
wrote:
 On 18 November 2014 15:05, Scott Kitterman deb...@kitterman.com wrote:
 
  [...] Maintainers can decide which they prefer and [...]
 
 
 On second thoughts, me thinks this may not be as easy as you suggest. :-(
 
 i.e. if package XYZ changes to depend on python-mysqlclient, it is going to
 conflict with every package that depends on python-mysqldb.

True.  This is one of the cases that Optional/Extra was designed to cover.

Is the original development inactive?  I think it would be at least somewhat 
anti-social to switch to a non-friendly fork (no idea if that's relevant 
here).  What are the circumstances around the fork.  I think that's at least 
socially significant.

Scott K


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1901392.8GKORRARNn@kitterman-optiplex-9020m

Bug#768096: [Python-modules-team] python mysqldb on python 3

[Scott Kitterman]

On Tuesday, November 18, 2014 04:02:14 PM Brian May wrote:
 On 18 November 2014 15:40, Scott Kitterman deb...@kitterman.com wrote:
  Is the original development inactive?  I think it would be at least
  somewhat
  anti-social to switch to a non-friendly fork (no idea if that's relevant
  here).  What are the circumstances around the fork.  I think that's at
  least
  socially significant.
 
 I am no expert here. Looking at source force, the latest stable release of
 (1.2.3) mysqldb was 2010-06-17 (with the corresponding windows msi being
 generated 2012-09-05).
 
 http://sourceforge.net/projects/mysql-python/files/mysql-python/1.2.3/
 
 There has been a beta version since (1.2.4b4), having problems getting a
 date for it using source forge.
 
 Last svn commit appears to have been made 2012-09-24.
 
 The big issue mysqlclient solves is Python3 support, although I suspect
 there are other bugs fixed too.
 
 https://pypi.python.org/pypi/mysqlclient/1.3.4
 
 Looking at mysqlclient at https://github.com/PyMySQL/mysqlclient-python,
 there is the text:
 
 This project adds Python 3 support and bug fixes. I hope this fork is
 merged back to MySQLdb1 like distribute was merged back to setuptools.
 
 A merge back would be good, but unfortunately I am doubtful it is going to
 happen.

That does sound like a friendly fork, so I think taking over the package name 
for Stretch would be appropriate, but in the meantime, it should stay in 
experimental in case a bug fix is needed for the current package for Jessie.

Scott K


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2181791.B13uNQkGGB@kitterman-optiplex-9020m

Bug#764890: ITP: dk-filter - DomainKeys for Sendmail/SMTP (RFC-4870)

[Scott Kitterman]

On October 12, 2014 7:18:48 AM EDT, Andrei POPESCU andreimpope...@gmail.com 
wrote:
Control: reassign -1 wnpp
Control: owner -1 Carlos Gili cg...@goliath-la.com

On Sb, 11 oct 14, 17:46:50, Carlos Gili wrote:
 Package: dk-filter
 Priority: whishlist
 
 Section: mail
 Original-Maintainer: Mike Markley m...@markley.org
 Description: DomainKeys for Sendmail/SMTP
  Implements a Sendmail/SMTP Mail Filter (Milter) for the
  DomainKeys standard (RFC-4870). DomainKeys provides a way
  for authorized sender mail servers from an specific Domain
  to confirm their identity when sending email by adding a
  cryptographic signature to the headers of the message. The
  dk-filter implements both DomainKeys signing and verification.
  .
 
 Currently, both DKIM (OpenDKIM) and DomainKeys together with SPF
 are requested by servers such as Hotmail or Yahoo to ensure that
 the mail is not forged (spam), otherwise your mail gets send to
 spam folder most of the time, unless you are an already KNOWN
 domain server.
 
 The binary .deb file for amd64 is ready to be uploaded, the i386
 and source ones will take a little since I'm integrating with GIT,
 and creating a Virtual environment to compile on 32bits, also I'm
 preparing a repository for several things.
 

No.  DomainKeys is dead. Only DKIM is used. 

dk-filter was buggy and long dead upstream when it was removed. There's no need 
for this in 2014.

Please don't re-introduce this into the archive.

Scott K


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/f0f32e79-bb75-4c72-ab18-e343f6f0c...@kitterman.com

Bug#753271: O: py-radix -- radix tree implementation for storage of IPv4 and IPv6 networks

[Scott Kitterman]

On Sunday, June 29, 2014 23:56:29 Christoph Berg wrote:
 Package: wnpp
 Severity: normal
 
 I'm orphaning the py-radix package. It's maintained under the Debian
 Python Modules Team umbrella, but I am the only Uploader, hence an O bug.
 
 Description: radix tree implementation for storage of IPv4 and IPv6 networks
 py-radix is an implementation of a radix tree for Python, which supports
 storage and lookups of IPv4 and IPv6 networks. This is a Python equivalent
 to Dave Plonka's Perl Net::Patricia (it even steals the same radix tree
 code from MRTd).
  .
  The radix tree (a.k.a Patricia tree) is the data structure most commonly
 used for routing table lookups. It efficiently stores network prefixes of
 varying lengths and allows fast lookups of containing networks. py-radix's
 implementation is built solely for networks (the data structure itself is
 more general).

pysubnettree (python and python3-subnettree) is similar and actively 
maintained.  The only rdepend on py-radix in the archice seems to be zorp and 
at a glance, it would not be that hard to port to subnettree.

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#725170: ITP: python-clamd -- clamd is a portable Python module to use the ClamAV anti-virus engine on Windows, Linux, MacOSX and other platforms. It requires a running instance of the clamd daemon

[Scott Kitterman]

On Wednesday, October 02, 2013 08:50:31 Daniel Wozniak wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Daniel Wozniak d...@woz.io
 
 * Package name: python-clamd
   Version : 1.0.1
   Upstream Author : Thomas Grainger tagr...@gmail.com
 * URL : https://github.com/orvant/debian-python-clamd
 * License : LGPL
   Programming Lang: Python
   Description : clamd is a portable Python module to use the ClamAV
 anti-virus engine
 
  clamd is a portable Python module to use the ClamAV anti-virus engine on
  Windows, Linux, MacOSX and other platforms. It requires a running instance
 of the clamd daemon.
  .
  This is a fork of pyClamd v0.2.0 created by Philippe Lagadec and published
 on his website: http://www.decalage.info/en/python/pyclamd which in turn is
 a slightly improved version of pyClamd v0.1.1 created by Alexandre Norman
 and published on his website: http://xael.org/norman/python/pyclamd/

We already have pyclamd 0.2.2 in the archive:

http://packages.qa.debian.org/p/pyclamd.html

Although it looks like at least the binary package name should change, I think 
it would make sense to have only one actively maintained version of this in 
the archive instead of two.  

Scott K


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/3386894.0XJyM6E3MB@scott-latitude-e6320

Bug#725170: ITP: python-clamd -- clamd is a portable Python module to use the ClamAV anti-virus engine on Windows, Linux, MacOSX and other platforms. It requires a running instance of the clamd daemon

[Scott Kitterman]

On Wednesday, October 02, 2013 08:11:03 Scott Kitterman wrote:
 On Wednesday, October 02, 2013 08:50:31 Daniel Wozniak wrote:
  Package: wnpp
  Severity: wishlist
  Owner: Daniel Wozniak d...@woz.io
  
  * Package name: python-clamd
  
Version : 1.0.1
Upstream Author : Thomas Grainger tagr...@gmail.com
  
  * URL : https://github.com/orvant/debian-python-clamd

Also, this should be the upstream URL, not the URL of your packaging work.

Scott K


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2867343.AHC1AtShKi@scott-latitude-e6320

Bug#725170: ITP: python-clamd -- clamd is a portable Python module to use the ClamAV anti-virus engine on Windows, Linux, MacOSX and other platforms. It requires a running instance of the clamd daemon

[Scott Kitterman]

Daniel Wozniak d...@woz.io wrote:
On 10/02/2013 05:11 AM, Scott Kitterman wrote:
 On Wednesday, October 02, 2013 08:50:31 Daniel Wozniak wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Daniel Wozniak d...@woz.io

 * Package name: python-clamd
Version : 1.0.1
Upstream Author : Thomas Grainger tagr...@gmail.com
 * URL : https://github.com/orvant/debian-python-clamd
 * License : LGPL
Programming Lang: Python
Description : clamd is a portable Python module to use the
ClamAV
 anti-virus engine

   clamd is a portable Python module to use the ClamAV anti-virus
engine on
   Windows, Linux, MacOSX and other platforms. It requires a running
instance
 of the clamd daemon.
   .
   This is a fork of pyClamd v0.2.0 created by Philippe Lagadec and
published
 on his website: http://www.decalage.info/en/python/pyclamd which in
turn is
 a slightly improved version of pyClamd v0.1.1 created by Alexandre
Norman
 and published on his website: http://xael.org/norman/python/pyclamd/
 We already have pyclamd 0.2.2 in the archive:

 http://packages.qa.debian.org/p/pyclamd.html

 Although it looks like at least the binary package name should
change, I think
 it would make sense to have only one actively maintained version of
this in
 the archive instead of two.

 Scott K
This is a fork of code in the package available currently. As far as I 
can tell this one is being actively worked on but the other is not. A 
little background, my primary motivation for wanting this package is 
that it the newest upstream of w3af requires it as a dependency.

http://packages.debian.org/sid/w3af


As long as it's reasonably backwards compatible, we should definitely replace 
the unmaintained code with the maintained fork.

Scott K


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/a2d19402-b30d-4e11-934f-1a25940f9...@email.android.com

Bug#719719: ITP: bind10 -- ISC's Internet Domain Name Server

[Scott Kitterman]

On Wednesday, August 14, 2013 09:47:14 Ernesto Hernández-Novich wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Ernesto Hernández-Novich (USB) e...@usb.ve
 
 * Package name: bind10
   Version : 1.1.0
   Upstream Author : ISC Software Distribution pack...@isc.org
 * URL : http://bind10.isc.org
 * License : BSD
   Programming Lang: C++, Python
   Description : ISC's Internet Domain Name Server
 
 BIND 10 is the next generation of BIND, the most widely-used name server
 software on the Internet, and is supported by the Internet Software
 Consortium, www.isc.org.

Source: bind9
Section: net
Priority: optional
Maintainer: LaMont Jones lam...@debian.org
Uploaders: Bdale Garbee bd...@gag.com

Noting that you aren't a maintainer of the existing BIND packages, have you 
coordinated this with them?  It seems rather unfriendly otherwise.

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#712630: ITP: pyqt5 -- Python bindings for Qt5

[Scott Kitterman]

Dmitrijs Ledkovs x...@debian.org wrote:

On 18 June 2013 05:12, Scott Kitterman deb...@kitterman.com wrote:

 This will have binaries for both python and python3 as both are
 supported.  DPMT will be the maintainer and I'll be an uploader. 
Anyone
 who wants to work on putting this together, please let me know.


I'd be interested. I haven't looked into details, but are:
lp:~xnox/ubuntu/raring/python-qt4/qt5
lp:~mitya57/+junk/wip-pyqt5-packaging

of any use? Have you started packaging yet? I don't see anything
committed in DPMT svn.

I'm aware of mitya57's work. No. I've not done anything additional yet.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/4b7320f6-cc17-49e8-8b56-7168542be...@email.android.com