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 0
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 packages to use
`
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
Description: Messa
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 should remove this
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 wrote:
> @barry: I could
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 taking a break from D
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` p
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 pack
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 same
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 0
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 di
Maybe, create a python{,3}-pyside-common package that only contains the
.egg-info and then have all subpackages depend on that?
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
pgp08bth0I
https://code.launchpad.net/~barry/autopkgtest/+git/autopkgtest/+ref/852475
pgp9syopDe3sn.pgp
Description: OpenPGP digital signature
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 in
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 we
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.
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 f
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 newer
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 even
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
p
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 clu
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).
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; t
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
pgpyPVZk
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.
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.
pg
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. I
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
th
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 co
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
Are you sure that link actually exists?
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-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 : ASLv2
Programming Lang: Python
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.
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: flufl.testing
Version : 0.1
Upstream Author : Barry Warsaw
* URL : https://gitlab.com/warsaw/flufl.testing
* License : ASLv2
Programming
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
https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/1640217
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 --extra-pack
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 is
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 upload)
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 wi
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: OpenPGP
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.
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
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
On Mon, 31 Oct 2016 18:25:16 -0400 Barry Warsaw 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 it makes lintian unhappy:
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?
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-webencodings
Version : 0.5
Upstream Author : Simon Sapin
* URL : https://github.com/gsnedders/python-webencodings
* License : BSD
How would we do that? I'm not particularly fond of debian/control.in files.
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 resync'
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!
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
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
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 have
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 coexist.
ec2bd443aee9 Mon Sep 17 00:00:00 2001
From: Barry Warsaw
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 documentation
described the # separa
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
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'
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 fi
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 s
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: autopkgtest-pkg-pytho
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 us
It's difficult to figure out the copyrights on many of the files in examples.
I've asked upstream for details.
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
> [..]
>
>
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,
libpython3-al
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 that
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
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.
Th
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 function
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 thi
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
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
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
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-public
Version : 0.2
Upstream Author : Barry Warsaw
* URL : https://pypi.python.org/pypi/atpublic
* License : ASL2
Programming Lang
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!
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.
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" >
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 wh
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 f
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 a
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
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 p
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 t
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
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...
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 in
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
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 whi
I'll have a fix uploaded momentarily.
Can you please report the output of `dpkg-query -W python-pip-whl`, both if
virtualenv works and doesn't work for you?
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 pa
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 +++-
pint/testsuite/test
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 pyfla
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.
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
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 t
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 remainin
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 9c046
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 only
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.
Th
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 n
1 - 100 of 576 matches
Mail list logo
