Re: sphinx-build vs. Python 3

[Ondrej Novy]

Hi,

po 20. 8. 2018 v 12:37 odesílatel Thomas Goirand  napsal:

> If you do the later, then anyway, you'll have to do the former if you
> need backports. This bite me a few times with OpenStack already. So, no
> mater what the faith of the sphinx-build command, it's always best to
> use python3 -m sphinx, IMO.
>

agree. So:

https://salsa.debian.org/python-team/modules/python-pymysql/commit/b562fc29c311249fcb34639cc2a7d3267dd1f818
(only if python3-sphinx is in B-D)

Any thoughts?

-- 
Best regards
 Ondřej Nový

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

Re: sphinx-build vs. Python 3

[Thomas Goirand]

On 08/21/2018 10:26 AM, Ondrej Novy wrote:
> Hi,
> 
> po 20. 8. 2018 v 12:37 odesílatel Thomas Goirand  > napsal:
> 
> If you do the later, then anyway, you'll have to do the former if you
> need backports. This bite me a few times with OpenStack already. So, no
> mater what the faith of the sphinx-build command, it's always best to
> use python3 -m sphinx, IMO.
> 
> 
> agree. So:
> 
> https://salsa.debian.org/python-team/modules/python-pymysql/commit/b562fc29c311249fcb34639cc2a7d3267dd1f818
> (only if python3-sphinx is in B-D)
> 
> Any thoughts?

On top of this, I generally also do PYTHON=python3, just in case the
Sphinx doc needs to invoke the interpreter...

Cheers,

Thomas Goirand (zigo)

Re: sphinx-build vs. Python 3

[Ondrej Novy]

Hi,

út 21. 8. 2018 v 12:37 odesílatel Thomas Goirand  napsal:

> On top of this, I generally also do PYTHON=python3, just in case the
> Sphinx doc needs to invoke the interpreter...
>

i don't think this is good idea. If Sphinx doc needs to invoke interpreter,
it should do it in more smart way. Overriding default is not solution, just
fix that docs source code.

-- 
Best regards
 Ondřej Nový

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

Re: sphinx-build vs. Python 3

[Dmitry Shachnev]

Hi Ondřej!

On Mon, Aug 20, 2018 at 09:50:25AM +0200, Ondrej Novy wrote:
> Hi,
>
> I have question about sphinx-build and our effort to move to Python 3.
>
> sphinx-build is currently Python 2 or Python 3 according to python-sphinx /
> python3-sphinx package installed (with python3 as default if both are
> installed by alternative priority).
>
> According to:
> https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation we
> should use "python3 -m sphinx" if we want to build docs using Python 3,
> because if you run sphinx-build, you can't be sure which version of Sphinx
> is run and if you need some Sphinx extension, which we typically installs
> only Python 2 or Python 3 version of it.

That wiki page was written before I changed Sphinx scripts to use Python 3
by default. That happened only recently, the relevant upload reached
unstable on July 5th 2018.

If you depend on python3-sphinx (>= 1.7.5-4~) then most likely the scripts
will be using Python 3. The opposite will happen only if the user manually
updated the alternative, and this won’t be the case on a sane build
environment.

> And my question is:
> * should we use "python3 -m sphinx" instead of "sphinx-build" everywhere
> where python3-sphinx is in B-D (mass-commit?)

This won’t hurt, but as I said it won’t make any difference on the current
unstable. It will make difference only when building against an older version
of sphinx (e.g. backports) *and* with installed python-sphinx.

> * should we change sphinx-build to be Python3 only? (and broke current
> packages build with Python2 Sphinx)

I would like to do this in the future, but currently there will be too
many broken packages:

https://lintian.debian.org/tags/build-depends-on-python-sphinx-only.html
lists 386 packages.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: sphinx-build vs. Python 3

[Mattia Rizzolo]

On Tue, Aug 21, 2018 at 04:03:20PM +0300, Dmitry Shachnev wrote:
> If you depend on python3-sphinx (>= 1.7.5-4~) then most likely the scripts
> will be using Python 3. The opposite will happen only if the user manually
> updated the alternative, and this won’t be the case on a sane build
> environment.

I'm not so sure about this.  I don't remember Policy specifying whether
a build process can make assumptions on the configuration of possible
alternatives, and at any rate I wouldn't bet my build process on that:
after all you talk about "sane build environment", but I don't remember
any kind of consensus that said building on your dirty daily system is
not supported.

I'm personally biased as a member of the Reproducible Builds team that
believe any possible variable in the environment must not affect the
build result, this sounds like yet another one to me.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: 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-

Re: RFS: pcapy/0.11.3-1 [ITA]

[eamanu15]

Hello Sergio,



No problem.  However, the "License:" still doesn't reflect the license
> of the software.  According to LICENSE:
>
>   We provide this software under a slightly modified version of the
>   Apache Software License. The only changes to the document were the
>   replacement of "Apache" with "Pcapy" and "Apache Software Foundation"
>   with "CORE Security Technologies". Feel free to compare the resulting
>   document to the official Apache license.
>
>   The `Apache Software License' is an Open Source Initiative Approved
>   License.
>
> Therefore, I think a better value for the field would be:
>
>   License: Apache with Pcapy modifications
>

Ready!


> Also, please remove the "All rights reserved." text here:
>
>   Copyright (C) 2003-2011 CORE Security Technologies .
>
>All rights reserved.
>

Ready!


> Oh, and please fix the years.  Nowhere in the code I see "2003-2011".
> Doing a basic grep, I see that the year should be 2014.
>

Ready

>
> I see that the contributions under the debian/ directory are released
> under GPL-3+.  That's absolutely fine (I am a GPL advocate as well).
> However, I must warn you that the Debian patches will also be released
> under this license, which may be problematic if/when you decide to
> upstream them.  But I understand this is the current situation anyway.
> You may want to try to contact Arnaud Fontaine and ask him if he's OK
> with changing the license to Apache in the future.
>

Ok. I will contact Arnaud Fontaine to ask about it. I think it's ok for
now. In the next release of package I can update this field.

Thanks, but what you did is incomplete.  In order to create a new
> package, you have to create an entry for it on d/control.  What you did
> (add ${python3:Depends} to python-pcapy's Depends) is wrong because
> you're basically pulling Python 3 dependencies for a Python 2 package.
> Please have a look at other packages under them DPMT and check their
> d/control; you will find many examples of how to create Python 3
> packages.
>

Ready!

Thanks for your help!
Regards!

-- 
Arias Emmanuel
https://www.linkedin.com/in/emmanuel-arias-437a6a8a
http://eamanu.com

Re: RFS: pcapy/0.11.3-1 [ITA]

[Sergio Durigan Junior]

Hi Emmanuel,

Sorry, you still have to fix a few things before the package is ready
for upload.  We're almost there; don't give up!

On Tuesday, August 21 2018, eamanu wrote:

> No problem.  However, the "License:" still doesn't reflect the license
>> of the software.  According to LICENSE:
>>
>>   We provide this software under a slightly modified version of the
>>   Apache Software License. The only changes to the document were the
>>   replacement of "Apache" with "Pcapy" and "Apache Software Foundation"
>>   with "CORE Security Technologies". Feel free to compare the resulting
>>   document to the official Apache license.
>>
>>   The `Apache Software License' is an Open Source Initiative Approved
>>   License.
>>
>> Therefore, I think a better value for the field would be:
>>
>>   License: Apache with Pcapy modifications
>>
>
> Ready!

Thanks.  The "License:" must be the same in both places, though.  Here:

  Files: *
  Copyright (C) 2014 CORE Security Technologies . 
  License: Apache Software License with Pcapy modifications

and here:

  License: Apache with Pcapy modifications
   We provide this software under a slightly modified version of the
   ...

It's OK to use "Apache with Pcapy modifications" in both places.

>> I see that the contributions under the debian/ directory are released
>> under GPL-3+.  That's absolutely fine (I am a GPL advocate as well).
>> However, I must warn you that the Debian patches will also be released
>> under this license, which may be problematic if/when you decide to
>> upstream them.  But I understand this is the current situation anyway.
>> You may want to try to contact Arnaud Fontaine and ask him if he's OK
>> with changing the license to Apache in the future.
>>
>
> Ok. I will contact Arnaud Fontaine to ask about it. I think it's ok for
> now. In the next release of package I can update this field.

Great.  It's OK for now, indeed.

> Thanks, but what you did is incomplete.  In order to create a new
>> package, you have to create an entry for it on d/control.  What you did
>> (add ${python3:Depends} to python-pcapy's Depends) is wrong because
>> you're basically pulling Python 3 dependencies for a Python 2 package.
>> Please have a look at other packages under them DPMT and check their
>> d/control; you will find many examples of how to create Python 3
>> packages.
>>
>
> Ready!

Thanks, that's better, but there are still a few things that need
fixing.

1) It's a good practice to explicitly say if the package is a Python 2
or Python 3 module.  We do that by suffixing the short description with
"(Python X)" (where X is 2 or 2), and by appending "This package
installs the library for Python X." to the long description.  Like this:

  Package: python-pcapy
  Architecture: any
  Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
  Recommends: python-impacket
  Description: Python interface to the libpcap packet capture library (Python 2)
   Pcapy is a  Python extension module that interfaces  with the libpcap
   packet capture library.
   .
   Pcapy enables Python scripts to capture packets on the network. Pcapy
   is highly  effective when used in conjunction  with a packet-handling
   package such as Impacket, which is a collection of Python classes for
   constructing and dissecting network packets.
   .
   This package installs the library for Python 2.

2) You don't need to specify "Provides:".  Please remove them from both
packages.


As a last note, it seems that you forgot to push the "upstream" and
"pristine-tar" branches, so I can't really build the package locally
here.  Please do that.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature