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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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
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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#885454: closed by Holger Levsen <hol...@debian.org> (Bug#885454: fixed in munin 2.0.34-2)
Control: reopen -1
Control: notfixed 2.0.34-2
>* Partly revert f1f48dee so that directories are again setup correctly
> on initial installations. (Closes: #885454)
You did that for munin, but not munin-node or munin-async.
I suggest this patch.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
From e129c85f209e903db10827642110b831424422a0 Mon Sep 17 00:00:00 2001
From: Stefano Rivera <stefa...@debian.org>
Date: Thu, 10 May 2018 23:14:14 -0700
Subject: [PATCH] Revert more of f1f48dee so that directories are again setup
correctly on initial installations of munin-node and munin-async. (Closes:
#885454)
---
debian/changelog| 2 ++
debian/munin-async.postinst | 7 +++
debian/munin-node.postinst | 11 +++
3 files changed, 20 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 7ac9f6a8..905c6753 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,8 @@
munin (2.0.37-2) UNRELEASED; urgency=medium
* Bump Standards-Version: to 4.1.4, no changes needed.
+ * Revert more of f1f48dee so that directories are again setup correctly on
+initial installations of munin-node and munin-async. (Closes: #885454)
-- Holger Levsen <hol...@debian.org> Thu, 05 Apr 2018 17:47:11 +
diff --git a/debian/munin-async.postinst b/debian/munin-async.postinst
index a940e507..cf104824 100644
--- a/debian/munin-async.postinst
+++ b/debian/munin-async.postinst
@@ -15,9 +15,16 @@ add_munin_async_user() {
fi
}
+initperms() {
+ chown munin-async:munin-async /var/lib/munin-async
+}
+
case "$1" in
configure)
add_munin_async_user
+ if [ -z "$2" ]; then
+ initperms
+ fi
;;
abort-upgrade|abort-deconfigure|abort-remove)
:
diff --git a/debian/munin-node.postinst b/debian/munin-node.postinst
index 845e9424..4f54d6f9 100644
--- a/debian/munin-node.postinst
+++ b/debian/munin-node.postinst
@@ -4,6 +4,14 @@ set -e
prevver="$2"
+initperms() {
+ chown munin:adm /var/log/munin
+ chmod 755 /var/log/munin
+
+ chown root:munin /etc/munin/plugin-conf.d
+ chmod 750 /etc/munin/plugin-conf.d
+}
+
init_plugins() {
TMPFILE=`mktemp /tmp/munin-node.configure.XX`
TMPFILE_STDERR=`mktemp /tmp/munin-node.configure.err.XX`
@@ -41,6 +49,9 @@ init_plugins() {
case "$1" in
configure)
+ if [ -z "$2" ]; then
+ initperms
+ fi
init_plugins
;;
triggered)
--
2.17.0
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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#864076: unblock: distro-info-data/0.36
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package distro-info-data This is a pre-upload unblock request for distro-info-data, now that the Jessie release date has been announced. While I was here, I realised that we didn't have EOL dates for Jessie or Wheezy yet :( We have a long-standing bug of not including LTS dates (#782685) so I've maintained the status-quo and did that for these two as well. Alternatively, I could just extend the support dates out to include LTS, but that seems like another bad idea :/ So, are you OK with this patch-set, and would you consider allowing it in, for Stretch? unblock distro-info-data/0.36 Thanks, SR diff --git a/debian.csv b/debian.csv index c1f0962..b476031 100644 --- a/debian.csv +++ b/debian.csv @@ -10,10 +10,10 @@ version,codename,series,created,release,eol 4.0,Etch,etch,2005-06-06,2007-04-08,2010-02-15 5.0,Lenny,lenny,2007-04-08,2009-02-14,2012-02-06 6.0,Squeeze,squeeze,2009-02-14,2011-02-06,2014-05-31 -7,Wheezy,wheezy,2011-02-06,2013-05-04 -8,Jessie,jessie,2013-05-04,2015-04-25 -9,Stretch,stretch,2015-04-25 -10,Buster,buster,2018-07-01 +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,2020-11-05 ,Sid,sid,1993-08-16 ,Experimental,experimental,1993-08-16 diff --git a/debian/changelog b/debian/changelog index cec721c..130df23 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,14 @@ +distro-info-data (0.36) UNRELEASED; urgency=medium + + * Set EOL date for Debian Wheezy. This excludes LTS, which we haven't +supported in distro-info yet, for Debian, but matches what we did for +Squeeze. + * Set (provisional) EOL date for Debian Jessie. + * Set release date for Stretch (and matching creation date for Buster). It +has been announced. + + -- Stefano Rivera <stefa...@debian.org> Sat, 03 Jun 2017 18:07:40 -0700 + distro-info-data (0.35) unstable; urgency=medium * Correct Ubuntu Zesty release date.
Bug#858096: [mate-panel?] Mate panel unstable, notification area icons disappear without warning
Control: severity -1 normal > I have been doing some more on this issue, even though it appears no one > else is interested, and have found that it happens when the panel properties > > background is changed from "None (use system theme" to "Solid colour" and > the style is adjusted to make the panel transparent. If the panel is left > Opaque the icons stay as they should but any transparency causes the icons > to disappear. Yep. I can reproduce that. And I don't think it qualifies as an RC bug, it is easily worked around. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#860864: unblock: distro-info-data/0.35
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package distro-info-data Ubuntu 17.04 has now released, and we need to add 17.10. Of course there will still need to be one more update of distro-info-data once stretch has a release date (that could be after the release). unblock distro-info-data/0.35 Thanks, SR diff -Nru distro-info-data-0.33/debian/changelog distro-info-data-0.35/debian/changelog --- distro-info-data-0.33/debian/changelog 2017-01-15 15:53:52.0 -0800 +++ distro-info-data-0.35/debian/changelog 2017-04-20 19:43:47.0 -0700 @@ -1,3 +1,15 @@ +distro-info-data (0.35) unstable; urgency=medium + + * Correct Ubuntu Zesty release date. + + -- Stefano Rivera <stefa...@debian.org> Thu, 20 Apr 2017 19:43:47 -0700 + +distro-info-data (0.34) unstable; urgency=medium + + * Add Ubuntu 17.10, Artful Aardvark. + + -- Stefano Rivera <stefa...@debian.org> Thu, 20 Apr 2017 16:42:23 -0700 + distro-info-data (0.33) unstable; urgency=medium * Add Debian 11 codename (with provisional creation date) (Closes: #851447) diff -Nru distro-info-data-0.33/ubuntu.csv distro-info-data-0.35/ubuntu.csv --- distro-info-data-0.33/ubuntu.csv2016-10-21 15:48:30.0 -0700 +++ distro-info-data-0.35/ubuntu.csv2017-04-20 19:43:47.0 -0700 @@ -24,4 +24,5 @@ 15.10,Wily Werewolf,wily,2015-04-23,2015-10-22,2016-07-22 16.04 LTS,Xenial Xerus,xenial,2015-10-22,2016-04-21,2021-04-21 16.10,Yakkety Yak,yakkety,2016-04-21,2016-10-13,2017-07-20 -17.04,Zesty Zapus,zesty,2016-10-13,2017-04-20,2018-01-25 +17.04,Zesty Zapus,zesty,2016-10-13,2017-04-13,2018-01-25 +17.10,Artful Aardvark,artful,2017-04-13,2017-10-19,2018-07-19
Bug#855555: unblock: hdmi2usb-fx2-firmware/0.0.0~git20151225-1
Control: tags -1 - moreinfo > How soon can we have confirmed whether this upload fixes the issue with > Numato Opsis boards? If we unblock this, I would like to know it at > least fixes the issue we are unblocking it for. It works. I confirmed this yesterday, and with the package, as built in the archive, this morning. Thanks CarlFK for hooking up an Opsis for me :) SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#855555: unblock: hdmi2usb-fx2-firmware/0.0.0~git20151225-1
2 @@ install: - # Install sdcc - sudo apt-get install --force-yes -y sdcc - sdcc --version + - # doxygen & rubber are needed for generating the documentation + - sudo apt-get install -y doxygen rubber script: - make + - make docs + +after_success: + - ./.travis-push-docs.sh diff --git a/debian/changelog b/debian/changelog index 3541a3a..82797f3 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,4 +1,12 @@ -hdmi2usb-fx2-firmware (0.0.0~git20151018-1) unstable; urgency=low +hdmi2usb-fx2-firmware (0.0.0~git20151225-1) UNRELEASED; urgency=low + + * New upstream release (different git branch) +- Should actually build a working uart firmware for the opsis. + (Closes: #855548) + + -- Stefano Rivera <stefa...@debian.org> Mon, 28 Nov 2016 23:35:19 -0800 + +hdmi2usb-fx2-firmware (0.0.0~git20151128-1) unstable; urgency=low * Initial upload. (Closes: #796769) diff --git a/debian/rules b/debian/rules index c4f2158..152525d 100755 --- a/debian/rules +++ b/debian/rules @@ -4,12 +4,13 @@ dh $@ VER=$(shell dpkg-parsechangelog | sed -rne 's/^Version: (.+)-.*/\1/p') +BRANCH=opsis-uart-with-eeprom-serialno get-packaged-orig-source: - git clone https://github.com/mithro/fx2lib -b cdc-usb-serialno-from-eeprom + git clone https://github.com/mithro/fx2lib -b $(BRANCH) set -xe; \ GIT_DATE=$$(dpkg-parsechangelog | sed -rne 's/^Version: .*\~git()(..)(..)-.*/\1-\2-\3 00:00:00 UTC/p'); \ cd fx2lib; \ - GIT_COMMIT=$$(git rev-list -n1 --until="$$GIT_DATE" cdc-usb-serialno-from-eeprom); \ + GIT_COMMIT=$$(git rev-list -n1 --until="$$GIT_DATE" $(BRANCH)); \ git archive $$GIT_COMMIT --prefix=hdmi2usb-fx2-firmware_$(VER).orig/ \ -o ../hdmi2usb-fx2-firmware_$(VER).orig.tar xz -f hdmi2usb-fx2-firmware_$(VER).orig.tar diff --git a/examples/cdc/Makefile b/examples/cdc/Makefile index 57cb825..e9b579c 100644 --- a/examples/cdc/Makefile +++ b/examples/cdc/Makefile @@ -1,4 +1,4 @@ -DIRS=to-uart +DIRS=loopback to-uart .PHONY: dirs $(DIRS) clean diff --git a/examples/cdc/common/dscr.a51 b/examples/cdc/common/dscr.a51 index 285d9f9..533d5ec 100644 --- a/examples/cdc/common/dscr.a51 +++ b/examples/cdc/common/dscr.a51 @@ -42,7 +42,8 @@ ENDPOINT_TYPE_ISO=1 ENDPOINT_TYPE_BULK=2 ENDPOINT_TYPE_INT=3 -.globl _dev_dscr, _dev_qual_dscr, _highspd_dscr, _fullspd_dscr, _dev_strings, _dev_strings_end, _dev_serial +.globl _dev_dscr, _dev_qual_dscr, _highspd_dscr, _fullspd_dscr, _dev_strings, _dev_strings_end +.globl _dev_serial ; These need to be in code memory. If ; they aren't you'll have to manully copy them somewhere ; in code memory otherwise SUDPTRH:L don't work right @@ -57,9 +58,9 @@ _dev_dscr: .db 0x00 ; 5 bDeviceSubclass 1 Subclass code .db 0x00 ; 6 bDeviceProtocol 1 Protocol Code .db 64; 7 bMaxPacketSize0 1 Maximum packet size for endpoint zero - .dw 0xB404; 8 idVendor 2 Vendor ID - .dw 0x0410; 10 idProduct 2 Product ID - .dw 0x0100; 12 bcdDevice 2 Device release number (BCD) + .dw 0x192A; 8 idVendor 2 Vendor ID + .dw 0x4154; 10 idProduct 2 Product ID + .dw 0x0300; 12 bcdDevice 2 Device release number (BCD) .db 1 ; 14 iManufacturer 1 Index of string descriptor for the manufacturer .db 2 ; 15 iProduct 1 Index of string descriptor for the product .db 3 ; 16 iSerialNumber 1 Index of string descriptor for the serial number @@ -107,7 +108,7 @@ highspd_dscr_end: .db 0x02 ; Interface class .db 0x02 ; Interface sub class .db 0x01 ; Interface protocol code class - .db 0x00 ; Interface descriptor string index + .db 0; Interface descriptor string index ;; CDC Header Functional Descriptor .db 0x05 ; Descriptor Size in Bytes (5) @@ -154,7 +155,7 @@ highspd_dscr_end: .db 0x0A ; Interface class .db 0x00 ; Interface sub class .db 0x00 ; Interface protocol code class - .db 0x00 ; Interface descriptor string index + .db 0; Interface descriptor string index ; endpoint 2 out .db DSCR_ENDPOINT_LEN; Descriptor length @@ -195,15 +196,15 @@ fullspd_dscr_end: ; NOTE the default TRM actually has more alt interfaces ; but you can add them back in if you need them. ; here, we just use the default alt setting 1 from the trm - .db DSCR_INTERFACE_LEN - .db DSCR_INTERFACE_TYPE - .db 0 ; index - .db 0 ; alt setting idx - .db 2 ; n endpoints - .db 0x2 ; class - .db 0x2 - .db 0x1 - .db 3 ; string index + .db DSCR_INTERFACE_LEN + .db DSCR_INTERFACE_TYPE + .db
Bug#855548: hdmi2usb-fx2-firmware: --mode serial doesn't work
Package: hdmi2usb-fx2-firmware Version: 0.0.0~git20151018-1 Severity: grave Justification: renders package unusable Control: affects -1 hdmi2usb-mode-switch hdmi2usb-mode-switch usually needs to put an opsis into serial mode, before it'll successfully flash an image. Currently, the uart image included in hdmi2usb-fx2-firmware doesn't seem to work. It looks like this was fixed upstream, but we packaged the wrong branch. SR
Bug#850661: Provides line defines versioned virtual packages
Hi martin (2017.01.09_02:36:38_+0200) > Provides defines virtual packages, and those do not (and cannot as > it wouldn't make sense) carry version numbers. They have been supported in dpkg since 1.17.11, and other tools since. Pypy is not the only package to use them. And it waited until they were fairly well supported in archive infrastructure (britney, etc.) before starting to use them. > § 7.5 of the policy says: > > A Provides field may not contain version numbers Pretty sure this is a case of policy lagging behind reality (which happens more often than we'd like :( ). Here's the dpkg maintainer agreeing with me, in an aptitude bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801216#26 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#849746: src:python-xattr: Unnecessary python{3,}-cffi Depends
Package: src:python-xattr
Version: 0.9.1-1
Severity: normal
Tags: patch
Now that the upstream is using an out-of-line cffi mode [0], it's no
longer necessary to Depend on python{3,}-cffi, only the backend is
needed.
So, we can revert the patch that fixed #814650.
[0]:
https://cffi.readthedocs.io/en/latest/overview.html#purely-for-performance-api-level-out-of-line
Patch attached.
SR
From 55f4ad7835ff36071bd6b16ea5f53d0d350cd919 Mon Sep 17 00:00:00 2001
From: Stefano Rivera <stefa...@debian.org>
Date: Fri, 30 Dec 2016 12:44:58 +0100
Subject: [PATCH] Drop unnecessary python{3,}-cffi Depends
---
debian/control | 2 --
1 file changed, 2 deletions(-)
diff --git a/debian/control b/debian/control
index b461cae..bf8334a 100644
--- a/debian/control
+++ b/debian/control
@@ -41,7 +41,6 @@ Depends:
${misc:Depends},
${python:Depends},
${shlibs:Depends},
- python-cffi,
Conflicts: python-pyxattr
Provides: ${python:Provides}
, python-pyxattr
@@ -59,7 +58,6 @@ Depends:
${misc:Depends},
${python3:Depends},
${shlibs:Depends},
- python3-cffi,
Conflicts: python3-pyxattr
Provides: ${python3:Provides}
, python3-pyxattr
--
2.11.0
Bug#849745: src:python-jack-client: Unnecessary (and possibly incorrect) cffi dependencies
Package: src:python-jack-client
Version: 0.4.2-1
Severity: normal
Tags: patch
Hi,
This package uses one of the in-line cffi modes [0]. This means it needs
to depend on python-cffi, not just the backend. The binaries currently
in the archive do this, but they wouldn't if they'd been built in the
presence of python-cffi (because it has a pydist override that generates
a dependency on the backend package).
Also, they build-depend on the backend which is a bit weird, and not
doing anything useful.
[0]:
https://cffi.readthedocs.io/en/latest/overview.html#simple-example-abi-level-in-line
So, here's a patch series to tidy this all up. And fix the broken clean rule.
SR
From 3a7092cac7ee34b651140cd0e5f7238bb71cdcc0 Mon Sep 17 00:00:00 2001
From: Stefano Rivera <stefa...@debian.org>
Date: Fri, 30 Dec 2016 12:30:28 +0100
Subject: [PATCH 1/3] Drop python{3,}-cffi-backend Build-Deps - there is no
test suite
---
debian/control | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 271bcf2..40ca5cf 100644
--- a/debian/control
+++ b/debian/control
@@ -7,9 +7,7 @@ Build-Depends: debhelper (>=9),
python-all (>= 2.6.6-3~),
python-setuptools,
python3-all,
- python-cffi-backend (>= 1.6.0),
- python3-setuptools,
- python3-cffi-backend (>= 1.6.0)
+ python3-setuptools
Standards-Version: 3.9.8
Homepage: http://jackclient-python.rtfd.org
X-Python-Version: >= 2.7
--
2.11.0
From 7b2c1ca6a3e2aee95b1834bc2a569141b34ebfac Mon Sep 17 00:00:00 2001
From: Stefano Rivera <stefa...@debian.org>
Date: Fri, 30 Dec 2016 12:31:53 +0100
Subject: [PATCH 2/3] This package uses inline cffi mode
So explicitly depend on python{3,}-cffi. The backend alone is not
sufficient.
---
JACK_Client.egg-info/SOURCES.txt | 1 +
debian/control | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/JACK_Client.egg-info/SOURCES.txt b/JACK_Client.egg-info/SOURCES.txt
index de9ad60..6387d3b 100644
--- a/JACK_Client.egg-info/SOURCES.txt
+++ b/JACK_Client.egg-info/SOURCES.txt
@@ -4,6 +4,7 @@ MANIFEST.in
NEWS.rst
README.rst
jack.py
+setup.cfg
setup.py
JACK_Client.egg-info/PKG-INFO
JACK_Client.egg-info/SOURCES.txt
diff --git a/debian/control b/debian/control
index 40ca5cf..e47d46d 100644
--- a/debian/control
+++ b/debian/control
@@ -18,8 +18,8 @@ Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/python-jack-client.git
Package: python-jack-client
Architecture: all
Depends: ${python:Depends},
- python-cffi-backend (>= 1.6.0),
${misc:Depends},
+ python-cffi,
libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125
Suggests: python-numpy
Description: JACK Audio Connection Kit (JACK) Client for Python
@@ -33,7 +33,7 @@ Package: python3-jack-client
Architecture: all
Depends: ${python3:Depends},
${misc:Depends},
- python3-cffi-backend (>= 1.6.0),
+ python3-cffi,
libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125
Suggests: python3-numpy
Description: JACK Audio Connection Kit (JACK) Client for Python 3
--
2.11.0
From 3fcab5fdd5655940471c52e83d2c45d06f9f8421 Mon Sep 17 00:00:00 2001
From: Stefano Rivera <stefa...@debian.org>
Date: Fri, 30 Dec 2016 12:35:08 +0100
Subject: [PATCH 3/3] Clean up egg-info
---
debian/clean | 1 +
1 file changed, 1 insertion(+)
create mode 100644 debian/clean
diff --git a/debian/clean b/debian/clean
new file mode 100644
index 000..45149aa
--- /dev/null
+++ b/debian/clean
@@ -0,0 +1 @@
+*.egg-info/*
--
2.11.0
Bug#849744: src:python-pygit2: Unnecessary Depends on python{3,}-cffi
Package: src:python-pygit2
Severity: normal
Tags: patch
python-pygit2 uses the out-of-line mode for driving cffi, which means
that only the cffi backend is required at runtime, not support for
building the cffi modules.
This means that the Depends on python{3,}-cffi can be dropped.
SR
From 971246798914223a745214ce65a02564ea96db56 Mon Sep 17 00:00:00 2001
From: Stefano Rivera <stefa...@debian.org>
Date: Fri, 30 Dec 2016 12:00:02 +0100
Subject: [PATCH] Drop unnecessary Depends on python-cffi
---
debian/control | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/debian/control b/debian/control
index eacd5a9..4e0a3db 100644
--- a/debian/control
+++ b/debian/control
@@ -26,8 +26,7 @@ Homepage: https://github.com/libgit2/pygit2
Package: python-pygit2
Architecture: any
-Depends: python-cffi (>= 0.9.2),
- ${misc:Depends},
+Depends: ${misc:Depends},
${python:Depends},
${shlibs:Depends},
Suggests: python-pygit2-doc,
@@ -40,8 +39,7 @@ Description: bindings for libgit2 - Python 2.x
Package: python3-pygit2
Architecture: any
-Depends: python3-cffi (>= 0.9.2),
- ${misc:Depends},
+Depends: ${misc:Depends},
${python3:Depends},
${shlibs:Depends},
Suggests: python-pygit2-doc,
--
2.11.0
Bug#849648: mitmproxy: Unnecessary Build-Depends on python-cffi (and broken Vcs-Git field)
Package: mitmproxy Version: 0.18.1-1 Severity: normal Tags: patch Upstream dropped their last cffi module (certffi) in 2723a0e5739412953f60c37d0dab81d684ba5f26 That means that the Build-Depends on python-cffi is unnecessary. Additionally, when attempting to submit a patch, I noticed that the Vcs-Git field is incorrect. Patches attached. SR From 93ec45a04325aaf86169bfe3f95e5707f3fcc181 Mon Sep 17 00:00:00 2001 From: Stefano Rivera <stef...@rivera.za.net> Date: Thu, 29 Dec 2016 15:55:38 +0100 Subject: [PATCH 1/3] Drop python-cffi Build-Depends, unnecessary --- debian/control | 1 - 1 file changed, 1 deletion(-) diff --git a/debian/control b/debian/control index a7d18e2d..569eba3b 100644 --- a/debian/control +++ b/debian/control @@ -13,7 +13,6 @@ Build-Depends: debhelper (>= 9), dh-python, libssl-dev, python-dev, python-setuptools, python-urwid (>= 1.3.1), python-backports.ssl-match-hostname (>= 3.5.0.1), - python-cffi, python-configargparse (>= 0.10), python-flask (>= 0.10.1), python-html2text (>= 2016.1.8), -- 2.11.0 From e6de4b41b8521f3a2f8da524bd5448ba1ce4db50 Mon Sep 17 00:00:00 2001 From: Stefano Rivera <stef...@rivera.za.net> Date: Thu, 29 Dec 2016 15:57:22 +0100 Subject: [PATCH 2/3] Fix Vcs-Git field --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 569eba3b..04c0ac54 100644 --- a/debian/control +++ b/debian/control @@ -38,7 +38,7 @@ Build-Depends: debhelper (>= 9), dh-python, libssl-dev, python-dev, python-jsbeautifier (>= 1.6.3), python-tz Standards-Version: 3.9.8 -Vcs-Git: https://anonscm.debian.org/collab-maint/mitmproxy.git +Vcs-Git: https://anonscm.debian.org/git/collab-maint/mitmproxy.git Vcs-Browser: https://anonscm.debian.org/git/collab-maint/mitmproxy.git Homepage: https://mitmproxy.org -- 2.11.0
Bug#849643: magic-wormhole: unnecessary Build-Depends on python3-cffi
Package: magic-wormhole Version: 0.8.1-2 Severity: normal Tags: patch I'm pretty sure that you added a Build-Dependency on python3-cffi in 47343f28a9f95ec7720e81bc13b2b52eaa4f8e43 to work around a bug in the python3-nacl package's dependencies (#801786). That has now been fixed, so I'd recommend dropping the unused dependency. Patch attached, thanks :) SR diff --git a/debian/control b/debian/control index e6c014b..f509200 100644 --- a/debian/control +++ b/debian/control @@ -8,7 +8,6 @@ Build-Depends: dh-python, python3, python3-autobahn (>= 0.14.1), - python3-cffi, python3-click, python3-hkdf, python3-humanize,
Bug#796769: retitle to ITP: hdmi2usb-fx2-firmware -- f/w for micro-controller on HDMI2USB hardware
Control: retitle -1 ITP: hdmi2usb-fx2-firmware -- FX2 firmware for hdmi2usb board development Control: owner -1 ! This package contains the FX2 firmware for several modes of the Numato Opsis board's USB interface. It is used for flashing updates to the board. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#846185: ITP: ixo-usb-jtag -- Firmware for USB JTAG programmers
Package: wnpp Severity: wishlist Owner: Stefano Rivera <stefa...@debian.org> * Package name: ixo-usb-jtag Version : 0.0.0+git20160908 Upstream Author : Tim 'mithro' Ansell <mit...@mithis.com> * URL : https://github.com/mithro/ixo-usb-jtag * License : GPL-2+ Programming Lang: C Description : Firmware for USB JTAG programmers This firmware allows a USB-capable microcontroller to act like an Altera USB-Blaster JTAG pod. Which in turn may allow you to use tools you'd normally use with the Altera USB-Blaster, including UrJTAG and openocd. Supported hardware: The Cypress FX2 EZ-USB family, or an FTDI FT245 in combination with a CPLD. Builds are included for the hdmi2usb project's boards (Digilet Atlys and Numato Opsis).
Bug#845120: RM: gst-plugins-dvswitch -- ROM; dvswitch is dead
Package: ftp.debian.org Severity: normal We took over the package, and cleaned it up, this time last year, so that we could use HDMI2USB boards with dvswitch. dvswitch itself was already dead, and we were using it on ancient wheezy installs. The DebConf Video team has switched to voctomix, so this can now die. SR
Bug#845107: ITP: hdmi2usb-mode-switch -- Configuration and firmware tool for HDMI2USB devices
Package: wnpp Severity: wishlist Owner: Stefano Rivera <stefa...@debian.org> * Package name: hdmi2usb-mode-switch Version : 0.0.0+git20161016-1 Upstream Author : Tim 'mithro' Ansell <mit...@mithis.com> * URL : https://github.com/timvideos/HDMI2USB-mode-switch * License : Apache-2.0 Programming Lang: Python 3 Description : Configuration and firmware tool for HDMI2USB devices This is the tool for flashing and configuring the HDMI2USB devices. It can load a runtime firmware, and write firmware to the device's flash. https://hdmi2usb.tv/ is an open hardware and software project for capturing HDMI video with an FPGA board. This package supports the Digilent Atlys and Numato Opsis boards.
Bug#845044: voctomix-gui: Missing .desktop file
Package: voctomix-gui Version: 0.4-1 Severity: minor It'd be really nice if voctogui had a .desktop file, and appeared in menus. It'll need a logo or something... SR
Bug#844748: openocd: Please package upstream snapshot with jtagspi
Package: openocd Version: 0.9.0-1+b1 Severity: normal Is there any chance of getting an upstream snapshot that includes the jtagspi driver? It was added in d25355473da9a925a696183a9947aac292cd2f60 upstream (Jul 2015). We (DebConf video team) need it to flash our HDMI capture boards. So, having a package (even in experimental) would be useful. SR
Bug#844735: libusb-1.0: Build fxload package from libusb-1.0 examples
Hi Debian (2016.11.18_15:36:47_+0100) > For flashing the Opsis [3] boards, which the DebConf Video team uses, we > need to use a libusb version of fxload. Bah, I don't know where I got that idea from. (Well I do, but it was confused.) That said, libusb still has the better maintained fxload :) SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#844735: libusb-1.0: Build fxload package from libusb-1.0 examples
Almost forgot. I have a patch.
It doesn't include a manpage, as there isn't one upstream :(
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
diff -Nru libusb-1.0-1.0.21/debian/control libusb-1.0-1.0.21/debian/control
--- libusb-1.0-1.0.21/debian/control2016-10-26 17:53:41.0 +0200
+++ libusb-1.0-1.0.21/debian/control2016-11-18 13:33:48.0 +0100
@@ -56,3 +56,12 @@
of Linux kernel internals.
.
This is a minimal package for use in debian-installer.
+
+Package: fxload
+Section: admin
+Architecture: any
+Depends: ${misc:Depends}
+Description: Firmware download to EZ-USB devices
+ This program is conveniently able to download firmware into FX and FX2 ez-usb
+ devices. It is intended to be invoked by hotplug scripts when the unprogrammed
+ device appears on the bus.
diff -Nru libusb-1.0-1.0.21/debian/fxload.install
libusb-1.0-1.0.21/debian/fxload.install
--- libusb-1.0-1.0.21/debian/fxload.install 1970-01-01 01:00:00.0
+0100
+++ libusb-1.0-1.0.21/debian/fxload.install 2016-11-18 13:33:49.0
+0100
@@ -0,0 +1 @@
+/usr/sbin/fxload
diff -Nru libusb-1.0-1.0.21/debian/patches/install-fxload
libusb-1.0-1.0.21/debian/patches/install-fxload
--- libusb-1.0-1.0.21/debian/patches/install-fxload 1970-01-01
01:00:00.0 +0100
+++ libusb-1.0-1.0.21/debian/patches/install-fxload 2016-11-18
13:33:49.0 +0100
@@ -0,0 +1,12 @@
+--- a/examples/Makefile.am
b/examples/Makefile.am
+@@ -1,7 +1,8 @@
+ AM_CPPFLAGS = -I$(top_srcdir)/libusb
+ LDADD = ../libusb/libusb-1.0.la
+
+-noinst_PROGRAMS = listdevs xusb fxload hotplugtest testlibusb
++noinst_PROGRAMS = listdevs xusb hotplugtest testlibusb
++sbin_PROGRAMS = fxload
+
+ if HAVE_SIGACTION
+ noinst_PROGRAMS += dpfp
diff -Nru libusb-1.0-1.0.21/debian/patches/series
libusb-1.0-1.0.21/debian/patches/series
--- libusb-1.0-1.0.21/debian/patches/series 2016-08-25 10:30:40.0
+0200
+++ libusb-1.0-1.0.21/debian/patches/series 2016-11-18 13:33:49.0
+0100
@@ -1 +1,2 @@
gnu-hurd-stub.diff
+install-fxload
diff -Nru libusb-1.0-1.0.21/debian/rules libusb-1.0-1.0.21/debian/rules
--- libusb-1.0-1.0.21/debian/rules 2016-10-26 17:43:38.0 +0200
+++ libusb-1.0-1.0.21/debian/rules 2016-11-18 13:33:49.0 +0100
@@ -20,10 +20,12 @@
override_dh_auto_build-arch:
dh_auto_build --builddirectory build-deb
+ dh_auto_build --builddirectory build-deb/examples
dh_auto_build --builddirectory build-udeb
override_dh_auto_install-arch:
dh_auto_install --builddirectory build-deb
--destdir=$(CURDIR)/debian/tmp-deb
+ dh_auto_install --builddirectory build-deb/examples
--destdir=$(CURDIR)/debian/tmp-deb
# Move the library to /lib
mkdir -p $(CURDIR)/debian/tmp-deb/lib/$(DEB_HOST_MULTIARCH)/
mv
$(CURDIR)/debian/tmp-deb/usr/lib/$(DEB_HOST_MULTIARCH)/libusb-1.0.so.* \
Bug#844735: libusb-1.0: Build fxload package from libusb-1.0 examples
Source: libusb-1.0 Affects: fxload Severity: normal Tags: patch fxload upstream seems to have stalled [0]. [0]: http://linux-hotplug.cvs.sourceforge.net/viewvc/linux-hotplug/fxload/ I think the best maintained version of fxload these days is in the libusb examples [1,2]. [1]: https://github.com/libusb/libusb/blob/master/examples/fxload.c [2]: https://github.com/libusb/libusb/commits/master/examples/fxload.c For flashing the Opsis [3] boards, which the DebConf Video team uses, we need to use a libusb version of fxload. Currently we're using a patchset [4] that I don't see landing in a dead upstream, any time soon :( [3]: https://opsis.hdmi2usb.tv/getting-started/jtag.html [4]: https://git.launchpad.net/~timvideos/+git/fxload/tree/debian/patches/multios So, the best path forward is probably libusb's fxload, in examples. Can we take over the fxload package with it? SR
Bug#840673: dput missing a dependency on python setuptools library [and 1 more messages]
Hi Matthias (2016.11.09_21:34:14_+) > it's surprising that dput would need a dependency on the setuptools egg > instead > of the pkg_resources egg. A dependency on the setuptools egg just sounds > plain > wrong. I think what's going on here is that the egg-info for setuptools is in the setuptools package, not the pkg-resources package. pkg-resources is refusing to do anything unless it can resolve the requirements of the package in question, which in this case includes setuptools. So even though it has everything it needs on hand, it isn't doing anything. If we're rewriting dependencies from setuptools to pkg-recources, we should ship the setuptools egg-info in pkg-resources. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#843992: ITP: ruby-knife-acl -- Knife plugin to manupulate Chef server access control lists
Package: wnpp Severity: wishlist Owner: Stefano Rivera <stefa...@debian.org> * Package name: ruby-knife-acl Version : 1.0.3 Upstream Author : Seth Falcon <s...@chef.io>, Jeremiah Snapp <jerem...@chef.io> * URL : https://github.com/chef/knife-acl * License : Apache-2.0 Programming Lang: Ruby Description : Knife plugin to manupulate Chef server access control lists
Bug#828517: OpenSSL transition severity
Hi Kurt (2016.10.27_00:35:51_-0700) > I just took a pass at it, and I think, did most of the port in an > afternoon and evening. Landed upstream, it'll be in the next upstream release. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#828517: OpenSSL transition severity
Hi Kurt (2016.10.26_21:22:48_+0200) > Having really no idea what you're talking about, the cases that > are problematic is that they created a function like "rsa_set_p" > and we have a function RSA_set0_factors() that allows to set p but > you need to pass q at the same time and it's not allowed to set it > to NULL. It does bind at a pretty low level (lots of structs reproduced), but you're right that I don't think it's as bad as they thought. I just took a pass at it, and I think, did most of the port in an afternoon and evening. It passes its own tests, and translates, but the resulting binary segfaults on some stdlib tests. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#828517: OpenSSL transition severity
Hi Kurt (2016.10.26_10:50:40_-0700) > severity 828517 serious FYI, I chatted about this with the upstream core developers, last month. They're estimating that it's 3 months' work, and haven't started on it, yet. (The OpenSSL binding needs to be entirely re-implemented to support the now opaque data structures.) So I have a pretty low expectation of this happening in time. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#828929: cairocffi: FTBFS with gcc-6 and glibc 2.23
Hi Jean-Christophe (2016.07.02_11:15:36_-0700)
> I don’t think it has anything to do with gcc/glibc.
I agree. I suggest doing a build with a debug python interpreter, then
you get a very helpful error message:
$ LC_ALL=C.UTF-8 xvfb-run -a --server-args="-screen 0 1024x768x24" python3-dbg
-m pytest
test session starts
platform linux -- Python 3.5.2+, pytest-3.0.2, py-1.4.31, pluggy-0.3.1
rootdir: /build/cairocffi-op2T2E/cairocffi-0.7.2, inifile:
collected 44 items
cairocffi/test_cairo.py ..
cairocffi/test_pixbuf.py
cairocffi/test_xcb.py FF
= FAILURES
==
__ test_xcb_pixmap
__
xcb_conn =
def test_xcb_pixmap(xcb_conn):
width = 10
height = 10
# create a new window
wid = create_window(xcb_conn, width, height)
# create the pixmap used to draw with cairo
pixmap = create_pixmap(xcb_conn, wid, width, height)
# create graphics context to copy pixmap on window
gc = create_gc(xcb_conn)
# create XCB surface on pixmap
root_visual = find_root_visual(xcb_conn)
> surface = XCBSurface(xcb_conn, pixmap, root_visual, width, height)
cairocffi/test_xcb.py:128:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _
self =
conn = , drawable = 2097153
visual = , width = 10,
height = 10
def __init__(self, conn, drawable, visual, width, height):
c_visual = visualtype_to_c_struct(visual)
p = cairo.cairo_xcb_surface_create(
> conn._conn, drawable, c_visual, width, height)
E TypeError: initializer for ctype 'xcb_connection_t *' appears indeed to
be 'xcb_connection_t *', but the types are different (check that you are not
e.g. mixing up different ffi instances)
cairocffi/xcb.py:38: TypeError
__ test_xcb_window
__
xcb_conn =
@pytest.mark.xfail(cairo_version() < 11200,
reason="Cairo version too low")
def test_xcb_window(xcb_conn):
width = 10
height = 10
# create a new window used to draw with cairo
wid = create_window(xcb_conn, width, height)
# map the window and wait for it to appear
xcb_conn.core.MapWindow(wid)
xcb_conn.flush()
start = time.time()
while time.time() < start + 10:
event = xcb_conn.wait_for_event()
if isinstance(event, xcffib.xproto.ExposeEvent):
break
else:
pytest.fail("Never received ExposeEvent")
# create XCB surface on window
root_visual = find_root_visual(xcb_conn)
> surface = XCBSurface(xcb_conn, wid, root_visual, width, height)
cairocffi/test_xcb.py:192:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _
self =
conn = , drawable = 2097152
visual = , width = 10,
height = 10
def __init__(self, conn, drawable, visual, width, height):
c_visual = visualtype_to_c_struct(visual)
p = cairo.cairo_xcb_surface_create(
> conn._conn, drawable, c_visual, width, height)
E TypeError: initializer for ctype 'xcb_connection_t *' appears indeed to
be 'xcb_connection_t *', but the types are different (check that you are not
e.g. mixing up different ffi instances)
cairocffi/xcb.py:38: TypeError
2 failed, 42 passed in 0.87 seconds
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Bug#836907: src:hidapi-cffi: Missing dependencies on python{3,}-cffi
Package: src:hidapi-cffi
Version: 0.2.1-1
Severity: serious
Tags: patch
Justification: Policy 7.2
Upstream only declares
> setup_requires=['cffi >= 0.8']
But that's insufficient, it actually requires cffi at runtime, the first
line is:
> from cffi import FFI
It's worth noting that in Debian we split the cffi package from the
cffi-backend package. We assume that cffi packages are using the
out-of-line modes, and they only need the cffi-backend. So, when a
package declares cffi in install_requires, we generate a dependency on
the cffi-backend package.
But this package is using the in-line ABI mode (see [0] for an
explanation of the modes). So it will need an explicit dependency on
cffi, even if upstream fixes setup.py
[0]: https://cffi.readthedocs.io/en/latest/overview.html
Patch attached: dependencies.patch
Also, I noticed a bunch of things in debian/rules that pybulid can do
for you, so there's a second patch: pybulid.patch.
SR
diff -Nru hidapi-cffi-0.2.1/debian/control hidapi-cffi-0.2.1/debian/control
--- hidapi-cffi-0.2.1/debian/control 2015-06-25 13:35:38.0 -0700
+++ hidapi-cffi-0.2.1/debian/control 2016-09-06 22:04:59.0 -0700
@@ -7,14 +7,14 @@
Package: python-hidapi
Architecture: any
-Depends: ${misc:Depends}, ${python:Depends}, libhidapi-hidraw0 | libhidapi-libusb0
+Depends: ${misc:Depends}, ${python:Depends}, libhidapi-hidraw0 | libhidapi-libusb0, python-cffi (>= 0.8)
Description: Python bindings for the HID API
Python bindings for libhidapi for working with Human Interface Devices
such as mouses and keyboards.
Package: python3-hidapi
Architecture: any
-Depends: ${misc:Depends}, ${python3:Depends}, libhidapi-hidraw0 | libhidapi-libusb0
+Depends: ${misc:Depends}, ${python3:Depends}, libhidapi-hidraw0 | libhidapi-libusb0, python3-cffi (>= 0.8)
Description: Python bindings for the HID API
Python bindings for libhidapi for working with Human Interface Devices
such as mouses and keyboards.
diff -Nru hidapi-cffi-0.2.1/debian/clean hidapi-cffi-0.2.1/debian/clean
--- hidapi-cffi-0.2.1/debian/clean 1969-12-31 16:00:00.0 -0800
+++ hidapi-cffi-0.2.1/debian/clean 2016-09-06 22:04:59.0 -0700
@@ -0,0 +1 @@
+hidapi_cffi.egg-info/*
diff -Nru hidapi-cffi-0.2.1/debian/rules hidapi-cffi-0.2.1/debian/rules
--- hidapi-cffi-0.2.1/debian/rules 2015-06-25 13:08:50.0 -0700
+++ hidapi-cffi-0.2.1/debian/rules 2016-09-06 22:04:59.0 -0700
@@ -1,26 +1,6 @@
#!/usr/bin/make -f
-# This file was automatically generated by stdeb 0.8.2 at
-# Thu, 09 Oct 2014 22:55:33 +0300
-PYTHONS:=$(shell pyversions -vr)
-PYTHON3S:=$(shell py3versions -vr)
export PYBUILD_NAME=hidapi
+
%:
dh $@ --with python2,python3 --buildsystem=pybuild
-
-override_dh_clean:
- dh_clean -O--buildsystem=pybuild
- rm -rf build
- rm -rf __pycache__
-
-override_dh_install:
- set -e ; for pyvers in $(PYTHONS); do \
- python$$pyvers setup.py install --install-layout=deb \
- --root $(CURDIR)/debian/python-hidapi; \
- done
- set -e ; for pyvers in $(PYTHON3S); do \
- python$$pyvers setup.py install --install-layout=deb \
- --root $(CURDIR)/debian/python3-hidapi; \
- done
- rm -rf $(CURDIR)/debian/python*-hidapi/usr/lib/python*/dist-packages/*.pth
- rm -rf $(CURDIR)/debian/python*-hidapi/usr/lib/python3.*
Bug#834545: transition: re2
Hi Emilio (2016.08.31_00:35:21_+0200) > > Would you mind if I held back for the next release, due on the 1st? So, that is staged in git and ready to go. It will require a 1-line patch to ocaml-re2 (inserting an std::), and ruby-re2 should be binnmuable. chromium-browser, libphonenumber, and hhvm all have unrelated FTBFSs at the moment. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
