[Python-modules-team] Accepted nose 1.3.7-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 22 Mar 2018 21:27:59 +0300 Source: nose Binary: python-nose-doc python-nose python3-nose Architecture: source Version: 1.3.7-4 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Dmitry Shachnev <mity...@debian.org> Description: python-nose - test discovery and running of Python's unittest python-nose-doc - documentation for discovery and running for Python's unittest python3-nose - test discovery and running for Python3 unittest Closes: 892938 Changes: nose (1.3.7-4) unstable; urgency=medium . [ Ondřej Nový ] * d/control: Set Vcs-* to salsa.debian.org * d/copyright: Use https protocol in Format field * d/changelog: Remove trailing whitespaces * d/control: Remove trailing whitespaces . [ Helmut Grohne ] * Mark all packages Multi-Arch: foreign (closes: #892938). . [ Dmitry Shachnev ] * Switch to pybuild buildsystem. * Move all clean logic to debian/clean file. * Remove obsolete Breaks/Replaces for pre-oldstable versions. * Remove debian/python-nose.prerm, leftover from old times. * Bump Standards-Version to 4.1.3, no changes needed. Checksums-Sha1: 32ba2c555392bd9559ea41ae2ee32bf1880146fa 2309 nose_1.3.7-4.dsc c4064606f424298e0b1eac933d1e2186d3340dd8 11944 nose_1.3.7-4.debian.tar.xz 50205149bb69f9a199c58115c5ea16e85ec96f44 7032 nose_1.3.7-4_source.buildinfo Checksums-Sha256: 7ae567b43ab48cde5a4de4e1ab0d250bd9861d8bda934d436832a0b3024d7029 2309 nose_1.3.7-4.dsc 0bffd5392dea5ca95680599e021213f8aee8c3ba3c0d77ae42b622bd7c8df693 11944 nose_1.3.7-4.debian.tar.xz 0d45b0ab756e8929204dd689c866ceff4354fc86dea17738b0c24a3c1cf040e7 7032 nose_1.3.7-4_source.buildinfo Files: 40d6b3d7048361820b2572e6d4b0071b 2309 python optional nose_1.3.7-4.dsc fcb7c827f72aba8cb4f90be7df322640 11944 python optional nose_1.3.7-4.debian.tar.xz 1792a0abaf791ae43e4c177e60ae69bb 7032 python optional nose_1.3.7-4_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEbEPcK+5mZmLK5jNU1v5xA2P4XdMFAlqz9gYACgkQ1v5xA2P4 XdMlQA//aKGS+dC1Af6kdK+EVO2OjoZDiZhJNu8Bw3XeXO+2QZrHFPjGUqiKyM1P 2OhR1srBZJYwuZI0A/9YTCAk9gO/H7Nski9PE9DFBarjxbr+CLtYg0arMqV61KXp OpHEDZMVNbD7ZuYiFOU3lEh57WsjyXRPupMt5/25KE8H0TbnH2bKNyMtEIgDNwNJ G/x4oSJwhvmDTOkS0xT2kvGcwznDM04PZqQ8b4dvpkTE6XBOyDxUrx8glfJILUNZ ho8WeKa9bVM/SrnAcMhIf4rcI1xzPLtc16rDIa+ZVdiyfvHfwf5kCZMtVK1t3F6F QU6ysbNjAL6c+p8y6QrsAL+PPUrjtix6qxKea49Tq+ppsu+HHvuKpGkpGoZoX5LL IiLyIF/d9yCiLy3krjYtTxt9DjV6dInvJeFRoM2qyKFb1A+9kdM55aviqXTnpAk0 vKp3ZS3cR3uuw32tEzNHSjnA+B8h5iaVkVY7YjCBknOQvHl4fRxR3KZih1zqLhuh teNqkKbYRFplBWmBm5RmdF9b4FSK/BjI1kB4baH6a9F6OEUOntqZgL6F8H8bX/xx mPZId7IYU9RWi/f4e7FajbvcdfJZeiu78LFr5UGpt2vcWBtuQIJkirXtaGtQ/sL7 J65InC50gTHAvI6yeAgSKwynjkGNGxc6KHImz+D+LJoUYTKhRHE= =W2tU -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 sphinx 1.6.7-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 22 Mar 2018 18:07:32 +0300 Source: sphinx Binary: python-sphinx python3-sphinx sphinx-common sphinx-doc libjs-sphinxdoc Architecture: source Version: 1.6.7-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Dmitry Shachnev <mity...@debian.org> Description: libjs-sphinxdoc - JavaScript support for Sphinx documentation python-sphinx - documentation generator for Python projects (implemented in Pytho python3-sphinx - documentation generator for Python projects (implemented in Pytho sphinx-common - documentation generator for Python projects - common data sphinx-doc - documentation generator for Python projects - documentation Closes: 893620 Changes: sphinx (1.6.7-2) unstable; urgency=medium . * Make python3-sphinx depend on python3-distutils (closes: #893620). Checksums-Sha1: 0e267d5116a7570325c5629bdf00a6f2ab0c48d5 3927 sphinx_1.6.7-2.dsc a3e00290e302e0acdcf5ab90ed1628241f7cd072 38052 sphinx_1.6.7-2.debian.tar.xz 4c6482b2027f37e110022499303e6b8b8b8b097a 5094 sphinx_1.6.7-2_source.buildinfo Checksums-Sha256: e62c3e1ebf13ebb256eeaa0455d1892be1094401ce3b15cf9fa02c48826dacad 3927 sphinx_1.6.7-2.dsc 6dae5e763802545033bcc15488d9605c98e4604fe922e29c49e708472912d5d6 38052 sphinx_1.6.7-2.debian.tar.xz 2dc12f5398592c055fd7e5be4edf5203a9790de3cd37c1e46f937b15b0bfef9e 5094 sphinx_1.6.7-2_source.buildinfo Files: 04771d49c9e6d1d274bde9994950fc87 3927 python optional sphinx_1.6.7-2.dsc 4765412f510fdeefec00c5d291f17217 38052 python optional sphinx_1.6.7-2.debian.tar.xz 57169e89751d3194dfae2f91c6c23b8b 5094 python optional sphinx_1.6.7-2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEbEPcK+5mZmLK5jNU1v5xA2P4XdMFAlqzxyAACgkQ1v5xA2P4 XdPqWw/+IJaUO2u0L3fCuZZ2XZQ/6dL2iIwD+x649WfnwcDKHWpPAxDgQwdKVhVC NDkEriaDYjST7xgliUH4zKn0TsrlHzEfoPgclK4//pSg9gs7rnbcycwoF0fmh/Wh jjbhd/RTEPE6F3Zv52IA2DXN/Li2sxBpTZJ0YqhGxhfUVhpa8EGQGF/HjEoocZ3I +9J5TtXytoqfVRe8km5zy0s6oWKruW4zT7PvtfaUMS9VLtnsGApm5PHRrnGDhBxu Y/If9aUQjNW4vOUq1PK7pSnybILHYT9TWc25o1yDJyRhpDVeryiOryGcwe8O0Wu5 E/fBYxiNY5v/H2XD0XMBVUruQxANfzuU2wyEAROXtgqP4WPcaEnKHQlAyPYIrB83 ycDE1M0Ij4m/OPVzjCRuug9qGoTjiCr4oKtNAkU6lP7x9Iex2EXUpDV0b7wT0PC1 uwRrK1r7rlCDOBtEFIs06r/idleeN8XUYOLjE8G4N27xdze0uRzf/YaKGPEy2SOd NqvNBwYMuqMPf6Z5SNq15i/JRZRbsLvS5ujl/YHMMVb0GzHdGnzbRMqpvpQqppL/ 8YZw4u71xXxnF7BlbcFP3luohSA1hH6eUa69YZohF2gaZAnfLWf+K8IWBplga9WD TO/wNhUWv+B+FVJ+446YJ/jMbFDzTkhJuSLJ25SmMvGOMsYDO2Y= =+XnX -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#892993: sphinx-rtd-theme CSS is not properly rebuilt from source
Source: sphinx-rtd-theme Version: 0.2.4-1 Severity: important Control: block 878237 by -1 This theme is currently not properly rebuilt from its SASS source. What is in debian/missing-sources/theme.css is only a de-uglified version of the built CSS file provided by upstream. To achieve that, we need to package neat [1] and wyrm [2]. Unfortunately wyrm seems to only support neat 1.x, not 2.x. [1]: https://neat.bourbon.io/ [2]: http://wyrmsass.org/ -- Dmitry Shachnev signature.asc Description: 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 sip4 4.19.8+dfsg-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 10 Mar 2018 09:56:30 +0300 Source: sip4 Binary: python-sip python-sip-dbg python-sip-dev sip-dev python-sip-doc python3-sip python3-sip-dev python3-sip-dbg Architecture: source Version: 4.19.8+dfsg-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Dmitry Shachnev <mity...@debian.org> Description: python-sip - Python/C++ bindings generator runtime library python-sip-dbg - Python/C++ bindings generator runtime library (debug extension) python-sip-dev - Python/C++ bindings generator development files python-sip-doc - Python/C++ bindings generator documentation python3-sip - Python 3/C++ bindings generator runtime library python3-sip-dbg - Python 3/C++ bindings generator runtime library (debug extension) python3-sip-dev - Python 3/C++ bindings generator development files sip-dev- Python/C++ bindings generator code generator application Changes: sip4 (4.19.8+dfsg-1) unstable; urgency=medium . [ Ondřej Nový ] * d/control: Set Vcs-* to salsa.debian.org . [ Dmitry Shachnev ] * New upstream bugfix release. * Bump API version to 12.4. Checksums-Sha1: 0055e2cd42772e681befd71ad28fb6952e8193f6 2654 sip4_4.19.8+dfsg-1.dsc ad596ad20303dc0f5c7270c0396b2ad54cfdd8b0 633749 sip4_4.19.8+dfsg.orig.tar.gz 1a8f38252265d7bc6ae17b7c2e4b98c6e978fe17 16348 sip4_4.19.8+dfsg-1.debian.tar.xz 95bb62d5bfc80e76389bfd8a18ca2d92844d9c0b 6760 sip4_4.19.8+dfsg-1_source.buildinfo Checksums-Sha256: e6b9c28a4165947be328776e85abcbd4df713c93a12034b23fe1316f65d4633a 2654 sip4_4.19.8+dfsg-1.dsc 4e94369bc0f695854e645771b929fdd3e6965f25e07a05ffeeec502804257f79 633749 sip4_4.19.8+dfsg.orig.tar.gz 2535344fd9a88936a69acb1197a9fab6a8486392d4711e486ca3df77aca83552 16348 sip4_4.19.8+dfsg-1.debian.tar.xz 62adcf2fbe662f5f64dd9dcf8be64277de3cbdf6fb58fe19571fe39ffb518ac0 6760 sip4_4.19.8+dfsg-1_source.buildinfo Files: 6090034a4cfa03bb0b8b371adbfec4a1 2654 devel optional sip4_4.19.8+dfsg-1.dsc 2113d4a4403b0b604e0969b9604565ef 633749 devel optional sip4_4.19.8+dfsg.orig.tar.gz 6df88e97d9ffcd9fd95164d97eefdb7e 16348 devel optional sip4_4.19.8+dfsg-1.debian.tar.xz 897747439b6fd90bb15aad49f101248e 6760 devel optional sip4_4.19.8+dfsg-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEbEPcK+5mZmLK5jNU1v5xA2P4XdMFAlqjggkACgkQ1v5xA2P4 XdMiew/9E+bj493uQSzBoP7KjjphlNrVPZx8NKoAiwlEduAmk+LUlnqiXVXtlBuu FwR4SGheq6/8U50jHXP7wFWTmrba2F/yAry7O1s4659g8m2cEuG5mpUhgcCYQxKM yIQMgATyJBfNEi57EfweMETT+arA2rY/lclMsZarJc7VGuLFbeQ+zHj7hWaHQnYE UGUhA0FvIl/2OdZv6HPyaO1k+Pfa07x43nKMf4bRI8z9yTsgo+hkkhO4ug6SMeEW G8HoiA4+J9xdJ7GCH8ZpR2rbuqYKIRKVCveOfSNIiVGsH8YGxonEut+tcc9OzUqN GGk50MDpjKAof3yukMBIQrPbqB0E1Hc/tWc0hHFkldp8qTVFdPD/EsB8x5nQI61o bGExa1vEmj1GgN7Uz+f1WKhj0WT+t7NCMFGgSRfjuEOMYK5LJv48DYTPoizUIgqN KLzuPJZ9ekD5ozMHl/+4prRocW/CoxDAti85VJj0wcDR8MjHc7TTS6r6jlURJK61 GFm7u5pNEQEsf91+uxqzPSDchFzyKkBfe9pJ/nTTqRs2jx31xzy/VB9suRm0OBHk 8rUMYKePRN9QE52kNJve8LSHycYN0b3hA7MB1p9NURfHUoR5hso9vjyLKwhx39Q/ qgPaQcFplQh0buFjBjro14x0ZAiEBJ6dRVYZa4y1wzbNOFtBx6k= =W8Mu -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 keyrings.alt 3.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 22 Feb 2018 13:38:44 +0300 Source: keyrings.alt Binary: python-keyrings.alt python3-keyrings.alt Architecture: source Version: 3.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Dmitry Shachnev <mity...@debian.org> Description: python-keyrings.alt - alternate backend implementations for python-keyring python3-keyrings.alt - alternate backend implementations for python3-keyring Changes: keyrings.alt (3.0-1) unstable; urgency=medium . [ Ondřej Nový ] * d/control: Set Vcs-* to salsa.debian.org . [ Dmitry Shachnev ] * New upstream release. * Do not ship keyrings/__init__.py files. - For Python 3, the namespace can be implicit (per PEP 420). - For Python 2, let dh_python2 generate this file in postinst. * Add a warning from upstream README to the package descriptions. * Update to debhelper compatibility level 11. * Bump Standards-Version to 4.1.3, no changes needed. Checksums-Sha1: d9d5089af2f52ac073170f324674a073c7d03b14 2416 keyrings.alt_3.0-1.dsc 0c34f47aa8098640881b47b75de03fd7c98a421e 26893 keyrings.alt_3.0.orig.tar.gz 56b9047cf18fe2b0e66c2000b88d4f3570fdd5e8 3052 keyrings.alt_3.0-1.debian.tar.xz ffc3084e4714877653d8456754ec28fdeef8144e 7481 keyrings.alt_3.0-1_source.buildinfo Checksums-Sha256: 72dbb9148610fbac476066c6bcb672d312d913299b0c8a2fa72589bc3543961c 2416 keyrings.alt_3.0-1.dsc d6ac80f3b7d8bfaae415cf3e4500326383b3266fc01e2a5b1466bea88bc136e8 26893 keyrings.alt_3.0.orig.tar.gz f9ad9c2905a559401b529c5d29b97eed641d75b5a9d426329a3b0dafbb5550af 3052 keyrings.alt_3.0-1.debian.tar.xz d2d35ab1be68f8c4188215d9d1631df22bdb43c7fe0924ec4d5bcc3572099602 7481 keyrings.alt_3.0-1_source.buildinfo Files: 5913950342f232f4223849d6e3663e54 2416 python optional keyrings.alt_3.0-1.dsc 20c6384e3bad544599194418925d1e70 26893 python optional keyrings.alt_3.0.orig.tar.gz aabad7acd5bf5b7f40e70ca059ac1405 3052 python optional keyrings.alt_3.0-1.debian.tar.xz 1a195536d1420b738b4a6d4caf0ab644 7481 python optional keyrings.alt_3.0-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEbEPcK+5mZmLK5jNU1v5xA2P4XdMFAlqOnjEACgkQ1v5xA2P4 XdNVFg//UfMuScHcxLj1LDE8qP7b1k2Ou0AGA1QJ55R4qL9HTyDYNQt8dug3DRQO PQyWh67yvwA4i/NVqKlV7qr+YfpqhIPYUoNuYrFZhwz74iYaVuME17pi63HIUbai WjWl6LpPg1q0/AP3BeBoh8eGINFKMmOQO6gmoCoQmP2uv1yAkBP3Yq2gtD6m5cwS Doxl+rE0ivQKAliBSGeyh4Jruylp94UDL0NQdzquRy15GW3x7iKTASUGuIL9WJTH 8s0uLCHXMAleGwCDsFc9JzmnhZOkdB8xz9llOeY+I61qflAwBdrA/2UbWkE2hIZ3 VB+XNRzPNnyPEiC4FawhzCq7W5+DLdXcpxpG9fp3vaMHrHXO12I+5El4X9IRPAd2 kpLU2bgQCmT5NzGHYbzfUX/VIjyS7bWMM67P+1CZ0GEAradKFFQ/8bKnDZHnYq4U p2idIqZVC/LL3ZegRVc2h2+b8ukkeTsCW+liwohPKafquv98hBrMvsGp5jLRQP/c mFe5othlhxRpmyXfS0eLWUXBfZ0XDOrMUn3Yux2zMKWqYAB3EpKg7V+gIYD9wM5Y XwlyyONby+5pdK17mkwwu0yHcuk0VS2XBWQSkXsos3kN/8+KhDHTHk+qFR6WWPCJ feRvvjhFpoW0LKMIOFmgqp7TLe7F+zzRaeIdy0mhgr1vRpivB2s= =5th3 -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#890621: python3-keyrings.alt 2.2-2 module.__file__ is None, causing regrtest.py to fail
Control: reassign -1 python3.6 3.6.4-4 Control: severity -1 serious Control: merge 890754 -1 On Sat, Feb 17, 2018 at 06:18:28PM -0600, Ron Lovell wrote: > Hi Dmitry, > > Thanks for the quick reply. I notice you have an older Python build. On my > Sid system, > in a new login session: > > $ python3.6 > Python 3.6.4+ (default, Feb 12 2018, 08:25:03) > [GCC 7.3.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import keyrings > >>> keyrings.__file__ > >>> repr(keyrings.__file__) > 'None' > >>> dir(keyrings) > ['__doc__', '__file__', '__loader__', '__name__', '__package__', > '__path__', '__spec__'] Oh, so it looks like a regression in python3.6 3.6.4-4. It looks very similar to #890754, so I am merging these two bugs. > I'm running Sid on arch amd64, with updates current. I wouldn't think a > rebuild with gcc 7.3 > would make a difference. I'm trying to think of anything special about my > environment that > would cause a difference. What do you mean by "a clean environment"? A > fresh install of Debian? No more need to reproduce it. Just for future, it is very convenient to use minimal chroots (like pbuilder, sbuild, schroot, etc) for testing such things. -- Dmitry Shachnev signature.asc Description: 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 sphinx 1.6.7-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 11 Feb 2018 22:08:38 +0300 Source: sphinx Binary: python-sphinx python3-sphinx sphinx-common sphinx-doc libjs-sphinxdoc Architecture: source Version: 1.6.7-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Dmitry Shachnev <mity...@debian.org> Description: libjs-sphinxdoc - JavaScript support for Sphinx documentation python-sphinx - documentation generator for Python projects (implemented in Pytho python3-sphinx - documentation generator for Python projects (implemented in Pytho sphinx-common - documentation generator for Python projects - common data sphinx-doc - documentation generator for Python projects - documentation Changes: sphinx (1.6.7-1) unstable; urgency=medium . * New upstream bugfix release. * Update Vcs fields for migration to salsa.debian.org. * Update debhelper compat level to 11. Checksums-Sha1: 2009ccedf1ba9b344532866747e8393e7b50aa93 3927 sphinx_1.6.7-1.dsc 92a9c4c594b7ca7b779fe69c99a71f9d42c07682 4692169 sphinx_1.6.7.orig.tar.gz 2c8878e0864a86c5386e03df7aeafcef018d1e62 833 sphinx_1.6.7.orig.tar.gz.asc e1eaf02eb05a7cb2203251c491fff09d9c8f8137 38012 sphinx_1.6.7-1.debian.tar.xz cc119dd509a73fb099bb256294f4a2f61da0f61a 5042 sphinx_1.6.7-1_source.buildinfo Checksums-Sha256: 5a3ea9fbffdc5e2f2e61e7793f531e0b2aca6207749084806580cb874c967c9e 3927 sphinx_1.6.7-1.dsc 832bed0dc6099c2abca957d90ff55bc1a6ec4425c13fc144adbae68a970e3775 4692169 sphinx_1.6.7.orig.tar.gz b14dbd6e5e33075f95048f3862996a1c696bb2cf892d2b0d225568cafb96961a 833 sphinx_1.6.7.orig.tar.gz.asc 1193359ee5221834ed9d47d22bcf4158205ebd13d7dfed72b343e85e59d379da 38012 sphinx_1.6.7-1.debian.tar.xz 064c39e5040a802ca1c2ac39f900acb2b7c1aeb5c064895ed6d6db7662f5efda 5042 sphinx_1.6.7-1_source.buildinfo Files: 19324d36b27c623641ea55ab21176ba1 3927 python optional sphinx_1.6.7-1.dsc 753731d5751991d9cc0c02b8994f21f6 4692169 python optional sphinx_1.6.7.orig.tar.gz a174f11d14410277bdb194839a3fcb79 833 python optional sphinx_1.6.7.orig.tar.gz.asc 8d8c98cb8b93f137fcea5aac197a1f86 38012 python optional sphinx_1.6.7-1.debian.tar.xz 141a35aaa6e7c5c88b1727abd480ac2d 5042 python optional sphinx_1.6.7-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEbEPcK+5mZmLK5jNU1v5xA2P4XdMFAlqAo24ACgkQ1v5xA2P4 XdPmehAAnvkTuWYU6INMNQuSyffTyxP00jNgSwhU0eHqfGkbTAS8yRRl5UrTbZ3Y Kxb8VueL5YdklXhYLh88gxw+8+wrnxnYh+6CFtkRiXDyUWwD2VMAZc00NInMoh9M 6ulmGRauqS/sg8RPxdsOVX87Asb+4jYpf1eHyGd4fEEdd++ThjLRuBmMx5hUnhS1 ENHFCvPc1ZbAOrM0judViwgFeeOloTmhBBdJ2scgXgmXHl5CnehzHJ8OUlGkm7f3 SCIj54CNqYAkY6ZnLZ/PQa9tkzSSckpbgdlIex3FZgNeyaVbbHxrhqMgP4h50IGD O9EOSGTyPekWDHBje/mP05HNI+HGGB0cs4JB8H1N8OKLPpqrmMgUQoM6U3SnkdI+ DpMQ029aONDztkWfn8y1Y+CrKWQyQtJTGNlZv3bT+m7cgACTlnh6CnVBWkUAdrMb /xYPDqASpw7UJ2zMi0n6XQmFuYiFKGBnaXGxk5YP61qBLWXT5xrBHfkS1Qlvt4D+ mBLYdAkV81ZhM4jNlWV/s50xfXL0XHxr8s02G8EuCffJU6J3IaMWry+XIWG8ip5Q nl/DyNakumzgsVW6J6PX9J0TuOjSUbE5GpBG78oxdQuq6srIe2AnDVanDalvOWzr MFwMuSISZoD4BSkqKhpMCK0vSIPQIvb4w/yT/ctfEf450QpdSD0= =4bjM -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
Re: [Python-modules-team] [IMPORTANT] DPMT migrated to Salsa
Hi, On Fri, Feb 09, 2018 at 10:27:42PM +0100, Vincent Bernat wrote: > ❦ 9 février 2018 13:46 +0100, Ondrej Novy <n...@ondrej.org> : > > >- mass-commit change of d/control: Vcs-* > > Is it needed? anonscm URL work (both Vcs fields use https) and it seems > a better idea to have service-independant URL. anonscm.debian.org URLs are not service-independent, as anonscm is the same machine as Alioth, and it may be shut down in the future. Also for new packages there will be no repositories on Alioth, and it is better to have consistent Vcs URLs for all team packages. So I think the mass-commit is needed. Please also see the documentation: https://wiki.debian.org/Salsa/Doc#Canonical_Repository_URLs -- Dmitry Shachnev signature.asc Description: 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#886400: python3-pyqt5.qtwebengine: segfaults on simple test
Hi, On Fri, Jan 05, 2018 at 08:28:25PM -0400, David Bremner wrote: > Sure, here is a stracktrace from > > /usr/bin/python3 testbrowser_webengine.py url=https://www.debian.org Can you please try the attached small change to testbrowser_webengine.py? I thought that this flag is only needed on Windows, but who knows. Also I think the url= is wrong, you should just pass the URL directly. > If you let me know which debug symbol packages to install, I'm happy to > try again with more symbols. If that change does not help, then please try with these packages: libqt5gui5-dbgsym libqt5quickwidgets5-dbgsym libqt5webenginewidgets5-dbgsym libqt5widgets5-dbgsym Also please let me know which Qt platform you are using (xcb or wayland) and which graphics card/driver you have (I saw some graphics specific bugs on upstream bugtracker). -- Dmitry Shachnev --- ./testbrowser_webengine.py.orig 2018-01-09 13:50:35.070024955 +0300 +++ ./testbrowser_webengine.py 2018-01-09 14:18:15.445976504 +0300 @@ -23,7 +23,7 @@ import sys import argparse -from PyQt5.QtCore import QUrl +from PyQt5.QtCore import QUrl, Qt from PyQt5.QtWidgets import QApplication from PyQt5.QtWebEngineWidgets import QWebEngineView @@ -37,6 +37,7 @@ if __name__ == '__main__': args = parse_args() +QApplication.setAttribute(Qt.AA_ShareOpenGLContexts) app = QApplication(sys.argv) wv = QWebEngineView() signature.asc Description: 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#886400: python3-pyqt5.qtwebengine: segfaults on simple test
Hi David! On Fri, Jan 05, 2018 at 07:39:59AM -0400, David Bremner wrote: > I encountered this when trying to run webmacs (a browser written in > python) on Debian. > > The attached script segfaults, seemingly on any URL. Feel free to > adjust the severity up or down; I'm guessing the package works for > some people / applications, but this seems like pretty core > functionality to be broken. I cannot reproduce this (tested with e.g. https://www.debian.org). Can you please attach some stacktrace? -- Dmitry Shachnev signature.asc Description: 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: python3-pyqt5.qtwebengine: package not available for Raspberry Pi
Control: tags -1 moreinfo Hi, and sorry for the delay! On Fri, Oct 27, 2017 at 06:41:31PM +0200, activityworkshop wrote: > Package: python3-pyqt5.qtwebengine > Severity: important > > Dear Maintainer, > > According to packages.debian.org, this package is only built for amd64 and > i386 architectures. > To use it on the Raspberry Pi, one would need it to be built also for ARM. > The Qt5 packages on which this one depends, such as libqt5qui5, > libqt5webenginecore5, libqt5webenginewidgets5 etc, already appear to be > built. > Is this just an oversight, that the python bindings are missing? > > As an aside, Raspbian already includes architecture-neutral packages which > depend on this python3-pyqt5.qtwebengine package, and these fail to install. In fact I think this bug report should go to Raspbian, not to Debian. From the Raspbian build logs [1], it looks like qtwebengine is available there only in buster, not in stretch (even though the version from Debian stretch builds fine on armhf). Also for some reason even when I added qtwebengine/armhf support to pyqt5 in 5.7+dfsg-6, the Raspbian developers reverted that change in 5.7+dfsg-6+rpi1 upload (and it is still reverted in 5.9+dfsg-2+rpi1 [2]): * Disable webengine for armhf, we do not currently have (and may never have) it in Raspbian. -- Peter Michael Green <plugw...@raspbian.org> Sat, 09 Sep 2017 01:01:09 + I do not know the reasoning for that change, so adding Peter to CC in hope he can explain it. I can still do an upload for Debian stretch, but only if you confirm that it will be useful for you. See #880080 for my discussion with the Release Team. [1]: https://buildd.raspbian.org/status/logs.php?pkg=qtwebengine-opensource-src [2]: http://archive.raspbian.org/raspbian/pool/main/p/pyqt5/pyqt5_5.9+dfsg-2+rpi1.debian.tar.xz -- Dmitry Shachnev signature.asc Description: 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#884020: python3-sphinx: versioned dependency on jinja2 is too loose
Hi Sandro! On Sun, Dec 10, 2017 at 09:59:27AM -0500, Sandro Tosi wrote: > Hello, > i had an outdated version on jinja2 on my machine (2.9.5-1) and when building > a > package i got the error: > > Error: The 'jinja2.asyncsupport' module cannot be found. Did you install > Sphinx and its dependencies correctly? > > after upgrading python3-jinja2 to 2.10-1, the error went away. > > Python3-sphinx declare this dep on jinja2: 'python3-jinja2 (>= 2.3)', probably > you need a tigher one Sphinx does not use jinja2.asyncsupport, and it should work fine with older versions of Jinja2. What you are experiencing looks like bug #862699, which was fixed in Jinja2 2.9.6-1. If you agree with me, please close this bug. -- Dmitry Shachnev signature.asc Description: 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#881581: python3-pyqt5: PyQt5 Leaks memory on dereference of QStyleOptionTab
Hi Jay, On Mon, Nov 13, 2017 at 01:24:29AM -0500, Jay Kamat wrote: > The version of PyQt5 in the Debian stretch archives seems to leak memory on > deference of a QStyleOptionTab. > > [...] > > This currently affects: > > - Debian Stable > - Ubuntu zesty > - Fedora 25 > > And curiously, the 5.7.1 PyQt5 on pypi does not suffer from this. > > Please let me know if you need any additional information. It would be nice to know which upstream change fixes this problem. I checked the diff between 5.7 and 5.7.1 tarballs and could not find anything related to QStyleOptionTab or mentioning memory leaks. Unfortunately I do not have time to dig deeper. -- Dmitry Shachnev signature.asc Description: 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#881923: new upstream version (1.6.6)
Control: tags -1 moreinfo Hi Daniel! On Thu, Nov 16, 2017 at 04:13:31PM +0100, Daniel Baumann wrote: > Hi, > > sphinx 1.6.6 was released, it would be nice if you could upgrade the > package in debian. I do not see it released. I see it neither in [1] nor in [2]. The milestone [3] says it will be due by November 26, 2017, but there are still many bugs so I am not sure how realistic it is. [1]: https://pypi.python.org/pypi/Sphinx [2]: https://github.com/sphinx-doc/sphinx/releases [3]: https://github.com/sphinx-doc/sphinx/milestone/39 -- Dmitry Shachnev signature.asc Description: 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#877895: intersphinx plugin makes packages unreproducible
On Thu, Oct 12, 2017 at 03:55:46PM -0400, Antoine Beaupré wrote: > now i guess i need to file bugs for all my build-deps to make sure they > ship -doc packages... sigh... > > i am not sure what the next step here is. should we just document this > as a known issue with reproducible builds and teach people how to fix > this somehow? I think yes. In theory every package which tries to access network during build is buggy, and needs to be fixed anyway. Pybuild helps with that by setting http_proxy/https_proxy to 127.0.0.1:9. > or is there anything else needed in sphinx? I do not want to hardcode Debian paths to various .inv files. What else can I do? -- Dmitry Shachnev signature.asc Description: 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#877895: intersphinx plugin makes packages unreproducible
Hi Antoine!
On Fri, Oct 06, 2017 at 08:59:55PM -0400, Antoine Beaupré wrote:
> I believe that those docs package already do provide docs index, e.g.:
>
> /usr/share/doc/python-configparser/html/objects.inv
>
> it's just a matter of fixing sphinx to make that work then... i wonder
> if interlinks supports file:// paths?
Intersphinx supports local files (the file:// prefix is unneeded). But you
need to explicitly point it to them.
In your package (feed2exec), doc/conf.py currently has:
intersphinx_mapping = {
'click': ('http://click.pocoo.org/', None),
'jinja': ('http://jinja.pocoo.org/docs/', None),
'python': ('https://docs.python.org/3/', None),
}
You need to patch this to point to Debian packaged paths. See codesearch [1]
for examples on how others are doing it.
[1]:
https://codesearch.debian.net/search?q=html%2Fobjects%5C.inv+path%3Adebian%2Fpatches%2F.*
--
Dmitry Shachnev
signature.asc
Description: 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#877014: python3-sphinx exception building breathe
Control: severity -1 normal Control: retitle -1 breathe: python3-sphinx warning building breathe On Wed, Sep 27, 2017 at 11:21:58PM +0300, Dmitry Shachnev wrote: > However in my opinion the real issue here is in breathe, and it should be > fixed in the first place. I have just created an upstream pull request about > this, and with that change applied breathe builds fine. > > I will also create a pull request to sphinx fixing the regression, but unless > there are other affected packages I will not backport it to Debian before new > upstream release. I have uploaded Sphinx with this change today, it now raises a warning instead of AssertionError on types mismatch. So downgrading the bug severity. -- Dmitry Shachnev signature.asc Description: 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#877014: python3-sphinx exception building breathe
Control: clone -1 -2 Control: reassign -2 src:breathe Control: forwarded -2 https://github.com/michaeljones/breathe/pull/353 Control: tags -2 +patch Control: severity -1 important Hi Adrian and Sebastian! On Wed, Sep 27, 2017 at 09:51:49PM +0300, Adrian Bunk wrote: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/breathe.html > > [...] > File "/usr/lib/python3/dist-packages/sphinx/domains/cpp.py", line 4969, in > checkType > assert False > AssertionError > Type is member, declType is class I agree that there is a breaking change in Sphinx 1.6.4: instead of printing a warning about type mismatch, it raises AssertionError. However in my opinion the real issue here is in breathe, and it should be fixed in the first place. I have just created an upstream pull request about this, and with that change applied breathe builds fine. I will also create a pull request to sphinx fixing the regression, but unless there are other affected packages I will not backport it to Debian before new upstream release. -- Dmitry Shachnev signature.asc Description: 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#874673: python-keyring: CLI tool is not properly installed
Hi Matthew! On Fri, Sep 08, 2017 at 11:27:32AM -0400, Matthew Gabeler-Lee wrote: > This package comes with a command line helper tool, but it is not installed > properly as such as part of the package. > > /usr/lib/python2.7/dist-packages/keyring/cli.py is installed, but not as a > tool in /usr/bin/, and further it cannot even be run directly from the > location it is installed: You can use “python -m keyring” or “python3 -m keyring”. In my opinion that is enough. -- Dmitry Shachnev signature.asc Description: 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#784512: Is anybody working on PySide2?
On Mon, Aug 28, 2017 at 01:16:36PM +0200, W. Martin Borgert wrote: > Quoting Dmitry Shachnev <mity...@debian.org>: > > Where did you read that pyside2 will be part of Qt? I thought it is rather > > a side project from The Qt Company. > > http://lists.qt-project.org/pipermail/pyside/2016-April/002401.html > > > * The goal is to make Pyside an integral part of new Qt releases. Thank you for the pointer! If pyside2 becomes part of Qt, then probably we will have to maintain in the Qt/KDE team because the uploads will need to be synchronized with Qt uploads. However they have not achieved this goal yet: there has been no pyside2 release yet, and there is no pyside submodule in qt5.git. -- Dmitry Shachnev signature.asc Description: 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#784512: Is anybody working on PySide2?
Hi! On Sun, Aug 27, 2017 at 04:53:30PM +0200, W. Martin Borgert wrote: > 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? Where did you read that pyside2 will be part of Qt? I thought it is rather a side project from The Qt Company. I do not have time or interest to package it myself, but if you (or anyone else) volunteer to package it, I can help you with some Qt or Python stuff. The latest stable upstream source can be found here: https://code.qt.io/cgit/pyside/pyside-setup.git/?h=5.9 -- Dmitry Shachnev signature.asc Description: 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#784512: Qt4 WebKit removal: raising severity to serious
Control: severity -1 serious Dear maintainer(s), As recently announced [1], we are going to remove not only Qt 4 WebKit, but Qt 4 as a whole in Buster. As removing Qt 4 WebKit is the first step, I am raising the severity of this bug to serious. Please port your package to Qt 5 if you do not want to get it removed from Debian. In Qt 5, the WebKit module is supported, and we are currently preparing a major update based on 5.212 branch [2]. [1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html [2]: https://code.qt.io/cgit/qt/qtwebkit.git/log/?h=5.212 -- Dmitry Shachnev signature.asc Description: 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#872992: pytest-qt: FTBFS: Tests failures because of logging changes in Qt
Source: pytest-qt Version: 2.1.2-2 Severity: serious Tags: patch Dear maintainer, pytest-qt fails to build in the current sid: tests/test_logging.py .F.FF..F. tests/test_logging.py::test_basic_logging[True-False] FAILED tests/test_logging.py::test_basic_logging[False-False] FAILED tests/test_logging.py::test_qtlog_fixture FAILED tests/test_logging.py::test_logging_fails_tests[DEBUG-1] FAILED These failures are caused by the configure file that is now shipped with Qt and which disables all debug output. See bug #805399 for details. The fix is exporting QT_LOGGING_RULES="default.debug=true" when running the tests. A patch to do this is attached. -- Dmitry Shachnev --- pytest-qt-2.1.2/debian/rules +++ pytest-qt-2.1.2/debian/rules @@ -26,5 +26,5 @@ override_dh_auto_test: ifeq (,$(findstring nocheck,$(DEB_BUILD_PROFILES))) - xvfb-run -a dh_auto_test + QT_LOGGING_RULES="default.debug=true" xvfb-run -a dh_auto_test endif --- pytest-qt-2.1.2/debian/tests/control +++ pytest-qt-2.1.2/debian/tests/control @@ -3,7 +3,7 @@ ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" - ; PYTEST_QT_API=pyqt5 xvfb-run -a $py -m pytest tests + ; QT_LOGGING_RULES="default.debug=true" PYTEST_QT_API=pyqt5 xvfb-run -a $py -m pytest tests ; done Depends: python3-all, python3-pyqt5, python3-pytestqt, xauth, xvfb @@ -12,6 +12,6 @@ ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" - ; PYTEST_QT_API=pyqt4 xvfb-run -a $py -m pytest tests + ; QT_LOGGING_RULES="default.debug=true" PYTEST_QT_API=pyqt4 xvfb-run -a $py -m pytest tests ; done Depends: python3-all, python3-pyqt4, python3-pytestqt, xauth, xvfb ___ 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#869971: nose: Provide a package for PyPy
Hi Ghislain! On Fri, Jul 28, 2017 at 10:28:09AM +0100, Ghislain Antony Vaillant wrote: > Dear Maintainer, > > The lack of a nose package for PyPy may block testing of future packaged > PyPy modules. Since nose should be compatible with PyPy according to the > upstream wiki [1], you might want to consider providing a corresponding > pypy-nose package. I want to note that nose is deprecated [1] and completely unmaintained [2] upstream, and all users are encouraged to switch to nose2 [3] or other alternatives (plain unittest/unittest2 or pytest). So if you want to package a new Python or PyPy module, please consider not using nose there. [1]: https://github.com/nose-devs/nose/blob/master/NEWS [2]: https://groups.google.com/d/msg/nose-dev/rkofU1WdNNc/um9FRb19BQAJ [3]: https://tracker.debian.org/pkg/nose2 -- Dmitry Shachnev ___ 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#872393: sphinx: autopkgtest failure on armhf with webkit2gtk 2.17.90
Hi Jeremy! On Wed, Aug 16, 2017 at 10:50:13PM -0400, Jeremy Bicha wrote: > Source: sphinx > Version: 1.5.6-2 > > Hi, webkit2gtk 2.17.90 (2.18 Beta 1) is no migrating out of > artful-proposed because the sphinx-doc autopkgtest is failing on > armhf. > > http://autopkgtest.ubuntu.com/packages/s/sphinx/artful/armhf > > Could you look into this? I am attaching two stacktraces: one for when the actual crash happens, and another one for the first call of g_log() in the main process, which happens just before the crash. I could not figure out how to break on warnings in WebKitWebProcess. This looks like a regression in WebKit to me. Maybe you can report it upstream and then we disable the test on armhf as a temporary workaround? -- Dmitry Shachnev #0 g_utf8_validate (str=str@entry=0xe , max_len=max_len@entry=-1, end=end@entry=0x0) at ../../../../glib/gutf8.c:1670 #1 0xf6c3a44c in g_variant_new_string (string=0xe ) at ../../../../glib/gvariant.c:1257 #2 0xf6c3d134 in g_variant_valist_new_nnp (str=0xfffee574, ptr=0xe) at ../../../../glib/gvariant.c:4770 #3 0xf6c3dffe in g_variant_valist_new_leaf (app=0xfffee588, str=0xfffee574) at ../../../../glib/gvariant.c:4962 #4 g_variant_valist_new (str=str@entry=0xfffee574, app=app@entry=0xfffee588) at ../../../../glib/gvariant.c:5144 #5 0xf6c3df4e in g_variant_valist_new (str=str@entry=0xfffee574, app=app@entry=0xfffee588) at ../../../../glib/gvariant.c:5196 #6 0xf6c3e15a in g_variant_new_va (format_string=, endptr=0x0, app=0xfffee588) at ../../../../glib/gvariant.c:5372 #7 0xf6c3e1e6 in g_variant_new (format_string=0xf5cc "(tsssb)") at ../../../../glib/gvariant.c:5307 #8 0xf3278e70 in Inspector::RemoteInspector::listingForInspectionTarget () at ./Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorGlib.cpp:192 #9 0xf327713c in Inspector::RemoteInspector::listingForTarget () at ./Source/JavaScriptCore/inspector/remote/RemoteInspector.cpp:203 #10 0xf3279af8 in Inspector::RemoteInspector::updateAutomaticInspectionCandidate () at ./Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorGlib.cpp:251 #11 0xf2a4ecc0 in JSGlobalContextCreateInGroup () at ./Source/JavaScriptCore/API/JSContextRef.cpp:144 #12 0xf38d0288 in webkit_web_view_get_javascript_global_context () at ./Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:3154 #13 0xf38d0350 in webkitWebViewRunJavaScriptCallback () at ./Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:3183 #14 0xf38d06e8 in operator() () at ./Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:3210 #15 call () at ./Source/WTF/wtf/Function.h:102 #16 0xf36eb534 in WTF::Function::operator()(API::SerializedScriptValue*, bool, WebCore::ExceptionDetails const&, WebKit::CallbackBase::Error) const () at ./Source/WTF/wtf/Function.h:56 #17 WebKit::GenericCallback<API::SerializedScriptValue*, bool, WebCore::ExceptionDetails const&>::performCallbackWithReturnValue () at ./Source/WebKit/UIProcess/GenericCallback.h:108 #18 WebKit::WebPageProxy::scriptValueCallback () at ./Source/WebKit/UIProcess/WebPageProxy.cpp:5123 #19 0xf3a058b0 in IPC::callMemberFunctionImpl<WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(IPC::DataReference const&, bool, WebCore::ExceptionDetails const&, WebKit::CallbackID), std::tuple<IPC::DataReference, bool, WebCore::ExceptionDetails, WebKit::CallbackID>, 0u, 1u, 2u, 3u>(WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(IPC::DataReference const&, bool, WebCore::ExceptionDetails const&, WebKit::CallbackID), std::tuple<IPC::DataReference, bool, WebCore::ExceptionDetails, WebKit::CallbackID>&&, std::integer_sequence) () at ./Source/WebKit/Platform/IPC/HandleMessage.h:40 #20 IPC::callMemberFunction<WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(IPC::DataReference const&, bool, WebCore::ExceptionDetails const&, WebKit::CallbackID), std::tuple<IPC::DataReference, bool, WebCore::ExceptionDetails, WebKit::CallbackID>, std::integer_sequence >(std::tuple<IPC::DataReference, bool, WebCore::ExceptionDetails, WebKit::CallbackID>&&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(IPC::DataReference const&, bool, WebCore::ExceptionDetails const&, WebKit::CallbackID)) () at ./Source/WebKit/Platform/IPC/HandleMessage.h:46 #21 IPC::handleMessage<Messages::WebPageProxy::ScriptValueCallback, WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(IPC::DataReference const&, bool, WebCore::ExceptionDetails const&, WebKit::CallbackID)> () at ./Source/WebKit/Platform/IPC/HandleMessage.h:126 #22 0xf39fece8 in WebKit::WebPageProxy::didReceiveMessage () at ./obj-arm-linux-gnueabihf/DerivedSources/WebKit2/WebPageProxyMessageReceiver.cpp:666 #23 0xf363afd4 in IPC::MessageReceiverMap::dispatchMessage () at ./Source/WebKit/Platform/IPC/MessageReceiverMap.cpp:123 #24 0xf370f6a8 in WebKit::WebProcessProxy::didReceiv
[Python-modules-team] Bug#872280: python3-sphinx-celery: Please backport upstream change to fix compatibility with Sphinx 1.6
Package: python3-sphinx-celery Version: 1.3.1-1 Severity: important User: python-modules-team@lists.alioth.debian.org Usertags: sphinx1.6 Dear maintainer, Please backport the following upstream commit: https://github.com/celery/sphinx_celery/commit/28d8f42b43d5a28a Without it, celery (in experimental) and python-django-celery-results fail to build with Sphinx 1.6 (currently available in experimental). Here is the failure for celery: reading sources... [ 0%] changelog [...] Exception occurred: File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 567, in __getitem__ return self.attributes[key] KeyError: 'refdomain' -- Dmitry Shachnev signature.asc Description: 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#872270: celery: FTBFS with Sphinx 1.6: AttributeError: 'Sphinx' object has no attribute 'domains'
On Tue, Aug 15, 2017 at 05:46:29PM +0300, Dmitry Shachnev wrote: > celery fails to build with Sphinx 1.6, currently available in experimental: > > [...] > > This commit from upstream Celery should fix this: > https://github.com/celery/celery/commit/3c98e6216167d7e5 Sorry, that commit is not enough, because after applying it the build fails with a new error: Traceback (most recent call last): [...] File "/usr/lib/python2.7/dist-packages/sphinx/domains/std.py", line 592, in note_citation_refs if node['refdomain'] == 'std' and node['reftype'] == 'citation': File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 567, in __getitem__ return self.attributes[key] KeyError: 'refdomain' So you also need to apply this patch to docs/_ext/githubsphinx.py file: https://github.com/celery/sphinx_celery/commit/28d8f42b43d5a28a After applying both patches the build succeeds. -- Dmitry Shachnev signature.asc Description: 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#872270: celery: FTBFS with Sphinx 1.6: AttributeError: 'Sphinx' object has no attribute 'domains'
Source: celery Version: 3.1.23-7 Severity: important Tags: fixed-upstream User: python-modules-team@lists.alioth.debian.org Usertags: sphinx1.6 Dear maintainer, celery fails to build with Sphinx 1.6, currently available in experimental: Running Sphinx v1.6.3 making output directory... Generating grammar tables from /usr/share/sphinx/pycode/Grammar-py2.txt WARNING: sphinx.ext.pngmath has been deprecated. Please use sphinx.ext.imgmath instead. Exception occurred: File "/tmp/celery-3.1.23/docs/../celery/contrib/sphinx.py", line 75, in setup app.domains['py'].directives['task'] = TaskDirective AttributeError: 'Sphinx' object has no attribute 'domains' The full traceback has been saved in /tmp/sphinx-err-KsCJml.log, if you want to report the issue to the developers. And the full traceback from the mentioned file is: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/cmdline.py", line 305, in main opts.warningiserror, opts.tags, opts.verbosity, opts.jobs) File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line 196, in __init__ self.setup_extension(extension) File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line 456, in setup_extension self.registry.load_extension(self, extname) File "/usr/lib/python2.7/dist-packages/sphinx/registry.py", line 207, in load_extension metadata = mod.setup(app) File "/tmp/celery-3.1.23/docs/../celery/contrib/sphinx.py", line 75, in setup app.domains['py'].directives['task'] = TaskDirective AttributeError: 'Sphinx' object has no attribute 'domains' This looks like a result of this Sphinx commit: https://github.com/sphinx-doc/sphinx/commit/8ca9bdfbd41cc547 This commit from upstream Celery should fix this: https://github.com/celery/celery/commit/3c98e6216167d7e5 -- Dmitry Shachnev signature.asc Description: 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#867794: python3-pyqt5: App tray icon won't show if show() before systray is available
Control: reassign -1 libqt5widgets5 5.7.1+dfsg-4 Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-61898 Hi Jérôme, On Sun, Jul 09, 2017 at 10:56:05PM +0200, Jérôme wrote: > Here's a minified example to reproduce the issue : > > [...] > > Remove systray applet from panel, launch code, add systray applet. The > icon does not show up. This is a bug in Qt, and I can confirm it with Qt 5.9 and C++ code. If you want to workaround this in your code, do not call show() unless QSystemTrayIcon.isSystemTrayAvailable() returns True. -- Dmitry Shachnev signature.asc Description: 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#866789: new upstream (1.6.x)
Hi Daniel, On Sat, Jul 01, 2017 at 08:09:15PM +0200, Daniel Baumann wrote: > it would be nice if you could upgrade to the current upstream version > (1.6.2). Sphinx has 916 reverse dependencies, so every new release should be thoroughly tested before uploading. My plan is to upload 1.5 to unstable within a couple of weeks, and only then start working on 1.6 in experimental. Are any particular features or bugfixes in 1.6 that you need? If yes then it may be easier to backport them. -- Dmitry Shachnev signature.asc Description: 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#822197: Memory addresses still seem to appear in sphinx docs...
On Tue, May 23, 2017 at 11:33:26PM -0400, Justin Cappos wrote: > So I had a look and think there may be an easier way to handle this. What > if the ' at ' was removed from the memory regex in > https://github.com/sphinx-doc/sphinx/blob/1.5.5/sphinx/util/inspect.py#L23 That would introduce many false positives. What if one has a legit hex constant in the code, i.e. 0x12345678? Also, please move this discussion upstream — I will not add any patches unless they are accepted upstream. -- Dmitry Shachnev signature.asc Description: 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#822197: Memory addresses still seem to appear in sphinx docs...
Hi Justin, On Sun, May 07, 2017 at 11:39:50AM -0400, Justin Cappos wrote: > Okay, I have opened a new bug about this in sphinx: > https://github.com/sphinx-doc/sphinx/issues/3722 According to upstream response, this is because Celery is using a non-standard format for memory addresses, and the regex in Sphinx does not catch it. We will not add hacks for every specific project in Sphinx, so I don’t think I can do anything about this. -- Dmitry Shachnev signature.asc Description: 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#862473: pyqt5-dev-tools: QFileDialog : Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Control: reassign -1 qt5-gtk-platformtheme 5.7.1+dfsg-3 Hi, On Sat, May 13, 2017 at 10:54:41AM +0200, brunoVolpi wrote: > Package: pyqt5-dev-tools > Version: 5.7+dfsg-5 > Severity: minor > > Dear Maintainer, > > using QFileDialog cause the msg : > Gtk-Message: GtkDialog mapped without a transient parent. This is > discouraged. > > tested with : > pyqt5 examples.dialog.findfiles.py return same problem > qmlscene > even reportbug did it some time This is an issue in Qt, not PyQt. Also, you can safely ignore this warning, as it is false positive. There has been code in place to hide this warning, but for some reason it stopped working: http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platformthemes/gtk3/qgtk3theme.cpp#n68 -- Dmitry Shachnev signature.asc Description: 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#822197: Memory addresses still seem to appear in sphinx docs...
Hi Justin, On Fri, May 05, 2017 at 06:01:22AM -0400, Justin Cappos wrote: > I am taking a look at some of the reproducible-builds packages that are > still failing and still see some issues that look like they may be from > memory addresses being output by sphinx. > > For example, django-celery outputs the following memory address > [...] > > I checked the github issue tracker and this doesn't seem to be listed > there, but it is possible that this issue is related: > https://github.com/sphinx-doc/sphinx/issues/1721. Can you please file a new bug for upstream Sphinx, or ping the existing issue you mentioned? I am afraid I don’t have time to look at this myself, so help from upstream would be nice. -- Dmitry Shachnev ___ 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#861567: sphinx: 1.5.3+ breaks src:dask build
Control: reassign -1 src:dask 0.12.0-1 Control: severity -1 important Control: tags -1 +patch Hi, On Sun, Apr 30, 2017 at 07:31:26PM +, Gianfranco Costamagna wrote: > Hello, I'm not sure if this is a problem in sphinx or not, > I noticed this failure on src:dask in Ubuntu, and it is > reproducible with 1.5.3 and 1.5.5 in Ubuntu artful and Debian experimental. > > For some reasons the _static directory is not copied correctly during doc > generation, > and the build fails because of a missing symlink > > dh_installdocs -O--buildsystem=pybuild > dh_sphinxdoc -O--buildsystem=pybuild > dh_sphinxdoc: > debian/python-dask-doc/usr/share/doc/python-dask-doc/html/_static/mathjax/MathJax.js > is missing > debian/rules:5: recipe for target 'binary' failed > > Can you please have a look and reassing back in case? The documentation says that files and directories are copied; it does not say anything about the symlinks. So it looks to me that dask was using undocumented behavior here. Also, it seems that mathjax is not actually used, so I am attaching a debdiff to get rid of it (also uploaded to Ubuntu and forwarded). -- Dmitry Shachnev --- dask-0.12.0/debian/control 2016-12-07 21:54:28.0 +0300 +++ dask-0.12.0/debian/control 2017-05-01 20:53:17.0 +0300 @@ -4,7 +4,6 @@ Priority: optional Build-Depends: debhelper (>= 9), dh-python, - libjs-mathjax, python3-all, python3-cloudpickle (>= 0.2.1), python3-numpy, --- dask-0.12.0/debian/patches/no-mathjax-extension.patch 1970-01-01 03:00:00.0 +0300 +++ dask-0.12.0/debian/patches/no-mathjax-extension.patch 2017-05-01 20:53:17.0 +0300 @@ -0,0 +1,16 @@ +Description: drop sphinx.ext.mathjax extension, it is unused +Author: Dmitry Shachnev <mity...@debian.org> +Forwarded: https://github.com/dask/dask/pull/2280 +Last-Update: 2017-05-01 + +--- a/docs/source/conf.py b/docs/source/conf.py +@@ -25,7 +25,7 @@ + + # Add any Sphinx extension module names here, as strings. They can be extensions + # coming with Sphinx (named 'sphinx.ext.*') or your custom ones. +-extensions = ['sphinx.ext.autodoc', 'sphinx.ext.mathjax', ++extensions = ['sphinx.ext.autodoc', + 'sphinx.ext.autosummary', 'sphinx.ext.extlinks', 'numpydoc'] + + numpydoc_show_class_members = False --- dask-0.12.0/debian/patches/series 2016-12-07 21:54:28.0 +0300 +++ dask-0.12.0/debian/patches/series 2017-05-01 20:53:17.0 +0300 @@ -1 +1 @@ -use-mathjax-package.patch +no-mathjax-extension.patch --- dask-0.12.0/debian/patches/use-mathjax-package.patch 2016-12-07 21:54:28.0 +0300 +++ dask-0.12.0/debian/patches/use-mathjax-package.patch 1970-01-01 03:00:00.0 +0300 @@ -1,14 +0,0 @@ -Author: Diane Trout <di...@ghic.org> -Description: Use locally installed MathJax - a/docs/source/conf.py -+++ b/docs/source/conf.py -@@ -28,6 +28,8 @@ - extensions = ['sphinx.ext.autodoc', 'sphinx.ext.mathjax', - 'sphinx.ext.autosummary', 'sphinx.ext.extlinks', 'numpydoc'] - -+mathjax_path = 'mathjax/MathJax.js?config=TeX-AMS-MML_HTMLorMML' -+ - numpydoc_show_class_members = False - - # Add any paths that contain templates here, relative to this directory. --- dask-0.12.0/debian/rules 2016-12-07 21:54:28.0 +0300 +++ dask-0.12.0/debian/rules 2017-05-01 20:51:58.0 +0300 @@ -8,12 +8,10 @@ override_dh_auto_build: export https_proxy=127.0.0.1:9 override_dh_auto_build: dh_auto_build - ln -s /usr/share/javascript/mathjax docs/source/_static PYTHONPATH=. sphinx-build -N -bhtml docs/source build/html # HTML generator override_dh_auto_clean: dh_auto_clean - -rm docs/source/_static/mathjax # Test needs: skimage, scipy, s3fs, cachey, distributed, graphviz # dask is a build-dep for distributed... so we can't run tests at build signature.asc Description: 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#857510: wand-doc, sphinx: broken symlink: /usr/share/doc/wand-doc/html/_static/websupport.js -> ../../../../javascript/sphinxdoc/1.0/websupport.js
Control: reassign -1 wand-doc 0.4.4-1.1
Control: tags -1 +patch
Hi Andreas,
On Sun, Mar 12, 2017 at 04:06:37AM +0100, Andreas Beckmann wrote:
> 0m21.5s ERROR: FAIL: Broken symlinks:
> /usr/share/doc/wand-doc/html/_static/websupport.js ->
> ../../../../javascript/sphinxdoc/1.0/websupport.js
>
> There is no .../javascript/sphinxdoc/1.0/websupport.js in
> libjs-sphinxdoc ...
> therefore assigning the bug to both wand and sphinx.
>
> I have *not* looked at the wand source package to determine whether
> wand or sphinx is responsible for the broken symlink.
This package is not using dh_sphinxdoc, but it is rather linking the files
manually (and wrongly), therefore it is not a bug in sphinx.
I am attaching a patch for wand to use dh_sphinxdoc, which fixes this issue.
The devhelp build is incomplete compared to HTML build (it lacks
searchindex.js), so in order to make dh_sphinxdoc recognize it, I needed
to do both HTML and devhelp builds.
--
Dmitry Shachnev
diff -Nru wand-0.4.4/debian/changelog wand-0.4.4/debian/changelog
--- wand-0.4.4/debian/changelog 2017-01-11 12:15:07.0 +0300
+++ wand-0.4.4/debian/changelog 2017-03-15 13:03:50.0 +0300
@@ -1,3 +1,9 @@
+wand (0.4.4-1.2) UNRELEASED; urgency=medium
+
+ * Use dh-sphinxdoc instead of broken hardcoded linking (Closes: #857510).
+
+ -- Dmitry Shachnev <mity...@debian.org> Wed, 15 Mar 2017 13:03:50 +0300
+
wand (0.4.4-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru wand-0.4.4/debian/control wand-0.4.4/debian/control
--- wand-0.4.4/debian/control 2017-01-11 12:14:15.0 +0300
+++ wand-0.4.4/debian/control 2017-03-15 13:03:18.0 +0300
@@ -70,7 +70,7 @@
Architecture: all
Section: doc
Depends: ${misc:Depends},
- libjs-sphinxdoc,
+ ${sphinxdoc:Depends},
Suggests: python-wand
Description: Python interface for ImageMagick library - documentation
Wand is a ctypes-based simple ImageMagick binding for Python. It
diff -Nru wand-0.4.4/debian/rules wand-0.4.4/debian/rules
--- wand-0.4.4/debian/rules 2016-11-06 12:02:18.0 +0300
+++ wand-0.4.4/debian/rules 2017-03-15 13:03:50.0 +0300
@@ -3,7 +3,7 @@
export PYBUILD_NAME=wand
%:
- dh $@ --buildsystem=pybuild --with python2,python3,pypy
+ dh $@ --buildsystem=pybuild --with python2,python3,pypy,sphinxdoc
.PHONY: build_doc clean_doc
@@ -27,6 +27,7 @@
#dh_auto_test
build_doc:
+ $(MAKE) -C $(CURDIR)/docs html
$(MAKE) -C $(CURDIR)/docs devhelp
clean_doc:
diff -Nru wand-0.4.4/debian/wand-doc.install wand-0.4.4/debian/wand-doc.install
--- wand-0.4.4/debian/wand-doc.install 2016-11-06 12:02:18.0 +0300
+++ wand-0.4.4/debian/wand-doc.install 2017-03-15 13:03:50.0 +0300
@@ -1 +1,2 @@
-docs/_build/devhelp/* usr/share/doc/wand-doc/html/
+docs/_build/html/* usr/share/doc/wand-doc/html/
+docs/_build/devhelp/Wand.devhelp.gz usr/share/doc/wand-doc/html/
diff -Nru wand-0.4.4/debian/wand-doc.links wand-0.4.4/debian/wand-doc.links
--- wand-0.4.4/debian/wand-doc.links 2016-11-06 12:02:18.0 +0300
+++ wand-0.4.4/debian/wand-doc.links 2017-03-15 13:03:05.0 +0300
@@ -2,9 +2,3 @@
usr/share/doc/wand-doc/html usr/share/doc/pypy-wand/html
usr/share/doc/wand-doc/html usr/share/doc/python-wand/html
usr/share/doc/wand-doc/html usr/share/doc/python3-wand/html
-usr/share/javascript/sphinxdoc/1.0/doctools.js usr/share/doc/wand-doc/html/_static/doctools.js
-usr/share/javascript/sphinxdoc/1.0/jquery.js usr/share/doc/wand-doc/html/_static/jquery.js
-usr/share/javascript/sphinxdoc/1.0/searchtools.js usr/share/doc/wand-doc/html/_static/searchtools.js
-usr/share/javascript/sphinxdoc/1.0/sidebar.js usr/share/doc/wand-doc/html/_static/sidebar.js
-usr/share/javascript/sphinxdoc/1.0/underscore.js usr/share/doc/wand-doc/html/_static/underscore.js
-usr/share/javascript/sphinxdoc/1.0/websupport.js usr/share/doc/wand-doc/html/_static/websupport.js
signature.asc
Description: 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
Re: [Python-modules-team] Bug#812768: python-whoosh: diff for NMU version 2.7.0-1.1
Hi all, On Mon, Jan 30, 2017 at 08:21:20AM +, Simon McVittie wrote: > [...] > > sphinx maintainers, celery-haystack maintainers: your packages build-depend > on python-whoosh. How important is it for those packages? Do you want to > adopt it? python-whoosh is not important at all for Sphinx, it is just one of the search backends for Sphinx websupport extension. I think I already maintain too many packages that I am not interested in, and I don’t have time to adopt another one. -- Dmitry Shachnev signature.asc Description: 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#739300: dh_sphinxdoc: Please replace MathJax.js with links to the packaged libjs-mathjax
Hi Ximin! On Sat, Dec 03, 2016 at 01:49:00AM +, Ximin Luo wrote: > Could dh_sphinxdoc not scan the html files for
[Python-modules-team] Bug#836248: Re-open
Hi Neil, I saw your previous reply after I sent mine, sorry for that. On Thu, Nov 03, 2016 at 09:35:42PM +, Neil Williams wrote: > > The original bug was asking about Alabaster, which is the default > > theme, and thus much more popular than the bootstrap theme. > > The bug mentioned python3-alabaster which comes from the alabaster > source package, not sphinx. Currently at versio 0.7.8-1 - that's why I > thought it could relate to themes packaged separately from sphinx > itself. i.e.: > > Built-Using: python3-alabaster (= foo) Alabaster comes from a separate source package, but it is the default theme for Sphinx. That's why I added support for it. > Correcting for the misconception about binary vs source package, my > expectation of the original bug report was that the fix would allow the > package to contain: > > Built-Using: alabaster (= 0.7.8-1) > > python-sphinx depends on python-alabaster in unstable but not in > jessie. The source package is still separate though and building docs > using alabaster doesn't create a dependency on python-alabaster. > > The current helper produces > > Built-Using: sphinx (= 1.4.8-1) > > That seems inaccurate to me as the files come from a dependency of > sphinx? Or is this only meant to relate to files in libjs-sphinxdoc? For packages using alabaster, it should list both sphinx and alabaster in sphinxdoc:Built-Using. For which package is it not the case? Sphinx should be listed there because all documentation packages produced by Sphinx contain i.e. _static/basic.css file, which is generated from basic.css_t in Sphinx source. > > I can try to detect whether the documentation contains embedded > > CSS/JS files from any theme, but that would be quite complicated. The > > only way that comes to my mind is comparing the file names in the > > theme package (extracted from build-dependencies) and in the built > > package, and searching for *_t → * renamings. > > > > However, this sounds like a huge hack to me, so I am not sure I want > > to do this. > > The theme needs to be specified in the conf.py and the package > providing it needs to be installed for the theme to be active, isn't > there a way of mapping that instead of looking at the output files? Finding and parsing the conf.py is an even more complicate task :) dh_sphinxdoc is not using any of Sphinx code, in fact, it is even written in Perl and not in Python. > > In your particular case (lava-server-doc), you have the JS, CSS and > > fonts files not symlinking, which sounds like a much bigger issue for > > me. In dh_sphinxdoc, I cannot support every existing Sphinx theme, so > > you need to symlink these files manually. > > > In lava-server-doc, there are > 5 MB of files that can be symlinked, > > and only two files (8.1 kB) that are generated from templates, so I > > don't even think it makes sense to care about them. > > Specifically about lava-server-doc, there is duplication because we're > migrating to a whole new model. We expect to drop the v1 directory > during 2017. I did not mean duplication *within* lava-server-doc. I meant that the files in lava-server-doc can be links to files in python[3]-sphinx-bootstrap-theme. I.e. /usr/share/doc/lava-server-doc/html/v2/_static/bootstrap-2.3.2/ → /usr/lib/python2.7/dist-packages/sphinx_bootstrap_theme/bootstrap/static/bootswatch-2.3.2/ and /usr/share/doc/lava-server-doc/html/v2/_static/bootswatch-3.3.4/ → /usr/lib/python2.7/dist-packages/sphinx_bootstrap_theme/bootstrap/static/bootswatch-3.3.4/ Having such links would eliminate most of the need for using the Built-Using field. (Also, it would be a good idea to ask sphinx-bootstrap-theme maintainer to use some interpreter-independent location for the static files, something in /usr/share, like I do with my python-sphinx-rtd-theme package. That would make it easier to symlink stuff.) > Thanks. The process of building from the theme is quite opaque - it's > not clear whether Built-Using: sphinx (= 1.4.8-1) is accurate for a > package using an external theme. Some help in the manpage would be > appreciated to clarify things like which files need to be symlinked to > the theme package and why Built-Using should refer to sphinx and not > the theme. I am bad at documenting things, but I will try to do my best here. -- Dmitry Shachnev signature.asc Description: 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#836248: Re-open
Hi Neil,
On Thu, Nov 03, 2016 at 06:37:23PM +, Neil Williams wrote:
> [...]
>
> That results in a package containing:
>
> Built-Using: python-sphinx-bootstrap-theme, sphinx (= 1.4.8-1)
>
> The problem with that is:
> $ apt-cache show sphinx
> N: Unable to locate package sphinx
> E: No packages found
>
> So dh_sphinxdoc should be putting in python-sphinx (= 1.4.8-1)
No. Let me quite the Debian Policy § 7.8 (the emphasis is mine):
A Built-Using field must list the corresponding *source* package for any
such binary package incorporated during the build […]
> Also, wasn't the original intention from the bug report that I'd be
> able to use it as:
>
> Built-Using: python-sphinx-bootstrap-theme (= ${sphinxdoc:Built-Using})
>
> [...]
>
> It's the theme which adds the CSS. Having Built-Using for sphinx is
> fine but the version of the theme is unrelated to the version of sphinx.
The original bug was asking about Alabaster, which is the default theme,
and thus much more popular than the bootstrap theme.
I can try to detect whether the documentation contains embedded CSS/JS files
from any theme, but that would be quite complicated. The only way that comes
to my mind is comparing the file names in the theme package (extracted from
build-dependencies) and in the built package, and searching for *_t → *
renamings.
However, this sounds like a huge hack to me, so I am not sure I want to do
this.
In your particular case (lava-server-doc), you have the JS, CSS and fonts
files not symlinking, which sounds like a much bigger issue for me.
In dh_sphinxdoc, I cannot support every existing Sphinx theme, so you need
to symlink these files manually.
In lava-server-doc, there are > 5 MB of files that can be symlinked, and
only two files (8.1 kB) that are generated from templates, so I don't even
think it makes sense to care about them.
> Finally, can we have some documentation of how to use
> ${sphinxdoc:Built-Using} in man dh_sphinxdoc please?
Leaving this bug open for this part of your message.
--
Dmitry Shachnev
signature.asc
Description: 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#842903: sphinx: Cirular build dependency on python3-xapian
Hi, On Wed, Nov 02, 2016 at 10:04:17AM +0200, Al Nikolov wrote: > Dear Maintainer, > > You introduced new build dependencies on python-xapian and python3-xapian. > > The source of them, xapian-bindings, has python-sphinx and python3-sphinx > among it's own build dependencies. The build-dependency on python-xapian is not new, Sphinx has it since 2011 (see the changelog entry for 1.1.2+dfsg-1). However, I only need it for tests, so it is safe to remove (and I can add it to the autopkgtests to make sure nothing breaks when Xapian is upgraded). -- Dmitry Shachnev signature.asc Description: 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#818115: turn python-sphinx into an arch:any package
Hi Helmut, On Thu, Oct 20, 2016 at 09:09:03PM +0200, Helmut Grohne wrote: > Hi Dmitry, > > I'm still kinda split about this. I discussed this with Guillem Jover > and Ian Jackson at length to avoid that step and still don't like it. Same for me. > > Do you have any use cases where the documentation should be built in > > build-arch target, rather than build-indep (which is only run for arch-indep > > builds)? > > Unfortunately, yes. python-sphinx has ~700 build-rdeps. We can simply > under approximate those that need python-sphinx during build-arch by > ignoring all packages that build architecture independent packages. That > leaves at least 25 affected packages: > > axe-demultiplexer buildbot cvxopt lava-dispatcher liblognorm mayavi2 > minieigen mydumper pathspider portabase py-postgresql pyalsaaudio > pynifti python-brainstorm python-chaco python-enable python-prctl > python-srp python-traits salmon squirrel3 trafficserver tsung urwid > vmdebootstrap To be honest, I think 25 (of ~700) is a small enough number. > Of these, liblognorm is a high popcon package that specifically fails > cross building, because its python-sphinx dependency is cross > unsatisfiable. > > If we can avoid turning python-sphinx Arch:any, then I'm all for it. So > which route shall we pursue now? I basically see three: > * Split documentation packages out of the above. > * Turn python-sphinx arch:any and annotate python-sphinx dependencies >with :native. > * Change dependency resolution in general. Update dpkg, apt, dose3. For >instance allowing :native annotations on Arch:all packages would >suffice. > > Indeed, I do like moving documentation to Arch:all packages, but I'm not > sure we want even more small binary packages. It usually does make sense to split the documentation. One reason for it is to avoid dependency of the main package on JS stuff like jQuery and underscore. Another reason, for non-Python packages, is to allow “light” builds without documentation (and without Sphinx/Python B-D) if the “nodoc” build profile is used. So I think the first option is not so bad as it may seem. I cannot tell anything about the other two options, you probably know better than me whether they are realistic or not. -- Dmitry Shachnev signature.asc Description: 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#840658: shadows builtin rst.el library
On Thu, Oct 20, 2016 at 10:12:02AM -0400, Antoine Beaupré wrote: > On 2016-10-20 09:46:32, Dmitry Shachnev wrote: > > Will it suit you if I just update the package to include the latest version > > of rst.el from upstream trunk? > > Well, I don't mind for sure - it would be nice to have that updated. > > But what I am concerned about is duplication between the two > packages. Either this is a bug in emacs24-el, or it's a bug in docutils, > but both packages shouldn't provide the same library, no? I think that if this file is developed as part of Docutils project, then it should be shipped by docutils package. That said, please feel free to file a bug against emacs24-el (or clone this one), saying that it should not ship rst.el. -- Dmitry Shachnev signature.asc Description: 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#840658: shadows builtin rst.el library
Hi Antoine, and thanks for your bug report. On Thu, Oct 13, 2016 at 11:37:20AM -0400, Antoine Beaupré wrote: > i am told that rst.el is distributed with Emacs since > v23.1. Unfortunately, it seems that if you have docutils-common *and* > emacs24-common, you have *two* versions of this package installed: > > $ dpkg -S rst.el > emacs24-el: /usr/share/emacs/24.4/lisp/textmodes/rst.el.gz > emacs24-common: /usr/share/emacs/24.4/lisp/textmodes/rst.elc > docutils-common: /usr/share/emacs/site-lisp/rst.el > > That seems strange to me: shouldn't there be only one rst.el mode out > there? > > I would understand if one would be a symlink to the other, or > something similar, but they are actually distinct versions: > > $ diff -u /usr/share/emacs/site-lisp/rst.el <(gunzip -c > /usr/share/emacs/24.4/lisp/textmodes/rst.el.gz)| head > --- /usr/share/emacs/site-lisp/rst.el 2014-08-03 21:24:43.0 -0400 > +++ /dev/fd/632016-10-13 11:34:54.258665200 -0400 > @@ -1,6 +1,6 @@ > ;;; rst.el --- Mode for viewing and editing reStructuredText-documents. > > -;; Copyright (C) 2003-2012 Free Software Foundation, Inc. > +;; Copyright (C) 2003-2014 Free Software Foundation, Inc. > > ;; Maintainer: Stefan Merten <smer...@oekonux.de> > ;; Author: Stefan Merten <smer...@oekonux.de>, > > This leads me to believe the one shipped with this package is also > outdated. > > I would recommend simply not shipping rst.el anymore. While the current docutils package in Debian indeed ships a quite dated version of rst.el, the docutils upstream trunk has a newer version, and it is even newer than what emacs ships (it is version 1.5, released this year). Speaking in terms of your diff, it has copyright 2003-2016 [0]. Also, all the current development happens in upstream docutils project [1], and the new releases are announced on docutils-users mailing list [2]. So I think docutils is still the right package to ship rst.el. Will it suit you if I just update the package to include the latest version of rst.el from upstream trunk? [0]: https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/tools/editors/emacs/rst.el [1]: https://sourceforge.net/p/docutils/code/HEAD/log/?path=/trunk/docutils/tools/editors/emacs/rst.el [2]: https://sourceforge.net/p/docutils/mailman/message/35252938/ -- Dmitry Shachnev signature.asc Description: 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#818115: turn python-sphinx into an arch:any package
Hi Johannes, On Tue, Oct 18, 2016 at 09:26:36AM +0200, Johannes Schauer wrote: > I just built src:sphinx on all porter boxes of release architectures. Thanks for this effort, I appreciate it regardless of status of this bug. > The only FTBFS I observed was on mips and the problem on mips went away with > the following patch: > [...] > > It is also important to notice, that the problem was not reproducible. When I > built the package again (without modifications) the test suite finished > successfully. It the problem is unreproducible and happens on only one architecture, I would just ignore it. > But it seems that (unless the above is a result of said webkit segfault) the > webkit issue went away [...] It did not go away, I just disabled running the jstests during build in this commit: https://anonscm.debian.org/cgit/python-modules/packages/sphinx.git/commit/?id=185f91d17037bfb9 > [...] and only this issue remains the sole blocker of making > python-sphinx Architecture:any. So are you also interested in me making Sphinx architecture:any? Do you have any use cases where the documentation should be built in build-arch target, rather than build-indep (which is only run for arch-indep builds)? -- Dmitry Shachnev signature.asc Description: 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#841141: /usr/bin/dh_sphinxdoc: dh_sphinxdoc doesn't recognise search pages with nonstandard paths
Hi Ximin,
On Tue, Oct 18, 2016 at 01:42:56AM +0200, Ximin Luo wrote:
> SageMath generates docs with search indexes like this:
>
> jQuery(function() { Search.loadIndex("../searchindex.js"); });
>
> This is not recognised by dh_sphinxdoc. If you change
>
> 192: my $loads_searchindex = $search =~ m/\QjQuery(function() {
> Search.loadIndex("searchindex.js"); });\E/;
>
> to
>
> 192: my $loads_searchindex = $search =~ m/\QjQuery(function() {
> Search.loadIndex("\E([^\/]*\/)?\Qsearchindex.js"); });\E/;
>
> it will fix the problem.
Thanks for catching this. According to the template, the path can be
arbitrary, so I went further and disabled the path check at all (left
only the check for loadIndex(...) call).
Do you want me to do a new upload now, or this can wait?
--
Dmitry Shachnev
signature.asc
Description: 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#831779: python-docutils: please make the output of rst2man reproducible
Hi Chris, On Mon, Oct 10, 2016 at 11:12:45AM +0100, Chris Lamb wrote: > Dear Maintainer, > > Looks like there has been some discussion upstream on this issue: > > https://sourceforge.net/p/docutils/patches/132/ Upstream first committed my patch, but then reverted it. If you can join the upstream discussion and give some real world example of where this patch can be useful, it would help a lot. -- Dmitry Shachnev signature.asc Description: 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
Re: [Python-modules-team] python-imagesize_0.7.1-1~bpo8+1
Hi, On Mon, Oct 03, 2016 at 07:45:36PM +0300, Al Nikolov wrote: > Hello, > > Please be aware that I'm uploading this backport into NEW. I need it to > update sphinx backport. Thanks for your work! Please be aware that I have uploaded new Sphinx to unstable today, which has a build-dependency on python3-xapian. That is needed only for tests and can be safely dropped when backporting. Please push the tag to the packaging repository if you have write access to DPMT namespace. -- Dmitry Shachnev signature.asc Description: 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#838646: sphinxcontrib-docbookrestapi: FTBFS: ImportError: Failed to import test module: test_utils
Hi Santiago,
It looks like python-tidylib should use ctypes.util.find_library('tidy') rather
than a hard-coded list of sonames.
I will be able to upload the fixed python-tidylib in a couple of days.
On September 23, 2016 2:26:31 PM GMT+03:00, Santiago Vila <sanv...@unex.es>
wrote:
> I filed a bug like this today in python-markdown:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838646
>
> It's similar in the "Could not load libtidy" part, so probably neither
> sphinxcontrib-docbookrestapi or python-markdown are to blame here but
> maybe some of their build-dependencies.
>
> I'm Cc:ing both bugs in the hope that some python expert may know the
> real reason for this (if they are really the "same" bug).
--
Dmitry Shachnev
___
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#795976: reopening 795976
Hi Jelmer, On Sun, May 15, 2016 at 06:29:21PM +, Jelmer Vernooij wrote: > reopen 795976 > thanks Should this bug be still open? Sphinx build should be reproducible. It FTBFS on reproducible-builds.org because of some problem with WebKit, but that is an unrelated issue, and I have disabled the tests in the current packaging Git. -- Dmitry Shachnev signature.asc Description: 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#834875: regression: qsettings can no longer save binary strings
On Sun, Aug 28, 2016 at 06:54:35PM +0200, Salvo Tomaselli wrote: > But now, to work around it, relational pickles and then encodes to > base64 before storing to QSettings. That is quite a bad work-around. If your upstream wants to support PyQt v5.7 (as released upstream), it is better to wrap the value in QByteArray. -- Dmitry Shachnev signature.asc Description: 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#836248: /usr/bin/dh_sphinxdoc: please provide substvar for Built-Using
Hi Sean, On Wed, Aug 31, 2016 at 07:12:04PM -0700, Sean Whitton wrote: > If a package installs sphinx documentation then it can embed code from > sphinx themes, such as python3-alabaster. That means it needs a > "Built-Using: python3-alabaster (= foo)". dh_sphinxdoc could provide a > substvar for this purpose. This makes sense. I will implement it when I have time. In fact it affects not only Alabaster, but most other themes too (like Sphinx' own built-in basic.css). > (Is there some reason why the copy of the theme is not turned into > symlinks by dh_sphinxdoc, as embedded javascript is?) alabaster.css is generated from the template, so the resulting files may vary from package to package. If you open /usr/lib/python3/dist-packages/alabaster/static/alabaster.css_t you will see quite a lot template code there which will be replaced in actual packages. -- Dmitry Shachnev signature.asc Description: 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#834875: regression: qsettings can no longer save binary strings
Hi Salvo, On Sat, Aug 20, 2016 at 09:18:51AM +0200, Salvo Tomaselli wrote: > in relational, I store the session as a binary string generated with the > pickle > module and save it using QSettings. > > now the functionality is broken, without changing the code in relational, so > it is a regression in Qt or PyQt. Now this is fixed. However storing pickled strings in QSettings usually does not make much sense. When a non-Qt object (such as bytes) is stored in QSettings, it gets pickled by PyQt. So in your case there will be double pickling. You can either store the object directly, or wrap the bytestring into a QtCore.QByteArray (which is a native Qt object). -- Dmitry Shachnev signature.asc Description: 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#833820: sphinx: Avoid evaulating default function arguments when including them in the documentation
Control: forwarded -1 https://github.com/sphinx-doc/sphinx/issues/2844 Hi Petter, On Tue, Aug 09, 2016 at 01:08:23AM +0200, Petter Reinholdtsen wrote: > Hi. The documentation generated by sphinx expands default python > arguments instead of reproducing the values listed in the source. Thanks for the bug report. Indeed such behavior is not only breaking the reproducible builds, but also a bit misleading. However I think this may be non-trivial to fix, as Sphinx tries to import the module, rather than parse it, and Python evaluates the arguments during module import. The same result (evaluated argument) can be seen if you call the built-in help() against that function. Speaking about your example, I would recommend against using such functions at all: the default argument of that function is module *import* time, not the actual time when it is executed; this is not what one may expect. In any case, I have forwarded this bug to upstream developers, let's see what they think about it. -- Dmitry Shachnev signature.asc Description: 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#833791: dh_sphinxdoc: Fails to recognise Sphinx-generated documentation
Hi Ben,
On Tue, Aug 09, 2016 at 03:15:49AM +1000, Ben Finney wrote:
> > On Tue, Aug 09, 2016 at 02:47:23AM +1000, Ben Finney wrote:
> > > $ dh_sphinxdoc doc/_build/html
> > > dh_sphinxdoc: Sphinx documentation not found at doc/_build/html/
> >
> > This command does not make any sense. dh_sphinxdoc operates on
> > *installed* documentation
>
> As can be seen from the session in the original message, the
> documentation is installed. (It is built by the upstream build system,
> and that's the default location.)
Hm, upstream build system will not install it into the Debian package tree,
it is a task of dh_installdocs.
There is no sense calling dh_sphinxdoc before the documentation is in
debian/{packagename}/usr/share/doc/ because the symlinks created by
dh_sphinxdoc are relative and will be broken in this case.
So you should:
1) add the debian/{packagename}.docs file to get the documentation installed
by dh_sphinxdoc (you can put doc/_build/html into that file)
2) only after that call dh_sphinxdoc (probably with no arguments)
> > and looks for files in debian/{packagename}/ directories.
>
> Yes, that's why I'm specifying the location where the documentation
> was actually installed by the upstream build system.
If you specify /some/path as an argument, dh_sphinxdoc will be looking in
debian/{packagename}/some/path (for one or multiple packages).
> Its error message even reports the very directory where it looked, and
> claims it can't find documentation that evidently exists there.
I agree the error message is a bit misleading, but this is not what you
have been complaining about.
If you still have this bug after installing the documentation into the proper
directory, please give me a link to your package so that I can look at it.
--
Dmitry Shachnev
signature.asc
Description: 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#833791: dh_sphinxdoc: Fails to recognise Sphinx-generated documentation
Hi Ben,
On Tue, Aug 09, 2016 at 02:47:23AM +1000, Ben Finney wrote:
> The ‘dh_sphinxdoc’ command is failing to detect Sphinx-generated
> documentation:
>
> [...]
>
> $ dh_sphinxdoc doc/_build/html
> dh_sphinxdoc: Sphinx documentation not found at doc/_build/html/
This command does not make any sense. dh_sphinxdoc operates on *installed*
documentation, and looks for files in debian/{packagename}/ directories.
(or debian/tmp/ when there is only one binary package).
Passing the path is usually not necessary (just calling it with no arguments
after the files are installed is enough), but when you pass the path, it
should be relative to the installation root directory.
--
Dmitry Shachnev
signature.asc
Description: 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#831779: python-docutils: please make the output of rst2man reproducible
Hi Chris, On Thu, Jul 21, 2016 at 11:08:50AM +0200, Chris Lamb wrote: > > Can you please forward it upstream to [1], or do you want me to do that? > > Please go ahead and do that. :) Done at https://sourceforge.net/p/docutils/patches/132/. We are having some interesting discussion there, please feel free to follow up if you are on SourceForge. I will do a new upload once we get some agreement with upstream on this. -- Dmitry Shachnev signature.asc Description: 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#831779: python-docutils: please make the output of rst2man reproducible
Hi Chris, On Tue, Jul 19, 2016 at 12:39:32PM +0200, Chris Lamb wrote: > Whilst working on the "reproducible builds" effort [0], we noticed > that python-docutils generates non-reproducible output via rst2man. > > Patch attached. Thanks for the patch! Can you please forward it upstream to [1], or do you want me to do that? [1]: https://sourceforge.net/p/docutils/patches/ -- Dmitry Shachnev signature.asc Description: 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
Re: [Python-modules-team] RM of shiboken & pyside ?
Hi Didier and Scott, On July 6, 2016 7:32:22 AM GMT+03:00, Scott Kitterman <deb...@kitterman.com> wrote: > 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 It is not dead according to Git activity: https://code.qt.io/cgit/pyside/shiboken.git/ https://code.qt.io/cgit/pyside/pyside.git/ PyOtherSide is a project with different functionality, so having it is not a reason for removing PySide. However we have PyQt5, and that can count as such reason. -- Dmitry Shachnev ___ 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
Hi Sebastiaan, On Tue, May 24, 2016 at 04:23:50PM +0200, Bas Couwenberg wrote: > The freeze is not until early next year, and the initial plan for removal > from python-qt4 was early 2016, we're almost 6 months in now. > > So if I can make a request, please upload python-qt4 as soon as possible, so > we can use the remaining time until the freeze to get QGIS working without > WebKit in python-qt4 as well as possible. Sure, I will upload the build without WebKit ASAP. Thanks for giving me the green light from your side :) -- Dmitry Shachnev signature.asc Description: 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#784513: qtwebkit removal from python-qt4
Hi Sebastiaan, On Tue, May 24, 2016 at 01:07:49AM +0200, Sebastiaan Couwenberg wrote: > On Mon, 07 Dec 2015 21:31:42 +0300 Dmitry Shachnev wrote: > > I am going to remove qtwebkit support from python-qt4 package in an upload > > in > > early 2015 (but not before January 7th, one month from now). > > Will these changes be uploaded any time soon? It was delayed only because of QGIS. > As long as the WebKit support remains available in the Qt4 packages, > QGIS upstream is reluctant to deal with its planned removal. The best > way to get them to address issues is to break their builds unfortunately. > > #825091 is the first issue caused by disabling QtWebKit support and I'd > like upstreams help to resolve it. WebKit support will definitely be removed from PyQt4 before Stretch freeze. It will be *probably* removed from Qt4, but that depends on how many rdepends are remaining. There is already WebKit support in Qt5/PyQt5 which is not going to be removed any time soon. -- Dmitry Shachnev signature.asc Description: 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#824611: Nagstamon bug
Control: reassign -1 nagstamon 1.0.1-1 Hi Florian, On Wed, May 18, 2016 at 04:13:46PM +0200, Florian Bruhin wrote: > This is actually a bug in Nagstamon, discovered by PyQt getting > stricter about correct @pyqtSlot signatures. Thanks for tracking down this issue, I am reassigning the bug accordingly. -- Dmitry Shachnev signature.asc Description: 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#824375: Please update to latest upstream
Control: tags -1 +pending Hi Julien, On Sun, May 15, 2016 at 07:57:21AM +0200, Julien Puydt wrote: > Hi, > > could you please upgrade to latest upstream? The packaging is already available in Git, I want upstream to review my pull request [1] before doing the upload though. Also, the upload will target experimental first. Anything in particular you want from the new release? If it's easily backportable to 1.3, it may be faster to go that route instead. [1]: https://github.com/sphinx-doc/sphinx/pull/2532 -- Dmitry Shachnev signature.asc Description: 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#818115: turn python-sphinx into an arch:any package
Hi Helmut, On Thu, May 12, 2016 at 08:40:00PM +0200, Helmut Grohne wrote: >> 161 is many packages, though in my opinion splitting the documentation into >> arch:all packages is something that should be done independently of this bug. >> Maybe we can have some kind of DD list whose packages are affected by this? >> (Or a Lintian warning, see below.) > > Computing this list in an automated way is difficult, because > build-rdeps has no way of ignoring Build-Depends-Indep (even though the > underlying dose can do that, though not in unstable as Johannes just > told me). reverse-depends -b src:sphinx [1] returns multiple lists for B-D and B-D-I, but a *huge* part of the B-D group is packages that don't have arch-dep stuff at all (i.e. pure Python packages). [1] where reverse-depends is from ubuntu-dev-tools > This is not as clear cut. Sometimes documentation is small. We tend to > not split out every single bit of documentation into arch:all packages. > To the contrary, manual pages tend to be included with the main package. > I do not see consensus for this increase in the number of binary > packages. Right, but we were talking about the solutions to cross issues... > If the dh addon is not to be used, you should deprecate it. I actually > find the addon useful, because it removes complexity (unless you do > [1]). In an ideal world, we would maybe say "dh $@ --with-indep sphinx"? I won't deprecate it because Sphinx was developed for Python and most Python packages don't have any arch-specific stuff at all, so for them --with sphinxdoc works fine. A --with-indep option would be nice indeed :) > > Alternatively, as you suggest, such packages may build-depend on > > sphinx-common > > and I may mark sphinx-common as Muili-Arch: foreign. If it helps then I will > > do that. > > It's the simplest workaround that I see. Of course, people need to > remember to Build-Depend on sphinx-common to use the addon, which is > complexity of its own. If we pursue that road, we should document it > precisely (e.g. README.Debian?). So should I go ahead and add M-A: foreign attribute to sphinx-common? I can also document it in README.Debian but I am not sure I will find proper wording to describe the problem. Maybe you can help me with that? If you could do that, then I'll be able to describe the solution myself. -- Dmitry Shachnev signature.asc Description: 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#818115: turn python-sphinx into an arch:any package
Hi Helmut, On Mon, Mar 14, 2016 at 07:05:11AM +0100, Helmut Grohne wrote: > Hi Dmitry, > > Thank you for your quick and insightful reply. As you can see, I don't always reply quickly. Sorry for the delay this time. > Cross building only applied to arch-dep packages. So in jansson's case, > it is not about libjansson-doc, but about the other packages. The only > part of sphinx that is actually used during a cross build of jansson > actually is the debhelper addon, which actually lives in sphinx-common > and is exposed by python-sphinx. In a very similar case, Tomasz Buchert > was able to move python-sphinx from Build-Depends to Build-Depends-Indep > in nghttp2[1]. So looking at this closer again, a potential solution for > sphinx could be: > > * Mark sphinx-common Multi-Arch: foreign. > * Move python-sphinx from jansson's Build-Depends to >Build-Depends-Indep. > * Add sphinx-common to jansson's Build-Depends. > > I didn't verify whether these changes are correct. We can try this to > put urgency out of the loop. I like the plan, though the third point can be avoided if dh_sphinxdoc is called only during arch-indep build. > If it were just jansson, I would certainly have spent more time on a > workaround there. But we are talking about 161 source packages[2]. It > seems highly likely that a significant fraction of them do not split > their sphinx generated documentation into Arch:all packages. 161 is many packages, though in my opinion splitting the documentation into arch:all packages is something that should be done independently of this bug. Maybe we can have some kind of DD list whose packages are affected by this? (Or a Lintian warning, see below.) > I do not like the proposed solution at all. That is why I hesitated more > than two years after recognizing that it would indeed fix things before > actually sending a bug. I would certainly love to see a different > solution. I do not like it too... But I will try to do as much as possible from my side to resolve this problem. > Do you have any preferences on the approaches sketched above keeping in > mind that we will apply it to hundreds of packages? In an ideal world, the solution looks this way: 1) Packages shipping Sphinx documentation in arch:any packages should split it into arch:all packages. 2) All packages using Sphinx should make sure dh_sphinxdoc is only called during arch-indep build. For 1), maybe we can have a Lintian warning for that? (i.e. sphinx-documentation-in-architecture-dependent-package) For 2), this means packages having both arch-dep and arch-indep packages won't be able to use --with sphinxdoc because sphinxdoc.pm sequence won't be present during arch:indep build. We can recommend packages to insert it manually then, like: override_dh_installdocs-indep: dh_installdocs -i dh_sphinxdoc -i Alternatively, as you suggest, such packages may build-depend on sphinx-common and I may mark sphinx-common as Muili-Arch: foreign. If it helps then I will do that. -- Dmitry Shachnev signature.asc Description: 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#822827: python3-pyqt5: qt5-5-1 abi dependencies makes install impossible against Qt5.6
Control: notfound -1 5.6 Control: found -1 pyqt5/5.6+dfsg-1 Control: fixed -1 pyqt5/5.6+dfsg-2 Hi Marc, On Wed, Apr 27, 2016 at 05:53:18PM -0700, Marc J. Driftmeyer wrote: > Yet, in Debian we get this: > > python3-pyqt5 depends on qtbase-abi-5-5-1 > qtbase-abi-5-5-1 does not appear to be available > python3-pyqt5 suggests python3-pyqt5-dbg > > I hope this is an oversight. As of now its useless against Qt 5.6.0 which > being in Sid. I have uploaded a PyQt version built against Qt 5.6 to experimental. -- Dmitry Shachnev signature.asc Description: 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#820895: sphinx: please extend SOURCE_DATE_EPOCH support
Hi Alexis, On Wed, Apr 13, 2016 at 03:00:24PM +0200, Alexis Bienvenüe wrote: > The attached patch extends the SOURCE_DATE_EPOCH support in copyright > year and gettext, and corrects copyright strings that does not > corresponds to SOURCE_DATE_EPOCH, so that affected packages can be built > reproducibly without any change. Thanks a lot for your efforts! Can you please submit your patch upstream (like you did it for #822197)? I would really prefer to get this patch reviewed/accepted by upstream before including it in the Debian packaging. (Also, if you will be submitting it, better use stable branch of git rather than master, which will make sure your change will be in the next bugfix release if accepted.) -- Dmitry Shachnev signature.asc Description: 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#820905: python-keyring: ImportError: No module named Gnome
Control: tags -1 +moreinfo Hi Matthieu, On Wed, Apr 13, 2016 at 04:38:26PM +0200, Matthieu Imbert wrote: > Hi, > > python-keyring is broken, at least on my system > > $ python > >>> import keyring > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python2.7/dist-packages/keyring/__init__.py", line 6, in > > from .core import (set_keyring, get_keyring, set_password, get_password, > File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 185, in > > init_backend() > File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 69, in > init_backend > load_config() > File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 139, in > load_config > return load_keyring(keyring_name) > File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 107, in > load_keyring > class_ = _load_keyring_class(keyring_name) > File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 97, in > _load_keyring_class > __import__(module_name) > ImportError: No module named Gnome This is probably because you hardcoded Gnome in Keyring configuration file, however that backend was removed in Keyring 8.x (moved to keyrings.alt package). The recommeneded alternative is to install python-secretstorage and let Keyring use the default secretstorage-based backend instead (which is compatible with GNOME Keyring too). -- Dmitry Shachnev signature.asc Description: 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#739300: Bug#739300: dh_sphinxdoc: Please replace MathJax.js with links to the packaged libjs-mathjax
Hi Sandro, On Sat, Apr 09, 2016 at 01:27:03PM +0100, Sandro Tosi wrote: > Is there any progress on this? I just got bitten by it: > > E: python-cycler-doc: privacy-breach-uses-embedded-file > usr/share/doc/python-cycler-doc/html/_modules/cycler.html You may use > libjs-mathjax package. (https://cdn.mathjax.org/mathjax/latest/mat > hjax.js?config=tex-ams-mml_htmlormml) > > a quick grep on DPMT packages, shows already scipy and networkx has to > manually symlink the file from libjs-mathjax to their local doc dir > > it would be extremely helpful if sphinx could do that for us. As I previously explained in this bug, you will have to replace the MathJax URL in conf.py manually anyway — dh_sphinxdoc can't do that for you. Replacing it with path to packaged MathJax.js is usually enough. If it's not (like when you want to serve the documentation via HTTP), then you can change the URL to something in _static/, and you need *one* line to symlink that to packaged MathJax. Because (in my opinion) this case is quite rare, because the solution is just one line, and also because of potential problems with directory symlinking, I also don't think this is something that could be done in dh_sphinxdoc. I also thought about changing Sphinx's own default to be the packaged URL. However, we only want it for Debian packages only, not for stuff that i.e. upstream developers build using our Sphinx package. But then there is no safe way to determine if Sphinx is called from Debian package build (one may not always be using dpkg-buildpackage or even debhelper, and instead calling sphinx-build manually from build: target in debian/rules). Better ideas are welcome, of course. -- Dmitry Shachnev signature.asc Description: 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#818115: turn python-sphinx into an arch:any package
Hi Helmut, On Sun, Mar 13, 2016 at 09:32:28PM +0100, Helmut Grohne wrote: > [skip] > > So here is a patch: > > sed -i -e '/Package: python3\?-sphinx/,+1s/\(Architecture: a\)ll/\1ny/' > debian/control > > Please apply it, so we can start adding the :native annotation to > reverse dependencies such as jansson #807848. I wonder what's the point of cross-building the arch-indep packages at all? In jansson case, it looks like python-sphinx should be moved from Build-Depends to Build-Depends-Indep, and the arch-any packages will be correctly cross-built without sphinx. If there are other cases except jansson, please let me know. Though I can't imagine how sphinx can be used for building something arch-specific… (Also, if I just apply the change you suggested, sphinx will FTBFS on some archs, because the tests use webkit which segfaults there — so it's a bit more tricky). -- Dmitry Shachnev signature.asc Description: 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#815826: python3-babel: /usr/bin/pybabel-python3 has versioned Python shebang
Package: python3-babel Version: 1.3+dfsg.1-6 Severity: important Dear maintainers, python3-babel currently ships an executable with versioned Python 3 shebang: $ head -n1 /usr/bin/pybabel-python3 #!/usr/bin/python3.4 There is nothing dependent on Python version in python-babel, so it should use just /usr/bin/python3 instead. This is especially wrong when the default Python 3 version in Debian is Python 3.5, and 3.4 is going to be removed (see #815720). One way to fix that is passing --shebang=/usr/bin/python3 to dh_python3. -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#815631: sphinx: Use alternatives to provide scripts under /usr/bin
Hi Kevin, On Tue, Feb 23, 2016 at 11:24:40PM +1100, Kevin Murray wrote: > Ah yes, that's true about hardcoding. This is actually why I need this: > hardcoded occurrences of sphinx-build in makefiles that aren't in python > projects but use (and only work with) python3 packages. And thanks for the tip > about python -m sphinx, I hadn't considered that. Though for the current use > case still means patching a makefile, in which case I'll just include the full > path to the installed script under /usr/share/sphinx. > > The problem was to use python3-sphinx from a Makefile (not an auto-generated > sphinx-quickstart one) without patching the makefile. Given your descriptions > above, I think that there are better ways of solving this problem than what I > proposed. Yes, in case it's hardcoded, you probably need to either patch Makefile or execute sphinx-build from debian/rules by hand (and bug your upstream about using configurable Make variables like in Sphinx-generated ones). > *However*, there is a supplementary issue: AFAICT, which package provides the > /usr/bin/sphinx-* scripts depends on the order of installation. To me this > sounds a little off, but I'm not sure. What is your opinion of this? No, it shouldn't depend on the order of installation. If the Python 2 version is present, it's used, otherwise the Python 3 one. This is mostly for compatibility with old Python 2 only stuff… -- Dmitry Shachnev signature.asc Description: 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#815631: sphinx: Use alternatives to provide scripts under /usr/bin
Hi Kevin,
On Tue, Feb 23, 2016 at 02:34:11PM +1100, Kevin Murray wrote:
> I have recently needed to use a python3-only sphinx build process on a
> system with both python-sphinx & python3-sphinx co-installed. IMHO
> co-installation
> could be a little cleaner and easier if sphinx:
>
> - Used update-alternatives to provide /usr/bin/sphinx-* in a
> configurable way. (e.g similar to how docutils handles this problem). This
> could use the current script installation path under
> /usr/share/sphinx/scripts/python*/
Let me quote Jakub Wilk, who wrote the current implementation:
The alternatives mechanism is only suitable if both commands are compatible,
i.e. their behavior doesn't vary with Python version. This is the case for
rst2html and friends, but no so much for sphinx-build. The problem is that
sphinx-build can import 3rd-party Python code, which is not necessarily
compatible with both Python 2 and 3.
> - Or, installed binaries under /usr/bin with the suffix '3', i.e. install
> /usr/bin/sphinx-build3. (modelled after pip/pip3 & nosetests/nosetests3 and
> other similar examples)
The name of sphinx-build command is hardcoded in too many places (i.e. the
Makefiles generated by Sphinx use it). Also, I don't much like the foo/foo3
naming because there is a better way: pythonX[.Y] -m sphinx allows one to
call sphinx-build with *any* Python version (not necessarily the default one).
> - Or, a combination of both these, where python-sphinx and
> python3-sphinx install /usr/bin/sphinx-*{2,3} respectively, and
> update-alternatives is used to provide /usr/bin/sphinx-* without
> prefix.
See above.
> P.S., I know one can always do /usr/share/sphinx/scripts/python3/sphinx-build
> as a workaround.
What is exactly your problem? Does Python 2 sphinx not work with your code?
Can you use python3 -m sphinx there? Or maybe use setuptools' build_sphinx
command?
--
Dmitry Shachnev
signature.asc
Description: 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#814909: Port jstest to WebKit 2
Control: tags -1 +pending Hi Iain, On Tue, Feb 16, 2016 at 01:53:00PM +, Iain Lane wrote: > Here's a diff to port the jstest from webkit1 to 2 - I wanted this for > Ubuntu since sphinx is in main there and we're trying to move over to > wk2. > > Apparently (according to upstream) you can get the return value from > executed javascript, so the title hack ought not to be necessary any > more - but I didn't manage to get this working. It's a bit fiddly to > access. If you want to improve the patch to do that, please do. :) I have already committed a webkit2 port to Git two weeks ago :) https://anonscm.debian.org/cgit/python-modules/packages/sphinx.git/commit/?id=aec7ca4cdae8dc9d -- Dmitry Shachnev signature.asc Description: 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#814023: pyqt5-dev-tools should be offered in Python 2 and 3 variants
Hi Elvis, On Sun, Feb 07, 2016 at 07:40:01PM +0100, Elvis Stansvik wrote: >> What I can do is to replace a dependency on python3 with a recommendation — >> as two of three tools in this package are written in C++ and do not need >> Python >> at all. Let me know if this will help you. > > That would be much appreciated, because I need the pyrcc5 binary provided by > the > package, and if you would drop the dependency to a recommendation, I could > avoid > unnecessarily installing Python 3 in the Docker container where I deploy my > app. Apparently I can't do even that because that will break at least two packages in archive which build-depend on pyqt5-dev-tools but not on python3-pyqt5 (relational and weborf)… -- Dmitry Shachnev signature.asc Description: 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#814023: pyqt5-dev-tools should be offered in Python 2 and 3 variants
Hi Elvis, On Sun, Feb 07, 2016 at 05:48:40PM +0100, Elvis Stansvik wrote: > The pyqt5-dev-tools currently depends on Python 3. Since packages of PyQt5 are > for both Python 2 and 3 are available, I think it would make sense to split > this package into python3-pyqt5-dev-tools and python2-pyqt5-dev-tools, for > Python 3 and Python2, respectively. The scripts installed would have to be > renamed (e.g. "python2-pyuic5" and "python3-pyuic5" to avoid conflict). Please remember that initally our PyQt5 packages were for Python 3 only. We have added Python 2 packages only to help other applications (like Calibre) porting from PyQt 4 to PyQt 5. I do not recommend using Python 2 in new code. > As it currently stands, if I'm developing a PyQt5 application using Python 2, > I > need the tools provided by this package. But installing it needlessly forces > me > to install Python 3. I have no problem with installing Python 3 on my dev > machine, but when building the application in a clean environment such as > Docker, pulling in Python 3 seems a bit silly. It would be much better if > there > was a python2-pyqt5-dev-tools I could install. I will not do this. If you just need to use pyuic with Python 2 then you may just use “python2 -m PyQt5.uic.pyuic command” which needs only python-pyqt5. What I can do is to replace a dependency on python3 with a recommendation — as two of three tools in this package are written in C++ and do not need Python at all. Let me know if this will help you. -- Dmitry Shachnev signature.asc Description: 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#784513: qtwebkit removal from python-qt4
Hi all, I am going to remove qtwebkit support from python-qt4 package in an upload in early 2015 (but not before January 7th, one month from now). That means that these files will be no longer installed (and accompanying documentation files): In python-qt4: - /usr/lib/python2.7/dist-packages/PyQt4/QtWebKit.so - /usr/lib/python2.7/dist-packages/PyQt4/uic/widget-plugins/qtwebkit.py In python-qt4-dbg: - /usr/lib/debug/usr/lib/python2.7/dist-packages/PyQt4/QtWebKit.so - /usr/lib/python2.7/dist-packages/PyQt4/QtWebKit_d.so In python3-pyqt4: - /usr/lib/python3/dist-packages/PyQt4/QtWebKit.cpython-*-*.so - /usr/lib/python3/dist-packages/PyQt4/uic/widget-plugins/qtwebkit.py In python3-pyqt4-dbg: - /usr/lib/debug/usr/lib/python3/dist-packages/PyQt4/QtWebKit.cpython-*-*.so - /usr/lib/python3/dist-packages/PyQt4/QtWebKit.cpython-*-*.so Please port your packages before that date, or these bugs will become RC. The recommended way is to port packages to PyQt5, see the instructions at [1]. For the reasoning behind qtwebkit removal, please see the original bug report and the announcement in [2]. [1]: http://pyqt.sourceforge.net/Docs/PyQt5/pyqt4_differences.html [2]: https://lists.debian.org/debian-devel-announce/2015/05/msg1.html On behalf of python-qt4 maintainers, -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#805430: Patch
Hi Harlan, On Wed, Nov 25, 2015 at 08:36:09PM -0500, Harlan Lieberman-Berg wrote: > tags 805430 +patch > thanks > > Hi there! > > I've attached a patch (a simple dch --bpo) to backport python-sphinx to > jessie. Please note, it will not work until python-alabaster is > backported. I've submitted a PR and bug against that package, and the > bug blocks this one. > > Thanks! Thomas Goirand (CCed) says[1] he is going to backport both sphinx and alabaster. I don't know in what timeframe he will do that, though. [1]: https://lists.debian.org/5652cc58.6060...@debian.org -- Dmitry Shachnev signature.asc Description: 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#802992: python-altgraph: FTBFS with Python 3.5 as default: tests failure
Source: python-altgraph
Version: 0.12~dfsg-2
Severity: important
Tags: patch
User: debian-pyt...@lists.debian.org
Usertags: python3.5
Dear Maintainer,
python-altgraph FTBFS when Python 3.5 is the default Python 3 version
(i.e. with python3-defaults from experimental):
I: pybuild base:170: cd '/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build';
python3.5 -m unittest discover -v
altgraph (unittest.loader._FailedTest) ... ERROR
==
ERROR: altgraph (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: altgraph
Traceback (most recent call last):
File "/usr/lib/python3.5/unittest/loader.py", line 462, in _find_test_path
package = self._get_module_from_name(name)
File "/usr/lib/python3.5/unittest/loader.py", line 369, in
_get_module_from_name
__import__(name)
File "/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build/altgraph/__init__.py",
line 132, in
__version__ = pkg_resources.require('altgraph')[0].version
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 952,
in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 839,
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'altgraph' distribution was not found
and is required by the application
You can find the full build log here:
https://launchpadlibrarian.net/222742551/buildlog_ubuntu-xenial-amd64.python-altgraph_0.12~dfsg-2_BUILDING.txt.gz
The attached patch fixes this (and, as a bonus, enables tests running for all
Python versions).
--
Dmitry ShachnevFrom a5480f3b6c34fdf2f5c50f94185efda0b8b56def Mon Sep 17 00:00:00 2001
From: Dmitry Shachnev <mity...@gmail.com>
Date: Sun, 25 Oct 2015 23:24:46 +0300
Subject: [PATCH] Fix the command to run the tests.
---
debian/changelog | 6 ++
debian/rules | 4
2 files changed, 10 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index b4f07ea..64ada6f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+python-altgraph (0.12~dfsg-3) UNRELEASED; urgency=medium
+
+ * Fix the command to run the tests.
+
+ -- Dmitry Shachnev <mity...@debian.org> Sun, 25 Oct 2015 23:23:49 +0300
+
python-altgraph (0.12~dfsg-2) unstable; urgency=medium
* Added note in README.Debian about which parts have been stripped.
diff --git a/debian/rules b/debian/rules
index 4b1070f..e8aaafa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,6 +20,10 @@ override_dh_sphinxdoc:
dh_sphinxdoc
find debian/python-altgraph-doc -name license.txt -delete
+override_dh_auto_test:
+ python3 setup.py egg_info
+ dh_auto_test -- --system=custom --test-args='{interpreter} -m unittest discover -v'
+
#build/python-altgraph-doc::
# sphinx-build -bhtml doc build/html
# dh_sphinxdoc -ppython-altgraph-doc build/html
--
2.6.1
signature.asc
Description: OpenPGP digital 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#802996: python-macholib: FTBFS with Python 3.5 as default: tests failure
Source: python-macholib
Version: 1.7~dfsg-2
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: python3.5
Dear Maintainer,
python-macholib FTBFS when Python 3.5 is the default Python 3 version
(i.e. with python3-defaults from experimental):
I: pybuild base:170: cd '/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build';
python3.5 -m unittest discover -v
macholib (unittest.loader._FailedTest) ... ERROR
==
ERROR: macholib (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: macholib
Traceback (most recent call last):
File "/usr/lib/python3.5/unittest/loader.py", line 462, in _find_test_path
package = self._get_module_from_name(name)
File "/usr/lib/python3.5/unittest/loader.py", line 369, in
_get_module_from_name
__import__(name)
File "/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build/macholib/__init__.py",
line 10, in
__version__ = pkg_resources.require('macholib')[0].version
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 952,
in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 839,
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'macholib' distribution was not found
and is required by the application
You can find the full build log here:
https://launchpadlibrarian.net/222807666/buildlog_ubuntu-xenial-amd64.python-macholib_1.7~dfsg-2_BUILDING.txt.gz
I tried to apply a patch similar to one in #802992, but the tests were still
failing, because they tried to access some OS X specific files.
If the tests cannot be fixed, you can disable them by exporting
PYBUILD_DISABLE=test.
--
Dmitry Shachnev
signature.asc
Description: OpenPGP digital 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#802229: python-cffi: Uses versioned Provides
Package: python3-cffi-backend Version: 1.2.1-1 Severity: important Justification: Policy § 7.5 Dear Maintainer, Packages python-cffi-backend and python3-cffi-backend currently have versioned Provides field: $ apt-cache show python3-cffi-backend | grep ^Provides Provides: python3-cffi-backend-api-9729, python3-cffi-backend-api-max (= 9983), python3-cffi-backend-api-min (= 9729) These provides are generated in debian/gen-backend-versions.py at lines 39-40. However, the Policy § 7.5 (Virtual packages - Provides) [1] says: | A Provides field may not contain version numbers, and the version number of | the concrete package which provides a particular virtual package will not be | considered when considering a dependency on or conflict with the virtual | package name. [1]: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#795976: sphinx: please make the build reproducible (timestamps, randomness)
Hi Val, Looks like my latest upload is still not reproducible: the debbindiff [1] reports differing contents of searchindex.js. Do you know if this can be fixed by yet another PYTHONHASHSEED=0 setting, or this is more complicate? [1]: https://reproducible.debian.net/dbd/unstable/amd64/sphinx_1.3.1-5.debbindiff.html -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#792715: opencv: FTBFS with Sphinx 1.3: wrong code to detect Sphinx version
Control: reassign -1 src:opencv 2.4.9.1+dfsg-1.1 Hi Simon, On Wed, 19 Aug 2015 21:42:58 +0100, Simon McVittie wrote: I'm looking into NMUing opencv for the libstdc++ transition. This change does not actually address the opencv FTBFS, because opencv specifically reads sphinx-build's stderr, and the newly patched sphinx-build writes to stdout. I personally think the right solution to this is for opencv to stop checking the sphinx-build version at all, since it doesn't actually use it for anything, and that's what I intend to NMU if its maintainers don't object. Oops. Sorry for not noticing that. Reassigning back to src:opencv then. -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#795976: sphinx: please make the build reproducible (timestamps, randomness)
Hi Val, On Tue, 18 Aug 2015 15:07:32 +0200, Val Lorentz wrote: The attached patch removes build timestamp from the output documentation, makes domains sorted in HTML documentation, and makes generated automata (and their pickle dump) deterministic. Once applied, sphinx (and packages using sphinx) can be built reproducibly in our current experimental framework. Thanks a lot for the patch! This was actually in my TODO list, and you helped me to make it a bit shorter :) A couple of questions though: * Will you forward the upstream part to upstream, or should I do that? It is a simple as a pull request to https://github.com/sphinx-doc/sphinx. * The PYTHONHASHSEED setting in debian/rules was there for purpose (needed to make sure tests pass with it, as there was a bug in earlier versions when they didn't). Is it possible to keep the old value? Maybe you can use something else than builtin hash()? If it's impossible, then debian/rules should set PYTHONHASHSEED=random explicitly when running tests. -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#795391: fedmsg: FTBFS: tests failures
Source: fedmsg Version: 0.9.3-1 Severity: serious Justification: fails to build from source The new dh-python automatically runs tests with nose if python-nose is present in build-dependencies. Unfortunately some of the tests fail during fedmsg build, like: == ERROR: test_config_basic (fedmsg.tests.test_commands.TestCommands) -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/mock/mock.py, line 1305, in patched return func(*args, **keywargs) File /tmp/buildd/fedmsg-0.9.3/.pybuild/pythonX.Y_2.7/build/fedmsg/tests/test_commands.py, line 195, in test_config_basic config_command() File /tmp/buildd/fedmsg-0.9.3/.pybuild/pythonX.Y_2.7/build/fedmsg/commands/config.py, line 90, in config disable_defaults=args.disable_defaults, File /tmp/buildd/fedmsg-0.9.3/.pybuild/pythonX.Y_2.7/build/fedmsg/config.py, line 160, in load_config raise ValueError(No config value 'endpoints' found.) ValueError: No config value 'endpoints' found. The full build log can be found at: http://mitya57.me/builds/fedmsg_0.9.3-1_amd64.build -- Dmitry Shachnev ___ 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#795393: celery: FTBFS: typos in method calls
Source: celery Version: 3.1.18-1 Severity: serious Justification: fails to build from source celery FTBFS in current sid: == ERROR: test_on_chord_part_return (celery.tests.backends.test_redis.test_RedisBackend) -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/mock/mock.py, line 1305, in patched return func(*args, **keywargs) File /tmp/buildd/celery-3.1.18/celery/tests/backends/test_redis.py, line 254, in test_on_chord_part_return b.client.expire.assert_called_witeh(gkey, 86400) File /usr/lib/python2.7/dist-packages/mock/mock.py, line 721, in __getattr__ raise AttributeError(name) AttributeError: assert_called_witeh == ERROR: test_send (celery.tests.utils.test_mail.test_Mailer) -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/mock/mock.py, line 1305, in patched return func(*args, **keywargs) File /tmp/buildd/celery-3.1.18/celery/tests/utils/test_mail.py, line 49, in test_send client.sendmail.assert_called_With(msg.sender, msg.to, str(msg)) File /usr/lib/python2.7/dist-packages/mock/mock.py, line 721, in __getattr__ raise AttributeError(name) AttributeError: assert_called_With -- Ran 1693 tests in 32.293s FAILED (errors=2, skipped=44) debian/rules:26: recipe for target 'override_dh_auto_test' failed These look like typos in method name (assert_called_with). The full build log can be found at: http://mitya57.me/builds/celery_3.1.18-1_amd64.build -- Dmitry Shachnev ___ 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#795389: fedmsg: FTBFS: tests failures
Source: fedmsg Version: 0.9.3-1 Severity: serious Justification: fails to build from source The new dh-python automatically runs tests with nose if python-nose is present in build-dependencies. Unfortunately some of the tests fail during fedmsg build, like: == ERROR: test_config_basic (fedmsg.tests.test_commands.TestCommands) -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/mock/mock.py, line 1305, in patched return func(*args, **keywargs) File /tmp/buildd/fedmsg-0.9.3/.pybuild/pythonX.Y_2.7/build/fedmsg/tests/test_commands.py, line 195, in test_config_basic config_command() File /tmp/buildd/fedmsg-0.9.3/.pybuild/pythonX.Y_2.7/build/fedmsg/commands/config.py, line 90, in config disable_defaults=args.disable_defaults, File /tmp/buildd/fedmsg-0.9.3/.pybuild/pythonX.Y_2.7/build/fedmsg/config.py, line 160, in load_config raise ValueError(No config value 'endpoints' found.) ValueError: No config value 'endpoints' found. The full build log can be found at: http://mitya57.me/builds/fedmsg_0.9.3-1_amd64.build -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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
Re: [Python-modules-team] backport of nose to Wheezy
Hi Sandro, On Wed, 8 Jul 2015 11:10:25 -0400, Sandro Tosi wrote: Hello, we are facing some bugs on the Wheezy version of nose which are solved in 1.3.x series, so i'd like to have an updated version in Wheezy: would you prefer to backport it yourself or do you mind if i do it? Sure, please go ahead and backport it. -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#789452: python-qt4-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Control: tags -1 moreinfo Hi Andreas, On Sun, 21 Jun 2015 07:27:01 +0200, Andreas Beckmann wrote: Package: python-qt4-dbg Version: 4.11.3+dfsg-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: lenny - squeeze - wheezy - jessie - stretch [snip] 12m44.3s INFO: dirname part contains a symlink: /usr/share/doc/python-sip4-dbg/changelog.Debian.gz (python-sip4-dbg) != /usr/share/doc/python-sip4/changelog.Debian.gz (?) /usr/share/doc/python-sip4-dbg - python-sip4 /usr/share/doc/python-sip4-dbg/copyright (python-sip4-dbg) != /usr/share/doc/python-sip4/copyright (?) /usr/share/doc/python-sip4-dbg - python-sip4 12m46.1s ERROR: FAIL: debsums reports modifications inside the chroot: debsums: no md5sums for libdb4.5 debsums: missing file /usr/share/doc/python-sip4-dbg/changelog.Debian.gz (from python-sip4-dbg package) debsums: missing file /usr/share/doc/python-sip4-dbg/copyright (from python-sip4-dbg package) python-sip4-dbg existed only until squeeze, there is no such package in wheezy. Also, it was built from sip4-qt3 source, there is no such source anymore. What does this have to do with python-qt4-dbg package? How can we fix a bug in a package that no longer exists for several releases? -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#784270: python-docutils: FTBFS: test_invalid_raw_xml fails with TypeError
Source: python-docutils Version: 0.12+dfsg-1 Severity: serious python-docutils FTBFS with Python 2.7.9: == ERROR: test_invalid_raw_xml (test_writers.test_docutils_xml.DocutilsXMLTestCase) -- Traceback (most recent call last): File /tmp/buildd/python-docutils-0.12+dfsg/test/test_writers/test_docutils_xml.py, line 181, in test_invalid_raw_xml result = publish_xml(settings, invalid_raw_xml_source) File /tmp/buildd/python-docutils-0.12+dfsg/test/test_writers/test_docutils_xml.py, line 127, in publish_xml settings_overrides=settings) File /tmp/buildd/python-docutils-0.12+dfsg/build/py2/docutils/core.py, line 414, in publish_string enable_exit_status=enable_exit_status) File /tmp/buildd/python-docutils-0.12+dfsg/build/py2/docutils/core.py, line 662, in publish_programmatically output = pub.publish(enable_exit_status=enable_exit_status) File /tmp/buildd/python-docutils-0.12+dfsg/build/py2/docutils/core.py, line 219, in publish output = self.writer.write(self.document, self.destination) File /tmp/buildd/python-docutils-0.12+dfsg/build/py2/docutils/writers/__init__.py, line 80, in write self.translate() File /tmp/buildd/python-docutils-0.12+dfsg/build/py2/docutils/writers/docutils_xml.py, line 74, in translate self.document.walkabout(visitor) File /tmp/buildd/python-docutils-0.12+dfsg/build/py2/docutils/nodes.py, line 174, in walkabout if child.walkabout(visitor): File /tmp/buildd/python-docutils-0.12+dfsg/build/py2/docutils/nodes.py, line 174, in walkabout if child.walkabout(visitor): File /tmp/buildd/python-docutils-0.12+dfsg/build/py2/docutils/nodes.py, line 166, in walkabout visitor.dispatch_visit(self) File /tmp/buildd/python-docutils-0.12+dfsg/build/py2/docutils/nodes.py, line 1882, in dispatch_visit return method(node) File /tmp/buildd/python-docutils-0.12+dfsg/build/py2/docutils/writers/docutils_xml.py, line 184, in visit_raw col_num, line_num, node.astext()) TypeError: %d format: a number is required, not NoneType Full log is available here: http://mitya57.me/builds/python-docutils_0.12+dfsg-1_amd64.build -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#776443: sphinx: please make output reproducible
Control: forwarded -1 https://github.com/sphinx-doc/sphinx/pull/1694 I have now forwarded your patch upstream (needed a bit of rebasing), let's see what upstream thinks about it. As we are in freeze now, I guess this can wait until the new upstream release, right? -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#767579: python-markdown: FTBFS: tests failures with new Pygments
Source: python-markdown Version: 2.5.1-1 Severity: serious python-markdown FTBFS with new pygments 2.0 in testing: FAIL: testBasicCodeHilite (tests.test_extensions.TestCodeHilite) - div class=codehilitepre# A Code Comment + div class=codehiliteprespan class=c# A Code Comment/span ? +++ FAIL: testLinenumsNone (tests.test_extensions.TestCodeHilite) - div class=codehilitepre# A Code Comment + div class=codehiliteprespan class=c# A Code Comment/span ? +++ Full build log: http://mitya57.me/builds/python-markdown_2.5.1-1_amd64.build -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#764761: pyqt4-dev-tools: fontMetrics.elidedText performs poorly on '\t' in QLabel.
On Fri, 17 Oct 2014 21:48:45 +0200, Enno wrote: Segfault? Well maybe I should add the full code: See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764761#15 The width of the tab is 80px according to Qt documentation, but this is not consistent with my experience, in my configuration in this QLabel it seems to be about 56px wide. I think 80px is *maximum* tab width, and real tab width will be (− width of previous text) mod (80px). Anyway, if it is less than the documented value, I think it is not a bug. Anyway, this should not stop you from discussing it with upstream :) -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#764761: pyqt4-dev-tools: fontMetrics.elidedText performs poorly on '\t' in QLabel.
On Fri, 17 Oct 2014 11:57:16 +0400, Dmitry Shachnev wrote: Second, I get a segmentation fault trying to reproduce this issue (with both Qt 4 and Qt 5). Reported at [1]. Please ignore that part, upstream pointed that it was my fault (In both Python and C++, one needs to keep a reference to the application object). Anyway, my investigations are still valid. -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#745383: sphinx-issuetracker: Please use dh_python2 instead of dh_pysupport
Source: sphinx-issuetracker Version: 0.8-1 Dear Maintainer, Your package currently uses python-support. In Sphinx, I maintain a hack that allows python-support- and dh_python2-based modules to co-exist in sphinxcontrib namespace. However, as python-support is deprecated for a long time, I would like to get rid of that hack. Please consider using the modern dh_python2 helper. See https://wiki.debian.org/Python/TransitionToDHPython2 for details. -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#745382: sphinxcontrib-spelling: Please use dh_python2 instead of dh_pysupport
Source: sphinxcontrib-spelling Version: 1.4-1 Dear Maintainer, Your package currently uses python-support. In Sphinx, I maintain a hack that allows python-support- and dh_python2-based modules to co-exist in sphinxcontrib namespace. However, as python-support is deprecated for a long time, I would like to get rid of that hack. Please consider using the modern dh_python2 helper. See https://wiki.debian.org/Python/TransitionToDHPython2 for details. -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#743858: segfaults when hgview a repository from https://bitbucket.org/grotegerd/mania
Control: tags -1 unreproducible On Mon, Apr 7, 2014 at 5:56 PM, Julien Cristau julien.cris...@logilab.fr wrote: Control: reassign -1 python-qt4 4.10.3+dfsg1-1 Reassigning to pyqt. hgview is pure python, a segfault means a bug somewhere lower in the stack. And again I can't reproduce it (on i386). Hgview window shows fine, and I can browse files[1] and commits there. [1] Better I did not see that. *Sigh* at people storing Manual.tex~, Manual.tex.backup, Manual.log, Manual.aux and so on in the Vcs. On Mon, Apr 7, 2014 at 09:49:39 -0400, Yaroslav Halchenko wrote: (gdb) bt 10 #0 0x721a5e30 in QMetaObject::cast(QObject*) const () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #1 0x70425996 in QAction::QAction(QString const, QObject*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #2 0x714324e9 in ?? () from /usr/lib/python2.7/dist-packages/PyQt4/QtGui.so #3 0x714326c8 in ?? () from /usr/lib/python2.7/dist-packages/PyQt4/QtGui.so #4 0x72eacd4a in ?? () from /usr/lib/python2.7/dist-packages/sip.so It would be nice if you attached a more useful stacktrace, with debug packages for Qt, PyQt and Sip installed. -- Dmitry Shachnev ___ 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#742130: python3-pyside: Wrong filenames for python3.3 modules
Package: python3-pyside Version: 1.2.1-3 Severity: grave Justification: renders package unusable Dear Maintainer, It is currently impossible to import pyside from python3.3 on i386. The reason is that the .so files are named wrongly. For example: /usr/lib/python3/dist-packages/PySide/QtCore.cpython-34m.cpython-33m.so /usr/lib/python3/dist-packages/PySide/QtGui.cpython-34m.cpython-33m.so and so on. They should be named instead (on i386): /usr/lib/python3/dist-packages/PySide/QtCore.cpython-33m-i386-linux-gnu.so /usr/lib/python3/dist-packages/PySide/QtGui.cpython-33m-i386-linux-gnu.so The python3.4 modules are named correctly. Looking at contents of amd64 packages, it seems the situation is opposite there: python3.3 modules are named correctly and python3.4 ones are broken. -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#739300: Bug#739300: dh_sphinxdoc: Please replace MathJax.js with links to the packaged libjs-mathjax
On Thu, 06 Mar 2014 19:00:09 +0100, Julian Taylor wrote: replacing a directory with a symlink is problematic as dpkg has special rules for handling symlinks which can cause all kinds of upgrade issues. The most common ones are files disappearing (see the plentora of missing copyright bugs due to symlinking -doc packages) or unpack errors due to ordering issues in the tarballs. For this reason dh_linktree exists, please use that instead. Another approach is to modify the path the webserver serves from, thats what I do in IPython. I see two disadvantages in this approach: - First, as Sebastian mentioned, “30k-ish symlinks is just too much for a documentation displaying one or two formulas”. - Then, set of MathJax files changes with each release, so we will have to rebuild all such packages with every new MathJax release (otherwise some symlinks will be broken or missing). The problem with replacing a directory with symlink can be easily solved by adding a preinst script to the package. -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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#739300: dh_sphinxdoc: Please replace MathJax.js with links to the packaged libjs-mathjax
Hi Sebastian, I have performed some queries on codesearch.debian.net and it seems that currently only two packages ship embedded copy of MathJax (mcrl2 and yelp): Your package breathe in NEW seems to be another one, and the only one using Sphinx. Given that you already fixes breathe, I think the impact of this bug is zero. Also, the source of MathJax is quite large (especially if you ship PNG files), so I would usually recommend people to remove that embedded copy from the source tarball. Anyway, I will keep this bug open and accept patches if someone decides to write them. Some packages (i.e. calibre) already do that. -- Dmitry Shachnev signature.asc Description: OpenPGP digital 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
