Acceptance of team policy

2016-08-10 Thread Dominik George
Hi,

of course, I have read and accept the DPMT policy.

I have also already workde with gbp in the way described in the policy.

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

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


Re: Maintenance of new Flask extensions

2016-08-10 Thread Dominik George
Hi Ondrej,

> I'm Flask Debian packaging maintainer. Not much to do with packaging, but
> help is always welcome.
> 
> > I would initially like to add these two extensions:
> >   Flask-Restless
> >   Flask-Compress
> >   Flask-LDAPConn
> 
> go ahead and pack it under DPMT.

Alright, thanks!

> 
> > Also, I would like to help fix open bugs in existing Flask packages.
> 
> which bugs? Flask package is bug-free :)
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=flask

I wasn't talking about Flask core, but the other extensions packaged in 
Debian. Flask-RESTful, for example, has some open RC bugs and is marked for 
autoremoval from testing.

> 
> If the DPMT is willing to co-maintain the new packages, I would like to keep
> > the package repositories and the like in DPMT from the beginning.
> 
> every help is welcome!
> 
> > Please tell me if it is ok to ask for team membership on Alioth ☺! My
> > username
> > there is natureshadow-guest.
> 
> https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin

I have tried to request team membership, and found that I already requested 
that (probably some years ago) and the request is still pending.

> 
> Thanks for your interest, maybe you could join our IRC (#debian-python). My
> nickname is onovy.

Joined it ☺.

Cheers,
Nik



-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

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


Bug#833920: ITP: flask-restless -- Flask extension which provides simple generation of ReSTful JSON APIs

2016-08-10 Thread Dominik George
Package: wnpp
Severity: wishlist
Owner: Dominik George <n...@naturalnet.de>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: flask-restless
  Version : 1.0.0b1
  Upstream Author : Jeffrey Finkelstein
* URL : https://github.com/jfinkels/flask-restless
* License : BSD or AGPLv3+
  Programming Lang: Python
  Description : Flask extension which provides simple generation of ReSTful 
JSON APIs

Flask-Restless is a Flask extension that provides simple generation of
ReSTful APIs that satisfy the JSON API specification given database
models defined using SQLAlchemy (or Flask-SQLAlchemy).


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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJOBAEBCAA4BQJXqxErMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYjLg//Q5Lx+NuPAf0YcHNw1QIy
bnh2tH5Qwd1sJ3nwTl4JYdDecUL5sm8m7oEBPThD/5uOi7Hu6e27W4P5x+YRCGTy
uBfu03n+btzCP85rTgQBINbbK3RpIxIiXOGf2WbKwHyex+ibTW6DzuHZ5otvLeJI
Ag6q+oRLOoTnqOjYWc3ul9uNw8U+pRpvig1KXQEN8XzwL3cPWLEA5vn5R001e0rh
vwKkvMv45ehzYhxlhwfSxrxIem28cs6q4U3BINXKOJj2t1HrN7PmYjQsprPY+z+D
hLg6zg3IsQlLAoWSDIjA9liwshNnf0IQzdtlDh32E/HwEnQp2UhPoSsuST1cuKiE
zwCjF2G4M4x+zQIsqg2xIrMRYr3OmWCqqAOrg7WzCM75hdF5iiSUEjIoGuD2sVl2
hO6zKOwiRbBWRgqj69+PxYL2mAOMewXGTmI21fd3PoXItU9yVFZ0cKX58VpqfmP7
lHxJvBO0fcLpxJ6bUk48GJG/fffsY5zAwwbdhlJgNNGmeCdHtU4OUfeMIngJwJ7v
kNHNIrUeGqtM89sYZ316RVGquRD7XPfpiywphSwE12G/4j6Zm6r/wOifQZYI2LML
cqcdZ4vNWVFMMoxfOUqGK+F8QVvxwGCooKq83IOm1FjCVM18JiF8L+xpQ0BS8yV9
1uhUG5WybIpIH2XnOBd2ycA=
=k0lG
-END PGP SIGNATURE-



Bug#833921: ITP: flask-compress -- Compress responses in your Flask app with gzip

2016-08-10 Thread Dominik George
Package: wnpp
Severity: wishlist
Owner: Dominik George <n...@naturalnet.de>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: flask-compress
  Version : 1.3.0
  Upstream Author : William Fagan
* URL : https://github.com/wichitacode/flask-compress
* License : MIT
  Programming Lang: Python
  Description : Compress responses in your Flask app with gzip

Flask-Compress allows you to easily compress your Flask application's
responses with gzip.

The preferred solution is to have a server (like Nginx) automatically
compress the static files for you. If you don't have that option
Flask-Compress will solve the problem for you.


In intend to maintain the package within the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJOBAEBCAA4BQJXqxMoMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8paToA/+PKT9Bm9JXiTKbbyGZg9R
3QXR6ulc7BpihiPHpBQTt8nFKZGhuCyTxkJfQPnx/uZLGHqV72tmqyNLA2P9EgT3
gc3Nbst1BpsuU/WSavGYSJR+maxPD63ITCGM1fzzAW0gAzK6D5WWBqrkdIN/2qnx
r6kgrOQVd1smsU3eSvfyyE2GoUpIsEiM0iulajG1I4ETReJcE2cKeFsPb248fHPe
djM8w48AIy7bEjBkuuHB++d75OxIytSBo9ltVnOqtJoYJUp6bZzFL8aHQe2hzQK9
rFBtRNcXvTnZOhZqismtgLnHv1Yb855mJR5JHHUGGvPURiUprnopR3KSQdq29gvT
AhG77A+0lEb2MXii4jOo6xc8Aqud5+ZCYdrAESL/vf1phDKyUbIYeURZ+VrFNtJJ
LKZbyZzC+Js596CBw6E3yofoeBdElwo/3AMbDUcRXgqzmXInzzwqCcFiTpuXNynZ
jWU7YLSufuHj7K1LV7mFffNu1fgcfTFVGu+beDfV6OQvBM6QOapZXITRzDs0F+Iy
2PFqRk3CUG+yA1uIFarpI5LsRVZgAd0H0dzxbZ0vPzri21lKdb1g2jPgwgMJCdK3
9kL8Z2x9JF0hVOmYeNstmwUtyvIZa2SC2WxqzhlYqTz4dAqbv9cmp4e1Rnqu7Dwe
4b7ZbmmENi+Tl1jcpE+H97I=
=xDZt
-END PGP SIGNATURE-



Bug#833922: ITP: flask-ldapconn -- LDAP connection and ORM for Flask Applications

2016-08-10 Thread Dominik George
Package: wnpp
Severity: wishlist
Owner: Dominik George <n...@naturalnet.de>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: flask-ldapconn
  Version : 0.6.13
  Upstream Author : Rafael Römhild
* URL : http://github.com/rroemhild/flask-ldapconn
* License : BSD
  Programming Lang: Python
  Description : LDAP connection and ORM for Flask Applications

Flask-LDAPConn is a Flask extension providing ldap3 (an LDAP V3 pure
Python client) connection for accessing LDAP servers.

To abstract access to LDAP data this extension provides a simple ORM
model.


In intend to maintain the package within the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJOBAEBCAA4BQJXqxRKMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYpfg//Yev9If4IafH30athGAqf
AySEtCUlRv7/nfchHl+b62V5aXWQzu7LPzqrLlsuTKsPJm6UFun3uWb78REFKEGD
Ah/37lLRgQn5gTgwqSeksUBcS/PhiZ//1S8yHl4HCEVDfnWvlFiqiYQdizX+PGDj
zwQnJxvQFoqkUdZnbUqjccAa1dWQZw/hNwSQAs+SbrdxT8jKGdznE6TsMLh0tWS0
SmF7KkVko4G/uQz100UdNqiyVobv9HxiKAgMvhMjLSMNF6d7IGyLKYr4bVP3tl7g
P4chtX3tNHeJyx9i+w6SG9kefRoZjS5SIxyfP1p/dTcgoEVS7eTHo/jEBRFCSLty
c/W7eImwkb9dwhamDMP+56IgTOcNcyljZddqsqqrY1nfnqJj0QhOhfDlurpo/aBX
DyAuwVwatv70wSpL1kF25RNzz00PohYvkUdxabXs81538u0Z4PYZDKB+It+7nlGx
FNM2YkahgIhFFApWjmDKAZJFwIR+LOrcTflTKbJdjjyA+5xy5rIqHPnn7bnD9Reo
h914PHP7pZEQb3cJhzjvBcbIPoQJrYEe3M69j+deQAnjTJcFmXX+/ragP9/KJpU7
DV+m/tJQeeX/mhB03u9I7gtZGlWOKS02dThVjQA9XTvN5o/t64HeeTtUKcHUi8XX
sGaBkO6rVjcSE3Gi1QKPy0Y=
=AmnQ
-END PGP SIGNATURE-



Maintenance of new Flask extensions

2016-08-08 Thread Dominik George
Hi DPMT,

I would like to package and maintain some Flask extensions. Flask, a web 
micro-framework, and some extensions for it are already available in Debian 
and under team maintenance of the DPMT.

I would initially like to add these two extensions:

  Flask-Restless
  Flask-Compress
  Flask-LDAPConn

Also, I would like to help fix open bugs in existing Flask packages.

I would base my packages off of existing ones in order to enable the team to 
co-maintain the packages.

Apart from these new packages, I maintain a few other packages in Debian, in 
cooperation with several DDs.

If the DPMT is willing to co-maintain the new packages, I would like to keep 
the package repositories and the like in DPMT from the beginning.

Please tell me if it is ok to ask for team membership on Alioth ☺! My username 
there is natureshadow-guest.

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)


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


Re: Pending broken links

2017-02-21 Thread Dominik George
Hi,

> I have noticed that the automatically generated links sent to the BTS on
> git changes that close bugs are broken.
> 
> e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855510#10 has the
> following link:
> 
> http://git.debian.org/?p=python-modules/packages/slimit.git;a=commitdiff;h=d20c791
> 

True.

For some reason, the redirect to gitweb on anonscm seems to be broken.

This works correctly:

http://git.debian.org/?p=python-modules/packages/slimit.git
→ https://anonscm.debian.org/gitweb/?p=python-modules/packages/slimit.git

This doesn't and redirects to cgit instead, cutting off the commit id:

http://git.debian.org/?p=python-modules/packages/slimit.git;a=commitdiff;h=d20c791
→ https://anonscm.debian.org/cgit/python-modules/packages/slimit.git/diff/?id=

But…

> Which generates the following error:
> 
> 404 - No such project

…following the above observation, it throws Bad object name instead here.

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature


Re: How to split modules in multiple deb packages

2017-02-20 Thread Dominik George
Hi,

> Hello everybody, I'm packaging a daemon that I've developed in python3 and I
> need to split the core modules in two deb packages, but I don't now how to do
> that.
> 
> One of the module is specific for Raspberry Pi, it adds some
> functionalities, but
> the daemon itself doesn't require a Pi hardware and can still do its job
> without that module even on a Pi. What I want to do is to split the modules
> in two deb packages, one with all the modules except rpi.py and one with only
> rpi.py (setting the appropriate dependencies, i.e. python3-gpiozero, etc).
> 
> How can I do that?

Well, in that case, with you being upstream, I'd separate the two
packages entirely.

> I can exclude rpi.py module from main package and create a
> python3-mypackage.rpi.install
> file installing rpi.py in /usr/lib/python3/mypackage but I don't think it is
> the right way of doing that.

Why not?

>  |-- mypackage/
>  |   |-- module1.py
>  |   |-- module2.py
>  |   |-- moduleN.py
>  |   `-- rpi.py

This is not a Python package.

(Hint: no __init__.py…)

> The MANIFEST.in
>  > include setup.py
>  > include MANIFEST.in
>  > recursive-include mypackage *.py
>  > include bin/mydaemon

Uh? All of this is duplicating setup.py. Just remove it. Instead, please
make sure to include your full licence, readme and changelog in the
source tarball from within MANIFEST.in.

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature


Re: How to split modules in multiple deb packages

2017-02-20 Thread Dominik George
Hi,

> > Well, in that case, with you being upstream, I'd separate the two
> > packages entirely.
> 
> Yes, I can do that. But, don't you think a whole package for a single
> python file is... too much?

Well, is it? You were the one asking how to split it ;)…

So, if you think the RPi and non-RPi parts should be separated, then
separate them. If you think they shouldn't, then don't. I'd only suggest
you make one decision, not two ;).

> >> I can exclude rpi.py module from main package and create a
> >> python3-mypackage.rpi.install
> >> file installing rpi.py in /usr/lib/python3/mypackage but I don't think it 
> >> is
> >> the right way of doing that.
> >
> > Why not?
> 
> Because I'll miss all the "egg"-related files. Won't I?

Well, you will, but that's correct. They only declare the Python
package, not the modules it contains. And as your rpi sub-package would
obviously depend on the main package, everything would be fine.

You'd indeed go with namespace packages instead if you decided to
separate the stuff upstream.

> And, how can I choose the right destination folder? /usr/lib/python3
> or /usr/lib/python3.4 perhaps?

By not using package.install, but copying the whole tree in
override_dh_auto_install and the nremoving the non-RPi parts from the
RPi copy of the tree. At least that's how I would do it if I had to.


But, seeing that you are in doubt of your own decision to split the
package: What about don't? Just make one package, period ;).

In case you think you have to split the code because part of it will
only run with python3-gpiozero, and python3-gpiozero is only available
on armel, armhf and arm64, then you have other options:

 1. Just make an architecture-dependent dependency on python3-gpiozero
and just let the rpi module throw an ImportError it gpiozero is
not available. No harm done, happens all the time, and would also
happen if you'd not install it in the first place ;).
 2. Find out that I am the python3-gpiozero maintainer, and kindly ask
me to provide gpiozero on all architectures. It does have a mock GPIO
implementation for testing purposes, if that's of any interest.

So I'd personally go with 1. now and remove the architecture
specification in the dependency once I got 2. finished.

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature


Re: Implicit namespace packages (was: Re: How to split modules in multiple deb packages)

2017-02-20 Thread Dominik George
> > This is not a Python package.
> >
> > (Hint: no __init__.py…)
> 
> Not required for Python3.
> 
> https://www.python.org/dev/peps/pep-0420/

Yep, you're right. But that would still have to be declared in
__init__.py to work properly, right? If not, that would be cool…

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature


Review/sponsorship of osmalchemy package

2016-09-12 Thread Dominik George
Hi,

I would like to ask for review and sponsorship of the osmalchemy package.

It can be found in the usual place at:
git.debian.org:/git/python-modules/packages/osmalchemy.git

The package can be build with gbp using pristine-tar. It appears to be
lintian-clean, apart from a missing upstream changelog (which upstream,
i.e. me, myself and I, will fix in a future release ;)).

OSMAlchemy will be used in several projects that will run on Debian;
it was also feaured at the Python Unconference in Germany last weekend
and many people like it and would like to use it, so adding it to Debian
seems legit (it has also a quite low impact on the repo, as it has only
few dependencies, so nothing bad to expect there).

Thanks in advance for looking at the package,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

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


Bug#838566: RFS: mimerender/0.6.0-1 [ITP]

2016-09-22 Thread Dominik George
Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

I am looking for a sponsor for my package "mimerender"

 * Package name: mimerender
   Version : 0.6.0-1
   Upstream Author : Martin Blech <martinbl...@gmail.com>
 * URL : https://github.com/martinblech/mimerender
 * License : MIT
   Section : python

It builds those binary packages:

  python-mimerender - RESTful HTTP Content Negotiation for web frameworks 
(Python 2)
  python3-mimerender - RESTful HTTP Content Negotiation for web frameworks 
(Python 3)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/mimerender

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mimerender/mimerender_0.6.0-1.dsc

The package is a dependency of the soon to be added flask-restless package.

  Regards,
   Dominik George

-BEGIN PGP SIGNATURE-

iQJhBAEBCABLBQJX49MdMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
5VcP/2d2QeKrmW4BjHgi/f47zf6sPuyaCI/J+K5LkIEo1giM09XGyXGj+qmJQgE1
o+PtW+Mgmzb2y+4SP8Oil39Rzs3w7DQd/2V8xV/MvrbWnnymQh2aqmv4r5aW4GKS
N4TLMfKm0yPkEljg6e6tByG7RtFaIwwYD26j3qq6E8yn5FYVbQJZLQee222AeLVA
U6L1JJvk+dwDW52HvS8yHjKexj5RxE34fRpJ3NFS82bHzUCRTY/mtB3SEqOHWBqf
X23+LIjx0YcSM4/6Phe5ZZ1YhSPby5wtdHAvPBVLKo/SAvbrSzX02zeAzcrwm/vO
AqNjAlReydi6p2WOrkWGj9yCQbTf/xMe/0RPY9HL+SuAOXjh5Fkwixj3WI/BXAUs
mbGBPOfI9Kn9g88sVreVtnyaJmIJBGt++VjRCHlp3AOjkR+0rUTJFjrjTyNJEtIM
CVrayIKxpOe8ozAWZRZPP7e/KoQDux3FPK643lQEf+f/n3tHTLmVoumTkspc5cWo
nTCSdpBhL+SiOvI7o7IwyKFcr9CZMwSVY81cVpbhOipcQLVLbYrIvyJsoXDJHMOd
Cu1Tj/PybMfcSeMxs+4cj3JWRmh1oDxpKjVSGZjumc0qlBr+sftGHfSQBSfJLJck
/zLyIJpmxCjdMiUtElQsROBRusKD5ypnpIbWH6vZ780/4hqx
=fkb9
-END PGP SIGNATURE-



Bug#838582: ITP: python-testing.postgresql -- Python unit testing helper for temporary PostgreSQL databases

2016-09-22 Thread Dominik George
Package: wnpp
Severity: wishlist
Owner: Dominik George <n...@naturalnet.de>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: python-testing.postgresql
  Version : 1.3.0
  Upstream Author : Takeshi Komiya
* URL : https://github.com/tk0miya/testing.postgresql
* License : Apache
  Programming Lang: Python
  Description : Python unit testing helper for temporary PostgreSQL 
databases

The testing.postgresql package is a helper module for unit testing Python
database applications. It provides methods for setting up, maintaing,
and cleaning up a PostgreSQL database server that can be used within a test
suite. A real PostgreSQL server is started as an instance in a temporary
directory and removed after running the tests.


The package would enable Debian package builds to use it and to enable
unit tests of Python packages that use databases. Right now, the only
way to build packages that do is to disable the tests.

The package shall be maintained within the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-

iQJhBAEBCABLBQJX5ASeMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
OC4P+wVDTvdt+ISFXMWyu0odDl/Kqjyx7jBxdBN3aSxjyhKpKyIvTyOYUU+wPSxe
fhEPeZM+OBeKYOxzclr5Scal2D64enL8k77cNGxw0hzQ2EaIGhStDE5Cxz8OJmuT
RnMEWQpHo2/PEkIsW8VVeu4oAPHkk+/gCoVXOYxwyxmtBPZWxLkvyjzHq6B2Q07h
7avdjrvdI15G5ASi27XFHoadGIV3toGIwzVRKqvAe2zTIlSgeFtQhgDKTIi0VfqO
D77+cIm/AMKWdrzWlTNtDA68QMAtqt3TGGo7lFHNETY7yrOZdPJwK1EgHAvX7NrC
3xH0PrOLu7WvQ3+0bLAlTtBRIJGxKbvMizqnNGwGeRJUHcWeexpahQczNy27CC9q
RlSiT8IfgGMouPRP7xJaqH1eg6SIhXxZ5FbI3K/k+L6xVI/Mo83q+w6VBKTzjRVf
TSTcSbDWQNnDc2yCpZ0vNI/1sth3jQKvtjgE4ARahlHIHLsjzpulzTA2/du3e931
NN+lJlTyz1Jp4yFXR2o/XazIn/VsoQtC5+LMy0RzyJE1Kjjs60iaGtFhRo34LrR1
StxwR8PhuK/hJluAN0Ufg6jLXPX7XGrZhSzgVugGbW2q9/jufcPtZbcXdtt/eD8V
J9zLKV5N9nvT/nx2JtP4C5DsIbHrT3FTd6qY/wxmpq/Qt7zE
=WzUS
-END PGP SIGNATURE-



Bug#838581: ITP: python-testing.mysqld -- Python unit testing helper for temporary MySQL databases

2016-09-22 Thread Dominik George
Package: wnpp
Severity: wishlist
Owner: Dominik George <n...@naturalnet.de>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: python-testing.mysqld
  Version : 1.4.0
  Upstream Author : Takeshi Komiya
* URL : https://github.com/tk0miya/testing.mysqld
* License : Apache
  Programming Lang: Python
  Description : Python unit testing helper for temporary MySQL databases

The testing.mysqld package is a helper module for unit testing Python
database applications. It provides methods for setting up, maintaing,
and cleaning up a MySQL database server that can be used within a test
suite. A real MySQL server is started as an instance in a temporary
directory and removed after running the tests.


The package would enable Debian package builds to use it and to enable
unit tests of Python packages that use databases. Right now, the only
way to build packages that do is to disable the tests.

The package shall be maintained within the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-

iQJhBAEBCABLBQJX5APJMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
M0EP+QEsX9hTVtToT3gkYdJnQ0qYo5SxmM+vtDjreWwQC+pWB2XdnXPtzheIifAi
dJkbxT7n1UmndsroPkKiay9Qhhs/i+k/maAdArTTOKG93KmZGmXw7+L87XqavGa0
hdMWnc7rFqAmgg6KAyQb0NjT4TZvtwetGvkTRDwFyWSlbeXS91dK9zTAtaAU31Jv
W5hh+ec+72bOdg7d5usut+KcwmiYXQcX2cTD9VAwSdM5dk13LUzvXffXn9pQTWc1
zEtCMKDLaqtB3do+95kZwjFQW+ynd4XfKyCsQdB3MuVn4rc+Ruc87mHijUI6Uhys
a1xvNbVNM3WtP0QBNi4b93MLZt7kOdGB9fGvMnSr2X6dLmwcW83jochBC629UhIU
fW/CMPGnZ/DwarMerov8j71rUv3tv01LI2FkLlF/oXDkh5Ni6l2sCDljfv4gtM8O
yAXKJsU5HOX1gc7KOdE+BI5Ws6k4qiRQUf7UWouLRuZVs2fvj1C6ntLxz7mkoTuQ
bvpZpTGLweGzzsl0/9A301Ooxpg+f1DxH2TI6BpRWA9t2XLqabsCW+8gBdAGmnQs
yE99tuWmqAQ3tsZCU0/1cPf0dym4Ir6jOKd6n2EjwvAMb2I5glG2VL8/WXeF1hNN
4p8kazlWHTFUiCrnrLyQjbuL7V29wekjKCv3vhYo2NVE1JJx
=eAUz
-END PGP SIGNATURE-



Bug#838575: RFS: flask-compress/1.3.1-1 [ITP]

2016-09-22 Thread Dominik George
Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

I am looking for a sponsor for my package "flask-compress"

 * Package name: flask-compress
   Version : 1.3.1-1
   Upstream Author : William Fagan
 * URL : https://github.com/libwilliam/flask-compress
 * License : MIT
   Section : python

It builds those binary packages:

  python-flask-compress - Compress responses in a Flask app with gzip (Python 2)
  python3-flask-compress - Compress responses in a Flask app with gzip (Python 
3)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/flask-compress

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/f/flask-compress/flask-compress_1.3.1-1.dsc


Flask-Compress is an extension for the popular Flask micro-framework for web 
applications.

  Regards,
   Dominik George
-BEGIN PGP SIGNATURE-

iQJhBAEBCABLBQJX4/Q2MRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
EHQP/RlBk46ylNURHGc+Q9S1GznIsFC60YH+sEq1Kb0jZ+go2sDRCO6zoQBG06OH
19OQxa+u/KVdlw23J78sckeFC9Q/Z5vmGKG9f73SfEBSwkwJT1jJLJCr66OyXu1j
RYvD1yebcHMGDuvVkK8NOHN+Trd4TA9EA9OG3DGMLRlj5jbkmEoayH1VP4J/kSZd
3Cn3RqwKifACCTOzRuQzUik5rE5rQ+5pBHFdkZM8zRkjwHxWDOmKcGp6+2uYx2ep
Qu9GH2nZsuQF/+Quw9etiU1f9K3Dj872SpOU78zCHtjsxlYEmOlsmi1vCK89JDDp
kobKTwc9mXiG/aTevKhJBPmaT4JTmKSNXk1gJUxiTaHPnDK+W3J2MSUODJAf4Yzd
+kaz5lLAh3iLeiFloowVSZ78QhZAboaaRpoZrJ4DlDahMupkflHpj9q72f0RvFIq
NLR4sm44D2xegYLOjJdYVYMXxANoSQM9nYGU/vgNBUiihE+z7tR143zyJT2Lya9m
pJWlbaGLMyIVm0UmGJnNFom+vcuElrlEo6m9Gx5sJCi8bjbPfeL4OIhmQW1KNFd4
3duqOAYDQUzlvrdSOIzsuuWqAV8xvmgFIRJcLREE4QVj9TyDwayXDUdu+TGkI7Ib
yA0XIvXulNrs3VZ4pfhv2dzG/JuJI2CjrTni+7i+Zjf71LWH
=jWru
-END PGP SIGNATURE-



Bug#838587: ITP: python-testing.common.database -- Utilities for Python testing.* modules

2016-09-22 Thread Dominik George
Package: wnpp
Severity: wishlist
Owner: Dominik George <n...@naturalnet.de>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: python-testing.common.database
  Version : 2.0.0
  Upstream Author : Takeshi Komiya
* URL : https://github.com/tk0miya/testing.common.database
* License : Apache
  Programming Lang: Python
  Description : Utilities for Python testing.* modules

This package provides common utilities for some Python unit testing
modules that handle database tests. Right now, two major test modules
are known: testing.mysqld and testing.postgresql.


The package shall be maintained inside the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-

iQJhBAEBCABLBQJX5AwLMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
DRsQALPk23qalpioBK5geJfr/Lgo7t2svsmpdFaHQzixvEyJK3twJ8b5enXM8AJR
Gd1GKGyvW+0qKTbrin4UNmP/LaynGQ1ZH63uE3rZ0VSzREi6b1ZjHd/vGKBjnq6m
77SSHRT5xkdg6mwjG19fQDx16vBn2qcEXiOZrwyjNaMD1k9T2xNBx/G8GzfIeZnD
0t0u3lIsDYU9ZpcE0GvUMi8zbUjRStUUMAEc3tnkvcz31lR7hA1xxjvWM5myY+ff
LVWA2vu+MQ5EvEJQrPjBfmKlIr+o32Nrc9BgoLkddm4Ol3ehhY9MuF2PI0U9f7nY
ZkidIkw6E42b94h/nA80i2VHHSMLbmZITReA5+s+nUvuv0is47Ymo1Z6UD5zIBZD
I1TXSMofkINsZKmkoSWmRXWq3lGRp8N+/ifw/4wSMPpiqrioH4OkeW9cogczx0KR
4yVg5muZz8UzVNBoj45dY49UluqEPbVNzd+bB9OJMd5X4y/ELwT7nFzF0PrB/d8Y
rUlfSC2m16eAu1aa19zWGRgLK0DHc7IPcbz2lOaPe5K2TEoC47oEbxDxsiMfo3Mp
trL+aI+cuAmYHQhoMA+YLuRTBriwjZ4auxYOBgSnV34dn5N3V2MSofaBOmyhZdJK
l7aQ1IYOErnhjoWq4miHHxLA3WclyI1VgYHImaPq+eUTvpzM
=tkW5
-END PGP SIGNATURE-



Bug#843158: ITP: gpxpy -- GPX file parser and GPS track manipulation library

2016-11-04 Thread Dominik George
Package: wnpp
Severity: wishlist
Owner: Dominik George <n...@naturalnet.de>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: gpxpy
  Version : 1.1.1
  Upstream Author : Tomo Krajina
* URL : http://www.trackprofiler.com/gpxpy/index.html
* License : Apache
  Programming Lang: Python
  Description : GPX file parser and GPS track manipulation library

gpxpy is a simple Python library for parsing and manipulating GPX files.
GPX is an XML based format for GPS tracks.
.
The library also contains utility functions that are used in GPX file
handling, but can also be used separately, e.g. simple functions for
calculating geographical coordinates.


The package shall be maintained inside the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-

iQJhBAEBCABLBQJYHHOWMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
B0IQAL+ktbh5pDNo0fc//HC8AMOf2qybGXZgPl7CDyXEMNuMaY3AvzDOFXKOAC0B
Xt+grZF06HcMIxCNVwpyn3KeHWbtXAPzbVUzASyBfb6lFj2UQ3zKUD7zFiiY4rwn
NqmIK3BIJ9wV7OtS2mcCInd/i+umQzQR3G4XVhB9Yn/7MpzzIfOqctnduT0Bvzyy
ry+lhUQWp/I5/uXb3QmKYKXaO7cdweudkqiqLj9hi8QpmVsgCk8Q45vFxZk+iuOr
seObj46NmlInluS0BvAvWZR8RBdUbxufrbQvYDSN2FDycGQQi4eHaUgIibGwyX96
5ZS1LAiAf4yuCAr76/VCXtk6auqPiJLgZi89lARIrYP5o4CnPdOZfa1611UXIdXt
Am2w5ZWmOpQkljjsL1HfcNJqcD9AtLck6k4zyv1vqOvIaRInml1l7EEiZPM1TPFM
nSADDSCyatywWOLAeZCg9nvU+Ud4gdWVEeAKadLQUXbgeCSDlqzrOKxc7AlsFmUg
m41GAJP48Ov5RsuhCzU7dC3PQnQBBIPoQ7z35m0dp75SwWKmAVMCke/6jQIqkz8X
UPY0Wj1Y9XYkF6932EKGn3tNEJiady2rYdfTrv/P0xYksLGhSiOZ2DQDdgCb0miS
abkZXXdYus5fKrYb46xYtoT1B1Dx7X6ujwCPJXw0Tf4eyKmG
=lJUx
-END PGP SIGNATURE-



Please add me on Salsa

2018-02-22 Thread Dominik George
Hi,

please add me to the team(s) on Salsa. I am an existing DPMT member.

Username: natureshadow-guest

Thanks,
Nik


signature.asc
Description: PGP signature


Re: the new PyPI, coming next month

2018-04-01 Thread Dominik George
Hi,

> To be clear, PGP signatures can still be uploaded and they are still
> available for download, they just don’t appear in the UI anymore.

So, what does the pypi.debian.net redirector use for uscan?  I imagine it
used to scrape the website.  Can it be changed to use the JSON API?

>  Longer term I’d *like* to get rid of PGP signatures, because I think
> their value here is actually pretty low.

I partially share this opinion, but that's a question to be discusses with
the Debian policy people in general.  While checking a GPG signature on the
source tarball in general is a good idea, I am afraid some developers just
drop any key they find on first glance into the package and are done with
it, which actually provides nothing but a false sense of safety.

> In that case they’d be replaced with TUF, but that’s a longer term
> project.

That one?: https://github.com/theupdateframework/tuf

Well, I can only say *please* do not remove the possibility to upload signed
source tarballs, but leave that to the developers!

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Phone: +49 228 92934581 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V. · Debian Developer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature


Re: Future of pygame in Debian.

2018-10-12 Thread Dominik George
Hi,

> […] tagged accordingly in the BTS […]

Oops, you are right. There are still two FTBFS bugs I failed to tag (but not
to fix).

Cheers,
Nik


signature.asc
Description: PGP signature


Re: Future of pygame in Debian.

2018-10-12 Thread Dominik George
Hi,

> pygame in Debian testing is currently python2 only, I am sure I am not
> alone in thinking this is not a good state of affairs given that pygame is
> frequently used for introducing people to programming.
> 
> pygame in sid has python3 support but is held back from migrating to
> testing by three rc bugs.  None of which have had any response from the
> maintainer.
> 
> One of those is a FTBFS with python 3.7 which is apparently fixed
> upstream.  So presumably the best thing to do about this one would be to
> update the package to the new upstream.  I may have a go at this myself
> but I'm not an expert in python packaging so I don't know how well I will
> do.
> 
> The other two are testsuite failures on architectures where frankly I
> doubt pygame has many users*.  I may also take a look at these after the
> new upstream version is dealt with but I don't think it's worth putting
> huge amounts of effort into pygame on architectures where I doubt it has
> any users and I equally don't think it should be allowed to block the
> availability of python3-pygame in testing on architectures people do
> actually care about, so if the root cause cannot be found quickly I would
> propose either disabling the tests on these architectures or requesting
> the ftpmasters remove the binaries.
> 
> Anyone have any comments or suggestions?

Yes. I am the maintainer whom you accuse of not maintaining the package.

Sorry to say that, but all your assumptions are wrong - all of the bugs you
mention are handled, tagged accordingly in the BTS, new uploads are prepared
in the packaging repository, and fixing last issues for the upload are being
coordinated with upstream, keeping the buster release schedule in mind:

  https://github.com/pygame/pygame/issues/543

Anything more I can do for you?

Cheers,
Nik


signature.asc
Description: PGP signature


Re: dh_python or pybuild

2021-10-11 Thread Dominik George
Hi,

> I am not sure if I misunderstand something or if the documentation is
> inconsistent.
> 
> The PythonPolicy
> https://www.debian.org/doc/packaging-manuals/python-policy/
> tells me that dh_python should be the preferred tool for packaging
> (https://www.debian.org/doc/packaging-manuals/python-policy/#versions)
> 
> But the LibraryStyleGuide
> https://wiki.debian.org/Python/LibraryStyleGuide
> tells me it is pybuild
> (https://wiki.debian.org/Python/LibraryStyleGuide#Overview).
> 
> And the DPT policy
> https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst
> tells me something about git-buildpackage and gbp.

the three components work together, or better, are used at different
stages.

* git-buildpackage (which is the same as gbp) is used to manage the
  sources of your package in git

* pybuild is the toolchain that does the building process itself, and
  knows how to run setup.py or other tools, etc.

* dh_python is the debhelper chain, the glue between the package
  building process and pybuild

dh_python can use several different build systems, of which pybuild is
the preferred one. When debhelper calls, e.g. dh_auto_build,
dh_auto_build calls all chains that support the build
target. dh_python does, so it is called, and in turn calls pybuild to
do its magic of figuring out how to do the build for your specific
package at hand.

HTH,
Nik



Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

2021-09-28 Thread Dominik George
Hi,


> Could someone please upload this little package ? It's a dependency of 
> xsdata, an awesome XML/dataclasses library I'd like to get into the archive.

I will check it tomorrow.

-nik



Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

2021-09-29 Thread Dominik George


> there was actually a recent discussion on this list, discouraging from
> using PyPI in favor of github, since GH tarball usually contains docs,
> tests, and other files useful when building from source, usually not
> included in tarball released to users, ie pypi

That's an upstream bug then, and upstream should fix that and ship a complete 
source tarball.

I always submit pull requests updating MANIFEST.in and until now, all upstreams 
have accepted them.

-nik



Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

2021-09-29 Thread Dominik George
Hi,

> Could someone please upload this little package ? It's a dependency of
> xsdata, an awesome XML/dataclasses library I'd like to get into the archive.

uploaded, thanks for your contribution!

One note: I'd consider watching for PyPI instead of GitHub.

Cheers,
Nik



Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

2021-09-29 Thread Dominik George


> and that will require an upstream new release, which does not help
> when you want/need to package the current one

Most upstreams kindly make . post releases immediately.

Maybe I am just lucky with upstreams...

-nik



Re: PDM - Python package manager for Debian

2022-04-03 Thread Dominik George
Hi Carsten,

> Or is there a way to get such packages build without a need for PDM to be 
> around?

This should really not matter at all when packaging for Debian. The source 
tarball should include a setup.cfg or setup.py file (i.e. be a regular Python 
sdist), and if not developing on the package, you should never meet PDM.

If the upstream sdist is not installable without PDM, this is probably an 
upstream bug; but my guess is that you chose a Git export instead of a real 
sdist as orig.tar.gz.

-nik



Re: PDM - Python package manager for Debian

2022-04-03 Thread Dominik George
Hi,


> I've compared the tarball from GH with the file from PyPi, the sdist on PyPi 
> contains even less files than the GH tarball, but also no setup.* files.

Uh, PEP-517 actually allows that... I have never seen that in the wild.

Cool, so this really means we will ultimately have to package everybody's 
homegrown build system now .

-nik



Re: pygame 2?

2022-01-22 Thread Dominik George
Hi,

> I'm wondering if anyone is working on bumping the pygame package to pygame
> 2? I imagine there might be quite a few incompatibilities that would break
> packages that depend on pygame, so perhaps an upload to experimental first
> would make sense?

I didn't have time to read up on the upgrade path, but will certainly
do so for bookworm.

-nik


signature.asc
Description: PGP signature


Bug#1029076: uwsgi-plugin-python3: built against non-default libpython3.11 / should always build against the defalt Python in testing

2023-01-17 Thread Dominik George
Package: uwsgi-plugin-python3
Version: 2.0.21-3+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debian-python@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Currently, the uWSGI Python 3 plugin is built against
Python 3.11, and depends on libpython3.11. This is,
to some extent, fine, as Python 3.11 is already in
Debian.

However, Python 3.10 is still the default Python in
bookworm, and as it stands this will not change [1].
In practice, this means that without changing the
interpreter and manually ensuring that the Python 3.11
environment is fully available, apps run through uWSGI
do not work.

So, the uWSGI plugin should in general always build
against the default Python IMHO.

- -nik

[1] https://lists.debian.org/debian-python/2023/01/msg00010.html

- -- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages uwsgi-plugin-python3 depends on:
ii  libc6  2.36-8
ii  libpython3.11  3.11.1-2
ii  uwsgi-core 2.0.21-3+b1

uwsgi-plugin-python3 recommends no packages.

Versions of packages uwsgi-plugin-python3 suggests:
pn  python3-uwsgidecorators  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iMAEARYKAGgWIQSk6zxRYJYchegBkTEK5VTlRg4b3QUCY8aedTEaaHR0cHM6Ly93
d3cuZG9taW5pay1nZW9yZ2UuZGUvZ3BnLXBvbGljeS50eHQuYXNjGBxuYXR1cmVz
aGFkb3dAZGViaWFuLm9yZwAKCRAK5VTlRg4b3ZDoAQCYW8oE4ZgiBKkgo1lge2Az
7/qTIXGHgKAAF5kmuGTB5QD+NiuAOboj6I6ZvxRZF4o1D3vXCBr1HkqYz+piZMQO
Fgc=
=Y+XX
-END PGP SIGNATURE-



Re: Launchpad: Merge of Accounts Requested

2024-03-18 Thread Dominik George
Hi,

>FYI: This message got delivered at the public mailing list
>debian-python@lists.debian.org.  To me it looks like someone if trying to find
>a loophole in launchpad and plans to abuse the system.

Thanks for reaching out to them.

While at it, I'd also question why Canonical is scraping public repositories 
and creating user accounts for the scraped addresses.

Yes, I know why they do it, but for me, it is another example of bad 
collaboration practice, on top of everything else to be said about Ubuntu (or 
more precisely, its owners).

It's also small things that impose burdens on others, and if they think they 
need to fork Debian, copy packages from it (to put behind a paywall 
afterwards), then they certainly could do that without spoofing Debian people 
and team addresses.

Disclaimer: I am assuming good faith in this specific case, but not in 
Canonical and Ubuntu in general.

-nik