Bug#1070764: nvidia-alternative: Is nvidia-alternative missing conflicts nvidia-tesla-470-alternative
Package: nvidia-alternative Version: 525.147.05-4~deb12u1 Severity: normal X-Debbugs-Cc: none, Diane Trout Dear Maintainer, I have a system with an older NVidia tesla card in it and nvidia-detect recommended the tesla-470 driver. unfortunately for me I'm having a bunch of trouble getting the right mix of nvidia driver and libraris installed. I've been having trouble keeping the 525 version uninstalled while getting the 470 version installed. One thing I noticed on nvidia-alternative was a long list of conflicts that skips over nvidia-tesla-470-alternative. I was wondering if that was an oversight (and if maybe there were some more conflicts missing. Here's the output of apt show nvidia-alternative. This is on a system that was just upgraded from 11 to 12. Package: nvidia-alternative Version: 525.147.05-4~deb12u1 Priority: optional Section: non-free/libs Source: nvidia-graphics-drivers Maintainer: Debian NVIDIA Maintainers Installed-Size: 188 kB Provides: nvidia-alternative--kmod-alias, nvidia-alternative-525.147.05, nvidia-alternative-any Pre-Depends: dpkg (>= 1.17.21), nvidia-legacy-check (>= 495) Depends: glx-alternative-nvidia (>= 1.2) Conflicts: libegl1-glvnd-nvidia, libgl1-glvnd-nvidia-glx, libgles1-glvnd-nvidia, libgles2-glvnd-nvidia, libglvnd0-nvidia, libglx0-glvnd-nvidia, libopengl0-glvnd-nvidia, nvidia-legacy-304xx-alternative, nvidia-legacy-340xx-alternative, nvidia-legacy-390xx-alternative, nvidia-tesla-418-alternative, nvidia-tesla-450-alternative, nvidia-tesla-460-alternative, nvidia-tesla-510-alternative Thanks, Diane
Bug#1070102: Requesting patch for llvm-toolchain-14
Source: llm-toolchain-14 Version: 1:14.0.6-12 Hello, python3-numba and packages using numba like python3-sparse are segfaulting on ARM64, upstream maintainers are suggesting we backport this small change. https://github.com/llvm/llvm-project/commit/2e1b838a889f9793d4bcd5dbfe10db9796b77143 diff --git a/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp b/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp index 3c7f4ec47eb84c..282c357f2de2c4 100644 --- a/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp +++ b/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp @@ -2406,6 +2406,7 @@ Error RuntimeDyldELF::finalizeLoad(const ObjectFile , } } + GOTOffsetMap.clear(); GOTSectionID = 0; CurrentGOTIndex = 0; Here's the sparse developer recommending it; https://github.com/pydata/sparse/issues/628#issuecomment-2076366957 And here's the numba comment. https://github.com/numba/numba/issues/9109#issuecomment-2042747383 I tried to figure out how to build llvm, but wasn't sure how to get the right set of patches for the branch I had checked out. Thanks, Diane
Bug#1055847: Please check python-sparse issue at Github
On Wed, 2024-04-24 at 15:53 +0200, Andreas Tille wrote: > Hi Diane and Ghislain, > > you are listed as Uploaders of python-sparse. Since I now have other > tasks than maintaining team maintained packages I would be really > happy > if you could subscribe upstream issue > > https://github.com/pydata/sparse/issues/628 > > and continue what I have started. > > Thanks a lot > Andreas. > I subscribed, though I'm still fighting with updating numba. Also I know there are many ways that numba can fail, so odds are sparse's problems are caused by numba. There are definitely problems with numba on arm64. https://github.com/numba/numba/issues/9109 (Also congratulations on your election, I have respect your organizational skills on the med team) Diane
Bug#1069786: python3-llvmlite: numba 0.59.1 needs >= llvmlite 0.43.0dev0
Package: llvmlite-doc Severity: normal X-Debbugs-Cc: none, Diane Trout Hello, I had some time to work on updating numba to 0.59.1 and discovered it needs llvmlite 0.43.0dev0, the current debian/watch file is too strict to detect that version number Also llvmlite and numba are tightly bound, would it be possible for me as numba maintainer to help update llvmlite? Attached is the patch I made to llvmlite to allow be to do gbp import-orig --uscan so I could have a llvmlite 0.43.0dev0 package to test numba against. >From 483c2b825bed861e7ead2c135bf35686543289b6 Mon Sep 17 00:00:00 2001 From: Diane Trout Date: Tue, 23 Apr 2024 19:18:23 -0700 Subject: [PATCH] Update d/watch to use @ANY_VERSION@ to detect version 0.43.0dev0 --- debian/changelog | 6 ++ debian/watch | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index ec1faf6..5ed5640 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +llvmlite (0.42.0-2) UNRELEASED; urgency=medium + + * Update d/watch to use @ANY_VERSION@ to detect version 0.43.0dev0 + + -- Diane Trout Tue, 23 Apr 2024 19:16:11 -0700 + llvmlite (0.42.0-1) unstable; urgency=medium * Upload to unstable. diff --git a/debian/watch b/debian/watch index 6ede6b4..c8d3ac0 100644 --- a/debian/watch +++ b/debian/watch @@ -1,4 +1,4 @@ version=4 -opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%llvmlite-$1.tar.gz%" \ +opts="filenamemangle=s%(?:.*?)?v@ANY_VERSION@@ARCHIVE_EXT@%llvmlite-$1.tar.gz%" \ https://github.com/numba/llvmlite/tags \ -(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate +(?:.*?/)?v@ANY_VERSION@@ARCHIVE_EXT@ debian uupdate -- 2.30.2
Bug#1068875: elpa-magit: Magit hangs when staging chunks over tramp
Package: elpa-magit Version: 3.3.0-3 Severity: normal X-Debbugs-Cc: none, Diane Trout Dear Maintainer, Hi. I ran into a bug on testing while running emacs 29.2 where staging chunks in magit sessions over tramp kept hanging. its described in "Emacs hangs on staging chunks over Tramp" https://github.com/magit/magit/issues/4720 and was caused by a change in tramp. "30.0.50; tramp: commit 8c6a463 breaks remotely staging chunks in magit" https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62093 The tramp part of the fix is in emacs 29.3 but there's a patch needed for magit as well, and probably a configuration change. https://github.com/magit/magit/commit/debb9723d9ce8ede802e33c7247ee9fa473907c3 -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (110, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-magit depends on: ii dh-elpa-helper 2.0.17 ii elpa-dash 2.19.1+git20220608.1.0ac1ecf+dfsg-1 ii elpa-git-commit 3.3.0-3 ii elpa-magit-section 3.3.0-3 ii elpa-with-editor3.3.2-1 ii emacsen-common 3.0.5 ii git 1:2.43.0-1 elpa-magit recommends no packages. elpa-magit suggests no packages. -- no debconf information
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi Julian, On Sat, 2024-03-30 at 20:22 +, Julian Gilbey wrote: > Lovely to hear from you, and oh wow, that's amazing, thank you! > > I can't speak for anyone else, but I suggest that pushing your > updates > to the science-team package would be very sensible; it would be silly > for someone else to have to redo your work. > > What more is needed for it to be ready for unstable? The things I think are kind of broken are: We've got 7.0.0 and upstreams current version is 15.0.2. the pyarrow 7.0.0 tests fail because it depends on a python test library that breaks with pytest 8.0. Either I need to disable the python tests or upgrade to a newer version. My upgrade didn't go smoothly because uscan found also upstreams debian watch file which is too loose and matches some other tar balls on their distribution site. (Though I don't know why uscan keeps looking for watch files after finding one in debian/watch) And you were probably right in that arrow needs to be a team, because I have no idea how to get other the other languages interfaces packaged. Oh and I probably need to get the pyarrow installed somewhere, since it was stopping at the tests I hadn't run into dh_missing errors yet. Diane
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
On Mon, 2024-03-25 at 18:17 +, Julian Gilbey wrote: > > > So this is a plea for anyone looking for something really helpful to > do: it would be great to have a group of developers finally package > this! There was some initial work done (see the RFP bug report for > details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), > but that is fairly old now. As Apache Arrow supports numerous > languages, it may well benefit from having a group of developers with > different areas of expertise to build it. (Or perhaps it would make > more sense to split the upstream source into a collection of > different > Debian source packages for the different supported languages. I > don't > know.) Unfortunately I don't have the capacity to devote any time to > it myself. > > Thanks in advance for anyone who can step forward for this! I've been maintain dask and anndata and saw that apache arrow was getting increasingly popular. I took the current science-team preliminary packaging 7.0.0 packaging and managed to get it to build through a combination of patches and turning off features. I even mostly managed to get pyarrow to build. (Though some tests fail due to pytest lazy-fixture being abandoned). I pushed my current work in progress to. https://salsa.debian.org/diane/arrow.git Was anyone else planning on working on it or should I push my updates to the science-team package? Diane
Bug#1067504: python3-numba: Can not be installed.
On Fri, 2024-03-22 at 15:58 +, Elizabeth Loss-Cutler-Hull wrote: > Package: python3-numba > Version: 0.59.0+dfsg-1 > Severity: serious > > In Debian sid, python3-numba currently depends on python3-numpy (< > 1:1.25) and python3-numpy (>= 1:1.22.0). > > However the currently available version of python3-numpy is > 1:1.26.4+ds-6, rendering python3-numba uninstallable. > Ah that's what I did wrong. Thank you for pointing the out of date version. I should have an fix uploaded soon. Diane
Bug#1059630: fix build with Python 3.12
On Mon, 2024-01-01 at 11:22 +0100, Matthias Klose wrote: > Control: tags -1 + patch > > patch at > http://launchpadlibrarian.net/706939750/python-sparse_0.14.0-1_0.14.0-1ubuntu1.diff.gz > I think a better solution to the versioneer fail to build is to remove the embedded versioneer and use the copy from python3-versioneer instead. I just need to fix some other problems in the autopkgtest too Diane
Bug#1058485: python-sparse: please (temporarily) drop python3-numba dependencies
python-sparse looks to have a hard dependency on numba, there's lots of functions tagged with @numba.jit, several modules start with import numba. Given how hard it is for numba to update, I wish upstream would keep numba an optional dependency. I should probably remove the since it seems required now. I'm not sure how to help with the python3.12 transition though. Diane On Tue, 2023-12-12 at 15:19 -0100, Graham Inggs wrote: > Source: python-sparse > Version: 0.14.0-1 > Severity: important > User: debian-pyt...@lists.debian.org > Usertags: python3.12 > > Hi Maintainer > > Your package has a dependency, build-dependency or autopkgtest > dependency on python3-numba. Numba is currently not compatible with > Python 3.12, although support is expected in the upcoming 0.59 > release. Please drop these dependencies for now, so we can proceed > with the Python 3.12 transition. > > As Numba often seems to lag behind major Python releases, please > consider using Recommends instead of Depends to avoid having to make > similar changes in future. > > Regards > Graham >
Bug#756017: dependencies
On Fri, 2023-11-03 at 15:54 +0100, Enrique García wrote: > I would really like to see bokeh packaged for Debian. I think getting bokeh pacakged would be great, I just lack time and motivation to deal with the javascript packages. Also I think there were times when bokeh was using an unpackaged build system, but they switched to something simpler. Diane
Bug#1050526: dask: autopkgtest regression on s390x
Hi,
I'm kind of shocked I think I found a fix.
I looked a little bit, and it seems like the random number generator
behaves differently between s390x and x86
Eventually the test calls dask.util.random_state_data(1, 42)
on x86 it starts with this on two different machines:
In [9]: random_state_data(1, 0)
Out[9]:
[array([2357136044, 2546248239, 3071714933, 3626093760, 2588848963,
3684848379, 2340255427, 3638918503, 1819583497, 2678185683,
2774094101, 1650906866, 1879422756, 1277901399, 3830135878,
243580376, 4138900056, 1171049868, 1646868794, 2051556033,
3400433126, 3488238119, 2271586391, 2061486254, 2439732824,
1686997841, 3975407269, 3590930969, 305097549, 1449105480,
374217481, 2783877012, 86837363, 1581585360, 3576074995,
and on s390x it starts with
In [16]: random_state_data(1, 42)
Out[16]:
[array([1725751647, 3007179467, 1543725811, 244708654, 1794401211,
1205115335, 3165536665, 338480024, 1725362215, 2031624818,
3527536423, 3606353689, 1251073550, 3394605429, 1471725021,
1961717077, 1672274585, 1743491620, 2537440437, 2191564966,
2500216069, 889024526, 16993528, 1474942136, 3958708949,
2650621168, 635132726, 2164863744, 3205794862, 3146973694,
345633582, 2688816030, 3419529805, 961385884, 359683718,
Digging further there's a place where they convert some random bytes
into unsigned int 32s using numpy.frombuffer.
I added some code to force little endian byte order on the buffer, and
after that random_state_data returns the same list of values on s390x.
So hopefully will then generate the same random values as x86_64.
Roughly the likely change.
===
--- dask-2023.8.0+dfsg.orig/dask/utils.py
+++ dask-2023.8.0+dfsg/dask/utils.py
@@ -426,7 +426,9 @@ def random_state_data(n: int, random_sta
random_state = np.random.RandomState(random_state)
random_data = random_state.bytes(624 * n * 4) # `n * 624` 32-bit
integers
-l = list(np.frombuffer(random_data, dtype=np.uint32).reshape((n, -
1)))
+dt = np.dtype(np.uint32)
+dt = dt.newbyteorder("<")
+l = list(np.frombuffer(random_data, dtype=dt).reshape((n, -1)))
assert len(l) == n
return l
signature.asc
Description: This is a digitally signed message part
Bug#1033907: numba crashes on non-x86
On Sat, 2023-08-19 at 18:21 +0100, Rebecca N. Palmer wrote: > numba also crashes on mips64el, mipsel and armhf (and s390x but that > was > already known; not amd64, i386 or ppc64el). However, I agree that > arm64 > is a good place to start trying to fix this, given how common it is. > Also given how popular Apple arm chips are upstream has some motivation to fix numba on arm64.
Bug#1049973: chirp: debian/watch should be updated
Source: chirp Version: 1:20221106+py3-2 Severity: minor Tags: patch Dear Maintainer, Hello, one of my coworkers mentioned he was using chirp but the debian version was out of date so had to download it directly from the upstream site. I looked at https://tracker.debian.org/pkg/chirp and saw that there was a problem searching for a new upstream version. I adjusted to the watch line to work with the layout I found on the upstream providers website today. Diane -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled >From 9d8eb219dd2746d4046903d65a12b8e19f7e4c83 Mon Sep 17 00:00:00 2001 From: Diane Trout Date: Thu, 17 Aug 2023 10:35:29 -0700 Subject: [PATCH] Update debian/watch to 2023 August website layout --- debian/watch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/watch b/debian/watch index 92b1b72..fb1ec0b 100644 --- a/debian/watch +++ b/debian/watch @@ -1,2 +1,2 @@ version=4 -https://trac.chirp.danplanet.com/chirp_daily/LATEST/ chirp-daily-(\d.*).(?:tgz|tbz2|txz|tar\.(?:gz|bz2|xz)) +https://trac.chirp.danplanet.com/chirp_next/next-(\d.*)/ chirp-(\d.*).(?:tgz|tbz2|txz|tar\.(?:gz|bz2|xz)) -- 2.40.1
Bug#1029297: python-graphviz: please make the build reproducible
> > This is because it shipped .PDF files that were generated during the > tests which were then installed under > /usr/lib/python3.X/dist-packages/doctest-output (!). Whoops! Thank you for finding that mistake. Sorry it took me so long to notice.
Bug#1049431: RM: legacy-api-wrap -- ROM; RoM: was packaged for scanpy which stopped depending on legacy-api-wrap
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: legacy-api-w...@packages.debian.org Control: affects -1 + src:legacy-api-wrap I'd packaged legacy-api-wrap for trying to package scanpy, but scanpy removed the dependency in 2021. https://github.com/scverse/scanpy/commit/5f19a29c01bcfd15cdd33a28f92c1038c8cc367f Nothing else seems to depend on python3-legacy-api-wrap. I checked with apt rdepends and build-rdeps.
Bug#1049430: RM: python-get-version -- ROM; No longer needed for trying to package scanpy
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-get-vers...@packages.debian.org Control: affects -1 + src:python-get-version python-get-version is a dependency of legacy-api-wrap, and I only packaged legacy-api-wrap because it was a dependency of scanpy. Scanpy removed the dependency and so python-get-version isn't needed any more. https://github.com/scverse/scanpy/commit/5f19a29c01bcfd15cdd33a28f92c1038c8cc367f
Bug#1044072: python-anndata: FTBFS with pandas 2.0
On Sun, 2023-08-13 at 15:14 +0100, Rebecca N. Palmer wrote: > Package: src:python-anndata > Version: 0.8.0-4 > Control: block 1043240 by -1 > > python-anndata fails to build with pandas 2.0, currently in > experimental. I was thinking I needed to update anndata soon. The last version I checked needed an updated dask, which we now have, I'll try to get to it soon
Bug#1043093: Updated dask to 2023.8.0+dfsg-1
Hi, I pushed dask 2023.8.0+dfsg-1 to unstable, hope that helps, though I"m not sure if that helped with the pandas tests though. Diane
Bug#1043093: dask: test fail with pandas 2.0
On Sat, 2023-08-05 at 22:56 +0100, Rebecca N. Palmer wrote: > Package: python3-dask > Version: 2022.12.1+dfsg-2 > Tags: fixed-upstream > > pandas 2.0's test_dask fails (in Salsa CI). Upstream reports suggest > that this is fixed in dask 2023.2, but I haven't checked whether > upgrading dask breaks anything else. > https://github.com/dask/dask/issues/10164 > > (I also consider it likely that pandas 2 breaks more than just dask, > so > this isn't urgent.) > If you want to try pandas with a newer version of dask, I've started working on updating dask and dask distributed for another bug, so Dask 2023.7.4 is mostly ready on salsa while I work on distributed. When I grabbed dask.distributed I got 2023.8, so I'll need to update dask again to match before releaseing. Diane
Bug#1033907: numba: autopkgtest regression: segmentation fault on arm64
Debian's llvmlite package was updated recently So I updated numba to 0.57.1 and released it to unstable, but even with the updates it still crashes on arm64. I forwarded it to upstream. Diane On Mon, 3 Jul 2023 13:36:53 +0200 Andreas Tille wrote: > Hi > > On Sun, 21 May 2023 11:39:29 -0700 Diane Trout wrote: > > Unfortunately it also wants llvmlite 0.40.0. > > Could you please be more verbose about this "unfortunately"? > > > It'd probably be easier to get upstream to help with debugging 0.57 > > I fully agree that we should target at latest upstream instead of > trying to stick to our heavily patched old version. > > Kind regards > Andreas. > > -- > http://fam-tille.de > >
Bug#1040411: cloudpickle: implicitly depends on python3-py
Thanks for the heads up. It should be fixed now On Wed, 2023-07-05 at 18:33 +0200, Timo Röhling wrote: > Source: cloudpickle > Version: 2.2.0-1 > Severity: serious > > Dear maintainer, > > your package implicitly depends on python3-py for its autopkgtest, > which used > to be provided by python3-pytest. However, pytest has dropped that > dependency, > breaking your autopkgtest and possibly your package. > > > Cheers > Timo > > Relevant excerpt from > https://ci.debian.net/data/autopkgtest/testing/amd64/c/cloudpickle/35335619/log.gz > > 57s === FAILURES > === > 57s __ CloudPickleTest.test_dynamic_pytest_module > __ > 57s > 57s self = testMethod=test_dynamic_pytest_module> > 57s > 57s def test_dynamic_pytest_module(self): > 57s # Test case for pull request > https://github.com/cloudpipe/cloudpickle/pull/116 > 57s import py > 57s > 57s def f(): > 57s s = py.builtin.set([1]) > 57s return s.pop() > 57s > 57s # some setup is required to allow pytest apimodules to > be correctly > 57s # serializable. > 57s from cloudpickle import CloudPickler > 57s from cloudpickle import cloudpickle_fast as cp_fast > 57s > CloudPickler.dispatch_table[type(py.builtin)] = > cp_fast._module_reduce > 57s E AttributeError: module 'py' has no attribute 'builtin' > 57s > 57s tests/cloudpickle_test.py:1511: AttributeError > 57s _ > Protocol2CloudPickleTest.test_dynamic_pytest_module __ > 57s > 57s self = testMethod=test_dynamic_pytest_module> > 57s > 57s def test_dynamic_pytest_module(self): > 57s # Test case for pull request > https://github.com/cloudpipe/cloudpickle/pull/116 > 57s import py > 57s > 57s def f(): > 57s s = py.builtin.set([1]) > 57s return s.pop() > 57s > 57s # some setup is required to allow pytest apimodules to > be correctly > 57s # serializable. > 57s from cloudpickle import CloudPickler > 57s from cloudpickle import cloudpickle_fast as cp_fast > 57s > CloudPickler.dispatch_table[type(py.builtin)] = > cp_fast._module_reduce > 57s E AttributeError: module 'py' has no attribute 'builtin' > 57s > 57s tests/cloudpickle_test.py:1511: AttributeError > > > signature.asc Description: This is a digitally signed message part
Bug#1038900: gnome-settings-daemon: my gnome session crashes immediately on login with a segfault in org.gnome.SettingsDaemon.UsbProtection.service
Package: gnome-settings-daemon Version: 43.0-4 Severity: important Dear Maintainer, After recently updating on testing I'm having a crash when I try to log in to a gnome session on a Dell XPS 9360. Both when connected to a thunderbolt dock and when the laptop is disconnected. A relevant chunk of the journalctl log is: --- Subject: A start job for unit UNIT has failed lines 3252-3274/3282 100% ░░ Subject: Automatic restarting of a unit has been scheduled ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ Automatic restarting of the unit UNIT has been scheduled, as the result for ░░ the configured Restart= setting for the unit. Jun 22 12:30:17 amarana systemd[2770]: Stopped org.gnome.SettingsDaemon.UsbProtection.service - GNOME USB protection service. ░░ Subject: A stop job for unit UNIT has finished ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A stop job for unit UNIT has finished. ░░ ░░ The job identifier is 2887 and the job result is done. Jun 22 12:30:17 amarana systemd[2770]: org.gnome.SettingsDaemon.UsbProtection.service: Start request repeated too quickly. Jun 22 12:30:17 amarana systemd[2770]: org.gnome.SettingsDaemon.UsbProtection.service: Failed with result 'core-dump'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ The unit UNIT has entered the 'failed' state with result 'core-dump'. --- And I had coredumpctl installed so was also able to get a backtrace of the failed module coredumpctl general information about crash. --- PID: 8619 (gsd-usb-protect) UID: 1000 (diane) GID: 1000 (diane) Signal: 11 (SEGV) Timestamp: Thu 2023-06-22 12:30:16 PDT (4min 49s ago) Command Line: /usr/libexec/gsd-usb-protection Executable: /usr/libexec/gsd-usb-protection Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.SettingsDaemon.UsbProtection.service Unit: user@1000.service User Unit: org.gnome.SettingsDaemon.UsbProtection.service Slice: user-1000.slice Owner UID: 1000 (diane) Boot ID: 10faf4426ba6447a90e28ccbbb5b8bf4 Machine ID: ded7c21fc20047a9b4cf708e45785ff1 Hostname: amarana Storage: /var/lib/systemd/coredump/core.gsd-usb-protect.1000.10faf4426ba6447a90e28ccbbb5b8bf4.8619.168746221600.zst (present) Size on Disk: 160.8K Message: Process 8619 (gsd-usb-protect) of user 1000 dumped core. Stack trace of thread 8619: #0 0x5559a6f5c558 n/a (gsd-usb-protection + 0x5558) #1 0x7ffabe643c93 g_task_return_now (libgio-2.0.so.0 + 0xafc93) #2 0x7ffabe644673 g_task_return (libgio-2.0.so.0 + 0xb0673) #3 0x7ffabe6aa3fa init_second_async_cb (libgio-2.0.so.0 + 0x1163fa) #4 0x7ffabe643c93 g_task_return_now (libgio-2.0.so.0 + 0xafc93) #5 0x7ffabe644673 g_task_return (libgio-2.0.so.0 + 0xb0673) #6 0x7ffabe6a9371 async_init_data_set_name_owner (libgio-2.0.so.0 + 0x115371) #7 0x7ffabe6a9652 async_init_get_name_owner_cb (libgio-2.0.so.0 + 0x115652) #8 0x7ffabe643c93 g_task_return_now (libgio-2.0.so.0 + 0xafc93) #9 0x7ffabe644673 g_task_return (libgio-2.0.so.0 + 0xb0673) #10 0x7ffabe69d912 g_dbus_connection_call_done (libgio-2.0.so.0 + 0x109912) #11 0x7ffabe643c93 g_task_return_now (libgio-2.0.so.0 + 0xafc93) #12 0x7ffabe643cc9 complete_in_idle_cb (libgio-2.0.so.0 + 0xafcc9) #13 0x7ffabe45167f g_main_dispatch (libglib-2.0.so.0 + 0x5467f) #14 0x7ffabe451a38 g_main_context_iterate (libglib-2.0.so.0 + 0x54a38) #15 0x7ffabe451cef g_main_loop_run (libglib-2.0.so.0 + 0x54cef) #16 0x5559a6f5a8d0 n/a (gsd-usb-protection + 0x38d0) #17 0x7ffabe24118a n/a (libc.so.6 + 0x2718a) #18 0x7ffabe241245 __libc_start_main (libc.so.6 + 0x27245) #19 0x5559a6f5a9b1 n/a (gsd-usb-protection + 0x39b1) Stack trace of thread 8620: #0 0x7ffabe315fff __poll (libc.so.6 + 0xfbfff) #1 0x7ffabe4519ae g_main_context_poll (libglib-2.0.so.0 + 0x549ae) #2 0x7ffabe451acc g_main_context_iteration (libglib-2.0.so.0 + 0x54acc) #3 0x7ffabe451b11 glib_worker_main (libglib-2.0.so.0 + 0x54b11) #4 0x7ffabe47bcfd g_thread_proxy (libglib-2.0.so.0 + 0x7ecfd) #5 0x7ffabe2a2fd4 n/a (libc.so.6 + 0x88fd4) #6 0x7ffabe3235bc n/a (libc.so.6 + 0x1095bc) Stack trace of thread 8622: #0 0x7ffabe31b4f9 syscall (libc.so.6 + 0x1014f9) #1 0x7ffabe4a650c
Bug#1033907: numba: autopkgtest regression: segmentation fault on arm64
I'm not really sure what to do about it. I looked some and there are a variety of different types of segfaults triggered by numba on arm64. I wasn't able to find any particular patterns. I have most of the patches they initially recommended but upstream has moved on to released 0.57.0 which supports python3.11, numpy 1.24, and llvm 14. Unfortunately it also wants llvmlite 0.40.0. There's quite a lot of differences from our patched 0.56.4 and their released 0.57.0. I was hoping to make a backports version of numba 0.57 when possible, though that also will take a backport of llvmlite. It'd probably be easier to get upstream to help with debugging 0.57 Diane
Bug#1033370: dino-im: Insufficient message sender validation in Dino CVE-2023-28686
Package: dino-im Version: 0.4.1-1 Severity: important Dear Maintainer, I saw an announcement on the dino-im muc that there's a security vulnerability in dino. https://dino.im/security/cve-2023-28686/ I believe this is the patch upstream recommends appling to fix it. https://github.com/dino/dino/commit/ef8fb0e94ce79d5fde2943e433ad0422eb7f70ec.patch For myself I cloned dino-im from salsa cd debian/patches/ curl -L -o cve-2023-28686.patch https://github.com/dino/dino/commit/ef8fb0e94ce79d5fde2943e433ad0422eb7f70ec.patch echo cve-2023-28686.patch >> series sbuild -d unstable It built successfully with the patch. I could do an NMU if you're busy, but it was also a really a trivial update to apply. Thanks Diane Trout -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing'), (110, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dino-im depends on: ii dino-im-common 0.4.1-1 ii libadwaita-1-0 1.2.2-1 ii libc6 2.36-8 ii libcairo2 1.16.0-7 ii libgcc-s1 12.2.0-14 ii libgcrypt20 1.10.1-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgee-0.8-20.20.6-1 ii libglib2.0-02.74.6-1 ii libgnutls30 3.7.9-1 ii libgpgme11 1.18.0-3+b1 ii libgraphene-1.0-0 1.10.8-1 ii libgstreamer-plugins-base1.0-0 1.22.0-3 ii libgstreamer1.0-0 1.22.0-2 ii libgtk-4-1 4.8.3+ds-2 ii libgtk-4-media-gstreamer4.8.3+ds-2 ii libicu7272.1-3 ii libnice10 0.1.21-1 ii libpango-1.0-0 1.50.12+ds-1 ii libqrencode44.1.1-1 ii libsignal-protocol-c2.3.2 2.3.3-2 ii libsoup-3.0-0 3.2.2-2 ii libsqlite3-03.40.1-1 ii libsrtp2-1 2.5.0-3 ii libstdc++6 12.2.0-14 ii libwebrtc-audio-processing1 0.3-1+b1 Versions of packages dino-im recommends: ii ca-certificates 20230311 ii dbus1.14.6-1 ii fonts-noto-color-emoji 2.038-1 ii network-manager 1.42.0-1 dino-im suggests no packages. -- no debconf information
Bug#1031701: pandas can't open xls (not xlsx) files, xlrd too old
I'm trying to talk the release team into letting me update, but I do think the update would likely break a different, so it's likely the answer will be no. I will try to get the updated xlrd into backports when it opens though. If you want to manually use debian packages instead of pip the updated package from experimental can be found here. https://packages.debian.org/source/experimental/python-xlrd
Bug#1031701: fixed in python-xlrd 2.0.1-1
Sorry my coworker got hit by this too, he worked around it by using libreoffice to convert the .xls file to .xlsx. I'd updated the xlrd package to 2.0.1 and pushed it to experimental to see how much it might break, Looks like there was some more discussion while I was fiddling with the package. On the plus side the update also enabled autopkgtests for xlrd. Though I had to switch from pulling from pypi to github to keep being able to build the -docs package, as upstream removed it from their pypi release. Diane signature.asc Description: This is a digitally signed message part
Bug#1009261: bug 1009261 is forwarded to https://bugs.webkit.org/show_bug.cgi?id=202363
On Sat, 2023-02-11 at 22:03 +0200, Adrian Bunk wrote: > On Sat, Feb 11, 2023 at 11:46:56AM -0800, Diane Trout wrote: > > forwarded 1009261 https://bugs.webkit.org/show_bug.cgi?id=202363 > > thanks > > If this was the problem, then this bug is a duplicate of #986218 that > was fixed in oldstable/stable/unstable in September. The bug reports certainly look similar to me
Bug#1009261: Evolution bwrap problem - may fail to print or hang in startup
On Sun, 01 May 2022 14:41:26 +0200 Domenico Cufalo wrote: > Dear developers, > > I have the same issue in my machine (Debian Bullseye Stable with Gnome > 3.38): Evolution doesn't start at all. > I also had this problem, but it went away on systems running testing or bookworm.
Bug#1030096: dask.distributed intermittent autopkgtest fail
> > That presumably means 5 days, which we don't have, i.e. *don't* > unless > release team tell you otherwise. For what it's worth this is our answer from #debian-release elbrus detrout: I'll handle dask.distributed detrout elbrus, Thank you. sorry about needing to ask for an exception elbrus ack, thanks for working on the package; it wasn't pretty that we had to remove it for the python3.11 transition
Bug#1030096: dask.distributed intermittent autopkgtest fail
> > That might be true on amd64, but I don't think it's true of > arm*/s390x: > the tests that are failing there do *not* appear to be isinstalled > tests. > > I suspect the tests wouldn't have worked on those architectures in > 2022.02 either, and we didn't notice because the previously mentioned > bug was causing the autopkgtest to not actually run the tests. > (dask.distributed is arch:all, so it's only built once, presumably on > amd64.) Ok yes there could also be issues with their serialization code on unusual architectures. > > When under less time pressure I think a good plan might be two > split > > the tests internally marked as isinstalled or flaky into a > separate > > autopkgtest run that's marked flaky and let the CI gate on the > more > > reliable tests. > > As stated above, that's probably the wrong split for this. It might not be enough to solve all dask.distributed's test problems, (as you point out for the other architectures) but it does seem like their test suites include both unit tests that don't depend on the host networking, and integration tests that are strongly impacted by the configuration of test runner. And there might be value in separating the unit & integration test types?
Bug#1030096: dask.distributed intermittent autopkgtest fail
On Fri, 2023-02-10 at 08:44 +0530, Nilesh Patra wrote: > 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) That explains why the tests suddenly passed when i wasn't looking. When I'd last looked in the morning most of them were marked failed. > 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. > Yeah I need to beg the release team for forgiveness. Though I made two changes that should dramatically increase the odds of the tests passing. One I told it to skip all the "isinstalled" marked tests, which are all skipped during build time, and the build seems to run far more reliably. I got the idea because it seemed like the vast majority of test failures are related to the daemons running or failing to shut down. While talking on IRC about dask.distributed problems I learned of the flaky autopkgtest restriction which says the test is expected to fail intermittently and is not suitable for gating continuous integratin. So I marked the current whole autopkgtest run as flaky. So CI should also ignore the results of failed test runs now. When under less time pressure I think a good plan might be two split the tests internally marked as isinstalled or flaky into a separate autopkgtest run that's marked flaky and let the CI gate on the more reliable tests. Diane signature.asc Description: This is a digitally signed message part
Bug#1030096: dask.distributed intermittent autopkgtest fail
On Thu, 2023-02-09 at 21:21 +, Rebecca N. Palmer wrote: > > > On 09/02/2023 17:07, Diane Trout wrote: > > Would it make sense to drop those errors back to warnings, and do > > you > > know enough about the setup.cfg language to do it quickly? > > > > Plausibly yes but I don't actually know, and remove the 'error' line > at > setup.cfg:60. My current frustrated idea is to do what's going on in d/rules and skip the isinstalled tests. My local build is running now, and I was probably thinking of pushing a proposed -3 to salsa in an hour or so > > > I went ahead and requested another run for the failed amd64 run and > > left the passing arm64 run alone. > > That worked, but armel (test_steal_twice), armhf (something outright > crashing) and s390x (lots) all failed. Aren't those all still on -1? I only see amd64 and arm64 having run 2022.12.1+ds1-2 At https://ci.debian.net/packages/d/dask.distributed/ > > The place to ask is debian-release; no comment on the likely result. > I'll try to ask. Diane
Bug#1030096: dask.distributed intermittent autopkgtest fail
On Thu, 2023-02-09 at 07:44 +, Rebecca N. Palmer wrote: > On 09/02/2023 06:36, Diane Trout wrote: > > Also there's still some flaky tests as the rebuild triggered by my > > just > > committing the changelog release had a failure in > > "test_release_retry" > > I don't think I've seen that particular one before, though like > several > others it's a warning being treated as an error because > dask.distributed > now does that (in setup.cfg). Would it make sense to drop those errors back to warnings, and do you know enough about the setup.cfg language to do it quickly? > > debci doesn't appear to have run yet. (If it does and fails, note > that > there's a retry button next to failure reports. Given how tight we > are > on time (we need to be in testing by the 12th), I'd rather not re- > upload > (restarting the migration clock) if we don't have to.) It says it failed on 4 tests on ci for amd64 but I could only find the traceback for test_default_5 with a bunch of OS errors having run out of file handles. I went ahead and requested another run for the failed amd64 run and left the passing arm64 run alone. > > Also, we need to close this bug (by email _not_ by uploading). Also how did numba 0.56.4-1 get overridden to be back in testing? Can we get dask.distributed forced back in? It looks like it mostly works, it feels like we're mostly fighting over it not being robust to environment specific issues. Diane
Bug#1030096: dask.distributed intermittent autopkgtest fail
On Wed, 2023-02-08 at 23:11 +, Rebecca N. Palmer wrote: > > Mostly, please upload *something* today, because we won't know for > sure > whether it passes on a real buildd/debci until we try that, and if it > doesn't then the sooner we find out the better. > It's uploaded it earlier today dask.distributed is past buildd, but I haven't seen dask.distributed on ci.debian.org yet. Also there's still some flaky tests as the rebuild triggered by my just committing the changelog release had a failure in "test_release_retry" Diane
Bug#1030096: dask.distributed intermittent autopkgtest fail
Hello, So I discovered I'd forgotten to do git cherry-pick --continue so missed the last patch from Rebecca. (b82894aa) Thank you so much for working out a better strategy for the flaky tests. I also found a computer I could log into that has has no working ipv6 support, and so could more quickly debug the ipv6 detection code, and finally got a version of it that works correctly. This version just uses ping but turns off set -e for the test. I just got back a passed from salsa. So does anyone want to make any more changes? Or should we release this version? Diane
Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?
On Tue, 2023-02-07 at 07:31 +, Rebecca N. Palmer wrote: > On 07/02/2023 03:20, Diane Trout wrote: > > What's your test environment like? > > Salsa CI. > > > I don't think head is hugely different from what was released in - > > 1. > > > > The diff looks like Andreas adjusted the dask dependency version, > > configured a salsa CI run, and added some upstream metadata files > > That sounds like you're not looking at my branch at all. As > previously > stated, that's > https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/tree/fix1030096 > (It's in a fork because I can't push to debian-python.) > > See earlier in this bug for which test failures still remain. I merged in most of Rebecca's changes via git cherry pick, though I slightly edited the changelog. (making most entries a bullet point instead of subheadings of the one line I left out). I think I got the code to detect if IPv6 is available to work correctly so I could set the DISABLE_IPV6 environment variable that dask.distrubted supports. I went with skipping the 32bit tests instead of xfailed because I don't think they can work as written since I really think they're making really large memory requests that can't ever succeed on 32bit. You did a lot of work on trying to get the flaky tests to work more reliably, and all that's included. Well except for the apply a patch and then revert it. All the merges are pushed to salsa debian/master. They also passed on my local build host running i386. Diane
Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?
On Mon, 2023-02-06 at 21:39 +, Rebecca N. Palmer wrote: > I agree that xfailing the tests *may* be a reasonable solution. I'm > only saying that it should be done by someone with more idea than me > of > whether these particular tests are important, because blindly > xfailing > everything that fails is effectively not having tests. > > If we do choose that approach, at least test_balance_expensive_tasks > needs to be an outright xfail/skip not just a flaky, because when it > fails it fails repeatedly. So my efforts at debugging are made harder by it working for me. I'm using a9771f68a28dfc65cae3ac6acf70451c264f3227 from Debian HEAD. = 2745 passed, 93 skipped, 216 deselected, 18 xfailed, 8 xpassed in 1992.20s (0:33:12) = I looked at the last log on ci.debian.org for dask.distributed https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dask.distributed/31090863/log.gz And it looks like several of those errors are networking related. CI with the previously released 2022.12.1+ds.1-1 version is failing with these tests: test_defaults test_hostport test_file test_default_client_server_ipv6[tornado] test_default_client_server_ipv6[asyncio] test_tcp_client_server_ipv6[tornado] test_tcp_client_server_ipv6[asyncio] test_only_local_access test_remote_access test_adapt_then_manual test_local_tls[True] test_local_tls[False] test_run_spec test_balance_expensive_tasks[enough work to steal] I think several of those may depend on a proper network. The host I'm using actually has both ipv4 and ipv6 working. I'm using sbuild automatically running autopkgtests on a oldish 2x4 8 core xeon server with ~24 GB of ram What's your test environment like? I don't think head is hugely different from what was released in -1. The diff looks like Andreas adjusted the dask dependency version, configured a salsa CI run, and added some upstream metadata files He had problems with a salsa build failure but that was with i386, I'm currently setting up i386 to see if I can replicate the salsa failure. Diane
Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?
On Mon, 2023-02-06 at 11:13 +0100, Andreas Tille wrote: > Hi Rebecca, > > Am Mon, Feb 06, 2023 at 07:59:17AM + schrieb Rebecca N. Palmer: > > (Background: the pandas + dask transition broke dask.distributed > > and it was > > hence removed from testing; I didn't notice at the time that if we > > don't get > > it back in we lose Spyder.) > > as far as I know Diane has put quite some effort into dask and I > understood that dask and dask.distributed are closely interconnected. > Hi now. My fragments of time were spent fighting with numba, and I didn't have the energy to be thinking about dask.distributed. Numba should be in a better place right now. So I can set my build machine to trying to build it and seeing where we are with it right now. The most important thing about dask / dask.distributed is they really should be at about the same upstream version. I'm not 100% sure how to mark that in the d/control file. Also upstream might have some ability to do minor releases independently. But if we do a new upstream release of dask, it needs to be paired with a new upstream release of dask.distributed. And in my experience dask.distributed is the one that's harder to get to work right. Diane
Bug#1030085: RM: bcolz -- RoQA; Package went unmaintained upstream and it now fails to build from source
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: bc...@packages.debian.org Control: affects -1 + src:bcolz The bcolz maintainers declared that the package is unmaintained. https://github.com/Blosc/bcolz bcolz's single non-meta pacakge dependency was dask, and the dask developers declared bcolz deprecated. https://github.com/dask/dask/issues/8330 And now bcolz has started failing to build from source because of changes in numpy. https://buildd.debian.org/status/package.php?p=bcolz=sid We should probably just remove it. Diane Trout
Bug#1029794: prosody-modules: mod_firewall attempts to call global 'is_admin' a nill value preventing prosody from starting
Package: prosody-modules Version: 0.0~hg20230116.ca7feb293d55+dfsg-1~bpo11+1 Severity: important Dear Maintainer, I did also talk to the prosody developers and filed the bug with them as well. I'll mark the forwarded when this gets an bug number assigned. What steps will reproduce the problem? 1. I upgraded the Debian bullseye backport packages from: prosody 0.12.1-1~bpo11+1 to 0.12.2-1~bpo11+1 prosody-modules 0.0~hg20220613.59bedf167910+dfsg-1~bpo11+1 0.0~hg20230116.ca7feb293d55+dfsg-1~bpo11+1 2. I had mod_firewall enabled in prosody.cfg and on restart, I had these errors in the systemd journal. c2sea5ba0: Traceback[c2s]: mod_firewall::deliver:23: attempt to call global 'is_admin' (a nil valu> stack traceback: mod_firewall::deliver:23: in function '?' /usr/lib/prosody/util/events.lua:81: in function (...tail calls...) /usr/lib/prosody/core/stanza_router.lua:188: in function 'core_post_stanza' /usr/lib/prosody/core/stanza_router.lua:128: in function 'core_process_stanza' /usr/lib/prosody/modules/mod_c2s.lua:326: in function 'func' /usr/lib/prosody/util/async.lua:144: in function I had to disable the firewall to get prosody to load correctly, but I would like the firewall available for antispam purposes. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 6.0.0-0.deb11.6-686-pae (SMP w/2 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prosody-modules depends on: ii prosody 0.12.2-1~bpo11+1 Versions of packages prosody-modules recommends: ii lua-ldap 1.2.5-1+b1 prosody-modules suggests no packages. -- no debconf information
Bug#1029232: dask.distributed: broken by version mismatch with dask
On Fri, 2023-01-20 at 13:20 -0800, Diane Trout wrote: > On Fri, 2023-01-20 at 21:02 +, Rebecca N. Palmer wrote: > > Would you like some help? If so, please push what you currently > > have > > to > > Salsa so we can see it. > > > > (No promises - #1029251 doesn't look like a big job but I might be > > wrong > > about that.) > > In shocking news, the build I did this morning actually finished. > > I should hopefully be able to organize the hacks and commit them to > salsa tonight. Maybe even get it uploaded tonight to. Unfortunately there was a lintian error that should get fixed before release. I pushed most of what changes I'd made to salsa, I need change the d/rules to keep a __pycache__ file from getting added to the -doc package, (not done yet) But then it should be ready to upload, but I'm tired so I wont get to it tonight. Diane
Bug#1029232: dask.distributed: broken by version mismatch with dask
On Fri, 2023-01-20 at 21:02 +, Rebecca N. Palmer wrote: > Would you like some help? If so, please push what you currently have > to > Salsa so we can see it. > > (No promises - #1029251 doesn't look like a big job but I might be > wrong > about that.) In shocking news, the build I did this morning actually finished. I should hopefully be able to organize the hacks and commit them to salsa tonight. Maybe even get it uploaded tonight to. Diane
Bug#1029232: dask.distributed: broken by version mismatch with dask
On Fri, 2023-01-20 at 07:57 +, Rebecca N. Palmer wrote: > Package: python3-distributed > Version: 2022.02.0+ds1-3 > Severity: serious > > dask.distributed has been failing its autopkgtests since dask was > upgraded to 2022.12.1. Yep. Andreas did the upload of dask 2022.12.1 with out asking me about it first. I've been desperately trying to get dask.distributed 2022.12.1 to build and run all it's tests since then. I'm still not done. Sadly because of the networking use dask.distributed is incompatible with xdist and so I can't speed up the tests.
Bug#1028691: dask.distributed: FTBFS: unsatisfiable build-dependencies: python3-dask (>= 2022.02.0), python-numpy-doc
On Wed, 2023-01-18 at 10:49 +0100, Sebastiaan Couwenberg wrote: > On 1/18/23 08:38, Sebastiaan Couwenberg wrote: > > python-numpy-doc has been dropped from the build dependencies in > > git, > > but the package FTBFS due to test failures. Those might be fixed in > > a > > new upstream release, but that may introduce regressions in its > > rdeps. > To workaround the two failing tests a patch has been added to mark > them > as xfail. > > The package now builds successfully, but needs more work before I'd > be > comfortable uploading it. Anyone else is free to upload it instead. > > Kind Regards, > > Bas > I've been working on updating dask.distributed to 2022.12.1 to match the dask version of dask and almost have an version where the tests pass (or are disabled). I'll probably have it uploaded in 10 - 30 hours. Diane
Bug#1028667: dask BD-Uninstallable
On Sun, 2023-01-15 at 14:42 -0800, Diane Trout wrote: > On Sun, 2023-01-15 at 18:16 +, Rebecca N. Palmer wrote: > > Probably fixed - see my merge request on Salsa. > > > > > I'd tried to build versions of dask from 2022.03 - 2022.06 and they > all > failed with what appeared to be a strong dependency on pyarrow, which > debian doesn't have. > > Did you get around that for 2022.12? Apparently 2022.12.1 builds without issue. I merged your salsa PR, have a couple useful things from my branch and there's about 2 tests triggering 5 failures in the autopkgtests to see if I can tell whats wrong with in 2022.12.1 Though before releasing it I would like to try to build the matching dask.distributed package. Though I also need to clean up my git history to get the 2022.12.1 changes I made onto salsa. But I'm going to do that tomorrow morning. Diane
Bug#1028667: dask BD-Uninstallable
On Sun, 2023-01-15 at 18:16 +, Rebecca N. Palmer wrote: > Probably fixed - see my merge request on Salsa. > I'd tried to build versions of dask from 2022.03 - 2022.06 and they all failed with what appeared to be a strong dependency on pyarrow, which debian doesn't have. Did you get around that for 2022.12? For what it's worth I had almost managed to back port enough of the pandas 1.5 compatibility stuff to 2022.02 to get it working correctly. To deal with the different repositories I pushed what I'd done to https://salsa.debian.org/diane/dask There's two errors left. One's a deprecation warning from SQLAlchemy that can probably be ignored as it's about SQLAlchemy 2.0 and there's one test failure in: FAILED dataframe/tests/test_arithmetics_reduction.py::test_reductions_frame_dt ypes_numeric_only - AssertionError: Series are different when I get a chance I'll try building your 2022.12 branches, but I have to go deal with family obligations now. Diane
Bug#1026286: Unsatisfiable versioned dependency on python3-numpy
On Wed, 2023-01-11 at 13:15 +0100, Enrico Zini wrote: > > Thanks! I've opened > https://github.com/numba/numba/issues/8703 upstream > to track the possibility of numba making it in time for testing: > let's > see what happens. > Thnaks I commented with the what I did to get numba to build.
Bug#1026286: Unsatisfiable versioned dependency on python3-numpy
On Sat, 2022-12-17 at 20:19 +0100, Enrico Zini wrote: > Package: python3-numba > Version: 0.56.2+dfsg-2 > Severity: serious > > Hello, > > thank you for maintaining python3-numba! > > Unfortunately the package is currently uninstallable in sid. > > It depends on `python3-numpy (<< 1:1.22), python3-numpy (>= > 1:1.20.0)`, > but the version of python3-numpy in sid is 1:1.23.5-2. > Yeah I know. Numba frequently lags on python and numpy updates. I think they're closer to having numpy fixes done than python 3.11 though. There's some patches, I've got some of them applied by the system I was using for a build server broke and I haven't had a chance to fix it.
Bug#1027254: dask and pandas 1.5
On Mon, 2023-01-09 at 08:00 +, Rebecca N. Palmer wrote: > To get the new upstream version to work, dask_sphinx-theme, dask and > dask.distributed all need to be updated, in that order. Tests here: > https://launchpad.net/~rebecca-palmer/+archive/ubuntu/dask2022p12v2/+packages Ok thanks for the updates. I'll try to work on it. As an explanation the dask tests have a dependency on on dask.distribute being installed. And the easiest way I had to deal with that was to skip the build time tests in favor of autopkgtests.
Bug#1028182: ITP: throttler -- Provides rate-limiting features using asyncio
Package: wnpp Severity: wishlist Owner: Diane Trout X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: throttler Version : 1.22 Upstream Contact: Ramzan Bekbulatov * URL : https://github.com/uburuntu/throttler * License : MIT/expat Programming Lang: Python Description : Provides rate-limiting features using asyncio Zero-dependency Python package for easy throttling with asyncio support. Originally snakemake was using a different package to provide a similar rate limiting feature called ratelimiter. However the last release for ratelimiter was in 2017, and the package contains syntax that no longer works with Python 3.11. So in snakemake 7.18.2 they switched to using this package instead. https://snakemake.readthedocs.io/en/stable/project_info/history.html#id5 This is a small package I intend to add to the python modules team. Diane
Bug#1028175: snakemake rulename failes with asyncio has no attribute coroutine with python3.11
Package: snakemake Version: 7.12.1-1 Severity: serious Dear Maintainer, I noticed that snakemake-modes tests were failing while I was trying to build the package. Eventually I found that running the snakemake executable was failing with python 3.11, but worked with 3.10. Using the test Snakefile from snakemake-mode for the tests I ran the command with both python3.11 and python3.10. The results are below. I should probably go try to package the throttle library and upload it to NEW. Snakemake's upstream patched snakemake to use a different library throttle in https://github.com/snakemake/snakemake/issues/1952 $ python3.11 /usr/bin/snakemake --dryrun aa.out Building DAG of jobs... Traceback (most recent call last): File "/usr/lib/python3/dist-packages/snakemake/__init__.py", line 730, in snakemake success = workflow.execute( ^ File "/usr/lib/python3/dist-packages/snakemake/workflow.py", line 942, in execute self.scheduler = JobScheduler( ^ File "/usr/lib/python3/dist-packages/snakemake/scheduler.py", line 105, in __init__ from ratelimiter import RateLimiter File "/usr/lib/python3/dist-packages/ratelimiter.py", line 36, in class RateLimiter(object): File "/usr/lib/python3/dist-packages/ratelimiter.py", line 127, in RateLimiter __aexit__ = asyncio.coroutine(__exit__) ^ AttributeError: module 'asyncio' has no attribute 'coroutine' $ python3.10 -Wd /usr/bin/snakemake --dryrun aa.out Building DAG of jobs... /usr/lib/python3/dist-packages/ratelimiter.py:127: DeprecationWarning: "@coroutine" decorator is deprecated since Python 3.8, use "async def" instead __aexit__ = asyncio.coroutine(__exit__) Job stats: job countmin threadsmax threads - --- - - aa 1 1 1 total1 1 1 [Sat Jan 7 19:56:59 2023] rule aa: output: aa.out jobid: 0 reason: Missing output files: aa.out resources: tmpdir=/tmp Job stats: job countmin threadsmax threads - --- - - aa 1 1 1 total1 1 1 Reasons: (check individual jobs above for details) missing output files: aa This was a dry-run (flag -n). The order of jobs does not reflect the order of execution. /usr/lib/python3.10/tempfile.py:999: ResourceWarning: Implicitly cleaning up _warnings.warn(warn_message, ResourceWarning) -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'oldstable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages snakemake depends on: ii ca-certificates 20211016 ii libjs-bootstrap 3.4.1+dfsg-3 ii libjs-jquery 3.6.1+dfsg+~3.5.14-1 ii python3 3.10.6-3+b1 ii python3-appdirs 1.4.4-3 ii python3-configargparse 1.5.3-1 ii python3-connection-pool 0.0.3-2 ii python3-datrie 0.8.2-4 ii python3-docutils 0.17.1+dfsg-3 ii python3-git 3.1.27-1 ii python3-jinja2 3.0.3-2 ii python3-jsonschema 4.9.1-3 ii python3-nbformat 5.5.0-1 ii python3-pkg-resources65.5.0-1.1 ii python3-psutil 5.9.4-1 ii python3-pulp 2.6.0+dfsg-1 ii python3-ratelimiter 1.2.0.post0-3 ii python3-requests 2.28.1+dfsg-1 ii python3-smart-open 5.2.1-5 ii python3-stopit 1.1.2-2 ii python3-tabulate 0.8.9-1 ii python3-toposort 1.7-1 ii python3-wrapt1.14.1-2+b1 ii python3-yaml 6.0-3+b1 Versions of packages snakemake recommends: ii cwltool 3.1.20221201130942-1 ii imagemagick 8:6.9.11.60+dfsg-1.3+b4 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3+b4 ii python3-azure-storage20221101+git-2 ii python3-biopython1.80+dfsg-1 ii python3-boto31.26.27+dfsg-1 ii python3-botocore 1.29.27+repack-1 ii python3-dropbox 11.34.0-1 ii python3-flask2.2.2-2 ii python3-ftputil 5.0.4-1 ii python3-irodsclient 0.8.1-3 ii python3-kubernetes 22.6.0-2 ii python3-pygments 2.13.0+dfsg-1 ii python3-tz 2022.7-1 ii python3-urllib3 1.26.12-1 ii python3-yappi1.4.0-1 Versions of packages
Bug#1024795: python-llvmlite
On Fri, 2022-12-23 at 10:56 -0500, M. Zhou wrote: > Control: tags -1 +moreinfo > > I'm confused. How did you manage to build the package from source > using c65b3e662b7b08920172b710419d7a06b660be59 on salsa? > > I did not upload it because I can never successfully build it > from source. > It turns out I was confused and had slipped an additional change into c37e824380fec443edb24c914b1767dcff496d38.patch and forgotten about it while I was flailing at numba. I found the small change and am attaching it It adds an #include "llvm/Pass.h" to passmanager.cpp And I was slow in replying because I was building llvmlite and numba and making sure the tests run. (Numba's tests can take a couple of hours to run) Hope that helps. Diane --- a/ffi/passmanagers.cpp +++ b/ffi/passmanagers.cpp @@ -22,6 +22,7 @@ #include "llvm/Transforms/IPO.h" #include "llvm/Transforms/Scalar.h" +#include "llvm/Pass.h" #include using namespace llvm;
Bug#1024795: python-llvmlite
Hi, I was trying to update numba, and need the updated version of llvmlite built against llvm-14 The version that's currently in unstable is still built against llvml- 11 https://packages.debian.org/sid/python3-llvmlite I've checked out out the llvmlite repository and rebuilt it locally using commit c65b3e662b7b08920172b710419d7a06b660be59 against llvm-14 and llvmlite's test cases pass. (And most of numba's passed too. And I think the remaining test failures aren't related to llvmlite) Is there a chance we could get an updated version released soon? Thanks Diane Trout signature.asc Description: This is a digitally signed message part
Bug#1024648: elpa-snakemake: fails to install with emacs 27: misses 'transient'
On Tue, 2022-11-22 at 18:24 +0100, Andreas Beckmann wrote: > > There needs to be either a > Depends: emacs-el (>= 1:28) > or an equivaent > Breaks: (emacs-el (<< 1:28) > or the installation must be skipped if emacs is too old. So it looks like elpa-snakemake depends on the transient package which is currently elpa-transient and in included in emacs 28. So what do you think of this instead? Depends: emacs-el (>= 1:28) | elpa-transient, Diane
Bug#1023208: evolution: Evolution calendar is highlighting tomorrow, not today.
Package: evolution Version: 3.46.1-1 Severity: normal X-Debbugs-Cc: none, Diane Trout Dear Maintainer, For some reason my instance of evolution has started highlighting the next day in the work week calendar. So as I write this on Monday, October 31st, looking at the work week calendar, Tuesday 01 November is highlighted with the red "current time" line moving toward an appointment tomorrow. I did check that the correct date is highlighted in the flatpak version. Though that's using 3.46.0 (Commit 0414db49604c08e720a5c6256c60dfcfd4dc8a500949789ec736a609018de1ca) and the change was recent enough that if it's not a configuration issue on my system the bug could've been introduced in the .1 release. Thanks, Diane Trout -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'oldstable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evolution depends on: ii dbus [default-dbus-system-bus] 1.14.4-1 ii evolution-common3.46.1-1 ii evolution-data-server 3.46.1-1 ii libc6 2.35-3 ii libcamel-1.2-64 3.46.1-1 ii libecal-2.0-2 3.46.1-1 ii libedataserver-1.2-27 3.46.1-1 ii libevolution3.46.1-1 ii libglib2.0-02.74.0-3 ii libgtk-3-0 3.24.34-3 ii libical33.0.16-1 ii libnotify4 0.8.1-1 ii libwebkit2gtk-4.1-0 2.38.0-3 ii libxml2 2.9.14+dfsg-1+b1 ii psmisc 23.5-3 Versions of packages evolution recommends: pn evolution-plugin-bogofilter | evolution-plugin-spamassassin ii evolution-plugin-pstimport 3.46.1-1 ii evolution-plugins3.46.1-1 ii yelp 42.2-1 Versions of packages evolution suggests: ii evolution-ews 3.46.1-1 pn evolution-plugins-experimental ii gnupg 2.2.40-1 ii network-manager 1.40.2-1 -- no debconf information
Bug#1000922: upgrading llvmlite to llvm-13
Hi,
I found a pull request that starts the process of upgrading llvmlite to
llvm-12 or -13.
https://github.com/numba/llvmlite/pull/802
I modified it to work with our llvmlite 0.39.1 package and was able to
build llvmlite and have it's tests pass on x86 64.
The llvmlite upstream developers are concerned about releasing it
because in their experience they have various compile errors on unusual
architectures.
Though I'm having those with the llvm-11 version too, so who knows.
I was thinking that releasing it to Debian's buildd would help upstream
see which architectures are having problems with the migration to llvm-
13
I've been trying to build and run numba's tests, it's been a bit
difficult to tell what's failures are new because of building against
llvm-13 and which are because there's some failures due to the
autopkgtest environment being different from what upstream expects.
I think there's only a couple of test failures out of the about 20 I'm
trying to fix that are due to the llvm-13 update.
Since there's already some numba test failures with ppc64el and amdel
even with the llvm-11 version of llvmlite, I feel like releasing the -
13 version of llvmlite isn't going to make things any worse for numba.
So should we uploading a version of llvmlite with the -13 compatibility
patch?
They both fell out of testing, and it'd be really bad for the
scientific python ecosystem if we don't get numba shipped in bullseye.
Diane
From 1d928ebcd59b23b5050234a2bf71f9be7f5f6bd1 Mon Sep 17 00:00:00 2001
From: Richard Barnes
Date: Wed, 1 Dec 2021 10:29:08 -0700
Subject: [PATCH] Enable LLVM-12 and LLVM-13
---
ffi/build.py | 5 ++---
ffi/targets.cpp| 2 ++
llvmlite/tests/test_binding.py | 19 ---
3 files changed, 20 insertions(+), 6 deletions(-)
--- a/ffi/build.py
+++ b/ffi/build.py
@@ -163,9 +163,8 @@
print(msg)
print(warning + '\n')
else:
-
-if not out.startswith('11'):
-msg = ("Building llvmlite requires LLVM 11.x.x, got "
+if not (out.startswith('11') or out.startswith('12') or out.startswith('13')):
+msg = ("Building llvmlite requires LLVM 11-13.x.x, got "
"{!r}. Be sure to set LLVM_CONFIG to the right executable "
"path.\nRead the documentation at "
"http://llvmlite.pydata.org/ for more information about "
--- a/ffi/targets.cpp
+++ b/ffi/targets.cpp
@@ -204,7 +204,9 @@
rm = Reloc::DynamicNoPIC;
TargetOptions opt;
+#if LLVM_VERSION_MAJOR < 12
opt.PrintMachineCode = PrintMC;
+#endif
opt.MCOptions.ABIName = ABIName;
bool jit = JIT;
--- a/llvmlite/tests/test_binding.py
+++ b/llvmlite/tests/test_binding.py
@@ -18,6 +18,16 @@
from llvmlite.tests import TestCase
+def clean_string_whitespace(x: str) -> str:
+# Remove trailing whitespace from the end of each line
+x = re.sub(r"\s+$", "", x, flags=re.MULTILINE)
+# Remove intermediate blank lines
+x = re.sub(r"\n\s*\n", r"\n", x, flags=re.MULTILINE)
+# Remove extraneous whitespace from the beginning and end of the string
+x = x.strip()
+return x
+
+
# arvm7l needs extra ABI symbols to link successfully
if platform.machine() == 'armv7l':
llvm.load_library_permanently('libgcc_s.so.1')
@@ -555,7 +565,10 @@
bd = ir.IRBuilder(fn.append_basic_block(name="<>!*''#"))
bd.ret(ir.Constant(ir.IntType(32), 12345))
asm = str(mod)
-self.assertEqual(asm, asm_nonalphanum_blocklabel)
+self.assertEqual(
+clean_string_whitespace(asm),
+clean_string_whitespace(asm_nonalphanum_blocklabel)
+)
def test_global_context(self):
gcontext1 = llvm.context.get_global_context()
@@ -640,7 +653,7 @@
def test_version(self):
major, minor, patch = llvm.llvm_version_info
# one of these can be valid
-valid = [(11,)]
+valid = [(11,), (12,), (13,)]
self.assertIn((major,), valid)
self.assertIn(patch, range(10))
--- a/ffi/passmanagers.cpp
+++ b/ffi/passmanagers.cpp
@@ -17,9 +17,6 @@
#include "llvm-c/Transforms/IPO.h"
#include "llvm-c/Transforms/Scalar.h"
#include "llvm/IR/LegacyPassManager.h"
-#if LLVM_VERSION_MAJOR > 11
-#include "llvm/IR/RemarkStreamer.h"
-#endif
#include "llvm/IR/LLVMRemarkStreamer.h"
#include "llvm/Remarks/RemarkStreamer.h"
#include "llvm/Transforms/IPO.h"
signature.asc
Description: This is a digitally signed message part
Bug#1016283: onetbb: FTBFS: _segment_table.h:63:63: error: member ‘tbb::detail::d1::segment_table, 128>, tbb::detail::d1::cache_aligned_alloc
On Fri, 2022-08-12 at 13:57 +0200, Lucas Nussbaum wrote: > On 08/08/22 at 22:45 +0200, Richard B. Kreckel wrote: > > I am unable to reproduce the above compile-time error. > > Hi, > > I can still reproduce it. > > Lucas > I saw this bug floating around and thought I'd try building tbb as well. The version in git on salsa built for me without issues. Though I was wondering if maybe the build process behaves differently depending on the cpu architecture? I've run into a few programs that behave differently at compile time depending on the build cpu. So here's the end of the sbuild run and the start of cat /proc/cpuinfo on the machine I used. +-- + | Summary | +-- + Build Architecture: amd64 Build Type: full Build-Space: 2839101 Build-Time: 1683 Distribution: unstable Host Architecture: amd64 Install-Time: 82 Job: /woldlab/loxcyc/home/diane/src/debian/onetbb_2021.5.0-13.dsc Lintian: info Machine Architecture: amd64 Package: onetbb Package-Time: 1775 Source-Version: 2021.5.0-13 Space: 2839101 Status: successful Version: 2021.5.0-13 --- - Finished at 2022-08-24T18:51:48Z Build needed 00:29:35, 2839101k disk space diane@trog:~/src/debian/tbb$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU E5320 @ 1.86GHz stepping: 7 microcode : 0x66 cpu MHz : 1748.216 cache size : 4096 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm pti tpr_shadow dtherm vmx flags : tsc_offset vtpr bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips: 3723.91 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Bug#1017075: #1017075 dask - autopkgtest regression on i386 and armhf
On Mon, 2022-08-22 at 08:37 +0200, Graham Inggs wrote: > Hi Drew > > On Sun, 21 Aug 2022 at 19:08, Drew Parsons > wrote: > > In regards to bug severity, the dask debci failures are now marked > > as > > "Not a regression" so they won't hold up migration of dask. > > Dask's autopkgtests are failing in testing since the removal of > scikit-learn. I raised the severity of this bug precisely to prevent > this accidental migration. > > > Graham, should the bug severity therefore be reduced from Serious > > back > > down to Important to enable migration of both dask and scipy? > > Please don't. Hopefully working around the 32-bit test failures is enough to resolve the problems for scipy?
Bug#998705: Many 502 errors, when using apt-cacher-ng for Debian installation
On Wed, 16 Feb 2022 09:28:13 -0300 Eriberto Mota wrote: > Hi guys, > > I am running Debian Stable (Bullseye) in my desktop and in my local server. > > Yesterday I made a backport version of the apt-cacher-ng for me and I put it > in the server. The problem seems is solved. > > Regards, > > Eriberto > > Just wanted to add in. I was experiencing the 502 errors, I installed the version apt-cacher-ng 3.7.4-1~bpo11+1 from backports and the 502 errors went away. Diane
Bug#1016877: org-mode-doc: The info documentation doesn't override the version shipped with emacs
On Mon, 2022-08-08 at 18:54 -0300, David Bremner wrote: > Diane Trout writes: > > > > > Though debian-el might be a better example to follow where the info > > file > > and its dir file are added to the elpa-src directory. > > > > Although that's my doing (I think) I have to note that it makes the > info > files inaccessible to /usr/bin/info, so might not be an ideal > solution. Hmm... I think ultimately the problem was caused for me by ending up with this value for Info-directory-list "/usr/share/info/emacs" "/usr/share/info/" "/usr/share/info/") If it looked like this it probably would work correctly "/usr/share/info/" "/usr/share/info/emacs" "/usr/share/info/") I just couldn't figure out where the /usr/share/info/emacs was getting added. Diane
Bug#1016877: org-mode-doc: The info documentation doesn't override the version shipped with emacs
Package: org-mode-doc
Version: 9.5.2-1
Severity: normal
X-Debbugs-Cc: none, Diane Trout
Dear Maintainer,
I was trying to read the info documentation provided by the org-mode-doc
package which matched the version of org mode I was using (9.5.2) but by
default was actually getting the org documentation shipped with emacs
version 9.3.
After digging for a while into how the Info-directory-list variable was
defined, the default looked like the following, and with the 9.5
documentation found in "/usr/share/info".
("/usr/share/emacs/site-lisp/elpa/debian-el-37" "/usr/share/info/emacs"
"/usr/share/info/" "/usr/share/info/")
I tried figure out how to adjust the construction of the
Info-directory-list to put a "/usr/share/info" before the flavor
directory "/usr/share/info/emacs" but couldn't figure it out.
But then I tried to figure out why there was the debian-el-37 directory on
the Info-directory-list path.
What I found is if the info dir file is present in one of the
automatically loaded package directories that directory will be
pre-pended to the Info-directory-list path.
Somehow adding a dir file to
/usr/share/emacs/site-lisp/elpa/org-9.5.2/ causes info to find the newer
version. I'd copied the dir file and a decompressed version of
org.info.gz into /usr/share/info/emacs/site-lisp/elpa/org-9.5.2
Though debian-el might be a better example to follow where the info file
and its dir file are added to the elpa-src directory.
Thanks,
Diane
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500,
'oldstable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
org-mode-doc depends on no packages.
org-mode-doc recommends no packages.
Versions of packages org-mode-doc suggests:
ii elpa-org [org-mode] 9.5.2+dfsh-4
-- no debconf information
Bug#1016769: ITP: elpa-snakemake -- support for editing and running snakemake files in emacs
Package: wnpp Owner: Diane Trout Severity: wishlist * Package name: elpa-snakemake Version : 2.0.0 Upstream Author : Kyle Meyer * URL or Web page : https://git.kyleam.com/snakemake-mode/about * License : GPL-3+ Description : support for editing and running snakemake files in emacs The source repository is broken up into providing two emacs packages. One snakemake.el provides support for running snakemake in an emacs transient mode, the other snakemake-model.el adds syntax highlighting for editing snakemake files within emacs.
Bug#1016719: dask: test_query_with_meta fails on 32 bit arches
On Sat, 2022-08-06 at 03:15 +0200, Drew Parsons wrote: > Source: dask > Version: 2022.02.0+dfsg-1 > Severity: normal > Control: forwarded -1 https://github.com/dask/dask/issues/8620 > > dask 2022.02.0 is failing two CI tests on 32 bit arches (armhf, > i386), > one in test_query_with_meta, the other in test_categorize_info > > The test_query_with_meta error is reported upstream at > https://github.com/dask/dask/issues/8620 > > The test_categorize_info error was dealt with upsteam with your patch > applied in https://github.com/dask/dask/pull/8851 which should be > applied in the 2022.04.0 release. Those seem reasonable things to backport, I'll try to get to it soon. > > Since we've got the pyarrow dependency getting in the way of > upgrading > to the more recent dask releases as noted in Bug#1013080, should we > pull > in the PR#8851 patch to debian/patches to fix test_categorize_info ? > > I did learn someone started packaging arrow and looks like they got somewhere, but I'm not sure how much more is needed to get it into NEW. https://salsa.debian.org/science-team/arrow/ Diane
Bug#1014690: llvmlite breaks numba autopkgtest: segmentation fault
On Thu, 2022-07-14 at 10:10 +0200, Paul Gevers wrote: > Control: reassign 1014690 src:llvmlite 0.38.1-2 > Control: affects 1014690 src:numba > Control: fixed 1014690 0.38.1-3 > > Hi Diane, > > On 14-07-2022 05:26, Diane Trout wrote: > > I know there's some problems with some of numba's autopkgtests but > > I > > couldn't reproduce the segmentation fault. > > That's because Mo reverted the change to use llvm-toolchain-13 in > llvmlite. > > > llvmlite's tracker suggests that the tests are passing now? > > > > Did you find a solution or is this likely to be a random problem? > > Well, reverting reopened another issue we have which is that we want > to > drop llvm-toolchain-11 from testing. In that case what about submitting the llvm-toolchain-13 version of llvmlite to experimental to start the process of trying to fix what it breaks? Diane signature.asc Description: This is a digitally signed message part
Bug#1014690: llvmlite breaks numba autopkgtest: segmentation fault
Hi, I know there's some problems with some of numba's autopkgtests but I couldn't reproduce the segmentation fault. llvmlite's tracker suggests that the tests are passing now? Did you find a solution or is this likely to be a random problem? Diane On Sun, 2022-07-10 at 13:10 +0200, Paul Gevers wrote: > Source: llvmlite, numba > Control: found -1 llvmlite/0.38.1-2 > Control: found -1 numba/0.55.2+dfsg-1 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of llvmlite the autopkgtest of numba fails in > testing when that autopkgtest is run with the binary packages of > llvmlite from unstable. It passes when run with only packages from > testing. In tabular form: > > pass fail > llvmlite from testing 0.38.1-2 > numba from testing 0.55.2+dfsg-1 > all others from testing from testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of llvmlite to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? > > More information about this bug and the reason for filing it can be > found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=llvmlite > > https://ci.debian.net/data/autopkgtest/testing/arm64/n/numba/23504675/log.gz > > [*] Testing with python3.9: > /usr/lib/python3/dist-packages/numba/tests/npyufunc/test_gufunc.py:5: > DeprecationWarning: numpy.core.umath_tests is an internal NumPy > module > and should not be imported. It will be removed in a future NumPy > release. > import numpy.core.umath_tests as ut > /usr/lib/python3/dist- > packages/numba/tests/test_llvm_version_check.py:1: > DeprecationWarning: the imp module is deprecated in favour of > importlib; > see the module's documentation for alternative uses > import imp > skipped CUDA tests > skipped CUDA tests > Parallel: 9022. Serial: 652 > test (numba.tests.gdb.test_array_arg.Test) ... skipped 'needs > subprocess > harness' > test (numba.tests.gdb.test_basic.Test) ... skipped 'needs subprocess > harness' > test (numba.tests.gdb.test_break_on_symbol.Test) ... skipped 'needs > subprocess harness' > test (numba.tests.gdb.test_conditional_breakpoint.Test) ... skipped > 'needs subprocess harness' > test_axis (numba.tests.npyufunc.test_gufunc.TestGUFunc) ... ok > test_axis (numba.tests.npyufunc.test_gufunc.TestDynamicGUFunc) ... ok > test_basic_gufunc > (numba.tests.npyufunc.test_ufuncbuilding.TestGUfuncBuilding) ... ok > test_basic_gufunc > (numba.tests.npyufunc.test_ufuncbuilding.TestGUfuncBuildingJitDisable > d) > ... ok > test_basic_ufunc > (numba.tests.npyufunc.test_ufuncbuilding.TestUfuncBuilding) ... ok > test_basic_ufunc > (numba.tests.npyufunc.test_ufuncbuilding.TestUfuncBuildingJitDisabled > ) > ... ok > test_documentation_example1 > (numba.tests.doc_examples.test_rec_array.TestExample) ... ok > test_docstring (numba.tests.npyufunc.test_gufunc.TestGUFunc) ... ok > test_broadcasting (numba.tests.npyufunc.test_ufunc.TestUFuncs) ... ok > test_dynamic_ufunc_like > (numba.tests.npyufunc.test_gufunc.TestDynamicGUFunc) ... ok > test_dynamic_scalar_output > (numba.tests.npyufunc.test_gufunc.TestDynamicGUFunc) > Note that scalar output is a 0-dimension array that acts as ... ok > test_documentation_example2 > (numba.tests.doc_examples.test_rec_array.TestExample) ... ok > test_dynamic_matmul > (numba.tests.npyufunc.test_gufunc.TestDynamicGUFunc) > ... ok > Fatal Python error: Segmentation fault > > Current thread 0xac447010 (most recent call first): > File > "/usr/lib/python3/dist- > packages/numba/tests/doc_examples/test_typed_list_usage.py", > line 34 in test_ex_inferred_list_jit > File "/usr/lib/python3.9/unittest/case.py", line 550 in > _callTestMethod > File "/usr/lib/python3.9/unittest/case.py", line 592 in run > File "/usr/lib/python3.9/unittest/case.py", line 651 in __call__ > File "/usr/lib/python3/dist-packages/numba/testing/main.py", line > 664 > in __call__ > File "/usr/lib/python3.9/multiprocessing/pool.py", line 125 in > worker > File "/usr/lib/python3.9/multiprocessing/process.py", line 108 in > run > File "/usr/lib/python3.9/multiprocessing/process.py", line 315 in > _bootstrap > File "/usr/lib/python3.9/multiprocessing/popen_fork.py", line 71 > in > _launch > File "/usr/lib/python3.9/multiprocessing/popen_fork.py", line 19 > in > __init__ > File "/usr/lib/python3.9/multiprocessing/context.py", line 277 in > _Popen > File "/usr/lib/python3.9/multiprocessing/process.py", line 121 in > start > File "/usr/lib/python3.9/multiprocessing/pool.py", line 326 in > _repopulate_pool_static >
Bug#1013080: dask: incompatibility with scipy 1.8
On Sat, 2022-06-25 at 10:17 +0200, Graham Inggs wrote: > Control: severity -1 serious > Control: tags -1 + patch > > Please see attached patch from Ubuntu for this issue. Thank you for the patch it worked well. I wanted to give a status update since it's been a while. I haven't made as much progress as I should've I tried to update to 2022.6 but that depends on pyarrow and adding that looks like it will requires packaging the full Apache arrow library https://github.com/apache/arrow That looks like it'll be a bit unpleasant to package because it's a library designed to interact with a large number of other languages and environments. Then I went back and started updating and got discovered they'd added the arrow dependency in 2022.03 which is the version with the fix you need in it. I have a version of 2022.02.0 that built with the patch and tested correctly with scipy 1.8.1, but I need to clean up my repository some before I push anything new to salsa. There's also a few new simple sphinx build dependencies that look like they were added in 2022.03 but those were pretty easy to package, though I still need to upload them to NEW. Hopefully I'll have something uploaded in a day or two. Diane
Bug#1013297: ITP: geiser-mit -- MIT/GNU Scheme's implementation of the geiser protocols
Package: wnpp Owner: Diane Trout Severity: wishlist * Package name: geiser-mit Version : 0.15 Upstream Author : Jose Antonio Ortega Ruiz * URL or Web page : https://geiser.nongnu.org/ https://gitlab.com/emacs-geiser/mit * License : BSD 3-Clause License Description : MIT/GNU Scheme's implementation of the geiser protocols Geiser is a generic Emacs/Scheme interaction mode, featuring an enhanced REPL and a set of minor modes improving Emacs’ basic scheme major mode. This package add support for MIT/GNU Scheme in Geiser. I'm planning on submitting this to the debian emacs team. It's part of the breakout of geiser's language specific modules into their own repositories.
Bug#1013296: ITP: geiser-chibi -- chibi language support for elpa-gesier
Package: wnpp Owner: Diane Trout Severity: wishlist * Package name: geiser-chibi Version : 0.17 Upstream Author : Jose Antonio Ortega Ruiz * URL or Web page : http://geiser.nongnu.org/ source https://gitlab.com/emacs-geiser/chibi * License : BSD-3-Clause Description : chibi language support for elpa-gesier This package provides support for using Chibi Scheme in Emacs with Geiser. . Provided geiser-core is installed in your system, if this package’s directory is in your load path, just add (require 'geiser-chibi) to your initialisation files and then M-x run-chibi to start a REPL. I'm planning on adding this to the debian emacs team. It's support files for another scheme language for elpa-geiser.
Bug#1013092: ITP: python3-sphinx-autosummary-accessors -- sphinx autosummary extension to pandas or xarray accessors
On Fri, 2022-06-17 at 00:32 +0200, Jonas Smedegaard wrote: > > I guess that by "MIT / Expat" you mean that you declared the project > as > beinge effectively licensed "MIT or Expat". Upstream lists this license: https://github.com/xarray-contrib/sphinx-autosummary-accessors/blob/main/LICENSE Which looks like MIT (Expat) https://www.debian.org/legal/licenses/mit > > From your description of the situation, the better approach is to > instead declare it as licensed "MIT and Expat". In reading the history of how this project came to be they say at https://github.com/xarray-contrib/sphinx-autosummary-accessors sphinx.ext.autosummary is able to create summary and object pages for objects and their methods, but it doesn't work well with accessor styled properties and methods (obj.accessor.attribute). pandas has accessor documentation built using sphinx.ext.autosummary templates, which xarray recently adopted by copying the templates and all related code. To avoid even more duplicated code, and to make it easier for projects to document their custom accessors, this project aims to provide this functionality by way of a sphinx extension. Most of the code was adapted from pandas. Which is why I think the pandas BSD 3 clause license is included. So perhaps it would be best to say MIT and BSD-3-clause. Diane signature.asc Description: This is a digitally signed message part
Bug#1013092: ITP: python3-sphinx-autosummary-accessors -- sphinx autosummary extension to pandas or xarray accessors
Package: wnpp Owner: Diane Trout Severity: wishlist * Package name: python3-sphinx-autosummary-accessors Version : 2022.4.0-1 Upstream Author : Justus Magin * URL or Web page : https://github.com/xarray-contrib/sphinx-autosummary-accessors * License : MIT Description : sphinx autosummary extension to pandas or xarray accessors This is a new dependency for building the documentation for dask. One confusing issue is the project is marked as being MIT licensed, but includes the pandas BSD-3 license because some of this project was derived from pandas. Unfortunately there's nothing that says what files were derived from pandas. So my copyright file marks everything as MIT / Expat, but includes the pandas BSD license block though I don't know what to attach it to. I was planning on adding this to the debian python team. Diane Trout
Bug#1013080: dask: incompatibility with scipy 1.8
Ok thanks for reporting.
I'll try to put some effort into updating to a newer version of dask
soon.
On Thu, 2022-06-16 at 16:10 +0200, Drew Parsons wrote:
> Source: dask
> Version: 2022.01.0+dfsg-2
> Severity: normal
> Control: tags -1 patch
>
> dask 2022.01 uses a deprecated scipy API and now fails tests with
> scipy 1.8.1:
>
> _ test_one[chisquare]
> __
>
> kind = 'chisquare'
>
> @pytest.mark.parametrize(
> "kind", ["chisquare", "power_divergence", "normaltest",
> "skewtest", "kurtosistest"]
> )
> def test_one(kind):
> a = np.random.random(size=30)
> a_ = da.from_array(a, 3)
>
> dask_test = getattr(dask.array.stats, kind)
> scipy_test = getattr(scipy.stats, kind)
>
> > result = dask_test(a_)
>
> /usr/lib/python3/dist-packages/dask/array/tests/test_stats.py:56:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> /usr/lib/python3/dist-packages/dask/array/stats.py:136: in chisquare
> return power_divergence(f_obs, f_exp=f_exp, ddof=ddof, axis=axis,
> lambda_="pearson")
> /usr/lib/python3/dist-packages/dask/array/stats.py:144: in
> power_divergence
> if lambda_ not in scipy.stats.stats._power_div_lambda_names:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
>
> name = '_power_div_lambda_names'
>
> def __getattr__(name):
> if name not in __all__:
> > raise AttributeError(
> "scipy.stats.stats is deprecated and has no attribute
> "
> f"{name}. Try looking in scipy.stats instead.")
> E AttributeError: scipy.stats.stats is deprecated and has
> no attribute _power_div_lambda_names. Try looking in scipy.stats
> instead.
>
> /usr/lib/python3/dist-packages/scipy/stats/stats.py:54:
> AttributeError
>
>
> Likewise
> test_two[chisquare-kwargs4]
> test_two[power_divergence-kwargs8]
> test_power_divergence_invalid
>
>
> The incompatibility is fixed in dask 2022.03 (lastest is 2022.6),
> or apply the patch in PR#8694
> https://github.com/dask/dask/pull/8694
>
>
>
>
>
> -- System Information:
> Debian Release: bookworm/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.18.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_AU:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
Bug#1012834: ITP: elpa-geiser-chicken -- Chicken's implementation of the geiser protocols
Package: wnpp Owner: Diane Trout Severity: wishlist * Package name: elpa-geiser-chicken Version : 0.17-1 Upstream Author : Jose Antonio Ortega Ruiz * URL or Web page : https://geiser.nongnu.org/ * License : BSD-3-Clause Description : Chicken's implementation of the geiser protocols Geiser is a generic Emacs/Scheme interaction mode, featuring an enhanced REPL and a set of minor modes improving Emacs’ basic scheme major mode. This package add support for Chicken in Geiser. This a language specific module for elpa-geiser and will be maintained in the debian-emacsen team. Diane
Bug#1012788: ITP: elpa-geiser-chez -- chez language support for elpa-geiser
Package: wnpp Owner: Diane Trout Severity: wishlist * Package name: elpa-geiser-chez Version : 0.17-1 Upstream Author : Jose A Ortega Ruiz * URL or Web page : https://geiser.nongnu.org/ * License : BSD-3 Clause Description : chez language support for elpa-geiser This package provides support for using Chez Scheme in Emacs with Geiser. . Provided geiser is installed in your system, if this package’s directory is in your load path, just add (require 'geiser-chez) to your initialisation files and then M-x run-chez to start a REPL. This is another package that is a scheme language specific mode associated with elpa-geiser. I plan on submitting it to the emacsen-team.
Bug#1012781: ITP: elpa-geiser-guile -- guile language support for elpa-gesier
Package: wnpp Owner: Diane Trout Severity: wishlist * Package name: elpa-geiser-guile Version : 0.23.2-1 Upstream Author : Jose Antonio Ortega Ruiz (j...@gnu.org) * URL or Web page : https://gitlab.com/emacs-geiser/guile/ * License : BSD-3-clause Description : guile language support for elpa-gesier This package provides support for using GNU Guile in Emacs with Geiser. . Provided geiser is installed in your system, if this package’s directory is in your load path, just add (require 'geiser-guile) to your initialisation files and then M-x run-guile to start a REPL. Scheme files with a Guile module declaration should be automatically recognised as Guile-flavoured Geiser buffers. The license is the "new" BSD 3 where the third clause is the non-endorsement clause. The version of geiser currently in Debian is a bit old and the language support files were included in the emacs elpa package. At some point upstream added support for more versions of scheme and decided to split the language specific modules out into separate packages. Diane
Bug#1012716: elpa-geiser: Package out of date and upstream likely moved
On Mon, 2022-06-13 at 08:24 -0300, David Bremner wrote: > Diane Trout writes: > > Hi Diane; > > Indeed geiser needs someone to care for it in Debian [1]. Interested? > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012753 Did Dhavan Vaidya drop out? I see on tracker.d.o they did an update in 2020. Also after looking at my udd page... The best I could say is I'm willing to try. https://udd.debian.org/dmd/?email1=diane%40ghic.org=diane%40debian.orghtml#todo Though honestly geiser looks relatively small and not that hard to maintain, it's big packages like numba or dask that are the most time consuming. Diane signature.asc Description: This is a digitally signed message part
Bug#1012717: [git-buildpackage/master] pkgpolicy: Use type annotations that also work for python 3.9
tag 1012717 pending thanks Date: Mon Jun 13 09:41:59 2022 +0200 Author: Diane Trout Commit ID: 09338d25d3da84fff9cbd0a17d87762744546122 Commit URL: https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=09338d25d3da84fff9cbd0a17d87762744546122 Patch URL: https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=09338d25d3da84fff9cbd0a17d87762744546122 pkgpolicy: Use type annotations that also work for python 3.9 Closes: #1012717
Bug#1012717: git-buildpackage: git-buildpackage should declare a dependency on python 3.10
On Sun, 2022-06-12 at 21:52 +0200, Guido Günther wrote: > > After looking the problem it up there's a line where it's trying to > > do a > > union type between _GenericAlias and NoneType, but that's a feature > > that > > was added in 3.10. > > https://peps.python.org/pep-0604/ > > > > Some of us on testing still have 3.9 as the default because numba > > doesn't work with 3.10. I think it's pretty reasonable to inidicate > > that > > gpb 0.9.27 does requires 3.10. > > I'm also happy to apply a patch that makes it compatible with python > 3.9 > again. The gain from the type annotations is pretty low atm. > -- Guido This looks like a good solution for 3.9 & 3.10 compatibility it works on both 3.9 and 3.10 and expresses the same meaning. https://docs.python.org/3/library/typing.html#typing.Optional Diane diff --git a/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py~ b/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py index c5427ee..9016828 100644 --- a/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py~ +++ b/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py @@ -34,8 +34,8 @@ class PkgPolicy(object): r'%(?P([^%]|\\%))+' r'\)s') -packagename_re: typing.Pattern[str] | None = None -packagename_msg: str | None = None -upstreamversion_re: typing.Pattern[str] | None = None -upstreamversion_msg: str | None = None +packagename_re: typing.Optional[typing.Pattern[str]] = None +packagename_msg: typing.Optional[str] = None +upstreamversion_re: typing.Optional[typing.Pattern[str]] = None +upstreamversion_msg: typing.Optional[str] = None @classmethod
Bug#1012717: git-buildpackage: git-buildpackage should declare a dependency on python 3.10
Package: git-buildpackage
Version: 0.9.27
Severity: normal
X-Debbugs-Cc: none, Diane Trout
Dear Maintainer,
I was attempting to update some packages using git-buildpackage and had
the following stack trace
~/src/debian/geiser$ gbp import-orig --uscan
Traceback (most recent call last):
File "/usr/bin/gbp", line 149, in
sys.exit(supercommand())
File "/usr/bin/gbp", line 137, in supercommand
module = import_command(cmd)
File "/usr/bin/gbp", line 71, in import_command
return __import__('gbp.scripts.%s' % modulename, fromlist='main', level=0)
File "/usr/lib/python3/dist-packages/gbp/scripts/import_orig.py", line 26, in
from gbp.deb import (DebianPkgPolicy, parse_changelog_repo)
File "/usr/lib/python3/dist-packages/gbp/deb/__init__.py", line 28, in
from gbp.deb.policy import DebianPkgPolicy# noqa: F401
File "/usr/lib/python3/dist-packages/gbp/deb/policy.py", line 27, in
from gbp.pkg.pkgpolicy import PkgPolicy
File "/usr/lib/python3/dist-packages/gbp/pkg/__init__.py", line 20, in
from gbp.pkg.pkgpolicy import PkgPolicy # noqa: F401
File "/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py", line 28, in
class PkgPolicy(object):
File "/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py", line 36, in
PkgPolicy
packagename_re: typing.Pattern[str] | None = None
TypeError: unsupported operand type(s) for |: '_GenericAlias' and 'NoneType'
After looking the problem it up there's a line where it's trying to do a
union type between _GenericAlias and NoneType, but that's a feature that
was added in 3.10.
https://peps.python.org/pep-0604/
Some of us on testing still have 3.9 as the default because numba
doesn't work with 3.10. I think it's pretty reasonable to inidicate that
gpb 0.9.27 does requires 3.10.
Thank you,
Diane Trout
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500,
'oldstable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages git-buildpackage depends on:
ii devscripts 2.22.1
ii git1:2.35.1-1
ii man-db 2.10.2-1
ii python33.9.8-1
ii python3-dateutil 2.8.1-6
ii python3-pkg-resources 59.6.0-1.2
ii sensible-utils 0.0.17
Versions of packages git-buildpackage recommends:
ii cowbuilder0.89
ii pbuilder 0.231
ii pristine-tar 1.49
ii python3-requests 2.27.1+dfsg-1
ii sbuild0.83.1
Versions of packages git-buildpackage suggests:
ii python3-notify2 0.3-4
ii sudo 1.9.10-3
ii unzip6.0-26
-- no debconf information
Bug#1012716: elpa-geiser: Package out of date and upstream likely moved
Package: elpa-geiser Version: 0.10-1 Severity: normal X-Debbugs-Cc: none, Diane Trout Dear Maintainer, Hello I was trying to experiment with emacs-guix, but it failed looking for a geiser symbol. I looked the versions of geisers available in guix and found they have 0.23.2 compared to Debian's 0.10.0 On the home page listed in the Debian metadata http://www.nongnu.org/geiser/ The source link now points at https://gitlab.com/emacs-geiser instead of http://download.savannah.gnu.org/releases/geiser/ which is in the debian/watch file the gitlab site lists 0.23.2 as the latest version. Diane Trout -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'oldstable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-geiser depends on: ii dh-elpa-helper 2.0.10 ii emacs1:27.1+1-3.1 ii emacs-gtk [emacsen] 1:27.1+1-3.1+b1 ii emacsen-common 3.0.4 it install-info 6.8-4+b1 elpa-geiser recommends no packages. Versions of packages elpa-geiser suggests: ii racket 8.4-1 -- no debconf information
Bug#440253: Please package inform 7
> Inform 7 is released piecemeal http://inform7.com/sources/>, with > many necessary components not yet released in source form at all. > People hoping to see this in Debian will, it seems, need to be patient > with the upstream developers. > > > Since Inform 7 seems to be an important development, it would be > > nice to have it in Debian. > > I agree. It will need to be a distinct package, though, as the > ‘inform’ package is soon to be renamed ‘inform6’ to reflect its focus > only on the Inform 6 system. As an update it appears that Inform7 was fully open sourced under the artistic public license with redistribution of derived works permission included. >From https://github.com/ganelson/inform "As from the first date of this repository becoming public, 28 April 2022, the Package is placed under the Artistic License 2.0."
Bug#982784: Packaged
Hi, I'm not sure if anyone else worked on this but I do have some packaging for flatseal. I'd like to see about joining the DebianOnMobile team first and hosting the package in that group before uploading it to new. Diane
Bug#1006333: biboumi: fail to start after libexpat1 update
FWIW I saw a more complex patch for this issue posted here https://lab.louiz.org/louiz/biboumi/-/commit/0061298dd0945f7f67e7fa340c6649b179c804d5 from the Biboumi XMPP muc. I added the patch to 9.0-4 and compiled it for bullseye, and it seems to work. I tried connecting to oftc.net and tried using the ad-hoc commands to try to configure some irc settings.
Bug#995735: dask.distributed: autopkgtest sometimes times out on ci.d.n worker since dask migrated
> > Indeed, in unstable. However, I just noticed a new issue and it's > that > the test fails in testing as it depends on a package that's not > available: python3-sparse. That's unfortunate. That's a new problem where python3-sparse depends on numba, but numba broke for python 3.10 and onetbb and I'm currently waiting for libtbb12 to hit unstable before I can update numba. I wonder if I can disable the sparse check for the moment. > > > I lowered the severity out of RC because I think it's better, but > > think > > I should still check CI a few more times before closing this > > Right. I agree with you that this issue seems of the past. Thanks for the confirmation. Diane signature.asc Description: This is a digitally signed message part
Bug#995735: dask.distributed: autopkgtest sometimes times out on ci.d.n worker since dask migrated
On Tue, 19 Oct 2021 21:48:27 +0200 Paul Gevers wrote: > Hi Diane, > > On 18-10-2021 20:53, Diane Trout wrote: > > I also glanced at the current CI build results and all the runs with > > 2021.09.1+ds.1-1 seem to be finishing in about 25 minutes both passing > > and faild tests. I do see the 2h runs with version 2021.08.1+ds.1-1 > > https://ci.debian.net/packages/d/dask.distributed/ > > > > Do you think that's a good enough test to close this bug? > > Well, the part about it timing out seems to be gone indeed, but the test > is still flaky as it fails on ci-worker13, but not on the others. > > Paul > How did you see that it failed on ci-worker13? I've looked through the recent CI build logs for dask-distributed. 2022.01 and they all seem to have worked, I lowered the severity out of RC because I think it's better, but think I should still check CI a few more times before closing this Diane
Bug#1006537: dask: autopkgtest failure on 32 bit, mismatch in size of data structure.
Hi, I had some time to work on this and worked around the test case that was failing, since it was failing because it was assuming it was running in a 64-bit environment. I submitted my comments to upstream here https://github.com/dask/dask/issues/8169#issuecomment-1059839906 I tested in a 32-bit chroot, and it seems like this should work. Though dask's autopkgtests will still fail because of python3-unicode2 is still in NEW. Diane signature.asc Description: This is a digitally signed message part
Bug#1006537: dask: autopkgtest failure on 32 bit, mismatch in size of data structure.
On Sun, 2022-02-27 at 08:34 +, Peter Michael Green wrote: > Package: dask > Version: 2022.01.0+dfsg-1 > Severity: serious > > The autopkgtest for dask is once-again failing on 32-bit > architectures, > this is blocking the fix for > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005962 > from migrating to testing. > Drat! I'd thought I'd found an upstream fix for that. And right now there's some problem where a dask dependency isn't installable in 32-bit as it depends on something still in NEW. The following packages have unmet dependencies: python3-fonttools : Depends: python3-unicodedata2 (>= 14.0.0) but it is not installable or python3-all (>= 3.11.0) but 3.9.8-1 is to be installed E: Unable to correct problems, you have held broken packages. So debugging it is a bit challenging at the moment. Diane
Bug#1000336: Upgrading tbb
On Wed, 2022-02-23 at 00:31 -0500, M. Zhou wrote: > Hello guys. Finally it's all green on our release architectures > https://buildd.debian.org/status/package.php?p=onetbb=experimental > > I shall request the slot for transition once finished the rebuild > of its reverse dependencies and filed FTBFS bugs if any. Wonderful! That is great news. Thank you! Diane
Bug#1000336: numba: FTBFS with Python 3.10
On Sat, 2022-02-19 at 11:02 +0100, Drew Parsons wrote: > Source: numba > Followup-For: Bug #1000336 > > onetbb is now building (in experimental) for all arches except > armel and armhf. > > Is it worth at this point to make an upload of numba 0.55 to > experimental to check that it's building and passing tests for the > other arches? It would... except numpy 1.22 just hit experimental on the 18th. and numba isn't compatible with numpy 1.22. I tried adding this to d/control, python3-numpy (<< 1.22), but my sbuild resolver still picked up numpy from experimental and refused to build. Upstream has a meta bug with the numpy 1.22 issues. https://github.com/numba/numba/issues/7754
Bug#1002402: python-sparse: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13
On Mon, 2022-02-21 at 02:24 +, Peter Michael Green wrote: > > During a rebuild of all packages in sid, your package failed to > > build > > on amd64. > > I'm no expert on this particular package, but this looks to me like > it is not actually caused by a problem in python-sparse, but is > instead a symptom of python3-numba not being built against python > 3.10 due to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000336 > Yep that was my interpretation as well. Numba 0.55.1 needs libtbb-dev > 2021.04, and 2021.05 is in experimental getting some weird architectures tested. However libtbb is going to need a transition. Unfortunately numpy 0.55.1 breaks with numpy 1.22 which is also in experimental Diane
Bug#1000336: Upgrading tbb
Hi, After Andreas pointed it out I looked through some of the build failures for onetbb and talked to upstream about the i386 failure. https://github.com/oneapi-src/oneTBB/issues/370#issuecomment-1030387116 They have a patch. https://github.com/oneapi-src/oneTBB/commit/542a27fa1cfafaf76772e793549d9f4d288d03a9 I've tested it against a checkout of the 2021.5.0-1 version of onetbb on i386 and it does build with it applied. Once there was a test failure, and once all tests ran successfully I see that you've made some more progress for the memory alignment bugs so I didn't commit "Detect 32 bit x86 systems while adding -mwaitpkg option" i386 patch but could if you want. Diane
Bug#1005181: dask: autopkgtest regression: dask/bytes/tests/test_http.py:120: Failed
On Tue, 2022-02-08 at 11:40 -0300, Emmanuel Arias wrote: > Source: dask > Version: 2021.09.1+dfsg-2 > Severity: important > X-Debbugs-Cc: eam...@yaerobi.com > > Dear Maintainer, > > The last update of fsspec package[0] cause a regression for dask[1]. > That is already fixed in upstream[2]. > > Please consider package new upstream release or backport the upstream > fix. Thanks for the report. Sadly I can't update dask to the latest version yet as they added a new dependency which is still in NEW. Hopefully the patch will backport. Diane
Bug#1005045: partd: pickle save+load data loss on ppc64el and s390x
I forwarded your report to upstream and asked them for their advice about what to do. I also wonder if a slight pause might help? or if partd needs some synchronization code. Diane
Bug#1000336: Upgrading tbb
On Thu, 2021-12-23 at 11:03 -0500, M. Zhou wrote: > Hi all, > > I'm back. > > I've just finished my final exams so I could do something during > the holiday. That TBB repository is still work-in-progress and > FTBFS from the master branch is something expected. I will finalize > it soon. Andreas said in previous posts that we prefer a faster > NEW queue process. I understand that but we cannot bypass NEW process > this time as upstream has bumped the SONAME. So I'm changing the > source name as well following the upstream since NEW is inevitable. > > As for llvmlite, the latest upstream RC release v0.38.0rc1 seems > to support python 3.10 . Should I upload the RC release? > > BTW, what else should I do? I've been out of sync from the mailing > list for a long while. Have you managed to make much progress? I fiddled with the packaging and got it to build and trying to run the autopkgtests with 2021.4.0-1 What'd help me is to have a package I could build locally and test numba against. If you got it working could you commit what you have to a salsa branch and let me know where it is? Thanks, Diane
Bug#1000336: numba: FTBFS with Python 3.10
On Wed, 2021-12-22 at 22:24 +0530, Nilesh Patra wrote: > > Upstream has mentioned that it has been fixed upstream. Diane, could > you > please do the needful and upload? > > Actually because of the current state of numba, several reverse > depends are FTBFS so it's > bit urgent to push. Apologies for getting on your nerves, though. I tried. but numba needs tbb version >= 2021. I tried to update tbb but ran into problems trying to build it. I pushed the compatibility patch to a python-3-10-compatibility branch on salsa for the moment. signature.asc Description: This is a digitally signed message part
Bug#1001348: dask: autopkgtest failures on 32 bit with pandas 1.3: Buffer type mismatch
I had been trying to update dask to newer version (2021.11.1), but it looks like the issue you referenced is still open. I tried the change they suggested in an i386 sbuild chroot and most of the errors went away. Though there was one test failure. "c.astype(np.int64, copy=False), k from np.int64 to np.intp fixes the issue?" Though since new dask version depended on a new sphinx plugin that I had to submit to the NEW queue I tried the patch on i386 with 2021.09.1 and those tests seemed to work. Let me see if 2021.09.1 works on amd64 and if it does I'll make a new 2021.09.1 release that's compatible with pandas 1.3 before trying to figure out whats going on with newer versions Diane On Wed, 2021-12-08 at 22:07 +, Rebecca N. Palmer wrote: > Package: python3-dask > Version: 2021.09.1+dfsg-1 > Severity: serious > Tags: patch > Control: forwarded -1 https://github.com/dask/dask/issues/8169 > (actually found independently) > > With pandas 1.3 (currently in unstable, see #999415), the dask > autopkgtest fails on armhf and i386 with > > /usr/lib/python3/dist-packages/dask/dataframe/backends.py:358: in > group_split_pandas > indexer, locations = pd._libs.algos.groupsort_indexer( > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ > _ _ _ _ > > > ??? > E ValueError: Buffer dtype mismatch, expected 'const intp_t' but > got > 'long long' > > pandas/_libs/algos.pyx:194: ValueError > > Full log: > https://ci.debian.net/data/autopkgtest/testing/armhf/d/dask/17399418/log.gz > > The above upstream bug says changing np.int64 to np.intp at > https://sources.debian.org/src/dask/2021.09.1+dfsg-1/dask/dataframe/backends.py/#L359 > > is a fix (which they haven't used, it's incompatible with earlier > pandas, but we don't need to care about that). >
Bug#1001607: ITP: sphinx-remote-toctree -- Reduce sphinx documentation build times
Package: wnpp Severity: wishlist Owner: Diane Trout X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: sphinx-remote-toctree Version : 0.0.3 Upstream Author : Chris Holdgraf * URL : https://github.com/executablebooks/sphinx-remove-toctrees * License : Expat Programming Lang: (Python Description : Reduce sphinx documentation build times ( Improve your Sphinx build time by selectively removing TocTree objects from pages. This is useful if your documentation uses auto-generated API documentation, which generates **a lot** of stub pages. . This extension can be used to remove the sidebar links for just the pages you specify, speed up the build considerably. . ## Who is this for? . This package is for maintainers that use Sphinx and have really large API documentation (or for some other reason, have a ton of nested pages). If you use a Sphinx theme that contains the entire Table of Contents on every page (e.g., any theme that has "collapsable" sidebar sections), this will slow things down considerably. Use this theme to speed up your builds. dask decided to require this package as a dependendcy for building documentation.
Bug#974473: sortedcollections: autopkgtest must be marked superficial
I decided to fix this bug by implementing running the package tests when installed instead of just marking the previous test superficial. (Probably the better solution) Diane
Bug#1001411: bullseye-pu: package dask.distributed/2021.01.0+ds.1-2.1 fixing CVE-2021-42343
On Sat, 2021-12-11 at 17:53 +, Adam D. Barratt wrote: > > Please go ahead. > Ok I uploaded dask.distributed_2021.01.0+ds.1-2.1+deb11u1_source.changes to ftp-master.
Bug#1001488: toolz: (autopkgtest) needs update for python3.10: Missing introspection for the following callables
On Sat, 2021-12-11 at 10:48 -0800, Steve Langasek wrote: > Package: toolz > Version: 0.11.1-1 > Followup-For: Bug #1001488 > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu jammy ubuntu-patch > Control: tags -1 patch > > Please find attached a trivial patch for this issue. > Upstream announced 0.11.2 is supposed to be compatible with Python 3.10 and they handled anext in a different way from your patch, the tests run on my system both at build time and in autopkgtests (amd64) with Python 3.10 https://github.com/pytoolz/toolz/commit/da81b1e8ab96b22ed81e6414099aba066633f3ff I'm pushed the new version which should fix this bug. Diane
