Bug#938027: python-pip: Python2 removal in sid/bullseye

Hi Sandro. Honestly, I have not contributed to Debian in a couple of years, and I don’t see that changing any time soon. Best to contact Matthias, the Python Team, or just do whatever you think is best. Cheers, -Barry > On Mar 13, 2020, at 12:32, Sandro Tosi wrote: > > On Fri, 30 Aug 2019

Bug#890621: forwarded python3.6 issue (bpo-32305 causing regressions)

On Feb 19, 2018, at 04:08, Matthias Klose wrote: > > This is https://bugs.python.org/issue32305, apparently intentional and will be > in 3.7. So better fix the packages itself. Not sure if that really should be > backported. Thanks for the forward. The fix is for third party

Bug#799281: ITP: mailman3-core -- Mailing list management system

On Sep 22, 2017, at 18:53, Pierre-Elliott Bécue wrote: > Now, when I run the tests, there are a lot of errors, but I can't say > exactly why. If you wish I can put a copy of the last attempt. Sure, post a link. I’ll let you know if I see anything obvious. -B signature.asc

Bug#799281: ITP: mailman3-core -- Mailing list management system

On Sep 22, 2017, at 09:28, Pierre-Elliott Bécue wrote: >> >>> In d/tests/mailman3-core-tests, what do you think about using `python3 -m >>> nose2` instead of `nose2-3`? >> >> As I wasn't able to have working tests for this package, they're disabled in >> d/rules. Maybe I just

Bug#799281: ITP: mailman3-core -- Mailing list management system

Hi guys, apologies for not responding earlier. I have taken a break from Debian development, so I am not reading my @debian.org email much these days: https://lists.debian.org/debian-python/2017/08/msg00107.html That said... > On Sep 20, 2017, at 12:53, Jonas Meurer

Bug#641314: debhelper: dh_auto_test should support standard python cli for running tests

Hi Niels, > On Sep 17, 2017, at 09:31, Niels Thykier wrote: > Is there an update to the situation here? Can we assume that the test > target is (generally) always available ? (even if we limit it to just > python3 related calls). No, I don’t have any update to this. I am

Bug#862072: [Python-modules-team] Bug#862072: python3-virtualenv doesn't provide entry point virtualenv

On May 08, 2017, at 10:16 AM, Mickael Viey wrote: >After a python3-virtualenv fresh install. The package is installed on >/usr/lib/python3/dist-packages, but doesn't provide any entry point to invoke >virtualenv: That's correct. python3-virtualenv is just the library. Install the `virtualenv`

Bug#859421: python-tz orphaning

On Apr 07, 2017, at 02:47 AM, Matthias Klose wrote: >I think it's safe to go forward with this. Maybe keep the zope team (or the >individual uploaders) as an uploader for a while, but I think the zope team >is a little bit dead at this point ... I really think we should pull the zope library

Bug#859747: pycxx 7.0.1-1 fails its autopkgtest

Source: pycxx Version: 7.0.1-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I just noticed this over in Ubuntu, where pycxx 7.0.1-1 is failing its autopkgtest, which prevents it from getting promoted out of zesty-proposed. Retested on unstable, in a sid chroot, the exact

Bug#852289: [Python-modules-team] Bug#852289: python-passlib: please make the build reproducible (timestamps)

On Jan 31, 2017, at 09:43 AM, Eli Collins wrote: >Passlib 1.7.1 is out, which should fix #852289; I'll try to keep an eye on >the reproducible build status for a bit in case there's any other hiccups. Thanks! I'm working on the new upstream in git right now. It looks like we can also drop the

Bug#812768: [Python-modules-team] Bug#812768: python-whoosh: diff for NMU version 2.7.0-1.1

On Jan 30, 2017, at 08:21 AM, Simon McVittie wrote: >Thanks for letting me know, I'll mark it as unmaintained. Would you like >your other packages to be marked as unmaintained too? > >Sorry, I am not intending to adopt python-whoosh: I'm only fixing it >because removing it from testing would be

Bug#744741: (no subject)

Maybe, create a python{,3}-pyside-common package that only contains the .egg-info and then have all subpackages depend on that?

Bug#852475: autopkgtest: apt-get install needs automatic conffile handling

Hi Martin, On Jan 24, 2017, at 09:19 PM, Martin Pitt wrote: >Ah, sbuild usually copies that from the host system >(/etc/schroot/default/nssdatabases), so indeed this tends to cause conffile >conflicts. Ah ha! That was the piece I was missing. Thanks for applying the patch. -Barry

Bug#852475: autopkgtest: apt-get install needs automatic conffile handling

https://code.launchpad.net/~barry/autopkgtest/+git/autopkgtest/+ref/852475 pgp9syopDe3sn.pgp Description: OpenPGP digital signature

Bug#852475: autopkgtest: apt-get install needs automatic conffile handling

Package: autopkgtest Version: 4.3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, Let's say one of your autopkgtest dependencies (perhaps recursively) needs to update a configuration file, i.e. via a conffile. E.g. when running the autopkgtests for aptdaemon

Bug#852289: [Python-modules-team] Bug#852289: python-passlib: please make the build reproducible (timestamps)

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

Bug#851649: (no subject)

I have no objections, but I don't have time right now to do it. Piotr did the 1.7.0-1 upload so please verify with him.

Bug#844943: python-bleach: FTBFS: Tests failures

On Jan 13, 2017, at 09:16 PM, Pirate Praveen wrote: >I would prefer this approach as I prefer to avoid maintaining two >versions if possible. I cloned html5lib.git repo, but found recent tags >missing there. Can you push them? Apologies. Tags pushed. Let me know when you have a repo or branch

Bug#844943: python-bleach: FTBFS: Tests failures

Here's another thought. What if we upload a new html5lib source package containing seven-9's? I know we're in freeze, but this may make the most sense. Then, packages which need the old version like bleach can depend on the seven-9's version and that won't affect packages which require the

Bug#783202: (no subject)

I've run into this --or something similar-- too. $ autopkgtest-buildvm-ubuntu-cloud -v When you run this on an Ubuntu 17.04 (zesty) host, it finishes quickly and leaves you with a nice autopkgtest-zesty-amd64.img. When you run the same command on an Ubuntu 16.10 (yakkety) host, it hangs and

Bug#844943: python-bleach: FTBFS: Tests failures

On Jan 10, 2017, at 09:37 AM, Pirate Praveen wrote: >bleach and other projects using html5lib seems to have locked the version of >html5lib to the one with 7 nines. Can we also go back to the older version >which works? I had a conversation with the upstream pip maintainer. In theory it may be

Bug#769598: (no subject)

Okay, I figured out the problem and have a fix. I don't believe this is a bug with dput-ng (so this issue can be closed), but instead it's a problem with the local user's trustdb. You'll have to fix your trustdb locally and then it should work. Here are a couple of links with some additional

Bug#769598: (no subject)

I'm hitting this same problem. I thought maybe it was related to having a $GNUPGHOME set, but even unsetting that doesn't help. It fails every time using either a name or uid (full or short).

Bug#835437: Seems fixed

On Dec 25, 2016, at 05:49 PM, Santiago Vila wrote: >The bug I reported said FTBFS. After the tests are disabled, this builds >ok again, so the FTBFS problem I reported is fixed. Thanks. If you're happy closing this bug, then so am I! I'll just clarify that I didn't actually disable the tests;

Bug#844457: [buildd-tools-devel] Bug#844457: sbuild: --extra-package is great, but could be better

On Dec 22, 2016, at 08:50 AM, Johannes Schauer wrote: >If the path given to --extra-package is a directory, then sbuild will add all >files that end in ".deb" within that directory to its local repository. > >Does that sound like a good compromise to you? It does indeed, thanks! -Barry

Bug#838695: (no subject)

We just hit this same problem. I think this is exactly the right fix. I tested it locally in a venv. Unfortunately I don't have permission to push the fix to the repo. Also, PyPI is a version behind unstable.

Bug#840673: (no subject)

On Dec 15, 2016, at 05:39 PM, Matthias Klose wrote: >disagreed, dput should just remove setuptools from the requires. I agree that the bug should be fixed in dput. It's up to dput's maintainer to decide how I suppose. Sounds like there's agreement we should reassign this bug back to dput.

Bug#835437: (no subject)

I can't reproduce the build failures reported here even with dpkg-buildpackage -A. However, I am going to add the discard-port proxies to d/rules that pybuild normally adds by default (this package doesn't use pybuild). That at least will prevent the tests from *actually* hitting the internet.

Bug#840673: (no subject)

I think one of the problems is that while in Debian, pkg_resources and setuptools are separate binary packages, it's not entirely clear to me that upstream views them as different packages. After all, they are Python packages distributed in the same git repo and tarball. Debian's separation of

Bug#839253: (no subject)

A couple of small decisions in discussion w/Martin: * If you have `Tests: foo` and `Features: test-name=bar`, warn and ignore the test-name feature. * If you have multiple test-name features, e.g. `Features: test-name=a, test-name=b` warn and skip. * I want the feature name to match the

Bug#846328: RFH: autopkgtest -- automatic as-installed testing for Debian packages

On Nov 30, 2016, at 11:48 AM, Martin Pitt wrote: >but I'd really like to mentor other people about the structure, how to test >autopkgtest itself locally, etc. I'd like to get more involved with auutopkgtest, since it's a tool I rely on quite a bit. Cheers, -Barry

Bug#837764: (no subject)

Are you sure that link actually exists?

Bug#846155: ITP: python-distro -- Linux OS platform information API

Package: wnpp Severity: wishlist Owner: Barry Warsaw <ba...@debian.org> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-distro Version : 1.0.1 Upstream Author : Nir Cohen * URL : https://github.com/nir0s/distro * License :

Bug#844679: [Python-modules-team] Bug#844679: /usr/bin/pip: Should use --disable-pip-version-check by default

On Nov 17, 2016, at 11:17 PM, Nelson A. de Oliveira wrote: >Since we are installing pip from a Debian package, shouldn't we have it >using "--disable-pip-version-check" by default, to avoid this? Yes, I think we should.

Bug#844650: ITP: flufl.testing -- a small collection of Python test helpers

Package: wnpp Severity: wishlist Owner: Barry Warsaw <ba...@debian.org> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: flufl.testing Version : 0.1 Upstream Author : Barry Warsaw <ba...@python.org> * URL : https://gitlab.com/warsaw/f

Bug#844561: claws-mail-python-plugin: Missing dependency on python-gtk2

Package: claws-mail-python-plugin Version: 3.14.1-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, I was debugging a failure of the Claws Mail Python plugin on Ubuntu 17.04. See LP: #1640217

Bug#844457: [buildd-tools-devel] Bug#844457: sbuild: --extra-package is great, but could be better

On Nov 16, 2016, at 07:48 AM, Johannes Schauer wrote: >> 1) Allow for passing wildcards to --extra-package. Then I could do >> something like `sbuild ... --extra-package=/path/to/itp/*.deb` and >> have it pick up all the debs in that directory. >> >> 2) Provide a shortcut option for

Bug#844455: autopkgtest: Please support additional (local) packages

On Nov 16, 2016, at 08:43 AM, Martin Pitt wrote: >As for building *in* autopkgtest with extra binaries, this doesn't >currently happen indeed; local binaries are only added as an apt >source for the test, but I think it would not hurt to supply them as >build dependencies too. > >However, there

Bug#844457: sbuild: --extra-package is great, but could be better

Package: sbuild Version: 0.72.0-2 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, I use --extra-package to build new versions of packages that grow new dependencies not yet in Debian. While waiting for the latter to clear NEW (or before the ITP-fixing

Bug#844455: autopkgtest: Please support additional (local) packages

Package: autopkgtest Version: 4.2 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, Occassionally I'm testing a new package version that has new dependencies which aren't yet in Debian. I can build the ITP'd packages locally and build the new package version

Bug#754248: [Python-modules-team] Bug#754248: python-virtualenv: Error when attempting to create a python2.6 virtualenv

On Nov 13, 2016, at 10:14 PM, Arthur de Jong wrote: >I just ran into this today and I can confirm that the above fix allows >me to move forward with a Python 2.6 virtualenv. Can you fix this for >unstable? Yes, I'll upload this fix to unstable momentarily. pgp3LVKV9oZPC.pgp Description:

Bug#835437: pycurl: FTBFS too much often (failing tests)

On Nov 03, 2016, at 08:32 PM, Santiago Vila wrote: >My recommendation: Please find the way to disable any tests which >perform network access, I have the strong feeling that the build would >never hang if those tests are disabled. +1 - unfortunately I just don't have any spare cycles right now.

Bug#835437: pycurl: FTBFS too much often (failing tests)

On Nov 03, 2016, at 02:03 PM, Sandro Tosi wrote: >Hey Barry, did you have a chance to look at this? might be also just >forward it upstream and see how that goes. Thanks! I'm sorry, I haven't. :( pgp4tL3nYiOn2.pgp Description: OpenPGP digital signature

Bug#777144: (no subject)

Hi. I'm not sure that's a reasonable thing to support, especially now that stretch is the next version. So much has changed in pip in the meantime, that I think it will be too difficult to backport or otherwise make unstable's pip work in any older versions. Sorry for not getting to this bug in

Bug#834193: Your mail

On Mon, 31 Oct 2016 18:25:16 -0400 Barry Warsaw <ba...@debian.org> wrote: > Thanks for the bug report. I plan on fixing this in 8.1.2-3 but I think the > shebang should be /usr/bin/python2 for /usr/bin/pip2. Can you think of a > reason not to do this? Well, one reason is that i

Bug#834193: (no subject)

Thanks for the bug report. I plan on fixing this in 8.1.2-3 but I think the shebang should be /usr/bin/python2 for /usr/bin/pip2. Can you think of a reason not to do this?

Bug#842738: ITP: python-webencodings -- Python implementation of the WHATWG Encoding standard

Package: wnpp Severity: wishlist Owner: Barry Warsaw <ba...@debian.org> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-webencodings Version : 0.5 Upstream Author : Simon Sapin * URL : https://github.com/gsnedders/python-webencodings * L

Bug#831271: (no subject)

How would we do that? I'm not particularly fond of debian/control.in files.

Bug#842732: python-pip: Fix autopkgtests

Package: python-pip Version: 8.1.2-2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, There are some latent autopkgtest failures now, as originally described in LP: #1626258, which also contains a debdiff. As per usual, this should be fixed in Debian and

Bug#840847: (no subject)

Any chance this fix can get uploaded soon-ish? gtimelog build depends on it so it's marked for autoremoval because of this bug. Thanks!

Bug#840084: [Python-modules-team] Bug#840084: python-virtualenv: “Multiple .dist-info directories” when creating virtualenv

On Oct 08, 2016, at 04:58 PM, Ben Finney wrote: >When attempting to create a new virtualenv, Pip crashes with an error: I can't reproduce this on unstable. % python2 -m pip --version pip 8.1.2 from /usr/lib/python2.7/dist-packages (python 2.7) % python2 -m virtualenv --version 15.0.3 % python2

Bug#839253: autopkgtest: --testname incompatible with Test-Command:

On Oct 01, 2016, at 12:16 AM, Martin Pitt wrote: >You can actually -- they get named "command1", "command2", etc, same >names that appear in the logs and in summary. I must have missed that, but it's really nice. pgpIUkqcn_THD.pgp Description: OpenPGP digital signature

Bug#839253: autopkgtest: --testname incompatible with Test-Command:

On Oct 01, 2016, at 12:16 AM, Martin Pitt wrote: >I'd slightly change that idea to be Test-Command-foobar:, to provide >an optional name? Test-Command: would then continue to get >autogenerated commandN names. I rather like that. One of my other minor problems is that in the summary, if you

Bug#839253: autopkgtest: --testname incompatible with Test-Command:

Package: autopkgtest Version: 4.0.5 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, AFAICT, if you specify a test with Test-Command: there's no way to select it with `autopkgtest --testname`. A couple of thoughts: * Allow Tests: and Test-Command: to

Bug#839072: autopkgtest: Allow for GitHub-style PR urls

e9 Mon Sep 17 00:00:00 2001 From: Barry Warsaw <ba...@ubuntu.com> Date: Wed, 28 Sep 2016 13:08:58 -0400 Subject: [PATCH] Support url#refspec format. First, I fixed the bug in the previously supported url#branch syntax, where the code expected a space separator but the documentati

Bug#839072: autopkgtest: Allow for GitHub-style PR urls

Package: autopkgtest Version: 4.0.5 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, As we've been discussing, it would be nice if you could run autopkgtest against GitHub-style pull requests. There's no direct URL that would allow you to do this, but you can

Bug#838531: nose2: FTBFS in testing (failing tests)

On Sep 24, 2016, at 03:47 PM, Chris Lamb wrote: >> nose2: FTBFS in testing (failing tests) > >This is somewhat mind-bending to debug: > > AssertionError: Regex didn't match: > 'FAILED \\(failures=5, errors=1, skipped=1\\)' not found in > […] FAILED (failures=1, errors=1, skipped=1)\n'

Bug#838663: tox: python3 pip is called "pip3" in Debian and tox should call that instead of "pip"

On Sep 23, 2016, at 02:37 PM, Ximin Luo wrote: >In Debian we have "pip3" but tox hardcodes an invocation to "pip". > >The attached patch fixes this; it should definitely be forwarded to upstream >as well. Hi and thanks for the report/patch. Can you provide a reproducible failure that this bug

Bug#838559: python-pex: tests started to fail on "Connection refused"

On Sep 22, 2016, at 12:10 PM, Martin Pitt wrote: >This does not depend on Debian vs. Ubuntu or container vs. qemu or >whether the test environment uses a proxy by itself. It can trivially >be reproduced locally with the schroot runner: > > autopkgtest --testname execute.sh python-pex -- schroot

Bug#838379: dpkg-dev: Add Testsuite: autopkgtest when a debian/tests/control.autodep8 exists

Package: dpkg-dev Version: 1.18.10 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, I have a Python package that only contains a d/tests/control.autodep8 file, not a d/tests/control file. This requires the addition of an explicit Testsuite:

Bug#838189: The name "tox" is fully misleading and should be better "python-tox"

On Sep 18, 2016, at 09:56 AM, Klaus Ethgen wrote: >I set this bug to normal instead of wishlist as it currently blocks >somehow packaging of other packages. What other packages does it block, and how exactly does it block them? >The name "tox" of this package is extremely misleading as normal

Bug#823922: (no subject)

It's difficult to figure out the copyrights on many of the files in examples. I've asked upstream for details.

Bug#832616: [Python-modules-team] Bug#832616: virtualenv: Doesn't seem to know what version it runs under

On Jul 27, 2016, at 05:06 PM, Matijs van Zuijlen wrote: >virtualenv allows specifying the python version to use. However, when >doing so I get the following output: > > $ virtualenv -p /usr/bin/python3 --system-site-packages .venv > Already using interpreter /usr/bin/python3 > [..] >

Bug#828883: (no subject)

This actually turns out to be a bug in pybuild (dh-python). In zope.interface's d/control file we have: Build-Depends: debhelper (>= 9), dh-python, dpkg-dev (>= 1.16.1~), libpython-all-dbg, libpython-all-dev,

Bug#830892: [Python-modules-team] Bug#830892: python-pip defaults to --user, breaks upstream --target option

On Jul 12, 2016, at 05:41 PM, Daniel Holth wrote: >The problem is that Debian patched pip to make the --user option the >default. In talking with Donald, we all agree that we need to move forward on the upstream switch to --user by default. I don't have time right now to continue working on

Bug#828094: python3-coverage: Missing JavaScript dependency: jquery.debounce.min.js

On Jul 03, 2016, at 09:04 PM, Ben Finney wrote: >I can work to package the library dependency; would you be interested >in sponsoring it into the archive? Yes, for sure! pgpKn2YszV_ST.pgp Description: OpenPGP digital signature

Bug#828094: python3-coverage: Missing JavaScript dependency: jquery.debounce.min.js

Package: python3-coverage Version: 4.1+dfsg.1-2 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, Apparently python-coverage has gained a dependency on jquery.debounce.min.js but this isn't available in the archive afaict.

Bug#827464: python-coverage: Please add usage DEP-8 tests

Package: python-coverage Version: 3.7.1+dfsg.1-1+b2 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, After a recent review, I noticed that DEP-8 tests have been added which do import tests. It would be useful to also add tests which check for run-time

Bug#825112: (no subject)

On Jun 08, 2016, at 10:23 AM, Gordon Ball wrote: >I don't see anything locally, but I do see it when uploading a binary >package to mentors.d.n - I'm unsure how their setup differs from >`lintian --pedantic`. Anyway. Interesting. Oh well, that's why version numbers never run out. :) >If you

Bug#825112: (no subject)

On Jun 07, 2016, at 10:00 PM, Gordon Ball wrote: >> The packaging looks really good. I noticed the setting of http_proxy in >> override_dh_auto_build. You probably don't strictly need that because I >> believe pybuild does that automatically. It can't hurt though and some >> maintainers prefer

Bug#825112: (no subject)

On Jun 07, 2016, at 10:35 AM, Gordon Ball wrote: >Packaging has been done and can be found in collab-maint [1] >(git-buildpackage+pristine-tar format [2]). Current version is >0.3.3+dfsg. Builds for xenial/yakkety can be found in a PPA [3]. Cool. I grabbed and looked at the collab branch. >The

Bug#825112: (no subject)

Just wondering if anybody's made progress on this. I was blown away by the talk on Xonsh at Pycon 2016 [*] and of course the first thing I did was look for it in Debian. :) I'd be happy to help package this up. [*] https://www.youtube.com/watch?v=uaje5I22kgE

Bug#824659: ITP: python-public -- @public decorator for adding names to __all__

Package: wnpp Severity: wishlist Owner: Barry Warsaw <ba...@debian.org> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-public Version : 0.2 Upstream Author : Barry Warsaw <ba...@python.org> * URL : https://pypi.python.org/p

Bug#824566: (no subject)

I don't know how to use targetcli. I tried the simple command you gave in your bug report, but that failed for other reasons (some kind of input file is missing). In any case, I just uploaded pyparsing 2.1.4+dfsg1-1 which has a number of bug fixes. Please try that. If it works for you, great!

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

On May 13, 2016, at 08:51 AM, Rolf Leggewie wrote: >Ubuntu is still unchanged both in Xenial and Yakkety. I'm currently in the process of resyncing the libpeas stack in Debian back to Yakkety. It's slow going because the python2/3 loader issue isn't the only delta from Debian in these packages.

Bug#824072: TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

Package: pyflakes Version: 1.2.2-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, Reported over on Launchpad at: https://bugs.launchpad.net/pyflakes/+bug/1560134 Filing here since I plan on fixing it in Debian. Reproduced by: $ echo "from . import foo"

Bug#823883: (no subject)

On May 11, 2016, at 10:25 AM, Antonio Terceiro wrote: >this test is indistinguishable from one that tests for python2 only ... >only now I noted that all of the python tests are inherentily flawed as >they are testing whether print is called with or without parenthesis, >instead of checking for

Bug#823931: autodep8: Append to existing tests

On May 11, 2016, at 10:29 AM, Antonio Terceiro wrote: >well if debian/tests/control already exists adt-run will not call >autodep8 at all. > >what we could do is make so that if debian/tests/control.autodep8.in (or >something similar) exists, autodep8 begins its output with the contents >of that

Bug#823931: autodep8: Append to existing tests

Package: autodep8 Version: 0.5.1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, autodep8 is very cool. I'm not sure whether this is within its mission but it would be kind of nice if it could run in append mode so that if you had existing tests that flexed

Bug#823883: (no subject)

Looks like I could, so I did! I pushed a 'pypy' branch to git which, if not perfect, seems to work for me in some limited testing without breaking the existing test suite. I'll attach a diff here for the fun of it. diff --git a/support/python/detect b/support/python/detect index 31e23be..4e4e528

Bug#823922: pyparsing: Update debian/copyright

Source: pyparsing Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, - From ftpmaster: Please can you update debian/copyright to reflect (at least) the files under examples/ on the next upload. Thanks. - -- System Information: Debian Release: stretch/sid APT

Bug#823883: autodep8: Support PyPy packages

Package: autodep8 Version: 0.5.1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, Currently autodep8 does a great job of adding simple import tests for Python 2 and Python 3 packages. It doesn't yet support PyPy though, and as we add more support for PyPy in

Bug#823628: lintian: Please add autopkgtest-pkg-python to known test suites

On May 06, 2016, at 10:05 PM, Axel Beckert wrote: >Lintian in git already knows about this (for about a week :-), hence >marking as pending. Yay! Thanks. pgpUkehrL8JoF.pgp Description: OpenPGP digital signature

Bug#823628: lintian: Please add autopkgtest-pkg-python to known test suites

Package: lintian Version: 2.5.44 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, In Python packages, with autopkg8, you can now say this in your d/control file: Testsuite: autopkgtest-pkg-python but lintian doesn't know about this yet: Now running lintian...

Bug#822750: (no subject)

Exactly what command did you run? I can't reproduce this: % pip install world Collecting world Using cached world-3.1.1-py2.py3-none-any.whl Collecting setuptools (from world) Using cached setuptools-20.10.1-py2.py3-none-any.whl Installing collected packages: setuptools, world Successfully

Bug#821442: schroot: operation not permitted (only with 4.5 kernel)

On Apr 18, 2016, at 09:40 PM, James McCoy wrote: >I've been seeing something similar. Am I right to assume that these are >union-type=overlay? If so, this seems to be a change in the kernel. Yep, union-type=overlay. pgpyRCcXhRcjK.pgp Description: OpenPGP digital signature

Bug#821442: schroot: operation not permitted

Package: schroot Version: 1.6.10-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, With today's dist-upgrade, I am unable to enter an existing or newly created chroot, nor am I able to sbuild or adt-run with the chroot. I had an existing sid-amd64 chroot

Bug#821223: [Python-modules-team] Bug#821223: Unable to create a virtualenv: invalid requirement: '_markerlib'

I'll have a fix uploaded momentarily.

Bug#821223: (no subject)

Can you please report the output of `dpkg-query -W python-pip-whl`, both if virtualenv works and doesn't work for you?

Bug#814397: (no subject)

We should devendor packaging from setuptools. From IRC: By the way, I'm pretty sure that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814397 is because pip unbundles and the latest python-pkg-resources doesn't (now that I actually look at setuptools) so pip is using

Bug#820195: (no subject)

FWIW, attached is the patch in Ubuntu which fixes the FTBFS. This comes from 0.6-1ubuntu1. Description: Adapt tests to changes in NumPy 1.10 Default casting rule Origin: Upstream (commit 9b91b1789c8dc81e84c0a8691febbd1e242a81d1) --- pint/testsuite/helpers.py | 8 +++-

Bug#820693: gdebi: Add flakes8 Build-Depends to fix FTBFS

Package: gdebi Version: 0.9.5.7 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, pyflakes has been split with /usr/bin scripts in separate binary packages for Python 2 and 3. This causes gdebi to FTBFS because it can't find pyflakes3. A simple addition of

Bug#804582: (no subject)

Okay, so I think the locale changes are enough to fix the FTBFS. I retried building in an Ubuntu PPA and the build succeeded. The timeout failure must just have been a problem with my local sbuild.

Bug#804582: (no subject)

It's a locale problem. This fixes most of the problems: diff --git a/debian/rules b/debian/rules index 9c04662..6130dc4 100755 --- a/debian/rules +++ b/debian/rules @@ -1,6 +1,8 @@ #!/usr/bin/make -f export PYBUILD_NAME=paramiko +export PYBUILD_VERBOSE=1 +export DH_VERBOSE=1 %: dh

Bug#804582: (no subject)

I haven't quite fixed it yet, but it's almost certainly related to FOLDER in test_sftp.py. When the tests, such as test_K_utf8() fail, it's because the folder isn't empty so the os.rmdir() fails. Quickly I tried to add a TEST_FOLDER=`mktemp -d` to the test command but that didn't quite work. I

Bug#804582: (no subject)

On Apr 08, 2016, at 10:59 AM, Jeremy T. Bouse wrote: >Yes, I'd taken a slightly different approach but got to the same results >that you are currently getting. I have included your approach as it is >much cleaner than what I'd hacked together. > >Still trying to get to the bottom of those

Bug#804582: (no subject)

I'm running across this too now. I think part of the problem is that pybuild invokes unittest discover by default, but this isn't how paramiko's test suite is actually run, at least if you go by what's in the tox.ini file. This gets me closer: diff --git a/debian/rules b/debian/rules index

Bug#807351: (no subject)

I just ran across this bug too, but not until I worked out a different patch. ;) I'd be fine with Neil's patch, or deleting the test entirely. In the attached, I only assert that the SystemError is raised, but not what the exception message is. The other change is to close a small (possibly

Bug#806824: libpeas python split

Hi Michael, On Apr 04, 2016, at 01:52 AM, Michael Biebl wrote: >Andreas was suggesting a compromise. Split out the python2 loader but keep >the python3 loader within the main libpeas-1.0-0 package. This will reduce >the churn quite a but. I think I missed that, thanks for the clarification.

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

On Apr 02, 2016, at 10:33 PM, Rolf Leggewie wrote: Hi Rolf, >I'm still at a loss what it is you are asking of me. The title of this >bug requests me to add a run-time dependency that doesn't even exist in >Debian yet. In Ubuntu the change you advocate has been made, but >apparently there were

  1   2   3   4   5   6   >