On 12/04/2024 15:35, Cody Scott wrote:
Package: wnpp
Severity: wishlist
Owner: Cody Scott
X-Debbugs-Cc: debian-de...@lists.debian.org, cody.sc...@giatec.ca
* Package name: python3-pyzmq
Version : 25.1.2
Upstream Contact: ZeroMQ
* URL :
Yes. I can see that there are API methods which expose nlohmann::json
(eg,
https://github.com/jupyter-xeus/xeus/blob/ebd21e9e7cfe143b4d0a6783112cc9006b456915/include/xeus/xdebugger.hpp#L55-L60)
so changes the header library are going to cause ABI breakage.
I don't see much choice here but to
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: x...@packages.debian.org, gor...@chronitis.net
Control: affects -1 + src:xeus
xeus exposes the interface of nlohmann::json as part of its ABI
(unfortunately), and changes in
Package: wnpp
Severity: wishlist
Owner: Gordon Ball
X-Debbugs-Cc: gor...@chronitis.net
* Package name: xeus-zmq
Version : 1.1.0
Upstream Contact: Jupyter-Xeus project
* URL : https://github.com/jupyter-xeus/xeus-zmq
* License : BSD-3-clause
Programming Lang
Got it, thanks for the explanation. This restriction existed since the
early stage of dh-r development
https://salsa.debian.org/r-pkg-team/dh-r/-/commit/22fd80b9#L174
by Gordon Ball (in CC but not really active in R pkg team any more) at
2016-09-04 12:28:57 +0200 . I'm guessing this restrict
Source: zlmdb
Version: 22.6.1-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml
Source: xrstools
Version: 0.15.0+git20210910+c147919d-3
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will
Source: spades
Version: 3.15.5+dfsg-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in
Source: ros-rosinstall
Version: 0.7.8-5
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in
Source: relatorio
Version: 0.10.1-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in
Source: refstack-client
Version: 0.0.0~2021.08.18.fa73ef2524-2
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which
Source: qcengine
Version: 0.23.0-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml
Source: qcat
Version: 1.1.0-3
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml
Source: python-tempestconf
Version: 2.5.0-3
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error
Source: python-pybedtools
Version: 0.9.0-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error
Source: python-multipart
Version: 0.0.5-2
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in
Source: python-canmatrix
Version: 0.9.5~github-2
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an
Source: python-aptly
Version: 0.12.10-3
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in
Source: policyd-rate-limit
Version: 1.0.1.1-2.1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an
Source: owslib
Version: 0.27.2-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml
Source: open-adventure
Version: 1.9-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in
Source: lirc
Version: 0.10.1-7
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml
Source: lecm
Version: 0.0.9-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml
Source: labgrid
Version: 0.4.1-4
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml
Source: ganeti
Version: 3.0.2-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml
Package: etm
Version: 3.2.30-4
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml
Source: elasticsearch-curator
Version: 5.8.1-4
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an
Source: ceph
Version: 16.2.10+ds-3
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml
Source: ansible
Version: 6.4.0+dfsg-1
Severity: minor
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in
Package: python3-testpath
Version: 0.6.0+dfsg-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: gor...@chronitis.net
The package is empty except for the changelog.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'),
On Wed, Feb 02, 2022 at 11:35:19AM +, Julian Gilbey wrote:
> Package: python3-ipykernel
> Version: 6.7.0-1
> Severity: serious
> X-Debbugs-Cc: Julien Puydt , Gordon Ball
>
>
ps, I had a search just now and it looks like someone else was working
1 year ago on `ptvsd`
On Wed, Feb 02, 2022 at 11:35:19AM +, Julian Gilbey wrote:
> Package: python3-ipykernel
> Version: 6.7.0-1
> Severity: serious
> X-Debbugs-Cc: Julien Puydt , Gordon Ball
>
>
> ipykernel depends on the debugpy package, as stated in setup.py.
> However, within Debia
Package: pkg-js-tools
Version: 0.11.7
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
Lines in the file `debian/nodejs/component_links` are checked for the
regex `/^([\w\-\.\/]+)\s+([\w\-\.\/]+)$/` and otherwise reported as
malformed.
This means that components named in the typescript style
Package: python3-metakernel
Version: 0.27.5-3
Severity: minor
X-Debbugs-Cc: gor...@chronitis.net
python3-metakernel adds a manual dependency on jupyter-notebook, which
should probably not be a hard dependency. The library doesn't import
from notebook anywhere I can see, so it's only being added
Package: wnpp
Severity: wishlist
Owner: Gordon Ball
X-Debbugs-Cc: debian-pyt...@lists.debian.org, gor...@chronitis.net
* Package name: python-pure-eval
Version : 0.2.1
Upstream Author : Alex Hall
* URL : https://github.com/alexmojaki/pure_eval
* License : MIT
Package: libjs-jquery-ui
Version: 1.13.0+dfsg-1
Severity: important
X-Debbugs-Cc: gor...@chronitis.net
When updating from 1.12.1 to 1.13.0, the ABI of the dist files
/usr/share/javascript/jquery-ui/jquery-ui[.min].js appears to have
changed.
In 1.12, it contained a single factory function which
I think this is caused by jquery-ui failing to load, which should have
created the `resizeable` property on that element.
jquery-ui was updated from 1.12.1 to 1.13.0 in november (but that change
wouldn't have been picked up until the jupyter notebook javascript was
rebuilt recently to try and fix
Package: wnpp
Severity: wishlist
Owner: Gordon Ball
X-Debbugs-Cc: gor...@chronitis.net, debian-pyt...@lists.debian.org
* Package name: python-stack-data
Version : 0.1.3
Upstream Author : Alex Hall
* URL : https://github.com/alexmojaki/stack_data
* License
Package: libjs-marked
Version: 4.0.5+ds-5
Severity: important
X-Debbugs-Cc: gor...@chronitis.net
In libjs-marked 0.8.0, /usr/share/javascript/marked/marked.js was a
UMD-type module suitable for browser use.
In libjs-marked 4.0, initially only marked.cjs (a CommonJS module not
suitable for
On Sun, Jan 09, 2022 at 11:47:47AM -0500, Sandro Tosi wrote:
> Gordon,
>
> > [ Gordon Ball ]
> >* Vendor mistune 0.8.4 due to incompatibility with mistune 2
> > (Closes: #1001283, #1002372)
>
> i think you closed *all* the mistune bugs by doing t
Reducing severity to `normal`, since this does not appear to happen
consistently. Looking through the CI logs, there are occasional failures
on ppc64el, but since it does not appear to happen consistently, I don't
_think_ this justifies RC severity, unless anyone can reproduce it in
actual usage.
Hi Yadd
Jupyter notebook (python3-notebook) ships with symlinks in
/usr/lib/python3/dist-packages/notebook/static/components to various
javascript libraries which are served to the browser at runtime.
That autopkgtest checks for broken symlinks in that tree. Presumably the
layout of dist files
I'm a bit mysterified by this. Failed tests do seem to be reproducible
(in debci) with this package pinned, but I can't work out how the traceback
shown actually stems from jupyter_client.
This version is meant to already include compatibility fixes
(https://github.com/dask/distributed/pull/5286)
I _think_ this would expected with 22.3.0-1 and python 3.10, since that
package was built only for python 3.9.
Can you reproduce this with 22.3.0-1+b1 now the python 3.10 binNMUs have
(mostly) happened? I can certainly import `zmq` in python3.10 without
immediate errors.
Source: glueviz
Version: 1.0.1+dfsg-1
Severity: important
X-Debbugs-Cc: gor...@chronitis.net
glueviz depends on jupyter_client < 7, which blocks the migration of
jupyter client 7 to testing.
As far as I can tell, this library isn't imported anywhere in glueviz. I
did a test rebuild in unstable
Package: qiime
Severity: normal
Tags: upstream
X-Debbugs-Cc: gor...@chronitis.net
I recently uploaded python-decorator 5.1 to experimental. This appears
to break qiime (or qiime's test suite, at least).
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/qiime/15900873/log.gz
This appears
On Fri, Sep 24, 2021 at 12:02:50AM -0400, Sandro Tosi wrote:
> On Tue, Sep 21, 2021 at 2:23 PM Gordon Ball wrote:
> > Indeed. qa.d.o betrays me.
>
> you cant hide the good work :)
>
> > The answer to this was delayed because I considered several times what
> > it s
Indeed. qa.d.o betrays me.
The answer to this was delayed because I considered several times what
it should actually be.
The _python_ side of ipywidgets has never been a problem, but the
JS/browser side has grown in complexity considerably in recent years,
and shows little sign of slowing down.
Hi Gordon,
>
> I requested access to the Debian Tasktools Team.
> May you accept my request?
>
> Sergio Cipriano.
>
> On Friday, September 10th, 2021 at 06:44, Gordon Ball
> wrote:
>
> > Hi Sergio
> >
> > In that case, please take over the t
ackage, so please remove me
from the uploaders. You might want to join the tasktools team on tracker
(team+taskto...@tracker.debian.org) and add that as a maintainer.
Gordon
On Wed, Sep 08, 2021 at 11:14:19AM +, Sergio Cipriano wrote:
> Hi Gordon,
>
> On Wednesday, September 8th, 20
Hi Sergio
Note that there is already `taskd` in the archive (former name of
taskserver). It's not been uploaded for a number of years and I believed
that it was dead upstream (and I had lost interest in using it). If
you're interested you could either take over that package (and introduce
a new
Ack, already looking at it.
Unfortunately, there is unlikely to be a quick fix, since upstream has
resolved this by removing their existing html/css sanitizer in favour of
an alternative one from the jupyterlab source tree, which will require
more packaging work before we can utilise it. This is
Package: wnpp
Severity: wishlist
Owner: Gordon Ball
X-Debbugs-Cc: gor...@chronitis.net
* Package name: matplotlib-inline
Version : 0.1.2
Upstream Author : IPython Development Team
* URL : https://github.com/ipython/matplotlib-inline
* License : BSD
Just to update, I applied for an unblock (#986915) for 4.8.0-2, which
* runs the tests against installed code (instead of the source tree)
* blacklists the remaining known flaky tests (appears to match the list
Lukas provided)
The changes are in git but I haven't uploaded yet (pending
2021-01-04 19:51:00.0 +
+++ pexpect-4.8.0/debian/changelog 2021-04-13 08:20:51.0 +
@@ -1,3 +1,10 @@
+pexpect (4.8.0-2) UNRELEASED; urgency=medium
+
+ * Skip several flaky tests, both for build and autopkgtest (Closes: #986727)
+ * Fix broken URL in d/watch
+
+ -- Gordon
On Sun, Apr 11, 2021 at 08:18:34PM +0200, Jochen Sprickerhof wrote:
> Hi,
>
> I looked into this bug but was not able to reproduce it locally.
> But it looks like that the autopkgtests only rerun the unit tests with the
> local source code and don't test the installed package at all. I was able
I started a branch for lintian-brush here:
https://salsa.debian.org/chronitis/lintian-brush/-/tree/github-archive-url
(using a nonexistant lintian tag, so having a real one would definitely
be a first step).
However, it turned out to be a bit more complex than I first thought (or
hoped):
* Lots
On Sat, Feb 06, 2021 at 04:05:20PM +0100, Ivo De Decker wrote:
> Control: tags -1 patch
>
> Hi,
>
> On Tue, Jan 28, 2020 at 11:43:47PM +0200, Adrian Bunk wrote:
> > Source: ipywidgets
> > Version: 6.0.0-6
> > Severity: serious
> > Tags: ftbfs
>
> This is fixed in git:
>
>
A sufficient patch is
```
diff --git a/debian/tests/control b/debian/tests/control
index bc03117..d765359 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,4 +1,4 @@
-Test-Command: pytest-3
+Test-Command: pytest-3 -k 'not nmr.ipynb'
Depends: python3-mdtraj,
python3-ipykernel,
Hi Nicola
Thanks for reporting this bug. This certainly sounds like a regression,
which wouldn't be that surprising given the large set of changes between
2.5.1 and 2.5.2.
Please report this as a bug upstream. I would expect this to not
be an intentional change within a minor version. If a patch
Source: mdtraj
Severity: normal
Tags: ftbfs
Dear Maintainer,
mdtraj appears to FTBFS when trying to migrate jupyter-client 6.1.6 ->
6.1.11
The failure is trying to build the example notebook examples/nmr.ipynb;
it appears to fail trying to find an external dependency (sparta) which
as far as I
Thanks for reporting.
This is a problem with pybind11-json-dev, which embeds the python
include path that it is built with, but does not currently declare a
dependency on the appropriate libpython3 version. (Not that declaring it
would be completely sufficient either, since as an arch:all it
Is this maybe a false positive from build-log scanning?
This is a header-only library and installed packages contain only
headers, CMake and pkg-config files, and the latter do not appear to set
-march=native as a required flag for downstream compilation.
-march=native is set when compiling the
Package: wnpp
Severity: wishlist
Owner: Gordon Ball
* Package name: xeus-python
Version : 0.8.6
Upstream Author : QuantStack
* URL : https://github.com/jupyter-xeus/xeus-python
* License : BSD-3-clause
Programming Lang: C++
Description : Python kernel
Package: wnpp
Severity: wishlist
Owner: Gordon Ball
* Package name: xeus
Version : 0.24.2
Upstream Author : QuantStack
* URL : https://github.com/jupyter-xeus/xeus
* License : BSD-3-clause
Programming Lang: C++
Description : C++ implementation
Package: wnpp
Severity: wishlist
Owner: Gordon Ball
* Package name: pybind11-json
Version : 0.2.6
Upstream Author : pybind11 contributors
* URL : https://github.com/pybind11/pybind11_json
* License : BSD-3-clause
Programming Lang: C++
Description
On Mon, Oct 26, 2020 at 01:07:09PM +, Luca Boccassi wrote:
> On Mon, 2020-10-26 at 12:28 +0000, Gordon Ball wrote:
> > On Mon, Oct 26, 2020 at 11:52:17AM +, Luca Boccassi wrote:
> > > On Mon, 2020-10-26 at 11:40 +, Gordon Ball wrote:
> > > > On Mon, Oc
On Mon, Oct 26, 2020 at 11:52:17AM +, Luca Boccassi wrote:
> On Mon, 2020-10-26 at 11:40 +0000, Gordon Ball wrote:
> > On Mon, Oct 26, 2020 at 09:48:52AM +, Luca Boccassi wrote:
> > > On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> > > > O
On Mon, Oct 26, 2020 at 09:48:52AM +, Luca Boccassi wrote:
> On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball wrote:
> > > src:zeromq3 and libzmq3-dev currently embed headers from the separate
> > >
On Sun, Oct 25, 2020 at 05:13:52PM +0100, László Böszörményi (GCS) wrote:
> On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball wrote:
> > src:zeromq3 and libzmq3-dev currently embed headers from the separate
> > cppzmq repository. However, the associated cmake files are not included,
to be fixed. Codesearch suggests gnuradio,
libopenshot, thrift, tango, ignition-transport, horizon-eda
Gordon
From 5c8f7f94d1e62a8a51bf73484493d9ae2e332a4d Mon Sep 17 00:00:00 2001
From: Gordon Ball
Date: Tue, 15 Sep 2020 08:52:10 +
Subject: [PATCH] Add cppzmq cmake files
---
debian/changelog
Thank you for the patch.
Unfortunately, this bug probably does not meet the standard for a update
to the "stable" release. The guidelines [0] are that a bug to be fixed in
stable should have at least severity "important", which is defined as
a bug which has a major effect on the usability
On Mon, Oct 12, 2020 at 01:46:40PM +0200, Julien Puydt wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-pyt...@lists.debian.org
>
> * Package name : python-jupyterlab-pygments
> Version: 0.1.2
> Upstream author: Project Jupyter Contributors
> * URL :
Package: wnpp
Severity: wishlist
Owner: Gordon Ball
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: nbclient
Version : 0.5.0
Upstream Author : Jupyter contributors
* URL : https://github.com/jupyter/nbclient
* License : BSD-3-clause
Programming
On Mon, Sep 07, 2020 at 12:13:44AM -0400, Joseph Nahmias wrote:
> Hi Gordon,
>
> On Sun, Sep 06, 2020 at 06:23:09PM +0000, Gordon Ball wrote:
> > > Happy to have co-maintainers and/or place it under the rubric of the
> > > Debian Python team.
> > >
>
On Sat, Sep 05, 2020 at 11:04:37PM -0400, Joseph Nahmias wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Joseph Nahmias
>
> * Package name: metakernel
> Version : 0.27.0
> Upstream Author : Metakernel Development Team
> * URL :
> Given that you say this was a build incompatibility, could you
> explain why you thought it was necessary to add a runtime Breaks:?
The setup.py for mitmproxy 4 sets an explicit upper limit on tornado
compatibility ("tornado>=4.3,<5.2"). The upstream commit [1] which relaxes
this constraint
On Thu, May 28, 2020 at 01:55:15PM +0200, Julien Puydt wrote:
> Hi,
>
> do you have any reason for not filing a RM bug request to the ftp-
> master team?
>
> If it's an old fork with no rdepends, that looks like a good candidate.
>
Hello Julien
As I didn't have any previous knowledge of this
Package: taskd
Severity: serious
Justification: Policy 3.3
taskd has not been uploaded for two releases, and development appears to
be dead upstream. I've long ceased to use it, and the install base
appears (per popcon) to be minimal.
Consequently, this is filed to have it removed from testing,
Source: python-tornado4
Severity: serious
Justification: Policy 7.2
This package is an old fork of the tornado binary package, which appears
to have been created for src:salt.
There are no longer any rdepends (salt ceased to depend upon it after
3000+dfsg1-1), so unless there are objections this
I've [team-]uploaded beaker and ripe-atlas-cousteau, and filed bugs
against kombu and pagure (on the basis that they are both have recent
activity). They've been added as blockers to this bug.
Apart from python-oslo.* changes already in experimental, I think that
means all the
Source: kombu
Severity: normal
Dear Maintainer,
Please drop the build-depends on python3-funcsigs.
It appears to be left over from older versions; the string "funcsigs"
now only appears in d/control and d/changelog, and since it's a backport
of a stdlib feature from python 3.3 it really should
Source: pagure
Severity: normal
Dear Maintainer
Please drop the build-depends on python3-funcsigs.
It doesn't appear to be used anywhere in the package (the string
"funcsigs" only appears in d/control), and shouldn't be needed - it's a
backport of a stdlib function added in python 3.3.
This is
I just uploaded python-logfury dropping the funcsigs dependency, so
that's one step closer.
Unless there are objections, I'll upload python-tornado 6 to unstable in
a week or so, with breaks against
pcs (<< 0.10.5-1~)
mitmproxy (<< 5.0~)
Package: mitmproxy
Severity: normal
Dear Maintainer,
I've just uploading python3-tornado 6.0.4 to experimental.
mitmproxy is the only blocker I've found (so far) which is incompatible
(at least to build) with this version (as opposed to 5.1.1 in unstable).
It appears mitmproxy upstream merged
On Mon, Mar 30, 2020 at 08:29:37PM -0400, Sandro Tosi wrote:
> Hey Gordon,
>
> > > > Do you think it would be possible to remove that build-depends (my
> > >
> > > I've actually tried to rebuild ipython-py2 without mpl and it builds
> > > fine: are you ok with me making an upload with that b-d
Package: ftp.debian.org
Severity: normal
Fork of src:prompt-toolkit containing only python2 parts; only reverse
dependency is src:ipython-py2 (RM request #955404).
Package: ftp.debian.org
Severity: normal
This source package was forked from src:ipython and contains only
python2 parts; there are no remaining dependencies (and only two
recommends from packages with open py2-removal RC bugs: src:sugar,
src:nipype).
Package: borgbackup
Version: 1.1.11-2
Severity: grave
Justification: renders package unusable
After updating python3-msgpack from 0.5.6-3 -> 0.6.2-1, attempting to
run any borg command fails with the following message, making borg
wholly unusable.
$ borg -v
You do not have a supported
On Mon, Mar 02, 2020 at 09:14:52AM -0500, Sandro Tosi wrote:
> > The src:ipykernel-py2 package provides python-ipykernel, which is to be
> > removed for the Python 2 removal transition.
>
> Cc-ing Gordon explicitly: the last time we spoke, Gordon wanted to
> keep the python2 stack of
On Fri, Feb 21, 2020 at 06:49:06AM +, Gordon Ball wrote:
> On Thu, Feb 20, 2020 at 09:31:16PM +0100, László Böszörményi (GCS) wrote:
> > On Thu, Feb 20, 2020 at 9:06 PM Luca Boccassi wrote:
> > > On Thu, 2020-02-20 at 20:57 +0100, László Böszörményi wrote:
> > >
On Thu, Feb 20, 2020 at 09:31:16PM +0100, László Böszörményi (GCS) wrote:
> On Thu, Feb 20, 2020 at 9:06 PM Luca Boccassi wrote:
> > On Thu, 2020-02-20 at 20:57 +0100, László Böszörményi wrote:
> > > Luca, what's your opinion on this? I think that needs to be packaged
> > > separately.
> >
> >
On Thu, Feb 13, 2020 at 09:02:33PM -0500, Sandro Tosi wrote:
> > > (source:ipython-py2)Build-Depends->python-matplotlib
> > ...
> >
> > Do you think it would be possible to remove that build-depends (my
>
> I've actually tried to rebuild ipython-py2 without mpl and it builds
> fine: are you ok
On Tue, Feb 11, 2020 at 08:56:43PM -0500, John Scott wrote:
> It appears that bugs haven't been filed to get reverse dependencies depending
> on version 1 out of testing.
>
> Britney [1] says
> > trying: prompt-toolkit
> > skipped: prompt-toolkit (39, 2, 91)
> >
> > got: 26+0:
Source: zeromq3
Severity: wishlist
Dear Maintainer,
zeromq3 installs /usr/include/zmq.hpp, which has been copied from cppzmq
(https://github.com/zeromq/cppzmq).
It's unclear which version of zmq.hpp this is (the copyright dates would
suggest fairly old). Possibly since this version the cppzmq
This bug was originally reported (#944743) against 6.0.0-1 and should
have been fixed in 6.0.0-2 (by passing dh_installsystemduser
--no-enable).
Installing 6.0.3 in a VM today appears to install but not auto-enable
the user unit. Can you confirm if this was an upgrade or a clean
install?
On Tue, Jan 07, 2020 at 09:16:42PM +0100, Paul Gevers wrote:
> Control: reopen -1
>
> Hi Gordon,
>
> On 06-01-2020 16:39, Debian Bug Tracking System wrote:
> > Your message dated Mon, 06 Jan 2020 15:37:55 +
> > with message-id
> > and subject line Bug#944227: fixed in prompt-toolkit
Source: python-softlayer
Severity: serious
Justification: Policy 7.4
Control: blocks 944227 -1
Dear Maintainer,
prompt-toolkit has been updated to the 2.x series. The current version
of python-softlayer requires prompt-toolkit 1, and was added to the
Breaks: list for prompt-toolkit 2.0.10.
This
The packages which I was waiting for (python-backcall, ipython-py2) have
now cleared NEW, so for me I'm ready to proceed.
Unless there are any objections, I propose to upload prompt-toolkit 2.0
(as per experimental, plus the Breaks: listed above) to unstable in
during the first week of January.
1 - 100 of 178 matches
Mail list logo
