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
painful suggestion for now, with the
least possibility of regressions or breakages.
Cheers,
-Barry
pgpoIISfZz1IH.pgp
Description: OpenPGP digital signature
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
hat Debian ought to have automatic promotion gating on reverse
dependency building and testing.
All that aside, if someone wants to help put together a git branch that
properly reverts html5lib to seven-9's, I will gladly review and test it with
pip, and upload it if it looks okay.
Cheers,
-B
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
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;
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
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.
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 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
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
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 <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 :
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 <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
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
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
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
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
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
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:
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 <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
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 <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
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
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
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
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
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
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
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:
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
It's difficult to figure out the copyrights on many of the files in examples.
I've asked upstream for details.
Just confirming version 2.5-2+v2.4-1 currently in the debian repository
works for me.
Thanks for the fix, at least for now.
Similar problems here, using the following device on a Mac Air...
03:00.0 Network controller: Broadcom Corporation BCM4360 802.11ac Wireless
Network Adapter (rev 03)
... but interestingly, only when connecting to a rather old WiFi router
that contains an Atheros b/g card.
I can connect to a
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,
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
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
: commands[1] | python -m coverage combine
- --rcfile=/home/barry/projects/ubuntu/allsnappy/ubuntu-image/coverage.ini
coverage runtests: commands[2] | python -m coverage html
- --rcfile=/home/barry/projects/ubuntu/allsnappy/ubuntu-image/coverage.ini
Couldn't find static file 'jquery.debounce.min.js
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
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
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
Earlier, Jasper Wallace asked whether "this one of those situations
where some unfortunate volunteer has ended up becoming critical security
infrastructure?"
The current flash security update (from 616 to 621) is now two weeks
overdue from the upstream site, and the player has been blacklisted
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
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
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
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
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
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
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
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
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?
Today the missing signature file preventing update of the nonfree flash
was added to
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/ enabling
updates -- eight (8) days after the publication of a CVE and five (5)
days after detection of an exploit in the wild.
Could this be a
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
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 +++-
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
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
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
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
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
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.
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
On Apr 02, 2016, at 12:27 PM, Rolf Leggewie wrote:
>On 11.03.2016 19:45, Barry Warsaw wrote:
>> In bug #806824 I propose to split the Python loaders for libpeas into
>> separate binary packages.
>
>That split hasn't happened yet and it isn't even clear if
>libpeas-1.0-0
On Mar 24, 2016, at 10:06 AM, Joel Cross wrote:
>Ddoes this mean that if I need to use the Python 2 version of Flake8 (for
>instance, for linting my Python 2 files), that I will need to install my own
>binary? It seems to me that if the package is missing a binary, and that
>binary isn't
leanup "rejecting $debfile : wrong
sha256sum"
[ `sha1sum $debfile|sed -e "s, .*,,"` =
"$debsha1" ] || die_hard_with_a_cleanup "rejecting $debfile : wrong sha1sum"
[ `md5sum $debfile|sed -e "s, .
I just tried this on a fully dist-upgraded sid machine:
@chemistry[~:1005]% virtualenv -p python3.5 /tmp/p35
Running virtualenv with interpreter /usr/bin/python3.5
Using base prefix '/usr'
New python executable in /tmp/p35/bin/python3.5
Also creating executable in /tmp/p35/bin/python
Installing
On Mar 22, 2016, at 12:12 PM, Ramakrishnan Muthukrishnan wrote:
>I am totally new to tox. I am assuming that tox itself being a python3
>program shouldn't affect running it *on* a python2 project. I would
>request some help understanding what is going on.
This is a known upstream problem.
so, isn't it possible that
third parties might still have Python 2 plugins for applications outside of
the Debian archive?
-Barry
pgpswRZmYXi4s.pgp
Description: OpenPGP digital signature
On Mar 11, 2016, at 04:16 PM, Michael Biebl wrote:
>first of all, would be great if you can block all bugs you filed by this
>one, so we can keep track of them more easily and the maintainers of
>those packages know that they should hold off until this particular bug
>report has been dealt with.
Source: entangle
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
In bug #806824 I propose to split the Python loaders for libpeas into
separate binary packages. This allows us to segregate the Python 2
and Python 3 versions, and eases the transition to a
Source: roger-router
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
In bug #806824 I propose to split the Python loaders for libpeas into
separate binary packages. This allows us to segregate the Python 2
and Python 3 versions, and eases the transition to a
Package: eog
Version: 3.18.2-1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
In bug #806824 I propose to split the Python loaders for libpeas into
separate binary packages. This allows us to segregate the Python 2
and Python 3 versions, and eases the
On Mar 11, 2016, at 07:22 AM, Michael Biebl wrote:
>It creates unnecessary churn and potential stale dependencies in the future.
>Most importantly, this split looks like an implementation detail to me.
>I don't see, why packages should add a dependency on
>libpeas-1.0-0-python3loader but not
On Mar 11, 2016, at 12:20 AM, Michael Biebl wrote:
>Tbh, I'm not too thrilled by hard-coding dependencies on
>libpeas-1.0-0-python3loader in several packages.
Can you explain why?
pgpHuFur8yD98.pgp
Description: OpenPGP digital signature
101 - 200 of 2076 matches
Mail list logo
