Bug#1060164: (no subject)
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 binNMU xeus, xeus-zmq, xeus-python, which will presumably break custom kernels compiled against it and an older version of nl::json. I considered just updating everything to new versions and "rolling forward", but the latest version of xeus-zmq at least has an soversion bump so probably better to request binNMUs before waiting for NEW.
Bug#1018279: python3-testpath: Empty binary package
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'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1004855: python3-ipykernel: missing dependency on debugpy
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` (renamed `debugpy` later), but it doesn't look like it was ever uploaded. But perhaps something to build upon. https://salsa.debian.org/python-team/packages/ptvsd https://salsa.debian.org/python-team/packages/pydevd pps, I disagree that this qualifies for `severity=serious`. I don't think there is either a policy violation or the package is unusable for most users. I propose to change this to `severity=important`.
Bug#1004855: python3-ipykernel: missing dependency on debugpy
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 Debian build, python3-debugpy is not listed in the > Build-Depends, so the resulting binary package does not Depend(s) on > it either. The ipykernel test suite passes because the debugger test > is skipped if debugpy is not installed, but Spyder behaves badly in > its absence. Yes, sorry. This is a known, but admittedly not documented, limitation of the current package. As far as I could tell debugpy was effectively treated as an optional feature (all imports seem to be protected with try-catch, etc), despite being listed as install_requires. > Furthermore, there is no python3-debugpy package yet in Debian. I am > happy to do an ITP and upload this package to NEW if that would help. I looked briefly into packaging debugpy and I think it's probably doable but looks like a reasonable amount of work (embedded vendored stuff, cython). I don't have time to take that on at the moment, but I'd be very happy if you're willing to. Gordon
Bug#1002372: marked as done (nbconvert: FTBFS: AttributeError: module 'mistune' has no attribute 'BlockGrammar')
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 this. can you > reopen the ones not affecting nbconvert so that we dont lose track of > them? Hi Sandro I _think_ the closed bugs (#1001283 was merged with 6 others) only cover the cases where the FTBFS tracebacks showed nbconvert (rather than direct import of mistune). I haven't admittedly tried rebuilding them all, but given the failure mode, I think the bug was correctly merged and they're likely to be fixed. * #1002371 python-fluids * #1002373 python-fabio * #1002374 silx * #1002375 mdtraj * #1002383 pyswarms * #1002790 statsmodels The main tracking bug for mistune (#1001591) should still be open, along with related bugs for packages which imported mistune directly (#1002163 python-m2r, #1002254 lookatme, #1002380 python-matrix-nio). Am I missing anything else which was wrongly closed? > > Thanks, > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi
Bug#1000884: autopkgtest
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 for marked has changed. I won't be able to look at this imminently, but there is a major version change of marked, there is probably API breakage as well. Since this only arises at runtime in the browser, it's not checked by autopkgtests. I'll look at this, but I'm not likely to be able to do so that quickly due to family commitments. Gordon
Bug#1000271: (no subject)
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) for jupyter_client 7. I'm wondering if this is something obscure like more filehandles or ports ending up being used and causing interference further down the line. Any ideas?
Bug#1000365: pre-rebuild?
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.
Bug#992704: (no subject)
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 going to be even more of a problem to backport to stable.
Bug#986727: (no subject)
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 approval) - if I haven't heard by 2021-04-16 I will probably upload anyway, as I'll be offline for a week after that, and I _hope_ the changes are fairly uncontriversial. I didn't include all of Lukas' changes - race condition, I'd already made the unblock request before checking this bug again, but I'll try and merge the ubuntu diff after the release.
Bug#986727: pexpect: flaky and superficial? autopkgtest
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 to > run the tests successfully without having the package installed. > As those tests are run during the package build already, I would propose to > remove the autopkgtests. As you say, it looks flaky (and I see that it is also failing consistently in Ubuntu CI testing - presumably due to different environment). I would prefer not to remove CI completely; even if the testsuite is run in-source it will still detect dependency failures (but I agree that the current version ought to use the installed code). I would propose to do that and skip any of the specific tests found to be flaky. I'll try and do so in the next couple of days. Gordon > > Cheers Jochen
Bug#950094: ipywidgets FTBFS with node-semver 7.1.1-2
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: > > https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/23daf45a127b3febe25ecefdbb7148b0f5049990 > > Gordon, are you planning to upload this soon? The soft freeze is pretty close > now. > The FTBFS bugs are fixed, in the sense that I have redone the build system reflecting all the changes that have happened to the parent libraries, and the basic build sequence runs without error. However, the resultant object doesn't actually work (yet). I'll upload it iff I can get something working before the freeze dates. > Thanks! > > Ivo >
Bug#980050: (no subject)
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, python3-jupyter-client, ```
Bug#975334: xeus-python ftbfs
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 wouldn't get binNMU'd anyway). I'll make a new upload of pybind11-json-dev then giveback this package.
Bug#961402: false positive?
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 test suite (test/CMakeLists.txt), which could be patched out, but since those binaries shouldn't leave the build machine, does it matter?
Bug#959180: mitmproxy incompatability
> 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 replaces usage of tornado.wsgi.WSGIAdapter which is
removed in tornado 6 (but imported unconditionally in mitmproxy 4),
but there might be other changes too.
Is this not a case where it is proper to declare that updating tornado
breaks this version of mitmproxy?
[1]:
https://github.com/mitmproxy/mitmproxy/commit/902ef59d01f45613ce33520159e157697bcc6f9f
Bug#960041: On python-tornado4
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 and hadn't created it I was a bit nervous about going straight for the delete button, although, as you say, it appears to have no users now. I filed the bug with RC severity initially; my plan was that if nobody responds to it being removed from testing (in a week or so), I'd then make a deletion request. Feel free to request deletion today though. (Tornado 6 will hopefully migrate to testing tomorrow once mitmproxy is removed from testing). Gordon > Cheers, > > JP >
Bug#960223: taskd: Unsuitable for stable release
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, and will proceed to RM in future if the situation doesn't change.
Bug#960041: python-tornado4: Pending removal
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 package will be dropped.
Bug#937769: uploaded ripe-atlas, beaker
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 reverse[-build]-depends are now either already uploaded or have bugs filed.
Bug#937769: logfury
I just uploaded python-logfury dropping the funcsigs dependency, so that's one step closer.
Bug#947298: ipython-py2: Python2 removal in sid/bullseye
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 removed? > > > > I've just uploaded 5.8.0-4 dropping the matplotlib dependency; it > > was a vestigal test dependency which was no longer needed. Thanks for > > spotting it (and all your work on py2removal). > > i've just uploaded scr:scapy dropping its python2 package, which was > the last rdep of scr:ipython-py2/bin:ipython/bin:python-ipython (the > remaining ones are packages already RC buggy and not in testing) -- i > think we're ready to remove this package, do you want to file the RM > bug or want me to? > I've just filed #955404 (RM ipython-py2) and #955406 (RM prompt-toolkit-py2), which deals with the remaining -py2 forks I created late last year. I must admit, I expected that they'd be needed for longer - I'm pleasantly surprised to be dumping them now. Gordon > Cheers, > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi
Bug#953989: borgbackup reports installed python3-msgpack is incompatible
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 msgpack[-python] version installed. Terminating. This should never happen as specific, supported versions are required by our setup.py. Do not contact borgbackup support about this. The setup.py in question requires <= 0.5.6 (plus some exclusions). It looks like borgbackup 1.2.0 declares support for this msgpack version. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages borgbackup depends on: ii fuse 2.9.9-3 ii libacl12.2.53-6 ii libb2-10.98.1-1.1 ii libc6 2.30-2 ii liblz4-1 1.9.2-2 ii libssl1.1 1.1.1d-2 ii libzstd1 1.4.4+dfsg-3 ii python33.8.2-1 ii python3-llfuse 1.3.6+dfsg-2+b1 ii python3-msgpack0.6.2-1 ii python3-pkg-resources 44.0.0-1 borgbackup recommends no packages. Versions of packages borgbackup suggests: pn borgbackup-doc -- no debconf information
Bug#948397: python-softlayer: Update to prompt-toolkit 2 compatible version
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 should be resolvable by updating to softlayer 5.8 or later. ScottK responded to the original prompt-toolkit upgrade bug (#914698), but it appears he's no longer listed as an uploader for this package. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-1-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#943901: [Python-modules-team] Bug#943901: ipykernel python 3.8
On Wed, Dec 18, 2019 at 09:37:32AM -0500, Sandro Tosi wrote: > Hey Gordon, > can i ask you why you split this package in 2? there are exactly 0 > reverse dependencies (as in `dak rm -Rn -b -b python-ipykernel`) of > python-ipykernel in the archive, so is it really necessary to keep the > py2 version around? at all? The rationale was that this package is needed to keep the ability to run user's existing legacy jupyter notebooks written for python2; something which I'd like _in principle_ to retain; python3-ipykernel cannot substitute for python-ipykernel where the user-level code is python2. The popcon (~2k) is sufficient to qualify for the py2keep criteria (although admittedly I haven't discussed it on the mailing list). I would also consider it part of a suite with ipython; if we get to the position of being able (this rdepend aside) drop ipython2, I'd reconsider ipykernel2 at the same time. The majority of depends for ipykernel are common with ipython, which still has a fair number of rdepends as per your graphs [1] (exceptions: python-tornado, python-jupyter-client). (see also discussion in #887101) Gordon [1]: http://sandrotosi.me/debian/py2removal/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 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 > > rdeps until and unless ipython2 can be dropped). > > > > The forked source package (ipykernel-py2) has been sitting in NEW since > > 2019-11-17. In principle dropping python2 from this source package > > doesn't have to wait for it to be accepted, but I preferred to maintain > > continuity. > > > > ___ > > Python-modules-team mailing list > > python-modules-t...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team > > > > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi
Bug#943901: ipykernel python 3.8
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 rdeps until and unless ipython2 can be dropped). The forked source package (ipykernel-py2) has been sitting in NEW since 2019-11-17. In principle dropping python2 from this source package doesn't have to wait for it to be accepted, but I preferred to maintain continuity.
Bug#851841: xonsh: jobs and backgrounding broken
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 candidate for a stable release at this time; I'll aim to provide a version in stretch-backports in due course.
Bug#851841: xonsh: jobs and backgrounding broken
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 stabilised. Are there strong opinions otherwise?
Bug#851841: xonsh: jobs and backgrounding broken
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 migration, so stretch will get 0.4.7 and unstable will be updated when patches for 0.5 are available. On 19/01/17 09:48, Frederic Peters wrote: > Package: xonsh > Version: 0.5.2+dfsg-1 > Severity: important > > Hi, > > This is about https://github.com/xonsh/xonsh/issues/2071 > > From a comment in there: > > I think there are two separate issues here (that I've noticed). One is that > backgrounding doesn't seem to work (the big issue). The other is that while > the SIGSTOP is sent by Ctrl-Z, the prompt doesn't always return control to > the user. > > This makes xonsh almost unusable, and this version shouldn't migrate to > testing. (imo) > > > Thanks, > Frederic > > -- System Information: > Debian Release: 9.0 > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages xonsh depends on: > ii python3-pkg-resources 32.3.1-1 > ii python3-ply3.9-1 > ii python3-venv 3.5.1-4 > pn python3:any > > Versions of packages xonsh recommends: > ii python3-prompt-toolkit 1.0.9-1 > ii python3-pygments2.1.3+dfsg-1 > ii python3-setproctitle1.1.10-1 > > Versions of packages xonsh suggests: > ii xonsh-doc 0.5.2+dfsg-1 > > -- no debconf information >
