Bug#788697: Rebuild needed
Now that Bug#779324 is fixed, a simple rebuild would to fix the FTBFS. -- Gediminas
Bug#793319: FTBFS: ImportError: cannot import name component_re
Now that Bug#779324 is fixed, a simple rebuild would fix the problem.
2015-07-22 22:58 GMT+03:00 Chris West (Faux) solo-debianb...@goeswhere.com
:
Source: zope.sqlalchemy
Version: 0.6.1-2
Severity: serious
Tags: sid stretch
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Dear Maintainer,
The package fails to build:
pydeb: Working on python distribution zope.sqlalchemy
Traceback (most recent call last):
File /usr/bin/van-pydeb, line 9, in module
load_entry_point('van.pydeb==1.3.3', 'console_scripts', 'van-pydeb')()
File /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py, line
552, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py, line
2672, in load_entry_point
return ep.load()
File /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py, line
2345, in load
return self.resolve()
File /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py, line
2351, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File /usr/lib/python2.7/dist-packages/van/pydeb/__init__.py, line 20,
in module
from pkg_resources import component_re # Is this a public interface?
ImportError: cannot import name component_re
pydeb: Working on binary package
Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/zope.sqlalchemy.html
Probably related:
https://bugs.debian.org/788697
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.19.0-22-generic (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
___
pkg-zope-developers mailing list
pkg-zope-develop...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-zope-developers
--
Gediminas
Bug#767554: python-persistent and python-zodb: error when trying to install together
2014-11-14 11:43 GMT+02:00 Arnaud Fontaine ar...@debian.org: Barry Warsaw ba...@debian.org writes: 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 version to 4.0 and made ZODB3 a metapackage depending on all of them. It looks like Debian still has zodb 3.9.7, right? Unfortunately, yes. As of fixing this RC bug for Jessie: Among the four, only persistent package is currently available in Debian, so there is no way to get rid of ZODB3 (at least for Jessie). Barry: If persistent = 4.0 Debian package is useful on its own to anyone (and thus should not be removed From testing), then can I add a Conflict on both packages and upload them to fix this bug? IIRC, I needed to update python-persistent for the Python 3 zope.component transition, as it's a build-dep. There are no other reverse dependencies that I know of. I think a Conflicts is the right way to handle this for now, given where we are in the Jessie release cycle. Arnaud, thanks for handling this! If that's ok with you, I'm going to upload both packages to fix this bug: * python-persistent: Conflicts: python-zodb ( 3.11.0~) * python-zodb: Conflicts: python-persistent Since ZODB3 before the split included persistent, it should provide it: Provides: python-persistent One package that Build-Depends on python-persistent but should be installable with only python-zodb is zope.component. -- Gediminas
Bug#684560: [gaphor] gaphor requires python-setuptools
2012/8/25 Jakub Wilk jw...@debian.org: * Arnaud Fontaine ar...@debian.org, 2012-08-25, 17:05: After investigating a bit this issue, it seems that both zope.component and its requirement, zope.interface, does 'install_requires' setuptools because pkg_resources is required for zope namespace, but after install requires.txt ends up with setuptools. One solution would be to patch setup.py to remove the install_requires line for setuptools, but it will be required in a lot of packages, so I'm wondering if dh_python2 should handle that automatically or with a specific option? What do you think? Thanks! The current behviour of dh_python2 is IMHO errant. It should either 1) translate setuptools in requires.txt into dependency on python-setuptools or 2) remove setuptools from requires.txt when translating it into dependency on python-pkg-resources. dh_python2 does 2) for a year already: python-defaults (2.7.2-2) experimental; urgency=low [ Piotr Ożarowski ] * dh_python2: ... - remove setuptools from requires.txt (it is replaced with python-pkg-resources Debian dependency) ... Most likely the packages mentioned have not been rebuild since then. Or they use dh_pydeb (from python-van.pydeb) that does not remove setuptools from requires.txt Looking at the problem with other side: should setuptools be in requires.txt in the first place if the package uses only pkg_resources? pkg_resources is _the_ thing that checks these requirements after all. I mean, it's like adding dpkg to Depends because you can't install the package without dpkg... :) Most zope packages depend on setuptools. You are right that it is not really needed, but for historical reasons it is there upstream for many packages. -- Gediminas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
