On Aug 27, 2015, at 10:50 AM, Piotr Ożarowski wrote:
Dear Maintainer,
Dear Co-Maintainer ;)
$ reportbug reportbug
:)
What you really wanted me to fix is #793148. I still have 2.6 installed
to test these parts of the code (and I cannot really enable them at
build time - I added a notes about
Package: dh-python
Version: 2.20150728
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
tests/Makefile still lists Python 2.6 as a supported version:
export DEBPYTHON_SUPPORTED=2.6,2.7
This breaks autopkgtest, as can be seen on ci.debian.net
Source: python-pykmip
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
python-pykmip currently includes Depends and Build-Depends on
python3-enum34. This package is incompatible with Python 3.5 and
unnecessary for Python 3.4 since the stdlib already contains
Package: python3-pies
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
python3-enum34 binary package has been removed from the archive,
because all supported versions of Python 3 already include the stdlib
enum package, and enum34 is no longer compatible with
On Aug 20, 2015, at 11:09 PM, Martin Pitt wrote:
However, I would be fine with approaching this from another angle: We
currently have the possibility to source arbitrary parts of the
command line from a file, with @. E. g.
adt-run foo.dsc @adt/lxc_runner.conf
which contains e. g. --- lxc -s
Can't you use `pex --python=python2.7`?
pgppNqfS8wtie.pgp
Description: OpenPGP digital signature
: python{,3}-setuptools, locales
+ - Bump Standards-Version to 3.9.6.
+ * debian/rules: Run the test suites under en_US.UTF-8 locale.
+ * debian/python-tables{,-doc}.docs: It's README.rst now.
+
+ -- Barry Warsaw ba...@ubuntu.com Tue, 11 Aug 2015 18:11:30 -0400
+
pytables (3.1.1-3) unstable
100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-apt (1.0.0~beta4) UNRELEASED; urgency=medium
+
+ * To properly conform to PEP 479 and Python 3.5, __iter__() methods
+should return when exhausted instead of raising StopIterator.
+
+ -- Barry Warsaw ba...@debian.org Thu
Source: matplotlib
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
matplotlib fails to build from source when multiple versions of Python
3 are supported. In Ubuntu we are working on the Python 3.5
transition and have an experimental PPA which defaults to
Package: pkg-gnome-tools
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
gnome-pkg-tools 0.19.5 (previewed in Ubuntu's 0.19.4ubuntu1)
introduces a build dependency loop with pygobject, preventing them
from being rebuilt together. This will be a problem during
Package: devscripts
Version: 2.15.5
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
After bug #785746 was fixed, uscan rewrites pypi.python.org to use the
pypi.debian.net redirectory. That's great, except that it's
undocumented. Please add a description of
Source: pillow
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
debian/rules adds $DEB_HOST_MULTIARCH to $SOABI, but this is incorrect
for Python 3.5, where the arch triplet is already included in $SOABI.
Attached is a patch that only conditionally adds the
Oops, of course I forgot to mention the change to d/rules in the changelog
entry, but you can fix that. :)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
+- 05_upstream_devendorize.patch: Upstream's pull request to better
+ support the devendorizing of urllib3 and chardet.
+
+ -- Barry Warsaw ba...@debian.org Wed, 10 Jun 2015 12:28:58 -0400
+
requests (2.7.0-2) unstable; urgency=medium
* Upload to unstable.
Index: debian/patches
Upstream issue:
https://bitbucket.org/pypa/wheel/issue/143/reproducible-whl-files
My PR:
https://bitbucket.org/pypa/wheel/pull-request/52/apply-the-debian-patch-for-reproducible/diff
For the timestamp, I added support for $WHEEL_FORCE_TIMESTAMP envar, so after
this lands, we could change the
The only part of the patch I don't like is the hard-coding of the timestamp.
I don't have a better idea, but before I apply this I'm going to see if
upstream has any suggestions. I'll include in that bug report the other two
fixes which look good.
pgpypITBp1bsR.pgp
Description: OpenPGP digital
Package: git-dpm
Version: 0.9.1-1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
To update to a new upstream release, I do this:
$ git-dpm import-new-upstream --ptc --rebase-patched ../foo.orig.tar.gz
Normally, if the patches rebase cleanly, everything is
This is almost certainly related to the distlib 0.2.0 update which manifest in
bug #785787 (and was fixed there for that example). We'll keep running into
these until I can finish the pip 7 work.
pgpam2W2BNYvI.pgp
Description: OpenPGP digital signature
@Felix: Thanks for the diagnosis and patch. It works for me and I've double
checked the patch with dstufft (upstream pip maintainer).
pgpT25jLsQYhn.pgp
Description: OpenPGP digital signature
@Felix: Actually the pip_util.diff is only relevant for bug #758787. I've
tested what will be pip 1.5.6-6 with that patch and it isn't relevant for bug
#786440 afaict.
I'm inclined not to fix this for the 1.5.6 series, and just concentrate on
getting (now) pip 7 into Debian.
pgpKfRMOrZuuz.pgp
Package: schroot
Version: 1.6.10-1+b1
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
It seems that union-type has broken for all three possible union mount
types described in 10mount. I used to be using aufs, but in a fresh
built stretch-amd64 chroot
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw ba...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-pluggy
Version : 0.3.0
Upstream Author : Holger Krekel
* URL : https://pypi.python.org/pypi/pluggy
* License : MIT
On May 12, 2015, at 06:53 PM, Ben Finney wrote:
While the package is marked “UNRELEASED”, putting a completed release
signature *in the VCS* is an arbitrary untruth. Untruths don't belong
in the VCS, is my position.
The interpretation of that signature line is at best ambiguous. Policy $4.4
Note that the problem isn't only in debchange. dpkg-buildpackage also seems
to suffer from unfinalized trailers:
$ bzr bd -S
Building using working tree
Building package in merge mode
Looking for a way to retrieve the upstream tarball
Upstream tarball already exists in build directory, using
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw ba...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-cachecontrol
Version : 0.11.2
Upstream Author : Eric Larson
* URL : https://pypi.python.org/pypi/CacheControl
* License
On May 03, 2015, at 02:28 PM, Matthias Klose wrote:
maintainership seems to be in good hands.
No questions there. Team maintainership is better in general because it
spreads the load and gives the maintainer some backup and consultation. It
also fosters collaboration across the wider Debian
Source: distlib
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
distlib is a dependency of pip. As such, it should really be
maintained as part of the Debian Python Modules Team, and managed
under the team's version control system. I would like to help
Package: python-lockfile
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
python-lockfile is a dependency of pip. As such, it should really be
maintained as part of the Debian Python Modules Team, and managed
under the team's version control system. I would
See also this PPA for possibly a start on the packaging:
https://launchpad.net/~nebc/+archive/ubuntu/bio-linux/+packages?field.name_filter=pythonfield.status_filter=publishedfield.series_filter=
pgpuduXtvU52R.pgp
Description: OpenPGP digital signature
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw ba...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-future
Version : 0.14.3
Upstream Author : Ed Schofield
* URL : https://python-future.org/
* License : MIT/X
Source: python-pex
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
Debian devendorizing of pkg_resources breaks pex because pex modifies
both sys.path and sys.modules. This causes pkg_resources to be
imported twice, once from the system and again from any
Let's keep an eye on PEP 488 - for Python 3.5, we're removing pyo files in
favor of aptly named __pycache__/*.pyc files. This will also have the benefit
of being able to support both -O and -OO optimizations at the same time.
https://www.python.org/dev/peps/pep-0488/
--
To UNSUBSCRIBE, email
ScottK and I discussed this and we agreed that the change is necessary, and
that the severity of this bug should be bumped to serious. We also need to
make a change to Debian Python Policy to more accurately reflect the
restriction on wheel files. I will handle both of these changes.
--
To
I have committed a fix for this to python-pip's svn and sent a message with
the relevant details to debian-python@. The bug and its fix are pretty
simple. Instead of only putting the .whl files early on sys.path when inside
a venv, we should be doing that in all cases. The only inside/outside
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw ba...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-pex
Version : 0.8.6
Upstream Author : Brian Wickman
* URL : https://pypi.python.org/pypi/pex
* License : Apache-2.0
On Jan 19, 2015, at 03:51 PM, W. Martin Borgert wrote:
I can confirm both the bug and the solution sent by Johannes. Barry, would
you fix this bug and ask for freeze exception? If not, I can try it, even if
my SVN knowledge is rusty :~(
It's not clear to me that such an exception would be
On Jan 18, 2015, at 11:48 PM, Kirill Smelkov wrote:
To me this whole let's bundle everything approach is only justified because
each package then could specify which version of dependencies to use
_exactly_.
I don't believe Debian packages are allowed to bundle packages that are also
available
Something else must still be going on. I have the following zope packages
installed:
% aptitude search zope | grep ^i
i python-zope.component - Zope Component Architecture
i python-zope.configuration - Zope Configuration Markup Language (ZCML)
i
On Dec 30, 2014, at 02:32 PM, Kirill Smelkov wrote:
Package: zope2.13
Version: 2.13.22-1
Severity: grave
Justification: renders package unusable
With zope2.13 I've tried to create a (user) instance and start it, but a
`SystemError: dynamic module not initialized properly` is raised while
zopectl
On Dec 28, 2014, at 11:48 PM, Ivo De Decker wrote:
On Sun, Dec 28, 2014 at 05:31:59PM -0500, Barry Warsaw wrote:
Would you please attach a debdiff against 4.1.1-3 so it's easier for me to
make sure that a future release from alioth vcs doesn't regress?
Sure. Attached.
Thanks, applied
On Dec 12, 2014, at 02:10 PM, Ben Finney wrote:
Name collision is one such problem that can reasonably be foreseen if
the package name is too generic for its purpose.
Perhaps. It's worth doing a search of existing FLOSS projects and see if
there are existing projects that could reasonably
Package: python-pip
Version: 1.5.6-4
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
When creating a virtual environment with virtualenv, the dependent
..whl files are copied into venv/lib/python-wheels/*.whl. This
allows pip inside such venvs to work.
On Dec 08, 2014, at 01:47 PM, Arnaud Fontaine wrote:
Arnaud Fontaine wrote (26 Nov 2014 09:03:09 GMT) :
Really sorry about that. FTR, I have not uploaded anything yet because
the release team would prefer to avoid the Conflicts if possible and
make python-zodb depends upon
On Dec 02, 2014, at 10:38 PM, Scott Kitterman wrote:
Speaking only for myself, I think that sounds reasonable.
It's well established I believe in Debian Python usage that if a user
installs packages in /usr/local and break their system, they are on their
own, so I'm not particularly worried
On Dec 03, 2014, at 03:20 PM, Piotr Ożarowski wrote:
IMO we should patch pip to *not* touch (install, upgrade, uninstall,
etc.) anything in /usr directory (or /) except /usr/local. Our Python
interpreter already installs to /usr/local and so should pip.
+1
This way:
* pip doesn't need to
For reference:
https://github.com/pypa/pip/issues/1668
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I hope you don't mind if I beat you to it? ;)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Nov 18, 2014, at 01:14 PM, Matthias Klose wrote:
I'm changing this now to use /var/lib/python-wheels, which is policy
conform. Please fix python-pip accordingly. From my point of view, this
should go into jessie.
Can you please elaborate on the section in Debian Policy used to justify this?
The weird package relationships are due to the interaction between historical
baggage, Debian Python policy, and the port of the cli to Python 3.
python-foo should only be for Python 2 compatible libraries, while python3-foo
is for the Python 3 compatible libraries. Back when python-virtualenv
On Nov 18, 2014, at 09:39 AM, Brian May wrote:
For another solution, have a look at django-admin, provided by the
django-common package. You can call it using any of the following ways:
brian@aquitard:~$ django-admin# run as sh; autodetect python
Yep, that autodetect is clever. Such a
It is not enough to remove /usr/lib/python-wheels in python3.4 and use a
tmpdir because pip (inside the venv) also needs to have the *.whl files on its
sys.path, otherwise its imports fail. pip would have to put all
/usr/share/python-wheels/*.whl on its sys.path (which I don't like). Or we
would
On Nov 13, 2014, at 12:41 PM, Holger Levsen wrote:
mapreri | h01ger: well, is there a pythonic way to preload library? :)
A *very* quick look at piuparts seems to show that the run() function is used
to run subprocesses from piuparts. You can even see where this function is
setting up the env
On Nov 12, 2014, at 05:50 PM, Arnaud Fontaine wrote:
From upstream point of view, ZODB3 (aka python-zodb in Debian) used to
include persistent, BTrees, ZODB and ZEO modules. However, since ZODB3
3.11.0a1, upstream has split it up into 4 distinct packages (one for
each module), bump the
I ran into this too while trying to reproduce locally bug #768286. I ended up
actually modifying /usr/sbin/piuparts to add --include=gcc as an option, which
is sub-optimal. I wonder if it makes sense to add an option to piuparts so
that additional options can be passed to debootstrap?
--
To
Source: genshi
Version: Re-enable genshi support for Python 3.4
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
We previously had to deliberately disable python3-genshi support for
Python 3.3 because upstream was not compatible. This was
implemented in the form of an
I recently uploaded pycurl 7.19.5-2, which is built against gnutls28 and I've
not been able to reproduce this bug. The url given in the example is no
longer valid (not surprisingly, since this is an *old* bug ;), but I've tried
several other https urls including:
* My launchpad page
*
Source: pycurl
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
Due to an upstream packaging bug, 7.19.5 didn't include the test
suite. This is fixed in upstream's vcs, so when a version with the
suite is released, I want to re-enable the tests.
However, the
See also: https://bugs.launchpad.net/ubuntu/+source/pycurl/+bug/1333672
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Could you please test again with pycurl 7.19.5-1? This new upstream version
is in unstable now and it is linked against gnutls28.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I think I just ran up against this same bug. I'm converting my Debian package
build workflow from pbuilder to sbuild and I have a custom
chroot-setup-commands. This has been working on Ubuntu (where I use sbuild
exclusive) for a long while, but now fails on Debian. I figure it has to be
the
Package: python-concurrent.futures
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
Upstream issue27 describes a test failure with PyPy. This also
affects i386 32 bit builds. In that case, the reprs include a
trailing 'L'. We see this in Ubuntu in FTBFS on
: Barry Warsaw ba...@debian.org
Date: Sat, 21 Jun 2014 18:44:45 -0400
Subject: Various fixes to get some semblance of the test suite passing at
package build time. This isn't perfect because tox's tests depend on tox
being built and installed - a catch 22. However, we can do a lot and there
are DEP
Package: git-dpm
Version: 0.8.5-1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
The manpage doesn't really document what --allow-nonlinear does. It
says:
--allow-nonlinear, --ignore-deletions, --dot-git-files=
Passed to update-patches, if called.
Package: git-dpm
Version: 0.8.5-1
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
Currently, update-patches emits d/patches files that start with a 4
digit number and a dash-separated list of words which are taken from
the first line of the Subject: header.
Package: git-dpm
Version: 0.8.5-1
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
git-dpm uses git tags of the style:
debian-1.7.1-3
patched-1.7.1-3
upstream-1.7.1
while gbp uses tags of the style:
debian/1.7.1-3
upstream/1.7.1
(gbp doesn't afaict tag the
Package: git-dpm
Version: 0.8.5-1
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
gbp has a command called `import-dscs` which takes a --debsnap option.
This is really wonderful in that it allows you to bootstrap a gbp-style git
repository for an existing
Package: git-dpm
Version: 0.8.5-1
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
gbp has a nice option that makes updating to a new upstream very
convenient: gbp import-orig --uscan
I'd love to have the same feature for git-dpm import-new-upstream! :)
-
On Sep 05, 2014, at 05:36 PM, Niko Tyni wrote:
Are you aware of the Patch-Name header? See #602272.
I wasn't; thanks for the pointer! However, now that I've read the
documentation and done some experimentation, it seems like it's not possible
to retrofit an existing git-dpm repo with
On Sep 05, 2014, at 07:24 PM, Bernhard R. Link wrote:
Could you check if after
git config --global dpm.debianTag 'debian/%e%v'
git config --global dpm.patchedTag 'debian/%e%v'
git config --global dpm.upstreamTag 'debian/%e%u'
A new repo and ran:
git config dpm.debianTag 'debian/%e%v'
git
On Sep 05, 2014, at 07:03 PM, Niko Tyni wrote:
This can be done by adding the headers to the commits on the patched branch.
Something like
git dpm checkout-patched
git commit --amend (or git rebase -i and reword all), add the header
git dpm update-patches
This works brilliantly, thanks!
My
I can think of a couple of things you could do instead.
* Run `python2 /usr/bin/tox -e docs`
* Add a `basepython=python2` to the [docs] section of your tox.ini
Would either one of those work? I'd really like to leave /usr/bin/tox as a
Python 3 script by default, and I'd like to not ship a
Quick follow up. You won't be able to name the executable /usr/bin/tox since
that collides with the Python testing framework. /usr/bin/tox-im is certainly
available though.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw ba...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: lazr.config
Version : 2.0
Upstream Author : lazr-develop...@lists.launchpad.net
* URL : http://launchpad.net/lazr.config
* License
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw ba...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: lazr.delegates
Version : 2.0
Upstream Author : lazr-develop...@lists.launchpad.net
* URL : http://launchpad.net/lazr.delegates
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw ba...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: lazr.smtptest
Version : 2.0.1
Upstream Author : lazr-us...@lists.launchpad.net
* URL : https://launchpad.net/lazr.smtptest
* License
On Aug 18, 2014, at 11:39 AM, Sandro Tosi wrote:
I'm raising the severity as 1.7.2 fixes the bug
https://bitbucket.org/hpk42/tox/issue/150/posargs-configerror which is
causing several issues in running OpenStack tests.
I started working on the new version before my recent vacation. Now that I'm
Here's a pull request to close this bug, and add some other packaging
improvements (lintian clean, etc.)
Cheers!
https://github.com/lamby/pkg-gunicorn/pull/14
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Package: gunicorn
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
Since upstream supports Python 3, it would be nice to have a Python 3
compatible gunicorn package in Debian. That probably means adopting
dh-python (for --buildsystem=pybuild) and perhaps even
Package: devscripts
Version: 2.14.5
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
Typical Emacs buffers use the 80th column for a wrap around glyph so
the effective width of wrapped lines is really 79 columns. If say
your Suggests line is exactly 80
On Jul 09, 2014, at 07:28 PM, James McCoy wrote:
What does “file --dereference --brief --mime-type
zope.browserpage-4.1.0a1.zip” show?
Looks like this is ultimately a bug in file 5.18, so right now only affects
Ubuntu:
% file --version
file-5.18
magic file from /etc/magic:/usr/share/misc/magic
Package: devscripts
Version: 2.14.5
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
I have a debian/watch file that points to a .zip on PyPI:
version=3
http://pypi.python.org/packages/source/z/zope.browserpage/zope.browserpage-(\d.*)\.(?:tar\.gz|zip)
Source: zope.security
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
In Ubuntu, the zope.security package has the following delta.
zope.security (3.8.3-2ubuntu1) precise; urgency=low
* Merge from Debian. Remaining changes:
- Add metapackage for
On Jul 01, 2014, at 05:24 PM, Brian Sutherland wrote:
The reason it was not added in Debian is because it requires the
RestrictedPython package:
https://pypi.python.org/pypi/RestrictedPython
That has security implications, and no-one wanted to take responsibility
for that.
I don't blame
Hi Gedminias!
As a side note, have you seen the discussion about folding the Debian Zope
team into the Debian Python team? Would you have any objection to that?
On Jul 01, 2014, at 07:49 PM, Gediminas Paulauskas wrote:
I've merged zope.security to Ubuntu a few times, keeping the delta.
The
We have to wait for python-persistent to clear NEW also.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw ba...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: python-persistent
Version : 4.0.8
Upstream Author : Zope Foundation and Contributors zope-...@zope.org
* URL : https://pypi.python.org
Source: zope.component
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
The zope.component build-time test suite introduces a circular
dependency with zope.security. Since both packages are having
python3-* versions added, I had to break the Build-Depends
I think it's better to prune the files in that directory from the orig
tarball, using a Files-Excluded header in d/copyright. The reason for this is
that, even though the package does not currently contain the documentation, if
it ever does, it's better to rebuild the docs from scratch using
Sorry about the bug mis-identification (I knew better).
On Jun 18, 2014, at 11:58 AM, Piotr Ożarowski wrote:
However, in almost all such cases, the binary package will Depend:
${python3:Depends} so that should be a good enough indication that
the binary package should get those
Package: python-nose-exclude
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
Upstream nose-exclude supports Python 3, but the Debian packaging does
not yet include a python3-nose-exclude package. I have a working
update to the package in my personal git repo.
On Jun 18, 2014, at 04:39 PM, Piotr Ożarowski wrote:
policy mentions that Python 2.X and Python 3.X are separate languages
for us and that's why we have python-foo and python3-foo packages.
I don't want APT to install python3 when I install python-foo and I
don't want APT to install python when I
On Jun 19, 2014, at 12:05 AM, Thomas Goirand wrote:
Thanks a lot for this work, this is very much appreciated.
You're welcome!
Unfortunately, I need to maintain a backport of nose-exclude in Wheezy,
and your patch is breaking it (log from the build on my (unclean) laptop):
File
Package: dh-python
Version: 1.20140511-1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
When applications (e.g. tox) are Python 3 scripts but are contained in
binary packages named python-foo instead of python3-foo, pybuild won't
apply Python 3 transformations
Are you reporting a packaging bug or an upstream bug? I ask because 1.7.1-1
doesn't explicitly set $HOME any more.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Jun 17, 2014, at 08:52 AM, Raphael Hertzog wrote:
(CCing Barry who expressed interested in python3-django as well)
I started a *very* minimal branch for adding Python 3 packaging to
python-django 1.6, although 1.6.5 is the latest on PyPI (and in Debian).
There's really not much to my branch
Source: zope.deprecation
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
The upstream tarball for zope.deprecation (as of 4.1.1) contains a
docs/_build directory with the pre-built html files. This is
generally unacceptable for Debian, where it's more
easy_install isn't the right way to install packages into the virtualenv
anymore. Please use pip, which should be installed in venv/bin
automatically now. I cannot reproduce the traceback you're seeing.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Package: virtualenvwrapper
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
With the upload of python-virtualenv 1.11.6-1, the binary packages
have been reorganized. The /usr/bin/virtualenv executable now lives
in the virtualenv binary package (whereas it
Package: dh-virtualenv
Version: Update Depends
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
With the upload of python-virtualenv 1.11.6-1, the binary packages
have been reorganized. The /usr/bin/virtualenv executable now lives
in the virtualenv binary
Source: tox
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Maintainer,
With the upload of python-virtualenv 1.11.6-1, the binary packages
have been reorganized. The /usr/bin/virtualenv executable now lives
in the virtualenv binary package (whereas it was in
201 - 300 of 576 matches
Mail list logo
