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
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.
On Mar 13, 2016, at 12:29 AM, Michael Biebl wrote:
>So, if I'm counting correctly, there are only 3 packages remaining that
>use the python2 loader. Somehow I think the best course of action would
>be to get those updated to python3.
Perhaps, but isn't that an upstream decision? Also, isn't it
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
Package: totem
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
I finally managed to report bugs on deja-dup, eog-plugins, gedit,
gnome-builder, gtranslator, liferea, rhythmbox, and totem.
pgpq2cruhIG61.pgp
Description: OpenPGP digital signature
Package: liferea
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: gtranslator
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: gnome-builder
Version: Please add libpeas-1.0-0-python3loader to Depends
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
Package: gedit
Version: 3.18.3-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
Package: eog-plugins
Version: Please add libpeas-1.0-0-python3loader to Depends
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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
Source: deja-dup
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
debugging when the
+ensurepip command fails.
+ * d/patches/ensurepip-wheels.diff: Update for compatibility with latest
+python-pip packages.
+ * d/control.in: Update python-pip-whl dependency version.
+
+ -- Barry Warsaw <ba...@debian.org> Wed, 09 Mar 2016 16:23:54 -0500
+
python3.5 (3
On Mar 05, 2016, at 10:06 PM, Ben Finney wrote:
>I have made another attempt, by using the above separation to inspire
>several parallel branches:
>
>* master: An integration-only branch for what the DPMT team requires.
>* upstream: The upstream source from released tarballs.
>* pristine-tar: The
I think this should now all be sorted out with python-virtualenv 15.0.0+ds-1
and python-pip 8.1.0-1. I'm going to close this bug but if you're still
having a problem with those new versions, please reopen it.
/control.in: Update python-pip-whl version dependency.
+
+ -- Barry Warsaw <ba...@ubuntu.com> Mon, 29 Feb 2016 16:45:06 -0500
+
python3.5 (3.5.1-6ubuntu2) xenial; urgency=medium
* python3.5-venv: Drop the dependency on python-pip-whl, depend on
diff --git a/debian/control.in b/debian/cont
more debugging when the
+ensurepip command fails.
+ * d/patches/ensurepip-wheels.diff: Update for compatibility with latest
+python-pip packages.
+ * d/control.in: Add virtualenv to Depends of pythonX.Y-venv.
+
+ -- Barry Warsaw <ba...@ubuntu.com> Mon, 29 Feb 2016 16:45:06
Does this problem happen on Stretch/unstable?
On Feb 19, 2016, at 11:52 AM, Iain Lane wrote:
>Assuming that the analysis is the same as Ubuntu, that leaves
>
> deja-dup entangle eog gedit gnome-builder gtranslator liferea totem rhythmbox
>
>to be updated.
That's a few more than what I changed in Ubuntu, which makes me think maybe I
missed
We've gone ahead and made this transition in Ubuntu 16.04, just as described
here. See LP: #1440504 for the changes we made to dependents. I am not a
Gnome developer so I don't want to make the changes in Debian despite being a
DD, but I'm happy to help if patches are needed.
On Feb 15, 2016, at 10:23 PM, Sebastian Ramacher wrote:
>Yes, it's a bug and it will be fixed shortly. It's a serious bug in Ubuntu,
>but it's nowhere near serious in Debian. Python 3.4 is still supported. Once
>we start the transition to remove Python 3.4 from the supported set and are
>left
Please be aware that this bug makes the package completely unusable for Python
3 users on such systems as described here. Thus I think serious is a valid
severity. I'll stop complaining once this bug is fixed though. Thanks.
Source: pytest
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
The change uploaded in 2.8.7-3 that closes #814622 and reverts the
change from 2.8.7-2 causes a critical regression in the DEP-8 tests on
Ubuntu, where only Python 3.5 exists. Once Debian drops
On Feb 15, 2016, at 08:06 PM, Sebastian Ramacher wrote:
>This is just not true. python3.m5 -m pytest works just fine. If not, please
>file a proper bug report.
The fix you uploaded introduces a regression, albeit in Ubuntu only right now,
but it will show up in Debian once Python 3.4 is dropped.
The reversion of 2.8.7-2 is not correct. It breaks the DEP-8 tests in Ubuntu
where there is only Python 3.5 (and will break Debian as soon as Python 3.4 is
dropped).
By reverting this, you find that there is no Python 3 module in python3-pytest
and `python3.5 -m pytest` fails. Please restore
On Feb 15, 2016, at 11:37 AM, Matthias Klose wrote:
>No, in the first place it's a bug to not declare a proper Breaks/Replaces.
Well, in the meantime, you uploaded a new version of python-setuptools, so the
Breaks/Replaces that already exists in python-pip is now out of date. But if
you agree
On Feb 13, 2016, at 07:27 AM, Ralf Treinen wrote:
>Here is a list of files that are known to be shared by both packages
>(according to the Contents file for sid/amd64, which may be
>slightly out of sync):
>
> /usr/share/python-wheels/setuptools-20.0-py2.py3-none-any.whl
>
>This bug has been
https://bugs.launchpad.net/debian/+bug/1545013
On Feb 12, 2016, at 01:11 PM, Andreas Beckmann wrote:
>the Breaks+Replaces against python-six-whl are insufficiently versioned,
>that package was removed in six 1.10.0-3, it is still present in -2.
I'm not sure I can make piuparts cooperate for me locally, but it's obvious
the Replaces/Breaks
Since upstream hasn't changed the default yet, and for understandable reasons
it isn't high on their priority list, and because I'm tired of carrying the
Ubuntu delta that switches to --user by default, I am going to port the Ubuntu
patch to the Debian version. This will let me resync to Debian
On Feb 10, 2016, at 11:43 AM, Donald Stufft wrote:
>Can we at least ensure that $HOME/.local/bin is on the $PATH by default if
>you’re going to do that?
How can we do that? Not in python-pip certainly. Users control their own
$PATH so I'm not sure how we can enforce that. I'm not sure what
Package: autopkgtest
Version: 3.19.2
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
My DEP-8 tests create some temporary directories, and they use $ADTTMP
to calculate the paths to create. However, if the tests fail and
you're using --shell-fail/-s, you get
On Feb 08, 2016, at 10:51 AM, Colin Watson wrote:
>Looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813399, but
>more of the same. Barry, shouldn't you be doing something like
>"python-six-whl (<< 1.10.0+)", rather than these sketchy <= dependencies
>on specific packaging revisions
On Feb 01, 2016, at 04:24 PM, Andreas Beckmann wrote:
>during a test with piuparts I noticed your package fails to upgrade from
>'testing'.
>It installed fine in 'testing', then the upgrade to 'sid' fails
>because it tries to overwrite other packages files without declaring a
>Breaks+Replaces
Hi Sebastian,
On Jan 30, 2016, at 01:34 AM, Sebastian Ramacher wrote:
>This was an upgrade and python-pip-whl version 1.5.6-7 is installed.
You definitely need python-pip-whl 8.0.2-1
Did that not install when you upgraded?
pgpn9pUGB0Pp7.pgp
Description: OpenPGP digital signature
On Jan 30, 2016, at 01:07 AM, Sebastian Ramacher wrote:
>After installing python3-cachecontrol, python3-lockfile, python3-packaging,
>python3-progress and python3-retrying, pip3 no longer fails with ImportErrors.
Those shouldn't be necessary. Was this an upgrade or a fresh install of these
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw <ba...@debian.org>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-progress
Version : 1.2
Upstream Author : Giorgos Verigakis
* URL : https://github.com/verigak/progress/
* L
Ultimately, this is a bug in Cython, which upstream is aware of and should fix
by Python 3.6. I reverted the change in upstream Python 3.5 (and 2.7) since
it's technically a regression. Matthias has cherry picked the fix for
Ubuntu's Python 3.5; I assume but am not sure if he's also done the
that they require. (Closes: #806824)
+
+ -- Barry Warsaw <ba...@debian.org> Fri, 15 Jan 2016 10:09:02 -0500
+
libpeas (1.16.0-1) unstable; urgency=medium
* New upstream release.
Index: debian/control.in
===
--- debian/cont
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw <ba...@debian.org>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: dirtbike
Version : 0.1
Upstream Author : Asheesh Laroia
* URL : https://github.com/paulproteus/dirtbike
* License :
This is actually easier than I first thought. All we need to do is move the
Python loaders to separate binary packages and update dependents which ship
Python support to Depends on the appropriate loader package.
This is an important fix so that we can provide images which only have Python
3
On Dec 29, 2015, at 02:37 PM, Andreas Metzler wrote:
>Control: tags 808922 + patch
>Control: tags 808922 + pending
>
>I've prepared an NMU for pycurl (versioned as 7.19.5.3-1.1) and
>uploaded it to DELAYED/15. Please feel free to tell me if I
>should delay it longer.
Yes, please delay it just a
Package: python3-genshi
Version: 0.7-5
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
ScottK pointed this out to me last night, but I don't have time right
now to debug this, so I'm filing this bug in case someone else has
time and inclination, and so it won't
On Jan 06, 2016, at 01:34 PM, Nikolaus Rath wrote:
>If necessary, s3ql can also be build with cython instead of cython3.
I strongly suspect this is a regression due to
http://bugs.python.org/issue22995 which I've now reopened. We're probably
just starting to see the unintended consequences of
On Jan 04, 2016, at 10:43 AM, Carl Chenet wrote:
>We have a RC bug for Tweepy in Debian because the unittest2 and/or vcr
>Python modules are not packaged for Debian
Not correct. Both packages are in Debian for both Python 2 and 3.
We have unittest2 1.1.0-6 and vcr 1.7.3-1
There must be some
On Dec 23, 2015, at 07:20 PM, Tristan Seligmann wrote:
>If you want to run pytest with a particular version of python, then
>"pythonX.Y -m pytest" is a much better way than relying on the py.test-X.Y
>scripts.
Sorry, I've had no time to respond in detail, but in general I agree with
this. It's
I made a small additional fix to the bilingual branch. The files passed to
pickle.load() and pickle.dump() must be opened in binary mode. Pushed to git.
Package: git-buildpackage
Version: 0.7.0
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
It seems like /usr/bin/git-dch is missing from git-buildpackage 0.7.0
even though apt-file lists it there. This breaks e.g. gbp import-orig
- --uscan and probably other
On Dec 02, 2015, at 06:02 PM, Guido Günther wrote:
>All git- and gbp- commands were removed back in February (and
>deprecation announced long before that). I guess you have
>git-dch in a post import hook that should be updated.
Indeed, sorry for the noise.
pgpFenigmuKis.pgp
Description:
Source: libpeas
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
As we move to a world dominated by Python 3, we are trying to reduce
the dependencies on Python 2 in Debian and derivatives. libpeas is a
problem because the package links against both Python 2
On Nov 28, 2015, at 05:37 PM, Ben Finney wrote:
>Okay, I've been struggling mightily with Git. Both in the “working
>together” sense, and in the “fighting against” sense. Can you help?
I'm certainly willing to try!
>I'm quite loath to lose the simplicity of a Debian packaging
>repository. There
On Nov 26, 2015, at 05:04 PM, Ben Finney wrote:
>I have finished updating the Debian package for ‘python-lockfile’
>version “0.11.0”. Before I finalise the release, is now a good time to
>discuss adding DPMT as a maintainer?
>
>Can I continue to maintain the packaging-only repository in a Bazaar
I now have two branches ready for review. The first just modernizes the code
and makes it bilingual so it'll work in Python 2.7, 3.4, and 3.5:
http://anonscm.debian.org/cgit/collab-maint/apt-xapian-index.git/log/?h=bilingual
This should be a pretty low risk branch to merge. It does not switch
I've just switched over to using sbuild (from pbuilder) to build my packages
for upload to Debian and I've run into this same bug.
My workflow generally involves building the source package by whatever means
is necessary for the package (depends on team, vcs, etc). Then I run adt-run,
sbuild
Package: apt-xapian-index
Version: 0.47
Severity: wishlist
File: apt-xapian-index
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
Since Python 3 is awesome, apt-xapian-index should be ported to it. I
have a branch that passes the test suite in Python 3.5 when importing
the
I think the proper fix for #802141 should have been to
export PYBUILD_DISABLE=test
I'm not sure there really is much dh-python can do here. Note that there
really are no tests in the upstream package. Cloning upstream's hg you find:
% python3.4 -m unittest discover -v
--
Ran 0 tests in 0.000s
OK
and
%
A better way to skip trying to run the nonexistent upstream test suite is to
add this to d/rules:
export PYBUILD_DISABLE=test
Thanks for diagnosing this further Matthias. I think you're on the right
track. For example, if I add this to zope.testing's d/rules, the bogus empty
/usr/lib/python3.5/dist-packages directory does not get installed:
override_dh_auto_test:
dh_auto_test
rm -rf
Package: lintian
Version: 2.5.38
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
lintian reports two complaints about the zope.interface package:
lintian
/home/barry/projects/debian/zinterface/build-area/zope.interface_4.1.3-1_source.changes
E: zope.interface
Package: dh-python
Version: 2.20150826
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
If a setup.py has dependencies in test_require or extras_require, they
don't seem to get satisfied by py3dist-override or the built-in
cpython3_fallback.
For example, when
Source: numpydoc
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
debian/copyright produces a bunch of lintian warnings:
W: numpydoc source: empty-short-license-in-dep5-copyright (paragraph at line 5)
W: numpydoc source: empty-short-license-in-dep5-copyright
On Oct 26, 2015, at 11:04 AM, Andreas Tille wrote:
>I took the freedom to fix the minor bug in addition to the serious
>one. Please add the debdiff to your packaging git.
Done, and thanks!
https://github.com/malthe/chameleon/issues/206
pgpnhg3ANe6hJ.pgp
Description: OpenPGP digital signature
On Oct 23, 2015, at 07:03 PM, Piotr Ożarowski wrote:
>most if not all files that differ outside egg-info dir are valid cases
>(version specific changes, so files, ...) so I don't think standard
>error is the right place (and I definitely don't want to see changes in
>.so files in build log)
I
After talking with Donald Stufft, we agreed that ignoring all dot-directories
isn't a good approach, and not something upstream would be interested in.
I've cloned this bug onto python-setuptools and am preparing a patch that will
prune debian/ and .pybuild/ for that package. It's a two-line
/ and debian/ as these are Debian artifacts.
+Closes: #802792.
+
+ -- Barry Warsaw <ba...@debian.org> Fri, 23 Oct 2015 10:45:35 -0400
+
python-setuptools (18.4-1) unstable; urgency=medium
* New upstream version.
diff --git a/debian/patches/ignore-debian-artifacts.diff b/debian/p
I know exactly what's going on now.
When setuptools wants to create the egg-info/SOURCES.txt file, it calls into
distutils to get a full manifest of all the files that are going to be
installed. For better or worse, what distutils does is:
* walk the filesystem from cwd, getting a list of all
On Oct 18, 2015, at 08:57 PM, Daniel Stender wrote:
>I've test build and saw that there are problems ... thanks for the pointer to
>the bug.
I've diagnosed the bug and proposed a fix. Let's see what Piotr says.
pgpTWSa9gtmfE.pgp
Description: OpenPGP digital signature
On Oct 21, 2015, at 09:41 AM, Martin Pitt wrote:
>Barry Warsaw [2015-10-15 13:48 -0400]:
>> With python-pex, an extra dependency is required on Ubuntu that isn't
>> required on Debian. Originally I was keeping an Ubuntu delta that
>> only differed by including the extra
On Oct 21, 2015, at 03:13 PM, Piotr Ożarowski wrote:
>if you use pybuild, then I suggest to:
>
>export PYBUILD_AFTER_INSTALL=find {destdir}{install_dir} -name SOURCES.txt
>-delete
>
>and send yet another angry email to setuptools authors ;)
I don't think it's as simple as that, otherwise it
Stepping through share_files() in dhpython/fs.py yields a clue. What appears
to happen is that share_files() is first called on the python3.4/dist-packages
tree and that gets copied into python3/dist-packages.
Then it gets called on the python3.5/dist-packages tree, and we find a
difference in
Actually, it looks like the extra python3.5 files are in the 3.4 dist-packages
and not the 3.5 dist-packages. ?!
pgpmYB2oPTCU5.pgp
Description: OpenPGP digital signature
On Oct 17, 2015, at 09:46 PM, Daniel Stender wrote:
>manuel [1] needs python{,3}-zope.testing for its test suite. Due to the
>missing egg-info in python3-zope.testing setup.py tries to fetch it over the
>net, which leads to a break of the tests during building leading to FTBFS of
>this package
Package: autopkgtest
Version: 3.17.3
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
With python-pex, an extra dependency is required on Ubuntu that isn't
required on Debian. Originally I was keeping an Ubuntu delta that
only differed by including the extra
Package: autopkgtest
Version: 3.17.3
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
python-pex tries to go out to pypi.python.org if it finds a dependency
that it can't satisfy with a system package. This hid some test
failures. I ended up doing this:
# Now
git-dpm allows for setting the tag format in debian/.git-dpm. Perhaps it
should be allowed to set the branch names here, or perhaps both the branch
names and tag formats should be settable in a debian/git-dpm.conf file or some
such?
pgpPioBrzaiVy.pgp
Description: OpenPGP digital signature
I don't have any great ideas, and I've never had to do this, but this article
might give some hints for approaches to experiment with.
http://stackoverflow.com/questions/449541/how-do-you-merge-selective-files-with-git-merge
Seems like it's a general git issue?
pgpFiMp1T4WOJ.pgp
Description:
Package: dh-python
Version: 2.20150826
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
dh_python3 sometimes leaves an empty
usr/lib/python3.Y/dist-packages/*.egg-info directory in python3-
binary packages. I haven't yet tracked the problem down but I have
two
Package: python-pex-cli
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
python-pex-cli is a problematic name for two reasons. First, it is
less discoverable because the executable is named /usr/bin/pex.
Second, /usr/bin/pex is a Python 3 script and dh_python3
Package: python-apt
Version: 1.0.0+b1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
python-apt 1.0.0 deprecates some APIs. The ensuing
DeprecationWarnings issues to stderr during the DEP-8 tests cause the
tests to fail. The fix is simple, although an
Indeed it's weird, but it's apparently included in the upstream tarball. I
don't know why, but let's see if upstream fixes it for now.
https://bitbucket.org/stoneleaf/enum34/issues/7/enum-enumpy-symlink-in-104-tarball
pgpyd_9_HWxQC.pgp
Description: OpenPGP digital signature
On Sep 22, 2015, at 01:07 PM, Gediminas Paulauskas wrote:
>I have committed a fix, but don't have the rights to upload it.
Thanks Gediminas! I made some very small tweaks to d/changelog, but will
sponsor the upload after some local testing.
I think the best we can do is add a Conflicts between the two packages. The
contents of the conflicting directories are different. Personally, I think
it's a bug that the two upstreams install these into the top-level namespace,
but given the nature of the packages, I can see why they did it
Source: debian-science
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
python-pyke (source package pyke) hasn't been modified upstream since
at least 2013 if not earlier. pyke is no longer compatible with the
newer versions of ply which are in unstable.
Upstream changeset:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=2e4c2fe2787785a421f256541de642976e9bd90b
Can this be cherry picked for Debian's emacs24?
pgpJYg_fPCADm.pgp
Description: OpenPGP digital signature
the renaming of a private attribute in Python 3.5.
Author: Barry Warsaw <ba...@ubuntu.com>
Bug: https://bitbucket.org/catherinedevlin/cmd2/issues/18/python-35-renames-subprocessmswindows
--- a/cmd2.py
+++ b/cmd2.py
@@ -47,6 +47,13 @@
if sys.version_info[0
core.zip location.
+ * debian/watch: Use the pypi.debian.net redirector.
+
+ -- Barry Warsaw <ba...@debian.org> Thu, 10 Sep 2015 15:25:31 -0400
+
python-babel (1.3+dfsg.1-5) unstable; urgency=medium
* Team upload.
Index: debian/c
Source: cssutils
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
cssutils 1.0-2 fails to build from source with Python 3.5.
The upstream bug report is here:
https://bitbucket.org/cthedot/cssutils/issues/52/bad-octal-escape-blows-up-on-python-35b3
- -- System Information:
Source: genshi
Severity: important
Owner: !
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
genshi 0.7-3 currently FTBFS with Python 3.5. Upstream ticket is
http://genshi.edgewall.org/ticket/602 which contains a patch, although
this doesn't completely solve the problem for me. This is a
Source: python-debtcollector
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
Version 0.7.0 is the latest version on PyPI and it fixes some
compatibility problems with Python 3.5. Please consider upgrading the
experimental version to 0.7.0. Also, please change
Source: ply
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
A new version of ply is available. However PyPI only has 3.6 while
3.7 is available from the ply home page.
https://pypi.python.org/pypi/ply
http://www.dabeaz.com/ply/
I've reported this as a bug
Source: python-future
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
zigo requested that I take over maintenance of this package. I'm
happy to do so as Uploader, but DMPT should be Maintainer. Let's move
this package to DPMT's alioth at the same time. There's no sense in
101 - 200 of 576 matches
Mail list logo
