Bug#1032902: Numba issues for genx for other architectures than amd64 and ppc64el (Was: genx won't start: TypeError: Pen(): arguments did not match any overloaded call)
On Tue, Apr 18, 2023 at 03:54:23PM +0200, Andreas Tille wrote: > and we have other errors for other architectures which all contain > the string "numba". IMHO this is a mess we can hardly fix in hard > freeze. I see only two chances: I haven't done a thorough research but it is probably originating from numba itself. >1. Restrict the architectures to amd64 and ppc64el (which are > the only ones where the build succeeds or We maybe a little too late for this as well. >2. Remove the package from testing for the moment. The only > rdepends is currently pan-grazing-incidence which will be > lowered to suggests once we re-render debian-pan metapackages. It is a possible option but it maybe a useful package in itself. This numba situation has arised due to uploading a new upstream update of genx during hard freeze (I wonder why this happened). I think we do have a third alternative: > What do you think? 3. Cherry-pick the commit[6] for fixing this bug and upload to t-p-u by asking release team first, or go ahead with a +really scheme whichever seems better, but it needs to be done quickly. > [1] > https://udd.debian.org/bugs/?release=bookworm_and_sid&merged=ign&done=only&rc=1&flastmod=ign&flastmodval=5&sortby=last_modified&sorto=asc&ctags=1&cdeferred=1&caffected=1&cautormtime=1&cmissingbuilds=1&#results > [2] https://buildd.debian.org/status/package.php?p=genx&suite=sid > [3] > https://buildd.debian.org/status/fetch.php?pkg=genx&arch=arm64&ver=3.6.21-1&stamp=1681143066&raw=0 > [4] > https://buildd.debian.org/status/fetch.php?pkg=genx&arch=armel&ver=3.6.21-1&stamp=1681142381&raw=0 > [5] > https://buildd.debian.org/status/fetch.php?pkg=genx&arch=i386&ver=3.6.21-1&stamp=1681142358&raw=0 [6] https://sourceforge.net/p/genx/git/ci/221e3207b045e7d3a59de1876a675ce017312d9c -- Best, Nilesh signature.asc Description: PGP signature
Bug#1032902: Numba issues for genx for other architectures than amd64 and ppc64el (Was: genx won't start: TypeError: Pen(): arguments did not match any overloaded call)
On Sat, Apr 29, 2023 at 07:44:24PM +0530, Nilesh Patra wrote: > On Tue, Apr 18, 2023 at 03:54:23PM +0200, Andreas Tille wrote: > >2. Remove the package from testing for the moment. The only > > rdepends is currently pan-grazing-incidence which will be > > lowered to suggests once we re-render debian-pan metapackages. > > It is a possible option but it maybe a useful package in itself. > This numba situation has arised due to uploading a new upstream update > of genx during hard freeze (I wonder why this happened). I guess I understand the reason for this: > I think we do have a third alternative: > > > What do you think? > > 3. Cherry-pick the commit[6] for fixing this bug and upload to t-p-u by > asking release team first, or go ahead with a +really scheme whichever > seems better, but it needs to be done quickly. I guess I ended up under-estimating the fix. Even after applying heaps of patches, genx is rendering broken for me, in the sense that the GUI is up but I am observing some concerning warnings/errors in the logs, which means that I need to pick more and more commits to the point that the delta becomes huge for existing package. It probably _genuinely_ needs a new version that Roland uploaded, which had major rework and has fixes for many bugs. I think it is better out of bookworm at the moment. My 2 cents. > > [1] > > https://udd.debian.org/bugs/?release=bookworm_and_sid&merged=ign&done=only&rc=1&flastmod=ign&flastmodval=5&sortby=last_modified&sorto=asc&ctags=1&cdeferred=1&caffected=1&cautormtime=1&cmissingbuilds=1&#results > > [2] https://buildd.debian.org/status/package.php?p=genx&suite=sid > > [3] > > https://buildd.debian.org/status/fetch.php?pkg=genx&arch=arm64&ver=3.6.21-1&stamp=1681143066&raw=0 > > [4] > > https://buildd.debian.org/status/fetch.php?pkg=genx&arch=armel&ver=3.6.21-1&stamp=1681142381&raw=0 > > [5] > > https://buildd.debian.org/status/fetch.php?pkg=genx&arch=i386&ver=3.6.21-1&stamp=1681142358&raw=0 > [6] > https://sourceforge.net/p/genx/git/ci/221e3207b045e7d3a59de1876a675ce017312d9c -- Best, Nilesh signature.asc Description: PGP signature
Bug#918774: fixed in lasi 1.1.3-1
On Thu, 27 Apr 2023 00:37:06 +0530 Nilesh Patra wrote: > On Sun, 23 Apr 2023 06:18:58 + Debian FTP Masters > wrote: > > Source: lasi > > Source-Version: 1.1.3-1 > > Done: Nilesh Patra > > Sending BTS mail to help reset the autorm counter. Another mail to reset the counter again. It needs a week more to get through. Nilesh
Bug#1035629: libnlopt-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Hi Andreas On Sat, 06 May 2023 23:19:13 +0200 Andreas Beckmann wrote: Package: libnlopt-dev Version: 2.7.1-4 Severity: serious /usr/share/doc/libnlopt-dev/examples/CMakeLists.txt (libnlopt-dev:amd64) != /usr/share/doc/libnlopt0/examples/CMakeLists.txt (?) /usr/share/doc/libnlopt-dev -> libnlopt0 /usr/share/doc/libnlopt-dev/examples/box.c (libnlopt-dev:amd64) != /usr/share/doc/libnlopt0/examples/box.c (?) /usr/share/doc/libnlopt-dev -> libnlopt0 /usr/share/doc/libnlopt-dev/examples/lorentzfit.c (libnlopt-dev:amd64) != /usr/share/doc/libnlopt0/examples/lorentzfit.c (?) /usr/share/doc/libnlopt-dev -> libnlopt0 /usr/share/doc/libnlopt-dev/examples/myconstraint.m (libnlopt-dev:amd64) != /usr/share/doc/libnlopt0/examples/myconstraint.m (?) /usr/share/doc/libnlopt-dev -> libnlopt0 I am a little confused with this output, and I'd appreciate if you could explain this a little. I do not see "/usr/share/doc/libnlopt0/examples" anywhere in bullseye see[1] - not even as a symlink. Manually installing the bullseye version and then trying to upgrade to the version in bookworm went without any issues for me. The only symlinks that exist in the package are in the nlopt-doc package which do not touch the examples dir or changelog dir. Could you help explain where exactly the overwriting is happening? [1]: https://packages.debian.org/bullseye/amd64/libnlopt0/filelist Thanks Nilesh
Bug#1035629: libnlopt-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Hi Thanks for explaining it to me. On 14/05/23 14:08, Andreas Beckmann wrote: On 14/05/2023 10.22, Nilesh Patra wrote: Could you help explain where exactly the overwriting is happening? In bullseye libnlopt-dev ships /usr/share/doc/libnlopt-dev as a symlink to libnlopt0 dpkg retains this symlink on upgrades to bookworm In bookworm libnlopt-dev ships /usr/share/doc/libnlopt-dev as a directory I've fixed it with a symlink_to_dir ... libnlopt-dev ships /usr/share/doc/libnlopt-dev/examples/*, too, which ends up as /usr/share/doc/libnlopt0/examples/*, but these could already be files owned by another package. And added a preinst to remove examples/ from libnlopt0, as it really should not be there. Best Nilesh
Bug#1033835: polyml: autopkgtest regression: output on stderr
Hi Jessica, On Sun, 2 Apr 2023 15:22:49 +0200 Paul Gevers wrote: Source: polyml Version: 5.7.1-5 Control: found -1 5.7.1-4 Severity: serious Your package has an autopkgtest, great. However, it fails since July 2020. Can you please investigate the situation and fix it? I copied some Looks like polyml is failing its autopkgtest. As the release happens is happening soon, would you consider to take a quick look at this? autopkgtest [19:23:44]: test upstream-polyc: [--- /usr/bin/ld: warning: /tmp/polyobj.2070.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker Test035.ML => Passed Test162.ML => Passed [...] Test026.ML => Passed autopkgtest [19:24:05]: test upstream-polyc: ---] autopkgtest [19:24:05]: test upstream-polyc: - - - - - - - - - - results - - - - - - - - - - upstream-polyc FAIL stderr: /usr/bin/ld: warning: /tmp/polyobj.2070.o: missing .note.GNU-stack section implies executable stack Thanks Nilesh
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Hi On Tue, May 16, 2023 at 03:01:10PM +0200, Andreas Tille wrote: > when fixing bug #1035428 I realised test suite issues with > > r-cran-thematic [1] >-> Error in `svglite_(filename, bg, width, height, pointsize, standalone, > always_valid)`: Graphics API version mismatch > > r-cran-treescape [2] > r-cran-treespace [3] >-> error is given if lambda is outside of [0,1] --- > `medTree(trees, -1)` did not throw an error. > > As far as I can guess at least the first type of error (Graphics API > version mismatch) is caused by the fact that a new upstream version of > r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to > experimental so it seems by accident). I can think of two ways: 1. r-cran-shiny is an arch:all package, so the package itself being built against r-base 4.3.0 is not an issue. The issue is the "r-base-core (>= 4.3.0-1)" that dh-r injects, which is being pulled in the autopkgtests of its reverse-depends. Changing that to "r-base-core (>= 4.2.2.20221110-2)" manually should do the trick. Something on the lines of: override_dh_gencontrol: dh_gencontrol sed "s/r-base-core (>= 4.3.0-1)/r-base-core (>= 4.2.2.20221110-2)" -i debian/r-cran-shiny/DEBIAN/control Ofcourse, the hard-coding of 4.3.0-1 can be converted to some better regular expression. 2. It makes a valid and strong case to use t-p-u (see here[5]) for such an upload, as it isn't a possibility to build against R in testing. You might want to ask release team about it, by filing a bug for release.d.o pseudo-package and/or asking in #debian-release on OFTC. I personally prefer "1" over 2 as it is less noise (and effort). Let me know what you think. > [1] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > [2] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > [3] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > [4] > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ [5] https://wiki.debian.org/TestingProposedUpdates -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 08:26:21AM -0500, Dirk Eddelbuettel wrote: > Note that none of this affects the release. My recommendation is temporarily > suspend the autopkgtest in those affected packages. No, don't do that as they indicate a new r-base being pulled as one of the dependencies (which would be incorrect for a package). In this case, r-cran-shiny has a hard-dependency on r-base. Once that is fixed, rest of the things should be sorted out. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > I personally prefer "1" over 2 as it is less noise (and effort). On second thoughts, I think sending it via testing-proposed-updates would be a better thing to do, as this case perfectly fits the problem. It's be same effort in both cases (one upload + filing a bug with release team). > Let me know what you think. > > [1] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > [2] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > [3] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > [4] > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > [5] https://wiki.debian.org/TestingProposedUpdates -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 09:31:20AM -0500, Dirk Eddelbuettel wrote: > > On 16 May 2023 at 19:49, Nilesh Patra wrote: > | On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > | > I personally prefer "1" over 2 as it is less noise (and effort). > | > | On second thoughts, I think sending it via testing-proposed-updates > | would be a better thing to do, as this case perfectly fits the problem. > | > | It's be same effort in both cases (one upload + filing a bug with release > team). > > Reading 'https://wiki.debian.org/TestingProposedUpdates' does indeed suggest > that this may be one of those situations. I can easily prepare a 4.3.0-2 > with that destination but would prefer if someone from the release could > 'nod', maybe in reply to this email. Uh, no. Maybe you misunderstood my suggestion. The t-p-u way was for r-cran-shiny not the r-base package. This is because r-cran-shiny would want to build against r-base in testing (and not unstable). Uploading a 4.3.0-2 of r-base would mean uploading a new r-base to testing without a proper transition and without re-compilation of API-incompatible graphics related packages -- that'd be quite the havoc in testing (and eventually next stable). It also violates some of the rules of t-p-u -- more details here[1] in case you are interested. r-base can continue to stay where it already is at the moment :) [1]: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035568: dnsmasq is broken on new bookworm installations
On Fri, 05 May 2023 15:17:37 + =?utf-8?q?Jens_Mei=C3=9Fner?= wrote: > Package: dnsmasq > Version: 2.89-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: heptal...@gmx.de > > Hello, > > dnsmasq on bookworm fails to start after installation because the dns port 53 > is already is use by systemd-resolved. > After stopping systemd-resolved dnsmasq will start but refuses all dns > queries with the Extended DNS Error Code 14 "Not Ready". > This error is reproducible on new installation. > > Setting severity to grave because it affects clean installs. Simon, since this is a bug of high severity and we are close to bookworm release, would you consider taking a quick look at it? Thanks Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Wed, May 17, 2023 at 08:58:58AM +0200, Andreas Tille wrote: > Am Tue, May 16, 2023 at 07:49:55PM +0530 schrieb Nilesh Patra: > > On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > > > I personally prefer "1" over 2 as it is less noise (and effort). > > > > On second thoughts, I think sending it via testing-proposed-updates > > would be a better thing to do, as this case perfectly fits the problem. > > I hope I was following developers reference about t-p-u[6] correctly > and pushed > I've choosen the version 1.7.4+dfsg-3~deb12u1 to match > the requirement that the version is lower than in unstable I guess this should be alright. But as per devref, you may want to choose "1.7.4+dfsg-2+deb12u1". > I wonder whether dput is working with target distribution bookworm since > lintian throws an error. It probably should. There's a d/ch entry I found for argon2 package here[7] in case that helps you. > Release team is in CC - do you think I should > file a bug right now or just after an upload? devref says "Ask for authorization for uploading from the release managers." So I suppose it makes sense to file a bug before you upload and ping them back again once you upload as per "After uploading and successful build on all platforms, contact the release team at debian-rele...@lists.debian.org and ask them to approve your upload." > > > > [1] > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > > > [2] > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > > > [3] > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > > > [4] > > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > > > [5] https://wiki.debian.org/TestingProposedUpdates > [6] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u [7] https://tracker.debian.org/news/1429925/accepted-argon2-020171227-03deb12u1-source-into-testing-proposed-updates/ -- Best, Nilesh signature.asc Description: PGP signature
Bug#1030451: marked as pending in python-pytray
Control: tag -1 pending Hello, Bug #1030451 in python-pytray 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-pytray/-/commit/af866bdfe160ccded9f2329a3f07d86cdd874494 Add patch to fix version (Closes: #1030451) (this message was generated automatically) -- Greetings https://bugs.debian.org/1030451
Bug#1028779: buildbot: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 --system=custom "--test-args=PYTHONPATH=pkg:{destdir}/{install_dir} PATH=\$PATH:{destdir}/usr/bin trial3 --
Hi Robin, buildbot is marked for removal on Feb 16. Do you intend to make an upload? Thanks Nilesh On Wed, 1 Feb 2023 11:47:56 +0100 s3v wrote: > Dear maintainer, > > Please find attached a patch to avoid deprecation warnings > causing tests to fail. > > Kind Regards signature.asc Description: PGP signature
Bug#1030096: dask.distributed intermittent autopkgtest fail
Control: fixed -1 2022.12.1+ds.1-2 Some tests passed after I put it for (multiple) retries. The current state looks fine https://qa.debian.org/excuses.php?package=dask.distributed But I am not sure if this counter would be set to 2 days (from 5 days) or not -- will likely need to ask release team. In any case it might be a nice idea to hold off any further uploads until this migrates. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1030096: dask.distributed intermittent autopkgtest fail
On 10 February 2023 1:28:04 pm IST, "Rebecca N. Palmer" wrote: >On 10/02/2023 06:41, Andreas Tille wrote: >> Am Fri, Feb 10, 2023 at 08:44:01AM +0530 schrieb Nilesh Patra: >>> But I am not sure if this counter would be set to 2 days (from 5 days) >>> or not -- will likely need to ask release team. >> >> As far as I observed the migration time is now 5 days (no matter whether >> autopkgtest or not). > >I think the "5 days" on the tracker page is because the reverse dependencies' >autopkgtests haven't all been run yet, and will change to 2 days once they >have: >https://release.debian.org/testing/freeze_policy.html I've not seen the tracker getting reset to 2 days when a certain package doesn't show success on all archs. Which means if a package passes on 3 archs, and shows the status as 'neutral' or 'not a regression' or 'tests not run on the architecture due to not being in the arch list (in d/t/control)' then I've seen a 5 day migration delay. And this is the case for distributed (not a regression on 2 archs) I don't know if things have changed lately, but I doubt. In any case, I've sent a message on the release team IRC. Best, Nilesh
Bug#1016732: Please help to reproduce (Was: shiny-server: server-function don't run)
Hi Yadd, On Sat, 28 Jan 2023 11:09:21 +0530 Nilesh Patra wrote: > On Fri, Jan 27, 2023 at 07:45:35PM +, Krüger, Sebastian wrote: > > I'm not a Shiny user either (so far), however the plan is for our institute > > to provide Shiny applications for certain users. (I will probably write > > some of these applications at some point, and I also administrate the web > > server...). > > > > My test system: I have a current Debian sid with R, cleaned from nodejs > > (apt...) and thus without shiny-server. > > > > Now I install the shiny-server (apt install shiny-server). > > > > In the packages r-cran-shiny and shiny-server are sample applications. I > > copied the examples from the r-cran-shiny package (e.g. > > /usr/lib/R/site-library/shiny/examples/01_hello) to /srv/shiny-server and > > could (after restarting shiny-server (systemctl restart shiny-server)) > > access the application via firefox: http://localhost:3838/01_hello/ . > > > > These applications consist of a UI part (user interface) and a result part. > > In the UI part, the web user can set (e.g.) parameters for the display in > > the result part. > > > > The problem: After installation, only the UI part is visible via the web > > browser. > > The result part is probably not visible because it does not receive any > > data from the UI part. > > > > With the help of a deb package for the Shiny sever from rstudio and the > > Debian package, I had at some point identified the sockjs installation as > > the problem... > > > > To get the Shiny application running (in the current scenario), I got the > > latest version of sockjs from github, "comped" it with npm () and then > > replaced the javascript files under "/usr/share/nodejs/sockjs/lib/" (from > > the Debian installation) with the files from the sockjs (github) package > > tree ".../node_modules/sockjs/lib/". > > > > After restarting the Shiny server, you can now also see the result part in > > the web browser and the Shiny application works. > > > > I am not a javascript/coffeescript friend or expert. The only thing I could > > see is that both my sockjs scripts and the Debian ones are based on the > > same github version > > (https://github.com/sockjs/sockjs-node/releases/tag/v0.3.24), but the > > Debian version was generated with coffescript 2.7.0 and "my" version was > > generated with coffescript 1.12.7. > > Looks like the coffeescript thingy in #1016732 is still unfixed and I've > re-opened the BR. Could you please > consider taking another look? Sorry for pinging you again, but would you be able to take a look at this please? I don't know enough coffeescript to be able to check this and it'd be awesome if you could consider taking a look. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1031434: conda-package-handling: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Control: reassign -1 python3-zstandard 0.19.0-3 Control: affects -1 + conda-package-handling Control: forcemerge -1 1031293 On Fri, 17 Feb 2023 06:30:57 +0100 Lucas Nussbaum wrote: > Source: conda-package-handling > Version: 2.0.1-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This is very clearly due to zstd python and unbundled lib mismatch. there's nothing that can be done at c-p-h end to fix this. Reassigning and merging with an already filed bug. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1031475: conda-package-streaming: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Control: reassign -1 python3-zstandard 0.19.0-3 Control: affects -1 + conda-package-streaming Control: forcemerge -1 1031293 On Fri, 17 Feb 2023 08:02:54 +0100 Lucas Nussbaum wrote: > Source: conda-package-streaming > Version: 0.7.0-4 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This is very clearly due to zstd python and unbundled lib mismatch. there's nothing that can be done at c-p-h end to fix this. Reassigning and merging with an already filed bug. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1031484: augur: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Control: reassign -1 python3-zstandard 0.19.0-3 Control: affects -1 + augur Control: forcemerge -1 1031293 On Fri, 17 Feb 2023 08:02:43 +0100 Lucas Nussbaum wrote: > Source: augur > Version: 20.0.0-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This is very clearly due to zstd python and unbundled lib mismatch. there's nothing that can be done at c-p-h end to fix this. Reassigning and merging with an already filed bug. signature.asc Description: PGP signature
Bug#1031444: poetry: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Control: tags -1 moreinfo Control: severity -1 important Hi Lucas, On Fri, 17 Feb 2023 07:47:47 +0100 Lucas Nussbaum wrote: > Source: poetry > Version: 1.3.2+dfsg-3 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. It builds fine on my local machine. I built more than 10 times on barriere.d.o and it worked fine. I was able to reproduce the issue once on my local machine, of many, many re-builds though but unfortunately that is not enough (for me) to reliably repro/root-cause this. Would you please consider building this again? If it still fails, then maybe it is a random issue or reproducible on some specific systems. I'm downgrading the severity to important for now, I hope that is fine. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1031465: snippy: FTBFS: make[2]: *** [Makefile:32: S1/snps.tab] Error 2
Attempting to fix Pjotr's address. Pjotr: if you are reading this, could you comment on it? Thanks Nilesh On Mon, 20 Feb 2023 17:21:59 +0100 Andreas Tille wrote: > Hi Pjotr, > > in contrast to the bug reporter I get in my unstable chroot > > ... > [15:53:57] Checking version: bcftools --version is >= 1.7 - ok, have 1.16 > [15:53:57] Checking version: freebayes --version is >= 1.1 - ok, have 1.3.6 > [15:53:57] Checking version: snpEff -version is >= 4.3 - ok, have 5.1 > ... > > which looks good regarding the version check of freebayes. However > later on the test ends up in: > > > Loaded 3 sequences totalling 317336 bp. > Loading mask bed file: example.bed > Will mask 8 regions totalling 3101 bp ~ 0.98% > 0 S1 snp=0 del=0 ins=0 het=0 unaligned=9643 > 1 S2 snp=0 del=0 ins=0 het=81 unaligned=9428 > 2 S3 snp=0 del=0 ins=0 het=0 unaligned=9376 > 3 S4 snp=0 del=0 ins=0 het=0 unaligned=9707 > Opening: core-mask.tab > Opening: core-mask.vcf > Processing contig: LBB_contig01 > Processing contig: LBB_contig02 > Processing contig: LBB_contig03 > Masking alignment at 8 regions > Generating core-mask.full.aln > Creating TSV file: core-mask.txt > Running: snp-sites -c -o core-mask.aln core-mask.full.aln > Warning: No SNPs were detected so there is nothing to output. > ERROR: Could not run: snp-sites -c -o core-mask.aln core-mask.full.aln > > > I'm not sure whether this might be related to some previous freebayes > call (which is the only package in the list of dependencies that has > changed) or whether there is some other problem. I think it is worth > investigating since snippy might be an interesting test suite for a > whole bunch of packages. > > Kind regards >Andreas. > > -- > http://fam-tille.de > > signature.asc Description: PGP signature
Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z
On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum wrote: > Source: python-zstandard > Version: 0.19.0-3 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. At the moment this is creating quite the havoc with making a bunch of things FTBFS as well (see merhged bugs) This is likely due to py-zst trying to link with the zstandard in the archive which does not seem to go very well. Is someone working to fix this? -- Best, Nilesh signature.asc Description: PGP signature
Bug#1016732: Please help to reproduce (Was: shiny-server: server-function? don't run)
On Sun, Feb 26, 2023 at 12:46:15AM +0530, Pirate Praveen wrote: > On Sun, 12 Feb 2023 23:16:06 +0530 Nilesh Patra wrote: > > Sorry for pinging you again, but would you be able to take a look at this > please? > > I don't know enough coffeescript to be able to check this and it'd be > > awesome if you could consider taking a look. > > Coffeescript 2 creates ESM format js by default, adding -t option to coffee > command should give you the old ES5 javascript like coffeescript 1.x > > See https://salsa.debian.org/js-team/node-sockjs/-/blob/master/Makefile#L11 Thanks for the pointer. However, unfortunately even after propagating the "-t" flag with coffee, the generated code does not work to fine (the UI is not functional). For now I have vendored coffee1 generated code itself. Do you have any other ideas? -- Best, Nilesh signature.asc Description: PGP signature
Bug#1032550: igdiscover: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Control: severity -1 important I've rebuild igdiscover 0.11-3 in a testing and unstable environment. Both builds are passing all tests. Same for me, I'm reducing the severity. Lucas, could you please do a re-run? I wonder if it is another of those "$specific-CPU-configuration" failures. Thanks, Nilesh
Bug#1032549: python-pbcore: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Hi Lucas,
Source: python-pbcore
Version: 2.1.2+dfsg-5
Severity: serious
Justification: FTBFS
WARNING: The wheel package is not available.
/usr/bin/python3.11: No module named pip
error: Command '['/usr/bin/python3.11', '-m', 'pip', '--disable-pip-version-check',
'wheel', '--no-deps', '-w', '/tmp/tmpqico3vl0', '--quiet',
'astroid<=2.14.0-dev0,>=2.12.13']' returned non-zero exit status 1.
E: pybuild pybuild:388: test: plugin custom failed with: exit code=1:
python3.11 setup.py test
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11
returned exit code 13
This error stems from an older pylint.
In your build log, I see that an older version of pylint is being used:
| Selecting previously unselected package pylint.
| Preparing to unpack .../111-pylint_2.15.10-1_all.deb ...
| Unpacking pylint (2.15.10-1) ...
This has been fixed with pylint 2.16.2-2, which is currently in unstable but
it'd migrate to testing
by tomorrow or the day after. Could you please consider to re-build and close
the bug once it does?
If you want, I'll send a reminder as well.
Thanks,
Nilesh
Bug#1032542: conda-package-handling: FTBFS in testing:, dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11
unblock 1032542 by 1031293 close 1032542 stop python-zstandard has migrated, and I am able to build conda-package-handling in a testing chroot. Closing the bug. Thanks, Nilesh
Bug#1032540: conda-package-streaming: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
unblock 1032540 by 1031293 close 1032540 stop Once python3-zstandard has migrated to testing the build time test should work again. python-zstandard has migrated, and I am able to build conda-package-streaming in a testing chroot. Closing the bug. Thanks, Nilesh
Bug#1032120: Upload of new upstream version before fix has migrated to testing
Quoting Andreas Tille: your recent upload of tiledb 2.15.0-1 into unstable is quite unfortunate in freeze policy. You should have waited at least until 2.14.1-2 fixing this bug to migrate to testing. You would need to ask release team for migration of 2.15.0 which will probably be refused The changes between 2.14 and 2.15 are non-trivial and are likely to be rejected by release team at the moment, considering there are no autopkgtests either. even if you would be able to fix the regression in autopkgtest[1]. This is because the version of tiledb-py is not compatible with tiledb 2.15.0. Uploading a new version of tiledb-py would fix this, but: - It'd be useless unless tiledb 2.15.0 migrates. - It seems to need pyarrow for tests, and other functionalities, which is un-packaged. So current situation is: * tiledb 2.14.1-1 in testing (and next stable) is marked for auto-removal. * consequently, tiledb-py is also marked for autoremoval. * tiledb 2.15.0-1 can't migrate because of freeze policy. What a freaking mess! Dirk, we could have avoided all of it if you had quite literally ** waited ** for a few hours to let tiledb migrate on the 8th of March. I'm sad to see such mess-ups happening at this time as I had put quite some efforts on tiledb-py myself too. The solution right now is what Andreas said: My recommendation would be to upload a version 2.15.0-2+really_2.14.1 Dirk, please fix this so tiledb can make a (valid) stable release. [1]: https://tracker.debian.org/pkg/tiledb Thanks, Nilesh
Bug#1032120: Upload of new upstream version before fix has migrated to testing (Was: Re: Bug#1032120: tiledb: uses atomic operations, but is not linked to libatomic)
Dirk - Ping on this? If you do not have the time, let me know. I'll do a NMU for tiledb to revert to prev version and also file an unblock request. On 3/10/23 20:53, Nilesh Patra wrote: Quoting Andreas Tille: your recent upload of tiledb 2.15.0-1 into unstable is quite unfortunate in freeze policy. You should have waited at least until 2.14.1-2 fixing this bug to migrate to testing. You would need to ask release team for migration of 2.15.0 which will probably be refused The changes between 2.14 and 2.15 are non-trivial and are likely to be rejected by release team at the moment, considering there are no autopkgtests either. even if you would be able to fix the regression in autopkgtest[1]. This is because the version of tiledb-py is not compatible with tiledb 2.15.0. Uploading a new version of tiledb-py would fix this, but: - It'd be useless unless tiledb 2.15.0 migrates. - It seems to need pyarrow for tests, and other functionalities, which is un-packaged. So current situation is: * tiledb 2.14.1-1 in testing (and next stable) is marked for auto-removal. * consequently, tiledb-py is also marked for autoremoval. * tiledb 2.15.0-1 can't migrate because of freeze policy. What a freaking mess! Dirk, we could have avoided all of it if you had quite literally ** waited ** for a few hours to let tiledb migrate on the 8th of March. I'm sad to see such mess-ups happening at this time as I had put quite some efforts on tiledb-py myself too. The solution right now is what Andreas said: My recommendation would be to upload a version 2.15.0-2+really_2.14.1 Dirk, please fix this so tiledb can make a (valid) stable release. [1]: https://tracker.debian.org/pkg/tiledb
Bug#1032120: Upload of new upstream version before fix has migrated to testing (Was: Re: Bug#1032120: tiledb: uses atomic operations, but is not linked to libatomic)
Tl;dr: Because It will not migrate and eventually get kicked out of testing and next stable on April, 13 regardless of what the tracker says now. On 3/12/23 19:00, Dirk Eddelbuettel wrote: Why not wait a week on 2.15.0-1 which now 'Too young, only 4 of 10 days old'? It won't migrate as told earlier too. By tomorrow it would have 'blocked by freeze' written over there. Hard freeze starts tomorrow, and it'd need an unblock request which wouldn't be agreed upon as only changes like these[1] are allowed in hard freeze. The version in testing has an RC bug, and hence this will be taken out of testing if we do not revert the version to a previous one. [1]: https://release.debian.org/bullseye/freeze_policy.html#appropriate Best, Nilesh
Bug#1032120: Upload of new upstream version before fix has migrated to testing (Was: Re: Bug#1032120: tiledb: uses atomic operations, but is not linked to libatomic)
On Sun, Mar 12, 2023 at 07:27:46PM +0530, Nilesh Patra wrote: > On 3/12/23 19:00, Dirk Eddelbuettel wrote: > > > > Why not wait a week on 2.15.0-1 which now 'Too young, only 4 of 10 days > > old'? > > It won't migrate as told earlier too. By tomorrow it would have 'blocked by > freeze' written over there. And it has that written over there now. Another better option can be to add autopkgtests to tiledb, as this is not a key package and hence can migrate w/o freeze block. Let me know what you think. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1032975: igdiscover -- Broken, unusable package due to incomplete code in the binary package
Package: igdiscover Version: 0.11-4 Severity: serious Usertags: ftbfs-bookworm Dear Maintainer, igdiscover vendors just a /usr/bin/igdiscover with is supposed to be nothing more than just a wrapper. The actual code is missing from the binary package (i.e. the python files) effectively making igdiscover useless. Even after fixing that, igdiscover is still broken because of a broken Snakefile and it is not able to run the pipeline/workflow which is the main functionality here (it is a workflow tool). Steps to check can be found here[1]. Remember to change merge tool to 'flash' (and apt-get install flash) before running `igdiscover run`. It chokes at not being able to find "igblastn" -- it might be originatin from ncbi-igblast. I've fixed the first part (py files installation) and pushed changes to salsa in a different branch here[2]. I do not have any more time to look into it. [1]: https://docs.igdiscover.se/en/stable/testing.html [2]: https://salsa.debian.org/med-team/igdiscover/-/tree/bookworm-release -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages igdiscover depends on: ii python3 3.11.1-2 pn python3-cutadapt pn python3-matplotlib ii python3-numpy1:1.24.1-2+b1 pn python3-pandas pn python3-ruamel.yaml pn python3-scipy pn python3-seaborn pn python3-sqt pn python3-xopen igdiscover recommends no packages. Versions of packages igdiscover suggests: pn igdiscover-doc pn snakemake
Bug#1032120: Upload of new upstream version before fix has migrated to testing (Was: Re: Bug#1032120: tiledb: uses atomic operations, but is not linked to libatomic)
Hi, I am removing myself from the uploaders field/maintenance of tiledb-py. Feel free to update it once tiledb is ready for migration. The repository lives at python team namespace. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1034221: caddy: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hi Peymaneh, On Tue, 11 Apr 2023 15:54:02 +0200 Andreas Henriksson wrote: > On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > > Package: caddy > > Version: 2.6.2-4 > > Severity: serious > > Tags: sid bookworm > > It seems that your package caddy is shipping files (.service, .socket or > > .timer) in /usr/lib/systemd/system. > [...] > > The culprit seems to be wrong path at: > https://sources.debian.org/src/caddy/2.6.2-4/debian/caddy.install/#L2-L3 > > Please note that if you change it to /lib/systemd/system now, you'll > likely need to reverse that change again in the future. > > Preferably the correct path is derived from the value given by > pkg-config --variable=systemdsystemunitdir systemd Can you take care of this? -- Best, Nilesh signature.asc Description: PGP signature
Bug#1034221: caddy: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Mon, Apr 17, 2023 at 03:47:43PM +, Peymaneh wrote: > Am 16.04.23 um 17:37 schrieb Nilesh Patra: > > Can you take care of this? > > thanks for the mail Nilesh, I missed the bugreport. In your fix, why not use Andreas' suggestion to install it via "pkg-config --variable=systemdsystemunitdir systemd" ? You might need to revert your fix again otherwise. > I uploaded a fix just now and will contact the release team for unblocking. I think that won't be needed. Caddy is a non-key package with (hopefully) passing autopkgtest. You'll need to ask release team if full-freeze starts before the next 20 days. -- Best, Nilesh signature.asc Description: PGP signature
Bug#918774: fixed in lasi 1.1.3-1
On Sun, 23 Apr 2023 06:18:58 + Debian FTP Masters wrote: Source: lasi Source-Version: 1.1.3-1 Done: Nilesh Patra Sending BTS mail to help reset the autorm counter. Thanks Nilesh
Bug#1028748: marked as pending in bottleneck
Control: tag -1 pending Hello, Bug #1028748 in bottleneck 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/bottleneck/-/commit/1e9826700e19c07757d48a71856998f8ff3219d1 Cherry-pick upstream patch to fix numpy 1.24 FTBFS (Closes: #1028748) (this message was generated automatically) -- Greetings https://bugs.debian.org/1028748
Bug#1022630: marked as pending in node-mermaid
Control: tag -1 pending Hello, Bug #1022630 in node-mermaid 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-mermaid/-/commit/75d671a0625d8fab10bb8e0fd4b6eaa6abec468a Add patch to fix bundling failure with rollup3 (Closes: #1022630) (this message was generated automatically) -- Greetings https://bugs.debian.org/1022630
Bug#1029350: Strange error in dh_auto_install of r-cran-spatstat.core
Source: dh-r
Version: 20210816
Severity: serious
Control: retitle -1 dh-r parsing of tests depends/suggests is faulty
[ Looks like I has mistakenly submitted the report to control@ earlier, fixing
that, rest of the mail is copied as is ]
Hi Andreas,
On 1/21/23 19:17, Andreas Tille wrote:
Hi,
I'm just running into
dh_auto_install: warning: can't parse dependency spatstat (>= 2.3-3).linnet
(>= 2.0-0)
Can't call method "get_deps" on an undefined value at
/usr/share/perl5/Debian/Debhelper/Buildsystem/R.pm line 51.
when trying to build r-cran-spatstat.core[1]
I've never seen this strange substitution of dependencies before.
Any idea what's wrong here?
Congrats. Looks like you hit a case which catches a bug in dh-R.
The problem is in the code when you are trying to substitute test depends from
the ones in suggests[2]. The substitution
that you are trying to do is also replacing prefixes with versioned dep. Since
there is spatstat and spatstat.linnet both in
d/t/control test-depends, and as you could see spatstat is a common prefix, it
is replacing this with the one
written in DESCRIPTION file which is wrong.
As it seems to me that you only intend to replace non-versioned stuff with the
versioned stuff, maybe you don't have
to replace all strings that are prefix. So _maybe_ a patch like this would do
(it works in this case at least):
diff --git a/dh/R.pm b/dh/R.pm
index 18171ae..7d052b1 100644
--- a/dh/R.pm
+++ b/dh/R.pm
@@ -210,7 +210,7 @@ sub install {
$rsname =~ s/[\s(].*// ;
if ( grep(/^$rsname$/i, @testdeps) ) {
if ( $rs ne $rsname ) { # seems that is a versioned depends that
needs to be propagated to Recommends
- $testdepends =~ s/$rsname */$rs/ ;
+ $testdepends =~ s/$rsname$/$rs/ ;
}
} else {
$newsuggests = $newsuggests . ', ' . $rs ;
But that said, I do not know the essence of this code, and please _triple
check_ and ** do not blindly apply **
[1] https://salsa.debian.org/r-pkg-team/r-cran-spatstat.core/-/jobs/3830571
[2]: https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L213
Hope that helps.
Thank you
Nilesh
Bug#1029351: Strange error in dh_auto_install of r-cran-spatstat.core
Source: dh-r
Version: 20210816
Severity: serious
Control: retitle -1 dh-r parsing of tests depends/suggests is faulty
Hi Andreas,
On 1/21/23 19:17, Andreas Tille wrote:
Hi,
I'm just running into
dh_auto_install: warning: can't parse dependency spatstat (>= 2.3-3).linnet
(>= 2.0-0)
Can't call method "get_deps" on an undefined value at
/usr/share/perl5/Debian/Debhelper/Buildsystem/R.pm line 51.
when trying to build r-cran-spatstat.core[1]
I've never seen this strange substitution of dependencies before.
Any idea what's wrong here?
Congrats. Looks like you hit a case which catches a bug in dh-R.
The problem is in the code when you are trying to substitute test depends from
the ones in suggests[2]. The substitution
that you are trying to do is also replacing prefixes with versioned dep. Since
there is spatstat and spatstat.linnet both in
d/t/control test-depends, and as you could see spatstat is a common prefix, it
is replacing this with the one
written in DESCRIPTION file which is wrong.
As it seems to me that you only intend to replace non-versioned stuff with the
versioned stuff, maybe you don't have
to replace all strings that are prefix. So _maybe_ a patch like this would do
(it works in this case at least):
diff --git a/dh/R.pm b/dh/R.pm
index 18171ae..7d052b1 100644
--- a/dh/R.pm
+++ b/dh/R.pm
@@ -210,7 +210,7 @@ sub install {
$rsname =~ s/[\s(].*// ;
if ( grep(/^$rsname$/i, @testdeps) ) {
if ( $rs ne $rsname ) { # seems that is a versioned depends that
needs to be propagated to Recommends
- $testdepends =~ s/$rsname */$rs/ ;
+ $testdepends =~ s/$rsname$/$rs/ ;
}
} else {
$newsuggests = $newsuggests . ', ' . $rs ;
But that said, I do not know the essence of this code, and please _triple
check_ and ** do not blindly apply **
[1] https://salsa.debian.org/r-pkg-team/r-cran-spatstat.core/-/jobs/3830571
[2]: https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L213
Hope that helps.
Thank you
Nilesh
Bug#1029310: [Help] Re: Bug#1029310: src:r-cran-bayesplot: fails to migrate to testing for too long: autopkgtest regression
On 1/21/23 16:56, Andreas Tille wrote: as per DebCI there are 15 autopkgtest failures which seem to be connected to ggplot2 API somehow.[1] Interestingly Salsa CI[2] does not show this autopkgtest error neither can I reproduce the problem on my local pbuilder. Has anyone some idea what might be wrong? If not I might ask bug reporter for more info. I can't repro it either. But the log you point to is a fresh failure (today). Did not dig deeper, but did you take a look at the `diff` between log that passes and the one which does not? I'm suspecting there is some dependency problem here. [1] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-bayesplot/30534574/log.gz [2] https://salsa.debian.org/r-pkg-team/r-cran-bayesplot/-/jobs/3779597 Thanks Nilesh
Bug#1029310: [Help] Re: Bug#1029310: src:r-cran-bayesplot: fails to migrate to testing for too long: autopkgtest regression
On 1/21/23 21:59, Andreas Tille wrote: Am Sat, Jan 21, 2023 at 09:46:07PM +0530 schrieb Nilesh Patra: On 1/21/23 16:56, Andreas Tille wrote: as per DebCI there are 15 autopkgtest failures which seem to be connected to ggplot2 API somehow.[1] Interestingly Salsa CI[2] does not show this autopkgtest error neither can I reproduce the problem on my local pbuilder. Has anyone some idea what might be wrong? If not I might ask bug reporter for more info. I can't repro it either. Relieving to know that I did not missed any basic thing here. ;-) But the log you point to is a fresh failure (today). Did not dig deeper, but did you take a look at the `diff` between log that passes and the one which does not? Not yet. Where can I find those old logs? You can take a diff betweek ci log you pointed to and the log on salsa CI/local system. The debci runs with package versions in testing, so there might be a bump in some dependency. Thanks Nilesh
Bug#1027235: marked as pending in python-pomegranate
Control: tag -1 pending Hello, Bug #1027235 in python-pomegranate 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-pomegranate/-/commit/0dba7288e24f9a14b62c07206476096db2e0a37e Add patch to make package compatible with np 1.24 (Closes: #1027235) (this message was generated automatically) -- Greetings https://bugs.debian.org/1027235
Bug#1027352: marked as pending in ruby-activerecord-import
Control: tag -1 pending Hello, Bug #1027352 in ruby-activerecord-import 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/ruby-team/ruby-activerecord-import/-/commit/69cb0d9ff3fb9d3a348b41d43d1aeffc09b1e9e3 Add patch to fix FTBFS (Closes: #1027352) (this message was generated automatically) -- Greetings https://bugs.debian.org/1027352
Bug#1029310: [Help] Re: Bug#1029310: src:r-cran-bayesplot: fails to migrate to testing for too long: autopkgtest regression
On 23 January 2023 3:06:58 pm IST, Andreas Tille wrote: >Am Sat, Jan 21, 2023 at 10:17:06PM +0530 schrieb Nilesh Patra: >> On 1/21/23 21:59, Andreas Tille wrote: >> > Am Sat, Jan 21, 2023 at 09:46:07PM +0530 schrieb Nilesh Patra: >> > > On 1/21/23 16:56, Andreas Tille wrote: >> > > > as per DebCI there are 15 autopkgtest failures which seem to be >> > > > connected to ggplot2 API somehow.[1] Interestingly Salsa CI[2] does >> > > > not >> > > > show this autopkgtest error neither can I reproduce the problem on my >> > > > local >> > > > pbuilder. >> > > > >> > > > Has anyone some idea what might be wrong? If not I might ask bug >> > > > reporter >> > > > for more info. >> > > >> > > I can't repro it either. >> > >> > Relieving to know that I did not missed any basic thing here. ;-) >> > >> > > But the log you point to is a fresh failure (today). >> > > Did not dig deeper, but did you take a look at the `diff` between log >> > > that passes and the one >> > > which does not? >> > >> > Not yet. Where can I find those old logs? >> >> You can take a diff betweek ci log you pointed to and the log on salsa >> CI/local system. >> The debci runs with package versions in testing, so there might be a bump in >> some dependency. > >I did a diff between the r-cran-* packages in the failing log and the >successful log: > [...] > >to me those diffs are locking not really spectacular regarding to >the actual issue. Right. >I admit I'm running out of ideas but for the moment my last resort >is to skip the 8 affected test, let the packages migrate to testing >and revert skipping the tests afterwards. I did find an issue[3] which states ggplot2 breaks bayesplot 1.9.0 and spews the exact same errors we observe in debci. There's also an upstream issue with bayesplot installation (similar stuff again) where it works for some people but not for others, see[4]. But then I'm not sure as to why it works for me, you and salsa CI. For now I'll have to dismiss it by calling it black magic. Your approach sounds fair. Maybe you should do what you wrote (disable tests, let it migrate, enable tests again) >[1] https://ci.debian.net/packages/r/r-cran-bayesplot/testing/amd64/ >[2] >https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-bayesplot/28139180/log.gz [3]: https://github.com/tidyverse/ggplot2/blob/main/revdep/problems.md#bayesplot [4]: https://github.com/stan-dev/bayesplot/issues/297 -- Best, Nilesh
Bug#1029660: nipype FTBFS: ModuleNotFoundError: No module named 'nibabel.trackvis'
Package: nipype Version: 1.7.1-2 Severity: serious Dear Maintainer, nipype is incompatible with nibabel 4.0 and FTBFS with several errors of type: | _ ERROR collecting interfaces/mrtrix/tests/test_auto_Tensor2Vector.py __ | ImportError while importing test module '/<>/nipype/interfaces/mrtrix/tests/test_auto_Tensor2Vector.py'. | Hint: make sure your test modules/packages have valid Python names. | Traceback: | /usr/lib/python3.11/importlib/__init__.py:126: in import_module |return _bootstrap._gcd_import(name[level:], package, level) | ../nipype/interfaces/mrtrix/__init__.py:36: in |from .convert import MRTrix2TrackVis | ../nipype/interfaces/mrtrix/convert.py:6: in |import nibabel.trackvis as trk | E ModuleNotFoundError: No module named 'nibabel.trackvis' It has also been out of testing for quite sometime. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1028848: python-miio: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.11" returned exit code 13
reassign 1028848 python-zeroconf 0.47.1-1 fixed 0.47.1-2 close 1028848 stop This was a problem with zeroconf instead, which has been fixed. Re-assigned and closed. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?
Dirk, Andreas, On Wed, Jun 28, 2023 at 10:49:24AM +0200, Andreas Tille wrote: > Yes, so I keep on updating r-cran- packages after freeze and save my > time to repeat myself. I probably should not be the one to add fuel to the fire, but allow me to present some statistics. The debian R team team currently has 1151 packages, and at the time of writing this mail, there are only 2-3 volunteers who do the job of maintaining this chunk of work, which means each volunteer is maintaining at least ~384 packages just in the R team (and I'm speaking this in the context of team uploads, and not according to the name mentioned in uploaders field). Here's upload stats[2]. In addition to that, the said volunteers are also maintaining packages in other debian teams. For instance, my packages span across ~10-12 different teams, and same goes for Andreas. On top of that, there's also RFP requests from people and we have to constantly work on packaging new and relevant software for debian. @Dirk, you, on the other hand have most of the packages you maintain out of maintainer teams, and as far as I can see, you currently have 179 packages[3], and you mostly upload only those packages, so it is likely easier to bring them to cran latest at most times. I'm not trying to draw any comparison, but only stating facts. As you may see, the load that's on each volunteer is quite a lot, and it gets humanely impossible to keep all those number of packages into an updated state. We'd love to be at versions that CRAN (or bioconductor) is at currently, but there simply aren't enough cycles most of the times. I'd also like to point out that despite the constraints, during the past year, the number of stale packages were consistently less than '30' which is ~CRAN latest. Now is an anomally because freeze just ended, and there's a huge delta. [1]: https://qa.debian.org/developer.php?email=r-pkg-team%40alioth-lists.debian.net [2]: http://blends.debian.net/liststats/uploaders_r-pkg.png [3]: https://qa.debian.org/developer.php?login=edd&comaint=yes Best, Nilesh signature.asc Description: PGP signature
Bug#1039645: r-cran-epi: autopkgtest failure with r-base (4.3.1-1)
On Thu, Jun 29, 2023 at 11:00:42AM +0200, Andreas Tille wrote: > Am Wed, Jun 28, 2023 at 08:18:57PM +0530 schrieb Nilesh Patra: > > You are correct. A transition is all we need. However, in case of > > r-cran-epi simply adding a versioned dep on dplyr should do the trick. > > (epi is not a failure in excuses for dplyr). > > Why exactly do you think that actually dplyr should receive a versioned > Depends. It is not specified in DESCRIPTION explicitly and before I > change d/control to something which is not reproduced by dh-update-R I don't know where you are looking, but it is very clearly mentioned in the imports in in the DESCRIPTION file https://salsa.debian.org/r-pkg-team/r-cran-epi/-/blob/master/DESCRIPTION#L12 It is also mentioned in the d/control (by you) https://salsa.debian.org/r-pkg-team/r-cran-epi/-/blob/master/debian/control#L19 > I would love to understand the background of your suggestion. Is it just > because r-cran-dplyr belongs to the affected packages in the graphics > API that was mentioned by Dirk? See above. Also, logs like | 190s Error: chunk 16 | 190s Error in vectbl_assign(x[[j]], i, recycled_value[[j]]) : | 190s DLL requires the use of native symbols | 190s Execution halted Point towards an ABI change, and dplyr from testing has been used in the CI | 216s Selecting previously unselected package r-cran-dplyr. | 216s Preparing to unpack .../091-r-cran-dplyr_1.0.10-1_amd64.deb ... | 216s Unpacking r-cran-dplyr (1.0.10-1) ... In addition to that, r-cran-epi is not mentioned in the excuses for dplyr https://qa.debian.org/excuses.php?package=r-cran-dplyr So it is apparent that a versioned dep on dplyr is needed. > > I think this particular bug is sensible because without these versioned > > depends, epi will fail it's tests (for instance while backporting). > > Why do you think so? r-cran-epi is an arch:any package that has been built against a new R version. It needs a version of dplyr that has also been built against the same R version due to graphics API changes. > > We > > can go on closing these BRs on the fly. It would also help you track all > > the dependencies a bit better. > > But what means "better". Well, looking at the bugs can help you track versioned deps better. But ignore my suggestion if that is not the case here, I won't argue. > For the moment we strictly trust DESCRIPTION. > If the DESCRIPTION file would be wrong I'd rather file an upstream bug > report to add the versioned dependency there. There's nothing that upstream can do in such a situation. This is a condition induced due to a transition in debian. > > PS: Do you need a hand with this transition? > > I'm hoping to fight through r-cran-* as far as no new packages are > involved. I've droped some TODOs inside d/changelog of packages that > need deeper inspection. I'm currently need to care for r-cran-[t-z]*. > Packages higher in alphabeth either have issues or had new releases > since I was there in the last two weeks, OK. Let me know if you need help. Best, Nilesh signature.asc Description: PGP signature
Bug#1039645: r-cran-epi: autopkgtest failure with r-base (4.3.1-1)
On Thu, Jun 29, 2023 at 11:59:45AM +0200, Andreas Tille wrote: > > See above. Also, logs like > > > > | 190s Error: chunk 16 > > | 190s Error in vectbl_assign(x[[j]], i, recycled_value[[j]]) : > > | 190s DLL requires the use of native symbols > > | 190s Execution halted > > > > Point towards an ABI change, and dplyr from testing has been used in the CI > > Yes, I understand that a versioned depends of dplyr would avoid trying > to pick the version from testing. But this should be dealt by a > transition rather than picking a "random" (??? - that is my question > about) package from the dependencies and make it versioned. Yes, but at the moment AFAICS, there's no transition going on for R from release team side, or am I missing something? I don't see any such request here, at least https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-rele...@lists.debian.org Why do you think it will fix itself? OR, are you treating "testing migration" as "transition", and using them interchangeably? (Please use words accurately in this context if that is the case, it can quickly lead to confusions like these). Yes, it can be fixed by a testing migration of both, r-base *and* dplyr, but it will simply not migrate to testing since it'd build against a version of dplyr in testing. You need to make it versioned to pickup the one from unstable OR ask the release team to trigger debci with deps from unstable, which they only do on a case-by-case basis. > > | 216s Selecting previously unselected package r-cran-dplyr. > > | 216s Preparing to unpack .../091-r-cran-dplyr_1.0.10-1_amd64.deb ... > > | 216s Unpacking r-cran-dplyr (1.0.10-1) ... > > > > In addition to that, r-cran-epi is not mentioned in the excuses for > > dplyr > > > > https://qa.debian.org/excuses.php?package=r-cran-dplyr > > > > So it is apparent that a versioned dep on dplyr is needed. > > I confirm that this would help the Debian migration case. However, I > was trying to backup this case by any R codebase reason. I think that's currently not a possibility w/o a proper release transition / release-team coordinated transition. You can't get around avoiding this work here, unfortunately. > If we fiddle around with versioned Depends to work around a transition issue > this > will end up in a lot of manual work, I did quite a lot of manual work for past R migrations. I remember handling such migration issues for past R migration to testing. You might not have noticed it because I did the uploads quickly after the said failures. > I also fail to see your point in the importance of backports. If we happen to backport R, dplyr (built against backported R) and epi someday, a versioned depends like this will help to get the autopkgtests passing and epi working in backports. But yes, this has got nothing to do with r-cran-epi or r-cran-dplyr specific "code changes" as such. > Which is the case in unstable, isn't it? Both are built against the new > graphics API and I fail to see in how far dplyr and epi are in any way > special compared for those lots of other R packages with bug reports. They need to be re-compiled versions of one-another. > Its not about ignoring your suggestion. I simply want to understand it > to apply it properly. As far as I can see those versioned Depends do > not have any internal reason when considering the R code. I agree, it is not about the code changes, but rather about the API changes at a toolchain level. I think the BRs are helpful in this particular case of r-base transition to 4.3.1 (but mayn't be in general). > They would be helpful to solve the trouble we are in now due a not properly > announced > transition. I think we are trying to speak of the same things in different ways, and we seem to be in agreement. To answer your question - I don't think there's anyway to avoid trouble with un-announced r-base uploads. Like every other major package (like for instance htslib in debian-med). A proper binNMU transition coordinated with the release team is the way to go. Randomly bumping a whole compiler will inevitably lead to a situation we are currently in. > So we need to decide what to do. I'm in favour of making either a full > transition or we try to implement the r-graphics-api-* Suggestion[1]. I > personally prefer the later one since its more clean and affects less > packages. Absolutely, I agree that[1] is the way to go. > [1] https://lists.debian.org/debian-r/2023/06/msg00017.html Best, Nilesh signature.asc Description: PGP signature
Bug#1030955: golang-github-hhatto-gorst: autopkgtest failure
Control: tags -1 patch On Thu, Jul 13, 2023 at 03:10:40PM +0530, Pirate Praveen wrote: > On Fri, 10 Feb 2023 00:07:51 +0200 Adrian Bunk wrote: > > The Ubuntu diff contains a patch that looks like a workaround (untested). > > This patch says data directory is reserved for golang autopkgtest in Ubuntu. > Is this the same on debian too? If yes, that looks like a bad idea to me. AFAIK, it uses the standard AUTOPKGTEST_TMP directory which is the standard across debian. I got the same impression on skimming through dh-golang code. As far as fix for your package is concerned, it is as simple as avoiding to remove entire data directory (which is just 28K in size). I'm able to get autopkgtests passing locally. Patch pasted inline. From 7aa6fc7ccf9bb7b938d290bc1e2eab2b324fb7ff Mon Sep 17 00:00:00 2001 From: Nilesh Patra Date: Thu, 13 Jul 2023 21:22:59 +0530 Subject: [PATCH] Avoid removing entire data dir during dh_install step --- debian/rules | 1 - 1 file changed, 1 deletion(-) diff --git a/debian/rules b/debian/rules index c858f56..28c01cd 100755 --- a/debian/rules +++ b/debian/rules @@ -7,5 +7,4 @@ export DH_GOLANG_INSTALL_EXTRA := data override_dh_install: dh_install -O--builddirectory=_build -O--buildsystem=golang -O--with=golang - rm -rf debian/golang-github-hhatto-gorst-dev/usr/share/gocode/src/github.com/hhatto/gorst/data rm -rf debian/golang-github-hhatto-gorst-dev/usr/share/gocode/src/github.com/hhatto/gorst/*.html -- 2.39.2 signature.asc Description: PGP signature
Bug#1041435: bitsnpicas: unusable, chokes with nullptr exception
Package: bitsnpicas Version: 2.0+ds-1 Severity: serious X-Debbugs-Cc: t...@debian.org Dear Maintainer, bitsnpicas is currently unusable and chokes with: $ bitsnpicas Exception in thread "main" java.lang.NullPointerException at java.base/java.io.Reader.(Reader.java:168) at java.base/java.io.InputStreamReader.(InputStreamReader.java:76) at java.base/java.util.Scanner.(Scanner.java:566) at com.kreative.unicode.data.Encoding.(Encoding.java:26) at com.kreative.unicode.data.EncodingList.(EncodingList.java:58) at com.kreative.unicode.data.EncodingList.instance(EncodingList.java:20) at com.kreative.bitsnpicas.edit.GlyphListModelList$GlyphListModelRootNode.(GlyphListModelList.java:93) at com.kreative.bitsnpicas.edit.GlyphListModelList.(GlyphListModelList.java:29) at com.kreative.bitsnpicas.edit.GlyphListPanel.(GlyphListPanel.java:34) at com.kreative.bitsnpicas.edit.BitmapListFrame.(BitmapListFrame.java:19) at com.kreative.bitsnpicas.edit.Main.openFont(Main.java:158) at com.kreative.bitsnpicas.edit.Main.newBitmapFont(Main.java:71) at com.kreative.bitsnpicas.edit.Main.main(Main.java:55) at com.kreative.bitsnpicas.main.Main.main(Main.java:12) This is because of the exclusion of following files w/o patching the code properly main/java/BitsNPicas/src/com/kreative/unicode/mappings/Mac*.txt main/java/BitsNPicas/src/com/kreative/unicode/mappings/Windows*.txt main/java/BitsNPicas/src/com/kreative/unicode/mappings/IBM*.txt I applied a patch trying to exclude unicodes and can get it to a usable state. The patch is attached with this bug report. However, even after being able to launch the menu, I see windows and IBM related unicode options in the menu. I did not dive deep into the code, but it could be stemming from main/java/BitsNPicas/src/com/kreative/unicode/data/unidata.ucd In which case the unicode bin itself contains non-free content and needs fixing accordingly. Thanks, Nilesh -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_IN, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bitsnpicas depends on: ii xdg-utils 1.1.3-4.1 bitsnpicas recommends no packages. bitsnpicas suggests no packages. -- no debconf information diff --git a/main/java/BitsNPicas/Makefile b/main/java/BitsNPicas/Makefile index d339248..3955afc 100644 --- a/main/java/BitsNPicas/Makefile +++ b/main/java/BitsNPicas/Makefile @@ -48,47 +48,16 @@ BitsNPicas.jar: bin jar cmf dep/MANIFEST.MF BitsNPicas.jar -C bin com/kreative/unicode -C bin com/kreative/bitsnpicas chmod +x BitsNPicas.jar -BitsNPicas.app: BitsNPicas-Pre10.15.app BitsNPicas-MacOS10.15.app BitsNPicas-MacOS11.0.app +BitsNPicas.app: BitsNPicas-Pre10.15.app BitsNPicas-Pre10.15.app: dep BitsNPicas.jar - mkdir -p BitsNPicas-Pre10.15.app/Contents/MacOS mkdir -p BitsNPicas-Pre10.15.app/Contents/Resources/Java cp -f dep/PkgInfo BitsNPicas-Pre10.15.app/Contents cp -f dep/Info.plist BitsNPicas-Pre10.15.app/Contents - cp -f dep/universalJavaApplicationStub-Pre10.15 BitsNPicas-Pre10.15.app/Contents/MacOS/BitsNPicas cp -f dep/kbnp*.icns dep/dmov*.icns dep/movr*.icns BitsNPicas-Pre10.15.app/Contents/Resources cp -f dep/*.jar BitsNPicas-Pre10.15.app/Contents/Resources/Java cp -f BitsNPicas.jar BitsNPicas-Pre10.15.app/Contents/Resources/Java -BitsNPicas-MacOS10.15.app: dep BitsNPicas.jar - mkdir -p BitsNPicas-MacOS10.15.app/Contents/MacOS - mkdir -p BitsNPicas-MacOS10.15.app/Contents/Resources/Java - cp -f dep/PkgInfo BitsNPicas-MacOS10.15.app/Contents - cp -f dep/Info.plist BitsNPicas-MacOS10.15.app/Contents - cp -f dep/universalJavaApplicationStub-MacOS10.15 BitsNPicas-MacOS10.15.app/Contents/MacOS/BitsNPicas - cp -f dep/kbnp*.icns dep/dmov*.icns dep/movr*.icns BitsNPicas-MacOS10.15.app/Contents/Resources - cp -f dep/*.jar BitsNPicas-MacOS10.15.app/Contents/Resources/Java - cp -f BitsNPicas.jar BitsNPicas-MacOS10.15.app/Contents/Resources/Java - -BitsNPicas-MacOS11.0.app: dep BitsNPicas.jar - mkdir -p BitsNPicas-MacOS11.0.app/Contents/MacOS - mkdir -p BitsNPicas-MacOS11.0.app/Contents/Resources/Java - cp -f dep/PkgInfo BitsNPicas-MacOS11.0.app/Contents - cp -f dep/Info.plist BitsNPicas-MacOS11.0.app/Contents - cp -f dep/universalJavaApplicationStub-MacOS11.0 BitsNPicas-MacOS11.0.app/Contents/MacOS/BitsNPicas - cp -f dep/kbnp*.icns dep/dmov*.icns dep/movr*.icns BitsNPicas-MacOS11.0.app/Contents/Resources - cp -f dep/*.jar BitsNPicas-MacOS11.0.app/Contents/Resources/Java - cp -f BitsNPicas.jar BitsNPicas-MacOS11.0.app/Contents/Resources/Java - -BitsNPicas.dmg: BitsNPicas.app - mkdir -p dmgtmp - cp -R BitsNPicas-Pre10.15.app dmgtmp - cp -R
Bug#1041451: gmap: FTBFS on all !amd64 archs
Source: gmap Version: 2023-06-01+ds-1 Severity: serious Dear Maintainer, gmap fails to build on all architectures except amd64. It compiles, but seems to fail it's build time tests, in particular align.test > 138435 AACAGCTA > > 4617 AACAGCTA > > FAIL align.test (exit status: 1) Testsuite summary for gmap 2023-06-01 # TOTAL: 4 # PASS: 3 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_IN, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
On Sun, 23 Jul 2023 07:15:09 -0500 Dirk Eddelbuettel wrote > Is this is not an example of a release manager override? The affectect > packages all work together in unstable and could migrate. How do you conclude that? The versions of affected packages are same in unstable and testing. They fail in i386 with a newer version of lme4. Best, Nilesh signature.asc Description: PGP signature
Bug#1041435: fixed in bitsnpicas 2.0+ds-2
Control: reopen -1 Control: retitle -1 bitsnpicas: Contains potentially non-free binary unicode data Control: found -1 2.0+ds-2 On Mon, 24 Jul 2023 13:20:33 + Debian FTP Masters wrote: > bitsnpicas (2.0+ds-2) unstable; urgency=medium > . >* Apply patch to fix usability. (Closes: #1041435) > Thank you Nilesh Patra. Thanks for applying my patch, it is atleast usable now. However, this part of the bug still remains un-fixed, which would mean potentially pushing non-free software into main. I've thus retitled the bug and reopened it. Best, Nilesh signature.asc Description: PGP signature
Bug#1027811: libcifpp-data: uninstallable
Hi Maarten/Patrice,
On Tue, 03 Jan 2023 17:23:19 +0100 Patrice DUROUX
wrote:
> Package: libcifpp-data
> Version: 5.0.5-5
> Severity: normal
>
> Dear Maintainer,
>
> Here is the output:
>
> Setting up libcifpp-data (5.0.5-5) ...
> /etc/cron.weekly/update-libcifpp-data: 9: Syntax error: "then" unexpected
> dpkg: error processing package libcifpp-data (--configure):
> installed libcifpp-data package post-installation script subprocess returned
> error exit status 2
>
>
> This script contains a duplicated 'then' directive:
>
> 8if [ "${euid}" -ne 0 ] ; then
> 9then echo "Please run as root"
> 10exit
> 11fi
This is fixed in the latest upload right - could you check?
If so, could you close this bug report?
--
Best,
Nilesh
signature.asc
Description: PGP signature
Bug#1026590: marked as pending in dask.distributed
Control: tag -1 pending Hello, Bug #1026590 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/39467213cd97c1acaed89ead0286568f49e069a5 Cherry-pick and tweak upstream patch to fix FTBFS with py3.11 (Closes: #1026590) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026590
Bug#976506: Fix for bullseye
On 9 January 2023 8:11:11 pm IST, Santiago Vila wrote: >reopen 976506 >found 976506 1.7.2-1 >found 976506 1.7.2-2 >fixed 976506 2.0.1-1 >thanks > >Hi. Please consider fixing this in stable as well, >as packages in stable must build in stable. > >If you have never done an upload for stable, the procedure >is documented here: > >https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions > >I would make an upload proposal in the form of debdiff, but I'm unsure >about backporting the fix in unstable to stable in this case, because >I don't really understand it. I will not do it, it is not worth the effort. The package is functional, it fails a test due to the date being set in 2021, and this fails upstream as well as they confirmed it. Thanks.
Bug#1027209: marked as pending in pyzmq
Control: tag -1 pending Hello, Bug #1027209 in pyzmq 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/pyzmq/-/commit/8d2ed46be2a65f2b132e0e71205f7a02f1926d84 Add patch to increase test timeout (Closes: #1027209) (this message was generated automatically) -- Greetings https://bugs.debian.org/1027209
Bug#1028609: deepin-terminal: FTBFS -- Build dependency uninstallable
Package: deepin-terminal Version: 5.2.11-1+b4 Severity: serious X-Debbugs-Cc: a...@debian.org, by...@debian.org Dear Maintainer, deepin-terminal FTBFS because of not being able to install its B-Ds. Some B-D (transitively?) depends on qtbase-abi-5-15-7 which is not installable due to being a virtual package. But I leave that onto you to check further. | Install main build dependencies (apt-based resolver) | | | Installing build dependencies | Reading package lists... | Building dependency tree... | Reading state information... | Some packages could not be installed. This may mean that you have | requested an impossible situation or if you are using the unstable | distribution that some required packages have not yet been created | or been moved out of Incoming. | The following information may help to resolve the situation: | | The following packages have unmet dependencies: | libdtkgui5 : Depends: qtbase-abi-5-15-7 but it is not installable | libdtkwidget5 : Depends: qtbase-abi-5-15-7 but it is not installable | libqt5designer5 : Depends: qtbase-abi-5-15-7 but it is not installable | qttools5-dev-tools : Depends: qt5-assistant (= 5.15.7-2) but it is not going to be installed | Depends: libqt5quick5 (>= 5.15.7+dfsg~) but it is not going to be installed or | libqt5quick5-gles (>= 5.15.7+dfsg~) but it is not going to be installed | Depends: libqt5quickwidgets5 (>= 5.15.7+dfsg~) but it is not going to be installed | Depends: libqt5webkit5 (>= 5.212.0~alpha4-8~) but it is not going to be installed | Depends: qtbase-abi-5-15-7 but it is not installable | Depends: qtdeclarative-abi-5-15-7 | E: Unable to correct problems, you have held broken packages. Thanks. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages deepin-terminal depends on: ii expect5.45.4-2+b1 ii libatspi2.0-0 2.46.0-4 ii libc6 2.36-7 ii libdframeworkdbus25.5.22-1 ii libdtkcore5 5.5.33-1+b2 ii libdtkgui55.5.25-1+b2 ii libdtkwidget5 5.5.48-1+b2 ii libgcc-s1 12.2.0-13 ii libglib2.0-0 2.74.4-1 ii libqt5core5a [qtbase-abi-5-15-7] 5.15.7+dfsg-2 ii libqt5dbus5 5.15.7+dfsg-2 ii libqt5gui55.15.7+dfsg-2 ii libqt5widgets55.15.7+dfsg-2 ii libstdc++612.2.0-13 ii zssh 1.5c.debian.1-8 deepin-terminal recommends no packages. deepin-terminal suggests no packages. -- no debconf information
Bug#1027215: How much do we lose if we remove theano (+keras, deepnano, invesalius)?
On Sat, Jan 14, 2023 at 11:12:07AM +, Rebecca N. Palmer wrote: > theano has been mostly abandoned upstream since 2018. (The Aesara fork is > not abandoned, but includes interface changes including the import name, so > would break reverse dependencies not specifically altered for it.) > > Its reverse dependencies are keras, deepnano and invesalius. keras is already orphaned, it needs to be updated either now or later. And it depends heavily on tensorflow, python bindigs of which are still not in yet. deepnano is also kind of abandoned. Last commit is from 2017. On grepping the code for invesalius, I see that it only uses theano as an option for backend. There are three backends as far as I can see, torch, plaidml (not in debian) and theano. So as long as torch works, this _probably_ should do fine here. In any case, the upstream for this package is active and we can ask them. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1028675: defcon: FTBFS: distutils.errors.DistutilsError: Command '['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmpyii6c34w', '--quiet', 'to
Control: tags -1 unreproducible Control: tags -1 moreinfo Control: severity -1 important Hi Lucas, On Sat, 14 Jan 2023 13:39:00 +0100 Lucas Nussbaum wrote: Source: defcon Version: 0.10.1-1 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20230113 ftbfs-bookworm Relevant part (hopefully): > debian/rules binary > dh binary --with python3,sphinxdoc --buildsystem=pybuild >dh_update_autotools_config -O--buildsystem=pybuild >dh_autoreconf -O--buildsystem=pybuild >dh_auto_configure -O--buildsystem=pybuild > I: pybuild base:240: python3.10 setup.py config > /usr/lib/python3/dist-packages/setuptools/config/setupcfg.py:508: SetuptoolsDeprecationWarning: The license_file parameter is deprecated, use license_files instead. > warnings.warn(msg, warning_class) > /usr/lib/python3/dist-packages/setuptools/installer.py:27: SetuptoolsDeprecationWarning: setuptools.installer is deprecated. Requirements should be satisfied by a PEP 517 installer. > warnings.warn( > WARNING: The wheel package is not available. > /usr/bin/python3.10: No module named pip > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 82, in fetch_build_egg > subprocess.check_call(cmd) > File "/usr/lib/python3.10/subprocess.py", line 369, in check_call > raise CalledProcessError(retcode, cmd) > subprocess.CalledProcessError: Command '['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmpyii6c34w', '--quiet', 'tomli>=1.0.0']' returned non-zero exit status 1. I can't reproduce this in a clean unstable chroot. Nor do I see any dependency on tomli anywhere in the code, and setuptools seems to be doing fine. Could you please consider to do a re-build and see if it works for you and this wasn't a one-off? Thanks Nilesh
Bug#1026634: marked as pending in yarl
Control: tag -1 pending Hello, Bug #1026634 in yarl 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/yarl/-/commit/87712024d2ed9d42b93cfbee615a6c3e33ffcb54 Cherry-pick upstream commit to fix FTBFS (Closes: #1026634) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026634
Bug#1028748: bottleneck: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.11" returned exit code 13
There is one hacky way to get this moving, and the package build with the patch. But not sure if it should be applied or not (as this is ugly) I am not adding a patch tag for the same reason. Have also mentioned this as a comment in upstream issue. --- a/bottleneck/slow/move.py +++ b/bottleneck/slow/move.py @@ -232,8 +232,9 @@ # At least one dimension has length 0 shape = list(a.shape) shape.pop(axis) -r = np.empty(shape, dtype=a.dtype) +r = np.empty(shape, dtype=float) r.fill(np.nan) +r = r.astype(a.dtype) if (r.ndim == 0) and (r.size == 1): r = np.nan return r
Bug#1028774: macsyfinder: FTBFS: RuntimeError: cannot join current thread
Hi Lucas, On Sat, 14 Jan 2023 13:41:14 +0100 Lucas Nussbaum wrote: Source: macsyfinder Version: 2.0-1 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20230113 ftbfs-bookworm >dh_auto_test -O--buildsystem=pybuild > I: pybuild base:240: python3.11 setup.py test > running test > WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox. > running egg_info > creating MacSyFinder.egg-info It passes for me in a clean unstable chroot. Could you please check if this is still persistent or was just a on-off thing? Thanks Nilesh
Bug#1028774: macsyfinder: FTBFS: RuntimeError: cannot join current thread
On Sun, Jan 15, 2023 at 10:08:18AM +0100, Lucas Nussbaum wrote: > On 15/01/23 at 12:20 +0530, Nilesh Patra wrote: > > It passes for me in a clean unstable chroot. Could you please check if this > > is still persistent or was just a on-off thing? > > I can still reproduce I tried building it in a porter box, able to get it going w/o issues. Then I also triggered salsa CI for the same and it succeeds there[1] Could you maybe share the details/configuration of the machine you are building this on? [1]: https://salsa.debian.org/med-team/macsyfinder/-/pipelines/485121 -- Best, Nilesh signature.asc Description: PGP signature
Bug#1028774: macsyfinder: FTBFS: RuntimeError: cannot join current thread
On Sun, Jan 15, 2023 at 02:02:15PM +0100, Santiago Vila wrote: > I can reproduce this build failure on Hetzner virtual machines with 2 CPUs, > where it fails randomly 50% of the time. > > Therefore, to reproduce the randomness, you have to try many times. I built it 50 times on barriere.debian.org (4 CPUs) and did not hit the failure even once. I don't think I have the time/energy for further debug this any further; I'd have tried if it was properly reproducible. Admittedly, I am a bit tempted to lower the severity. My hunch is quite strong that this would work on buildd infra. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
On Wed, 21 Dec 2022 12:32:25 +0100 olivier sallou wrote: > On Wed, 2022-12-21 at 11:02 +0100, olivier sallou wrote: > > looks like a python3 issue (though was already adapter to py3...) > > > > will have a look and reproduce > > I could reproduce and found an issue with demo_checker.py handling with > python3 > > I have a patch. will test it and upload I wrote a patch as well, and was going to upload, but you beat me to it, hah :/ My patch is quite similar to yours, though. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1022404: raqm: diff for NMU version 0.7.0-4.1
On Sat, 19 Nov 2022 21:19:24 +0200 Adrian Bunk wrote: > Control: tags 1022404 + patch > Control: tags 1022404 + pending > > Dear maintainer, > > I've prepared an NMU for raqm (versioned as 0.7.0-4.1) and uploaded > it to DELAYED/15. Please feel free to tell me if I should cancel it. It has been 15 days past your upload but it has not reflected yet in the archive. Did you happen to cancel your NMU? -- Best, Nilesh signature.asc Description: PGP signature
Bug#1026608: marked as pending in jcommander
Control: tag -1 pending Hello, Bug #1026608 in jcommander 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/java-team/jcommander/-/commit/faa56c48a90d96905c35775ee83741ee4a610f1b Add patch to fix FTBFS (Closes: #1026608) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026608
Bug#1026586: marked as pending in python-asyncssh
Control: tag -1 pending Hello, Bug #1026586 in python-asyncssh 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-asyncssh/-/commit/8a5e69ad67f6fdd3bbcdfca1f7ddb3a2558c1009 Cherry-pick upstream patch to fix FTBFS with python3.11 (Closes: #1026586) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026586
Bug#1026512: marked as pending in ruby-prof
Control: tag -1 pending Hello, Bug #1026512 in ruby-prof 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/ruby-team/ruby-prof/-/commit/74ec3f804170b2e8b71ffc6b433d4307fb350d06 d/ruby-tests.rake: Use t.verbose instead of passing verbose in t.options (Closes: #1026512) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026512
Bug#1025778: autoremoval
On 12/23/22 15:07, Maarten L. Hekkelman wrote: Hi, Something is going wrong, somewhere. I prepared packages to upgrade libcifpp and everything depending on it. Pushed some other stuff into testing also as a preparation and submitted a 'bug' asking for a time slot to transition both libcifpp and libpdb-redo. Sebastian has set the release tracker, see[1][2] What followed was a long period of silence. Release team made a bit of indication 4 days back. Please ping them on the bug (maybe CC sramacher@d.o) and ask when could they schedule the BinNMUs And then I got a notice that density-fitness, libpdb-redo and libnewuoa are about to be removed from testing. Replying to the bug report that threatens removal of these packages should reset the auto-rm counter. You may notice that I've CC'ed the bug report so this should serve the purpose. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024893;msg=11 [2]: https://release.debian.org/transitions/html/auto-libcifpp.html -- Best, Nilesh
Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0
On Sat, 10 Dec 2022 18:07:53 +0530 Nilesh Patra wrote: > On Mon, 28 Nov 2022 21:05:07 + Tobias Hansen wrote: > > On 11/27/22 19:24, Nilesh Patra wrote: > > > On Sun, Nov 27, 2022 at 05:35:17PM +, Tobias Hansen wrote: > > >> On 11/27/22 06:37, Nilesh Patra wrote: > > >>> Tobias, since this is done, would you consider to check sagemath now > > >>> and get the ball rolling? :-) > > >> Hi, > > >> > > >> I actually tried building with the new pari and gap versions a while ago > > >> (using sagemath 9.5 with upstream patches for the new pari and gap > > >> versions, I pushed them to the git repo today) and got stuck with a lot > > >> of errors like this (might be unrelated to pari and gap): > > > I am having a hard time building/reproducing this because sage tends to > > > need a lot of compute power that I currently do not have, and it takes > > > forever to porter box too. > > > But looking at the error, my hunch is that this is a setuptools related > > > monkeypatch issue (there are similar RC bugs filed for many packages). So > > > re-ordering cython import > > > in sage/misc/cython.py file after setuptools along with ensuring > > > distutils is imported after setuptools will (very) likely help. > > > > > > Here is a related link that I found for the same > > > > > > > > > https://stackoverflow.com/questions/21594925/error-each-element-of-ext-modules-option-must-be-an-extension-instance-or-2-t > > > > > Thanks. The attached patch removed the error, but now there are these > > warnings when cython is used in doctests: > > > > UserWarning: Distutils was imported before Setuptools, but importing > > Setuptools also replaces the `distutils` module in `sys.modules`. > > > > Apologies for late response. I suppose the line above is the crux? setuptools > monkey-patches distutils so it should be imported _before_ distutils. > Somewhere in the doctests, it is other way round and hence the error. > > Did you get a chance to build sage yet? Sorry to pester you, but since softfreeze is near - did you happen to have any update about this yet? Can I be of help in any way? Let me know. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1026500: marked as pending in pexpect
Control: tag -1 pending Hello, Bug #1026500 in pexpect 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/pexpect/-/commit/00023268e170ef850d2ecaf01eee8b47d7be0e98 Add patch to fix FTBFS with python3.11 (Closes: #1026500) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026500
Bug#1026570: python-streamz: FTBFS: ValueError: I/O operation on closed file.
Control: fix blocked by 1026590 Pretty sure this stems from dask.distributed itself, as I see similar error messages there. On Tue, 20 Dec 2022 18:23:56 +0100 Lucas Nussbaum wrote: > Source: python-streamz > Version: 0.6.3-3 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20221220 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > debian/rules binary > > dh binary --with python3 --buildsystem=pybuild > >dh_update_autotools_config -O--buildsystem=pybuild > >dh_autoreconf -O--buildsystem=pybuild > >dh_auto_configure -O--buildsystem=pybuild > > I: pybuild base:240: python3.11 setup.py config > > running config > > I: pybuild base:240: python3.10 setup.py config > > running config > >dh_auto_build -O--buildsystem=pybuild > > I: pybuild base:240: /usr/bin/python3.11 setup.py build > > running build > > running build_py > > creating /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/graph.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/__init__.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/dask.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/orderedweakset.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/plugins.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/core.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/utils_test.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/sources.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/collection.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/batch.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/sinks.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > copying streamz/utils.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz > > creating > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe > > copying streamz/dataframe/__init__.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe > > copying streamz/dataframe/core.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe > > copying streamz/dataframe/aggregations.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe > > copying streamz/dataframe/utils.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe > > creating /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > copying streamz/tests/__init__.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > copying streamz/tests/py3_test_core.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > copying streamz/tests/test_plugins.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > copying streamz/tests/test_sinks.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > copying streamz/tests/test_core.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > copying streamz/tests/test_batch.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > copying streamz/tests/test_sources.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > copying streamz/tests/test_graph.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > copying streamz/tests/test_dask.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > copying streamz/tests/test_kafka.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/tests > > creating > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe/tests > > copying streamz/dataframe/tests/test_dataframe_utils.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe/tests > > copying streamz/dataframe/tests/test_dataframes.py -> > > /<>/.pybuild/cpython3_3.11_streamz/build/streamz/dataframe/tests -- Best, Nilesh signature.asc Description: PGP signature
Bug#1027061: sqlmodel -- FTBFS with python3.11
Source: sqlmodel Version: 0.0.8-1 Severity: serious X-Debbugs-Cc: mo...@debian.org Hi, sqlmodel FTBFS with tonnes of: I: pybuild base:240: PYTHONPATH=/<> python3.11 -m pytest -k 'not test_create_db_and_table' = test session starts == platform linux -- Python 3.11.1, pytest-7.2.0, pluggy-1.0.0+repack rootdir: /<> plugins: anyio-3.6.2 collected 83 items / 25 errors / 3 deselected / 80 selected ERRORS _ ERROR collecting docs_src/tutorial/fastapi/app_testing/tutorial001/test_main.py _ ImportError while importing test module '/<>/docs_src/tutorial/fastapi/app_testing/tutorial001/test_main.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: /usr/lib/python3.11/importlib/__init__.py:126: in import_module return _bootstrap._gcd_import(name[level:], package, level) docs_src/tutorial/fastapi/app_testing/tutorial001/test_main.py:2: in from fastapi.testclient import TestClient /usr/lib/python3/dist-packages/fastapi/testclient.py:1: in from starlette.testclient import TestClient as TestClient # noqa /usr/lib/python3/dist-packages/starlette/testclient.py:16: in import httpx E ModuleNotFoundError: No module named 'httpx' _ ERROR collecting docs_src/tutorial/fastapi/app_testing/tutorial001/test_main_001.py _ ImportError while importing test module '/<>/docs_src/tutorial/fastapi/app_testing/tutorial001/test_main_001.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: /usr/lib/python3.11/importlib/__init__.py:126: in import_module return _bootstrap._gcd_import(name[level:], package, level) docs_src/tutorial/fastapi/app_testing/tutorial001/test_main_001.py:1: in from fastapi.testclient import TestClient /usr/lib/python3/dist-packages/fastapi/testclient.py:1: in from starlette.testclient import TestClient as TestClient # noqa /usr/lib/python3/dist-packages/starlette/testclient.py:16: in import httpx E ModuleNotFoundError: No module named 'httpx' _ ERROR collecting docs_src/tutorial/fastapi/app_testing/tutorial001/test_main_002.py _ ImportError while importing test module '/<>/docs_src/tutorial/fastapi/app_testing/tutorial001/test_main_002.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: /usr/lib/python3.11/importlib/__init__.py:126: in import_module return _bootstrap._gcd_import(name[level:], package, level) docs_src/tutorial/fastapi/app_testing/tutorial001/test_main_002.py:1: in from fastapi.testclient import TestClient /usr/lib/python3/dist-packages/fastapi/testclient.py:1: in from starlette.testclient import TestClient as TestClient # noqa /usr/lib/python3/dist-packages/starlette/testclient.py:16: in import httpx E ModuleNotFoundError: No module named 'httpx' -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1027062: python3-sqlmodel -- Uninstallable with new sqlalchemy in unstable
Package: python3-sqlmodel Version: 0.0.8-1 Severity: serious X-Debbugs-Cc: mo...@debian.org Hi, The pyproject.toml of sqlmodel enforces a strictly less than dep on sqlalchemy version 1.4.41 however the current version of sqlalchemy in unstable is 1.4.45, and hence sqlmodel is unstallable. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-sqlmodel depends on: ii python33.10.6-1 pn python3-pydantic pn python3-sqlalchemy pn python3-typing-extensions python3-sqlmodel recommends no packages. python3-sqlmodel suggests no packages.
Bug#1027063: python3-ormar uninstallable with current sqlalchemy in unstable
Package: python3-ormar Version: 0.12.0-1 Severity: serious X-Debbugs-Cc: edw...@4angle.com Hi, The pyproject.toml of ormar declares a strictly less than dep for sqlalchemy <1.4.42 but the current sqlalchemy version in unstable is 1.4.45, and hence it is uninstallable at the moment. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-ormar depends on: ii python3 3.10.6-1 pn python3-databases ii python3-importlib-metadata 4.12.0-1 pn python3-pydantic pn python3-sqlalchemy python3-ormar recommends no packages. python3-ormar suggests no packages.
Bug#1026590: dask.distributed: FTBFS: RuntimeError: IOLoop is closed
Hi Diane, It seems that dask.distributed's current version in unstable is python3.11-incompatible, which is breaking a bunch of stuff. Could you please consider fixing it and closing the bug? On Tue, 20 Dec 2022 18:20:11 +0100 Lucas Nussbaum wrote: > Source: dask.distributed > Version: 2022.02.0+ds.1-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20221220 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > rm -f distributed/comm/tests/__init__.py > > set -e; \ > > for p in distributed/http/static/js/anime.js > > distributed/http/static/js/reconnecting-websocket.js; do \ > > uglifyjs -o $p debian/missing-sources/$p ; \ > > done > > chmod a-x distributed/tests/test_utils_test.py > > dh_auto_build > > I: pybuild base:240: /usr/bin/python3.11 setup.py build > > /usr/lib/python3/dist-packages/setuptools/dist.py:530: UserWarning: > > Normalizing '2022.02.0+ds.1' to '2022.2.0+ds.1' > > warnings.warn(tmpl.format(**locals())) > > running build > > running build_py > > creating > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/__init__.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/worker.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/pytest_resourceleaks.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/queues.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/counter.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/core.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/variable.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/system_monitor.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/threadpoolexecutor.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/asyncio.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/bokeh.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/security.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/versions.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/locket.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/preloading.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/actor.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/objects.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/_ipython_utils.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/semaphore.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/spill.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/batched.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/stealing.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/client.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/metrics.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/lock.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/utils_test.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/sizeof.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/compatibility.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/profile.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/nanny.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed > > copying distributed/event.py -> > > /<>/.pybuild/cpython3_3.11_distributed/build/distributed -- Best, Nilesh signature.asc Description: PGP signature
Bug#1027138: sqlmodel -- autopkgtests FAIL
Source: sqlmodel
Version: 0.0.8-2
Severity: serious
X-Debbugs-Cc: mo...@debian.org
Hi,
Autopkgtest for new upload of sqlmodel are failing with
| # Test inherited indexes
|insp: Inspector = inspect(mod.engine)
|indexes = insp.get_indexes(str(mod.Hero.__tablename__))
|expected_indexes = [
|{"name": "ix_hero_age", "dialect_options": {}, "column_names":
["age"], "unique": 0},
|{"name": "ix_hero_name", "dialect_options": {}, "column_names":
["name"], "unique": 0},
|]
|for index in expected_indexes:
| > assert index in indexes, "This expected index should be in the
indexes in DB"
| E AssertionError: This expected index should be in the indexes in DB
| E assert {'column_names': ['age'], 'dialect_options': {}, 'name':
'ix_hero_age', 'unique': 0} in [{'column_names': ['age'], 'name':
'ix_hero_age', 'unique': 0}, {'column_names': ['name'], 'name': 'ix_hero_name',
'unique': 0}]
Full log:
https://ci.debian.net/data/autopkgtest/testing/amd64/s/sqlmodel/29756092/log.gz
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1015322: marked as pending in ruby-kyotocabinet
Control: tag -1 pending Hello, Bug #1015322 in ruby-kyotocabinet 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/ruby-team/ruby-kyotocabinet/-/commit/816c2438a6babc6f40b02ad14c088d41ec6f7afd Add patch to fix FTBFS with ruby3.1 (Closes: #1015322) (this message was generated automatically) -- Greetings https://bugs.debian.org/1015322
Bug#1027335: pairtools -- FTBFS in unstable
Source: pairtools Version: 0.3.0-3.2 Severity: serious Pairtools FTBFS with pysam related error. Looks like something is off. dh_auto_clean I: pybuild base:240: python3.11 setup.py clean Traceback (most recent call last): File "/<>/setup.py", line 130, in ext_modules=get_ext_modules(), ^ File "/<>/setup.py", line 81, in get_ext_modules extra_link_args=pysam.get_libraries(), ^ File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 100, in get_libraries return [os.path.join(dirname, x + so) for x in pysam_libs] ^^^ File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 100, in return [os.path.join(dirname, x + so) for x in pysam_libs] ~~^~~~ TypeError: can only concatenate str (not "NoneType") to str Thanks, Nilesh -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1027335: pairtools -- FTBFS in unstable
On Fri, 30 Dec 2022 20:05:32 +0530 Nilesh Patra wrote:
> Source: pairtools
> Version: 0.3.0-3.2
> Severity: serious
>
> Pairtools FTBFS with pysam related error. Looks like
> something is off.
>
> dh_auto_clean
> I: pybuild base:240: python3.11 setup.py clean
> Traceback (most recent call last):
>
>
> File "/<>/setup.py", line 130, in
> ext_modules=get_ext_modules(),
> ^
> File "/<>/setup.py", line 81, in get_ext_modules
> extra_link_args=pysam.get_libraries(),
> ^
> File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 100, in
> get_libraries
> return [os.path.join(dirname, x + so) for x in pysam_libs]
>^^^
> File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 100, in
>
> return [os.path.join(dirname, x + so) for x in pysam_libs]
> ~~^~~~
> TypeError: can only concatenate str (not "NoneType") to str
This patch in pysam gets the build in pairtools going beyond this point, but
now the build chokes with:
| pairtools.cli (unittest.loader._FailedTest.pairtools.cli) ... ERROR
| pairtools.lib (unittest.loader._FailedTest.pairtools.lib) ... ERROR
|
| ==
| ERROR: pairtools.cli (unittest.loader._FailedTest.pairtools.cli)
| --
| ImportError: Failed to import test module: pairtools.cli
| Traceback (most recent call last):
| File "/usr/lib/python3.11/unittest/loader.py", line 440, in _find_test_path
|package = self._get_module_from_name(name)
|
| File "/usr/lib/python3.11/unittest/loader.py", line 350, in
_get_module_from_name
|__import__(name)
| File
"/<>/.pybuild/cpython3_3.11/build/pairtools/cli/__init__.py", line
188, in
|from . import (
| File "/<>/.pybuild/cpython3_3.11/build/pairtools/cli/dedup.py",
line 12, in
|from ..lib import fileio, pairsam_format, headerops
| File
"/<>/.pybuild/cpython3_3.11/build/pairtools/lib/__init__.py", line
7, in
|from . import parse
| File "/<>/.pybuild/cpython3_3.11/build/pairtools/lib/parse.py",
line 38, in
|from .parse_pysam import get_mismatches_c
| ImportError:
/<>/.pybuild/cpython3_3.11/build/pairtools/lib/parse_pysam.cpython-311-x86_64-linux-gnu.so:
undefined symbol: bam_dup1
Description: Add patch to return proper sysconf so for current python
Author: Nilesh Patra
Last-Update: 2022-12-30
--- a/pysam/__init__.py
+++ b/pysam/__init__.py
@@ -96,5 +96,7 @@
if pysam.config.HTSLIB == "builtin":
pysam_libs.append('libchtslib')
-so = sysconfig.get_config_var('SO')
+so = sysconfig.get_config_var('EXT_SUFFIX')
+if not so:
+so = sysconfig.get_config_var('SO')
return [os.path.join(dirname, x + so) for x in pysam_libs]
signature.asc
Description: PGP signature
Bug#1027335: pairtools -- FTBFS in unstable
Control: severity -1 normal
Control: retitle -1 pairtools -- current repo in salsa FTBFS
Control: clone -1 -2
Control: reassign -2 python3-pysam 0.20.0+ds-2
Control: retitle -2 pysam -- no definition for bam_dup1
On Fri, Dec 30, 2022 at 08:24:42PM +0530, Nilesh Patra wrote:
> On Fri, 30 Dec 2022 20:05:32 +0530 Nilesh Patra wrote:
> > Source: pairtools
> > Version: 0.3.0-3.2
> > Severity: serious
> >
> > Pairtools FTBFS with pysam related error. Looks like
> > something is off.
> >
> > dh_auto_clean
> > I: pybuild base:240: python3.11 setup.py clean
> > Traceback (most recent call last):
> >
> >
> > File "/<>/setup.py", line 130, in
> > ext_modules=get_ext_modules(),
> > ^
> > File "/<>/setup.py", line 81, in get_ext_modules
> > extra_link_args=pysam.get_libraries(),
> > ^
> > File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 100, in
> > get_libraries
> > return [os.path.join(dirname, x + so) for x in pysam_libs]
> >^^^
> > File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 100, in
> >
> > return [os.path.join(dirname, x + so) for x in pysam_libs]
> > ~~^~~~
> > TypeError: can only concatenate str (not "NoneType") to str
>
> This patch in pysam gets the build in pairtools going beyond this point, but
> now the build chokes with:
>
> | pairtools.cli (unittest.loader._FailedTest.pairtools.cli) ... ERROR
>
>
> | pairtools.lib (unittest.loader._FailedTest.pairtools.lib) ... ERROR
> |
> | ==
> | ERROR: pairtools.cli (unittest.loader._FailedTest.pairtools.cli)
> | --
> | ImportError: Failed to import test module: pairtools.cli
> | Traceback (most recent call last):
> | File "/usr/lib/python3.11/unittest/loader.py", line 440, in _find_test_path
> |package = self._get_module_from_name(name)
> |
> | File "/usr/lib/python3.11/unittest/loader.py", line 350, in
> _get_module_from_name
> |__import__(name)
> | File
> "/<>/.pybuild/cpython3_3.11/build/pairtools/cli/__init__.py",
> line 188, in
> |from . import (
> | File
> "/<>/.pybuild/cpython3_3.11/build/pairtools/cli/dedup.py", line
> 12, in
> |from ..lib import fileio, pairsam_format, headerops
> | File
> "/<>/.pybuild/cpython3_3.11/build/pairtools/lib/__init__.py",
> line 7, in
> |from . import parse
> | File
> "/<>/.pybuild/cpython3_3.11/build/pairtools/lib/parse.py", line
> 38, in
> |from .parse_pysam import get_mismatches_c
> | ImportError:
> /<>/.pybuild/cpython3_3.11/build/pairtools/lib/parse_pysam.cpython-311-x86_64-linux-gnu.so:
> undefined symbol: bam_dup1
Turns out this is because there is just a function "declaration" in
pysam/libchtslib.pxd for bam_dup1.
But the headers imported do not even have the function.
I patched the current package in salsa to get the ball rolling. But this needs
bioframe.
Also, the below patch still needs to be applied to pysam. pushed to salsa.
> Description: Add patch to return proper sysconf so for current python
> Author: Nilesh Patra
> Last-Update: 2022-12-30
> --- a/pysam/__init__.py
> +++ b/pysam/__init__.py
> @@ -96,5 +96,7 @@
> if pysam.config.HTSLIB == "builtin":
> pysam_libs.append('libchtslib')
>
> -so = sysconfig.get_config_var('SO')
> +so = sysconfig.get_config_var('EXT_SUFFIX')
> +if not so:
> +so = sysconfig.get_config_var('SO')
> return [os.path.join(dirname, x + so) for x in pysam_libs]
>
--
Best,
Nilesh
signature.asc
Description: PGP signature
Bug#1027629: python-biopython: FTBFS: Test DSSP generation from MMCIF with non-standard residues.
Hi Maarten,
This seems to stem from your latest upload of dssp. Could you consider taking
a look at this one?
Thanks,
Nilesh
On Sun, 1 Jan 2023 15:20:12 +0100 Lucas Nussbaum wrote:
> Source: python-biopython
> Version: 1.80+dfsg-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230101 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > mkdir -p Tests_avoid
> > for avoid in PAML_tools EmbossPhylipNew MSAProbs_tool NACCESS_tool
> > PopGen_GenePop PopGen_GenePop_EasyController XXmotif_tool PDB_ResidueDepth
> > mmtf mmtf_online BioSQL_MySQLdb BioSQL_psycopg2 \
> > ; do \
> > mv Tests/test_${avoid}.py Tests_avoid ; \
> > done
> > mv: cannot stat 'Tests/test_NACCESS_tool.py': No such file or directory
> > # For the doc package we need a clean testsuite without all the remaining
> > files. So keep a clean copy here
> > mkdir -p debian/tmp_tests
> > cp -a Tests debian/tmp_tests
> > # remove duplicated file
> > rm -f debian/tmp_tests/Tests/Quality/example.fastq.gz
> > # We also keep the tests we need to avoid for later inspection
> > cp -a Tests_avoid debian/tmp_tests
> > # in the Debian package dialign it is not needed to set DIALIGN2_DIR but
> > the test is verifying this dir
> > # to run the EMBOSS test test_Emboss also requires to have the environment
> > variable EMBOSS_ROOT set
> > LC_ALL=C.UTF-8 dh_auto_test -- --test --system=custom \
> > --test-args='set -e; \
> > mkdir -p {build_dir}/home; \
> > mkdir -p {build_dir}/Doc/examples; \
> > cp -a Doc/Tutorial.tex {build_dir}/Doc; \
> > cp -a Doc/Tutorial {build_dir}/Doc; \
> > cp -a Doc/examples {build_dir}/Doc; \
> > cp -a Tests {build_dir}; \
> > cd {build_dir}/Tests; \
> > env DIALIGN2_DIR=/usr/share/dialign
> > EMBOSS_ROOT=/usr/lib/emboss HOME={build_dir}/home {interpreter}
> > run_tests.py --offline'
> > pybuild --test -i python{version} -p "3.11 3.10" --test --system=custom
> > "--test-args=set -e; \\\
> > mkdir -p {build_dir}/home; \\\
> > mkdir -p {build_dir}/Doc/examples; \\\
> > cp -a Doc/Tutorial.tex {build_dir}/Doc; \\\
> > cp -a Doc/Tutorial {build_dir}/Doc; \\\
> > cp -a Doc/examples {build_dir}/Doc; \\\
> > cp -a Tests {build_dir}; \\\
> > cd {build_dir}/Tests; \\\
> > env DIALIGN2_DIR=/usr/share/dialign
> > EMBOSS_ROOT=/usr/lib/emboss HOME={build_dir}/home {interpreter}
> > run_tests.py --offline"
> > I: pybuild base:240: set -e; \
> > mkdir -p
> > /<>/.pybuild/cpython3_3.11/build/home; \
> > mkdir -p
> > /<>/.pybuild/cpython3_3.11/build/Doc/examples; \
> > cp -a Doc/Tutorial.tex
> > /<>/.pybuild/cpython3_3.11/build/Doc; \
> > cp -a Doc/Tutorial
> > /<>/.pybuild/cpython3_3.11/build/Doc; \
> > cp -a Doc/examples
> > /<>/.pybuild/cpython3_3.11/build/Doc; \
> > cp -a Tests
> > /<>/.pybuild/cpython3_3.11/build; \
> > cd
> > /<>/.pybuild/cpython3_3.11/build/Tests; \
> > env DIALIGN2_DIR=/usr/share/dialign
> > EMBOSS_ROOT=/usr/lib/emboss
> > HOME=/<>/.pybuild/cpython3_3.11/build/home python3.11
> > run_tests.py --offline
> > test_Ace ... ok
--
Best,
Nilesh
signature.asc
Description: PGP signature
Bug#1027751: need to properly depend on python3-exceptiongroup
Source: pytest Version: 7.1.2-4 Severity: serious X-Debbugs-Cc: roehl...@debian.org Hi, While building pairtools version 1.0.2-1 I noticed this error. I have temporarliy added a build depend on exceptiongroup in the said package to work around the issue. | I: pybuild base:240: export CURPY=python3.10; cd /<>/.pybuild/cpython3_3.10/build && python3.10 -m pytest -v | Traceback (most recent call last): | File "/usr/lib/python3.10/runpy.py", line 187, in _run_module_as_main |mod_name, mod_spec, code = _get_module_details(mod_name, _Error) | File "/usr/lib/python3.10/runpy.py", line 146, in _get_module_details |return _get_module_details(pkg_main_name, error) | File "/usr/lib/python3.10/runpy.py", line 110, in _get_module_details |__import__(pkg_name) | File "/usr/lib/python3/dist-packages/pytest/__init__.py", line 5, in |from _pytest._code import ExceptionInfo | File "/usr/lib/python3/dist-packages/_pytest/_code/__init__.py", line 2, in |from .code import Code | File "/usr/lib/python3/dist-packages/_pytest/_code/code.py", line 60, in |from exceptiongroup import BaseExceptionGroup | ModuleNotFoundError: No module named 'exceptiongroup' | E: pybuild pybuild:388: test: plugin custom failed with: exit code=1: export CURPY=python3.10; cd /<>/.pybuild/cpython3_3.10/build && python3.10 -m pytest -v My hunch is that the issue is this: | $ apt show python3-pytest | grep excep | Depends: python3-attr, python3-more-itertools, python3-pkg-resources, python3-pluggy (>= 0.12), python3-py, python3-exceptiongroup | python3 (>> 3.11), python3-importlib-metadata | python3 (>> 3.8), python3-iniconfig, python3-packaging, python3-tomli | python3 (>> 3.11), python3:any The "python3 (>> 3.11)" dependency is now beginning to be satisfied with doko's new python3.11 upload i.e. version 3.11.1 (see[1]) exceptiongroup should still be picked in this scnario, this is a bit odd though, but definitely worth a look. [1]: https://tracker.debian.org/news/1404008/accepted-python311-3111-2-source-into-unstable/ -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1025380: marked as pending in python-fissix
Control: tag -1 pending Hello, Bug #1025380 in python-fissix 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-fissix/-/commit/3e5007125c8171958c8d1985b6c4a6d74917b082 Cleanup tests dir after dh_auto_test (Closes: #1025380) (this message was generated automatically) -- Greetings https://bugs.debian.org/1025380
Bug#1024954: librcsb-core-wrapper: (autopkgtest) needs update for python3.11: initialization of CorePyWrap raised unreported exception
Hi again, On Mon, Nov 28, 2022 at 08:05:35PM +0530, Nilesh Patra wrote: > On Sun, 27 Nov 2022 22:26:31 +0100 Paul Gevers wrote: > > Source: librcsb-core-wrapper > > Version: 1.005-10 > > We are in the transition of adding python3.11 as a supported Python > > version [0]. > > [...] > > [0] https://bugs.debian.org/1021984 > > [1] https://qa.debian.org/excuses.php?package=python3-defaults > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/libr/librcsb-core-wrapper/28726239/log.gz > > > > Testing with python3.11: > > Traceback (most recent call last): > >File "", line 1, in > > SystemError: initialization of CorePyWrap raised unreported exception > > autopkgtest [17:14:04]: test autodep8-python3 > > There are a few similar bug reports with same error messages which aren't > helpful and > I am not quite sure as to how to debug errors like these. I did try to check > this using > gdb but I don't get anything helpful from this either. > > I also found similar bug reports on a few git hub projects, without any > closure/conclusion, > for instance this one[1] > > Could someone on the list please help fix this/point towards the right > direction to check so > this can be debugged ny further? Similar report is also filed for tagpy (Bug#1025201) -- could someone please help in fixing these? > [1]: https://github.com/hsnr-gamera/gamera-4/issues/54 -- Best, Nilesh signature.asc Description: PGP signature
Bug#1025370: ntcard: ftbfs with nthash 2.3.0
On Wed, 7 Dec 2022 08:27:54 +0100 Andreas Tille wrote: > Hi, > > I'm considering reverting the version bump (shame on me I did not tested > ntcard before uploading). I'm personally quite annoyed with this, I suppose your uploads, or rather team uploads have broken quite a few packages in the past days. It was first t-coffee update that broke biopython, and then mcl which broke pplacer and now this. The mcl update also most likely needs to be rolled back. The ocaml changes are not compatible with the new version of mcl, and someone needs to update pplacer too to make sure that it is compatible with newer mcl. I want to make it a mandatory policy: do NOT upload packages randomly. Run ratt or run https://salsa.debian.org/ruby-team/meta atleast given that we are close to release, random updates of not so important packages is un-necessarily breaking a lot of things. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1025115: marked as pending in python-phx-class-registry
Control: tag -1 pending Hello, Bug #1025115 in python-phx-class-registry 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-phx-class-registry/-/commit/3fd692321d8e292a1a17e91bb3541368d323f2ca Test-depends on python3-all to make autopkgtest work with all supported pyversions (Closes: #1025115) (this message was generated automatically) -- Greetings https://bugs.debian.org/1025115
Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0
On Mon, 28 Nov 2022 21:05:07 + Tobias Hansen wrote: > On 11/27/22 19:24, Nilesh Patra wrote: > > On Sun, Nov 27, 2022 at 05:35:17PM +, Tobias Hansen wrote: > >> On 11/27/22 06:37, Nilesh Patra wrote: > >>> Tobias, since this is done, would you consider to check sagemath now and > >>> get the ball rolling? :-) > >> Hi, > >> > >> I actually tried building with the new pari and gap versions a while ago > >> (using sagemath 9.5 with upstream patches for the new pari and gap > >> versions, I pushed them to the git repo today) and got stuck with a lot of > >> errors like this (might be unrelated to pari and gap): > > I am having a hard time building/reproducing this because sage tends to > > need a lot of compute power that I currently do not have, and it takes > > forever to porter box too. > > But looking at the error, my hunch is that this is a setuptools related > > monkeypatch issue (there are similar RC bugs filed for many packages). So > > re-ordering cython import > > in sage/misc/cython.py file after setuptools along with ensuring distutils > > is imported after setuptools will (very) likely help. > > > > Here is a related link that I found for the same > > > > > > https://stackoverflow.com/questions/21594925/error-each-element-of-ext-modules-option-must-be-an-extension-instance-or-2-t > > > Thanks. The attached patch removed the error, but now there are these > warnings when cython is used in doctests: > > UserWarning: Distutils was imported before Setuptools, but importing > Setuptools also replaces the `distutils` module in `sys.modules`. Apologies for late response. I suppose the line above is the crux? setuptools monkey-patches distutils so it should be imported _before_ distutils. Somewhere in the doctests, it is other way round and hence the error. Did you get a chance to build sage yet? > This may lead to undesirable behaviors or errors. To avoid these issues, > avoid using distutils directly, ensure that setuptools is installed in the > traditional way (e.g. not an editable install), and/or make sure that > setuptools is always imported before distutils. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1025835: tiledb-py: build-depends on libtiledb-doc
On Sat, Dec 10, 2022 at 07:56:52AM -0600, Dirk Eddelbuettel wrote: > > On 10 December 2022 at 09:07, Peter Green wrote: > | Source: tiledb-py > | Version: 0.18.2-1 > | Severity: serious > | Justification: rc policy - "Packages must be buildable within the same > release" > | x-debbugs-cc: e...@debian.org > | User: debian...@lists.debian.org > | Usertags: edos-uninstallable > | > | tiledb-py build-depends on libtiledb-doc, which is no longer built by > tiledb since > | version 2.13.0-1, this removal is no mentioned in the changelog, so it's > not clear to me > | if it was deliberate or not. It is still present in unsable as a cruft > package, but is > | completely gone from testing. This means that tiledb-py in testing is in > violation of > | the rc policy. > > Good catch but that was in fact deliberate. > > The build (of a package I inherited / adopted) was giving me fits, and I as > maintainer have decided to follow a) upstreams preference for documentation > on the websites and b) simplify the build. While this is an acceptable stance, I'd really prefer if you consider to keep vendoring the documentation. I have seen a number of bug reports and also heard from many people that they'd like to have a copy of documentation offline as well, as it a) enables to work when internet is spotty for them b) Look up everything offline instead of the online source as the docs contain API that correspond to the relevant version. I understand that vendoring documentation could be extra work, but if vendoring it is not a source of nuisance for each and every update, and the build rules are constant then I don't see a lot of issue with it. For your case, did you have any particular issues/build failures while vendoring the documentation? Also, I know that you understand tiledb far better than I do, but still I'd like to offer my help for this issue, should you like it, and if you help me understand where exactly it crossed the threshold for maintainer-time-well-spent. > We should adjust tiledb-py This is easy enough to do, which would mean removing doc package from tiledb-py as well. But again, I'd like to do this only after I hear back from you. > (which needs an update for the now released 0.19.0 > anyway, and had skipped minor release 0.18.3 which is ok) accordingly. Thanks for the ping. I work on hunderds of packages and I tend to skip updates so this is helpful. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1025835: marked as pending in tiledb-py
Control: tag -1 pending Hello, Bug #1025835 in tiledb-py 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/tiledb-py/-/commit/3ebd90b5a585801bc52d4a3bb1a54e72e95faa6a Drop doc package, which was never rendering fine anyway (Closes: #1025835) (this message was generated automatically) -- Greetings https://bugs.debian.org/1025835
Bug#1005619: marked as pending in hypercorn
Control: tag -1 pending Hello, Bug #1005619 in hypercorn 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/hypercorn/-/commit/3b7c9435b05554b430bf0f99f1858b46927bae0f Clean-up symlink after dh_auto_clean hook (Closes: #1005619) (this message was generated automatically) -- Greetings https://bugs.debian.org/1005619
Bug#1025658: libboost-python1.74-dev: Python 3.11 changes break loading of boost-python using extensions
Hi Anton/Gio, This is breaking a bunch of packages, including packages that directly affect key-packages. Since you maintain boost, could you please apply Stuart's patch and upload? Thanks! On Wed, 07 Dec 2022 12:25:10 +1100 Stuart Prescott wrote: > Package: libboost-python1.74-dev > Version: 1.74.0-17+b2 > Severity: serious > Tags: patch > Justification: Breaks reverse dependencies with Python 3.11 > X-Debbugs-Cc: stu...@debian.org, debian-pyt...@lists.debian.org > > > Dear Maintainer, > > Python 3.11 has changed some details around types and GC; boost's enum.cpp > needs modifying to cope. The result of this change is that trying to > load an extension compiled with Debian's boost 1.74 results in a C++ > exception being thrown and, since not properly handled, the following > rather obscure error: > > SystemError: initialization of $module raised unreported exception > > Further details courtesy of Alastair McKinstry's debugging work are to > be found at > > https://bugs.debian.org/1024911#14 > > So far, we've spotted this problem in: > > cctbx: https://bugs.debian.org/1024859 > ecflow: https://bugs.debian.org/1024911 > python-pgmagick: https://bugs.debian.org/1023909 > > The attached patch is a (trivial) backport of the upstream change for > this: > > https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013 > > I've verified that the attached patch solves the Python 3.11 incompatibility > of python-pgmagick, allowing it to successfully build, meaning that it is > now able to load its boost-python extensions for the test suite. > > regards > Stuart -- Best, Nilesh signature.asc Description: PGP signature
Bug#1025370: ntcard: ftbfs with nthash 2.3.0
Hi Andreas, On 12 December 2022 12:17:37 am IST, Andreas Tille wrote: >Am Fri, Dec 09, 2022 at 03:12:35PM +0530 schrieb Nilesh Patra: >> > I'm considering reverting the version bump (shame on me I did not tested >> > ntcard before uploading). >> >> I'm personally quite annoyed with this, I suppose your uploads, or rather >> team uploads have broken quite a few packages in the past days. It was >> first t-coffee update that broke biopython, and then mcl which broke pplacer >> and now this. > >I think this "common feature to break something" is quite different in >the single cases. It was pretty hard to estimate the effect of the >t-coffee case. I tend to differ. That new update was segfaulting for a number of months until Hamid and you had a discussion to build it with no optimisations. When seeing signs of a software getting _kind of_ unstable, extra care should be taken, atleast given the fact that we are close to release. There's a tool called reverse-depends that's a part of the ubuntu-dev-tools package. Simply running "$ reverse-depends t-coffee" and "$ reverse-depends t-coffee -b" would give an idea of the impact. >A lot of effort was done to fix its autopkgtest in >advance. I simply assumed that passing its test is sufficient for an >upload. Which we have seen is not the case. Again, this is from the perspective of us being near freeze. Such breakages are unhealthy at this point in time. Autopkgtests are a good indicator that the current package is working for a few cases. But it can never almost give an indication about updating current software will break something else. >While the breaking upload of MCL was not intended I would even insist >that there is a point in the breaking upload. MCL is a popular program >which we should deliver in its recent version. The support and >cooperation by upstream rectified this. The fact that some packages >like pplacer depend from a patch by third party which is not maintained >by its author since 10 years might mean that we will possibly loose >these packages which is a shame but may be the fate of those packages. Agreed. But here's the question: was this really the right time to do a broken upload? Was it really that necessary? Couldn't we have taken small steps and waited until the next debian release (Trixie) freeze to see if we got the ocaml support? >However, there is some hope that MCL upstream might find a solution. For sure. But I'm not sure if this is going to happen before the soft freeze ends. >> The mcl update also most likely needs to be rolled back. The ocaml changes >> are >> not compatible with the new version of mcl, and someone needs to update >> pplacer >> too to make sure that it is compatible with newer mcl. > >There is some hope for an updated OCaml patch[1], thought. If the OCaml >patch can be updated that would be great. If not I see no chance to >keep pplacer in the long term. > >> I want to make it a mandatory policy: do NOT upload packages randomly. Run >> ratt >> or run https://salsa.debian.org/ruby-team/meta atleast given that we are >> close to >> release, random updates of not so important packages is un-necessarily >> breaking a >> lot of things. > >I confirm that running ratt or meta of Ruby team would be a good idea in >some cases. However, I disagree to make it mandatory in policy. I request the policy to be made mandatory during freeze time, i.e. starting from "soft-freeze - 2 months" till "release" >Picking three cases of uploads from the number of all uploads is not a >very strong argument. We have *lots* of uploads pending for the next >couple of weeks to meet the freeze. Delaying these just because three >broken uploads (one is fixed meanwhile and there is a clear way to fiy >the second for ntcard by reverting the vesion bump of nthash if upstream >does not respond timely) is not a good strategy in my eyes. There are also library packages that are being updated. And I completely and absolutely disagree that updating them randomly without checking reverse deps does not cause any harm. Not all upstreams follow semantic versioning properly and then are un-noticed API breakages which we have seen in nthash already for instance. I don't think doing more of these unchecked updates is benefitting anyone using debian at all. >[1] >https://alioth-lists.debian.net/pipermail/debian-med-packaging/2022-December/105589.html -- Best, Nilesh
Bug#1025370: ntcard: ftbfs with nthash 2.3.0
Control: severity -1 important For the time being, I have vendored the relevant header files from nthash in ntcard itseld and patched the buildsystem a bit to pick those up. Ans so, for now, ntcard would "build" (with a compromise) and so I am downgrading the severity. -- Best, Nilesh signature.asc Description: PGP signature
Bug#987921: [RFS] Re: Bug#987921: linbox FTBFS on 32bit with gcc 10
Hi Anton, On Tue, 11 May, 2021, 2:47 am Anton Gladky, wrote: > Your changes look good. Let's wait for approval by > release team not to pollute unstable by unapproved uploads. > The release team has responded that it's a targeted fix, and can be uploaded. You might want to see the full reply here[1] [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988296#10 Nilesh
