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: 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
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
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.
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
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
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
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,
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
> 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
I just uploaded python-logfury dropping the funcsigs dependency, so
that's one step closer.
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: 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
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
l/ipython_2.svg
>
> thanks,
> Sandro
>
> On Wed, Dec 18, 2019 at 8:09 AM Gordon Ball wrote:
> >
> > I've forked the source package for ipykernel to retain (for now) the
> > python2 version.
> >
> > (Rationale: while there aren't rdeps, keeping this pack
I've forked the source package for ipykernel to retain (for now) the
python2 version.
(Rationale: while there aren't rdeps, keeping this package is needed to
keep the ability to use python2 jupyter notebook. This package is
flagged py2keep; I don't think dropping python2 here frees up many other
As noted above, the bug severity was upgraded too late to stop 0.5.2
migrating.
There have been a series of releases since, and while this bug was
mostly fixed in 0.5.3 it appears there were still some edge cases.
The code is still fairly fast moving, and in the end I don't think it's
a good
Apparently I was too slow. It migrated only about an hour after I
increased the severity, which was too late for the RC bug to be considered.
Given the proximity to the freeze, I'm tempted to allow xonsh to be
removed from testing and provide a backport in due course when the
current branch has
Thanks for reporting.
I think I have to agree. I pushed the 0.5 series when it was released
thinking it would be a better base if patching was required in future,
but there do appear to be too many bugs which cannot be patched at the
moment.
I have upgraded the bug to severity:serious to prevent
29 matches
Mail list logo
