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
Re: Discussing next steps for the Python2 removal
On Fri, 25 Oct 2019 at 12:38:11 +0200, Ondrej Novy wrote: > this is not how autorm works. You can't remove from testing only one of two > binary package from same source package. You are removing package as a whole. > > But maintainer can anytime fix that bug by removing py2 binary from source > package, which is few minutes work. The maintainer of a leaf package can do this in a few minutes at any time, but library packages with many reverse-dependencies (for example dbus-python) don't really have that option, so I hope using autorm for library packages is not on the table at this stage? smcv
Re: Discussing next steps for the Python2 removal
Hi, po 28. 10. 2019 v 10:56 odesílatel Simon McVittie napsal: > The maintainer of a leaf package can do this in a few minutes at any > time, but library packages with many reverse-dependencies (for example > dbus-python) don't really have that option, so I hope using autorm for > library packages is not on the table at this stage? > but we are still talking about __leaf__ packages so dbus-python is irelevant, right? -- Best regards Ondřej Nový
package_data in python package
Hi,
I have a problem with package_data files in a package ("khard", which is
not currently under the debian-python umbrella but it is on my todo list
to transfer it, I just didn't find the time yet) not getting installed.
I submitted an error upstream,
https://github.com/scheibler/khard/issues/231 but they can't reproduce
the problem.
I "fixed" the issue by adding a patch to add "khard/data/" to
MANIFEST.in (with "recursive-include khard/data/ *"), but I don't get
why this directory doesn't get installed by default... Is it because of
a limitation of dh-python? Have I forgot an option somewhere?
Link to the patch and the source of the package:
https://sources.debian.org/src/khard/0.15.0-2/debian/patches/0003-add-khard-data-dir-to-MANIFEST.in.patch/
Thanks for your help!
--
Félix
signature.asc
Description: PGP signature
Re: package_data in python package
On Monday, October 28, 2019 10:25:44 AM EDT Félix Sipma wrote:
> Hi,
>
> I have a problem with package_data files in a package ("khard", which is
> not currently under the debian-python umbrella but it is on my todo list
> to transfer it, I just didn't find the time yet) not getting installed.
>
> I submitted an error upstream,
> https://github.com/scheibler/khard/issues/231 but they can't reproduce
> the problem.
>
> I "fixed" the issue by adding a patch to add "khard/data/" to
> MANIFEST.in (with "recursive-include khard/data/ *"), but I don't get
> why this directory doesn't get installed by default... Is it because of
> a limitation of dh-python? Have I forgot an option somewhere?
>
> Link to the patch and the source of the package:
> https://sources.debian.org/src/khard/0.15.0-2/debian/patches/0003-add-khard->
> data-dir-to-MANIFEST.in.patch/
>
> Thanks for your help!
It's the way setuptools works. Looking at the current upstream
recommendations:
https://python-packaging.readthedocs.io/en/latest/non-code-files.html
your solution seems correct.
Scott K
Re: package_data in python package
On 2019-10-28 10:44-0400, Scott Kitterman wrote: > It's the way setuptools works. Looking at the current upstream > recommendations: > > https://python-packaging.readthedocs.io/en/latest/non-code-files.html > > your solution seems correct. Hi Scott, Thanks for your message. I'm not sure I get why upstream can't reproduce the problem in this case... setuptools, as used in the setup.py seems to install the data dir just fine, and without my patch. That's why I thought that it was maybe a limitation of dh-python... -- Félix signature.asc Description: PGP signature
Re: package_data in python package
On Monday, October 28, 2019 11:02:40 AM EDT Félix Sipma wrote: > On 2019-10-28 10:44-0400, Scott Kitterman wrote: > > It's the way setuptools works. Looking at the current upstream > > recommendations: > > > > https://python-packaging.readthedocs.io/en/latest/non-code-files.html > > > > your solution seems correct. > > Hi Scott, > > Thanks for your message. I'm not sure I get why upstream can't reproduce > the problem in this case... setuptools, as used in the setup.py seems to > install the data dir just fine, and without my patch. > > That's why I thought that it was maybe a limitation of dh-python... It does depend considerably on how you do the install. For example, to replicate what pip does (to get the data files installed) you have to do: python setup.py install --single-version-externally-managed --record=/dev/null I don't find I need to do that with pybuild though. I find setuptools handling of data files highly mysterious and counter-intuitive, so I doubt I'll have more specific advice. Scott K signature.asc Description: This is a digitally signed message part.
Re: package_data in python package
On 2019-10-28 11:15-0400, Scott Kitterman wrote: > On Monday, October 28, 2019 11:02:40 AM EDT Félix Sipma wrote: >> On 2019-10-28 10:44-0400, Scott Kitterman wrote: >>> It's the way setuptools works. Looking at the current upstream >>> recommendations: >>> >>> https://python-packaging.readthedocs.io/en/latest/non-code-files.html >>> >>> your solution seems correct. >> >> Hi Scott, >> >> Thanks for your message. I'm not sure I get why upstream can't reproduce >> the problem in this case... setuptools, as used in the setup.py seems to >> install the data dir just fine, and without my patch. >> >> That's why I thought that it was maybe a limitation of dh-python... > > It does depend considerably on how you do the install. For example, to > replicate what pip does (to get the data files installed) you have to do: > > python setup.py install --single-version-externally-managed --record=/dev/null > > I don't find I need to do that with pybuild though. I find setuptools > handling > of data files highly mysterious and counter-intuitive, so I doubt I'll have > more specific advice. > > Scott K They just run "python3 setup.py install" (https://github.com/scheibler/khard/issues/231): $ python3 -m venv test-for-231 $ source test-for-231/bin/activate $ python3 setup.py install $ tree test-for-231/lib/python3.7/site-packages/khard-0.15.0-py3.7.egg test-for-231/lib/python3.7/site-packages/khard-0.15.0-py3.7.egg ├── EGG-INFO │ ├── dependency_links.txt │ ├── entry_points.txt │ ├── not-zip-safe │ ├── PKG-INFO │ ├── requires.txt │ ├── SOURCES.txt │ └── top_level.txt └── khard ├── actions.py ├── address_book.py ├── carddav_object.py ├── cli.py ├── config.py ├── data │ ├── config.spec │ └── template.yaml ├── helpers.py ├── __init__.py ├── khard.py ├── __main__.py ├── object_type.py └── version.py 3 directories, 20 files For my part, I "just" build the debian package with "gbp buildpackage", and with "dh $@ --with python3 --buildsystem=pybuild" in debian/rules. The solutions I say are: I can keep the patch in the package (without really understanding the need for it) or try to convince upstream to merge it (but they can't reproduce the problem, so why would they do that?). In both cases, probably others will encounter the same problem in other packages... It would be nice to fix the problem once for all (if possible :)). Regards, -- Félix signature.asc Description: PGP signature
Re: package_data in python package
Félix Sipma writes: > They just run "python3 setup.py install" > (https://github.com/scheibler/khard/issues/231): > [...] > > For my part, I "just" build the debian package with "gbp buildpackage", > and with "dh $@ --with python3 --buildsystem=pybuild" in debian/rules. > > The solutions I say are: I can keep the patch in the package (without > really understanding the need for it) or try to convince upstream to > merge it (but they can't reproduce the problem, so why would they do > that?). In both cases, probably others will encounter the same problem > in other packages... It would be nice to fix the problem once for all > (if possible :)). Just FYI, https://bugs.debian.org/940728 describes a similar problem, although there the unhandled files are Python source files. pybuild seems to handle things different from plain setup.py. Cheers Ole
