[Python-modules-team] Bug#510901: python-foolscap: should advertise [secure_connections] feature to setuptools
I have updated the package in Debian-SVN now. Could you please check (and confirm) that this fixes the problem for you. If it does please let me know so I can get the updated package uploaded. I think that looks good.. I built a package from the current SVN debian/* files on a system with setuptools installed, and the Tahoe build process seems to be happy with the resulting .deb package. I don't know if you build the .deb yourself, or if it gets built by some automated process (pbuilder or something), but I assume that the new Build-Depends: item will ensure that setuptools is present during the build, which ought to be enough to fix this problem. I'll double-check once the official package is in sid. thanks! -Brian ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#786440: python-pip: pip is out-of-date, 'pip list' fails sometimes
Package: python-pip Version: 1.5.6-5 Severity: important I noticed that 'pip list' on my sid system failed, with a rather obscure error: Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/pip/basecommand.py, line 122, in main status = self.run(options, args) File /usr/lib/python2.7/dist-packages/pip/commands/list.py, line 80, in run self.run_listing(options) File /usr/lib/python2.7/dist-packages/pip/commands/list.py, line 142, in run_listing self.output_package_listing(installed_packages) File /usr/lib/python2.7/dist-packages/pip/commands/list.py, line 151, in output_package_listing if dist_is_editable(dist): File /usr/lib/python2.7/dist-packages/pip/util.py, line 367, in dist_is_editable req = FrozenRequirement.from_dist(dist, []) File /usr/lib/python2.7/dist-packages/pip/__init__.py, line 299, in from_dist assert len(specs) == 1 and specs[0][0] == '==' AssertionError After some digging, it turned out that the problem was that I have the 'python-pyhsm' package installed, which has a version string of 1.0.4k, and the extra k causes pkg_resources to return a spec that looks like === 1.0.4k (with three equal signs, not two), triggering the assert. Most packages have a normalized version string, for which pkg_resources emits a spec like == 1.0.0, which doesn't cause pip to complain. This was fixed in pip-6.0, which tolerates both == and ===. Sid currently has a pkg_resources that can emit ===, but not a pip that can tolerate it. This only shows up if you happen to have at least one python package installed with a non-normalized version string. For me, I was able to make pip work again by uninstalling python-pyhsm. I'm sure you're aware that sid's pip-1.5.6 is pretty out-of-date, and that 6.1.1 is the current version (https://pip.pypa.io/en/stable/news.html). It's not a trivial upgrade, for sure, but consider this note as supporting evidence in the campaign to get pip updated :). cheers, -Brian Steps To Reproduce: apt-get install python-pip python-pyhsm pip list Expected: a list of packages Got Instead: part of the list, then an exception with an AssertionError cheers, -Brian -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages python-pip depends on: ii ca-certificates 20141019 ii python2.7.9-1 ii python-colorama 0.3.3-1 ii python-distlib0.2.0-1 ii python-html5lib 0.999-3 ii python-pkg-resources 16.0-1 ii python-requests 2.4.3-6 ii python-setuptools 16.0-1 ii python-six1.9.0-3 pn python:anynone Versions of packages python-pip recommends: ii build-essential 11.7 pn python-dev-all none ii python-wheel 0.24.0-1 python-pip suggests no packages. -- no debconf information ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#795848: problem is fixed in the current release
I only recently heard about this.. we fixed that problem in the (current) foolscap-0.9.1 release, made on 21-Sep-2015. Upgrading to 0.9.1 ought to resolve this FTBFS. (there is a new problem that involves a bad interaction between foolscap-0.9.1 and twisted >=15.3.0, but for teh most part it only affects Tahoe-LAFS. I'm working on a new foolscap release that will resolve it, but I don't think that's cause to hold up putting foolscap-0.9.1 into sid). cheers, -Brian ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#830555: new Foolscap release available
I've just released foolscap-0.12.0 to PyPI, which should fix this. We've deprecated a function that talks to the root nameservers, and this release removes the test that used to exercise that function. I think that was the only place which should be doing off-box network access (there's plenty of localhost access, of course, this being a networking package). I hope that will resolve the issue. Please let me know if there's anything I can do to help get this packaged and (most importantly) the auto-removal of Foolscap and Tahoe-LAFS resolved. thanks! -Brian ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#830555: upstream ticket added
Ouch.. I didn't know it was doing this.. I'm guessing one of the tests is pinging the nameservers to exercise the "figure out my own IP address" function. I've filed a bug upstream to track down the offending test and change it: https://foolscap.lothar.com/trac/ticket/263 I'll try to address that soon. We have a new release in the works, should be done in a few weeks. I know that Tahoe-LAFS is marked for autoremoval from testing on Aug 22nd because of this, and I really don't want that to happen :-). cheers, -Brian ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#877206: new release is available, should fix this
I just released foolscap-0.13.0, which ought to fix this.. let me know if you see any problems, or if I can help with getting it into debian/ubuntu before the package gets removed. Thanks! ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#877206: working on a fix
(upstream author here) Sorry folks, I didn't realize this problem was so bad. I haven't seen a bug filed about this on https://foolscap.lothar.com/trac/ or https://github.com/warner/foolscap/issues , but I just saw email from the Ubuntu bugtracker because I'm subscribed to Tahoe-LAFS changes, and the FTBFS bug is threatening to remove Tahoe too (because of the dependency). When I checked my nightly buildbot job, it looks like the problem has been happening since exactly the Twisted-17.9.0 release, but I hadn't noticed (I don't have any sorts of notifications on that buildbot). It hasn't been affecting our Tahoe unit tests. Let me see if I can find a fix this weekend, and make a new release. It looks like Failures are no longer pickleable, which we do in a logging routine that's exercised by those tests. I've been meaning to replace that logging with a JSON-based serialization scheme.. I guess it's time to accelerate that project. cheers, -Brian ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
