Re: DPMT membership request

[Piotr Ożarowski]

[Felix Krull, 2016-08-08]
> I'd like to join the DPMT to maintain quark-sphinx-theme (ITP at [1])
> which is going to be needed as a build dependency for the next
> SpeedCrunch version [2].
> 
> I have read the policy [3] and accept it. My Alioth login is fkrull-guest.

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

Re: Request to join DPMT

[Piotr Ożarowski]

[Tobias Hansen, 2016-08-10]
> I would like to join the team to help maintain Python modules that are
> dependencies of SageMath (at the moment, I'd like to update pexpect to
> the new upstream version).
> 
> My alioth login is thansen.
> 
> I have read https://python-modules.alioth.debian.org/policy.html and
> accept it.

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

Re: Acceptance of team policy

[Piotr Ożarowski]

[Dominik George, 2016-08-10]
> of course, I have read and accept the DPMT policy.
> 
> I have also already workde with gbp in the way described in the policy.

welcome in the team :)
-- 
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

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT (was: PAPT Git)

[Barry Warsaw]

On Aug 10, 2016, at 08:49 PM, Brian May wrote:

>Most of the time it works pretty well... It looked good compared with
>the alternatives available at the time we made the decision.
>
>However this is irrelevant IMHO if it isn't being mantained.

Yep.  git-dpm was the best of breed at the time we were switching from svn,
and several developers had good experiences with it.  When things are fairly
simple, so is git-dpm, and when it Just Works, it's easy to use.  When it's
*not* -- or when you hit any of the bugs previously mentioned -- then you're
out of luck.

git-dpm is no longer maintained so those bugs won't get fixed.  And gbp-pq has
improved a lot since then.

Moving PAPT to git without git-dpm will gain team experience with that
toolset.  IIRC we figured it was as easy as `rm debian/.git-dpm` to switch,
and we should test that on a few candidate packages.  More important is to
update the documentation:

https://wiki.debian.org/Python/GitPackaging

so we're all on the same page.

Cheers,
-Barry

Request to join DPMT

[Tobias Hansen]

Dear DPMT,

I would like to join the team to help maintain Python modules that are
dependencies of SageMath (at the moment, I'd like to update pexpect to
the new upstream version).

My alioth login is thansen.

I have read https://python-modules.alioth.debian.org/policy.html and
accept it.

Thanks,

Tobias

PS: I already tried pushing to the pexpect git repo and it failed. The
policy says it should work for all DDs.

remote: error: insufficient permission for adding an object to
repository database ./objects
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://git.debian.org/git/python-modules/packages/pexpect.git
 ! [remote rejected] master -> master (unpacker error)
 ! [remote rejected] pristine-tar -> pristine-tar (unpacker error)
 ! [remote rejected] upstream -> upstream (unpacker error)
error: failed to push some refs to
'ssh://git.debian.org/git/python-modules/packages/pexpect.git'

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

[Nikolaus Rath]

On Aug 10 2016, Thomas Goirand  wrote:
> As I only heard complains about git-dpm, maybe someone would like to
> express his joy using it, and explain why they think it's a nice tool.
> But is there such person? It seems git-dpm only brings frustration.

In my opinion, git-dpm solves the problem of keeping a full history of
Debian source packages (i.e., patches applied and debian/patches/
populated) as well as possible. This means that it is often painful.

I think the only way to make this less painful is to get rid of the idea
of managing patches in a VCS and use something like gitpkg. This has the
drawback source package is now *generated* from the Git repository
(i.e., you can't do git clone + debuild), but it makes maintaining the
Git repository much less painful. Judging from all the attempts I've
seen so far, trying to put patches (i.e., the output of a VCS) under
version-control is just a doomed endeavor.


I don't believe that switching from git-dpm to git-buildpackage is going
to make things easier, it'll just be trading one set of problems for
another.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

[Raphael Hertzog]

On Wed, 10 Aug 2016, Nikolaus Rath wrote:
> I don't believe that switching from git-dpm to git-buildpackage is going
> to make things easier, it'll just be trading one set of problems for
> another.

I don't agree on this. I have been a happy git-buildpackage user for all
my packages. The problem with git-dpm is that the patch series can't be easily
fixed after a merge when it generates conflicts. It's too intricately tied
to git-dpm's own fake merge logic with commit it recorded in
debian/.git-dpm and it's very painful to bring the repository in a state
where git-dpm is happy.

With git-buildpackage, the merge and the update of the patch series are
distinct operations that can be done at different times. Since patches are
unapplied, the merge usually works fine and the patch series
can be easily rebased afterwards with your tool of choice.

Anyway, +1 from me to switch to git-buildpackage and in fact among the
python-django maintainers we are close to decide to switch back to
git-buildpackage because it's really horrible to use when you want to
merge across branches of different releases.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

[Barry Warsaw]

On Aug 10, 2016, at 11:53 AM, Nikolaus Rath wrote:

>I think the only way to make this less painful is to get rid of the idea
>of managing patches in a VCS and use something like gitpkg. This has the
>drawback source package is now *generated* from the Git repository
>(i.e., you can't do git clone + debuild), but it makes maintaining the
>Git repository much less painful. Judging from all the attempts I've
>seen so far, trying to put patches (i.e., the output of a VCS) under
>version-control is just a doomed endeavor.
>
>I don't believe that switching from git-dpm to git-buildpackage is going
>to make things easier, it'll just be trading one set of problems for
>another.

Two thoughts:

* We probably need to do some actual experimentation on actual packages, so
  we should plan for allowing that on a limited basis, with the caveat that
  once a new workflow is chosen, we'll make all team packages consistent
  again.

* With git-dpm we *had* to enforce the tool choice because git-dpm's artifacts
  had to be preserved.  If we ditch git-dpm, is that still the case?  IOW, if
  you choose to use gbp-pq, am I forced to do so when I modify the same repo?
  Or if you choose to use PoQ (plain 'ol quilt), will that affect how others
  can co-maintain the package in git?

We only need to mandate workflows and conventions where the effects and
artifacts are visible after a package is updated.  Think of it like the choice
of editor - no one cares whether you use vim, emacs, gedit, or whatever to
modify the files, because its effects are only local to you (for the most
part).

Cheers,
-Barry

Re: PAPT Git (was: pypi2deb 1.20160809 and --profile dpmt)

[Sandro Tosi]

On Tue, Aug 9, 2016 at 11:50 PM, W. Martin Borgert  wrote:
> On 2016-08-09 23:28, Daniel Stender wrote:
>> On this occasion ... let it be me to start the discussion: let's get into Git
>> also for Python Apps soon.
>
> A common VCS for both DPMT and PAPT would be nice, indeed.

should we try and use plain git-buildpackage instead of git-dpm?

>
> (I have been reminded rightfully by both Piotr and Sandro, that
> PAPT still uses SVN. Changing that would increase my fun level!)
>

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT (was: PAPT Git)

[Thomas Goirand]

On 08/10/2016 09:21 AM, Sandro Tosi wrote:
> On Tue, Aug 9, 2016 at 11:50 PM, W. Martin Borgert  wrote:
>> On 2016-08-09 23:28, Daniel Stender wrote:
>>> On this occasion ... let it be me to start the discussion: let's get into 
>>> Git
>>> also for Python Apps soon.
>>
>> A common VCS for both DPMT and PAPT would be nice, indeed.
> 
> should we try and use plain git-buildpackage instead of git-dpm?

Piotr avoided the discussion during Debconf 16. IMO for good, as it
would have probably taken a full session.

I wrote a draft about my thought about it. Let me past it here.

The biggest defect of git-dpm, to me, is that it is often very painful
to merge a new upstream release in the packaging branch. Instead of
accepting the merge, and resolving conflicts later on, git-dpm goes into
the rebase conflict mode of Git, and it's often not obvious what to do
there. Messing-up everything, and restart from scratch (and then iterate
until done properly) isn't uncommon. Sometimes, all of this time is
spent just for a patch that needs to be removed removed.

With git-dpm, many operations aren't obvious, and it seems there's not
even an answer for stuff like this:
https://bugs.debian.org/810580
https://bugs.debian.org/801667
https://bugs.debian.org/801666

which stayed opened with no reply for months.

Sometimes, things are just very annoying:
https://bugs.debian.org/763569
https://bugs.debian.org/813302
https://bugs.debian.org/768382
https://bugs.debian.org/801649

It is also annoying that git-dpm doesn't produce a clean git history. It
ends up this way:

commit 241398abe0c476f39f0b4d62fb5227e4d0a52778
Merge: c72e5ea 880b748
Author: Thomas Goirand 
Date:   Tue Aug 2 08:40:37 2016 +

merge patched into master

commit 880b74889bbba237fe1bb17d992e1cbbb462be6b
Author: Thomas Goirand 
Date:   Tue Aug 2 08:39:49 2016 +

django-1.10-fix_runtests_lack_of_TEMPLATES

when really, this should be a single commit, not a merge operation. This
also doesn't include the debian/changelog comments, which also should be
in the same commit.

Even more: the generated patch headers aren't compliant with the format
1.0 as defined in the DEP. Meaning that we have to rewrite them. But
worse: git-dpm rewrites the headers loosing precious information like
the Origin field or bug numbers.

git-dpm also fails to tag upstream/foo automatically when importing a
new version. I've been told to use "git-dpm tag", but that's not
obvious. My own experience managing debian/patches quilt patches
manually or through gbp pq is actually much much nicer.

Plus it appears git-dpm is unmaintained and even sometimes buggy
(according to what I heard from others in Debconf: I didn't experienced
crashes myself). The non-mandatory use of "gbp pq" is nicer approach:
those who prefer manual quilt handling can do it.

As I only heard complains about git-dpm, maybe someone would like to
express his joy using it, and explain why they think it's a nice tool.
But is there such person? It seems git-dpm only brings frustration.

Cheers,

Thomas Goirand (zigo)

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT (was: PAPT Git)

[W. Martin Borgert]

On 2016-08-10 10:18, Thomas Goirand wrote:
> Instead of
> accepting the merge, and resolving conflicts later on, git-dpm goes into
> the rebase conflict mode of Git, and it's often not obvious what to do
> there. Messing-up everything, and restart from scratch (and then iterate
> until done properly) isn't uncommon.

Been there, lost hours :~(

> As I only heard complains about git-dpm, maybe someone would like to
> express his joy using it, and explain why they think it's a nice tool.
> But is there such person? It seems git-dpm only brings frustration.

Well, in most cases I did not have any problems with it.
Points I like and would prefer not to change:
 - no need to use quilt
 - no special build command, just plain dpkg-bp or whatever

The idea to try something else in PAPT is very welcome from my
side, no matter what tool.

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT (was: PAPT Git)

[Brian May]

Thomas Goirand  writes:

> git-dpm also fails to tag upstream/foo automatically when importing a
> new version. I've been told to use "git-dpm tag", but that's not
> obvious. My own experience managing debian/patches quilt patches
> manually or through gbp pq is actually much much nicer.

The problem with git-dpm tag is that this tags the Debian release too -
sometimes you want to tag the upstream version and aren't ready to
release a Debian version just yet.

> Plus it appears git-dpm is unmaintained and even sometimes buggy

That is the big problem. Nobody maintaining it or responding to bug
reports.

> As I only heard complains about git-dpm, maybe someone would like to
> express his joy using it, and explain why they think it's a nice tool.
> But is there such person? It seems git-dpm only brings frustration.

Most of the time it works pretty well... It looked good compared with
the alternatives available at the time we made the decision.

However this is irrelevant IMHO if it isn't being mantained.
-- 
Brian May 

Re: Maintenance of new Flask extensions

[Piotr Ożarowski]

[Dominik George, 2016-08-10]
> > 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.

I don't know how to disable these join request on FusionForge, sorry
(and I ignore them on purpose, policy clearly says to mail this mailing
list). I will add you this evening.
-- 
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

Re: PAPT Git

[Piotr Ożarowski]

[Sandro Tosi, 2016-08-10]
> should we try and use plain git-buildpackage instead of git-dpm?

the plan is to test something else (git-pq), yes

(and maybe even later replace git-dpm with it in DPMT if it proves to be better)
-- 
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

Acceptance of team policy

[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: using git-dpm or plain git-buildpackage in PAPT and DPMT

[Simon McVittie]

On Wed, 10 Aug 2016 at 16:41:40 -0400, Barry Warsaw wrote:
> * With git-dpm we *had* to enforce the tool choice because git-dpm's artifacts
>   had to be preserved. If we ditch git-dpm, is that still the case?  IOW, if
>   you choose to use gbp-pq, am I forced to do so when I modify the same repo?

You do not have to choose gbp-pq. You do have to use some tool that
copes with:

* a git repository with patches unapplied but present in debian/patches/
* no other special metadata present in git (you can optionally commit a
  debian/gbp.conf, and I would recommend it, but it isn't required)

In particular this rules out dgit (which wants a patches-applied tree)
and git-dpm (which wants a patches-applied tree with its own metadata).

In practice this means you can build with either gbp buildpackage, or plain
dpkg-buildpackage/debuild; and you can manage the patches either with gbp pq,
with quilt, or (in simple cases) by running git format-patch in an
upstream-tracking repository, dropping the results into debian/patches/
and modifying debian/patches/series with a text editor.

gbp pq works best if all repository users stick to the dialect of DEP-3
where all Debian-specific pseudo-headers appear at the end of the diff
(next to the Signed-off-by if any), so that it looks a lot like git
format-patch output (canonically with the leading From_ line and the
trailing signature omitted, although if they're present in input it
will of course cope). This is basically also what git-dpm generates,
so it should be familiar to DPMT people already. Good for gbp-pq:

From: Donald Duck 
Date: Fri, 01 Apr 2016 12:34:00 +0100
Subject: Reticulate splines correctly

This regressed in 2.0.

In particular, this broke embiggening.

Origin: vendor, Debian
Forwarded: http://bugs.example.org/123
---
[diff goes here]

Not good for gbp-pq (it works OK, but an import/export round-trip will
mangle the metadata if you don't take steps to preserve it):

Author: Donald Duck 
Description: Reticulate splines correctly
 This regressed in 2.0.
 .
 In particular, this broke embiggening.
Last-update: Fri, 01 Apr 2016 12:34:00 +0100
Origin: vendor, Debian
Forwarded: http://bugs.example.org/123
---
[diff goes here]

Regards,
S

Re: Maintenance of new Flask extensions

[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

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-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

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-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

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-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-