[Python-modules-team] Accepted chargebee2-python 2.4.9-1 (source all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 30 Mar 2018 20:19:53 -0400
Source: chargebee2-python
Binary: python-chargebee2 python3-chargebee2
Architecture: source all
Version: 2.4.9-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-chargebee2 - Python library for integrating with Chargebee (Python 
2/API v2)
 python3-chargebee2 - Python library for integrating with Chargebee (Python 
3/API v2)
Changes:
 chargebee2-python (2.4.9-1) unstable; urgency=medium
 .
   * New upstream release
Checksums-Sha1:
 a40580054fb4d0c8446c967835f8426b150263ec 2188 chargebee2-python_2.4.9-1.dsc
 81dfa064e36114bb82dc51c4b14476a0e77d05a6 148706 
chargebee2-python_2.4.9.orig.tar.gz
 b59d4ae2fca4e951500b4896a6e5475fd704c428 3172 
chargebee2-python_2.4.9-1.debian.tar.xz
 d2ca414246aa22a24e66c7e961cbdb95ab358768 6121 
chargebee2-python_2.4.9-1_amd64.buildinfo
 21382ca2357d3050a0e489f94c532a7c9e778464 139764 
python-chargebee2_2.4.9-1_all.deb
 7e0178b7f09b7d47ddc8517c3e0de66f8bd3f0c2 139824 
python3-chargebee2_2.4.9-1_all.deb
Checksums-Sha256:
 3d678762dbaf7636d59f1ba4b79ef64fbf9898769e59f295dd10d964850dfc95 2188 
chargebee2-python_2.4.9-1.dsc
 fa1b225c7505fd0ee213874c71a96c61e9555d93deb503fb5a633bfbf8163b05 148706 
chargebee2-python_2.4.9.orig.tar.gz
 52c2e3395e5e2d887039eaff7bac26aac8401e0a9100828520694117daa42b18 3172 
chargebee2-python_2.4.9-1.debian.tar.xz
 47fdc4de2df519748940ccc53c7163cb3639cd91233bab9e5515c03ffb8b2213 6121 
chargebee2-python_2.4.9-1_amd64.buildinfo
 ca554b4a8640a440d11bdeec634d5c46875315f979917708d6244f63d329d99a 139764 
python-chargebee2_2.4.9-1_all.deb
 c5bc37fca5a0e5b514246064f60d5bcdc0bc4c2777246760df142eadafa2a11a 139824 
python3-chargebee2_2.4.9-1_all.deb
Files:
 8b00b91a34075c02be5ac2953186d3ff 2188 contrib/python optional 
chargebee2-python_2.4.9-1.dsc
 73f5fcc9ef51de627af528d45058a562 148706 contrib/python optional 
chargebee2-python_2.4.9.orig.tar.gz
 f8ae8aed5c381d106a72e76b044f3c44 3172 contrib/python optional 
chargebee2-python_2.4.9-1.debian.tar.xz
 4e9df10214176e6ef54706fdfa8e594e 6121 contrib/python optional 
chargebee2-python_2.4.9-1_amd64.buildinfo
 39c08d08363a4482022bef13b5b7d1f0 139764 contrib/python optional 
python-chargebee2_2.4.9-1_all.deb
 31eedf762c03d54cca7ac5c6c0bff531 139824 contrib/python optional 
python3-chargebee2_2.4.9-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJavtWVAAoJEHjX3vua1ZrxwT4P/il0C+SfMXC0ANKgtjhZBsy5
UMas/bz07QzC5AQvicofTt4btmbkcsg64oe1buWxgT+TfawRqjPyWzvxsZC3vRdq
crSAuf0FsdRWOxzyRVavj9Qj00AuoNYCpvzFmF6OeiZgec2wUhousMfoX+47gZni
OW2kfL1u2NbS7fcpLIrBGVxCnV5Yo31676avhse0dqXAd9O/0dOk+hqF4uBaWwAS
c0bjIj7jVHtgEJOseZUMHeg+faa23j0vfLEhrO1Z1FNITq//N23yCgepQtqxWPte
ObR/yig0ldtEpp0DAmRo5Xxz30UxWJBa3m4vVL/w5F1y+N5+GAqQKxZ2FStuFwP9
O2MZHXJ3wkv0CPC26joA6jOZTPiCnItg6zxbS0g4WMpkj26vQNGWL3KFujxitQdX
exMhWkFqt4gxRKxC+rt14RYfGw9tKK2lRrxlUaHieUH6Xp0dJko3fjmbMrlz2ZqG
jbHLen1lXZ2ge7cUlRu2d9+EeNTRxpXYfo5/Bj6iXMXbvu9fxsF9ZeyWLSJVFCmh
3eq4jwqwbHdNRpYCxK/8wpZ/31P69ffS1y+7xJclEBw42eYC+XjP6PzRpIWnR/8b
gAzn0qNKWaXOn9x3vkR30aYtK3GOOwzWIoegaf7Y91ZlbAeCwfBzupqOzH2kJUAf
+KAuaVDO9COOsi+/eXaw
=10FT
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted chargebee2-python 2.4.8-1 (source all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 22 Mar 2018 08:16:52 -0400
Source: chargebee2-python
Binary: python-chargebee2 python3-chargebee2
Architecture: source all
Version: 2.4.8-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-chargebee2 - Python library for integrating with Chargebee (Python 
2/API v2)
 python3-chargebee2 - Python library for integrating with Chargebee (Python 
3/API v2)
Changes:
 chargebee2-python (2.4.8-1) unstable; urgency=medium
 .
   * New upstream release
Checksums-Sha1:
 8fdb32157ea90733dbaf5cfc92a777469151a928 2188 chargebee2-python_2.4.8-1.dsc
 6c0ad7d494240a0affb25b4af7d0e042853756fa 148379 
chargebee2-python_2.4.8.orig.tar.gz
 b73fb6c17070a555eccf3c9b61a4edc44a7a9a0b 3160 
chargebee2-python_2.4.8-1.debian.tar.xz
 7a41c3063b22612acb562d08bfa34c9a3a919334 6121 
chargebee2-python_2.4.8-1_amd64.buildinfo
 f28e327ee67b6ab29a3337358d6675f07597caa3 139408 
python-chargebee2_2.4.8-1_all.deb
 322a7b9fffe1cc3f715bc0d1e16f1975b86fe776 139484 
python3-chargebee2_2.4.8-1_all.deb
Checksums-Sha256:
 4e2b0ee87c9058a4e8612c40181b637e5cc28582b95fbbcb836ed03a3b717ad9 2188 
chargebee2-python_2.4.8-1.dsc
 5df9df99768824ed46a38a997102990b0d38bca41dc04f5c10197280471d0803 148379 
chargebee2-python_2.4.8.orig.tar.gz
 0cf2dd4779ebf82d9f8aa285430b5f09f4fbbba871f6b4c5ecca4cb125f8b7cf 3160 
chargebee2-python_2.4.8-1.debian.tar.xz
 6fd70ad37500919bf00accab96f5af7a21961bc71352c03243b564ef5f02e5cb 6121 
chargebee2-python_2.4.8-1_amd64.buildinfo
 9010ea21ffaa6e297c1f24e42493fcb201fe984bcacede0c4b9657f9916dbfc8 139408 
python-chargebee2_2.4.8-1_all.deb
 3380e979a1eecd2698efc56fb8dd826d5b34bccc6f62d1ae582b6b8df8b277f6 139484 
python3-chargebee2_2.4.8-1_all.deb
Files:
 d3a5a6f9323f8844b1a238b743d2c432 2188 contrib/python optional 
chargebee2-python_2.4.8-1.dsc
 0b9b2fe0c3aaea8701ad23f1d9f23394 148379 contrib/python optional 
chargebee2-python_2.4.8.orig.tar.gz
 ccae5fcac1b078b2d8232714c91f88fa 3160 contrib/python optional 
chargebee2-python_2.4.8-1.debian.tar.xz
 e54afc035daeeea205ec77f1f56f82ff 6121 contrib/python optional 
chargebee2-python_2.4.8-1_amd64.buildinfo
 4ca07c3281a687499e138835ebb8f4c5 139408 contrib/python optional 
python-chargebee2_2.4.8-1_all.deb
 d3bde8ecbbbded76d15bd5d5335799d7 139484 contrib/python optional 
python3-chargebee2_2.4.8-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJas6AOAAoJEHjX3vua1Zrxsu8P/jbO6SJCeoJAf2QmpaW1X/O4
vRtz20oaLQBymBVWTOqUW22f7B/U0pOTlwHkmtf8g4WZNX1uywTZB+VuOAeL1Nqu
rYl8hjC75WF2+WJuiiNqQw3sb9Xo3aF9WUM02wwla5FU51tnsmjkRTNBfDcrSzca
TTfSfD8h6SEgt2VkYz3A8E9j5/dLKFCRJAq5LQTf1cxUE/lXl1CQOtAyxOkNOn0B
OufL0zJnfmRjvvoDCoKK7L87zEVwUBvz9Fz9T0eH6W1OimZKuuUPuz+q/KBr9ybF
XnXDNkrSOkmqkdkyGEQ9H4+LPuA0cHF6B9Bzkr0JEBJdnUGrCiKokswj1hbmrt59
7d93UPIqthn+7jJU4obNWdh4uHlGquUdxK42mujOUNYVht7UtfBafON1zseU9V6W
HfpL2vDBaaX1wI53dC2scnXh9j63wU0r4aMePb7qD8KcR9kTttJdrrODN4eXnr8r
l7CqDHVpMsvHd0BDTvIu7CCz0SU7uPQ7nSNJOsoS+h06KNSFNFkVWSSTigYVjY+L
bgQTJbRFOJtbvYdSCqRd3xWjGYs775vqALwwOEljVCLGMidmJpvcMXDHV2aZwwd/
xjwNBOziBqU9MKVKLOuOQqFewg+TkGIfWu5GytcjZ8O0EAltmUSa3eZVBCbVda0n
7HIk3h2x/nsYy/3AuXEr
=JTm7
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted python-nacl 1.2.1-3 (source amd64 all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 13 Mar 2018 18:31:45 -0400
Source: python-nacl
Binary: python-nacl python3-nacl python-nacl-doc
Architecture: source amd64 all
Version: 1.2.1-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-nacl - Python bindings to libsodium (Python 2)
 python-nacl-doc - Python bindings to libsodium (documentation)
 python3-nacl - Python bindings to libsodium (Python 3)
Changes:
 python-nacl (1.2.1-3) unstable; urgency=medium
 .
   * Update to also set timeout=hypothesis.unlimited to further improve the
 odds of test success on slow architectures (this is the planned default
 for Hypothesis, so it is forwawrd compatible)
Checksums-Sha1:
 3594e3a140b854ea9b7849506d22202a333a742e 2451 python-nacl_1.2.1-3.dsc
 f215bfb1d4146374992789f997b12aa4d111eafa 40456 
python-nacl_1.2.1-3.debian.tar.xz
 c3b14eaa3e43ee16c9ff2dd1fda68eb04fe8a94e 51420 
python-nacl-dbgsym_1.2.1-3_amd64.deb
 77adf50d3279485bbf8cfb394dc5a3521384f47d 158020 python-nacl-doc_1.2.1-3_all.deb
 362aabffc02bea28e1b9cefc638fb92a442877c5 8813 
python-nacl_1.2.1-3_amd64.buildinfo
 7a3564ec7d8c5ed94983e5e27ba7a3ca18174b22 36780 python-nacl_1.2.1-3_amd64.deb
 0fb3cb7448b72b0ae32a5dee035e54f4e20c3fbb 47412 
python3-nacl-dbgsym_1.2.1-3_amd64.deb
 a076f75e6931c2dd2a92eabe39d6993cf858f856 36948 python3-nacl_1.2.1-3_amd64.deb
Checksums-Sha256:
 69a824285c58a52cef7aa83b49ee832b7cef2773cfc22085b803981802b73ade 2451 
python-nacl_1.2.1-3.dsc
 5647820e0dc40776139991cf501de08077ade8f8f0cf1031eef462c8130a3aa9 40456 
python-nacl_1.2.1-3.debian.tar.xz
 27dc56c9a7d843b86d67d0cdc74245e621a72e32baafa7063e29e191c997fbe1 51420 
python-nacl-dbgsym_1.2.1-3_amd64.deb
 d42a277550d1bd4452e0f03f84434036ed3930200b38449759229d6e1ab6c8fd 158020 
python-nacl-doc_1.2.1-3_all.deb
 399a8a7fb9a8d75d68bb7f5859f00d3185978c49c6066acd3f7b1cb2e4be23bd 8813 
python-nacl_1.2.1-3_amd64.buildinfo
 9ab07f970f160e4536ffc9ba8d2601ab18d241a279b838990b39eba8d8a6d42a 36780 
python-nacl_1.2.1-3_amd64.deb
 9b1c2806a8f3e74a435f49ca31cc660256a54cb068033e5154e3e45f761bb4e7 47412 
python3-nacl-dbgsym_1.2.1-3_amd64.deb
 9ee2a23efdda487cf10b6157ec04d74023095301d7e72ec9924b480a606cde83 36948 
python3-nacl_1.2.1-3_amd64.deb
Files:
 6b30bc22f6cef3da1994001360642df2 2451 python optional python-nacl_1.2.1-3.dsc
 3a60d7b17a4f20edb1388e20d3b579e5 40456 python optional 
python-nacl_1.2.1-3.debian.tar.xz
 e18cab183bcce7e026dec633c16fe8c7 51420 debug optional 
python-nacl-dbgsym_1.2.1-3_amd64.deb
 fcea754baa258e9b00860b6faba83af6 158020 doc optional 
python-nacl-doc_1.2.1-3_all.deb
 0a6fab2f64d3c631810ccf4cc2656ec9 8813 python optional 
python-nacl_1.2.1-3_amd64.buildinfo
 363c74134415b1b09597e5abe167b072 36780 python optional 
python-nacl_1.2.1-3_amd64.deb
 8b5db1843ea9bb08a81b54025b7de158 47412 debug optional 
python3-nacl-dbgsym_1.2.1-3_amd64.deb
 b4697fb0f6cb32117513154fc17ea6c8 36948 python optional 
python3-nacl_1.2.1-3_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJaqFbYAAoJEHjX3vua1Zrxm5wQAM3bGG4B9o5vHBW4ReTRECtl
RSvrJLlIZgyUMpk6+LXXGPjYE+rqLqWD73CktDjsPUQ7lORJXrP9qA9AtNk92079
J14CHl8Hd+Eevgcr4YFUXiFopX4V1EX8Y5bAA4QH9x+n7bYD9y1gpboLGrAmmNFD
onwXWHXSGBOlJ03lynRlzo6++vIE9zX6oCXu0gbvZnjURZkjEZl+coDiUCjOiXaF
GOCNsu1P9QRRJMJf9L1Sam/GpgwzZftIVfMNbjzbAuvQXo+BxJ/wdSCprJof5HDT
7fHu1l7AFGW13crHFyp67+plktoImoUvpVzYgeKQvxpz/JSUUu2wkMSef6y+tC3i
JlgMH+5e6Yx485vJdUfiAxyGShkgkfuq4lJv+1t7nMQDs40JP3DDmmOhJI5cSJKa
RPreGgL8Cob2SiOi9BX08kznXYkzu0h+eVTUS120fbfi98968gwsMD9hM0n9lQnY
Ww5WHQkl5L2l6zWnl8sQ8ZK5HJ4McfaIVdMSXd0ovk1PIf5EGS2hUVETlMBbNEgy
8P3olNL2NuZGH7hYK77cn1knX7bYXU6tL373H+SwQeO5d0KDIWOzBTu6k0Hlk3Z2
5+50Ghqkorjc23+HYG1oGJuN9YCFT9grj7ZgSMnPNF019pCK0MFXfhhLI+JmLt3H
Ypp6hSsUP0+6Va7Cs4+5
=OhCl
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted python-nacl 1.2.1-2 (source amd64 all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 12 Mar 2018 22:38:19 -0400
Source: python-nacl
Binary: python-nacl python3-nacl python-nacl-doc
Architecture: source amd64 all
Version: 1.2.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-nacl - Python bindings to libsodium (Python 2)
 python-nacl-doc - Python bindings to libsodium (documentation)
 python3-nacl - Python bindings to libsodium (Python 3)
Changes:
 python-nacl (1.2.1-2) unstable; urgency=medium
 .
   * Add debian/patches/0001-bump-hypothesis-timeouts-for-slow-archs.patch to
 add time for tests to complete on slower architectures
Checksums-Sha1:
 fcf2dec0904c0f63d19bf93b41a06706ea9746ea 2451 python-nacl_1.2.1-2.dsc
 add7bcc8b004a7bd7c3b736ab8e8943941e63a8b 40236 
python-nacl_1.2.1-2.debian.tar.xz
 fd6ed58ebf0832caf0bfb78e19bccde00d2149dc 51428 
python-nacl-dbgsym_1.2.1-2_amd64.deb
 cc71fe4793dffce03af7a7fb764006d67a99d124 157936 python-nacl-doc_1.2.1-2_all.deb
 969f36a12f7beb941bda848d2f38a6fea28fe44a 8813 
python-nacl_1.2.1-2_amd64.buildinfo
 e666e7b8d39ac3f2a544dba401287eb8fee93ab0 36656 python-nacl_1.2.1-2_amd64.deb
 7f946aeaec9265d45636221601a8794d68253056 47400 
python3-nacl-dbgsym_1.2.1-2_amd64.deb
 218308e6e4fdbbde6edfcc2099ab5f5a45dac65a 36800 python3-nacl_1.2.1-2_amd64.deb
Checksums-Sha256:
 f112698cf0ed0eeae468265900ad38d480006d33cc74ab3990f2cc9340ffe239 2451 
python-nacl_1.2.1-2.dsc
 f38c60ab3bae2fa1f537c1e70933341ed45fc2239c6f5656af9140c1150ea952 40236 
python-nacl_1.2.1-2.debian.tar.xz
 d6fed99507039f9ef287839333163e627a0acf7416828be30b165a96ce462833 51428 
python-nacl-dbgsym_1.2.1-2_amd64.deb
 008b5aa6d7be95b9dd346da351647e351e9e2da8cde03f41e8b51486463f3eac 157936 
python-nacl-doc_1.2.1-2_all.deb
 5c250fb139329b8ab06e58ef9815894db52c25125293f915f900b1179d8f7a49 8813 
python-nacl_1.2.1-2_amd64.buildinfo
 83c1ecd1d2a624bee838783fcb6704840a1be05b3e8d677c3dde57bb2c47f7df 36656 
python-nacl_1.2.1-2_amd64.deb
 271185a73ced6f46230c19900a92e0a3a901f3f90e132a7b6faef1f90aeec6b6 47400 
python3-nacl-dbgsym_1.2.1-2_amd64.deb
 51285516b9ee8e3a3b8bcfbd1efa6ef54223caea5ef8ac2801e54b153cc95389 36800 
python3-nacl_1.2.1-2_amd64.deb
Files:
 ecc4b1571c6f7037268470d56c017a98 2451 python optional python-nacl_1.2.1-2.dsc
 a899c0b20b9685ee6068e7ebce3d206f 40236 python optional 
python-nacl_1.2.1-2.debian.tar.xz
 cf2b5ace974ace5d4f8147b2a5fc32c5 51428 debug optional 
python-nacl-dbgsym_1.2.1-2_amd64.deb
 beb39837f30930f5275399bb3bfd4ede 157936 doc optional 
python-nacl-doc_1.2.1-2_all.deb
 9770dbfc39706095b4cfd0fd27c3169b 8813 python optional 
python-nacl_1.2.1-2_amd64.buildinfo
 139c84238d0eecb1b0c7f5a2ebf8aef3 36656 python optional 
python-nacl_1.2.1-2_amd64.deb
 91afe545d487ddca4cb323e12ed7166d 47400 debug optional 
python3-nacl-dbgsym_1.2.1-2_amd64.deb
 6e829a60e51c1bdc710bf10e905fa1a4 36800 python optional 
python3-nacl_1.2.1-2_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJapzvuAAoJEHjX3vua1Zrx6zcP+QH/TjLzGHH349fxfynBoRFV
3eqa7N2Rdenom0XVwcl6tWlTuWwOKOQ5zgNSSwqy91739ZXMPQ6zLCsNdXMWyDxp
R7lKZQVbnGT4horvk/ynuHHRsqZp6yD/KVLdOnsblLVFvD1wR6+EMbo0nZnpxtY0
Vz4jUGY1AeSgcL7kDFq2CNEo6gEGc/4Q5PiqKpK8xj5W/bho/LwlwhdaNJMkuozA
KvIuzduKtVP1KBJnkspV5GIVnvRav2ccQsyjI/sYAczzx5vHuD4fPihRp6buSOg5
9RMbXuBWk50i7fgDYcIAWQWJQXqhvIrp4qJAhXzsS+oiyn3gVtJPiyobRdqisqtI
5r5WERqayFPDv1Fykz1LJnmXFUgaSkL7ekP25gZTbmzB9tYm9RHyYh90jW2lqBOh
eRhIEDPrC0vkobFaW4xJDNLOpHdbqYovtOhpKoFeAPDHNJKUs+LYYx8HtrZ9YKu+
+HZY+kEzdNkpXjx4wKAd2ZG7eqeylWLq/wZ+o+SiVhutIvQuUTbikKOSRFUu0bR2
zrhg3mHQQeagUTQsFsH7LgiBl1Pfz//tVGdmDyGUSuZ9Qp7Q62KwnRqv89m2lxzm
Sh1SxVqLUnRIjZOyY+UW98CpqO20kkhSWz5ECM261m8HaSMcko77njACfK47Y8Zr
kj2T9+FilIXCLH7a9W09
=+XFS
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted python-nacl 1.2.1-1 (source amd64 all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 12 Mar 2018 08:37:37 -0400
Source: python-nacl
Binary: python-nacl python3-nacl python-nacl-doc
Architecture: source amd64 all
Version: 1.2.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-nacl - Python bindings to libsodium (Python 2)
 python-nacl-doc - Python bindings to libsodium (documentation)
 python3-nacl - Python bindings to libsodium (Python 3)
Closes: 892637
Changes:
 python-nacl (1.2.1-1) unstable; urgency=medium
 .
   [ Colin Watson ]
   * Move VCS to salsa.debian.org.
 .
   [ Ondřej Nový ]
   * d/copyright: Use https protocol in Format field
   * d/watch: Use https protocol
 .
   [ Scott Kitterman ]
   * Convert from git-dpm to patches unapplied format
   * Add myself to Uploaders
   * New upstream release (Closes: #892637)
 - Add python-hypothesis/python3-hypothesis to build-depends for tests
 - Update debian/rules so .hypothesis files are left scattered about the
   binaries
 - Update debian/copyright
   * Bump standards-version to 4.1.3 without further change
   * Add libjs-sphinxdoc to python-nacl-doc Depends
Checksums-Sha1:
 a0b8274e6642d6849067c6a220358586a422a4e8 2451 python-nacl_1.2.1-1.dsc
 628edaf52c31928528082ca7463c205024515ba4 3256719 python-nacl_1.2.1.orig.tar.gz
 94bb30e352cd3407673531ce3ea221dd53603b96 39676 
python-nacl_1.2.1-1.debian.tar.xz
 6f88642542f77ac704da7b23e1944bc81e20590c 51456 
python-nacl-dbgsym_1.2.1-1_amd64.deb
 bae1d28158d7c273035647b1aa04111766722d42 157844 python-nacl-doc_1.2.1-1_all.deb
 e9d40bb4d3691c2d7ff424c775b797f84118cc98 8813 
python-nacl_1.2.1-1_amd64.buildinfo
 b7a26df3d24ddc2e38396392b224a661b87e8fec 36556 python-nacl_1.2.1-1_amd64.deb
 939dc1a12996c451948c6b5a9ce25134480ced75 47408 
python3-nacl-dbgsym_1.2.1-1_amd64.deb
 811d72b7fbd0345e85df90e412e4bd5951063dd4 36756 python3-nacl_1.2.1-1_amd64.deb
Checksums-Sha256:
 187f7b4c73d78692e53931d5b661ed4bcd781c8da1022df3798b7dcc1df92395 2451 
python-nacl_1.2.1-1.dsc
 e0d38fa0a75f65f556fb912f2c6790d1fa29b7dd27a1d9cc5591b281321eaaa9 3256719 
python-nacl_1.2.1.orig.tar.gz
 70902b44d22a6dbb91901071a5997715899de04099357bbb6343b9e1ae26757d 39676 
python-nacl_1.2.1-1.debian.tar.xz
 0cb51fa938fdb2626fa5227cdf53a85d8890ca83bbb229447c410bde98d5b86c 51456 
python-nacl-dbgsym_1.2.1-1_amd64.deb
 df9e520ff30b54b6405b26cd5a147ed2cfc9423c04ff62688a23bc59d14eff48 157844 
python-nacl-doc_1.2.1-1_all.deb
 4d391bb87c47860fa1bd5d3b403dc5d59c8ef7648c921b603156566382d0902b 8813 
python-nacl_1.2.1-1_amd64.buildinfo
 d8105f16355a75b2ed90e0348112d9eb68cfcfe88c5f4b802a6dc577199080a2 36556 
python-nacl_1.2.1-1_amd64.deb
 70a8f833bbd23e4c303f70a6732ae4692e1f69456dfca4d81139c9fa2b838cb0 47408 
python3-nacl-dbgsym_1.2.1-1_amd64.deb
 b57f0e9ce2e183557c8b7a2e67445b2e0113b6b91610f279df1654f6d58c26f3 36756 
python3-nacl_1.2.1-1_amd64.deb
Files:
 7cc8efe6e6088aeed1f01431d845ac1c 2451 python optional python-nacl_1.2.1-1.dsc
 1db3e111775fbe6b66772ff30af7a956 3256719 python optional 
python-nacl_1.2.1.orig.tar.gz
 a460ba43349a86cde2ad5a9558f1d8d4 39676 python optional 
python-nacl_1.2.1-1.debian.tar.xz
 c3d90572e94835c570dfc27a0ca97eac 51456 debug optional 
python-nacl-dbgsym_1.2.1-1_amd64.deb
 b096b48ef0bdba74ac087b7d45953217 157844 doc optional 
python-nacl-doc_1.2.1-1_all.deb
 c860e7c40a777cfe042356bc0cbe3bf8 8813 python optional 
python-nacl_1.2.1-1_amd64.buildinfo
 c22bbe673d70db8c06bb70f22197caa2 36556 python optional 
python-nacl_1.2.1-1_amd64.deb
 8a253c78486ab420791d9031025c5736 47408 debug optional 
python3-nacl-dbgsym_1.2.1-1_amd64.deb
 00b3b9e35bb04fa63e9aae883323d37c 36756 python optional 
python3-nacl_1.2.1-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJapnrlAAoJEHjX3vua1ZrxEZ4P/3lr9jMPFIV3pCiQAPOOMNUJ
PSXZEGC8+Vr2o9V2WGsw05igluAWMjkk+nfEpwTfm2Y7y5CoQoRALV1plyXWLV0C
uI0KjlwyshzWEEgWncGgyayjVkiYoQRLDDwMfykJQ8o3wjZ3GgoqoTC8WUl6Jx7i
rm5K9BW3k0pQXfSdigvtqCshXVmNzx36u+fTnekWzLkDK38hvwVL1END/vhiyWtY
C06MGn9FNtJ1m2Prmdp2JIExWQTSXM7tca7JXQAbw4Jk4/T/RE+11CgDax7PTOXY
daYZ6qm5+C2Z53oidtsI8DnP1ec7dMCs4crxAknRQyuLWD/jVPqH7nUM1krS2k/S
ETQqrJv+YN+CMO8infRMULcKSil9yWsjyM9pUAfPYEfbVeYGF+sTt7/H4QgaFHTV
b/0qJhYG/lg1WpYWGLFSMjWC8/X2VRFtApzjwh/L0iQR75FYR2zTgUh2ZbTPfS8r
YOmInHarSvu7rPfrFzrLtmAEoq8DSSE9UR+2+PCOJKT3RXoGdsxtfeu2AlNWZFCz
Sy1KQEzidSiuow0iJweh7VqBcdhISRua7G7tzT3smMHJ7BWZM1GZMK8tyezaUOMg
ChTvJ0g9R65d6uK/3yEt5qGzDIyEOf59ngcKHFef3v9MUT9SN69FyFxqojcoonrz
GMipU1JwaHAJiDmX1h17
=wsBe
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted django-anymail 2.0-1 (source all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 11 Mar 2018 03:42:20 -0400
Source: django-anymail
Binary: python-django-anymail python3-django-anymail
Architecture: source all
Version: 2.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-django-anymail - Django email backend for multiple ESPs (Python 2)
 python3-django-anymail - Django email backend for multiple ESPs (Python 3)
Changes:
 django-anymail (2.0-1) unstable; urgency=medium
 .
   * New upstream release
 - Updated package descriptions in debian/control to mention addition of
   SendinBlue support
 - Add debian/NEWS to report breaking change, WEBHOOK_AUTHORIZATION renamed
   to WEBHOOK_SECRET
Checksums-Sha1:
 ff92f0d48288edef1e218ebb446d925b40ae88c5 2159 django-anymail_2.0-1.dsc
 84edd0b6125d4238d0d0750384869726f70e6841 64576 django-anymail_2.0.orig.tar.gz
 e48352c7e902382a02275d23cb3a0f20f258cdf1 4180 
django-anymail_2.0-1.debian.tar.xz
 ebf80c6b88c916c9194e8d864be9d12d3d1b7bc9 6059 
django-anymail_2.0-1_amd64.buildinfo
 37fe69bfa89f930ef53d7a8aae29fa7ace82cf5b 57804 
python-django-anymail_2.0-1_all.deb
 852567fb1b4537dc494f46d4bb42fa563a06d1b4 57876 
python3-django-anymail_2.0-1_all.deb
Checksums-Sha256:
 5159780a14b8e836563753cfbd4a093e8cd1c778619ce38236114204cb81dfe5 2159 
django-anymail_2.0-1.dsc
 bbcf597c6dcdca59b2393f20754b90b5601ac27f3a7157e17ac73e9e8da2d226 64576 
django-anymail_2.0.orig.tar.gz
 448b821471523aa2f7c01a250585f7f6191ebe9931de0ba8a050bddb0123add7 4180 
django-anymail_2.0-1.debian.tar.xz
 4cb19c2f02aff65f486275b44e349706bce58066be29534c07660959f6d79416 6059 
django-anymail_2.0-1_amd64.buildinfo
 378aadf3fa5c424f1d2b0277ad49f695c9bdad680cd1bccf0115d0cb46b5c489 57804 
python-django-anymail_2.0-1_all.deb
 6dbf6931663e8626e9a643fdafdf5f752a61ef6d031a55798d44e7a90360a523 57876 
python3-django-anymail_2.0-1_all.deb
Files:
 4fa0a383bd55e0e7fbba16e683a52828 2159 contrib/python optional 
django-anymail_2.0-1.dsc
 cd4f45afdc40defc047ea96cf293c5c8 64576 contrib/python optional 
django-anymail_2.0.orig.tar.gz
 0016e82bba483f9bc19c767293bc593e 4180 contrib/python optional 
django-anymail_2.0-1.debian.tar.xz
 b71fe50122e1b557ea7f0607a486ff7c 6059 contrib/python optional 
django-anymail_2.0-1_amd64.buildinfo
 add1946a20eea15a52701a7e76249c75 57804 contrib/python optional 
python-django-anymail_2.0-1_all.deb
 774a94fad184fae488235d31b982fc11 57876 contrib/python optional 
python3-django-anymail_2.0-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJapOa3AAoJEHjX3vua1ZrxmTcQAITnh7la3BO57139GRxfBCIE
hkCAXiejmsyUnucUWtzBAcUNuCkBknc7BWAYCpZtXk86Why6/fEo8+kda2scU7rC
ERW6w9dqp0sWxd07qkiReHfcWr0XJ4wYrUrD6W5EEyTa1TLmemT53yYXCc6tRyiL
lsf0CpbQ87KbYfF+Z7i2GTvNzvO+uEFBOgZDtj0j6NjAKqzSDffU3Q0WJHHCSMYJ
pvHL81bQQema+L+RpnEkX0DAVQRCivNDlRzo8DgfHtzgHq3muJ5lQvpG+uxA51kf
U5MRGtj0mddW13n9DWzdhoFJ4mkvNTa15ggRLTpGQBsuMLpBT5RWvVWWeAouJ+Wk
JDecpjlAELJtoINITZMIEDYikIWWH+M+M+h9dGcZZOktu0oJ/sVSLmaofx/2Jm5Y
TvrTiGapmfT4dCxcdZqGrvFeKzl+OdP+Gpmt/2if71avJhcsY73UG3+LhUkOuNFT
cV+JkYFg3DNCS4PA9xozO40RU4L6PEmU13K9HuSoUB1GXOvzmrwcOYT6nwix6bZC
gWYRwMovSQ6FkUzVTfaGA9s24PePC94U1lcAlEK9TjnopCNOXXXvgivzJXWSvu9X
34bIhgUxfMw3xEWVArLMSvMllzoYiB3X177YABZTzfdF8Cz5tV5d9XTgaz3CcJX6
X48NRvbiIBT6yhNMoFtg
=tZsL
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted python-bleach 2.1.3-1 (source all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 07 Mar 2018 14:07:14 -0500
Source: python-bleach
Binary: python-bleach python3-bleach python-bleach-doc
Architecture: source all
Version: 2.1.3-1
Distribution: unstable
Urgency: high
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-bleach - whitelist-based HTML-sanitizing library (Python 2)
 python-bleach-doc - whitelist-based HTML-sanitizing library (common 
documentation)
 python3-bleach - whitelist-based HTML-sanitizing library (Python 3)
Closes: 892252
Changes:
 python-bleach (2.1.3-1) unstable; urgency=high
 .
   [ Ondřej Nový ]
   * d/control: Set Vcs-* to salsa.debian.org
   * d/copyright: Use https protocol in Format field
 .
   [ Scott Kitterman ]
   * New upstream release (Closes: #892252)
Checksums-Sha1:
 1a60f9aa866bc1ef83406077036df428639bc18d 2624 python-bleach_2.1.3-1.dsc
 978e10156c57eb556f9b4c3cd5b1c213e9c41e2c 50496 python-bleach_2.1.3.orig.tar.gz
 747c726323e8cf60276980fb0e496954560311ff 3232 
python-bleach_2.1.3-1.debian.tar.xz
 1fe59e78338bdf5df9c6673cf732b25ec2b4c8a1 56192 
python-bleach-doc_2.1.3-1_all.deb
 bae2c40a0e49ba60b2e1ea7192b7aebd695e6134 22096 python-bleach_2.1.3-1_all.deb
 fecece504f502cae07ff1617129e624904947e13 7920 
python-bleach_2.1.3-1_amd64.buildinfo
 792c79628b4fb102d10faeb963c7a2a7c270207d 22196 python3-bleach_2.1.3-1_all.deb
Checksums-Sha256:
 cd13b632d25f656bf7dc24cc043de88d9af255d00a1c31c3216d08ef3993fd79 2624 
python-bleach_2.1.3-1.dsc
 2efa88ba7a17032436f1e1d337601a6b6551ed734da21a39a53f5bee543ea2de 50496 
python-bleach_2.1.3.orig.tar.gz
 1fec610cffa64f6fbf680696d8a0a4b200847f552efc6b2d6262f6e2355474e3 3232 
python-bleach_2.1.3-1.debian.tar.xz
 911abce1576cbb06899e3c175ad1c7a1b4bf455e14b3ba83355cf061be6a5e8a 56192 
python-bleach-doc_2.1.3-1_all.deb
 fc7163758c3480333fd4dbd6d849e02c149c497c2605e643a1c71bfb4fc95fc8 22096 
python-bleach_2.1.3-1_all.deb
 8e054d9218a0624dd1001ee86229f1005116ab6640786c829d6498752c7cad21 7920 
python-bleach_2.1.3-1_amd64.buildinfo
 8e8f5e77108655d1b511687f50e589519a89943f81cd93cdea58fee3586bd90f 22196 
python3-bleach_2.1.3-1_all.deb
Files:
 28af1f79c63f7bb399080e9453bb90cd 2624 python optional python-bleach_2.1.3-1.dsc
 16c3466551d3a5a369a563b5bca5ee44 50496 python optional 
python-bleach_2.1.3.orig.tar.gz
 abfb339412e9249a77b1fefb0c8e5ca2 3232 python optional 
python-bleach_2.1.3-1.debian.tar.xz
 d9383de580c49571bd56f5b57947e3a8 56192 doc optional 
python-bleach-doc_2.1.3-1_all.deb
 c4aba956290324467429200ee30c250b 22096 python optional 
python-bleach_2.1.3-1_all.deb
 676a843856bd9ca91a3a0b369385b98a 7920 python optional 
python-bleach_2.1.3-1_amd64.buildinfo
 381103e844afc32ddaada6310ec0c1cf 22196 python optional 
python3-bleach_2.1.3-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJaoDssAAoJEHjX3vua1ZrxkvQQAKsVwPIsLwlsyysQgOosqwEi
SLaYLC7TqJeDqf2hA61pHB4ys1gFmFQm2hprePMDFJBPcOdzfFaODKzzc3n71IRm
3my6QQSOAM/GPBDZ+O0nBfDkJQBobXNgcr/tf+xkBF7alQSMTs6Zk/syokJtplQq
QiWU3LoPa3mmR/CHU0rW9odUSycu/ROPCNAXzPDSpJ+dvxxgE/RfSEx7BithP2N7
/gkJQ8zzCv2O3SGXtBgj4agRnvfgLS1Q/bjVj8JUujknCB10+2sSouWLFRjcDlZ2
I2IGCciieGnL2rFT7Q4FEX8H88gnJT7l+HIqwW13BSScYw5c6WRzK7wFu2fgwBd8
5tmAhat1qfyh16nXlkrqkn1InvhXPRG2nD5HtiGFIu4+Fiqatequg3Z3PYkE9sv/
1PrfXYFoplnGZ3IHqaODsrikHMH7kppe8tXh5HG/wFMX7X2Jb92HinUlYz7ViOo9
KDrVGiGQ+2k7Brd9XqfEZujes91fgsliFQkl4iWdodagYPkZbX4mdoQS9EaHhLfA
F8DKtZvw8i7WPF0285WvtJzUEmPOm9aBGPJEOiuw6smTMueh62GMMh/r4s9wjEUN
g97RRyuqoxtQOiDIfFyvY1I45mcWpCUnYX+FaA+qMDD+JZYsc5iQNVVhKE2xKqDo
CjLGInegdh2fa/NSD2K7
=WxvH
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#892252: src:python-bleach: URI values with character entities not properly sanitized

[Scott Kitterman]

Package: src:python-bleach
Version: 2.1.2-1
Severity: important
Tags: upstream, security


Version 2.1.3 (March 5th, 2018)
---

**Security fixes**

* Attributes that have URI values weren't properly sanitized if the
  values contained character entities. Using character entities, it
  was possible to construct a URI value with a scheme that was not
  allowed that would slide through unsanitized.

  This security issue was introduced in Bleach 2.1. Anyone using
Bleach 2.1 is highly encouraged to upgrade.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#890097: src:django-anymail: New, minor WEBHOOK_AUTHORIZATION security issue

[Scott Kitterman]

On Sun, 11 Feb 2018 01:08:01 -0500 Scott Kitterman <deb...@kitterman.com> 
wrote:
> Package: src:django-anymail
> Version: 0.8-2
> Severity: important
> Tags: upstream,security
> 
> Security fix
> 
> This fixes a low severity security issue affecting Anymail v0.2–v1.3. (CVE
> Pending)
> 
> Django error reporting includes the value of your Anymail
> WEBHOOK_AUTHORIZATION setting. In a properly-configured deployment, this
> should not be cause for concern. But if you have somehow exposed your Django
> error reports (e.g., by mis-deploying with DEBUG=True or by sending error
> reports through insecure channels), anyone who gains access to those reports
> could discover your webhook shared secret. An attacker could use this to 
post
> fabricated or malicious Anymail tracking/inbound events to your app, if you
> are using those Anymail features.
> 
> The fix renames Anymail's webhook shared secret setting so that Django's 
error
> reporting mechanism will sanitize it.
> 
> If you are using Anymail's event tracking and/or inbound webhooks, you 
should
> upgrade to this release and change "WEBHOOK_AUTHORIZATION" to 
"WEBHOOK_SECRET"
> in the ANYMAIL section of your settings.py. You may also want to rotate the
> shared secret value, particularly if you have ever exposed your Django error
> reports to untrusted individuals.
> 
> If you are only using Anymail's EmailBackends for sending email and have not
> set up Anymail's webhooks, this issue does not affect you.
> 
> The old WEBHOOK_AUTHORIZATION setting is still allowed in this release, but
> will issue a system-check warning when running most Django management
> commands. It will be removed completely in a near-future release, as a
> breaking change.
> 
> Thanks to Charlie DeTar (@yourcelf) for responsibly reporting this security
> issue through private channels.
> 
> https://github.com/anymail/django-anymail/commit/1a6086f2b58478d71f89bf27eb034ed81aefe5ef
> 
> Given that the fix for this is problematic from a backward compatility
> perspective and that it requires a misconfigured django app before it is a
> problem, recommend No DSA for the security team.

This is now assigned CVE-2018-189.

https://github.com/anymail/django-anymail/releases/tag/v1.4

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Two more mass-commits

[Scott Kitterman]

On February 14, 2018 8:57:13 AM UTC, "IOhannes m zmölnig (Debian/GNU)" 
<umlae...@debian.org> wrote:
>
>
>On 2018-02-13 23:34, Scott Kitterman wrote:
>> For the second one, it's usually a little more complicated.  If the
>source priority is Optional, don't repeat it in the binary stanza by
>changing Extra to Optional.  In that case the binary stanza should be
>removed 
>> 
>
>out of interest: does having a duplicate Priority section (one in
>source, one in the binary stanza; both with the same value) cause any
>actual problem or do you fear cruft accumulation?

IIRC, lintian will whine at you over it.  Lintian is whiny enough without 
providing encouragement.

Mostly cruft accumulation.  If we're going to do a mass operation on this many 
packages, let's do it correctly.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Two more mass-commits

[Scott Kitterman]

For the second one, it's usually a little more complicated.  If the source 
priority is Optional, don't repeat it in the binary stanza by changing Extra to 
Optional.  In that case the binary stanza should be removed 

Scott K

On February 13, 2018 3:13:35 PM UTC, Ondrej Novy  wrote:
>Hi,
>
>I would like to do two more mass-commits in DPMT:
>
>https://salsa.debian.org/python-team/modules/uvloop/commit/2e86105ed89b1081ed0ae506cffc6f7d47fd7a45
>https://salsa.debian.org/python-team/modules/uvloop/commit/94ffa9b43eed60ff446266064d47d33c1d1d1eed
>
>Any thoughts?

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#890200: PyQt5 package should provide an egg-info

[Scott Kitterman]

On Sunday, February 11, 2018 09:19:59 PM VA wrote:
> Package: python-pyqt5
> Version: 5.9.2+dfsg-1
> 
> Many Debian python packages include an egg-info folder, but python-pyqt5
> does not.

The PyQt5 upstream does not use standard Python tools for building the 
package.  As shipped by upstream, a source build of PyQt5:

python3 configure.py
make
sudo make install

does not install any egg information.  Only the upstream wheels provide 
anything.  They provide a PyQt5-5.10.dist-info directory which appears to 
perform a similar function.

This is probably not feasible in Debian as we split PyQt5 into a number of 
sub-packages to minimize the dependencies that get pulled in for various 
applications.  I'm not sure how to manage the egg-info for such a case.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted django-anymail 1.4-1 (source all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 11 Feb 2018 01:21:39 -0500
Source: django-anymail
Binary: python-django-anymail python3-django-anymail
Architecture: source all
Version: 1.4-1
Distribution: unstable
Urgency: high
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-django-anymail - Django email backend for multiple ESPs (Python 2)
 python3-django-anymail - Django email backend for multiple ESPs (Python 3)
Closes: 890097
Changes:
 django-anymail (1.4-1) unstable; urgency=high
 .
   * New upstream release (Closes: #890097)
 - Fixes new WEBHOOK_AUTHORIZATION secret security issue (CVE pending)
   * Update Vcs-* for move to salsa.d.o
   * Bump standards-version to 4.1.3 without further change
   * Added missing disclaimer on why django-anymail is in contrib
Checksums-Sha1:
 732e22efd45f27376303fefcb291c15df3cb1f2f 2159 django-anymail_1.4-1.dsc
 e9e91f00eb0744f83eb9e0a2a61d94d4bd7706e9 57218 django-anymail_1.4.orig.tar.gz
 10632bf14e6394c266f10aedaf2e3559cdde5dfd 3472 
django-anymail_1.4-1.debian.tar.xz
 d3b75c3f34ce8254023652b8de96b7d162b4fc68 6083 
django-anymail_1.4-1_amd64.buildinfo
 f91b66bbae2771031eb160429c15621970825acf 54368 
python-django-anymail_1.4-1_all.deb
 004dec58ca5461ec3b25dc70b6529744fc7fb809 54456 
python3-django-anymail_1.4-1_all.deb
Checksums-Sha256:
 fedbcd9c4f05dfabcd9afd7e1a75930142c7dec42df846720d934f66403c9131 2159 
django-anymail_1.4-1.dsc
 f534ab2ca82b6e1155d02d656db28d17d1f4e832f641b537539a4ebbcdee7e39 57218 
django-anymail_1.4.orig.tar.gz
 6f60a7f889114fce8a76cb805a283ffb50dad375fa609175a1006ab20451a072 3472 
django-anymail_1.4-1.debian.tar.xz
 413669bb439f2107e87ce81cefa3a348d3c543088f3b30ed1a58818d76bc58c4 6083 
django-anymail_1.4-1_amd64.buildinfo
 e0fc4c7c8a310df50cebdb6854410b07d4fd928368e9a3b0f983fc7cebb97740 54368 
python-django-anymail_1.4-1_all.deb
 0b2ac97d7209d05fec57c5086fddd8343f77df245fd584ae72c3641b58523800 54456 
python3-django-anymail_1.4-1_all.deb
Files:
 609e70f7ca96eb80c5492db56582bfa5 2159 contrib/python optional 
django-anymail_1.4-1.dsc
 06e0085983448f461ac63f648a748d66 57218 contrib/python optional 
django-anymail_1.4.orig.tar.gz
 3c9e41cd277884f63966b8a6bddfdd6f 3472 contrib/python optional 
django-anymail_1.4-1.debian.tar.xz
 ef8be568a03e7a4de9ae80f1d4f49201 6083 contrib/python optional 
django-anymail_1.4-1_amd64.buildinfo
 0507c62460c62fb44df6642075fb57c4 54368 contrib/python optional 
python-django-anymail_1.4-1_all.deb
 75b43274ef1b2d845c7f1b745005fe4f 54456 contrib/python optional 
python3-django-anymail_1.4-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJaf+G8AAoJEHjX3vua1ZrxiDoP/RIirJbyaAZmQ6XxlGLZkKtt
haQJJqageoxo2M01pXuMOmk6GRIJkF10gaHb03zddAuSrelpxVUYRKVNd0RvmAH4
a0NprTp4UUX9yq26+/TjYGVFmMjSfOUPjPefDA30ECPpJRho7knIp1/VHUHaL0Ci
jmYTDODHPlNyQw2oFrR7I2rMGGCI7Xd8QQW6ljlgYulkoJdT+dARzNr6CPuzBXHl
sToYTs9fLcgBslT4nyEclhvtPAAFenDBYbAiNYemiI9UUJE+D+d8JVFGd5VxAtiC
McowPvzjpQKFRM2oNfpXjv8Pi2YNjldJbBEHkVx6rZ8LQH+kKwOtK87z0r4nAoo8
r5mKHSgwojYg8p2G5NaDaQgVV9SrqqSzJZuMgz8zwn2dbY9ntpcXaqlFNuf85D4g
cqQufLFAMLDurXTaFScde1hRYI2IO02pGqILQ1YJWd8Wpk4wnaMWX3jTQ+V4G8t3
T4skcFwSTGXoEQSXwJMgamfHQ8fiUpVtVVLf8SiARFzL7pq/dlLyRKd6E3KYUXgS
zyv6dKcLbbD+3viENwy8dszMQoBOjYd+QHJDxgyh/aSVqKaS574magVBnPmOS/bP
fr6A1TBsvtnSOyI2R2/2ppl2Y8I4CtyYD4C6NWzmp1phJ1/Zd40jBuKSUBE2TrDz
0DazbdpDjtDTtoZnazSX
=yzro
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#890097: src:django-anymail: New, minor WEBHOOK_AUTHORIZATION security issue

[Scott Kitterman]

Package: src:django-anymail
Version: 0.8-2
Severity: important
Tags: upstream,security

Security fix

This fixes a low severity security issue affecting Anymail v0.2–v1.3. (CVE
Pending)

Django error reporting includes the value of your Anymail
WEBHOOK_AUTHORIZATION setting. In a properly-configured deployment, this
should not be cause for concern. But if you have somehow exposed your Django
error reports (e.g., by mis-deploying with DEBUG=True or by sending error
reports through insecure channels), anyone who gains access to those reports
could discover your webhook shared secret. An attacker could use this to post
fabricated or malicious Anymail tracking/inbound events to your app, if you
are using those Anymail features.

The fix renames Anymail's webhook shared secret setting so that Django's error
reporting mechanism will sanitize it.

If you are using Anymail's event tracking and/or inbound webhooks, you should
upgrade to this release and change "WEBHOOK_AUTHORIZATION" to "WEBHOOK_SECRET"
in the ANYMAIL section of your settings.py. You may also want to rotate the
shared secret value, particularly if you have ever exposed your Django error
reports to untrusted individuals.

If you are only using Anymail's EmailBackends for sending email and have not
set up Anymail's webhooks, this issue does not affect you.

The old WEBHOOK_AUTHORIZATION setting is still allowed in this release, but
will issue a system-check warning when running most Django management
commands. It will be removed completely in a near-future release, as a
breaking change.

Thanks to Charlie DeTar (@yourcelf) for responsibly reporting this security
issue through private channels.

https://github.com/anymail/django-anymail/commit/1a6086f2b58478d71f89bf27eb034ed81aefe5ef

Given that the fix for this is problematic from a backward compatility
perspective and that it requires a misconfigured django app before it is a
problem, recommend No DSA for the security team.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted psycopg2 2.7.4-1 (source amd64 all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 09 Feb 2018 23:39:00 -0500
Source: psycopg2
Binary: python-psycopg2 python-psycopg2-dbg python3-psycopg2 
python3-psycopg2-dbg python-psycopg2-doc
Architecture: source amd64 all
Version: 2.7.4-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-psycopg2 - Python module for PostgreSQL
 python-psycopg2-dbg - Python module for PostgreSQL (debug extension)
 python-psycopg2-doc - Python module for PostgreSQL (documentation package)
 python3-psycopg2 - Python 3 module for PostgreSQL
 python3-psycopg2-dbg - Python 3 module for PostgreSQL (debug extension)
Closes: 880651
Changes:
 psycopg2 (2.7.4-1) unstable; urgency=medium
 .
   * New upstream release (Closes: #880651)
 - Drop d/p/0002-Make-dbapi_extension.py-compatible-with-Sphinx-1.6.patch,
   incorporated upstream
   * Drop extra priority from -dbg packages
   * Update debian/watch to use secure URI
   * Clean up trailing whitespace in d/control and d/changelog
   * Bump standards-version to 4.1.3 without further change
Checksums-Sha1:
 7958e480515c5962c49cb8382e025c56e88d8bc3 2492 psycopg2_2.7.4-1.dsc
 d030339fdde7c99f81593d8933cb712aa72ab6c2 425331 psycopg2_2.7.4.orig.tar.gz
 7c2c665d94ccabfe0a1eb7d82b4a8cc8eb225c18 14039 psycopg2_2.7.4-1.diff.gz
 44e7f27edef65c23671b9db7ed08acfbe1064855 9162 psycopg2_2.7.4-1_amd64.buildinfo
 4738500df20aa2eb979ec3fffea1be5f3a208be6 384388 
python-psycopg2-dbg_2.7.4-1_amd64.deb
 88ba2f1f59819b0aafe3adfa21f9d23c85503603 281608 
python-psycopg2-doc_2.7.4-1_all.deb
 ba8193533e73cd044230f8feb8e42f320fc43438 177016 
python-psycopg2_2.7.4-1_amd64.deb
 682554333fb588d22fd272ad50ccc616827e4c36 464840 
python3-psycopg2-dbg_2.7.4-1_amd64.deb
 420072e495907de98b7033f8754069fcce7e7a74 174020 
python3-psycopg2_2.7.4-1_amd64.deb
Checksums-Sha256:
 b739dbdc47cc00316c954e2106a0f3413e1698d4f3d8d06a92a5a9c0611e55db 2492 
psycopg2_2.7.4-1.dsc
 8bf51191d60f6987482ef0cfe8511bbf4877a5aa7f313d7b488b53189cf26209 425331 
psycopg2_2.7.4.orig.tar.gz
 af41c4a3b5b81f48913fadbe99844646b34101606be0cc0dec6f2318d9e0383c 14039 
psycopg2_2.7.4-1.diff.gz
 3681f3f25a5f81d81d625f052c4dd345b5143e8e5a7ba74fe56515929b5dfc39 9162 
psycopg2_2.7.4-1_amd64.buildinfo
 6b0421e801f7a50309eb559950ed779fb578004033032a696a88d9da5cb796e4 384388 
python-psycopg2-dbg_2.7.4-1_amd64.deb
 a98c83a18c91ca8b8b2dd782c65f1cc422d7e85520368116ff8da6b0c8869f47 281608 
python-psycopg2-doc_2.7.4-1_all.deb
 365dae5e2d5947e704ba80af8c86c7774296db27f0c9476a46f9b36b5da4cd72 177016 
python-psycopg2_2.7.4-1_amd64.deb
 f35ac2d0269d43106cf08cabd7e0217c8e1ae0c138f0b576c37ea48450fe8b7c 464840 
python3-psycopg2-dbg_2.7.4-1_amd64.deb
 36ae0886d9e70c8c508af05848296857c84e8c176008123c75a8609cd1b52402 174020 
python3-psycopg2_2.7.4-1_amd64.deb
Files:
 12417610afbbb6dfbffce95c6d9585c1 2492 python optional psycopg2_2.7.4-1.dsc
 70fc57072e084565a42689d416cf2c5c 425331 python optional 
psycopg2_2.7.4.orig.tar.gz
 67a7cd9ac6ded196d3669482699437f0 14039 python optional psycopg2_2.7.4-1.diff.gz
 6536df29d9775a6ae5618a2e4fe2acb9 9162 python optional 
psycopg2_2.7.4-1_amd64.buildinfo
 a34d5870d985de64bce24aea3fdf68ae 384388 debug optional 
python-psycopg2-dbg_2.7.4-1_amd64.deb
 4679c3f3caa1999d1399d5c72b0cf652 281608 doc optional 
python-psycopg2-doc_2.7.4-1_all.deb
 b38ad4b4c2d2f5b95254ac4ffc2e2ba2 177016 python optional 
python-psycopg2_2.7.4-1_amd64.deb
 b23d856f6122ab6ea9ae5db297ac0ca7 464840 debug optional 
python3-psycopg2-dbg_2.7.4-1_amd64.deb
 8aa1e2244a6ae6d8b3ed91798a7feb23 174020 python optional 
python3-psycopg2_2.7.4-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJafnyBAAoJEHjX3vua1Zrx8LsQAL5xMmSi+3RXkipV6ZldDZme
93LQp/Ew+Md2bqS1jng5P6aJcYRKkiUQWcQTIXokYIl2pcHFXBrj1Rgb9/jKNSS8
KbEANuMFI68N/6VepCfRKI4P3MYGiLtce7wUOEVA6d6PNAbbpSfx4hWq5KcYZjU8
2DmrEOX5hhmye4WsIj4X/BhZMKJ+ZBibsnMi/St7b5GI1yfknLJy74Z2bwQSV/EP
hX7Y7hBGeBn09Wx+OVpSgBXV9wM6sMSuDIF7iMsLYYshu+mMEPEWFNqWo4h81vlv
y3GFJoCviV+vbMoF1JZxzA3k4+0KEH4F13hl6/DOGKfkRHz/Jd7+3ujckonn2Y4B
tbl4sPjICVP+q1fjMlOLz81OYdbFdUkX7A9Q2Q7eVNZhDuvGOvj+6xXqTA/eAei5
ifEwNF2bT4uCrOKFllNBwSMURyEjkqyMYGCqOmgKqG9GUBwZSelBve6oBsVulrUA
WRSIXzebi9f76djYH6tEXuZS0If/C9jzFsvPEpB9CwcQ58AWCjaRMM/G2yPBsl9D
9l0++sobhTYSlB0fjqRVDoSVGT5RggAtuSiMeId1HDAnyrteN5rl4G5pUpJ893WM
XpFFvT6TnH/d7bPj3Ci2MfTNzxKpVzTJOR2CCJiUUJfuI0MAUEPV9QNNxCo5ZacX
iwXJYY8HLJjRux6m7Lsf
=ABVE
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted django-anymail 0.8-2+deb9u1 (source all) into proposed-updates->stable-new, proposed-updates

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 06 Feb 2018 22:44:27 -0500
Source: django-anymail
Binary: python-django-anymail python3-django-anymail
Architecture: source all
Version: 0.8-2+deb9u1
Distribution: stretch-security
Urgency: high
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-django-anymail - Django email backend for multiple ESPs (Python 2)
 python3-django-anymail - Django email backend for multiple ESPs (Python 3)
Closes: 889450
Changes:
 django-anymail (0.8-2+deb9u1) stretch-security; urgency=high
 .
   * Security fix for timing attack on WEBHOOK_AUTHORIZATION secret (CVE-2018-
 6596) as described in https://github.com/anymail/django-anymail/releases/
 tag/v1.2.1 (Closes: #889450)
Checksums-Sha1:
 cfa9505607506e4faafac1b5cae581a865b30358 2208 django-anymail_0.8-2+deb9u1.dsc
 856186c4ac3eefc154b788eb7c05f98b971a 41671 django-anymail_0.8.orig.tar.gz
 c05e6c40e7c79f1c0cda107519a96913101a0298 4712 
django-anymail_0.8-2+deb9u1.debian.tar.xz
 c0fd412da729c2e01fc69c54c2000fa5bb636e30 5886 
django-anymail_0.8-2+deb9u1_amd64.buildinfo
 1539294f1959412f90b2d9da615b26d67f10d1cf 41254 
python-django-anymail_0.8-2+deb9u1_all.deb
 7d2bd9b1c2b2ee04b3fdb168932c442dc1109f76 41320 
python3-django-anymail_0.8-2+deb9u1_all.deb
Checksums-Sha256:
 6c47b08d6f06daba4e0fbb945e6d275b96449bd652c4be6e7874da7b19e87161 2208 
django-anymail_0.8-2+deb9u1.dsc
 64b5ae56823925de69b09615bb737001b2604a80ba1fcf2cb43b00d91fec0b32 41671 
django-anymail_0.8.orig.tar.gz
 010428555a84c141197ec184194a973b301975718cb023967311e45d1dfc89ca 4712 
django-anymail_0.8-2+deb9u1.debian.tar.xz
 cea033aa323fbd72515c1b3ed2a3ff4794535ec957f5bad579711e5a17330496 5886 
django-anymail_0.8-2+deb9u1_amd64.buildinfo
 ad9ec36435ce3b4ddf3fa0fa06dce5d29698b6a54f0bf36aa4b78bfd7461e1b2 41254 
python-django-anymail_0.8-2+deb9u1_all.deb
 8eb07666ea05647588caaa8753e7143182d30de2c2d5dec0cb2c18c3d50bac20 41320 
python3-django-anymail_0.8-2+deb9u1_all.deb
Files:
 e9f92b3d8992e0eb91dabb0c8c7f7782 2208 contrib/python optional 
django-anymail_0.8-2+deb9u1.dsc
 adaf3b352d5a90f909560a0ed2b2d3c5 41671 contrib/python optional 
django-anymail_0.8.orig.tar.gz
 d39682b0c2aef632cc1c4c1d62d393e2 4712 contrib/python optional 
django-anymail_0.8-2+deb9u1.debian.tar.xz
 716dd6aa21c7f5c1a87aa344eaca9728 5886 contrib/python optional 
django-anymail_0.8-2+deb9u1_amd64.buildinfo
 c898f7af2f28d8e8e92ed27982596d3f 41254 contrib/python optional 
python-django-anymail_0.8-2+deb9u1_all.deb
 3864352c28b8afd43b7ec7e1237d9126 41320 contrib/python optional 
python3-django-anymail_0.8-2+deb9u1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJaen/rAAoJEHjX3vua1ZrxW4UQALs2jrqDUJhw9plUz+B4D96l
JrW0/5sI2ChZx1E853e1IcT1ObTiNvlGQx2hBVfOytfHpfuZBrstD7CDRCmGiXgX
a7Fk/0I68tpfhlIuIsyfOyl7ZJFMi7K0lYOkLL0PxnPhWdpLf7fFjFxvwf3OONhD
E+m0Zkgs8xhZf+Fqt5r86rLNAGZm3fEWLjfj03OmfdajWcdvE3eK9kLbe6e/f9qG
kYNnJ5BVAUoyleONui86M7JfpZp8C/xnldtUz1Rko/PX/GGUlJxvr/Wtn0T4owzd
Hrofj8TH4SbJoFHHxIGRM/aeFDS5RvvbQdn/3bTpB9Mab7P3fDmhQRcp+6gOz33n
bNGuMbZjump4dgjJlfOSH+TjRTiXAPKQwTZaMbxo2OG9MFbyVMrdoWHiz/Qcmg5Y
+lfOARw0tuk8qxqXZl1LW/lSOKTC99/bbByYKhs1h/wdEDrfV7GI8RuYgme5p161
fw+AUcED9PdvRUIDAi0bi82CIUjOiQVhdYTaJaeoXqQSANMf/5YmUKCS+1n5lf9t
tgGQJUCK1j76SPnKHHlXgV5kmfocqt/A8Mw76IctKtm9RMWgQNtidGhFHzobvpM4
sgkMhHMMaHpi54XKk/WnZwAeeYikpPQ4fYltfe++LgIPVj6DKBKzySOtNQ2PV3tR
EoE4WrV3qtn2c3uPXgBK
=DbVn
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted chargebee2-python 2.4.5-1 (source all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 06 Feb 2018 00:49:11 -0500
Source: chargebee2-python
Binary: python-chargebee2 python3-chargebee2
Architecture: source all
Version: 2.4.5-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-chargebee2 - Python library for integrating with Chargebee (Python 
2/API v2)
 python3-chargebee2 - Python library for integrating with Chargebee (Python 
3/API v2)
Changes:
 chargebee2-python (2.4.5-1) unstable; urgency=medium
 .
   * New upstream release
   * Update debian/copyright
Checksums-Sha1:
 5cc8c891e8c7c0a2a121cc671a77b59afdb0af29 2213 chargebee2-python_2.4.5-1.dsc
 bca110ee93f7d2bca008341274cb1090245c1461 148168 
chargebee2-python_2.4.5.orig.tar.gz
 1af9071ff2d0f0c311641e4c325483a1b351d3b2 2956 
chargebee2-python_2.4.5-1.debian.tar.xz
 a2bfeb592abc7ea09bc6690333f2917f663ea218 5979 
chargebee2-python_2.4.5-1_amd64.buildinfo
 71203c3e6dbb6c47ea41d7b1be2e88b5870b1cec 138960 
python-chargebee2_2.4.5-1_all.deb
 02d989b92095384eae7e0dd7a9f171b7acede091 139040 
python3-chargebee2_2.4.5-1_all.deb
Checksums-Sha256:
 f192a37877480bbc41a5c7cab88c9dde8c0c0012bd12931d62d950366da7c418 2213 
chargebee2-python_2.4.5-1.dsc
 459a3f80012e6c848ea3c068cbfcfa5770d578ea224017e12e697462153a3d2a 148168 
chargebee2-python_2.4.5.orig.tar.gz
 c728bfb2f7c9285867b07372f46c89c3875c07a7bc58a7c173999609beab43a6 2956 
chargebee2-python_2.4.5-1.debian.tar.xz
 c15c5d3de524f60d78bb1f8945940420291006ddd0c21a62909d781d4f033dfe 5979 
chargebee2-python_2.4.5-1_amd64.buildinfo
 93f5df509d7f664aa4bd1fbe59c21c66db4c7b7497f239007be743d723ba4410 138960 
python-chargebee2_2.4.5-1_all.deb
 dd2be4feb02dc6d3468ae4ba950b0443588f2acf8d9d44e15955b9ddf0dc33ef 139040 
python3-chargebee2_2.4.5-1_all.deb
Files:
 ac730fea5ca53dde981664e4655bcd38 2213 contrib/python optional 
chargebee2-python_2.4.5-1.dsc
 8682115d4ec8aa923a12b5d2b3f685b6 148168 contrib/python optional 
chargebee2-python_2.4.5.orig.tar.gz
 a7a6013104ecfd77279c490fb3c98df9 2956 contrib/python optional 
chargebee2-python_2.4.5-1.debian.tar.xz
 618d8ec9ce675276b17c4787eae03976 5979 contrib/python optional 
chargebee2-python_2.4.5-1_amd64.buildinfo
 9de5d6524d2a623e2c7914da2eff766e 138960 contrib/python optional 
python-chargebee2_2.4.5-1_all.deb
 bebd1c51b3890113723e71378ab5ca1d 139040 contrib/python optional 
python3-chargebee2_2.4.5-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJaeUpRAAoJEHjX3vua1ZrxjeYP/0ElIcNBq1d02K5PzyMzvBWt
46pxWytTKw83WyNxyE6DhN1mcFhc/u8GA6xOVsG9v9mDTXfW5ryJWfVBB7NYLjNm
bwwoXm/uvXRTCISiGhGj6D7Uiwc1S3azKSpBS2lhX37OdzQ9mx/3RM5ZWmRTh5UO
a6QA7Y7JWLbloX3c5NaoLsGJdvVo2aVtwJ5eiVgDy5FUbI40oeW4Wyy3ZEXubLNE
QzjFrcGpmVeqmCYXmVjVsEusmWSC9Tno5AkHHyh1PuLWW426iOi08bkHOL7r/v2N
PARmPlN7Y0Csa+GePycbnRBusjqhWE2QmVxs/CF87d3fjrPV0jmTSnNk5AB9B0pV
qC1IdWTxUo8WXCtlpmjuqL78g4z68tahDBz7meAncp22zHxpDldD7XEmZdw6GxM9
HNmyqhm3u8tg2VstoO/KKGaqUe+XhI62cpVobQkMSHVSXBK8yxehMq5ECh/Lkk3T
VV1PrIxYZSQL6GelRrMG5QkakODAUVzIfJtaNSp+FoLgl9u5i9O2wbZYwj6nX72D
aVqCzZJO42P6Nq3uTB4PBL9jq6cOknfiGtMXtUm1xAwEpfSENprbyx6ersayLU5f
Qhe6EvGpHtF8j1qu1YLF/mluEg/3/n983z4eOzzqh5SOZ9XMZYoN8Gv3EISdWsha
2LS3x/lbLsO/l+IwUCbG
=LqGW
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Accepted django-anymail 1.3-1 (source all) into unstable

[Scott Kitterman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 03 Feb 2018 11:23:43 -0500
Source: django-anymail
Binary: python-django-anymail python3-django-anymail
Architecture: source all
Version: 1.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 
<python-modules-team@lists.alioth.debian.org>
Changed-By: Scott Kitterman <sc...@kitterman.com>
Description:
 python-django-anymail - Django email backend for multiple ESPs (Python 2)
 python3-django-anymail - Django email backend for multiple ESPs (Python 3)
Closes: 889450
Changes:
 django-anymail (1.3-1) unstable; urgency=medium
 .
   * New upstream release (Closes: #889450)
 - Includes security fix for timing attack on WEBHOOK_AUTHORIZATION secret
   (no CVE assigned) as described in
   https://github.com/anymail/django-anymail/releases/tag/v1.2.1
   * Update debian/watch and debian/copyright to use secure URIs
Checksums-Sha1:
 76bca39bc107637152b322760be833f637b6af88 2182 django-anymail_1.3-1.dsc
 53f8410e7a3d49d41d3b7e06fd81971856037da8 56653 django-anymail_1.3.orig.tar.gz
 4b66f150af5589c74db99c115835bbf8eed459e8 3304 
django-anymail_1.3-1.debian.tar.xz
 9871e2e92e6f1174bc0c9eaa2ef179777cbb5d7d 5974 
django-anymail_1.3-1_amd64.buildinfo
 d6b1468af29edb14a578b207af1492ff90846dbe 53764 
python-django-anymail_1.3-1_all.deb
 cae0a4d73c3a632ccc3b68061f305eea541102e1 53848 
python3-django-anymail_1.3-1_all.deb
Checksums-Sha256:
 04d2aa883c7733e9b999e018d1cdff619c361b11cd25abc3d191c12dd3bb50f0 2182 
django-anymail_1.3-1.dsc
 6868f65ea15ea958591aecf222ddc3cf37970ca5441a035ddac285168720ed52 56653 
django-anymail_1.3.orig.tar.gz
 128bb179440d1537700a4b8d4617fc3c35f749bc311b89cbf0f0ccd5d5389669 3304 
django-anymail_1.3-1.debian.tar.xz
 1ce4b73781ac91f33c6ccbb9e4a8cb46c47cb9ee3efbbc4149a80ee19acae947 5974 
django-anymail_1.3-1_amd64.buildinfo
 5d3a9d11de9f0121efb6e0f1f46e9c0edb7eb12aa8ce9b23b3142abdc1b325f3 53764 
python-django-anymail_1.3-1_all.deb
 2bc621df179d371166c5fadad8fdb076662f9d6409a529d7db373031ca2e4e23 53848 
python3-django-anymail_1.3-1_all.deb
Files:
 ce717c1c27dcf9c4d6d326fabccec44e 2182 contrib/python optional 
django-anymail_1.3-1.dsc
 2138d056b8523bf91f7d67c6fb041e14 56653 contrib/python optional 
django-anymail_1.3.orig.tar.gz
 6dc93d1d36823793cd65a8c7a4fab1b3 3304 contrib/python optional 
django-anymail_1.3-1.debian.tar.xz
 428511e511583f239dd6a07694593372 5974 contrib/python optional 
django-anymail_1.3-1_amd64.buildinfo
 e8fa49a66cba54f677c97ada8f725d4c 53764 contrib/python optional 
python-django-anymail_1.3-1_all.deb
 9d8fb2ca1a8fee668a900f0c6c4cba97 53848 contrib/python optional 
python3-django-anymail_1.3-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJadeeUAAoJEHjX3vua1ZrxNgYP/2YX55Zxw9a0Ug7jV7OFwu3v
u13ql2eKvQRIgT8EJfTUp93Whw8Ygc0Zhae8x3MS7c2djg9vVBab3neO7pimJZNw
O1hNKvh9qic5ZZIH0Yo9mW7hVUwjw0oEqOWnSTi/Cb4LbUFRYWzZZSSHv0eL1Z7C
h+fifa0+WJ1j0C9eLED01jMdbzSNp4/PdpFbT3RCJF9Z0zTeGQ3Tb+ZNiLaM4RlP
gGyptJUuscRJl0WHN8KNMKBE6pP2wkoNrPxrWa/H80scmJPIDfQVnfMPUuOE9F6J
onMjmCO0setnqg9rSvd7pWoCIKnKRv55zyWppKhxYQUEcM/KpKK/17xkMb8UlPIk
6v6dibybgcd//hstydFEzFn0zT+anOidfwLQPzvO8x1EvRYBbu+9iZee3aKk/HYa
xDizrTZzOZ6h2m987ys0mVABNsiP//Dc0UF1zP1Ke2d0tu1SR90GvUlXCtDZABQR
Fh51tYLl21gu1AGIajhrTM3WioWZeYDf/l8HB4YCdOwpWXLuZKbJ5UbVzZ6VPUlz
JICNgrcbSaFJqAbtOvs9rqrQak39kBO3pFZJhuWmWv97Jl1j/TE0459sd7SEQ4/j
woixMBB0FiBuUgheEeTIwAL20sEKgFv6LAhKrMju61ZfZ4J5hIXVbh5bStvpC6GP
XY6pMUw/0YBVMvhSmGyM
=1AvG
-END PGP SIGNATURE-


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#879958: Bug#879958: marked as pending

[Scott Kitterman]

On November 4, 2017 7:18:58 AM EDT, deb...@activityworkshop.net wrote:
>I'm not sure if I'm the one supposed to close this bug or if the fixer 
>will do it.  Does "pending" mean it's going through the process or 
>waiting for me?
>
>If I understand correctly, the fix has already been done (thank you
>very 
>much!) and the packages are already being built for buster, but not 
>stretch.  And I guess it's not planned to build them for stretch
>either?
>
>Is there a way for me to test this using stretch, or do I have to 
>upgrade to buster?

Pending means that the fix is available, but not yet released.  You don't need 
to close the bug.  The fix that's pending is for Stretch.

Fixes for stable releases need to be approved by the stable release manager.  I 
believe that this is waiting for that approval.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#784512: Bug#784512: Is anybody working on PySide2?

[Scott Kitterman]

On August 27, 2017 11:13:36 AM EDT, Didier 'OdyX' Raboud  
wrote:
>Le dimanche, 27 août 2017 16.53:30 h CEST, vous avez écrit :
>> Hi,
>> 
>> python-ghost depends on pyside, which will be removed with Qt4.
>> Upstream already ported to pyside2, but I can't find pyside2 in
>> Debian, not even an ITP or RFP. But somewhere I read, that
>> pyside2 will be part of Qt. Is somebody working on this? It
>> would be bad to remove pyside from Debian before pyside2 is in
>> place, right?
>
>For what is worth: I'm not working on pyside, nor pyside2. I removed
>myself 
>from both shiboken and pyside's uploader fields (but should really have
>mailed 
>debian-python about that earlier).

Other than transition related fixes (if you can call disabling tests fixes), I 
don't think anyone has worked on pyside in a long time.

You should consider it orphaned in any practical sense.

If python-ghost can't use PyQt5 instead (some packages are written to work with 
either), then if you want to keep it in the archive, I would plan on packaging 
pyside2.

Qt4 has been unmaintained upstream for many years and it needs to go.

It does look like you're correct that pyside2 is being developed as part of the 
Qt project:

https://wiki.qt.io/PySide2

Given that, we should have it in Debian, but I'm not likely to have time to 
work on it myself.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#868971: Bug#868971: python-feather-format: FTBFS: feather/ext.cpp:28:20: fatal error: Python.h: No such file or directory

[Scott Kitterman]

On July 19, 2017 3:45:23 PM EDT, Lucas Nussbaum  wrote:
>Source: python-feather-format
>Version: 0.3.1+dfsg1-1
>Severity: serious
>Tags: buster sid
>User: debian...@lists.debian.org
>Usertags: qa-ftbfs-20170719 qa-ftbfs
>Justification: FTBFS on amd64
>
>Hi,
>
>During a rebuild of all packages in sid, your package failed to build
>on
>amd64.
>
>Relevant part (hopefully):
>> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
>-Wstrict-prototypes -g -O2
>-fdebug-prefix-map=/<>/python-feather-format-0.3.1+dfsg1=.
>-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
>-D_FORTIFY_SOURCE=2 -fPIC -Ifeather
>-I/usr/lib/python3/dist-packages/numpy/core/include
>-I/<>/python-feather-format-0.3.1+dfsg1/src
>-I/usr/include/python3.6m -c feather/ext.cpp -o
>build/temp.linux-amd64-3.6/feather/ext.o -std=c++11 -O3
>> cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid
>for C/ObjC but not for C++
>> feather/ext.cpp:28:20: fatal error: Python.h: No such file or
>directory
>>  #include "Python.h"
>> ^
>> compilation terminated.
>> error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
>> E: pybuild pybuild:283: build: plugin distutils failed with: exit
>code=1: /usr/bin/python3.6 setup.py build 
>> dh_auto_build: pybuild --build -i python{version} -p 3.6 3.5 returned
>exit code 13
>> debian/rules:8: recipe for target 'build' failed
>> make: *** [build] Error 25
>
>The full build log is available from:
>http://aws-logs.debian.net/2017/07/19/python-feather-format_0.3.1+dfsg1-1_unstable.log

From the log, it looks like missing build-depends on python3-all-dev.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#866575: Bug#866575: libapache2-mod-wsgi-py3: Impossible depends when built with more then one supported python3 version

[Scott Kitterman]

On Saturday, July 08, 2017 12:52:39 PM Bas Couwenberg wrote:
> Package: libapache2-mod-wsgi-py3
> Version: 4.5.11-1
> Followup-For: Bug #866575
> 
> Dear Maintainer,
> 
> The attached patch fixes this issue, but there are several other issues
> with the package that should be fixed in the next upload too.

Thanks for the patch.  I have committed it to the DPMT git repository for the 
next upload.  Since I'm not the package maintainer, I am going to leave it to 
them to decide what else needs to be addressed.

In particular, I suspect this package will need to be rebuilt again when the 
default python3 version changes to update the symlink:

 ./usr/lib/apache2/modules/mod_wsgi.so -> mod_wsgi.so-3.5

Given that, it might make more sense to only build it for the default version.

Thanks again,

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#867481: Bug#867481: Bug#867481: celery FTBFS: test_recursive runs forever with python 3.6

[Scott Kitterman]

On July 7, 2017 8:16:01 PM EDT, Brian May  wrote:
>Adrian Bunk  writes:
>
>>> * sphinx_celery
>>
>> https://tracker.debian.org/pkg/sphinx-celery
>
>Looks like there is only a Python3 version of the package...

It's DPMT maintained, so you could add the python version.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] python-jpype_0.6.2-1_amd64.changes REJECTED

[Scott Kitterman]

Unfortunately, I feel I need to reject your package because it contains a file
with no clear license that is not documented in debian/copyright.

test/sample/big.xml:





It's not clear that this is free (and thus suitable for distribution in
Debian Main even in source form).  If the file has a free license, please
document that, if not repack the tarball to remove it.

Scott K



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#867199: src:python-jpype: Non-free file (possible) in source test/sample/big.xml

[Scott Kitterman]

Package: src:python-jpype
Version: 0.5.4.2-2
Severity: serious
Justification: Policy 2.3

Unfortunately, I just rejected your package from New because it contains a
file with no clear license that is not documented in debian/copyright.  The
same problem exists with the current packages in Debian.

test/sample/big.xml:





It's not clear that this is free (and thus suitable for distribution in
Debian Main even in source form).  If the file has a free license, please
document that, if not repack the tarball to remove it.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#866694: src:pythonmagick: FTBFS with python3.6 as a supported python3

[Scott Kitterman]

Package: src:pythonmagick
Version: 0.9.14-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

With python3.6 as a supported python3 version, this package FTBFS:

checking for python with minimal version... 3.6
checking for a Python interpreter with version >= 3.6... none
configure: error: no suitable Python interpreter found

See [1].

Scott K

[1] 
https://buildd.debian.org/status/fetch.php?pkg=pythonmagick=amd64=0.9.14-3%2Bb2=1498871134=0

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#866575: libapache2-mod-wsgi-py3: Impossible depends when built with more then one supported python3 version

[Scott Kitterman]

Package: libapache2-mod-wsgi-py3
Version: 4.5.11-1
Severity: grave
Justification: renders package unusable

After binNMU with both python3.5 and python3.6 as supported python3 versions,
the package depends include:

python3 (>= 3.6), python3 (<< 3.6)

This makes it unistallable (thus the grave bug).  Ideally, it would build for
both versions and the depends would be:

python3 (>= 3.5), python3 (<< 3.7)

It does look like it is correctly building for both versions:

 ./usr/lib/apache2/modules/mod_wsgi.so -> mod_wsgi.so-3.5
 ./usr/lib/apache2/modules/mod_wsgi.so-3.5
 ./usr/lib/apache2/modules/mod_wsgi.so-3.6

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#865926: jsonpickle: ftbfs with python3.6, please upgrade to 0.9.4

[Scott Kitterman]

On Mon, 26 Jun 2017 10:26:13 +1200 Michael Hudson-Doyle 
 wrote:
> Source: jsonpickle
> Version: 0.9.3-1
> Severity: normal
> User: debian-pyt...@lists.debian.org
> Usertags: python3.6
> 
> Dear Maintainer,
> 
> jsonpickle fails to build when Python 3.6 is a supported version, as the
> current development version of Ubuntu. The 0.9.4 upstream release builds 
fine
> though, so it would be good to update to that in preparation for the Python 
3.6
> transition in unstable.

We have 3.6 supported in Debian now too, so bumping to serious.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#862423: pysvn ftbfs with more than one supported python3 version

[Scott Kitterman]

On Fri, 12 May 2017 08:25:16 -0700 Matthias Klose  wrote:
> Package: src:pysvn
> Version: 1.9.4-2
> Severity: important
> Tags: sid buster
> User: debian-pyt...@lists.debian.org
> Usertags: python3.6
> 
> pysvn ftbfs with more than one supported python3 version, when PYVERS3 
expands
> to more than one version. So either build for only the default version 
(change
> the b-d's), or fix the build system to build for all supported versions.

This is causing actual FTBFS in the archive now, so raising severity to 
serious.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#866536: src:jpy: FTBFS on mips

[Scott Kitterman]

Package: src:jpy
Version: 0.8-5
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Package FTBFS (just on mips) during binNMU that added python3.6 support:

https://buildd.debian.org/status/fetch.php?pkg=jpy=mips=0.8-5%2Bb1=1498778567=0

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#863267: Bug#863267: Associated removals

[Scott Kitterman]

On May 26, 2017 3:04:03 AM EDT, Adrian Bunk <b...@debian.org> wrote:
>On Fri, May 26, 2017 at 05:46:22AM +0000, Scott Kitterman wrote:
>> 
>> 
>> On May 26, 2017 12:30:17 AM EDT, Neil Williams <codeh...@debian.org>
>wrote:
>> >On Fri, 26 May 2017 04:11:49 +
>> >Scott Kitterman <deb...@kitterman.com> wrote:
>> >
>> >> I don't see any way to completely resolve this before stretch
>> >> releases other than removing lava-server.
>> >
>> >This is a *django* bug! There is no evidence that lava-server is
>> >responsible for this - it just has to use multiple django apps. Any
>> >other system outside Debian using multiple apps will suffer the same
>> >bug.
>> >
>> >Note: once this bug occurs, unless the user is *clearly* warned to
>look
>> >for and install 1.8, *data loss* will occur. We have already had one
>> >user lose data covering 6 months of tests due to this error. The
>> >process must halt when the exception is seen, the app will be down
>and
>> >unusable and users will get a 503.
>> 
>> Sounds like a great input for the release notes.  You should submit
>it.
>> 
>> If you'd filed this bug months ago, back when you found it, maybe
>something could have been done.  Given short time before release,
>there's not a lot of options.
>> 
>> It really doesn't matter whose fault the bug is.
>
>Let's get constructive:
>
>If it is agreed that this is a bug in Django, then you or Neil or the 
>Django maintainers should forward it to upstream for getting a fix from
>upstream.
>
>If there is no fix for Django available in time for the stretch
>release,
>the problem should be noted in the release notes (especially if it
>might
>also affect other users of Django) *and* the fix should be delivered to
>users in a stretch point release.

It's not an upgrade path that upstream supports.  They aren't going to 'fix' 
anything for this even if they agree it's a Django problem (I'm not saying it 
is or isn't, it doesn't matter at this point).

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#863267: Bug#863267: Associated removals

[Scott Kitterman]

On May 26, 2017 12:30:17 AM EDT, Neil Williams <codeh...@debian.org> wrote:
>On Fri, 26 May 2017 04:11:49 +0000
>Scott Kitterman <deb...@kitterman.com> wrote:
>
>> I don't see any way to completely resolve this before stretch
>> releases other than removing lava-server.
>
>This is a *django* bug! There is no evidence that lava-server is
>responsible for this - it just has to use multiple django apps. Any
>other system outside Debian using multiple apps will suffer the same
>bug.
>
>Note: once this bug occurs, unless the user is *clearly* warned to look
>for and install 1.8, *data loss* will occur. We have already had one
>user lose data covering 6 months of tests due to this error. The
>process must halt when the exception is seen, the app will be down and
>unusable and users will get a 503.

Sounds like a great input for the release notes.  You should submit it.

If you'd filed this bug months ago, back when you found it, maybe something 
could have been done.  Given short time before release, there's not a lot of 
options.

It really doesn't matter whose fault the bug is.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#863267: Associated removals

[Scott Kitterman]

I don't see any way to completely resolve this before stretch releases other 
than removing lava-server.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Scott Kitterman]

On May 23, 2017 5:28:04 PM EDT, Alexander Wirt  wrote:
>On Tue, 23 May 2017, Raphael Hertzog wrote:
>
>> (please cc me on answers)
>> 
>> On Tue, 23 May 2017, Debian FTP Masters wrote:
>> > please take the version from testing, not a version that never was
>in the archive
>> 
>> I have been maintaining the 1.8.x LTS version of Django in
>jessie-backports since
>> December 2015.
>> 
>> Except the very first, none of the 1.8.x versions that I uploaded in
>> jessie-backports have been in testing.
>> 
>> Please let me continue providing this service to our users.
>> 
>> Why are you suddenly acting on this upload and not the formers?
>You didn't followed the often stated policy. Full stop. We just never
>noticed. 
>
>We stated that several times and you just decided that policy does not
>count
>for you. I think that is pretty unfair. 

There are security fixes in this upload.  What's the way to get those fixed?  
Backporting 1.10 isn't an option because it is incompatible with many other 
packages.

Would cherry-picked security fixes be okay?

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#862434: Bug#862434:

[Scott Kitterman]

On Tuesday, May 16, 2017 03:42:52 PM Michael Hudson-Doyle wrote:
> I have not, no. I guess we'll get the autopkgtest coverage when Python 3.6
> is the default, perhaps I should try something before then...

I have a vague recollection I looked at this before and it's more complicated 
than that.  Unfortunately too vague for any useful advice.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#862434: Bug#862434:

[Scott Kitterman]

On Tuesday, May 16, 2017 03:11:33 PM Michael Hudson-Doyle wrote:
> I don't think that's quite right, I think the problem is the computation of
> PY3MIN and PY3MAX. I've uploaded this patch to Ubuntu which I think fixes
> the problem:
> http://launchpadlibrarian.net/319819189/mod-wsgi_4.5.11-1build1_4.5.11-1ubun
> tu1.diff.gz
> 
> (you'd still have to edit wsgi.load to use the Python 3.6 version but I
> guess that's just the way it is)

And you've tested that works (as in run time works, not just builds)?

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#860882: [package:python-passlib] Generated egg version is invalid. Breaks Ansible runs.

[Scott Kitterman]

On Sun, 23 Apr 2017 13:08:36 +1000 Brian May  wrote:
> Brian May  writes:
> 
> > In what way do you consider this a bug in python-passlib and not
> > ansible?
> 
> Looks like an Ansible bug to me:
> 
> https://github.com/ansible/ansible/issues/20199

Definitely.  If you look at the Python package versioning PEP [1], 
1.7.0.post20170421091442 is a perfectly valid version for a Python package.

Scott K


[1] https://www.python.org/dev/peps/pep-0440/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] next version of csvkit

[Scott Kitterman]

On Friday, March 31, 2017 10:26:27 PM Ghislain Vaillant wrote:
> How so? Buster will not be supporting Python 2, so the narrative of
> having new source packages only provide Python 3 binary packages is
> totally justified.

What makes you think this is true?

Personally, I expect Python2 to be around for a very long time.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#857006: Bug#857006: python-urllib3: Missing version constraint for six

[Scott Kitterman]

On March 7, 2017 7:11:35 PM EST, Daniele Tricoli  wrote:
>Hello Tristan,
>thanks for this report.
>
>On Tuesday, March 7, 2017 5:19:02 AM CET Tristan Seligmann wrote:
>> setup.py does not have a version constraint on six as it is vendored
>> upstream, but since we are unvendoring it in Debian, we need a
>version
>> constraint. This is made trickier by the fact that upstream won't be
>> tracking the minimum version for us, as they only need to care about
>the
>> specific version they vendor. Perhaps a >= 
>> constraint in Debian would be the easiest?
>
>It seems that urllib3 is vendoring six 1.10.0:
>https://github.com/shazow/urllib3/commit/ce9394a2564608823019ad6b59276bfa82bad642
>
>I will add the >= 1.10.0, on the next upload. I plan to upload
>urllib 1.20 to experimental soon.
>
>Should I need to backport this also for Stretch?
>
>Cheers,

Stretch has 1.10, so I would think that the issue is not RC for Stretch.  I'd 
leave it the way it is.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#851013: python-pyramid: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13

[Scott Kitterman]

On Tue, 7 Feb 2017 20:06:04 -0500 Sandro Tosi  wrote:
> As Stuart, i cannot replicate this bug: i built pyramid 5 times and
> all of them shown no errors in the test suite:
> 
> 
> $ grep -A2 ^Ran *.build
> Ran 2482 tests in 5.871s
> 
> OK
> --
> Ran 2482 tests in 6.876s
> 
> OK
> ```
> 
> (log attached)
> 
> i think we can wait a little more days, and then close it if we dont
> hear otherwise

It's been almost a month.  At the very least, I think it can be downgraded 
(which I've done).

Scott K

signature.asc
Description: This is a digitally signed message part.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Comments regarding afew_0.0+git2016.02.29.b19a88f-1_amd64.changes

[Scott Kitterman]

I am going to accept your package, however there is an error in debian/
copyright that should be fixed for the next upload.  Instead of MIT, the
license should be referred to as Expat (MIT uses many licenses, not just this
one.  See 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification
for details.

Scott K



___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#844587: Bug#844587: python3-googleapiclient: file conflict with existing python3-googleapi

[Scott Kitterman]

On Thursday, November 17, 2016 08:03:08 PM Ambrose Andrews wrote:
> Package: python3-googleapiclient
> Severity: normal
> 
> Dear Maintainer,
> 
> When I was installing newly arrived (in testing) python3-googleapiclient i
> noticed errors arising from file conflicts with the already installed
> python3-googleapi .
> 
> (looks like this is the same upstream software packaged twice.)
> 
> I suppose one of them can go :-)

Thanks for noticing.  I've asked to have this one removed.

Scott K

signature.asc
Description: This is a digitally signed message part.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#844225: Bug#844225: please rebuild

[Scott Kitterman]

On November 13, 2016 11:07:12 AM EST, VA  wrote:
>Package: python-pyqt5.qsci
>Version: 2.9.3+dfsg-3
>
>Since update of Qt to 5.7 in Debian, a basic program using Python 
>QScintilla segfaults:
>
>from PyQt5.QtWidgets import *
>from PyQt5.Qsci import *
>app = QApplication([])
>ed = QsciScintilla()
>ed.show()
>print(ed.text())
>app.exec_()
>
>Is this due to the qscintilla bindings not having been updated/rebuilt?

Yes.  That's part of the transition that's not yet done.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#844139: python-django: FTBFS: Tests failures

[Scott Kitterman]

On Sat, 12 Nov 2016 21:15:22 +0100 Lucas Nussbaum  wrote:
> Source: python-django
> Version: 1:1.10.3-1
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-2016 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
...
> 
> This failure happens on a CPU with TSX extensions available, but is not
> reproducible on a machine without them. 

==
FAIL: test_fuzzy_compiling (i18n.test_compilation.FuzzyTranslationTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
  File "/<>/tests/i18n/test_compilation.py", line 218, in 
test_fuzzy_compiling
self.assertEqual(ugettext('Lenin'), force_text('Ленин'))
  File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python2.7/unittest/case.py", line 924, in 
assertMultiLineEqual
self.fail(self._formatMessage(msg, standardMsg))
  File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
raise self.failureException(msg)
AssertionError: u'Lenin' != u'\u041b\u0435\u043d\u0438\u043d'
- Lenin
+ \u041b\u0435\u043d\u0438\u043d

The non-lazy evaluation test passes and the lazy evaluation code last changed 
before 1.10.0 was released, so if this is a problem in 1.10.3 in unstable, it 
also affects 1.10.1 in testing.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#844037: src:python-django: New upstream release available

[Scott Kitterman]

Package: src:python-django
Version: 1.10.1
Severity: wishlist

Django 1.10.3 is out and it would be nice to see it in Debian.

Thanks,

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Packaging Django v1.8 for Sid?

[Scott Kitterman]

On November 8, 2016 5:00:24 PM EST, Turbo Fredriksson  wrote:
>On 8 Nov 2016, at 10:43, Neil Williams  wrote:
>
>> As I said, I don't see python-django1.8 being an option for unstable
>at
>> this time.
>
>Without that, we won’t have a (properly) working Openstack GUI in
>stretch :(.
>
>It’s still going to be there, installable and everything, but it won’t
>work correctly.

Python-django doesn't have a great track record regarding needing security 
updates [1].  I don't think it's reasonable to ask the security team to support 
two versions.  Neither do I think it would be appropriate to ship a package 
this risky without security support.  I'm currently supporting security 
backports for Django 1.6 on wheezy and jessie for customers and it can be a lot 
of work.

Much as I know you don't want to hear it, I think the only path to success is 
to make openstack work with 1.10.

Scott K
[1] https://security-tracker.debian.org/tracker/source-package/python-django

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#841830: please provide qtwebengine

[Scott Kitterman]

QtWebEngine itself is not in Debian yet.  Once it is, we intend to provide 
bindings for it.

Scott K

On October 23, 2016 12:14:46 PM EDT, VA  wrote:
>Source: pyqt5
>Version: 5.7+dfsg-2
>
>Qt Webkit has been deprecated since Qt 5.5 
>(https://wiki.qt.io/New_Features_in_Qt_5.5#Deprecated_Functionality)
>and 
>is to be replaced by Qt WebEngine (which was introduced in Qt 5.4). Qt 
>WebEngine has a corresponding PyQt module.
>
>Please provide a package for accessing QtWebEngine (like 
>python-pyqt5.qtwebkit).

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Maintenance of new Flask

[Scott Kitterman]

Please resend to debian-python@l.d.o and include your alioth user name when 
you do.

Scott K

On Monday, August 08, 2016 01:09:03 PM Dominik George wrote:
> Hi DPMT,
> 
> I would like to package and maintain some Flask extensions. Flask, a web
> micro-framework, and some extensions for it are already available in Debian
> and under team maintenance of the DPMT.
> 
> I would initially like to add these two extensions:
> 
>   Flask-Restless
>   Flask-Compress
>   Flask-LDAPConn
> 
> Also, I would like to help fix open bugs in existing Flask packages.
> 
> I would base my packages off of existing ones in order to enable the team to
> co-maintain the packages.
> 
> Apart from these new packages, I maintain a few other packages in Debian, in
> cooperation with several DDs.
> 
> If the DPMT is willing to co-maintain the new packages, I would like to keep
> the package repositories and the like in DPMT from the beginning.
> 
> Please tell me if it is ok to ask for team membership on Alioth ☺!
> 
> Cheers,
> Nik


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#823615: Marking as wishlist since the package is working as designed

[Scott Kitterman]

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] on the maintenance of rope

[Scott Kitterman]

On Monday, July 25, 2016 02:02:05 PM Ghislain Vaillant wrote:
> Dear Arnaud and potential DPMT co-maintainers,
> 
> I am currently participating in a packaging effort to update spyder [1],
> a scientific IDE, to its latest upstream version. Amongst its
> dependencies, spyder requires a fairly recent version of rope for both
> Python 2 and 3.
> 
> However, the source package currently in Debian is missing a binary
> package for Python 3 and is affected by a security vulnerability. Both
> issues were raised in the BTS [2, 3], but none of them seems to have
> been acknowledged or acted upon.
> 
> Could you please confirm whether the package is still actively
> maintained, and if so, consider fixing the bugs mentioned above?
> 
> Otherwise, I'd be happy to contribute but it would require me to perform
> a migration of the packaging repository to the DPMT git, and
> translate the build system from cdbs to pybuild. That is, because it
> is the only workflow I am familiar with, and also the one recommended
> by the DPMT policy / wiki.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826042
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755911
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777525

There is already a git repository that was created when the team migration was 
done, so no conversion is needed.  Particularly given the outstanding security 
issue, it probably shouldn't wait long, so you might consider going ahead with 
your work in the existing git repository while waiting to see what Arnaud has 
to say.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] RM of shiboken & pyside ?

[Scott Kitterman]

On Tuesday, July 05, 2016 06:00:25 PM Didier 'OdyX' Raboud wrote:
> Hi there,
> 
> Now that we have PyOtherSide in Debian, and that both shiboken and
> PySide are somewhat broken in sid & stretch; what about just removing
> them from Debian ?
> 
> I'm not a PySide user myself, and it's abandonned upstream…

If it's dead, let's remove it.

Scott K


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#806591: qscintilla2: FTBFS on sparc64 due to mismatched symbols files

[Scott Kitterman]

On Saturday, May 14, 2016 01:39:11 PM John Paul Adrian Glaubitz wrote:
> Hi Scott!
> 
> > c++ symbols files are a paint o deal with and do (particularly in
> > qscintilla's case vary per-architecture.  Updating only one
> > architecture tends to be error prone.  I will include a fix for this
> > with the next new upstream release when all archs need updating.
> 
> Any news on this?
> 
> Looks like you recently uploaded a new upstream release, so I assume
> you forgot to update the symbols file.
> 
> Could you please fix this in the next upload?

I just looked at fixing this, but I see that the build log for the current 
version, qscintilla2_2.9.2+dfsg-2, is not on buildd.d.o.  Due to the new Qt 
version there were some considerable additional changes in the symbols.  If 
you can provide a log with at least the symbols changes for 
qscintilla2_2.9.2+dfsg-2, I should be able to include this in the next upload 
in the next days.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#811984: qscintilla2: FTBFS with GCC 6: symbol changes

[Scott Kitterman]

On Tuesday, January 19, 2016 08:13:26 PM Martin Michlmayr wrote:
> Package: qscintilla2
> Version: 2.9.1+dfsg-4
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-6 gcc-6-symbols
> 
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
> 
> Note that only the first error is reported; there might be more.  You
> can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
> you can set CC=gcc-6 CXX=g++-6 explicitly.
> 
> You may be able to find out more about this issue at
> https://gcc.gnu.org/gcc-6/changes.html
> 
> > sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux
> 
> ...
> 
> > dpkg-gensymbols: warning: some new symbols appeared in the symbols file:
> > see diff output below dpkg-gensymbols: warning: some symbols or patterns
> > disappeared in the symbols file: see diff output below dpkg-gensymbols:
> > warning: debian/libqscintilla2-12v5/DEBIAN/symbols doesn't match
> > completely debian/libqscintilla2-12v5.symbols ---
> > debian/libqscintilla2-12v5.symbols
> > (libqscintilla2-12v5_2.9.1+dfsg-4_amd64) +++
> > dpkg-gensymbolsv15vh4   2016-01-19 21:14:51.112125090 +
> > @@ -96,6 +96,13 @@
> > 
> >   _Z5IsEOLi@Base 2.8.4
> >   _Z5issmli@Base 2.8.4
> >   _Z5qRgba@Base 2.8.4
> > 
> > + _Z5qSwapI12QFontPrivateEvR28QExplicitlySharedDataPointerIT_ES4_@Base
> > 2.9.1+dfsg-4 + _Z5qSwapIP12QFontPrivateEvRT_S3_@Base 2.9.1+dfsg-4
> > + _Z5qSwapIP8QMapDataEvRT_S3_@Base 2.9.1+dfsg-4
> > + _Z5qSwapIPN10QByteArray4DataEEvRT_S4_@Base 2.9.1+dfsg-4
> > + _Z5qSwapIPN7QString4DataEEvRT_S4_@Base 2.9.1+dfsg-4
> > + _Z5qSwapIPN9QListData4DataEEvRT_S4_@Base 2.9.1+dfsg-4
> > + _Z5qSwapIjEvRT_S1_@Base 2.9.1+dfsg-4
> > 
> >   _Z6iscamli@Base 2.8.4
> >   _Z6issmldi@Base 2.8.4
> >   _Z6issmlfi@Base 2.8.4
> > 
> > @@ -258,6 +265,7 @@
> > 
> >   _ZN10QByteArrayC2Ev@Base 2.8.4
> >   _ZN10QByteArrayD1Ev@Base 2.8.4
> >   _ZN10QByteArrayD2Ev@Base 2.8.4
> > 
> > + _ZN10QByteArrayaSEOS_@Base 2.9.1+dfsg-4
> > 
> >   _ZN10QByteArraypLEc@Base 2.8.4
> >   _ZN10QDropEvent20acceptProposedActionEv@Base 2.8.4
> >   _ZN10QsciLexerD11qt_metacallEN11QMetaObject4CallEiPPv@Base 2.8.4
> > 
> > @@ -403,12 +411,15 @@
> 
> ...
> 
> The diff was 1.5 MB so I didn't include everything.  I can send you a
> log if you want.
> 
> Martin

Once GCC-6 is default, I'll update the symbols files.  It's premature to do it 
now.

Scott K

signature.asc
Description: This is a digitally signed message part.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#827417: Bug#827417: unmatching types with qscintilla

[Scott Kitterman]

On Thursday, June 16, 2016 12:48:30 AM VA wrote:
> Package: python-pyqt5.qsci
> Version: 2.9.2+dfsg-1
> 
> I just upgraded Qt5 libraries and now functions from PyQt5.Qsci taking a
> QString cannot take anything from Python:

We've just scheduled a rebuild of Qscintilla2 against the new version of Qt in 
Unstable.  That should take care of this.  If you are still having the problem 
after updating to the new version, please reopen the bug.

Scott K


signature.asc
Description: This is a digitally signed message part.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#823137: Bug#823137: new upstream release of qscintilla

[Scott Kitterman]

On May 1, 2016 6:45:18 AM EDT, VA  wrote:
>Package: qscintilla2
>Version: 2.9.1+dfsg-4
>
>QScintilla 2.9.2 has been released: https://riverbankcomputing.com/news

Already working on it.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#810260: Bug#810260: python-getdns: FTBFS: error: "GETDNS_TRANSPORT_STARTTLS" undeclared

[Scott Kitterman]

On Thu, 07 Jan 2016 17:37:34 -0800 Daniel Kahn Gillmor  
wrote:
> Control: reassign 810260 getdns
> Control: affects 810260 python-getdns
> Control: retitle backward-incompatible API change in getdns 0.9.0
...
> This appears to be due to an unnoticed API change in libgetdns 0.9.0,
> sorry about that.  I've just raised the issue with upstream, hopefully
> we can get it resolved promptly.

There's a matching upstream change for python-getdns now, so I think they've 
decided how to resolve it.  I'll cherrypick the fix and upload it.  Since there 
are no other rdepends, as a practical matter, I think this is best.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#806591: qscintilla2: FTBFS on sparc64 due to mismatched symbols files

[Scott Kitterman]

On Wed, 2 Dec 2015 10:24:56 +0100 John Paul Adrian Glaubitz 
 wrote:
> On 11/29/2015 01:23 PM, John Paul Adrian Glaubitz wrote:
> > qscintilla2 currently fails to build from source on sparc64 due to several
> > symbols files having mismatched symbols for this architecture.
> > 
> > Please update the symbols file using the diff provided in the build log [1].
> 
> I just uploaded a patched version to 'unreleased'.
> 
> It would still be great to have this fixed in unstable!

c++ symbols files are a paint o deal with and do (particularly in qscintilla's 
case vary per-architecture.  Updating only one architecture tends to be error 
prone.  I will include a fix for this with the next new upstream release when 
all archs need updating.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#810139: Bug#810139: kivy: FTBFS: TypeError: can't pickle Cython.Compiler.FlowControl.NameAssignment objects

[Scott Kitterman]

On Wednesday, January 06, 2016 08:56:40 PM Chris Lamb wrote:
> Source: kivy
> Version: 1.9.0-3
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> kivy fails to build from source in unstable/amd64:
> 
>   [..]
> 
>   copying kivy/uix/filechooser.py ->
> /home/lamby/temp/cdt.20160106205225.upezSixthN/kivy-  running build_ext
> Build configuration is:
>* use_rpi = 0
>* use_opengl_es2 = 1
>* use_opengl_debug = 0
>* use_glew = 0
>* use_sdl2 = 1
>* use_ios = 0
>* use_mesagl = 0
>* use_x11 = 0
>* use_gstreamer = 1
>* use_avfoundation = 0
>* use_osx_frameworks = 0
>* debug = False
>   Updated
> /home/lamby/temp/cdt.20160106205225.upezSixthN/kivy-1.9.0/.pybuild/pythonX.
> Y_3.5/build/kivy/graphics/config.h Updated kivy/graphics/config.h
>   Updated
> /home/lamby/temp/cdt.20160106205225.upezSixthN/kivy-1.9.0/.pybuild/pythonX.
> Y_3.5/build/kivy/graphics/config.pxi Updated kivy/graphics/config.pxi
>   Updated
> /home/lamby/temp/cdt.20160106205225.upezSixthN/kivy-1.9.0/.pybuild/pythonX.
> Y_3.5/build/kivy/setupconfig.py Updated kivy/setupconfig.py
>   Detected compiler is unix
>   cythoning kivy/graphics/opengl.pyx to kivy/graphics/opengl.c
>/usr/lib/python3.5/distutils/dist.py:261: UserWarning: Unknown
> distribution option: 'dependency_links' warnings.warn(msg)
>/usr/lib/python3.5/distutils/dist.py:261: UserWarning: Unknown
> distribution option: 'install_requires' warnings.warn(msg)
>Traceback (most recent call last):
>  File "setup.py", line 910, in 
>install_requires=['Kivy-Garden==0.1.1'])
>  File "/usr/lib/python3.5/distutils/core.py", line 148, in setup
>dist.run_commands()
>  File "/usr/lib/python3.5/distutils/dist.py", line 955, in run_commands
>self.run_command(cmd)
>  File "/usr/lib/python3.5/distutils/dist.py", line 974, in run_command
>cmd_obj.run()
>  File "/usr/lib/python3.5/distutils/command/build.py", line 135, in run
>self.run_command(cmd_name)
>  File "/usr/lib/python3.5/distutils/cmd.py", line 313, in run_command
>self.distribution.run_command(command)
>  File "/usr/lib/python3.5/distutils/dist.py", line 974, in run_command
>cmd_obj.run()
>  File "/usr/lib/python3/dist-packages/Cython/Distutils/build_ext.py",
> line 164, in run _build_ext.build_ext.run(self)
>  File "/usr/lib/python3.5/distutils/command/build_ext.py", line 338, in
> run self.build_extensions()
>  File "setup.py", line 258, in build_extensions
>build_ext.build_extensions(self)
>  File "/usr/lib/python3/dist-packages/Cython/Distutils/build_ext.py",
> line 171, in build_extensions ext.sources =
> self.cython_sources(ext.sources, ext)
>  File "/usr/lib/python3/dist-packages/Cython/Distutils/build_ext.py",
> line 320, in cython_sources full_module_name=module_name)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Main.py", line
> 677, in compile return compile_single(source, options, full_module_name)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Main.py", line
> 630, in compile_single return run_pipeline(source, options,
> full_module_name)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Main.py", line
> 487, in run_pipeline err, enddata = Pipeline.run_pipeline(pipeline, source)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Pipeline.py", line
> 328, in run_pipeline data = phase(data)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Pipeline.py", line
> 53, in generate_pyx_code_stage module_node.process_implementation(options,
> result)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/ModuleNode.py",
> line 118, in process_implementation self.generate_c_code(env, options,
> result)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/ModuleNode.py",
> line 339, in generate_c_code self.body.generate_function_definitions(env,
> code)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Nodes.py", line
> 436, in generate_function_definitions
> stat.generate_function_definitions(env, code)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Nodes.py", line
> 436, in generate_function_definitions
> stat.generate_function_definitions(env, code)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Nodes.py", line
> 3056, in generate_function_definitions
> FuncDefNode.generate_function_definitions(self, env, code)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Nodes.py", line
> 1923, in generate_function_definitions self.generate_function_body(env,
> code)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Nodes.py", line
> 1681, in generate_function_body self.body.generate_execution_code(code)
>  File "/usr/lib/python3/dist-packages/Cython/Compiler/Nodes.py", line
> 442, in 

[Python-modules-team] Bug#809540: Bug#809540: Recommend python3-all as well

[Scott Kitterman]

On Thursday, December 31, 2015 11:54:29 PM Yuri D'Elia wrote:
> Package: python-stdeb
> Version: 0.8.5-1
> Severity: wishlist
> 
> With the general push for python3, I'd advocate for recommending python3-all
> and suggesting python3-all-dev in addition to the current dependencies.

The -dev packages are only needed for compiling Python extensions.  They 
aren't needed for normal Python modules/applications.  Since we use the -dev 
package being in build-depends for tracking python3 transitions (see [1] for 
the current example), extra build-depends on the -dev packages are an unneeded 
complication.

Scott K

[1] https://release.debian.org/transitions/html/python3.5.html

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#665015: Bug#665015: python-sleekxmpp: New upstream version

[Scott Kitterman]

On December 23, 2015 10:29:50 AM EST, "W. Martin Borgert"  
wrote:
>Quoting Jonas Smedegaard :
>> Well, it was _you_ - noone else - who proposed to get rid of cdbs
>here.
>> You could instead suggest to team up with us when noticing that the
>> style of packaging fit your abilities and preferences. ;-)
>
>I'm not even sure, whether DPMT requires use of dh, but all
>packages I looked at seem to use dh. I assume it is team policy.

There is no policy on this.  It's only the way most people's preference runs 
these days.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#784513: qtwebkit removal from python-qt4

[Scott Kitterman]

s/2015/2016//___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#807336: Bug#807336: python-psycopg2: double free or corruption

[Scott Kitterman]

On Monday, December 07, 2015 05:42:54 PM Fabien Harrang wrote:
> Below GDB traces with python-psycopg2-dbg installed.
> 
> Thanks,
> 
> Fabien
> 
> gdb -ex r --args python -m trt.geolocate geolocate_addresses

Sorry, I should have mentioned this the first time...

Please use python-dbg as the interpreter command.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#803419: Bug#803419: fixed in qscintilla2 2.9.1+dfsg-2

[Scott Kitterman]

On Friday, October 30, 2015 01:16:14 PM Matijs van Zuijlen wrote:
> Hi,
> 
> Unfortunately the below change means the dev package now breaks the package
> it depends on. Perhaps this should be a versioned Breaks?
> 
> >   * Add libqt5scintilla2-dev Breaks/Replaces libqt5scintilla2-12v5 due to
> > qscintilla2.prf moving between the packages (Closes: #803419)

Yes.  It should have been.  Fixing.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#800819: pyfits: Still FTBFS on mips

[Scott Kitterman]

Source: pyfits
Version: 1:3.3-6
Severity: serious
Justification: fails to build from source (but built successfully in the past)

There's still a test failure on mips, despite everthing building on other
archs now (thanks for fixing those):

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build/pyfits/tests/test_image.py", line 
1328, in test_compression_with_gzip_column
assert np.all(comp_hdu.data[0] == arr[0])
AssertionError

--
Ran 405 tests in 213.015s

FAILED (failures=3)
E: pybuild pybuild:262: test: plugin distutils failed with: exit code=1: cd 
/«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build; python2.7 -m nose 
dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7 --dir . 
returned exit code 13
debian/rules:6: recipe for target 'build-arch' failed
make: *** [build-arch] Error 25

This is blocking progress on the python3.5 transition, so I would appreciate
it if you could make it a priority to address.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#800683: pyfits: FTBFS during rebuild for python3.5 transition

[Scott Kitterman]

Source: pyfits
Version: 1:3.3-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Here's an excerpt from the amd64 build log:

I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build; python3.4 
-m nose 
FF.../«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/pyfits/hdu/compressed.py:605:
 PyfitsPendingDeprecationWarning: Keyword argument tileSize to CompImageHDU is 
pending deprecation; use tile_size instead
  PyfitsPendingDeprecationWarning)
/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/pyfits/hdu/compressed.py:605: 
PyfitsPendingDeprecationWarning: Keyword argument compressionType to 
CompImageHDU is pending deprecation; use compression_type instead
  PyfitsPendingDeprecationWarning)
.../«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/pyfits/hdu/compressed.py:605:
 PyfitsPendingDeprecationWarning: Keyword argument compressionType to 
CompImageHDU is pending deprecation; use compression_type instead
  PyfitsPendingDeprecationWarning)
/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/pyfits/hdu/compressed.py:605: 
PyfitsPendingDeprecationWarning: Keyword argument quantizeLevel to CompImageHDU 
is pending deprecation; use quantize_level instead
  PyfitsPendingDeprecationWarning)
/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/pyfits/hdu/compressed.py:605: 
PyfitsPendingDeprecationWarning: Keyword argument compressionType to 
CompImageHDU is pending deprecation; use compression_type instead
  PyfitsPendingDeprecationWarning)
/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/pyfits/file.py:339: 
UserWarning: Overwriting existing file 
'/tmp/pyfits-test-csigwsrv/test_new.fits'.
  warnings.warn("Overwriting existing file %r." % self.name)
.../«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/pyfits/file.py:339:
 UserWarning: Overwriting existing file 
'/tmp/pyfits-test-zwl3n9fq/test_new.fits'.
  warnings.warn("Overwriting existing file %r." % self.name)
/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/pyfits/file.py:339:
 UserWarning: Overwriting existing file 
'/tmp/pyfits-test-pof_8tg7/newtable.fits'.
  warnings.warn("Overwriting existing file %r." % self.name)

==
FAIL: Regression test for https://aeon.stsci.edu/ssb/trac/pyfits/ticket/158
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in runTest
self.test(*self.arg)
  File 
"/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/pyfits/tests/test_header.py", line 
672, in test_hierarch_create_and_update
assert len(w) == 0
AssertionError

==
FAIL: Regression test for https://aeon.stsci.edu/ssb/trac/pyfits/ticket/158
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in runTest
self.test(*self.arg)
  File 
"/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/pyfits/tests/test_header.py", line 
735, in test_short_hierarch_create_and_update
assert len(w) == 0
AssertionError

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#800392: Bug#800392: python-numpy: FTBFS on powerpc due to test failure

[Scott Kitterman]

OK. Can you prepare an upload?  This is blocking the python3.5 transition, so I 
would like to see it resolved quickly.

Scott K

On September 29, 2015 3:05:18 AM EDT, Julian Taylor 
<jtaylor.deb...@googlemail.com> wrote:
>On 28.09.2015 20:58, Scott Kitterman wrote:
>> 
>> Seems like this may be related to #702169.
>> 
>
>no, powerpc is the arch with the broken malloc:
>https://sourceware.org/bugzilla/show_bug.cgi?id=6527
>
>the test should probably just be ignored (as it has been in the past)
>it
>has always been broken and nobody ever cared.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#800392: Bug#800392: Bug#800392: Bug#800392: python-numpy: FTBFS on powerpc due to test failure

[Scott Kitterman]

On Wednesday, September 30, 2015 01:22:51 AM Julian Taylor wrote:
> On 30.09.2015 01:14, Julian Taylor wrote:
> > On 30.09.2015 01:01, Sandro Tosi wrote:
> >> On Tue, Sep 29, 2015 at 8:05 AM, Julian Taylor
> >> 
> >> Is there an elegant way to instruct numpy testsuite to just ignore
> >> errors on powerpc? I would really love to keep the test failures as
> >> blocking on all Debian archs. I cant think of any smart way to keep
> >> the 'set -e' for all archs except powerpc
> >> 
> >> on way would be to just skip that test (in the last failure it was
> >> always test_multiarray.TestClip.test_basic) but of course that doesnt
> >> guarantee that other tests might fail after that (and we dont know
> >> now) or that other test starts failing (because of the broken malloc
> >> acting up).
> > 
> > it would probably be best to disable the assert in
> > lowlevel_strided_loops.c.src on powerpc depending cpp macros, that way
> > it will also continue to work when users would want to use python-dbg on
> > ppc if softfaulting is enabled.
> 
> attached a patch

Without testing, that seems reasonable.  Do you want someone to sponsor an 
upload for you or are you waiting for feedback from Sandro?  If the former, 
please turn this into a debdiff or put it in DPMT svn with changelog, etc and I 
can probably sponsor tomorrow if no one else does.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#800392: python-numpy: FTBFS on powerpc due to test failure

[Scott Kitterman]

Source: python-numpy
Version: 1:1.9.2-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Here's the build-log excerpt:

test_basic (test_multiarray.TestChoose) ... ok
test_broadcast1 (test_multiarray.TestChoose) ... ok
test_broadcast2 (test_multiarray.TestChoose) ... ok
test_basic (test_multiarray.TestClip) ... python2.7-dbg: 
numpy/core/src/multiarray/lowlevel_strided_loops.c.src:820: 
_aligned_contig_cast_double_to_longdouble: Assertion `npy_is_aligned(dst, 
__builtin_offsetof (struct {char c; npy_longdouble v;}, v))' failed.
Running unit tests for numpy
NumPy version 1.9.2
NumPy is installed in 
/«PKGBUILDDIR»/debian/tmp/usr/lib/python2.7/dist-packages/numpy
Python version 2.7.10 (default, Sep 13 2015, 20:30:50) [GCC 5.2.1 20150911]
nose version 1.3.6
Aborted
make[1]: *** [override_dh_auto_install] Error 134
debian/rules:147: recipe for target 'override_dh_auto_install' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [binary-arch] Error 2
debian/rules:15: recipe for target 'binary-arch' failed

Seems like this may be related to #702169.

Resolution of this bug will be an issue with making python3.5 the default
python3, so it would be good to get this resolved soon.

Thanks,

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#800239: py3cairo: FTBFS with python3.5 as a supported python3 version

[Scott Kitterman]

Source: py3cairo
Version: 1.10.0+dfsg-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)

py3cairo FTBFS when binNMUed to add support for python3.5.  Here's what
appears to be the relevant bit of the build log:

Checking for library python3.5 in LIBDIR : 06:20:11 runner ['/usr/bin/gcc', 
'-D_FORTIFY_SOURCE=2', '-g', '-O2', '-fstack-protector-strong', '-Wformat', 
'-Werror=format-security', '-pthread', '-fwrapv', '-fstack-protector-strong', 
'-flto', '-fuse-linker-plugin', '-ffat-lto-objects', 
'-DPYTHONDIR="/usr/lib/python3/dist-packages"', 
'-DPYTHONARCHDIR="[\'/usr/lib/python3/dist-packages\']"', '-DNDEBUG', 
'../test.c', '-c', '-o', 'test.c.0.o']
06:20:11 runner ['/usr/bin/gcc', 'test.c.0.o', '-o', 
'/«BUILDDIR»/py3cairo-1.10.0+dfsg/build3.5/.conf_check_48bc0baa924006e4ec070860d537efdb/testbuild/testprog',
 '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib', '-lpython3.5', '-Wl,-z,relro', 
'-Wl,-z,relro', '-pthread', '-Wl,-O1', '-Wl,-Bsymbolic-functions', 
'-Wl,-z,relro']
  ./options()
  ./configure()
Traceback (most recent call last):
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Scripting.py", line 93, in 
waf_entry_point
run_commands()
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Scripting.py", line 145, in 
run_commands
run_command(cmd_name)
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Scripting.py", line 138, in 
run_command
ctx.execute()
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Configure.py", line 124, in 
execute
super(ConfigurationContext,self).execute()
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Context.py", line 87, in execute
self.recurse([os.path.dirname(g_module.root_path)])
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Context.py", line 127, in 
recurse
user_function(self)
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/wscript", line 29, in configure
ctx.check_python_headers()
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Configure.py", line 217, in fun
return f(*k,**kw)
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Tools/python.py", line 146, in 
check_python_headers

result=conf.check(lib=name,uselib='PYEMBED',libpath=path,mandatory=False,msg='Checking
 for library %s in LIBDIR'%name)
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Configure.py", line 217, in fun
return f(*k,**kw)
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Tools/c_config.py", line 357, 
in check
ret=self.run_c_code(*k,**kw)
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Configure.py", line 217, in fun
return f(*k,**kw)
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Tools/c_config.py", line 435, 
in run_c_code
bld.compile()
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Tools/errcheck.py", line 95, in 
check_compile
ret=old_compile(self)
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Build.py", line 190, in compile
self.store()
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Utils.py", line 300, in f
ret=fun(*k,**kw)
  File "/«BUILDDIR»/py3cairo-1.10.0+dfsg/waflib/Build.py", line 164, in store
cPickle.dump(data,f)
AttributeError: Can't pickle local object 'Context.__init__..node_class'

It does look like there is a fix for this in Ubuntu [1].

Scott K

[1] https://launchpad.net/ubuntu/+source/py3cairo/1.10.0+dfsg-4ubuntu2

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#789670: NMU diff

[Scott Kitterman]

I intend to upload the attached shortly.  While NMU of a new upstream release
isn't normal, it does, in this case, solve an RC bug, so I think it's a
reasonable way to proceed.

Scott Kdiff -Nru python-pies-2.6.1/debian/changelog python-pies-2.6.7/debian/changelog
--- python-pies-2.6.1/debian/changelog	2014-05-21 05:47:42.0 -0400
+++ python-pies-2.6.7/debian/changelog	2015-09-25 23:22:38.0 -0400
@@ -1,3 +1,22 @@
+python-pies (2.6.7-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release (Closes: #773923)
+- Solves configparser conflict (Closes: #751375)
+- Rebuild with python3.4 drops python3-enum34 Depends (Closes: #796909)
+  * Install python-pies2overrides in /usr/lib/python2.7/dist-packages
+directly rather than install in /usr/pyshared and symlinking since
+pyshared is no longer used
+  * Remove removal of /usr/lib/python3.4 from debian/rules since it
+produced an empty python3 package (Closes: #770261)
+  * Do not install pies2overrides/xmlrpc sincie it conflicts with
+python-futures and is not used in the Debian archive (Closes: #789670)
+  * Manually add python-pies depends on pies2overrides and enum34
+  * Add the actual upstream github location to debian/watch since the
+redirector is down
+
+ -- Scott Kitterman <sc...@kitterman.com>  Fri, 25 Sep 2015 22:10:08 -0400
+
 python-pies (2.6.1-1) unstable; urgency=low

   * Initial release (Closes: #739115)
diff -Nru python-pies-2.6.1/debian/control python-pies-2.6.7/debian/control
--- python-pies-2.6.1/debian/control	2014-05-20 11:17:15.0 -0400
+++ python-pies-2.6.7/debian/control	2015-09-25 22:58:59.0 -0400
@@ -19,7 +19,7 @@

 Package: python-pies
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
+Depends: ${misc:Depends}, ${python:Depends}, python-pies2overrides, python-enum34
 Description: compatibility layer for Python 2 and 3 (Python 2 interface)
  Pies is a Python 2 and 3 compatibility layer with the philosophy that all
  code should be Python 3 code. Starting from this viewpoint means that
diff -Nru python-pies-2.6.1/debian/rules python-pies-2.6.7/debian/rules
--- python-pies-2.6.1/debian/rules	2014-05-20 10:16:18.0 -0400
+++ python-pies-2.6.7/debian/rules	2015-09-25 22:53:49.0 -0400
@@ -12,15 +12,13 @@

 override_dh_auto_install:
 	dh_auto_install -O--buildsystem=pybuild
-	# remove rampant egg PKG-INFO
-	rm -rf debian/python3-pies/usr/lib/python3.4
 	# manual install of pies2overrides because dh_python2 can't handle two
 	# packages, and pyinstall can't install to empty namespace
-	$(foreach dir,html http xmlrpc,$(shell mkdir -p $(PIES2OVERRIDES_PKG)/usr/share/pyshared/$(dir)))
+	$(foreach dir,html http xmlrpc,$(shell mkdir -p $(PIES2OVERRIDES_PKG)/usr/lib/python2.7/dist-packages/$(dir)))
 	for file in $$(tail -n+2 pies2overrides/MANIFEST | grep -v setup.py); do \
 		cp pies2overrides/$$file \
-			$(PIES2OVERRIDES_PKG)/usr/share/pyshared/$$file; \
-		dh_link -ppython-pies2overrides \
-			usr/share/pyshared/$$file \
-			usr/lib/python2.7/dist-packages/$$file; \
+			$(PIES2OVERRIDES_PKG)/usr/lib/python2.7/dist-packages/$$file; \
 	done
+	# Don't install xmlrpc since it conflicts with python-future and is
+	# not used by anything in the archive
+	rm -rf $(PIES2OVERRIDES_PKG)/usr/lib/python2.7/dist-packages/xmlrpc
diff -Nru python-pies-2.6.1/debian/watch python-pies-2.6.7/debian/watch
--- python-pies-2.6.1/debian/watch	2014-02-15 19:08:22.0 -0500
+++ python-pies-2.6.7/debian/watch	2015-09-25 20:54:38.0 -0400
@@ -1,2 +1,4 @@
 version=3
+opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/pies-$1\.tar\.gz/ \
+  https://github.com/timothycrosley/pies/tags .*/v?(\d\S*)\.tar\.gz
 http://githubredir.debian.net/github/timothycrosley/pies/ ([\d\.]+)\.tar\.gz
diff -Nru python-pies-2.6.1/.env python-pies-2.6.7/.env
--- python-pies-2.6.1/.env	2014-02-24 05:57:40.0 -0500
+++ python-pies-2.6.7/.env	2015-07-12 03:34:45.0 -0400
@@ -37,9 +37,11 @@
 root
 sudo rm -rf dist build
 python setup.py sdist upload
+python setup.py bdist_wheel upload
 overrides
 sudo rm -rf dist build
 python setup.py sdist upload
+python setup.py bdist_wheel upload
 }

 function _leave_project()
diff -Nru python-pies-2.6.1/.gitignore python-pies-2.6.7/.gitignore
--- python-pies-2.6.1/.gitignore	1969-12-31 19:00:00.0 -0500
+++ python-pies-2.6.7/.gitignore	2015-07-12 03:34:45.0 -0400
@@ -0,0 +1,57 @@
+*.py[cod]
+.DS_Store
+# C extensions
+*.so
+
+# Packages
+*.egg
+*.egg-info
+build
+eggs
+parts
+var
+sdist
+develop-eggs
+.installed.cfg
+lib
+lib64
+MANIFEST
+
+# Installer logs
+pip-log.txt
+npm-debug.log
+
+# Unit test / coverage reports
+.coverage
+.tox
+nosetests.xml
+htmlcov
+.cache
+
+# Translations
+*.mo
+
+# Mr Developer
+.mr.developer.cfg
+.project
+.pydevproject
+
+# SQLite
+test_exp_framework
+
+# npm
+node_modules/
+
+# dolphin
+.directory
+libpeerconnection.log
+
+# setuptools

[Python-modules-team] Bug#799725: Bug#799725: Please remove alternate build deps for gstreamer 0.10

[Scott Kitterman]

On September 21, 2015 4:42:13 PM EDT, Vincent Cheng  wrote:
>On Mon, Sep 21, 2015 at 1:31 PM, Moritz Muehlenhoff 
>wrote:
>> Source: kivy
>> Severity: normal
>>
>> Hi,
>> kivy is using gstreamer 1.0, but still has alternate build-deps/deps
>> on gstreamer 0.10:
>>
>> libgstreamer0.10-dev
>> python-gst0.10
>>
>> Please remove these, gstreamer 0.10 is scheduled for removal from
>> the archive.
>
>Is it not possible to keep these alternate build-deps in d/control to
>e.g. ease backporting? My understanding is that the dependency
>resolver that buildds use will only look at the first build-dep and
>disregard alternate build-deps.

As long as whoever files that rm bugs mentions these are alternates, it 
shouldn't delay removal of the obsolete packages.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#799559: Bug#799559: python-pip: Recommends non-existing package python-dev-all

[Scott Kitterman]

On September 20, 2015 7:03:05 AM EDT, Hans Joachim Desserud 
 wrote:
>Package: python-pip
>Version: 1.5.6-7
>Tags: patch
>Severity: minor
>
>Dear maintainer,
>
>python-pip recommends the package python-dev-all which doesn't seem to 
>exist [1].
>The attached patch removes this suggestion.

I'm pretty sure they meant python-all-dev which does exist and is a reasonable 
suggestion.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-qt4 depends on qt5 ??

[Scott Kitterman]

On September 20, 2015 4:44:34 AM EDT, "Antonio Sánchez"  
wrote:
>Hi, I'm trying to update from python-qt4 4.10.3-2 (from old jessie) to
>python-qt4 4.11.2 (current version in jessie) and APT wants to install
>75Mb
>in libqt5 and pyqt5 dependences O_O!
>
>Is it normal?

Not what I would expect.  What exactly are you doing and what packages does it 
want to install/update?

Scott K
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#789670: Dropping python-pies2overrides

[Scott Kitterman]

On Fri, 18 Sep 2015 22:29:03 + Tristan Seligmann  
wrote:
> Since frosted is the only reverse dep of python-pies, and it can use
> python3-pies instead, how about just dropping
> python-pies/python-pies2overrides completely?

It doesn't look like frosted uses the xmlrpc override, so even simpler would 
be just to remove the xmlrpc override (since frosted does use others).  Then 
the change would be confined to python-pies2-overrides.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#789670: Your mail

[Scott Kitterman]

On Fri, 18 Sep 2015 15:37:35 -0400 Barry Warsaw  wrote:
> I think the best we can do is add a Conflicts between the two packages.  The
> contents of the conflicting directories are different.  Personally, I think
> it's a bug that the two upstreams install these into the top-level 
namespace,
> but given the nature of the packages, I can see why they did it this way.
> 
> I'll upload a Conflicts for future and will begin the NMU for python-pies.

As I discussed with Barry on IRC, I think this situation is a naming conflict 
that falls within the scope of policy 10.1.  While the specific files may 
provide the same/similar functionality, the packages do not so Conflicts or 
Update Alternatives are not appropriate solutions.

We did do a bit of investigation and it does not seem to me that 
renaming/moving the python-futures files is feasible.  The point of the package 
is to provide things like this generally.  Python-pies has a small rdpends set 
so I think moving the duplicated files in it is more tractable and makes more 
sense.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#799182: python3-billiard: Python3-billiard arch any without arch specific content

[Scott Kitterman]

Source: billiard
Version: 3.3.0.20-1
Severity: normal
Tags: patch

Since billiard build-depends on python3-all-dev it shows up on the list of
packages needing rebuilding for the transition [1], but examination of
python3-billiard shows it does not contain the compiled extension because
setup.py explicitly disables it.  As a result, python3-billiard should be
arch all and not depend on python3-all-dev.

Please consider the attached patch as it will ease the management of this
transition.  Note that while I used an NMU style for the debian/changelog in
the patch, I have no intent to NMU for this.

Also, the patch resolves a build-log warning by adding a direct build-dep on
dh-python (while I was there).

Scott K

[1] https://release.debian.org/transitions/html/python3.5.html
diff -Nru billiard-3.3.0.20/debian/changelog billiard-3.3.0.20/debian/changelog
--- billiard-3.3.0.20/debian/changelog	2015-05-19 08:32:11.0 -0400
+++ billiard-3.3.0.20/debian/changelog	2015-09-16 11:11:13.0 -0400
@@ -1,3 +1,12 @@
+billiard (3.3.0.20-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert python3-billiard from arch any to arch all since binary extension
+builds are disabled for ptyhon3 and adjust build-depends accordingly
+  * Add dh-python to build-depends to ensure the most recent version is used
+
+ -- Scott Kitterman <sc...@kitterman.com>  Wed, 16 Sep 2015 11:10:00 -0400
+
 billiard (3.3.0.20-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru billiard-3.3.0.20/debian/control billiard-3.3.0.20/debian/control
--- billiard-3.3.0.20/debian/control	2015-05-19 01:45:20.0 -0400
+++ billiard-3.3.0.20/debian/control	2015-09-16 11:09:56.0 -0400
@@ -6,13 +6,14 @@
Thomas Bechtold <thomasbecht...@jpberlin.de>,
Brian May <b...@debian.org>,
 Build-Depends: debhelper (>= 9),
+   dh-python,
python-all-dev,
python-mock,
python-nose,
python-setuptools,
python-sphinx (>= 1.0.7+dfsg-1~),
python-unittest2,
-   python3-all-dev,
+   python3-all,
python3-mock,
python3-nose,
python3-setuptools,
@@ -34,8 +35,8 @@
  that can grow in size.
 
 Package: python3-billiard
-Architecture: any
-Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
+Architecture: all
+Depends: ${misc:Depends}, ${python3:Depends}
 Suggests: python-billiard-doc
 Description: Multiprocessing Pool Extensions for Python (Python3 version)
  This package contains extensions to the multiprocessing Pool.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#799185: dulwich: Proper depends for python3 package not provided

[Scott Kitterman]

Source: dulwich
Version: 0.11.1-1
Severity: serious
Tags: patch
Justification: Policy 3.5

Unfortunately, dulwich uses python:Depands instead of python3:Depends for its
python3 package.  The attached patch resolves this as well as cleaning up
obsolete provides.

Note that this error, in addition to being an RC bug, makes it harder to
track the upcoming python3.5 transition [1].

Scott K

[1] https://release.debian.org/transitions/html/python3.5.html
diff -ruN dulwich/debian/changelog dulwich-0.11.1/debian/changelog
--- dulwich/debian/changelog	2015-09-16 11:42:36.339210393 -0400
+++ dulwich-0.11.1/debian/changelog	2015-09-16 11:44:25.711211825 -0400
@@ -1,3 +1,11 @@
+dulwich (0.11.1-2) unstable; urgency=medium
+
+  * Team upload.
+  * Fix python3 depends
+  * Remove obsolete provides
+
+ -- Scott Kitterman <sc...@kitterman.com>  Wed, 16 Sep 2015 11:31:00 -0400
+
 dulwich (0.11.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -ruN dulwich/debian/control dulwich-0.11.1/debian/control
--- dulwich/debian/control	2015-09-16 11:42:36.339210393 -0400
+++ dulwich-0.11.1/debian/control	2015-09-16 11:32:27.335202422 -0400
@@ -14,7 +14,6 @@
 
 Package: python-dulwich
 Architecture: any
-Provides: ${python:Provides}
 Depends: ${python:Depends}, ${misc:Depends}, ${shlibs:Depends}
 Breaks: bzr-git (<< 0.6.2)
 Suggests: python-dulwich-dbg
@@ -36,7 +35,6 @@
 Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}, python-dbg, python-dulwich (= ${binary:Version})
 Priority: extra
 Section: debug
-Provides: ${python:Provides}
 Description: Python Git library - Debug Extension
  Dulwich is a Python implementation of the file formats and protocols
  used by the Git version control system. It can currently read from and write
@@ -67,10 +65,9 @@
 
 Package: python3-dulwich
 Architecture: any
-Provides: ${python:Provides}
-Depends: ${python:Depends}, ${misc:Depends}, ${shlibs:Depends}
+Depends: ${python3:Depends}, ${misc:Depends}, ${shlibs:Depends}
 Breaks: bzr-git (<< 0.6.2)
-Suggests: python-dulwich-dbg
+Suggests: python3-dulwich-dbg
 Description: Python Git library - Python3 module
  Dulwich is a Python implementation of the file formats and protocols
  used by the Git version control system. It can currently read from and write
@@ -85,10 +82,9 @@
 
 Package: python3-dulwich-dbg
 Architecture: any
-Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}, python3-dbg, python3-dulwich (= ${binary:Version})
+Depends: ${misc:Depends}, ${shlibs:Depends}, python3-dbg, python3-dulwich (= ${binary:Version})
 Priority: extra
 Section: debug
-Provides: ${python:Provides}
 Description: Python Git library - Python 3 Debug Extension
  Dulwich is a Python implementation of the file formats and protocols
  used by the Git version control system. It can currently read from and write
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#798010: Bug#798010: ipython3: malicious dynamic python3 interpreter lookup via "/usr/bin/env python3" in main executable

[Scott Kitterman]

On Friday, September 04, 2015 02:30:47 PM Tobias Megies wrote:
> Package: ipython3
> Version: 2.3.0-2
> Severity: serious
> Justification: Debian Python Policy 2.4.2: Interpreter Location
> 
> Dear Maintainer,
> 
> the main executable /usr/bin/ipython3 has shebang line 1 "#!/usr/bin/env
> python3" and thus uses the first python3 interpreter found in $PATH doing a
> dynamic lookup at execution time.
> If a local user-space Python environment is coming first in $PATH it will
> thus yield the Python3 IPython prompt from user space and not from the
> system python. This will result in very puzzling situation and clearly is
> in violation of the Debian Python Policy which demands the hardcoded system
> python binary in shebang.
> 
> See Debian Python Policy 2.4.2 Interpreter location:
> https://www.debian.org/doc/packaging-manuals/python-policy/ch-> 
> python.html#s-interpreter_loc
> 
> === quote start
> The preferred specification for the Python interpreter is /usr/bin/python or
> /usr/bin/pythonX.Y. This ensures that a Debian installation of python is
> used and all dependencies on additional python modules are met.
> Maintainers should not override the Debian Python interpreter using
> /usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it
> bypasses Debian's dependency checking and makes the package vulnerable to
> incomplete local installations of python.
> === quote end

First, Python policy is not Debian policy, so violating it doesn't 
automatically make a serious bug.  Second, the policy says preferred and 
should quite deliberately as the /usr/bin/env approach is quite common in the 
Python world and we do not want to force maintainers to patch large numbers of 
packages to avoid it.

Scott K

signature.asc
Description: This is a digitally signed message part.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] [Bug 1482844] Re: Caffeine can't connect to display since updating to Vivid kernel and X (HWE)

[Scott Kitterman]

Dear whoever subscribed the Debian Python Modules Team to this bug:

Please don't do such a thing again.  If there is a bug that's also
present in Debian, please file a bug in the Debian BTS and then link it
to the Ubuntu bug.

-- 
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1482844

Title:
  Caffeine can't connect to display since updating to Vivid kernel and X
  (HWE)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-xlib/+bug/1482844/+subscriptions

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Request to join Debian Python Modules Team

[Scott Kitterman]

Done.

Scott K

On Wednesday, July 01, 2015 01:21:50 PM Sandro Tosi wrote:
 Can someone approve this request plz? He's working with me to get
 python-tabulate in debian and DPMT. thanks already
 
 On Tue, Jun 30, 2015 at 8:16 PM, ChangZhuo Chen (陳昌倬) czc...@gmail.com 
wrote:
  Hi.
  
  I request to join Debian Python Modules Team for the package
  python-tabulate [0]. My Alioth account is czchen-guest.
  
  [0] http://bugs.debian.org/782140
  --
  ChangZhuo Chen (陳昌倬) czc...@gmail.com
  http://czchen.info/
  Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D
  
  ___
  Python-modules-team mailing list
  Python-modules-team@lists.alioth.debian.org
  http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-tea
  m


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#768194: [python-psycopg2] extensions.ISOLATION_LEVEL_AUTOCOMMIT should disappear

[Scott Kitterman]

On Wednesday, November 05, 2014 10:10:52 PM B wrote:
 Package: python-psycopg2
 Version: 2.5.4+dfsg-1
 Severity: normal
 
 --- Please enter the report below this line. ---
 
 Ho folks,
 
 Or at the very least, doc should clearly state that it MUST NOT
 be used into 'set_session()')'.
 
 Because issuing:
 connection.set_session(psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT,
 readonly=True, deferrable=False, autocommit=True)
 
 fails with the following message:
 ValueError: isolation_level must be between 1 and 4
 (œuf corse, as psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT == 0)

Fixed upstream by improving the documentation in this commit:

https://github.com/psycopg/psycopg2/commit/f27ca25d2e1cf2236444ecad9cf6eafb01efb77e

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#789390: Bug#789390: pyclamd: please update the package to 0.3.15

[Scott Kitterman]

On Saturday, June 20, 2015 12:22:49 PM Gianfranco Costamagna wrote:
...
 Hi, since I'm in an ongoing effort to package w3af for Debian (an updated
 version), I would like to have the last version of pyclamd (actually w3af
 uses python-clamd, I asked upstream to switch to pyclamd).
 
 thanks a lot for the effort,
 
 I did a quick review for the package and I found some minor improvements I'm
 attaching to this email.
...
They all look good.  I'll incorporate them and some other changes and upload 
shortly.  It seems you missed adding python-setuptools and python3-setuptools 
to the build-depends.  That indicates to me you aren't testing your packages 
in a clean environment.  In this case it's not a big deal, since I do, but for 
future reference it's a good practice to do so to detect exactly this kind of 
issue.

Thank you for your contribution.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] PyPi watch line broken at least in python-requests

[Scott Kitterman]

On Tuesday, May 05, 2015 10:43:07 AM Jaroslav Benkovský wrote:
 Hi,
 
 Vivid package for python-requests:
  uscan --report
 
 uscan warning: In debian/watch,
   no matching hrefs for watch line
   http://pypi.python.org/packages/source/r/requests/requests-(.*)\.tar\.gz
 
 
 Looks like  PyPi returns an empty page for a requests for
 http://pypi.python.org/packages/source/r/requests/ .
 
 Perhaps it's a configuration change on PyPi's side? Maybe other packages
 are affected as well ...

Works fine on one of my packages I checked:

$ uscan --verbose
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
   opts=uversionmangle=s/(rc|a|b|c)/~$1/ 
http://pypi.debian.net/pysubnettree/pysubnettree-(.+)\.(?:zip|tgz|tbz|txz|
(?:tar\.(?:gz|bz2|xz)))
-- Found the following matching hrefs:
 /pysubnettree/pysubnettree-0.22.tar.gz (0.22)
 /pysubnettree/pysubnettree-0.23.tar.gz (0.23)
Newest version on remote site is 0.23, local version is 0.23
 = Package is up to date
-- Scan finished

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#783390: pymodbus: Debian/copyright has wrong license

[Scott Kitterman]

Source: pymodbus
Version: 1.2.0-2
Severity: serious
Justification: Policy 4.5

Dear Maintainer,

The debian/copyright file lists MIT as the upstream license, but the only
references in the code are to BSD.  From setup.py in 1.2.0-2:

License :: OSI Approved :: BSD License

In the version in New that I'm reviewing for experimental, there are
additional references to BSD as well as the full text in doc/LICENSE.

Since this is a pre-existing issue with the package, I'm not rejecting due to
the issue, but it should be fixed ASAP.  Additionally, pymodbus/__init__.py
says:

TwistedModbus is built on top of the code developed by:

Copyright (c) 2001-2005 S.W.A.C. GmbH, Germany.
Copyright (c) 2001-2005 S.W.A.C. Bohemia s.r.o., Czech Republic.
Hynek Petrak hy...@swac.cz

Released under the the BSD license

These should probably be mentioned in debian/copyright as well.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Comments regarding pymodbus_1.2.0+git20150104-1_amd64.changes

[Scott Kitterman]

Please see the serious bug I just filed (#783390) regarding issues with
debian/copyright.

The package includes a PDF which is not rebuilt (or shipped).  Since it
appears that it could be rebuilt, this is presumably OK, but you should
check to make sure even though it's only in the source tarball.  The
tarball has to have preferred form of modification available.

Please remove the Python/Python3 provides.  For python they are largely
obsolete and should only be used if there is a package directly depending
on the versioned provided package.  Since we're down to python2.7, that should
never happen.  If there is an rdepend that needs it (I didn't check), please
have the depend on the non-versioned package.  For python3, we don't use the
provides at all.

Scott K



___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#779871: python-awsauth, python-requests-aws, python3-awsauth, python3-requests-aws: error when trying to install together

[Scott Kitterman]

On Thursday, March 05, 2015 08:14:35 PM Andreas Beckmann wrote:
 Package:
 python-awsauth,python-requests-aws,python3-awsauth,python3-requests-aws
 Version: 0.1.6-1
 Severity: serious
 User: trei...@debian.org
 Usertags: edos-file-overwrite
 
 Architecture: amd64
 Distribution: sid

src:python-requests-aws and src:requests-aws are the same upstream package.  
src:requests-aws was there first and is in both Jessie and Sid, so I'll remove 
src:python-requests-aws.

Scott K

signature.asc
Description: This is a digitally signed message part.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#779369: pyqt5-examples missing dependencies python3-pyqt5.{qtquick, qtopengl, qtmultimedia, qtsvg} etc.

[Scott Kitterman]

On Friday, February 27, 2015 07:43:08 PM Chris Bainbridge wrote:
 Package: pyqt5-examples
 Version: 5.3.2+dfsg-3
 Severity: normal
 
 Dear Maintainer,
 
 pyqt5-examples should depend on all the libraries necessary to run the
 examples.

...

We've discussed this a bit and don't really agree with the premise.  The 
examples are provided as part of the documentation that goes with PyQt5 and 
are not really meant to be executed without further consideration.

PyQt5 is split into multiple binaries to allow systems to only have the parts 
of PyQt5 and Qt5 installed that are needed.  If the examples package had a 
dependency (or recommends) on everything that was needed to run every example, 
then to look at any example, it might be needed to install many extra 
dependencies that aren't relevant to the example a person is interested in.

We do agree that we ought to document what packages are needed to run the 
examples as package suggests.  That would make it easy for someone who wants 
to run the examples to install all the needed packages while still not 
requiring it for everyone.

Scott K

signature.asc
Description: This is a digitally signed message part.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#779369: pyqt5-examples missing dependencies python3-pyqt5.{qtquick, qtopengl, qtmultimedia, qtsvg} etc.

[Scott Kitterman]

On Sunday, March 01, 2015 08:39:53 PM Chris Bainbridge wrote:
 On 1 March 2015 at 17:21, Scott Kitterman deb...@kitterman.com wrote:
  On Friday, February 27, 2015 07:43:08 PM Chris Bainbridge wrote:
   Package: pyqt5-examples
   Version: 5.3.2+dfsg-3
   Severity: normal
   
   Dear Maintainer,
   
   pyqt5-examples should depend on all the libraries necessary to run the
   examples.
  
  ...
  
  We've discussed this a bit and don't really agree with the premise.  The
  examples are provided as part of the documentation that goes with PyQt5
  and  are not really meant to be executed without further consideration.
 
 Is this consistent with other -examples packages in Debian? Afaics the
 qt*5-example packages all have proper dependencies and are executable
 after installation, as are qt4-demos, and non-executable examples are
 usually put in a -doc package (like python-qt4-doc).

It's more complicated than that.  If we were going to make the examples 
executable based on depends, we'd have to provide both python and python3 
versions and split them into sub-packages to keep from pulling in excessive 
dependencies.  For this package, it doesn't seem like a reasonable thing to 
do.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#772815: Bug#772815: Bug#772815: Bug#772815: pyyaml: CVE-2014-9130

[Scott Kitterman]

On Friday, December 12, 2014 08:17:17 AM Scott Kitterman wrote:
 On Friday, December 12, 2014 07:33:25 AM Salvatore Bonaccorso wrote:
  Hi Scott,
  
  On Thu, Dec 11, 2014 at 07:09:11AM -0500, Scott Kitterman wrote:
   On December 11, 2014 6:37:51 AM EST, Moritz Muehlenhoff j...@inutil.org
 
 wrote:
   Package: pyyaml
   Severity: grave
   Tags: security
   
   Hi,
   CVE-2014-9130 from libyaml also affects pyyaml. I'm attaching a short
   reproducer.
   
   I'm away from any computer I could test this on today.
   
   Is this still a problem with a fixed libyaml?   Our pyyaml is built
   against it and I thought didn't use the internal parser.
  
  It seems so, and there was some discussion on the oss-security list
  (also about if this should get a separate CVE for pyyaml)[0].
  
   [0] http://www.openwall.com/lists/oss-security/2014/11/28/8
  
  On up-to-date unstable the reproducer gives:
  
  Traceback (most recent call last):
File CVE-2014-9130.py, line 5, in module
...
  
  save_possible_simple_key assert self.allow_simple_key or not required
  AssertionError
 
 In fact, there's an upstream commit to address it now:
 
 https://bitbucket.org/xi/pyyaml/commits/ddf211a41bb231c365fece5599b7e484e6dc
 33fc
 
 I'm happy to prepare an unstable update.  Do you know if it's decided if
 this gets a separate CVE number or not?
 
 Scott K

Confirmed that with the upstream fix the assert is resolved and it's a regular 
error now:

Traceback (most recent call last):
  File CVE-2014-9130.py, line 5, in module
foo = yaml.load(stream)
  File /usr/lib/python3/dist-packages/yaml/__init__.py, line 72, in load
return loader.get_single_data()
  File /usr/lib/python3/dist-packages/yaml/constructor.py, line 35, in 
get_single_data
node = self.get_single_node()
  File /usr/lib/python3/dist-packages/yaml/composer.py, line 36, in 
get_single_node
document = self.compose_document()
  File /usr/lib/python3/dist-packages/yaml/composer.py, line 55, in 
compose_document
node = self.compose_node(None, None)
  File /usr/lib/python3/dist-packages/yaml/composer.py, line 84, in 
compose_node
node = self.compose_mapping_node(anchor)
  File /usr/lib/python3/dist-packages/yaml/composer.py, line 133, in 
compose_mapping_node
item_value = self.compose_node(node, item_key)
  File /usr/lib/python3/dist-packages/yaml/composer.py, line 84, in 
compose_node
node = self.compose_mapping_node(anchor)
  File /usr/lib/python3/dist-packages/yaml/composer.py, line 127, in 
compose_mapping_node
while not self.check_event(MappingEndEvent):
  File /usr/lib/python3/dist-packages/yaml/parser.py, line 98, in 
check_event
self.current_event = self.state()
  File /usr/lib/python3/dist-packages/yaml/parser.py, line 439, in 
parse_block_mapping_key
expected block end, but found %r % token.id, token.start_mark)
yaml.parser.ParserError: while parsing a block mapping
  in CVE-2014-9130.yaml, line 2, column 4
expected block end, but found 'scalar'
  in CVE-2014-9130.yaml, line 3, column 4

I'll upload to unstable shortly.  If the CVE number changes, I guess we'll 
clean up the paperwork when/if it does.

Scott K

signature.asc
Description: This is a digitally signed message part.
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#772815: Bug#772815: pyyaml: CVE-2014-9130

[Scott Kitterman]

On December 11, 2014 6:37:51 AM EST, Moritz Muehlenhoff j...@inutil.org wrote:
Package: pyyaml
Severity: grave
Tags: security

Hi,
CVE-2014-9130 from libyaml also affects pyyaml. I'm attaching a short
reproducer.

I'm away from any computer I could test this on today. 

Is this still a problem with a fixed libyaml?   Our pyyaml is built against it 
and I thought didn't use the internal parser. 

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#771794: Bug#771794: pip silently removes/updates system provided python packages

[Scott Kitterman]

Based on discussions on IRC, we have a patch for pip 6.0 that I've backported 
to the Debian packaged version.  I believe it does the right thing now:

# pip install requests   
Requirement already satisfied (use --upgrade to upgrade): requests in 
/usr/lib/python2.7/dist-packages
Cleaning up...
# pip install requests --upgrade 
Downloading/unpacking requests from 
https://pypi.python.org/packages/py2.py3/r/requests/requests-2.5.0-py2.py3-none-any.whl#md5=9d29a8a0210c236d9329bed49277b3fa
  Downloading requests-2.5.0-py2.py3-none-any.whl (464kB): 464kB downloaded
Installing collected packages: requests
  Found existing installation: requests 2.4.3
Not uninstalling requests at /usr/lib/python2.7/dist-packages, owned by OS
Successfully installed requests
Cleaning up...

I'll double check this, but I think we have a winner.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#771794: pip silently removes/updates system provided python packages

[Scott Kitterman]

On Tuesday, December 02, 2014 12:37:40 PM Donald Stufft wrote:
  On Dec 2, 2014, at 12:25 PM, Daniel Kahn Gillmor d...@fifthhorseman.net
  wrote: 
  On 12/02/2014 11:51 AM, Donald Stufft wrote:
  I'd very much prefer it if you didn't do this. This *is* going to break
  things for people and it's going to cause a bunch of confusion.
  
  It's not clear to me which side you're arguing for.  can you clarify
  which action is going to break things for people and cause a bunch of
  confusion?
  
  If pip silently removes/updates system-provided python packages, that is
  likely to break things and cause a bunch of confusion, no?
  
  alternately, if pip verbosely refuses to run as uid 0, that's at least a
  non-silent failure. (though it certainly will break things and frustrate
  some people)
  
  --dkg
 
 I’m saying don’t make the change. There are major software systems that
 rely on the ability to install things as root using pip. Chef, puppet, etc.
 
 It’s also going to cause a bunch of confusion because all of a sudden pip
 is going to have a vastly different behavior if it’s running on Debian vs
 if it’s running somewhere else. That’s going to blow back on us (the pip
 maintainers) as we get bug reports from people who assume we broke their
 use cases for pip.
 
 We (pip maintainers) recognize this can cause issues and we’d like to
 arrive a solution that solves this issue without introducing major
 divergence between various platforms and with respect towards the use cases
 that need or require that ability. It’s somewhat of a thorny problems to do
 it correctly, we’re a fairly small team with limited time, and we have
 bigger issues of concern that have taken a front seat.

In the meantime, we have a release to get out the door, so wait for upstream 
to figure it out in TBD timeframe isn't a particularly palatable option.

As package maintainers, I think we have a limited set of options available:

1.  Do nothing for now.  Maybe upstream figures out something in time to get a 
fix in for Jessie.  Maybe the release team decides to ignore the bug for 
Jessie.  Maybe the release team removes pip for Jessie.

2.  Disable root/system use.

3.  Make install as --user default and require some suitable named option for 
root/system install.

4.  Install as root by default if permissions allow, but default to --user if 
not instead of just erroring out.

As upstream, do you have a preference if it's not #1?  Are there other options 
that would be better?

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#771794: pip silently removes/updates system provided python packages

[Scott Kitterman]

On Tuesday, December 02, 2014 04:15:05 PM Donald Stufft wrote:
...
 I have another question. If we fix this in the upcoming pip 6 release what
 is the chances of getting an exception for pip 6 in the freeze? If I can
 solve the problem in pip proper and keep the delta between different
 platforms smaller I can juggle around priorities and push the other big
 ticket thing I was working on till another release.
...
The deadline for getting Important (i.e. not Serious/Grave/Critical) bug fixes 
unblocked for Jessie is December 5th (that's uploaded to Debian and the 
release team has reviewed and unblocked it).

Unless the next release is ~nothing but fixes for important/release critical 
bugs, the chance is approximately zero.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#771794: pip silently removes/updates system provided python packages

[Scott Kitterman]

On Tuesday, December 02, 2014 04:54:37 PM Donald Stufft wrote:
  On Dec 2, 2014, at 4:47 PM, Scott Kitterman deb...@kitterman.com wrote:
  
  On Tuesday, December 02, 2014 04:15:05 PM Donald Stufft wrote:
  ...
  
  I have another question. If we fix this in the upcoming pip 6 release
  what
  is the chances of getting an exception for pip 6 in the freeze? If I can
  solve the problem in pip proper and keep the delta between different
  platforms smaller I can juggle around priorities and push the other big
  ticket thing I was working on till another release.
  
  ...
  The deadline for getting Important (i.e. not Serious/Grave/Critical) bug
  fixes unblocked for Jessie is December 5th (that's uploaded to Debian and
  the release team has reviewed and unblocked it).
  
  Unless the next release is ~nothing but fixes for important/release
  critical bugs, the chance is approximately zero.
  
  Scott K
 
 This bug is marked “Serious” right? So if I understand correctly a new
 version isn’t acceptable, even to fix a Serious issue, unless it only fixes
 items that are allowed within whatever phase the release process is in?

A new release would be acceptable if it only fixed release critical stuff.  The 
problem comes in where a new release fixes something serious and other stuff.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#771794: pip silently removes/updates system provided python packages

[Scott Kitterman]

On Tuesday, December 02, 2014 05:17:48 PM Donald Stufft wrote:
  On Dec 2, 2014, at 5:03 PM, Scott Kitterman deb...@kitterman.com wrote:
  
  On Tuesday, December 02, 2014 04:54:37 PM Donald Stufft wrote:
  On Dec 2, 2014, at 4:47 PM, Scott Kitterman deb...@kitterman.com
  wrote:
  
  On Tuesday, December 02, 2014 04:15:05 PM Donald Stufft wrote:
  ...
  
  I have another question. If we fix this in the upcoming pip 6 release
  what
  is the chances of getting an exception for pip 6 in the freeze? If I
  can
  solve the problem in pip proper and keep the delta between different
  platforms smaller I can juggle around priorities and push the other big
  ticket thing I was working on till another release.
  
  ...
  The deadline for getting Important (i.e. not Serious/Grave/Critical) bug
  fixes unblocked for Jessie is December 5th (that's uploaded to Debian
  and
  the release team has reviewed and unblocked it).
  
  Unless the next release is ~nothing but fixes for important/release
  critical bugs, the chance is approximately zero.
  
  Scott K
  
  This bug is marked “Serious” right? So if I understand correctly a new
  version isn’t acceptable, even to fix a Serious issue, unless it only
  fixes
  items that are allowed within whatever phase the release process is in?
  
  A new release would be acceptable if it only fixed release critical stuff.
   The problem comes in where a new release fixes something serious and
  other stuff.
  
  Scott K
 
 Ok, so anything from upstream will need to be backported to 1.5.x then,
 which might be a pain but I don’t think undoable. We reorganized some stuff
 but it shouldn’t be impossible.
 
 Would a patch for this issue need to be done and uploaded and unblocked by
 the Dec 5th? Or Since it’s a “Serious” issue is there a longer deadline?
 
 What’s the chances of accepting the status quo for Jessie and having an
 upstream fix in Jessie+1? This isn’t a *new* problem, it exists in stable
 and oldstable as well and it wasn’t unknown to be a problem previously
 (there’s another ticket about making —user the default in BTS which
 references this fact over a year ago). I’m not sure what would make it all
 of a sudden a dire problem in Jesse, so if we can wait till Jesse+1 and I
 can get a stakeholder to sit down with me and sort out what a solution
 *needs* from the Debian side of things I can make sure a fix does land in
 the next pip release which will be out far in advance of Jessie+1.

Assuming the maintainer doesn't decide to downgrade the bug (which I think is 
unlikely and a number of people would object to, so I think we can ignore it 
as a possibility), the decision to ignore the bug for Jessie belongs with the 
release team.  If we choose not to fix it (and there's no Non-Maintainer 
Upload), then they will decide to either remove the package or ignore the bug.

Since this particular issue is release critical, the December 5th deadline 
isn't relevant to a targeted fix just for this issue.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#771794: pip silently removes/updates system provided python packages

[Scott Kitterman]

On Tuesday, December 02, 2014 19:28:20 Donald Stufft wrote:
  On Dec 2, 2014, at 6:32 PM, Scott Kitterman deb...@kitterman.com wrote:
  
  Assuming the maintainer doesn't decide to downgrade the bug (which I think
  is unlikely and a number of people would object to, so I think we can
  ignore it as a possibility), the decision to ignore the bug for Jessie
  belongs with the release team.  If we choose not to fix it (and there's
  no Non-Maintainer Upload), then they will decide to either remove the
  package or ignore the bug.
  
  Since this particular issue is release critical, the December 5th deadline
  isn't relevant to a targeted fix just for this issue.
  
  Scott K
 
 So the issue here is that pip is removing apt “owned” files implicitly
 during an upgrade right? Looking at easy_install there’s no Serious bug
 there and the primary difference between what will happen if you
 easy_install something and pip install something is that pip might remove
 files from /usr/lib. In both cases the items installed by both solutions
 will be in /usr/local/lib.
 
 So what if Debian just patched python-pip so that it doesn’t remove the
 files from /usr/lib (but it would remove files from /usr/local etc). This
 would have the effect of pip not touching dpkg owned files which would
 bring it in line with that easy_install does. /usr/local/lib takes
 precedence over /usr/lib so it won’t break things for people actually
 trying to install things to /usr/local.
 
 There *might* be some edge cases that occurs with having two versions of a
 package on sys.path, but I can’t think of any offhand (and either way,
 those edge cases already exist if someone does
 ``apt-get install python-requests  pip install —upgrade requests`` and
 then later on Debian releases a new update to python-requests since those
 files that pip removed will get reinstalled in that situation.
 
 That should fix the immediate problem this bug addresses and then we can
 figure out a longer term “real” fix in upstream pip that can go into
 Jessie+1.

Speaking only for myself, I think that sounds reasonable.

It's well established I believe in Debian Python usage that if a user installs 
packages in /usr/local and break their system, they are on their own, so I'm 
not particularly worried about the edge cases for having the same python 
package installed in /usr/lib and /usr/local, it's on whoever installed stuff 
in /usr/local.

Being no more broken than easy_install seems like a reasonable compromise to 
me.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#725848: python-pip: default install method for non-root users should be --user

[Scott Kitterman]

On Mon, 17 Nov 2014 16:47:54 -0500 Donald Stufft don...@stufft.io wrote:
 Please don’t change the default. There is no way in pip to turn that flag 
*off*
 again once it's turned on and any flag added by Debian will be Debian specific
 and confuse people. We (pip) plan to make this change on our own at which 
point
 it will then be able to be done in a consistent way.

If I read you right, if we make --user the default, then pip won't be able to 
muck with system package installation.  I don't see that as a bad thing.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#764493: python-eventlet 0.15.2-1 to Sid/Jessie

[Scott Kitterman]

On Wed, 15 Oct 2014 18:24:06 +0200 
=?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= g...@debian.org wrote:
 Hi,
 
 Thomas packaged v0.15.2 and uploaded to experimental. In my opinion it
 should be uploaded to Sid and let migrate to Jessie.
...
Now that we are in Freeze, this is pretty unlikely.  Any objection to just 
uploading the Ubuntu patch so we can close the RC bug?

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#534605: python-geoip: [patch] build python debug package

[Scott Kitterman]

On Thu, 25 Jun 2009 20:02:26 +0200 Michael Vogt m...@ubuntu.com wrote:
 Package: python-geoip
 Version: 1.2.4-1
 Severity: wishlist
 Tags: patch
 User: ubuntu-de...@lists.ubuntu.com
 Usertags: origin-ubuntu karmic ubuntu-patch
 
 
 Hi,
 
 attached is a patch from Ubuntu to build a debug package
 of python-geoip. Please consider it for inclusion.
 
 It also appears that the license has changed from GPL to
 LGPL. debian/copyright still refers to GPL, but the header
 of py_GEOIP.c reads now:
 
 /* py_GeoIP.c
  *
  * Copyright (C) 2007 MaxMind LLC
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
  * License as published by the Free Software Foundation; either
  * version 2.1 of the License, or (at your option) any later version.
  *
The debian/copyright part of this is fixed.

Now that the package is switched from CDBS to dh, the patch is no longer 
appropriate, so dropping the patch tag.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] kombu_3.0.21-2_amd64.changes REJECTED

[Scott Kitterman]

Maintainer request - changelong UNRELEASED.

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team