Bug#1060053: RFP: wayprompt -- multi-purpose (password-)prompt tool for Wayland

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist

* Package name: wayprompt
  Version : 0.0.0
  Upstream Contact: Leon Plickat 
* URL : 
* License : GPL-3
  Programming Lang: Zig
  Description : multi-purpose (password-)prompt tool for Wayland

WayPrompt also has a TUI fallback mode for when no Wayland connection
can be established, like when invoked while using a TTY.

Installs multiple executables:
 • wayprompt: CLI prompt tool
 • pinentry-wayprompt: drop-in PinEntry replacement, for example for GPG

All executables use the same configuration file.


Note that this project is written in Zig which is not packaged for Debian yet,
I didn't find any other PinEntry replacement for Wayland.

Bug#1043168: please include missing stub_flasher_32.json file

[Piotr Ożarowski]

Package: esptool
Version: 4.6.2+dfsg-0.1
Severity: minor

Hi,

I had to add stub_flasher_32.json file manually from upstream repo in
order to make my esphome (not yet in Debian, working on it) work with
ESP32 WROOM 32 board.

Please include this file in the package. TIA


signature.asc
Description: PGP signature

Bug#1041538: dh-python: Unhelpful inclusion of optional packages in Depends

[Piotr Ożarowski]

[Scott Kitterman, 2023-07-20]
> I had to override dh_python3 to add --no-guessing-deps in the latest

FTR: you can override detection with debian/py3dist-overrides (see
dh_python3's manpage or /usr/share/doc/dh-python/README.PyDist for more
details)

> dnspython upload because it was getting things wrong.  Here's what it
> generated:
> 
> python3-httpcore | python3 (<< 3.8), python3-sniffio, python3:any
> 
> The correct answer here is actually use python3:any.  Here's what I
> think is going on:
> 
> From the pyproject.toml file:
> 
> [tool.poetry.dependencies]
> python = "^3.8"
> httpx = {version=">=0.24.1", optional=true, python=">=3.8"}
> httpcore = {version=">=0.17.3", optional=true, python=">=3.8"}
> h2 = {version=">=4.1.0", optional=true, python=">=3.8"}
> idna = {version=">=2.1,<4.0", optional=true}
> cryptography = {version=">=2.6,<42.0", optional=true}
> trio = {version=">=0.14,<0.23", optional=true}
> sniffio = {version="^1.1", optional=true}
> wmi = {version="^1.5.1", optional=true}
> aioquic = {version=">=0.9.20", optional=true}
> 
> ...
> 
> [tool.poetry.extras]
> doh = ['httpx', 'h2']
> idna = ['idna']
> dnssec = ['cryptography']
> trio = ['trio']
> wmi = ['wmi']
> doq = ['aioquic']
> 
> There are two issues:
> 
> 1.  httpcore and sniffio shouldn't be listed at all.  They are optional.
> I suspect that either poetry or dh-python is looking at the extras
> section and since those packages aren't listed for one of the extras, it
> assumes the package is required, despite the optional flag.  They
> probably should be listed somewhere (upstream bug), but I think if it
> says optional, it shouldn't be added to Depends.

dh_python3 doesn't look at source files. It generates dependencies by
parsing installed requires.txt file so IMHO it's an upstream / poetry bug

> 2.  Generating an optional depends on python3 << 3.8 isn't helpful.  It
> looks to me like {version=">=0.17.3", optional=true, python=">=3.8"} is
> being mis-interpreted.  I believe the intent here is to say that the
> dependency is optional when python3 > 3.8, not you need it if python3 >

can you show me how poetry / pyproject / whatever parsed this file
interpreted it? I.e. what's in installed requires.txt

(I suspect it's a hard dependency there)

> 3.8.  There's a larger question of why the interpreter version is there
> at all, given that's now the minimum python3 version supported, but
> that's an upstream issue, we ought to get it right.

I agree

Bug#1029239: project moved to git.sr.ht - watch file

[Piotr Ożarowski]

Hi,

Looks like imv moved from github to git.sr.ht.
Here's an updated debian/watch file that detects 4.4.0 version:

| version=4
| https://git.sr.ht/~exec64/imv \
| /~exec64/imv/archive/@ANY_VERSION@@ARCHIVE_EXT@

Bug#1031902: dh-python: Generate cpython3_fallback during build

[Piotr Ożarowski]

Generating these files requires network so it cannot be enabled on
Debian. Dunno what policy Ubuntu has in that regard but I added --ubuntu
option for ./pydist/generate_fallback_list.py - let me know if Contents
URL needs an update, BTW

Bug#1030165: python3-aiohttp-jinja2: Update to latest version

[Piotr Ożarowski]

Hi,

[Sam Bull, 2023-01-31]
> The package appears to be 1.2, which is starting to look quite out-of-date.
> Would be great to get a new package in time for bookworm.

it FTBFS due to some tests failing, I didn't have enought time to
investigate them, any help appreciated…

Bug#1030164: python3-sqlalchemy: Update to 2.0

[Piotr Ożarowski]

Hi,

[Sam Bull, 2023-01-31]
> It would be nice to have sqlalchemy 2.0 packaged in time for bookworm.
> It would be a shame to be stuck with legacy 1.4 for atleast 2.5 years longer.

I will not upload 2.0 to unstable now - there are way too many changes
in the API. There's not enough time to fix all reverse dependencies.
I can upload 2.0 to experimental for now if you're interested.

Bug#1013732: hostapd: please enable 802.11ax

[Piotr Ożarowski]

Hi,

I just rebuilt with patch from this bug report and it seems to work
fine. Please enable it

Bug#1026020: python3-starlette: starlette.testclient requires module httpx

[Piotr Ożarowski]

httpx is used only in this test file and your package is invoking tests
so even if we add it to Recommends or Suggests (it definitely will not
go into Depends) you'll have to add it to ormar's Build-Depends

Bug#1023711: -2 depends on python3-python-socks

[Piotr Ożarowski]

I uploaded 0.7.1-2 that depends on python3-python-socks which is
currently in NEW so it's still not installable but at least it will not
trigger upgrades for Debian Sid users for now

Sorry for not waiting with -1 upload to unstable

Bug#1021656: please package new upstream release

[Piotr Ożarowski]

Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1
Severity: wishlist

Hi,

Please prepare new upstream release.

(and thanks for packaging / maintaining it!)

Bug#1000680: python3-aiohttp: fails to import, "TypeError: function() argument 'code' must be code, not str"

[Piotr Ożarowski]

[Boyuan Yang, 2021-11-28]
> Thanks for the info and sorry for the breakage; obviously I should have
> uploaded it into Experimental first. I am looking into fixing the issue
> (ideally through upgrade of all related packages) but this may take some time.
> If you already have a solution, it would be even better.

I already fixed it by upgrading aiohttp. It needs 2 NEW packages that I
packaged and uploaded, one of them is already accepted, second it
waiting for review. Unfortunately I uploaded my previous build (tagged
1~exp1 in the git repo, but uploaded -1 so version in unstable needs
aiosignal ASAP - I asked one of the ftp-masters if it's possible to
check it sooner and hopefully unstable will be fixed soon)

Bug#997020: RFP: fnott -- keyboard driven and lightweight Wayland notification daemon

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+swa...@tracker.debian.org

* Package name: fnott
  Version : 1.1.2
  Upstream Author : Daniel Eklöf 
* URL : https://codeberg.org/dnkl/fnott
* License : MIT
  Programming Lang: C
  Description : keyboard driven and lightweight Wayland notification daemon

Fnott is a keyboard driven and lightweight notification daemon for
wlroots-based Wayland compositors. It implements (parts of) the Desktop
Notification Specification.

Supported features
• Summary
• Body
• Actions (requires a dmenu-like utility to display and let user select action)
• Urgency
• Icons
  - PNGs (using libpng)
  - SVGs (using bundled nanosvg)
• Markup
• Timeout


We already have mako-notifier in Debian but fnott better suits my needs.
F.e. it adjusts notification popup size as needed (instead of hardcoding
width/height of the popup)

Sway and related packages team added to X-Debbugs-Cc.

I can create an initial package and/or sponsor potential maintainer.


signature.asc
Description: PGP signature

Bug#993865: please enable CONFIG_MT7915E

[Piotr Ożarowski]

Package: src:linux
Version: 5.10.28-1
Severity: wishlist

Dear Maintainer,

Please enable CONFIG_MT7915E (MediaTek MT7915E (PCIe) support) - looks
like my new mini PCIe card needs this one.
5.14-1~exp2 from experimental doesn't have this one enabled as well

CONFIG_MT7915E was added in Linux 5.8

TIA

Bug#991709: unblock: python-defaults/2.7.18-3

[Piotr Ożarowski]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-defaults
(just uploaded, so needs few more days but hopefully it will make it
into Bullseye)

[ Reason ]
pyclean and pycomile scripts (and debpython module stripped down to
code needed by mentioned scripts) were accidentally removed in 2.7.18-1
from python2-minimal package. There's a fallback code in maintainer
scripts (in python-foo packages) so nobody noticed for almost a year but
fortunately Jakub Wilk pinged us about the problem.

[ Impact ]
We're almost done with removing Python 2.X stack, but these scripts are
still used and cover few more cases than the fallback code. At least
pyclean will be used a lot while removing old packages.


unblock python-defaults/2.7.18-3


diff -Nru python-defaults-2.7.18/debian/changelog 
python-defaults-2.7.18/debian/changelog
--- python-defaults-2.7.18/debian/changelog 2020-08-04 10:22:34.0 
+0200
+++ python-defaults-2.7.18/debian/changelog 2021-07-28 13:17:06.0 
+0200
@@ -1,3 +1,9 @@
+python-defaults (2.7.18-3) unstable; urgency=medium
+
+  * Install pycompile and pyclean accidentally removed in -1
+
+ -- Piotr Ożarowski   Wed, 28 Jul 2021 13:17:06 +0200
+
 python-defaults (2.7.18-2) unstable; urgency=medium
 
   * Don't ship a duplicate README.Debian in python2-doc. Closes: #966823.
diff -Nru python-defaults-2.7.18/debian/rules 
python-defaults-2.7.18/debian/rules
--- python-defaults-2.7.18/debian/rules 2020-08-04 10:20:50.0 +0200
+++ python-defaults-2.7.18/debian/rules 2021-07-28 13:16:09.0 +0200
@@ -112,6 +112,7 @@
dh_testroot
 #  dh_installdirs -ppython usr/share/doc/python
dh_install
+   DESTDIR=debian/python2-minimal PREFIX=/usr make install-runtime
 
touch stamp-install
 


signature.asc
Description: PGP signature

Bug#989651: python3-sqlalchemy: Please package new upstream version

[Piotr Ożarowski]

Hi

> Please consider packaging the latest upstream version (currently 1.4.17) of 
> SQLAlchemy.

I will upload 1.4.X soon after Debian Bullseye is released

Bug#982298: dh-python: deprecated test command 'python3.9 setup.py test'

[Piotr Ożarowski]

> > actually… pybuild should invoke something like this:
> > `{interpreter} -m unittest discover -v {args}`
> > so I don't know where "setup.py test" came from. Can you point me to

pybuild *does* that for distutils plugin. I will not change it in this
release cycle as I don't know how many packages depend on that

Bug#982298: dh-python: deprecated test command 'python3.9 setup.py test'

[Piotr Ożarowski]

[Julian Gilbey, 2021-02-09]
> On Mon, Feb 08, 2021 at 02:32:23PM +0100, Piotr Ożarowski wrote:
> > [Julian Gilbey, 2021-02-08]
> > > I: pybuild base:232: python3.9 setup.py test 
> > > running test
> > > WARNING: Testing via this command is deprecated and will be removed in a 
> > > future version. Users looking for a generic test entry point independent 
> > > of test runner are encouraged to use tox.
> > > 
> > > Since it is dh-python that runs this command, presumably it is
> > > dh-python that should change it, or maybe I'm wrong?
> > 
> > if your package uses pytest or nose{,2} then just add appropriate build
> > dependency (like: python3-pytest) and above command will not be used.
> > See pybuild's manual for more details
> 
> It doesn't: it uses unittest.  I guess I could depend on
> python3-pytest anyway, and that might solve it, but it seems a little
> strange to depend on python3-pytest when the package uses unittest.
> But then maybe I haven't understood something correctly.

actually… pybuild should invoke something like this:
`{interpreter} -m unittest discover -v {args}`
so I don't know where "setup.py test" came from. Can you point me to
your package?

Bug#982298: dh-python: deprecated test command 'python3.9 setup.py test'

[Piotr Ożarowski]

[Julian Gilbey, 2021-02-08]
> I: pybuild base:232: python3.9 setup.py test 
> running test
> WARNING: Testing via this command is deprecated and will be removed in a 
> future version. Users looking for a generic test entry point independent of 
> test runner are encouraged to use tox.
> 
> Since it is dh-python that runs this command, presumably it is
> dh-python that should change it, or maybe I'm wrong?

if your package uses pytest or nose{,2} then just add appropriate build
dependency (like: python3-pytest) and above command will not be used.
See pybuild's manual for more details

Bug#976695: vim-ctrlp does not work with packadd!

[Piotr Ożarowski]

Control: severity -1 minor

> You annunced NEWS. use packadd!
> 
> but, vim said: E919: ディレクトリが 'packpath' の中にありません: "pack/*/opt/ctrlp"
> 
> This means vim can't find ctrlp in "pack/*/opt/ctrlp"
> 
> I have redoed "vam install ctrlp"

ah, there's a typo in NEWS, it should be: "packadd! CtrlP" like in
package's description. I will fix it in my next upload, thanks

Bug#944875: workaround

[Piotr Ożarowski]

Control: tags -1 + patch

here's a patch to use deprecated setRequestInterceptor if
setUrlRequestInterceptor is not available
commit 6d030410a363123c5152d4b2d1a056bac8bffa46 (HEAD -> master)
Author: Piotr Ożarowski 
Date:   Tue May 12 12:32:01 2020 +0200

use deprecated setRequestInterceptor if setUrlRequestInterceptor is not available

diff --git a/src/calibre/ebooks/pdf/html_writer.py b/src/calibre/ebooks/pdf/html_writer.py
index c3abe969b..293ee3341 100644
--- a/src/calibre/ebooks/pdf/html_writer.py
+++ b/src/calibre/ebooks/pdf/html_writer.py
@@ -276,7 +276,10 @@ class RenderManager(QObject):
 ans.setHttpUserAgent(ua)
 s = ans.settings()
 s.setDefaultTextEncoding('utf-8')
-ans.setUrlRequestInterceptor(self.interceptor)
+try:
+ans.setUrlRequestInterceptor(self.interceptor)
+except AttributeError:
+ans.setRequestInterceptor(self.interceptor)
 self.profile = ans
 
 self.opts = opts

Bug#944875: workaround

[Piotr Ożarowski]

> This function was introduced in Qt 5.13.
> Not sure what can be done here ... besides waiting

We have 5.14 in Debian and this bug is still present.

Since I don't need links in PDF I commented ans.setUrlRequestInterceptor line
to workaround it and it seems to work fine for me.

Bug#954748: RFA: python-weberror -- Python web error handling and exception catching module

[Piotr Ożarowski]

Package: wnpp
Severity: normal

I request an adopter for the python-weberror package.

The package description is:
 This Python module provides error handling and exception catching
 functionality for WSGI web applications. It is primarily used by Pylons
 (python-pylons).

Bug#954102: ITP: starlette -- little ASGI library that shines

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ożarowski 

* Package name: starlette
  Version : 0.13.2
  Upstream Author : Tom Christie 
* URL : https://github.com/encode/starlette
* License : BSD
  Programming Lang: Python
  Description : little ASGI library that shines

Binary package names: python3-starlette

 Starlette is a lightweight ASGI (https://asgi.readthedocs.io/en/latest/)
 framework/toolkit, which is ideal for building high performance asyncio
 services.
 .
 It is production-ready, and gives you the following:
 .
  * Seriously impressive performance.
  * WebSocket support.
  * GraphQL support.
  * In-process background tasks.
  * Startup and shutdown events.
  * Test client built on `requests`.
  * CORS, GZip, Static Files, Streaming responses.
  * Session and Cookie support.
  * 100% test coverage.
  * 100% type annotated codebase.
  * Zero hard dependencies.

Bug#954101: ITP: python-databases -- async database support for Python's asyncio

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ożarowski 

* Package name: python-databases
  Version : 0.3.0
  Upstream Author : Tom Christie 
* URL : https://github.com/encode/databases
* License : BSD
  Programming Lang: Python
  Description : async database support for Python's asyncio

Binary package names: python3-databases

 Databases gives you simple asyncio support for a range of databases.
 .
 It allows you to make queries using the powerful SQLAlchemy Core
 expression language, and provides support for PostgreSQL, MySQL, and SQLite.
 .
 Databases is suitable for integrating against any async Web framework, such as
 Starlette, Sanic, Responder, Quart, aiohttp, Tornado, FastAPI or Bocadillo.

Bug#943580: cannot reproduce (dist name vs module name issue?)

[Piotr Ożarowski]

Control: tags 943580 + moreinfo

Hi,

I cannot reproduce it:

 python3.8 -c 'import pkg_resources as pkg; pkg.require("typing")' 

   
 1 
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'typing' distribution was not found and 
is required by the application
 python3.7 -c 'import pkg_resources as pkg; pkg.require("typing")' 

   
 1 
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'typing' distribution was not found and 
is required by the application
 python3.6 -c 'import pkg_resources as pkg; pkg.require("typing")' 

   
 1 
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'typing' distribution was not found and 
is required by the application
 python3.5 -c 'import pkg_resources as pkg; pkg.require("typing")' 

   
 1 
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'typing' distribution was not found and 
is required by the application


Did you or upstream author confuse module name with (Python) distribution name
(or Python package name or whatever they call it these days)?

Bug#885299: bumping severity of pygtk bugs

[Piotr Ożarowski]

[Moritz Mühlenhoff, 2020-02-20]
> On Sun, Oct 06, 2019 at 05:09:30PM -0400, Jeremy Bicha wrote:
> > Control: severity -1 serious
> > Control: tags -1 -buster
> > 
> > 
> > As part of the Python2 removal, it is our intent that pygtk will be removed 
> > from Testing before the release of Debian 11
> > "Bullseye". Therefore, I am bumping the severity of this bug to Serious to 
> > ensure that there is plenty of warning before
> > the Debian 11 release and to make the eventual removal of pygtk as smooth 
> > as possible.
> 
> Should griffith be removed? It's dropped from testing for two years now
> and the upstream homepage vanished. Piotr, given that you're among the
> upstream authors, is this still maintained?

unfortunately it should be removed from Debian. Maybe some day I will
find time to update it to Python 3 and new GTK, but not anytime soon.

Bug#949377: dh_python --buildsystem=cmake doesn't pass recently added Python_EXECUTABLE variable

[Piotr Ożarowski]

Hi Lisandro,

> I'm writing this because at first I understood that dh-python should *set* 
> this
> variable, but that's FindPython's job.

I'm afraid that's the case here. We need to invoke cmake twice: once
for Python 3.7 and once for 3.8 (to build extensions for both of them)

Bug#947906: RM: api-hour -- ROM; abandoned upstream

[Piotr Ożarowski]

Package: ftp.debian.org
Severity: normal

Upstream replaced it with Pillars (which seems abandoned as well)


signature.asc
Description: PGP signature

Bug#947905: RM: emma -- ROM; abandoned upstream, uses unmaintained pygtk and deprecated Python2

[Piotr Ożarowski]

Package: ftp.debian.org
Severity: normal


signature.asc
Description: PGP signature

Bug#940728: pybuild does not copy all files in setup.py install

[Piotr Ożarowski]

Hi Ole,

[Ole Streicher, 2019-09-19]
> can you explain why you set the severity to "normal"? This problem
> causes another package to fail completely; this is IMO a reason to have
> it RC.

two reasons:
• this is a problem for one or two packages, few other thousands work fine
• I'm 90% sure this is not a bug in dh-python but in setuptools / distutils / 
setup.py
  (I will close this bug once I find some time to prove it)

Bug#921017: wireguard: doesn't always set all allowed-ips

[Piotr Ożarowski]

Hi Daniel,

> I tried to replicate this with exactly the kind of setup you've
> described, but using version 0.0.20190905-1 on amd64 on a
> debian/unstable system.  i saw the output was like:
> 
> my_public_key=10.8.1.2/32 10.1.0.0/20 10.0.0.0/20 192.168.6.0/24
> 
> Can you still replicate the problem?

yes, I can still replicate it with 0.0.20190905-1 but I do it on stable
(first Stretch now Buster) with packages from unstable (without
rebuilding them). Every time different peer (I have 11 of them) gets a
non complete AllowedIPs so I admit it's hard to reproduce…


PS I have another problem that I didn't report yet on one (and only one)
   of my peers which I don't think is related, but in case it is:
   from time to time (sometimes few days apart sometimes weeks)
   wireguard freezes (as in it doesn't accept any in/out connections).
   Restarting (ip l set dev wg0 down and up again) doesn't help. What
   helps is to change listening port to something else. This peer has a
   non-public and dynamic IP (but I have another client using the same
   provider on my OpenWRT router and it seems to work fine there)

Bug#930356: CVE-2019-12760

[Piotr Ożarowski]

Hi Andreas,

> > Please see https://bugzilla.redhat.com/show_bug.cgi?id=1718212
> > 
> > Patch is at https://gist.github.com/dhondta/f71ae7e5c4234f8edfd2f12503a5dcc7
> 
> I know you are usually pretty quick in solving serious issues.  I tried
> to check the issue and think the link provided for a patch is just
> pointing to a proof of concept exploit.  When reading the discussion
> here
> 
>https://github.com/davidhalter/parso/issues/75
> 
> I understand that it is not fixed but the authors do not consider the
> issue serious.  Could you please give some comment from an insiders
> point of view (which I'm not).  I'm just caring since several Debian
> Science dependencies are about to be removed from testing due to this
> bug.

I don't consider it that serious as well. I'll wait for upstream to
provide a proper fix. If there will be no such fix in time, I guess I can
just disable cache if security team insists.

> PS: Is there any reason why this package is not on Salsa and not
> team maintained?

that's because python-jedi is a mutli-tarball source package and parso
was part of it at the beginning. Last time I checked gbp didn't
support it (or I don't know how to use it) so it was easier for me to
keep it outside DPMT. I guess there's no reason not to move parso into
DPMT now.

Bug#926187: dh-python: dh_python3 replaces shebang with /usr/bin/python2 not /usr/bin/python3

[Piotr Ożarowski]

> To clarify, I meant that dh_python3 replaces the shebangs with
> /usr/bin/python2 (not /usr/bin/python) instead of /usr/bin/python3.

not a bug, it's a feature :)

If upstream claims it's for Python 2.X then that's what it is.
If it's not, use --shebang /usr/bin/python3


signature.asc
Description: PGP signature

Bug#920899: /usr/lib/pypy/ns/ vs. /usr/share/pypy/ns/

[Piotr Ożarowski]

> > It's using /usr/lib/pypy/ns/ the same way as we do in Python 2.
> 
> It's in /usr/lib/ not /usr/share/
> 
> I couldn't reasonably make pypy use /usr/ as it's prefix, without it
> finding cPython libraries. So the whole of pypy is in /usr/lib/pypy/.

pypy can be in /usr/lib/ and ns files in /usr/share/.
Why do you want them both in /usr/lib? I'm sorry I didn't double check
where /usr/bin/pypycompile searches for these files and assumed it's in
/usr/share, but could you follow other interpreters and read it from
/usr/share? This seems a better choice (FHS wise).
Note that there's already /usr/share/pypy/dist/ dir with pydist files…

patch attached :)
diff --git a/debian/changelog b/debian/changelog
index 6bade0b3..69248c65 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,12 @@
 pypy (7.0.0+dfsg-3) UNRELEASED; urgency=medium
 
+  [ Stefano Rivera ]
   * Update watch file regex, upstream calls it pypy2.7 now.
 
+  [ Piotr Ożarowski ]
+  * pypycompile and pypyclean now read namespaces from /usr/share/pypy/ns
+(to follow dh_pypy's suggested location)
+
  -- Stefano Rivera   Tue, 26 Feb 2019 16:38:55 -0800
 
 pypy (7.0.0+dfsg-2) unstable; urgency=medium
diff --git a/debian/scripts/pypyclean b/debian/scripts/pypyclean
index eaba24bd..83c89070 100755
--- a/debian/scripts/pypyclean
+++ b/debian/scripts/pypyclean
@@ -31,7 +31,7 @@ def package_modules(package):
 
 def installed_namespaces():
 '''Return a dictionary of package: frozenset(namespaces)'''
-ns_dir = '/usr/lib/pypy/ns'
+ns_dir = '/usr/share/pypy/ns'
 ns_by_pkg = {}
 for pkg in os.listdir(ns_dir):
 ns_file = os.path.join(ns_dir, pkg)
diff --git a/debian/scripts/pypycompile b/debian/scripts/pypycompile
index 42af3264..31abe2df 100755
--- a/debian/scripts/pypycompile
+++ b/debian/scripts/pypycompile
@@ -45,7 +45,7 @@ def generate_namespace_init(package, verbose):
 '''Iterate through a package's ns file.
 Create all necessary__init__.pys, and yield them.
 '''
-ns_file = os.path.join('/usr/lib/pypy/ns', package)
+ns_file = os.path.join('/usr/share/pypy/ns', package)
 if not os.path.exists(ns_file):
 return
 with open(ns_file) as f:

Bug#912892: pybuild confuses host and target

[Piotr Ożarowski]

Hi,

> | try:
> | # Set _PYTHON_HOST_PLATFORM to ensure debugging symbols on, f.e. 
> i386
> | # emded a constant name regardless of the 32/64-bit kernel.
> | env.setdefault(
> | '_PYTHON_HOST_PLATFORM',
> | 
> '{env[DEB_TARGET_ARCH_OS]}-{env[DEB_TARGET_ARCH]}'.format(env=env))
> | except KeyError:
> | pass
> 
> That's wrong. You're confusing host and target here. Please use
> DEB_HOST_* instead of DEB_TARGET_*. Refer to man 1 dpkg-architecture for
> their definitions.

I just applied your patch from 901759 and since I don't know much about
multiarch and you didn't change this part in your patch: is this still
valid? Should I replace DEB_TARGET with DEB_HOST in above snippet? 

Bug#921017: wireguard: doesn't always set all allowed-ips

[Piotr Ożarowski]

Package: wireguard
Version: 0.0.20190123-1
Severity: normal

Hi Daniel,

I have multiple peers defined in /etc/wireguard/wg0.conf
but setting AllowedIPs doesn't fully work for some of them
if I use `wg setconf`… and works perfectly fine if I do this
"manually" via `wg set wg0 peer my_public_key allowed-ips …`.

example peer setup in /etc/wireguard/wg0.conf:

 [Peer]
 PublicKey = my_public_key
 AllowedIPs = 10.8.1.2/32,10.1.0.0/20,10.0.0.0/20,192.168.6.0/24

and `wg setconf wg0 /etc/wireguard/wg0.conf && wg show wg0 allowed-ips | grep 
my_public_key`
outputs:

 my_public_key 192.168.6.0/24 10.8.1.2/32

(note missing 10.1.0.0/20,10.0.0.0/20)


Same thing happens if I use systemd-networkd to handle the interface
(/etc/systemd/network/wg0.netdev with "AllowedIPs = 
10.8.1.2/32,10.1.0.0/20,192.168.6.0/24,10.0.0.0/20")


It works for most peers (with multiple IPs/ranges) and
doesn't for two. I have to add missing ranges "manually" via
`wg set wg0 peer my_public_key allowed-ips 
192.168.6.0/24,10.8.1.2/24,10.1.0.0/20,10.0.0.0/20`
The other one that fails has one IP and one range in AllowedIPs so it's
not about more than 2 IPs/ranges.


FTR: I do not use wg-quick, I use either systemd-networkd or my own
startup script that basically does this:

 ip link add wg0 type wireguard
 ip addr add 10.8.1.1/24 dev wg0
 wg setconf wg0 /etc/wireguard/wg0.conf
 ip link set up dev wg0


PS thanks for maintaining WireGuard! I already replaced OpenVPN with it on all
   my machines :-)


-- System Information:
Debian Release: 9.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wireguard depends on:
ii  wireguard-dkms   0.0.20190123-1
ii  wireguard-tools  0.0.20190123-1

wireguard recommends no packages.

wireguard suggests no packages.

-- no debconf information

Bug#920277: bitlbee-plugin-facebook: doesn't work anymore

[Piotr Ożarowski]

Package: bitlbee-plugin-facebook
Version: 1.1.2-1
Severity: serious

Hi,

without this change¹ this package is no longer usable (due to some
changes on FB side). I suggest to package latest upstream snapshot as
other commits look useful as well.

[¹] 
https://github.com/bitlbee/bitlbee-facebook/commit/7682a3560c737fbbbd7cdf7a5b640bfb3242ec3c

Bug#918401: python-pygments must depend on python3-pygments (or a new package for pygmentize)

[Piotr Ożarowski]

Control: tag -1 + wontfix
Control: severity -1 normal

> Programs like pygmentize should be in an own package,
> not part of some module package.
>
> In any case python-pygments must depend on whatever package

I reported bugs in all packages that depend on python-pygments and were
using pygmentize. It's not my fault if your package didn't depend on the
right one (or had dependency via other package that happened to depend
on python-pygments)

I will definitely not add a dependency on python3-pygments in python-pygments
and I don't plan to add new binary package in the near future.

Bug#916072: mark python-chardet Multi-Arch: foreign

[Piotr Ożarowski]

> > python-chardet cannot be used to satisfy cross build dependencies (e.g.
> > for nagios-plugins-contrib via python-debian).
> 
> Thanks for the detailed explanation and the attached patch! It's fine
> for me, but I'm only an uploader of chardet so I will ping Piotr before
> applying it.

go ahead, I will not pretend I'm a multiarch expert ;)

Bug#917892: ptex2tex: /usr/bin/pygmentize moved to python3-pygments package

[Piotr Ożarowski]

Package: ptex2tex
Version: 0.4-1
Severity: normal

Dear Maintainer,

if the dependency on python-pygments is due to pygmentize script
(and latex/styles/minted.sty suggests that)
then please replace it with python3-pygments as that the package
that provides this script now. TIA

Bug#917890: nanoc: /usr/bin/pygmentize moved to python3-pygments

[Piotr Ożarowski]

Source: nanoc
Version: 4.11.0-1
Severity: normal

Dear Maintainer,

I moved /usr/bin/pygmentize script to python3-pygments package
and it looks like you used it in
nanoc/lib/nanoc/filters/colorize_syntax/colorizers.rb

Please update Depends so that this lib can find the right executable

Bug#917887: editra: please use packaged version of pygments

[Piotr Ożarowski]

Package: editra
Version: 0.7.20+dfsg.1-3
Severity: normal

Dear Maintainer,

Editra ships a copy of Pygments, please use the one from python-pygments
(or python3-pygments once it uses Python 3) instead of shipping local
copy of /usr/lib/python2.7/dist-packages/Editra/src/extern/pygments
or notify security team that you need this copy.

While we're at it, please also consider moving Editra into private
namespace (/usr/share/editra/) - let me know if you don't know how to do
this and I'll provide a patch.

Bug#917886: rst2pdf: /usr/bin/pygmntize binary moved to python3-pygments package

[Piotr Ożarowski]

Package: src:rst2pdf
Version: 0.93-6
Severity: normal

Dear Maintainer,

I moved /usr/bin/pygmntize script to python3-pygments binary package.
Please update your dependency.

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#915833: please follow Python policy guidelines and rename binary package name to python3-pytz

[Piotr Ożarowski]

Package: python3-tz
Version: 2016.7-0.3
Severity: wishlist

Hi,

Debian Python Policy suggests using module name for binary package
names, please follow this advice as it's very helpful
(I just spent over a minute trying to fugure out why `import tz` doesn't
work even though I installed python3-tz)

TIA

PS yeah, I hate module names with "py" prefix as well

Bug#914928: ITP: python-typing-extensions -- Backported and Experimental Type Hints for Python

[Piotr Ożarowski]

>  The typing module was added to the standard library in Python 3.5 on a
>  provisional basis and will no longer be provisional in Python 3.7. However,
>  this means users of Python 3.5 - 3.6 who are unable to upgrade will not be
>  able to take advantage of new types added to the typing module, such as
>  typing.Text or typing.Coroutine.

we will remove 3.6 from Debian soon, is it worth packaging it?
or are you targetting backports?

Bug#912865: ITP: mako - lightweight notification daemon for Wayland

[Piotr Ożarowski]

> There is already a python template library for python with the source
> package name mako- i'm not sure what the best namechange for the
> notification daemon could be? Should only the source packge be renamed
> or also the binary package? If the former, is mako-src to generic?

It's OK to choose mako for binary name as src:mako is
using python-mako, python3-mako and python-mako-doc.
(and /usr/bin/mako-render script so you're fine here as well).

I'd use mako-daemon or mako-wayland for source name

Bug#910284: dh_python3 --no-ext-rename does not work (Was: Bug#910284: r-cran-fastcluster does not build Python modules for all supported Python versions)

[Piotr Ożarowski]

Control: tags -1 -help
Control: tags -1 patch

> I tried to fix the issue reported below by using
>   dh_python3 --no-ext-rename
> (see [1]) but this has no effect and the resulting package just
> contains

well, --no-ext-rename should not be used for public modules (I cannot
imagine a single case where it's needed in dist-packages so I'll probably
disable it for public modules).

The fix:  ;)

You're missing python3-all-dev¹ build dependency so pybuild builds only
for the available interpreter, not for all supported ones.

[¹] and python-all-dev to be precise, python-dev covers all 2.X
interpreters, though
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#910025: matrix-synapse: depends on python-pysaml2 (>= 4.0.0) but 3.0.0-5 is available in Stretch (bpo)

[Piotr Ożarowski]

Package: matrix-synapse
Version: 0.33.4-1~bpo9+1
Severity: normal

Dear Maintainer,

I tried to install matrix-synapse on stretch (with stretch-backports)
but python-pysaml2 (>= 4.0.0) is not available.

(matrix-synapse : Depends: python-pysaml2 (>= 4.0.0) but 3.0.0-5 is to be 
installed)

Bug#901512: python3: Python doesn't register with the debian alternatives system

[Piotr Ożarowski]

Control: tags -1 +wontfix
Control: severity -1 wishlist

/usr/bin/python points to default Python 2.X version and we support python2.7 
only
right now. The only change planned for 2.X is to remove 2.7 from list of
supported 2.X versions.

Python 3 is a completely different language from our POV so
/usr/bin/python will never point to python3. When 2.7 will be removed
from supported versions - /usr/bin/python will disappear.

Bug#839786: sponsorship offer

[Piotr Ożarowski]

if someone picks this up, I'd be happy to help with Python bits and/or
sponsor this package. I can even maintain the Python parts if someone
takes care of JavaScript ones.

Bug#900526: testing of modules which rely on entry points is broken

[Piotr Ożarowski]

[Yaroslav Halchenko, 2018-05-31]
> I will meanwhile provide a workaround one way (skipping tests) or another
> (symlinking .egg-info may be), but it would be nice if pybuild --test handled
> those usecases smoother

is debian/pybuild.testfiles smooth enough?

(just put file/dir name there and pybuild will copy it to build
directory before tests and remove them before installing files)

Bug#894213: foo FTBFS with dh-python >= 3.20180313

[Piotr Ożarowski]

[Andreas Tille, 2018-04-30]
> On Mon, Apr 30, 2018 at 03:57:51PM +0200, Piotr Ożarowski wrote:
> > [Andreas Tille, 2018-04-30]
> > > >  PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3) ...
> > > I tried the same trick for snakemake in Git[1] but failed.
> > > 
> > > Am I missing something?
> > 
> > you changed PYTHONPATH, but PATH still hardcodes old path, I'd start
> > with that.
> 
> Hmmm, inside pbuilder chroot the files are installed to
> 
>   /build/snakemake-4.8.0/.pybuild/cpython3_3.6_snakemake/build/bin/snakemake
> 
> while
> 
>   # pybuild --print build_dir --interpreter python3
>   /build/snakemake-4.8.0/.pybuild/cpython3_3.6/build

you invoked it outside debian/rules, without --name or PYBUILD_NAME set,
right?

> I have no idea why since some dh-python version things are different
> than before but wouldn't it be the best idea to let pybuild set PATH and
> PYTHONPATH instead of setting it manually by some manual command?

I meant to fix also debian/rules line 11 (you fixed line 21 only)
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#894213: foo FTBFS with dh-python >= 3.20180313

[Piotr Ożarowski]

[Andreas Tille, 2018-04-30]
> >  PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3) ...
> 
> This worked nicely for python-skbio.
>  
> > I fixed few packages already, here's a list of other affected ones:
> > ...
> > snakemake   Debian Med Packaging Team
> 
> I tried the same trick for snakemake in Git[1] but failed.
> 
> Am I missing something?

you changed PYTHONPATH, but PATH still hardcodes old path, I'd start
with that.
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#894326: foo FTBFS with dh-python >= 3.20180313

[Piotr Ożarowski]

[Andreas Tille, 2018-04-26]
> some packages I maintain received this kind of bug in the case of
> python-skbio it is
> 
>ModuleNotFoundError: No module named 'skbio'
> 
> So the module that was just build is not found.  I guess this is due to
> some misuse of pybuild - but what did I wrong?  Python-skbio is available
> on Salsa[1] (updated to new upstream but with no change for the current
> problem).
> 
> Any hint how to fix this?

that's because I had to change pybuild's internal paths (to make it work
with multiple modules/packages at the same time).

I added --print option for those who really need it (f.e. while
building sphinx docs) - please use it instead of hardcoding pybuild's
internal paths.

You can use it like this:

 PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3) ...


I fixed few packages already, here's a list of other affected ones:

cypari2 Debian Science Team
keras   Debian Science Maintainers
khmer   Debian Med Packaging Team
macsDebian Med Packaging Team
numba   Debian Science Maintainers
numexpr Debian Science Maintainers
paleomixDebian Med Packaging Team
petsc4pyDebian Science Maintainers
pyosmiumDebian GIS Project
pysal   Debian GIS Project
python-gevent   Laszlo Boszormenyi
python-skbioDebian Med Packaging Team
rowsPaulo Roberto Alves de Oliveira
saltDebian Salt Team
slepc4pyDebian Science Maintainers
snakemake   Debian Med Packaging Team
statsmodels Debian Science Maintainers
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#883529: Buildbot maintenance by PAPT

[Piotr Ożarowski]

[Robin Jarry, 2018-02-27]
> after some discussions on https://bugs.debian.org/883529, Martin Borgert
> suggested that buildbot becomes maintained by the Python Applications
> Packaging Team.
> 
> That sounds like a good thing to have more than one person able to work
> on this package.
> 
> I am currently working on buildbot (both upstream dev and Debian
> packaging), I have read the Debian Python Policy and I'm not sure how to
> proceed for joining the PAPT.

great, just let me know if you accept our policy and I'll hit the button
(BTW, dh-python should be ready for builbot now, let me know if you need
more changes)
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#893693: fail2ban: uses pybuild's internal paths

[Piotr Ożarowski]

Package: fail2ban
Version: 0.10.2-1
Severity: important

Dear Maintainer,

Please apply attached patch to fix FTBFS with new dh-python.
Patch also adds missing dh-python to Build-Depends
commit 3080b5a15e02056fadffc9039dc24574588c72f5
Author: Piotr Ożarowski <pi...@debian.org>
Date:   Wed Mar 21 10:32:31 2018 +0100

do not use pybuild's internal paths

diff --git a/debian/control b/debian/control
index 77b32cb3..a4b4b6f4 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Priority: optional
 Maintainer: Yaroslav Halchenko <deb...@onerussian.com>
 Build-Depends:
  debhelper (>= 9)
+ , dh-python (>= 3.20180313~)
  , debhelper (>= 9.20160709) | dh-systemd
  , python3
  , python3-pyinotify
diff --git a/debian/rules b/debian/rules
index 77db4aa7..bb1e8af3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,6 @@ export PYBUILD_DISABLE_python2=1
 	dh $@ --with python3,systemd --buildsystem pybuild
 
 DESTDIR=$(CURDIR)/debian/fail2ban
-PYVERSION=$(shell py3versions -dv)
 
 override_dh_clean:
 	rm -rf fail2ban.egg-info
@@ -55,7 +54,7 @@ ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 	cd build && \
 	 LC_ALL=C.UTF-8 \
 	 FAIL2BAN_CONFIG_DIR="$(CURDIR)/config" \
-	 PYTHONPATH="$(CURDIR)/.pybuild/pythonX.Y_$(PYVERSION)/build/" \
+	 PYTHONPATH="$(shell pybuild --print build_dir --interpreter python3)" \
 	  scripts-*/fail2ban-testcases --no-network --verbosity=2
 endif
 

Bug#893692: bcolz: uses pybuild's internal paths

[Piotr Ożarowski]

Package: bcolz
Version: 1.1.0+ds1-5
Severity: important

Dear Maintainer,

Please don't use pybuild's internal paths. They did change recently and
they might change in the future, use pybuild's --print if you really
have to. See attached patch
commit e78665a2045be2ca3a31a6df747fd316a62f159c
Author: Piotr Ożarowski <pi...@debian.org>
Date:   Wed Mar 21 09:59:25 2018 +0100

do not hardcode pybuild's internal paths

diff --git a/debian/control b/debian/control
index 4fa5101..78d2746 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Debian Science Maintainers <debian-science-maintainers@lists.alioth.
 Uploaders: Daniel Stender <sten...@debian.org>
 Build-Depends:
  debhelper (>= 9),
- dh-python,
+ dh-python (>= 3.20180313~),
  python-all-dev,
  python3-all-dev,
  python-setuptools,
diff --git a/debian/rules b/debian/rules
index 8223ad1..dc1b667 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,8 +16,8 @@ export SETUPTOOLS_SCM_PRETEND_VERSION = $(VERSION_UPSTREAM)
 override_dh_auto_install:
 	dh_auto_install
 ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
-	cp .pybuild/pythonX.Y_*/build/bcolz/carray_ext*.so bcolz/
-	PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N docs/ debian/bcolz-doc/usr/share/doc/bcolz-doc/html/
+	PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3) \
+	http_proxy='127.0.0.1:9' sphinx-build -N docs/ debian/bcolz-doc/usr/share/doc/bcolz-doc/html/
 endif
 
 override_dh_installdocs:

Bug#893242: python-pygit2 FTBFS with dh-python 3.20180313

[Piotr Ożarowski]

Control: severity 893242 normal
Control: tags 893242 + wontfix

>   File "/usr/lib/python3.6/unittest/loader.py", line 451, in _find_test_path
> msg % (mod_name, module_dir, expected_dir))
> ImportError: 'test_archive' module incorrectly imported from 
> '/build/1st/python-pygit2-0.26.3/.pybuild/cpython3_3.6_pygit2/build/test'. 
> Expected '/build/1st/python-pygit2-0.26.3/test'. Is this module globally 
> installed?

I change the current directory to the build directory on purpose. I want
to test files that will be installed in the package, not the source
files and that's what happens if you start tests from source dir (due to
Python's "." in sys.path).

I'm amazed that even stdlib enforces such insane setting...

PS note that previous version of dh-python/pybuild also used build dir
as current directory

Bug#891331: Beta from SQLA are *not* to upload, and full of bugs

[Piotr Ożarowski]

[Thomas Goirand, 2018-02-24]
> Please upload a working version of SQLA in Experimental, for example 1.2.1,
> which is accepted by OpenStack, as per this document:

if 1.2.4 works in OpenStack, I will upload it directly into unstable. Is
that OK?

Bug#891214: src:linux: please build thunderbolt-net module

[Piotr Ożarowski]

Package: src:linux
Version: 4.15.4-1
Severity: wishlist

Dear Maintainer,

thunderbolt-net (CONFIG_THUNDERBOLT_NET) was introduced in Linux 4.15.
Please include it in Debian package.

TIA


PS thanks for doing such a great work with this package! :)

Bug#891210: tt-rss: please package new upstream release / snapshot

[Piotr Ożarowski]

Package: tt-rss
Version: 17.1+git20170410+dfsg-2
Severity: wishlist

Dear Maintainer,

Thank you for maintaining TT-RSS :)

Please package new upstream release or snapshot.

TIA

Bug#889508: hostapd: please consider adding systemd service template

[Piotr Ożarowski]

Package: hostapd
Version: 2:2.4-1+deb9u1
Severity: wishlist
Tags: patch

Dear Andrew,

Please consider replacing hostapd.service with hostapd@.service
template - this makes it a lot easier if you have multiple WLAN cards

Here's the template I use:

  [Unit]
  Description=Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP 
Authenticator (%I)
  After=network.target
  BindsTo=sys-subsystem-net-devices-%i.device

  [Service]
  EnvironmentFile=/etc/default/hostapd
  ExecStart=/usr/sbin/hostapd $DAEMON_OPTS /etc/hostapd/%i.conf
  Restart=on-failure
  RestartSec=1

  [Install]
  WantedBy=multi-user.target sys-subsystem-net-devices-%i.device


it assumes one will feed it with wlan interface name, f.e.

  $ systemctl start hostapd@wlan0.service

will read config data from /etc/hostapd/wlan0.conf which should contain
"interface=wlan0" and will be stopped automatically if wlan0 interface is no
longer available (I use it to disable hostapd if USB device is removed or start
hostapd when USB device is inserted)

Note that I also changed forking type & removed creating PID file since
systemd can handle all this stuff

DAEMON_OPTS from /etc/default/hostapd is shared in all instances (if one needs
more options)

It's probably also worth mentioning `systemctl enable hostapd@wlan0.service`
commnand in a README

Bug#777089: Next python-mote pre-condition - issue with pybuild: python-backports.tempfile conflicting python-backports.weakref

[Piotr Ożarowski]

> > > However, in Debian case, I do not know how this can be handled as
> > > 2 packages cannot hold the same file (even if __init__ is only an empty
> > > file), and at least one must be present (if you install only one).
> 
> The Python jargon is that the "backports" shared by backports.tempfile
> and backports.weakref is a "namespace package".
> 
> For Python 2, dh_python2 handles this: python-lazr.restfulclient and
> python-lazr.uri are an example of cooperating packages that share a
> namespace package.

FTR: If you want to use dh_python2's --namespace: make sure ALL packages
that share namespace use this feature and not a single one ships
__init__.py file.

> > I'm not a python expert but I expect the least-horrible way to do this
> > would be to ship a package that only contained the __init__. Then have
> > all the python-backports.* packages depend on it.
> 
> This is not necessary, and would probably (hopefully?) lead to rejection
> from the NEW queue.

I don't think it's a bad solution, I used it in the past for some
packages.
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#888014: ITP: python-backports.tempfile -- backports of new features in Python tempfile module

[Piotr Ożarowski]

FTR: you need to handle namespace in BOTH packages
(python-backports.weakref AND python-backports.tempfile)

Bug#777089: Next python-mote pre-condition - issue with pybuild: python-backports.tempfile conflicting python-backports.weakref

[Piotr Ożarowski]

[Andreas Tille, 2018-01-22]
> Hi,
> 
> I kept on working packaging python-moto predependencies.  I'm now
> stumbling upon python-backports.tempfile[1] and
> python-backports.weakref[2].  My naive packaging attempt puts
> the modules into
> 
>/usr/lib/python*/dist-packages/backports
> 
> leaving the same package
> 
>/usr/lib/python3/dist-packages/backports/__init__.py

if it's an empty file (or can be removed, as most probably in this case)
you can tell dh_python2 to handle the namespace for you with:

 override_dh_python2:
dh_python2 --namespace backports

For Python 3, __init__.py is not needed anymore, so you can simply
remove it in both packages by creating debian/python3-foo.pyremove file
with "backports/__init__.py"

> for both packages and thus the packages are conflicting.  I have no idea
> why pybuild simply uses the dir backports instead of the full module

that's how Python works, nothing to do with pybuild
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#777089: Please help with test suite error and installation problem of python-aws-xray-sdk (Was: If there is no response in debian-python then debian-science might be the right team)

[Piotr Ożarowski]

[Andreas Tille, 2018-01-15]
> Now I need to exclude those tests that try to access remote network
> locations but I failed with the same method as you proposed above.
> 
> Any clue how I can do that properly (please Git pull to see my failed
> attempts).

if you want to disable specific test (not the whole file) in pytest, use
"-k-somename" (note the "-" after "-k")
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#777089: Please help with test suite error and installation problem of python-aws-xray-sdk (Was: If there is no response in debian-python then debian-science might be the right team)

[Piotr Ożarowski]

[Andreas Tille, 2018-01-15]
>   1) test suite
> 
> I: pybuild base:184: cd 
> /build/python-aws-xray-sdk-0.95/.pybuild/pythonX.Y_2.7/build; python2.7 -m 
> pytest tests
> = test session starts 
> ==
> platform linux2 -- Python 2.7.14+, pytest-3.2.1, py-1.4.34, pluggy-0.4.0
> rootdir: /build/python-aws-xray-sdk-0.95, inifile:
> collected 57 items / 4 errors
> 
>  ERRORS 
> 
>  ERROR collecting 
> .pybuild/pythonX.Y_2.7/build/tests/test_async_local_storage.py.
> /usr/lib/python2.7/dist-packages/_pytest/python.py:395: in _importtestmodule
> mod = self.fspath.pyimport(ensuresyspath=importmode)
> /usr/lib/python2.7/dist-packages/py/_path/local.py:662: in pyimport
> __import__(modname)
> E File 
> "/build/python-aws-xray-sdk-0.95/.pybuild/pythonX.Y_2.7/build/tests/test_async_local_storage.py",
>  line 10
> E   async def _test():
> E   ^
> E   SyntaxError: invalid syntax

async (and all aio* libs in other tests) is not available in Python 2.7
so simply disable them. You can do this in debian/rules:

export PYBUILD_TEST_ARGS_python2=--ignore tests/test_async_local_storage.py 
--ignore tests/test_async_recorder.py --ignore tests/ext/aiobotocore/ --ignore 
tests/ext/aiohttp/


>   2) installation of the resulting package:
> 
> E:Sub-process /usr/bin/dpkg returned an error code (1)
> Traceback (most recent call last):
>   File "/usr/share/wajig/debfile-deps.py", line 56, in 
> main(sys.argv[1])
>   File "/usr/share/wajig/debfile-deps.py", line 48, in main
> cache.commit(apt.progress.text.AcquireProgress())
>   File "/usr/lib/python3/dist-packages/apt/cache.py", line 529, in commit
> raise SystemError("installArchives() failed")
> SystemError: installArchives() failed
> python-aws-xray-sdk (0.95-1) wird eingerichtet ...
>   File "/usr/lib/python2.7/dist-packages/aws_xray_sdk/core/async_context.py", 
> line 14
> def __init__(self, *args, loop=None, use_task_factory=True, **kwargs):
>  ^
> SyntaxError: invalid syntax
> 
>   File 
> "/usr/lib/python2.7/dist-packages/aws_xray_sdk/core/async_recorder.py", line 
> 20
> async def wrapper(wrapped, instance, args, kwargs):
> ^
> SyntaxError: invalid syntax
> 
>   File 
> "/usr/lib/python2.7/dist-packages/aws_xray_sdk/ext/aiobotocore/patch.py", 
> line 30
> async def _xray_traced_aiobotocore(wrapped, instance, args, kwargs):
> ^
> SyntaxError: invalid syntax
> 
>   File 
> "/usr/lib/python2.7/dist-packages/aws_xray_sdk/ext/aiohttp/middleware.py", 
> line 11
> async def middleware(app, handler):
> ^
> SyntaxError: invalid syntax

similar issue here, async stuff will not work in 2.7, you can tell
dh_python2 to remove these files by adding
debian/python-aws-xray-sdk.pyremove file containing:

  aws_xray_sdk/core/async_*
  aws_xray_sdk/ext/aiobotocore/
  aws_xray_sdk/ext/aiohttp/

-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#795261: add a warning for stripped python-*-dbg packages

[Piotr Ożarowski]

> I currently don't have an example. But that would be a package that has a -dbg
> *and* a -dbgsym package. Maybe Piotr could elaborate if pybuild now handles 
> the
> case correctly, and then maybe just close the issue?

pybuild just invokes -dbg interpreter to build extension, It doesn't
know anything about binary packages unless --name option (AKA
PYBUILD_NAME) is set but then it uses it only to set the right DESTDIR
(f.e. debian/python3-foo-dbg/). It doesn't interact with dh_strip or
anything like that. 

If there's a way to instruct debhelper (via buildsystem) to never ever
create -dbgsym packages for given package (100% binary packages that
start wit python- or python3- AFAICT) then please let me know and I will
implement it.
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#812228: what if $DPKG_MAINTSCRIPT_ARCH is empty

[Piotr Ożarowski]

FTR: (as I had to dig into my branch comments to see why I didn't merge it)

What if $DPKG_MAINTSCRIPT_ARCH is empty?

Bug#873965: not a bug

[Piotr Ożarowski]

Hi,

you want to run tests from source package's root directory, right?

The directory contains "aiohttp" subdir with __init__.py file...
you try to test installed module but Python gives preference to the
files in current directory so installed module and extension are
ignored.

Bug#769380: python3-mako: Please make the package multi-arch compatible

[Piotr Ożarowski]

> So, Piotr, do you think that any of the options is preferable?
> 
> If there's no reply I'd like to upload an NMU with a fix for this
> problem.
> 
> I think that changing the package to "Architecture: any" and "M-A: same"
> is safer than dropping a dependency to recommends.  It's not ideal, but
> in the end is just causes a small overhead, and changing dependencies
> can even break reverse-depends and introduce bugs difficult to detect.

please point me to the policy if it's already known what's the right
approach

Bug#879934: pdfrw: please upgrade to 0.4 (needed for Python 3.X)

[Piotr Ożarowski]

Source: pdfrw
Version: 0.3-1
Severity: normal

Dear Maintainer,

Please upgrade pdfrw to 0.4 as previous version do not work properly
with Python 3.X (I'm getting tracebackng about bytes vs str)

Bug#879927: webassets: please upgrade to 0.12.1

[Piotr Ożarowski]

Source: webassets
Version: 4
Severity: normal

Dear Maintainer,

Please upgrade webassets to 0.12.1 as previous versions do not work with
Jinja 2.9. See the fix¹ or bug report² for details.

TIA

[¹] 
https://github.com/miracle2k/webassets/commit/f11f7d300a539caead81fc28b01f760e6c3c9409
[²] https://github.com/miracle2k/webassets/issues/477

Bug#879203: RFP: redisearch -- search engine on top of Redis

[Piotr Ożarowski]

> > > Hm, do we even *want* autoloading modules? I'm not 100% sure we do. I 
> > > guess
> > > it does not block the packaging anyway...
> > 
> > as an upstream I'd go even further and make it possible to block loading
> > modules from client (runtime), but that's probably just me.
> 
> I don't 100% understand what you mean; can you clarify? :)

I compiled the module and was able to load it as any user from any
location (well, OK - I needed to know Redis' login/password, if set),
but still, that is not something I (as a sys admin) would want.

Anyway, that's something that should be discussed on the upstream
mailing list, not here, so ignore me.

Bug#879203: RFP: redisearch -- search engine on top of Redis

[Piotr Ożarowski]

[Chris Lamb, 2017-10-24]
> Am happy to package this, and probably makes sense as the Redis
> maintainer anyway.
> 
> > I chose redis-modulename as binary package name
> 
> So, "redis-redisearch". The only problem is that this *somewhat*
> collides with other packages in this namespace, such as redis-sentinel
> and redis-tools (which are not modules). So, one alternative might be
> "redis-module-redisearch" or "redis-modules-redisearch" but I find
> them to be a little too ugly.

or there can be few exceptions from the rule, just like we have
"python-all" in Python

> > /usr/lib/redis/ but maybe /usr/lib/redis/modules/ is a better idea.
> 
> /usr/lib/redis/modules/ wfm. (We don't need to gnu-triplet-these for
> multiarch do we?)

If upstream supports it (IIRC I saw it somewhere, but it might be
ramp-packer only) that would be great, but I'm afraid it's not the case
yet.

> > so support for /etc/redis/conf.d/ or autoloading modules from given dir
> 
> Hm, do we even *want* autoloading modules? I'm not 100% sure we do. I guess
> it does not block the packaging anyway...

as an upstream I'd go even further and make it possible to block loading
modules from client (runtime), but that's probably just me.

Bug#879203: RFP: redisearch -- search engine on top of Redis

[Piotr Ożarowski]

CCing redis maintainer as there's probably a need for Redis module
naming policy (I chose redis-modulename as binary package name).

Please also note that there's no standard module directory, at least
upstream doesn't define one AFAICT so I chose
/usr/lib/redis/ but maybe /usr/lib/redis/modules/ is a better idea.

There's also no mechanism to autoload installed module that maintainer
or system admin can use other than editing /etc/redis/redis.conf
(and add "loadmodule /usr/lib/redis/redisearch.so" there) so support for
/etc/redis/conf.d/ or autoloading modules from given dir at startup
would be great (can we request that upstream?)

Bug#879203: RFP: redisearch -- search engine on top of Redis

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist

* Package name: redisearch
  Version : 0.21.3
  Upstream Author : Redis Labs
* URL : http://redisearch.io/
* License : AGPL
  Programming Lang: C
  Description : search engine on top of Redis

 Unlike other redis search libraries, it does not use internal data
 structures
 like sorted sets.
 .
 Inverted indexes are stored as a special compressed data type that
 allows for
 fast indexing and search speed, and low memory footprint.
 .
 This also enables more advanced features, like exact phrase matching and
 numeric filtering for text queries, that are not possible or efficient
 with
 traditional redis search approaches.


suggested binary package name: redis-redisearch
suggested module location: /usr/lib/redis/redisearch.so

Note that tests require Python's rmtest library which is not yet
packaged in Debian

I'm attaching debian/control and debian/rules file I used to test this
module.
Source: redisearch
Section: database
Priority: optional
Maintainer: Your Name 
Build-Depends: debhelper (>= 10)
Standards-Version: 4.1.0
Homepage: http://redisearch.io/

Package: redis-redisearch
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, redis-server (>= 4:4.0)
Description: search engine on top of Redis
 Unlike other redis search libraries, it does not use internal data structures
 like sorted sets.
 .
 Inverted indexes are stored as a special compressed data type that allows for
 fast indexing and search speed, and low memory footprint.
 .
 This also enables more advanced features, like exact phrase matching and
 numeric filtering for text queries, that are not possible or efficient with
 traditional redis search approaches.
#!/usr/bin/make -f

%:
dh $@

override_dh_auto_clean:
dh_auto_clean
find $(CURDIR) -name '*.pyc' -delete
find $(CURDIR)/src/tests/ -type f -executable -delete

override_dh_auto_test:
# disabled due to missing rmtest (and ramp-packer?) Python modules in 
Debian

override_dh_auto_install:
dh_install src/redisearch.so /usr/lib/redis/

Bug#874214: src:python-pathlib: please add python3-pathlib binary package

[Piotr Ożarowski]

Package: src:python-pathlib
Version: 1.0.1-2
Severity: normal
Tags: patch

Hi,

I know pathlib is deprecated, but one of the libraries I consider
packaging is requiring pathlib (and it's Python 3.X only).

Please consider adding python3-pathlib binary package, see attached
patch.
diff -Nru python-pathlib-1.0.1/debian/changelog 
python-pathlib-1.0.1/debian/changelog
--- python-pathlib-1.0.1/debian/changelog   2015-06-25 10:02:25.0 
+0200
+++ python-pathlib-1.0.1/debian/changelog   2017-09-04 11:51:22.0 
+0200
@@ -1,3 +1,9 @@
+python-pathlib (1.0.1-3) UNRELEASED; urgency=medium
+
+  * Add python3-pathlib binary package
+
+ -- Piotr Ożarowski <pi...@debian.org>  Mon, 04 Sep 2017 11:51:22 +0200
+
 python-pathlib (1.0.1-2) unstable; urgency=medium
 
   * Enable reproducible build py patching generation of manpage
diff -Nru python-pathlib-1.0.1/debian/control 
python-pathlib-1.0.1/debian/control
--- python-pathlib-1.0.1/debian/control 2015-06-24 15:38:23.0 +0200
+++ python-pathlib-1.0.1/debian/control 2017-09-04 11:51:22.0 +0200
@@ -5,6 +5,7 @@
 Build-Depends: debhelper (>= 9),
dh-python,
python-all (>= 2.6.6-3~),
+   python3-all,
python-sphinx
 X-Python-Version: >= 2.6
 Standards-Version: 3.9.6
@@ -27,6 +28,22 @@
  .
  This is the Python 2 version of the package.
 
+Package: python3-pathlib
+Architecture: all
+Depends: ${misc:Depends}, ${python3:Depends}
+Description: set of Python 3 classes to handle filesystem paths
+ Pathlib offers a set of classes to handle filesystem paths.
+ It offers the following advantages over using string objects:
+ .
+  * No more cumbersome use of os and os.path functions. Everything
+can be done easily through operators, attribute accesses, and method calls.
+  * Embodies the semantics of different path types. For example,
+comparing Windows paths ignores casing.
+  * Well-defined semantics, eliminating any warts or ambiguities
+(forward vs. backward slashes, etc.).
+ .
+ This is the Python 3 version of the package.
+
 Package: python-pathlib-doc
 Architecture: all
 Section: doc
diff -Nru python-pathlib-1.0.1/debian/rules python-pathlib-1.0.1/debian/rules
--- python-pathlib-1.0.1/debian/rules   2015-06-24 15:38:23.0 +0200
+++ python-pathlib-1.0.1/debian/rules   2017-09-04 11:51:22.0 +0200
@@ -6,7 +6,7 @@
 BUILD_DATE=$(shell LC_ALL=C date -u "+%B %d, %Y" -d "$(LAST_CHANGE)")
 
 %:
-   dh $@ --with python2,sphinxdoc --buildsystem=pybuild
+   dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_clean:
dh_auto_clean

Bug#873680: gaupol: Gtk-WARNING warnings in gaupol

[Piotr Ożarowski]

Control: tags -1 unreproducible

> I get the following message each time I start gaupol and get constant
> reminders on the console  -
> 
> (python3:12069): Gtk-WARNING **: Allocating size to
> GtkApplicationWindow 0x55e19b4ea2c0 without calling
> gtk_widget_get_preferred_width/height(). How does the code know the
> size to allocate?

I cannot reproduce it, tried on unstable and stable

Bug#873496: src:mediagoblin: 1001_fix_exception_syntax.patch is broken

[Piotr Ożarowski]

Package: src:mediagoblin
Version: 0.9.0~dfsg-1~exp2
Severity: normal

Hi,

"except ldap.LDAPError, e:" wasn't meant as multiple exceptions, "e" is
ldap.LDAPError's instance name - syntax used in Python 2.X, no longer
available in Python 3.X - comma is replaced with "as" keyword, also
backported to 2.7 so you can safely use:

- except ldap.LDAPError, e:
+ except ldap.LDAPError as e:

Bug#865805: new upstream release fixes 865805

[Piotr Ożarowski]

Hi,

It FTBFS (fails to build from source) due to my recent python3-aiohttp
upload (2.X). New upstream release of aiohttp-cors (0.5.2) fixes it.

Please prepare 0.5.3 (even newer) upload and send me RFS email.

Bug#864868: installer blocks if previously chosen swap is not encrypted

[Piotr Ożarowski]

Package: debian-installer
Version: 20170608
Severity: normal

Hi,

I tested firmware-stretch-DI-rc5-amd64-netinst.iso yesterday and it
didn't allow me to continue installation without swap partition on an
encrypted disk if a swap partition on another unencrypted disk was
previously selected. Deselecting it before setting up encrypted disk
fixes it, but I had to restart the whole installation and deselect old
disk's swap partition before configuring the new disk.

to reproduce:
* start the installation on a system with a working, unencrypted swap partition
* let partman (?) autoselect old swap partition (I had it on an old hdd)
* setup encrypted disk without swap
* deselect swap partition from the old disk (after a warning from DI)
* try to continue (a message that swap is on an non-encrypted partition
  will show up even after deselecting it)


PS my first try was with firmware-stretch-DI-rc5-amd64-DVD-1.iso
(via DriveDroid on Android phone) but it didn't start: there's only a
grub prompt, without any menu. netinst version mentioned above worked
fine with DriveDroid.


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Laptop: Lenovo W540. secure boot disabled in BIOS, UEFI enabled, with
legacy mode (priority set to UEFI)

Bug#856610: unblock: sqlalchemy/1.1.5+ds1-1

[Piotr Ożarowski]

Control: tags -1 - moreinfo

> that's because Thomas overwrote my NMU with another upload, please give
> me some time to talk with him

Thomas added my changes back, all 3 OpenStack packages have ">="
dependency only (no "<<" anymore)

Bug#856610: unblock: sqlalchemy/1.1.5+ds1-1

[Piotr Ożarowski]

[Niels Thykier, 2017-04-03]
> > unblock sqlalchemy/1.1.5+ds1-1
> > unblock murano/1:3.0.0-3.1
> > unblock ceilometer/1:7.0.1-1.1
> > unblock mistral/3.0.0-2
> > 
> 
> I cannot exactly say I am trilled with this change.  But starting from
> the bottom, something is definitely wrong.  AFAICT, the latter 3
> packages in your unblock request fail piuparts tests because they cannot
> be installed with the following:
> 
> """
>   The following packages have unmet dependencies:
>piuparts-depends-dummy : Depends: python-sqlalchemy (< 1.1.0) but
> 1.1.6+ds1-1 is to be installed
>   E: Unable to correct problems, you have held broken packages.
> """
> 
> That suggests to me that this unblock request cannot succeed in its
> current form.  These 3 openstack packages have other bugs that would be
> great to have fixed in testing (a nettools dependency issue), so I would
> be glad if that part could get solved.

that's because Thomas overwrote my NMU with another upload, please give
me some time to talk with him

Bug#858012: minidlna: wrong config option name in debian/NEWS

[Piotr Ożarowski]

Package: minidlna
Version: 1.1.6+dfsg-1
Severity: wishlist

Hi,

I think you want to s/turn media_dirs on./turn wide_links on./
in debian/NEWS file.

Bug#856610: unblock: sqlalchemy/1.1.5+ds1-1

[Piotr Ożarowski]

FYI: I plan to upload sqlalchemy 1.1.6+ds1-1 (i.e. a new upstream
release in 1.1.X series). I assume if you will allow 1.1.5, then there's
no reason to not allow 1.1.6 - i.e. next bug fix release in 1.1 series.

Note that upstream already started working on 1.2 series which I'm not
considering for Stretch - these one gets new features and f.e. drops
Python 2.6 (which we don't support since a long time, but still) - my
point is: upstream is sane.
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#857273: pygments: Provide pygmentize in the Python 3 binary package

[Piotr Ożarowski]

[Ghislain Antony Vaillant, 2017-03-09]
> The pygmentize console script is currently provided by the Python 2
> binary package. However Python 2 support will be dropped for the Buster
> cycle.
> 
> Please consider moving the pygmentize console script from
> python-pygments to python3-pygments, so that packages depending on this
> specific script (such as Pweave) can be free of Python 2 dependencies.

will do in first Buster upload

Bug#856926: Processed: rekall: package not installable after no-change rebuild

[Piotr Ożarowski]

rekall's setup.py contains¹ (in install_requires):

 "pycrypto == 2.6.1"

which is translated by dh_python2 into "python-crypto (= 2.6.1)"
(translating == into = and not simply ignoring it, or replacing with
">=" which is IMO the least problematic solution, is a new thing
introduced in dh-python 2.20170125, I'm not a big fan of it but
apparently it's what maintainers want)

Why pycrypto is translated and other requirements not?
That's because pycrypto (Debian) maintainer flagged² pycrypto's
versioning as compatible with Debian's (it's disabled by default, you
can `dh_python2 --accept-upstream-versions` if you want that behaviour
with other modules/requirements)

What to do to fix it?
* patch setup.py to replace == with >= or remove version completly, no
  matter what's the outcome of next point:
* start a thread on debian-python@l.d.o abuot what to do with ==
  (ignore? translate into =, translate into >=)

[¹] 
https://sources.debian.net/src/rekall/1.6.0%2Bdfsg-1/rekall-core/setup.py/#L61
[²] 
https://sources.debian.net/src/python-crypto/2.6.1-7/debian/python-crypto.pydist/

Bug#856610: unblock: sqlalchemy/1.1.5+ds1-1

[Piotr Ożarowski]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package sqlalchemy 1.1 - it was in unstable for a very
long time and was my plan to ship it in Strech since the first beta
release of 1.1.0. Upstream author provides best unit test coverage I've
seen in an Open Source project and cares about stability and
compatibility a lot (+ provides very detailed migration guides).
A lot of packages needed an update for 1.1 but it was mostly a rebuild & check
(I was generating << X.Y+1 dependency for each package that depended on
X.Y release before 1.1 one), this work was done long before freeze.
It was supposed to be done even sooner, but I kept it in experimental
for over a month due to miscommunication with another developer.
I've missed few packages (and was busy with RL) so it didn't propagate
to testing on time. Packages that blocked the migration are: ceilometer,
murano, ceilometer and mistral - see below.

ceilometer and murano NMUs have just a requirements.txt tiny patch to
drop << 1.1 dependency. requirements.txt is used in Python world for
recommended env. (in contrast to setup.py's requires.txt which is
supposed to list minimum required dependencies) - unfortunately
OpenStack upstream decided to not bother with it and just copy
requirements.txt into requires.txt - a lot of OS packages were patched
for this reason (thanks to OS team!), unfortunately I've missed two.

mistral 3.0.0-2 was uploaded on 24 Oct 2016 with sqlalchemy >= 1.1
dependency so it didn't migrate to testing due to missing SA 1.1

All other python-sqlalchemy and python3-sqlalchemy rev. dependencies are
already in testing because, as I mentioned before, sqlalchemy no longer
generates (via dh_python{2,3}) <

signature.asc
Description: PGP signature

Bug#855537: ITP: aiohttp-cors -- Cross Origin Resource Sharing (CORS) support for aiohttp

[Piotr Ożarowski]

Hi Brandon,

> https://mentors.debian.net/debian/pool/main/a/aiohttp-cors/aiohttp-cors_0.5.0-1.dsc

even though upstream claims this module works with Python 3.4.1, it
requires at least Python 3.5 (due to "typing" module which is not
present in 3.4) so please bump X-Python3-Version to >= 3.5 and ping me¹.

PS there's DPMT in (commented out) Vcs-* fields - let me know if you
   read our police and want to join the team
PPS I'm interested in homeassistant so feel free to send me RFS
email¹ for any package related to this project

[¹] https://people.debian.org/~piotr/sponsor

Bug#852908: mako: FTBFS: Test failures

[Piotr Ożarowski]

> The failure is caused by the recent upload of pygments 2.2.0. With this new
> release the 'u' prefix is omitted from the rendered utf8 strings, as in:
>  
> while pygments 2.1.3 gives:
>  u

hmmm... that's weird as my first thought was it was due to new pygnents
so I tested it with old one and it failed as well... I probably messed
it somehow. Thanks for the patch!

Bug#744741: egg-info and Debian-specific submodule packages

[Piotr Ożarowski]

[Luke W Faraone, 2017-01-30]
> In bug #744741[1], we have a report where a lack of ``egg-info`` metadata 
> breaks
> both ``pip``'s installation detection and packages that use ``pkg_resources`` 
> to
> discover dependencies.
> 
> Usually, the answer would be simple: ship the ``egg-info`` metadata as part of
> the package. But PySide is distributed upstream[2] and via PyPI[3] as one
> monolithic package. Debian splits that out into 14 packages, ``python-
> pyside.phonon``, ``python-pyside.qtcore``, ``python-pyside.qtdeclarative``, 
> etc.
> 
> So, should we ship the egg-info files in a common package, as Barry
> suggested[4], and make each of the submodules depend on it? This has the

there's already python-pyside and python3-pyside that depend on all
other subpackages. Upstream expects pkg_resources.require('PySide') to
confirm that all of them are installed (as otherwise there would be
more egg-infos) so the answer is simple: ship it in python-pyside and
python3-pyside.

> unfortunate side-effect of breaking third-party packages that attempt to 
> detect
> whether PySide is installed.
> 
> Alternatively, we could only distribute it as part of ``python-pyside`` (a
> metapackage), but this would require patching to some Debian-distributed
> packages such as ``yubikey-piv-manager``.

yubikey-piv-manager can either depend of python-pyside or remove PySide
from setup.py in order to keep (in Depends) python-pyside.qtgui and
python-pyside.qtnetwork only, yes

> A third option would be to ask upstream to split out the packages as we have
> done -- that would resolve the conflict in this instance, but not the general
> issue, and would probably take a lot of effort (or be rebuffed).

even more eggs? Please no.
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#852428: dh-python: dh_python* should examine requirements.txt instead of/in addition to requires.txt

[Piotr Ożarowski]

Control: tags 852428 +wontfix
Control: severity 852428 wishlist

> The pip documentation
> (https://pip.pypa.io/en/stable/user_guide/#requirements-files)
> discusses requirements files and names them requirements.txt rather
> than requires.txt.  dh_python2 and dh_python3 both look at
> requires.txt instead; it would make sense for them to look for
> requirements.txt as well, rather than having to manually specify this
> in the package build.

no, that's not what requirements.txt is for. See
https://caremad.io/posts/2013/07/setup-vs-requirement/

Bug#851741: python-jinja2: New major version breaks ansible templates

[Piotr Ożarowski]

Hi Jeremy,

[Jeremy Bicha, 2017-01-18]
> The new version of jinja2 breaks several templates used by ansible.
> 
> Please see https://github.com/ansible/ansible/issues/20063
> 
> I stumbled across this when using debops:
> https://github.com/debops/ansible-postfix/issues/84

could you check if this commit fixes it for you?
https://github.com/pallets/jinja/commit/c6ddeb7d5f64789ed0bbc1ffef8596a79bc06fd9

Bug#808654: Bug #808654 closed accidentally (it seems)

[Piotr Ożarowski]

> Hello Piotr. For reasons I still don't understand, your commands
> above made the bug to be closed.

the bug was actually not in fedmsg but in moksha.hub and I fixed it in 1.4.1-2 
(hence different source package/version that was closing bug).

I just checked (build logs you pointed me to are really old, before my
fix) and this package still FTBFS but for a completely different reason
(I guess it's OK to reopen this one as the final result is the same - it
doesn't build)

Bug#851413: gertty: Uninstallable in Debian Unstable

[Piotr Ożarowski]

[Axel Beckert, 2017-01-14]
> gertty is uninstallable in Debian Unstable (but not in Debian Testing)
> since it depends on python-sqlalchemy (< 1.1), but Debian Unstable
> currently contains python-sqlalchemy at version 1.1.4+ds1-1.

I uploaded rebuilt version to DELAYED/2

I don't know why I missed this one, it's in my SA 1.1 transition file...
but marked as one without << 1.1...

> This is probably also the reason why python-sqlalchemy >> 1.1 never
> migrated to testing despite it's considered a valid candidate:
> https://qa.debian.org/excuses.php?package=sqlalchemy

yeah, this page is not really helpful...

Bug#849195: ITP: uvloop -- fast implementation of asyncio event loop on top of libuv

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ożarowski <pi...@debian.org>

* Package name: uvloop
  Version : 0.6.7
  Upstream Author : Yury Selivanov <y...@magic.io>
* URL : http://github.com/MagicStack/uvloop
* License : MIT
  Programming Lang: Python
  Description : Fast implementation of asyncio event loop on top of libuv

 uvloop is a fast, drop-in replacement of the built-in asyncio
 event loop. uvloop is implemented in Cython and uses libuv
 under the hood. It makes asyncio 2-4x faster.

Binary package names: python3-uvloop python3-uvloop-dbg

Bug#844408: Request to join the team

[Piotr Ożarowski]

> I hereby request to join the team, I want to maintain my package
> python-mimeparse here. My Alioth login is mathiasertl-guest. I naturally
> accept the policy document at [1].

welcome :)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#740161: patch for 740161

[Piotr Ożarowski]

> > Please let me know if there's something wrong with my last patch
> > (https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=740161;filename=740161.patch;msg=21)
> > and I will try to update it.
> > 
> Jakub Wilk had some remarks in comment #10[1], which I presume is
> relevant for this bug being reopened. Long story short, the file your
> patch touched is auto-generated and manual changes to it are lost.

my second patch also updates data/debhelper/dh_commands-manual

I'm attaching one without data/debhelper/dh_commands (if that's the
problem)
commit 20c7b86cf98e803af9d97938870399e1c5e7d482
Author: Piotr Ozarowski 
Date:   Thu Dec 1 18:39:34 2016 +0100

dh_python{2,3} are now in dh-python package

python package provides an older copy of dh_python2 (and a wrapper that
detects dh-python build dependency) and python3 package depends on
dh-python but I'd like to drop both of these transitional workarounds at
some point (when all packages build depend on dh-python)

diff --git a/data/debhelper/dh_commands-manual b/data/debhelper/dh_commands-manual
index 9d2ccc1..d9769e5 100644
--- a/data/debhelper/dh_commands-manual
+++ b/data/debhelper/dh_commands-manual
@@ -17,8 +17,8 @@ dh_autoreconf_clean||dh-autoreconf | debhelper (>= 9.20160403~)
 dh_autoreconf||dh-autoreconf | debhelper (>= 9.20160403~)
 dh_lv2config||lv2core
 dh_nativejava||gcj-native-helper | default-jdk-builddep
-dh_python2||python:any | python-all:any | python-dev:any | python-all-dev:any
-dh_python3||python3:any | python3-all:any | python3-dev:any | python3-all-dev:any
+dh_python2||dh-python
+dh_python3||dh-python
 dh_sphinxdoc||python-sphinx | python3-sphinx
 dh_systemd_enable||debhelper (>= 9.20160709~) || dh-systemd
 dh_systemd_start||debhelper (>= 9.20160709~) || dh-systemd