Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
Hi Nilesh, On Sun, May 19, 2024 at 12:27:02PM +0530, Nilesh Patra wrote: > Julian Gilbey : > > I have come across a number of packages with a line in their > > debian/rules like: > > > > ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS))) > > > > This should be "nodoc", according to the "nodoc" entry in > > https://wiki.debian.org/BuildProfileSpec#Registered_profile_names > > > > It would be good to check for this error. > > This mostly looks like a typo and I am kinda sure that you'd find typos like > this all over many places. I am a bit unsure if checks for this is something > we > as a new lintian warning is something that we even need? Perhaps, perhaps not. It's not something that's easily spotted by eye unless you're explicitly looking for it. > Louis-Philippe Véronneau : > > ... > > I've created a patch on Salsa that creates a new Lintian check for this. > > > > https://salsa.debian.org/lintian/lintian/-/merge_requests/504 > > And if we do -- I checked the MR and it does not look extensible. If in > future there comes another class of typos, it will result in a new patch of > this > kind. Instead, is it possible to have a list of offending terms like this in a > data list and warn the user about them via a lintian warning? > > For instance, we have data/fields/obsolete-packages for listing obsolete > packages and showing the user about the obsolete packages and their > replacements. Do you think a similar implementation for this > (data/fields/bad-buildprofiles ?) makes sense? Now *that's* a really nice approach. But here I'd suggest doing the opposite: checking for valid build options (and note: this is a check for DEB_BUILD_OPTIONS, not for DEB_BUILD_PROFILES). There is a very short list of standard build options: those listed in dpkg-buildpackage(1) (parallel=n, nocheck, noopt, nostrip, terse, hardening=..., reproducible=..., abi=..., future=..., qa=..., optimize=..., sanitize=...) and https://wiki.debian.org/BuildProfileSpec: nodoc Best wishes, Julian
Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8
On Wed, Apr 03, 2024 at 03:58:21PM -0400, Jeremy Bícha wrote: > I noticed one package affected by this issue, prettytable, has > switched to a fork, pytest-lazy-fixtures (note the s at the end of the > name). > > Would someone like to package this for Debian to fix several packages > failing to build? > > https://github.com/dev-petrov/pytest-lazy-fixtures > > Thank you, > Jeremy Bícha Dear all affected by pytest-lazy-fixture: pytest-lazy-fixtures is now in testing and unstable; in many cases, it can be used as a drop-in replacement for pytest-lazy-fixture (though not all, it turns out). I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from Debian unstable. Best wishes, Julian
Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
On Thu, May 09, 2024 at 01:13:45PM -0400, Louis-Philippe Véronneau wrote: > tags 1070770 patch > thanks > > I've created a patch on Salsa that creates a new Lintian check for this. > > https://salsa.debian.org/lintian/lintian/-/merge_requests/504 Amazing, thanks! I've added a bunch of suggestions/comments to the patch: the erroneous check in debian/rules is for the DEB_BUILD_OPTIONS setting rather than the DEB_BUILD_PROFILES setting, so it should refer to "options" rather than "profiles", even though the description for the "nodoc" option appears on the BuildProfilesSpec wiki page! I also suggest one tweak to the regex. Best wishes, Julian
Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
Package: lintian Version: 2.117.0 Severity: wishlist I have come across a number of packages with a line in their debian/rules like: ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS))) This should be "nodoc", according to the "nodoc" entry in https://wiki.debian.org/BuildProfileSpec#Registered_profile_names It would be good to check for this error.
Bug#1070485: spyder: fails with pytest 8 due to dependency on pytest-lazy-fixture
Package: spyder Version: 5.5.1+ds-1 Severity: normal Tags: upstream See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063957 and https://github.com/spyder-ide/spyder/issues/21935 This affects just one test file: spyder/plugins/completion/providers/languageserver/tests/test_client.py Unfortunately, simply replacing pytest-lazy-fixture with pytest-lazy-fixtures does not work; see https://github.com/dev-petrov/pytest-lazy-fixtures/issues/17 For the time being, I'm disabling this test but recording this as a bug in the BTS to keep track of this.
Bug#1070452: ITP: pytest-lazy-fixtures -- pytest plugin to use fixtures in @pytest.mark.parametrize
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 1063...@bugs.debian.org * Package name: pytest-lazy-fixtures Version : 1.0.7 Upstream Contact: Petrov Anton * URL : https://github.com/dev-petrov/pytest-lazy-fixtures * License : Expat Programming Lang: Python Description : pytest plugin to use fixtures in @pytest.mark.parametrize This plugin was inspired by pytest-lazy-fixture; that plugin is incompatible with pytest 8.x, so this can be used as a replacement. . Improvements that have been made in this project: . * You can use fixtures in any data structures * You can access the attributes of fixtures * You can use functions in fixtures This will allow those packages using pytest-lazy-fixture (which is now unusable in debian/testing) in their tests to migrate to this maintained alternative. (See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063957) It will be maintained within the Debian Python Team, and I will be listed as an Uploader.
Bug#1070188: python3-spyder: uninstallable in unstable due to pylint
On Fri, May 03, 2024 at 02:14:36PM +0200, Roland Mas wrote: > Le 02/05/2024 à 06:07, Julian Gilbey a écrit : > > On Wed, May 01, 2024 at 03:04:56PM +0200, Roland Mas wrote: > > > Package: python3-spyder > > > Version: 5.5.1+ds-1 > > > Severity: important > > > > > > Dear Maintainer, > > > > > > python3-spyder is no longer installable in sid; it depends (and > > > build-depends) on pylint (< 3.1~) but pylint is currently 3.1.0-1 in > > > unstable. > > > > > > Loosening the versioned dependency is enough to allow spyder to build, > > > but I don't know whether that introduces runtime changes or not. > > Dear Roland, > > > > That would be a reasonable thing to do. Version 5.5.4 depends on > > pylint >= 3.1. I don't have time to do this right now, unfortunately, > > so if someone else would like to make the required changes and upload > > a patched version of 5.5.1 in the meantime, please feel free to do > > so. > > I guess I could do that, but is there any reason not to upgrade to 5.5.4 > directly? Maybe I'm fooled by only the "micro" part of the version number > changing, but it doesn't sound like a big upgrade… > > Roland. Several other dependencies would also need to be upgraded. Because of this, generally takes a while to do even minor version upgrades and to investigate any newly failing tests in the process. I am currently quite overloaded in my Day Job, and have some other RC bugs to address as well, so I won't realistically be able to do that until at least June. Best wishes, Julian
Bug#1070188: python3-spyder: uninstallable in unstable due to pylint
On Wed, May 01, 2024 at 03:04:56PM +0200, Roland Mas wrote: > Package: python3-spyder > Version: 5.5.1+ds-1 > Severity: important > > Dear Maintainer, > > python3-spyder is no longer installable in sid; it depends (and > build-depends) on pylint (< 3.1~) but pylint is currently 3.1.0-1 in > unstable. > > Loosening the versioned dependency is enough to allow spyder to build, > but I don't know whether that introduces runtime changes or not. Dear Roland, That would be a reasonable thing to do. Version 5.5.4 depends on pylint >= 3.1. I don't have time to do this right now, unfortunately, so if someone else would like to make the required changes and upload a patched version of 5.5.1 in the meantime, please feel free to do so. See https://github.com/spyder-ide/spyder/commit/26244db2750f92aa6cbbfd74252d6aa4daa07811 for the changes required (but obviously don't change python-lsp-server for now!). Best wishes, Julian
Bug#1070215: python-qtpy: Please support qtpy abstraction in packaging
Hi Stuart, On Thu, May 02, 2024 at 09:50:46AM +1000, Stuart Prescott wrote: > Source: python-qtpy > Version: 2.4.1-2 > Severity: normal > X-Debbugs-Cc: stu...@debian.org > > Dear Maintainer, > > The qtpy description says "Abstraction layer for PySide2/PySide6/PyQt5/PyQt6" > however the packaging for python3-qtpy is optimised only for applications > using PyQt5, declaring Depends on all the python3-pyqt5 packages. > > An application that uses qtpy and any library other than pyqt5 needs to > have pyqt5 installed in addition to what is actually required. > [...] Indeed; I have had a similar discussion a while back with one of the other qtpy maintainers, but I don't remember the details. I like your idea about having python3-qtpy-* packages; I hadn't thought of doing this, and it would be the least disruptive for reverse dependencies, as they could simply change to one of the python3-qtpy-* packages. I don't have the capacity to do this myself, but please feel free to do a team upload. If going down this route, the src:python-qtpy testsuite could be enhanced to test the various different backends. (This is supported by upstream, if I recall correctly.) Before you do this, though, please do compile a list of reverse dependencies that would be hit by this change so we understand the scope of the impact. > One possible solution to this would be for src:python-qtpy to include > the following packages: > > Package: python3-qtpy > Depends: python3-packaging > Contains: everything > > Package: python3-qtpy-pyqt5 > Depends: python3-qtpy, python3-pyqt5, python3-pyqt5.* > Contains: probably nothing > > Package: python3-qtpy-pyqt6 > Depends: python3-qtpy, python3-pyqt6, python3-pyqt6.* > Contains: probably nothing > > Package: python3-qtpy-pyside6 > Depends: python3-qtpy, python3-pyside6.* > Contains: probably nothing > Another solution is for python-qtpy to declare at most Suggests on any > of the pyqt/pyside packages and leave it to the application to declare > dependencies on the toolkit packages it needs. The application package > knows what toolkit and libraries are required while, by design, qtpy > does not. This would also provide better support for the split toolkit > packages given that Qt5 and Qt6 are modularised - the application can > depend on only what is needed rather than having all the split packages > installed just in case. This seems superfluous given your suggestion above: your new python3-qtpy package would be exactly this, except lacking the Suggests. (It should, of course, also suggest the python3-qtpy-* packages.) But given that python3-qtpy is extremely unlikely to be requested by an individual user - it is instead a runtime dependency of other packages - having a long list of Suggests is unlikely to bring much benefit. > PySide6 will hit NEW soon-ish and sasview will need the updated > packaging for qtpy soon after. I wouldn't do the qtpy update, then, until PySide6 has reached testing, or it will need two journeys to NEW itself. > I'm happy to do a Team Upload to implement whichever agreed strategy you > prefer. Best wishes, Julian
Bug#1069357: cpp-httplib: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --timeout-multiplier=3 --test-arg
On Sat, Apr 20, 2024 at 01:59:57PM +0200, Lucas Nussbaum wrote: > Source: cpp-httplib > Version: 0.14.3+ds-1.1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on arm64. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > dh_auto_test -- \ > > --timeout-multiplier=3 \ > > --test-args='--gtest_filter=-*_Online' > > cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb > > LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --timeout-multiplier=3 > > --test-args=--gtest_filter=-\*_Online > > ninja: Entering directory `/<>/obj-aarch64-linux-gnu' > > ninja: no work to do. > > 1/1 main TIMEOUT900.12s killed by signal 15 SIGTERM Hi Andrea, It looks like it's just that arm64 is slow (as are several other archs). Changing the command to read --timeout-multiplier=30 should fix this FTBFS serious bug and allow cpp-httplib to migrate to testing. Best wishes, Julian
Bug#1069624: rapidfuzz: Fails to build on arch: all
Hi Jeremy, On Sun, Apr 21, 2024 at 02:01:26PM -0400, Jeremy Bícha wrote: > Source: rapidfuzz > Version: 3.6.2+ds-2 > Severity: serious > Tags: ftbfs > > The arch: all build for rapidfuzz is failing: > > https://buildd.debian.org/status/package.php?p=rapidfuzz > > If you use sbuild, I believe you can test this with > sbuild -arch-all --no-arch-any Thanks for flagging this. I've only just fixed taskflow, and will be able to look at rapidfuzz later this week, all being well. It's surprising how many issues new packages can throw up when they're first build on the multiple archs by the buildds! Best wishes, Julian
Bug#1066036: black: Consider building faster native packages with mypyc
On Sat, Apr 20, 2024 at 04:50:20PM +0200, Michael R. Crusoe wrote: > On 19/04/2024 07.17, Julian Gilbey wrote: > > [...] > > > Dear Maintainer, > > > > > > I noticed that your package supports building native code extensions using > > > mypyc. Upstream themselves ship portable binary wheels for better > > > performance. As a member of the Debian Package Team, I would be happy to > > > add > > I should have said "Debian Python Package Team" > > > this to your package. Please let me know. > > [...] > > Thanks for the positive response. How do you want the mypyc compilation added > to the package? Do you want a diff, a merge-request on Salsa, or a team > upload? I'm not the primary maintainer, so I suggest a team upload once hatch-pypyc has made it to testing. Best wishes, Julian
Bug#1066036: black: Consider building faster native packages with mypyc
On Mon, Mar 11, 2024 at 02:49:26PM +0100, Michael R. Crusoe wrote: > Package: black > Version: 23.1.0-1 > Severity: wishlist > X-Debbugs-Cc: cru...@debian.org > > Dear Maintainer, > > I noticed that your package supports building native code extensions using > mypyc. Upstream themselves ship portable binary wheels for better > performance. As a member of the Debian Package Team, I would be happy to add > this to your package. Please let me know. This sounds like a nice idea; the pyproject.toml file states: [tool.hatch.build.targets.wheel.hooks.mypyc] enable-by-default = false dependencies = [ "hatch-mypyc>=0.16.0", "mypy==1.7.1", "click==8.1.3", # avoid https://github.com/pallets/click/issues/2558 ] so you would have to build python3-hatch-pypyc first, though. If you can do that, this would be plausible. I would guess that using mypyc would depend on having mypyc in Debian, but at the moment it's only an ITP (#932003). Best wishes, Julian
Bug#1069261: cwlformat: fails with newer ruamel.yaml
Package: cwlformat Version: 2022.02.18-2 Severity: serious Tags: patch I've uploaded ruamel.yaml version 0.18.6 and it has unfortunately broken the test suite of cwlformat. There is a simple patch, applied upstream, to fix this: it just updates the expected output of the test. It is here: https://github.com/rabix/cwl-format/commit/486a92b9667f80ed6a217bbb8f5683ae342f1d43 You would also need to version python3-ruamel.yaml (>= 0.18.6) in the Build-Depends, as otherwise the test will fail when tested against the older version of the package. It doesn't need this restriction in the binary package, though, but the debian/tests/control will do, otherwise that will also fail. I think I'll need to add a Breaks: cwlformat (<< 2022.02.18-3) in python3-ruamel.yaml too, in order to allow migration. Thanks for your help! If you want me to do an NMU, I can do so (I'm not in debian-med, so I don't think I can push to your salsa repo though. Best wishes, Julian
Bug#1059838: cython: autopkgtest regression with Python 3.12 on ppc64el
severity 1059838 normal thanks On Tue, Jan 02, 2024 at 11:59:09AM +0200, Graham Inggs wrote: > Source: cython > Version: 3.0.7-2 > Severity: serious > User: debian-pyt...@lists.debian.org > Usertags: python3.12 > > Hi Maintainer > > cython's autopkgtests fail with Python 3.12 on ppc64el[1]. I've > copied what I hope is the relevant part of the log below. > > Regards > Graham This has been forwarded upstream and they have suggested it might be a limited-memory issue; there has been no further work on it. The test has been disabled for now, so downgrading the severity to normal. Best wishes, Julian
Bug#1068867: python3-reno: SyntaxWarning: invalid escape sequence
Package: python3-reno
Version: 2.11.2-4
Severity: normal
On a testing system, Python 3.12 flags the following warnings when
setting up python3-reno:
Setting up python3-reno (2.11.2-4) ...
/usr/lib/python3/dist-packages/reno/config.py:68: SyntaxWarning: invalid escape
sequence '\d'
textwrap.dedent('''\
/usr/lib/python3/dist-packages/reno/config.py:79: SyntaxWarning: invalid escape
sequence '\.'
textwrap.dedent('''\
/usr/lib/python3/dist-packages/reno/tests/test_exts.py:102: SyntaxWarning:
invalid escape sequence '\d'
textwrap.dedent('''\
/usr/lib/python3/dist-packages/reno/tests/test_exts.py:113: SyntaxWarning:
invalid escape sequence '\d'
expected = textwrap.dedent("""\
/usr/lib/python3/dist-packages/reno/tests/test_scanner.py:71: SyntaxWarning:
invalid escape sequence '\s'
gnupg_version_re = re.compile('^gpg\s.*\s([\d+])\.([\d+])\.([\d+])')
These can presumably be fixed by making the strings raw or quoting the
backslashes (making the strings raw with the """\ wouldn't work,
though).
Best wishes,
Julian
Bug#958024: Package available on Salsa
On Tue, Feb 02, 2021 at 11:03:43AM +0100, Adam Cecile wrote: > Hello, > > I already had a package for this, sadly not uploaded to Salsa. > > I just did: > https://salsa.debian.org/python-team/packages/openapi-spec-validator > > Feel free to get it uploaded into the archive in interested in! > > Regards, Adam. Thanks Adam! I'll pick this one up over the next week or two. Best wishes, Julian
Bug#1068792: dch: warning message: "realpath: '': No such file or directory"
Package: devscripts Version: 2.23.7 Severity: normal When running dch -i, I get the warning message: realpath: '': No such file or directory before the editor starts. This is possibly due to the setting of EDITOR and/or VISUAL: I have set them to "emacs -nw". Other than this warning, dch seems to work fine. Best wishes, Julian
Bug#761152: python-strict-rfc3339: changing from ITP to RFP
retitle 761152 ITP: python-strict-rfc3339 -- Strict, simple, lightweight RFC3339 functions owner 761152 ! thanks On Sun, Dec 27, 2015 at 01:16:59PM +0100, Lucas Nussbaum wrote: > retitle 761152 RFP: python-strict-rfc3339 -- Strict, simple, lightweight > RFC3339 functions > noowner 761152 > tag 761152 - pending > thanks > [...] I've updated Adam Cecile's packaging work on salsa for this package and uploaded it to NEW. (It's a test-time dependency of some of the jupyter* packages or their dependencies.)
Bug#1068693: node-mathjax-full: "MathJax(?): class constructors must be invoked with 'new'"
Package: node-mathjax-full Version: 3.2.2+~cs4.2.1-2 Severity: normal I invoked MathJax using the line: in the header of a file, but MathJax would not load; the console gave the error message: MathJax(?): class constructors must be invoked with 'new' referring to tex-mml-chtml.js:1:18018 Any ideas? Best wishes, Julian
Bug#1068553: ITP: python-overrides -- Python decorator to verify that expected overrides are maintained
Oh, oops. Not sure what to suggest at this point; perhaps I could drop a note to the ftpmasters? There's not much difference between them (except that I used pytest to get autopkgtest to work and my package description was much less detailed). Whichever one is accepted, we should certainly drop or archive the salsa repo for the other! I don't have any views either way. Best wishes, Julian On Mon, Apr 08, 2024 at 04:59:13PM +0200, Roland Mas wrote: > overrides is already in NEW, with packaging hosted on > https://salsa.debian.org/python-team/packages/overrides. Sorry, I should > have filed an ITP for that. > > Roland. > > Le 07/04/2024 à 11:02, Julian Gilbey a écrit : > > Package: wnpp > > Severity: wishlist > > Owner: Julian Gilbey > > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org > > > > * Package name: python-overrides > >Version : 7.7.0 > >Upstream Author : Copyright: Mikko Korpela > > * URL : https://github.com/mkorpela/overrides > > * License : Apache-2.0 > >Programming Lang: Python > >Description : Python decorator to verify that expected overrides are > > maintained > > Provides a decorator @override that verifies that a method that > > should override an inherited method actually does it. Python has no > > standard mechanism by which to guarantee that (1) a method that > > previously overrode an inherited method continues to do so, and (2) a > > method that previously did not override an inherited will not > > override now. This package allows this to be addressed in an automated > > manner. > > > > This package is a (recursive) dependency of the new version of > > jupyter-server. > > > > It will be team-maintained within the Debian Python Team. The Debian > > packaging is on salsa at > > https://salsa.debian.org/python-team/packages/python-overrides > > > Julian
Bug#1068625: python3-sphinxcontrib.httpdomain: SyntaxWarning: invalid escape sequence '\s'
Package: python3-sphinxcontrib.httpdomain
Version: 1.8.0-3
Severity: normal
Tags: patch
When installing this package in unstable (so it is byte-compiled by
python3.12), the following warning appears:
/usr/lib/python3/dist-packages/sphinxcontrib/autohttp/flask_base.py:82:
SyntaxWarning: invalid escape sequence '\s'
rcomp = re.compile("^\s*.. :quickref:\s*(?P.*)$")
Patch: either the regexp needs to be a raw string (r"^\s*.. [...]"),
or the two backslashes need quoting ("^\\s*.. [...]").
Best wishes,
Julian
Bug#1068557: ITP: sphinxcontrib-openapi -- Sphinx extension to generate API docs from OpenAPI spec
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinxcontrib-openapi Version : 0.8.4 Upstream Author : Ihor Kalnytskyi * URL : https://github.com/sphinx-contrib/openapi * License : BSD-2-clause Programming Lang: Python Description : Sphinx extension to generate API docs from OpenAPI spec This extension generates API documentation for reStructuredText documentation using the Sphinx system. It also depends on `sphinxcontrib.httpdomain` that provides an HTTP domain for describing RESTful HTTP APIs. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/sphinxcontrib-openapi
Bug#1068556: ITP: sphinxcontrib-emojicodes -- Sphinx extension to use emoji codes in Sphinx documentation
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinxcontrib-emojicodes Version : 0.3.1 Upstream Author : Copyright: The Sphinx Emoji Codes contributors * URL : https://github.com/sphinx-contrib/emojicodes * License : BSD-3-clause Programming Lang: Python Description : Sphinx extension to use emoji codes in Sphinx documentation This extension allows one to write things like |:smile:| in Sphinx documentation. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/sphinxcontrib-emojicodes
Bug#1068555: ITP: rfc3986-validator -- RFC 3986 validator (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rfc3986-validator Version : 0.1.1 Upstream Author : Nicolas Aimetti * URL : https://github.com/naimetti/rfc3986-validator * License : Expat Programming Lang: Python Description : RFC 3986 validator (Python library) This package provides a validator for URIs to determine whether they conform to the Internet Engineering Task Force (IETF) specification (RFC 3986). This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/rfc3986-validator
Bug#1068554: ITP: rfc3339-validator -- RFC 3339 validator (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rfc3339-validator Version : 0.1.4 Upstream Author : Nicolas Aimetti * URL : https://github.com/naimetti/rfc3339-validator * License : Expat Programming Lang: Python Description : RFC 3339 validator (Python library) This package provides a validator for date-time strings to determine whether they conform to the Internet Engineering Task Force (IETF) Internet Date/Time Format (RFC 3339). This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/rfc3339-validator
Bug#1068553: ITP: python-overrides -- Python decorator to verify that expected overrides are maintained
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-overrides Version : 7.7.0 Upstream Author : Copyright: Mikko Korpela * URL : https://github.com/mkorpela/overrides * License : Apache-2.0 Programming Lang: Python Description : Python decorator to verify that expected overrides are maintained Provides a decorator @override that verifies that a method that should override an inherited method actually does it. Python has no standard mechanism by which to guarantee that (1) a method that previously overrode an inherited method continues to do so, and (2) a method that previously did not override an inherited will not override now. This package allows this to be addressed in an automated manner. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-overrides
Bug#1068552: ITP: python-isoduration -- Operations with ISO 8601 durations (Python 3 package)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-isoduration Version : 20.11.0+git20211126.ae0bd61 Upstream Author : Víctor Muñoz * URL : https://github.com/bolsote/isoduration * License : ISC Programming Lang: Python Description : Operations with ISO 8601 durations (Python 3 package) ISO 8601 supports time durations in string format, for example "P3Y6M4DT12H30M5S" represents a duration of 3 years, 6 months, 4 days, 12 hours, 30 minutes, and 5 seconds. This package supports working with such durations, addressing the shortcomings of the isodate package. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-isoduration
Bug#1068551: ITP: python-fqdn -- Python library to validate fully qualified domain names (FQDNs)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-fqdn Version : 1.5.1 Upstream Author : ypcrts * URL : https://github.com/ypcrts/fqdn * License : MPL-2.0 Programming Lang: Python Description : Python library to validate fully qualified domain names (FQDNs) This package validates FQDNs conforming to the Internet Engineering Task Force (IETF) specification (RFC 1123 in particular). The design intent is to validate that a string would be traditionally acceptable as a public Internet hostname to RFC-conforming software. Configuration options can be used to obtain more relaxed checks. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-fqdn
Bug#1068550: ITP: pytest-mypy-testing -- Plugin to test mypy output with pytest
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-mypy-testing Version : 0.1.3 Upstream Author : Copyright: David Fritzsche * URL : https://github.com/davidfritzsche/pytest-mypy-testing * License : CC0-1.0 Programming Lang: Python Description : Plugin to test mypy output with pytest This plugin provides a way to test that mypy produces a given output. As mypy can be told to display the type of an expression, this allows one to check mypy's type interference. This package is a test-time dependency of the new version of traitlets; the current version in unstable has the relevant tests ignored at present, but it would be good to be able to include these tests in the autopkgtest suite. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pytest-mypy-testing
Bug#1068549: ITP: pytest-console-scripts -- Pytest plugin for running Python scripts from within tests
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-console-scripts Version : 1.4.1 Upstream Author : Vasily Kuznetsov * URL : https://github.com/kvas-it/pytest-console-scripts * License : Expat Programming Lang: Python Description : Pytest plugin for running Python scripts from within tests This plugin is quite similar to `subprocess.run()`, but it also has an in-process mode, where the scripts are executed by the interpreter that's running `pytest` (using some amount of sandboxing). . In-process mode significantly reduces the run time of the test suites that run many external scripts. This is speeds up development. In a CI environment subprocess mode can be used to make sure the scripts also work (and behave the same) when run by a fresh interpreter. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pytest-console-scripts
Bug#1068548: ITP: picobox -- Opinionated Python dependency injection framework
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: picobox Version : 4.0.0 Upstream Author : Ihor Kalnytskyi * URL : https://github.com/ikalnytskyi/picobox * License : Expat Programming Lang: Python Description : Opinionated Python dependency injection framework Picobox is designed to be clean, pragmatic and with Python in mind. No complex graphs, no implicit injections, no type bindings - just picoboxes and explicit demands. . It is a small, thread-safe, pure Python library with no dependencies. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/picobox
Bug#1068547: ITP: jupyter-server-terminals -- Jupyter server extension providing support for terminals
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: jupyter-server-terminals Version : 0.5.3 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter-server/jupyter_server_terminals * License : BSD-3-clause Programming Lang: Python Description : Jupyter server extension providing support for terminals This package allows Jupyter servers to interface to terminals via Tornado websockets. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/jupyter-server-terminals
Bug#1068546: ITP: async-asgi-testclient -- Python async client for testing ASGI web applications
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: async-asgi-testclient Version : 1.4.11 Upstream Author : Jordi Masip * URL : https://github.com/vinissimus/async-asgi-testclient * License : Expat Programming Lang: Python Description : Python async client for testing ASGI web applications This library is used for testing ASGI (Asynchronous Server Gateway Interface) applications. It is designed to be a common testing library for such applications that does not depend on the specific web framework being used. . It works by calling the ASGI app directly rather than via a web server. This package is a (recursive) dependency of the new version of jupyter-server. (More precisely, it is a test-time dependency of a currently unreleased version of picobox.) It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/async-asgi-testclient
Bug#1057870: RFP: sphinx-mdinclude -- Sphinx extension for including or writing pages in Markdown format
retitle 1057870 ITP: sphinx-mdinclude -- Sphinx extension for including or writing pages in Markdown format owner 1057870 j...@debian.org thanks On Sat, Dec 09, 2023 at 09:37:47PM +, Martin wrote: > Package: wnpp > Severity: wishlist > > * Package name: sphinx-mdinclude > Version : v0.5.3 > Upstream Author : Hiroyuki Takagi etc. > * URL or Web page : https://github.com/omnilib/sphinx-mdinclude > * License : MIT > Programming Lang: Python > Description : Sphinx extension for including or writing pages in > Markdown format > > sphinx-mdinclude is a simple Sphinx extension that enables including > Markdown documents from within reStructuredText. It provides the .. > mdinclude:: directive, and automatically converts the content of > Markdown documents to reStructuredText format. > > sphinx-mdinclude is a fork of m2r and m2r2, focused only on providing a > Sphinx extension. I'll take this one! Best wishes, Julian
Bug#1068407: xfce4-terminal: processes sleep after a while when switching to a different workspace
Package: xfce4-terminal Version: 1.1.1-1 Severity: normal This is a weird bug, and I have no idea how to locate the source. I'm running in an Xfce4 environment (xfce4-session, xfce4-panel, xfce4-screensaver, xfce4-terminal and various other applications such as firefox) on a Debian testing machine. I have four workspaces on my desktop. If I start a long-running process in a terminal, for example an sbuild, it runs absolutely fine. But if I switch to a different workspace, it seems that the process just freezes - when I return to the workspace some time later, it continues from where it was. This makes it impossible to reliably have long-running jobs in a terminal. This behaviour started relatively recently (probably within the last month or so). I've tried upgrading xfce4-terminal to 1.1.3-1 (rebuilt for debian/testing), but while it seemed to work better for a little while, it soon started doing the same thing. Do you have any idea what might be causing this? It might not be due to xfce4-terminal itself, of course. Thanks! Julian
Bug#1068381: closed by Debian FTP Masters (reply to Andrius Merkys ) (Bug#1068381: fixed in openapi-specification 3.1.0-2)
Wow, that was fast - thank you! Best wishes, Julian On Thu, Apr 04, 2024 at 11:39:06AM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the openapi-specification package: > > #1068381: openapi-specification: please include examples in Debian package > > It has been closed by Debian FTP Masters > (reply to Andrius Merkys ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > (reply to Andrius Merkys > ) by > replying to this email. > > > -- > 1068381: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068381 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > Date: Thu, 04 Apr 2024 11:34:30 + > From: Debian FTP Masters > Subject: Bug#1068381: fixed in openapi-specification 3.1.0-2 > To: 1068381-cl...@bugs.debian.org > > Source: openapi-specification > Source-Version: 3.1.0-2 > Done: Andrius Merkys > > We believe that the bug you reported is fixed in the latest version of > openapi-specification, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 1068...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Andrius Merkys (supplier of updated openapi-specification > package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Format: 1.8 > Date: Thu, 04 Apr 2024 07:02:32 -0400 > Source: openapi-specification > Architecture: source > Version: 3.1.0-2 > Distribution: unstable > Urgency: medium > Maintainer: Andrius Merkys > Changed-By: Andrius Merkys > Closes: 1068381 > Changes: > openapi-specification (3.1.0-2) unstable; urgency=medium > . >[ Debian Janitor ] >* Apply multi-arch hints. + openapi-specification: Add Multi-Arch: foreign. >* Set upstream metadata fields: Bug-Database, Bug-Submit, > Repository-Browse. > . >[ Andrius Merkys ] >* Install examples (Closes: #1068381). >* Add 'Repository' to debian/upstream/metadata. >* Bump Standards-Version to 4.6.2 (no changes). >* Bump copyright year. > Checksums-Sha1: > 8ae465ff9afc6e2c9769b834a13d622adab0baed 1979 > openapi-specification_3.1.0-2.dsc > ec05a031f1fd591a475907eed4fff865e210dc06 1916 > openapi-specification_3.1.0-2.debian.tar.xz > 7f62eaffb8cbdc20bff88b4f5e4207af2c1e5a49 6643 > openapi-specification_3.1.0-2_source.buildinfo > Checksums-Sha256: > 44f6c1e8c3f50bf5bd4d8f9a3de5bf38abf3b88571056a1c0eb2a919add52546 1979 > openapi-specification_3.1.0-2.dsc > c6d486f6d135c8117bf69f8639af1738483cfc99c4534429032765ec1d5a103b 1916 > openapi-specification_3.1.0-2.debian.tar.xz > fb46904ee1b822a0e1a898aca5ae3f0b58728b1436cf9aa410df3f33e2f8c073 6643 > openapi-specification_3.1.0-2_source.buildinfo > Files: > e04c753c5338c275baed48d76e5dd2a5 1979 web optional > openapi-specification_3.1.0-2.dsc > a321b5c416136e3914bee3988b9fbf60 1916 web optional > openapi-specification_3.1.0-2.debian.tar.xz > 1cf03a0e38108fbc83826e02ac62d49e 6643 web optional > openapi-specification_3.1.0-2_source.buildinfo > > -BEGIN PGP SIGNATURE- > > iQJGBAEBCgAwFiEEdyKS9veshfrgQdQe5fQ/nCc08ocFAmYOjEISHG1lcmt5c0Bk > ZWJpYW4ub3JnAAoJEOX0P5wnNPKHOpAQAIDCMppvcxHRkVW2KrFRsvOqG+J253T9 > 1b0vFq2BJcKXrkgNQUxIJRh4OBP1256WWnGUQhg+3LeyVwEtBPHvRyqi2LIVM809 > KSz3ucA+HgdkrONhyk/fC6bhL/7+XlPHGhcf/IerxYJp1CzOfQ8E6ynoSQHzxf1c > 7jlCi73WBw7+b4Lkc6d7ZKe8G6JEGstuJc7gy2wQN7teKVyO6xu3k6q2sllaAgfF > 9GzduxThAqIekRpW6S2QVrx1+Ciy54QuYvjQPdAtzWJ40YM3QWMdg3DMABEeg2j4 > lfO8Zzjy/x269QBX1+hZDvt/ywEgrmZYITW4sVsotHxArHptj1P821DnUxWD/YY8 > PtjeztyOPALveZ5NKb1jIWhqd4iiOZ6LVnjcg2kL/4HKylSDtJdkS4XlIXWN1QtZ > km0rWF2tpKzdpHfi9uhSYJanda+vVES1nd5ZRqmyNEcn5s9XFM20UMpXCQe0Yjep > gFIjxg7WolZB/37EKSuUTmXBTQEWLDulFjsYDKd4htleRWF5UTIHSr7wlmk490xK > LqoXyeYfphrKIxiGVechthi7kWea96z5jB/9su88jCceHOnUU9tXIVKH24ar4I/2 > GN4Y4IhbascWpnlBX7oA93ry9ja+BOYagTKCLixJ/eeq5EbAQvmUqwIbjgoljf7y > 4zVqcfTv0od1 > =OD5C > -END PGP SIGNATURE- > > Date: Thu, 04 Apr 2024 11:07:38 +0100 > From: Julian Gilbey > Subject: openapi-specificatio
Bug#745103: [Pkg-utopia-maintainers] Bug#745103: Bug#795023: [network-manager] Bricks DNS when disconnecting from a VPN, separately ignores instruction not to use VPN DNS servers
On Thu, Apr 04, 2024 at 10:28:08AM +0200, Michael Biebl wrote: > Am 04.04.24 um 07:21 schrieb Julian Gilbey: > > > Hi Michael, > > > > Ah, you've probably just solved my problem - thank you! I had no idea > > that there was another network management tool involved. A quick look > > suggests that it's ifupdown, so I'll try removing that and see what > > happens. > > Don't forget to remove the configuration from /etc/network/interfaces (or > completely remove that file) after uninstalling ifupdown. Thanks; I figured that out after a while ;-) And I'm pleased to say it's all working well now. Best wishes, Julian
Bug#1068381: openapi-specification: please include examples in Debian package
Package: openapi-specification Version: 3.1.0-1 Severity: normal Hi! Would it be possible to include the OpenAPI-Specification examples in the Debian package? (Adding debian/examples with the single line: examples/* would do it.) They're used in the test suite of a package I'm trying to build, and it would be great to be able to just depend on the Debian package for this. Best wishes, Julian
Bug#745103: [Pkg-utopia-maintainers] Bug#745103: Bug#795023: [network-manager] Bricks DNS when disconnecting from a VPN, separately ignores instruction not to use VPN DNS servers
On Wed, Apr 03, 2024 at 03:41:17PM +0200, Michael Biebl wrote: > Am 03.04.24 um 13:42 schrieb Julian Gilbey: > [...] > > I can confirm that something like this is still happening with > > network-manager 1.46.0-1 (Debian testing machine), when using > > network-manager-strongswan: before switching on the VPN, > > /etc/resolv.conf reads: > > > > nameserver 192.168.0.1 > > nameserver 0.0.0.0 > > If that is really /etc/resolv.conf verbatim, it means it was not created by > NetworkManager. Which somehow suggests you use another network management > tool besides NetworkManager. > A mix and match is not a good idea and as far as I'm concerned, > unsupportable. Hi Michael, Ah, you've probably just solved my problem - thank you! I had no idea that there was another network management tool involved. A quick look suggests that it's ifupdown, so I'll try removing that and see what happens. Best wishes, Julian
Bug#745103: Bug#795023: [network-manager] Bricks DNS when disconnecting from a VPN, separately ignores instruction not to use VPN DNS servers
On Thu, Aug 20, 2015 at 09:20:10PM +0100, OmegaPhil wrote: > Package: network-manager > Version: 1.0.4-1 > > I have played around with this some more - the idea with the work VPN > connection is not that it takes over everything, but simply that one > particular IP address gets routed to it - everything else works as normal. > > This is why I'm ignoring routes etc, with 'Automatic (VPN) addresses > only' used with the intention of not fiddling with the current DNS > configuration, which is failing. > > The workaround is to manually set 'DNS servers' and 'Search domains' to > the normal values outside of the VPN, rather than leaving them blank, > which Network Manager can't seem to cope with. I can confirm that something like this is still happening with network-manager 1.46.0-1 (Debian testing machine), when using network-manager-strongswan: before switching on the VPN, /etc/resolv.conf reads: nameserver 192.168.0.1 nameserver 0.0.0.0 then with the VPN on, it becomes # Generated by NetworkManager nameserver nameserver but after the VPN is switched off, it collapses to just one line: # Generated by NetworkManager making DNS lookups impossible. Manually reverting /etc/resolv.conf to its original state restores normal networking. Best wishes, Julian
Bug#1061152: asymptote: autopkgtest should test installed package
Hi Hilmar, On Wed, Jan 24, 2024 at 06:07:56PM +0100, Sven Joachim wrote: > [...] > > Hello, > > > >> Your package's autopkgtest runs the upstream test suite which is > >> nice. However, it first builds the program and then tests that, > >> rather than the package from the archive. This is not very useful, > >> as changes in reverse dependencies could cause breakage at runtime > >> which might vanish after a rebuild. [...] (followed by suggestion of how to fix this) If Sven's patch works, you would also be able to drop most of the test-time dependencies and depend only on asymptote itself (and maybe one or two other packages), as you would not need to build asymptote. Best wishes, Julian
Bug#1060128: ITP: python-sphinxcontrib-github-alt -- Sphinx extension for easy GitHub links
On Fri, Mar 22, 2024 at 07:42:12AM +, Julian Gilbey wrote: > [...] > Thanks for this ITP! Two things: > > (1) I recommend that this package is called > python-sphinxcontrib.github-alt with a dot after "sphinxcontrib" to > keep it in line with the names of all the other sphinxcontrib packages > in Debian. Ah, it turns out that I'm wrong about this; the other packages are called "sphinxcontrib.foo" because that is the name of the Python module; here the module is literally called sphinxcontrib_github_alt, so your proposed package name is correct. I'm planning to package it today. Best wishes, Julian
Bug#1065445: pristine-tar: fails if upstream tarball top directory name is capitalised
severity 1065445 important thanks On Tue, Mar 05, 2024 at 05:08:27PM +, Julian Gilbey wrote: > [...] > > I have reported this as a severity "important" bug because it may > silently (or not so silently) affect many packages. Well, I thought I'd reported this as "important", but it seems I forgot to actually do so. Raising the severity now. Best wishes, Julian
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi Diane, On Sat, Mar 30, 2024 at 08:59:39PM -0700, Diane Trout wrote: > Hi Julian, > > On Sat, 2024-03-30 at 20:22 +0000, Julian Gilbey wrote: > > Lovely to hear from you, and oh wow, that's amazing, thank you! > > > > I can't speak for anyone else, but I suggest that pushing your > > updates > > to the science-team package would be very sensible; it would be silly > > for someone else to have to redo your work. > > > > What more is needed for it to be ready for unstable? > > > The things I think are kind of broken are: > > We've got 7.0.0 and upstreams current version is 15.0.2. Yes, that does seem a little less than ideal! > the pyarrow 7.0.0 tests fail because it depends on a python test > library that breaks with pytest 8.0. Either I need to disable the > python tests or upgrade to a newer version. It may well be that newer versions would work with pytest 8.x. I don't think it's worth spending time trying to patch such a relatively old version. > My upgrade didn't go smoothly because uscan found also upstreams debian > watch file which is too loose and matches some other tar balls on their > distribution site. > > (Though I don't know why uscan keeps looking for watch files after > finding one in debian/watch) Oh dear. uscan(1) does say: Unless --watchfile is given, uscan looks recursively for valid source trees starting from the current directory (see the below section "Directory name checking" for details). and then: For each valid source tree found, typically the following happens: [...] so yes, it will look at more than one location. > And you were probably right in that arrow needs to be a team, because I > have no idea how to get other the other languages interfaces packaged. I suggest that without anyone else volunteering to do those other language interfaces (perhaps it's not a pressing need for people working with language X), I wonder whether it's worth just packaging the Python (and presumably C++) interfaces for now, and then if others want to join the effort to support language X later on, a new version of the Debian package can be uploaded with a new binary package for language X. It does mean more trips through the NEW queue if and when that happens, but given that no-one's shown interest in language X for the last several years, this is unlikely to be much of an issue. Version 7.0 provided support (it seems) for: GLib (seems that a draft framework for building this is already in the Debian package, and it can then be used in lots of languages), C++ (this is the core libraries), C# (not of interest to us), Go, Java, JavaScript, Julia, Matlab (not of interest to us), Python, R, Ruby. > Oh and I probably need to get the pyarrow installed somewhere, since it > was stopping at the tests I hadn't run into dh_missing errors yet. Oh. Would pybuild do that automatically (perhaps specifying PYBUILD_PACKAGE)? Best wishes, Julian
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi Diane, On Fri, Mar 29, 2024 at 11:49:07AM -0700, Diane Trout wrote: > On Mon, 2024-03-25 at 18:17 +0000, Julian Gilbey wrote: > > > > > > So this is a plea for anyone looking for something really helpful to > > do: it would be great to have a group of developers finally package > > this! There was some initial work done (see the RFP bug report for > > details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), > > but that is fairly old now. As Apache Arrow supports numerous > > languages, it may well benefit from having a group of developers with > > different areas of expertise to build it. (Or perhaps it would make > > more sense to split the upstream source into a collection of > > different > > Debian source packages for the different supported languages. I > > don't > > know.) Unfortunately I don't have the capacity to devote any time to > > it myself. > > > > Thanks in advance for anyone who can step forward for this! > > I've been maintain dask and anndata and saw that apache arrow was > getting increasingly popular. > > I took the current science-team preliminary packaging 7.0.0 packaging > and managed to get it to build through a combination of patches and > turning off features. > > I even mostly managed to get pyarrow to build. (Though some tests fail > due to pytest lazy-fixture being abandoned). > > I pushed my current work in progress to. > > https://salsa.debian.org/diane/arrow.git > > Was anyone else planning on working on it or should I push my updates > to the science-team package? Lovely to hear from you, and oh wow, that's amazing, thank you! I can't speak for anyone else, but I suggest that pushing your updates to the science-team package would be very sensible; it would be silly for someone else to have to redo your work. What more is needed for it to be ready for unstable? Best wishes, Julian
Bug#1067822: dh-python: build fails when using python3-flit-scm as SETUPTOOLS_SCM_PRETEND_VERSION is not set
Package: dh-python Version: 6.20240310 Severity: normal Tags: patch python3-flit-scm needs to be added to the list of packages requiring SETUPTOOLS_SCM_PRETEND_VERSION to be set. Merge request at: https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/56 Best wishes, Julian
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi all, [NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to set to d-science and the RFP bug only] An update on Apache Arrow, and in particular the Python library PyArrow. For those who don't know: Apache Arrow is a development platform for in-memory analytics. It contains a set of technologies that enable big data systems to process and move data fast. It specifies a standardized language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware. The project is developing a multi-language collection of libraries for solving systems problems related to in-memory analytical data processing. This includes such topics as: * Zero-copy shared memory and RPC-based data movement * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) * In-memory analytics and query processing (from: https://arrow.apache.org/docs/index.html) Pandas has announced that Pandas 3.x will depend on PyArrow in a critical way (it will back the "string" datatype), and it is due to be released imminently. So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! Best wishes, Julian
Bug#1060128: ITP: python-sphinxcontrib-github-alt -- Sphinx extension for easy GitHub links
On Sat, Jan 06, 2024 at 07:31:22AM +, Dale Richards wrote: > Package: wnpp > Severity: wishlist > Owner: Dale Richards > X-Debbugs-Cc: debian-de...@lists.debian.org, d...@dalerichards.net > > * Package name: python-sphinxcontrib-github-alt > Version : 1.2 > Upstream Contact: Jupyter Development Team > * URL : https://github.com/jupyter/sphinxcontrib_github_alt > * License : BSD 2-clause > Programming Lang: Python > Description : Sphinx extension for easy GitHub links > > Link to GitHub issues, pull requests, commits and users for a particular > project. > > I intend to maintain this package within the Debian Python Team. Hi Dale, Thanks for this ITP! Two things: (1) I recommend that this package is called python-sphinxcontrib.github-alt with a dot after "sphinxcontrib" to keep it in line with the names of all the other sphinxcontrib packages in Debian. (2) Have you had any time to work on this? I will probably need this package soon for another Jupyter package (latest version of jupyter-notebook), so I'd be happy to upload it to NEW when I get there if you don't have a chance. Best wishes, Julian
Bug#1030786: Please update jupyter-server to 1.23.5
On Tue, Feb 07, 2023 at 02:26:34PM +, Amr Ibrahim wrote: > Package: jupyter-server > > Hello, > > Please update jupyter-server to 1.23.5 if the jump to version 2.2.1 is > not appropriate. > [...] Hi Amr and Julien, et al, I just took a look at 2.13.0 to see what would be needed. Here's my results: * Missing Python dependencies: - jupyter_server_terminals: https://github.com/jupyter-server/jupyter_server_terminals All Python dependencies present in Debian, except for docs: "sphinxcontrib-openapi", "sphinxcontrib_github_alt", (ITP #1060128) "sphinxemoji", - jupyter_events: https://github.com/jupyter/jupyter_events Missing Python dependencies: python-json-logger rfc3339-validator (perhaps? doesn't appear to be necessary) rfc3986-validator (perhaps? doesn't appear to be necessary) Missing docs dependencies: "jupyterlite-sphinx", - overrides: https://github.com/mkorpela/overrides No Python dependencies - python-json-logger: https://github.com/madzak/python-json-logger Forked into https://github.com/nhairs/python-json-logger with a PEP 541 request for transfer of maintenance No Python dependencies If we don't worry about packaging the docs for these packages, then it seems like it's just four new packages needed. Best wishes, Julian
Bug#1067248: ITP: pytest-jupyter -- Pytest plugins for Jupyter libraries and extensions
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-jupyter Version : 0.9.1 * URL : https://github.com/jupyter-server/pytest-jupyter * License : BSD-3-clause and Expat Programming Lang: Python Description : Pytest plugins for Jupyter libraries and extensions This set of pytest plugins are used for testing Jupyter. It includes an echo kernel to speed up testing. It uses pytest-tornasync internally for async test suite running, and may not be compatible with pytest-asyncio. This package is a new requirement for the package tests for jupyter-client and jupyter-server (newer versions of these packages that have not yet been packaged). It will be maintained within the Debian Python Team.
Bug#1033028: pydata-sphinx-theme: please update to at least v0.9.0rc1
On Wed, Mar 15, 2023 at 11:55:57PM +0100, Gianfranco Costamagna wrote: > Source: pydata-sphinx-theme > Version: 0.7.2-3 > > Hello, I see there is version 0.13.1, I would like to have it packaged, > because newer python-pyqtgraph is requesting >"navbar_end": ["theme-switcher", "navbar-icon-links"], > > and AFAICS that theme-switcher appeared on 0.9.0 or similar version. > > "Add dark theme and theme switcher by @12rambau in #540" > > I know updating needs another library "sphinx_theme_builder", but you seem > already having an ITP for it :) > > thanks for your work! > > Gianfranco Hi Gianfranco, Sandro has "orphaned" this package (in other words, left it to the Debian Python Team), so it is very unlikely that he will follow up his ITP (#1015231). If you'd like to pick this up yourself, you would be most welcome (and if so, and if you're not already in the Debian Python Team, my suggestion is that you join it for this package and for the ITP dependency). Best wishes, Julian
Bug#1067200: RM: cython-legacy -- ROM; Legacy transition package no longer needed
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: debian-pyt...@lists.debian.org cython-legacy was introduced as a transitional measure until cython version 3.x was supported by all source packages using cython. There are now no source packages in unstable or testing (main) depending on cython3-legacy and no binary packages either, so this legacy package can be removed. (It also has an RC bug against it, and doesn't really work with Python 3.12.) Best wishes, Julian
Bug#1065655: dot2tex: SyntaxWarning: invalid escape sequences
On Mon, Mar 18, 2024 at 12:12:06PM +, Torrance, Douglas wrote: > Control: tags -1 - moreinfo + confirmed > [...] > > > > Oh, and just to add on to this: I believe that this will become a > > SyntaxError in Python 3.13 or Python 3.14. > > Ok, thanks for clarifying! > > I was able to reproduce the warnings in Python 3.12: > ... > > They were silent using Python 3.11, which is suppose is why I hadn't seen them > before. Just checked the Python docs: see the second point of https://docs.python.org/3/whatsnew/3.12.html#other-language-changes Best wishes, Julian
Bug#1065655: dot2tex: SyntaxWarning: invalid escape sequences
On Mon, Mar 18, 2024 at 05:48:14AM +, Julian Gilbey wrote: > I was building or testing a package using sbuild or autopkgtest using > lxc, I don't remember which. One of the dependencies was dot2tex, so > it was being installed on a clean chroot (or equivalent). The > warnings appeared during the dpkg installation of the package > (probably during the configure step). > > But either way, all of these are, indeed, syntax errors and need to be > corrected. (It turns out, just looking at the first example on line > 1236, that they cannot all be fixed by turning them into raw strings: > this string has both '\p', which should be '\\p' (with a literal > backslash), and '\n', which presumably is intended as a new line > character. Oh, and just to add on to this: I believe that this will become a SyntaxError in Python 3.13 or Python 3.14. Best wishes, Julian
Bug#1065655: dot2tex: SyntaxWarning: invalid escape sequences
On Sun, Mar 17, 2024 at 11:44:23PM +, Torrance, Douglas wrote: > Control: tags -1 moreinfo > > On Fri, 08 Mar 2024 09:54:07 +0000 Julian Gilbey wrote: > > Package: dot2tex > > Version: 2.11.3-4 > > Severity: normal > > > > While installing this version on a testing system, lots of warning > > messages were given; the relevant strings should be marked as raw. > > [...] > > Thanks for the report! > > I'm not able to reproduce these warnings. What did you run to get them? I was building or testing a package using sbuild or autopkgtest using lxc, I don't remember which. One of the dependencies was dot2tex, so it was being installed on a clean chroot (or equivalent). The warnings appeared during the dpkg installation of the package (probably during the configure step). But either way, all of these are, indeed, syntax errors and need to be corrected. (It turns out, just looking at the first example on line 1236, that they cannot all be fixed by turning them into raw strings: this string has both '\p', which should be '\\p' (with a literal backslash), and '\n', which presumably is intended as a new line character. Best wishes, Julian
Bug#1065327: ITA: python-levenshtein
On Fri, Mar 15, 2024 at 10:03:44AM -0400, Louis-Philippe Véronneau wrote: > Ah, great news then, happy to let you have it :) > > I'll be happy to contribute punctually if needed if you do indeed keep it in > the DPT. Thanks! Quick update, having taken a peek at the package: the version currently in unstable is quite old - it is a version that did not require rapidfuzz. So I will leave it as-is until rapidfuzz makes it into testing (which may be some time), and then it can be updated. Best wishes, Julian > On 2024-03-15 07:01, Julian Gilbey wrote: > > On Thu, Mar 14, 2024 at 10:40:38AM -0400, Louis-Philippe Véronneau wrote: > > > retitle 1065327 ITA: python-levenshtein -- extension for computing string > > > similarities and edit distances (Python 3) > > > owner 1065327 Louis-Philippe Véronneau > > > thanks > > > > > > I need this package for sublime-music and since it's being orphaned, I'm > > > planning to adopt it. > > > > > > If someone else wants to maintain this package though, I won't fight you > > > for it :) > > > > > > Cheers (and thanks to morph for the work so far), > > > > Hi Louis-Philippe, > > > > Both Jelmer and I are also willing to take it on. I wrote to the > > Python list in response to Jelmer (before I saw your ITA): > > > >I've just taken a look at python-levenshtein, as I remember the name > >now: it might make more sense for me to take it as it depends on > >rapidfuzz and rapidfuzz-cpp, which I've just packaged and are sitting > >in NEW. But if you want to take it, please feel free to do so! (Once > >rapidfuzz makes it into unstable, a lot of debian/rules could probably > >also be simplified.) > > > > So happy whoever wants to take it; we just won't be able to do much > > until rapidfuzz, rapidfuzz-cpp and taskflow make it to unstable. > > > > I do suggest that we keep it within the DPT, though. > > > > Best wishes, > > > > Julian
Bug#1065327: ITA: python-levenshtein
On Thu, Mar 14, 2024 at 10:40:38AM -0400, Louis-Philippe Véronneau wrote: > retitle 1065327 ITA: python-levenshtein -- extension for computing string > similarities and edit distances (Python 3) > owner 1065327 Louis-Philippe Véronneau > thanks > > I need this package for sublime-music and since it's being orphaned, I'm > planning to adopt it. > > If someone else wants to maintain this package though, I won't fight you for > it :) > > Cheers (and thanks to morph for the work so far), Hi Louis-Philippe, Both Jelmer and I are also willing to take it on. I wrote to the Python list in response to Jelmer (before I saw your ITA): I've just taken a look at python-levenshtein, as I remember the name now: it might make more sense for me to take it as it depends on rapidfuzz and rapidfuzz-cpp, which I've just packaged and are sitting in NEW. But if you want to take it, please feel free to do so! (Once rapidfuzz makes it into unstable, a lot of debian/rules could probably also be simplified.) So happy whoever wants to take it; we just won't be able to do much until rapidfuzz, rapidfuzz-cpp and taskflow make it to unstable. I do suggest that we keep it within the DPT, though. Best wishes, Julian
Bug#1064946: morph's abandoned packages (list)
Dear all (and Bcc-ing the RM bugs), For information, here is a list of packages that morph has either requested removal of or orphaned. If you are interested in taking one or more of them on, that would be great! Removal requested: #1066146 RM: flask-basicauth -- ROM; RC buggy, dead upstream, leaf package #1065141 RM: gmplot -- ROM; leaf package #1064947 RM: nb2plots -- ROM; leaf package #1065200 RM: overpass -- ROM; leaf package #1065199 RM: pprintpp -- ROM; leaf package #1065045 RM: pyannotate -- ROM; leaf package #1065201 RM: python-overpy -- ROM; leaf package #1065202 RM: python-ppmd -- ROM; leaf package #1064946 RM: sphinx-a4doc -- ROM; leaf package Recently-orphaned packages (removing those in wnpp which have been retitled "ITA") sorted alphabetically; these could, of course, be brought into team maintenance. #1065235 O: basemap -- matplotlib toolkit to plot on map projections #1065243 O: colorspacious -- library for doing colorspace conversions #1065151 O: commonmark -- Python parser for the CommonMark Markdown spec #1065246 O: contourpy -- Python library for calculating contours of 2D quadrilateral grids #1065248 O: cppy -- C++ headers for (Python) C extension development #1065139 O: dot2tex -- Graphviz to LaTeX converter #1065140 O: fastkml -- fast KML processing #1065142 O: html5lib -- HTML parser/tokenizer based on the WHATWG HTML5 specification #1065244 O: kiwisolver -- fast implementation of the Cassowary constraint solver #1065238 O: lazy-object-proxy -- Python 3 fast and thorough lazy object proxy #1065037 O: m2crypto -- Python wrapper for the OpenSSL library #1065325 O: matplotlib -- Python based plotting system #1065143 O: mkautodoc -- AutoDoc for MarkDown #1065042 O: mpl-sphinx-theme -- documentation for the mpl-sphinx-theme Python library #1065220 O: mpmath -- library for arbitrary-precision floating-point arithmetic #1065224 O: mysql-connector-python -- pure Python implementation of MySQL Client/Server protocol #1065198 O: networkx -- tool to create, manipulate and study complex networks #1065329 O: numpy -- Fast array facility to the Python 3 language #1065221 O: py7zr -- pure Python 7-zip library #1065222 O: pychm -- Python binding for CHMLIB #1065231 O: pydot -- Python interface to Graphviz's dot #1065152 O: pygeoif -- basic implementation of the __geo_interface__ #1065036 O: pyopenssl -- Python wrapper around the OpenSSL library #1065149 O: pyproject-metadata -- Dataclass for PEP 621 metadata with support for [core metadata] generation #1065223 O: pysimplesoap -- simple and lightweight SOAP Library #1064977 O: python-cryptography-vectors -- Test vectors for python-cryptography #1065327 O: python-levenshtein -- extension for computing string similarities and edit distances #1065025 O: sphinx-book-theme -- clean book theme for scientific explanations and documentation with Sphinx #1065026 O: sphinx-bootstrap-theme -- bootstrap theme for Sphinx #1065030 O: sphinxcontrib-log-cabinet -- Organize changelog directives in Sphinx docs #1065027 O: sphinx-copybutton -- sphinx extension to add a "copy" button to code blocks #1065028 O: sphinx-gallery -- extension that builds an HTML gallery of examples from Python scripts #1065029 O: sphinx-panels -- documentation for the sphinx-panels Python library #1065043 O: sphinxtesters -- utilities for testing Sphinx extensions #1064948 O: texext -- sphinx extensions for working with LaTeX math There's also an old ITP that was closed: #1015231 ITP: sphinx-theme-builder -- tool for authoring Sphinx themes with a simple (opinionated) workflow Best wishes, Julian
Bug#1066046: mystic: fails autopkgtests on i386, armel, armhf, ppc64el
Source: mystic Version: 0.4.2-1 Severity: serious Tags: upstream The autopkgtests are failing on mystic/tests/test_collapse.py, line 177. Making this bug report to track progress.
Bug#1065822: anki: Please drop dependencies on python3-distutils
Hi Graham and Laurin, The package is currently only in unstable because of other RC bugs. Its presence in unstable will not cause any problems, even if distutils is removed from unstable. When the new version is finally packaged, it certainly won't depend on distutils. (Removing anki from Debian entirely and then having to go through NEW when the new version is packaged is unnecessary effort.) Best wishes, Julian On Sun, Mar 10, 2024 at 02:47:25PM +0100, Laurin Hagemann wrote: > Hi! > > This is pending on the packaging of the new anki version, which will be a l= > ot of work. If needed it might be better to remove the anki package if it c= > auses problems, since > the old version will not build without distutils, and the packaging of the = > new version might take some more time. > > Kind regards, > Laurin > > On Sun, 2024-03-10 at 11:27 -0100, Graham Inggs wrote: > > Source: anki > > Version: 2.1.15+dfsg-4 > > Severity: important > > User: debian-pyt...@lists.debian.org > > Usertags: python3.12 > >=20 > > Hi Maintainer > >=20 > > This package has dependencies, build-dependencies and/or autopkgtest > > dependencies on python3-distutils. The python3-distutils binary > > package will soon be dropped from python3-stdlib-extensions. > >=20 > > In fact, there is no module for Python 3.12 in python3-distutils, so > > these dependencies may already be unnecessary.
Bug#1065655: dot2tex: SyntaxWarning: invalid escape sequences
Package: dot2tex
Version: 2.11.3-4
Severity: normal
While installing this version on a testing system, lots of warning
messages were given; the relevant strings should be marked as raw.
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:900: SyntaxWarning: invalid
escape sequence '\i'
variables['<>'] = "\input{gvcols.tex}"
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1236: SyntaxWarning: invalid
escape sequence '\p'
s += " \psellipse[%s](%sbp,%sbp)(%sbp,%sbp)\n" % (stylestr, smart_float(x),
smart_float(y),
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1256: SyntaxWarning: invalid
escape sequence '\p'
s = " \pspolygon[%s]%s\n" % (stylestr, "".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1262: SyntaxWarning: invalid
escape sequence '\p'
s = " \psline%s\n" % "".join(pp)
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1272: SyntaxWarning: invalid
escape sequence '\p'
return " \psbezier{%s}%s\n" % (arrowstyle, "".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1299: SyntaxWarning: invalid
escape sequence '\p'
s = " \psset{linecolor=%s}\n" % color
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1306: SyntaxWarning: invalid
escape sequence '\p'
s = " \psset{fillcolor=%s}\n" % color
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1313: SyntaxWarning: invalid
escape sequence '\p'
s = " \psset{linecolor=%s}\n" % color
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1322: SyntaxWarning: invalid
escape sequence '\p'
return " \psset{%s}\n" % psstyle
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1393: SyntaxWarning: invalid
escape sequence '\p'
s += " \psbezier[%s]%s\n" % (stylestr, "".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1395: SyntaxWarning: invalid
escape sequence '\p'
s += " \psline[%s]%s%s\n" % (stylestr, pp[0], pp[-1])
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1589: SyntaxWarning: invalid
escape sequence '\p'
dashed='\pgfsetdash{{3pt}{3pt}}{0pt}',
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1590: SyntaxWarning: invalid
escape sequence '\p'
dotted='\pgfsetdash{{\pgflinewidth}{2pt}}{0pt}',
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1591: SyntaxWarning: invalid
escape sequence '\p'
bold='\pgfsetlinewidth{1.2pt}')
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1639: SyntaxWarning: invalid
escape sequence '\d'
s += " \definecolor{newcol}%s;\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1641: SyntaxWarning: invalid
escape sequence '\p'
s += " \pgfsetcolor{%s}\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1649: SyntaxWarning: invalid
escape sequence '\d'
s += " \definecolor{strokecol}%s;\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1651: SyntaxWarning: invalid
escape sequence '\p'
s += " \pgfsetstrokecolor{%s}\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1661: SyntaxWarning: invalid
escape sequence '\d'
s += " \definecolor{fillcol}%s;\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1663: SyntaxWarning: invalid
escape sequence '\p'
s += " \pgfsetfillcolor{%s}\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1707: SyntaxWarning: invalid
escape sequence '\%'
s += " \%s%s (%sbp,%sbp) ellipse (%sbp and %sbp);\n" % (cmd, stylestr,
smart_float(x), smart_float(y),
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1723: SyntaxWarning: invalid
escape sequence '\%'
s = " \%s%s %s -- cycle;\n" % (cmd, stylestr, " -- ".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1730: SyntaxWarning: invalid
escape sequence '\d'
return " \draw%s %s;\n" % (stylestr, " -- ".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1753: SyntaxWarning: invalid
escape sequence '\d'
s = " \draw (%sbp,%sbp) node%s {%s};\n" % (smart_float(x), smart_float(y),
lblstyle, text)
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1765: SyntaxWarning: invalid
escape sequence '\d'
s += " \draw%s %s .. %s;\n" % (stylestr, " .. ".join(pstrs), pp[-1])
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1857: SyntaxWarning: invalid
escape sequence '\d'
s += " \draw [%s] %s to[%s]%s %s;\n" % (stylestr, src,
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1860: SyntaxWarning: invalid
escape sequence '\d'
s += " \draw [%s] %s ..%s %s;\n" % (stylestr, " .. ".join(pstrs), extra,
pp[-1])
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1862: SyntaxWarning: invalid
escape sequence '\d'
s += " \draw [%s] %s --%s %s;\n" % (stylestr, pp[0], extra, pp[-1])
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:2110: SyntaxWarning: invalid
escape sequence '\p'
dashed='\pgfsetdash{{3pt}{3pt}}{0pt}',
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:2111: SyntaxWarning: invalid
escape sequence '\p'
dotted='\pgfsetdash{{\pgflinewidth}{2pt}}{0pt}',
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:2112: SyntaxWarning: invalid
escape sequence '\p'
Bug#1064824: node-d3: fails to export map and other functions
On Tue, Mar 05, 2024 at 05:39:00PM +0530, Nilesh Patra wrote: > On Mon, Mar 04, 2024 at 09:18:01PM +0000, Julian Gilbey wrote: > [...] > > (!) Conflicting re-exports > > "index.js" re-exports "map" from both > > "../../../usr/share/nodejs/d3-array/src/index.js" and > > "../../../usr/share/nodejs/d3-collection/src/index.js" (will be ignored). > > created dist/d3.min.js in 4.2s > > - > > I have pushed a commit to salsa that hopefully fixes this - can you please > try with the same and see if that > helps you somewhat? That's perfect, thanks! And such a simple solution :-) (Though I don't pretend to understand how the patch works!) The taskflow webserver now works exactly as intended (as far as I can tell). > > So it's specifically "map" that is problematic, and I just happen to > > have stumbled upon it: d3 v5 depends on d3-array version 1, but the > > version of node-d3-array in unstable is 3.2.0+~cs5.0.6-2, and this is > > causing the conflict. > > > > I don't know the best way to fix this. node-d3-array version was > > upgraded from 1.2.4 to 3.x about two years ago, so d3 would have had > > this bug since then, but I'm the first one to stumble upon it :-/ > > > > Perhaps we could package node-d3-array-1 (version 1.2.4) and have > > node-d3 build-depends on that? > > I tried to embed it and realised it is creating an unholy mess. I got it > working eventually > but it can open a can of worms sometime later. Maybe packaging the older > version > would be the way to go if my fix above does not work. > > I've added yadd to the thread for more qualified advice. It might be a good idea to do this anyway, but given that no-one else has noticed a problem in > 2 years suggests it's not worth the effort. Best wishes, Julian
Bug#1065445: pristine-tar: fails if upstream tarball top directory name is capitalised
reassign 1065445 git-buildpackage retitle 1065445 git-buildpackage: --pristine-tar fails if upstream tarball top directory name is not - thanks (See below for explanation.) On Tue, Mar 05, 2024 at 07:41:02AM +, Julian Gilbey wrote: > severity 1065445 important > retitle 1065445 pristine-tar: fails if original tarball top directory name is > not - > thanks > > On Mon, Mar 04, 2024 at 08:53:21PM +0000, Julian Gilbey wrote: > > Package: pristine-tar > > Version: 1.50+nmu1 > > Severity: normal > > > > I discovered that a package I was trying to use with pristine-tar > > failed to work. The cause of the issue seems to be that the upstream > > tarball's top directory name is capitalised, but pristine-tar > > regenerates a tarball with the name lowercased. > > > > Steps to reproduce using git-buildpackage: > > 1. Import the attached minimal working example into git using the command: > >gbp import-dsc --pristine-tar hello_1.0-1.dsc > > > > 2. Change into the build directory: > >cd hello > > > > 3. Regenerate the original tar ball using pristine-tar, for example: > >gbp buildpackage -S > > > > 4. Return to the parent directory, then: > > > > $ tar ztf hello_1.0.orig.tar.gz > > Hello-1.0/ > > Hello-1.0/Makefile > > Hello-1.0/hello.c > > $ tar ztf build-area/hello_1.0.orig.tar.gz > > hello-1.0/ > > hello-1.0/Makefile > > hello-1.0/hello.c > > > > Note the capitalisation has changed. Also: > > > > $ ls -l hello_1.0.orig.tar.gz build-area/hello_1.0.orig.tar.gz > > -rw-r--r-- 1 jdg jdg 256 Mar 4 20:46 build-area/hello_1.0.orig.tar.gz > > -rw-r--r-- 1 jdg jdg 175 Mar 4 20:00 hello_1.0.orig.tar.gz > > > > Best wishes, > > > >Julian > > It turns out it's actually much more general than this: if the > original tarball does not have a top directory named > - > then pristine-tar fails; it *always* creates a tarball with top > directory called this, rather than using the name used by the original > upstream tarball. So pristine-tar fails on all such cases, including > cases where mk-origtargz has been used to exclude some files. > > Attached is a minimal example, hello2. > >Julian I checked pristine-tar directly on these examples, and it turns out that it can handle these situations with no problems. The problem only emerges when git-buildpackage is being used, as in the example I gave in the original bug report. I don't know how gbp import-orig/import-dsc --pristine-tar calls pristine-tar, but somehow it appears to forget the top directory name of the original tarball, leading to this problem. I have reported this as a severity "important" bug because it may silently (or not so silently) affect many packages. Best wishes, Julian
Bug#1065446: pristine-tar: fails if upstream tarball contains an empty directory
reassign 1065445 git-buildpackage retitle 1065445 git-buildpackage: --pristine-tar fails if upstream tarball contains an empty directory thanks (See below for explanation.) On Mon, Mar 04, 2024 at 09:20:02PM +, Julian Gilbey wrote: > On Mon, Mar 04, 2024 at 08:53:25PM +0000, Julian Gilbey wrote: > > Package: pristine-tar > > Version: 1.50+nmu1 > > Severity: normal > > > > I discovered that a package I was trying to use with pristine-tar > > failed to work. The cause of the issue seems to be that the upstream > > tarball contains an empty directory, which is lost when regenerated by > > pristine-tar. > > > > Steps to reproduce using git-buildpackage: > > 1. Import the attached minimal working example into git using the command: > >gbp import-dsc --pristine-tar foobar_1.0-1.dsc > > > > 2. Change into the build directory: > >cd foobar > > > > 3. Regenerate the original tar ball using pristine-tar, for example: > >gbp buildpackage -S > > > > 4. Return to the parent directory, then: > > > > $ tar ztf foobar_1.0.orig.tar.gz > > foobar-1.0/ > > foobar-1.0/foobar.c > > foobar-1.0/Makefile > > foobar-1.0/emptydir/ > > $ tar ztf build-area/foobar_1.0.orig.tar.gz > > foobar-1.0/ > > foobar-1.0/Makefile > > foobar-1.0/foobar.c > > > > Note the empty directory has disappeared. Also: > > > > $ ls -l foobar_1.0.orig.tar.gz build-area/foobar_1.0.orig.tar.gz > > -rw-r--r-- 1 jdg jdg 253 Mar 4 20:51 build-area/foobar_1.0.orig.tar.gz > > -rw-r--r-- 1 jdg jdg 193 Mar 4 20:00 foobar_1.0.orig.tar.gz > > > > Best wishes, > > > >Julian > > I forgot to attach the foobar package, here it is. > >Julian I checked pristine-tar directly on this example, and it turns out that it can handle this situation with no problem, as long as the directory tree has the empty directory present when pristine-tar gentar is called. The problem only emerges when git-buildpackage is being used, as in the example I gave in the original bug report. I presume that this problem arises because git does not record the presence of empty directories, so the resulting created tar file does not know about them either. Best wishes, Julian
Bug#1065445: pristine-tar: fails if upstream tarball top directory name is capitalised
severity 1065445 important retitle 1065445 pristine-tar: fails if original tarball top directory name is not - thanks On Mon, Mar 04, 2024 at 08:53:21PM +, Julian Gilbey wrote: > Package: pristine-tar > Version: 1.50+nmu1 > Severity: normal > > I discovered that a package I was trying to use with pristine-tar > failed to work. The cause of the issue seems to be that the upstream > tarball's top directory name is capitalised, but pristine-tar > regenerates a tarball with the name lowercased. > > Steps to reproduce using git-buildpackage: > 1. Import the attached minimal working example into git using the command: >gbp import-dsc --pristine-tar hello_1.0-1.dsc > > 2. Change into the build directory: >cd hello > > 3. Regenerate the original tar ball using pristine-tar, for example: >gbp buildpackage -S > > 4. Return to the parent directory, then: > > $ tar ztf hello_1.0.orig.tar.gz > Hello-1.0/ > Hello-1.0/Makefile > Hello-1.0/hello.c > $ tar ztf build-area/hello_1.0.orig.tar.gz > hello-1.0/ > hello-1.0/Makefile > hello-1.0/hello.c > > Note the capitalisation has changed. Also: > > $ ls -l hello_1.0.orig.tar.gz build-area/hello_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 256 Mar 4 20:46 build-area/hello_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 175 Mar 4 20:00 hello_1.0.orig.tar.gz > > Best wishes, > >Julian It turns out it's actually much more general than this: if the original tarball does not have a top directory named - then pristine-tar fails; it *always* creates a tarball with top directory called this, rather than using the name used by the original upstream tarball. So pristine-tar fails on all such cases, including cases where mk-origtargz has been used to exclude some files. Attached is a minimal example, hello2. Julian hello2_1.0.orig.tar.gz Description: application/gzip Format: 3.0 (quilt) Source: hello2 Binary: hello2 Architecture: any Version: 1.0-1 Maintainer: Julian Gilbey Homepage: Standards-Version: 4.6.2 Build-Depends: debhelper-compat (= 13) Package-List: hello2 deb unknown optional arch=any Checksums-Sha1: 088958090dae03cbf08b77cd3d4f828a5708f1e4 167 hello2_1.0.orig.tar.gz ee6010e1aaee036ac478acf0b435103befd02ebd 2028 hello2_1.0-1.debian.tar.xz Checksums-Sha256: 2c625982f9b41d456f63c8385a3597c2ff02f2a4e535db802bca7426b2d44947 167 hello2_1.0.orig.tar.gz 187551b3d11623c2e2b984a9701f1fad74c532b2e948892a34a4d8dc28f3d901 2028 hello2_1.0-1.debian.tar.xz Files: 323ce17ab35564a9c31a8e0320f7a069 167 hello2_1.0.orig.tar.gz 12bb0fa03c08e92a450065425d0e570f 2028 hello2_1.0-1.debian.tar.xz hello2_1.0-1.debian.tar.xz Description: application/xz
Bug#1064824: node-d3: fails to export map and other functions
On Mon, Mar 04, 2024 at 09:18:01PM +, Julian Gilbey wrote: > [...] > So it's specifically "map" that is problematic, and I just happen to > have stumbled upon it: d3 v5 depends on d3-array version 1, but the > version of node-d3-array in unstable is 3.2.0+~cs5.0.6-2, and this is > causing the conflict. > > I don't know the best way to fix this. node-d3-array version was > upgraded from 1.2.4 to 3.x about two years ago, so d3 would have had > this bug since then, but I'm the first one to stumble upon it :-/ > > Perhaps we could package node-d3-array-1 (version 1.2.4) and have > node-d3 build-depends on that? I was just wondering if there's a simpler way than having a new package: have d3-array 1.2.4 being an unexported component of the node-d3 source package, and instead of Build-Depends: node-d3-array, have a Build-Conflicts: node-d3-array. But then I discovered that the binary package node-d3 depends on node-d3-array, as do 7 other packages in testing (I haven't checked unstable). I'm guessing that most of those dependencies probably need version 1.x of d3-array, so it may be that having a node-d3-array-1 (or -v1) package is actually the way forward in this situation. Best wishes, Julian
Bug#1065446: pristine-tar: fails if upstream tarball contains an empty directory
Package: pristine-tar Version: 1.50+nmu1 Severity: normal I discovered that a package I was trying to use with pristine-tar failed to work. The cause of the issue seems to be that the upstream tarball contains an empty directory, which is lost when regenerated by pristine-tar. Steps to reproduce using git-buildpackage: 1. Import the attached minimal working example into git using the command: gbp import-dsc --pristine-tar foobar_1.0-1.dsc 2. Change into the build directory: cd foobar 3. Regenerate the original tar ball using pristine-tar, for example: gbp buildpackage -S 4. Return to the parent directory, then: $ tar ztf foobar_1.0.orig.tar.gz foobar-1.0/ foobar-1.0/foobar.c foobar-1.0/Makefile foobar-1.0/emptydir/ $ tar ztf build-area/foobar_1.0.orig.tar.gz foobar-1.0/ foobar-1.0/Makefile foobar-1.0/foobar.c Note the empty directory has disappeared. Also: $ ls -l foobar_1.0.orig.tar.gz build-area/foobar_1.0.orig.tar.gz -rw-r--r-- 1 jdg jdg 253 Mar 4 20:51 build-area/foobar_1.0.orig.tar.gz -rw-r--r-- 1 jdg jdg 193 Mar 4 20:00 foobar_1.0.orig.tar.gz Best wishes, Julian
Bug#1065445: pristine-tar: fails if upstream tarball top directory name is capitalised
Package: pristine-tar Version: 1.50+nmu1 Severity: normal I discovered that a package I was trying to use with pristine-tar failed to work. The cause of the issue seems to be that the upstream tarball's top directory name is capitalised, but pristine-tar regenerates a tarball with the name lowercased. Steps to reproduce using git-buildpackage: 1. Import the attached minimal working example into git using the command: gbp import-dsc --pristine-tar hello_1.0-1.dsc 2. Change into the build directory: cd hello 3. Regenerate the original tar ball using pristine-tar, for example: gbp buildpackage -S 4. Return to the parent directory, then: $ tar ztf hello_1.0.orig.tar.gz Hello-1.0/ Hello-1.0/Makefile Hello-1.0/hello.c $ tar ztf build-area/hello_1.0.orig.tar.gz hello-1.0/ hello-1.0/Makefile hello-1.0/hello.c Note the capitalisation has changed. Also: $ ls -l hello_1.0.orig.tar.gz build-area/hello_1.0.orig.tar.gz -rw-r--r-- 1 jdg jdg 256 Mar 4 20:46 build-area/hello_1.0.orig.tar.gz -rw-r--r-- 1 jdg jdg 175 Mar 4 20:00 hello_1.0.orig.tar.gz Best wishes, Julian
Bug#1065446: pristine-tar: fails if upstream tarball contains an empty directory
On Mon, Mar 04, 2024 at 08:53:25PM +, Julian Gilbey wrote: > Package: pristine-tar > Version: 1.50+nmu1 > Severity: normal > > I discovered that a package I was trying to use with pristine-tar > failed to work. The cause of the issue seems to be that the upstream > tarball contains an empty directory, which is lost when regenerated by > pristine-tar. > > Steps to reproduce using git-buildpackage: > 1. Import the attached minimal working example into git using the command: >gbp import-dsc --pristine-tar foobar_1.0-1.dsc > > 2. Change into the build directory: >cd foobar > > 3. Regenerate the original tar ball using pristine-tar, for example: >gbp buildpackage -S > > 4. Return to the parent directory, then: > > $ tar ztf foobar_1.0.orig.tar.gz > foobar-1.0/ > foobar-1.0/foobar.c > foobar-1.0/Makefile > foobar-1.0/emptydir/ > $ tar ztf build-area/foobar_1.0.orig.tar.gz > foobar-1.0/ > foobar-1.0/Makefile > foobar-1.0/foobar.c > > Note the empty directory has disappeared. Also: > > $ ls -l foobar_1.0.orig.tar.gz build-area/foobar_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 253 Mar 4 20:51 build-area/foobar_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 193 Mar 4 20:00 foobar_1.0.orig.tar.gz > > Best wishes, > >Julian I forgot to attach the foobar package, here it is. Julian Format: 3.0 (quilt) Source: foobar Binary: foobar Architecture: any Version: 1.0-1 Maintainer: Julian Gilbey Homepage: Standards-Version: 4.6.2 Build-Depends: debhelper-compat (= 13) Package-List: foobar deb unknown optional arch=any Checksums-Sha1: 0e2d40b683cd46506364ff326fd7990addcde812 193 foobar_1.0.orig.tar.gz 406c92cd201f9a00f15d6f74cfa04ea2b9ac9501 2024 foobar_1.0-1.debian.tar.xz Checksums-Sha256: 19388ac41515a84a018cf030561f6664a50339ea68db874c470491b18c9bc9cb 193 foobar_1.0.orig.tar.gz bfe8513364dcbe2e7b9a44c6436bf0a48ff482105f5414a852eda8190712e543 2024 foobar_1.0-1.debian.tar.xz Files: c111a679204eda05e4cac4997d0c3dfd 193 foobar_1.0.orig.tar.gz 846524b08e24b0b5b0af3401eaf58e7c 2024 foobar_1.0-1.debian.tar.xz foobar_1.0-1.debian.tar.xz Description: application/xz foobar_1.0.orig.tar.gz Description: application/gzip
Bug#1064824: node-d3: fails to export map and other functions
Hi Nilesh, On Tue, Mar 05, 2024 at 02:06:08AM +0530, Nilesh Patra wrote: > > This gives lots of differences still; stripping down to just the > > differences still has many, many differences: some new exports not in > > the original d3, and some lost exports; the list begins: > > $ diff -u /tmp/d3-npm.exports.trimmed /tmp/d3-debian.exports.trimmed > > > > +exports.Adder = Adder; > > -exports.bisect = bisectRight; > > +exports.bin = bin; > > +exports.bisect = bisect; > > +exports.bisectCenter = bisectCenter; > > +exports.blur2 = blur2; > > +exports.blur = blur; > > +exports.blurImage = blurImage; > > +exports.count = count; > > -exports.csvFormatRow = csvFormatRow; > > -exports.csvFormatValue = csvFormatValue; > > $ cat /tmp/d3-debian.exports.trimmed | egrep --color > '(bisectRight|csvFormatRow|csvFormatValue)' > exports.bisectRight = bisectRight; > exports.csvFormatRows = csvFormatRows; > > Some of the diff entries are false positive -- it is just that entries are > not identical across these > files and despite sorting them, you do not get the exact picture of the diff > in exports. Well spotted, thanks! I'll snip the discussion of csvFormatValue... > [...] > Which is why. Seems the versions of dev dependencies have not been > appropriately tightened by the upstream > so we are running into weird surprises like these. Re-compiling node-d3 again > now should fixup this export however. Great! > These minor deltas in exports are more or less due to > version differences in different d3 plugins. > > ... > > Background to this: I'm trying to package a new package which provides > > a web server to visualise some data. The package includes a few > > precompiled JavaScript libraries obtained from npmjs.com, and the > > server works fine with them. But following Debian policy, I need to > > replace those with the source packages. And the server then doesn't > > work. > > > > The JavaScript libraries which the package uses are: d3 v5.16.0, > > d3-tip, apparently v0.9.1, along with jQuery and bootstrap4. I have > > replaced all of these with the versions in the corresponding Debian > > packages (and I've just uploaded a new version of d3-tip, thinking > > that that was the cause of the bug). > > > > When visiting the served web page, the console log gives the error > > message: > > > > Uncaught (in promise) TypeError: t.map is not a function > >n http://localhost:8080/js/d3/d3-tip.min.js:1 > >main http://localhost:8080/js/index.js:848 > >async* http://localhost:8080/js/index.js:993 > > > > (This has changed from the original bug report as the minimised new > > version of d3-tip has t.map instead of h.map.) > > > > d3-tip.js requires d3-collection, from which it calls a map function. > > I tried replacing d3-tip.min.js with the pre-packaged version rather > > than the (newly built) Debian version, but that did not help. I > > reverted that change and instead replaced d3.v5.min.js (which is a > > copy of /usr/share/nodejs/d3/dist/d3.min.js) with the version provided > > by upstream, which is a verbatim copy of the npmjs.com d3.min.js, and > > the server then worked perfectly. So this told me that it is the > > Debian compiled d3 which is not working correctly. > > Julian, I am very confused by that wording - from what I could gauge, your > target package does not work with debian libs but it does work with npmjs, > yes? I'm sorry I wasn't clear. Yes, that's it: I'm trying to package taskflow for Debian (it's a dependency of something else that I'm trying to package), and it provides a profiler visualisation tool in the form of a webserver. The upstream package (https://github.com/taskflow/taskflow) has d3.v5.min.js and d3-tip.min.js included (in tfprof/js/d3), and these are bitwise identical to the npmjs versions (versions 5.16.0 and 0.9.1). The webserver works using these versions. To satisfy Debian policy, I replaced these with the versions found in libjs-d3-tip and node-d3, but then the webserver fails to produce a usuable visualisation. My exploration, described above, was that "map" was not exported from d3-collection, and that led me to explore whether this was a unique missing export or not; I discovered that it was not. > In that case linking your target package and listing the exact steps to > that error can help someone debug it in more detail as to what might be > missing. I've just rebuilt node-d3 locally from (Debian) source on an unstable schroot, and I think I may have found the source of the bug: the build reads: - dh_auto_build --buildsystem=nodejs No build command found, searching known files No build command found, searching known files Found debian/nodejs/d3-sankey/build cd ./d3-sankey && sh -ex ../debian/nodejs/d3-sankey/build + rollup -c src/index.js → dist/d3-sankey.js... created dist/d3-sankey.js in 120ms src/index.js → dist/d3-sankey.min.js... created dist/d3-sankey.min.js in 561ms Found debian/nodejs/./build cd ./. && sh
Bug#1065445: pristine-tar: fails if upstream tarball top directory name is capitalised
On Mon, Mar 04, 2024 at 08:53:21PM +, Julian Gilbey wrote: > Package: pristine-tar > Version: 1.50+nmu1 > Severity: normal > > I discovered that a package I was trying to use with pristine-tar > failed to work. The cause of the issue seems to be that the upstream > tarball's top directory name is capitalised, but pristine-tar > regenerates a tarball with the name lowercased. > > Steps to reproduce using git-buildpackage: > 1. Import the attached minimal working example into git using the command: >gbp import-dsc --pristine-tar hello_1.0-1.dsc > > 2. Change into the build directory: >cd hello > > 3. Regenerate the original tar ball using pristine-tar, for example: >gbp buildpackage -S > > 4. Return to the parent directory, then: > > $ tar ztf hello_1.0.orig.tar.gz > Hello-1.0/ > Hello-1.0/Makefile > Hello-1.0/hello.c > $ tar ztf build-area/hello_1.0.orig.tar.gz > hello-1.0/ > hello-1.0/Makefile > hello-1.0/hello.c > > Note the capitalisation has changed. Also: > > $ ls -l hello_1.0.orig.tar.gz build-area/hello_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 256 Mar 4 20:46 build-area/hello_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 175 Mar 4 20:00 hello_1.0.orig.tar.gz > > Best wishes, > >Julian I forgot to attach the hello package; here it is. Julian Format: 3.0 (quilt) Source: hello Binary: hello Architecture: any Version: 1.0-1 Maintainer: Julian Gilbey Homepage: Standards-Version: 4.6.2 Build-Depends: debhelper-compat (= 13) Package-List: hello deb unknown optional arch=any Checksums-Sha1: 13d5ecfcec8a27b9d89ea9e73ad0066fd2ece889 175 hello_1.0.orig.tar.gz 17f6726313b66fe7cecaa22aba10185037f945a1 2028 hello_1.0-1.debian.tar.xz Checksums-Sha256: 5d35cb0e91cbf6597d88d0c9fe4569544c391882ebf82a7754c2edba8bea50fb 175 hello_1.0.orig.tar.gz f23d59003adf6cda9a84c25f3836021781f7df42e1a0037b737d62568d7bf0bd 2028 hello_1.0-1.debian.tar.xz Files: 5f3b5a48f5a653abab7de8852c8380b7 175 hello_1.0.orig.tar.gz eb3450a52485d0bb39416a0e691af913 2028 hello_1.0-1.debian.tar.xz hello_1.0-1.debian.tar.xz Description: application/xz hello_1.0.orig.tar.gz Description: application/gzip
Bug#1019431: Bug#1019435: ITP: rapidfuzz - rapid fuzzy string matching
rename 1019431 ITP: rapidfuzz-cpp -- C-API of the Python RapidFuzz package thanks On Sat, Mar 02, 2024 at 08:27:00PM +, Julian Gilbey wrote: > merge 1019435 1019431 1019436 > thanks > > The rapidfuzz-capi and jarowinkler packages have been merged into > rapidfuzz, so I am merging these three ITPs into a single ITP. > >Julian On second thoughts, it doesn't make that much sense to bundle the C++ header file package with the Python package; it became clear as I was writing debian/rules that they really are two separate packages. Also renaming the package as rapidfuzz-cpp, following upstream. Julian
Bug#1019435: ITP: rapidfuzz - rapid fuzzy string matching
On Sat, Mar 02, 2024 at 08:27:00PM +, Julian Gilbey wrote: > merge 1019435 1019431 1019436 > thanks > > The rapidfuzz-capi and jarowinkler packages have been merged into > rapidfuzz, so I am merging these three ITPs into a single ITP. > >Julian On second thoughts, I'll package rapidfuzz-cpp separately, so unmerging these bugs again. Julian
Bug#1019431: Bug#1019435: ITP: rapidfuzz - rapid fuzzy string matching
merge 1019435 1019431 1019436 thanks The rapidfuzz-capi and jarowinkler packages have been merged into rapidfuzz, so I am merging these three ITPs into a single ITP. Julian
Bug#1059529: pybuild-autopkgtest: before-pybuild-autopkgtest target presence breaks autopkgtest
On Thu, Feb 29, 2024 at 11:17:00AM -0300, Antonio Terceiro wrote: > [...] > > This was a bug in the python-bytecode debian/rules at that point: > > 40 │ before-pybuild-autopkgtest: > 41 │ ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) > 42 │ ifeq ($(DEB_BUILD_ARCH),armhf) > 43 │ patch -p1 < debian/armhf.patch > 44 │ endif > 45 │ endif > > when the ifeq's don't evaluate to true (what happens everywhere but on > armhf), the body of the `before-pybuild-autopkgtest` target is empty, > and this causes make to call the default (%) target, which then calls > `dh`. Thanks for the analysis, Antonio; I completely hadn't realised that. So no bug in dh_python after all! Best wishes, Julian
Bug#1064824: node-d3: fails to export map and other functions
reassign 1064824 node-d3 5.16.0+~cs5.28.10-1 severity 1064824 serious retitle 1064824 node-d3: fails to export map and probably other functions thanks (I'm raising this to severity "serious" because it breaks a different package.) (For background to the discovery of this bug, see below.) The Debian version of d3.js does not export "map", which it should. This breaks the libjs-d3-tip package. In fact, the export lists are significantly different: $ grep '^exports' d3-npm/dist/d3.js | sort > /tmp/d3-npm.exports $ grep ^exports /usr/share/nodejs/d3/dist/d3.js | sort > /tmp/d3-debian.exports $ diff -u /tmp/d3-npm.exports /tmp/d3-debian.exports [520 lines, lots of differences are due to "$1" type suffixes/ $ sed -e 's/\$[0-9]*;/;/' /tmp/d3-npm.exports > /tmp/d3-npm.exports.trimmed $ sed -e 's/\$[0-9]*;/;/' /tmp/d3-debian.exports > /tmp/d3-debian.exports.trimmed $ diff -u /tmp/d3-npm.exports.trimmed /tmp/d3-debian.exports.trimmed This gives lots of differences still; stripping down to just the differences still has many, many differences: some new exports not in the original d3, and some lost exports; the list begins: +exports.Adder = Adder; -exports.bisect = bisectRight; +exports.bin = bin; +exports.bisect = bisect; +exports.bisectCenter = bisectCenter; +exports.blur2 = blur2; +exports.blur = blur; +exports.blurImage = blurImage; +exports.count = count; -exports.csvFormatRow = csvFormatRow; -exports.csvFormatValue = csvFormatValue; Now, one *might* guess that the reason for this is that d3 imports lots of d3-* modules, and these have been updated and changed since d3 v5.16.0 was released, so these changes are reflected in the new list of exports (though people assuming that the Debian version of d3 v5.16.0 reflects the upstream version will then be confused and possibly frustrated). But that doesn't explain the absence of map, which comes from (node-)d3-collection. For /usr/share/nodejs/d3-collection/dist/d3-collection.js reads: exports.entries = entries; exports.keys = keys; exports.map = map; exports.nest = nest; exports.set = set; exports.values = values; So I cannot fathom why map is not being exported by d3 itself. There may be other cases of this behaviour, but I have not investigated further. I am quite stumped by this. Background to this: I'm trying to package a new package which provides a web server to visualise some data. The package includes a few precompiled JavaScript libraries obtained from npmjs.com, and the server works fine with them. But following Debian policy, I need to replace those with the source packages. And the server then doesn't work. The JavaScript libraries which the package uses are: d3 v5.16.0, d3-tip, apparently v0.9.1, along with jQuery and bootstrap4. I have replaced all of these with the versions in the corresponding Debian packages (and I've just uploaded a new version of d3-tip, thinking that that was the cause of the bug). When visiting the served web page, the console log gives the error message: Uncaught (in promise) TypeError: t.map is not a function n http://localhost:8080/js/d3/d3-tip.min.js:1 main http://localhost:8080/js/index.js:848 async* http://localhost:8080/js/index.js:993 (This has changed from the original bug report as the minimised new version of d3-tip has t.map instead of h.map.) d3-tip.js requires d3-collection, from which it calls a map function. I tried replacing d3-tip.min.js with the pre-packaged version rather than the (newly built) Debian version, but that did not help. I reverted that change and instead replaced d3.v5.min.js (which is a copy of /usr/share/nodejs/d3/dist/d3.min.js) with the version provided by upstream, which is a verbatim copy of the npmjs.com d3.min.js, and the server then worked perfectly. So this told me that it is the Debian compiled d3 which is not working correctly. Best wishes, Julian
Bug#1064824: libjs-d3-tip: TypeError: h.map is not a function
On Mon, Feb 26, 2024 at 12:15:54PM +0100, Petter Reinholdtsen wrote: > [Julian Gilbey] > > If it's OK, I can do that and release it. > > It is more than OK, it is most welcome. I packaged this to solve a > dependency, but do not know much about javascript packaging and would > love for someone who do to take over. :) > > I suspect I prepared a new version and decided to wait for the next > release before uploading, or ran into build problems and did not have > time to investigate. I do not really remember any more. Thanks Petter! There are definitely some build problems, and I've fixed most of them (though it's a bit clunky). But I don't understand enough JavaScript/ECMA-Script to solve the remaining issues. I will probably ask on the list for some help with this. Best wishes, Julian
Bug#1064824: libjs-d3-tip: TypeError: h.map is not a function
On Mon, Feb 26, 2024 at 09:32:44AM +, Julian Gilbey wrote:
> Package: libjs-d3-tip
> Version: 0.7.1-5
> Severity: important
>
> I have tried to use d3-tip.min.js for a website in another package,
> but it fails with the error: "Uncaught (in promise) TypeError: h.map
> is not a function". This comes from the index.js line "d3.map({
> ...". Presumably d3 no longer ships a map function. In more recent
> versions of d3-tip (which is now archived), this has been resolved by
> importing "map" from d3-collections. So maybe the best way to fix
> this bug is to upgrade the package.
Hi Petter,
I see you've updated the version in salsa but not yet released it; is
there any reason not to do so? Obviously, there are some missing
(build-)dependencies (d3-collection, d3-selection, rollup), but those
can be added without trouble. If it's OK, I can do that and release
it.
Best wishes,
Julian
Bug#1064824: libjs-d3-tip: TypeError: h.map is not a function
Package: libjs-d3-tip
Version: 0.7.1-5
Severity: important
I have tried to use d3-tip.min.js for a website in another package,
but it fails with the error: "Uncaught (in promise) TypeError: h.map
is not a function". This comes from the index.js line "d3.map({
...". Presumably d3 no longer ships a map function. In more recent
versions of d3-tip (which is now archived), this has been resolved by
importing "map" from d3-collections. So maybe the best way to fix
this bug is to upgrade the package.
Best wishes,
Julian
Bug#1064473: ITP: taskflow -- Parallel and Heterogeneous Task Programming System for C++
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: taskflow Version : 3.6.0+git20240218.9616467 Upstream Contact: Dr. Tsung-Wei Huang * URL : https://taskflow.github.io/ * License : Expat Programming Lang: C++ Description : Parallel and Heterogeneous Task Programming System for C++ Taskflow helps you quickly write parallel and heterogeneous task programs with high performance and simultaneous high productivity. It is faster, more expressive, with fewer lines of code, and easier for drop-in integration than many of existing task programming libraries. It is provided as a collecion of C++ header files, using C++17. This package is a dependency of rapidfuzz, which is a C++ and Python library for rapid string distance calculations. In turn, rapidfuzz is a dependency of newer versions of other Python packages. It is also a great package in itself, providing a library that can be used to great effect, as described in several papers and conference presentations. I don't think it fits within the Debian Python Team's remit, yet it is needed by them. So my proposal is to have myself as maintainer for now but for the Debian Python Team to be listed as an Uploader.
Bug#1063274: pydevd: autopkgtest-failing warning with pandas 2.1
On Tue, Feb 20, 2024 at 09:46:16PM +, Rebecca N. Palmer wrote: > Is that a yes to>> Does just the patch (not the new upstream) also break > debugpy?or have you not tried specifically that? > > (I'm looking for a quick fix for the autopkgtest fail to unblock the pandas > 2.x transition. I agree that upgrading to a new upstream is a good idea in > the long run.) Dear Rebecca, A quick update on this: version -9 failed its autopkgtests on some archs, so I uploaded version -10 this morning. Hopefully that will pass and migrate in a couple of days. On the pandas front, though, I don't know if you've seen the roadmap: version 2.2 is released, and version 3.0 is in preparation. But 3.0 will depend on PyArrow - the string data type will use PyArrow as a backend rather than NumPy as at present. This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021 and it looks like this is going to be a monster to package. It's probably worth getting a small group of developers together to work on this soonish - I don't have the capacity to take it on, I'm afraid. Best wishes, Julian
Bug#1063274: pydevd: autopkgtest-failing warning with pandas 2.1
On Tue, Feb 20, 2024 at 09:46:16PM +, Rebecca N. Palmer wrote: > Is that a yes to>> Does just the patch (not the new upstream) also break > debugpy?or have you not tried specifically that? > > (I'm looking for a quick fix for the autopkgtest fail to unblock the pandas > 2.x transition. I agree that upgrading to a new upstream is a good idea in > the long run.) Fair point; I've just uploaded 2.10.0+ds-9. Best wishes, Julian
Bug#1063274: pydevd: autopkgtest-failing warning with pandas 2.1
On Mon, Feb 19, 2024 at 10:36:29PM +, Rebecca N. Palmer wrote: > Thank you for caring about not breaking other packages, and yes, that's a > good reason to not upload that new upstream for now. > > Does just the patch (not the new upstream) also break debugpy? (It > shouldn't be able to, since it only touches test code.) It's taking time to locate the source of the problem. It's a bit messy: debugpy vendors pydevd, pydevd in turn vendors bytecode. I've split out bytecode and pydevd into separate packages. Unfortunately, the bytecode version in pydevd is behind that in Debian, though that should not be too much of a problem. The native version of debugpy (with all other packages being Debian ones) passes all the tests in a Debian testing lxc container, but with the Debian versions of bytecode, pydevd and debugpy, it doesn't. So something's gone wrong somewhere, but it's taking some effort to locate (and hopefully fix!) the cause. Best wishes, Julian
Bug#1063274: pydevd: autopkgtest-failing warning with pandas 2.1
On Mon, Feb 19, 2024 at 08:03:34AM +, Rebecca N. Palmer wrote: > This has been merged but not uploaded - is there a reason it shouldn't be, > or have you just not had time? Hi Rebecca, Yes; I've upgraded to the latest version in my local repo, which includes this patch upstream, but it's now causing FTBFS issues in debugpy, which I haven't managed to track down yet. :-( Julian
Bug#1063491: python3-jedi: unvendoring python3-typeshed breaks other packages
Package: python3-jedi Version: 0.19.1+ds-1 Severity: grave Unfortunately, just removing the vendored typeshed from this package causes other packages to break. I don't fully understand the mechanism, but jedi looks to load things from the vendored directory, and if it doesn't find them, things go horribly wrong. It's broken the spyder (autopkg)tests, and several others (see tracker.debian.org for details). To be sure that python3-jedi was the cause, I built a local version of python3-jedi 0.19.1 with the vendored typeshed still present, and the spyder tests work fine with this single change. A reasonable (short-term?) fix is to reintroduce the vendored version of typeshed. This is much better than having a broken package. A horrible fix is to symlink all of the stubs from the python3-typeshed to the expected places in jedi/third_party/typeshed, but that seems like a lot of work. (One would have to get rid of typeshed/stdlib/2/ in the process, but I don't know if that will break things. Hopefully not!) Most of the stubs in python3-typeshed are not imported into jedi/third_party, only a few. But the directory layout is very different. A probably better fix would be to change the code in jedi to not look for the third_party/typeshed directory and to perhaps look in /usr/lib/python3/dist-packages/*-stubs instead (as python3-typeshed stores its stubs in multiple directories). But that's significantly more work and will be harder to test. Best wishes, Julian
Bug#1063485: python3-docopt: invalid escape sequences
On Thu, Feb 08, 2024 at 08:31:33PM +, Julian Gilbey wrote:
> Package: python3-docopt
> Version: 0.6.2-4.1
> Severity: normal
>
> Installing python3-docopt, I received the following warning messages:
>
> Setting up python3-docopt (0.6.2-4.1) ...
> /usr/lib/python3/dist-packages/docopt.py:165: SyntaxWarning: invalid escape
> sequence '\S'
> name = re.findall('(<\S*?>)', source)[0]
> [...]
>
> These strings should all be preceded by an "r" to make them raw
> strings.
I've just uploaded a fixed version (as an NMU) to DELAYED/7-day.
I also see that you haven't touched this package since 2018; perhaps
you would like to hand over maintainership of it to the Debian Python
Team?
Best wishes,
Julian
Bug#1063485: python3-docopt: invalid escape sequences
Package: python3-docopt
Version: 0.6.2-4.1
Severity: normal
Installing python3-docopt, I received the following warning messages:
Setting up python3-docopt (0.6.2-4.1) ...
/usr/lib/python3/dist-packages/docopt.py:165: SyntaxWarning: invalid escape
sequence '\S'
name = re.findall('(<\S*?>)', source)[0]
/usr/lib/python3/dist-packages/docopt.py:166: SyntaxWarning: invalid escape
sequence '\['
value = re.findall('\[default: (.*)\]', source, flags=re.I)
/usr/lib/python3/dist-packages/docopt.py:207: SyntaxWarning: invalid escape
sequence '\['
matched = re.findall('\[default: (.*)\]', description, flags=re.I)
/usr/lib/python3/dist-packages/docopt.py:456: SyntaxWarning: invalid escape
sequence '\S'
split = re.split('\n *(<\S+?>|-\S+?)', doc)[1:]
These strings should all be preceded by an "r" to make them raw
strings.
Best wishes,
Julian
Bug#1063465: python3-numpy: installs duplicate files in /usr/lib/python3.X/dist-packages
Package: python3-numpy Version: 1:1.24.2-2 Severity: normal When installing python3-numpy, I got a warning: Skipping /usr/lib/python3.12/dist-packages/numpy-1.24.2.egg-info due to invalid metadata entry 'name' Investigating further, I see that python3-numpy includes the following: /usr/lib/python3.11 /usr/lib/python3.11/dist-packages /usr/lib/python3.11/dist-packages/numpy /usr/lib/python3.11/dist-packages/numpy/core /usr/lib/python3.11/dist-packages/numpy/core/_multiarray_umath.cpython-311-x86_64-linux-gnu.so /usr/lib/python3.12 /usr/lib/python3.12/dist-packages /usr/lib/python3.12/dist-packages/numpy /usr/lib/python3.12/dist-packages/numpy/core /usr/lib/python3.12/dist-packages/numpy/core/_multiarray_umath.cpython-312-x86_64-linux-gnu.so /usr/lib/python3.12/dist-packages/numpy/core/lib /usr/lib/python3.12/dist-packages/numpy/core/lib/libnpymath.a /usr/lib/python3.12/dist-packages/numpy/random /usr/lib/python3.12/dist-packages/numpy/random/lib /usr/lib/python3.12/dist-packages/numpy/random/lib/libnpyrandom.a /usr/lib/python3.12/dist-packages/numpy-1.24.2.egg-info /usr/lib/python3.12/dist-packages/numpy-1.24.2.egg-info/entry_points.txt These files are all likely to be duplicates of the identically-named files in /usr/lib/python3/dist-packages, so should be removed from the binary package. Best wishes, Julian
Bug#1063464: python3-kiwisolver: has invalid Python version number (0.0.0)
Package: python3-kiwisolver Version: 1.4.4-1+b2 Severity: normal The metadata file: /usr/lib/python3/dist-packages/kiwisolver-0.0.0.dist-info/METADATA specifies the version number as 0.0.0. This is obviously incorrect. (It might be that the build is looking for a git version tag and fails to find one. In that case, you could set the environment variable SETUPTOOLS_SCM_PRETEND_VERSION appropriately.) Best wishes, Julian
Bug#1063463: python3-kiwisolver: installs metadata files in /usr/lib/python3.12/dist-packages
Package: python3-kiwisolver Version: 1.4.4-1+b2 Severity: normal When I install this package, I get warnings: WARNING: Skipping /usr/lib/python3.12/dist-packages/kiwisolver-0.0.0.dist-info due to invalid metadata entry 'name' Investigating further, I see that the package installs the following: /usr/lib/python3/dist-packages/kiwisolver-0.0.0.dist-info /usr/lib/python3/dist-packages/kiwisolver-0.0.0.dist-info/INSTALLER /usr/lib/python3/dist-packages/kiwisolver-0.0.0.dist-info/METADATA /usr/lib/python3/dist-packages/kiwisolver-0.0.0.dist-info/WHEEL /usr/lib/python3/dist-packages/kiwisolver-0.0.0.dist-info/top_level.txt /usr/lib/python3.12 /usr/lib/python3.12/dist-packages /usr/lib/python3.12/dist-packages/kiwisolver-0.0.0.dist-info /usr/lib/python3.12/dist-packages/kiwisolver-0.0.0.dist-info/INSTALLER There should be no files in /usr/lib/python3.12. Best wishes, Julian
Bug#1058365: add patch
On Thu, Jan 11, 2024 at 12:00:13PM +0100, Matthias Klose wrote: > Control: tags -1 + patch > > patch at > https://launchpadlibrarian.net/708712831/python-jedi_0.18.2-1_0.18.2-1ubuntu1.diff.gz Hi Piotr, Are you able to upload a fixed or new version of python-jedi to address this serious bug? It is likely to soon pull spyder out of testing, which I am responsible for. I'm happy to do an NMU, uploading the new version of python-jedi (as that introduces compatibility with Python 3.12). I'll do so in a few days if I haven't heard back from you by then. At the same time, using the python3-typeshed package rather than vendoring it (#1039627) would also fix #1040094, but this might be a bit more work, as jedi/inference/gradual/utils.py would also need some attention, and some of the test_typeshed.py tests might no longer work. You could also drop python3-unittest2 without harm (#1058976). I'd be happy to have a go at these other bugs if you would like me to. Best wishes, Julian
Bug#1062604: cython-legacy: Please package new release 0.29.37
On Fri, Feb 02, 2024 at 12:27:50AM -0500, Boyuan Yang wrote: > Source: cython-legacy > Severity: normal > Version: 0.29.36-3 > X-Debbugs-CC: gin...@debian.org debian-pyt...@lists.debian.org > > Hi, > > The cython upstream has released a new 0.29.37 release, that hopefully have > brought official python 3.12 support. Please test and package it in Debian and > I hope it could solve the compatibility issue between cython-legacy and python > 3.12. > > Thanks, > Boyuan Yang Hi Boyuan, I've just uploaded it, but the changes from 0.29.36 are quite minor. It certainly doesn't introduce Python 3.12 support (and the tests which failed with 0.29.36 on Python 3.12 still fail). Best wishes, Julian
Bug#1063034: nvidia-kernel-dkms: should depend on kernel headers
Package: nvidia-kernel-dkms Version: 525.147.05-5 Severity: serious This module did not build on my machine. I tracked down the cause to the absence of the relevant linux-headers package, which is required to build the module. This package should depend on linux-headers-generic to ensure that the appropriate linux-headers- package is installed. Best wishes, Julian
Bug#1061659: Fwd: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to testing for too long: i386 autopkgtest regression
On Mon, Jan 29, 2024 at 02:23:21AM +0530, Nilesh Patra wrote: > +Maytha who prepared the upload. > > On Sun, Jan 28, 2024 at 05:05:55PM +0000, Julian Gilbey wrote: > > Hi Nilesh, > > > > You did the last upload of this package - do you have any idea about > > this bug? > > I've been trying to track it down for the past hour but I don't have a fix > that I am confident about. > [...] > > On compiler level O_LARGEFILE is set to 0x0 on 64 bit systems while it is > 0x8000 (equivalent to 32-bit integer) for i386. > In fuse/print.go, LARGEFILE is hard-coded to "0x8000" which ends up matching > the value on 32-bit system > and it chokes with the panic. > > Interestingly, for all other 32-bit archs that are tested on debci, it is set > to a value higher than 0x8000 and so > they magically work. Given that the package is written with 64-bit systems in > focus, this change can work: > > - 0x8000: "LARGEFILE", > + 0x0:"LARGEFILE", > > And I have confirmed that it gets the test passing, but this looks... wrong. > OTOH, the if block inside and the panic statements were probably always > deadcode > whenever LARGEFILE flag was being passed considering it was geared towards > 64-bit use-cases. > > Please let me know what you think about this. Hi Nilesh and Maytha, Thanks for your work on this! Unfortunately, I really don't know enough about the inner workings of go-fuse to know how best to handle this. But your reasoning sounds good to me. Let's see if Hanwen responds to the GitHub issue. Best wishes, Julian
Bug#1061659: Fwd: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to testing for too long: i386 autopkgtest regression
Hi Nilesh, You did the last upload of this package - do you have any idea about this bug? Best wishes, Julian - Forwarded message from Paul Gevers - Date: Sun, 28 Jan 2024 08:50:51 +0100 From: Paul Gevers Subject: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to testing for too long: i386 autopkgtest regression To: sub...@bugs.debian.org Source: golang-github-hanwen-go-fuse Version: 2.1.0+git20220822.58a7e14-1 Severity: serious Control: close -1 2.4.2-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:golang-github-hanwen-go-fuse has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest on i386. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=golang-github-hanwen-go-fuse - End forwarded message -
Bug#1061550: elan: creates invalid settings file on startup
On Fri, Jan 26, 2024 at 09:36:07AM +, Julian Gilbey wrote:
> [...]
>
> The settings file, ~/.elan/settings.toml, contains the single line:
>
> { telemetry = false, version = "12", overrides = {} }
>
> which is clearly in JSON format rather than TOML format.
> [...]
It seems that the cause of this bug is probably the Debian patch that
changes the version of the toml crate. There are breaking changes, so
the toml functions used in elan need to be updated to reflect these
changes.
Best wishes,
Julian
Bug#1061550: elan: creates invalid settings file on startup
Package: elan
Version: 3.0.0-2
Severity: important
I installed elan, and had no ~/.elan directory. I created an empty
directory ~/leantest, changed into it and ran the command "elan
default stable". This creates the ~/.elan directory and populates
it. However, the output of this command was:
info: syncing channel updates for 'stable'
info: latest update on stable, lean version v4.4.0
info: downloading component 'lean'
Total: 182.6 MiB Speed: 8.0 MiB/s
info: installing component 'lean'
error: error parsing settings
The settings file, ~/.elan/settings.toml, contains the single line:
{ telemetry = false, version = "12", overrides = {} }
which is clearly in JSON format rather than TOML format.
Manually editing the file to read:
telemetry = false
version = "12"
overrides = { }
allows "elan default stable" to work, though it then modifies
~/.elan/settings.toml to read:
{ default_toolchain = "stable", telemetry = false, version = "12", overrides =
{} }
which then breaks the next attempt to use elan:
euler:~/leantest $ elan default stable
info: using existing install for 'stable'
error: error parsing settings
So it seems that elan is for some reason writing out the settings in
JSON rather than TOML format every time it touches them.
As a data point, the settings.toml on a Mac reads (between the "---"
lines):
---
default_toolchain = "stable"
telemetry = false
version = "12"
[overrides]
---
So something is very wrong here.
Best wishes,
Julian
Bug#1043240: transition: pandas 1.5 -> 2.1
On Fri, Jan 26, 2024 at 08:43:03AM +0200, Graham Inggs wrote: > Hi > > On Tue, 23 Jan 2024 at 14:38, Julian Gilbey wrote: > > We're nearly there (the transition page says it's 99% done), and when > > this transition is complete, then python3-defaults 3.11.6+ will be > > able to migrate to testing. > > python3-defaults/3.11.6-1 with Python 3.12 as a supported version is > now in testing [1]. Wonderful news! Congratulations to everyone who helped to make this happen! Best wishes, Julian
Bug#1061366: python3.12: Python3.12 segfaults on python-xarray testsuite
reassign 1061366 python3-xarray thanks On Tue, Jan 23, 2024 at 07:19:35AM +, Alastair McKinstry wrote: > Package: python3.12 > Version: 3.12.1-2 > Severity: serious > Justification: 4 > X-Debbugs-Cc: debian-pyt...@lists.debian.org > > Python3.12 segfaults on the unittest suite for python-xarray > (2024.01.0, head of tree in debian/latest) > Unfortunately I cannot get a core dump yet to be more specific; this is on > arm64 at least. > > > > -- System Information: > Debian Release: 12.4 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) > Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled
