Bug#893745: python-cffi: FTBFS on ia64: several test failures
Hi Aaron (2018.03.22_01:02:21_+0200) > Builds of python-cffi for ia64 (admittedly not a release architecture) > have been failing lately, per the below excerpts from [1]. > > Could you please take a look? python-cffi is pretty good at turning up libffi bugs, so presumably that's what this is. That said, I haven't looked into this, yet. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#882632: Bug #882632: libgit2: debian/copyright refers to CC0 by URL
Hi Nicolas (2018.01.14_11:07:19_-0800) > Please consider uploading a new version; I will take the liberty to do > a NMU if there is no reply within a week. I've sponsored an NMU to the delayed/0 queue, given there was several months of notice here. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#798148: new upstream available
Hi Aurelien (2016.06.01_07:23:41_+1000) I've been prodded by timvideos people to try to get an updated usb.ids in Debian. > Anyway I have uploaded the version 008 to experimental so that people > who really need the new version can use it. Is there anything still blocking this from unstable? I don't see any relevant open bugs. > Note that it poses additional issues: > - the udeb package doesn't work anymore as it can't access the systemd > database I see 1:009-2 dropped the udeb. Is the functionality still needed? > - some packages depends on usbutils to be able to access usb.ids. It is > not provided anymore in this version, so they will break. I'll try to > identify the affected packages and start to fill bugs. I guess this is the crux of the issue. I couldn't see any of those, if they've been filed, I guess they should have blocks on this. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#891087: beautifulsoup has been replaced by bs4
Source: beautifulsoup Severity: important We really should remove beautifulsoup, it has been replaced by bs4, many years ago. I've just been lazy, and haven't hassled consumers to migrate... This bug is for tracking the transition to bs4. SR
Bug#891090: archmage: python-beautifulsoup is replaced with python-bs4
Package: archmage Version: 1:0.3.1-3 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891094: calibre: python-beautifulsoup is replaced with python-bs4
Package: calibre Version: 3.17.0+dfsg-1 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891106: websploit: python-beautifulsoup is replaced with python-bs4
Package: websploit Version: 3.0.0-1 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891103: uicilibris: python-beautifulsoup is replaced with python-bs4
Package: uicilibris Version: uicilibris Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891102: python-tvrage: python-beautifulsoup is replaced with python-bs4
Package: python-tvrage Version: 0.4.1-1 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891105: webcheck: python-beautifulsoup is replaced with python-bs4
Package: webcheck Version: 1.10.4-1 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891107: geneagrapher: python-beautifulsoup is replaced with python-bs4
Package: geneagrapher Version: 1.0c2+git20120704-2 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891095: ibid: python-beautifulsoup is replaced with python-bs4
Package: ibid Version: 0.1.1+dfsg-4 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891100: gourmet: python-beautifulsoup is replaced with python-bs4
Package: gourmet Version: 0.17.4-5 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891096: planet-venus: python-beautifulsoup is replaced with python-bs4
Package: planet-venus Version: 0~git9de2109-4 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891101: python-pyth: python-beautifulsoup is replaced with python-bs4
Package: python-pyth Version: 0.6.0-1 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891097: python-freevo: python-beautifulsoup is replaced with python-bs4
Package: python-freevo Version: 1.9.2b2-4.3 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891098: python-gumbo: python-beautifulsoup is replaced with python-bs4
Package: python-gumbo Version: 0.10.1+dfsg-2.1 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891099: python-pattern: python-beautifulsoup is replaced with python-bs4
Package: python-pattern Version: 2.6+git20150109-2 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891093: guake-indicator: python-beautifulsoup is replaced with python-bs4
Package: guake-indicator Version: 1.1-2 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#891104: wapiti: python-beautifulsoup is replaced with python-bs4
Package: wapiti Version: 2.3.0+dfsg-6 Severity: important Control: block 891087 by -1 beautifulsoup version 4 was replaced as a new package, bs4, which has been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any maintenance since then. It's high time to remove it from the archive. Most code written against Beautiful Soup 3 will work against Beautiful Soup 4 with one simple change. All you should have to do is change the package name from BeautifulSoup to bs4, and depend on python-bs4 instead of python-beautifulsoup. There is some documentation on the migration here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4 Thanks, SR
Bug#881549: munkres: Please migrate away from Epydoc if possible
Hi Kenneth (2017.11.12_16:14:10_-0800) > If possible, please consider moving away from the use of Epydoc in your > package. Epydoc is basically unmaintained upstream. Also, it is only > supported for Python 2, so it will reach its end of life along with > Python 2 sometime in 2020. Upstream has migrated to something called pdoc, which seems to be an epydoc replacement that supports Python 3. https://github.com/BurntSushi/pdoc That's not currently packaged for Debian, so I'm just going to drop these docs, for now. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#891185: transition: re2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, re2 is C++ and likes to have transitions. Not many reverse-deps, though :) It's in experimental. I've test built the reverse-depends, and didn't see any new failures. I can't get chromium-browser to build before or after the transition, but presumably it's fine, Google would be targeting the latest re2 anyway. Reportbug Ben file: title = "re2"; is_affected = .depends ~ "libre2-3" | .depends ~ "libre2-4"; is_good = .depends ~ "libre2-4"; is_bad = .depends ~ "libre2-3"; https://release.debian.org/transitions/html/auto-re2.html Looks good, though. SR
Bug#904076: pypy: hurd support
Hi Samuel (2018.08.14_13:21:14_+0200) > > > Upstream has commited it. > > > > > > Could you upload these three patches to Debian so we can get all the > > > rdeps of pypy fixed? > > > > Here is the upstream version of the "hurd" patch. > > I have uploaded the upstream fixes, as attached to this mail, to DELAYED/5 Thanks! I'll supersede that with an upload that bundles in a bunch of other things I need to do. I didn't see any patch here adding platform data (DLFCN, CDROM, IN, TYPES). See for example https://bitbucket.org/pypy/pypy/src/29eab8b5cf205d791413edeee6ada18dde0cfe1f/lib-python/2.7/plat-linux2/?at=default Interestingly, I don't see this in our cpython package, either: https://sources.debian.org/src/python2.7/2.7.15-3/debian/patches/ They aren't widely used, I guess nobody noticed? SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#904521: pypy-py: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/pypy-py/examples/genhtml.py
> Any update on this bug?
Working on a solution. I'll filter /usr/share/doc in
pypy{clean,compile}.
And I'll add a temporary cleanup task to pypyclean that runs on only .py
files in /usr/share/doc, and ignores errors. We'll have to carry that
for some years, I think.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Bug#904521: pypy-py: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/pypy-py/examples/genhtml.py
Hi Niels (2018.08.16_15:03:27_-0700)
> > Any update on this bug?
>
> Working on a solution. I'll filter /usr/share/doc in
> pypy{clean,compile}.
My thinking there is that it never makes sense to byte-compile things in
/usr/share/doc. (Unless specifically requested, not using the -p flag).
Piotr: The same bug exists in the fallback code that dh_pypy generates,
e.g.
# Automatically added by dh_pypy:
if which pypycompile >/dev/null 2>&1; then
pypycompile -p pypy-py
elif pypy -m py_compile >/dev/null 2>&1; then
dpkg -L pypy-py | grep '\.py$' | pypy -m py_compile - >/dev/null
fi
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Bug#904076: pypy: hurd support
Hi Samuel (2018.08.15_08:08:44_-0700) > Thanks! I'll supersede that with an upload that bundles in a bunch of > other things I need to do. Uploaded. It needs to be bootstrapped (as it currently B-Ds on pypy on any-i386). Would you do that? Or should I upload a -3 with kfreebsd-i386 and i386 for now? SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#907332: ghostscript has a new code execution issue, even when used with -dSAFER
Control: tag -1 stretch > I was able to reproduce the issue on my system: Reproduced on stretch too. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#762346: RFP: pypy3 -- fast alternative implementation of Python3 - PyPy interpreter
Control: retitle -1 ITP: pypy3 -- fast alternative implementation of Python3 - PyPy interpreter Control: owner -1 stefa...@debian.org Yeah, I've had it mostly-packaged for a couple of years, just a couple more kinks to sort out... https://salsa.debian.org/debian/pypy3 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#630848: python-lazr.uri: E: namespace:119: cannot remove /usr/lib/python2.6/dist-packages/lazr/__init__.py
Control: reassign -1 python2-minimal Control: found -1 python2-minimal/2.7.15-3 Sorry, should have done this years ago... > Typical experimental amd64 system. Today I removed python-lazr.uri: > > | Removing python-lazr.uri ... > | E: namespace:119: cannot remove > /usr/lib/python2.6/dist-packages/lazr/__init__.py > | E: namespace:119: cannot remove > /usr/lib/python2.7/dist-packages/lazr/__init__.py If you install two packages in the lazr namespace, and then remove one of them, the __init__.py gets deleted. However, I don't think that actually breaks anything, just makes a noise. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#891098: python-gumbo: python-beautifulsoup is replaced with python-bs4
Control: tag -1 + patch
There's an upstream PR migrating to bs4
https://github.com/google/gumbo-parser/pull/368
Patch attached.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
diff -Nru gumbo-parser-0.10.1+dfsg/debian/control
gumbo-parser-0.10.1+dfsg/debian/control
--- gumbo-parser-0.10.1+dfsg/debian/control 2015-12-30 18:44:19.0
+
+++ gumbo-parser-0.10.1+dfsg/debian/control 2018-08-27 15:48:16.0
+0100
@@ -45,7 +45,7 @@
Architecture: all
Depends: ${misc:Depends}, ${shlibs:Depends}, ${python:Depends},
libgumbo1 (>= ${source:Version})
-Recommends: python-beautifulsoup, python-html5lib
+Recommends: python-bs4, python-html5lib
Description: pure-C HTML5 parser Python bindings
Gumbo is an implementation of the [HTML5 parsing algorithm implemented
as a pure C99 library with no outside dependencies. It's designed to serve
@@ -59,7 +59,7 @@
Architecture: all
Depends: ${misc:Depends}, ${shlibs:Depends}, ${python3:Depends},
libgumbo1 (>= ${source:Version})
-Recommends: python3-html5lib
+Recommends: python3-bs4, python3-html5lib
Description: pure-C HTML5 parser Python 3 bindings
Gumbo is an implementation of the [HTML5 parsing algorithm implemented
as a pure C99 library with no outside dependencies. It's designed to serve
diff -Nru gumbo-parser-0.10.1+dfsg/debian/patches/03-bs4.patch
gumbo-parser-0.10.1+dfsg/debian/patches/03-bs4.patch
--- gumbo-parser-0.10.1+dfsg/debian/patches/03-bs4.patch1970-01-01
01:00:00.0 +0100
+++ gumbo-parser-0.10.1+dfsg/debian/patches/03-bs4.patch2018-08-27
15:48:16.0 +0100
@@ -0,0 +1,178 @@
+From 29e1abb337af2a15ac4b38fb1c28d1b55ed08d54 Mon Sep 17 00:00:00 2001
+From: Roman Miroshnychenko
+Date: Tue, 19 Jul 2016 18:25:52 +0300
+Subject: [PATCH] Updates soup_adapter to use BeautifulSoup 4
+
+Also fixes the indentation according to PEP-8
+---
+ python/gumbo/soup_adapter.py | 123 +--
+ 1 file changed, 61 insertions(+), 62 deletions(-)
+
+diff --git a/python/gumbo/soup_adapter.py b/python/gumbo/soup_adapter.py
+index b18748f..6a247dd 100644
+--- a/python/gumbo/soup_adapter.py
b/python/gumbo/soup_adapter.py
+@@ -13,66 +13,65 @@
+ # limitations under the License.
+ #
+
+-"""Adapter between Gumbo and BeautifulSoup.
++"""Adapter between Gumbo and BeautifulSoup 4.
+
+-This parses an HTML document and gives back a BeautifulSoup object, which you
+-can then manipulate like a normal BeautifulSoup parse tree.
++This parses an HTML document and gives back a BeautifulSoup 4 object, which
you
++can then manipulate like a normal BeautifulSoup 4 parse tree.
+ """
+
+ __author__ = 'jdt...@google.com (Jonathan Tang)'
+
+-import BeautifulSoup
+-
++import bs4 as BeautifulSoup
+ import gumboc
+
+
+ def _utf8(text):
+- return text.decode('utf-8', 'replace')
++return text.decode('utf-8', 'replace')
+
+
+ def _add_source_info(obj, original_text, start_pos, end_pos):
+- obj.original = str(original_text)
+- obj.line = start_pos.line
+- obj.col = start_pos.column
+- obj.offset = start_pos.offset
+- if end_pos:
+-obj.end_line = end_pos.line
+-obj.end_col = end_pos.column
+-obj.end_offset = end_pos.offset
++obj.original = str(original_text)
++obj.line = start_pos.line
++obj.col = start_pos.column
++obj.offset = start_pos.offset
++if end_pos:
++obj.end_line = end_pos.line
++obj.end_col = end_pos.column
++obj.end_offset = end_pos.offset
+
+
+ def _convert_attrs(attrs):
+- # TODO(jdtang): Ideally attributes would pass along their positions as well,
+- # but I can't extend the built in str objects with new attributes. Maybe
work
+- # around this with a subclass in some way...
+- return [(_utf8(attr.name), _utf8(attr.value)) for attr in attrs]
++# TODO(jdtang): Ideally attributes would pass along their positions as
well,
++# but I can't extend the built in str objects with new attributes. Maybe
work
++# around this with a subclass in some way...
++return [(_utf8(attr.name), _utf8(attr.value)) for attr in attrs]
+
+
+ def _add_document(soup, element):
+- # Currently ignored, since there's no real place for this in the
BeautifulSoup
+- # API.
+- pass
++# Currently ignored, since there's no real place for this in the
BeautifulSoup
++# API.
++pass
+
+
+ def _add_element(soup, element):
+- # TODO(jdtang): Expose next/previous in gumbo so they can be passed along to
+- # BeautifulSoup.
+- tag = BeautifulSoup.Tag(
+- soup, _utf8(element.tag_name), _convert_attrs(element.attributes))
+- for child in element.children:
+-tag.append(_add_node(soup, child))
+- _add_source_info(
+- tag, element.original_tag, element.start_pos, element.end_pos)
+- tag.original_end_tag = str(element.original_end_tag)
+- return tag
++# TODO(jdtang): Expose next/previous in gumbo so they can be passed along
to
+
Bug#907398: src:python-pattern: Test suite isn't run at build time
Package: src:python-pattern Version: 2.6+git20150109-2 Severity: minor I see there is a test suite in the package, and some infrastructure for running it in debian/rules, but the run-tests task isn't run during the package build (or as an autopkgtest). Both of these would be a useful thing to do. SR
Bug#891099: python-pattern: python-beautifulsoup is replaced with python-bs4
Control: tag -1 + patch
Looks like upstream has mostly done this already, and just needs to cut
a new release...
https://github.com/clips/pattern/commit/25e88a3ab29cae04efed3205bd7f6ddcdf8b0ddc
https://github.com/clips/pattern/commit/1dffe92fd8606fdce7126e0b71947911af0c4feb
Patch attached.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
diff -Nru python-pattern-2.6+git20150109/debian/control
python-pattern-2.6+git20150109/debian/control
--- python-pattern-2.6+git20150109/debian/control 2016-05-12
21:26:36.0 +0100
+++ python-pattern-2.6+git20150109/debian/control 2018-08-27
14:30:22.0 +0100
@@ -4,7 +4,7 @@
Maintainer: Miriam Ruiz
Build-Depends:
debhelper (>= 9), quilt, python-all, python-setuptools, dh-python,
- python-liblinear, python-libsvm, python-feedparser, python-beautifulsoup,
+ python-liblinear, python-libsvm, python-feedparser, python-bs4,
python-simplejson, python-pdfminer, python-numpy, wordnet-base
Standards-Version: 3.9.8
X-Python-Version: >= 2.6
@@ -15,7 +15,7 @@
Package: python-pattern
Architecture: all
Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends},
- python-liblinear, python-libsvm, python-feedparser, python-beautifulsoup,
+ python-liblinear, python-libsvm, python-feedparser, python-bs4,
python-simplejson, python-pdfminer, python-numpy, wordnet-base
Description: web mining module for Python
Pattern is a web mining module for the Python programming language. It has
diff -Nru python-pattern-2.6+git20150109/debian/patches/bs4.patch
python-pattern-2.6+git20150109/debian/patches/bs4.patch
--- python-pattern-2.6+git20150109/debian/patches/bs4.patch 1970-01-01
01:00:00.0 +0100
+++ python-pattern-2.6+git20150109/debian/patches/bs4.patch 2018-08-27
14:30:11.0 +0100
@@ -0,0 +1,71 @@
+Description: Port to beautifulsoup4
+
+Author: Markus Beuckelmann
+Origin: upstream,
https://github.com/clips/pattern/commit/25e88a3ab29cae04efed3205bd7f6ddcdf8b0ddc
https://github.com/clips/pattern/commit/1dffe92fd8606fdce7126e0b71947911af0c4feb
+Bug-Debian: https://bugs.debian.org/891099
+
+--- a/pattern/web/__init__.py
b/pattern/web/__init__.py
+@@ -36,7 +36,7 @@
+ import locale
+
+ import feedparser
+-import BeautifulSoup
++import bs4 as BeautifulSoup
+
+ try:
+ # Import persistent Cache.
+--- a/test/test_web.py
b/test/test_web.py
+@@ -308,7 +308,9 @@
+ ( "text", "text\n\n"),
+ ( "text", "* text\n"),
+ ( "text", "text\t"),
+- ( "", "\n\n\n")):
++ ( "", "\n"),
++ ( "", "\n\n"),
++ ( "", "\n\n\n\n\n")):
+ self.assertEqual(web.strip_tags(html), plain)
+ # Assert exclude tags and attributes
+ v = web.strip_tags("text",
exclude={"a": ["href"]})
+@@ -749,17 +751,17 @@
+ # Assert Node properties.
+ v1 = web.Document(self.html)
+ self.assertEqual(v1.type, web.DOCUMENT)
+-self.assertEqual(v1.source[:10], "")
++self.assertEqual(v3.source, "html")
+ self.assertEqual(v1.head.type, web.ELEMENT)
+ self.assertEqual(v1.body.type, web.ELEMENT)
+ self.assertTrue(v1.head.source.startswith(").
+ a = v.by_class("comment")
+ self.assertEqual(a[0].tag, "p")
+-self.assertEqual(a[0].by_tag("span")[0].attributes["class"], "date")
+-self.assertEqual(a[0].by_tag("span")[1].attributes["class"], "author")
++self.assertEqual(a[0].by_tag("span")[0].attributes["class"], ["date"])
++self.assertEqual(a[0].by_tag("span")[1].attributes["class"],
["author"])
+ for selector in (".comment", "p.comment", "*.comment"):
+ self.assertEqual(v.by_tag(selector)[0], a[0])
+ # Assert Element.getElementById() (test ).
diff -Nru python-pattern-2.6+git20150109/debian/patches/series
python-pattern-2.6+git20150109/debian/patches/series
--- python-pattern-2.6+git20150109/debian/patches/series2016-05-12
21:18:38.0 +0100
+++ python-pattern-2.6+git20150109/debian/patches/series2018-08-27
14:27:44.0 +0100
@@ -5,3 +5,4 @@
remove-paypal.patch
fix-tests.patch
fix-examples.patch
+bs4.patch
Bug#891104: wapiti: python-beautifulsoup is replaced with python-bs4
Looks like upstream did this work already. https://sourceforge.net/p/wapiti/code/324/ It's fixed in recent upstream releases (e.g. 3.0.1). SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#825970: pypy: Please package pypy3 as well now
Hi Jeroen (2018.07.26_12:46:39_+0100) > > Python2 is dying. Is there any reason so that pypy3 shouldn't be > > compiled and uploaded? If you lack time and need help, please just ask. It's mostly been time, yes. > I'd also like to see pypy3 packaged. Is there already any work done on > packaging pypy3? If not then we should probably start with creating a > pypy3 source package based on the pypy2 packaging. I've had something mostly ready to go for a year or so :/ https://salsa.debian.org/debian/pypy3 amd64 builds: https://people.debian.org/~stefanor/pypy3/ (which I'll update with 6.0.0, shortly) The remaining issue that I know of, is figuring out a plan for byte-compilation. I'll bring it up on the debian-python list... SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#904040: openntpd: Apparmor denies logging
Package: openntpd
Version: 1:6.2p3-1
Severity: normal
Tags: patch
Can't reproduce this in a quick check in Debian, but I can see it on
Ubuntu 18.04 machines, and this patch does the trick.
AppArmor denies openntpd access to syslog:
> [1690592.258663] audit: type=1400 audit(1531921190.778:1052):
> apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected
> path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log"
> pid=2708 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
This seems to be a known issue with apparmor + systemd
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1373070
And the workaround is a patch like this (which has already been applied
to ntpd).
SR
diff -Nru openntpd-6.2p3/debian/apparmor-profile openntpd-6.2p3/debian/apparmor-profile
--- openntpd-6.2p3/debian/apparmor-profile 2017-10-31 17:44:20.0 -0700
+++ openntpd-6.2p3/debian/apparmor-profile 2018-07-18 10:01:06.0 -0700
@@ -1,7 +1,7 @@
# vim:syntax=apparmor
#include
-/usr/sbin/ntpd {
+/usr/sbin/ntpd flags=(attach_disconnected) {
#include
#include
Bug#895641: ITP: ruby-tomlrb -- A racc based toml parser
Package: wnpp Severity: wishlist Owner: Stefano Rivera <stefa...@debian.org> * Package name: ruby-tomlrb Version : 1.2.6 Upstream Author : Francois Bernier <frankbern...@gmail.com> * URL : https://github.com/fbernier/tomlrb * License : Expat Programming Lang: Ruby Description : A racc based toml parser A Racc based TOML Ruby parser supporting the 0.4.0 version of the spec. This is a dependency of the Chef stack. I intend to package it within the ruby team.
Bug#895638: ITP: ruby-iso8601 -- Ruby parser to work with ISO 8601 dateTimes and durations
Package: wnpp Severity: wishlist Owner: Stefano Rivera <stefa...@debian.org> * Package name: ruby-iso8601 Version : 0.10.1 Upstream Author : Arnau Siches * URL : https://github.com/arnau/ISO8601 * License : Expat Programming Lang: Ruby Description : Ruby parser to work with ISO 8601 dateTimes and durations ISO8601 is a simple implementation in Ruby of the ISO 8601 (Data elements and interchange formats - Information interchange - Representation of dates and times) standard.
Bug#895641: ITP: ruby-tomlrb -- A racc based toml parser
Hi Pirate (2018.04.14_07:44:39_+0200) > There is already a ruby-toml package, > https://tracker.debian.org/pkg/ruby-toml > > Can this be used instead? Yeah, I considered patching it to use that. But I think Chef recipes can reasonably assume that tomlrb is present, when Chef itself uses it. From what I see on the TOML wiki [0] the tomlrb library is in better shape that ruby-toml. I see an issue about merging the many ruby toml implementations [1], but crickets so far... [0]: https://github.com/toml-lang/toml/wiki [1]: https://github.com/jm/toml/issues/53 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#886456: python-pip: segfault when running 'pip install --upgrade ...'
Control: tags -1 moreinfo > I was trying to upgrade ansible (which I initially installed with pip). > The result was, that the program segfaulted. I tried this with --user and > without, but it makes no difference. Can you reproduce this failure? I can't. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#827568: marked as done (twine: please ship README)
Control: reopen -1 Bah. We have the HTML, but I would like to ship the RST too. Oh well, 1.11 is coming out next week, it can be fixed in that upload. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#891087: beautifulsoup has been replaced by bs4
Control: severity -1 serious > This bug is for tracking the transition to bs4. Time to raise this to RC, and let the testing autoremover do its job. I think most of the packages that are still actively maintained have been ported. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#901753: Invalid syntax error on startup
Control: forwarded -1 https://bitbucket.org/pypy/pypy/issues/2934/interactive-shell-imports-codepy-from Control: tag -1 upstream Hi Witold (2018.06.18_01:10:57_+0200) I've forwarded this upstream. This is caused by the "code.py" in your current directory, which the REPL is importing, instead of the stdlib "code" module. That's a pypy bug. However, naming a python script the same as an stdlib module is always going to be problematic. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#918501: transition: re2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition re2 is a C++ regex library, requiring about a transition a year, for various symbol changes. Only 6 reverse dependencies in testing. The automated ben file looks fine: https://release.debian.org/transitions/html/auto-re2.html I've uploaded to experimental and test-built all of the reverse-deps. No regressions in amd64 buildability of them. Everything that's in testing rebuilt without patching. Still waiting for some MIPS*el builds, but those could take weeks... And not expecting any new FTBFS - I've test-built them on the porterbox. reportbug ben file: title = "re3"; is_affected = .depends ~ "libre2-4" | .depends ~ "libre2-5"; is_good = .depends ~ "libre2-5"; is_bad = .depends ~ "libre2-4"; SR
Bug#918513: ITP: soupsieve -- A modern CSS selector implementation for BeautifulSoup
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: soupsieve Version : 1.6.2 Upstream Author : Isaac Muse * URL : https://github.com/facelessuser/soupsieve * License : MIT/Expat Programming Lang: Python Description : A modern CSS selector implementation for BeautifulSoup Soup Sieve is a CSS selector library designed to be used with Beautiful Soup 4 (python-bs4 in Debian). It aims to provide selecting, matching, and filtering using modern CSS selectors. Soup Sieve currently provides selectors from the CSS level 1 specifications up through the latest CSS level 4 drafts (though some are not yet implemented). Soup Sieve was written with the intent to replace Beautiful Soup's builtin select feature, and as of Beautiful Soup version 4.7.0, it now is . Soup Sieve can also be imported in order to use its API directly for more controlled, specialized parsing.
Bug#918501: transition: re2
Hi Emilio (2019.01.07_10:32:43_-0800) > Thanks, uploaded. I see dnsdist failed to binnmu on i386. I suspect this is a transient/intermittent test failure - it builds for me locally. Try a give-back? SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#918501: transition: re2
Hi Emilio (2019.01.07_19:05:02_+0200) > Go ahead. Thanks, uploaded. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#917572: RM: ibid -- ROM; unmaintained
Package: ftp.debian.org Severity: normal Time to get honest with myself, I stopped maintaining ibid upstream, almost immediately after getting it into Debian. And the rest of the upstream team did, too. If we get our act together again, we can bring it back, but ibid's looking pretty dead right now. SR
Bug#917575: RM: beautifulsoup -- ROM; Replaced by bs4
Package: ftp.debian.org Severity: normal Control: block -1 with 917572 All reverse-dependencies have migrated or been removed, see #891087. > $ dak rm -nR beautifulsoup > Will remove the following packages from unstable: > > beautifulsoup |3.2.1-1 | source > python-beautifulsoup |3.2.1-1 | all > > Maintainer: Debian Python Modules Team > > > --- Reason --- > > -- > > Checking reverse dependencies... > # Broken Depends: > guake-indicator: guake-indicator [hurd-i386] > ibid: ibid > > # Broken Build-Depends: > ibid: python-beautifulsoup > > Dependency problem found. guake-indicator was fixed in #891093, but hasn't built since on hurd. ibid RM is pending: #917572. SR
Bug#893743: python-cffi: FTBFS on hurd-i386: test_thread AssertionError
Control: severity -1 normal Control: retitle -1 locking issues on hurd cause test failure Control: forwarded -1 https://bitbucket.org/cffi/cffi/issues/383/test-fails-on-gnu-hurd-locking-issues I'm going to skip this test for now, but leave the bug open, until the underlying issue is resolved. This is a bug, but it's not critical for the vast majority of CFFI users, and we don't want to abort the build. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#925461: unblock: pypy/7.0.0+dfsg-3, backports.functools-lru-cache/1.5-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock pypy & backports.functools-lru-cache.
A relatively last-minute feature in pypy was namespace package support
(#920899). Unfortunately the path I picked isn't what dh_pypy (in
dh-python) implemented, and I think Piotr's rationale for that was
reasonable. But I didn't notice the incompatibility until after the
freeze.
So, #924676 and #924677.
debdiffs attached.
unblock pypy/7.0.0+dfsg-3
unblock backports.functools-lru-cache/1.5-3
Thanks,
SR
diff -Nru pypy-7.0.0+dfsg/debian/changelog pypy-7.0.0+dfsg/debian/changelog
--- pypy-7.0.0+dfsg/debian/changelog2019-02-12 17:41:21.0 -0500
+++ pypy-7.0.0+dfsg/debian/changelog2019-03-24 11:07:07.0 -0400
@@ -1,3 +1,12 @@
+pypy (7.0.0+dfsg-3) unstable; urgency=medium
+
+ * Update watch file regex, upstream calls it pypy2.7 now.
+ * pypycompile and pypyclean now read namespaces from /usr/share/pypy/ns
+(following dh_pypy). (Closes: #924676)
+- Breaks old pypy-backports.functools-lru-cache, using the old location.
+
+ -- Stefano Rivera Sun, 24 Mar 2019 11:07:07 -0400
+
pypy (7.0.0+dfsg-2) unstable; urgency=medium
* Remove dh_builddeb override, no longer necessary.
diff -Nru pypy-7.0.0+dfsg/debian/control pypy-7.0.0+dfsg/debian/control
--- pypy-7.0.0+dfsg/debian/control 2019-02-12 17:41:21.0 -0500
+++ pypy-7.0.0+dfsg/debian/control 2019-03-24 11:07:07.0 -0400
@@ -18,8 +18,8 @@
procps,
pypy [any-amd64 any-i386 armhf ppc64 ppc64el s390x] ,
python (>= 2.6.6-11~),
- python-pycparser,
python-docutils,
+ python-pycparser,
python-sphinx (>= 1.0.7+dfsg),
python2.7-dev,
tcl-dev,
@@ -36,7 +36,9 @@
Package: pypy
Architecture: any
Depends: pypy-lib (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
-Breaks: pypy-dev (<< ${source:Version})
+Breaks:
+ pypy-backports.functools-lru-cache (<< 1.5-3~),
+ pypy-dev (<< ${source:Version})
Provides: ${pypy-abi}
Suggests: pypy-doc, pypy-tk (= ${binary:Version})
Pre-Depends: dpkg (>= 1.15.6~), ${misc:Pre-Depends}
diff -Nru pypy-7.0.0+dfsg/debian/copyright pypy-7.0.0+dfsg/debian/copyright
--- pypy-7.0.0+dfsg/debian/copyright2019-02-12 17:41:21.0 -0500
+++ pypy-7.0.0+dfsg/debian/copyright2019-03-24 11:07:07.0 -0400
@@ -206,7 +206,7 @@
Floris Bruynooghe
Christopher Pope
Tristan Arthur
- Christian Tismer
+ Christian Tismer
Dan Stromberg
Carl Meyer
Florin Papa
diff -Nru pypy-7.0.0+dfsg/debian/pypy.dirs pypy-7.0.0+dfsg/debian/pypy.dirs
--- pypy-7.0.0+dfsg/debian/pypy.dirs2019-02-12 17:41:21.0 -0500
+++ pypy-7.0.0+dfsg/debian/pypy.dirs2019-03-24 11:07:07.0 -0400
@@ -1,2 +1,2 @@
+/usr/share/pypy/ns
/usr/local/lib/pypy2.7/dist-packages
-/usr/lib/pypy/ns
diff -Nru pypy-7.0.0+dfsg/debian/pypy.install
pypy-7.0.0+dfsg/debian/pypy.install
--- pypy-7.0.0+dfsg/debian/pypy.install 2019-02-12 17:41:21.0 -0500
+++ pypy-7.0.0+dfsg/debian/pypy.install 2019-03-24 11:07:07.0 -0400
@@ -2,5 +2,5 @@
debian/scripts/pypycompile/usr/bin
include/pypy_*.h /usr/lib/pypy/include
lib_pypy/_*_cffi.*.so /usr/lib/pypy/lib_pypy
-pypy/goal/pypy-c /usr/lib/pypy/bin
pypy/goal/libpypy-c.so/usr/lib/pypy/bin
+pypy/goal/pypy-c /usr/lib/pypy/bin
diff -Nru pypy-7.0.0+dfsg/debian/pypy.links pypy-7.0.0+dfsg/debian/pypy.links
--- pypy-7.0.0+dfsg/debian/pypy.links 2019-02-12 17:41:21.0 -0500
+++ pypy-7.0.0+dfsg/debian/pypy.links 2019-03-24 11:07:07.0 -0400
@@ -1,2 +1,2 @@
-/usr/lib/pypy/bin/pypy-c /usr/bin/pypy
/usr/lib/pypy/bin/libpypy-c.so /usr/lib/libpypy-c.so
+/usr/lib/pypy/bin/pypy-c /usr/bin/pypy
diff -Nru pypy-7.0.0+dfsg/debian/scripts/pypyclean
pypy-7.0.0+dfsg/debian/scripts/pypyclean
--- pypy-7.0.0+dfsg/debian/scripts/pypyclean2019-02-12 17:41:21.0
-0500
+++ pypy-7.0.0+dfsg/debian/scripts/pypyclean2019-03-24 11:07:07.0
-0400
@@ -31,7 +31,7 @@
def installed_namespaces():
'''Return a dictionary of package: frozenset(namespaces)'''
-ns_dir = '/usr/lib/pypy/ns'
+ns_dir = '/usr/share/pypy/ns'
ns_by_pkg = {}
for pkg in os.listdir(ns_dir):
ns_file = os.path.join(ns_dir, pkg)
diff -Nru pypy-7.0.0+dfsg/debian/scripts/pypycompile
pypy-7.0.0+dfsg/debian/scripts/pypycompile
--- pypy-7.0.0+dfsg/debian/scripts/pypycompile 2019-02-12 17:41:21.0
-0500
+++ pypy-7.0.0+dfsg/debian/scripts/pypycompile 2019-03-24 11:07:07.0
-0400
@@ -45,7 +45,7 @@
'''Iterate through a package's ns file.
Create all necessary__init__.pys, and yield them.
'''
-ns_file = os.path.join('/usr/lib/pypy/ns', package)
+ns_file = os.path.join('/usr/share/pypy/ns', package)
if not os.path.exists(ns_file):
return
with open(ns_file) as f:
diff -Nru py
Bug#922300: unblock: chef/13.8.7-3, ohai/13.8.0-1
Hi Release Team: > unblock chef/13.8.7-3 > unstable ohai/13.8.0-1 > OR > remove ruby-cheffish/13.1.0-2 I have a couple of packages that are part of the part of the chef stack and some were pulled out with it, through no fault of their own. So, I'd add to that, a unblock foodcritic/13.1.1-2 unblock ruby-knife-acl/1.0.3-2 Neither of those are critical to the maintenance of ci.debian.org, but they are of use to people managing Cheffed infrastructure, and don't have particularly high popcon or bug numbers. OR If we don't unblock the chef stack, can we also: remove chef-zero/13.1.0-2 It seems silly to keep it in the release, without chef. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#924676: pypy: Move namespace files to /usr/share/pypy/ns
Package: pypy Version: 6.0.0+dfsg-4 Severity: important When namespace support was added in 6.0.0+dfsg-4, we used /usr/lib/pypy/ns. However dh_pypy is not using that path, it's using /usr/share/pypy/ns (which matches where it puts pydist files). See: #920899 Let's sort this out before buster release, so we have an API we can live with for the future. SR
Bug#909379: segfault when leaving the python3-dbg interpreter
Hi Picca (2019.03.09_20:56:03_-0800) > I'm interested to hear about any API/ABI breakage in cffi modules, but I > just can't find the culprits, here. Sorry, was tired and closed the wrong clone of the bug. However, this bug is also no longer reproduceable, as mentioned in message 62 from Thomasz. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#920899: dh-python: Add namespace support to dh_pypy
Package: dh-python Version: 3.20180927 Severity: wishlist I'm adding namespace support to pypy in 6.0.0+dfsg-4. It's using /usr/lib/pypy/ns/ the same way as we do in Python 2. Packages using --namespace should create a file named after themselves in /usr/lib/pypy/ns/, naming the namespace. They shouldn't include __init__.py. They should probably gain a dependency on pypy (>= 6.0.0+dfsg-4). I'm doing all of this manually (without dh_pypy's help) in backports.functools-lru-cache. SR
Bug#918048: pypy: FTBFS (stage1) on x32, probably cpu64ilp32 issue
Tags: -1 upstream pypy hasn't been ported to x32, yet. In general it hasn't needed explicit porting to new platforms, when not using a JIT. But on x32, we've seen this issue, and it hasn't been deeply investigated. It's presumably some code assuming 64-bit system, and being wrong. This was visible before it started build-depending on itself on amd64-any (and thus x32) https://buildd.debian.org/status/fetch.php?pkg=pypy=x32=2.4.0%2Bdfsg-1=1411624326=0 Upstream has discussed x32 a few times in the past years, and if you look at the changelog (and upstream hg) you'll see a few commits from me and others trying to pick away at it. But I haven't touched it in a few years... Upstream's current stance is that x32 isn't supported (although it probably wouldn't be hard to support). SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#921170: soupsieve: FTBFS in sid (test_namespace_xml_with_namespace fails)
Hi Santiago (2019.02.02_15:47:56_+0100) Sorry, that was an undeclared versioned build-dependency. Try again with the latest python-bs4. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#918788: ImportError: No module named backports.functools_lru_cache
Control: tag -1 +unreproducible +moreinfo > Package: python-backports.functools_lru_cache > Version: 1.5-1 > -- System Information: > Debian Release: 9.5 > APT prefers stable > APT policy: (900, 'stable'), (500, 'stable-updates') > Architecture: amd64 (x86_64) Hrm. Given version 1.5-1 is not in stable and the package name was incorrect in this bug report, I'm guessing it was filed from a different system. Can you provide more information from the system you've seen this on? What version of python2.7 is present? Any other python-backports.* packages? I'd be interested in seeing the apt output for when the above packages were installed, /var/log/apt/term.log* I'm guessing you're missing /usr/lib/python2.7/dist-packages/backports/__init__.py If you sudo touch /usr/lib/python2.7/dist-packages/backports/__init__.py you should be able to get it back. But the question is why that happened to you. I can't reproduce this issue, so I can't find anything to fix. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#920899: closed by Piotr Ożarowski (Bug#920899: fixed in dh-python 3.20190307)
Control: reopen -1
Hi Debian (2019.03.07_13:51:28_-0800)
> It's using /usr/lib/pypy/ns/ the same way as we do in Python 2.
It's in /usr/lib/ not /usr/share/
I couldn't reasonably make pypy use /usr/ as it's prefix, without it
finding cPython libraries. So the whole of pypy is in /usr/lib/pypy/.
Patch attached.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
From e3e2f2dc8f693119ff40e5366d5bd9bc590eeffb Mon Sep 17 00:00:00 2001
From: Stefano Rivera
Date: Wed, 13 Mar 2019 14:50:37 -0700
Subject: [PATCH] Put pypy namespace files in the correct place:
/usr/lib/pypy/ns.
---
debian/changelog | 6 ++
dh_pypy | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index d29b1e4..2ac9ba6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+dh-python (3.20190313) UNRELEASED; urgency=medium
+
+ * Put pypy namespace files in the correct place: /usr/lib/pypy/ns.
+
+ -- Stefano Rivera Wed, 13 Mar 2019 14:47:03 -0700
+
dh-python (3.20190308) unstable; urgency=medium
* so2pyver: add a fallback to UTF-8 if locale.getdefaultlocale() returns None
diff --git a/dh_pypy b/dh_pypy
index b16487f..97bee8b 100755
--- a/dh_pypy
+++ b/dh_pypy
@@ -282,7 +282,7 @@ def main():
log.error('cannot remove __init__.py from package: %s', e)
exit(6)
if nsp:
-dstdir = join('debian', package, 'usr/share/pypy/ns/')
+dstdir = join('debian', package, 'usr/lib/pypy/ns/')
if not exists(dstdir):
os.makedirs(dstdir)
with open(join(dstdir, package), 'a', encoding='utf-8') as fp:
--
2.20.1
Bug#930536: unblock: distro-info-data/0.41
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package distro-info-data This is a pure-data package, tracking Debian and Ubuntu releases. As the release date is now known, it needs an update. Since the last update, the most recent Ubuntu release has also received an animal name, so that is included, too. unblock distro-info-data/0.41 Thanks, SR diff -Nru distro-info-data-0.40/debian/changelog distro-info-data-0.41/debian/changelog --- distro-info-data-0.40/debian/changelog 2019-04-23 12:14:38.0 -0700 +++ distro-info-data-0.41/debian/changelog 2019-06-14 10:50:04.0 -0700 @@ -1,3 +1,11 @@ +distro-info-data (0.41) unstable; urgency=medium + + * Add final animal name for Ubuntu 19.10 Eoan Ermine. + * Set release date for Buster (and matching creation date for Bullseye). +It has been announced. + + -- Stefano Rivera Fri, 14 Jun 2019 10:50:04 -0700 + distro-info-data (0.40) unstable; urgency=medium * Correct EOL date for trusty. (LP: #1825553) diff -Nru distro-info-data-0.40/debian.csv distro-info-data-0.41/debian.csv --- distro-info-data-0.40/debian.csv2019-04-23 12:14:38.0 -0700 +++ distro-info-data-0.41/debian.csv2019-06-14 10:50:04.0 -0700 @@ -13,8 +13,8 @@ 7,Wheezy,wheezy,2011-02-06,2013-05-04,2016-04-26 8,Jessie,jessie,2013-05-04,2015-04-25,2018-06-06 9,Stretch,stretch,2015-04-25,2017-06-17 -10,Buster,buster,2017-06-17 -11,Bullseye,bullseye,2019-08-01 +10,Buster,buster,2017-06-17,2019-07-06 +11,Bullseye,bullseye,2019-07-06 12,Bookworm,bookworm,2021-08-01 ,Sid,sid,1993-08-16 ,Experimental,experimental,1993-08-16 diff -Nru distro-info-data-0.40/ubuntu.csv distro-info-data-0.41/ubuntu.csv --- distro-info-data-0.40/ubuntu.csv2019-04-23 12:14:38.0 -0700 +++ distro-info-data-0.41/ubuntu.csv2019-06-14 10:50:04.0 -0700 @@ -29,4 +29,4 @@ 18.04 LTS,Bionic Beaver,bionic,2017-10-19,2018-04-26,2023-04-26 18.10,Cosmic Cuttlefish,cosmic,2018-04-26,2018-10-18,2019-07-18 19.04,Disco Dingo,disco,2018-10-18,2019-04-18,2020-01-18 -19.10,Eoan EANIMAL,eoan,2019-04-18,2019-10-17,2020-07-17 +19.10,Eoan Ermine,eoan,2019-04-18,2019-10-17,2020-07-17
Bug#922090: Missing eol-server info in ubuntu.csv
Hi Brian (2019.02.11_14:22:14_-0800) Sorry for not engaging in this sooner. Unfortunately, it missed Debian's freeze, and I've been trying to think about what I want to do about that... > The ubuntu.csv file is missing eol-server dates for multiple releases of > Ubuntu (likely because there is not a distinction between EoL dates for > server and desktop anymore), however this creates the following > confusing and misleading situation. > > (disco-amd64)root@impulse:~# ubuntu-distro-info --all -r --days=eol-server | > grep LTS > 6.06 LTS -2812 > 8.04 LTS -2104 > 10.04 LTS -1384 > 12.04 LTS (unknown) > 14.04 LTS (unknown) > 16.04 LTS (unknown) > 18.04 LTS (unknown) I'm not entirely convinced that your proposed solution is the right thing to do here. As there is no distinction between Desktop and Server EoLs any more, isn't "unknown" a better response? I don't have a particularly strong opinion here. But I'm looking at Debian Buster freeze, and I can't find the motivation to push this through there. > Additionally, I will be adding an another column to ubuntu.csv for ESM > support and having empty values for eol-server, with a new column after > it, ends up breaking ubuntu-distro-info. That's a bigger issue, because of the format change, of course. So when we resolve that in Debian, I'd like to include a new Debian LTS column (#782685) at the same time. In the mean-time, Debian and Ubuntu are going to be diverged, I guess :( SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#927819: unblock: distro-info-data/0.40
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package distro-info-data This is a pure data package. This upload contains two updates to Ubuntu data: 1. Ubuntu 19.04 has released, and we have a provisional entry for 19.10. There is no animal name for it, yet. But no idea when we're going to get that. 2. Correction to the Ubuntu 14.04 EOL. (and a noop standards-version update) The package is pointless without up-to-date data. When we have an idea of the Buster release date, we'll probably want to do another upload. That could be a post-release SPU, if absolutely necessary. unblock distro-info-data/0.40 diff --git a/debian/changelog b/debian/changelog index a3645af..5433f38 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +distro-info-data (0.40) unstable; urgency=medium + + * Correct EOL date for trusty. (LP: #1825553) + * Add Ubuntu 19.10, with a provisional animal name. (LP: #1825379) + * Bump Standards-Version to 4.3.0, no changes needed. + + -- Stefano Rivera Tue, 23 Apr 2019 12:14:38 -0700 + distro-info-data (0.39) unstable; urgency=medium * Add Ubuntu 19.04 Disco Dingo. (LP: #1800656) diff --git a/debian/control b/debian/control index 8505040..095e4c2 100644 --- a/debian/control +++ b/debian/control @@ -4,7 +4,7 @@ Priority: optional Maintainer: Benjamin Drung Uploaders: Stefano Rivera Build-Depends: debhelper (>= 9), python -Standards-Version: 4.1.4 +Standards-Version: 4.3.0 Vcs-Git: https://salsa.debian.org/debian/distro-info-data.git Vcs-Browser: https://salsa.debian.org/debian/distro-info-data Rules-Requires-Root: no diff --git a/ubuntu.csv b/ubuntu.csv index 1fb41a2..f35a640 100644 --- a/ubuntu.csv +++ b/ubuntu.csv @@ -18,7 +18,7 @@ version,codename,series,created,release,eol,eol-server 12.10,Quantal Quetzal,quantal,2012-04-26,2012-10-18,2014-05-16 13.04,Raring Ringtail,raring,2012-10-18,2013-04-25,2014-01-27 13.10,Saucy Salamander,saucy,2013-04-25,2013-10-17,2014-07-17 -14.04 LTS,Trusty Tahr,trusty,2013-10-17,2014-04-17,2019-04-17 +14.04 LTS,Trusty Tahr,trusty,2013-10-17,2014-04-17,2019-04-25 14.10,Utopic Unicorn,utopic,2014-04-17,2014-10-23,2015-07-23 15.04,Vivid Vervet,vivid,2014-10-23,2015-04-23,2016-01-23 15.10,Wily Werewolf,wily,2015-04-23,2015-10-22,2016-07-22 @@ -29,3 +29,4 @@ version,codename,series,created,release,eol,eol-server 18.04 LTS,Bionic Beaver,bionic,2017-10-19,2018-04-26,2023-04-26 18.10,Cosmic Cuttlefish,cosmic,2018-04-26,2018-10-18,2019-07-18 19.04,Disco Dingo,disco,2018-10-18,2019-04-18,2020-01-18 +19.10,Eoan EANIMAL,eoan,2019-04-18,2019-10-17,2020-07-17
Bug#936822: lazr.restfulclient: Python2 removal in sid/bullseye
Happy to remove, but there are reverse-dependencies: Reverse-Depends === * python-launchpadlib * ubuntu-dev-tools Reverse-Build-Depends = * python-launchpadlib SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#936824: lazr.uri: Python2 removal in sid/bullseye
Happy to remove, but there are still reverse-dependencies: Reverse-Depends === * python-launchpadlib * python-lazr.restfulclient * python-wadllib Reverse-Build-Depends = * python-wadllib SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937511: pypy: Python2 removal in sid/bullseye
user debian-pyt...@lists.debian.org usertags 937511 py2keep thanks PyPy is a Python 2 interpreter. It's useful for building PyPy3. It does this faster, and with less memory, than cPython on platforms that it has JIT for. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937510: pypy3: Python2 removal in sid/bullseye
user debian-pyt...@lists.debian.org usertags 937510 py2keep thanks The rpython source code of PyPy is Python 2. So, Python 2 sphinx is used for building autodoc. I haven't tried python 3 sphinx, it may work. The docs could also be omitted. However: Python 2.7 (cpython or pypy) is used for building pypy3. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#938254: python-wadllib: Python2 removal in sid/bullseye
Happy to remove. There are still reverse-dependencies: Reverse-Depends === * python-launchpadlib * python-lazr.restfulclient Reverse-Build-Depends = * python-launchpadlib SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937549: pystemmer: Python2 removal in sid/bullseye
Control: block 937549 with 938426 938528 883146 Happy to, but there are still a couple of reverse-deps: Reverse-Depends === * python-stemmer-dbg * sagemath [amd64 arm64 armhf i386 ppc64el] Reverse-Build-Depends-Indep === * sphinx Reverse-Build-Depends = * bzr * sagemath SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937639: python-cffi: Python2 removal in sid/bullseye
Control: block 937639 with 936262 937809 936555 937889 938195 938729 938622 936643 937499 937540 937602 937672 937784 937889 937937 938272 938273 938310 938840 Happy to, but there are many reverse-deps. Probably going to take a while to get them all ported. Reverse-Depends === * python-cairocffi * python-hidapi * python-ipalib * python-librtmp * python-ssdeep * python-twext * tahoe-lafs Reverse-Build-Depends = * cairocffi * gphoto2-cffi * hidapi-cffi * pyopenssl * pysoundfile * python-bcrypt * python-cryptography * python-gevent * python-librtmp * python-nacl * python-ssdeep * python-xattr * python-xeddsa * pyzmq * xcffib SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#938755: unidecode: Python2 removal in sid/bullseye
block 938755 with 937318 938044 thanks No objection, but there are reverse-deps: Reverse-Depends === * python-preggy * python-pretty-yaml Reverse-Build-Depends = * preggy * python-pretty-yaml SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#936196: webcheck: Python2 removal in sid/bullseye
Control: block 936196 with 934876 936153 936270 936596 936641 936790 936835 936973 937236 936678 937850 937965 937967 938006 934852 938575 938718 938816 939259 939260 There are quite a few reverse-dependencies that need to be removed first, and this library is quite popular in its own right. Reverse-Recommends == * gourmet * python-gumbo * python-lxml * python-pandas * python-seaborn * python-translate * webcheck * websploit Reverse-Depends === * archmage * calibre * geneagrapher * keysync * ledger-autosync * python-jenkinsapi * python-ofxclient * python-ofxparse * python-pattern * python-subliminal * python-webtest Reverse-Build-Depends-Indep === * ledger-autosync * translate-toolkit Reverse-Build-Depends = * aseba-plugin-blockly * calibre * geneagrapher * lxml * pandas * python-ofxclient * python-ofxparse * python-pattern * soupsieve SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#936325: configobj: Python2 removal in sid/bullseye
Control: block 936325 with 936221 936394 936460 938945 936996 937330 937336 937577 936237 883146 939024 938425 938623 938728 Happy to do that, but there are a good handful of reverse-deps: Reverse-Depends === * blueproximity * diamond * dynagen * gtg * mayavi2 * psychopy * puddletag * python-apptools * python-breezy * python-bzrlib * python-diamond * rabbitvcs-core * sabnzbdplus * tails-installer * turnin-ng Reverse-Build-Depends = * breezy * bzr * diamond * psychopy * python-apptools SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#938518: soupsieve: Python2 removal in sid/bullseye
Control: block 938518 with 936196 Happy to remove, but bs4 depends on it, and many things still depend on bs4. Reverse-Depends === * python-bs4 Reverse-Build-Depends = * beautifulsoup4 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#938249: python-virtualenv: Python2 removal in sid/bullseye
user debian-pyt...@lists.debian.org usertags 938249 + py2keep thanks I think we should keep virtualenv, as long a we have the interpreter. It definitely qualifies via popcon :P SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937411: pycparser: Python2 removal in sid/bullseye
user debian-pyt...@lists.debian.org usertags 937411 + py2keep thanks python-pycparser is needed to translate pypy and pypy3 on cPython. We do this when bootstrapping pypy, and on architectures that pypy doesn't have JIT support for. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937762: python-flexmock: Python2 removal in sid/bullseye
Control: block 937762 with 937232 938191 938676 Happy to, but there are some reverse-deps to deal with, first: Reverse-Depends === * paleomix Reverse-Build-Depends-Indep === * python-sqlalchemy-utils Reverse-Build-Depends = * paleomix * tomahawk SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937510: pypy3: Python2 removal in sid/bullseye
Hi 937510 (2019.08.31_10:24:30_-0300) > The rpython source code of PyPy is Python 2. So, Python 2 sphinx is used > for building autodoc. I haven't tried python 3 sphinx, it may work. Confirmed that it doesn't: Running Sphinx v1.8.5 Exception occurred: File "/<>/pypy3-7.1.1+dfsg/pypy/doc/config/generate.py", line 2, in from pypy.config import pypyoption, makerestdoc File "/<>/pypy3-7.1.1+dfsg/pypy/config/pypyoption.py", line 322 print config.getpaths() ^ SyntaxError: invalid syntax We could do work to make everything imported by sphinx, importable under python 3, but this isn't a use-case upstream needs to support, so I suspect we'd be the ones maintaining this. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937815: python-html2text: Python2 removal in sid/bullseye
Control: block 937815 with 936270 935358 Happy to remove, but there are reverse-deps: Reverse-Recommends == * sat-xmpp-core Reverse-Depends === * calibre Reverse-Build-Depends = * calibre SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#927147: requestsync: Please port to python3
Control: tag 927147 pending Thanks for the patch. I'm starting a python3 porting branch. And hope to finish it in a day or two. https://code.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/+git/ubuntu-dev-tools/+ref/python3 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#939457: lxml breaks beautifulsoup4 autopkgtest: a real XHTML didn't come out *exactly* the same as it went in
Hi Paul (2019.09.05_04:56:41_-0300) Fixed upstream in beautifulsoup4, upload incoming. https://bugs.launchpad.net/beautifulsoup/+bug/1840141 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#938168: python-setuptools: Python2 removal in sid/bullseye
user debian-pyt...@lists.debian.org usertags 938168 + py2keep thanks I think it would make sense to keep setuptools alive on 2.7 and pypy, until they are removed. And we need a python2.7 interpreter (ideally both cpython and pypy) to build pypy3. So, I suggest keeping these. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#931659: transition: rm python2
The current regex is using \bpython, which matches dh-python. I suggest this patch, using \s instead. Gets us down to 3455/4057. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 diff --git a/config/ongoing/python2-rm.ben b/config/ongoing/python2-rm.ben index ca4b33d..60d928c 100644 --- a/config/ongoing/python2-rm.ben +++ b/config/ongoing/python2-rm.ben @@ -1,6 +1,6 @@ title = "python2-rm"; notes = "Python 2 removal tracker (#931659)"; -is_affected = .depends ~ /\b(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)\b/ | .build-depends ~ /\b(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)\b/; -is_bad = .depends ~ /\b(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)\b/ | .build-depends ~ /\b(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)\b/; +is_affected = .depends ~ /\s(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)\b/ | .build-depends ~ /\s(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)\b/; +is_bad = .depends ~ /\s(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)\b/ | .build-depends ~ /\s(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)\b/; is_good = .depends ~ "''";
Bug#932821: pypy: Drop PyPy
Hi Ondřej (2019.07.23_13:43:02_-0300) > please drop the PyPy package, it's Python 2.7 based and unsupported. Gonna need PyPy / cpython2.7 to build PyPy3 (the source is Python 2.7). We use PyPy on archs that PyPy has JIT support for. It reduced memory usage and build time. The upstream is going to continue to build and support PyPy for the forseeable future. They aren't contemplating a port to python3, for the rpython side, yet. My understanding from the Python BoF was that we'd stop packaging random modules for pypy, but not that pypy would go away. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937815: [Python-modules-team] Processed: Bug#937815 marked as pending in python-html2text
Control: untag -1 pending Hi Sandro (2019.10.04_18:58:17_+0200) > there are still reverse dependencies: > http://sandrotosi.me/debian/py2removal/python-html2text_1.svg It's in a branch, not master. https://salsa.debian.org/python-team/modules/python-html2text/compare/master...python3 Upstream released a new version, it's py3, only. So, stuffed the new version in a "python3" branch to remind myself that it's not uploadable. So no, not *actually* pending. Let's revert the bot's work. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#950983: clickhouse FTBFS in bullseye/sid
Hi Jochen (2020.02.09_00:40:36_-0800) Control: tag -1 + patch I notice that Ubuntu has a patch for this: https://launchpadlibrarian.net/466815449/clickhouse_18.16.1+ds-5_18.16.1+ds-5ubuntu1.diff.gz It's building on amd64 and ppc64el: https://launchpad.net/ubuntu/+source/clickhouse/18.16.1+ds-5ubuntu1 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#938518: soupsieve: Python2 removal in sid/bullseye
Control: tags -1 - pending And there's a new upstream release, 2.0, that drops Python 2.7 support. I'll hold back on that, for now. But I'm somewhat tempted to fork the source package for it. But I'll wait a couple of months, and see if we get nearer being able to drop the 2.7 package. Ignore the pending tag. It's me pushing 2.0 into a branch. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#949656: apt-cacher-ng: Doesn't skip over IPv6-only mirrors as it used to
Package: apt-cacher-ng Version: 3.3.1-2 Severity: normal Since upgrading from 3.2-3 to 3.3.1-2, I couldn't do an "apt update" any more. It would 502 on the InRelease file. My backend configuration is: http://mirror.kardiogramm.net/debian/ http://deb.debian.org/debian/ The first one is my mirror at home, that is only available over IPv6. On IPv4-only networks, apt-cacher-ng used to just skip over this. Now it gets stuck on it. SR -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8), LANGUAGE=en_ZA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-cacher-ng depends on: ii adduser 3.118 ii debconf [debconf-2.0]1.5.73 ii dpkg 1.19.7 ii libbz2-1.0 1.0.8-2 ii libc62.29-9 ii libevent-2.1-7 2.1.11-stable-1 ii libevent-pthreads-2.1-7 2.1.11-stable-1 ii libgcc1 1:9.2.1-22 ii liblzma5 5.2.4-1+b1 ii libssl1.11.1.1d-2 ii libstdc++6 9.2.1-22 ii libsystemd0 244-3 ii libwrap0 7.6.q-30 ii lsb-base 11.1.0 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages apt-cacher-ng recommends: ii ca-certificates 20190110 Versions of packages apt-cacher-ng suggests: ii avahi-daemon 0.7-5 ii doc-base 0.10.9 ii libfuse2 2.9.9-2 -- Configuration Files: /etc/apt-cacher-ng/acng.conf changed: CacheDir: /var/cache/apt-cacher-ng LogDir: /var/log/apt-cacher-ng SupportDir: /usr/lib/apt-cacher-ng Remap-debrep: file:deb_mirror*.gz /debian ; file:backends_debian # Debian Archives Remap-uburep: file:ubuntu_mirrors /ubuntu ; file:backends_ubuntu # Ubuntu Archives Remap-cygwin: file:cygwin_mirrors /cygwin # ; file:backends_cygwin # incomplete, please create this file or specify preferred mirrors here Remap-sfnet: file:sfnet_mirrors # ; file:backends_sfnet # incomplete, please create this file or specify preferred mirrors here Remap-alxrep: file:archlx_mirrors /archlinux # ; file:backend_archlx # Arch Linux Remap-fedora: file:fedora_mirrors # Fedora Linux Remap-epel: file:epel_mirrors # Fedora EPEL Remap-slrep: file:sl_mirrors # Scientific Linux Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo # Gentoo Archives Remap-secdeb: security.debian.org /debian-security ; security.debian.org deb.debian.org/debian-security ReportPage: acng-report.html ExThreshold: 4 NetworkTimeout: 40 FastTimeout = 4 LocalDirs: acng-doc /usr/share/doc/apt-cacher-ng /etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: '/etc/apt-cacher-ng/security.conf' -- debconf information: apt-cacher-ng/proxy: keep apt-cacher-ng/port: keep apt-cacher-ng/bindaddress: keep * apt-cacher-ng/tunnelenable: false apt-cacher-ng/cachedir: keep apt-cacher-ng/gentargetmode: No automated setup
Bug#950672: hy: diff for NMU version 0.17.0-1.1
Control: tags 950672 + pending
Dear maintainer,
I've prepared an NMU for hy (versioned as 0.17.0-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
SR
diff -Nru hy-0.17.0/debian/changelog hy-0.17.0/debian/changelog
--- hy-0.17.0/debian/changelog 2019-08-19 18:21:26.0 -0700
+++ hy-0.17.0/debian/changelog 2020-02-04 08:40:08.0 -0800
@@ -1,3 +1,10 @@
+hy (0.17.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Support Python 3.8 (Closes: #950672)
+
+ -- Stefano Rivera Tue, 04 Feb 2020 08:40:08 -0800
+
hy (0.17.0-1) unstable; urgency=medium
* Update to 0.17.0 upstream release (Closes: #913044, #892264, #913048)
diff -Nru hy-0.17.0/debian/patches/py38.patch hy-0.17.0/debian/patches/py38.patch
--- hy-0.17.0/debian/patches/py38.patch 1969-12-31 16:00:00.0 -0800
+++ hy-0.17.0/debian/patches/py38.patch 2020-02-04 08:40:08.0 -0800
@@ -0,0 +1,53 @@
+Description: Support posonlyargs in Python 3.8
+Author: Kodi Arfer
+Author: Stefano Rivera
+Origin: upstream, https://github.com/hylang/hy/commit/ba9b0239c7fa2a02478e8456ed3867c6f2fec0c5
+Origin: upstream, https://github.com/hylang/hy/commit/36708e8e996700da256943b3e8162a29fa381473
+Bug-Debian: https://bugs.debian.org/950672
+
+--- a/hy/compiler.py
b/hy/compiler.py
+@@ -1145,7 +1145,7 @@
+ expr,
+ name=fname,
+ args=ast.arguments(
+-args=[], vararg=None, kwarg=None,
++args=[], vararg=None, kwarg=None, posonlyargs=[],
+ kwonlyargs=[], kw_defaults=[], defaults=[]),
+ body=f(parts).stmts,
+ decorator_list=[])
+@@ -1524,6 +1524,7 @@
+ args = ast.arguments(
+ args=main_args, defaults=defaults,
+ vararg=rest,
++posonlyargs=[],
+ kwonlyargs=kwonly, kw_defaults=kw_defaults,
+ kwarg=kwargs)
+
+--- a/hy/_compat.py
b/hy/_compat.py
+@@ -37,10 +37,12 @@
+ finally:
+ traceback = None
+
+-code_obj_args = ['argcount', 'kwonlyargcount', 'nlocals', 'stacksize',
++code_obj_args = ['argcount', 'posonlyargcount', 'kwonlyargcount', 'nlocals', 'stacksize',
+ 'flags', 'code', 'consts', 'names', 'varnames',
+ 'filename', 'name', 'firstlineno', 'lnotab', 'freevars',
+ 'cellvars']
++if not PY38:
++code_obj_args.remove("posonlyargcount")
+ else:
+ def raise_from(value, from_value=None):
+ raise value
+--- a/tests/native_tests/native_macros.hy
b/tests/native_tests/native_macros.hy
+@@ -391,7 +391,7 @@
+ ;; Now, let's use a `require`d macro that depends on another macro defined only
+ ;; in this scope.
+ (defmacro local-test-macro [x]
+-(.format "This is the local version of `nonlocal-test-macro` returning {}!" x))
++(.format "This is the local version of `nonlocal-test-macro` returning {}!" (int x)))
+
+ (assert (= "This is the local version of `nonlocal-test-macro` returning 3!"
+ (test-module-macro-2 3)))
diff -Nru hy-0.17.0/debian/patches/series hy-0.17.0/debian/patches/series
--- hy-0.17.0/debian/patches/series 2019-08-16 15:57:27.0 -0700
+++ hy-0.17.0/debian/patches/series 2020-02-04 08:15:19.0 -0800
@@ -1 +1,2 @@
hy-history.patch
+py38.patch
Bug#950767: postgresql-11-python3-multicorn: Underlinked when built with Python3.8 as default
Package: postgresql-11-python3-multicorn Version: 1.3.4-31-g9ff7875-2 Severity: normal Tags: upstream patch User: debian-pyt...@lists.debian.org Usertags: python3.8 FYI: The multicorn.so PostgreSQL plugin will not be linked to libpython when built under Python 3.8, without this patch: https://github.com/Kozea/Multicorn/pull/242 https://docs.python.org/3/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build says: > To embed Python into an application, a new --embed option must be > passed to python3-config --libs --embed to get -lpython3.8 (link the > application to libpython). To support both 3.8 and older, try > python3-config --libs --embed first and fallback to python3-config > --libs (without --embed) if the previous command fails. SR
Bug#950481: doit: diff for NMU version 0.31.1-3.2
Control: tags 950481 + pending
Dear maintainer,
I've prepared an NMU for doit (versioned as 0.31.1-3.2) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.
Regards.
SR
diff -Nru doit-0.31.1/debian/changelog doit-0.31.1/debian/changelog
--- doit-0.31.1/debian/changelog 2019-11-15 20:02:13.0 +0100
+++ doit-0.31.1/debian/changelog 2020-02-02 13:23:58.0 +0100
@@ -1,3 +1,10 @@
+doit (0.31.1-3.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Python 3.8 support. (Closes: #950481)
+
+ -- Stefano Rivera Sun, 02 Feb 2020 13:23:58 +0100
+
doit (0.31.1-3.1) unstable; urgency=high
* Non-maintainer upload.
diff -Nru doit-0.31.1/debian/patches/py38 doit-0.31.1/debian/patches/py38
--- doit-0.31.1/debian/patches/py38 1970-01-01 01:00:00.0 +0100
+++ doit-0.31.1/debian/patches/py38 2020-02-02 13:23:58.0 +0100
@@ -0,0 +1,32 @@
+Description: Fix tests under Python 3.8
+ Replace recursive knot with explicitly unpicklable object
+ .
+ Python 3.8 was able to pickle the previously unpicklable. Instead of relying
+ on limits, let's raise an explicit error.
+Bug-Upstream: https://github.com/pydoit/doit/issues/341
+Bug-Debian: https://bugs.debian.org/950481
+Forwarded: https://github.com/pydoit/doit/pull/350
+--- a/tests/test_runner.py
b/tests/test_runner.py
+@@ -577,17 +577,12 @@
+ t2 = pickle.loads(t1p)
+ assert 4 == t2.actions[0].py_callable()
+
+-@pytest.mark.xfail('PLAT_IMPL == "PyPy"') # pypy can handle it :)
+ def test_not_picklable_raises_InvalidTask(self):
+-# create a large enough recursive obj so pickle fails
+-d1 = {}
+-last = d1
+-for x in range(400):
+-dn = {'p': last}
+-last = dn
+-d1['p'] = last
+-
+ def non_top_function(): pass
++class Unpicklable:
++def __getstate__(self):
++raise pickle.PicklingError("DO NOT PICKLE")
++d1 = Unpicklable()
+ t1 = Task('t1', [non_top_function, (d1,)])
+ pytest.raises(InvalidTask, runner.JobTask, t1)
+
diff -Nru doit-0.31.1/debian/patches/series doit-0.31.1/debian/patches/series
--- doit-0.31.1/debian/patches/series 2019-11-15 19:59:07.0 +0100
+++ doit-0.31.1/debian/patches/series 2020-02-02 13:10:15.0 +0100
@@ -1,2 +1,3 @@
change-pytest-fixture-syntax.patch
fix-pytest-gte-4-0.patch
+py38
Bug#950481: src:doit: Tests fail on Python 3.8
Package: src:doit Version: 0.31.1-3.1 Severity: normal Tags: upstream patch Tests fail under Python 3.8 https://github.com/pydoit/doit/issues/341 I filed this PR upstream, and intend to upload it to Debian: https://github.com/pydoit/doit/pull/350 SR
Bug#950853: gffutils tests are timing out with Python 3.8
Control: tag -1 + patch Hi Matthias (2020.02.07_05:18:06_-0800) > gffutils tests are timing out with Python 3.8, while they succeed when run > with > 3.7. Currently only seen in an Ubuntu focal environment, however the upstream > sources don't mention 3.7 and 3.8 at all. I spent some time debugging this last week, and I *think* the cause is https://bugs.python.org/issue38501 This patch seems to avoid it: https://github.com/daler/gffutils/pull/155 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#940924: python3-rope: the license has been changed without the main author's consent
Control: tag -1 - sid Control: notfound -1 rope/0.14.0-1 Removing sid tag and version, to stop this from blocking unrelated changes from migrating to testing. 0.14 isn't in Debian yet, and Debian is still declaring the GPLv2+ license. This bug is about future versions. > As can be seen here[1], the license of this package has been changed from > GPL to LGPL without the consent of the main author. > > [1] https://github.com/python-rope/rope/pull/266 FWIW, there is no sign of objection, either. And his GH account does seem active. Many other projects have successfully relicensed without obtaining consent from every contributor. However, the vast majority of code here seems to be copyright Ali Gholami Rudi. If the Debian maintainer doesn't want to acknowledge this license change, an easy solution for Debian would be to treat this as being GPLv3 licensed. That is compatible with the original GPLv2, or later, license as well as subsequent LGPLv3 changes. > I don't know, if it is still relevant to keep this orphaned package in > Debian anymore. But yeah, if nobody is maintaining it, that's all moot. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#936505: faulthandler: Python2 removal in sid/bullseye
user debian-pyt...@lists.debian.org usertags 936505 + py2keep thanks This is built-in in Python 3, so no porting required. It can die with Python 2.7. But it's useful, as long as we have python2.7 in the archive, so I'm marking this py2keep. Happy to be overridden on that, if people want to be more aggressive. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937487: pynag: Python2 removal in sid/bullseye
Hi Matthias (2019.08.30_09:34:35_+0200) > - Convert your Package to Python3. This is the preferred option. In > case you are providing a Python module foo, please consider dropping > the python-foo package, and only build a python3-foo package. Please > don't drop Python2 modules, which still have reverse dependencies, > just document them. > > This is the preferred option. Team uploaded 1.1.2+dfsg-1 to experimental, with a new Python 3 package. The python 2 package is still there, because: Reverse-Depends * syslog-nagios-bridge (for python-pynag) (That's #945740) SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#914569: beets: zsh completion broken
Control: tag -1 +moreinfo +unreproducible Hi Clint (2018.11.25_05:15:04_+0200) > % beet import ../ > _beet:zregexparse:4: invalid regex : ) > (with zsh 5.6.2-3) Works for me, with zsh 5.7.1-1+b1. Something changed in zsh? Or something unusual about the directory you were in? SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#933775: dnsviz: diff for NMU version 0.8.0-1.1
Control: tags 933775 + patch
Control: tags 933775 + pending
Dear maintainer,
I've prepared an NMU for dnsviz (versioned as 0.8.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
While I was there, I did some bigger cleanup. You can find this all in
https://salsa.debian.org/stefanor/dnsviz
Regards.
SR
diff -Nru dnsviz-0.8.0/debian/changelog dnsviz-0.8.0/debian/changelog
--- dnsviz-0.8.0/debian/changelog 2019-02-04 02:46:32.0 +0200
+++ dnsviz-0.8.0/debian/changelog 2020-01-05 11:36:48.0 +0200
@@ -1,3 +1,11 @@
+dnsviz (0.8.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Switch to Python 3. (Closes: #933775)
+ * Build with pybuild.
+
+ -- Stefano Rivera Sun, 05 Jan 2020 11:36:48 +0200
+
dnsviz (0.8.0-1) unstable; urgency=medium
* New upstream version 0.8.0
diff -Nru dnsviz-0.8.0/debian/control dnsviz-0.8.0/debian/control
--- dnsviz-0.8.0/debian/control 2019-02-04 02:46:32.0 +0200
+++ dnsviz-0.8.0/debian/control 2020-01-05 11:36:48.0 +0200
@@ -7,11 +7,11 @@
debhelper (>= 9~),
dh-python,
inkscape,
- python (>= 2.7~),
- python-dnspython (>= 1.13.0~),
- python-libnacl,
- python-m2crypto (>= 0.28.0~),
- python-pygraphviz (>= 1.4~),
+ python3,
+ python3-dnspython (>= 1.13.0~),
+ python3-libnacl,
+ python3-m2crypto (>= 0.28.0~),
+ python3-pygraphviz (>= 1.4~),
Standards-Version: 4.3.0
Homepage: https://github.com/dnsviz/dnsviz
Vcs-Browser: https://salsa.debian.org/dns-team/dnsviz
@@ -21,7 +21,7 @@
Architecture: all
Depends:
${misc:Depends},
- ${python:Depends},
+ ${python3:Depends},
dns-root-data,
libjs-jquery,
libjs-jquery-ui,
diff -Nru dnsviz-0.8.0/debian/patches/debian-changes dnsviz-0.8.0/debian/patches/debian-changes
--- dnsviz-0.8.0/debian/patches/debian-changes 2019-02-04 02:46:32.0 +0200
+++ dnsviz-0.8.0/debian/patches/debian-changes 2020-01-05 11:36:48.0 +0200
@@ -36,43 +36,3 @@
def apply_substitutions(filename, install_prefix):
assert filename.endswith('.in'), 'Filename supplied for customization must end with \'.in\': %s' % (filename)
/dev/null
-+++ dnsviz-0.8.0/dnsviz/config.py
-@@ -0,0 +1,37 @@
-+#
-+# This file is a part of DNSViz, a tool suite for DNS/DNSSEC monitoring,
-+# analysis, and visualization.
-+# Created by Casey Deccio (ca...@deccio.net)
-+#
-+# Copyright 2014-2016 Verisign, Inc.
-+#
-+# Copyright 2016-2019 Casey Deccio
-+#
-+# DNSViz is free software; you can redistribute it and/or modify
-+# it under the terms of the GNU General Public License as published by
-+# the Free Software Foundation; either version 2 of the License, or
-+# (at your option) any later version.
-+#
-+# DNSViz is distributed in the hope that it will be useful,
-+# but WITHOUT ANY WARRANTY; without even the implied warranty of
-+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-+# GNU General Public License for more details.
-+#
-+# You should have received a copy of the GNU General Public License along
-+# with DNSViz. If not, see <http://www.gnu.org/licenses/>.
-+#
-+
-+from __future__ import unicode_literals
-+
-+import os
-+import sys
-+
-+if hasattr(sys, 'real_prefix'):
-+DNSVIZ_INSTALL_PREFIX = sys.prefix
-+else:
-+DNSVIZ_INSTALL_PREFIX = ''
-+DNSVIZ_SHARE_PATH = os.path.join(DNSVIZ_INSTALL_PREFIX, 'share', 'dnsviz')
-+JQUERY_PATH = 'file:///usr/share/javascript/jquery/jquery.min.js'
-+JQUERY_UI_PATH = 'file:///usr/share/javascript/jquery-ui/jquery-ui.min.js'
-+JQUERY_UI_CSS_PATH = 'file:///usr/share/javascript/jquery-ui-themes/redmond/jquery-ui.css'
-+RAPHAEL_PATH = 'file:///usr/share/javascript/raphael/raphael.min.js'
diff -Nru dnsviz-0.8.0/debian/rules dnsviz-0.8.0/debian/rules
--- dnsviz-0.8.0/debian/rules 2019-02-04 02:46:32.0 +0200
+++ dnsviz-0.8.0/debian/rules 2020-01-05 11:36:48.0 +0200
@@ -1,6 +1,6 @@
#!/usr/bin/make -f
%:
- dh $@ --with python2
+ dh $@ --with python3 --buildsystem pybuild
override_dh_auto_build:
$(MAKE) -C doc icons
Bug#953753: RM: foodcritic -- ROM; End of life upstream, replaced by chefstyle
Package: ftp.debian.org Severity: normal https://blog.chef.io/goodbye-foodcritic/ Given that, not going to bother packaging the latest version. SR
Bug#948895: neomutt: FTBFS: test failure
Control: reopen -1 Control: notfixed -1 20191207+dfsg.1-1 > This is fixed by: > https://github.com/neomutt/neomutt/commit/6a98d598bf0443516146c6a856b965f5e0fb35a1#diff-80e4b64ac703024c17f04c3d0d014e40 > > In other words updating to the latest release (20191207) would > fix this issue. That is just one of the failures here. Here's another one: https://github.com/neomutt/neomutt/commit/26a6b07c728aa88414057cff257cdebfd2967907 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#953757: neomutt: Occasional segfault on New Message (pager.c:2425)
Package: neomutt
Version: 20191207+dfsg.1-1
Severity: normal
Tags: patch upstream
Upstream issue https://github.com/neomutt/neomutt/issues/2038
Upstream patch: https://github.com/neomutt/neomutt/pull/2039
While reading a message, "New mail in this mailbox" appears and then *boom*.
gdb:
Program received signal SIGSEGV, Segmentation fault.
0x562c12c68ba2 in mutt_pager (banner=banner@entry=0x0, fname=, flags=flags@entry=66,
extra=extra@entry=0x7ffe04fe0130) at ../pager.c:2425
2425../pager.c: No such file or directory.
(gdb) p e
$1 = (struct Email *) 0x0
(gdb) bt
#0 0x562c12c68ba2 in mutt_pager
(banner=banner@entry=0x0, fname=, flags=flags@entry=66,
extra=extra@entry=0x7ffe04fe0130)
at ../pager.c:2425
#1 0x562c12c1f09a in mutt_display_message (win=,
m=0x562c134a5e90, e=e@entry=0x562c140620b0)
at ../commands.c:362
#2 0x562c12c3edaa in mutt_index_menu () at ../index.c:2512
#3 0x562c12c15371 in main (argc=, argv=0x7ffe04fe3868,
envp=) at ../main.c:1254
(gdb)
-- Package-specific info:
NeoMutt 20191207
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 5.4.0-3-amd64 (x86_64)
ncurses: ncurses 6.2.20200212 (compiled with 6.2.20200212)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
libnotmuch: 5.2.0
hcache backends: tokyocabinet
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu}
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss
--idn --mixmaster --sasl --tokyocabinet
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/neomutt-KUFXeJ/neomutt-20191207+dfsg.1=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
-autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens
+getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify
-locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime
-sqlite +start_color +sun_attachment +typeahead
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_ZA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages neomutt depends on:
ii libc6 2.29-10
ii libgnutls30 3.6.12-2
ii libgpg-error0 1.37-1
ii libgpgme111.13.1-6
ii libgssapi-krb5-2 1.17-6
ii libidn11 1.33-2.2
ii liblua5.3-0 5.3.3-1.1+b1
ii libncursesw6 6.2-1
ii libnotmuch5 0.29.3-1+b1
ii libsasl2-22.1.27+dfsg-2
ii libtinfo6 6.2-1
ii libtokyocabinet9 1.4.48-12
Versions of packages neomutt recommends:
ii libsasl2-modules 2.1.27+dfsg-2
ii locales 2.29-10
ii mime-support 3.64
Versions of packages neomutt suggests:
ii aspell 0.60.8-1
ii ca-certificates 20190110
ii gnupg 2.2.19-2
pn mixmaster
ii openssl 1.1.1d-2
ii postfix [mail-transport-agent] 3.4.9-1
pn urlview
Versions of packages neomutt is related to:
ii neomutt 20191207+dfsg.1-1
-- no debconf information
Bug#956412: pypy3: /usr/local/lib/pypy3.6/dist-packages/ not on sys.path
Package: pypy3 Version: 7.3.0+dfsg-4 Severity: normal sys.path isn't setup correctly for pypy3 to use locally installed modules. I don't think it ever has been, I just keep forgetting about it. Virtualenvs work, of course. SR
