Re: bringing python-django-registration back into testing, dfsg issues

[Elena ``of Valhalla'' Grandi]

On 2022-09-27 at 08:17:39 +1000, Craig Small wrote:
> Given they sit under Public aren't they DATA FILES and subject to
> https://www.unicode.org/license.txt
> That license seems very BSD 3-Clause-ish.
> [...]

thanks, I was using my pessimist parser :) and didn't notice the good
news.

confusable-homoglyphs is now in NEW.

-- 
Elena ``of Valhalla''

率


signature.asc
Description: PGP signature

Re: bringing python-django-registration back into testing, dfsg issues

[Craig Small]

On Mon, 26 Sept 2022 at 19:18, Elena ``of Valhalla'' Grandi <
valha...@debian.org> wrote:

> http://www.unicode.org/Public/UNIDATA/Scripts.txt
> http://www.unicode.org/Public/security/latest/confusables.txt
> which, if my understanding of https://www.unicode.org/copyright.html is
> correct aren't DFSG, but could be redistributed.
>
Given they sit under Public aren't they DATA FILES and subject to
https://www.unicode.org/license.txt
That license seems very BSD 3-Clause-ish.

I suppose it comes down to what "Further specification" means. Does it mean
license.txt overrules copyright.html?

You could ask debian-legal for guidance.

Do you think it is ok to upload the package like this?
>
It's not ideal but if the result is you cannot use those confusables then
its the only way forward.


> 2) Even if the answer to 1 is yes, I can also try to package
> confusable_homoglyphs: upstream can download the files from the unicode
> consortium if they aren't available: do you think it's better to use
> that ability and package the file in contrib, or just put everything in
> non-free?
>
> Personally, the latter sounds quite easier, and I would be strongly
> tempted by it.
>
I have a similar problem with SNMP MIBs (thanks IETF). They're not even
redistributable so I have a contrib mibs-downloader package.
If the system can do it itself, that's ok but it needs to be something that
the user knows is happening. I have had issues with WordPress before where
it has links in some of the themes.

So in summary:
 * See if license.txt is the actual license and its DFSG free (I think it
could be)
* If not, I'd package the files in a separate archive

 - Craig

-- 
> Elena ``of Valhalla''
>
> 率
>

bringing python-django-registration back into testing, dfsg issues

[Elena ``of Valhalla'' Grandi]

Hello

python-django-registration has been removed from testing, and since it's
an useful package I'd like to bring it back into it.

There is a new upstream release, and there was already some work done in
git to package it, but it was failing because upstream has added a new
dependency on https://pypi.org/project/confusable_homoglyphs/

The problem with the latter is that it includes two files from the
unicode consortium:
http://www.unicode.org/Public/UNIDATA/Scripts.txt
http://www.unicode.org/Public/security/latest/confusables.txt
which, if my understanding of https://www.unicode.org/copyright.html is
correct aren't DFSG, but could be redistributed.

I have two questions on how to proceed.

1) I've pushed to git a patch to make confusable_homoglyphs optional:
it seems to be working, but it's still missing proper warning of the
user that that specific protection is disabled. I would add both a
runtime warning and a .NEWS.

Do you think it is ok to upload the package like this?

2) Even if the answer to 1 is yes, I can also try to package
confusable_homoglyphs: upstream can download the files from the unicode
consortium if they aren't available: do you think it's better to use
that ability and package the file in contrib, or just put everything in
non-free?

Personally, the latter sounds quite easier, and I would be strongly
tempted by it.
-- 
Elena ``of Valhalla''

率


signature.asc
Description: PGP signature

Re: writing debian/gbp.conf considered harmful [was: python-django-js-asset_1.2.2-3_source.changes REJECTED]

[Thomas Goirand]

On 9/21/21 11:00 PM, Antonio Terceiro wrote:
> However, having it duplicated in every package means we as a team work
> consistently regardless of people's global configuration, and that's one
> less detail people need to get just right to be able to contribute
> effectively.

No. It *ALREADY* works by default, no need to tweak anything on
debian/gbp.conf. Also, as I wrote already, using gbp buildpackage is
*NOT* the only one way of doing things. One can use sbuild without gbp.
What you're proposing is in fact the same as if you were proposing to
add defaults for some text editors in the packaging: that's irrelevant,
and hard to maintain consistently (like Sandro wrote).

> Also, one's global configuration might not apply to all the packages
> they contribute to

It is the case for me: I contribute to both the OpenStack team and the
Python team. Both teams have *very* different workflow (the Python team
is using pristine-tar, I don't like it and that's the main reason why
OpenStack is maintained outside of this team...).

In the OpenStack team, we used to maintain per-package debian/gbp.conf.
I am *very* happy we decided back in Debconf Montreal in 2017 to stop
doing that.

> it's easier for everyone if gbp just does the
> right thing based on per-package configuration than expecting people to
> remember to switch their defaults, or to pass options explicitly.

There's nothing to switch. One just needs to remember to explicitly
generate the tarball with "gbp export-orig", OR (preferred) directly
fetch the orig.tar.{gz,xz} from the Debian archive. If you forget, gbp
complains about it and stops building (that is, as long as you have the
option "no-create-orig = True" in your ~/.gbp.conf).

Cheers,

Thomas Goirand (zigo)

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Sandro Tosi]

On Tue, Sep 21, 2021 at 5:00 PM Antonio Terceiro  wrote:
>
> On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > > That's because gbp does not use pristine-tar by default, and
> > > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > > fix that.
> >
> > I dont think this is the right approach: the default options to work
> > on DPT packages should be in gbp default config file (or in another,
> > global, config file), and not live in each and every package
> > debian/gbp.conf file; it is already inconsistently maintained with
> > several packages having uncommon settings that will take precedence
> > over the default ones.
>
> I agree with you in theory; my global gbp.cons enables pristine-tar.
>
> However, having it duplicated in every package means we as a team work
> consistently regardless of people's global configuration,

not at all, right now we dont have a *consistent* debian/gbp.conf in
each package, everyone writes their own and it's currently a mess.

what when we decide to add a new option, or change the value of an
existing one? DPT currently has ~2500 packages: how do you maintain
consistency in all of them?

> and that's one
> less detail people need to get just right to be able to contribute
> effectively.
>
> Also, one's global configuration might not apply to all the packages
> they contribute to; it's easier for everyone if gbp just does the
> right thing based on per-package configuration than expecting people to
> remember to switch their defaults, or to pass options explicitly.

please refer to
https://lists.debian.org/debian-python/2021/09/msg00065.html for how i
see this being implemented.


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Antonio Terceiro]

On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > That's because gbp does not use pristine-tar by default, and
> > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > fix that.
> 
> I dont think this is the right approach: the default options to work
> on DPT packages should be in gbp default config file (or in another,
> global, config file), and not live in each and every package
> debian/gbp.conf file; it is already inconsistently maintained with
> several packages having uncommon settings that will take precedence
> over the default ones.

I agree with you in theory; my global gbp.cons enables pristine-tar.

However, having it duplicated in every package means we as a team work
consistently regardless of people's global configuration, and that's one
less detail people need to get just right to be able to contribute
effectively.

Also, one's global configuration might not apply to all the packages
they contribute to; it's easier for everyone if gbp just does the
right thing based on per-package configuration than expecting people to
remember to switch their defaults, or to pass options explicitly.


signature.asc
Description: PGP signature

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Sandro Tosi]

On Mon, Sep 20, 2021 at 11:21 AM Andrey Rahmatullin  wrote:
> On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > > That's because gbp does not use pristine-tar by default, and
> > > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > > fix that.
> > I dont think this is the right approach: the default options to work
> > on DPT packages should be in gbp default config file (or in another,
> > global, config file), and not live in each and every package
> > debian/gbp.conf file;
> What's the mechanism to put these options there for everyone who works on
> a DPT package?

that's a great question! i dont think a technical solution currently exists.

> Or do you mean just working with whatever is shipped with
> gbp?

that wont work, but there could be a solution if we request a new
feature in gbp.

According to man 5 gbp.conf, there is either a global configuration
file, a per user file or a per repo/branch. In order to support
different workflows (for different teams, f.e.), this is not
sufficient.

But it could work if gbp.conf supported something similar to gitconfig
includeIf: in my ~/.gitconfig i have

```
[includeIf "gitdir:~/deb/"]
   path = ~/.gitconfig-deb
```

(~/deb is where i keep all my Debian work), and that means that if the
CWD is part of the ~/deb/ tree, git will also include ~/.gitconfig-deb
which contains Debian-specific configs, like the @d.o mail address.

Now, we'd also need a single location to store the team-specific
gbp.conf, and we already have a repo thta would fit:
https://salsa.debian.org/python-team/tools/packages , which currently
contains files useful to work on the entire team packages. This is
useful in my specific workflow, which is suspect is rather unusual,
but here how it goes:

* i checked https://salsa.debian.org/python-team/tools/packages in
~/deb/python (this could be anywhere)
* run ./checkout -a to checkout all team packages (or ./checkout
... for only a subset)
* use `mr` (via .mcrconfig) to work on _m_ultiple _r_epositories (mr)

this repo could also contain a team-specific gbp.conf file we could
use. Admittedly, we probably only need a handful of options,
pristine-tar = True is only one that comes to mind (be aware this file
will need to be compatible with *all* repos currently in the team, so
setting the debian branch etc, wont work, until all repos are
uniform).

I'm going to file a feature request for the includeIf-like feature for gbp

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Thomas Goirand]

On 9/20/21 5:14 PM, Sandro Tosi wrote:
>> That's because gbp does not use pristine-tar by default, and
>> debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
>> fix that.
> 
> I dont think this is the right approach: the default options to work
> on DPT packages should be in gbp default config file (or in another,
> global, config file), and not live in each and every package
> debian/gbp.conf file; it is already inconsistently maintained with
> several packages having uncommon settings that will take precedence
> over the default ones.

+1

Plus gbp is just *one* out of *many* tools available. Some people just
prefer to use sbuild only, for example, and that's perfectly fine. IMO
it's up to the person that's using gbp to know what they are doing.

FYI, I've rebuilt regularly packages from the team, I even have
"pristine-tar = False" in my ~/.gbp.conf, and it's all fine...

Cheers,

Thomas Goirand (zigo)

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Andrey Rahmatullin]

On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > That's because gbp does not use pristine-tar by default, and
> > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > fix that.
> I dont think this is the right approach: the default options to work
> on DPT packages should be in gbp default config file (or in another,
> global, config file), and not live in each and every package
> debian/gbp.conf file;
What's the mechanism to put these options there for everyone who works on
a DPT package? Or do you mean just working with whatever is shipped with
gbp?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Sandro Tosi]

> That's because gbp does not use pristine-tar by default, and
> debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> fix that.

I dont think this is the right approach: the default options to work
on DPT packages should be in gbp default config file (or in another,
global, config file), and not live in each and every package
debian/gbp.conf file; it is already inconsistently maintained with
several packages having uncommon settings that will take precedence
over the default ones.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Antonio Terceiro]

On Sun, Sep 19, 2021 at 10:56:33PM +0200, Carsten Schoenert wrote:
> Hi Antonio,
> 
> thanks for your quick feedback!
> 
> Am 19.09.21 um 21:24 schrieb Antonio Terceiro:
> 
> > Looking from my side, the tarball from the archive (apt source
> > python-django-js-asset) and the one generated by pristine-tar are
> > identical:
> > 
> > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
> > /tmp/python-django-js-asset_1.2.2.orig.tar.gz
> > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
> > /tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz
> > 
> >  From reading the REJECT email, I think it implies that the .dsc/.changes
> > you uploaded refer to an orig tarball with 6360 bytes. Do you still have
> > the exact artifacts that you uploaded?
> 
> No, not completely.
> But I played around a bit with gbp and pristine-tar too and I was able to
> recreate a tarball which has the same size and the same hashes as the
> *.tar.gz in the archive and the one you've posted by using pristine-tar
> manually.
> 
> If I clean out all completely and build the package from scratch by gbp I
> get again a wrong size and of course also different hashes.
> 
> Currently I've no real clue why gbp is creating here different results, will
> look again at this once Guido is around, I'm sure he can blame me that I'm
> doing something wrong. :P

That's because gbp does not use pristine-tar by default, and
debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
fix that.


signature.asc
Description: PGP signature

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Andrey Rahmatullin]

On Sun, Sep 19, 2021 at 10:56:33PM +0200, Carsten Schoenert wrote:
> Hi Antonio,
> 
> thanks for your quick feedback!
> 
> Am 19.09.21 um 21:24 schrieb Antonio Terceiro:
> 
> > Looking from my side, the tarball from the archive (apt source
> > python-django-js-asset) and the one generated by pristine-tar are
> > identical:
> > 
> > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
> > /tmp/python-django-js-asset_1.2.2.orig.tar.gz
> > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
> > /tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz
> > 
> >  From reading the REJECT email, I think it implies that the .dsc/.changes
> > you uploaded refer to an orig tarball with 6360 bytes. Do you still have
> > the exact artifacts that you uploaded?
> 
> No, not completely.
> But I played around a bit with gbp and pristine-tar too and I was able to
> recreate a tarball which has the same size and the same hashes as the
> *.tar.gz in the archive and the one you've posted by using pristine-tar
> manually.
> 
> If I clean out all completely and build the package from scratch by gbp I
> get again a wrong size and of course also different hashes.
As pristine-tar is not enabled in debian/gbp.conf you need to enable it
explicitly with --git-pristine-tar each time you run a command that uses
it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Carsten Schoenert]

Hi Antonio,

thanks for your quick feedback!

Am 19.09.21 um 21:24 schrieb Antonio Terceiro:


Looking from my side, the tarball from the archive (apt source
python-django-js-asset) and the one generated by pristine-tar are
identical:

4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
/tmp/python-django-js-asset_1.2.2.orig.tar.gz
4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
/tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz

 From reading the REJECT email, I think it implies that the .dsc/.changes
you uploaded refer to an orig tarball with 6360 bytes. Do you still have
the exact artifacts that you uploaded?


No, not completely.
But I played around a bit with gbp and pristine-tar too and I was able 
to recreate a tarball which has the same size and the same hashes as the 
*.tar.gz in the archive and the one you've posted by using pristine-tar 
manually.


If I clean out all completely and build the package from scratch by gbp 
I get again a wrong size and of course also different hashes.


Currently I've no real clue why gbp is creating here different results, 
will look again at this once Guido is around, I'm sure he can blame me 
that I'm doing something wrong. :P


I was able to upload 1.2.2-3 successful recently so no big problem any more.

--
Regards
Carsten

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Antonio Terceiro]

Hi,

On Sun, Sep 19, 2021 at 10:27:21AM +0200, Carsten Schoenert wrote:
> Hello Antonio,
> 
> as you initially did the first upload for this package I'm now heading
> over to you.
> 
> Am 19.09.21 um 09:48 schrieb Debian FTP Masters:
> > 
> > python-django-js-asset_1.2.2-3.dsc: Invalid size hash for 
> > python-django-js-asset_1.2.2.orig.tar.gz:
> > According to the control file the size hash should be 6360,
> > but python-django-js-asset_1.2.2.orig.tar.gz has 6367.
> > 
> > If you did not include python-django-js-asset_1.2.2.orig.tar.gz in your 
> > upload, a different version
> > might already be known to the archive software.
> 
> I've no idea where the size of 6360 for the orig.tar.gz file is coming
> from which DAK refers.
> 
> If I look at the source package sites or on snapshot.d.o I always see a
> size of 6367.
> 
> https://packages.debian.org/source/unstable/python-django-js-asset
> http://snapshot.debian.org/package/python-django-js-asset/1.2.2-1/
> 
> And this size was recreated by gbp locally.
> But the question is now how to proceed now. A quick & dirty solution
> would be to simply use the old tar.gz file (if available).
> Another option would be more dramatically and let remove the package
> completely from the archive. Do you have opinions on that?

Looking from my side, the tarball from the archive (apt source
python-django-js-asset) and the one generated by pristine-tar are
identical:

4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
/tmp/python-django-js-asset_1.2.2.orig.tar.gz
4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
/tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz

From reading the REJECT email, I think it implies that the .dsc/.changes
you uploaded refer to an orig tarball with 6360 bytes. Do you still have
the exact artifacts that you uploaded?


signature.asc
Description: PGP signature

Bug#952764: ITP: python-django-libsass -- django-compressor filter using libsass

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-libsass
  Version : 0.8
  Upstream Author : Matt Westcott 
* URL : https://github.com/torchbox/django-libsass/
* License : BSD-3-clause
  Programming Lang: Python
  Description : django-compressor filter using libsass

 A django-compressor filter to compile Sass files using libsass.  It builds on
 libsass-python to make @import paths aware of Django's staticfiles mechanism,
 and provides a filter module for django-compressor which uses the
 libsass-python API directly, avoiding the overheads of calling an external
 executable to do the compilation.

I do intend to maintain this package as part of DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl5ZaFgRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqyTgf+MpKlYbBsY6wJe41VmqSLhhn5WIIPNB+d
jmq1si+HsnGSbdTVa6orfrhEGW8XeWYRpRc6K3prnJQgMeDaTMXrWou+1HrcQprp
fm+y2jy+xpwOaqaxZQNQo8Ei5W+Y8UGjhxRm1AEsLJkCLV4fpnO+hMivFnMLKDZ4
SLkAcw25c7Le0s5+As6FciPSb128Spwd9/vC11r/XWDsHNTuDkYDS62rkpA9oTx6
7e/Q4kvfbCtiswfSCz7E2dKdspPO7NjwYqp7udL/ho6JEMIgyTVqAdH8qs7xD5CS
lQOzCYiFKmClb3KkyNekr7b74QXLr3v523Abn8MIAssMGY9nBoFo5w==
=yHRq
-END PGP SIGNATURE-

Bug#945247: ITP: python-django-rest-framework-guardian -- django-guardian support for Django REST Framework

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-rest-framework-guardian
  Version : 0.3.0
  Upstream Author : Ryan P Kilby 
* URL : https://github.com/rpkilby/django-rest-framework-guardian/
* License : BSD-3-clause
  Programming Lang: Python
  Description : django-guardian support for Django REST Framework

 django-rest-framework-guardian provides django-guardian integrations for Django
 REST Framework.
 It provides an ObjectPermissionsFilter to which will ensure that querysets only
 returns objects for which the user has the appropriate view permission and an
 ObjectPermissionsAssignmentMixin that allows permissions to be easily assigned
 to users and/or groups through serializers.

I intend to maintain this package as part of the DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl3W9CwRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wr8XggAtMRZvl0IZorRflGuVQR6p6c0sbI+NIhU
+P94bHDaq9sivb81J5ziXwgWGxKEmpwQa+KNCPEG579NL6N6+koAyhsKchyQX2WW
ny8iGz1J6apkyXlfYQPjCPto8UMIe0uW5LZR19dbGaXmAr/+COInaczKBYRneNkg
bftl8bK6nFar7y07JUwjuYXywTpTFGFST+L3kKG/Vx22lVBEUqeIk2Rg7OJKJIR4
RTYLsYIZLDejHmOP5NKMO9Jb09BFWZixzovDxc9bZ7bvStooASpAgj4Sd3BppU6g
qkZrkxQaIwkYz3r9KxD818PAjywbIZoPAdzyz/lCqYJkC6tXD4yX/w==
=cVy1
-END PGP SIGNATURE-

Bug#939350: RM: python-django-rosetta -- RoM; RC-buggy; no Python 3 support and no reverse deps; low popcon

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Doesn't support modern Django and FTBFS because of that (#933146).

Popcon 20.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#934561: RM: python-django-extdirect -- ROM; Python 2 only, leaf package, low popcon

[Ondřej Nový]

Package: ftp.debian.org
Severity: normal

Python 2 only, leaf package, low popcon.

Reverse dependencies checked with:
dak rm -Rn python-django-extdirect

Thanks.

Bug#934555: RM: python-django-piston -- ROM; Python 2 only, leaf package, low popcon

[Ondřej Nový]

Package: ftp.debian.org
Severity: normal

Python 2 only, leaf package, low popcon.

Reverse dependencies checked with:
dak rm -Rn python-django-piston

Thanks.

Bug#929620: ITP: python-django-storages -- storage backends in Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-storages
  Version : 1.7.1
  Upstream Author : Josh Schneier 
* URL : https://github.com/jschneier/django-storages/
* License : BSD-3-Clause, Expat
  Programming Lang: Python
  Description : storage backends in Django


 django-storages is a collection of custom storage backends for Django. Each
 storage backend has its own unique settings you will need to add to your
 settings.py file. Read the documentation for your storage engine(s) of choice
 to determine what you need to add.

I intend to maintain this package as part of DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlzr1xoRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WpZwgf/bY/LnCwGA+ODJGMC/5plSLKd0DhllDkA
LOQi9GTVMD+SuUN+HIPprHsgzs0smbVhGyAfbMVEUIkqZB6Iz7RfSHPoPm5aPU3A
viJ5rooUa0xldeOVzGE5q8lXRRmoXDjt0qKhxZJG6NfnQiLfAo69swzYDpaU7A3/
EaMD3rnkkLibmRZBXCXOP00jtPW7sFwprJI6ihpLsSgIYDLGOHol1Hv3xkbL3lYG
pu7ox/+iOU4IDR+tpa4QInTr2DcsYW64xKYwTULiW2cbLIZDpEHGnxsBp41aZwAN
qThSrD7kQSYl4jXS9cFZCvY8xSaQumZVJPvQ0uYozasM1Mz8pC/nNA==
=VEj8
-END PGP SIGNATURE-

Bug#929349: ITP: python-django-split-settings -- Organize Django settings into multiple files and directories

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-split-settings
  Version : 0.3.0
  Upstream Author : Nikita Sobolev, Visa Kopu, Antti Kaihola
* URL : https://github.com/sobolevn/django-split-settings/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Organize Django settings into multiple files and directories

 Organize Django settings into multiple files and directories. Easily override
 and modify settings. Use wildcards in settings file paths and mark settings
 files as optional.

I do intend to maintain this as part of DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlzk9igRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wp8/QgAw7dDr4UtfHLUUzTjx9rQhi2XovpEb1hl
Jp8iqhZGeEJh/nAE70sK3rgiIz/ScXmdyWPrTNv9oioViDM8g+1SmtJ8c5myvbk9
+Gm7gigB40qjl+lIb3UrmUhgeIK12pIiTe5YXuzqfP4CqEEMkvHVIpPNpnAVaNWo
y1O81e0NHWPwpYQk/eyWNAuKXOZTERnFqfYATrSbUbQ7qk91u0zxjdIzk/wM5im3
O+eRdDzdO2PjJrDaQRgLRHo1NTw6ff1eAC4eovDqEIjtFJ0XGWnUCFLkwKDdGxhT
yQJiZHm7ZqIBdTMHuXLzIs4oB6W0wEoH+nSXFDjAqWlcIlq2usHj3w==
=lTdO
-END PGP SIGNATURE-

Bug#929347: ITP: python-django-modelcluster -- clusters of models as a single unit

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-modelcluster
  Version : 4.4
  Upstream Author : Matthew Westcott 
* URL : https://github.com/wagtail/django-modelcluster/
* License : BSD-3-clause
  Programming Lang: Python
  Description : clusters of models as a single unit


 django-modelcluster extends Django's foreign key relations to make it possible
 to work with a 'cluster' of related objects, without necessarily holding them
 in the database. It introduces a new type of relation, ParentalKey, where the
 related models are stored locally to the 'parent' model until the parent is
 explicitly saved. Up to that point, the related models can still be accessed
 through a subset of the QuerySet API.

This is a prerequisite for wagtailcms and I intend to maintain it as part of
DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlzk8FkRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WpdkwgArliGcT6jN3LgX+ve257zsOsPJ5potafK
eBVZsb5Jie/UW0T5MnP22N4TcnO7eldhX9psfXZq+TMTToRiRoRJgGAI9lkJa5XX
w0M51iaBYVZh7WaibFhWjm7RRQ7fUKQiMjIqrwY7QtgQlR2/nHZ4QPGmmgCWorRD
gA3uxBMwzELBv7KWnrxGkrhgSwNPYADdoqFA/s6VQEHRRKEzhFHm6M3eyI+CAm+P
VrMAkz1M/tc2gGhI3IKAYt1puDR84ZJ3Ezz1eQxDHnJQ0Eoh59pUpDTlg9yRaJPa
eNo8aqSWqaq5PHSr8Ktzs5cn3j3yfoNF+sVg983Y2vEsTIbTBjRN3A==
=9sC9
-END PGP SIGNATURE-

Bug#928085: ITP: python-django-waffle -- feature flipper for Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-waffle
  Version : 0.16.0
  Upstream Author : James Socol 
* URL : https://github.com/django-waffle/django-waffle/
* License : BSD-3-clause
  Programming Lang: Python
  Description : feature flipper for Django

 Django Waffle is feature flipper for Django. You can define the conditions for
 which a flag should be active, and use it in a number of ways. Feature flags
 are a critical tool for continuously integrating and deploying applications.
 .
 Waffle aims to
  * provide a simple, intuitive API everywhere in your application;
  * cover common use cases with batteries-included;
  * be simple to install and manage;
  * be fast and robust enough to use in production; and
  * minimize dependencies and complexity.

I do intend to maintain this package as part of DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlzEm5MRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wrc4wgAgdhmvzUCRwtL0WQliPthXFWatcwOFpU9
C/5ePoIuY4ziK3lRMY77jXT62Gl1njJ1MGKaFPpdIq0UC7C6V7wV+WpsZfwokJv3
feJK/sAbL4Q4Qinuna+YrWWRTFTCVsVbbDaLDdpWeL8I5QvtBuddtmduwjjN4eLP
rRMFQWRJ1ZqS3iYnBJGVh82nkcbTpKkJwZQB1F0CD+mHG3quX5Qj85Ee1Oz8AxOK
3lkS9ta2zB9FLKfujRcJzF/jiUAB7TjTKLvYnOZu578IOuyJGcTtU5juhmNLuwdk
AH4JR0uDHOyrAnKODp6q2ELBf+ZmKjK3nJi0AVC/DrwAJZbbP0Erzg==
=eEtQ
-END PGP SIGNATURE-

Bug#912279: ITP: python-django-timezone-field -- database and form fields for pytz objects

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-timezone-field
  Version : 3.0
  Upstream Author : Mike Fogel 
* URL : https://github.com/mfogel/django-timezone-field/
* License : BSD-2-clause
  Programming Lang: Python
  Description : database and form fields for pytz objects

A Django app providing database and form fields for pytz timezone objects.

This is a requirement for python-django-celery-beat (>= 1.2.0).

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlvXY8QRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoolAf+NEowzGjtEwE6ey7m9rRDEg8LKAH7WIzL
C55Q1zyF0868Wc5NCOtX4OLVXtPQ8KEYO1iTHgCXsUV7afgzFvsJcev9H7MAQfAO
O/lZceieS03Sto/q2HS0dFN6j9Oxg6nnoKkcRhVOY5h+9+iNfiWH0bLj/jDto8lc
Yz2p4XtIVfPiIzhp6Ca3iVJz2UN+Bap1WTTP/kwiGxq4YaDZ5dZ8OMeXFuxaCEEe
aUzE/o/Esp2SlJbnZ8Cd4rTqWoCe42H8L5P/DxRcAilgDaXrlnaPuinzos75kdjx
HgDVxhDZM0q8rLkd4u8GTHoIrn1fJFnFCEXL7uC6x/xZt5S+SosMcQ==
=zSgM
-END PGP SIGNATURE-

Bug#906891: ITP: python-django-csp -- Content Security Policy for Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-csp
  Version : 3.4
  Upstream Author : James Socol 
* URL : https://github.com/mozilla/django-csp/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Content Security Policy for Django

 django-csp adds Content-Security-Policy headers to Django applications. It
 provides a middleware that takes care of setting the correct header values and
 has several configuration settings to create custom policies.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlt8d2URHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqxTAf8CJ2Bygn0jRfApuzq9dcRsCWt3md4oBao
X/zu+lcqRva3KvsQSA77E4TUXkanUO6f2cFyZEo7JO3zgeIb0AbPjJfiN3qe1BEw
/y9dWCjKcUrMXU0/8fxExR8nJrlBEEw6lhiPQwwzwahbcbEjBZaWVznDGBdT9917
0RzVCumRhZA7DD/9t7Zo0JBeEZNDFwDJI9HKEPHRY2F2uvdEgy5IoVUA6fDRLMNk
n+Rcy2KBQXviawpeivu9a+CDTz1zkB5t+1oQodtuLyFgDz1be1pIlDu3PT+IkCGj
0lcbeIbH3zZKtQuqLT3H6KQGuQp23eDBCi7oa2kv3ccNd4KX9LNygg==
=/d7s
-END PGP SIGNATURE-

Bug#903883: ITP: python-django-dbconn-retry -- reconnect on a failed database

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-dbconn-retry
  Version : 0.1.5
  Upstream Author : Jonas Maurus 
* URL : https://github.com/jdelic/django-dbconn-retry/
* License : BSD-3-clause
  Programming Lang: Python
  Description : reconnect on a failed database

 This library monkeypatches django.db.backends.base.BaseDatabaseWrapper so that
 when a database operation fails because the underlying TCP connection was
 already closed, it first tried to reconnect, instead of immediately raising an
 OperationException.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAltMOpMRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoIHwf/aZ/p6LNMKsCs5WzTxx76czSgkWnbnWwL
lmgAgKNq62KXexBnHqvbmbniM1pDRhcG8u+yCMdIZUU5JHMRvHSQ7W5vC/Nwr8Ns
EW6rwBpIRlUQxW/zouX9kGk7pJ89B8JOsZgaN0hyLgjo5UbhqjPWwwS1STcrlDJJ
84dWH2bO/TMotSNnyrnPWhMb/Q9aNLYtVpowtPmQ/QkFwcK7p2+uNFh3yoNd/5yK
47jqySCuDF4vAMqI5gfUR/WIENd0wD5bRcX475WyyfzWTg2bc09f6iugqO6t6k46
G7MuiCLfPGWfPGfK+FlR4JHKADlncWZTmkTYUSbxA3uoD3Xpez9+fw==
=mVdu
-END PGP SIGNATURE-

Re: write access to python-django-adminsortable and python-django-casclient git repos @ salsa

[Ondrej Novy]

Hi,

2018-05-09 13:16 GMT+02:00 Joost van Baal-Ilić <
joostvb-debian-python-2018050...@mdcc.cx>:

> Yes and yes.
>

thanks, welcome :).

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: write access to python-django-adminsortable and python-django-casclient git repos @ salsa

[Joost van Baal-Ilić]

Hi Ondřej,

On Wed, May 09, 2018 at 12:01:15PM +0200, Ondrej Novy wrote:
> 2018-05-05 15:52 GMT+02:00 Joost van Baal-Ilić <
> joostvb-debian-python-2018050...@mdcc.cx>:
> 
> > ... Could I
> > (joostvb@d.o) get write access again?  I've been told DPMT-membership is
> > what's
> > needed for that.
> 
> did you read http://python-modules.alioth.debian.org/policy.html and do you
> accept it?

Yes and yes.

Thanks! Bye,

Joost



signature.asc
Description: Digital signature

Re: write access to python-django-adminsortable and python-django-casclient git repos @ salsa

[Ondrej Novy]

Hi,

2018-05-05 15:52 GMT+02:00 Joost van Baal-Ilić <
joostvb-debian-python-2018050...@mdcc.cx>:

> ... Could I
> (joostvb@d.o) get write access again?  I've been told DPMT-membership is
> what's
> needed for that.
>

did you read http://python-modules.alioth.debian.org/policy.html and do you
accept it?

Thanks.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

write access to python-django-adminsortable and python-django-casclient git repos @ salsa

[Joost van Baal-Ilić]

Hi,

In 2016 I've been working on the python-django-adminsortable and
python-django-casclient Debian packages; Ondřej Nový  also worked on
those.  I'd like to squash an RC-bug in one of those packages.  It seems I've
lost my commit-access when these repo's moved from alioth to salsa.  Could I
(joostvb@d.o) get write access again?  I've been told DPMT-membership is what's
needed for that.

Thanks, Bye, Joost

-- 
26 Й дамъ вамъ сердце нобо й  дꙋхъ  нобъ дамъ вамъ, й  Ѽимꙋ сердце
каменное Ѽ плотн вашеѧ й дамъ вамъ сердце плотѧно,  й дхъ мой дамъ
въ васъ:  --Книга пророка Іеꙁекіилѧ.  Глава 36


signature.asc
Description: Digital signature

Bug#896557: ITP: python-django-nocaptcha-recaptcha -- Google No CAPTCHA reCAPTCHA widget for Django forms

[Alexandros Afentoulis]

Package: wnpp
Severity: wishlist
Owner: Alexandros Afentoulis <alexaf.d...@bloom.re>
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: python-django-nocaptcha-recaptcha
  Version : 0.0.20
  Upstream Author : Imaginary Landscape <jjasin...@imgescape.com>
* URL :
https://github.com/ImaginaryLandscape/django-nocaptcha-recaptcha
* License : BSD
  Programming Lang: Python
  Description : Google No CAPTCHA reCAPTCHA widget for Django forms

This python module allows creating Django forms with Google's "No
CAPTCHA" reCAPTCHA or reCAPTCHA version 2. This is the only available
reCAPTCHA since Google switched off version 1 in March 2018.

This package is not a dependency for others, its building dependencies
are already satisfied and has no running dependencies to other python
modules.

I already have a working debian package, tested against oldstable and
Django 1.8. I plan on git pushing the repository on salsa as soon as
possible. I will need a sponsor to upload that package and I would
certainly maintain it within a team if that's more appropriate.

Bug#884317: ITP: python-django-x509 -- x509 PKI certificates management for Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-x509
  Version : 0.3.2
  Upstream Author : Federico Capoano <f.capo...@cineca.it>
* URL : https://github.com/openwisp/django-x509/
* License : BSD-3-clause
  Programming Lang: Python
  Description : x509 PKI certificates management for Django

 Simple reusable django app implementing x509 PKI certificates management.
 .
 Features:
  * CA generation
  * Import existing CAs
  * End entity certificate generation
  * Import existing certificates
  * Certificate revocation
  * CRL view (public or protected)
  * Possibility to specify x509 extensions on each certificate
  * Random serial numbers based on uuid4 integers

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAloxiEARHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WpH5gf/QqABUoqaxpWbsJJ5/Y7NGidCJXkdkk+t
8U+z3f41v8F3cnrOHjFA9Qx5tS8a6aChzZ+AEGgYYazavXnSr5rcXj9jptt6wqML
w8i5GXDOHuVqXtyf+D0Ky0CTiWcvfc9tJc1iyd4jfa9n6pQB9h0b7M12ohtTJB5t
Veb85cCFLnFz5wuOIzbs8Y7ZDpVmg8co6C2vAJ6xgj7cQqkKQGRyJ2P4UEPAl//u
KA+VG8dPf4+xuC5PpRKMg72whCuAw72YFBJxw94X+DzoQQSvQsJrHA3Ao4lvGzxL
oXqemstFuvr2/YHwc/pOdqrtGTxx6kDXSHD0kwP1ShjGBUqbQaEjTw==
=IfFR
-END PGP SIGNATURE-

Bug#882612: ITP: python-django-channels -- Developer-friendly asynchrony for Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-channels
  Version : 1.1.8
  Upstream Author : Django Software Foundation <foundat...@djangoproject.com>
* URL : https://github.com/django/channels/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Developer-friendly asynchrony for Django

Channels is a project to make Django able to handle more than just plain HTTP
requests, including WebSockets and HTTP2, as well as the ability to run code
after a response has been sent for things like thumbnailing or background
calculation.
.
It’s an easy-to-understand extension of the Django view model, and easy to
integrate and deploy.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAloYb68RHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrUfAgAvm3ncost8O4M6p8FIsj8pU6weYZXjvLx
bNevDHHpaMyq+XSi3FIJSQUiqb3ruoFvAKiHI3QytTVsn98BUGcN9BZIj5SSNuja
NDuuhjNvVRPmf3FHXDsgROoZLG/OiQfQAnb3v/6J52JOfjt8dFS/2nGcftl92n7U
oLnRnVyn3lVd5WZaajRkYIUcKh2XMNuPHCq+1pDqhtaSl49BLEMtr7QiJ7L6ELW7
w0XoSHq7Gj70XtGIrfb5I4PfD0/wI4+ffViSwtLPA7UWB229xvTX2CvVoeEjHoaG
xq6o0fKFGOf9Us9MpwymAxPbP8HvbO5j9TR9T0F5cpibtf8ApycINg==
=TS5k
-END PGP SIGNATURE-

Bug#881606: ITP: python-django-celery-beat -- Database-backed Periodic Tasks

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-celery-beat
  Version : 1.1.0
  Upstream Author : Ask Solem <a...@celeryproject.org>
* URL : https://github.com/celery/django-celery-beat/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Database-backed Periodic Tasks

This extension enables you to store the periodic task schedule in the database.
.
The periodic tasks can be managed from the Django Admin interface, where you
can create, edit and delete periodic tasks and how often they should run.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAloJgOURHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoEGwf/dtc7jVsZEiBpdBix/SpLjXngW0ol/aXM
ucDzYc4Gd4JGtLdY/tw0rJZFK5V9h5yRjLefkIY2bBoaeLoNygXeueFcrnOr4S2L
0Tn73sQVX7DMqrLMQ4qOTB5cE7mMmPY3fngoDQ00W4OPfZP5YgzclEhGzoRuIN5A
Z7mBEM+RhRHSe3QoVwt+U7nUrfxvZZd4psUToyTYg1pzrQWXQpPs2DW81YoMY7Nh
ZFwUy7MXq0d8biPGmdlk3X7fz10JRz92vHGIKTsFlYdzq1viDau0+zmDXdTQ7pan
OPQSxbd79UXL3Q5Bkgw1cuk1jh6+/1EReTYw0JhCUTq6lG2O+5DYdQ==
=fba9
-END PGP SIGNATURE-

Bug#871640: ITP: python-django-celery-results -- Celery result backends for Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-celery-results
  Version : 1.0.1
  Upstream Author : Ask Solem <a...@celeryproject.org>
* URL : https://github.com/celery/django-celery-results/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Celery result backends for Django

 This extension enables you to store Celery task results using the Django ORM.
 .
 It defines a single model (django_celery_results.models.TaskResult) used to
 store task results, and you can query this database table like any other Django
 model.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlmMH6wRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoY8gf/UZjAs6ocs2/HgTvtGBfou8jt7+vtj8LQ
AusMa3XAnJXCLcprnrOvXeSgcIL4wnqDamiM4xNU248iPN/6ytgedPEM3wdBbWBE
Yl+wrc7MBLzWvVYi7PhGuijsDC230vZwzakFAHgcwoCHI1MPtUIpJ0Szw4/dJIMo
Ph1lFoyuoCySxYr6hnLeCDMRrhqiQjtwPecdmvFbopU1eupIxIFR7JA9n2K0FLqp
47cj8vIe3AgTd8NTFvpR36g3kFpteb68x3wgOeODsIUvDMqPdur+siRZ9eODdBdz
Xk61wYLesizsf+mWSkF65pzMPxOY+XasUlPMed/MEUtJJuO4cAtALQ==
=kHgA
-END PGP SIGNATURE-

Bug#868865: ITP: python-django-imagekit -- Automated image processing for Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-imagekit
  Version : 4.0.1
  Upstream Author : Matthew Tretter <m...@tthewwithanm.com>
* URL : https://github.com/matthewwithanm/django-imagekit/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Automated image processing for Django

 ImageKit is a Django app for processing images. Need a thumbnail? A
 black-and-white version of a user-uploaded image? ImageKit will make them for
 you. If you need to programmatically generate one image from another, you need
 ImageKit.
 .
 ImageKit comes with a bunch of image processors for common tasks like resizing
 and cropping, but you can also create your own.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAllvNR0RHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WovTAgArqSrjepDEm7WvKa4bz4CyoRmNd5cuRFJ
9h3RDN3V6vvGSDTQi1Go0nq6jA64vC188XlCbuozXquiUP8hSlrNlausQZgTAHm6
1E+OyypIcjZHZdzyrXJiuzzbXjwrMXqgkDALSeRUQyGe7HIpoPvx27DLowU9aaTj
8c7jeGiW0sV6DRIzE16amQbdaM/qh2tPNG/keH8Seuo1RJiqcAwq2JLdc3BV72ii
L/+4SiPBV/EVFfBp4aBW5lG409wAIwVDWXTCzZNxAE0WtwD7+vyXmkUMiOmDDCVi
U/lySU1RUXRe5m6nh3R/nQeRXIKqlZJNKdEXUt5YulS9GX6+uLoUMw==
=e9uz
-END PGP SIGNATURE-

Bug#864887: ITP: python-django-netfields -- Django PostgreSQL netfields implementation

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-netfields
  Version : 0.7
  Upstream Author : James Oakley <jf...@funktronics.ca>
* URL : https://github.com/jimfunk/django-postgresql-netfields/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Django PostgreSQL netfields implementation

 This project is an attempt at making proper PostgreSQL net related fields for
 Django. In Django pre 1.4 the built in IPAddressField does not support IPv6 and
 uses an inefficient HOST() cast in all lookups. As of 1.4 you can use
 GenericIPAddressField for IPv6, but the casting problem remains.
 .
 In addition to the basic IPAddressField replacement a CIDR and a MACADDR field
 have been added. This library also provides a manager that allows for advanced
 IP based lookup directly in the ORM.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAllD55URHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoHBwgAqp0kK185VilKQG3ymoNydm8k58roOsdI
oRQkzBXVA0YEHw4KxqK7L1eu77En3oddKZzDtr4izHPJPWZo5CDPpMBOfkScnANN
59SnxjHPCVWVYZ/4g6B4EOPLO6t+XYLk+Ukp7dwg02mAxUS/VrSmq/E0izP0Z/4f
3zR12542hxN8J8OsTc1l2rbQ7a0LAgBvYqfZRyNkzPkepcmH1CjGFTD2u1I66CVq
AFqh7PQku3WShpKDeEleamcoivzVCOO0d9DOz1D/kuWy/2pBA6M9ssERs0yGOSkO
EyzqiZfenml/i0LF6ZZ6oa/MJq5fDWyo9b4J0jW9NtpNDHTSHzkduA==
=6jfw
-END PGP SIGNATURE-

Bug#856637: ITP: python-django-push-notifications -- Send push notifications through GCM or APNS in Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-push-notifications
  Version : 1.4.1
  Upstream Author : Jerome Leclanche <jer...@leclan.ch>
* URL : https://github.com/jleclanche/django-push-notifications/
* License : Expat
  Programming Lang: Python
  Description : Send push notifications through GCM or APNS in Django

 A minimal Django app that implements Device models that can send messages
 through APNS, FCM/GCM and WNS. It provides three models:
 .
  * GCMDevice
  * APNSDevice
  * WNSDevice
 .
 The app also implements an admin panel, through which you can test single and
 bulk notifications.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAli5JQ4RHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoWLQf8Dpm1luwJNz8bboP5ydl5vdW/OfZ77wZG
hiMlDUyShozPr3wiw7pKDczF/zhTkdmxsUkRWpVgyxQ9C02JKjw6pgkwyHye6fKD
yjexN6mEDGpdaCw9dXIEERcpTs7OKPuuHY/pcwmram/AcwWy0PS4idoh//kep+wZ
esgIHlVeGXqh4iv2ppXdii3P6Adb0sAx9v/3z65TDvdfxjNjZpb29BjtqAZif8po
pO5qHHzBSWD1ZTFQscM6cC+iP1oLuvzQ3RePcbkcm3nP40m7dDOm9Q3AvPtb9pRK
kyM+WL0tkx1Kq9RPnH1lME8Thh+/Gus0tO+JeM+fYTo8ikWVU377vg==
=uY7A
-END PGP SIGNATURE-

Bug#856518: ITP: python-django-extra-views -- Complementary class-based generic views for Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-extra-views
  Version : 0.8.0
  Upstream Author : Andrew Ingram <a...@andrewingram.net>
* URL : https://github.com/AndrewIngram/django-extra-views/
* License : Expat
  Programming Lang: Python
  Description : Complementary class-based generic views for Django

 Django Extra Views provides a number of additional class-based generic views to
 complement those provide by Django itself.
 .
 Features:
  * FormSet and ModelFormSet views - The formset equivalents of FormView and
ModelFormView.
  * InlineFormSetView - Lets you edit formsets related to a model (uses
inlineformset_factory).
  * CreateWithInlinesView and UpdateWithInlinesView - Lets you edit a model and
its relations.
  * GenericInlineFormSetView, the equivalent of InlineFormSetView but for
GenericForeignKeys.
  * Support for generic inlines in CreateWithInlinesView and
UpdateWithInlinesView.
  * Support for naming each inline or formset with NamedFormsetsMixin.
  * SortableListMixin - Generic mixin for sorting functionality in your views.
  * SearchableListMixin - Generic mixin for search functionality in your views.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAli3QtIRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WpTiwgAhoVaRi+xw4K4SDrvWRzcPIcJqewbdoMg
ZpsAbcmCD8BIgxnZS8Dbj+/7q6Bb8ytHMQ31YNNoxEC/7BbUfKqOigtCI0oMONyH
0sepZANsJGFGNXKNaZf7Z8Qskv8GFZXgg4toO2ExLI45LpZwWz/VyQ1xQv1xzzXF
seliEG2ciMMHB9rxJ20PKMt1uKrBhp7/NP8dC/15Wh71/0KRDDfb6oGblJBlxKr6
1IbgZom2aJsou/+yUr9KCOz/244ZwMqiNd1P87Sw1pFXaiRc9BkQr9Al0yk4hSD5
wzC2/MMwynblxhVJ0vedoTRsQfHuotp35LUc5sfjh8E3F7sUfKECtA==
=FoEh
-END PGP SIGNATURE-

Bug#856454: ITP: python-django-otp -- pluggable framework for two-factor authentication

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-otp
  Version : 0.3.8
  Upstream Author : Peter Sagerson <psagersdjwub...@ignorare.net>
* URL : https://bitbucket.org/psagers/django-otp/
* License : BSD-2-clause
  Programming Lang: Python
  Description : pluggable framework for two-factor authentication

 This project makes it easy to add support for one-time passwords (OTPs) to
 Django. It can be integrated at various levels, depending on how much
 customization is required. It integrates with django.contrib.auth, although it
 is not a Django authentication backend. The primary target is developers
 wishing to incorporate OTPs into their Django projects as a form of two-factor
 authentication.
 .
 This project includes several simple OTP plugins and more are available
 separately. This package also includes an implementation of OATH HOTP and TOTP
 for convenience, as these are standard OTP algorithms used by multiple plugins.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAli2g8IRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wpqkwf/XzBWdDJvKagNcVWJCmuLjS6PcRgSqoN7
UAaPE3sXQXukFYjun1RrIexen+wRlCSvOWgBeUcTrzO3Rngp3wSvRR/YOjun6+WE
ad7jkNcY99D0WjkMxnUjxLhTT7iZpVa7j0hLpb9BRI+qFMT2cR9UTOeYW6yyx6Vk
lIv1BlcOw4x4FvyXMzTXJd+ZoaDWwdsTRLcDJWsx74+mjTNN9coChYVga5TjmDOC
wql9BHhAYsAeEBFRmHgxX8Yf/m8WZACPCnfFHAXZC3H26xffiQEqx3ABwEEi3jCB
mWI6Je7whwLR3RO/IZyjD9hetV9PKFzHEkFq4CjxYiZ3MYocbJGupg==
=cWnJ
-END PGP SIGNATURE-

Bug#854975: ITP: python-django-dynamic-scraper -- Manage Scrapy spiders through Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-dynamic-scraper
  Version : 0.11.3
  Upstream Author : Holger Drewes <holger.dre...@gmail.com>
* URL : https://github.com/holgerd77/django-dynamic-scraper
* License : BSD-3-clause
  Programming Lang: Python
  Description : Manage Scrapy spiders through Django

 Django Dynamic Scraper (DDS) is an app for Django build on top of the scraping
 framework Scrapy. While preserving many of the features of Scrapy it lets you
 dynamically create and manage spiders via the Django admin interface.
 .
 Features:
  * Create and manage scrapers for your Django models in the Django admin
interface
  * Many features of Scrapy like regular expressions, processors, pipelines
  * Image/screenshot scraping
  * Dynamic scheduling depending on crawling success via Django Celery
  * Checkers to check if items once scraped are still existing

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAligq18RHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrMuwf/QXgGRtG3mte11vigPzD1MYZD0bcgj5Xk
uoN7CnNTa5XAFSjizvvyygZy36vDOIcfkR+slV1uaUdMUmD5zuidBF2F0sPLK9KP
wltil4/NzY7tq6CgvrtJwl+KNAwc1t0izxGJUJH5PPKgIQaBn3jYNAj36ErX2ucS
5NDYZZhoW7EpoVpc/rdKsbCR3Utibus5pE5xgKCL018ZsOGFMBibdfjYwv3LbVh/
JKvwyQueGF71eJPdFfBRdAcI2zHJavA3OJaG5wWiaAmv6ewl1znAaGU4ylY3USzY
1b2/XOU6ig4lKiFKBIqPnaVBiVGBqbTTtoeXyx3OSclkDhGd1DBPpA==
=Kg0h
-END PGP SIGNATURE-

Re: python-django-mptt

[Brian May]

Thomas Goirand  writes:

> I just tried to fix the FTBFS of a few pakcages last aug. after the
> Django 1.10 upload indeed. But I can't remember what I did for this
> package, for which I don't care much (I just tried to be helpful
> globally in Debian in this case). Did I forget to include what I push to
> Git? :/

Ok, so it looks like the patch was applied, however the changelog entry
was not updated.

However I still can't get it to build.

So keeping the RC bug open is still appropriate.

I tried updating to the latest upstream version (see git) however now I
can't see how to run the tests (the supplied mptt/settings.py file is
insufficient).

It is not really important enough for me to worry much more.
-- 
Brian May 

Re: python-django-mptt

[Thomas Goirand]

On 02/01/2017 03:39 AM, Brian May wrote:
> On 2017-02-01 13:34, Brian May wrote:
> 
>> Ok, just noticed that the changelog in the uploaded package didn't
>> include this line to close the bug report.
>>
>> http://metadata.ftp-master.debian.org/changelogs/main/p/python-django-mptt/python-django-mptt_0.8.5-0.1_changelog
>>
>> I will close the bug report manually.
>>
>>  
>>
> Actually better clarify with the uploader first.
> 
>  
> 
> Thomas, did you fix #828669 when you uploaded version 0.8.5-0.1
> <http://metadata.ftp-master.debian.org/changelogs/main/p/python-django-mptt/python-django-mptt_0.8.5-0.1_changelog>
>  to
> Debian? The version uploaded doesn't have the following line in the
> changelog:
> 
> Add patch to fix FTBFS in Django 1.10 (Closes: #828669):
> 0001-django-1.10-Prepare-the-manager-using-code-for-Djang.patch
> 
> So it looks like you didn't fix this FTBFS, but I thought that was the point 
> of making this upload?

I just tried to fix the FTBFS of a few pakcages last aug. after the
Django 1.10 upload indeed. But I can't remember what I did for this
package, for which I don't care much (I just tried to be helpful
globally in Debian in this case). Did I forget to include what I push to
Git? :/

Cheers,

Thomas Goirand (zigo)

python-django-mptt

[Brian May]

Hello All, 

Why didn't the upload of python-django-mptt automatically close #828669?


Too late now, it was removed from testing and I think it is too late to
re-add. I don't think it is important. 

However I just wondered why this bug didn't get closed. 

(I thought I also responded to that last email too, but will have to
double check this) 

https://anonscm.debian.org/cgit/python-modules/packages/python-django-mptt.git/tree/debian/changelog


Regards

  

Re: Updating python-django-tagging (0.4.1 -> 0.4.3)

[Christos Trochalakis]

Hello,

On Wed, May 11, 2016 at 12:30:59PM +0100, Christopher Baines wrote:

Hey,

Is anyone available to review and upload a new version of
python-django-tagging [1][2]?

The changelog is:
 * New upstream release
 * Convert debian/copyright to the DEP-5 format
 * Add myself as an uploader
 * Remove the fix_calc_tag_weight patch, as this has been merged upstream
 * Remove the fix-testsuite patch, as this is unnecessary

Thanks,

Chris

1:
https://anonscm.debian.org/cgit/python-modules/packages/python-django-tagging.git/
2: https://tracker.debian.org/pkg/python-django-tagging



It's been a while. I have pushed an update since a new version is out
(0.4.5) and a smaller set of fixes. I plan to upload it in sid in a day
or two. So, anyone interested, please take a look.

Since python-django-tagging is removed from testing and currently no
re-entries are allowed, stretch might be released without the package.

Ufortunately this affects graphite-web which depends on
python-django-tagging. But, I assume that we can ask for an exception
from the release team. Either way, uploading to sid is a first step.

Bug#848120: ITP: python-django-etcd-settings -- config manager for Django apps based on ETCD

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-etcd-settings
  Version : 0.1.11
  Upstream Author : Enrique Paz <enrique.pazpe...@kpn.com>
* URL : https://github.com/kpn-digital/django-etcd-settings
* License : Apache-2
  Programming Lang: Python
  Description : config manager for Django apps based on ETCD.

 This application allows you to extend the Django settings as configured in the
 settings.py file with:
 .
  * Environment dependent values
  * Values in different config sets, identified by name, which can be selected
on a 'per request' basis using the X-DYNAMIC-SETTINGS HTTP header
 .
 Both the added configuration values and config sets would live at ETCD,
 which will be continuously monitored by this library in order to
 transparently update your app settings upon changes.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlhRFcIRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrpKAf/SAJqMKoehHx1c1iH/r1ZVsanzKb8f6eA
MxgCw62kyPuvY7buvsYGrvJRLYy0sSUyRlAiLiwjjNSFXmG7jHFo9dmRzoOQ4vkC
o7aIkVmQsnFIs5xNJex9Coqwr2zTXtGlaKIT9NDBtMBMEAXdZuNj7ZrzmbH7TNM6
IyiYMi5zGuqtsdRuMkdDmho0ARkAyAI/NZWpqthL1CeVreJVZBq7Vtwm/khKUAiX
l1Z11Szk+GB4JAiA5l0lAH2H5jn+g7Wli8JKUH61dJmueq81/oT09juNwBtj5ner
ZSpP8SlxNNYXyHqWWdi1FFcSiintMaQA8i1X6d5Uk+FYCz2nJYEx/g==
=F6fL
-END PGP SIGNATURE-

Re: Bug#847217: RFS: python-django-allauth/0.29.0-1 [ITP]

[Jan Luca Naumann]

Hey,

I forgot to mention that I upload the package to the Git repo of the
Python modules team as soon as my request to join the team is   accepted.

Best regards,
Jan

On Tue, 06 Dec 2016 16:16:17 +0100 Jan Luca Naumann
<j.naum...@fu-berlin.de> wrote:
> Package: sponsorship-requests Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "python-django-allauth"
> 
> * Package name: python-django-allauth Version : 
> 0.29.0-1 Upstream Author : Raymond Penners and contributors * URL :
> http://www.intenct.nl/projects/django-allauth/ * License : MIT 
> Section : python
> 
> It builds those binary packages:
> 
> python-django-allauth - Django apps for local and social 
> authentication (Python 2) python-django-allauth-doc - Django apps 
> for local and social authentication (common docs) 
> python3-django-allauth - Django apps for local and social 
> authentication (Python 3)
> 
> To access further information about this package, please visit the 
> following URL:
> 
> https://mentors.debian.net/package/python-django-allauth
> 
> Alternatively, one can download the package with dget using this 
> command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/p/python-django-allauth/python-django-allauth_0.29.0-1.dsc
>
>
>
>
> 
More information about python-django-allauth can be obtained from
> http://www.intenct.nl/projects/django-allauth/ .
> 
> Best regards, Jan
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#847217: RFS: python-django-allauth/0.29.0-1 [ITP]

[Jan Luca Naumann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-django-allauth"

 * Package name    : python-django-allauth
   Version : 0.29.0-1
   Upstream Author : Raymond Penners and contributors
 * URL : http://www.intenct.nl/projects/django-allauth/
 * License : MIT
   Section : python

It builds those binary packages:

 python-django-allauth - Django apps for local and social authentication 
(Python 2)
 python-django-allauth-doc - Django apps for local and social authentication 
(common docs)
 python3-django-allauth - Django apps for local and social authentication 
(Python 3)

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

 https://mentors.debian.net/package/python-django-allauth

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

 dget -x 
https://mentors.debian.net/debian/pool/main/p/python-django-allauth/python-django-allauth_0.29.0-1.dsc

More information about python-django-allauth can be obtained from
http://www.intenct.nl/projects/django-allauth/ .

Best regards,
Jan

Bug#830512: ITP: python-django-navtag -- Django template tag to handle navigation

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fl...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-navtag
  Version : 2.1.1
  Upstream Author : Chris Beaven <smileych...@gmail.com>
* URL : http://github.com/SmileyChris/django-navtag
* License : BSD-3-clause
  Programming Lang: Python
  Description : Django template tag to handle navigation


 A simple Django template tag to handle navigation item selection. It works
 through template inheritance and allows to define hierarchical navigation menu
 structures in the presentation layer. It differentiates itself from other
 solutions by sole reliance on templates.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXgAdFAAoJEGlMre9Rx7W2v1wP/jrPB3Ha3LV7iQa1KQ0mFTXl
Ml7yiSzwJ07E+lBCLj+8NVIcKhUqhCUYt3WFV3kkrDm0Dt2Rf+ZPkG0R4LkQO61r
yuaVn3iLcWmm92zPzf7kpDMiES1uNZ5gY2rNVQyhFh2Bbzbn7cxhthNr1CMNd9zh
geZfTqnG4mlak2sYGmTxElUl19HyCMJfr9kiMnAppmAUAzyHWafRpaNRlV8JE0tf
X6GAHUoZjlSIOCYSji/bYWTSA9ELry75sLp5dxBg1Hf1/nWgU6x4JWu1Zewr/VE6
BaCJbTBNlRueZx2tYEQvrdh/aLvD0Odd1QX0Bw+wwVGh71oJ14oqp7YWTmSDb1aS
UlaawTnJCsdlonT+a5xbqr3ixz3Hqzxtc+7KCGSd8dRyw/O3Wsz+uQ3/7v8d1PjC
zA8uCBbJS3N5TTPwqrzAIMSSAFhbta6Sko/8ZujRqkucGHuD3DsN/4QpC1ryEV93
qVRE0usRnh8pqBLp3qGTmZJ3EIBHemnIvC5Cb5kexq14QsTGV/7VMGhD8kjQi2xA
jfQnI8aF/TKdS72sJ0CpHrZwEre4KZLGeT72+I1HPjEgVerzBRaY+loa95sIj7P3
WF6HLsIbhCMXbzAyJ53JdvLgVQQnmJjX714LIdyx1U0CY821Ion7j504XDDguQ6G
XJD2nuirOk62hXAlz6zt
=6pIa
-END PGP SIGNATURE-

Updating python-django-tagging (0.4.1 -> 0.4.3)

[Christopher Baines]

Hey,

Is anyone available to review and upload a new version of
python-django-tagging [1][2]?

The changelog is:
  * New upstream release
  * Convert debian/copyright to the DEP-5 format
  * Add myself as an uploader
  * Remove the fix_calc_tag_weight patch, as this has been merged upstream
  * Remove the fix-testsuite patch, as this is unnecessary

Thanks,

Chris

1:
https://anonscm.debian.org/cgit/python-modules/packages/python-django-tagging.git/
2: https://tracker.debian.org/pkg/python-django-tagging



signature.asc
Description: OpenPGP digital signature

Re: Bug#819183: ITP: python-django-gravatar2 -- Essential Gravatar support for Django. Features helper methods and templatetags.

[Pierre-Elliott Bécue]

Le jeudi 24 mars 2016 à 12:09:00-0400, Pierre-Elliott Bécue a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: "Pierre-Elliott Bécue" <be...@crans.org>
> 
> * Package name: python-django-gravatar2
>   Version : 1.4.0
>   Upstream Author : Tristan Waddington
> * URL : https://github.com/twaddington/django-gravatar
> * License : MIT
>   Programming Lang: Python
>   Description : Essential Gravatar support for Django. Features helper 
> methods and templatetags.
> 
> A lightweight django-gravatar app. Includes helper methods for interacting 
> with gravatars
> outside of template code.
> .
> It features the following:
> .
>  * Helper methods for constructing a gravatar url and checking an email for 
> an existing
>gravatar
>  * Templatetags for generating a gravatar url or gravatar  tag.
> 
> This package provides gravatar features that are not yet present in django
> packages in Debian. It's also a dependency of HyperKitty, that I'm currently
> packaging.
> 
> I'd be happy to co maintain it with the DPMT, and I look for a sponsor who
> knows about django packaging.

Package VCS can be found here:

https://gitlab.pimeys.fr/PEB/python-django-gravatar2

Package results can be found there:

https://peb.pimeys.fr/packages/python-django-gravatar2/

-- 
PEB

Bug#819183: ITP: python-django-gravatar2 -- Essential Gravatar support for Django. Features helper methods and templatetags.

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: "Pierre-Elliott Bécue" <be...@crans.org>

* Package name    : python-django-gravatar2
  Version : 1.4.0
  Upstream Author : Tristan Waddington
* URL : https://github.com/twaddington/django-gravatar
* License : MIT
  Programming Lang: Python
  Description : Essential Gravatar support for Django. Features helper 
methods and templatetags.

A lightweight django-gravatar app. Includes helper methods for interacting with 
gravatars
outside of template code.
.
It features the following:
.
 * Helper methods for constructing a gravatar url and checking an email for an 
existing
   gravatar
 * Templatetags for generating a gravatar url or gravatar  tag.

This package provides gravatar features that are not yet present in django
packages in Debian. It's also a dependency of HyperKitty, that I'm currently
packaging.

I'd be happy to co maintain it with the DPMT, and I look for a sponsor who
knows about django packaging.

Re: Updating python-django-tagging

[Christopher Baines]

On 06/03/16 13:12, Christopher Baines wrote:
> I have been looking at updating the python-django-tagging package, as it
> currently fails to build from source, and there is a new upstream
> release available (that I believe will fix this).
> 
> However, git-dpm keeps complaining in different ways when I try to do
> this (and I have tried a few different ways). I think the source of the
> issues I am having could be that the debian/.git-dpm file is out of sync
> with the rest of the repository (it seems to still refer to the 0.3.1
> version, whereas the current version is 0.4).
> 
> What is the best approach here if I am trying to update the package? I
> can try and fix the debian/.git-dpm file (manually or using some tool?),
> or I could just avoid using git-dpm (but I do need to do some patch
> changes)?

To try and move this forward, I have made an attempt at fixing the metadata.

I have not updated the python modules team remote just yet, but you can
find the updates here [1], and the specific commit for the metadata here
[2].

If I hear no objections in the next couple of days, I'll update the
repository on git.debian.org.

1: http://git.cbaines.net/python-django-tagging/
2:
http://git.cbaines.net/python-django-tagging/commit/?id=2e528690df8792b2e70248ce18712ca653ede12b




signature.asc
Description: OpenPGP digital signature

Bug#818266: ITP: python-django-casclient -- CAS client library for Django, K-State's version

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist

* Package name: python-django-casclient
* URL : https://pypi.python.org/pypi/django-cas-client/, 
https://github.com/kstateome/django-cas
* License : MIT
  Programming Lang: Python
  Description : CAS client library for Django, K-State's version
 Django-cas is a CAS client library for Django.  It is K-State's
 fork of the original and includes Edmund Crewe's proxy ticket
 patch and several additional features as well as features merged
 from KTHse's django-cas2.

I'll work on the packaging using debian-python's git at Alioth, at
https://anonscm.debian.org/cgit/python-modules/packages/python-django-casclient 
.

Bye,

Joost




signature.asc
Description: Digital signature

Re: Updating python-django-tagging

[Barry Warsaw]

On Mar 07, 2016, at 10:24 AM, Brian May wrote:

>I really like the work flow of git-dpm. Think it is much better then
>gbp-pq, which IIRC stores and distributes the patch files in git.
>
>Shame it isn't better maintained. As a result, seems it is very easy to
>get it in a confused state (e.g. by not noticing the local upstream
>branch needs a fast forward) and doesn't handle merging of branches.

Just to be clear, I agree on all your points.  When git-dpm works, it works
great and you almost don't even have to think about.  I like tools that don't
make me think. :)

Cheers,
-Barry


pgpfNJKylJROt.pgp
Description: OpenPGP digital signature

Re: Updating python-django-tagging

[Brian May]

Barry Warsaw  writes:

> In some of my non-team packages I've been trying to use gbp-pq more.  It seems
> not terrible, and at least it's maintained.  Is it time to consider switching?
> Perhaps just on a trial basis?  When git-dpm works, it does work well.

I really like the work flow of git-dpm. Think it is much better then
gbp-pq, which IIRC stores and distributes the patch files in git.

Shame it isn't better maintained. As a result, seems it is very easy to
get it in a confused state (e.g. by not noticing the local upstream
branch needs a fast forward) and doesn't handle merging of branches.
-- 
Brian May 

Re: Updating python-django-tagging

[Barry Warsaw]

On Mar 06, 2016, at 01:12 PM, Christopher Baines wrote:

>However, git-dpm keeps complaining in different ways when I try to do
>this (and I have tried a few different ways). I think the source of the
>issues I am having could be that the debian/.git-dpm file is out of sync
>with the rest of the repository (it seems to still refer to the 0.3.1
>version, whereas the current version is 0.4).
>
>What is the best approach here if I am trying to update the package? I
>can try and fix the debian/.git-dpm file (manually or using some tool?),
>or I could just avoid using git-dpm (but I do need to do some patch
>changes)?

I don't really have any good suggestions.  I've had some weird problems with
git-dpm occasionally and no real solutions.  For example, it kept wanting to
turn a certain git commit in the patched branch into a double quilt patch, and
nothing I did seemed to work (I ended up giving up).

In some of my non-team packages I've been trying to use gbp-pq more.  It seems
not terrible, and at least it's maintained.  Is it time to consider switching?
Perhaps just on a trial basis?  When git-dpm works, it does work well.

Cheers,
-Barry


pgpNZJLDfuqc9.pgp
Description: OpenPGP digital signature

Updating python-django-tagging

[Christopher Baines]

Hello,

I have been looking at updating the python-django-tagging package, as it
currently fails to build from source, and there is a new upstream
release available (that I believe will fix this).

However, git-dpm keeps complaining in different ways when I try to do
this (and I have tried a few different ways). I think the source of the
issues I am having could be that the debian/.git-dpm file is out of sync
with the rest of the repository (it seems to still refer to the 0.3.1
version, whereas the current version is 0.4).

What is the best approach here if I am trying to update the package? I
can try and fix the debian/.git-dpm file (manually or using some tool?),
or I could just avoid using git-dpm (but I do need to do some patch
changes)?

Thanks,

Chris



signature.asc
Description: OpenPGP digital signature

Will fix python-django-registration RCs shortly (Was: Re: Request to join DPMT && python-django-registration)

[Stephan Sürken]

Hi list, interested parties,

On Mi, 2015-11-11 at 16:39 +0100, Stephan Sürken wrote:
> I would like to join the DPM Team. I am a DD, my user name on alioth is
> "absurd" (and yes, I read the policy document and I am aware of the git
> move ;).

seems I am still not in the official members list

https://alioth.debian.org/projects/python-modules/

but maybe I am just not getting something ;).

So anyway, this is to avoid maybe ongoing duplicate work. If no one
objects, I will...

> As first urgent quest I would like to fix the RC django 1.8 (I already
> did some work on that package for some time before it was moved to the
> DPMT).

...update the package shortly (i.e., within this week). This will focus
on minimal changes to make it work with django 1.8+.

> As for p-d-r in general: Has there been any discussion here already
> if/how to package 'p-d-r-redux' (which seems to be a (still maintained)
> fork)?

As we now have #806182, I am hoping for some discussion/advice there how
to exactly handle this in the future (I have not looked into *-redux at
all yet).

So the 1st question for me is whether it's really a drop-in replacement,
or if we might, at this point, create a new package *-redux (maybe with
the option to fix #567739, too).

Thx for any advice on this!

S



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

Re: Bug#806182: Will fix python-django-registration RCs shortly (Was: Re: Request to join DPMT && python-django-registration)

[James Bennett]

Stephan Sürken wrote:
>> As for p-d-r in general: Has there been any discussion here already
>> if/how to package 'p-d-r-redux' (which seems to be a (still maintained)
>> fork)?
> 
> As we now have #806182, I am hoping for some discussion/advice there how
> to exactly handle this in the future (I have not looked into *-redux at
> all yet).
> 
> So the 1st question for me is whether it's really a drop-in replacement,
> or if we might, at this point, create a new package *-redux (maybe with
> the option to fix #567739, too).

-redux is not a drop-in replacement. However, upstream
django-registration is 1.8 compatible as of the current release on PyPI,
and is about to gain a 1.9-compatible release as well. So please make
sure to check on what's happening in upstream before you duplicate the
work already done there:

https://github.com/ubernostrum/django-registration

Re: Bug#806182: Will fix python-django-registration RCs shortly (Was: Re: Request to join DPMT && python-django-registration)

[Stephan Sürken]

Hi James,

On Mi, 2016-01-06 at 06:23 -0600, James Bennett wrote:
(...)
> > So the 1st question for me is whether it's really a drop-in replacement,
> > or if we might, at this point, create a new package *-redux (maybe with
> > the option to fix #567739, too).
> 
> -redux is not a drop-in replacement. However, upstream
> django-registration is 1.8 compatible as of the current release on PyPI,
> and is about to gain a 1.9-compatible release as well. So please make
> sure to check on what's happening in upstream before you duplicate the
> work already done there:
> 
> https://github.com/ubernostrum/django-registration

ahh, thanks James, I guess now I understand your previous comment ;).

Let's see if I got this right:

django-registration is actually no longer discontinued, and now lives at

https://github.com/ubernostrum/django-registration

The (incompatible) *-redux fork lives at

https://github.com/macropin/django-registration

Thx!

S


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

Bug#810061: ITP: python-django-environ -- utilize 12factor inspired environment variables for Django

[Brian May]

Package: wnpp
Severity: wishlist
Owner: Brian May <b...@debian.org>

* Package name: python-django-environ
  Version : 0.4
  Upstream Author : joke2k
* URL : https://github.com/joke2k/django-environ/
* License : MIT
  Programming Lang: Python2 and Python3
  Description : Simplified environment variables for Django

Simplifies configuring key aspects of Django Applications through
environment variables.

I am hopeless with descriptions, any improvements to the above
description welcome.

This will be maintained as part of DPMT, and will be required for the
next release of django-guardian.

Re: Request to join DPMT && python-django-registration

[Stephan Sürken]

On Do, 2015-11-12 at 22:29 +0100, Stephan Sürken wrote:
> Hi Brian,
> 
> On Do, 2015-11-12 at 09:01 +1100, Brian May wrote:
> > Stephan Sürken  writes:
> > 
> > > As first urgent quest I would like to fix the RC django 1.8 (I already
> > > did some work on that package for some time before it was moved to the
> > > DPMT).
> > 
> > I am not sure what you are referring to here?
> 
> merely that I did some work for that package previously already (I am

...or maybe you just missed this hint:

https://bugs.debian.org/797208 ?

MfG,

S

Re: Request to join DPMT && python-django-registration

[Brian May]

Stephan Sürken <abs...@olurdix.de> writes:

> On Do, 2015-11-12 at 22:29 +0100, Stephan Sürken wrote:
>> > > As first urgent quest I would like to fix the RC django 1.8 (I already
>> > > did some work on that package for some time before it was moved to the
>> > > DPMT).
>> > 
>> > I am not sure what you are referring to here?
>> 
>> merely that I did some work for that package previously already (I am
>
> ...or maybe you just missed this hint:
>
> https://bugs.debian.org/797208 ?

Oh yes, I see. I didn't see the subject line, and he said django in the
body, not python-django-registration. Which got me confused, as
python-django has no RC bugs.
-- 
Brian May <b...@debian.org>

Re: Request to join DPMT && python-django-registration

[Stephan Sürken]

Hi Brian,

On Do, 2015-11-12 at 09:01 +1100, Brian May wrote:
> Stephan Sürken  writes:
> 
> > As first urgent quest I would like to fix the RC django 1.8 (I already
> > did some work on that package for some time before it was moved to the
> > DPMT).
> 
> I am not sure what you are referring to here?

merely that I did some work for that package previously already (I am
still listed there as Uploader), and that I would really like to see
that RC bug fixed.

Oh and I see it hasn't been moved to the DPMT recently -- I guess I was
referring to the move to git here ;)...

Hth,

S

Request to join DPMT && python-django-registration

[Stephan Sürken]

Hi fellows,

I would like to join the DPM Team. I am a DD, my user name on alioth is
"absurd" (and yes, I read the policy document and I am aware of the git
move ;).

As first urgent quest I would like to fix the RC django 1.8 (I already
did some work on that package for some time before it was moved to the
DPMT).

As for p-d-r in general: Has there been any discussion here already
if/how to package 'p-d-r-redux' (which seems to be a (still maintained)
fork)?

Thx!

S

Re: Request to join DPMT && python-django-registration

[Brian May]

Stephan Sürken  writes:

> As first urgent quest I would like to fix the RC django 1.8 (I already
> did some work on that package for some time before it was moved to the
> DPMT).

I am not sure what you are referring to here?
-- 
Brian May 

Re: python-django

[Raphael Hertzog]

On Sun, 11 Oct 2015, Brian May wrote:
> Just noticed how it named the upstream branches.
> 
> * [new branch] upstream-debian/experimental -> upstream-debian/experimental
> * [new branch] upstream-debian/jessie -> upstream-debian/jessie
> * [new branch] upstream-debian/sid -> upstream-debian/sid
> 
> Not sure this is ideal :-(

This definetely sucks, I want to continue to use upstream/1.7.x,
upstream/1.8.x and so on. We want to be able to maintain multiple
upstream branches in parallel, no matter where they are uploaded.

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: python-django-contact-form maintenance

[Andrew Starr-Bochicchio]

On Sun, Oct 11, 2015 at 10:49 AM, Christophe Siraut <d...@tobald.eu.org> wrote:
> I do not intend to continue maintaining python-django-contact-form, I
> just removed myself from the uploaders field, maintainer is DPMT.
> Tests are currently failing and package fails to build from source.
> Upstream released a new version 3 months ago.

Added myself to Uploaders and made an upload bringing in the new
version and resolving the build failure.

Thanks,

-- Andrew Starr-Bochicchio

   Ubuntu Developer <https://launchpad.net/~andrewsomething>
   Debian Developer <http://qa.debian.org/developer.php?login=asb>
   PGP/GPG Key ID: D53FDCB1

Re: python-django-contact-form maintenance

[Andrew Starr-Bochicchio]

On Sun, Oct 11, 2015 at 2:29 PM, W. Martin Borgert <deba...@debian.org> wrote:
> On 2015-10-11 16:49, Christophe Siraut wrote:
>> I do not intend to continue maintaining python-django-contact-form, I
>> just removed myself from the uploaders field, maintainer is DPMT.
>> Tests are currently failing and package fails to build from source.
>> Upstream released a new version 3 months ago.
>
> Christoph, can you confirm that upstream moved from bitbucket to
> github? Seems to be here:
> https://github.com/ubernostrum/django-contact-form
> Just to confuse me further, there is another, older project with
> the same name:
> https://github.com/jbergantine/django-contact-form

GitHub is where the source of the package on PyPi originates from:

https://pypi.python.org/pypi/django-contact-form/1.1

-- Andrew Starr-Bochicchio

   Ubuntu Developer <https://launchpad.net/~andrewsomething>
   Debian Developer <http://qa.debian.org/developer.php?login=asb>
   PGP/GPG Key ID: D53FDCB1

Re: python-django

[Barry Warsaw]

On Oct 10, 2015, at 09:13 AM, Raphael Hertzog wrote:

>Yes, except for the naming of branches where I would prefer to keep the
>DEP-14 naming scheme (we should just rename debian/sid into debian/master).
>
>http://dep.debian.net/deps/dep14/
>
>And I would suggest that we generalize the DEP-14 naming scheme as part of
>our git packaging policy...

I'm all for standardization, but I do like the shorter names for the common
case where you only need the unstable version.  Certainly if there are vendor
or series differences, the namespaces make a lot of sense.  But most of my
packages don't need it.

Would you be open to allowing such simplification in the common case in
DEP-14?

Cheers,
-Barry

Re: python-django

[Brian May]

On Sat, 10 Oct 2015 at 09:54 Brian May 
wrote:

> We can move the migrated version out of the way, restore the old version,
> and update it to the required standards (e.g. git-dpm). Is everyone happy
> with this approach?
>

Have moved the repository back. Should be usable exactly as before. Have
not yet tried to convert it to using git-dpm; might need to experiment a
bit and make sure I really do understand git-dpm before I start pushing
anything.

Re: python-django

[Brian May]

On Sun, 11 Oct 2015 at 13:50 Brian May 
wrote:

> I just converted and pushed these branches to git-dpm.
>
>
Just noticed how it named the upstream branches.

* [new branch] upstream-debian/experimental -> upstream-debian/experimental
* [new branch] upstream-debian/jessie -> upstream-debian/jessie
* [new branch] upstream-debian/sid -> upstream-debian/sid

Not sure this is ideal :-(

(yes, I did update debian/.git-dpm)

Re: python-django

[Brian May]

On Sun, 11 Oct 2015 at 11:40 Brian May 
wrote:

> Should we convert all branches to git-dpm? Or forget the branches
> referring to obsolete distributions?
>
> Probably should do these:
>
> origin/debian/experimental
> origin/debian/jessie
> origin/debian/sid
>

I just converted and pushed these branches to git-dpm.

I have not attempted to change the branch names. I have not attempted to
create the debian/README.sources file yet either.

I kept a copy of the original python-django.git on git.debian.org in case
anybody wants me to revert. It looks good to me.

I also updated debian/sid by applying a Python 3.5 fix from upstream and
updating to 1.7.10 with a security fix.

Unfortunately debian/sid does not build on sid, the tests fail:
"IndexError: index 5 is out of bounds for axis 0 with size 2" - I don't
think this is anything I did. It builds fine on Jessie.

Re: python-django

[Raphael Hertzog]

Hi,

On Fri, 09 Oct 2015, Brian May wrote:
> We can move the migrated version out of the way, restore the old version,
> and update it to the required standards (e.g. git-dpm). Is everyone happy
> with this approach?

Yes, except for the naming of branches where I would prefer to keep
the DEP-14 naming scheme (we should just rename debian/sid into debian/master).

http://dep.debian.net/deps/dep14/

And I would suggest that we generalize the DEP-14 naming scheme as part of
our git packaging policy...

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/

Bug#794829: ITP: python-django-cors-headers -- Django app for handling the server headers required for Cross-Origin Resource Sharing (CORS)

[Brian May]

Package: wnpp
Severity: wishlist
Owner: Brian May b...@debian.org

* Package name: python-django-cors-headers
  Version : 1.1.0
  Upstream Author : Otto Yiu
* URL : https://github.com/ottoyiu/django-cors-headers/
* License : MIT
  Programming Lang: Python2 and Python3
  Description : Django app for handling the server headers required for 
Cross-Origin Resource Sharing (CORS)

Pypi link: https://pypi.python.org/pypi/django-cors-headers

Will be DPMT maintained. Required for another package I am creating. I
think this is likely to be useful for other people besides myself.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150807011318.15108.81449.report...@prune.in.vpac.org

Bug#789711: ITP: python-django-oauth-toolkit -- OAuth2 capabilities for Django projects

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer fl...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-oauth-toolkit
  Version : 0.8.1
  Upstream Author : Federico Frenguelli synas...@gmail.com, Massimiliano 
Pippi mpi...@gmail.com
* URL : https://github.com/evonove/django-oauth-toolkit
* License : BSD
  Programming Lang: Python
  Description : OAuth2 capabilities for Django projects

 Django OAuth Toolkit can help you providing out of the box all the endpoints,
 data and logic needed to add OAuth2 capabilities to your Django projects.
 Django OAuth Toolkit makes extensive use of OAuthLib, so that everything is
 rfc-compliant.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJViaIlAAoJEGlMre9Rx7W2/DAQAKM0xgESTN94Up8mNp9i0LFf
i31seoZ8spPxQpk7PPcFCGfl8Q+Es2/g0AJqW8mj05Vnp6P0ipTQdfczTkQTN04m
n6N6x0gHIXqpHrhxZZ8TDOQcJz+JmGANs7uKJd8nHnQdUOODnsocO8zFH0nyCXFz
8ieYkE7G2KQ9bHYE33pUOdr6RrB2vGkozIgH3aRpVRwWJdt4y3Ia14UVRyO4f7J8
KHvaFq/xUBxHV/+Yc+qdgaONibkPwiINIodQ+M8egPNfp0CIVkJdma+o2gX37pBU
ytAvfEpPKFrUc/9zqTFWS16etWkr5aPuBPz85vd6yPvTtjlvdJ1y+Y9yjCYQyqzW
mD1shkMw0v+xkcS0ShYegXW5k9gpwbin7RA08gBwVSutVWKhw4iPkLZCzKdAaL7Q
5XXlCToq6rD27irXHmoqiorkN3Fz1TMB+PBSEJ1pFyCdLvklCs8jjwQkTJR9u2ob
mKg8xB/nYpVhHGaKLnHutCPrVZd0L4gjXMEqcHxcuYbcg3XV48avFou0gFfudEHq
Xl6/QmX0G5MVzJiStwu3Qx02Fi22Yl2mTiNcdDpt+hjbCwrnMIKBe57H3MS2M6xu
WjOS7KIG0UE83uRt8PoXPdXY/3BaSWUe5OHtHno6pZFNsgu0fBhZTBRkGSWwLXYi
8lH5WPDWraxhj1Awsd/h
=08zU
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150623181504.12570.22196.reportbug@kashyyyk.local

Re: Looking for a sponsor, just dput python-django-bootstrap to mentors.debian.net

[Vincent Cheng]

Hi Caio,

On Fri, Dec 5, 2014 at 6:45 AM, Caio Begotti caio.bego...@canonical.com wrote:
 Hi everyone! I just dput python-django-bootstrap to
 https://mentors.debian.net/package/django-bootstrap3 and marked it as
 needing a sponsor to review it etc. Would you be interested in it?

 I was not sure if this team had a different policy for RFS or what, so I
 decided to send this e-mail anyway hoping you guys would let me know if I
 did the wrong thing :-)

AFAIK there's no team-specific RFS policy. From what I've seen though,
sponsorship within the DPMT/PAPT often takes place via IRC (OFTC,
#debian-python), and relatively few RFS requests come through the
mailing list. I only saw this because I'm trying to work through my
email backlog at the moment...

Anyways, here's a quick review of your package:

- please file an ITP bug report [1] and close it in debian/changelog.
New packages should only have a single, short changelog entry
(typically something like Initial release (Closes: #xx)).
- debian/clean seems to be redundant with your override target in d/rules
- Vcs-{Svn,Browser} is missing in d/control; please apply for access
to the DPMT's svn repo at Alioth and upload (and maintain) your
package there, then add the missing Vcs-* fields to d/control
- I suggest following DEP-5 [3] for d/copyright, but that's up to you.
However, you should either have the full upstream license text in
d/copyright, or if it's a license available in
/usr/share/common-licenses, explicitly provide a link to the
appropriate license file. You also seem to be missing a
copyright+license statement for the packaging itself (debian/*).
- some issues caught by lintian that you can easily fix:

P: django-bootstrap3 source: no-dep5-copyright
P: python-django-bootstrap: no-upstream-changelog
I: python-django-bootstrap: extended-description-is-probably-too-short
I: python-django-bootstrap: possible-documentation-but-no-doc-base-registration

(HISTORY.rst looks like an upstream changelog to me)

- the build log contains a bunch of import errors when the docs are
built (i.e. ImportError: No module named django) - missing
build-dep?

Regards,
Vincent

[1] https://www.debian.org/devel/wnpp/
[2] https://alioth.debian.org/project/request.php?group_id=30714
[3] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACZd_tAFrNBsjsBQr9j2HB3t8-J7CeP+xwRyjgq-E=mkr5v...@mail.gmail.com

Looking for a sponsor, just dput python-django-bootstrap to mentors.debian.net

[Caio Begotti]

Hi everyone! I just dput python-django-bootstrap to
https://mentors.debian.net/package/django-bootstrap3 and marked it as
needing a sponsor to review it etc. Would you be interested in it?

I was not sure if this team had a different policy for RFS or what, so I
decided to send this e-mail anyway hoping you guys would let me know if I
did the wrong thing :-)

Cheers!

Bug#770779: unblock: python-django-guardian/1.2.4-2

[Brian May]

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

python-django-guardian was RC bug #763222. I believe this is a just a
technical bug in the tests, the actual package should work fine.
However, it means the package won't build.

This in turn has introduced an RC bug in djangorestframework #769216,
and other packages that depend on djangorestframework are scheduled for
removal from testing.

What would be considered an acceptable fix?

I could recommend:

* Just disabling the tests.

  Pros: easy patch.
  Con: potentially risky.

* Continue hacking on the tests until they work.
  I imagine this will mean:
  mv guardian/testapp/migrations guardian/testapp/south_migrations
  build new migrations in guardian/testapp

  Pros: We fix the problem and keep the tests.
  Cons: 1. While the process of generating the patch is going to be simple,
  the actual patch itself is going to be extensive, because of the
  requirement to move the exiting migration directory. 2. We start
  diverging more and more from upstream code.

* Use the upstream git code.

  While there are some bugs that we would have to patch, the total patch
  set would be a lot simpler this way. e.g. the following bugs are open
  upstream:

  https://github.com/lukaszb/django-guardian/issues/284
  https://github.com/lukaszb/django-guardian/issues/254

  Pros: I believe many problems we have hacked/patched in the Debian
  version are already fixed upstream, and if we stop diverging so much
  from upstream, it will make future updates (including security
  updates) much easier.
  Cons: We diverge from the current Debian version.

I don't have a solution just yet, however just trying to solicit
feedback if any of the above solutions would be considered acceptable
for the release team.

My favoured solution is the last one, because it is going to result in
the simplest package, with minimal differences from upstream.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE= (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141124005442.4496.94062.report...@aquitard.in.vpac.org

Re: /usr/bin/django-admin in python-django

[Karsten Hilbert]

On Mon, Jul 21, 2014 at 10:17:20AM +1000, Brian May wrote:

 Not sure I understand it (that space in ' ''' seems to be important?),

I would guess it creates a 3-quotes Python string embedded into a single-quote 
one:

test = ' single-quotes string with: '''3-quotes-string''' embedded into it'

Writing  would make the first quote escape the second.

Or some such :-)

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140721090148.ga4...@hermes.hilbert.loc

Re: /usr/bin/django-admin in python-django

[Matthias Urlichs]

Hi,

Karsten Hilbert:
 Writing  would make the first quote escape the second.
 
Not escape, but …

 Or some such :-)
 
To make this more explicit:

foo=''' '
echo This is Shell code
exec python $0
' '''
print(This is Python)

So to Python, you have a (multiline, hence the triple-quote) string which
contains of a space and a single quote, a linefeed, random text, and the
reverse linefeed-singlequote-space combo.

To the shell, $foo is a single space.

In fact, I would do this slightly differently:

#!/bin/sh
# -*- coding: utf-8 -*-

shell_code=''' '
echo This is Shell
exec python $0

python_code='''
## ONLY use DOUBLE quotes ‹› after this line
print(This is Python)

# End of Python code. Do not modify this line. #'

This way, dash -n $SCRIPT will ignore the Python code
(since it's a string) and not report a syntax error.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140721095510.ga15...@smurf.noris.de

Re: /usr/bin/django-admin in python-django

[Jakub Wilk]

* Brian May br...@microcomaustralia.com.au, 2014-07-20, 11:47:

Or, another words, ideally we want all these to work:

python2 /usr/bin/django-admin - python2
python3 /usr/bin/django-admin - python3
/usr/bin/django-admin - autodetect.


One possibility is to write a shell script that is also valid Python 
code. PoC:


#!/bin/sh
sh=
if command -v python3  /dev/null; then
exec python3 $0 $@
else
exec python $0 $@
fi
' '''
import sys
print(I'm Python %d.%d! % sys.version_info[:2])


Another possibility is to create the django-admin symlink in maintainer 
scripts, with the target depending on which of python*-django packages 
are installer. This is how src:sphinx manages its /usr/bin/sphinx-* 
symlinks.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720090004.ga2...@jwilk.net

Re: /usr/bin/django-admin in python-django

[Brian May]

On 20 July 2014 19:00, Jakub Wilk jw...@debian.org wrote:

 One possibility is to write a shell script that is also valid Python code.
 PoC:


Not sure I understand it (that space in ' ''' seems to be important?), but
it seems to work. Thanks.

Another possibility is to create the django-admin symlink in maintainer
 scripts, with the target depending on which of python*-django packages are
 installer. This is how src:sphinx manages its /usr/bin/sphinx-* symlinks.


Here we need to be able to specify an exact python version in most cases,
as the Python version used depends on the Django app installed. As well as
maintain compatibility with existing packages.

So the first approach seems to appropriate one here.
-- 
Brian May br...@microcomaustralia.com.au

Re: /usr/bin/django-admin in python-django

[Brian May]

On 7 July 2014 11:55, Brian May br...@microcomaustralia.com.au wrote:

 The problem is that the django-admin wrapper chose the python3 version,
 but karaage.tests.settings is only available in Python2, even though I have
 python3-django installed.



See bugs #755341 and #755321.

Looks like code is trying to run django-admin as a python script, allows it
to specify which version of python to use.

Only thing is, it isn't Python. It is now shell. This allows automatic
choosing of which Python version to use.

Unfortunately, it might be more important being able to manually specify
which Python version to use.
-- 
Brian May br...@microcomaustralia.com.au

Re: /usr/bin/django-admin in python-django

[Brian May]

On 20 July 2014 11:12, Brian May br...@microcomaustralia.com.au wrote:

 See bugs #755341 and #755321.

 Looks like code is trying to run django-admin as a python script, allows
 it to specify which version of python to use.

 Only thing is, it isn't Python. It is now shell. This allows automatic
 choosing of which Python version to use.

 Unfortunately, it might be more important being able to manually specify
 which Python version to use.


Or, another words, ideally we want all these to work:

python2 /usr/bin/django-admin - python2
python3 /usr/bin/django-admin - python3
/usr/bin/django-admin - autodetect.

Wonder if it is possible to have some magically hash bang line in
/use/bin/django-admin to autodetect the python version to use? e.g.

=== cut ===
#!/usr/bin/python-auto-detect
from django.core import management

if __name__ == __main__:
management.execute_from_command_line()
=== cut ===


-- 
Brian May br...@microcomaustralia.com.au

/usr/bin/django-admin in python-django

[Brian May]

While I am happy with the majority of this package, not sure about this
wrapper. It was designed to prevent conflicts between python-django and
python3-django.

As an example:

(wheezy)root@aquitard:~# /usr/bin/django-admin dumpdata
--settings=karaage.tests.settings
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/django/bin/django-admin.py, line
5, in module
management.execute_from_command_line()
  File
/usr/lib/python2.7/dist-packages/django/core/management/__init__.py, line
399, in execute_from_command_line
utility.execute()
  File
/usr/lib/python2.7/dist-packages/django/core/management/__init__.py, line
392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File
/usr/lib/python2.7/dist-packages/django/core/management/__init__.py, line
261, in fetch_command
commands = get_commands()
  File
/usr/lib/python2.7/dist-packages/django/core/management/__init__.py, line
107, in get_commands
apps = settings.INSTALLED_APPS
  File /usr/lib/python2.7/dist-packages/django/conf/__init__.py, line 54,
in __getattr__
self._setup(name)
  File /usr/lib/python2.7/dist-packages/django/conf/__init__.py, line 49,
in _setup
self._wrapped = Settings(settings_module)
  File /usr/lib/python2.7/dist-packages/django/conf/__init__.py, line
132, in __init__
% (self.SETTINGS_MODULE, e)
ImportError: Could not import settings 'karaage.tests.settings' (Is it on
sys.path? Is there an import error in the settings file?): No module named
tests.settings

The problem is that the django-admin wrapper chose the python3 version,
but karaage.tests.settings is only available in Python2, even though I have
python3-django installed.

However, anything I do here will mean making changes from upstream.

I guess I could also try to parse the --settings or DJANGO_SETTINGS_MODULE,
try to determine automatically if the Python3 version exists. However I
think this could get very messy very quickly and probably won't work in all
cases.


This is significant for me, as I have postinst scripts that do the
following:

django-admin collectstatic --settings=kgadmin.conf.settings --noinput

Have changed that now to:

python2.7 /usr/lib/python2.7/dist-packages/django/bin/django-admin.py \
collectstatic --settings=kgadmin.conf.settings --noinput

Can change it for new packages, not for old packages though. I don't see
any good solution for this though.

Hopefully nobody else does this :-)
-- 
Brian May br...@microcomaustralia.com.au

Re: python 3 and django (was: Is python-django still maintained in DPMT svn?)

[Brian May]

On 28 June 2014 20:43, Brian May b...@debian.org wrote:

 I personally will need python3-mysqldb, python3-psycopg, and python3-flup
 (or equivalent).


python3-psycopg: was replaced with  python3-psycopg2, packages are
available in wheezy and sid already. Have updated svn not to refer to the
psycopg any more, it already had psycopg2.

python-mysqldb: upstream does not support Python3, and development looks
very deadish.
http://mysql-python.sourceforge.net/

python-flup: upstream website is dead, connection times out:
http://www.saddi.com/software/flup/
Pypi indicates no releases in years, and no mention of Python 3 support:
https://pypi.python.org/pypi/flup
I see references to a slightly newer version on the upstream website, which
of course is dead:
https://github.com/pld-linux/python3-flup/blob/master/python3-flup.spec
links to
http://hg.saddi.com/flup-py3.0/archive/cc23b715b120.tar.bz2/flup-1.0.3_20120326.tar.bz2

Possibly (hopefully!) these packages are not required any more or have been
replaced by something else in Python 3, I don't know.
-- 
Brian May b...@debian.org

Re: python-django-jsonfield

[Brian May]

On 4 July 2014 12:13, Brian May br...@microcomaustralia.com.au wrote:

 I tried to go back to the correct version, django-jsonfield. It doesn't
 appear to work properly with Python3, something that I require. It imports
 six, but this seems to be very much incomplete. The tests fail under
 Python3.


If I apply the following patch, all tests pass under Python2 and Python3
without warnings under wheezy and sid.

So I might just apply the patch and upload to Debian. Seems like the safest
option.

Shame though this won't work out of the box with the version in Pypi. Most
of the changes involve tests only, so don't matter, there is one line that
is for a non-test file however.
-- 
Brian May br...@microcomaustralia.com.au


fix_tests_python3
Description: Binary data

python-django-jsonfield

[Brian May]

Hello,

I accidentally stuffed up and uploaded the wrong upstream. I have requested
my upload be rejected for now.

Compare:

https://pypi.python.org/pypi/django-jsonfield/0.9.12
https://pypi.python.org/pypi/jsonfield/0.9.20


I tried to go back to the correct version, django-jsonfield. It doesn't
appear to work properly with Python3, something that I require. It imports
six, but this seems to be very much incomplete. The tests fail under
Python3.

jsonfield, on the other hand, works with Python3 out of the box. It appears
to be very similar, although different feature set.

It looks like both are being developed upstream, neither have had a release
since last year, and while django-jsonfield now passes all Python3 tests,
it still produces a lot of (easy to fix) warnings, which makes me feel that
maybe jsonfield is the superior version, as it supports Python3 in PYPI
already, and tests run without any problems.

Can I switch to jsonfield? Or does the risk of breaking something outweigh
the benefits of a Python3 package in Debian?

Any other comments?

Thanks
-- 
Brian May br...@microcomaustralia.com.au

Re: Is python-django still maintained in DPMT svn?

[Thomas Goirand]

On 01/28/2014 10:45 PM, Luke Faraone wrote:
 I most probably did forget to push; I'll take a look later today. 
 
 Thanks for the poke, Raphaël, and thanks Barry for helping with the
 package! I've been lagging on adopting Python3 myself; it'll be great to
 have Django removed from the list of blockers for that transition. :)
 
   -- Luke

Hi there,

Is there any progress in adding Python 3 support in the Django package?

It'd be nice to not wait too long, because currently, without it to
support Python 3, there's no other way but to add django-* packages
without support for Python 3 as well, which is annoying (I'm having the
issue currently with python-django-pyscss).

Would you accept that I try to work it out?

Cheers,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ae6d72.1070...@debian.org

Re: python 3 and django (was: Is python-django still maintained in DPMT svn?)

[Thomas Goirand]

On 06/28/2014 03:23 PM, Thomas Goirand wrote:
 On 01/28/2014 10:45 PM, Luke Faraone wrote:
 I most probably did forget to push; I'll take a look later today. 

 Thanks for the poke, Raphaël, and thanks Barry for helping with the
 package! I've been lagging on adopting Python3 myself; it'll be great to
 have Django removed from the list of blockers for that transition. :)

   -- Luke
 
 Hi there,
 
 Is there any progress in adding Python 3 support in the Django package?
 
 It'd be nice to not wait too long, because currently, without it to
 support Python 3, there's no other way but to add django-* packages
 without support for Python 3 as well, which is annoying (I'm having the
 issue currently with python-django-pyscss).
 
 Would you accept that I try to work it out?
 
 Cheers,
 
 Thomas Goirand (zigo)

I just saw that Brian May added some commits in the SVN to add Python3
support to it. :)

Brian, what's left to do before the upload?

BTW, I saw that you've added some Suggests: for packages which do not
exist yet in Debian (like python3-mysqldb, python3-psycopg,
python3-flup, and probably some more). Should we try to add Python 3
support to these first? Are they Python 3.4 compatible?

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ae7024.1040...@debian.org

Re: python 3 and django (was: Is python-django still maintained in DPMT svn?)

[Brian May]

On 28 June 2014 17:35, Thomas Goirand z...@debian.org wrote:

 I just saw that Brian May added some commits in the SVN to add Python3
 support to it. :)

 Brian, what's left to do before the upload?


See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736878

Basically everything is done, except I uploaded to DELAYED/10 - I have been
told I have should have made a normal non-delayed upload, it will be
delayed in NEW anyway. Not yet had a chance to fix this. If it is possible
for somebody else to alter the position first, please do so.


BTW, I saw that you've added some Suggests: for packages which do not
 exist yet in Debian (like python3-mysqldb, python3-psycopg,
 python3-flup, and probably some more). Should we try to add Python 3
 support to these first? Are they Python 3.4 compatible?


I basically copied and edited the entries for the Python2 version :-)

I personally will need python3-mysqldb, python3-psycopg, and python3-flup
(or equivalent).

django-south will be included in Django 1.7, and as such will have Python 3
support. They have just released 1.7RC1, so it should be too much longer
before 1.7 is released.
-- 
Brian May b...@debian.org

Re: Is python-django still maintained in DPMT svn?

[Brian May]

On 28 June 2014 17:23, Thomas Goirand z...@debian.org wrote:

 Is there any progress in adding Python 3 support in the Django package?


See  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736878

Also see other thread on debian-python, I just replied there.

In short, yes.

It'd be nice to not wait too long, because currently, without it to
 support Python 3, there's no other way but to add django-* packages
 without support for Python 3 as well, which is annoying (I'm having the
 issue currently with python-django-pyscss).


Yes, that should be possible when this package gets in. Have had similar
concerns myself.
-- 
Brian May br...@microcomaustralia.com.au

Re: python 3 and django (was: Is python-django still maintained in DPMT svn?)

[Brian May]

On 28 June 2014 20:43, Brian May b...@debian.org wrote:

 django-south will be included in Django 1.7, and as such will have Python
 3 support. They have just released 1.7RC1, so it should be too much longer
 before 1.7 is released.


Obviously I meant to say should not be too much longer.

I was told that django-south should sort of work with Python 3, but
probably not much point packaging a python3-django-south.

http://south.aeracode.org/ticket/1210
-- 
Brian May b...@debian.org

ITA: python-django-contact-form -- extensible contact-form application for Django

[Christophe Siraut]

retitle 705275 ITA: python-django-contact-form -- extensible contact-form 
application for Django
owner 705275 !
thanks

Hi,

I am using python-django-contact-form and I am willing to take care of
the package.

Cheers,
Christophe


signature.asc
Description: Digital signature

Bug#737485: RFP: python-django-localflavor -- Country-specific Django helpers

[Marcelo Jorge Vieira]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-python@lists.debian.org

* Package name: python-django-localflavor
  Version : 1.0
  Upstream Author : Django Software Foundation
* URL : http://github.com/cowboy/grunt/
* License : BSD
  Programming Lang: Python
  Description : Country-specific Django helpers

Django's localflavor packages offer additional functionality for particular 
countries or cultures. For example, these might include form fields for your 
country's postal codes, phone number formats or government ID numbers.

This code used to live in Django proper -- in django.contrib.localflavor -- but 
was separated into a standalone package in Django 1.5 to keep the framework's 
core clean.


Cheers,

-- 
Marcelo Jorge Vieira
xmpp:me...@jabber-br.org
http://metaldot.alucinados.com


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

Is python-django still maintained in DPMT svn?

[Barry Warsaw]

I ask because:

% rmadison python-django | grep sid
 python-django | 1.6.1-1| sid   | source, all

% debcheckout -a --source=never python-django
...

% grep -i svn debian/control 
Vcs-Svn: svn://anonscm.debian.org/python-modules/packages/python-django/trunk/

% head debian/changelog 
python-django (1.5.3-1) unstable; urgency=high

% apt-get source python-django
...

% head debian/changelog 
python-django (1.6.1-1) unstable; urgency=medium

As the package is supposed to be team maintained, I'm wondering *where* it's
maintained.  I have some patches to fix build failures against Sphinx 1.2.1.

Cheers,
-Barry

PS. I suppose I should add myself to Uploaders?


signature.asc
Description: PGP signature

Re: Is python-django still maintained in DPMT svn?

[Raphael Hertzog]

Hi Barry,

On Tue, 28 Jan 2014, Barry Warsaw wrote:
 As the package is supposed to be team maintained, I'm wondering *where* it's
 maintained.  I have some patches to fix build failures against Sphinx 1.2.1.

Good question. Luke, are you using git-svn and you forgot to push or
something?

 PS. I suppose I should add myself to Uploaders?

Not required if you don't intend to work regularly on it. Just put Team
upload in the changelog and lintian will be happy.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128131627.gc15...@x230-buxy.home.ouaza.com

Re: Is python-django still maintained in DPMT svn?

[Barry Warsaw]

Hi Raphaël,

On Jan 28, 2014, at 02:16 PM, Raphael Hertzog wrote:

Hi Barry,
 As the package is supposed to be team maintained, I'm wondering *where* it's
 maintained.  I have some patches to fix build failures against Sphinx 1.2.1.

Good question. Luke, are you using git-svn and you forgot to push or
something?

Let me know; if not I can just update svn by slamming `apt-get source`s
debian/ over the svn version.

 PS. I suppose I should add myself to Uploaders?

Not required if you don't intend to work regularly on it. Just put Team
upload in the changelog and lintian will be happy.

Cool.  I may also take a look at #736878 (Python 3 support).

-Barry


signature.asc
Description: PGP signature