[Python-modules-team] Accepted celery 4.1.0-4 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 03 Apr 2018 08:38:39 +1000 Source: celery Binary: python-celery python-celery-common python-celery-doc python3-celery Architecture: source all Version: 4.1.0-4 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Brian May <b...@debian.org> Description: python-celery - async task/job queue based on message passing (Python2 version) python-celery-common - async task/job queue based on message passing (common files) python-celery-doc - async task/job queue based on message passing (Documentation) python3-celery - async task/job queue based on message passing (Python3 version) Closes: 888407 Changes: celery (4.1.0-4) unstable; urgency=medium . * Run upstream tests with pytest instead of nose. Closes: 888407. Checksums-Sha1: d94ab0a30e42720571908193b572c0b1f6f1dd8d 3036 celery_4.1.0-4.dsc 68c4fcb08b0e1251fdc88cadd68fca2442a163b7 1331689 celery_4.1.0.orig.tar.gz db3422b287d31fc60ed03b2d9d1234545e04911f 23316 celery_4.1.0-4.debian.tar.xz bc7515d41ab712890755f7218c56368c5819a391 12472 celery_4.1.0-4_i386.buildinfo 24667cd3b563eee828a473e6308088a0a1abb383 31124 python-celery-common_4.1.0-4_all.deb fe3ac61a1ed9f06b8516d2a53176554fe8af4a5a 1679740 python-celery-doc_4.1.0-4_all.deb c59baf572c1a7a0edb897dc4dc192fbfbc1d85f3 274140 python-celery_4.1.0-4_all.deb 76c25f2e07af5ba99623e9b4c5ca6713bb0b873a 274184 python3-celery_4.1.0-4_all.deb Checksums-Sha256: 673f8820f32f524f60cb07a16ddfba28cd6b21c34766708c639b14336061b56a 3036 celery_4.1.0-4.dsc 77ff3730198d6a17b3c1f05579ebe570b579efb35f6d7e13dba3b1368d068b35 1331689 celery_4.1.0.orig.tar.gz 70844a79c6db553198142e2652720c3af8374d635777e79cf0d1ef6da116010a 23316 celery_4.1.0-4.debian.tar.xz 3a75995397fd9dd1a82736892203cd7d3e6312f2f77b8705e4e2ea66491ee8f1 12472 celery_4.1.0-4_i386.buildinfo ec407b1d920c23be9300b329f7c7917106ede8abec99c74c4cbaf03dc81845dc 31124 python-celery-common_4.1.0-4_all.deb 1f3ef9ba83d743820f41a4674ba053f0e5a13cfd7854da7ad84fd3b702339495 1679740 python-celery-doc_4.1.0-4_all.deb 817f08d0f3b229b2a04ca028dc63344d372fb2a53d68142408f8dccd210509c2 274140 python-celery_4.1.0-4_all.deb c87a8799664a1e85923eeb4e7808c25f48afa1d534da074d1ffb5e22e71226af 274184 python3-celery_4.1.0-4_all.deb Files: 3d046a0f4e09a60a0a044348a9a2e2c2 3036 python optional celery_4.1.0-4.dsc db91e1d26936381127f01e150fe3054a 1331689 python optional celery_4.1.0.orig.tar.gz d3e88b692a48070d96a31a8b79f773a2 23316 python optional celery_4.1.0-4.debian.tar.xz b30f81668780a3120f84a836d73f8c72 12472 python optional celery_4.1.0-4_i386.buildinfo 0189a9ce5fb20b1738275684a021819a 31124 python optional python-celery-common_4.1.0-4_all.deb 9b3f63f70a3da47f8cde49e98aa57644 1679740 doc optional python-celery-doc_4.1.0-4_all.deb 1e6611bae4fd4a73d39ffab6ed800d6e 274140 python optional python-celery_4.1.0-4_all.deb 03bffa820134d97c8431559555ab1d36 274184 python optional python3-celery_4.1.0-4_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAlrDKKMACgkQKpJZkldk SvrRhBAAgLeJoUcTtYGs4P2AY3PydmGcK6dR6LiEaottVzGW7yg+AOTXn2LiYJA/ aqBzY+WgmbqdzQBo+sR1hYVrw886D3256Iuc5HEP/dLkNvcAsyRwtTziUY9up4bp DdbUnSIZsaqFssq3Y6CAIvHAz6/BL8teYImuWf95KEtiQmKYEyPqm3TRRE3mJLDN icZe/xMyRFcCW+Xi+Bh2/u8q4M7OzKExNnjL4PHIJrx+EBA8uKx+Wtzu1PHE3eGG pNQNEmIh/04k/MriBtjCoMTiUuoCco6SVBKMcnKuUrJ5dbn4AZCqJzV9lHQ8rERF XIKdIgsUFF79iumyxKY6SZs97kpQBLEU1yRyY46LIfeQF3+X5QyQvH9UK1gpkK3m Wr688m5TkslZ+1ZzBqkLiiwVfa81HkRFDvLVRe1vlKuFfoLLwo7hJn2yl/V689lP 27HxjqS/wP6Q+Z3C/ac6W8InlyWFRB6IAGgbMCz88ukuH+GV8RECb/4rA4c1zwAi n6IEFjANTvCEARf5oNQtkPLb3ghz+ToWdAStTJTBu4QFZIiqSuJeVrC0zL59fvNs BEXWnx4cB/pHXRUlAUBtqYdyoIy0+lelGHf/83sVGIeIZdcX05Ti24HcjmNy7LPr JUadNs+dP2Y4lcAit4paMcoplLf2Rs3U3caWeBkmDW2+97Th+S0= =mEC0 -END PGP SIGNATURE- ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Accepted python-django 1.7.11-1+deb8u3 (source all) into oldstable-proposed-updates->oldstable-new, oldstable-proposed-updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 30 Mar 2018 12:24:14 +1100 Source: python-django Binary: python-django python3-django python-django-common python-django-doc Architecture: source all Version: 1.7.11-1+deb8u3 Distribution: jessie-security Urgency: high Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Brian May <b...@debian.org> Description: python-django - High-level Python web development framework (Python 2 version) python-django-common - High-level Python web development framework (common) python-django-doc - High-level Python web development framework (documentation) python3-django - High-level Python web development framework (Python 3 version) Changes: python-django (1.7.11-1+deb8u3) jessie-security; urgency=high . * Non-maintainer upload by the LTS Team. * Fix CVE-2018-7536: Denial-of-service possibility in ``urlize`` and ``urlizetrunc`` template filters * Fix CVE-2018-7537: Denial-of-service possibility in ``truncatechars_html`` and ``truncatewords_html`` template filters Checksums-Sha1: 90fd1ba4dd1fe82935a9f78e9acf6f763d6dda92 2721 python-django_1.7.11-1+deb8u3.dsc f9abaf7eacec73bc1c5e6080e2778a7174ebf9d4 7586798 python-django_1.7.11.orig.tar.gz 94458a8196ee911b227365549865204f7c8fa905 36792 python-django_1.7.11-1+deb8u3.debian.tar.xz 0c7c92c1aad389b4b2df965f0645d6bc48b19a70 994520 python-django_1.7.11-1+deb8u3_all.deb 78f862ebd59af745478a5058a9f74a9ed3d54105 977346 python3-django_1.7.11-1+deb8u3_all.deb fb85b5127cb9da679cf78768f64c4a7a7eae0a6b 1498210 python-django-common_1.7.11-1+deb8u3_all.deb cd13034cc7feb8f460923c529c981a9538c786a3 2500294 python-django-doc_1.7.11-1+deb8u3_all.deb Checksums-Sha256: 020ff13d430d50ff6e2ddb8d3973ad9ef90829167fe57bfba4d551f39f7194dd 2721 python-django_1.7.11-1+deb8u3.dsc 2039144fce8f1b603d03fa5a5643578df1ad007c4ed41a617f02a3943f7059a1 7586798 python-django_1.7.11.orig.tar.gz 098bd99951b72ef0cea19d8c267714c82e1e7abc3303d7a557aebad8c71019d5 36792 python-django_1.7.11-1+deb8u3.debian.tar.xz c7e2f0188b5b7d6de5f8699c2c613fad3a3d933215a39c08b1f217955489ceaa 994520 python-django_1.7.11-1+deb8u3_all.deb 7d91dd136b1b3298535f7986977392a6582e264a942f90fa36cefe5d25164230 977346 python3-django_1.7.11-1+deb8u3_all.deb 3f4f734d1a147b4cd0f280421d446f9b4983c370530345f84ce228a35f95181a 1498210 python-django-common_1.7.11-1+deb8u3_all.deb 234cc0c4fd72a69951fa09b023e94fec39ba4670c9599f24796267f0ad92d667 2500294 python-django-doc_1.7.11-1+deb8u3_all.deb Files: c25590e5709564161b3f4e4175c4c713 2721 python optional python-django_1.7.11-1+deb8u3.dsc 030b2f9c99a6e4e0418eadf7dba9e235 7586798 python optional python-django_1.7.11.orig.tar.gz 18a7ee38c4bd80a6c9c22e2a7bc95e63 36792 python optional python-django_1.7.11-1+deb8u3.debian.tar.xz 750fd6eaac43c21bd3f9423dbd215563 994520 python optional python-django_1.7.11-1+deb8u3_all.deb a874dd9861840324d81046130ad2bc47 977346 python optional python3-django_1.7.11-1+deb8u3_all.deb ff55243bccc557db352c3c0775f615d2 1498210 python optional python-django-common_1.7.11-1+deb8u3_all.deb 379faa79c26f83310d6988740f5fcdee 2500294 doc optional python-django-doc_1.7.11-1+deb8u3_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAlq9nvgACgkQKpJZkldk Svoygw//Zw2THhVwV0ELKSlrBLD4HS78rMw7obXEyLdy6JClsqS3T51M1HZBXj4C jZXm69AC4X+UaniPmguP25rGUzIzH8UzLg3yOk8MH+tTbuyqqja/ydSNZu8xaMZR e94gRQfczB2t0WOq6mfCwXwYFLif0NWs0auqWJLgB668HbMEh+Fbvr7TX1hvto78 xYOfSCWzLkLpJ+YPpajWSRITzuo8fBweNZ+W5a0pSFn6osMO8BN5sB/0n+CBTEa2 aUHZdDUZfpEUpHbiT7/azF+XFIMDB/XP4hBWDZtVsPJlCTaXVffRueUS1Ty3TUHH aTldyuszCvjL39xKVvpnI2+FHBLEuQwJNQFJWvfVvjQpHg9fNehvzI8AXcZhfxp7 t4/8jO18S6FXd8NQWa4O/9Lok3vF90jyA8LgNCqb18yUZ0vtas8xepJnrqgCW4Vv aUHQff4+66JHanpaJWnkWr/LcANJQCW3dG72abl6LGeJUBLpoaDtEL+uuE6jOy+0 NhfxPbbcByd1+9eMFQC5u49K4rH5GNLy1+V8q9XuO8Fcr66i+6xH10t5A6Osre/n uTJ/vXxMV9ZjfhVt142mIVG+id8UD1JD6eXrnZUczm7kxIaO2/nt6LW0Gv3Odxi8 pDvVxv/Z73x0CAlFylYEcFdBFRrjoh1RUwRjYHHz5cArinslrjo= =GyF+ -END PGP SIGNATURE- ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Accepted python-django 1:1.10.7-2+deb9u1 (source all) into proposed-updates->stable-new, proposed-updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 30 Mar 2018 09:32:16 +1100 Source: python-django Binary: python-django python3-django python-django-common python-django-doc Architecture: source all Version: 1:1.10.7-2+deb9u1 Distribution: stretch-security Urgency: high Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Brian May <b...@debian.org> Description: python-django - High-level Python web development framework (Python 2 version) python-django-common - High-level Python web development framework (common) python-django-doc - High-level Python web development framework (documentation) python3-django - High-level Python web development framework (Python 3 version) Changes: python-django (1:1.10.7-2+deb9u1) stretch-security; urgency=high . * Non-maintainer upload by the LTS Team. * Fix CVE-2018-7536: Denial-of-service possibility in ``urlize`` and ``urlizetrunc`` template filters * Fix CVE-2018-7537: Denial-of-service possibility in `truncatechars_html`` and ``truncatewords_html`` template filters Checksums-Sha1: bd7cc0212574558a72b79c9bbd3292a2eccb1f4c 2804 python-django_1.10.7-2+deb9u1.dsc 5edd13a642460c33cdaf8e8166eccf6b2a2555df 7737654 python-django_1.10.7.orig.tar.gz 12c09049d5e940914dd75161032940279147dcf6 32660 python-django_1.10.7-2+deb9u1.debian.tar.xz d9f3a1a462c6c15dfc8732385e6e40567be18ed0 1513510 python-django-common_1.10.7-2+deb9u1_all.deb 694da118c5c0501b3ae03c0db3da937986004281 2534816 python-django-doc_1.10.7-2+deb9u1_all.deb a4152e9e34a1362b2923164ab78a4dbbd6d599c9 903920 python-django_1.10.7-2+deb9u1_all.deb 4c604cb419126dfbae381e32a94bc26e263dcb63 9245 python-django_1.10.7-2+deb9u1_i386.buildinfo 2c26b063e5ede0d9cdfc0038c9dff939d7c97339 885448 python3-django_1.10.7-2+deb9u1_all.deb Checksums-Sha256: f256ef83e1a2d55cb44cfe917f725aff93778fdea5d7d9bb6997b16a02844c5c 2804 python-django_1.10.7-2+deb9u1.dsc 593d779dbc2350a245c4f76d26bdcad58a39895e87304fe6d725bbdf84b5b0b8 7737654 python-django_1.10.7.orig.tar.gz 7f61ad87834650527daf985d3a4c1bb4897f281fdd648952d97eb530cad53340 32660 python-django_1.10.7-2+deb9u1.debian.tar.xz 49ebdb958438d01d5c6690e0b634f8c53f1e0146316613112b374eb61cb9fe4e 1513510 python-django-common_1.10.7-2+deb9u1_all.deb 8d3d51b0e64859134d5c33a31d84e950ef670616059b3be4cb943ca0180d10b4 2534816 python-django-doc_1.10.7-2+deb9u1_all.deb 954508822f12b99d2fdc52bc9d8314857081b9b139a1ee4605262459a65cbbc0 903920 python-django_1.10.7-2+deb9u1_all.deb bb4b3f50acf1e1c9b74747fac44ec6944bb8cba51afe5a3dcf5236e16e9b497a 9245 python-django_1.10.7-2+deb9u1_i386.buildinfo d3e78c18742afcb5c673aaf626139f2fa8603a413314be97dabbcc714a18343a 885448 python3-django_1.10.7-2+deb9u1_all.deb Files: fddbe29d04c7e613875ee291ffaf5e37 2804 python optional python-django_1.10.7-2+deb9u1.dsc 693dfeabad62c561cb205900d32c2a98 7737654 python optional python-django_1.10.7.orig.tar.gz 835e49ccdbc45e02c529591b2fb6a4a8 32660 python optional python-django_1.10.7-2+deb9u1.debian.tar.xz 7c03462ba2e0fea282a8f2661b52b6b6 1513510 python optional python-django-common_1.10.7-2+deb9u1_all.deb 9afa38724da25ef24c9fc1b34e39a8dd 2534816 doc optional python-django-doc_1.10.7-2+deb9u1_all.deb 9ef3afec0deb632b5f0e1db8c5b3eb4b 903920 python optional python-django_1.10.7-2+deb9u1_all.deb 4aea79eef83b2321bc9bf31768cbcf4b 9245 python optional python-django_1.10.7-2+deb9u1_i386.buildinfo 611252e2e8f01c0ca0297e9d7a181443 885448 python optional python3-django_1.10.7-2+deb9u1_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAlq9fecACgkQKpJZkldk SvocMA/+ILTQpaxf3KEFkvs2K9MOBOuIlYJ14iC3xNGGyTzRheZs0NGIc2NZrf16 lUQBjMsZiN4FKQ3TsiiCD5XkU+SG00QTgtUtwm5Gl1KGtoToGwDFySZ0UP0e2gNV 1Ov+6FLl96sLnhFp6aOjiGiSOKMyoErF2vlOLEAvvDLLHc6xc83QZmLYA3cdOcNK eKa/sHRA/onG79t0IgxqUfzy7Xd2SqFpJlEjJ3TPkLCK0irY4MN4ilvsB/ksXVH5 ddrWZh1Jzg6c7VOt4yQKI05tFzw31K8XoeOPmRV4pwi5nUVY5B2nk6HYC3ljzCm6 xjjQIIc+pWAGgewsFqN1YecnQcIPfABPnRp4TlmwMuGfyKHO16F/tlL+b65X3Xyu WxoAc2qRcFbIEVi8SLUGRgctuxn9cHuirzmK8F+nrqquAXcWCwWYWv+5kEfWfAC3 KL2h+sjctskDr9lGGwBeqfVWbgX4rKepwHv7nbAMdFwOejN91jusiEnDOXE/l/2k zSNIvYeJddIBKvHigC21zej3NXIkW4xOOH+wrj0LrZm8H3eBm2Tu5/DBlOjh5rzc IQcjHIsDLah5OitNn1748b8ITttnIth6MzRkQQEN8PgYCfyTdrSmVlL56I+bLg4t 2+Kj0ppSpqKqJaEdb45JRMbjrYu+sxZKU6/myZOpD+U2mut8Q3Y= =M92W -END PGP SIGNATURE- ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Accepted django-simple-captcha 0.5.6-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 02 Apr 2018 14:35:56 +1000 Source: django-simple-captcha Binary: python-django-captcha python3-django-captcha django-simple-captcha Architecture: source all Version: 0.5.6-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Brian May <b...@debian.org> Description: django-simple-captcha - Django Simple Captcha Django application python-django-captcha - Django Simple Captcha Django application python3-django-captcha - Django Simple Captcha Django application Closes: 882140 Changes: django-simple-captcha (0.5.6-1) unstable; urgency=medium . [ Brian May ] * New upstream version. * Fixes compatibility with Django 2.0. Closes: #882140. . [ Ondřej Nový ] * d/control: Set Vcs-* to salsa.debian.org * d/copyright: Use https protocol in Format field * d/changelog: Remove trailing white space. Checksums-Sha1: 707ca55150b7e772a5212b3644b6e7b05a840303 2503 django-simple-captcha_0.5.6-1.dsc 32f11d4ed34cfd24d289fccf1f86797d7d5d2cb6 183304 django-simple-captcha_0.5.6.orig.tar.gz 09f56a0f93e44c76ef6c97149093c6b1e62cc8c4 86252 django-simple-captcha_0.5.6-1.debian.tar.xz 8b9189742e8fe9473ad700d5eb18d821eba69c5a 7032 django-simple-captcha_0.5.6-1_all.deb b06775d28088254e7bbed5ab09b6d62bef13f57b 7589 django-simple-captcha_0.5.6-1_i386.buildinfo d747d88a458076017c55c03328a7d8c9617fc0d1 27056 python-django-captcha_0.5.6-1_all.deb 568e36973bebdd2bd5dee2335cffcd209f88ac11 27136 python3-django-captcha_0.5.6-1_all.deb Checksums-Sha256: 70a973f22aa170b21634187622c5c70ac310ac2aca6359f1180a38bda3d3f371 2503 django-simple-captcha_0.5.6-1.dsc 3bfb52d892c000dcf158ee50ec3be0761efc50788ece8ec46228794f60d48ce5 183304 django-simple-captcha_0.5.6.orig.tar.gz 032941495d6e57b47f048f0f29226368425686f18568dcf1604670f6a2d2b0dd 86252 django-simple-captcha_0.5.6-1.debian.tar.xz ec37a2e1a06e7dd74d75371fcc9e989f05cba7bf58ab9e1684627dfe29168d20 7032 django-simple-captcha_0.5.6-1_all.deb b34a9997e5d599bdb6dd2af41d7a07b4af4fee23b984d1596238a63aa25bf8b2 7589 django-simple-captcha_0.5.6-1_i386.buildinfo e1d4d69499f367576a0683c798daae844f1bd0fd05f5389d7c506c882ea614a4 27056 python-django-captcha_0.5.6-1_all.deb a2c6a77be5dab4b4028a8493c6795781548201d353fc187e3b115bf4c21213db 27136 python3-django-captcha_0.5.6-1_all.deb Files: afbe8bd04dfc6c26c7f00b1716390d48 2503 python optional django-simple-captcha_0.5.6-1.dsc 7366da087c9686a15a99098abc29ed81 183304 python optional django-simple-captcha_0.5.6.orig.tar.gz abe6bfe181336d3436286ffa1e46fe45 86252 python optional django-simple-captcha_0.5.6-1.debian.tar.xz 304f48af106213b2803ef33d3fd25113 7032 python optional django-simple-captcha_0.5.6-1_all.deb 2938abc42b801ea4e1257d33fb8bb3be 7589 python optional django-simple-captcha_0.5.6-1_i386.buildinfo f3dc3879f780e131334a124ef6308d7c 27056 python optional python-django-captcha_0.5.6-1_all.deb f5cea41b25da2eab818620ed991b26d5 27136 python optional python3-django-captcha_0.5.6-1_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAlrBtIcACgkQKpJZkldk Svo0lQ//YoEhdaAX92a3uXQvAACk3SCMOrhddmYahCoNuVzGajH53l5jCB0KcpPw YuupZQ2jZ9mpb+RX/QcotkA0IdGRs/uoZGBr3MxpAz/4RYHjyjVg9chPYNnMkihy Niyn9I/p7HPz4DwqqRU+mXl4bsWeODqAvbjbz5g5TefnucoYmEW0eIC3CcrhV8qz SvbKGtmNsJ7wsUbDEivpCr60W2Dzc3MkR55vnEHYbxMIlgiqhCh/aXoxMnmXCeYe kujY2ScO2w+VXUp/V/LkVHjEeTIEYSq9fx7NbuDzGx2h+J/WBFrhn2puVUF3PfZl Qc/Zc8I0ddVyq3fPEMnGiukVjZes0R5qs9tHtKDLRpsKcG0yDtxtUhJ0TR6Qpwvc fExRw1jhFs14IMcfMavSjgRRVgUqHCD6yf2oR4aOTBw6O9xEs7hYEQt33k0GCN0d wQcz4oNGz1VaZ+N2uy3uKB0PmV1bdXnH7AUkEhR0z6MnwRmnvLfLgAaGiCfZaJ3n q5M5BfeUh9z2iLkLOt6adQl4O+Go8M8itI6GDzHqUEDQzgQPvEHefZnK0j8qRUFm Zqb3/5Gl6pod16Voz11931Zd7R1l6jLboUdut/ZrB6ANWm67lu3p2GRC8mFcq4C6 0n+L6MJ9FDOY3QhPsMPkLdh0wWFRgnBnFYLLUQcmM0vJltUt+/Y= =DnRm -END PGP SIGNATURE- ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Accepted python-django 1:1.10.7-2+deb9u1 (source all) into stable->embargoed, stable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 30 Mar 2018 09:32:16 +1100 Source: python-django Binary: python-django python3-django python-django-common python-django-doc Architecture: source all Version: 1:1.10.7-2+deb9u1 Distribution: stretch-security Urgency: high Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Brian May <b...@debian.org> Description: python-django - High-level Python web development framework (Python 2 version) python-django-common - High-level Python web development framework (common) python-django-doc - High-level Python web development framework (documentation) python3-django - High-level Python web development framework (Python 3 version) Changes: python-django (1:1.10.7-2+deb9u1) stretch-security; urgency=high . * Non-maintainer upload by the LTS Team. * Fix CVE-2018-7536: Denial-of-service possibility in ``urlize`` and ``urlizetrunc`` template filters * Fix CVE-2018-7537: Denial-of-service possibility in `truncatechars_html`` and ``truncatewords_html`` template filters Checksums-Sha1: bd7cc0212574558a72b79c9bbd3292a2eccb1f4c 2804 python-django_1.10.7-2+deb9u1.dsc 5edd13a642460c33cdaf8e8166eccf6b2a2555df 7737654 python-django_1.10.7.orig.tar.gz 12c09049d5e940914dd75161032940279147dcf6 32660 python-django_1.10.7-2+deb9u1.debian.tar.xz d9f3a1a462c6c15dfc8732385e6e40567be18ed0 1513510 python-django-common_1.10.7-2+deb9u1_all.deb 694da118c5c0501b3ae03c0db3da937986004281 2534816 python-django-doc_1.10.7-2+deb9u1_all.deb a4152e9e34a1362b2923164ab78a4dbbd6d599c9 903920 python-django_1.10.7-2+deb9u1_all.deb 4c604cb419126dfbae381e32a94bc26e263dcb63 9245 python-django_1.10.7-2+deb9u1_i386.buildinfo 2c26b063e5ede0d9cdfc0038c9dff939d7c97339 885448 python3-django_1.10.7-2+deb9u1_all.deb Checksums-Sha256: f256ef83e1a2d55cb44cfe917f725aff93778fdea5d7d9bb6997b16a02844c5c 2804 python-django_1.10.7-2+deb9u1.dsc 593d779dbc2350a245c4f76d26bdcad58a39895e87304fe6d725bbdf84b5b0b8 7737654 python-django_1.10.7.orig.tar.gz 7f61ad87834650527daf985d3a4c1bb4897f281fdd648952d97eb530cad53340 32660 python-django_1.10.7-2+deb9u1.debian.tar.xz 49ebdb958438d01d5c6690e0b634f8c53f1e0146316613112b374eb61cb9fe4e 1513510 python-django-common_1.10.7-2+deb9u1_all.deb 8d3d51b0e64859134d5c33a31d84e950ef670616059b3be4cb943ca0180d10b4 2534816 python-django-doc_1.10.7-2+deb9u1_all.deb 954508822f12b99d2fdc52bc9d8314857081b9b139a1ee4605262459a65cbbc0 903920 python-django_1.10.7-2+deb9u1_all.deb bb4b3f50acf1e1c9b74747fac44ec6944bb8cba51afe5a3dcf5236e16e9b497a 9245 python-django_1.10.7-2+deb9u1_i386.buildinfo d3e78c18742afcb5c673aaf626139f2fa8603a413314be97dabbcc714a18343a 885448 python3-django_1.10.7-2+deb9u1_all.deb Files: fddbe29d04c7e613875ee291ffaf5e37 2804 python optional python-django_1.10.7-2+deb9u1.dsc 693dfeabad62c561cb205900d32c2a98 7737654 python optional python-django_1.10.7.orig.tar.gz 835e49ccdbc45e02c529591b2fb6a4a8 32660 python optional python-django_1.10.7-2+deb9u1.debian.tar.xz 7c03462ba2e0fea282a8f2661b52b6b6 1513510 python optional python-django-common_1.10.7-2+deb9u1_all.deb 9afa38724da25ef24c9fc1b34e39a8dd 2534816 doc optional python-django-doc_1.10.7-2+deb9u1_all.deb 9ef3afec0deb632b5f0e1db8c5b3eb4b 903920 python optional python-django_1.10.7-2+deb9u1_all.deb 4aea79eef83b2321bc9bf31768cbcf4b 9245 python optional python-django_1.10.7-2+deb9u1_i386.buildinfo 611252e2e8f01c0ca0297e9d7a181443 885448 python optional python3-django_1.10.7-2+deb9u1_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAlq9fecACgkQKpJZkldk SvocMA/+ILTQpaxf3KEFkvs2K9MOBOuIlYJ14iC3xNGGyTzRheZs0NGIc2NZrf16 lUQBjMsZiN4FKQ3TsiiCD5XkU+SG00QTgtUtwm5Gl1KGtoToGwDFySZ0UP0e2gNV 1Ov+6FLl96sLnhFp6aOjiGiSOKMyoErF2vlOLEAvvDLLHc6xc83QZmLYA3cdOcNK eKa/sHRA/onG79t0IgxqUfzy7Xd2SqFpJlEjJ3TPkLCK0irY4MN4ilvsB/ksXVH5 ddrWZh1Jzg6c7VOt4yQKI05tFzw31K8XoeOPmRV4pwi5nUVY5B2nk6HYC3ljzCm6 xjjQIIc+pWAGgewsFqN1YecnQcIPfABPnRp4TlmwMuGfyKHO16F/tlL+b65X3Xyu WxoAc2qRcFbIEVi8SLUGRgctuxn9cHuirzmK8F+nrqquAXcWCwWYWv+5kEfWfAC3 KL2h+sjctskDr9lGGwBeqfVWbgX4rKepwHv7nbAMdFwOejN91jusiEnDOXE/l/2k zSNIvYeJddIBKvHigC21zej3NXIkW4xOOH+wrj0LrZm8H3eBm2Tu5/DBlOjh5rzc IQcjHIsDLah5OitNn1748b8ITttnIth6MzRkQQEN8PgYCfyTdrSmVlL56I+bLg4t 2+Kj0ppSpqKqJaEdb45JRMbjrYu+sxZKU6/myZOpD+U2mut8Q3Y= =M92W -END PGP SIGNATURE- ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Accepted python-django 1.7.11-1+deb8u3 (source all) into oldstable->embargoed, oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 30 Mar 2018 12:24:14 +1100 Source: python-django Binary: python-django python3-django python-django-common python-django-doc Architecture: source all Version: 1.7.11-1+deb8u3 Distribution: jessie-security Urgency: high Maintainer: Debian Python Modules Team <python-modules-team@lists.alioth.debian.org> Changed-By: Brian May <b...@debian.org> Description: python-django - High-level Python web development framework (Python 2 version) python-django-common - High-level Python web development framework (common) python-django-doc - High-level Python web development framework (documentation) python3-django - High-level Python web development framework (Python 3 version) Changes: python-django (1.7.11-1+deb8u3) jessie-security; urgency=high . * Non-maintainer upload by the LTS Team. * Fix CVE-2018-7536: Denial-of-service possibility in ``urlize`` and ``urlizetrunc`` template filters * Fix CVE-2018-7537: Denial-of-service possibility in ``truncatechars_html`` and ``truncatewords_html`` template filters Checksums-Sha1: 90fd1ba4dd1fe82935a9f78e9acf6f763d6dda92 2721 python-django_1.7.11-1+deb8u3.dsc f9abaf7eacec73bc1c5e6080e2778a7174ebf9d4 7586798 python-django_1.7.11.orig.tar.gz 94458a8196ee911b227365549865204f7c8fa905 36792 python-django_1.7.11-1+deb8u3.debian.tar.xz 0c7c92c1aad389b4b2df965f0645d6bc48b19a70 994520 python-django_1.7.11-1+deb8u3_all.deb 78f862ebd59af745478a5058a9f74a9ed3d54105 977346 python3-django_1.7.11-1+deb8u3_all.deb fb85b5127cb9da679cf78768f64c4a7a7eae0a6b 1498210 python-django-common_1.7.11-1+deb8u3_all.deb cd13034cc7feb8f460923c529c981a9538c786a3 2500294 python-django-doc_1.7.11-1+deb8u3_all.deb Checksums-Sha256: 020ff13d430d50ff6e2ddb8d3973ad9ef90829167fe57bfba4d551f39f7194dd 2721 python-django_1.7.11-1+deb8u3.dsc 2039144fce8f1b603d03fa5a5643578df1ad007c4ed41a617f02a3943f7059a1 7586798 python-django_1.7.11.orig.tar.gz 098bd99951b72ef0cea19d8c267714c82e1e7abc3303d7a557aebad8c71019d5 36792 python-django_1.7.11-1+deb8u3.debian.tar.xz c7e2f0188b5b7d6de5f8699c2c613fad3a3d933215a39c08b1f217955489ceaa 994520 python-django_1.7.11-1+deb8u3_all.deb 7d91dd136b1b3298535f7986977392a6582e264a942f90fa36cefe5d25164230 977346 python3-django_1.7.11-1+deb8u3_all.deb 3f4f734d1a147b4cd0f280421d446f9b4983c370530345f84ce228a35f95181a 1498210 python-django-common_1.7.11-1+deb8u3_all.deb 234cc0c4fd72a69951fa09b023e94fec39ba4670c9599f24796267f0ad92d667 2500294 python-django-doc_1.7.11-1+deb8u3_all.deb Files: c25590e5709564161b3f4e4175c4c713 2721 python optional python-django_1.7.11-1+deb8u3.dsc 030b2f9c99a6e4e0418eadf7dba9e235 7586798 python optional python-django_1.7.11.orig.tar.gz 18a7ee38c4bd80a6c9c22e2a7bc95e63 36792 python optional python-django_1.7.11-1+deb8u3.debian.tar.xz 750fd6eaac43c21bd3f9423dbd215563 994520 python optional python-django_1.7.11-1+deb8u3_all.deb a874dd9861840324d81046130ad2bc47 977346 python optional python3-django_1.7.11-1+deb8u3_all.deb ff55243bccc557db352c3c0775f615d2 1498210 python optional python-django-common_1.7.11-1+deb8u3_all.deb 379faa79c26f83310d6988740f5fcdee 2500294 doc optional python-django-doc_1.7.11-1+deb8u3_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAlq9nvgACgkQKpJZkldk Svoygw//Zw2THhVwV0ELKSlrBLD4HS78rMw7obXEyLdy6JClsqS3T51M1HZBXj4C jZXm69AC4X+UaniPmguP25rGUzIzH8UzLg3yOk8MH+tTbuyqqja/ydSNZu8xaMZR e94gRQfczB2t0WOq6mfCwXwYFLif0NWs0auqWJLgB668HbMEh+Fbvr7TX1hvto78 xYOfSCWzLkLpJ+YPpajWSRITzuo8fBweNZ+W5a0pSFn6osMO8BN5sB/0n+CBTEa2 aUHZdDUZfpEUpHbiT7/azF+XFIMDB/XP4hBWDZtVsPJlCTaXVffRueUS1Ty3TUHH aTldyuszCvjL39xKVvpnI2+FHBLEuQwJNQFJWvfVvjQpHg9fNehvzI8AXcZhfxp7 t4/8jO18S6FXd8NQWa4O/9Lok3vF90jyA8LgNCqb18yUZ0vtas8xepJnrqgCW4Vv aUHQff4+66JHanpaJWnkWr/LcANJQCW3dG72abl6LGeJUBLpoaDtEL+uuE6jOy+0 NhfxPbbcByd1+9eMFQC5u49K4rH5GNLy1+V8q9XuO8Fcr66i+6xH10t5A6Osre/n uTJ/vXxMV9ZjfhVt142mIVG+id8UD1JD6eXrnZUczm7kxIaO2/nt6LW0Gv3Odxi8 pDvVxv/Z73x0CAlFylYEcFdBFRrjoh1RUwRjYHHz5cArinslrjo= =GyF+ -END PGP SIGNATURE- ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Accepted python-django 1.4.22-1+deb7u4 (source all) into oldoldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 07 Mar 2018 17:01:54 +1100 Source: python-django Binary: python-django python-django-doc Architecture: source all Version: 1.4.22-1+deb7u4 Distribution: wheezy-security Urgency: high Maintainer: Chris Lamb <la...@debian.org> Changed-By: Brian May <b...@debian.org> Description: python-django - High-level Python web development framework python-django-doc - High-level Python web development framework (documentation) Changes: python-django (1.4.22-1+deb7u4) wheezy-security; urgency=high . * Non-maintainer upload by the LTS Team. * Fix CVE-2018-7536: Denial-of-service possibility in ``urlize`` and ``urlizetrunc`` template filters * Fix CVE-2018-7537: Denial-of-service possibility in ``truncatechars_html`` and ``truncatewords_html`` template filters Checksums-Sha1: c6f495c840e4a491c0eda87ffb3eadc5c2b5064f 2260 python-django_1.4.22-1+deb7u4.dsc cedd81e52f794c6f69b9a71c65e90f16570783c7 7802249 python-django_1.4.22.orig.tar.gz 5e9d00c8a83898d121d7b01028bbb6c13e2b05d5 32697 python-django_1.4.22-1+deb7u4.debian.tar.gz e730778e39924953a76aa26de3639e593a401e35 5382496 python-django_1.4.22-1+deb7u4_all.deb 28fba2cab13000ed1f03da12601c91785a46fb64 2468682 python-django-doc_1.4.22-1+deb7u4_all.deb Checksums-Sha256: 05f7e1f67b03374cf57361919327a5dc99518ef39470a1fbac4fdf98e113c31b 2260 python-django_1.4.22-1+deb7u4.dsc d0e2c9d772fcab2cf9c09e1c05e711cf5fe5eb93225762b29f0739d65e0d1784 7802249 python-django_1.4.22.orig.tar.gz c005727941e74c7ba29a85d60095aa8aa8cdf3a06a620f9b375b22342fc89ea1 32697 python-django_1.4.22-1+deb7u4.debian.tar.gz fdbaf382df4d0c4ea138dedb25aba2ddf6b3d2478738a553b2807918dbe8a0f3 5382496 python-django_1.4.22-1+deb7u4_all.deb 182cffea23efec346306237477d603e998a93d00d1c9f847bf5e099b744f72eb 2468682 python-django-doc_1.4.22-1+deb7u4_all.deb Files: a0b6b646a26018856fe16a7a880261f4 2260 python optional python-django_1.4.22-1+deb7u4.dsc 12dc09e5909ce4da93a9d4338db0a43d 7802249 python optional python-django_1.4.22.orig.tar.gz e7abbc3e221d1ac73d39483a502e22c1 32697 python optional python-django_1.4.22-1+deb7u4.debian.tar.gz e67601f0d07fe40ed11cb3c1ac2843b5 5382496 python optional python-django_1.4.22-1+deb7u4_all.deb 8bf50d7e4271f75ff984945614d50b4c 2468682 doc optional python-django-doc_1.4.22-1+deb7u4_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE1jZRJqkttWDGJ6ztF4RXf4EfbqwFAlqg0+IACgkQF4RXf4Ef bqxq/hAAjLl5Cl/OYRiU31V1jWN4ewHr4jp15B9h5q8DZglRBc5em/2RaqNBrqrA k2cZ2coJpOWPEextZPNVrk3R4p2gKEiL83yN+J3Q9nZkeQob50mXUl4ijANAhE3E 6nb9usa0PUe9WHZII53C7NYJZSlV8GHFdTbVr+g616SoJqVyhwQaAPMMuQfBNUaP kpuvHUMo1CJEq6quk+NHp1XsIubzc7RSvejuNBiLFRZ7eSQ2pwNj7ufextmE+Izg c+ZgrICQ/KLKU1p6y6FAL/UDKkEzBGKtE2GnksapENV42JxKvsstLgzAn0r0qWQV WPGdkpNTUPM1fW0NCOBQIUMla/jceuESKXn2Sk/3Jy76kFG9d5a3Ow48IMDemyZB ExXwJWNJATWlASs/4M1wxqDx3wxuCv3NgYNaG9t6HjA4ixBgFdYnHI7bO9NOBmfK V0K7zR0KKKaN1c2rfPTrMcnOgsSZHJs9k+cVUz7o1/qfRn38nHZ39J/bdP5eZySG I5ju/efy7RpE6baQ47TNPOa4xz5bGNYgQceaQk0/mrPu8WBf7+k+8tZC/l2kcjuJ UgINwK0kyw3w7EgFXyvRUnYlAVdVdCA2SP3iZXI3R+zOW9gD6HipCFODeHQcw2+f P7S0bwvdUwK45KptF7zMmhHv00ELB1KGqbb6L9nLDPywaNthgrw= =9BwZ -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#865588: Bug#865588: Bug#865588: djangorestframework FTBFS with Django 1.11: ERROR collecting tests/test_fields.py
Thijs Kinkhorst <th...@debian.org> writes: > We're half a year on, so has this now changed? (I tried to check out the > git repo and build it, but that had several problems so I might be missing > one or two pieces to quickly verify it). I believe Antonio has been looking at fixing the dependancies. I CCed him. Possibly there are errors in the git packaging that need to be fixed. I stopped as soon as I encountered problems, because I did not have the time to fix them. -- Brian May <b...@debian.org> ___ 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#882140: python3-django-captcha: Django 2.0 support
On Sun, Nov 19, 2017 at 10:25:49AM -0500, James Valleroy wrote: > Package: python3-django-captcha > Version: 0.5.5-1 > Severity: normal I believe 0.5.6 should fix this, now in git. Unfortunately, it depends on django-ranged-response, which isn't yet in Debian. https://pypi.python.org/pypi/django-ranged-response/0.2.0 -- Brian May <b...@debian.org> ___ 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#881196: Bug#881196: django-celery FTBFS with celery 4.1.0-1
Adrian Bunk <b...@debian.org> writes: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/django-celery.html It seems that django-celery has been abandoned by upstream. Packages like django-celery-results are recommended instead. As such, I have no desire to patch this bug (yet again), and suggest that we should think about removing the package from Debian testing and unstable instead. -- Brian May <b...@debian.org> ___ 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#855829: Bug#855829: Possible solution
Neil Williams <codeh...@debian.org> writes: > I've pushed a new temporary branch [0] (which can be removed once > reviewed) which uses the removal method in lieu of upstream merging the > pull request [1] and making a new upstream release. Please review. Looks fine to me. At least on a temp basis. Uploaded. -- Brian May <b...@debian.org> ___ 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#855829: Bug#855829: Bug#855829: Possible solution
Neil Williams <codeh...@debian.org> writes: > I suggest that the first step is to remove the problematic tablib > support from a new 1.10 django-tables upload with a view to closing the > bugs and allowing migration. Later, consideration can be given to adding > the support back *if* tablib is fixed in Debian. More likely, I suspect > that tablib will disappear along with the xsl dependencies and the > python2 runtime for antlr as the Python3 migration moves forward. I expect to be busy for the time being, however if somebody is able to make the above changes to git (or offer an alternative suggestion), I should be able to review and upload a new package. Thanks! -- Brian May <b...@debian.org> ___ 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#855829: Bug#855829: Possible solution
Neil Williams <codeh...@debian.org> writes: > I'll test this .dsc with django 1.11 and in my local installs of > lava-server to make sure it is functional but does this sound like a > workable solution for keeping django-tables in Debian? I don't see any > other solution to the FTBFS against django1.11 at the moment (#865814). My first thoughts are: * Removing a major feature from upstream is bad. * However removing the feature is probably less evil then dropping the package. * We probably should contact upstream about the problem, as it sounds like this means the upstream package is no longer Python3 compatable - if I understood correctly. -- Brian May <b...@debian.org> ___ 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#868808: Bug#868808: celery: Memory addresses being output in documentation fixed in upstream
Preston Moore <prestonkmo...@gmail.com> writes: > As part of the reproducible builds effort[1] I have been working with Celery's > developers to merge a fix that will allow Sphinx to correctly strip memory > addresses as it generates Celery's documentation. This fix is now in place > upstream. It seems like there is not going to be a new celery release anytime soon: https://github.com/celery/celery/pull/3958#issuecomment-313997326 Are you able to provide a link to the commit that fixed this? -- Brian May <b...@debian.org> ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#867481: Bug#867481: celery FTBFS: test_recursive runs forever with python 3.6
Adrian Bunk <b...@debian.org> writes: >> * sphinx_celery > > https://tracker.debian.org/pkg/sphinx-celery Looks like there is only a Python3 version of the package... -- Brian May <b...@debian.org> ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#867481: Bug#867481: celery FTBFS: test_recursive runs forever with python 3.6
Adrian Bunk <b...@debian.org> writes: > test_recursive (celery.tests.app.test_log.test_logger_isa) ... Wed Aug 8 > 21:54:56 UTC 2018 - pbuilder was killed by timeout after 18h. > Thu Jul 6 15:31:49 UTC 2017 - total duration: 18h 0m 25s. Presumabley this is fixed in the latest celery. However it looks like the latest celery requires two new packages not yet in Debian: * sphinx_celery * cyanide -- Brian May <b...@debian.org> ___ 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-ldap3_2.2.4-1_i386.changes REJECTED
Debian FTP Masters <ftpmas...@ftp-master.debian.org> writes: > The upload includes 'python-ldap3_2.2.4-1_i386.changes' whose filename > includes the architecture name i386, but does not include binaries for > i386. It is rejected to avoid filename conflicts with later buildd > uploads. I just successfully uploaded django-environ_0.4.3-1_i386.changes into unstable today. Why did this upload get rejected? Regards -- Brian May <b...@debian.org> ___ 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#865588: Bug#865588: djangorestframework FTBFS with Django 1.11: ERROR collecting tests/test_fields.py
Currently getting this error building the latest version - as in the
Debian git package.
Possibly this is because we depend on a package that needs updating -
mostly likely mkdocs or jinja2 - but wonder which one? Maybe we should
just update both anyway.
# Build the HTML documentation.
mkdir /<>/docs.debian
LC_ALL=C.UTF-8 PYTHONPATH=/usr/share/mkdocs/themes mkdocs build && mv site
docs.debian/html
INFO- Building documentation to directory: /<>/site
Traceback (most recent call last):
File "/usr/bin/mkdocs", line 9, in
load_entry_point('mkdocs==0.15.3', 'console_scripts', 'mkdocs')()
File "/usr/lib/python3/dist-packages/click/core.py", line 716, in __call__
return self.main(*args, **kwargs)
File "/usr/lib/python3/dist-packages/click/core.py", line 696, in main
rv = self.invoke(ctx)
File "/usr/lib/python3/dist-packages/click/core.py", line 1060, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3/dist-packages/click/core.py", line 889, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3/dist-packages/click/core.py", line 534, in invoke
return callback(*args, **kwargs)
File "/usr/lib/python3/dist-packages/mkdocs/__main__.py", line 137, in
build_command
), clean_site_dir=clean)
File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 290, in
build
build_pages(config)
File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 234, in
build_pages
build_template('404.html', env, config, site_navigation)
File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 149, in
build_template
output_content = template.render(context)
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in
render
return self.environment.handle_exception(exc_info, True)
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in
handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
raise value.with_traceback(tb)
File "/<>/docs_theme/404.html", line 1, in top-level template
code
{% extends "main.html" %}
File "/<>/docs_theme/main.html", line 7, in top-level template
code
{% if page.title %}{{ page.title }} - {% endif %}{{ config.site_name
}}
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 430, in
getattr
return getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'page' is undefined
--
Brian May <b...@debian.org>
___
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#865937: Bug#865937: python-django-extensions FTBFS: ValueError: expected only letters, got u''
Adrian Bunk <b...@debian.org> writes: > python-django-extensions FTBFS with the new python-babel: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django-extensions.html I have reproduced this failure in python-django-extensions 1.8.0 and forwarded it upstream: https://github.com/django-extensions/django-extensions/issues/1072 -- Brian May <b...@debian.org> ___ 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#865814: Bug#865814: django-tables FTBFS with Django 1.11
Looks like fixing this is going to require python3-tablib package. We have a python-tablib package, not a python3-tablib one though. I filled a bug report against python-tablib source. ERRORS _ ERROR collecting tests/export/test_export.py _ tests/export/test_export.py:12: in from django_tables2.export.export import TableExport django_tables2/export/__init__.py:2: in from .export import TableExport django_tables2/export/export.py:10: in 'You must have tablib installed in order to use the django-tables2 export functionality' E ImproperlyConfigured: You must have tablib installed in order to use the django-tables2 export functionality !!! Interrupted: 1 errors during collection === 1 error in 0.88 seconds -- Brian May <b...@debian.org> ___ 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#865814: Bug#865814: django-tables FTBFS with Django 1.11
Brian May <b...@debian.org> writes: > Looks like fixing this is going to require python3-tablib package. We > have a python-tablib package, not a python3-tablib one though. > > I filled a bug report against python-tablib source. #865855 -- Brian May <b...@debian.org> ___ 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#852512: marked as pending
Chris Lamb <la...@debian.org> writes: > Brian May wrote: >> >> Bug #852512 reported by you has been fixed in the Git repository. You can >> see the changelog below, and you can check the diff of the fix at: >> >> >> https://anonscm.debian.org/cgit/python-modules/packages/python-django.git/commit/?id=249c143 > > --- a/debian/control > +++ b/debian/control > @@ -38,6 +38,11 @@ Build-Depends: > python3-tblib , > python3-tz , > python3-yaml , > + python-doc , > + sphinx-doc , > + python-six-doc , > + python-django-formtools-doc , > + python-psycopg2-doc , > > > Is the "" restriction correct? We generate the documentation > regardless of whether we are running the testsuite or not. Oops. I meant to check this before doing the git push. I have not seen this "" before, and have no idea what it means. Can you provide me a reference? Thanks -- Brian May <b...@debian.org> ___ 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#855829: Bug#855829: Where is the build log for django-tables2?
Neil Williams <codeh...@debian.org> writes: > severity 855829 normal > retitle 855829 New upstream release needed in experimental for testing with > django 1.11 > tag 855829 - buster > tag 855829 - sid > thanks Django 1.11 is now in unstable, hence I don't understand why you made the above changes. -- Brian May <b...@debian.org> ___ 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#769052: libapache2-mod-wsgi-py3: should not provide httpd-wsgi
Brian May <b...@debian.org> writes: > On Tue, Nov 11, 2014 at 11:40:56AM +1100, Brian May wrote: >> A bug report has been filled against debian-policy for a httpd-wsgi3 >> virtual package for Python 3 WSGI, see #768117. > > This happened years ago... > > Please change the provides to use httpd-wsgi3 instead of httpd-wsgi. This is now in the policy. #768117 has been closed. So are there any objections to making this change now? (apologies, I thought policy update had already happened) -- Brian May <b...@debian.org> ___ 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-pip ancient version 1.5 for Debian 8
CCing to correct mailing list. debian-pyt...@lists.debian.org I don't actually understand the issue. Clark Knøsen <cl...@electrobeat.dk> writes: > python-pip is no longer compatible with newer installations/repos like > > # pip install pyvirtualdisplay selenium > > python-pip installs 1.5 and the current version i 9.0 -- Brian May <br...@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/ ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#863267: Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8
Raphael Hertzog <hert...@debian.org> writes: > Is that actually true? linaro_django_xmlrpc seems to be listed in > INSTALLED_APPS, no? > > Do you have any idea why it would give this error? I note that linaro_django_xmlrpc is towards the end of INSTALLED_APPS. Maybe it did not get loaded? Maybe it stopped loading apps the moment it detects a bad dependancy? After looking at the code, this doesn't exactly make sense, but maybe something here might help regardless. -- Brian May <b...@debian.org> ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#863267: Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8
Some misconceptions resolved: * This bug does not cause any data to be deleted. * This bug does not cause any data to be currupted. * This bug does not cause any data to be lost. * This bug only affects one application. Out of many others that use Django. The damage this bug does cause: * If you try to upgrade the package in question, the migrations will run in the postinst script. These migrations will fail - before even touching the database. This is a pre-migration sanity check that fails. This in turn means the postinst script will fail and the package is marked as bad. All the data is still there, and it hasn't been touched. It may not be accessible to the application however, as it will depend on the migrations being run. The application may crash as the database schema is different from what it expects. I do not believe this should be an RC bug against Django. -- Brian May <b...@debian.org> ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#863267: Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8
Neil Williams <codeh...@debian.org> writes: > Again, I also spotted this and thought it was the source. However, > changing this causes the migration to fail with 1.10 as there are > objects in this model which must be applied before > lava_scheduler_app/0001_initial will complete. e.g. the AuthToken > object is referred to directly in lava_scheduler_app/0001_initial and > this is defined by linaro_django_xmlrpc Yes, I was just attempting to publicly document what is causing the problem, as opposed to coming up with a solution to the problem. > I tried a few simplistic edits of those migration files on a test > instance, the migrations still fail to apply. I had a feeling simple changes would not work here. My generally feeling at the moment is: A. Create simple minimal test case with two Django Apps and a script that does the minimum required to demonstrate the problem. B. Create a Django bug report pointing to our test case. They may or may not accept it as a bug in Django, however it would be good to get their feedback. C. My idea for a work around is to write code that will directly update the Django migration tables to indicate that this migration really has been applied. -- Brian May <b...@debian.org> ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#863267: Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8
Neil Williams <codeh...@debian.org> writes:
> django.db.migrations.exceptions.InconsistentMigrationHistory: Migration
> lava_scheduler_app.0001_initial is applied before its dependency
> linaro_django_xmlrpc.0001_initial on database 'default'.
Ok, I see what is going on now. Untested theory at the moment, but it
fits the symptoms.
./lava_scheduler_app/migrations/0001_initial.py contains:
dependencies = [
('auth', '0001_initial'),
migrations.swappable_dependency(settings.AUTH_USER_MODEL),
('linaro_django_xmlrpc', '__first__'),
('dashboard_app', '__first__'),
]
My reading of this is that this means this migration depends on the
first migration from 'linaro_django_xmlrpc' to be already
applied. However on Jessie, 'linaro_django_xmlrpc' has no
migrations. Hence I suspect whatever version of Django that installed
this migration to be buggy, because it didn't check the dependencies
could be satisfied. Or maybe this was considered OK at the time.
This migration is already applied when we come to do the new migrations
for Django 1.8 or Django 1.10
Django 1.8 doesn't care that the first migration for
'linaro_django_xmlrpc' hasn't been applied yet. As a result, it can fake
the migration and everyone is happy.
Django 1.10 does care. It says the database is broken because the
prerequisite for this migration was never applied. It does this check
before applying any migrations.
I don't know for sure what is correct behaviour here. However I am
inclined to think maybe this isn't a Django 1.10 fault, because the
migration in Jessie clearly says it depends on a migration that was
never applied - because it doesn't even exist at this point.
--
Brian May <b...@debian.org>
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#863267: Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8
Neil Williams <codeh...@debian.org> writes: > Applying linaro_django_xmlrpc.0001_initial... FAKED I am speculating this line might be very relevant. Taken from the Django 1.8 migration. Looks like this never had a migration before, so now needs to be faked. I wonder if this is what is triggering the Django 1.10 bug. To the best of my knowledge this should still be supported. If I am right, then it should be possible to work around this by manually applying the migration in fake mode. -- Brian May <b...@debian.org> ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#863267: Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8
Neil Williams <codeh...@debian.org> writes: > Upgrading directly to Stretch: Just to clarify: Was this upgrading the entire system to stretch, or just the relevant packages? -- Brian May <b...@debian.org> ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED
Ian Campbell <i...@debian.org> writes: > Yet 1.10.x is going to be in Stretch, according to [0]? If users want > LTS then why aren't we shipping that in our upcoming stable release > (whether its instead of or in addition to the latest release)? In general the Django LTS releases occur after on a cycle, several months after the Debian Freeze. Django 1.11 LTS was released in April 2017 for example. Even if we could get Django 1.11 in the freeze, as Raphael Hertzog was suggesting in another email, not sure how the release team would feel about this - and it would be up to them I think. There may be ways to ease the pain, however it would still be up to the release team. I seem to recall the same thing happened when Django 1.8 LTS was released, Jessie was already in freeze. The alternative option is that we use the previous LTS Django release. However, that would mean Jessie would still be on Django 1.4, which lost upstream support in 2015. Similarly, if Stretch was released with 1.8 LTS (yes I know, this is not really an option anymore), Django 1.8 will loose support April next year - when Stretch is still supported. We would basically be releasing Debian with a old LTS version of Django that is obsolete before Debian is even released. Reference: https://www.djangoproject.com/download/ -- Brian May <b...@debian.org> ___ 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#863026: Bug#863026: Broken symlinks break collecstatic on deploy
Enrico Zini <enr...@debian.org> writes: > Yes, my mistake, I found the bug on nono.debian.org (jessie) but I > reported it from my laptop (testing). Actually, partly my mistake. This is a different bug. I hadn't noticed, but this bug is specific for the Python2 package on Jessie. Where as the bug I reported was specific to the Python3 package. The problem being that the symlinks refer to the "pyshared" directory, which was removed IIRC after wheezy. It was intended to share files between Python 2.6 and Python 2.7. These symlink were removed in version 3.0.5-0.2. +djangorestframework (3.0.5-0.2) experimental; urgency=medium + + * Non-maintainer upload. + * Fix broken links to media files. Remove debian/*.links, these symlinks are +no longer relevant. + + -- Brian May <b...@debian.org> Mon, 16 Mar 2015 14:20:11 +1100 + > I noticed after sending the bug, then tried to send found/notfound > commands to fix the versions, but apparently I didn't manage to mark > 3.4.0-2 as fixed. I will fix that. However note that "notfound" is the opposite of "found", it will remove the "found" version. What you were looking for was the "fixed" instruction. > I'm sorry I didn't notice #858811, I guess since it doesn't know it > affects stable, it got closed and archived. Don't be sorry - it affected the same file, but was a different bug, in a different package. Question: Does this deserve an update in the next Debian Jessie point release? There was a point release just recently, so might be several months until the next one. -- Brian May <b...@debian.org> ___ 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#863026: Bug#863026: Broken symlinks break collecstatic on deploy
Enrico Zini <enr...@debian.org> writes: > Package: python-djangorestframework > Version: 3.4.0-2 > Severity: important > > Hello, > > when using rest_framework in jessie, collectstatic raises this exception: Sorry, I am confused. You say this happens in Jessie, but refer to version 3.4.0-2 which is in stretch and sid. In any case, it sounds like this bug, which *is* fixed in 3.4.0-2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858811 -- Brian May <b...@debian.org> ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#860882: [package:python-passlib] Generated egg version is invalid. Breaks Ansible runs.
Brian May <b...@debian.org> writes: > In what way do you consider this a bug in python-passlib and not > ansible? Looks like an Ansible bug to me: https://github.com/ansible/ansible/issues/20199 -- Brian May <b...@debian.org> ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#860882: [package:python-passlib] Generated egg version is invalid. Breaks Ansible runs.
On Fri, Apr 21, 2017 at 12:10:21PM +0200, Aurelien ROUGEMONT wrote: > __version__ = '1.7.0.post20170421091442' > > This version is not parsable by ansible. In the project's setup.py you can > find this : In what way do you consider this a bug in python-passlib and not ansible? (Not saying you are wrong, just trying to understand this better) -- Brian May <b...@debian.org> ___ 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#860673: Bug#860673: python-django: FTBFS on i386: E: Build killed with signal TERM after 150 minutes of inactivity
Chris Lamb <la...@debian.org> writes: > Lucas Nussbaum wrote: > >> > test_output_verbose (test_runner.test_debug_sql.TestDebugSQL) ... ok >> > E: Build killed with signal TERM after 150 minutes of inactivity > > Can't reproduce this locally alas... I couldn't reproduce this locally. I use a 32bit schroot. -- Brian May <b...@debian.org> ___ 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#860619: Bug#860619: python-passlib: FTBFS on i386: Test failures
Brian May <b...@debian.org> writes: > I believe this is fixed in version 1.7.1 which is in unstable. Unblock request sent: #860717 -- Brian May <b...@debian.org> ___ 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#860619: Bug#860619: python-passlib: FTBFS on i386: Test failures
Lucas Nussbaum <lu...@debian.org> writes: > Relevant part (hopefully): >> File "", line 673, in _load_unlocked >> File "", line 673, in exec_module >> File "", line 222, in >> _call_with_frames_removed >> File "/<>/passlib/tests/test_totp.py", line 61, in >> datetime.datetime.utcfromtimestamp(max_time_t << 1) >> OverflowError: timestamp out of range for platform time_t I believe this is fixed in version 1.7.1 which is in unstable. This is actually Python 3.6 bug: https://bugs.python.org/issue29100 https://bugs.python.org/issue29346 python-passlib applied a work around: https://bitbucket.org/ecollins/passlib/commits/80f838f5771f6753b0e46716ab25b48641aeef89 -- Brian May <b...@debian.org> ___ 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#860619: Bug#860619: python-passlib: FTBFS on i386: Test failures
Brian May <b...@debian.org> writes: > This is actually Python 3.6 bug: Actually that claim makes no sense as Python 3.6 isn't in Debian testing or unstable yet. -- Brian May <b...@debian.org> ___ 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#860342: Bug#860342: python3-taglib: Newer upstream releases available since Jan 21, 2014
Robbie Harwood <rharw...@club.cc.cmu.edu> writes: > $ axi-cache rdepends python3-taglib | egrep -v 'dbgsym|i386' > python3-taglib > Reverse Depends: > bluemindo > libstdc++6 > > The former is a music player, which makes sense, and has a version in > experimental; the latter is perplexing to me. As far as I can tell, libstdc++6 doesn't actually depend on python3-taglib. No idea why your results show otherwise. blumindo is not in unstable or stretch. Guessing you were looking at the version in experimental. -- Brian May <b...@debian.org> ___ 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#860342: Bug#860342: python3-taglib: Newer upstream releases available since Jan 21, 2014
Robbie Harwood <rharw...@club.cc.cmu.edu> writes: > Please update to a newer version of the package. This looks unmaintained and > I would have filed an RM request save that there are packages that depend on > this in the archive. What packages depend on python3-taglib? I can't see anything in testing. (no, I do not I consider this grounds for an RM by itself). -- Brian May <b...@debian.org> ___ 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#858305: Bug#858305: celeryd: celerdy should depend on python-celery-common?
Nish Aravamudan <nish.aravamu...@canonical.com> writes: > I was able to verify the updated package in unstable has the correct > dependencies and when 'celeryd' is installed, the appropriate binaries > `celery` and `celeryd` are avaiable. Thanks for the confirmation. Unblock request sent: #858864 -- Brian May <b...@debian.org> ___ 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#858811: python3-djangorestframework: grid.png installed in wrong place
Package: python3-djangorestframework Version: 3.4.0-1 Severity: important grid.png is installed here: /usr/share/doc/python3-djangorestframework/img/grid.png But the following file: /usr/lib/python3/dist-packages/rest_framework/static/rest_framework/css/bootstrap-tweaks.css Expects to find it here: /usr/lib/python3/dist-packages/rest_framework/static/rest_framework/img/grid.png This can break collectstatic, at least with django-pipelines. In comparison, python-djangorestframework has grid.png installed in the correct place. I plan on looking at this myself. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-djangorestframework depends on: ii python3-django 1:1.10.6-1 pn python3:any Versions of packages python3-djangorestframework recommends: ii python3-defusedxml 0.4.1-2 ii python3-django-filters 0.13.0-1 ii python3-django-guardian 1.4.4-1 ii python3-markdown 2.6.8-1 ii python3-pil 4.0.0-4 Versions of packages python3-djangorestframework suggests: pn python-djangorestframework-doc -- no debconf information ___ 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#769052: libapache2-mod-wsgi-py3: should not provide httpd-wsgi
On Tue, Nov 11, 2014 at 11:40:56AM +1100, Brian May wrote: > A bug report has been filled against debian-policy for a httpd-wsgi3 > virtual package for Python 3 WSGI, see #768117. This happened years ago... Please change the provides to use httpd-wsgi3 instead of httpd-wsgi. -- Brian May <b...@debian.org> ___ 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#858305: Bug#858305: celeryd: celerdy should depend on python-celery-common?
Nish Aravamudan <nish.aravamu...@canonical.com> writes: >> I have pushed a change through to git that will fix this on the next >> release. I just uploaded this to unstable. Are you able to test this? (note I did not fix the bashism issue yet) Thanks -- Brian May <b...@debian.org> ___ 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#858540: barbican: FTBFS: ImportError: No module named vine.five
Brian May <b...@debian.org> writes: >> File "/usr/lib/python2.7/dist-packages/kombu/five.py", line 6, in >> >> import vine.five >> ImportError: No module named vine.five Just to keep this bug report up-to-date: This particular problem is easy to fix, and I have made the fix to git. Unfortunately there is a bigger problem, and that is that kombu depends on a package in experimental (python-ampq). This is due to an accidental-upload-to-unstable-instead-of-experimental. For the latest progress on this, read the thread in debian-python or see the bug report #858586. I imagine we will end up fixing this by downgrading kombu. -- Brian May <b...@debian.org> ___ 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#858540: barbican: FTBFS: ImportError: No module named vine.five
On Thu, Mar 23, 2017 at 08:02:30PM +, Chris Lamb wrote: > This appears to affect more than src:barbican (eg. src:designate) and is > probably a bug in Kombu instead: > > File "/usr/lib/python2.7/dist-packages/kombu/five.py", line 6, in > import vine.five > ImportError: No module named vine.five Just for the record, this does *not* affect the version in testing. (which initially had me concerned because vine is not in testing) -- Brian May <b...@debian.org> ___ 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#858305: Bug#858305: celeryd: celerdy should depend on python-celery-common?
Nishanth Aravamudan <nish.aravamu...@canonical.com> writes: > It seems like celeryd incorrectly only depends on python-celery (which > appears to just the python2 library code), but the init scripts in > celeryd invoke celery and celeryd, which are (now?) in > python-celery-common. I have pushed a change through to git that will fix this on the next release. However note that I am not entirely happy with celeryd. The problem being that the init.d depends on some project directory that is outside the scope of Debian. As a result choices like python2 or python3 are arbitrary (unless override in the defaults file) and may be wrong for the given project. Or may change unexpectedly. e.g. installing python3-celery will make it default to python3. Would be better I think if the project supplied its own init.d script. -- Brian May <b...@debian.org> ___ 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#856625: Accidentally duplicated work
Harlan Lieberman-Berg <hlieber...@debian.org> writes: > I was following #856625 and accidentally duplicated some work of yours. > I saw that the RC bug was fixed in the latest upstream release, so I > packaged 2.3 and shoved it into the git before I saw you had started > working on cherry-picking the patch in. I've rebased my work and pushed > it up as UNRELEASED, just in case it is helpful for the future. I am not sure how you updated to the latest upstream version. Somehow you did it without merging from upstream. As this is still a git-dpm package, you should be using git-dpm tools to update to a new upstream. Maybe this is as a result of a rebase - a rebase won't preserve merge commits. If you type in "git-dpm status" you can clearly see it is not happy. However, more importantly, the release team is very unlikely to let a new upstream version into unstable. So, unfortunately, I am inclined to remmend reverting all changes on the master branch since debian/2.1-3 for now. If you want, I can do this. Because if any future RC bugs occur during the freeze, we need to be able to make new releases from from the master branch for the same upstream version. -- Brian May <b...@debian.org> ___ 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#851722: Bug#851722: django-pipeline: FTBFS randomly (failing tests)
Brian May <b...@debian.org> writes: > Ok, I got a suggestion to run the failing test by itself. It fails > everytime. As reported in the upstream bug report. Unblock request sent: #857429 -- Brian May <b...@debian.org> ___ 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#856625: Bug#856625: parsedatetime: FTBFS (AssertionError: 0.0666666666667 is not less than 0.05)
Santiago Vila <sanv...@debian.org> writes: > Maybe this "only" fails shortly after February 28th, but we really want > tests to never fail. It is possible that this package assumes one or more > things in the following list?: To me it looks like the test is assuming a month is 30 days. It allows some margin for error, so 31 days might be OK, however by the looks of it, 28 days is not OK. I have forwarded this upstream: https://github.com/bear/parsedatetime/issues/215 -- Brian May <b...@debian.org> ___ 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#851722: Bug#851722: django-pipeline: FTBFS randomly (failing tests)
Santiago Vila <sanv...@unex.es> writes: > So I think forwarding the bug would make sense. Just tell upstream the > truth, namely, that you have received a bug saying the package fails > to build randomly. See https://github.com/jazzband/django-pipeline/issues/622 -- Brian May <b...@debian.org> ___ 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#851722: Bug#851722: django-pipeline: FTBFS randomly (failing tests)
Brian May <b...@debian.org> writes: > Santiago Vila <sanv...@unex.es> writes: > >> So I think forwarding the bug would make sense. Just tell upstream the >> truth, namely, that you have received a bug saying the package fails >> to build randomly. > > See https://github.com/jazzband/django-pipeline/issues/622 Ok, I got a suggestion to run the failing test by itself. It fails everytime. As reported in the upstream bug report. -- Brian May <b...@debian.org> ___ 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#855877: Bug#855877: python3-django-celery: management commands broken with Django 1.10
Antonio Terceiro <terce...@debian.org> writes: > Package: python3-django-celery > Version: 3.1.17-3.1 > Severity: grave > Forwarded: https://github.com/celery/django-celery/pull/458 > Justification: renders package unusable Unblock request sent #855899 -- Brian May <b...@debian.org> ___ 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#852512: Bug#852512: python-django: Please avoid accessing the internet for intersphinx mapping
Chris Lamb <la...@debian.org> writes:
> This is caused by:
>
>intersphinx_mapping = {
> 'python': ('https://docs.python.org/3/', None),
> 'sphinx': ('http://sphinx-doc.org/', None),
> 'six': ('https://pythonhosted.org/six/', None),
As far as I can tell, this documentation isn't packaged in Debian.
> 'formtools': ('https://django-formtools.readthedocs.io/en/latest/',
> None),
> 'psycopg2': ('http://initd.org/psycopg/docs/', None),
> }
I think everything else is packaged, just missing a python-six-doc
package.
--
Brian May <b...@debian.org>
___
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#854716: Bug#854716: python3-django-cors-headers: Does not work with Django 1.10
Michael Fladischer <mich...@fladi.at> writes: > Updating to 1.2.0 would solve this but the freeze is already in place, so it's > either backporting the fix from upstream[0] or asking fo an exeption from > release team. Unblock request sent for backport: #854833 -- Brian May <b...@debian.org> ___ 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#854716: Bug#854716: python3-django-cors-headers: Does not work with Django 1.10
Michael Fladischer <mich...@fladi.at> writes: > the version of django-cors-headers currently in testing/unstable does not work > with Django 1.10 because of changes to the middleware system. Upstream has an > issue on this: It looks like it is a bit more complicated then "does not work". If you use the old style MIDDLEWARE_CLASSES setting, it works fine, same as before. The problems only occur if you want to use the new style MIDDLEWARE setting. I can confirm that the supplied patch soles the problem. -- Brian May <b...@debian.org> ___ 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#854716: Bug#854716: python3-django-cors-headers: Does not work with Django 1.10
Michael Fladischer <mich...@fladi.at> writes: > Updating to 1.2.0 would solve this but the freeze is already in place, so it's > either backporting the fix from upstream[0] or asking fo an exeption from > release team. It is going to require approval from the release team either way. However, probably fare easy to get approval for one commit as opposed to all of these: https://github.com/ottoyiu/django-cors-headers/compare/1.1.0...1.2.0 > [0] > https://github.com/ottoyiu/django-cors-headers/commit/870b1d9deb54ff4c1fefedc39dff02519abb32c5 I will have a look. -- Brian May <b...@debian.org> ___ 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#849652: Bug#849652: faker: FTBFS on 32-bit: ValueError: timestamp out of range for platform time_t
To: debian-python mailing list Help in fixing this RC bug would be appreciated. I have forwarded this upstream, however need a quick fix for the Debian package (not sure but suspect it might be too late for stretch). Unfortunately, not sure where to start. I don't understand this date_time_this_century() function that appears to be the cause of it. Thanks "Chris West (Faux)" <solo-debianb...@goeswhere.com> writes: > The package fails to build: > > FulROR: test_date_time_this_period (faker.tests.FactoryTestCase) > -- > Traceback (most recent call last): > File "faker/tests/__init__.py", line 389, in test_date_time_this_period > > self.assertTrue(self._datetime_to_time(provider.date_time_this_century(before_now=False, > after_now=True)) >= self._datetime_to_time(datetime.datetime.now())) > File "faker/providers/date_time/__init__.py", line 403, in > date_time_this_century > return cls.date_time_between_dates(now, next_century_start, tzinfo) > File "faker/providers/date_time/__init__.py", line 381, in > date_time_between_dates > datetime_to_timestamp(datetime_end), > File "faker/providers/date_time/__init__.py", line 22, in > datetime_to_timestamp > return mktime(dt.timetuple()) > OverflowError: mktime argument out of range > > == > ERROR: test_date_time_this_period_with_tzinfo (faker.tests.FactoryTestCase) > -- > Traceback (most recent call last): > File "faker/tests/__init__.py", line 418, in > test_date_time_this_period_with_tzinfo > provider.date_time_this_century(before_now=False, after_now=True, > tzinfo=utc) >= datetime.datetime.now() > File "faker/providers/date_time/__init__.py", line 403, in > date_time_this_century > return cls.date_time_between_dates(now, next_century_start, tzinfo) > File "faker/providers/date_time/__init__.py", line 381, in > date_time_between_dates > datetime_to_timestamp(datetime_end), > File "faker/providers/date_time/__init__.py", line 21, in > datetime_to_timestamp > dt = dt.astimezone(tzlocal()) > File "/usr/lib/python2.7/dist-packages/dateutil/tz/tz.py", line 99, in > utcoffset > if self._isdst(dt): > File "/usr/lib/python2.7/dist-packages/dateutil/tz/tz.py", line 143, in > _isdst > return time.localtime(timestamp+time.timezone).tm_isdst > ValueError: timestamp out of range for platform time_t > > -- > Ran 45 tests in 7.922s > > FAILED (errors=2) > debian/rules:27: recipe for target 'override_dh_auto_test' failed -- Brian May <b...@debian.org> ___ 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#852289: Bug#852289: python-passlib: please make the build reproducible (timestamps)
Barry Warsaw <ba...@debian.org> writes: > On Jan 23, 2017, at 04:40 PM, Eli Collins wrote: > >>In case this helps the debian package maintainer decide on this patch / >>schedule things, the timestamp problem this addresses is due to a bug in >>the passlib 1.7.0 setup script, which should be fixed in the 1.7.1 upstream >>release (due out next weekend). > > Thanks for the status Eli. If the bug is fixed upstream, I think it makes > sense to just wait until 1.7.1. Feel free to drop us a ping when that's > available (though I'll eventually notice it anyway). If Brian doesn't beat me > to it, I'm happy to update to 1.7.1 once it's available. Considering the coming freeze, might be best to upload a fix before then... If you want this in stretch that is. -- Brian May <b...@debian.org> ___ 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#851722: Bug#851722: django-pipeline: FTBFS randomly (failing tests)
Hello All,
I would appreciate any help with this bug. While I have ideas on the
cause, I cannot reproduce it; and I am reluctant to forward upstream a
bug I cannot personally reproduce.
Thanks.
Santiago Vila <sanv...@debian.org> writes:
> Package: src:django-pipeline
> Version: 1.6.8-2
> Severity: important
>
> Dear maintainer:
>
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> but it failed:
>
>
> [...]
> debian/rules build-indep
> dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
>dh_testdir -i -O--buildsystem=pybuild
>dh_update_autotools_config -i -O--buildsystem=pybuild
>dh_auto_configure -i -O--buildsystem=pybuild
> I: pybuild base:184: python2.7 setup.py config
> running config
> I: pybuild base:184: python3.5 setup.py config
> running config
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/<>'
> dh_auto_build
> I: pybuild base:184: /usr/bin/python setup.py build
> running build
>
> [... snipped ...]
>
> default_collector.clear()
> File "/<>/pipeline/collector.py", line 23, in clear
> dirs, files = self.storage.listdir(path)
> File "/usr/lib/python2.7/dist-packages/django/core/files/storage.py", line
> 399, in listdir
> for entry in os.listdir(path):
> OSError: [Errno 2] No such file or directory: '/<>/tests/static'
>
> ==
> ERROR: test_pipeline_enabled_and_found
> (tests.tests.test_views.ServeStaticViewsTest)
> --
> Traceback (most recent call last):
> File "/<>/tests/tests/test_views.py", line 24, in setUp
> default_collector.clear()
> File "/<>/pipeline/collector.py", line 23, in clear
> dirs, files = self.storage.listdir(path)
> File "/usr/lib/python2.7/dist-packages/django/core/files/storage.py", line
> 399, in listdir
> for entry in os.listdir(path):
> OSError: [Errno 2] No such file or directory: '/<>/tests/static'
>
> ==
> ERROR: test_pipeline_enabled_and_not_found
> (tests.tests.test_views.ServeStaticViewsTest)
> --
> Traceback (most recent call last):
> File "/<>/tests/tests/test_views.py", line 24, in setUp
> default_collector.clear()
> File "/<>/pipeline/collector.py", line 23, in clear
> dirs, files = self.storage.listdir(path)
> File "/usr/lib/python2.7/dist-packages/django/core/files/storage.py", line
> 399, in listdir
> for entry in os.listdir(path):
> OSError: [Errno 2] No such file or directory: '/<>/tests/static'
>
> --
> Ran 88 tests in 0.931s
>
> FAILED (errors=8, skipped=15)
> Creating test database for alias 'default'...
> Destroying test database for alias 'default'...
> E: pybuild pybuild:276: test: plugin custom failed with: exit code=1:
> PYTHONPATH=. python2.7 /usr/bin/django-admin test --settings=tests.settings
> dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
> debian/rules:24: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 25
> make[1]: Leaving directory '/<>'
> debian/rules:11: recipe for target 'build-indep' failed
> make: *** [build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
>
>
> This is just how the build ends, not necessarily the relevant part.
>
> I've put several build logs here:
>
> https://people.debian.org/~sanvila/build-logs/django-pipeline/
>
> If this is really a bug in one of the build-depends, please use reassign and
> affects,
> so that this is still visible in the page for this package.
>
> The bug should be reproducible with sbuild on a single CPU virtual machine,
> provided you try enough times (as the failure happens randomly).
>
> Thanks.
>
> ___
> Python-modules-team mailing list
> Python-modules-team@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
--
Brian May <b...@debian.org>
___
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#851722: Bug#851722: django-pipeline: FTBFS randomly (failing tests)
Santiago Vila <sanv...@debian.org> writes:
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> but it failed:
I am not able to reproduce this :-(
I am guessing it might be related to different order the tests are being
run in or something. Which can be non-determinstic - depends on order
files are listed in filesystem.
Are you able to reproduce with the following patch? This will show what
order the tests are being run in:
diff --git a/debian/rules b/debian/rules
index dc35e19..f53ec96 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,4 +21,4 @@ override_dh_installchangelogs:
dh_installchangelogs -- HISTORY.rst
override_dh_auto_test:
- PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="PYTHONPATH=. python{version}
/usr/bin/django-admin test --settings=tests.settings" dh_auto_test
+ PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="PYTHONPATH=. python{version}
/usr/bin/django-admin test -v3 --settings=tests.settings" dh_auto_test
Thanks!
--
Brian May <b...@debian.org>
___
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#839687: Bug#839687: how to manage setuptools-scm packages in debian?
Antoine Beaupré <anar...@debian.org> writes: > Answering my own question (and it would be nice to have this documented > somewhere!), the solution is to use a more recent dh-python dependency > and depend on python-setuptools-scm explicitely, *and* use > --buildsystem=pybuild. In the past I have found I need to set (in debian/rules): export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell cat PKG-INFO | sed -n 's/^Version: //p') otherwise the version won't come out correctly. -- Brian May <b...@debian.org> ___ 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#832360: Bug#832360: mkdocs: javascript in mkdocs themes should be symlinks to files in libjs-* packages
Sean Whitton <spwhit...@spwhitton.name> writes: > This package installs a lot of *.js files under > /usr/lib/python3/dist-packages/mkdics/themes. While some of these are > mkdocs-specific, a lot of them are available in binary packages in > Debian. For example, there are several minified copies of jquery, which > is available in bin:libjs-jquery. > > Except in cases where it is known that the current version of a library > in Debian is incompatible with a given mkdocs theme (which might be > considered an upstream bug), mkdocs should depend on the relevant > libjs-* package and install a symlink to the minified file provided by > that package, instead of another minified copy of the library. Help to fix this appreciated. Am very short on time recently. Thanks. -- Brian May <b...@debian.org> ___ 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#828651: FTBFS under Django 1.10
On Sun, Jun 26, 2016 at 05:14:09PM +0100, Chris Lamb wrote: > Source: django-model-utils > Version: 2.4-1 > Severity: important > User: python-dja...@packages.debian.org > Usertags: django110 django110-ftbfs 2.5.2 is still broken, from upstream the changelog for 2.5.1: * Django 1.10 support regressed with changes between pre-alpha and final release; 1.10 currently not supported. See upstream bug at https://github.com/carljm/django-model-utils/issues/232 -- Brian May <b...@debian.org> ___ 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#834116: Bug#834116: django-model-utils: description should distinguish different binary packages
Ben Finney <bign...@debian.org> writes: > Every package description should make clear what is specific to each > binary package built from a source package. Please distinguish the > different binary packages by what actually makes them different (in > this case: the target Python version of each). > > This distinction should be in both the synopsis and long description. > > Attached is a Git bundle which implements an improved description for > each binary package. It is also in the branch located at > <URL:https://notabug.org/bignose/debian_django-model-utils/src/wip/issue/description>. Hello, Thanks for the report. Feel free to make changes and push to the git repository. I have applied your changes. The only thing I changed was the changelog - for some reason you created a new entry instead of reusing the latest entry. Note that the package currently FTBFS - I am assuming Django 1.10 issues - so I won't be able to do an upload anytime soon. Regards -- Brian May <b...@debian.org> ___ 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#828642: Bug#828642: Proposed NMU: fix FTBFS in Django 1.10
Thomas Goirand <z...@debian.org> writes: > Attached is the debdiff for the proposed upload, which I also pushed to > the DPMT git. I am uploading this fix to the DELAYED/2 queue. Let me > know if you oppose to the upload, so I can dcut the uploaded version > before it reaches the archive. No objections from me. If you want to skip the 2 day delay, that is fine with me also. Thanks! -- Brian May <b...@debian.org> ___ 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#828653: Fix committed to Git
Thomas Goirand <z...@debian.org> writes: > I have sent a (one liner) fix to the Git. Can you please review it, and > allow me to upload it (or upload it yourself)? Please go ahead and upload. Thanks -- Brian May <b...@debian.org> ___ 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] Fixed #828669 in Git: can I upload?
Thomas Goirand <z...@debian.org> writes: > I've fixed #828669 by applying a patch from a contributor of django-mptt > which was available in github. I pushed all of that (including upgrading > to 0.8.5, the latest upstream release) to the DPMT git. Are you giving > me the greenlight for upload? You upload looks fine. Go ahead, make the upload. Thanks. I would normally ask to make sure that the appropriate bugs are filled upstream, however last I looked upstream wasn't particular responsive, and I suspect that hasn't changed :-( -- Brian May <b...@debian.org> ___ 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#832192: Bug#832192: Which bug report for archive override of Section for ‘celeryd’?
Ben Finney <ben+deb...@benfinney.id.au> writes: > Which bug report requests the archive override for the Section of this > package? As noted in the initial bug report: Bug #833034 -- Brian May <b...@debian.org> ___ 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#832192: Bug#832192: celeryd: Section should not be “python”
To: Debian-Devel Any ideas what section this package should go into? I don't really care myself, however don't want to move it somewhere and find that I need to move it again. Thanks. Ben Finney <ben+deb...@benfinney.id.au> writes: > Well, it seems at least a good fit: Celery is a “system resource” as > much as any other daemon that provides services to applications behind > the scenes. > > The sections aren't going to fit all packages perfectly, though. If > you can justify the package fitting some other section by functional > description, go for it. -- Brian May <b...@debian.org> ___ 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#831648: Bug#831648: python-mkdocs: please make the build reproducible
Chris Lamb <la...@debian.org> writes: > I believe so, yes. I didn't spot that wishlist bug as it didn't > have a patch. Looks like the upstream fix doesn't include the change to mkdocs/nav.py; can you please confirm this is required? https://github.com/mkdocs/mkdocs/pull/939/commits/8b006bd7fda55e47e29412896c511c7244398f82 If so, we might need to update the ticket to say it wasn't fixed: https://github.com/mkdocs/mkdocs/issues/938 -- Brian May <b...@debian.org> ___ 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#828652: Bug#828652: Commited to Git
Thomas Goirand <z...@debian.org> writes: > The fix (ie: upgrading to 1.4.4) is pushed to git. Would you allow me to > NMU what's in git? The packaging changes look fine to me (django-nose). I suggest you join the python-modules-team (if you are not already joined) and upload as a normal team upload (not NMU). Otherwise I can do the upload too if you want me to. -- Brian May <b...@debian.org> ___ 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#829656: Bug#829656: mkdocs: Missing dependencies
Brian May <b...@debian.org> writes: > I think you might be confused; these a warnings only. The build-depends > installs the required packages. Oh, I guess you were talking about depends on the binary packages, not the build-depends. Will upload after I finish doing some tests. PS. All my uploads are done using a clean schroot. -- Brian May <b...@debian.org> ___ 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#829656: Bug#829656: mkdocs: Missing dependencies
Jeremy Bicha <jbi...@ubuntu.com> writes: > The logs have these warnings: > I: dh_python3 pydist:184: Cannot find package that provides > mkdocs_bootstrap. Please add package that provides it to Build-Depends > or add "mkdocs_bootstrap python3-mkdocs-bootstrap" line to > debian/py3dist-overrides or add proper dependency to Depends by hand > and ignore this info. > I: dh_python3 pydist:184: Cannot find package that provides > mkdocs_bootswatch. Please add package that provides it to > Build-Depends or add "mkdocs_bootswatch python3-mkdocs-bootswatch" > line to debian/py3dist-overrides or add proper dependency to Depends > by hand and ignore this info. I think you might be confused; these a warnings only. The build-depends installs the required packages. Build-Depends: debhelper (>= 9), dh-python, python3-all (>= 3.2), python3-setuptools, python3-markdown (>= 2.1.0), python3-jinja2, python3-yaml, python3-watchdog, python3-pkg-resources, python3-click, python3-tornado, python3-livereload, mkdocs-bootstrap (>=0.1.1), mkdocs-bootswatch (>=0.1.0), I will see if I can silence the warning, but I don't think anything is broken here or that the serious severity is justified. -- Brian May <b...@debian.org> ___ 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#825967: Bug#825967: python-django-extensions: please “Suggests: python-django-extensions-doc” in library binary packages
Ben Finney <ben+deb...@benfinney.id.au> writes: > Programming with the Python ‘django_extensions’ library requires > understanding how it works and what it does. > > Please set a “Suggests: python-django-extensions-doc” dependency to > the library packages, so that administrators selecting > ‘python-django-extensions’ or ‘python3-django-extensions’ will receive > the suggestion. Was going to upload a fix for this, but opened bug #828207 instead. -- Brian May <b...@debian.org> ___ 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#828207: FTBFS: AttributeError: 'module' object has no attribute 'SubfieldBase'
Source: python-django-extensions
Version: 1.6.7-2
Severity: serious
Justification: FTBFS
Guessing this might be a Django issue with 1.10~beta1-1:
dh_auto_test -- --system=custom --test-args="{interpreter} -m pytest
--ds=tests.testapp.settings --cov=django_extensions"
I: pybuild base:184: python2.7 -m pytest --ds=tests.testapp.settings
--cov=django_extensions
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/usr/lib/python2.7/dist-packages/pytest.py", line 17, in
raise SystemExit(pytest.main())
File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 39, in main
config = _prepareconfig(args, plugins)
File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 118, in
_prepareconfig
pluginmanager=pluginmanager, args=args)
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 724, in __call__
return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 338, in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 333, in
_MultiCall(methods, kwargs, hook.spec_opts).execute()
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 595, in execute
return _wrapped_call(hook_impl.function(*args), self.execute)
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 249, in _wrapped_call
wrap_controller.send(call_outcome)
File "/usr/lib/python2.7/dist-packages/_pytest/helpconfig.py", line 28, in
pytest_cmdline_parse
config = outcome.get_result()
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 279, in get_result
_reraise(*ex) # noqa
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 264, in __init__
self.result = func()
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 596, in execute
res = hook_impl.function(*args)
File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 861, in
pytest_cmdline_parse
self.parse(args)
File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 966, in parse
self._preparse(args, addopts=addopts)
File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 937, in
_preparse
args=args, parser=self._parser)
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 724, in __call__
return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 338, in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 333, in
_MultiCall(methods, kwargs, hook.spec_opts).execute()
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 595, in execute
return _wrapped_call(hook_impl.function(*args), self.execute)
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 253, in _wrapped_call
return call_outcome.get_result()
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 279, in get_result
_reraise(*ex) # noqa
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 264, in __init__
self.result = func()
File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py",
line 596, in execute
res = hook_impl.function(*args)
File "/usr/lib/python2.7/dist-packages/pytest_django/plugin.py", line 238, in
pytest_load_initial_conftests
_setup_django()
File "/usr/lib/python2.7/dist-packages/pytest_django/plugin.py", line 134, in
_setup_django
django.setup()
File "/usr/lib/python2.7/dist-packages/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python2.7/dist-packages/django/apps/registry.py", line 108, in
populate
app_config.import_models(all_models)
File "/usr/lib/python2.7/dist-packages/django/apps/config.py", line 199, in
import_models
self.models_module = import_module(models_module_name)
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
File "tests/testapp/models.py", line 10, in
from django_extensions.db.fields.json import JSONField
File "django_extensions/db/fields/json.py", line 65, in
class JSONField(six.with_metaclass(models.SubfieldBase, models.TextField)):
AttributeError: 'module' object has no attribute 'SubfieldBase'
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500,
[Python-modules-team] Bug#824266: Bug#824266: mkdocs: Please support SOURCE_DATE_EPOCH specification for build time stamps
Axel Beckert <a...@debian.org> writes: > See https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Examples > for some examples on how to implement support for SOURCE_DATE_EPOCH, > including an example for Python. Response from the upstream author (please consider replying to the upstream bug report, not here): "FYI, the Python example is wrong. If `SOURCE_DATE_EPOCH` is supposed to be a Unix timestamp (number of seconds since epoch), then `time.gmtime()` is not the Python equivalent. However, `calendar.timegm(datetime.datetime.utcnow().utctimetuple())` or `calendar.timegm(time.gmtime())` is. It is annoyingly complicated to get a Unix timestamp in Python. Although Python >= 3.3 makes it easier with `datetime.datetime.utcnow().timestamp()`. Not sure how the `datetime` module went so long without the ability to return a timestamp." -- Brian May <b...@debian.org> ___ 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#824266: Bug#824266: mkdocs: Please support SOURCE_DATE_EPOCH specification for build time stamps
Axel Beckert <a...@debian.org> writes: > mkdocs integrates build time stamps into the documentation it is > generating. This makes at least unburden-home-dir no more reproducibly > building because it now uses mkdocs to generate HTML documentation at > build time. Is this something that should be forwarded upstream? https://github.com/mkdocs/mkdocs/issues -- Brian May <b...@debian.org> ___ 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#823488: Bug#823488: python-ldap3: connection switch silently to anonymous bind if password is empty, failing auth
Simone Piccardi <picca...@truelite.it> writes: > When creating a connection with the Connection object the code defaults to > AUTH_ANONYMOUS (doing so an anonymus bind) also when _only_ the password > is empty (not, as said by documentation, when both user and password are > empty). Hello, You appear to be reporting this bug against the version in Jessie. However the version in unstable is fixed. See https://github.com/cannatag/ldap3/issues/174 As a result, I don't think there is anything I can do with this report. You could try talking to the security team, however I don't think this would qualify as a security issue requiring a security fix. It might also qualify for an update as a point release. I would be nervous about changing the behaviour of a function in a stable release, and the potential of this change to break other applications that could potentially be relying on this (broken) behaviour. Regards -- Brian May <b...@debian.org> ___ 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-modules-commits] [mpmath] 01/01: d/copyright: Changed licence shortname BSD -> BSD-3-clause
Barry Warsaw <ba...@debian.org> writes: >>announced before: >>http://lists.alioth.debian.org/pipermail/python-modules-team/2016-March/030256.html > > Thanks! I must have missed it, but you did the right thing. In future, far better to use the debian-pyt...@lists.debian.org mailing list; less likely to get missed. Having said that I did see the email, and I was happy with it. I didn't notice it was the wrong mailing list though :-(. It does cause confusion for people who are familar with the team, having the aloith as the Maintainer field - people use this expecting to be able to contact the Maintainer... Sometimes I will resend emails to debian-pyt...@lists.debian.org when I see this happen. -- Brian May <b...@debian.org> ___ 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#822224: Bug#822224: Further changes
Neil Williams <codeh...@debian.org> writes: > python-django and python-django-tables2 from jessie work but if either > one is pulled in from jessie-backports without the other, restarting > apache2 causes a HTTP500. I am not sure I see how adding the Breaks header helps resolve this? -- Brian May <b...@debian.org> ___ 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#822224: Bug#822224: Further changes
Neil Williams <codeh...@debian.org> writes: > i.e. django-tables 1.1.6 reveals a "bug" in django 1.7 so django needs > to be updated to 1.8 before django-tables 1.1.6 can be > upgraded/installed. Sorry, not sure I understand the need for the Breaks. What happens if you upgrade django-tables and then upgrade django? Apart from the Breaks header, all other the changes look fine and I will look at making these changes to the unstable version. -- Brian May <b...@debian.org> ___ 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#811477: Bug#811477: FTBFS: missing dependency on funcsigs
Thomas Goirand <z...@debian.org> writes: > Since there's no movement on this bug (even not a reply from the current > maintainers), I've prepared an NMU, which I'm uploading to the delayed 3 > days queue. If I noticed earlier that this issue wasn't solved, I would > have probably uploaded earlier. Sorry, I would have looked at at a lot earlier, but I somehow missed seeing the bug report. > Attached to this message, you'll find the proposed diff. You'll note > that it also patches the doc's conf.py which is using intersphinx. This > does network access during build, which is also an RC bug. If you don't > agree with this debdiff, please let me know ASAP, and I'll dcut the > package out. It looks like your patch has been applied into git by Ondřej Nový (who I CCed), so I think your upload is good to go. I think the only thing left is to add the tags to git. Only possible concern: Is it ok to disable intersphinx like this? I assume the documentation will still be good, just the links to external documentation won't appear as links. Is this correct? -- Brian May <b...@debian.org> ___ 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#808536: Bug#808536: Bug#808536: pytest-django: diff for NMU version 2.9.1-2.1
Brian May <b...@debian.org> writes: > The patch looks good to me, I should be able to incooporate it into git > and upload today. Thanks for the patch. I have just uploaded a fixed version to Debian. -- Brian May <b...@debian.org> ___ 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#808536: Bug#808536: pytest-django: diff for NMU version 2.9.1-2.1
Neil Williams <li...@codehelp.co.uk> writes: > I've prepared an NMU for pytest-django (versioned as 2.9.1-2.1) and > uploaded it to DELAYED/7. Please feel free to tell me if I > should delay it longer. Sorry, somehow I completely missed even seeing this bug report. The patch looks good to me, I should be able to incooporate it into git and upload today. -- Brian May <b...@debian.org> ___ 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#818730: Bug#818730: FTBFS in unstable
Discussion was moved here: https://lists.debian.org/debian-python/2016/03/msg00070.html Am about to upload what should be a fix to this problem. -- Brian May <b...@debian.org> ___ 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#818730: Bug#818730: FTBFS in unstable
Steve Langasek <vor...@debian.org> writes:
> django-pipeline fails to build in unstable with the following error:
Was this on a clean unstable system?
Am wondering if maybe there is something else installed that is badly
interacting with the build process.
Have traced through the code, and all it should be doing in the failing
test is:
to_class('pipeline.compressors.yuglify.YuglifyCompressor')
which in turn returns:
importlib.import_module('pipeline.compressors.yuglify').YuglifyCompressor
I don't see why this should be failing. Particularly as the message
makes it clear that this symbol can be loaded.
--
Brian May <b...@debian.org>
___
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] FTBFS trouble upgrading python-django to 1.9.4-1
Luke Faraone <lfara...@debian.org> writes:
> Notably, similar ln/mv errors happen in 1.9.2-1[2], but they aren't
> fatal.
There should not be any errors, fatal or not.
> Does anybody have an idea what's wrong here?
Some sort of weird race condition with "find" locating the file, and
something else deleting it before the "mv"???
I tried to reproduce, but my build crashed before it even got to this
step.
Traceback (most recent call last):
File "./runtests.py", line 458, in
Applying sites_framework.0001_initial... OK
Cloning test database for alias 'other' (':memory:')...
Cloning test database for alias 'other' (':memory:')...
Cloning test database for alias 'other' (':memory:')...
Cloning test database for alias 'other' (':memory:')...
options.debug_sql, options.parallel)
File "./runtests.py", line 275, in django_tests
extra_tests=extra_tests,
File "/«PKGBUILDDIR»/django/test/runner.py", line 533, in run_tests
result = self.run_suite(suite)
File "/«PKGBUILDDIR»/django/test/runner.py", line 494, in run_suite
).run(suite)
File "/usr/lib/python2.7/unittest/runner.py", line 151, in run
test(result)
File "/usr/lib/python2.7/unittest/suite.py", line 70, in __call__
return self.run(*args, **kwds)
File "/«PKGBUILDDIR»/django/test/runner.py", line 310, in run
counter = multiprocessing.Value(ctypes.c_int, 0)
File "/usr/lib/python2.7/multiprocessing/__init__.py", line 253, in Value
return Value(typecode_or_type, *args, **kwds)
File "/usr/lib/python2.7/multiprocessing/sharedctypes.py", line 108, in Value
lock = RLock()
File "/usr/lib/python2.7/multiprocessing/__init__.py", line 183, in RLock
return RLock()
File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 172, in
__init__
SemLock.__init__(self, RECURSIVE_MUTEX, 1, 1)
File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 75, in __init__
sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)
OSError: [Errno 13] Permission denied
make[1]: *** [override_dh_auto_test] Error 1
debian/rules:22: recipe for target 'override_dh_auto_test' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [build] Error 2
debian/rules:10: recipe for target 'build' failed
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
___
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#814622: Bug#814622: python3-pytest: modifies shipped files: /usr/bin/py.test-3.[45]
Andreas Beckmann <a...@debian.org> writes: > during a test with piuparts I noticed your package modifies files it > ships in /usr. This is so wrong, I'm not even bothered to look > up the part of policy this violates ;-P >From python3-pytest.postinst: case "$1" in configure|abort-upgrade|abort-remove|abort-deconfigure) # Just in case, recreate all scripts for version in `py3versions -vi`; do if [ $version ]; then cp /usr/bin/py.test-3 /usr/bin/py.test-$version sed -i "s,#! */usr/bin/python3,#!/usr/bin/python$version," "/usr/bin/py.test-$version" fi done ;; This should be done at build time in debian/rules, not at install time. -- Brian May <b...@debian.org> ___ 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#812672: Bug#812672: djangorestframework: FTBFS - TypeError: a bytes-like object is required, not 'str'
Michael Tautschnig <m...@debian.org> writes:
> During a rebuild of all Debian packages in a clean sid chroot (using
> cowbuilder
> and pbuilder) the build failed with the following error.
I am unable to reproduce this build failure. On clean Debian sid chroot.
> [...]
> # Build the HTML documentation.
> mkdir
> /srv/jenkins-slave/workspace/sid-goto-cc-djangorestframework/djangorestframework-3.3.2/docs.debian
> LANG=C.UTF-8 mkdocs build && mv site docs.debian/html
> Traceback (most recent call last):
> File "/usr/bin/mkdocs", line 9, in
> load_entry_point('mkdocs==0.14.0', 'console_scripts', 'mkdocs')()
> File "/usr/lib/python3/dist-packages/click/core.py", line 716, in __call__
> return self.main(*args, **kwargs)
> File "/usr/lib/python3/dist-packages/click/core.py", line 675, in main
> _verify_python3_env()
> File "/usr/lib/python3/dist-packages/click/_unicodefun.py", line 69, in
> _verify_python3_env
> if locale.lower().endswith(('.utf-8', '.utf8')):
> TypeError: a bytes-like object is required, not 'str'
> debian/rules:12: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 1
Looks like a problem with python3-click, used by mkdocs.
>From my build log:
Get:42 http://localhost:/debian sid/main i386 python3-click all 6.2-1 [56.0
kB]
Get:51 http://localhost:/debian sid/main i386 mkdocs all 0.14.0-1 [270 kB]
The code in question is:
if os.name == 'posix':
import subprocess
rv = subprocess.Popen(['locale', '-a'], stdout=subprocess.PIPE,
stderr=subprocess.PIPE).communicate()[0]
good_locales = set()
has_c_utf8 = False
for line in rv.splitlines():
locale = line.strip()
if locale.lower().endswith(('.utf-8', '.utf8')):
good_locales.add(locale)
if locale.lower() in ('c.utf8', 'c.utf-8'):
has_c_utf8 = True
To me this code does look broken. line I think is a bytes object, so we
can't compare with str. I will have to try and work out why it isn't
crashing for me...
In any case I believe this is a bug in python3-click. Now, I can
reproduce it too, however not in the build of djangorestframework,
because it sets LANG:
(sid-amd64)root@prune:/home/brian# mkdocs
Traceback (most recent call last):
File "/usr/bin/mkdocs", line 9, in
load_entry_point('mkdocs==0.14.0', 'console_scripts', 'mkdocs')()
File "/usr/lib/python3/dist-packages/click/core.py", line 716, in __call__
return self.main(*args, **kwargs)
File "/usr/lib/python3/dist-packages/click/core.py", line 675, in main
_verify_python3_env()
File "/usr/lib/python3/dist-packages/click/_unicodefun.py", line 69, in
_verify_python3_env
if locale.lower().endswith(('.utf-8', '.utf8')):
TypeError: a bytes-like object is required, not 'str'
(sid-amd64)root@prune:/tmp/brian/tmp9rNvFP/build/amd64# LANG=C.UTF-8 mkdocs
Usage: mkdocs [OPTIONS] COMMAND [ARGS]...
MkDocs - Project documentation with Markdown.
Options:
-V, --version Show the version and exit.
-q, --quietSilence warnings
-v, --verbose Enable verbose output
-h, --help Show this message and exit.
Commands:
build Build the MkDocs documentation
gh-deploy Deply your documentation to GitHub Pages
json Build the MkDocs documentation to JSON files...
newCreate a new MkDocs project
serve Run the builtin development server
--
Brian May <b...@debian.org>
___
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#812672: Bug#812672: djangorestframework: FTBFS - TypeError: a bytes-like object is required, not 'str'
Brian May <b...@debian.org> writes: > (sid-amd64)root@prune:/tmp/brian/tmp9rNvFP/build/amd64# LANG=C.UTF-8 mkdocs Oh, I guess you don't have the C.UTF-8 locale defined. For me, I do. That means, for me, the following code will detect a non-ascii codec, and exit before running the faulty code. try: import locale fs_enc = codecs.lookup(locale.getpreferredencoding()).name except Exception: fs_enc = 'ascii' if fs_enc != 'ascii': return I will file a bug against python3-click now. Actually I have a feeling that even the python3 issue fixed, that won't solve the FTBFS problem. It looks like the code that fails is code that picks the most appropriate fatal error because the above test failed :-( -- Brian May <b...@debian.org> ___ 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#812672: mkdocs locale error building djangorestframework
Adam Borowski <kilob...@angband.pl> writes: > My guess as to the cause of #812672 is that you have LC_CTYPE or LC_ALL set > to an ancient locale. These variables override LANG, the order is > LC_ALL>LC_CTYPE>LANG. Interesting thought. Unfortunately, I can't tell from the supplied build logs what these are set to. I probably should change the line from: LANG=C.UTF-8 mkdocs build && mv site docs.debian/html To something like: LANG=C.UTF-8 LC_CTYPE= LC_ALL= mkdocs build && mv site docs.debian/html Just in case. -- Brian May <b...@debian.org> ___ 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#812672: Bug#812672: djangorestframework: FTBFS - TypeError: a bytes-like object is required, not 'str'
Hello, We have a theory that this is due to LC_CTYPE and LC_ALL environment being set to legacy values. Are you able to tell me what the environment variables LC_CTYPE and LC_ALL are set to during the failed boot? If this is the case I can fix the problem by unsetting these before calling mkdocs. Thanks. -- Brian May <b...@debian.org> ___ 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#812465: Bug#812465: Please do not be so restrictive with versions of urllib3
Ian Cordasco <graffatcolmin...@gmail.com> writes: > If you'd like to develop patches to make backporting requests without > backporting the necessary version of urllib3, that's fine. I don't > think there should be a policy of carrying unnecessary unsupported > patches that will likely cause more bug reports than not. To expand on my previous email, the backports version would be 1.13.1-1~bpo8+1 However debian/control specifies python-urllib3 (= 1.13.1-1); this will not allow the backported version to work. Changing this in debian/control as suggested has no impact on the upstream policy, nor does it require maintaing patches. -- Brian May <b...@debian.org> ___ 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#812465: Bug#812465: Bug#812465: Please do not be so restrictive with versions of urllib3
Ian Cordasco <graffatcolmin...@gmail.com> writes: > Requests integrates tightly with urllib3. Trying to use an older version of > the dependency (or a newer version) can wreak havoc. Try using requests > 2.2.1 and urllib3 1.10 or 1.11. The right constraint is necessary to > prevent Debian from needing to carry patches for compatibility. Upstream > will not support anything for users that violates the existing restrictions. Better read that request again. There was nothing I saw about using it with an older upstream version of urllib3. -- Brian May <b...@debian.org> ___ 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#812465: Bug#812465: Please do not be so restrictive with versions of urllib3
Ian Cordasco <graffatcolmin...@gmail.com> writes: > If you'd like to develop patches to make backporting requests without > backporting the necessary version of urllib3, that's fine. I don't > think there should be a policy of carrying unnecessary unsupported > patches that will likely cause more bug reports than not. You do realize this isn't a upstream change that is being proprosed, just a small change to debian/control that will not have any impact for unstable, testing or stable? -- Brian May <b...@debian.org> ___ 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#705225: python-passlib: bcrypt not usable from python-passlib -- missing backend
Brian May <br...@microcomaustralia.com.au> writes: > I just opened #796853 for this security issue. #796853 was closed, so I believe this bug can now be closed... -- Brian May <b...@debian.org> ___ 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#806364: Bug#806364: Bug#806364: python-django-extensions: FTBFS with Django 1.9
Brian May <b...@debian.org> writes: > Filled upstream at > https://github.com/django-extensions/django-extensions/issues/769 Upstream fixed the problem, but the fix was broken and had to be reverted. See: https://github.com/django-extensions/django-extensions/issues/796 https://github.com/django-extensions/django-extensions/issues/781 Upstream are currently discussing a new solution to the problem. -- Brian May <b...@debian.org> ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
