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#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#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#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#1063971: marked as pending in python-dateutil
Control: tag -1 pending Hello, Bug #1063971 in python-dateutil reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-dateutil/-/commit/7b821657a3281a3662c85324abd41a105df001ec New upstream version (closes: #1063971); remove ancient Breaks field and update Standards-Version (this message was generated automatically) -- Greetings https://bugs.debian.org/1063971
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#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#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#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#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#1063274: marked as pending in pydevd
Control: tag -1 pending Hello, Bug #1063274 in pydevd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pydevd/-/commit/71ad2efe09bbf80d73f1116c2e209a7cef713e0a Tests: be compatible with pandas 2.1 (closes: #1063274) (this message was generated automatically) -- Greetings https://bugs.debian.org/1063274
Bug#1063274: marked as pending in pydevd
Control: tag -1 pending Hello, Bug #1063274 in pydevd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pydevd/-/commit/4c5714f817b2642e6b2ca979756e701e645232c3 Merge branch 'fix1063274' into 'debian/unstable' Tests: be compatible with pandas 2.1 (closes: #1063274) See merge request python-team/packages/pydevd!1 (this message was generated automatically) -- Greetings https://bugs.debian.org/1063274
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#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#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#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
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
On Thu, Jan 04, 2024 at 08:28:53PM +, Julian Gilbey wrote: > Hi all, > > A quick update > [...] > > Updates: > [...] > > (2) It appears that all of the autopkgtests triggered by > python3-werkzeug 2.3.8 have passed (though most are no longer showing > on tracker.d.o). The only package that is failing is flask-dance. As > you (Carsten) mentioned earlier, "the upstream package isn't really > ready for the newer versions", so I suggest that we file an RC bug > against it. Perhaps we can ask the appropriate team (release team?) > to drop it from testing for now so that python3-werkzeug can migrate. > It has no reverse dependencies. And upstream fixed it with version 7.0.1 within hours of it being reported! I've just uploaded that to unstable, so python3-werkzeug will hopefully migrate in a couple of days' time. Best wishes, Julian
Bug#1060020: marked as pending in flask-dance
Control: tag -1 pending Hello, Bug #1060020 in flask-dance reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/flask-dance/-/commit/8e14c38b796d0fff768fad95ac64fdf7a52b572a New upstream version (closes: #1060020) (this message was generated automatically) -- Greetings https://bugs.debian.org/1060020
Bug#1060020: flask-dance: FTBFS with python3-werkzeug >= 2.3.8
Source: flask-dance Version: 7.0.0-1 Severity: serious flask-dance fails its tests when built with python3-werkzeug 2.3.8-1 (and also with version 3.0.x in experimental as well), and needs updating to handle this. Also reported upstream to https://github.com/singingwolfboy/flask-dance/issues/425 Best wishes, Julian
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hi all, A quick update On Thu, Jan 04, 2024 at 12:13:19PM +0100, Thomas Goirand wrote: > On 1/3/24 22:22, Julian Gilbey wrote: > > On Fri, Dec 22, 2023 at 12:04:48AM +0100, Gregor Riepl wrote: > > > Hi Carsten, > > > [...] > > > > > > My point was that if, for whatever reason, werkzeug 3.0.1 is not yet fit > > > for > > > release, it should be enough to upgrade to 2.3.5 to address these unit > > > test > > > failures. > > > [...] Updates: (1) I've added python3-markupsafe to the Build-Depends and pushed to debian/experimental (though not uploaded it to experimental) (2) It appears that all of the autopkgtests triggered by python3-werkzeug 2.3.8 have passed (though most are no longer showing on tracker.d.o). The only package that is failing is flask-dance. As you (Carsten) mentioned earlier, "the upstream package isn't really ready for the newer versions", so I suggest that we file an RC bug against it. Perhaps we can ask the appropriate team (release team?) to drop it from testing for now so that python3-werkzeug can migrate. It has no reverse dependencies. Best wishes, Julian
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
On Thu, Jan 04, 2024 at 12:13:19PM +0100, Thomas Goirand wrote: > On 1/3/24 22:22, Julian Gilbey wrote: > > On Fri, Dec 22, 2023 at 12:04:48AM +0100, Gregor Riepl wrote: > > > Hi Carsten, > > > [...] > > > > > > My point was that if, for whatever reason, werkzeug 3.0.1 is not yet fit > > > for > > > release, it should be enough to upgrade to 2.3.5 to address these unit > > > test > > > failures. > > > [...] > > > > > > That doesn't make any sense to me. These deprecations are obviously in > > > werkzeug and not flask-login. Why would changes in flask-login fix them? > > > > > > Not saying flask-login shouldn't be updated, but that's not the right > > > scope > > > for this bug report. > > > > Just to throw in: these werkzeug failures are also causing a similar > > FTBFS in debugpy; I've temporarily addressed it by skipping these unit > > tests, but that's not a great solution. > > > > I just took a quick look at upgrading the unstable/testing version of > > werkzeug to 2.3.8 in the meantime. It was pretty quick, and the > > package tests all pass. Shall I upload it to unstable? On salsa, I > > would push to debian/2.x for the Debian branch and to upstream-2.x for > > the upstream, so as not to prevent merging the experimental branch > > into debian/master later. Actually, it is probably OK to use the > > upstream branch for this update without causing problems, but might be > > better to be safe. > > > > (Incidentally, while doing this, I spotted one bug with the current > > experimental version: it is missing a Build-Depends on > > python3-markupsafe.) > > > > Best wishes, > > > > Julian > > Hi Julian, > > I do not agree with Casten here. Please do upload 2.3.8 to unstable if it > fixes things, so we have time to address all the Python 3.12 issues right > now. Please hold on uploading 3.x (as well as werkzeug) if this can wait, > because we need to address all the Python 3.12 issues first, and now is not > a good time to transition any other components. > > Upgrading flask+werkzeug is *NOT* urgent. Fixing all 3.12 issues must be our > current priority. > > Cheers, > > Thomas Goirand (zigo) Hi Thomas, I've already uploaded 2.3.8 for exactly this reason ;-) Best wishes, Julian
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
On Thu, Jan 04, 2024 at 09:23:58AM +, Julian Gilbey wrote: > Hello Carsten, > [...] > There are other packages that currently FTBFS because werkzeug 2.2.x > is not compatible with Python 3.12 in some small ways. It would fix > those FTBFS bugs now; 6 months is a long time to wait! I've already > done the work on 2.3.8, so it's just a matter of uploading it. I'll > do that now. Done, and pushed to salsa. Let's see what happens ;-) The debian branch is debian/2.x, and I used the standard upstream and pristine-tar branches. So you'll need to do a manual git pull on the upstream and pristine-tar branches, and a git pull --tags; gbp push will probably not work on debian/experimental until there's a new upstream 3.x, so you'll have to do a manual git push and git push --tags until that. But gbp buildpackage will still work fine. Best wishes, Julian
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hello Carsten,
On Thu, Jan 04, 2024 at 07:07:01AM +0100, Carsten Schoenert wrote:
> Hello Julian,
>
> Am 03.01.24 um 22:22 schrieb Julian Gilbey:
> > Just to throw in: these werkzeug failures are also causing a similar
> > FTBFS in debugpy; I've temporarily addressed it by skipping these unit
> > tests, but that's not a great solution.
> >
> > I just took a quick look at upgrading the unstable/testing version of
> > werkzeug to 2.3.8 in the meantime. It was pretty quick, and the
> > package tests all pass. Shall I upload it to unstable?
>
> in the end it's up to you. I personally still see no real gain in doing such
> a version bump if we could spend the same time on fixing issues we currently
> see for Flask/Werkzeug >= 3.x given that we need to migrate any way in a not
> to far future. Why spend now time on things that could happen already within
> the past 6 months? What do we really gain?
There are other packages that currently FTBFS because werkzeug 2.2.x
is not compatible with Python 3.12 in some small ways. It would fix
those FTBFS bugs now; 6 months is a long time to wait! I've already
done the work on 2.3.8, so it's just a matter of uploading it. I'll
do that now.
> And, in case you decide to upload Werkzeug 2.3.8, my guess is you will see
> almost the same fallout as that is still visible for the both packages with
> the version bump to 3.x in experimental. With one exception, it will produce
> pressure to fix out the issues we seen until now even more.
I guess that 2.3.8 is much closer to the version currently in testing
than 3.x is. It will certainly fix some bugs.
> I worked on a lot of packages that had FTBFS or test suite issues in the
> past 2-3 weeks, the current queue of outstanding packages for Flask/Werkzeug
> 3.x is down to 5 packages.
That's great, thanks!!
[... list snipped ...]
> > (Incidentally, while doing this, I spotted one bug with the current
> > experimental version: it is missing a Build-Depends on
> > python3-markupsafe.)
>
> The only requirement for Markupsafe in Flask 3.0.0 is listed in
> requirements/tests-pallets-min{.*}.
>
> The build of src:flask is depending on python3-werkzeug >= 3.x, which has
> itself a dependency on python3-markupsafe, so if you spot a missing direct
> dependency I'm interested how this comes to play as Markupsafe should be
> around at build time.
In the debian/experimental branch of python-werkzeug, debian/control
does not mention python3-markupsafe, but it should do.
Best wishes,
Julian
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
On Fri, Dec 22, 2023 at 12:04:48AM +0100, Gregor Riepl wrote: > Hi Carsten, > [...] > > My point was that if, for whatever reason, werkzeug 3.0.1 is not yet fit for > release, it should be enough to upgrade to 2.3.5 to address these unit test > failures. > [...] > > That doesn't make any sense to me. These deprecations are obviously in > werkzeug and not flask-login. Why would changes in flask-login fix them? > > Not saying flask-login shouldn't be updated, but that's not the right scope > for this bug report. Just to throw in: these werkzeug failures are also causing a similar FTBFS in debugpy; I've temporarily addressed it by skipping these unit tests, but that's not a great solution. I just took a quick look at upgrading the unstable/testing version of werkzeug to 2.3.8 in the meantime. It was pretty quick, and the package tests all pass. Shall I upload it to unstable? On salsa, I would push to debian/2.x for the Debian branch and to upstream-2.x for the upstream, so as not to prevent merging the experimental branch into debian/master later. Actually, it is probably OK to use the upstream branch for this update without causing problems, but might be better to be safe. (Incidentally, while doing this, I spotted one bug with the current experimental version: it is missing a Build-Depends on python3-markupsafe.) Best wishes, Julian
Bug#1057950: marked as pending in dask.distributed
Control: tag -1 pending Hello, Bug #1057950 in dask.distributed reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/dask.distributed/-/commit/3251532057218005ba71d408f080f7b56985835b Fix sphinx config error (closes: #1057950) (this message was generated automatically) -- Greetings https://bugs.debian.org/1057950
Bug#1058401: marked as pending in debugpy
Control: tag -1 pending Hello, Bug #1058401 in debugpy reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/debugpy/-/commit/baef6a8568c4fd29fbba1dd451440bd8ffd4cd11 Skip failing tests (closes: #1058401) (this message was generated automatically) -- Greetings https://bugs.debian.org/1058401
Bug#1058222: marked as pending in pydevd
Control: tag -1 pending Hello, Bug #1058222 in pydevd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pydevd/-/commit/466f9efb3a080d988b218362b1bb1eecf0ec4cb8 Fix FTBFS and reported failing tests upstream (closes: #1058222) (this message was generated automatically) -- Greetings https://bugs.debian.org/1058222
Bug#1058222: marked as pending in pydevd
Control: tag -1 pending Hello, Bug #1058222 in pydevd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pydevd/-/commit/2ecef63c6c2f780fd046a26145507e06f9dd9e8d Fix FTBFS (closes: #1058222) (this message was generated automatically) -- Greetings https://bugs.debian.org/1058222
Bug#1059334: marked as pending in python-bytecode
Control: tag -1 pending Hello, Bug #1059334 in python-bytecode reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-bytecode/-/commit/c814e57a38c7165281061f7eccb2079b86de81a4 Fix autopkgtest calling (closes: #1059334); this requires moving away from pybuild-autopkgtest to manually calling pytest (see #1059529). (this message was generated automatically) -- Greetings https://bugs.debian.org/1059334
Bug#1056460: python-bytecode's autopkg tests fail with Python 3.12 (armhf)
severity 1056460 important thanks On Wed, Nov 22, 2023 at 02:29:47PM +0100, Matthias Klose wrote: > Package: src:python-bytecode > Version: 0.15.1-1 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: python3.12 > > python-bytecode's autopkg tests fail with Python 3.12 (armhf): > > [...] Upstream don't have much idea of what might be causing this. For the time being, I have found that finishing a test early on armhf prevents the crash from happening. On the other hand, just disabling the test does not, which is bizarre. So downgrading the severity of this bug to important for now.
Bug#1058429: marked as pending in textdistance
Control: tag -1 pending Hello, Bug #1058429 in textdistance reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/textdistance/-/commit/ee102e0c91c95b94cf6c9252f2debdf330f96d79 New upstream version (closes: #1058429); update patches and dependencies (this message was generated automatically) -- Greetings https://bugs.debian.org/1058429
Bug#1056531: cython 3.x (for Python 3.12)
severity 1056531 important retitle 1056531 spyder-kernels: cannot handle Cython files with Python 3.12 thanks Update on this bug. cython3-legacy and the current cython3 (which I've just updated to not fail the autopkgtest tests with Python 3.12) do not have working pyximport modules. So I'm skipping the tests in this package which depend on that for the time being. When Cython 3.x is in testing, I will re-enable those tests and depend on the new version of cython3. In the meantime, Spyder will have difficulties with Cython source files if Python 3.12 is the default Python. As long as Python 3.11 is the default, it will be fine. So I'm lowering the severity to important for now, and will close it once I can depend on Cython 3.x. Best wishes, Julian
Bug#1056531: cython 3.x (for Python 3.12)
On Mon, Dec 11, 2023 at 08:06:41PM +0100, Matthias Klose wrote: > > [...] > > Excellent - I didn't know about that. Are you OK for me to upload > > versions of cython and cython-legacy which depend on this to fix the > > Python 3.12 breakage? > > not for cython, which won't need that soonish for 3.0.x. and if you have to > update the b-d to cython3-legacy, why not add the zombie-imp dependency as > well manually for the few packages that need it? The problem is not with other packages importing imp (which need to be fixed in such a case), rather that pyximport (in cython/cython-legacy) imports imp. So it's cython that needs to be patched. I'm wondering what the provisional timescale for cython 3.0.x is? Should I just leave my package with an autopkgtest failure until cython 3.0.x is in unstable or ideally testing? That's why I was thinking of also patching cython in the short term until we are ready for cython 3.0.x to enter unstable. Best wishes, Julian
Bug#1056531: cython 3.x (for Python 3.12)
On Mon, Dec 11, 2023 at 04:34:17PM +0100, Matthias Klose wrote: > On 11.12.23 16:19, Julian Gilbey wrote: > > On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote: > > > [...] > > > You could package a non-conflicting cython-legacy, however that would > > > require more changes, also how to build it. > > > > Hi Matthias, > > > > Unfortunately, at least some of cython3-legacy doesn't currently work > > with Python 3.12, and is the primary cause of (at least) #1056531. > > cython3 provides the pyximport module, and that uses the imp module > > which has been removed from Python 3.12. > > > > Two possible ways forward on this particular bug: > > > > - Disable all of the cython tests for this package for the time being, > >until cython 3.x migrates to testing - this is simple and effective. > > > > - Patch cython3-legacy to use importlib rather than imp. This is > >probably a good thing to do anyway. (It may also be good to do this > >with cython3 version 0.x currently in testing/unstable until cython > >3.x is able to be uploaded to unstable.) Then have my package's > >autopkgtest depend on cython3-legacy (unless cython3 0.x is also > >patched). > > I won't working on this. Have you tried to depend on the python3-zombie-imp > instead? Excellent - I didn't know about that. Are you OK for me to upload versions of cython and cython-legacy which depend on this to fix the Python 3.12 breakage? Best wishes, Julian
Bug#1056531: cython 3.x (for Python 3.12)
On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote: > [...] > You could package a non-conflicting cython-legacy, however that would > require more changes, also how to build it. Hi Matthias, Unfortunately, at least some of cython3-legacy doesn't currently work with Python 3.12, and is the primary cause of (at least) #1056531. cython3 provides the pyximport module, and that uses the imp module which has been removed from Python 3.12. Two possible ways forward on this particular bug: - Disable all of the cython tests for this package for the time being, until cython 3.x migrates to testing - this is simple and effective. - Patch cython3-legacy to use importlib rather than imp. This is probably a good thing to do anyway. (It may also be good to do this with cython3 version 0.x currently in testing/unstable until cython 3.x is able to be uploaded to unstable.) Then have my package's autopkgtest depend on cython3-legacy (unless cython3 0.x is also patched). Thoughts? Julian
Bug#1056516: marked as pending in qstylizer
Control: tag -1 pending Hello, Bug #1056516 in qstylizer reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/qstylizer/-/commit/47cdadceaa15632148efd6015c5834841b75d8bd Fix package tests for Python 3.12 (closes: #1056516) (this message was generated automatically) -- Greetings https://bugs.debian.org/1056516
Bug#1057730: marked as pending in python-jellyfish
Control: tag -1 pending Hello, Bug #1057730 in python-jellyfish reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-jellyfish/-/commit/10d200089b11f984a1de60b5185e5d37f679d721 Fix binary-only build (closes: #1057730) (this message was generated automatically) -- Greetings https://bugs.debian.org/1057730
Bug#1055555: marked as pending in python-jellyfish
Control: tag -1 pending Hello, Bug #105 in python-jellyfish reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-jellyfish/-/commit/62b719f11470df24c47c768def1fb600dcb78827 Mark new version as working with Python 3.12 (closes: #105) (this message was generated automatically) -- Greetings https://bugs.debian.org/105
Bug#1057451: rust-ahash: autopkgtests failing
Source: rust-ahash Version: 0.8.5-2 Severity: serious Hi Jonas, I have a package that depends on the newer version of rust-ahash, so I've just taken a quick look at this package, which is not migrating to testing because the autopkgtests are failing. I am no Rust expert, so I don't know the cause of this failure. One thought: perhaps it's because the autopkgtest dependencies (debian/tests/control) need to be updated? Here are the version differences I can see between debian/control and debian/tests/control: dh-cargo (>= 25) versus (>= 18) librust-serde-1+default-dev (>= 1.0.117) versus (>= 1.0.59) But it may be something else in this control file, like a missing dependency perhaps? Or there may be a bug in the upstream package. Best wishes, Julian
Bug#1050086: rust-ahash: Fails to build
On Sat, Aug 19, 2023 at 11:31:42AM -0400, Jeremy Bícha wrote: > Source: rust-ahash > Version: 0.8.3-7 > Severity: serious > Tags: ftbfs > > rust-ahash fails to build. Here's a build log excerpt: > [...] This bug report can be closed, as 0.8.5-2 does successfully build. Best wishes, Julian
Bug#1055555: python-jellyfish fails tests with Python 3.12
On Wed, Nov 08, 2023 at 08:27:14AM +0100, Matthias Klose wrote: > Package: src:python-jellyfish > Version: 0.8.9-1 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: python3.12 > > python-jellyfish fails tests with Python 3.12 > > [...] There is a new upstream version of this package which should fix this. Upstream have migrated from cjellyfish (a C-based library of functions for computing distances quickly) to a Rust-based solution. This requires version 0.8.x of librust-ahash-dev, which is currently stuck in unstable due to bug #1050086. Best wishes, Julian
Bug#1054699: marked as pending in node-webfont
Control: tag -1 pending Hello, Bug #1054699 in node-webfont reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/js-team/node-webfont/-/commit/34a5defa443ceb664143a31e047f1534eb614185 Remove hardening flags unsupported by current emscripten version (closes: #1054699) (this message was generated automatically) -- Greetings https://bugs.debian.org/1054699
Bug#1052842: marked as pending in pydevd
Control: tag -1 pending Hello, Bug #1052842 in pydevd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pydevd/-/commit/33c36a4f4ed1cd041a3fcf68551f2ebc5268714e Allow django 4.2 in tests (closes: #1052842) (this message was generated automatically) -- Greetings https://bugs.debian.org/1052842
Bug#1040940: rmlint-gui fails to start: SyntaxError: source code cannot contain null bytes
Package: rmlint-gui Version: 2.9.0-2.4 Severity: grave euler:~ $ rmlint --gui File "/tmp/.shredder-bootstrap.py.KFWS71", line 23 SyntaxError: source code cannot contain null bytes The generated temporary source file has a null byte at the end of the file. This is quite possibly already fixed upstream.
Bug#1040179: rmlint-gui: invalid Python version number breaks other packages
Hi Carlos,
A quick update: I have uploaded 2.9.0-2.4 to DELAYED/7-days. The
debdiff between -2.3 and -2.4 is attached.
Best wishes,
Julian
On Tue, Jul 04, 2023 at 04:47:29PM +0100, Julian Gilbey wrote:
> Hi Carlos,
>
> This package has a grave bug against it as it breaks other packages.
> I'll do an NMU in the next couple of days (uploading to the delayed
> queue) unless you would like to do it yourself.
>
> Please do let me know!
>
> Best wishes,
>
>Julian
>
> On Tue, Jul 04, 2023 at 10:23:09AM +0100, Julian Gilbey wrote:
> > reassign 1040179 rmlint-gui
> > severity 1040179 grave
> > retitle 1040179 rmlint-gui: invalid Python version number breaks other
> > packages
> > thanks
> >
> > On Mon, Jul 03, 2023 at 08:03:58PM -0400, mhaag85893 wrote:
> > > Hi, Julian
> > >
> > > That worked! Here's the output:
> >
> > Hi Mike,
> >
> > Fantastic, thanks!
> >
> > > Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
> > > Type "help", "copyright", "credits" or "license()" for more
> > > information.
> > >
> > > == RESTART: /home/mike/Downloads/check_version_info.py
> > > =
> > > Info file
> > > /usr/lib/python3/dist-packages/Shredder-2.9.0.Odd.Olm.egg-info has
> > > invalid version 2.9.0 Odd Olm
> > >
> > > I apt purged rmlint and rmlint-gui followed by an apt autoremove. Then,
> > > restarted Spyder and the error message did not appear.
> > >
> > > To verify, I reinstalled rmlint and rmlint-gui. Then, restarted Spyder
> > > which
> > > reproduced the error message.
> > > [...]
> >
> > OK, so you've located the culprit - thank you for doing this.
> >
> > > If you want me to try something else, let me know, but it sure looks like
> > > the
> > > 1040179 bug report can be closed.
> >
> > No, I won't close it, as it is a major bug in the rmlint-gui package.
> > I'll reassign it there. Since rmlint has no active maintainer, I'll
> > deal with this myself in the next couple of days.
> >
> > Best wishes,
> >
> >Julian
diff -Nru rmlint-2.9.0/debian/changelog rmlint-2.9.0/debian/changelog
--- rmlint-2.9.0/debian/changelog 2021-04-15 22:03:37.0 +0100
+++ rmlint-2.9.0/debian/changelog 2023-07-05 09:31:46.0 +0100
@@ -1,3 +1,11 @@
+rmlint (2.9.0-2.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix error in other packages caused by invalid python package version
+number (cherry-picking upstream patch; closes: #1040179)
+
+ -- Julian Gilbey Wed, 05 Jul 2023 09:31:46 +0100
+
rmlint (2.9.0-2.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
--- rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch 2020-12-01 18:56:33.0 +
+++ rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch 2023-07-05 09:31:46.0 +0100
@@ -10,11 +10,9 @@
lib/config.h.in | 62 ++---
1 file changed, 33 insertions(+), 29 deletions(-)
-diff --git a/lib/config.h.in b/lib/config.h.in
-index 44d7e5d9..d9fdeabd 100644
--- a/lib/config.h.in
+++ b/lib/config.h.in
-@@ -121,9 +121,13 @@
+@@ -123,9 +123,13 @@
# define N_(String) gettext_noop (String)
#endif
@@ -30,7 +28,7 @@
typedef guint64 RmOff;
-@@ -150,33 +154,33 @@ typedef guint64 RmOff;
+@@ -152,33 +156,33 @@
///
@@ -91,6 +89,3 @@
/* Domain for reporting errors. Needed by GOptions */
#define RM_ERROR_QUARK (g_quark_from_static_string("rmlint"))
---
-2.20.1
-
diff -Nru rmlint-2.9.0/debian/patches/python-version-number.patch rmlint-2.9.0/debian/patches/python-version-number.patch
--- rmlint-2.9.0/debian/patches/python-version-number.patch 1970-01-01 01:00:00.0 +0100
+++ rmlint-2.9.0/debian/patches/python-version-number.patch 2023-07-05 09:31:46.0 +0100
@@ -0,0 +1,17 @@
+From: Cebtenzzre
+Subject: gui: use PEP 440-compliant version number
+Origin: upstream, https://github.com/sahib/rmlint/commit/b5a6d9b359b1fc1ea75bdb6c1ae6cbdc0a304ecf
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040179
+
+--- a/gui/setup.py
b/gui/setup.py
+@@ -14,7 +14,8 @@
+ with open('../.version', 'r') as handle:
+ version_string = handle.read()
+
+-return version_string.strip()
++version_numbers, _ = version_string.split(' ', 1)
++return
Bug#1040179: rmlint-gui: invalid Python version number breaks other packages
Hi Carlos, This package has a grave bug against it as it breaks other packages. I'll do an NMU in the next couple of days (uploading to the delayed queue) unless you would like to do it yourself. Please do let me know! Best wishes, Julian On Tue, Jul 04, 2023 at 10:23:09AM +0100, Julian Gilbey wrote: > reassign 1040179 rmlint-gui > severity 1040179 grave > retitle 1040179 rmlint-gui: invalid Python version number breaks other > packages > thanks > > On Mon, Jul 03, 2023 at 08:03:58PM -0400, mhaag85893 wrote: > > Hi, Julian > > > > That worked! Here's the output: > > Hi Mike, > > Fantastic, thanks! > > > Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux > > Type "help", "copyright", "credits" or "license()" for more information. > > > > == RESTART: /home/mike/Downloads/check_version_info.py > > = > > Info file > > /usr/lib/python3/dist-packages/Shredder-2.9.0.Odd.Olm.egg-info has > > invalid version 2.9.0 Odd Olm > > > > I apt purged rmlint and rmlint-gui followed by an apt autoremove. Then, > > restarted Spyder and the error message did not appear. > > > > To verify, I reinstalled rmlint and rmlint-gui. Then, restarted Spyder which > > reproduced the error message. > > [...] > > OK, so you've located the culprit - thank you for doing this. > > > If you want me to try something else, let me know, but it sure looks like > > the > > 1040179 bug report can be closed. > > No, I won't close it, as it is a major bug in the rmlint-gui package. > I'll reassign it there. Since rmlint has no active maintainer, I'll > deal with this myself in the next couple of days. > > Best wishes, > >Julian
Bug#1036438: anki: Anki outdated and causing problems in synchronizing and importing decks
forcemerge 958853 1036438 thanks On Sat, May 20, 2023 at 10:38:17PM +0200, Pedro GONZÁLEZ MURILLO wrote: > Package: anki > Version: 2.1.15+dfsg-3 > Severity: important > X-Debbugs-Cc: pedrogonzalezmurillo...@gmx.com > > Dear Maintainer, > [...] > > The problem could be solved by packaging a newer version of anki > *** End of the template - remove these template lines *** Dear Pedro, Indeed. Please see https://bugs.debian.org/958853 for more on this. Packaging a newer version of anki is a major undertaking (the whole package architecture has changed - it is now a mixture of Rust and Python, with some Javascript thrown in as well), and I don't currently have the time to work out how to do it. Anki will not be in the soon-to-be-released Debian 12 (bookworm), and will only be in trixie (the next Debian release) if I or someone else has the time to work out how to package it. Best wishes, Julian
Bug#1033106: safeeyes fails to load plugins with Python 3.11
Hi!
With no response to the RC bug in 7 days, I've just uploaded an NMU to
DELAYED/7-days.
I have also fixed #1006942 at the same time by upgrading to version
2.1.5 and updating the Depends field; the differences between 2.1.3
and 2.1.5 are only minor. (The diff-file attached is large primarily
because the new version has updated the translation files.)
The only file differences shown by debdiff on the generated debs is
that the egg-info files are now 2.1.5 rather than 2.1.3.
If you are happy with this new version, I will push the changes to
salsa once it is accepted into unstable. If you would like me to skip
the delayed queue, I'm happy to do that, and if you would prefer me to
delete the updated version and fix it yourself, I can do that too.
Best wishes,
Julian
On Fri, Mar 17, 2023 at 12:25:22PM +, Julian Gilbey wrote:
> Package: safeeyes
> Version: 2.1.3-1
> Severity: serious
> Tags: patch upstream
>
> Safeeyes uses the deprecated inspect.getargspec() function, which was
> dropped in Python 3.11, so no plugins are loaded, significantly
> impairing the functionality of this package.
>
> There is a one-line patch at
> https://github.com/slgobinath/SafeEyes/pull/505 (and a discussion at
> https://github.com/slgobinath/SafeEyes/issues/491)
>
> Please could you apply it for bookworm?
>
> Many thanks,
>
>Julian
diff -Nru safeeyes-2.1.3/debian/changelog safeeyes-2.1.5/debian/changelog
--- safeeyes-2.1.3/debian/changelog 2021-09-04 19:00:04.0 +0100
+++ safeeyes-2.1.5/debian/changelog 2023-03-24 12:32:08.0 +
@@ -1,3 +1,12 @@
+safeeyes (2.1.5-0.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * New upstream version makes icon appear in KDE/Plasma and XFCE4 system
+tray once again (Closes: #1006942)
+ * Support Python 3.11 (Closes: #1033106)
+
+ -- Julian Gilbey Fri, 24 Mar 2023 12:32:08 +
+
safeeyes (2.1.3-1) unstable; urgency=medium
* New upstream release
diff -Nru safeeyes-2.1.3/debian/control safeeyes-2.1.5/debian/control
--- safeeyes-2.1.3/debian/control 2021-09-04 19:00:04.0 +0100
+++ safeeyes-2.1.5/debian/control 2023-03-24 12:32:08.0 +
@@ -13,8 +13,8 @@
Package: safeeyes
Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}, python3-gi, python3-dbus, gir1.2-gtk-3.0
-Recommends: gir1.2-appindicator3-0.1, xprintidle
+Depends: ${misc:Depends}, ${python3:Depends}, python3-gi, python3-dbus, gir1.2-gtk-3.0, gir1.2-notify-0.7
+Recommends: gir1.2-ayatanaappindicator3-0.1, xprintidle
Description: Protect your eyes from eye strain using this continuous breaks
Safe Eyes is a simple tool to remind you to take periodic breaks for your
eyes. This is essential for anyone spending more time on the computer to
diff -Nru safeeyes-2.1.3/debian/patches/series safeeyes-2.1.5/debian/patches/series
--- safeeyes-2.1.3/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ safeeyes-2.1.5/debian/patches/series 2023-03-24 12:32:08.0 +
@@ -0,0 +1 @@
+support-python311.patch
diff -Nru safeeyes-2.1.3/debian/patches/support-python311.patch safeeyes-2.1.5/debian/patches/support-python311.patch
--- safeeyes-2.1.3/debian/patches/support-python311.patch 1970-01-01 01:00:00.0 +0100
+++ safeeyes-2.1.5/debian/patches/support-python311.patch 2023-03-24 12:32:08.0 +
@@ -0,0 +1,11 @@
+--- a/safeeyes/utility.py
b/safeeyes/utility.py
+@@ -666,7 +666,7 @@
+ Check whether the given function is defined in the module or not.
+ """
+ if hasattr(module, method_name):
+-if len(inspect.getargspec(getattr(module, method_name)).args) == no_of_args:
++if len(inspect.getfullargspec(getattr(module, method_name)).args) == no_of_args:
+ return True
+ return False
+
diff -Nru safeeyes-2.1.3/.github/FUNDING.yml safeeyes-2.1.5/.github/FUNDING.yml
--- safeeyes-2.1.3/.github/FUNDING.yml 1970-01-01 01:00:00.0 +0100
+++ safeeyes-2.1.5/.github/FUNDING.yml 2023-03-09 12:28:03.0 +
@@ -0,0 +1,12 @@
+# These are supported funding model platforms
+
+github: slgobinath
+patreon: # Replace with a single Patreon username
+open_collective: # Replace with a single Open Collective username
+ko_fi: # Replace with a single Ko-fi username
+tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
+community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
+liberapay: # Replace with a single Liberapay username
+issuehunt: # Replace with a single IssueHunt username
+otechie: # Replace with a single Otechie username
+custom: 'https://www.paypal.com/paypalme/slgobinath'
diff -Nru safeeyes-2.1.3/.github/ISSUE_TEMPLATE/bug_report.md safeeyes-2.1.5/.github/ISSUE_TEMPLATE/bug_report.md
--- safeeyes-2.1.3/.github/ISSUE_TEMPLATE/bug_report.md 1970-01-01 01:00:00.0 +0100
+++ safeeyes-2.1.5/.github/ISSUE_TEMPLATE/bug_report.md 2023-03-09 12
Bug#1033106: safeeyes fails to load plugins with Python 3.11
Package: safeeyes Version: 2.1.3-1 Severity: serious Tags: patch upstream Safeeyes uses the deprecated inspect.getargspec() function, which was dropped in Python 3.11, so no plugins are loaded, significantly impairing the functionality of this package. There is a one-line patch at https://github.com/slgobinath/SafeEyes/pull/505 (and a discussion at https://github.com/slgobinath/SafeEyes/issues/491) Please could you apply it for bookworm? Many thanks, Julian
Bug#1024047: python-line-profiler
On Mon, Feb 27, 2023 at 04:16:53PM +0100, Bastian Germann wrote: > On Mon, 13 Feb 2023 21:14:24 +0000 Julian Gilbey wrote: > > Just an FYI: though ubelt is a requirement for running the tests, a > > much more serious problem is that python-line-profiler requires an > > alpha version of Cython 3.0.0 to compile, and that is not (yet?) > > packaged for Debian. Hopefully at some point over the next two years, > > Cython 3.0 will mature enough to actually be released, and then it > > will be possible to upgrade python-line-profiler. > > The version seems to build with the stable cython3: > https://salsa.debian.org/python-team/packages/python-line-profiler/-/jobs/3998594 Thanks - that's good to know! So it should make it into trixie regardless of what happens to Cython. Best wishes, Julian
Bug#1024047: python-line-profiler
Just an FYI: though ubelt is a requirement for running the tests, a much more serious problem is that python-line-profiler requires an alpha version of Cython 3.0.0 to compile, and that is not (yet?) packaged for Debian. Hopefully at some point over the next two years, Cython 3.0 will mature enough to actually be released, and then it will be possible to upgrade python-line-profiler. Best wishes, Julian
Bug#1030530: Python 3.10 in bookworm
On Tue, Feb 07, 2023 at 12:31:23PM +0100, Joost van Baal-Ilić wrote: > Op Tue, Feb 07, 2023 at 05:52:21AM + schreef Danial Behzadi دانیال بهزادی: > > Does it worth trying to package pyenv for Debian? Ain't it against any > > rules? > > See "ITP pyenv" @ http://bugs.debian.org/978149 . Oh, how embarrassing - I already knew about this software a year ago! Best wishes, Julian
Bug#1030530: Python 3.10 in bookworm
Hi Andrey, On Mon, Feb 06, 2023 at 11:53:33AM +0100, Andrey Rakhmatullin wrote: > On Sun, Feb 05, 2023 at 01:50:34PM +0000, Julian Gilbey wrote: > > Our social contract #4 says "Our priorities are our users and free > > software". What benefits would having the python3.10 base packages in > > bookworm bring for our users (as I point out, for some users, this is > > a necessity) and what disadvantages would it bring (none that I can > > think of)? Why would we tell a whole bunch of our users: "Don't > > upgrade to Debian 12 until all of the critical packages you use from > > PyPI are upgraded to support Python 3.11, or fix those packages > > yourself"? > The next obvious step for these use cases is to just install 3.10 with > pyenv. Oh, that's brilliant! I didn't know about this tool (and I note it's not currently in Debian). This solution for users who need Python 3.10, together with the support burden of having python3.10 in bookworm (which I hadn't appreciated), I withdraw my objection to the removal of python3.10. Best wishes, Julian
Bug#1030530: Python 3.10 in bookworm
On Sun, Feb 05, 2023 at 02:41:08PM +, Stefano Rivera wrote: > Hi Julian (2023.02.05_10:38:23_+) > > > Why is the current intention not to ship the python3.10 package in > > bookworm? > > Because we aim to have a single Python release supported in every stable > release. I am not suggesting that we revert to having Python 3.10 as a "supported version" (that would be a whole separate discussion); I am suggesting that we keep just the Python 3.10 interpreter and python3.10-venv in bookworm, so that users can use it to run a virtual environment if they need to do so. > > I was trying to run some experiments in a virtual environment a few > > days ago, and it turns out that several of the Python packages I > > needed do not yet run on Python 3.11. I was saved by being able to > > run in a Python 3.10 venv and download all the required packages from > > PyPI. If bookworm shipped without python3.10, I would not have been > > able to do my work. Removing python3.10 from bookworm will seriously > > affect many of our users in a similar situation to me. > > By the time bookworm releases, that probably won't be the case any more. I honestly don't know if that will be the case or not; some packages will be much slower to adapt than others. That's why I'm suggesting we leave the python3.10 and python3.10-venv packages in bookworm. > But anything that gets removed from Debian, because it isn't ready yet > obviously gets hurt in the process... I'm not sure what you mean here? Best wishes, Julian
Bug#1030530: Python 3.10 in bookworm
Our social contract #4 says "Our priorities are our users and free software". What benefits would having the python3.10 base packages in bookworm bring for our users (as I point out, for some users, this is a necessity) and what disadvantages would it bring (none that I can think of)? Why would we tell a whole bunch of our users: "Don't upgrade to Debian 12 until all of the critical packages you use from PyPI are upgraded to support Python 3.11, or fix those packages yourself"? And may I politely remind you, Thomas, that you are very concerned about breaking things for people: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973617#40 This is likely a far greater impact than the discussion there on many more people. Best wishes, Julian On Sun, Feb 05, 2023 at 12:25:18PM +0100, Thomas Goirand wrote: > How about fixing the 3.11 issues if you hit them ? How about using Buster and > 3.9 if 3.11 doesn't work (yet) for you ? > > Thomas Goirand (zigo) > On Feb 5, 2023 11:38, Julian Gilbey wrote: > > > > Why is the current intention not to ship the python3.10 package in > > bookworm? > > > > I was trying to run some experiments in a virtual environment a few > > days ago, and it turns out that several of the Python packages I > > needed do not yet run on Python 3.11. I was saved by being able to > > run in a Python 3.10 venv and download all the required packages from > > PyPI. If bookworm shipped without python3.10, I would not have been > > able to do my work. Removing python3.10 from bookworm will seriously > > affect many of our users in a similar situation to me. > > > > Best wishes, > > > > Julian > > > > P.S. We should also fix #1036268 if we do keep python3.10 in bookworm; > > I'm happy to do an NMU if needed.
Bug#1030530: Python 3.10 in bookworm
Why is the current intention not to ship the python3.10 package in bookworm? I was trying to run some experiments in a virtual environment a few days ago, and it turns out that several of the Python packages I needed do not yet run on Python 3.11. I was saved by being able to run in a Python 3.10 venv and download all the required packages from PyPI. If bookworm shipped without python3.10, I would not have been able to do my work. Removing python3.10 from bookworm will seriously affect many of our users in a similar situation to me. Best wishes, Julian P.S. We should also fix #1036268 if we do keep python3.10 in bookworm; I'm happy to do an NMU if needed.
Bug#958853: Fix
On Wed, Dec 21, 2022 at 07:24:38PM +0100, Dan O'Huiginn wrote: > Upstream has now moved away from Bazel: > https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4b202c08bd740c7bb37763 > > The new build system uses cargo and ninja. It'll still be a substantial job > to package this for Debian, but hopefully more feasible than before. Oh wow, that's good news, thanks! I don't know whether I'll have time to do it before the freeze, though - I am very overloaded at the moment, unfortunately. (And unless something's changed, upstream were using some locally modified Rust crates, which just added to the pain.) Best wishes, Julian
Bug#1026247: Spyder shows a popup message on start: "You have missing dependencies! Mandatory: qdarkstyle"
forcemerge 1024008 1026247 thanks On Sat, Dec 17, 2022 at 07:42:52AM +0100, local10 wrote: > Package: spyder > Version: 5.3.3+dfsg-3 > > > Every time I start Spyder the following popup shows up: > > You have missing dependencies! This is due to the version of spyder in unstable (and testing) currently being uninstallable, primarily due to the impact of the Python 3.11 migration. Hoping to fix in the near future. Best wishes, Julian
Bug#1025000: python-qtawesome: Includes non-source Font Awesome 5
forwarded https://github.com/spyder-ide/qtawesome/issues/220 thanks On Fri, Dec 09, 2022 at 10:15:58AM +0100, Bastian Germann wrote: > Am 09.12.22 um 07:49 schrieb Andrius Merkys: > > I saw you have excluded the files in unreleased 1.2.1+dfsg-1 version of > > the package. Are you planning to upload it soon, or are there any > > blockers? > > It has not built yet because the example.py is run via d/rules: > https://salsa.debian.org/python-team/packages/python-qtawesome/-/jobs/3625869 > > Either we patch it or do not run it. I tried not running it but end up with a > stack trace in that case. > I will investigate on the weekend. I've found out from the Spyder developers that Spyder doesn't use FontAwesome, so it's not a problem to remove it from my perspective. See the GitHub issue noted above. I'm also now looking into the Material Design Icon fonts; see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973617 I also now don't understand why there are two different MDI fonts in this package. But that's a separate issue. Best wishes, Julian
Bug#1025867: src:spyder: unsatisfied build dependency in testing: python3-qdarkstyle (< 3.1~)
Hi Paul, On Sat, Dec 10, 2022 at 10:14:22PM +0100, Paul Gevers wrote: > Source: spyder > Version: 5.3.3+dfsg-3 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: edos-uninstallable > > Dear maintainer(s), > > Dose [1] is reporting a build issue with your package, it's missing a > build dependency. Obviously your build dependencies shouldn't be > removed from testing, but unfortunately there are multiple scenarios > where that can happen nevertheless. To uphold our social contract, > Debian requires that packages can be rebuild from source in the suite > we are shipping them, so currently this is a serious issue with your > package in testing. Yes, something weird happened; I don't know why python3-qdarkstyle was allowed to migrate to testing and break spyder. But anyway, spyder is a complete mess right now because of the python 3.11 transition, and this is the least of the problems :( When I am able to upgrade to spyder 5.4.0, it uses the python3-qdarkstyle currently in testing, so all will be OK again. But it may well be several weeks before that happens. Best wishes, Julian
Bug#1025000: python-qtawesome: Includes non-source Font Awesome 5
Hi Andrius, On Fri, Dec 09, 2022 at 10:59:35AM +0200, Andrius Merkys wrote: > Hi, > [...] > > I got the impression that the removed fonts can be drop-in-replaced with > ones from DFSG-compatible fork from fonts-fork-awesome, but I did not check > that. I am in contact with finalcif upstream and could talk to them, but I > would first try the drop-in replacement approach. I've been looking at this a bit this morning - I don't have more time today, but I think that would be a very sensible thing to do before releasing a DFSG version of this package. If the ForkAwesome fonts can do the job, then great! Best wishes, Julian
Bug#1025000: python-qtawesome: Includes non-source Font Awesome 5
On Fri, Dec 09, 2022 at 07:28:37AM +, Julian Gilbey wrote: > [...] > I also forgot to push my 1.2.1-1 changes to salsa, unfortunately. > Oops! But that's history now. Ah, I never released that version, so please ignore this comment! Salsa is fine. Best wishes, Julian
Bug#1025000: python-qtawesome: Includes non-source Font Awesome 5
On Fri, Dec 09, 2022 at 08:49:10AM +0200, Andrius Merkys wrote: > Hi Bastian, > > On Mon, 28 Nov 2022 16:16:19 +0100 Bastian Germann wrote: > > This package contains three font files > > /usr/share/python-qtawesome/fonts/fontawesome5-*-webfont.ttf > > which are licensed freely but are not built from source and cannot be built > > from source > > (missing build system). #902981 has the details. > > > > Please repack the package to get rid of these files. > > I saw you have excluded the files in unreleased 1.2.1+dfsg-1 version of the > package. Are you planning to upload it soon, or are there any blockers? > > Best, > Andrius Hi all, I have seen this and will deal with it soon. Have you contacted the authors of the package to discuss this issue? I also forgot to push my 1.2.1-1 changes to salsa, unfortunately. Oops! But that's history now. Anyway, a quick check on testing shows that there are three packages depending on python3-qtawesome: finalcif, openlp, python3-spyder. I know about python3-spyder (and it has the same upstream developers as python3-qtawesome), but finalcif and openlp's maintainers might not realise the issue and be surprised when they start getting bug reports about icons missing (or the package failing) - it would be polite to email their maintainers and uploaders before releasing this DFSG version of the package. Best wishes, Julian
Bug#1024008: python3-spyder is not installable
On Mon, Nov 14, 2022 at 04:09:57PM +0200, Adrian Bunk wrote: > On Mon, Nov 14, 2022 at 11:13:14AM +0000, Julian Gilbey wrote: > > I maintain pydevd, so I'll try to look at that soon; someone else will > > have to handle pyzmq. > > pyzmq built on several architectures (including amd64),[1] > so this should not block you. It breaks the spyder-kernels autopkgtests on those architectures where it has not successfully built, and the new spyder depends on the new spyder-kernels, so spyder-kernels and spyder won't be able to migrate until pyzmq is fixed (unless the release team hint it through). Best wishes, Julian
Bug#1024008: python3-spyder is not installable
Dear Adrian, On Sun, Nov 13, 2022 at 08:28:27PM +0200, Adrian Bunk wrote: > Package: python3-spyder > Version: 5.3.3+dfsg-3 > Severity: serious > > The following packages have unmet dependencies: > python3-spyder : Depends: python3-pylsp (< 1.6~) but 1.6.0-1 is to be > installed > Depends: python3-qtconsole (< 5.4~) but 5.4.0-1 is to be > installed Thanks for this report; I am already aware of this issue. Spyder is unfortunately now caught up in the python3.11-add transition. There are two packages causing problems which will have to be resolved first before this can be fixed: * pyzmq - this is not successfully building for Python 3.11 * pydevd - likewise I maintain pydevd, so I'll try to look at that soon; someone else will have to handle pyzmq. Once pyzmq has successfully built for unstable, I'll be able to upload spyder-kernels 2.4.0-1 and spyder 5.4.0-1, which will fix these dependencies. Best wishes, Julian
Bug#1022188: debugpy: FTBFS due to either "Timed out..." or "Address already in use"
Hi Sergio, On Mon, Nov 07, 2022 at 01:44:41PM +, Julian Gilbey wrote: > Hi Sergio, > > On Fri, Oct 21, 2022 at 01:43:10PM -0400, Sergio Durigan Junior wrote: > > Source: debugpy > > Version: 1.6.3+ds-1 > > Severity: serious > > > > Hi, > > > > debugpy is currently FTBFSing: > > [...] I've uploaded a new version of debugpy, which I hope addresses this issue. I've closed the bug report, but if you still find it happens with version 1.6.3+git20221103.a2a3328+ds-1, please reopen it and send me a link to a log file of a broken run! Best wishes, Julian
Bug#1022188: debugpy: FTBFS due to either "Timed out..." or "Address already in use"
Hi Sergio, On Fri, Oct 21, 2022 at 01:43:10PM -0400, Sergio Durigan Junior wrote: > Source: debugpy > Version: 1.6.3+ds-1 > Severity: serious > > Hi, > > debugpy is currently FTBFSing: > [...] > > The long summary is too big to post here, but you can see the full log > at: > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/debugpy.html > [...] > I found a few upstream bugs that contain either the "Timed out waiting > for debug server to connect" or the "Address already in use" messages, > but I haven't investigated further TBH. Sorry for the slow reply. That's interesting, because it built fine on the buildd network and using lxc. If it's "address already in use", it's probably because there are timing issues: it's running the tests on multiple CPUs and if it tries to spin up local servers on two CPUs almost simultaneously, they might end up trying to use the same port. I saw this same issue with pydevd, and worked around it by restricting it to using a single CPU; maybe I should do the same here. If it's "timed out", I'm not sure what the cause is; might it possibly be that pbuilder does not allow servers to start on local ports or for the build to connect to local ports? I had to work around this in pydevd's debian/rules, but it didn't seem to be a problem with debugpy. Maybe it is. Ho hum, something to investigate! Best wishes, Julian
Bug#1019965: pydevd: FTBFS in sid (failed tests)
severity 1019965 normal thanks On Mon, Sep 19, 2022 at 04:01:31PM +0100, Julian Gilbey wrote: > On Sat, Sep 17, 2022 at 02:41:29PM +0200, Gianfranco Costamagna wrote: > > Source: pydevd > > Version: 2.8.0+git20220826.8ee4065+ds-1 > > Severity: serious > > > > Hello, please have a look at the build log, some tests are now failing. > > > > Can also be seed in Debian CI > > > > https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/pydevd.html > > > > Thanks for having a look. > > Hi Gianfranco, > > That's weird, as it built OK just two weeks ago. Upstream's tests > succeed on this test, which is a little weird, so it might be a > version thing. I'll report it upstream. > > Best wishes, > >Julian OK, it's transient: I reran it on both my machine and on ci.debian.net and it passed without difficulty. So I'm going to downgrade this bug report and just keep an eye on it. If it recurs, I'll report it and separate out this test (or perhaps just skip it). Best wishes, Julian
Bug#1019965: pydevd: FTBFS in sid (failed tests)
On Sat, Sep 17, 2022 at 02:41:29PM +0200, Gianfranco Costamagna wrote: > Source: pydevd > Version: 2.8.0+git20220826.8ee4065+ds-1 > Severity: serious > > Hello, please have a look at the build log, some tests are now failing. > > Can also be seed in Debian CI > > https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/pydevd.html > > Thanks for having a look. Hi Gianfranco, That's weird, as it built OK just two weeks ago. Upstream's tests succeed on this test, which is a little weird, so it might be a version thing. I'll report it upstream. Best wishes, Julian
Bug#1016511: marked as pending in pydevd
Control: tag -1 pending Hello, Bug #1016511 in pydevd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pydevd/-/commit/8b002a564a405816e342761ef4642dab01d92695 Add Breaks+Replaces python3-omegaconf (Closes: #1016511) (this message was generated automatically) -- Greetings https://bugs.debian.org/1016511
Bug#1016511: python3-pydevd: missing Breaks+Replaces: python3-omegaconf (<< ???)
On Tue, Aug 02, 2022 at 07:41:51AM +0200, Andreas Beckmann wrote: > Package: python3-pydevd > Version: 2.8.0+git20220714.32dee0b+dfsg-2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > Control: block -1 with 1016510 > > Hi, > > during a test with piuparts I noticed your package failed to install > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > [...] > python3-omegaconf still needs to drop the conflicting files (#1016510), > so my guess would be that you need to add > > Breaks+Replaces: python3-omegaconf (<< 2.1.0~rc1-4~) Thanks Andreas! I had no idea any other packages were using the pydevd namespace - I hadn't even thought to check. Thomas has now fixed python3-omegaconf (thanks Thomas!), so the new version of pydevd that I'm just building and uploading should solve this one. Best wishes, Julian
Bug#958853: Fix
On Fri, Jul 29, 2022 at 06:22:00PM -0700, Drew Stephens wrote: > I managed to get 2.1.15 from the package working for now for putting > int(round()) around numbers in preferences.py and deckconf.py when they were > returning the unexpected float type error. For some reason, even though it > says the package is removed from testing, I am still able to install the > package from the repositories. > > I'm on Bookworm amd64 Hi Drew, That sounds like a good fix, thanks. The anki package is no longer in testing but it is in unstable. I don't know what your apt setup is (you could look at /etc/apt/sources.list and the like), so you might be picking it up from the unstable distribution. Alternatively, if you haven't updated your sources in a while, you might still have an old copy of the package index still referring to anki. The main Debian archive does not distinguish between different distributions (stable/testing/unstable), so you would still be able to find this package. Meanwhile, I still do not think it is in the best interests of Debian's users to allow a version of anki that is over 2 years old into stable, as it will then be over 4 years old by the time the next stable arrives; by then, upstream's servers might be incompatible with version 2.1.15. It's an unfortunate situation, but one I am not in a position to fix. Best wishes, Julian
Bug#1015744: python3-matplotlib: version 3.5.2-2 is breaking spyder autopkgtests
On Thu, Jul 21, 2022 at 05:57:58PM -0400, Sandro Tosi wrote: > same as #1015745 > > It's not scipy, it's the python3-defaults transition. python3.9 is > being dropped as a supported python version. Ah, thanks! Sorry for the noise. Julian
Bug#1015744: python3-matplotlib: version 3.5.2-2 is breaking spyder autopkgtests
Package: python3-matplotlib Version: 3.5.2-2 Severity: serious Something significant seems to have changed in version 3.5.2-2 of this package, as it now breaks the spyder 5.3.1+dfsg-1 autopkgtests: see https://ci.debian.net/packages/s/spyder/testing/amd64/ The tests passed with version 1.8.1-6. The relevant lines of the log file are: _ ERROR collecting spyder/app/tests/test_mainwindow.py _ ImportError while importing test module '/tmp/autopkgtest-lxc.lani2ms0/downtmp/build.v6H/src/spyder/app/tests/test_mainwindow.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: /usr/lib/python3/dist-packages/_pytest/python.py:608: in _importtestmodule mod = import_path(self.path, mode=importmode, root=self.config.rootpath) /usr/lib/python3/dist-packages/_pytest/pathlib.py:533: in import_path importlib.import_module(module_name) /usr/lib/python3.9/importlib/__init__.py:127: in import_module return _bootstrap._gcd_import(name[level:], package, level) :1030: in _gcd_import ??? :1007: in _find_and_load ??? :986: in _find_and_load_unlocked ??? :680: in _load_unlocked ??? /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:168: in exec_module exec(co, module.__dict__) spyder/app/tests/test_mainwindow.py:32: in from matplotlib.testing.compare import compare_images /usr/lib/python3/dist-packages/matplotlib/__init__.py:109: in from . import _api, _version, cbook, docstring, rcsetup /usr/lib/python3/dist-packages/matplotlib/cbook/__init__.py:31: in from matplotlib import _api, _c_internal_utils E ImportError: cannot import name '_c_internal_utils' from partially initialized module 'matplotlib' (most likely due to a circular import) (/usr/lib/python3/dist-packages/matplotlib/__init__.py) The same seems to have happened to scipy in version 1.8.1-7, in case that helps. Best wishes, Julian
Bug#1015745: python3-scipy: version 1.8.1-7 is breaking spyder autopkgtests
Package: python3-scipy Version: 1.8.1-7 Severity: serious Something significant seems to have changed in version 1.8.1-7 of this package, as it now breaks the spyder 5.3.1+dfsg-1 autopkgtests: see https://ci.debian.net/packages/s/spyder/testing/amd64/ The tests passed with version 1.8.1-6. The relevant lines of the log file are: _ ERROR collecting spyder/plugins/variableexplorer/widgets/tests/test_arrayeditor.py _ ImportError while importing test module '/tmp/autopkgtest-lxc._c2d6g21/downtmp/build.YmB/src/spyder/plugins/variableexplorer/widgets/tests/test_arrayeditor.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: /usr/lib/python3/dist-packages/_pytest/python.py:608: in _importtestmodule mod = import_path(self.path, mode=importmode, root=self.config.rootpath) /usr/lib/python3/dist-packages/_pytest/pathlib.py:533: in import_path importlib.import_module(module_name) /usr/lib/python3.9/importlib/__init__.py:127: in import_module return _bootstrap._gcd_import(name[level:], package, level) :1030: in _gcd_import ??? :1007: in _find_and_load ??? :986: in _find_and_load_unlocked ??? :680: in _load_unlocked ??? /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:168: in exec_module exec(co, module.__dict__) spyder/plugins/variableexplorer/widgets/tests/test_arrayeditor.py:24: in from scipy.io import loadmat /usr/lib/python3/dist-packages/scipy/__init__.py:153: in from scipy._lib._ccallback import LowLevelCallable /usr/lib/python3/dist-packages/scipy/_lib/_ccallback.py:1: in from . import _ccallback_c E ImportError: cannot import name '_ccallback_c' from 'scipy._lib' (/usr/lib/python3/dist-packages/scipy/_lib/__init__.py) The same seems to have happened to matplotlib in version 3.5.2-2, in case that helps. Best wishes, Julian
Bug#1014844: python-lsp-server: breaks spyder 5.3.1 and needs to be held until spyder 5.3.2 is released
Source: python-lsp-server Version: 1.5.0-1 Severity: serious This package is incompatible with the currently released version of spyder (5.3.1). As explained by upstream in https://github.com/spyder-ide/spyder/issues/17550#issuecomment-1079828357 the releases of PyLSP and Spyder are performed by the same team and are therefore coordinated. A new major or minor release of PyLSP is usually performed a week or two before Spyder is released, but Spyder will break in various ways if the wrong version of PyLSP is used. The Debian unstable version of Spyder has been patched to use the newer PyLSP version, but various failing tests had to be ignored to do so; these failing tests indicate that Spyder 5.3.1 does not work correctly with python-lsp-server 1.5.0-1. The soon-to-be-released Spyder 5.3.2 or 5.4.0 will work correctly. I will close this bug report when the new version of Spyder has been released and uploaded to unstable. Best wishes, Julian
Bug#1014489: deepdiff: autopkgtest failing due to missing dependencies
Source: deepdiff Version: 5.8.2-2 Severity: serious The recent patch to add python3-toml and python3-clevercsv to the Build-Depends forgot to add the same dependencies to the autopkgtest dependencies. As a result, the autopkgtests are now failing and this package is preventing the migration of pytest to testing. Best wishes, Julian
Bug#1013700: marked as pending in python-qtpy
Control: tag -1 pending Hello, Bug #1013700 in python-qtpy reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-qtpy/-/commit/e7d0236cc1a1e1718a05ed4a09a7dd24fca6b723 Fix FTBFS error with Pytest 7.x (closes: #1013700) (this message was generated automatically) -- Greetings https://bugs.debian.org/1013700
Bug#1013700: Strangely rare pytest 7.x bug report
Hi Carles,
It is utterly, utterly bizarre. But I think I've found the problem.
There's a pytest.ini file in the package, but it's not copied into the
test directory. So when pytest is run in the .pybuild directory, it
climbs all the way back up the directory tree to the python-qtpy-2.1.0
until it discovers the pytest.ini file there and uses that. It sees
that we are requesting qtpy/tests, which it then expands into the
directory path .pybuild/cpython3_3.10_qtpy/build/qtpy/tests, starting
from the directory in which it found pytest.ini, and this causes the
breakage.
The solution is to copy the pytest.ini file into the .pybuild
directories by adding it to debian/pybuild.testfiles
Why this behaviour changed between pytest 6.x and pytest 7.x I don't
know; I don't see it obviously documented. But that at least resolves
this problem.
Thanks for your help!
Best wishes,
Julian
On Mon, Jul 04, 2022 at 08:39:32PM +0100, Carles Pina i Estany wrote:
>
> Hi Julian,
>
> On Jul/04/2022, Julian Gilbey wrote:
> > Hi Carles,
> >
> > Thanks for your thoughts! Yes, indeed that seems to be the issue.
> > But what I don't understand is why the import is turned into
> > .pybuild.cpython3_3.9_qtpy.build.qtpy.tests and not just qtpy.tests or
>
> I see how pytest does it (but keep reading)
>
> > a longer path, and why only this package fails in this way. Perhaps
> > this is the only package that has an import statement in
> > pytest_configure?
>
> This I don't know and I'm curious, and it might help disecting the issue
> (or understanding it). Do you know of any other python3 package that you
> expected to fail? (using pytest in a similar way).
>
> I might try to get both and follow what they do different (to hopefully
> know what is python-qtpy doing different :-) )
>
> I'm sure that there are tons of packages that use pytest :-) I'm
> wondering if you had a good candidate.
>
> Best regards,
>
> >
> > Best wishes,
> >
> >Julian
> >
> > On Mon, Jul 04, 2022 at 04:03:39PM +0100, Carles Pina i Estany wrote:
> > >
> > > Hi,
> > >
> > > I'm a lurker of debian-pyt...@lists.debian.org but seeing Python+Qt I
> > > wanted to have a look. I don't have a solution (I might look more
> > > another time if time permits) but I might have something that might help
> > > someone who knows the tools better.
> > >
> > > I am not familiar with Python Debian packaging details/tools neither
> > > with pytest :-( so take all of this with a pinch of salt.
> > >
> > > If it helps the error comes from:
> > > /usr/lib/python3.9/importlib/__init__.py in the functin "import_modules"
> > > it does:
> > > """
> > > if name.startswith('.'):
> > > if not package:
> > > msg = ("the 'package' argument is required to perform a
> > > relative "
> > >"import for {!r}")
> > > raise TypeError(msg.format(name))
> > > """
> > >
> > > When the import fails the "name" parameter of "import_modules" function
> > > is: '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests' , which is derived
> > > from the hidden dirctory ".pybuild" as created by default by "pybuild".
> > >
> > > I think that the initial "." is used only as a directory name but Python
> > > assumes that is a relative import requiring the package parameter.
> > >
> > > Just to check my thoughts, and after running dpkg-buildpackage and
> > > failing let's try again:
> > >
> > > $ cd .pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ;
> > > cd -
> > > Fails with the:
> > >
> > > TypeError: the 'package' argument is required to perform a relative
> > > import for '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests'
> > > /home/carles/git/python-qtpy
> > >
> > > Then let's try to avoid the initial "." confusion:
> > >
> > > $ mv .pybuild pybuild
> > > $ cd pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; cd
> > > -
> > >
> > > It works.
> > >
> > > I don't know why this is the only package affected by this though...
> > >
> > > Hopefully it helps a bit!
> > >
> > > On Jul/04/2022, Julian Gilbey wrote:
> > > > Dear all,
> > > >
> > > > I wonder whether you might have any clue about
> > > > https://bugs.
Bug#1013700: Strangely rare pytest 7.x bug report
Hi Carles,
Thanks for your thoughts! Yes, indeed that seems to be the issue.
But what I don't understand is why the import is turned into
.pybuild.cpython3_3.9_qtpy.build.qtpy.tests and not just qtpy.tests or
a longer path, and why only this package fails in this way. Perhaps
this is the only package that has an import statement in
pytest_configure?
Best wishes,
Julian
On Mon, Jul 04, 2022 at 04:03:39PM +0100, Carles Pina i Estany wrote:
>
> Hi,
>
> I'm a lurker of debian-pyt...@lists.debian.org but seeing Python+Qt I
> wanted to have a look. I don't have a solution (I might look more
> another time if time permits) but I might have something that might help
> someone who knows the tools better.
>
> I am not familiar with Python Debian packaging details/tools neither
> with pytest :-( so take all of this with a pinch of salt.
>
> If it helps the error comes from:
> /usr/lib/python3.9/importlib/__init__.py in the functin "import_modules"
> it does:
> """
> if name.startswith('.'):
> if not package:
> msg = ("the 'package' argument is required to perform a relative "
>"import for {!r}")
> raise TypeError(msg.format(name))
> """
>
> When the import fails the "name" parameter of "import_modules" function
> is: '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests' , which is derived
> from the hidden dirctory ".pybuild" as created by default by "pybuild".
>
> I think that the initial "." is used only as a directory name but Python
> assumes that is a relative import requiring the package parameter.
>
> Just to check my thoughts, and after running dpkg-buildpackage and
> failing let's try again:
>
> $ cd .pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; cd -
> Fails with the:
>
> TypeError: the 'package' argument is required to perform a relative import
> for '.pybuild.cpython3_3.9_qtpy.build.qtpy.tests'
> /home/carles/git/python-qtpy
>
> Then let's try to avoid the initial "." confusion:
>
> $ mv .pybuild pybuild
> $ cd pybuild/cpython3_3.9_qtpy/build; python3.9 -m pytest qtpy/tests ; cd -
>
> It works.
>
> I don't know why this is the only package affected by this though...
>
> Hopefully it helps a bit!
>
> On Jul/04/2022, Julian Gilbey wrote:
> > Dear all,
> >
> > I wonder whether you might have any clue about
> > https://bugs.debian.org/1013700
> > I have mostly worked out the "cause" of the bug, but I haven't quite
> > got to the bottom of it.
> >
> > When running the command
> > PYTHONPATH=. python3.10 -m pytest qtpy/tests
> > in the directory .pybuild/cpython3_3.10_qtpy/build, I get the error
> > message:
> >
> > ImportError while loading conftest
> > '/home/jdg/debian/spyder-packages/qtpy/build-area/python-qtpy-2.1.0/.pybuild/cpython3_3.10_qtpy/build/qtpy/tests/conftest.py'.
> > TypeError: the 'package' argument is required to perform a relative import
> > for '.pybuild.cpython3_3.10_qtpy.build.qtpy.tests'
> >
> > If the directory .pybuild is renamed to pybuild, the tests run without
> > a problem. So there seems to be something funny about conftest.py
> > (and removing all of the other files from the qtpy/tests directory
> > except for the empty __init__.py gives the same error); here's a link
> > to it:
> >
> > https://salsa.debian.org/python-team/packages/python-qtpy/-/blob/master/qtpy/tests/conftest.py
> >
> > But there doesn't seem to be anything out of the ordinary about this.
> > So I am mystified: why does pytest 7.x seem to not give this error on
> > any other Debian package?
> >
> > The only solution I currently have for this package is skip the tests
> > at build time and rely on autopkgtest to do them.
> >
> > Best wishes,
> >
> >Julian
Bug#1013700: Strangely rare pytest 7.x bug report
Dear all, I wonder whether you might have any clue about https://bugs.debian.org/1013700 I have mostly worked out the "cause" of the bug, but I haven't quite got to the bottom of it. When running the command PYTHONPATH=. python3.10 -m pytest qtpy/tests in the directory .pybuild/cpython3_3.10_qtpy/build, I get the error message: ImportError while loading conftest '/home/jdg/debian/spyder-packages/qtpy/build-area/python-qtpy-2.1.0/.pybuild/cpython3_3.10_qtpy/build/qtpy/tests/conftest.py'. TypeError: the 'package' argument is required to perform a relative import for '.pybuild.cpython3_3.10_qtpy.build.qtpy.tests' If the directory .pybuild is renamed to pybuild, the tests run without a problem. So there seems to be something funny about conftest.py (and removing all of the other files from the qtpy/tests directory except for the empty __init__.py gives the same error); here's a link to it: https://salsa.debian.org/python-team/packages/python-qtpy/-/blob/master/qtpy/tests/conftest.py But there doesn't seem to be anything out of the ordinary about this. So I am mystified: why does pytest 7.x seem to not give this error on any other Debian package? The only solution I currently have for this package is skip the tests at build time and rely on autopkgtest to do them. Best wishes, Julian
Bug#1012793: libpyside2-py3-5.15 uninstallable on unstable: unsatisfiable Depends
On Tue, Jun 14, 2022 at 10:43:34AM +0300, Dmitry Shachnev wrote: > Hi Julian! > > On Tue, Jun 14, 2022 at 08:37:38AM +0100, Julian Gilbey wrote: > > Package: libpyside2-py3-5.15 > > Version: 5.15.2-2.1 > > Severity: serious > > > > This package depends on qtbase-abi-5-15-2 and > > qtdeclarative-abi-5-15-2, but libqt5core5a now Provides: > > qtbase-abi-5-15-4 and libqt5qml5 now Provides: > > qtdeclarative-abi-5-15-4. The dependencies of this package need > > updating to bring them into sync. > > We are now in a middle of Qt 5.15.4 transition [1][2]. Wait a couple of days, > pyside2 will be rebuilt by the Release team. > > [1]: https://release.debian.org/transitions/html/qtbase-abi-5-15-4.html > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007170 Hi Dmitry, Amazing, thanks! Julian
Bug#1012793: libpyside2-py3-5.15 uninstallable on unstable: unsatisfiable Depends
Package: libpyside2-py3-5.15 Version: 5.15.2-2.1 Severity: serious This package depends on qtbase-abi-5-15-2 and qtdeclarative-abi-5-15-2, but libqt5core5a now Provides: qtbase-abi-5-15-4 and libqt5qml5 now Provides: qtdeclarative-abi-5-15-4. The dependencies of this package need updating to bring them into sync. Best wishes, Julian
Bug#1012188: python3-poppler-qt5: puts files in /usr/lib/python3.10/site-packages
Package: python3-poppler-qt5 Version: 0.75.0-3+b1 Severity: serious This packages installs the file /usr/lib/python3.10/site-packages/python_poppler_qt5-0.75.0.dist-info/RECORD which is a violation of the Python Policy: Public Python 3 modules must be installed in the system Python 3 modules directory, /usr/lib/python3/dist-packages. The rest of the package (including the RECORD file) are already installed in the correct location, so I don't know why this file ends up in the wrong place. Best wishes, Julian
Bug#1011152: spyder: Console not starting. Spyder alerts : iPython 7.31.1 & qtconsole 5.3.0 not installed. But they are !
It's a pleasure! We cannot write instructions to cover every eventually; that is effectively impossible. But it seems like you did the right thing to sort out your problem, which I am pleased to hear. Best wishes, Julian On Tue, May 17, 2022 at 07:42:37PM +0200, epsommum...@virgilio.it wrote: > Thank you very much ! > > Your command did not work in Spyder's console on the desktop, first because of > the 3 at the end of pip, then because pressing the Y key at the prompt did not > do anything. After googling how to force uninstall I found the command that > worked for the desktop : > > pip uninstall iPython -y > > (I did not have a local qtconsole package installed) > > In qemu, I typed this in a regular console since no console worked in Spyder : > > python3 -m pip uninstall qtconsole iPython > > Here the prompts accepted my Y presses. > > I then had to do (probably because I closed spyder while it was reporting the > error messages for a github bug report) : > > killall spyder > > Then Spyder started successfully ! > > Too bad your instructions are not included in Spyder's error messages to > explain > to people like me who are not pros what to do to solve such a simple problem ! > > Anyway, thank you again ! > > P.S. : the mail bounced because this mail address I use for bug reports had > not > been used for too long, and I had to renew the password.
Bug#1011152: spyder: Console not starting. Spyder alerts : iPython 7.31.1 & qtconsole 5.3.0 not installed. But they are !
Dear RB68, On Tue, May 17, 2022 at 04:54:19PM +0200, RB68 wrote: > Package: spyder > Version: 5.3.0+dfsg1-7 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: epsommum...@virgilio.it > > Dear Maintainer, > > I upgraded Spyder 4.2.1 to 5.3 both on my main desktop PC and in a qemu > client. > In both cases I encountered a problem. > > The console would not start in the qemu client, Spyder alerting that iPython > 7.31.1 & qtconsole 5.3.0 are not installed, even though they are ! After a > reboot I still faced the same problem. Thanks for this report. This is strange... > [...] > > Here are the error messages from Spyder : > > # Mandatory: > IPython >=7.31.1 : 7.28.0 (NOK) > qtconsole >=5.3.0;<5.4.0 : 5.1.1 (NOK) This says that the versions of ipython and qtconsole that spyder has loaded are versions 7.28.0 and 5.1.1 respectively. > Traceback (most recent call last): > File "/home/horses/.local/lib/python3.9/site- > packages/qtconsole/base_frontend_mixin.py", line 138, in _dispatch > handler(msg) And I think we have the problem: you have locally installed versions of several of the required Python packages (presumably using "pip3 install --user", and these are loaded in preference to the system versions. Have a look at the directory ~/.local/lib/python3.9/site-packages to see what's locally installed, and uninstall all of the packages that have newer versions on the system. For example: pip3 uninstall qtconsole iPython I assume that doing this will resolve the problem. If not, please let me know. Best wishes, Julian
Bug#1009836: python3-pylsp-flake8: give upstream source in the d/copyright file
Package: python3-pylsp-flake8 Version: 0.4.0-2 Severity: serious The debian/copyright file for this package currently does not state the location of the upstream sources. (Marked "serious" because this is a violation of Policy section 12.5.) I'm happy to fix this myself if you would like me to. Best wishes, Julian
Bug#1005640: fonttools: Missing dependency python3-unicodedata2 (ITP needed)
On Sun, Feb 13, 2022 at 05:15:16PM +0800, Yao Wei wrote: > Package: fonttools > Version: 4.29.1-1 > Severity: serious > Justification: Policy 3.5 > X-Debbugs-Cc: debian-fo...@lists.debian.org > Control: block 1005477 by -1 > Control: block 1005474 by -1 > > This package has missing dependency of python package name > "unicodedata2" since version 4.29.1-1, according to the FTBFS messages > from #1005474 and #1005477. > > NEW python package for unicodedata2 is needed. An alternative is to patch setup.py and requirements.txt to remove the dependency, as the Python code itself will fall back to the standard library unicodedata if unicodedata2 cannot be found. The tables will not be as up-to-date, but otherwise everything will work. Best wishes, Julian
Bug#1004855: python3-ipykernel: missing dependency on debugpy
On Wed, Feb 02, 2022 at 01:33:30PM +, Gordon Ball wrote: > ps, I had a search just now and it looks like someone else was working > 1 year ago on `ptvsd` (renamed `debugpy` later), but it doesn't look > like it was ever uploaded. But perhaps something to build upon. > > https://salsa.debian.org/python-team/packages/ptvsd > https://salsa.debian.org/python-team/packages/pydevd Ooh, debugpy is complicated, as you say. I think it's worth discussing how to handle this vendored pydevd on d-python. Best wishes, Julian
Bug#1004855: python3-ipykernel: missing dependency on debugpy
On Wed, Feb 02, 2022 at 01:33:30PM +, Gordon Ball wrote: > On Wed, Feb 02, 2022 at 11:35:19AM +0000, Julian Gilbey wrote: > > Package: python3-ipykernel > > Version: 6.7.0-1 > > Severity: serious > > X-Debbugs-Cc: Julien Puydt , Gordon Ball > > > > > ps, I had a search just now and it looks like someone else was working > 1 year ago on `ptvsd` (renamed `debugpy` later), but it doesn't look > like it was ever uploaded. But perhaps something to build upon. > > https://salsa.debian.org/python-team/packages/ptvsd > https://salsa.debian.org/python-team/packages/pydevd > > pps, I disagree that this qualifies for `severity=serious`. I don't > think there is either a policy violation or the package is unusable for > most users. I propose to change this to `severity=important`. Thanks, and I have no objections to changing the severity; I was quite unsure what to label this one. Best wishes, Julian
Bug#1004855: python3-ipykernel: missing dependency on debugpy
On Wed, Feb 02, 2022 at 01:06:56PM +, Gordon Ball wrote: > On Wed, Feb 02, 2022 at 11:35:19AM +0000, Julian Gilbey wrote: > > Package: python3-ipykernel > > Version: 6.7.0-1 > > Severity: serious > > X-Debbugs-Cc: Julien Puydt , Gordon Ball > > > > > > ipykernel depends on the debugpy package, as stated in setup.py. > > However, within Debian build, python3-debugpy is not listed in the > > Build-Depends, so the resulting binary package does not Depend(s) on > > it either. The ipykernel test suite passes because the debugger test > > is skipped if debugpy is not installed, but Spyder behaves badly in > > its absence. > > Yes, sorry. This is a known, but admittedly not documented, limitation > of the current package. As far as I could tell debugpy was effectively > treated as an optional feature (all imports seem to be protected with > try-catch, etc), despite being listed as install_requires. Ah, OK, I hadn't realised this. > > Furthermore, there is no python3-debugpy package yet in Debian. I am > > happy to do an ITP and upload this package to NEW if that would help. > > I looked briefly into packaging debugpy and I think it's probably doable > but looks like a reasonable amount of work (embedded vendored stuff, > cython). I don't have time to take that on at the moment, but I'd be > very happy if you're willing to. Oh, that's a pain. But I'll give it a go, as Spyder really does expect it. Best wishes, Julian
Bug#1004855: python3-ipykernel: missing dependency on debugpy
Package: python3-ipykernel Version: 6.7.0-1 Severity: serious X-Debbugs-Cc: Julien Puydt , Gordon Ball ipykernel depends on the debugpy package, as stated in setup.py. However, within Debian build, python3-debugpy is not listed in the Build-Depends, so the resulting binary package does not Depend(s) on it either. The ipykernel test suite passes because the debugger test is skipped if debugpy is not installed, but Spyder behaves badly in its absence. Furthermore, there is no python3-debugpy package yet in Debian. I am happy to do an ITP and upload this package to NEW if that would help. Best wishes, Julian
