Re: Bug#1022526: python-ssdeep: FTBFS: distutils.errors.DistutilsClassError: command class must subclass Command
Control: tags -1 + upstream On Sun, Oct 23, 2022 at 03:37:36PM +0200, Lucas Nussbaum wrote: > Source: python-ssdeep > Version: 3.1+dfsg-3 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20221023 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. At the time when I introduced python-ssdeep to Debian, fuzzy hashing was not a thing. tlsh didn't exist. Now it is there and tlsh seems technically supperior albeit incompatible. So unless there is some compatibility reason for keeping ssdeep, I think it should be RoQAed. And no, updating it to 3.4 does not fix the ftbfs. Would someone handle dnstwist, which is the only remaining dependency? Helmut
Bug#998614: RFP: python-crccheck -- implementation of 170+ CRC algorithms in Python
Package: wnpp Severity: wishlist Tags: patch X-Debbugs-Cc: debian-python@lists.debian.org * Package name: python-crccheck Version : 1.0 Upstream Author : Martin Scharrer * URL : https://sourceforge.net/projects/crccheck/ * License : GPL-3 Programming Lang: Python Description : implementation of 170+ CRC algorithms in Python crccheck is a Python module that implements more than 170 CRC algorithms used in various applications. A few examples include: CRC-5/USB, CRC-14/GSM, CRC-16/MODBUS, CRC-24/OPENPGP, PKZIP, CRC-32 A catalogue can be found at http://reveng.sourceforge.net/crc-catalogue/. Packaging crccheck is a prerequisite for other Python modules notably chepy and zigpy. I've already packaged it and am attaching my work. Helmut python-crccheck_1.0-1.debian.tar.xz Description: application/xz
Bug#943693: RFP: python-ws-discovery -- WS-Discovery implementation for Python
Package: wnpp
Severity: wishlist
Tags: patch
* Package name: python-ws-discovery
Version : 1.1.2
Upstream Author : Andrei Kopats
* URL : https://github.com/andreikop/python-ws-discovery
* License : LGPL-3
Programming Lang: Python
Description : WS-Discovery implementation for Python
WS-Discovery is a multicast-based device discovery protocol often used
with cameras. This module allows discovering other devices as well as
publishing oneself.
As of yet, there is no comparable functionality in the Debian archive.
The gsoap package provides some functionality to implement wsd as does
python-zeep, but neither is readily usable for the discovery purpose.
For these reasons, I think that adding python-ws-discovery would be
good.
I don't intend to maintain this package, but I am providing an initial
packaging together with this RFP anyway. It's a simple python module
with few oddities. The one thing that will need attention is its use of
the generic name /usr/bin/discover. I'm going to discuss that with
upstream. Note that the source vs binary package name mismatch is
intentional. Upstream really calls the source "python-ws-discovery", but
the importable module is "wsdiscovery", so the binary package should be
"python3-wsdiscovery". I recommend maintaining this package within the
DPMT (cced). Hope this helps.
Helmut
diff -ruN a/debian/TODO b/debian/TODO
--- a/debian/TODO 1970-01-01 01:00:00.0 +0100
+++ b/debian/TODO 2019-10-25 10:25:48.0 +0200
@@ -0,0 +1,2 @@
+* Demote python3-click to recommends. Should be dh_python3 --recommneds=click, but doesn't work!?
+* Don't occupy generic name /usr/bin/discover.
diff -ruN a/debian/changelog b/debian/changelog
--- a/debian/changelog 1970-01-01 01:00:00.0 +0100
+++ b/debian/changelog 2019-10-28 08:34:45.314112777 +0100
@@ -0,0 +1,5 @@
+python-ws-discovery (1.1.2-1) unstable; urgency=medium
+
+ * Initial release. (Closes: #-1)
+
+ -- Helmut Grohne Fri, 25 Oct 2019 10:25:48 +0200
diff -ruN a/debian/control b/debian/control
--- a/debian/control 1970-01-01 01:00:00.0 +0100
+++ b/debian/control 2019-10-28 08:35:01.009977195 +0100
@@ -0,0 +1,27 @@
+Source: python-ws-discovery
+Build-Depends:
+ debhelper-compat (= 12),
+ dh-python,
+ python3,
+ python3-click,
+ python3-mock ,
+ python3-netifaces,
+ python3-pytest ,
+ python3-setuptools,
+Maintainer: TBD
+Section: python
+Priority: optional
+Standards-Version: 4.4.1
+Homepage: https://github.com/andreikop/python-ws-discovery
+Testsuite: autopkgtest-pkg-python
+
+Package: python3-wsdiscovery
+Architecture: all
+Depends: ${misc:Depends}, ${python3:Depends}
+Recommends: ${python3:Recommends}
+Description: WS-Discovery implementation for Python - Python 3.X module
+ The module allows discovering WS-Discovery compatible devices as well as
+ publishing oneself as a discoverable device.
+ .
+ WS-Discovery is a multicast-based device discovery protocol defined by an
+ OASIS standard.
diff -ruN a/debian/copyright b/debian/copyright
--- a/debian/copyright 1970-01-01 01:00:00.0 +0100
+++ b/debian/copyright 2019-10-25 10:25:48.0 +0200
@@ -0,0 +1,17 @@
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: python-ws-discovery
+Source: https://github.com/andreikop/python-ws-discovery
+
+Files: *
+Copyright:
+ 2013-2018 Andrei Kopats
+ 2016-2019 Petri Savolainen
+License: LGPL-3
+
+Files: debian/*
+Copyright: 2019 Intenta GmbH
+License: LGPL-3
+
+License: LGPL-3
+ On Debian systems, the full text of the GNU Lesser General Public License
+ version 3 can be found in the file `/usr/share/common-licenses/LGPL-3'.
diff -ruN a/debian/rules b/debian/rules
--- a/debian/rules 1970-01-01 01:00:00.0 +0100
+++ b/debian/rules 2019-10-25 10:25:48.0 +0200
@@ -0,0 +1,4 @@
+#!/usr/bin/make -f
+export PYBUILD_NAME=wsdiscovery
+%:
+ dh $@ --buildsystem=pybuild --with=python3
diff -ruN a/debian/source/format b/debian/source/format
--- a/debian/source/format 1970-01-01 01:00:00.0 +0100
+++ b/debian/source/format 2019-10-25 10:25:48.0 +0200
@@ -0,0 +1 @@
+3.0 (quilt)
diff -ruN a/debian/watch b/debian/watch
--- a/debian/watch 1970-01-01 01:00:00.0 +0100
+++ b/debian/watch 2019-10-25 10:25:48.0 +0200
@@ -0,0 +1,3 @@
+version=4
+opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/python-ws-discovery-$1\.tar\.gz/ \
+ https://github.com/andreikop/python-ws-discovery/tags .*/v?(\d\S+)\.tar\.gz
Bug#934667: RFP: aioftp -- ftp client/server library for Python asyncio
Package: wnpp Severity: wishlist Tags: patch * Package name: python-aioftp Version : 0.10.1 Upstream Author : pohmelie * URL : https://github.com/aio-libs/aioftp * License : Apache-2.0 Programming Lang: Python Description : ftp client/server library for Python asyncio python-aioftp is a module for using a ftp client or server together with asyncio. If asyncio is not required, pyftpdlib should be considered as an alternative and is already packaged in Debian. This library can complement parfive, which is being packaged for Debian (see #929438). It can be used independently of course. There is not currently an asyncio ftp server in Debian. The library is very simple and does not have any runtime dependencies outside the standard library. I'm also attaching the debian tree for aioftp-0.10.1.tar.gz as obtained from pypi. Likely, the package should be maintained in the DPMT. Helmut python-aioftp_0.10.1-1.debian.tar.xz Description: application/xz
Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import
Control: severity 896234 normal Control: severity 896242 normal Control: severity 896272 normal Control: severity 896306 normal Control: severity 896307 normal Control: severity 896328 normal Control: severity 896378 normal Control: severity 896396 normal Control: severity 896429 normal On Sat, Apr 21, 2018 at 09:47:59AM +1000, Brian May wrote: > Helmut Grohne writes: > > > django.core.exceptions.ImproperlyConfigured: Requested setting > > DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must > > either define the environment variable DJANGO_SETTINGS_MODULE or call > > settings.configure() before accessing settings. > > I believe this bug report, and several others you filled recently that > contain this same text are false. I went passed the bug list to a few others for review and posted the full list to d-devel (including all tracebacks). Nobody spoke up and Chris Lamb vaguely said that the django ones looked legit to him. I have lowered the severity of the relevant bugs (matching "ImproperlyConfigured") to prevent issues with testing migration. > Like it or not, it is just not possible to import Django libraries > without providing a valid django settings file. This is not a sign that > something is broken. I wonder whether we can draw anything useful from these bugs before closing them. For one thing, you cannot use autopkgtest-pkg-python on these modules as is. Then having them not importable means that e.g, pydoc. That's unfortunate. Often times, modules with non-trivial impact on their environment do not do so at import time, but provide something like an install function such that the user makes a conscious choice. An example would be gbulb.install(). So yeah, for django this may make sense, but this behaviour is still unfortunate from a qa pov. I'd like to hear your opinion on this matter. After the dust has settled, I can follow up on d-devel with a summary that suggests filtering this particular django exception. Helmut
