Bug#970777: Acknowledgement (fish: tty settings are not resetted on exit)

[Tristan Seligmann]

On Mon, 28 Sep 2020 at 02:56, Boyuan Yang  wrote:
> Please let me know if this will be handled in the near future. If not
> (or if there's no reply within 1 week), I plan to do a NMU stable
> upload and contact the Release Team about this stable upload.

I can't take care of this right now, so please go ahead with the NMU
(and thanks for taking care of this!)

In the meantime, I think running "reset" after returning to bash
should make the terminal usable again.

Bug#969225: python3-electrum: Please relax dependency on python3-qdarkstyle

[Tristan Seligmann]

On Sat, 29 Aug 2020 at 16:45,  wrote:
> On top of that, since 4.0.2-1, python3-electrum has "Depends:
> python3-qdarkstyle". Is this absolute dependency needed?
> (See Policy 7.2¹ for details.)

This dependency was picked up mostly by accident; upstream specifies a
dependency on qdarkstyle in setup.py so when python3-qdarkstyle is
installed at build-time, dh_python3 automatically translates the
requires.txt entry into a Depends: in the binary package. Electrum is
perfectly functional without this, though (it will just give you a
warning if you try to activate dark mode), so I will filter the dep
out at build time.

Bug#968780: ratt outputs thousands of warnings

[Tristan Seligmann]

Package: ratt
Version: 0.0~git20180127.c44413c-2+b10
Severity: normal

I have a multiarch amd64 system with i386 active. This causes around 30,000
lines of warnings like this to be output by ratt:

(W)Packages: Ignoring Package (python3-pyzfs,0.8.4-2,i386) : architecture: i386 
is not included in all,amd64

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ratt depends on:
ii  libc6   2.31-3
ii  sbuild  0.80.0

Versions of packages ratt recommends:
ii  dose-extra  5.0.1-15

ratt suggests no packages.

-- no debconf information

Bug#968666: electrum: exception which prevents startup "Non keyword-only attributes not allowed after..."

[Tristan Seligmann]

On Wed, 19 Aug 2020 at 19:28, Luke Kenneth Casson Leighton
 wrote:
> > On Wed, 19 Aug 2020 at 14:48, lkcl  wrote:
> > >
> > > ValueError: Non keyword-only attributes are not allowed after a 
> > > keyword-only attribute.  Attribute in question: Attribute(name='invoice', 
> > > default=NOTHING, validator=None, repr=True, cmp=True, hash=None, 
> > > init=True, metadata=mappingproxy({}), type=, converter=None, 
> > > kw_only=False)
> >
> > This is a consequence of #968563; upgrading python3-attr should fix it.
>
> the normal approach to this would be to release a version of the
> electrum packaging that specifically depends on that specific version
> of python3-attr or above. the following to go into debian/control:

Yes, the next upload will fix this as well as some other dependency issues.

Bug#968666: electrum: exception which prevents startup "Non keyword-only attributes not allowed after..."

[Tristan Seligmann]

Control: tags -1 - upstream
Control: forcemerge 968563 -1

On Wed, 19 Aug 2020 at 14:48, lkcl  wrote:
>
> ValueError: Non keyword-only attributes are not allowed after a keyword-only 
> attribute.  Attribute in question: Attribute(name='invoice', default=NOTHING, 
> validator=None, repr=True, cmp=True, hash=None, init=True, 
> metadata=mappingproxy({}), type=, converter=None, kw_only=False)

This is a consequence of #968563; upgrading python3-attr should fix it.

Bug#968410: Patch

[Tristan Seligmann]

Control: tags -1 + patch

Attached patch fixes this.
From 46f86fdd03d77d6d2a6d4f0fc3f64c447093bae7 Mon Sep 17 00:00:00 2001
From: Tristan Seligmann 
Date: Sat, 15 Aug 2020 11:28:42 +0200
Subject: [PATCH] Install _distutils_hack. Closes: #968410.

---
 debian/changelog  | 7 +++
 debian/pypy-setuptools.install| 1 +
 debian/python3-setuptools.install | 1 +
 3 files changed, 9 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a5ffcf3..87d60a4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+setuptools (49.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install _distutils_hack. Closes: #968410.
+
+ -- Tristan Seligmann   Sat, 15 Aug 2020 11:28:00 +0200
+
 setuptools (49.3.1-1) unstable; urgency=medium
 
   * New upstream version.
diff --git a/debian/pypy-setuptools.install b/debian/pypy-setuptools.install
index 5392cf5..ff7e0bc 100644
--- a/debian/pypy-setuptools.install
+++ b/debian/pypy-setuptools.install
@@ -1,2 +1,3 @@
 /usr/lib/pypy/dist-packages/easy_install*
 /usr/lib/pypy/dist-packages/setuptools*
+/usr/lib/pypy/dist-packages/_distutils_hack*
diff --git a/debian/python3-setuptools.install b/debian/python3-setuptools.install
index 2c09851..f188df6 100644
--- a/debian/python3-setuptools.install
+++ b/debian/python3-setuptools.install
@@ -1,2 +1,3 @@
 /usr/lib/python3.*/*-packages/easy_install*
 /usr/lib/python3.*/*-packages/setuptools*
+/usr/lib/python3.*/*-packages/_distutils_hack*
-- 
2.28.0

Bug#968303: fish-common: pkgconfig lists /usr/local

[Tristan Seligmann]

On Thu, 13 Aug 2020 at 10:11, David Adam  wrote:
> > Futhermore, the variable $fish_completion_path still lists loads of
> > flatpak directories, which are not available in Debian, and should
> > preferrably be removed.
>
> Do you mean $fish_complete_path? My guess is that those directories have
> almost certainly been set by something you have installed on your system
> rather than the fish package. `set --show fish_complete_path` will tell
> you if it has been set as a universal variable, in which case you can just
> erase/reset it; if not, you might have to go looking through /etc to find
> out what is setting it.

flatpak adds itself to XDG_DATA_DIRS via Xsession.d; I think that may
be where these paths come from.

Bug#968150: lintian-brush: Failure to fix public-upstream-key-not-minimal

[Tristan Seligmann]

Package: lintian-brush
Version: 0.74
Severity: normal

This is happening to me with src:anorack.

lintian:
I: anorack source: public-upstream-key-not-minimal upstream/signing-key.asc has 
3 extra signature(s) for keyid 2D4EB3A6015475F5

lintian-brush:
Fixer 'public-upstream-key-not-minimal' made no changes. (took: 0.01s)

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.4
ii  python3  3.8.2-3
ii  python3-breezy   3.1.0-5
ii  python3-debian   0.1.37
ii  python3-debmutate0.4
ii  python3-distro-info  0.23
ii  python3-dulwich  0.20.2-1
ii  python3-iniparse 0.4-3
ii  python3-ruamel.yaml  0.16.10-2

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.3-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.20-1
ii  libdebhelper-perl13.2
ii  lintian  2.88.0
ii  python3-asyncpg  0.20.1-1+b1
ii  python3-bs4  4.9.1-1
ii  python3-levenshtein  0.12.0-5+b1
ii  python3-pyinotify0.9.6-1.3
ii  python3-toml 0.10.1-1

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  215

-- no debconf information

Bug#967241: RM: twistedchecker/experimental -- ROM; Not in unstable, irrelevant for Debian

[Tristan Seligmann]

Package: ftp.debian.org
Severity: normal

This package does not really belong in Debian and has never been in unstable.

Bug#966485: git-buildpackage: [gbp pull] git merge invoked without --ff

[Tristan Seligmann]

Package: git-buildpackage
Version: 0.9.20
Severity: normal

gbp invokes git merge expecting the default behaviour of -ff; however, my
global config sets --no-ff as default so I end up with unexpected merge
commits. gbp should explicitly pass --ff to git merge and git pull in order to
get the behaviour it expects.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.20.4
ii  git1:2.28.0-1
ii  man-db 2.9.3-2
ii  python33.8.2-3
ii  python3-dateutil   2.8.1-4
ii  python3-pkg-resources  46.1.3-1
ii  sensible-utils 0.0.12+nmu1

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.88
ii  pbuilder  0.230.4
ii  pristine-tar  1.48
ii  python3-requests  2.23.0+dfsg-2
ii  sbuild0.79.1-1

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.1-2
ii  unzip6.0-25

-- no debconf information

Bug#965179: ITP: hypothesis-auto -- Extends Hypothesis to add fully automatic testing of type annotated functions

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann 

* Package name    : hypothesis-auto
  Version         : 1.1.4
  Upstream Author : Timothy Crosley 
* URL             : https://pypi.org/project/hypothesis-auto/
* License         : MIT
  Programming Lang: Python
  Description     : Extends Hypothesis to add fully automatic testing of type 
annotated functions

Binary package names: python3-hypothesis-auto

hypothesis-auto is an extension for the Hypothesis project that enables fully 
automatic tests for type annotated functions.

This is a test dep of the new isort upstream version.

Bug#961263: nvidia-cuda-dev: File collision

[Tristan Seligmann]

Package: nvidia-cuda-dev
Version: 10.1.168-10
Severity: important

dpkg: error processing archive 
/var/cache/apt/archives/nvidia-cuda-dev_10.1.168-10_amd64.deb (--unpack):
 trying to overwrite '/usr/include/ansidecl.h', which is also in package 
binutils-dev 2.34-8

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), 
LANGUAGE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#892264: Hy 0.17.0

[Tristan Seligmann]

Go for it! Maintainer should probably be DPMT anyway.

On Sat, 17 Aug 2019 at 01:31, Tianon Gravi  wrote:

> On Tue, 4 Jun 2019 at 16:59, Tianon Gravi  wrote:
> > I've updated Git with what I think is finally successful packaging of
> > a newer Hy version (0.17.0 ATM).  It requires updated "python-astor"
> > (I tested 0.8.0) and "python-rply" (I tested 0.7.7), which I don't
> > have time to chase down properly right now.
>
> Hi Tristan!  To this end (getting Hy 0.17.0 in the archive) I've
> updated Git for "python-rply" to 0.7.7 (from 0.7.4), but I wanted to
> reach out before uploading to check whether you're OK with this
> version bump?
>
> (You're the human listed in Maintainer/Uploaders :D)
>
> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
>


-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

Bug#921688: NMU Diff

[Tristan Seligmann]

Thank you for taking care of this; I plan to package a new upstream version
when I can, but the need to package new dependencies makes this non-trivial
and due to personal circumstances I have not yet had the opportunity to
handle this.

On Tue, 7 May 2019 at 04:30, Sam Hartman  wrote:

>
> Dear maintainer.
> I made the following 0-day NMU of electrum.
> I suspect that once you update to a new version you will not wish to
> include these changes, but in the interest of awareness of your package
> I wanted to make sure you were aware.
>
> diff --git a/debian/changelog b/debian/changelog
> index 4ff..c30a279 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,12 @@
> +electrum (3.2.3-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * On startup print a warning that this version in insecure and then
> +exit, Closes: #928518
> +
> +
> + -- Sam Hartman   Mon, 06 May 2019 22:11:19 -0400
> +
>  electrum (3.2.3-1) unstable; urgency=medium
>
>* New upstream release.
> diff --git a/debian/patches/replace-with-security-warning.patch
> b/debian/patches/replace-with-security-warning.patch
> new file mode 100644
> index 000..e8f409e
> --- /dev/null
> +++ b/debian/patches/replace-with-security-warning.patch
> @@ -0,0 +1,60 @@
> +From: Sam Hartman 
> +Date: Mon, 6 May 2019 22:10:51 -0400
> +X-Dgit-Generated: 3.2.3-1.1 3afceceac2d1042645e470189c13edb4f965e7a9
> +Subject: Replace with security warning
> +
> +On startup print to GUI and stdio a security warning and then exit.
> +
> +---
> +
> +--- electrum-3.2.3.orig/electrum/electrum
>  electrum-3.2.3/electrum/electrum
> +@@ -1,4 +1,4 @@
> +-#!/usr/bin/env python3
> ++#!/usr/bin/python3
> + # -*- mode: python -*-
> + #
> + # Electrum - lightweight Bitcoin client
> +@@ -30,13 +30,42 @@ script_dir = os.path.dirname(os.path.rea
> + is_bundle = getattr(sys, 'frozen', False)
> + is_local = not is_bundle and os.path.exists(os.path.join(script_dir,
> "electrum.desktop"))
> + is_android = 'ANDROID_DATA' in os.environ
> ++try:
> ++import PyQt5
> ++except Exception:
> ++sys.exit("Error: Could not import PyQt5 on Linux systems, you may
> try 'sudo apt-get install python3-pyqt5'")
> +
> ++from PyQt5.QtGui import *
> ++from PyQt5.QtWidgets import *
> ++from PyQt5.QtCore import *
> ++import PyQt5.QtCore as QtCore
> + # move this back to gui/kivy/__init.py once plugins are moved
> + os.environ['KIVY_DATA_DIR'] = os.path.abspath(os.path.dirname(__file__))
> + '/electrum/gui/kivy/data/'
> +
> + if is_local or is_android:
> + sys.path.insert(0, os.path.join(script_dir, 'packages'))
> +
> ++security_message = ''' \
> ++This version of Electrum is vulnerable to malicious code inserted by
> ++attackers and is being actively exploited to try and convince users to
> ++give their private credentials to attackers.  See
> ++https://bugs.debian.org/921688 for details.  Until the version in
> ++Debian is updated, please see https://electrum.org/download.html
> ++'''
> ++sys.stderr.write(security_message)
> ++
> ++
> ++from electrum.gui.qt.util import MessageBoxMixin
> ++class Window(QMainWindow, MessageBoxMixin):
> ++
> ++def __init__(self, *args, **kwargs):
> ++super().__init__(*args, **kwargs)
> ++self.show_warning(msg = security_message, title = "THIS
> APPLICATION is INSECURE")
> ++
> ++
> ++app = QApplication(["electrum", "gui"])
> ++window = Window()
> ++sys.exit(2)
> +
> + def check_imports():
> + # pure-python dependencies need to be imported here for pyinstaller
> diff --git a/debian/patches/series b/debian/patches/series
> new file mode 100644
> index 000..8ffe66a
> --- /dev/null
> +++ b/debian/patches/series
> @@ -0,0 +1 @@
> +replace-with-security-warning.patch
> diff --git a/electrum/electrum b/electrum/electrum
> index dd35c35..8c5ef37 100755
> --- a/electrum/electrum
> +++ b/electrum/electrum
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env python3
> +#!/usr/bin/python3
>  # -*- mode: python -*-
>  #
>  # Electrum - lightweight Bitcoin client
> @@ -30,13 +30,42 @@ script_dir =
> os.path.dirname(os.path.realpath(__file__))
>  is_bundle = getattr(sys, 'frozen', False)
>  is_local = not is_bundle and os.path.exists(os.path.join(script_dir,
> "electrum.desktop"))
>  is_android = 'ANDROID_DATA' in os.environ
> -
> +try:
> +import PyQt5
> +except Exception:
> +sys.exit("Error: Could not import PyQt5 on Linux systems, you may try
> 'sudo apt-get install python3-pyqt5'")
> +
> +from PyQt5.QtGui import *
> +from PyQt5.QtWidgets import *
> +from PyQt5.QtCore import *
> +import PyQt5.QtCore as QtCore
>  # move this back to gui/kivy/__init.py once plugins are moved
>  os.environ['KIVY_DATA_DIR'] = os.path.abspath(os.path.dirname(__file__))
> + '/electrum/gui/kivy/data/'
>
>  if is_local or is_android:
>  sys.path.insert(0, os.path.join(script_dir, 'packages'))
>
> +security_message = ''' \
> +This version of Electrum is vulnerable to malicious code inserted by
> +attackers and is being actively 

Bug#924650: epsilon: diff for NMU version 0.7.1-1.1

[Tristan Seligmann]

Thanks!

On Sat, 6 Apr 2019 at 13:12, Tobias Frost  wrote:

> Control: tags 924650 + pending
>
>
> Dear maintainer,
>
> I've prepared an NMU for epsilon (versioned as 0.7.1-1.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
>
>

-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

Bug#918476: ITS: fish

[Tristan Seligmann]

Please go ahead! I am unfortunately unable to work on Debian-related
matters for another month or two.

Once I am back I would be interested in co-maintaining the package but we
can coordinate on that later.

On Sun, 6 Jan 2019, 15:06 Mo Zhou,  wrote:

> Package: fish
> Version: 2.7.1-3+b1
> X-Debbugs-CC: Tristan Seligmann 
>
> Hi Tristan,
>
> fish is my default login shell and I wish to use fish 3.0 and push
> fish 3.0.X into Buster. So following the ITS process I'm filing this
> bug.
>
>
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#ps-guidelines
>
> And I'm preparing the NEW release here
> https://salsa.debian.org/lumin/fish
> before pushing anything to the original git repo
>

Bug#916682: python-cryptography: build from source fails with libssl-dev_1.1.0j-1~deb9u1 amd64

[Tristan Seligmann]

I suspect this is fixed upstream but I am unable to take care of uploading
a new version for the next few weeks. An NMU / team upload would be
appreciated!

Bug#902327: isort: diff for NMU version 4.3.4+ds1-1.1

[Tristan Seligmann]

On Wed, 8 Aug 2018 at 08:45 Niels Thykier  wrote:

> I've prepared an NMU for isort (versioned as 4.3.4+ds1-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>

Patch looks good to me, thanks for taking care of this.

Bug#902553: Bug#902592: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

[Tristan Seligmann]

On Fri, 29 Jun 2018 at 14:40 Andreas Tille  wrote:

> Would you mind filing an according bug report we could refer to?
>

I've filed this as #902784 although I haven't had the chance to investigate
the cause further. (Probably some minor packaging error)

Bug#902784: cython-dbg: StringIOTree debug module missing

[Tristan Seligmann]

Package: cython-dbg
Version: 0.28.2-4
Severity: important

cython ships a StringIOTree extension module:

/usr/lib/python2.7/dist-packages/Cython/StringIOTree.x86_64-linux-gnu.so

However, cython-dbg is missing the debug version of this module. This results
in import errors when using the debug interpreter:

mithrandi@lorien ~> python-dbg -c 'import Cython.Compiler.Main'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Main.py", line 30, in 

from .Symtab import ModuleScope
  File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Symtab.py", line 19, 
in 
from . import PyrexTypes
  File "/usr/lib/python2.7/dist-packages/Cython/Compiler/PyrexTypes.py", line 
17, in 
from .Code import UtilityCode, LazyUtilityCode, TempitaUtilityCode
  File "Cython/Compiler/Code.py", line 38, in init Cython.Compiler.Code
ImportError: 
/usr/lib/python2.7/dist-packages/Cython/StringIOTree.x86_64-linux-gnu.so: 
undefined symbol: Py_InitModule4_64

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), 
LANGUAGE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cython-dbg depends on:
ii  cython  0.28.2-4
ii  libc6   2.27-3

cython-dbg recommends no packages.

cython-dbg suggests no packages.

-- no debconf information

Bug#902553: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

[Tristan Seligmann]

On Fri, 29 Jun 2018 at 14:20 Andreas Tille  wrote:

> Hi Tristan,
>
> On Fri, Jun 29, 2018 at 01:31:31PM +0200, Tristan Seligmann wrote:
> > This is a cython bug; cython-dbg fails to ship the StringIOTree extension
> > module, so the regular non-debug module is found when doing a debug build
> > but fails to load.
>
> Are you refering to #902551?
>

No, that bug looks unrelated.

Bug#902553: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

[Tristan Seligmann]

This is a cython bug; cython-dbg fails to ship the StringIOTree extension
module, so the regular non-debug module is found when doing a debug build
but fails to load.

On Fri, 29 Jun 2018 at 13:18 Andreas Tille  wrote:

> Control: tags -1 help
>
> I agree with Ghislain that the issue below might be caused by Cython.
> Any idea how to fix this?
>
> Kind regards
>
>   Andreas.
>
> On Fri, Jun 29, 2018 at 12:23:52PM +0200, Ghislain Vaillant wrote:
> > I am away right now and can't investigate before two weeks.
> >
> > Looks Cython related from a first look.
> >
> > Ghis
> >
> > Le ven. 29 juin 2018 à 11:17, Andreas Tille  a
> écrit :
> >
> > > Hi Ghislain,
> > >
> > > since one of the Debian Med packages seems to be affected I tried to
> > > upgrade h5py (see Git repository).  Unfortunately it does not build:
> > >
> > > ...
> > > running build_ext
> > > Traceback (most recent call last):
> > >   File "setup.py", line 168, in 
> > > cmdclass = CMDCLASS,
> > >   File "/usr/lib/python2.7/dist-packages/setuptools/__init__.py", line
> > > 129, in setup
> > > return distutils.core.setup(**attrs)
> > >   File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
> > > dist.run_commands()
> > >   File "/usr/lib/python2.7/distutils/dist.py", line 953, in
> run_commands
> > > self.run_command(cmd)
> > >   File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
> > > cmd_obj.run()
> > >   File "/usr/lib/python2.7/distutils/command/build.py", line 128, in
> run
> > > self.run_command(cmd_name)
> > >   File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
> > > self.distribution.run_command(command)
> > >   File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
> > > cmd_obj.run()
> > >   File "/build/h5py-2.8.0/setup_build.py", line 156, in run
> > > from Cython.Build import cythonize
> > >   File "/usr/lib/python2.7/dist-packages/Cython/Build/__init__.py",
> line
> > > 1, in 
> > > from .Dependencies import cythonize
> > >   File "/usr/lib/python2.7/dist-packages/Cython/Build/Dependencies.py",
> > > line 36, in 
> > > from ..Compiler.Main import Context, CompilationOptions,
> > > default_options
> > >   File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Main.py", line
> > > 30, in 
> > > from .Symtab import ModuleScope
> > >   File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Symtab.py",
> line
> > > 19, in 
> > > from . import PyrexTypes
> > >   File
> "/usr/lib/python2.7/dist-packages/Cython/Compiler/PyrexTypes.py",
> > > line 17, in 
> > > from .Code import UtilityCode, LazyUtilityCode, TempitaUtilityCode
> > >   File "Cython/Compiler/Code.py", line 38, in init Cython.Compiler.Code
> > > ImportError: /usr/lib/python2.7/dist-packages/Cython/
> > > StringIOTree.x86_64-linux-gnu.so: undefined symbol: Py_InitModule4_64
> > > E: pybuild pybuild:336: build: plugin distutils failed with: exit
> code=1:
> > > /usr/bin/python-dbg setup.py build
> > > dh_auto_build: pybuild --build -i python{version}-dbg -p 2.7 returned
> exit
> > > code 13
> > > make[1]: *** [debian/rules:22: override_dh_auto_build] Error 25
> > > make[1]: Leaving directory '/build/h5py-2.8.0'
> > > make: *** [debian/rules:10: build] Error 2
> > > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> > >
> > >
> > > Can you please have a look?
> > >
> > > Kind regards
> > >
> > > Andreas.
> > >
> > > --
> > > http://fam-tille.de
> > >
>
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>
>
> --
> http://fam-tille.de
>
>

Bug#884484: python-cryptography-vectors/2.2.2-1 appears to break python-cryptography in testing

[Tristan Seligmann]

On Mon, 11 Jun 2018 at 09:15 Paul Gevers  wrote:

> Hi Tristan,
>
> On 11-06-18 02:49, Tristan Seligmann wrote:
> > On Sun, 10 Jun 2018 at 21:57 Paul Gevers  > did you ever
> > considered to add these vectors (as a second tar ball in the source 3
> > format) to the source package of python-cryptography?
> >
> >
> > I think this might actually be the ideal solution, all else being equal,
> > but a lot of the tooling in use (dh_python, pybuild, git-dpm, etc.)
> > unfortunately does not handle this scenario well, so I haven't attempted
> it.
>
> I don't assume you filed bug reports against those tools?
>

git-dpm is unmaintained now, I think; DPMT is switching to gbp-pq which I
think does support multiple tarballs. Thinking about the other tools, I
guess the problem is that there are two entirely separate (but duplicate;
ie. both Python packages) build processes that need to be run, and usually
we would use two separate source packages to do this. But maybe there's
something I missed?

Anyhow, to answer the question, I didn't file any bug reports myself.

Bug#884484: python-cryptography-vectors/2.2.2-1 appears to break python-cryptography in testing

[Tristan Seligmann]

On Sun, 10 Jun 2018 at 21:57 Paul Gevers  wrote:

> Hi
>
> On 10-06-18 21:34, Tristan Seligmann wrote:
> > -vectors exists purely for the benefit of the tests, nothing outside the
> > tests uses the vectors. If you are not running the tests, having a
> > mismatched version of -vectors will have no effect.
>
> Thanks for clarifying. Just for my understanding, did you ever
> considered to add these vectors (as a second tar ball in the source 3
> format) to the source package of python-cryptography?
>

I think this might actually be the ideal solution, all else being equal,
but a lot of the tooling in use (dh_python, pybuild, git-dpm, etc.)
unfortunately does not handle this scenario well, so I haven't attempted it.

Bug#884484: python-cryptography-vectors/2.2.2-1 appears to break python-cryptography in testing

[Tristan Seligmann]

On Sun, 10 Jun 2018 at 21:06 Paul Gevers  wrote:

> need to stay in lock step. In this bug (#884484) the solution was to
> tighten the test dependencies, which is one way to achieve this (albeit
> it will only work for the next time without the help of the RT or me),
> but I wonder if this dependency is only for the test, or really needed
> for python-cryptography. If the latter, to guarantee that the archive
>

-vectors exists purely for the benefit of the tests, nothing outside the
tests uses the vectors. If you are not running the tests, having a
mismatched version of -vectors will have no effect.


> Currently this regression is delaying the migration of both packages to
> testing by 10 days. I can help speed it up a bit if this regression is
> really only a TEST dependency restriction.
>

Sounds good to me!

Bug#892112: python-cryptography appears to intend to install python-cffi as a dependency, but it isn't installed

[Tristan Seligmann]

On Mon, 5 Mar 2018 at 20:12 Corey Bryant  wrote:

>Installation of python-cryptography doesn't install python-cffi. This
>is on Ubuntu Bionic. The following bug has some more details:
>
> https://bugs.launchpad.net/ubuntu/+source/python-cryptography/+bug/1752660
>
>The package currently has 'dh_python(2|3) --depends=cffi' but that is
>apparently not working, at least on bionic.
>

In Debian, python-cffi is only required at build time. At runtime, it is
not required (only python-cffi-backend is required). This is mostly driven
by the python-cffi package itself: see /usr/share/python/dist/python-cffi
for details.

I don't immediately know why or if this would be different in Ubuntu, and I
don't immediately see what the stack trace in the Ubuntu bug report has to
do with cffi being installed or not.

Bug#884417: python-trezor v0.9.0 tagged - next steps?

[Tristan Seligmann]

I have a fixed version prepared in git now, but it looks like we need to
wait for Electrum 3.1.0 to be released as 3.0.6 is not compatible with
python-trezor 0.9.0

On Tue, 27 Feb 2018 at 06:55 Jonathan Cross  wrote:

> >  I'll try to take care of it this week.
>
> Fantastic, thanks Tristan!
>

Bug#884417: python-trezor v0.9.0 tagged - next steps?

[Tristan Seligmann]

On Mon, 26 Feb 2018 at 21:20 Andreas Beckmann  wrote:

> This is what I understood from reading debian/{changelog,control} and
> the upload notifications on the qa page [1]: the package was split with
> the 0.7.16-1 upload, but lacks proper Breaks+Replaces for the files
> being moved around.
>

Yes, this is a relatively straightforward fix, sorry for the delay in
implementing it! I'll try to take care of it this week. It's just an issue
with the Debian packaging, not the upstream portion.

Bug#888303: zbar: Ship python3-zbar package

[Tristan Seligmann]

Source: zbar
Version: 0.10+doc-10.1+b1
Severity: wishlist

Electrum has python3-zbar as an optional dependency now since the move to
Python 3, but this does not actually exist in Debian yet. Could you add it?

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), 
LANGUAGE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#887582: FTBFS: test suite failures on 32-bit arches

[Tristan Seligmann]

Source: fish
Version: 2.7.1-2
Severity: serious
Tags: upstream
Justification: FTBFS

The test suite is failing on 32-bit arches in a somewhat inscrutable way. I am
investigating this but filing a bug to track the status so long.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), 
LANGUAGE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#777089: Next python-mote pre-condition test issue: python-jsondiff trows ModuleNotFoundError: No module named 'nose_random'

[Tristan Seligmann]

On Tue, 16 Jan 2018 at 22:45 Andreas Tille  wrote:

> My web search for a module named 'nose_random' remained empty.
>

I found this package, which seems to match, from the same organization:
https://github.com/ZoomerAnalytics/nose-random

Unfortunately it seems to be unreleased, so I think you would need to
package a GitHub snapshot or something (or alternatively disable the tests).

Bug#886683: [Pkg-bitcoin-devel] Bug#886683: electrum: Security vulnerability in electrum

[Tristan Seligmann]

On Tue, 16 Jan 2018 at 09:09 Salvatore Bonaccorso <car...@debian.org> wrote:

> Hi,
>
> On Tue, Jan 16, 2018 at 06:56:19AM +, Tristan Seligmann wrote:
> > On Mon, 15 Jan 2018 at 22:21 Moritz Mühlenhoff <j...@inutil.org> wrote:
> >
> > > Ok, I'll update the Debian Security Tracker accordingly, but we also
> should
> > > remove the package in the next stable point release.
> > > Can you please also file a bug? (reportbug release.debian.org -> "rm")
> > >
> >
> > Yes, good point; I have filed this as #887412.
>
> Does the same reasoning as well apply to the version in
> oldstable/jessie? If so we might want to remove it from there as well
> (just fill a second RM bug specific for the jessie version).
>

Done (#887415). The jessie version is too old to be affected by the
security issue, but otherwise has the same problem (cannot connect to the
network) as well as probably calculating fees for offline transacting that
are way too low for the current situation.

Bug#887415: RM: electrum/1.9.8-4

[Tristan Seligmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

The same as #887412, this version of Electrum is no longer able to connect to
the network. It is unaffected by the security issue, but we should remove it to
avoid user confusion.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), 
LANGUAGE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#886683: [Pkg-bitcoin-devel] Bug#886683: electrum: Security vulnerability in electrum

[Tristan Seligmann]

On Mon, 15 Jan 2018 at 22:21 Moritz Mühlenhoff  wrote:

> Ok, I'll update the Debian Security Tracker accordingly, but we also should
> remove the package in the next stable point release.
> Can you please also file a bug? (reportbug release.debian.org -> "rm")
>

Yes, good point; I have filed this as #887412.

Bug#887412: RM: electrum/2.7.9-1

[Tristan Seligmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Unfortunately due to protocol changes Electrum 2.7.9 (the version in stretch)
is unable to connect to the Electrum servers. Backporting the changes would
require extensive/invasive changes to the code, and this version is also
subject to a security vulnerability (#886683), so I think we should remove the
package from stable, unless including a newer upstream wholesale would be
acceptable.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), 
LANGUAGE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#777089: Please help with test suite error and installation problem of python-aws-xray-sdk (Was: If there is no response in debian-python then debian-science might be the right team)

[Tristan Seligmann]

On Mon, 15 Jan 2018 at 13:59 Andreas Tille  wrote:

>SyntaxError: invalid syntax
> !!! Interrupted: 4 errors during collection
> 
>

All of these syntax errors relate to syntax that only exist on Python 3,
thus I would conclude that this package does not support Python 2.

Bug#886810: yubioath-desktop: New upstream release: 4.3.2

[Tristan Seligmann]

Package: yubioath-desktop
Version: 3.0.1-2
Severity: wishlist

There is a new upstream version available.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), 
LANGUAGE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages yubioath-desktop depends on:
ii  libykpers-1-11.18.0-1
ii  pcscd1.8.23-1
ii  python   2.7.14-4
ii  python-click 6.7-3
ii  python-crypto2.6.1-8
ii  python-pkg-resources 38.2.4-2
ii  python-pyscard   1.9.6-2
ii  python-pyside.qtgui  1.2.2+source1-3
ii  python-pyside.qtnetwork  1.2.2+source1-3

yubioath-desktop recommends no packages.

yubioath-desktop suggests no packages.

-- no debconf information

Bug#886683: [Pkg-bitcoin-devel] Bug#886683: electrum: Security vulnerability in electrum

[Tristan Seligmann]

Control: found -1 2.4.2+dfsg1-1
Control: fixed -1 3.0.5-1

On Tue, 9 Jan 2018 at 00:21 Daniel Koszta  wrote:

> A new, fixed version is already available in debian unstable, but it
> should be included in stable and testing as soon as possible.
>

Unfortunately the version in stable is too old to be able to connect to the
current Electrum servers due to protocol incompatibilities; thus I do not
think there is a need to backport this fix to stable (if you are still
using this version successfully, it is most likely on an offline machine
that is not vulnerable to this exploit).

Testing should be updated shortly as nothing blocks the migration from
unstable: https://qa.debian.org/excuses.php?package=electrum

Bug#883717: Oops, correct patch

[Tristan Seligmann]

On Wed, 6 Dec 2017 at 23:56 Tristan Seligmann <mithra...@mithrandi.net>
wrote:

> On Wed, 6 Dec 2017 at 23:52 Thomas Goirand <z...@debian.org> wrote:
>
>> The OpenStack team doesn't need this package anymore, and it'd be nice
>> to have it within the DPMT instead. Would you like to do that work?
>>
>
> I'm still happy to adopt the package; it looks like upstream does not
> actually support Python 3 and rather another fork is needed for this for
> Electrum, but it would make sense to maintain both packages in the same
> place.
>

I have just uploaded python-jsonrpclib 0.1.7-1 adopting the package into
DPMT (and pushed to DPMT git).

Bug#884064: ITP: jsonrpclib-pelix -- This project is an implementation of the JSON-RPC v2.0 specification (backwards-

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann <mithra...@debian.org>

* Package name: jsonrpclib-pelix
  Version : 0.3.1
  Upstream Author : Thomas Calmant <thomas.calmant+git...@gmail.com>
* URL : http://github.com/tcalmant/jsonrpclib/
* License : Apache License 2.0
  Programming Lang: Python
  Description : This project is an implementation of the JSON-RPC v2.0 
specification (backwards-

Binary package names: python3-jsonrpclib-pelix

This is a fork of jsonrpclib used by electrum for Python 3 support; I intend
not to ship the Python 2 package to avoid conflicts with python-jsonrpclib.

Bug#883717: Oops, correct patch

[Tristan Seligmann]

On Wed, 6 Dec 2017 at 23:52 Thomas Goirand  wrote:

> The OpenStack team doesn't need this package anymore, and it'd be nice
> to have it within the DPMT instead. Would you like to do that work?
>

I'm still happy to adopt the package; it looks like upstream does not
actually support Python 3 and rather another fork is needed for this for
Electrum, but it would make sense to maintain both packages in the same
place.


> FYI, the new Git repo URL is currently:
> http://anonscm.debian.org/git/openstack/python/python-jsonrpclib.git


Thanks!

Bug#881703: Please package Electrum 3.0.2 -- updates after segwit softfork

[Tristan Seligmann]

Hi all,

I am currently doing final testing on an Electrum 3.0.2 package for Debian;
however I will need to wait for python3-jsonrpclib-pelix to go through NEW
before I can upload (upstream is using a jsonrpclib fork to get Python 3
support) so it may still be a little while before this lands in unstable.

Bug#883717: Oops, correct patch

[Tristan Seligmann]

Oops. Actually correct patch attached this time.
>From e08d824f98d32e13c8252eae05afa96356c1d995 Mon Sep 17 00:00:00 2001
From: Tristan Seligmann <mithra...@mithrandi.net>
Date: Wed, 6 Dec 2017 21:02:34 +0200
Subject: [PATCH] Add Python 3 package

---
 debian/control | 26 --
 debian/rules   |  4 +++-
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 28a50a9..f3f8693 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Uploaders: Loic Dachary (OuoU) <l...@debian.org>,
Thomas Goirand <z...@debian.org>,
Ghe Rivero <ghe.riv...@stackops.com>,
Mehdi Abaakouk <sil...@sileht.net>
-Build-Depends: debhelper (>= 9), python-setuptools, python-all (>= 2.6.6-3~), openstack-pkg-tools
+Build-Depends: debhelper (>= 9), dh-python, python-setuptools, python-all (>= 2.6.6-3~), python3-setuptools, python3-all, openstack-pkg-tools
 Build-Depends-Indep: python-simplejson
 Standards-Version: 3.9.4
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=openstack/python-jsonrpclib.git
@@ -19,7 +19,7 @@ Architecture: all
 Pre-Depends: dpkg (>= 1.15.6~)
 Depends: ${python:Depends}, ${misc:Depends}, python-simplejson
 Recommends: ${python:Recommends}
-Description: implementation of the JSON-RPC v2.0 specification
+Description: implementation of the JSON-RPC v2.0 specification - Python 2
  This library implements the JSON-RPC 2.0 proposed specification in pure
  Python. It is designed to be as compatible with the syntax of xmlrpclib as
  possible (it extends where possible), so that projects using xmlrpclib could
@@ -31,3 +31,25 @@ Description: implementation of the JSON-RPC v2.0 specification
   * Keyword arguments
   * Notifications (both in a batch and 'normal')
   * Class translation using the 'jsonclass' key.
+ .
+ This package contains the Python 2 version of jsonrpclib.
+
+Package: python3-jsonrpclib
+Architecture: all
+Pre-Depends: dpkg (>= 1.15.6~)
+Depends: ${python3:Depends}, ${misc:Depends}, python3-simplejson
+Recommends: ${python3:Recommends}
+Description: implementation of the JSON-RPC v2.0 specification - Python 3
+ This library implements the JSON-RPC 2.0 proposed specification in pure
+ Python. It is designed to be as compatible with the syntax of xmlrpclib as
+ possible (it extends where possible), so that projects using xmlrpclib could
+ easily be modified to use JSON and experiment with the differences.
+ .
+ It is backwards-compatible with the 1.0 specification, and supports all of the
+ new proposed features of 2.0, including:
+  * Batch submission (via MultiCall)
+  * Keyword arguments
+  * Notifications (both in a batch and 'normal')
+  * Class translation using the 'jsonclass' key.
+ .
+ This package contains the Python 3 version of jsonrpclib.
diff --git a/debian/rules b/debian/rules
index 93e4913..5ca5e3e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,5 +4,7 @@ UPSTREAM_GIT = git://github.com//jsonrpclib.git
 include /usr/share/openstack-pkg-tools/pkgos.make
 
 %:
-	dh $@  --with python2
+	dh $@  --with python2,python3
 
+override_dh_auto_install:
+	pkgos-dh_auto_install
-- 
2.15.1

Bug#883717: python-jsonrpclib: Please package python3-jsonrpclib

[Tristan Seligmann]

Source: python-jsonrpclib
Version: 0.1.3-1
Severity: wishlist

electrum has switched to Python 3 as of 3.0, so python3-jsonrpclib will become
a reverse dependency. I've attached a patch to make this build.

As an aside, I see that this package seems to be undermaintained
(Vcs-{Git,Browser} are broken URLs, and there has been no upload since the
initial upload); I would like to volunteer to take over maintenance under
DPMT's umbrella if this would be acceptable.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), 
LANGUAGE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information
>From 467016f79243b4d3704fb721a3b8229a687a49a4 Mon Sep 17 00:00:00 2001
From: Tristan Seligmann <mithra...@mithrandi.net>
Date: Wed, 6 Dec 2017 21:02:34 +0200
Subject: [PATCH] Add Python 3 package

---
 0001-Add-Python-3-package.patch | 64 +
 debian/control  | 26 +++--
 debian/rules|  2 +-
 3 files changed, 89 insertions(+), 3 deletions(-)
 create mode 100644 0001-Add-Python-3-package.patch

diff --git a/0001-Add-Python-3-package.patch b/0001-Add-Python-3-package.patch
new file mode 100644
index 000..89d6fd7
--- /dev/null
+++ b/0001-Add-Python-3-package.patch
@@ -0,0 +1,64 @@
+From 7b1dd7a19a9f0d4ae2ac3a7e8270ac9b9043b5d6 Mon Sep 17 00:00:00 2001
+From: Tristan Seligmann <mithra...@mithrandi.net>
+Date: Wed, 6 Dec 2017 21:02:34 +0200
+Subject: [PATCH] Add Python 3 package
+
+---
+ debian/control | 22 --
+ debian/rules   |  2 +-
+ 2 files changed, 21 insertions(+), 3 deletions(-)
+
+diff --git a/debian/control b/debian/control
+index 28a50a9..e032d83 100644
+--- a/debian/control
 b/debian/control
+@@ -7,7 +7,7 @@ Uploaders: Loic Dachary (OuoU) <l...@debian.org>,
+Thomas Goirand <z...@debian.org>,
+Ghe Rivero <ghe.riv...@stackops.com>,
+Mehdi Abaakouk <sil...@sileht.net>
+-Build-Depends: debhelper (>= 9), python-setuptools, python-all (>= 2.6.6-3~), 
openstack-pkg-tools
++Build-Depends: debhelper (>= 9), python-setuptools, python-all (>= 2.6.6-3~), 
python3-setuptools, python3-all, openstack-pkg-tools
+ Build-Depends-Indep: python-simplejson
+ Standards-Version: 3.9.4
+ Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=openstack/python-jsonrpclib.git
+@@ -19,7 +19,25 @@ Architecture: all
+ Pre-Depends: dpkg (>= 1.15.6~)
+ Depends: ${python:Depends}, ${misc:Depends}, python-simplejson
+ Recommends: ${python:Recommends}
+-Description: implementation of the JSON-RPC v2.0 specification
++Description: implementation of the JSON-RPC v2.0 specification - Python 2
++ This library implements the JSON-RPC 2.0 proposed specification in pure
++ Python. It is designed to be as compatible with the syntax of xmlrpclib as
++ possible (it extends where possible), so that projects using xmlrpclib could
++ easily be modified to use JSON and experiment with the differences.
++ .
++ It is backwards-compatible with the 1.0 specification, and supports all of 
the
++ new proposed features of 2.0, including:
++  * Batch submission (via MultiCall)
++  * Keyword arguments
++  * Notifications (both in a batch and 'normal')
++  * Class translation using the 'jsonclass' key.
++
++Package: python3-jsonrpclib
++Architecture: all
++Pre-Depends: dpkg (>= 1.15.6~)
++Depends: ${python3:Depends}, ${misc:Depends}, python3-simplejson
++Recommends: ${python3:Recommends}
++Description: implementation of the JSON-RPC v2.0 specification - Python 3
+  This library implements the JSON-RPC 2.0 proposed specification in pure
+  Python. It is designed to be as compatible with the syntax of xmlrpclib as
+  possible (it extends where possible), so that projects using xmlrpclib could
+diff --git a/debian/rules b/debian/rules
+index 93e4913..9c0060f 100755
+--- a/debian/rules
 b/debian/rules
+@@ -4,5 +4,5 @@ UPSTREAM_GIT = git://github.com//jsonrpclib.git
+ include /usr/share/openstack-pkg-tools/pkgos.make
+ 
+ %:
+-  dh $@  --with python2
++  dh $@  --with python2,python3
+ 
+-- 
+2.15.1
+
diff --git a/debian/control b/debian/control
index 28a50a9..a3f93aa 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Uploaders: Loic Dachary (OuoU) <l...@debian.org>,
Thomas Goirand <z...@debian.org>,
Ghe Rivero <ghe.riv...@stackops.com>,
Mehdi Abaakouk <sil...@sileht.net>
-Build-Depends: debhelper (>= 9), python-setuptools, python-all (>= 2.6.6-3~), 
openstack-pkg-tools
+Build-Depends: debhelper (>= 9), python-setuptools, python-all

Bug#882170: python-cryptography: missing dependency on python-cffi

[Tristan Seligmann]

Control: retitle -1 python-cryptography: extraneous setuptools dependency
on cffi
Control: tags -1 + pending

Argh! This is caused by an incomplete fix for #882011 of course.

On Sun, 19 Nov 2017 at 22:45 Adrian Bunk  wrote:

> pkg_resources.DistributionNotFound: The 'cffi>=1.7' distribution was not
> found and is required by cryptography
>

This problem is actually backwards from what it seems; python-cffi has a
pydist file that translates into a dependency on python-cffi-backend only
as python-cffi is not needed at runtime, and translated dependencies are
removed from requires.txt by dh_python2. However, since dh_python2 doesn't
understand the environment marker in the dependency, we are passing
--depends=cffi manually to take care of the dependency; unfortunately the
entry in requires.txt is thus not removed, so setuptools/pkg_resources
think that cffi needs to be available.

Stripping out the untranslated distributions from requires.txt ourselves
should fix this, I'll upload this fix once I've done a little more testing.

Bug#881458: hlint fails to run

[Tristan Seligmann]

Package: hlint
Version: 2.0.9-1+b1
Severity: important

hlint fails to run on everything with this error:

hlint: user error (Failed to find requested hint files:
  /usr/share/hlint/hlint.yaml
)   

That file does indeed not exist (and is not present in the hlint package).

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8), 
LANGUAGE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hlint depends on:
ii  libc62.24-17
ii  libffi6  3.2.1-6
ii  libgmp10 2:6.1.2+dfsg-1.1
ii  libyaml-0-2  0.1.7-2

Versions of packages hlint recommends:
ii  ghc  8.0.2-10

hlint suggests no packages.

-- no debconf information

Bug#871994: python-cryptography FTBFS: TypeError: putenv() argument 2 must be string without null bytes, not str

[Tristan Seligmann]

On Sun, 13 Aug 2017 at 14:36 Adrian Bunk  wrote:

> Some recent change in unstable makes python-cryptography FTBFS:
>

Control: reassign -1 python-pytest
Control: affects -1 python-cryptography
Control: tags -1 + upstream fixed-upstream

This is caused by an upstream bug in pytest, that should be fixed by pytest
3.2.1: https://github.com/pytest-dev/pytest/issues/2644

Bug#870091: ITP: pyaes -- Pure-Python Implementation of the AES block-cipher and common modes of operation

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann <mithra...@mithrandi.net>

* Package name: pyaes
  Version : 1.6.0
  Upstream Author : Richard Moore <py...@ricmoo.com>
* URL : https://github.com/ricmoo/pyaes
* License : License :: OSI Approved :: MIT License
  Programming Lang: Python
  Description : Pure-Python Implementation of the AES block-cipher and 
common modes of operation

Binary package names: python-pyaes

 A pure-Python implementation of the AES (FIPS-197)
 block-cipher algorithm and common modes of operation (CBC, CFB, CTR, ECB,
 OFB) with no dependencies beyond standard Python libraries. See README.md
 for API reference and details.

I intend to maintain this under the Debian Python Modules Team.

Bug#866668: src:python-cryptography: Misbuild with more than one supported python3 version

[Tristan Seligmann]

Control: severity -1 important

On Fri, 30 Jun 2017 at 19:33 Scott Kitterman  wrote:

> Technically, it builds, but in a way that's not useful.  It would actually
> be
> better if it had failed (I noticed this from reviewing build logs after the
> python3 interpreter depends weren't generated correctly).
>

In fact, the package works fine on python3.5 as well as python3.6 (the
module imports, and the full test suite passes against the installed
modules), thus I'm downgrading the severity of this bug.

During the build, the extension modules are first built on python3.5, and
it is these modules that land in /usr/lib/python3, with the "abi3" ABI tag.
The extension modules are then built again on python3.6, but these don't
get moved into /usr/lib/python3 due to the files from the python3.5 build
having the same name, thus landing in an incorrect directory in the  final
package and serving no useful purpose.

The reason the package still works is the "abi3" ABI tag; these modules
(like all CFFI-built modules, by default) are using the Python 3 "stable
ABI"[1] so the modules built on python3.5 work fine when imported on
python3.6, and vice-versa. I think what this means is that we only need to
run the Python 3 build once (using the default version?); also, I think the
interpreter depends are in fact correct in light of this. I tested
downgrading to 1.7.1-3 and the module still imports and works on python3.6,
even though 1.7.1-3 was only ever built against python3.5.

However, testing against all supported versions at build time is probably
still appropriate.

I'm looping in debian-python here as others may be surprised by this
combination of effects as well, and we should probably be handling the
issue of modules using the stable ABI consistently. Also, I'm not 100%
certain what the best way forward is here; teach pybuild/dh_python3 about
the stable ABI?

[1] https://docs.python.org/3/c-api/stable.html

Bug#866553: python-cryptography FTBFS with python 3.6

[Tristan Seligmann]

On Fri, 30 Jun 2017 at 04:45 Adrian Bunk  wrote:

>   File "/usr/lib/python3/dist-packages/cffi/api.py", line 56, in __init__
> import _cffi_backend as backend
> ModuleNotFoundError: No module named '_cffi_backend'
>

The cause of this error is that Python 3.6 was just added to supported, but
python-cffi has not yet been rebuilt for Python 3.6, and thus
python3-cffi-backend does not contain a Python 3.6 module.
python-cryptography was stuck in BD-Uninstallable until now due to
asn1crypto being in NEW, so I guess this is a case of unfortunate timing.

Should this bug be reassigned to python-cffi?

Bug#862277: python-cryptography: Importing the cryptography.hazmat.backends module is very slow

[Tristan Seligmann]

On Wed, 10 May 2017 at 16:36 David Douard  wrote:

> the loading of the cryptography.hazmat.backends module is very slow on
> my stretch machine:
>

This is ultimately caused by pkg_resources doing slow things at import time:

https://github.com/pypa/setuptools/issues/510

Cryptography 1.8.1 includes a workaround deferring the import of
pkg_resources to when default_backend is called:

https://github.com/pyca/cryptography/commit/aa396c0805aced49d5502fafa20f304a23e369a7

Which probably explains your virtualenv results.

However, given that stretch is frozen now, I'm not sure there is anything
to be done about it at this stage.

Bug#850003: jessie-pu: package python-cryptography/0.6.1-1+deb8u1

[Tristan Seligmann]

Sorry, real life caught up with me, but I've just uploaded this now.
(Hopefully I did it right, since this is my first p-u upload)

On Sat, 15 Apr 2017 at 13:18 Salvatore Bonaccorso <car...@debian.org> wrote:

> Hi Tristan,
>
> On Sun, Apr 02, 2017 at 09:40:29PM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> >
> > On Tue, 2017-01-03 at 06:09 +0200, Tristan Seligmann wrote:
> > > Backport the fix for CVE-2016-9243 which was deemed not severe enough
> for a
> > > DSA. I've attached a full debdiff, the patch is quite small and
> self-contained,
> > > although I needed another patch to fix building against the libssl now
> in
> > > jessie.
> >
> > Apologies for the delay in getting back to you.
> >
> > Please go ahead.
>
> Any news for the upload?
>
> Regards,
> Salvatore
>

Bug#857278: python-nacl: sodium_init() fails because already initialized.

[Tristan Seligmann]

On Wed, 15 Mar 2017 at 07:39  wrote:

> This patch is no longer required now as this issue has been fixed with
> the new release 1.1.0 in upstream.
>

Thanks for tracking / following up on this issue; I have been paying
attention despite the silence from my side, and it is appreciated :)

I'm planning to look at uploading the new release in the next few days;
should be by the end of the weekend at the latest.

Bug#857006: python-urllib3: Missing version constraint for six

[Tristan Seligmann]

On Wed, 8 Mar 2017 at 02:11 Daniele Tricoli  wrote:

> I will add the >= 1.10.0, on the next upload. I plan to upload
> urllib 1.20 to experimental soon.
>
> Should I need to backport this also for Stretch?
>

I think it's not critical to backport it; CCing hlieberman for a second
opinion, since he originally discovered the issue while trying to build
certbot.

Bug#857006: python-urllib3: Missing version constraint for six

[Tristan Seligmann]

Package: python-urllib3
Version: 1.19.1-1
Severity: important

setup.py does not have a version constraint on six as it is vendored upstream,
but since we are unvendoring it in Debian, we need a version constraint. This
is made trickier by the fact that upstream won't be tracking the minimum
version for us, as they only need to care about the specific version they
vendor. Perhaps a >=  constraint in Debian would be
the easiest?

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-urllib3 depends on:
ii  python-six  1.10.0-4
pn  python:any  

Versions of packages python-urllib3 recommends:
ii  ca-certificates  20161130
ii  python-cryptography  1.7.1-2
ii  python-idna  2.2-1
ii  python-ipaddress 1.0.17-1
ii  python-openssl   16.2.0-1

Versions of packages python-urllib3 suggests:
pn  python-ntlm   
pn  python-socks  

-- no debconf information

Bug#850003: jessie-pu: package python-cryptography/0.6.1-1+deb8u1

[Tristan Seligmann]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Backport the fix for CVE-2016-9243 which was deemed not severe enough for a
DSA. I've attached a full debdiff, the patch is quite small and self-contained,
although I needed another patch to fix building against the libssl now in
jessie.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru python-cryptography-0.6.1/debian/changelog 
python-cryptography-0.6.1/debian/changelog
--- python-cryptography-0.6.1/debian/changelog  2014-10-16 06:46:31.0 
+0200
+++ python-cryptography-0.6.1/debian/changelog  2017-01-01 22:19:17.0 
+0200
@@ -1,3 +1,12 @@
+python-cryptography (0.6.1-1+deb8u1) stable; urgency=high
+
+  * Stable update.
+  * Backport the fix for CVE-2016-9243 (HKDF returns an empty byte string
+for small key sizes).
+  * Fix FTBFS due to SSL2 method detection.
+
+ -- Tristan Seligmann <mithra...@debian.org>  Sun, 01 Jan 2017 22:19:17 +0200
+
 python-cryptography (0.6.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru python-cryptography-0.6.1/debian/patches/3215.patch 
python-cryptography-0.6.1/debian/patches/3215.patch
--- python-cryptography-0.6.1/debian/patches/3215.patch 1970-01-01 
02:00:00.0 +0200
+++ python-cryptography-0.6.1/debian/patches/3215.patch 2017-01-01 
22:19:17.0 +0200
@@ -0,0 +1,40 @@
+From d945a5213f2b2bbb189bbc2be407aa35e0dab204 Mon Sep 17 00:00:00 2001
+From: Alex Gaynor <alex.gay...@gmail.com>
+Date: Sat, 5 Nov 2016 21:18:15 -0400
+Subject: [PATCH] Fixes #3211 -- fixed hkdf's output with short length
+
+Index: python-cryptography/cryptography/hazmat/primitives/kdf/hkdf.py
+===
+--- python-cryptography.orig/cryptography/hazmat/primitives/kdf/hkdf.py
2017-01-01 22:24:27.090828930 +0200
 python-cryptography/cryptography/hazmat/primitives/kdf/hkdf.py 
2017-01-01 22:24:27.086828861 +0200
+@@ -99,7 +99,7 @@
+ output = [b""]
+ counter = 1
+ 
+-while (self._algorithm.digest_size // 8) * len(output) < self._length:
++while self._algorithm.digest_size * (len(output) - 1) < self._length:
+ h = hmac.HMAC(key_material, self._algorithm, 
backend=self._backend)
+ h.update(output[-1])
+ h.update(self._info)
+Index: python-cryptography/tests/hazmat/primitives/test_hkdf.py
+===
+--- python-cryptography.orig/tests/hazmat/primitives/test_hkdf.py  
2017-01-01 22:24:27.090828930 +0200
 python-cryptography/tests/hazmat/primitives/test_hkdf.py   2017-01-01 
22:24:27.086828861 +0200
+@@ -152,6 +152,17 @@
+ 
+ hkdf.verify(b"foo", six.u("bar"))
+ 
++def test_derive_short_output(self, backend):
++hkdf = HKDF(
++hashes.SHA256(),
++4,
++salt=None,
++info=None,
++backend=backend
++)
++
++assert hkdf.derive(b"\x01" * 16) == b"gJ\xfb{"
++
+ 
+ @pytest.mark.hmac
+ class TestHKDFExpand(object):
diff -Nru python-cryptography-0.6.1/debian/patches/series 
python-cryptography-0.6.1/debian/patches/series
--- python-cryptography-0.6.1/debian/patches/series 1970-01-01 
02:00:00.0 +0200
+++ python-cryptography-0.6.1/debian/patches/series 2017-01-01 
22:19:17.0 +0200
@@ -0,0 +1,2 @@
+ssl2-detection.patch
+3215.patch
diff -Nru python-cryptography-0.6.1/debian/patches/ssl2-detection.patch 
python-cryptography-0.6.1/debian/patches/ssl2-detection.patch
--- python-cryptography-0.6.1/debian/patches/ssl2-detection.patch   
1970-01-01 02:00:00.0 +0200
+++ python-cryptography-0.6.1/debian/patches/ssl2-detection.patch   
2017-01-01 22:19:17.0 +0200
@@ -0,0 +1,13 @@
+Index: python-cryptography/cryptography/hazmat/bindings/openssl/ssl.py
+===
+--- python-cryptography.orig/cryptography/hazmat/bindings/openssl/ssl.py   
2017-01-01 22:33:41.640198755 +0200
 python-cryptography/cryptography/hazmat/bindings/openssl/ssl.py
2017-01-01 22:34:20.336845122 +0200
+@@ -384,7 +384,7 @@
+ #else
+ static const long Cryptography_HAS_SECURE_RENEGOTIATION = 1;
+ #endif
+-#ifdef OPENSSL_NO_SSL2
++#ifdef OPENSSL_NO_SSL2_METHOD
+ static const long Cryptography_HAS_SSL2 = 0;
+ SSL_METHOD* (*SSLv2_method)(void) = NULL;
+ SSL_METHOD* (*SSLv2_client_method)(void) = NULL;

Bug#849379: whalebuilder: Relax dependency on docker.io

[Tristan Seligmann]

Package: whalebuilder
Version: 0.4.1
Severity: wishlist

I'd like to be able to use this package with the upstream Docker packages
instead of the Debian ones (since I need the former installed for other
reasons, and they can't be installed simultaneously); what about relaxing the
dependency to something like "docker.io | docker-engine"?

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#848065: python-cryptography: renders ansible unusable

[Tristan Seligmann]

Control: notfound -1 1.5.3-1

You have an installation of PyOpenSSL in
/home/pjs/.local/lib/python2.7/site-packages that is not compatible with
Cryptography 1.5.3; removing or upgrading this should solve your problem.

To avoid this kind of problem in future, I would recommend using virtualenv
rather than installing things to ~/.local, as packages in a virtualenv will
not interfere with the system Python like ~/.local / --user packages will.

On Tue, 13 Dec 2016 at 20:03 Paulo Silva  wrote:

> Package: python-cryptography
> Version: 1.5.3-1
> Severity: critical
> Justification: breaks unrelated software
>
> Upgrading python-cryptography from 1.5.2-1 to 1.5.3-1 renders ansible
> unusable:
>
> $ ansible-playbook -vvv playbook.yml
> ERROR! Unexpected Exception: 'module' object has no attribute 'SSL_ST_INIT'
> the full traceback was:
>
> Traceback (most recent call last):
>   File "/usr/bin/ansible-playbook", line 103, in 
> exit_code = cli.run()
>   File "/usr/lib/python2.7/dist-packages/ansible/cli/playbook.py", line
> 159, in run
> results = pbex.run()
>   File
> "/usr/lib/python2.7/dist-packages/ansible/executor/playbook_executor.py",
> line 89, in run
> self._tqm.load_callbacks()
>   File
> "/usr/lib/python2.7/dist-packages/ansible/executor/task_queue_manager.py",
> line 177, in load_callbacks
> for callback_plugin in callback_loader.all(class_only=True):
>   File "/usr/lib/python2.7/dist-packages/ansible/plugins/__init__.py",
> line 394, in all
> self._module_cache[path] = self._load_module_source(name, path)
>   File "/usr/lib/python2.7/dist-packages/ansible/plugins/__init__.py",
> line 324, in _load_module_source
> module = imp.load_source(name, path, module_file)
>   File
> "/usr/lib/python2.7/dist-packages/ansible/plugins/callback/hipchat.py",
> line 32, in 
> from ansible.module_utils.urls import open_url
>   File "/usr/lib/python2.7/dist-packages/ansible/module_utils/urls.py",
> line 150, in 
> from urllib3.contrib.pyopenssl import ssl_wrap_socket
>   File "/usr/lib/python2.7/dist-packages/urllib3/contrib/pyopenssl.py",
> line 47, in 
> import OpenSSL.SSL
>   File "/home/pjs/.local/lib/python2.7/site-packages/OpenSSL/__init__.py",
> line 8, in 
> from OpenSSL import rand, crypto, SSL
>   File "/home/pjs/.local/lib/python2.7/site-packages/OpenSSL/SSL.py", line
> 124, in 
> SSL_ST_INIT = _lib.SSL_ST_INIT
> AttributeError: 'module' object has no attribute 'SSL_ST_INIT'
>
> Downgrading to python-cryptography to 1.5.2-1 fixes the issue:
>
> $ sudo dpkg -i
> /var/cache/apt/archives/python-cryptography_1.5.2-1_amd64.deb
> dpkg: warning: downgrading python-cryptography from 1.5.3-1 to 1.5.2-1
> (Reading database ... 575660 files and directories currently installed.)
> Preparing to unpack .../python-cryptography_1.5.2-1_amd64.deb ...
> Unpacking python-cryptography (1.5.2-1) over (1.5.3-1) ...
> Setting up python-cryptography (1.5.2-1) ...
>
> $ ansible-playbook -vvv playbook.yml
> PLAYBOOK: playbook.yml
> *
> (...)
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500,
> 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages python-cryptography depends on:
> ii  libc62.24-8
> ii  libssl1.11.1.0c-2
> ii  python   2.7.11-2
> pn  python-cffi-backend-api-max  
> pn  python-cffi-backend-api-min  
> ii  python-enum341.1.6-1
> ii  python-idna  2.1-1
> ii  python-ipaddress 1.0.17-1
> ii  python-pyasn10.1.9-2
> ii  python-setuptools28.7.1-1
> ii  python-six   1.10.0-3
> pn  python:any   
>
> python-cryptography recommends no packages.
>
> Versions of packages python-cryptography suggests:
> pn  python-cryptography-doc  
> ii  python-cryptography-vectors  1.5.3-1
>
> -- no debconf information
>

Bug#843631: Root cause

[Tristan Seligmann]

Control: retitle 843631 Downstream incompatibilities due to SSL_ST_*
constants not defined in OpenSSL 1.1.0

I think I have it figured out now:

OpenSSL 1.1.0 was uploaded to unstable recently, which no longer defines
(some of?) these SSL_ST_* constants. python-cryptography 1.5.2 was uploaded
and built in unstable prior to this, so it still has the values built into
the binary, but upon rebuilding against the new libssl, they are no longer
present as they cannot be found at build time. My 1.5.3 upload happened to
be the first time the package was rebuilt against libssl1.1, thus
triggering the problem.

This is indeed fixed upstream in pyopenssl 16.2.0[1], where they now
conditionally check for the presence of these constants.

Sandro: I don't think I can fix this properly from the cryptography side
since these constants are actually gone from libssl, but since they only
need to _exist_ and not actually _work_ in order to import the "OpenSSL"
module, I could try to implement a workaround that defines them to some
nonsense value if you think that would be better than waiting on an updated
python-openssl.

I'm also happy to help with preparing the python-openssl update, although I
understand that you may not be interested in further "help" from me right
at the moment.

[1] See https://github.com/pyca/pyopenssl/issues/525

Bug#843631: AttributeError: 'module' object has no attribute 'SSL_ST_INIT'

[Tristan Seligmann]

Hi Sandro,

I appreciate your frustration here, and as the maintainer of
python-cryptography of course I'm responsible when there are issues with
the package.

That said, I did actually test pyopenssl before uploading this version, and
it was working locally; in addition, the diff from 1.5.2 to 1.5.3 is almost
trivial (I've attached it for reference); the HKDF fix is a one line change
plus an added test, and the only other changes are bumping the version
number, so I'm still looking into the actual cause of the problem.

I think the mistake I made when testing locally was that I didn't update my
build chroot first; if the problem is related to newer build-dependencies
(eg. python-cffi) then that would explain why my local package does not
exhibit the problem while the one from the buildds does. (Of course this is
the result of rushing the 1.5.3 update; I do know better than to rush out a
"trivial" update, as these things often turn out to be less trivial than
assumed, but I felt there was some urgency to getting the new package into
unstable as the security issue is more likely to affect users there and I
guess I let this override my better judgement)

I will follow up again once I track down the root cause of the problem.
commit c551c1690dc2ec0a12f779eaab780da45e40d1c6
Author: Tristan Seligmann <mithra...@debian.org>
Date:   Tue Nov 8 05:34:19 2016 +0200

Import python-cryptography_1.5.3.orig.tar.gz

diff --git a/CHANGELOG.rst b/CHANGELOG.rst
index 0bfd328..9b0bf29 100644
--- a/CHANGELOG.rst
+++ b/CHANGELOG.rst
@@ -1,6 +1,13 @@
 Changelog
 =
 
+1.5.3 - 2016-11-05
+~~
+
+* **SECURITY ISSUE**: Fixed a bug where ``HKDF`` would return an empty
+  byte-string if used with a ``length`` less than ``algorithm.digest_size``.
+  Credit to **Markus Döring** for reporting the issue.
+
 1.5.2 - 2016-09-26
 ~~
 
diff --git a/PKG-INFO b/PKG-INFO
index 3c67042..9de24de 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
 Metadata-Version: 1.1
 Name: cryptography
-Version: 1.5.2
+Version: 1.5.3
 Summary: cryptography is a package which provides cryptographic recipes and primitives to Python developers.
 Home-page: https://github.com/pyca/cryptography
 Author: The cryptography developers
diff --git a/src/cryptography.egg-info/PKG-INFO b/src/cryptography.egg-info/PKG-INFO
index 3c67042..9de24de 100644
--- a/src/cryptography.egg-info/PKG-INFO
+++ b/src/cryptography.egg-info/PKG-INFO
@@ -1,6 +1,6 @@
 Metadata-Version: 1.1
 Name: cryptography
-Version: 1.5.2
+Version: 1.5.3
 Summary: cryptography is a package which provides cryptographic recipes and primitives to Python developers.
 Home-page: https://github.com/pyca/cryptography
 Author: The cryptography developers
diff --git a/src/cryptography/__about__.py b/src/cryptography/__about__.py
index 02d6494..6baca0d 100644
--- a/src/cryptography/__about__.py
+++ b/src/cryptography/__about__.py
@@ -14,7 +14,7 @@ __summary__ = ("cryptography is a package which provides cryptographic recipes"
" and primitives to Python developers.")
 __uri__ = "https://github.com/pyca/cryptography;
 
-__version__ = "1.5.2"
+__version__ = "1.5.3"
 
 __author__ = "The cryptography developers"
 __email__ = "cryptography-...@python.org"
diff --git a/src/cryptography/hazmat/primitives/kdf/hkdf.py b/src/cryptography/hazmat/primitives/kdf/hkdf.py
index f738bbd..82ed9b1 100644
--- a/src/cryptography/hazmat/primitives/kdf/hkdf.py
+++ b/src/cryptography/hazmat/primitives/kdf/hkdf.py
@@ -91,7 +91,7 @@ class HKDFExpand(object):
 output = [b""]
 counter = 1
 
-while (self._algorithm.digest_size // 8) * len(output) < self._length:
+while self._algorithm.digest_size * (len(output) - 1) < self._length:
 h = hmac.HMAC(key_material, self._algorithm, backend=self._backend)
 h.update(output[-1])
 h.update(self._info)
diff --git a/tests/hazmat/primitives/test_hkdf.py b/tests/hazmat/primitives/test_hkdf.py
index e33529c..a05fd75 100644
--- a/tests/hazmat/primitives/test_hkdf.py
+++ b/tests/hazmat/primitives/test_hkdf.py
@@ -142,6 +142,17 @@ class TestHKDF(object):
 
 hkdf.verify(b"foo", u"bar")
 
+def test_derive_short_output(self, backend):
+hkdf = HKDF(
+hashes.SHA256(),
+4,
+salt=None,
+info=None,
+backend=backend
+)
+
+assert hkdf.derive(b"\x01" * 16) == b"gJ\xfb{"
+
 
 @pytest.mark.requires_backend_interface(interface=HMACBackend)
 class TestHKDFExpand(object):

Bug#835543: python-pip-whl: Unable to create virtualenv

[Tristan Seligmann]

Package: python-pip-whl
Version: 8.1.2-2
Severity: important

  File 
"/usr/share/python-wheels/pip-8.1.2-py2.py3-none-any.whl/pip/__init__.py", line 
21, in 
from pip._vendor.requests.packages.urllib3.exceptions import 
DependencyWarning
ImportError: cannot import name 'DependencyWarning'

Not sure what's going on here, but I guess a vendored package is out of sync?

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-pip-whl depends on:
ii  ca-certificates  20160104

python-pip-whl recommends no packages.

python-pip-whl suggests no packages.

-- no debconf information

Bug#833679: BitPaddedInt import error

[Tristan Seligmann]

Control: reassign -1 picard
Control: forwarded -1 http://tickets.musicbrainz.org/browse/PICARD-833

Your hypothesis was correct: `mutagen.id3.BitPaddedInt`used to be imported
from `mutagen._id3util.BitPaddedInt` in `mutagen.id3`; however, `id3` was
turned into a package, so now the import doesn't leak anymore. In addition,
the helper class itself moved to `mutagen.id3._util.BitPaddedInt`.

Looks like this was reported upstream recently as well:
http://tickets.musicbrainz.org/browse/PICARD-833

I'm reassigning to picard, as I don't think fixing this in mutagen is the
right thing to do.

On Sun, 7 Aug 2016 at 21:51 Jamie Heilman 
wrote:

> Package: python-mutagen
> Version: 1.34-1
>
>
> Picard can't even start anymore with the latest python-mutagen
> package:
>
> Traceback (most recent call last):
>   File "/usr/bin/picard", line 2, in 
> from picard.tagger import main; main('/usr/share/locale', True)
>   File "/usr/lib/picard/picard/tagger.py", line 65, in 
> from picard.formats import open as open_file
>   File "/usr/lib/picard/picard/formats/__init__.py", line 157, in 
> from picard.formats.id3 import (
>   File "/usr/lib/picard/picard/formats/id3.py", line 30, in 
> from picard.formats.mutagenext import compatid3
>   File "/usr/lib/picard/picard/formats/mutagenext/compatid3.py", line 25,
> in 
> from mutagen.id3 import ID3, Frames, Frames_2_2, TextFrame, TORY, \
> ImportError: cannot import name BitPaddedInt
>
> I haven't dug any deeper to establish if this is the callers
> fault for relying on leaked namespaces or just API breakage.
>
> --
> Jamie Heilman http://audible.transient.net/~jamie/
>

Bug#802582: [Python-apps-team] Bug#802582: isort: Missing isort for python2

[Tristan Seligmann]

On Tue, 19 Jul 2016 at 19:58 Sandro Tosi  wrote:

> any update on this? i have pylint which depends on isort now, and I
> cant package it because isort doesnt expose a python2 package - please
> have a look at it asap, thanks!
>

Sorry, I pretty much forgot about this bug. Originally it was blocked on
some issues with pies2overrides, but since isort no longer depends on
pies2overrides there should be no obstacle to shipping a Python 2 package
any longer.

I will take a look at it again and upload later tonight (assuming I don't
run into any other issues).

Bug#828518:

[Tristan Seligmann]

Control: tag -1 + pending upstream

Upstream have OpenSSL 1.1.0 support nearly ready to go, basically just
waiting on the final 1.1.0 release to be out. See:

https://github.com/pyca/cryptography/milestones/1.1.0%20Support

Bug#820962: ruby: File conflict between ruby 1:2.3.0+3 and ruby-dev 1:2.3.0+1

[Tristan Seligmann]

Package: ruby
Version: 1:2.3.0+3
Severity: serious
Justification: Policy 7.6.1

Unpacking ruby (1:2.3.0+3) over (1:2.3.0+1) ...
dpkg: error processing archive 
/var/cache/apt/archives/ruby_1%3a2.3.0+3_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/pkgconfig/ruby.pc', which is 
also in package ruby-dev:amd64 1:2.3.0+1
Errors were encountered while processing:
 /var/cache/apt/archives/ruby_1%3a2.3.0+3_amd64.deb

It looks like Breaks/Replaces are needed here.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ruby depends on:
ii  ruby2.3  2.3.0-5

ruby recommends no packages.

Versions of packages ruby suggests:
pn  ri
ii  ruby-dev  1:2.3.0+3

-- no debconf information

Bug#816063: SNI

[Tristan Seligmann]

The reason https://self-signed.badssl.com works is because Emacs 24 does
not do SNI; badssl.com serves up a cert valid for "*.badssl.com" in the
absence of SNI, which is perfectly valid for self-signed.badssl.com.

This is apparently fixed upstream already:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20465

Bug#816735: python-flake8: Missing dependency on python-pep8

[Tristan Seligmann]

Package: python-flake8
Version: 2.2.2-1
Severity: important

There is a dependency on pep8, but this is not sufficient (pep8 only pulls in
python3-pep8):

mithrandi@lorien ~> flake8 --version
Traceback (most recent call last):
  File "/usr/bin/flake8", line 5, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3141, 
in 
@_call_aside
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3127, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3154, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 640, 
in _build_master
ws.require(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 941, 
in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 828, 
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pep8>=1.5.7' distribution was not 
found and is required by flake8


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-flake8 depends on:
ii  pep8   1.7.0-1
ii  pyflakes   1.0.0-4
ii  python 2.7.11-1
ii  python-mccabe  0.2.1-1

python-flake8 recommends no packages.

Versions of packages python-flake8 suggests:
pn  python-mock  

-- no debconf information

Bug#816043: pypy: bsddb module is broken

[Tristan Seligmann]

Package: pypy
Version: 4.0.1+dfsg-1
Severity: normal

The extension module seems to be missing:

Python 2.7.10 (4.0.1+dfsg-1, Nov 20 2015, 19:46:58)
[PyPy 4.0.1 with GCC 5.2.1 20151028] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 import bsddb
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/pypy/lib-python/2.7/bsddb/__init__.py", line 67, in 
import _bsddb
ImportError: No module named _bsddb



mithrandi@lorien ~> dpkg -L pypy | grep bsddb
mithrandi@lorien ~> dpkg -L pypy-lib | grep bsddb
/usr/lib/pypy/lib-python/2.7/bsddb
/usr/lib/pypy/lib-python/2.7/bsddb/dbutils.py
/usr/lib/pypy/lib-python/2.7/bsddb/dbtables.py
/usr/lib/pypy/lib-python/2.7/bsddb/dbshelve.py
/usr/lib/pypy/lib-python/2.7/bsddb/dbrecio.py
/usr/lib/pypy/lib-python/2.7/bsddb/dbobj.py
/usr/lib/pypy/lib-python/2.7/bsddb/db.py
/usr/lib/pypy/lib-python/2.7/bsddb/__init__.py


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pypy depends on:
ii  dpkg  1.18.4
ii  libbz2-1.01.0.6-8
ii  libc6 2.21-9
ii  libexpat1 2.1.0-7
ii  libffi6   3.2.1-4
ii  libgdbm3  1.8.3-13.1
ii  libncurses5   6.0+20160213-1
ii  libsqlite3-0  3.11.0-2
ii  libssl1.0.2   1.0.2f-2
ii  libtinfo5 6.0+20160213-1
ii  pypy-lib  4.0.1+dfsg-1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages pypy recommends:
ii  libunwind-dev  1.1-4.1

Versions of packages pypy suggests:
pn  pypy-doc  
pn  pypy-tk   

-- no debconf information

Bug#808433: nethogs: diff for NMU version 0.8.1-0.3

[Tristan Seligmann]

Control: tags 808433 + patch

Dear maintainer,

I've prepared an NMU for nethogs (versioned as 0.8.1-0.3). The diff
is attached to this message.

(This is just Arnout Engelen's package from mentors, with a tiny tweak to the
changelog)

Regards.
diff -Nru nethogs-0.8.0/Changelog nethogs-0.8.1/Changelog
--- nethogs-0.8.0/Changelog 2010-08-31 23:16:32.0 +0200
+++ nethogs-0.8.1/Changelog 2015-12-20 21:14:42.0 +0200
@@ -1,5 +1,15 @@
 Changelog
 
+12/05/13 (muzso)
+- added new command line switches:
+  -s  Sorts output by the sent column.
+  -c  Limits the number of updates (useful for tracemode and scripting the
+  output).
+  -v  Sets view mode (0 = KB/s, 1 = total KB, 2 = total B, 3 = total MB)
+- changed needrefresh default value from true to false
+  (upon startup there's no useful info on network usage, so displaying
+   any results has no use for the user)
+
 31/08/10 (Arnout)
 - support for screens wider than 80 characters, thanks to Shock
   at https://bugs.launchpad.net/ubuntu/+source/nethogs/+bug/627626
@@ -18,7 +28,7 @@
 27/08/05 (Arnout)
 - giving all unknown connections their own
   `unknown' process
-- UDP support
+- Initial work on UDP support
 - investigated memleak, turns out to be a problem in libc:
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273051 
   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103142
diff -Nru nethogs-0.8.0/connection.cpp nethogs-0.8.1/connection.cpp
--- nethogs-0.8.0/connection.cpp2008-12-31 17:52:26.0 +0200
+++ nethogs-0.8.1/connection.cpp2015-12-20 21:14:42.0 +0200
@@ -1,19 +1,31 @@
+/* 
+ * connection.cpp
+ *
+ * Copyright (c) 2004-2006,2008 Arnout Engelen
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
USA.
+ *
+ */
+
+
 #include 
-#include 
+#include 
 #include 
 #include "nethogs.h"
 #include "connection.h"
-
-class ConnList
-{
-public:
-   ConnList (Connection * m_val = NULL, ConnList * m_next = NULL)
-   {
-   val = m_val; next = m_next;
-   }
-   Connection * val;
-   ConnList * next;
-};
+#include "process.h"
 
 ConnList * connections = NULL;
 
@@ -105,22 +117,22 @@
ConnList * prev_conn = NULL;
while (curr_conn != NULL)
{
-   if (curr_conn->val == this)
+   if (curr_conn->getVal() == this)
{
ConnList * todelete = curr_conn;
-   curr_conn = curr_conn->next;
+   curr_conn = curr_conn->getNext();
if (prev_conn == NULL)
{
connections = curr_conn;
} else {
-   prev_conn->next = curr_conn;
+   prev_conn->setNext(curr_conn);
}
delete (todelete);
}
else
{
prev_conn = curr_conn;
-   curr_conn = curr_conn->next;
+   curr_conn = curr_conn->getNext();
}
}
 }
@@ -153,43 +165,55 @@
}
 }
 
-/* 
- * finds connection to which this packet belongs.
- * a packet belongs to a connection if it matches
- * to its reference packet 
- */
-Connection * findConnection (Packet * packet)
-{
+Connection * findConnectionWithMatchingSource(Packet * packet) {
+   assert(packet->Outgoing());
+
ConnList * current = connections;
while (current != NULL)
{
-   /* the reference packet is always *outgoing* */
-   if (packet->match(current->val->refpacket))
+   /* the reference packet is always outgoing */
+   if (packet->matchSource(current->getVal()->refpacket))
{
-   return current->val;
+   return current->getVal();
}
 
-   current = current->next;
+   current = current->getNext();
}
+   return NULL;
+}
 
-   // Try again, now with the packet inverted:
-   current = connections;
-   Packet * invertedPacket = packet->newInverted();
-
+Connection * findConnectionWithMatchingRefpacketOrSource(Packet * packet) {
+   ConnList * current = connections;

Bug#815654: dh-python: dh_python does not understand environment markers

[Tristan Seligmann]

On Tue, 23 Feb 2016 at 14:12 Piotr Ożarowski <pi...@debian.org> wrote:

> [Tristan Seligmann, 2016-02-23]
> > As per subject; this may be a bit tricky to solve,
>
> I will not even try to support PEPs that are changed or replaced by
> another one every few months (i.e. most of them).
> Let me know once it's stable for at least a year or so.
>
> For now, I can only add a code to ignore additional data (if it's not
> done already)
>

They're already ignored, as dh_python ignores all extras for purposes of
calculating dependencies (they just look like extras with a leading colon
in the name). I don't mind if you're "wontfix" on this as it isn't very
important, but at least this bug report will be here for anyone who goes
looking for it.

Bug#815654: dh-python: dh_python does not understand environment markers

[Tristan Seligmann]

Package: dh-python
Version: 2.20151103
Severity: normal

As per subject; this may be a bit tricky to solve,

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-python depends on:
pn  python3:any  

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  libdpkg-perl  1.18.4

-- no debconf information

Bug#815387: ITP: python-attrs -- Python attributes without boilerplate

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann <mithra...@mithrandi.net>

* Package name: python-attrs
  Version : 15.2.0
  Upstream Author : Hynek Schlawack <h...@ox.cx>
* URL : https://github.com/hynek/attrs
* License : MIT
  Programming Lang: Python
  Description : Python attributes without boilerplate

attrs is an MIT-licensed Python package with class decorators that ease the
chores of implementing the most common attribute-related object protocol.

attrs is the successor to Characteristic, and is a dependency of
python-servicy-identity from 16.0.0.

Bug#815385: python-service-identity: Missing dependency on python-attrs

[Tristan Seligmann]

Package: python-service-identity
Version: 16.0.0-1
Severity: grave
Justification: renders package unusable

service_identity 16.0.0-1 requires python-attrs (upstream switched from
characteristic to attrs), but the Depends: is missing.

Also, it would be unsatisfiable due to attrs not being packaged yet, but I am
about to upload a package to NEW.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-service-identity depends on:
ii  python-openssl 0.15.1-2
ii  python-pyasn1  0.1.9-1
ii  python-pyasn1-modules  0.0.7-0.1
pn  python:any 

Versions of packages python-service-identity recommends:
ii  python-idna  2.0-3

python-service-identity suggests no packages.

-- no debconf information

Bug#815090: python-hypothesis: Fails to build reproducibly

[Tristan Seligmann]

Source: python-hypothesis
Version: 1.11.0-1
Severity: minor
Tags: upstream

setup.py calculates the "all" extra in a way that depends on dict ordering,
thus the setuptools-constructed requires.txt is not reproducible.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#811172: Fixed upstream

[Tristan Seligmann]

This is fixed in e7316a1 [1] upstream, may be worth backporting that patch.

[1] https://bitbucket.org/durin42/hg-git/commits/e7316a1

Bug#811386: ITP: python-genty -- Python library for test generation

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann <mithra...@mithrandi.net>

* Package name: python-genty
  Version : 1.3.0
  Upstream Author : Box <o...@box.com>
* URL : https://github.com/box/genty
* License : Apache 2.0
  Programming Lang: Python
  Description : Python library for test generation

Needed as a test dependency for python-flaky. I will maintain this under DPMT.

Bug#810643: python-axiom: FTBFS: test_sequence.TestSequenceOperations.test_slices: Second list contains 3 additional elements.

[Tristan Seligmann]

Control: forwarded -1 https://github.com/twisted/axiom/issues/56

These test failures are caused by sqlite3 3.10.0-1 being built with the
SQLITE_LIKE_DOESNT_MATCH_BLOBS compile-time option activated, which breaks
startswith/endswith on blob columns. I've opened an issue upstream to deal
with this, and hope to resolve it there shortly.

Bug#808763: Running pytest

[Tristan Seligmann]

If you want to run pytest with a particular version of python, then
"pythonX.Y -m pytest" is a much better way than relying on the py.test-X.Y
scripts.

Bug#808605: ITP: python-flaky -- Plugin for nose or py.test that automatically reruns flaky tests

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann <mithra...@mithrandi.net>

* Package name: python-flaky
  Version : 3.0.1
  Upstream Author : Box <o...@box.com>
* URL : https://github.com/box/flaky
* License : Apache License
  Programming Lang: Python
  Description : Plugin for nose or py.test that automatically reruns flaky 
tests

Binary package names: python3-flaky python-flaky pypy-flaky

Flaky is a plugin for nose or py.test that automatically reruns flaky tests.

Bug#807681: python3-pkg-resources: UnicodeDecodeError when parsing egg-info files with non-ASCII content

[Tristan Seligmann]

Package: python3-pkg-resources
Version: 18.7-1
Severity: important

An example of such a file can be found in python3-dialog (the Description
contains UTF-8 encoded non-breaking spaces), but I am sure there are others.

The failure traceback looks as follows (from trying to run an unrelated
package's setup.py):

Traceback (most recent call last):
  File "setup.py", line 17, in 
from setuptools.command.test import test as TestCommand
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 12, in 

from setuptools.extension import Extension
  File "/usr/lib/python3/dist-packages/setuptools/extension.py", line 8, in 

from .dist import _get_unpatched
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 19, in 
import pkg_resources
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3144, 
in 
@_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3130, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3157, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 649, in 
_build_master
ws = cls()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 642, in 
__init__
self.add_entry(entry)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 698, in 
add_entry
for dist in find_distributions(entry, True):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2136, 
in find_on_path
path_item, entry, metadata, precedence=DEVELOP_DIST
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2519, 
in from_location
version = cls._version_from_metadata(dist_path) or version
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2842, 
in _version_from_metadata
return _version_from_file(strm)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2483, 
in _version_from_file
line = next(iter(version_lines), '')
  File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 3559: 
ordinal not in range(128)

I thought this might be some locale issue, but LANG is set to a UTF-8 locale,
so it's not that.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pkg-resources depends on:
pn  python3:any  

python3-pkg-resources recommends no packages.

Versions of packages python3-pkg-resources suggests:
ii  python3-setuptools  18.7-1

-- no debconf information

Bug#807681: Further investigation

[Tristan Seligmann]

Upon further investigation, it seems this error is caused by something
(git-buildpackage?) setting LC_ALL=POSIX (which also overrides any LANG
setting); forcing LC_ALL to a UTF-8 locale solves the issue. So I guess
this is not a pkg_resources bug, but I'm not sure exactly where to reassign
it to.

Bug#805388: libcuda1: Multi-arch file mismatch

[Tristan Seligmann]

Package: libcuda1
Version: 352.55-3
Severity: serious
Justification: Policy 7.4

libcuda1 declares Multi-Arch: same; libcuda1:amd64 and libcuda1:i386 are not
co-installable in experimental due to differing file contents:

Preparing to unpack .../libcuda1_352.55-3_i386.deb ...
Unpacking libcuda1:i386 (352.55-3) ...
dpkg: error processing archive 
/var/cache/apt/archives/libcuda1_352.55-3_i386.deb (--unpack):
 trying to overwrite shared '/usr/share/lintian/overrides/libcuda1', which is 
different from other instances of package libcuda1:i386
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

-- Package-specific info:
uname -a:
Linux lorien 4.2.0-1-amd64 #1 SMP Debian 4.2.6-1 (2015-11-10) x86_64 GNU/Linux

/proc/version:
Linux version 4.2.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.3 
(Debian 4.9.3-5) ) #1 SMP Debian 4.2.6-1 (2015-11-10)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  352.55  Thu Oct  8 15:18:00 PDT 
2015
GCC version:  gcc version 4.9.3 (Debian 4.9.3-5) 

lspci 'VGA compatible controller [0300]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 
970] [10de:13c2] (rev a1) (prog-if 00 [VGA controller])
Subsystem: eVga.com. Corp. Device [3842:2974]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia

dmesg:


Device node permissions:
crw-rw+ 1 root video 226,   0 Nov 16 03:50 /dev/dri/card0
crw-rw-rw-+ 1 root root  195,   0 Nov 16 03:50 /dev/nvidia0
crw-rw-rw-+ 1 root root  195, 255 Nov 16 03:50 /dev/nvidiactl
video:x:44:mithrandi,Debian-gdm

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Nov 17 17:39 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   49 Jul 25 12:27 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   44 Nov 17 17:39 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   48 Jul 25 12:27 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Jul 25 12:27 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   41 Nov 17 17:39 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Nov 17 17:39 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Nov 17 17:39 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Nov 17 17:39 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   50 Nov 17 17:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Nov 17 17:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   47 Nov 17 17:39 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   47 Nov 17 17:39 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   49 Nov 17 17:39 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   51 Nov 17 17:39 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Nov 17 17:39 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Nov 17 17:39 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Nov 17 17:39 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 Nov 17 17:39 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 Nov 17 17:39 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Nov 17 17:39 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 Nov 17 17:39 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   22 Jul 25 12:27 /etc/alternatives/libGL.so-master 
-> /usr/lib/mesa-diverted

Bug#803949: electrum: Electrum unable to start; Cannot read config file

[Tristan Seligmann]

On Tue, 3 Nov 2015 at 17:09 Zachary Peterson  wrote:

>   File "/usr/lib/python2.7/dist-packages/electrum/simple_config.py", line
> 157, in read_user_config
> raise IOError("Cannot read config file.")
> IOError: Cannot read config file.


This error is raised if an exception occurs reading the configuration file,
located at ~/.electrum/config. Unfortunately the reraised exception
contains no information about what went wrong.

The following command should reproduce the process used by Electrum 1.9.8
to load the config file:

python -c 'import ast, os; print
ast.literal_eval(open(os.path.expanduser("~/.electrum/config")))'

This should fail with a Python exception; could you reply to this bug with
the output?

(The problem could be that your configuration is corrupt somehow, or the
file is unreadable for some reason. Another possibility is that you have
run a newer version of Electrum somehow; newer versions use a different
format for the configuration and wallet files, and will upgrade it
automatically, making older versions unable to read the files.)

Bug#803422: electrum: missing Dependency on python-qt4

[Tristan Seligmann]

On Fri, 30 Oct 2015 at 01:57 Sebastian Kuzminsky  wrote:

> I'm not sure why ${python:Depends} didnt pick it up.  I manually added
> python-qt4 to the Depends line and now it's fine.
>

${python:Depends} doesn't include it because setup.py doesn't declare a
dependency on qt as the electrum library and command-line interface no
longer require qt to work. For this reason, I think Depends is
inappropriate; however, I expect most users want the GUI functionality, so
Recommends seems like the solution. Unfortunately, I already uploaded
2.5.2-1 without this fix, but I'll upload 2.5.2-2 today to fix this

Bug#802638: [pkg-ntp-maintainers] Bug#802638: ntpd fails to start with "Cannot find user ID 113"

[Tristan Seligmann]

On Thu, 22 Oct 2015 at 09:07 Kurt Roeckx <k...@roeckx.be> wrote:

> On Thu, Oct 22, 2015 at 01:40:06AM +0200, Tristan Seligmann wrote:
> > Package: ntp
> > Version: 1:4.2.8p4+dfsg-1
> > Severity: grave
> > Justification: renders package unusable
> >
> > As per subject. This may well be a duplicate of #793745, however:
> >
> > - I am using the default ntp.conf shipped with the package, including the
> >   "rlimit memlock 0" line.
>
> Can you try with "rlimit memlock -1" instead?  It seems "0" now
> means everything, and -1 means no locking.
>

Ah, that would explain it. Changing it to -1 does work (I guess the default
config should be changed as well, and perhaps a NEWS.Debian entry for those
using modified configs?)

Bug#802730: ITP: python-setuptools-scm -- Handles managing your python package versions in scm metadata.

[Tristan Seligmann]

Control: forcemerge 797915 -1

On Fri, 23 Oct 2015 at 00:51 Brian May  wrote:

> * Package name: python-setuptools-scm
>

Already packaged, see #797915.

Bug#802638: ntpd fails to start with "Cannot find user ID 113"

[Tristan Seligmann]

Package: ntp
Version: 1:4.2.8p4+dfsg-1
Severity: grave
Justification: renders package unusable

As per subject. This may well be a duplicate of #793745, however:

- I am using the default ntp.conf shipped with the package, including the
  "rlimit memlock 0" line.

- Downgrading to 4.2.8p3+dfsg-1 fixes the problem.

So I am not sure this is the same underlying cause. Please downgrade/merge as
appropriate if I am wrong about this.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ntp depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.18.3
ii  libc62.19-22
ii  libcap2  1:2.24-12
ii  libedit2 3.1-20150325-1
ii  libopts251:5.18.6~pre3-3
ii  libssl1.0.0  1.0.2d-1
ii  lsb-base 9.20150917
ii  netbase  5.3

Versions of packages ntp recommends:
ii  perl  5.20.2-6

Versions of packages ntp suggests:
pn  ntp-doc  

-- no debconf information

Bug#801801: ITP: python-phpserialize -- Python port of PHP's serialize and unserialize functions

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann <mithra...@mithrandi.net>

* Package name: python-phpserialize
  Version : 1.3
  Upstream Author : Armin Ronacher <armin.ronac...@active-4.com>
* URL : https://github.com/mitsuhiko/phpserialize
* License : BSD
  Programming Lang: Python
  Description : Python port of PHP's serialize and unserialize functions

This module implements the Python serialization interface (eg: provides dumps,
loads and similar functions).

I intend to maintain this in the Debian Python Modules Team. This package is an
optional dependency of nikola (needed by the import_wordpress command in some
cases).

Bug#801796: nikola: New upstream release: 7.7.2

[Tristan Seligmann]

Package: nikola
Version: 7.6.4-1
Severity: wishlist

There is a new upstream release available; please package it.

Bug#799694: Not just ppc64

[Tristan Seligmann]

Control: severity -1 serious

This appears to be happening on all arches, not just ppc64. See, for
example:

https://buildd.debian.org/status/fetch.php?pkg=healpy=amd64=1.8.1-1%2Bb2=1444131922

Bug#789670: Dropping python-pies2overrides

[Tristan Seligmann]

Since frosted is the only reverse dep of python-pies, and it can use
python3-pies instead, how about just dropping
python-pies/python-pies2overrides completely?

Bug#799278: python-cffi: Non-deterministic results with anonymous unions/structs

[Tristan Seligmann]

Package: python-cffi
Version: 1.1.2-1
Severity: minor
Tags: upstream fixed-upstream

When an anonymous union or struct is encountered, for example the union in:

typedef struct {
union {
int a;
char b;
} u
} mystruct;

CFFI internally gives this a name like "$1". However, the assignment of these
names depends on dictionary ordering, causing the output to vary across builds
resulting in reproducibility issues.

This bug is now fixed upstream in rev 1cfe8c7a59e8; I am filing this bug report
just to serve as a place to track the issue in Debian until a fixed cffi
version makes it into Debian.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-cffi depends on:
ii  python-cffi-backend  1.1.2-1
ii  python-pycparser 2.14+dfsg-2
pn  python:any   

python-cffi recommends no packages.

Versions of packages python-cffi suggests:
ii  python-dev  2.7.9-1

-- no debconf information

Bug#798691: Reproducible in sid

[Tristan Seligmann]

Note that this problem is reproducible in unstable, as well. (glibc in
unstable is using gcc 4.8 as well, so I guess this is not surprising at all)


python-cffi_1.1.2-1_i386-20150914-0052.build
Description: Binary data

Bug#797977: pytest: Provide pypy package

[Tristan Seligmann]

Source: pytest
Version: 2.7.2-2
Severity: wishlist

This would involve a pypy-pytest package, as well as possibly a py.test-pypy
binary or something like this (not sure exactly what to call it). I would like
this to be able to run py.test-based test suites in various pypy-* packages.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#792231: electrum

[Tristan Seligmann]

Great news!

I'm currently testing a 2.4.1 Debian package and so far everything looks
good; assuming nothing else turns up, I will be uploading the new version
within a few days.

On Tue, 18 Aug 2015 at 11:41 Thomas Voegtlin thom...@electrum.org wrote:

 Please note that the tlslite the dependency has been removed from
 Electrum since version 2.4.1.

 The only part of tlslite that was used in Electrum was the RSA
 implementation; it is now added to the electrum lib.

 Thomas

Bug#792231: This needs examined as soon as possible

[Tristan Seligmann]

Unfortunately there are some significant challenges with 2.0+. The primary
issue is the dependency on tlslite, which was removed from Debian
previously due to being insecure and unmaintained. In addition, quite a bit
of the certificate handling code does things incorrectly (see eg. the
certificate chain verification code[1] that does not check the certificate
purpose, allowing anyone with a valid cert to sign a fraudulent cert as if
they were a CA).

I would very much welcome help with these issues, but be warned there is
most likely a fair amount of work involved in either rewriting the
cert-handling code to use another library (probably
python-openssl/python-cryptography), or resurrecting and maintaining the
tlslite package.

[1]
https://github.com/spesmilo/electrum/blob/master/lib/paymentrequest.py#L119

On Mon, 3 Aug 2015 at 15:51 Thomas Ward tew...@dark-net.net wrote:

 1.9.8 is a year old.  In addition, 2.4 is the current version.

 Failing to update breaks recovery of wallets from newer versions, and
 there are quite a lot of improvements in 2.4 over 1.9.8 that should be
 reviewed and included.



 Thomas

Bug#792231: electrum

[Tristan Seligmann]

On Mon, 3 Aug 2015 at 20:27 Thomas Voegtlin thom...@electrum.org wrote:

 On 08/03/2015 10:41 AM, Tristan Seligmann wrote:
  In addition,
  quite a bit of the certificate handling code does things incorrectly
  (see eg. the certificate chain verification code[1] that does not
  check the certificate purpose, allowing anyone with a valid cert to
  sign a fraudulent cert as if they were a CA).
 

 Instead of suggesting that there are quite a bit of incorrect things,
 and then citing one example, can you provide the full list of problems
 that you see?


Sorry, I believe I owe you an apology for my carelessly written email.
Firstly, I took a look at the code again, and I think the single issue I
described does not actually exist, I probably misread the code before. (To
be precise, while the code does not check the key usage, it *does* check
the Basic Constraints extension which I believe is the correct check to
prevent the flaw I mistakenly identified).

While it is quite possible for newly written certificate-handling / X509
code to be buggy simply due to the complex nature of what this entails, I
don't have any specific issues to highlight at this time, and I can hardly
claim to be an expert in this area myself, so I retract my previous claim.

However, the primary issue is still dealing with tlslite somehow: I do not
think the FTP masters / security team will be happy with me distributing an
embedded copy of tlslite in the electrum package, and I don't feel
comfortable maintaining tlslite in Debian either way given the
circumstances.

Note that python-cryptography is the cryptography library upon which
python-openssl (PyOpenSSL) is based, not pycrypto which is a different
library; but cryptography does use cffi to bind to OpenSSL etc., so is also
not pure python. Unfortunately most of the existing mature TLS / X.509 /
etc. handling code exists in C libraries...

Bug#793822: fish is not added to /etc/shells

[Tristan Seligmann]

Control: tag -1 + pending

Thanks for the report! In fact, this was supposed to be already done, but
the maintainer scripts got messed up at some point, resulting in this
functionality being broken. I'll fix this in the next upload.

On Mon, 27 Jul 2015 at 22:12 Judicaël Grasset 
judicael.gras...@etu.u-bordeaux.fr wrote:

 After the installation, fish is not added to the /etc/shells file.
 I think fish should be added to /etc/shells in order to let the user
 easily change his default shell via chsh.

Bug#785432:

[Tristan Seligmann]

Control: tag -1 + help

The only requirement is that *some* GStreamer audiosink is installed, in
order for Quod Libet to send audio to it. Depending on
gstreamer1.0-pulseaudio doesn't seem reasonable since it would force
pulseaudio to be pulled in even on systems that are not using it (and then
still wouldn't work if the sink for whatever audio system you *are* using
wasn't installed).

I'm not really sure what the correct way to get the right audiosink package
installed is; anyone have an idea? I feel like this is the responsibility
of the desktop task that you install, rather than something that should be
solved by individual application packages.

Bug#789768: python-cryptography: Upstream version is 0.9.1

[Tristan Seligmann]

The new version requires python-idna (which is through NEW), and
python-ipaddress (which is still in NEW). I am planning to upload a new
python-cryptography once python-ipaddress makes it out of NEW.

On Wed, 24 Jun 2015 at 11:51 Sebastien Delafond s...@debian.org wrote:

 Source: python-cryptography
 Severity: wishlist

 Upstream version is 0.9.1, and recent python-netlib depends on that;
 would it be possible to package it ?

 Cheers,

 --Seb

 -- System Information:
 Debian Release: 8.0
   APT prefers stable
   APT policy: (501, 'stable'), (500, 'oldoldstable-proposed-updates'),
 (500, 'oldoldstable'), (500, 'oldstable'), (1, 'unstable')
 Architecture: i386 (i686)

 Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 Init: sysvinit (via /sbin/init)