Bug#714275: qemu-system-ppc manpage and many others are copies of qemu-system-x86_64 page
Package: qemu-system-ppc Version: 1:8.2.1+ds-1~bpo12+1 Followup-For: Bug #714275 X-Debbugs-Cc: gstee...@gmail.com Dear Maintainer, Numerous manpages for parts of qemu (including anything to do with powerpc) are actually separate copies of the qemu-system-x86_64 manpage. -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-22-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_CA.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-system-ppc depends on: ii libaio1 0.3.113-4 ii libbpf1 1:1.1.0-1 ii libc6 2.36-9+deb12u7 ii libcapstone44.0.2-5 ii libfdt1 1.6.1-4+b1 ii libfuse3-3 3.14.0-4 ii libglib2.0-02.74.6-2+deb12u3 ii libgmp102:6.2.1+dfsg1-1.1 ii libgnutls30 3.7.9-2+deb12u3 ii libhogweed6 3.8.1-2 ii libibverbs1 44.0-2 ii libjpeg62-turbo 1:2.1.5-2 ii libnettle8 3.8.1-2 ii libnuma12.0.16-1 ii libpixman-1-0 0.42.2-1 ii libpmem11.12.1-2 ii libpng16-16 1.6.39-2 ii librdmacm1 44.0-2 ii libsasl2-2 2.1.28+dfsg-10 ii libseccomp2 2.5.4-1+deb12u1 ii libslirp0 4.7.0-1 ii libudev1252.26-1~deb12u2 ii liburing2 2.3-3 ii libvdeplug2 4.0.1-4 ii libzstd11.5.4+dfsg2-5 ii qemu-system-common 1:8.2.1+ds-1~bpo12+1 ii qemu-system-data1:8.2.1+ds-1~bpo12+1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages qemu-system-ppc recommends: ii ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1 ii qemu-block-extra1:8.2.1+ds-1~bpo12+1 ii qemu-system-gui 1:8.2.1+ds-1~bpo12+1 ii qemu-system-modules-opengl 1:8.2.1+ds-1~bpo12+1 ii qemu-system-modules-spice 1:8.2.1+ds-1~bpo12+1 ii qemu-utils 1:7.2+dfsg-7+deb12u6 ii seabios 1.16.3-2~bpo12+1 Versions of packages qemu-system-ppc suggests: ii samba 2:4.20.2+dfsg-2~bpo12+2 ii vde2 2.3.2+r586-8+b1 -- no debconf information
Bug#1075855: Kernel panic caused by aacraid module prevents normal boot
Package: linux-image-amd64 Version: 6.7.12-1 Hardware: Huananzhi F8D-Plus (C612 Intel Chipset), 2*Xeon 2680v4, 128 GB RAM Raid controller: Adaptec ASR-5805Z Hello! I've encountered an issue booting up Debian Testing with the latest kernel. The system reports something about kernel panic caused by aacraid module, then hangs completely during fsck step. Information about the installed system is in the attached .txt file. Note that hardware is different, because the SSD with Debian Testing has been extracted from the server for investigation. Using the kernel parameters "pci=nocrs single" I was able to boot into emergency mode and see the error messages related to kernel panic. Photos attached. Pulling the RAID controller out of the PCI-E slot restores normal boot. I tried different linux distributions to check hypothesis about regression in the latest kernel. Results are shown below. Distribution Kernel version Result Debian Testing KDE Linux *6.6.15*-amd64 #1 Debian 6.6.15-2 *Kernel panic* messages, boot hangs at fsck step. Kubuntu 24.04 LTS Linux KubuntuPortable *6.8.0*-36-generic #36-Ubuntu SMP PREEMPT_DYNAMIC Mon Jun 10 10:49:14 UTC 2024 x86_64 GNU/Linux *Kernel panic* messages, boot hangs at fsck step. Fedora Workstation Live x86_64-40-1.14 Linux localhost-live *6.8.5*-301.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 11 20:00:10 UTC 2024 x86_64 GNU/Linux *Boot hangs*. Linux Mint 21.1 Xfce 64-bit Linux mint *5.15.0*-56-generic #62-Ubuntu SMP Tue Nov 19:54:14 UTC 2022 x86_64 GNU/Linux *Normal boot*, ext4 partition on the RAID5 array is accessible. Debian Stable KDE Live Linux debian *6.1.0*-22-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.94-1 (2024-06-21) x86_64 GNU/Linux *Normal boot,* ext4 partition on the RAID5 array is accessible. Windows Server 2016 NA *Normal boot*. Adaptec Storage Manager reports optimal condition for the RAID5 array. *No errors reported for HDDs*. Ext4 partition on the array is accessible from Windows. Expected behavior: normal boot Actual result: system hangs during boot As a workaround, I installed kernel 6.1.0 from the Bookworm repository. IMG_20240628_180225.jpg <https://drive.google.com/file/d/1gw4LeXFP1BzqX1mTws8AVuhEE1Xjg-Sv/view?usp=drive_web> IMG_20240628_180411.jpg <https://drive.google.com/file/d/1oQPH23vhCDgeDuYzpHqVSvcv-okzAkY-/view?usp=drive_web> IMG_20240628_180419.jpg <https://drive.google.com/file/d/1g89ljiHNS5_I5cI-Z-1kitge_tJY9V-o/view?usp=drive_web> Gordon Mikhail, bioinformatician Genetics of Plant-Microbe Interactions lab | ARRIAM Guar Physiological genetics lab | VIR michaelgordon@Lab9-X99 ~> apt list --installed | grep "linux-image" (base) WARNING: apt does not have a stable CLI interface. Use with caution in scripts. linux-image-6.1.0-22-amd64/stable,now 6.1.94-1 amd64 [installed] linux-image-6.6.15-amd64/now 6.6.15-2 amd64 [installed,local] linux-image-6.7.12-amd64/now 6.7.12-1 amd64 [installed,local] linux-image-6.8.12-amd64/now 6.8.12-1 amd64 [installed,local] linux-image-amd64/now 6.8.12-1 amd64 [installed,upgradable to: 6.9.7-1] michaelgordon@Lab9-X99 ~> apt show libc6 | grep ^Version (base) WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Version: 2.38-13 michaelgordon@Lab9-X99 ~> neofetch (base) _,met$gg. michaelgordon@Lab9-X99 ,g$$$P. -- ,g$$P" """Y$$.".OS: Debian GNU/Linux trixie/sid x86_64 ,$$P' `$$$. Host: MS-7D31 1.0 ',$$P ,ggs. `$$b: Kernel: 6.7.12-amd64 `d$$' ,$P"' .$$$Uptime: 42 secs $$P d$' ,$$PPackages: 2378 (dpkg) $$: $$. -,d$$'Shell: fish 3.7.1 $$; Y$b._ _,d$P' Resolution: 3840x2160 Y$$.`.`"YP"' DE: Plasma 5.27.10 `$$b "-.__ WM: kwin `Y$$Theme: [Plasma], Breeze [GTK2/3] `Y$$. Icons: [Plasma], breeze [GTK2/3] `$$b.Terminal: konsole `Y$$b. Terminal Font: Hack 12 `"Y$b._ CPU: 12th Gen Intel i5-12600K (16) @ 4.900GHz `"""GPU: Intel AlderLake-S GT1 Memory: 1909MiB / 64099MiB michaelgordon@Lab9-X99 ~> uname -a (base) Linux Lab9-X99 6.7.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1 (2024-04-24) x86_64 GNU/Linux michaelgordon@Lab9-X99 ~ [1]> sudo modinfo aacraid
Bug#1074239: cura: Cura fails to start
Control: severity -1 grave I'm also having this problem as of recently. I tried building the package myself from source (the Debian version, not upstream) and still had the problem. It's probably related to a recent upgrade of one of Cura's dependencies. I wasn't able to get upstream to build, but if I do I will report back here. Since this bug makes the package unusable, I think the severity should be grave. I am not sure whether anyone is able to change that, but I have added the control header in case it works, because I think it's pretty clear that the severity should be grave. Thanks, Asher -- Violence is the last refuge of the incompetent. -- Salvor Hardin I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#1068868: ITP: python3-pyzmq -- Python bindings for 0MQ
On 12/04/2024 15:35, Cody Scott wrote: Package: wnpp Severity: wishlist Owner: Cody Scott X-Debbugs-Cc: debian-de...@lists.debian.org, cody.sc...@giatec.ca * Package name: python3-pyzmq Version : 25.1.2 Upstream Contact: ZeroMQ * URL : https://pyzmq.readthedocs.io/en/latest/ * License : BSD Programming Lang: Python Description : Python bindings for 0MQ This will be used by Python applications that use ZeroMQ. There doesn't appear to be any other Python bindings for ZeroMQ. I plan to maintain it and I'm looking for a sponsor. I believe this is already packaged - see https://tracker.debian.org/pkg/pyzmq Gordon
Bug#1060164: (no subject)
Yes. I can see that there are API methods which expose nlohmann::json (eg, https://github.com/jupyter-xeus/xeus/blob/ebd21e9e7cfe143b4d0a6783112cc9006b456915/include/xeus/xdebugger.hpp#L55-L60) so changes the header library are going to cause ABI breakage. I don't see much choice here but to binNMU xeus, xeus-zmq, xeus-python, which will presumably break custom kernels compiled against it and an older version of nl::json. I considered just updating everything to new versions and "rolling forward", but the latest version of xeus-zmq at least has an soversion bump so probably better to request binNMUs before waiting for NEW.
Bug#1063680: nmu: xeus_3.1.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: x...@packages.debian.org, gor...@chronitis.net Control: affects -1 + src:xeus xeus exposes the interface of nlohmann::json as part of its ABI (unfortunately), and changes in the header library from 3.11.2 to 3.11.3 have consequently caused an ABI break. This library is still fairly niche, and I think this can probably just be dealt with for now by NMUing the library and packaged dependencies. nmu xeus_3.1.3-1 . ANY . unstable . -m "Rebuild against nlohmann-json3-dev 3.11.3" nmu xeus-zmq_1.1.1-1 . ANY . unstable . -m "Rebuild against nlohmann-json3-dev 3.11.3" nmu xeus-python_0.15.10+~0.6.1-1 . ANY . unstable . -m "Rebuild against nlohmann-json3-dev 3.11.3"
Bug#1053387: reportbug: querybts crashes when more than one bug number is passed on the command line
Package: reportbug
Version: 12.0.0
Severity: normal
X-Debbugs-Cc: none, Asher Gordon
Dear Maintainer,
-- Package-specific info:
** Environment settings:
EDITOR="/home/asher/.config/fish/scripts/emacsclient.fish"
When passing multiple bug numbers on the command line, the querybts
script crashes. Example:
$ querybts 100 101
Querying Debian BTS for reports on 100 101...
2 bug reports found:
Traceback (most recent call last):
File "/usr/bin/querybts", line 241, in
main()
File "/usr/bin/querybts", line 217, in main
ui.handle_bts_query(package, options.system, options.timeout,
options.mirrors, options.http_proxy,
File "/usr/lib/python3/dist-packages/reportbug/ui/text_ui.py", line 603,
in handle_bts_query
package = [p[4:] for p in package if p.startswith("src:")][0]
File "/usr/lib/python3/dist-packages/reportbug/ui/text_ui.py", line 603,
in
package = [p[4:] for p in package if p.startswith("src:")][0]
AttributeError: 'int' object has no attribute 'startswith'
This is because of a chunk of code introduced in 9855d71:
# only pass a single package name to browse_bugs
if isinstance(package, list):
package = [p[4:] for p in package if p.startswith("src:")][0]
source = True
This code is problematic for several reasons.
1. The elements of 'package' are integers, not strings (I am not sure
under what circumstances they would be strings). This is what causes the
crash.
2. Even if we fix problem 1 (e.g. s/if p/if str(p)/), this code still
fails if none of the packages begin with the string 'src:', because the
list comprehension will result in an empty list, for which 0 is an
invalid index.
3. There is no need for a list comprehension at all (or even a loop),
since we only take the 0th element.
4. Even if this code did what I believe it intended to do (more or less
'package = package[0]'), this does not align with expected behavior. The
help text for the 'b' command says 'Open the complete bugs list in a web
browser.' Note that it does not say 'Open the first bug in a web
browser.'
I believe all of these problems can be fixed by
a) Reverting 9855d71.
b) Changing browse_bugs() and search_bugs() to call launch_browser()
multiple times (once for each package).
c) Changing launch_browser() to run xdg-open in the background so that
all the bugs are opened in separate tabs, and you don't have to close
the browser to see the next bug. webbrowser().open() automatically runs
the browser in the background as far as I can tell, so we don't have to
worry about that part.
I have done all of these things in the patch below:
From 2037bac77dae3e49162780277ff0501726bc6bf0 Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Tue, 3 Oct 2023 00:51:18 -0400
Subject: [PATCH] Fix browsing multiple bugs from the command line.
---
reportbug/ui/text_ui.py | 15 +--
reportbug/urlutils.py | 2 +-
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/reportbug/ui/text_ui.py b/reportbug/ui/text_ui.py
index bd8bd83..af316fb 100644
--- a/reportbug/ui/text_ui.py
+++ b/reportbug/ui/text_ui.py
@@ -598,11 +598,6 @@ def handle_bts_query(package, bts, timeout, mirrors=None, http_proxy="",
else:
ewrite('%d bug reports found:\n\n', count)
-# only pass a single package name to browse_bugs
-if isinstance(package, list):
-package = [p[4:] for p in package if p.startswith("src:")][0]
-source = True
-
return browse_bugs(hierarchy, count, bugs, bts, queryonly,
mirrors, http_proxy, timeout, screen, title,
package, source, mbox_reader_cmd)
@@ -690,10 +685,9 @@ def browse_bugs(hierarchy, count, bugs, bts, queryonly, mirrors,
lastpage = []
break
elif x == 'b':
-if source:
-launch_browser('https://bugs.debian.org/src:%s' % package)
-else:
-launch_browser('https://bugs.debian.org/%s' % package)
+for p in package:
+launch_browser('https://bugs.debian.org/%s%s' %
+ (('src:' if source else ''), p))
continue
elif x == 'r':
continue
@@ -910,7 +904,8 @@ def search_bugs(hierarchyfull, bts, queryonly, mirrors,
lastpage = []
Bug#1051972: jami-daemon: Fails to start with libopendht2 2.6.0.4-1
Package: jami-daemon Version: 20230206.0~ds2-1.3 Severity: grave X-Debbugs-Cc: none, Asher Gordon Dear Maintainer, After upgrading libopendht2, jami-daemon fails to start, making Jami unusable. Downgrading libopendht2 fixes the problem. $ apt-cache policy libopendht2 | grep Installed: Installed: 2.6.0.4-1 $ jami Using Qt runtime version: 6.4.2 "notify server name: dunst, vendor: knopwob, version: 1.9.2 (2023-04-20), spec: 1.2" "Using locale: en_US" "Error : jamid is not available, make sure it is running" terminate called after throwing an instance of 'char const*' Aborted $ /usr/libexec/jamid /usr/libexec/jamid: symbol lookup error: /usr/libexec/jamid: undefined symbol: _ZN3dht4http8ResolverC1ERN4asio10io_contextERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10shared_ptrINS_6LoggerEE Downgrading: $ sudo sed -i~ s/trixie/bookworm/g /etc/apt/sources.list $ sudo apt-get update Get:1 tor+https://deb.debian.org/debian bookworm InRelease [151 kB] [...] Fetched 88.2 MB in 42s (2,120 kB/s) Reading package lists... Done $ sudo apt-get install libopendht2=2.4.12-7 Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be DOWNGRADED: libopendht2 0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded. Need to get 806 kB of archives. After this operation, 377 kB disk space will be freed. Do you want to continue? [Y/n] y Get:1 tor+https://deb.debian.org/debian bookworm/main amd64 libopendht2 amd64 2.4.12-7 [806 kB] Fetched 806 kB in 2s (335 kB/s) debconf: unable to initialize frontend: Dialog debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.) debconf: falling back to frontend: Readline dpkg: warning: downgrading libopendht2:amd64 from 2.6.0.4-1 to 2.4.12-7 (Reading database ... 586843 files and directories currently installed.) Preparing to unpack .../libopendht2_2.4.12-7_amd64.deb ... Unpacking libopendht2:amd64 (2.4.12-7) over (2.6.0.4-1) ... Setting up libopendht2:amd64 (2.4.12-7) ... Processing triggers for libc-bin (2.37-8) ... $ apt-cache policy libopendht2 | grep Installed: Installed: 2.4.12-7 $ jami Using Qt runtime version: 6.4.2 "notify server name: dunst, vendor: knopwob, version: 1.9.2 (2023-04-20), spec: 1.2" "Using locale: en_US" No migration required [...] $ /usr/libexec/jamid Jami Daemon 13.7.0, by Savoir-faire Linux Inc. 2004-2023 https://jami.net/ [Video support enabled] [Plugins support enabled] 22:56:59.121 os_core_unix.c !pjlib 2.12.1 for POSIX initialized C-c C-cCaught signal Interrupt, terminating... Jami runs as expected. It looks like jamid references an undefined symbol, _ZN3dht4http8ResolverC1ERN4asio10io_contextERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10shared_ptrINS_6LoggerEE, which is likely present in the old version of libopendht2. I don't know a whole lot about C++ and name mangling, but I would guess that Jami had been using a deprecated or undocumented symbol, which has been removed or renamed in libopendht2. It's also possible that the new libopendht2 was compiled with a newer compiler, which mangled the name differently, but as far as I know, name mangling is supposed to be fairly stable (again, I don't know a whole lot about this). Also, the name unmangled: $ echo _ZN3dht4http8ResolverC1ERN4asio10io_contextERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10shared_ptrINS_6LoggerEE | c++filt dht::http::Resolver::Resolver(asio::io_context&, std::__cxx11::basic_string, std::allocator > const&, std::shared_ptr) Thanks, Asher -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-4-amd64 (SMP w/12 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages jami-daemon depends on: ii libarchive13 3.6.2-1 ii libasound2 1.2.9-2 ii libavcodec60 7:6.0-6 ii libavdevice607:6.0-6 ii libavfilter9 7:6.0-6 ii libavformat607:6.0-6 ii libavutil58 7:6.0-6 ii libc62.37-8 ii libdbus-c++-1-0v50.9.0-12 ii libfmt9 9.1.0+ds1-2 ii libgcc-s113.2.0-3 ii libgit2-1.5 1.5.1+ds-1
Bug#1043429: xserver-xorg-input-libinput: "xinput set-prop" command fails with error
Package: xserver-xorg-input-libinput Version: 1.3.0-1 Severity: important X-Debbugs-Cc: g.shumw...@gmx.net -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Lucienne [1002:164c] (rev c1) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 0 /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 6.4.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-1) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-3 (2023-08-08)
Bug#947222: marked as pending in bsdgames
Hi Tobias, Thanks for fixing this bug. I believe #723808 can now be closed as well. Thanks, Asher -- Brian Kernighan has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the numerous idiot lights which plague the modern driver. Rather, if the driver makes any mistake, a giant "?" lights up in the center of the dashboard. "The experienced driver", he says, "will usually know what's wrong." I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#1042462: ITP: xeus-zmq -- ZeroMQ middleware for Xeus
Package: wnpp Severity: wishlist Owner: Gordon Ball X-Debbugs-Cc: gor...@chronitis.net * Package name: xeus-zmq Version : 1.1.0 Upstream Contact: Jupyter-Xeus project * URL : https://github.com/jupyter-xeus/xeus-zmq * License : BSD-3-clause Programming Lang: C++ Description : ZeroMQ middleware for Xeus Xeus is a C++ implementation of the jupyter kernel protocol designed to make it more robust to interact with an interpreter from Jupyter notebook by moving the notebook <-> interpreter communication out of the interpreter itself. This package contains the ZMQ transport, which was previously part of the core xeus library but was split out in xeus 3. This is a new dependency to update xeus-python, and likely any other xeus kernels in future.
Bug#1041902: lua5.4: 'lua_settop' may use an invalid pointer to stack
Control: reassign -1 src:lua5.4
Asher Gordon writes:
> I think this fix from upstream should be backported to Debian's Lua
> 5.4, and possibly 5.{1,2,3} as well (I haven't tested those).
I found out Lua 5.4 is the first version with lua_toclose() (and the
__close() metamethod), so the particular manifestation of the bug I've
shown cannot be present in previous versions. Also, lua.org says this
bug has existed since 5.4.3: https://www.lua.org/bugs.html#5.4.4-5
I think that Debian should update lua5.4 to the latest upstream version
5.4.6, which should fix this (and other) bugs. I see that currently,
even in sid, lua5.4 is still 5.4.4.
Thanks,
Asher
P.S. I am reassigning this to the source package, since I think that
makes more sense.
--
On two occasions I have been asked [by members of Parliament!], "Pray, Mr.
Babbage, if you put into the machine wrong figures, will the right answers
come out?" I am not able rightly to apprehend the kind of confusion of
ideas that could provoke such a question.
-- Charles Babbage
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#1041902: lua5.4: 'lua_settop' may use an invalid pointer to stack
Package: lua5.4
Version: 5.4.4-3
Severity: normal
X-Debbugs-Cc: none, Asher Gordon
Dear Maintainer,
I found a bug in which calling lua_toclose() while the "main" stack is
active (i.e., not inside a function which was called by lua_call()), can
sometimes cause memory errors later. As I later found out, this was a
symptom of a bug in lua_settop(). Here is a minimal example showcasing
the bug:
#include
#include
#include
#include
/* Here's where we do our experimentation. The table returned by the
Lua program should be given as the sole argument on the Lua
stack. */
static int experiment(lua_State *L) {
/* local obj = class:new() */
lua_getfield(L, -1, "new");
lua_rotate(L, -2, 1);
lua_call(L, 1, 1);
lua_toclose(L, -1);
lua_pop(L, 1);
return 0;
}
int main(int argc, char **argv) {
lua_State *L;
const char *prog;
if (argc != 2) {
fprintf(stderr, "Usage: %s FILE\n", argv[0]);
return 1;
}
prog = argv[1];
L = luaL_newstate();
luaL_openlibs(L);
if (luaL_loadfile(L, prog))
lua_error(L);
lua_call(L, 0, 1);
if (!lua_istable(L, -1))
luaL_error(L, "%s did not return a table", prog);
#ifdef BAD_CODE
/* Here's where the error originates! If we call experiment()
manually like this, closing the value causes memory errors later
on. Instead, we have to call it through Lua. */
experiment(L);
#else
/* This works as expected. */
lua_pushcfunction(L, experiment);
lua_rotate(L, -2, 1);
lua_call(L, 1, 0);
#endif
lua_close(L);
return 0;
}
local inspect = require 'inspect'
local class = {}
local mt = {__index = class}
function mt:__close ()
print('Closing!')
-- This triggers the error for some reason. I imagine it's not
-- specific to the 'inspect' package, but rather just doing
-- something complex with 'self'.
print(inspect(self))
end
function class:new ()
assert(self == mt.__index)
return setmetatable({foo = 'bar'}, mt)
end
return class
Compile using
$ gcc -Wall -O0 -DBAD_CODE `pkg-config --cflags lua5.4` -o memory-error
memory-error.c `pkg-config --libs lua5.4`
and then run it with
$ valgrind ./memory-error test.lua
You should notice many errors. If you compile without -DBAD_CODE, it
works as expected (see the source for details).
I tried this with the latest upstream version from git, and found that
the bug did not occur. After some bisecting, I found the commit where
this was fixed upstream. The commit is "196bb94d Bug: 'lua_settop' may
use an invalid pointer to stack"
https://github.com/lua/lua/commit/196bb94d66e727e0aec053a0276c3ad701500762
I'm not sure if this is a security issue or not. If so, please raise the
Severity accordingly.
I think this fix from upstream should be backported to Debian's Lua 5.4,
and possibly 5.{1,2,3} as well (I haven't tested those). Hopefully it is
as simple as applying the patch.
Thanks,
Asher
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-1-amd64 (SMP w/12 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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lua5.4 depends on:
ii libc6 2.37-5
ii libreadline8 8.2-1.3
lua5.4 recommends no packages.
lua5.4 suggests no packages.
-- no debconf information
--
Yesterday upon the stair
I met a man who wasn't there.
He wasn't there again today --
I think he's from the CIA.
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#1039613: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed
Thanks Paul. We did make some changes in Nmap 7.94 which could have caused regressions. I've opened an issue for this on our upstream tracker ( https://github.com/nmap/nmap/issues/2685). Please let us know if you figure anything else out. -Gordon
Bug#1040001: To strict version restrictions injected by dh-r (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi Andreas On 06/07/2023 22:09, Andreas Tille wrote: It comes from this line: https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272 More precisely the “r-base-core (>= $rbase_version)” part, which imposes an unnecessarily tight restriction on the r-base-core version. Got it, thanks for the explanation. This restriction existed since the early stage of dh-r development https://salsa.debian.org/r-pkg-team/dh-r/-/commit/22fd80b9#L174 by Gordon Ball (in CC but not really active in R pkg team any more) at 2016-09-04 12:28:57 +0200 . I'm guessing this restriction was obtained from the cdbs helper that existed before the dh support was created by Gordon and he simply took over what existed there. The according line in the initial commit of dh-r is I'm pretty sure I cargo-culted it from the previous CDBS helper when writing dh-r. I assumed it was meant to allow for non-backwards compatible bytecode, but I'm not sure I investigated the exact semantics it was meant to be enforcing. I concur that it sounds like the `$rapiversion` dependency is probably sufficient. (Yes, I'm afraid I don't really have an ongoing interest in R - I used it a lot in academia, but it hasn't really featured in professional life since then). Gordon
Bug#1038918: librem-ec-acpi-dkms: Does not build against Linux 6.3.0
Package: librem-ec-acpi-dkms Version: 0.9.1-4 Severity: grave X-Debbugs-Cc: none, Asher Gordon Dear Maintainer, During a system upgrade, I noticed that there was an error upgrading the Linux kernel. I was able to isolate the problem to the librem-ec-acpi-dkms package. (Without this package, the brightness keys on the Librem 14 do not work anymore after a suspend, and possibly other issues too.) If I remove the package and install it again, I get the following output: Loading new librem_ec_acpi-0.9.1 DKMS files... Building for 6.1.0-9-amd64 6.3.0-1-amd64 Building initial module for 6.1.0-9-amd64 Done. librem_ec_acpi.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/6.1.0-9-amd64/updates/dkms/ depmod... Building initial module for 6.3.0-1-amd64 Error! Bad return status for module build on kernel: 6.3.0-1-amd64 (x86_64) Consult /var/lib/dkms/librem_ec_acpi/0.9.1/build/make.log for more information. dpkg: error processing package librem-ec-acpi-dkms (--configure): installed librem-ec-acpi-dkms package post-installation script subprocess returned error exit status 10 So it appears to build successfully against 6.1.0, but not 6.3.0. Here is the contents of my /var/lib/dkms/librem_ec_acpi/0.9.1/build/make.log: DKMS make.log for librem_ec_acpi-0.9.1 for kernel 6.3.0-1-amd64 (x86_64) Fri Jun 23 01:16:58 AM EDT 2023 make: Entering directory '/usr/src/linux-headers-6.3.0-1-amd64' CC [M] /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.o /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:276:24: error: initialization of ‘int (*)(struct power_supply *, struct acpi_battery_hook *)’ from incompatible pointer type ‘int (*)(struct power_supply *)’ [-Werror=incompatible-pointer-types] 276 | .add_battery = librem_ec_battery_add, |^ /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:276:24: note: (near initialization for ‘librem_ec_battery_hook.add_battery’) /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:277:27: error: initialization of ‘int (*)(struct power_supply *, struct acpi_battery_hook *)’ from incompatible pointer type ‘int (*)(struct power_supply *)’ [-Werror=incompatible-pointer-types] 277 | .remove_battery = librem_ec_battery_remove, | ^~~~ /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:277:27: note: (near initialization for ‘librem_ec_battery_hook.remove_battery’) /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:773:27: error: initialization of ‘void (*)(struct acpi_device *)’ from incompatible pointer type ‘int (*)(struct acpi_device *)’ [-Werror=incompatible-pointer-types] 773 | .remove = librem_ec_remove, | ^~~~ /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:773:27: note: (near initialization for ‘librem_ec_driver.ops.remove’) cc1: some warnings being treated as errors make[1]: *** [/usr/src/linux-headers-6.3.0-1-common/scripts/Makefile.build:257: /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.o] Error 1 make: *** [/usr/src/linux-headers-6.3.0-1-common/Makefile:2050: /var/lib/dkms/librem_ec_acpi/0.9.1/build] Error 2 make: Leaving directory '/usr/src/linux-headers-6.3.0-1-amd64' I don't know much about kernel module development, but it looks like these errors are due to an API change in the new kernel version. This makes the package nonfunctional for Linux 6.3.0 (although it still works for 6.1.0, which I'm on now), thus the grave severity. Thanks, Asher -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/12 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librem-ec-acpi-dkms depends on: ii dkms 3.0.11-3 librem-ec-acpi-dkms recommends no packages. librem-ec-acpi-dkms suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1029354: ncat: ICMPv4 Type 3 Code 13 not implemented
Sorry for the delay, but this sounds like expected behavior. Ncat is generally using the socket API rather than raw packets and so the host receives the ICMP response and translates that into a more generic error code that Ncat sees. You can use our Nping tool if you need raw packet sending and sniffing instead. -Gordon On Sat, Jan 21, 2023 at 8:30 AM Marco Moock wrote: > Package: ncat > Version: 7.93+dfsg1-1 > Severity: minor > Tags: upstream > X-Debbugs-Cc: m...@posteo.de > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate > *** > >* What led up to the situation? > ncat and reply is ICMPv4 Type 3 Code 13, wrong error > message > "Ncat: No route to host.". >* What outcome did you expect instead? > Correct message, like "Connection to administratively > prohibited". > https://datatracker.ietf.org/doc/html/rfc1812#section-5.2.7.1 > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages ncat depends on: > ii libc62.36-8 > ii liblua5.3-0 5.3.6-2 > ii libpcap0.8 1.10.3-1 > ii libssl3 3.0.7-1 > > ncat recommends no packages. > > ncat suggests no packages. > > -- no debconf information > >
Bug#1028372: ncat: Please lower alternative priority below nc.traditional
As the author of Ncat, I disagree that it has "very different output" from traditional and OpenBSD netcats. Unless you specify -v (verbose mode), Ncat usually doesn't have any output at all. It silently connects to a remote system (or listens for connections from remote systems) and relays exactly what those systems transmit. Also, nc.traditional does not even support IPv6. A failure because the remote host only supports IPv6 seems a lot more problematic than any alleged difference in output. The traditional nc doesn't support SSL encryption either. That's a problem for communicating with modern web sites and mail servers as well as for communicating securely between ncat instances. Also Ncat fully supports Windows and Mac, so users can interoperate between more systems. And it's more performance in many cases since it supports modern Linux I/O API's rather than just select and poll. Also traditional netcat is not maintained by any particular organization. For these reasons, we support having Ncat be one of the official Debian Netcat alternatives.It's already the default on many other distributions, including Red Hat Enterprise Linux, Fedora, etc. We also love traditional and OpenBSD netcats and are glad those are offered by Debian and Kali as well. Cheers, Gordon "Fyodor" Lyon
Bug#1029974: libsox-fmt-base: [PATCH] vorbis: fix memory leaks
Also, I should note that I also reported this bug upstream. Since I don't have a SourceForge account, I wrote to where my message is awaiting moderator approval. But until the bug is fixed upstream, perhaps a patch should be implemented in the Debian package. Thanks, Asher -- Brian Kernighan has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the numerous idiot lights which plague the modern driver. Rather, if the driver makes any mistake, a giant "?" lights up in the center of the dashboard. "The experienced driver", he says, "will usually know what's wrong." I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#1029974: libsox-fmt-base: [PATCH] vorbis: fix memory leaks
Package: libsox-fmt-base
Version: 14.4.2+git20190427-3+b1
Severity: normal
X-Debbugs-Cc: Asher Gordon
Dear Maintainer,
While attempting to write Perl bindings for libsox, I stumbled upon a
memory leak in vorbis.c (two, actually). The memory leak can be seen by
something like the following:
$ valgrind --leak-check=full --show-leak-kinds=all sox test.ogg test.mp3
$ valgrind --leak-check=full --show-leak-kinds=all sox test.mp3 test.ogg
The first line shows the read memory leak and the second shows the write
memory leak.
The fix is trivial, and I have attached a patch below (created on the
upstream code base, but applies cleanly on the Debian version):
From a23816e06a6433d1d553668bb8bd784d5f11d37e Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Sun, 29 Jan 2023 13:08:12 -0500
Subject: [PATCH] vorbis: fix memory leaks
Data was allocated in startread() and startwrite() that was not freed
in stopread() and stopwrite(). Fix it.
---
src/vorbis.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/vorbis.c b/src/vorbis.c
index 9fa234ce..ab15301a 100644
--- a/src/vorbis.c
+++ b/src/vorbis.c
@@ -229,6 +229,7 @@ static int stopread(sox_format_t * ft)
free(vb->buf);
ov_clear(vb->vf);
+ free(vb->vf);
return (SOX_SUCCESS);
}
@@ -404,6 +405,7 @@ static int stopwrite(sox_format_t * ft)
vorbis_block_clear(&ve->vb);
vorbis_dsp_clear(&ve->vd);
vorbis_info_clear(&ve->vi);
+ free(ve);
return (SOX_SUCCESS);
}
--
2.39.0
Thanks,
Asher
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libsox-fmt-base depends on:
ii libc6 2.36-8
ii libflac12 1.4.2+ds-2
ii libgsm1 1.0.22-1
ii libogg0 1.3.5-3
ii libopencore-amrnb0 0.1.6-1
ii libopencore-amrwb0 0.1.6-1
ii libsndfile1 1.2.0-1
ii libsox3 14.4.2+git20190427-3+b1
ii libvorbis0a 1.3.7-1
ii libvorbisenc2 1.3.7-1
ii libvorbisfile3 1.3.7-1
ii libwavpack1 5.6.0-1
libsox-fmt-base recommends no packages.
libsox-fmt-base suggests no packages.
-- no debconf information
--
* Dry-ice can't code his way out of a paper bag
dry-ice: int main() { ExitPaperBag(); return 0; }
Is that how that's done then? *takes notes*
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#1023374: kwin-x11: kwin_x11 --replace ... yields "symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5: undefined symbol: drmModeFormatModifierBlobIterNext"
Package: kwin-x11 Version: 4:5.26.0-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? recent update * What exactly did you do (or not do) that was effective (or ineffective)? plasma did not have any borders or title bars on its windows, found kwin_x11 was not running ... so attempted to use kwin_x11 --replace * What was the outcome of this action? symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5: undefined symbol: drmModeFormatModifierBlobIterNext * What outcome did you expect instead? kill any existing kwin_x11 instances and start a new kwin_x11 instance. *** End of the template - remove these template lines *** -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kwin-x11 depends on: ii kwin-common4:5.26.0-1 ii libc6 2.35-4 ii libepoxy0 1.5.10-1 ii libgcc-s1 12.2.0-3 ii libkdecorations2-5v5 4:5.26.0-1 ii libkf5configcore5 5.98.0-1 ii libkf5configgui5 5.98.0-1 ii libkf5configwidgets5 5.98.0-1 ii libkf5coreaddons5 5.98.0-1 ii libkf5crash5 5.98.0-1 ii libkf5globalaccel-bin 5.98.0-1 ii libkf5globalaccel5 5.98.0-1 ii libkf5i18n55.98.0-1+b1 ii libkf5notifications5 5.98.0-1 ii libkf5plasma5 5.98.0-1 ii libkf5service-bin 5.98.0-1 ii libkf5service5 5.98.0-1 ii libkf5windowsystem55.98.0-1 ii libkwineffects14 4:5.26.0-1 ii libkwinglutils14 4:5.26.0-1 ii libqaccessibilityclient-qt5-0 0.4.1-1+b1 ii libqt5core5a 5.15.6+dfsg-2 ii libqt5dbus55.15.6+dfsg-2 ii libqt5gui5 5.15.6+dfsg-2 ii libqt5qml5 5.15.6+dfsg-2 ii libqt5quick5 5.15.6+dfsg-2 ii libqt5widgets5 5.15.6+dfsg-2 ii libqt5x11extras5 5.15.6-2 ii libstdc++6 12.2.0-3 ii libx11-6 2:1.8.1-2 ii libxcb-composite0 1.15-1 ii libxcb-keysyms10.4.0-1+b2 ii libxcb-randr0 1.15-1 ii libxcb-render0 1.15-1 ii libxcb-shape0 1.15-1 ii libxcb-xfixes0 1.15-1 ii libxcb11.15-1 ii libxi6 2:1.8-1+b1 kwin-x11 recommends no packages. kwin-x11 suggests no packages. -- no debconf information
Bug#1022089: zlmdb: Uses deprecated yaml.load
Source: zlmdb Version: 22.6.1-1 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in zlmdb/_database.py: https://sources.debian.org/src/zlmdb/22.6.1-1/zlmdb/_database.py/?hl=239#L239 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022088: xrstools: Uses deprecated yaml.load
Source: xrstools Version: 0.15.0+git20210910+c147919d-3 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. xrstools uses yaml.load in several places: - XRStools/ramanWidget/MainWindow.py - XRStools/WIZARD/Wizard.py - XRStools/WIZARD/methods/SuperResolution - XRStools/WIZARD/methods/RIXS_spectra - XRStools/WIZARD/methods/predictions -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022086: spades: Uses deprecated yaml.load
Source: spades Version: 3.15.5+dfsg-1 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Parts of the spades codebase use the newer form, but there are multiple places where the old version is used: https://codesearch.debian.net/search?q=yaml.load+package%3Aspades&literal=1 This causes the spades autopkgtest to fail with python3-yaml 6, as can be seen in experimental pseudo-excuses: https://ci.debian.net/data/autopkgtest/unstable/amd64/s/spades/27249904/log.gz -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022084: ros-rosinstall: Uses deprecated yaml.load
Source: ros-rosinstall Version: 0.7.8-5 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in multiple locations in rosinstall: src/rosinstall/rosws_stacks_cli.py; test/local/test_rosinstall.py; scripts/rosco; src/rosinstall/locate.py -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022083: relatorio: Uses deprecated yaml.load
Source: relatorio Version: 0.10.1-1 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in relatorio/templates/chart.py: https://sources.debian.org/src/relatorio/0.10.1-1/relatorio/templates/chart.py/?hl=60#L60 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022082: refstack-client: Uses deprecated yaml.load
Source: refstack-client Version: 0.0.0~2021.08.18.fa73ef2524-2 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in refstack_client.py read_accounts_yaml(): https://sources.debian.org/src/refstack-client/0.0.0~2021.08.18.fa73ef2524-2/refstack_client/refstack_client.py/?hl=69#L69 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022080: qcengine: Uses deprecated yaml.load
Source: qcengine Version: 0.23.0-1 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in qcengine/config.py _load_defaults(): https://sources.debian.org/src/qcengine/0.23.0-1/qcengine/config.py/?hl=193#L193 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022079: qcat: Uses deprecated yaml.load
Source: qcat Version: 1.1.0-3 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in qcat/adapters.py: https://sources.debian.org/src/qcat/1.1.0-3/qcat/adapters.py/?hl=37#L37 - the file contains several functions which do use yaml.load with a Loader= argument, but one case that looks like it has no fallback and would fail (in `yaml2adapter()`) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022078: python-tempestconf: Uses deprecated yaml.load
Source: python-tempestconf Version: 2.5.0-3 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in config_tempest/profile.py: https://sources.debian.org/src/python-tempestconf/2.5.0-3/config_tempest/profile.py/?hl=45#L45 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022076: python-pybedtools: Uses deprecated yaml.load (in contrib)
Source: python-pybedtools Version: 0.9.0-1 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. The only outstanding case appears to be in contrib: https://sources.debian.org/src/python-pybedtools/0.9.0-1/pybedtools/contrib/plotting.py/?hl=527#L527 (but this file is installed in python3-pybedtools), the test suite uses of yaml appear to be fixed. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022075: python-multipart: Uses deprecated yaml.load
Source: python-multipart Version: 0.0.5-2 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. This is only used in the testsuite: https://sources.debian.org/src/python-multipart/0.0.5-2/multipart/tests/test_multipart.py/?hl=712#L712 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022036: python-canmatrix: Uses deprecated yaml.load
Source: python-canmatrix Version: 0.9.5~github-2 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. load() in https://sources.debian.org/src/python-canmatrix/0.9.5~github-2/src/canmatrix/formats/yaml.py/?hl=77#L77 appears to use unqualified yaml.load - and it looks like in this case the desired behaviour is probably not to use safe_load since _init_yaml() declares several tag types, but I think loading (if it is ever used) still needs an explicit Loader= argument. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022035: python-aptly: Uses deprecated yaml.load
Source: python-aptly
Version: 0.12.10-3
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net
We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262
Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).
In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.
Found in publisher/__{init,main}__.py for loading config.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1022034: policyd-rate-limit: Uses deprecated yaml.load
Source: policyd-rate-limit Version: 1.0.1.1-2.1 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in https://sources.debian.org/src/policyd-rate-limit/1.0.1.1-2.1/policyd_rate_limit/utils.py/?hl=88#L88 for loading yaml-format config files (and in tests) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022033: owslib: Uses deprecated yaml.load
Source: owslib Version: 0.27.2-1 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in https://sources.debian.org/src/owslib/0.27.2-1/owslib/ogcapi/__init__.py/?hl=102#L102 (but only when loading openapi in yaml format - not sure if this codepath is much used). -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022032: open-adventure: Uses deprecated yaml.load in tests
Source: open-adventure Version: 1.9-1 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in tests/coverage_dungeon.py -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022021: lirc: Uses deprecated yaml.load in python-pkg
Source: lirc Version: 0.10.1-7 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. It appears to be used in python-pkg/lirc/database.py and tools/check_config.py. The former gets installed in the `lirc` binary package. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022020: lecm: Uses deprecated yaml.load
Source: lecm Version: 0.0.9-1 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. yaml.load is used to load config in https://sources.debian.org/src/lecm/0.0.9-1/lecm/configuration.py/?hl=71#L71 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022019: labgrid: Uses deprecated yaml.load
Source: labgrid Version: 0.4.1-4 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Most call sites in labgrid appear to be fixed, but there appears to be one remaining use of yaml.load in remote/coordinator, assuming that is still live code: https://sources.debian.org/src/labgrid/0.4.1-4/labgrid/remote/coordinator.py/?hl=309#L309 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022018: ganeti: Uses deprecated yaml.load
Source: ganeti Version: 3.0.2-1 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. This is used in the tests: test/py/ganeti.cli_unittest.py; this causes autopkgtest failure against the version of pyyaml in experimental. I don't think it breaks anything outside the test suite however. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022016: etm: Uses deprecated yaml.load
Package: etm Version: 3.2.30-4 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found in `etmTk/data.py` in several places. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages etm depends on: ii python33.10.6-1 ii python3-dateutil 2.8.2-1 pn python3-icalendar ii python3-tk 3.10.7-1 ii python3-tz 2022.4-1 ii python3-yaml 5.4.1-1+b2 Versions of packages etm recommends: pn mercurial etm suggests no packages.
Bug#1022015: elasticsearch-curator: Uses deprecated yaml.load
Source: elasticsearch-curator Version: 5.8.1-4 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. Found at least in curator/utils.py (https://sources.debian.org/src/elasticsearch-curator/5.8.1-4/curator/utils.py/?hl=53#L53) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022014: ceph: Uses deprecated yaml.load
Source: ceph Version: 16.2.10+ds-3 Severity: normal X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. The only place I found this in the ceph source is in a test: https://sources.debian.org/src/ceph/16.2.10+ds-3/src/test/crimson/cbt/t2c.py/?hl=46#L46 This doesn't look like it's installed in any of the binaries, but perhaps it can be hit during build? -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022013: ansible: Uses deprecated yaml.load (in community plugin only)
Source: ansible Version: 6.4.0+dfsg-1 Severity: minor X-Debbugs-Cc: gor...@chronitis.net We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the freeze, per #1008262 Your package appears to use `yaml.load()` without specifying a `Loader=` argument, which will become an error in pyyaml version 6. This should have emitted a warning message since version 5.1 (from 2019). In most cases this can be fixed by replacing `yaml.load` with `yaml.safe_load`, unless the ability for yaml to create arbitrary python objects is desirable. I could only find this usage in the community VDO plugin, not the core, hence `minor`: https://sources.debian.org/src/ansible/6.4.0+dfsg-1/ansible_collections/community/general/plugins/modules/system/vdo.py/?hl=551#L551 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1018279: python3-testpath: Empty binary package
Package: python3-testpath Version: 0.6.0+dfsg-2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: gor...@chronitis.net The package is empty except for the changelog. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1008808: texlive-games: [chess.sty] Incorrect usage of babel breaks package
Hi Hilmar, Hilmar Preuße writes: > So you're actively pushed to other packages. Please consider to follow > this recommendation. Thanks for the advice. So it seems a better solution would be to use an alternative package in Scid's generated LaTeX files. I don't think that should be too difficult. I'll do that when I have the time and send a report to upstream and/or Debian. Thanks, Asher -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me sprea= d! I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#1008808: texlive-games: [chess.sty] Incorrect usage of babel breaks package
Package: texlive-games
Version: 2021.20220204-1
Severity: normal
X-Debbugs-Cc: Asher Gordon
File: /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
Dear Maintainer,
The file /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty (used
by the LaTeX files generated by Scid) uses "\input english.sty" instead
of "\usepackage[english]{babel}". This causes a lot of errors when
compiling a LaTeX file that uses the chess package. If the errors are
ignored (e.g. by using "-interaction nonstopmode"), then the compiled
document has a lot of garbage at the start.
The following is a minimal example that produces the error:
\documentclass{article}
\usepackage{chess}
\begin{document}
This is a test.
\begin{chess}
1.~e4 c5 2.~Nf3 Nc6
\end{chess}
\end{document}
The test.fls file produced by
"pdflatex -interaction nonstopmode -recorder test.tex" is attached
below:
PWD /tmp/tmp.mH6e5epKvE
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/pdftex/pdflatex.fmt
INPUT test.tex
OUTPUT test.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/english.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.def
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def
INPUT /usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/chess/chess20.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/chess/chessf10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr6.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmsy6.tfm
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT ./test.aux
INPUT test.aux
INPUT test.aux
OUTPUT test.aux
OUTPUT test.pdf
INPUT /var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map
INPUT test.aux
INPUT
/home/asher/.texlive2021/texmf-var/fonts/pk/ljfour/public/chess/chessf10.600pk
INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb
The following change resolves most of the errors:
--- /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty~ 2022-04-01 15:57:17.0 -0400
+++ /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty 2022-04-01 16:26:46.228383005 -0400
@@ -61,7 +61,7 @@
%
% Do we have language support? Otherwise take default language!
%
-\ifx\undefined\babel@core@loaded\input english.sty\fi
+\ifx\undefined\babel@core@loaded\usepackage[english]{babel}\fi
Bug#1004855: python3-ipykernel: missing dependency on debugpy
On Wed, Feb 02, 2022 at 11:35:19AM +, Julian Gilbey wrote: > Package: python3-ipykernel > Version: 6.7.0-1 > Severity: serious > X-Debbugs-Cc: Julien Puydt , Gordon Ball > > ps, I had a search just now and it looks like someone else was working 1 year ago on `ptvsd` (renamed `debugpy` later), but it doesn't look like it was ever uploaded. But perhaps something to build upon. https://salsa.debian.org/python-team/packages/ptvsd https://salsa.debian.org/python-team/packages/pydevd pps, I disagree that this qualifies for `severity=serious`. I don't think there is either a policy violation or the package is unusable for most users. I propose to change this to `severity=important`.
Bug#1004855: python3-ipykernel: missing dependency on debugpy
On Wed, Feb 02, 2022 at 11:35:19AM +, Julian Gilbey wrote: > Package: python3-ipykernel > Version: 6.7.0-1 > Severity: serious > X-Debbugs-Cc: Julien Puydt , Gordon Ball > > > ipykernel depends on the debugpy package, as stated in setup.py. > However, within Debian build, python3-debugpy is not listed in the > Build-Depends, so the resulting binary package does not Depend(s) on > it either. The ipykernel test suite passes because the debugger test > is skipped if debugpy is not installed, but Spyder behaves badly in > its absence. Yes, sorry. This is a known, but admittedly not documented, limitation of the current package. As far as I could tell debugpy was effectively treated as an optional feature (all imports seem to be protected with try-catch, etc), despite being listed as install_requires. > Furthermore, there is no python3-debugpy package yet in Debian. I am > happy to do an ITP and upload this package to NEW if that would help. I looked briefly into packaging debugpy and I think it's probably doable but looks like a reasonable amount of work (embedded vendored stuff, cython). I don't have time to take that on at the moment, but I'd be very happy if you're willing to. Gordon
Bug#1004670: pkg-js-tools: restrictive regex for d/nodejs/component_links
Package: pkg-js-tools Version: 0.11.7 Severity: normal X-Debbugs-Cc: gor...@chronitis.net Lines in the file `debian/nodejs/component_links` are checked for the regex `/^([\w\-\.\/]+)\s+([\w\-\.\/]+)$/` and otherwise reported as malformed. This means that components named in the typescript style (@foo/bar) can't be used with this file. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/1 CPU thread) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pkg-js-tools depends on: ii debhelper 13.6 ii libdebian-copyright-perl 0.2-4 ii libdebian-source-perl 0.116 ii libipc-run-perl 20200505.0-1 ii libjson-perl 4.04000-1 ii libyaml-perl 1.30-1 ii nodejs12.22.9~dfsg-1 ii perl 5.32.1-6 Versions of packages pkg-js-tools recommends: ii devscripts2.22.1 ii libdpkg-perl 1.21.1 Versions of packages pkg-js-tools suggests: ii autodep8 0.25 ii autopkgtest5.19 ii git-buildpackage 0.9.25 pn libconfig-inifiles-perl ii libconfig-model-dpkg-perl 2.156 ii libconfig-model-perl 2.149-1 ii lintian2.114.0 ii node-semver7.3.5+~7.3.8-1 ii npm8.4.0~ds-1 -- no debconf information
Bug#1004668: python3-metakernel: Should not depend on jupyter-notebook
Package: python3-metakernel Version: 0.27.5-3 Severity: minor X-Debbugs-Cc: gor...@chronitis.net python3-metakernel adds a manual dependency on jupyter-notebook, which should probably not be a hard dependency. The library doesn't import from notebook anywhere I can see, so it's only being added as a possible frontend for whatever kernel metakernel is implementing. However, other frontends exist (jupyter-console, nbclient, kernel gateways, etc), so a hard dependency on the most heaviweight frontend seems unnecessary. I would either demote this to Suggests: or drop it completely. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/1 CPU thread) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-metakernel depends on: ii jupyter-notebook 6.4.8-1 ii python33.9.8-1 ii python3-ipykernel 6.7.0-1 ii python3-pexpect4.8.0-2 Versions of packages python3-metakernel recommends: ii python3-pydot 1.4.2-1 python3-metakernel suggests no packages. -- no debconf information
Bug#1003716: ITP: python-pure-eval -- Safely evaluate Python AST nodes
Package: wnpp Severity: wishlist Owner: Gordon Ball X-Debbugs-Cc: debian-pyt...@lists.debian.org, gor...@chronitis.net * Package name: python-pure-eval Version : 0.2.1 Upstream Author : Alex Hall * URL : https://github.com/alexmojaki/pure_eval * License : MIT Programming Lang: Python Description : Safely evaluate Python AST nodes This is a Python package that lets you safely evaluate certain AST nodes without triggering arbitrary code that may have unwanted side effects. This is a dependency on python-stack-data, itself a dependency of IPython 8.0 This will be maintained in the debian-python team.
Bug#1003680: libjs-jquery-ui: ABI of jquery-ui.[min.].js changed in 1.13
Package: libjs-jquery-ui Version: 1.13.0+dfsg-1 Severity: important X-Debbugs-Cc: gor...@chronitis.net When updating from 1.12.1 to 1.13.0, the ABI of the dist files /usr/share/javascript/jquery-ui/jquery-ui[.min].js appears to have changed. In 1.12, it contained a single factory function which loaded the entire library as a `define()` or global: `define([ "jquery" ], factory );` In 1.13, it contains one factory function per source file in the distribution, eg `define( 'ui/version.js',[ "jquery" ], factory );` This does not match what you get using the jqueryui downloader, nor does it match the reference file in the salsa jqueryui repository (debian/reference-jquery-ui.js), which has an ABI like that seen in 1.12. This change in ABI breaks jupyter-notebook. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/1 CPU thread) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libjs-jquery-ui depends on: ii libjs-jquery 3.5.1+dfsg+~3.5.5-8 Versions of packages libjs-jquery-ui recommends: ii javascript-common 11+nmu1 Versions of packages libjs-jquery-ui suggests: pn libjs-jquery-ui-docs -- no debconf information
Bug#1003613: (no subject)
I think this is caused by jquery-ui failing to load, which should have created the `resizeable` property on that element. jquery-ui was updated from 1.12.1 to 1.13.0 in november (but that change wouldn't have been picked up until the jupyter notebook javascript was rebuilt recently to try and fix issues with libjs-marked). However, I haven't worked out _what_ broke yet. Ideas on a postcard.
Bug#1003645: ITP: python-stack-data -- More useful tracebacks for python
Package: wnpp Severity: wishlist Owner: Gordon Ball X-Debbugs-Cc: gor...@chronitis.net, debian-pyt...@lists.debian.org * Package name: python-stack-data Version : 0.1.3 Upstream Author : Alex Hall * URL : https://github.com/alexmojaki/stack_data * License : MIT Programming Lang: Python Description : More useful tracebacks for python This library extracts more detail from stack frames and tracebacks, showing richer debugging information, particularly for interactive use. This is a new dependency for IPython 8.0 It will be maintained in the debian-python team.
Bug#1003600: libjs-marked: missing javascript module type in libjs-marked
Package: libjs-marked Version: 4.0.5+ds-5 Severity: important X-Debbugs-Cc: gor...@chronitis.net In libjs-marked 0.8.0, /usr/share/javascript/marked/marked.js was a UMD-type module suitable for browser use. In libjs-marked 4.0, initially only marked.cjs (a CommonJS module not suitable for browser use) was shipped. This was subsequently symlinked as marked.js (and equivalently for a minifed version), but has essentially a different ABI and cannot be used in the same context. Installing marked via npm provides `marked.cjs`, `marked.esm.js` and `marked.umd.js`. Please include at least the `umd` version. Lack of this breaks jupyter-notebook. Gordon -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/1 CPU thread) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled libjs-marked depends on no packages. Versions of packages libjs-marked recommends: ii javascript-common 11+nmu1 libjs-marked suggests no packages. -- no debconf information
Bug#1002372: marked as done (nbconvert: FTBFS: AttributeError: module 'mistune' has no attribute 'BlockGrammar')
On Sun, Jan 09, 2022 at 11:47:47AM -0500, Sandro Tosi wrote: > Gordon, > > >[ Gordon Ball ] > >* Vendor mistune 0.8.4 due to incompatibility with mistune 2 > > (Closes: #1001283, #1002372) > > i think you closed *all* the mistune bugs by doing this. can you > reopen the ones not affecting nbconvert so that we dont lose track of > them? Hi Sandro I _think_ the closed bugs (#1001283 was merged with 6 others) only cover the cases where the FTBFS tracebacks showed nbconvert (rather than direct import of mistune). I haven't admittedly tried rebuilding them all, but given the failure mode, I think the bug was correctly merged and they're likely to be fixed. * #1002371 python-fluids * #1002373 python-fabio * #1002374 silx * #1002375 mdtraj * #1002383 pyswarms * #1002790 statsmodels The main tracking bug for mistune (#1001591) should still be open, along with related bugs for packages which imported mistune directly (#1002163 python-m2r, #1002254 lookatme, #1002380 python-matrix-nio). Am I missing anything else which was wrongly closed? > > Thanks, > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi
Bug#1001668: downgrading severity
Reducing severity to `normal`, since this does not appear to happen consistently. Looking through the CI logs, there are occasional failures on ppc64el, but since it does not appear to happen consistently, I don't _think_ this justifies RC severity, unless anyone can reproduce it in actual usage.
Bug#1003247: mailman3-web: Mailman3 not working following distribution upgrade from Debian 10 to 11.
Package: mailman3-web Version: 0+20200530-2 Severity: important Dear Maintainer, I performed a distribution upgrade from Debian 10 Buster (which runs mailman 3.2.1) to Debian 11 Bullseye (which runs mailman 3.3.1) with the command "apt-get full-upgrade -y" and everything apparently worked properly except at the end of the upgrade when the following error dialog was generated by the mailman3-web and mailman3-full post-installation scripts: Setting up mailman3-web (0+20200530-2) ... Determining localhost credentials from /etc/mysql/debian.cnf: succeeded. dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf dbconfig-common: flushing administrative password sed: -e expression #2, char 77: unterminated `s' command dpkg: error processing package mailman3-web (--configure): installed mailman3-web package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of mailman3-full: mailman3-full depends on mailman3-web; however: Package mailman3-web is not configured yet. dpkg: error processing package mailman3-full (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: mailman3-web mailman3-full E: Sub-process /usr/bin/dpkg returned an error code (1) Now, every time that I execute "apt-get upgrade" then I continue to get the above error dialog. Also, the command "dpkg-reconfigure mailman3-web" generates this output: /usr/sbin/dpkg-reconfigure: mailman3-web is broken or not fully installed So, I am now stuck since apt-get is saying that mailman3-web is not configured yet, however, neither apt-get nor dpkg-reconfigure will successfully configure mailman3-web. Note the syntax error statement from the above dialog which may be the culprit: "sed: -e expression #2, char 77: unterminated `s' command" Does anybody have any idea how to fix this? I would very much appreciate some suggestions. Thanks, Gordon Dickens -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) 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 mailman3-web depends on: ii dbconfig-mysql 2.0.19 ii debconf [debconf-2.0] 1.5.77 ii init-system-helpers1.60 ii lsb-base 11.1.0 ii python33.9.2-3 ii python3-django-hyperkitty 1.3.4-4 ii python3-django-postorius 1.3.4-2+deb11u1 ii python3-mysqldb1.4.4-2+b3 ii python3-psycopg2 2.8.6-2 ii python3-whoosh 2.7.4+git6-g9134ad92-5 ii ucf3.0043 ii uwsgi-core 2.0.19.1-7.1 ii uwsgi-plugin-python3 2.0.19.1-7.1 Versions of packages mailman3-web recommends: ii libapache2-mod-proxy-uwsgi 2.4.52-1~deb11u2 Versions of packages mailman3-web suggests: ii default-mysql-server1.0.7 ii mariadb-server-10.5 [virtual-mysql-server] 1:10.5.12-0+deb11u1 -- Configuration Files: /etc/mailman3/apache.conf changed: Alias /mailman3/favicon.ico /var/lib/mailman3/web/static/postorius/img/favicon.ico Alias /mailman3/static /var/lib/mailman3/web/static Require all granted ProxyPass /mailman3/favicon.ico ! ProxyPass /mailman3/static ! ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost -- debconf information: mailman3-web/pgsql/changeconf: false mailman3-web/remote/host: localhost mailman3-web/dbconfig-remove: true mailman3-web/internal/skip-preseed: false mailman3-web/db/basepath: /var/lib/mailman3/web mailman3-web/upgrade-error: abort * mailman3-web/database-type: mysql mailman3-web/pgsql/no-empty-passwords: * mailman3-web/superuser-name: gordon * mailman3-web/db/app-user: mailman3web@localhost mailman3-web/passwords-do-not-match: * mailman3-web/db/dbname: mailman3web mailman3-web/missing-db-package-error: abort * mailman3-web/superuser-mail: gor...@mailhub4u.com mailman3-web/install-error: abort mailman3-web/pgsql/method: TCP/IP mailman3-web/mysql/authplugin: default mailman3-web/nginx-choice: mailman3-web/dbconfig-upgrade: true mailman3-web/pgsql/admin-user: postgres mailman3-web/pgsql/authmethod-admin: ident * mailman3-web/mysql/method: Unix socket * mailman3-web/emailname: host2.mailhub4u.com mailman3-web/pgsql/authmethod-user: password mailman3-web/remote/port: mailman3-web/remove-error: abort * mailman3-web/restart-webserver: true mailman3-web/pgsql/manualconf: mailman3-web/dbconfig-reinstall: false * mailman3-web/dbconfig-install: true mailman3-web/purge: false mailman3-web/internal/recon
Bug#1000884: autopkgtest
Hi Yadd Jupyter notebook (python3-notebook) ships with symlinks in /usr/lib/python3/dist-packages/notebook/static/components to various javascript libraries which are served to the browser at runtime. That autopkgtest checks for broken symlinks in that tree. Presumably the layout of dist files for marked has changed. I won't be able to look at this imminently, but there is a major version change of marked, there is probably API breakage as well. Since this only arises at runtime in the browser, it's not checked by autopkgtests. I'll look at this, but I'm not likely to be able to do so that quickly due to family commitments. Gordon
Bug#1000271: (no subject)
I'm a bit mysterified by this. Failed tests do seem to be reproducible (in debci) with this package pinned, but I can't work out how the traceback shown actually stems from jupyter_client. This version is meant to already include compatibility fixes (https://github.com/dask/distributed/pull/5286) for jupyter_client 7. I'm wondering if this is something obscure like more filehandles or ports ending up being used and causing interference further down the line. Any ideas?
Bug#1000365: pre-rebuild?
I _think_ this would expected with 22.3.0-1 and python 3.10, since that package was built only for python 3.9. Can you reproduce this with 22.3.0-1+b1 now the python 3.10 binNMUs have (mostly) happened? I can certainly import `zmq` in python3.10 without immediate errors.
Bug#999703: glueviz: Upper-limit dependency on jupyter_client
Source: glueviz Version: 1.0.1+dfsg-1 Severity: important X-Debbugs-Cc: gor...@chronitis.net glueviz depends on jupyter_client < 7, which blocks the migration of jupyter client 7 to testing. As far as I can tell, this library isn't imported anywhere in glueviz. I did a test rebuild in unstable without seeing any errors, but I haven't tried using the package beyond that. Gordon -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-4-amd64 (SMP w/1 CPU thread) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#996469: qiime: Test errors with python3-decorator 5
Package: qiime Severity: normal Tags: upstream X-Debbugs-Cc: gor...@chronitis.net I recently uploaded python-decorator 5.1 to experimental. This appears to break qiime (or qiime's test suite, at least). https://ci.debian.net/data/autopkgtest/unstable/amd64/q/qiime/15900873/log.gz This appears to be consistent with `ci/recipe/meta.yaml` (decorator >=4,<5). Is it possible to patch this for compatibility? The test outputs _look_ cosmetic (although might hide something deeper). -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/1 CPU thread) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qiime depends on: ii python3 3.9.2-3 pn python3-bibtexparser ii python3-dateutil 2.8.1-6 ii python3-decorator 4.4.2-2 pn python3-dill ii python3-networkx 2.5+ds-2 ii python3-pandas1.1.5+dfsg-2 ii python3-pyparsing 2.4.7-1 ii python3-tzlocal 2.1-1 ii python3-yaml 5.4.1-1 Versions of packages qiime recommends: pn q2-cutadapt pn q2-demux pn q2-feature-classifier pn q2-feature-table pn q2-metadata pn q2-quality-filter pn q2-types pn q2cli pn q2templates qiime suggests no packages.
Bug#896460: Please package ipywidgets 7
On Fri, Sep 24, 2021 at 12:02:50AM -0400, Sandro Tosi wrote: > On Tue, Sep 21, 2021 at 2:23 PM Gordon Ball wrote: > > Indeed. qa.d.o betrays me. > > you cant hide the good work :) > > > The answer to this was delayed because I considered several times what > > it should actually be. > > thanks for your thorough explanation! > > > The _python_ side of ipywidgets has never been a problem, but the > > JS/browser side has grown in complexity considerably in recent years, > > and shows little sign of slowing down. > > > > The debian javascript situation has improved somewhat - it was possible > > to significantly simplify the labyrinthine custom build infinity0 did > > for ipywidgets 6 in 6.0.0-8 to mostly use logic from pkg-js-tools, and > > having recent versions of eg, webpack helps a lot. I don't think however > > there is really a useful way of providing "only" the python side of > > ipywidgets in debian. It's already a concern that needing to unvendor > > javascript and hack build processes results in a substandard experience > > in eg, jupyter-notebook, and I don't think it's viable to ship > > ipywidgets unless we can get something resembling full functionality. > > > > The javascript side is blocked on jupyterlab (#934258). I know jpuydt > > has done some work on it in the past, but I don't know the current > > state. Some other signficant building blocks like lumino (ex-phosphorjs) > > are now packaged. > > > > It might be possible to vendor only the needed bits of jupyterlab, as > > was recently necessary in jupyter-notebook (CVE fix requiring multiple > > new dependencies), but I think that illustrates the issue. While the > > python side of jupyter proves tractable, the web application side is a > > large, fast moving target which I have concerns about our ability to > > really keep up and provide a good user experience. > > > is there something (at least on the python side) that we can do to > help you out in upgrading ipywidgets? or asking for help to the > javascript team a viable option? > > would you think it's appropriate to evaluate to vendor the javascript > dependencies? IIRC pip considered doing so (not sure if it was > actually done), and notably kubernetes starting doing that, and that's > been grought up to the TC and that has not been overruled, so when the > balance between maintenance cost vs split dependencies into separate > packages is vastly in favor of the former (as it appears in the > ipywidgets case) vendored is somehow tolerated I'm quite willing where necessary to vendor unpackaged javascript libraries into the package - debian/missing-sources already contains several - but that isn't the main problem. The problem is that the javascript you get doing `pip install` really cannot be argued to be source - it's compiled from multiple javascript and typescript libraries, and it's well beyond any grey area around "maybe a minified copy of handwritten javascript is kind-of source". So it needs to be rebuilt, and that means getting a complex multi-stage source build to work. Just having the javascript dependencies packaged or vendored is only half the problem. > > > I will certainly _attempt_ to get ipywidgets up to date during this > > cycle. But given missing dependencies and the time likely to be > > required, I don't think I can guarantee it. If it cannot be updated in a > > reasonable period of time, I think the question of whether it is better > > to drop it might arise. I appreciate there are dependencies, although I > > think most of them are ultimately optional. > > there are some rather important modules in the rev dep list: > > Checking reverse dependencies... > # Broken Depends: > jupyter-sphinx: python3-jupyter-sphinx > q2-demux: q2-demux > q2-feature-table: q2-feature-table > sagemath: sagemath-jupyter > > # Broken Build-Depends: > jupyter-sphinx: python3-ipywidgets > matplotlib: python3-ipywidgets > nbsphinx: python3-ipywidgets > pandas: python3-ipywidgets > plotly: python3-ipywidgets > sagemath: python3-ipywidgets (>= 6.0.0) > Looking at these, several appear to be wrong dependencies, and several are optional, unless I'm missing something from grepping their source: matplotlib/3.3.4-1: listed in requirements/doc/doc-requirements.txt, but not actually imported anywhere pandas/1.1.5+dfsg-2: listed in requirements-dev.txt, not actually imported anywhere plotly/4.14.3+dfsg-1: imported and used, but includes fallback if missing nbsphinx/0.8.0+ds-2: imported and used, but includes fallback if missing jupyter-sphinx/0.3.2-1: requires ipywidgets
Bug#896460: Please package ipywidgets 7
Indeed. qa.d.o betrays me. The answer to this was delayed because I considered several times what it should actually be. The _python_ side of ipywidgets has never been a problem, but the JS/browser side has grown in complexity considerably in recent years, and shows little sign of slowing down. The debian javascript situation has improved somewhat - it was possible to significantly simplify the labyrinthine custom build infinity0 did for ipywidgets 6 in 6.0.0-8 to mostly use logic from pkg-js-tools, and having recent versions of eg, webpack helps a lot. I don't think however there is really a useful way of providing "only" the python side of ipywidgets in debian. It's already a concern that needing to unvendor javascript and hack build processes results in a substandard experience in eg, jupyter-notebook, and I don't think it's viable to ship ipywidgets unless we can get something resembling full functionality. The javascript side is blocked on jupyterlab (#934258). I know jpuydt has done some work on it in the past, but I don't know the current state. Some other signficant building blocks like lumino (ex-phosphorjs) are now packaged. It might be possible to vendor only the needed bits of jupyterlab, as was recently necessary in jupyter-notebook (CVE fix requiring multiple new dependencies), but I think that illustrates the issue. While the python side of jupyter proves tractable, the web application side is a large, fast moving target which I have concerns about our ability to really keep up and provide a good user experience. I will certainly _attempt_ to get ipywidgets up to date during this cycle. But given missing dependencies and the time likely to be required, I don't think I can guarantee it. If it cannot be updated in a reasonable period of time, I think the question of whether it is better to drop it might arise. I appreciate there are dependencies, although I think most of them are ultimately optional. Gordon On Sun, Sep 19, 2021 at 10:52:39PM -0400, Sandro Tosi wrote: > Hello Gordon, > you've been active uploading several packages of the ipython stack in > the last few days: can you provide an update regarding ipywidgets too? > thanks > > On Sun, Sep 12, 2021 at 12:01 PM Sandro Tosi wrote: > > > > Hello Gordon, > > > > On Sat, 21 Apr 2018 10:55:29 +0200 Tobias Hansen wrote: > > > Sagemath 8.2 uses ipywidgets 7 [1] and using version 6 causes about 80 > > > doctests to fail. > > > > do you have any plan to update ipywidgets to 7+ anytime soon? the > > upstream version currently in sid is severely outdated, being released > > more than 4 years ago! > > > > Several packages are requiring ipywidgets 7 and the lack of it in > > Debian is hold several maintainers back from updating their packages > > (I have 3 myself alone). > > > > This bug was open more than 3 years ago: please provide an update on a > > timeline for ipywidgets 7 for debian, so that we can plan accordingly. > > > > Thanks, > > Sandro > > > > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi
Bug#993864: ITP: taskserver -- taskwarrior synchronisation server
I thought the tracker one at least is a public team, for which access shouldn't need to be approved. In any case, I don't appear to have any way to grant access. I've granted you access to the Salsa team. Welcome! Gordon On Sat, Sep 11, 2021 at 08:20:45PM +, Sergio Cipriano wrote: > Hi Gordon, > > I requested access to the Debian Tasktools Team. > May you accept my request? > > Sergio Cipriano. > > On Friday, September 10th, 2021 at 06:44, Gordon Ball > wrote: > > > Hi Sergio > > > > In that case, please take over the taskd package. Because I felt the > > > > package was abandoned, there has been a "don't migrate to testing" RC > > > > bug open for a while, so feel free to close that when you have something > > > > in better shape. > > > > I don't have a continuing interest in this package, so please remove me > > > > from the uploaders. You might want to join the tasktools team on tracker > > > > (team+taskto...@tracker.debian.org) and add that as a maintainer. > > > > Gordon > > > > On Wed, Sep 08, 2021 at 11:14:19AM +, Sergio Cipriano wrote: > > > > > Hi Gordon, > > > > > > On Wednesday, September 8th, 2021 at 02:16, Gordon Ball > > > gor...@chronitis.net wrote: > > > > > > > Hi Sergio > > > > > > > > Note that there is already `taskd` in the archive (former name of > > > > > > > > taskserver). It's not been uploaded for a number of years and I believed > > > > > > > > that it was dead upstream (and I had lost interest in using it). If > > > > > > > > you're interested you could either take over that package (and introduce > > > > > > > > a new binary name), or I can rm it in favour of taskserver. > > > > > > > > On Tue, Sep 07, 2021 at 09:24:51AM -0300, Sergio de Almeida Cipriano > > > > Junior wrote: > > > > > > > > > Package: wnpp > > > > > > > > > > Severity: wishlist > > > > > > > > > > Owner: Sergio de Almeida Cipriano Junior sergios...@protonmail.com > > > > > > > > > > X-Debbugs-Cc: debian-de...@lists.debian.org, sergios...@protonmail.com > > > > > > > > > > - Package name : taskserver > > > > > > > > > > Version : 1.1.0 > > > > > > > > > > Upstream Author : Göteborg Bit Factory > > > > > supp...@gothenburgbitfactory.org > > > > > > > > > > - URL : https://github.com/GothenburgBitFactory/taskserver > > > > > > > > > > - License : MIT > > > > > > > > > > Programming Lang: C++ > > > > > > > > > > Description : taskwarrior synchronisation server > > > > > > > > > > > > > > > Taskserver is a daemon or service that will allow you to share tasks > > > > > among > > > > > > > > > > different client applications, primarily Taskwarrior. > > > > > > I am interested in taskd and I would be glad to take over the package. > > > > > > Cheers Sergio.
Bug#993864: ITP: taskserver -- taskwarrior synchronisation server
Hi Sergio In that case, please take over the taskd package. Because I felt the package was abandoned, there has been a "don't migrate to testing" RC bug open for a while, so feel free to close that when you have something in better shape. I don't have a continuing interest in this package, so please remove me from the uploaders. You might want to join the tasktools team on tracker (team+taskto...@tracker.debian.org) and add that as a maintainer. Gordon On Wed, Sep 08, 2021 at 11:14:19AM +, Sergio Cipriano wrote: > Hi Gordon, > > On Wednesday, September 8th, 2021 at 02:16, Gordon Ball > wrote: > > > Hi Sergio > > > > Note that there is already `taskd` in the archive (former name of > > > > taskserver). It's not been uploaded for a number of years and I believed > > > > that it was dead upstream (and I had lost interest in using it). If > > > > you're interested you could either take over that package (and introduce > > > > a new binary name), or I can rm it in favour of taskserver. > > > > On Tue, Sep 07, 2021 at 09:24:51AM -0300, Sergio de Almeida Cipriano Junior > > wrote: > > > > > Package: wnpp > > > > > > Severity: wishlist > > > > > > Owner: Sergio de Almeida Cipriano Junior sergios...@protonmail.com > > > > > > X-Debbugs-Cc: debian-de...@lists.debian.org, sergios...@protonmail.com > > > > > > - Package name : taskserver > > > > > > Version : 1.1.0 > > > > > > Upstream Author : Göteborg Bit Factory > > > supp...@gothenburgbitfactory.org > > > - URL : https://github.com/GothenburgBitFactory/taskserver > > > - License : MIT > > > > > > Programming Lang: C++ > > > > > > Description : taskwarrior synchronisation server > > > > > > Taskserver is a daemon or service that will allow you to share tasks among > > > > > > different client applications, primarily Taskwarrior. > > I am interested in taskd and I would be glad to take over the package. > > Cheers Sergio.
Bug#993864: ITP: taskserver -- taskwarrior synchronisation server
Hi Sergio Note that there is already `taskd` in the archive (former name of taskserver). It's not been uploaded for a number of years and I believed that it was dead upstream (and I had lost interest in using it). If you're interested you could either take over that package (and introduce a new binary name), or I can rm it in favour of taskserver. On Tue, Sep 07, 2021 at 09:24:51AM -0300, Sergio de Almeida Cipriano Junior wrote: > Package: wnpp > Severity: wishlist > Owner: Sergio de Almeida Cipriano Junior > X-Debbugs-Cc: debian-de...@lists.debian.org, sergios...@protonmail.com > > * Package name: taskserver > Version : 1.1.0 > Upstream Author : Göteborg Bit Factory > * URL : https://github.com/GothenburgBitFactory/taskserver > * License : MIT > Programming Lang: C++ > Description : taskwarrior synchronisation server > > Taskserver is a daemon or service that will allow you to share tasks among > different client applications, primarily Taskwarrior.
Bug#992704: (no subject)
Ack, already looking at it. Unfortunately, there is unlikely to be a quick fix, since upstream has resolved this by removing their existing html/css sanitizer in favour of an alternative one from the jupyterlab source tree, which will require more packaging work before we can utilise it. This is going to be even more of a problem to backport to stable.
Bug#992554: tor: version 0.4.5.10-1 does not work
Package: tor Version: 0.4.5.10-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: g.shumw...@gmx.net -- System Information: Debian Release: 11.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 5.10.0-8-686-pae (SMP w/4 CPU threads) 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 tor depends on: ii adduser 3.118 ii libc6 2.31-16 ii libcap2 1:2.44-1 ii libevent-2.1-7 2.1.12-stable-1 ii liblzma55.2.5-2 ii libseccomp2 2.5.1-1 ii libssl1.1 1.1.1k-1 ii libsystemd0 247.9-1 ii libzstd11.4.8+dfsg-2.1 ii lsb-base11.1.0 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages tor recommends: ii logrotate3.18.1-2 ii tor-geoipdb 0.4.5.10-1 ii torsocks 2.3.0-3 Versions of packages tor suggests: ii apparmor-utils 2.13.6-10 pn mixmaster pn obfs4proxy ii socat1.7.4.1-3 ii tor-arm 2.1.0-2.1 pn torbrowser-launcher -- no debconf information
Bug#991874: ITP: matplotlib-inline -- Matplotlib inline display backend for IPython and Jupyter
Package: wnpp Severity: wishlist Owner: Gordon Ball X-Debbugs-Cc: gor...@chronitis.net * Package name: matplotlib-inline Version : 0.1.2 Upstream Author : IPython Development Team * URL : https://github.com/ipython/matplotlib-inline * License : BSD Programming Lang: Python Description : Matplotlib inline display backend for IPython and Jupyter This library provides support for displaying matplotlib plots inline in Jupyter notebooks (or other frontends). It was previously part of IPython/ipykernel but has been factored out to simplify their dependencies as of IPython 7.23/ipykernel 6.0.
Bug#900806: Greetings;
Greetings; I sent you an email a couple of days ago and haven't heard from you. Please confirm if you received my email? Yours Sincerely, Engr. Gordon Hirschy email; eng...@engrgordon.com
Bug#987810: filters: kraut: Please remove offensive salute
Package: filters
Version: 2.55-3
Severity: normal
Tags: patch
X-Debbugs-Cc: Asher Gordon
Dear Maintainer,
The 'kraut' filter contains the salute "Sieg Heil!", which was used by
the Nazis and is considered offensive (it's even a crime in
Germany). Please remove this and replace it with "Naturlich!", as in the
following patch (see also the commit message of the patch for more
info):
From a6d6cff523e30fec19488a2efe9e7f638839f2d2 Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Thu, 29 Apr 2021 23:16:58 -0400
Subject: [PATCH] kraut: Remove offensive salute.
The "Sieg Heil!" salute was used by the Nazis, and it is even a crime
to use this salute in Germany today. Replace this salute with the
inoffensive "Naturlich!", literally "Naturally!", used as an emphatic
"yes".
Also remove braces around the "Naturlich!" print statement, since the
braces were left over from when sprintf() was used, and the braces are
not consistent with the rest of the file.
---
debian/changelog | 6 ++
kraut.l | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index d3e0097..bb11d6e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+filters (2.55-4) unstable; urgency=medium
+
+ * kraut: remove offensive "Sieg Heil!" salute.
+
+ -- Asher Gordon Thu, 29 Apr 2021 23:16:46 -0400
+
filters (2.55-3) unstable; urgency=medium
[ Helmut Grohne ]
diff --git a/kraut.l b/kraut.l
index bc522d4..fc8fae1 100644
--- a/kraut.l
+++ b/kraut.l
@@ -65,8 +65,7 @@ Th printf("D");
[Gg]ary printf("Gerhardt");
[Jj]on printf("Hansel");
-[a-f]"!" {printf("%s Naturlich!",yytext);}
-[p-z]"!" {printf("%s Sieg Heil!",yytext);}
+"!"printf("%s Naturlich!", yytext);
. printf("%s", yytext);
\n printf("\n");
--
2.30.2
Also, I'm not sure if the "Sieg Heil!" is a violation of Debian
policy. If so, please raise the severity appropriately (or just apply my
patch ;-) ).
Thanks,
Asher
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 filters depends on:
ii libc6 2.31-11
filters recommends no packages.
Versions of packages filters suggests:
ii bsdgames 2.17-28
-- no debconf information
--
Vimes grunted. "Where there are policemen there's crime, sergeant,
remember that."
"Yes, I do, sir, although I think it sounds better with a little reordering
of the words."
[Snuff, by Terry Pratchett]
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#986727: (no subject)
Just to update, I applied for an unblock (#986915) for 4.8.0-2, which * runs the tests against installed code (instead of the source tree) * blacklists the remaining known flaky tests (appears to match the list Lukas provided) The changes are in git but I haven't uploaded yet (pending approval) - if I haven't heard by 2021-04-16 I will probably upload anyway, as I'll be offline for a week after that, and I _hope_ the changes are fairly uncontriversial. I didn't include all of Lukas' changes - race condition, I'd already made the unblock request before checking this bug again, but I'll try and merge the ubuntu diff after the release.
Bug#986915: unblock: pexpect/4.8.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package pexpect (not yet uploaded to unstable) [ Reason ] #986727: flaky autopkgtests [ Impact ] Failing autopkgtests in stable causing problems for stable updates, unnecessary noise, etc [ Tests ] Built and ran the autopkgtest 15 times in a loop without failures after these changes. [ Risks ] Affects autopkgtest only, should have no regression potential. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] https://salsa.debian.org/python-team/packages/pexpect/-/compare/debian%2F4.8.0-1...master unblock pexpect/4.8.0-2 diff -Nru pexpect-4.8.0/debian/changelog pexpect-4.8.0/debian/changelog --- pexpect-4.8.0/debian/changelog 2021-01-04 19:51:00.0 + +++ pexpect-4.8.0/debian/changelog 2021-04-13 08:20:51.0 + @@ -1,3 +1,10 @@ +pexpect (4.8.0-2) UNRELEASED; urgency=medium + + * Skip several flaky tests, both for build and autopkgtest (Closes: #986727) + * Fix broken URL in d/watch + + -- Gordon Ball Tue, 13 Apr 2021 08:20:51 + + pexpect (4.8.0-1) unstable; urgency=medium [ Ondřej Nový ] diff -Nru pexpect-4.8.0/debian/rules pexpect-4.8.0/debian/rules --- pexpect-4.8.0/debian/rules 2021-01-04 19:51:00.0 + +++ pexpect-4.8.0/debian/rules 2021-04-13 08:20:51.0 + @@ -5,7 +5,13 @@ # replwrap has issues when wrapping a readline-enabled command when # bracketed-paste mode is enabled, which results in extra escape sequences # pexpect isn't... expecting -export PYBUILD_TEST_ARGS = -k 'not (pxssh or replwrap)' +# test_beforeacross_chunks seems to contain a race condition as to whether +# the captured output contains a newline or not, which it then asserts +# test_spawn_uses_env appears to rarely fail with no exit code (also a race?) +export PYBUILD_TEST_ARGS = -k 'not (pxssh or replwrap or test_before_across_chunks or test_spawn_uses_env)' + +# this skips two further tests upstream knows to be flaky in their CI +export TRAVIS = 1 %: dh $@ --with python3,sphinxdoc --buildsystem=pybuild diff -Nru pexpect-4.8.0/debian/tests/control pexpect-4.8.0/debian/tests/control --- pexpect-4.8.0/debian/tests/control 2021-01-04 19:51:00.0 + +++ pexpect-4.8.0/debian/tests/control 2021-04-13 08:20:51.0 + @@ -1,2 +1,2 @@ -Test-Command: python3 -m pytest -k 'not (pxssh or replwrap)' tests +Tests: pytest Depends: @, python3-pytest, openssl diff -Nru pexpect-4.8.0/debian/tests/pytest pexpect-4.8.0/debian/tests/pytest --- pexpect-4.8.0/debian/tests/pytest 1970-01-01 00:00:00.0 + +++ pexpect-4.8.0/debian/tests/pytest 2021-04-13 08:20:51.0 + @@ -0,0 +1,11 @@ +#!/bin/sh -e + +# used upstream to flag some tests as flaky in CI +export TRAVIS=1 + +# copy the tests out of the source tree to use the installed lib +cp -r tests $AUTOPKGTEST_TMP +cd $AUTOPKGTEST_TMP + +# see d/rules for comments on why these tests are skipped +python3 -m pytest -k 'not (pxssh or replwrap or test_before_across_chunks or test_spawn_uses_env)' tests diff -Nru pexpect-4.8.0/debian/watch pexpect-4.8.0/debian/watch --- pexpect-4.8.0/debian/watch 2021-01-04 19:51:00.0 + +++ pexpect-4.8.0/debian/watch 2021-04-13 08:20:51.0 + @@ -1,3 +1,3 @@ version=4 opts=uversionmangle=s/(rc|a|b|c)/~$1/ \ -https://github.com/pexpect/pexpect/tags .*/archive/@ANY_VERSION@@ARCHIVE_EXT@ +https://github.com/pexpect/pexpect/tags .*/@ANY_VERSION@@ARCHIVE_EXT@
Bug#986727: pexpect: flaky and superficial? autopkgtest
On Sun, Apr 11, 2021 at 08:18:34PM +0200, Jochen Sprickerhof wrote: > Hi, > > I looked into this bug but was not able to reproduce it locally. > But it looks like that the autopkgtests only rerun the unit tests with the > local source code and don't test the installed package at all. I was able to > run the tests successfully without having the package installed. > As those tests are run during the package build already, I would propose to > remove the autopkgtests. As you say, it looks flaky (and I see that it is also failing consistently in Ubuntu CI testing - presumably due to different environment). I would prefer not to remove CI completely; even if the testsuite is run in-source it will still detect dependency failures (but I agree that the current version ought to use the installed code). I would propose to do that and skip any of the specific tests found to be flaky. I'll try and do so in the next couple of days. Gordon > > Cheers Jochen
Bug#985633: warn about watch files that use github and include full refs
I started a branch for lintian-brush here: https://salsa.debian.org/chronitis/lintian-brush/-/tree/github-archive-url (using a nonexistant lintian tag, so having a real one would definitely be a first step). However, it turned out to be a bit more complex than I first thought (or hoped): * Lots of unrelated test cases get broken (since it rewrites their watch files) * Lots of different ways of spelling the match pattern - amongst my there were at least three (and subvariants of each) - .*/archive/v([0-9.]+)# now matches nothing - .*/archive/(.+) # now matches refs/tags/x.y.z - .*/archive/@ANY_VERSION@ # now matches nothing and the discussion on IRC suggested other cases too (adding a wildcard for the new /refs/tags/ part, just matching @any_vers...@.tar.gz, etc. * Unpreservable formatting in several of the test cases I was using (continuation lines in comments?) * What new pattern to actually write? The initial idea was just to literally replace /archive/ with /archive/refs/tags/, which _should_ meet the idea of being conservative about what to fix (but might still collide with hand-written fixes for this issue like ./archive/.*/v... I _think_ a good indicator for lintian (and a fixer) would be if the matching expression contains "archive" followed by no wildcard pattern before the capturing group for the version. Let me know if this makes sense to develop further. Gordon
Bug#982776: mpdtoys: mpfade does not work for a stopped MPD server with PulseAudio output
Package: mpdtoys
Version: 0.25.0
Severity: normal
Tags: patch
X-Debbugs-Cc: Asher Gordon
Dear Maintainer,
I have configured my MPD daemon to output through PulseAudio (the PA
server is running as my local user). After doing so, when the daemon is
stopped (no song playing or paused), the volume displays as 'n/a' in
'mpc status' and is returned as undef by the 'volume' method of the
Audio::MPD::Common::Status class in the Audio::MPD Perl library. I'm not
sure why this is--possibly due to a limitation in the PulseAudio
interface--but it breaks mpfade when the MPD daemon is stopped. mpfade
thinks the volume was changed manually, even though it wasn't, and thus
exits erroneously.
Here is the exact message:
$ mpfade 0.5 100
fading up from 0 to 100 over 30 seconds
manual volume change, aborting fade up
I've written a patch to fix this problem. Unfortunately, it's a bit of a
hack, but it should work. I took the liberty of adding a
debian/changelog entry in my name, but of course, feel free to put my
name in brackets and change the name at the bottom. The patch is as
follows:
From ab6adb95c0b3a744df326f3e4351e58fe7084d20 Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Sun, 14 Feb 2021 04:51:29 -0500
Subject: [PATCH] mpfade: Fix setting volume for PulseAudio sound output.
When MPD is configured to output sound through PulseAudio, it seems
that the volume cannot be set or gotten unless a song is playing or
paused (not stopped). This could be a bug in MPD, but more likely it
is a limitation in the PulseAudio interface (I don't know much about
that, so I'm not sure).
In any case, this simple hack (unfortunately it cannot be called
anything other than a hack) should fix it. We also may need to try to
set the volume several times, because it seems it may not be possible
to set the volume immediately after we start playing a song.
---
debian/changelog | 6 ++
mpfade | 16 +++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index 5e07a73..b836200 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+mpdtoys (0.25.2) unstable; urgency=medium
+
+ * mpfade: Fix setting volume for PulseAudio sound output.
+
+ -- Asher Gordon Sun, 14 Feb 2021 05:02:40 -0500
+
mpdtoys (0.25.1) unstable; urgency=medium
* QA upload.
diff --git a/mpfade b/mpfade
index 49adf17..49260a4 100755
--- a/mpfade
+++ b/mpfade
@@ -74,9 +74,23 @@ else {
if (! defined $endpoint) {
$endpoint=50;
}
- $mpd->volume($vol=0);
+ $vol=0;
print "fading up from $vol to $endpoint over $seconds seconds\n";
$mpd->play;
+
+ # Sometimes the volume is not defined unless a song is playing
+ # or paused (not stopped). This seems to happen for PulseAudio
+ # sound output. This little hack gets around that.
+ my $curvol;
+ my $iterations=0;
+ do {
+ $mpd->volume($vol);
+ $curvol=$mpd->status->volume;
+ if (++$iterations >= 10) {
+ die "error: cannot set volume to $vol\n";
+ }
+ } until (defined $curvol && $curvol == $vol);
+
fade($endpoint, $seconds);
}
--
2.30.0
Thanks,
Asher
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 mpdtoys depends on:
ii libaudio-mpd-perl 2.004-2
ii perl 5.32.1-2
mpdtoys recommends no packages.
Versions of packages mpdtoys suggests:
ii libproc-daemon-perl0.23-1
ii libstring-approx-perl 3.28-1+b3
ii libterm-readkey-perl 2.38-1+b2
ii mpd0.22.4-1
-- no debconf information
--
I often quote myself; it adds spice to my conversation.
-- G. B. Shaw
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#971224: ipywidgets FTBFS with node-semver 7.1.1-2
On Sat, Feb 06, 2021 at 04:05:20PM +0100, Ivo De Decker wrote: > Control: tags -1 patch > > Hi, > > On Tue, Jan 28, 2020 at 11:43:47PM +0200, Adrian Bunk wrote: > > Source: ipywidgets > > Version: 6.0.0-6 > > Severity: serious > > Tags: ftbfs > > This is fixed in git: > > https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/23daf45a127b3febe25ecefdbb7148b0f5049990 > > Gordon, are you planning to upload this soon? The soft freeze is pretty close > now. > The FTBFS bugs are fixed, in the sense that I have redone the build system reflecting all the changes that have happened to the parent libraries, and the basic build sequence runs without error. However, the resultant object doesn't actually work (yet). I'll upload it iff I can get something working before the freeze dates. > Thanks! > > Ivo >
Bug#980050: (no subject)
A sufficient patch is ``` diff --git a/debian/tests/control b/debian/tests/control index bc03117..d765359 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1,4 +1,4 @@ -Test-Command: pytest-3 +Test-Command: pytest-3 -k 'not nmr.ipynb' Depends: python3-mdtraj, python3-ipykernel, python3-jupyter-client, ```
Bug#980263: taskwarrior: Filtering for project-names containing hyphen and number stopped working
Hi Nicola Thanks for reporting this bug. This certainly sounds like a regression, which wouldn't be that surprising given the large set of changes between 2.5.1 and 2.5.2. Please report this as a bug upstream. I would expect this to not be an intentional change within a minor version. If a patch is proposed upstream it can be applied. Possibly related: https://github.com/GothenburgBitFactory/taskwarrior/issues/2124 On Sat, Jan 16, 2021 at 09:59:16PM +0100, Nicola Chiapolini wrote: > Package: taskwarrior > Version: 2.5.3+dfsg-1 > Severity: important > > Dear Maintainer, > > I use taskwarrior since several years and have a large number of > projects. One common pattern looks like 'c.vs.2021-01'. After updating > from 2.5.1+dfsg-11 to 2.5.3+dfsg-1, searches for such projects (`task > project:c.vs.2021-01`) fail with error 'Cannot subtract strings'. > > Downgrading fixes the problem. > > > Thanks for all the work. Let me know if I should report this upstream or can > support in any other way. > > best regards > Nicola > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), > (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages taskwarrior depends on: > ii libc62.31-9 > ii libgcc-s110.2.1-3 > ii libgnutls30 3.7.0-5 > ii libstdc++6 10.2.1-3 > ii libuuid1 2.36.1-4 > > taskwarrior recommends no packages. > > taskwarrior suggests no packages. > > -- no debconf information >
Bug#980050: mdtraj: FTBFS with jupyter-client 6.1.11
Source: mdtraj Severity: normal Tags: ftbfs Dear Maintainer, mdtraj appears to FTBFS when trying to migrate jupyter-client 6.1.6 -> 6.1.11 The failure is trying to build the example notebook examples/nmr.ipynb; it appears to fail trying to find an external dependency (sparta) which as far as I can tell was never installed for autopkgtests. I'm not quite sure why this regression is visible at this point, since I can't see why this test would have succeeded before. Presumably a change in jupyter client affected the custom notebook executor in the testsuite. see https://ci.debian.net/data/autopkgtest/testing/amd64/m/mdtraj/9644331/log.gz -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/1 CPU thread) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#976990: fprintd: Latest update broke fprintd entirely
Package: fprintd Version: 1.90.5-2 Severity: grave X-Debbugs-Cc: Asher Gordon Dear Maintainer, After upgrading fprintd (and libpam-fprintd) from 1.90.1-2 to 1.90.5-2, it stopped working entirely. Instead of fingerprint authentication, password authentication is used for login and sudo. I have checked that /etc/pam.d/common-auth has the right settings. The problem appears to be that fprintd itself has stopped working, not the PAM module (which is why I reported this bug in fprintd rather than libpam-fprintd). When I use any of the fprintd-* commands, it fails as follows: $ fprintd-delete asher Impossible to get devices: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.184" (uid=1000 pid=15139 comm="fprintd-delete asher ") interface="net.reactivated.Fprint.Manager" member="GetDevices" error name="(unset)" requested_reply="0" destination=":1.185" (uid=0 pid=15143 comm="/usr/libexec/fprintd ") $ fprintd-enroll asher Impossible to enroll: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.186" (uid=1000 pid=15151 comm="fprintd-enroll asher ") interface="net.reactivated.Fprint.Manager" member="GetDefaultDevice" error name="(unset)" requested_reply="0" destination=":1.185" (uid=0 pid=15143 comm="/usr/libexec/fprintd ") $ fprintd-list asher Impossible to get devices: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.188" (uid=1000 pid=15165 comm="fprintd-list asher ") interface="net.reactivated.Fprint.Manager" member="GetDevices" error name="(unset)" requested_reply="0" destination=":1.185" (uid=0 pid=15143 comm="/usr/libexec/fprintd ") $ fprintd-verify Impossible to verify: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.189" (uid=1000 pid=15169 comm="fprintd-verify ") interface="net.reactivated.Fprint.Manager" member="GetDefaultDevice" error name="(unset)" requested_reply="0" destination=":1.185" (uid=0 pid=15143 comm="/usr/libexec/fprintd ") From the org.freedesktop.DBus.Error.AccessDenied error, it seems that it might be a permissions problem. However, the commands do not work, even when run as root: $ sudo fprintd-list asher [sudo] password for asher: Impossible to get devices: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.199" (uid=0 pid=15422 comm="fprintd-list asher ") interface="net.reactivated.Fprint.Manager" member="GetDevices" error name="(unset)" requested_reply="0" destination=":1.200" (uid=0 pid=15425 comm="/usr/libexec/fprintd ") All the above commands returned with an exit status of 1. Also, if I run /usr/libexec/fprintd manually, I get the following warning (although a 0 exit status): $ /usr/libexec/fprintd (fprintd:15733): fprintd-WARNING **: 13:01:49.856: Failed to get name: net.reactivated.Fprint Perhaps this is because fprintd is already running. However 'ps -fe | grep [f]printd' lists no processes. Thanks, Asher -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND 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 fprintd depends on: ii dbus 1.12.20-1 ii libc6 2.31-5 ii libfprint-2-2 1:1.90.5-2 ii libglib2.0-0 2.66.3-2 ii libpolkit-gobject-1-0 0.105-29 ii policykit-10.105-29 fprintd recommends no packages. fprintd suggests no packages. -- no debconf information -- By necessity, by proclivity, and by delight, we all quote. In fact, it is as difficult to appropriate the thoughts of others as it is to invent. -- R. Emerson -- Quoted from a fortune cookie program (whose author claims, "Actually, stealing IS easier.") [to which I reply, "You think it's easy for me to misconstrue all these misquotations?!?" Ed.] I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#975876: libpam-fprintd: Upgrade removed fprintd method from /etc/pam.d/common-auth
Package: libpam-fprintd Version: 1.90.1-2 Severity: important X-Debbugs-Cc: Asher Gordon Dear Maintainer, When I upgraded the libpam-fprintd package to 1.90.1-2 (from 0.8.1-2¹), fingerprint scanning stopped working for many things, including login, sudo, and systemctl (but still worked for GDM and GNOME). I figured out that this was because the pam_fprintd.so method had been removed from /etc/pam.d/common-auth. After using pam-auth-update to re-add fprintd, everything worked as expected. The upgrade should not have removed the pam_fprintd.so method from /etc/pam.d/common-auth. Indeed, I see no reason why that file should be modified at all. I set the severity of this bug to important, since removing fprintd from common-auth breaks many things, and the cause of the problem is not obvious. Feel free to downgrade if you disagree. The best solution, in my opinion, would be to stop further updates from modifying common-auth. At the very least, something should be added to NEWS.Debian indicating that pam-auth-update will need to be re-run in order to have fingerprints working again. Also, it's possible that a different package upgrade caused the config file to change, but this package seems the likeliest candidate. Thanks, Asher Footnotes: ¹ I had been using an old version because of other problems. See #949165. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-3-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND 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 libpam-fprintd depends on: ii fprintd 1.90.1-2 ii libc6 2.31-4 ii libpam-runtime 1.3.1-5 ii libpam0g1.3.1-5 ii libsystemd0 246.6-4 libpam-fprintd recommends no packages. libpam-fprintd suggests no packages. -- no debconf information -- He was part of my dream, of course -- but then I was part of his dream too. -- Lewis Carroll I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#975334: xeus-python ftbfs
Thanks for reporting. This is a problem with pybind11-json-dev, which embeds the python include path that it is built with, but does not currently declare a dependency on the appropriate libpython3 version. (Not that declaring it would be completely sufficient either, since as an arch:all it wouldn't get binNMU'd anyway). I'll make a new upload of pybind11-json-dev then giveback this package.
Bug#974770: backupninja malformed day warning
Package: backupninja Version: 1.1.0-2.1 When I use something like "when=mondays at 03:00" in the backup configuration file, I get the warning "The day in the 'when' option in the configuration is malformed. [...]". There is a fix for this problem in the backupninja master branch: https://0xacab.org/riseuplabs/backupninja/commit/a0f5063e8b31df18b397a91095f33d4efe39f58e I suggest merging this fix into the Debian branch.
Bug#961402: false positive?
Is this maybe a false positive from build-log scanning? This is a header-only library and installed packages contain only headers, CMake and pkg-config files, and the latter do not appear to set -march=native as a required flag for downstream compilation. -march=native is set when compiling the test suite (test/CMakeLists.txt), which could be patched out, but since those binaries shouldn't leave the build machine, does it matter?
Bug#973043: ITP: xeus-python -- Python kernel for jupyter using the xeus library
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: xeus-python Version : 0.8.6 Upstream Author : QuantStack * URL : https://github.com/jupyter-xeus/xeus-python * License : BSD-3-clause Programming Lang: C++ Description : Python kernel for jupyter using the xeus library This package provides xpython, a high-performance python 3 kernel for the Jupyter interactive computing environment (Jupyter notebook, lab, etc), using the native xeus library to handle messaging between the interpreter and frontend as opposed to the pure-python implementation in ipykernel.
Bug#973041: ITP: xeus -- C++ implementation of the Jupyter interactive computing protocol
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: xeus Version : 0.24.2 Upstream Author : QuantStack * URL : https://github.com/jupyter-xeus/xeus * License : BSD-3-clause Programming Lang: C++ Description : C++ implementation of the Jupyter interactive computing protocol xeus is a library meant to facilitate the implementation of kernels for Jupyter. It takes the burden of implementing the Jupyter Kernel protocol so developers can focus on implementing the interpreter part of the kernel. This is a dependency for xeus-python. I'll maintain it in the debian-sciece team.
Bug#973040: ITP: pybind11-json -- Bridge between nlohmann::json and pybind11
Package: wnpp Severity: wishlist Owner: Gordon Ball * Package name: pybind11-json Version : 0.2.6 Upstream Author : pybind11 contributors * URL : https://github.com/pybind11/pybind11_json * License : BSD-3-clause Programming Lang: C++ Description : Bridge between nlohmann::json and pybind11 Header-only library which extends pybind11 to support automatic conversion of pybind11 objects to nlohmann::json and vice-versa. This is a dependency for xeus-python. I'll maintain this in the debian-science team.
Bug#972785: zeromq3: Include cmake files for cppzmq
On Mon, Oct 26, 2020 at 01:07:09PM +, Luca Boccassi wrote:
> On Mon, 2020-10-26 at 12:28 +0000, Gordon Ball wrote:
> > On Mon, Oct 26, 2020 at 11:52:17AM +, Luca Boccassi wrote:
> > > On Mon, 2020-10-26 at 11:40 +, Gordon Ball wrote:
> > > > On Mon, Oct 26, 2020 at 09:48:52AM +, Luca Boccassi wrote:
> > > > > On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> > > > > > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball
> > > > > > wrote:
> > > > > > > src:zeromq3 and libzmq3-dev currently embed headers from the
> > > > > > > separate
> > > > > > > cppzmq repository. However, the associated cmake files are not
> > > > > > > included,
> > > > > > > which means when trying to build downstream projects which use
> > > > > > > cppzmq
> > > > > > > and cmake, it's necessary to hack the buildsystem or embed the
> > > > > > > cmake
> > > > > > > files from cppzmq.
> > > > > > These are different projects and should be packaged differently. As
> > > > > > czmq is packaged by Luca, I think cppzmq should be packaged by him
> > > > > > as
> > > > > > well. But let's hear what he says.
> > > > > >
> > > > > > Regards,
> > > > > > Laszlo/GCS
> > > > >
> > > > > Hi,
> > > > >
> > > > > Given it's just a header, I don't think it's necessary to do anything
> > > > > complicated - there's nothing to build and there's no dependencies to
> > > > > track. No point in having separate packages or cmake files or whatnot
> > > > > -
> > > > > #include is all a user needs.
> > > > >
> > > >
> > > > The CMake files aren't _needed_, but they're provided upstream and
> > > > downstream projects that use cppzmq and CMake expect them to be there,
> > > > and it feels like an unnecessary friction to need to patch/override the
> > > > buildsystem of downstream projects to get round us shipping the headers
> > > > but not the other parts of the cppzmq distribution.
> > >
> > > Sorry I still don't follow, why does the downstream build system need
> > > to be patched/overriden? Again, it's just a header. There's nothing to
> > > build - just install the package, #include and it's good to go.
> > >
> >
> > This is probably a case where build tools provide you with extra ways to
> > shoot yourself in the foot. See, for example:
> >
> > https://github.com/jupyter-xeus/xeus/blob/master/CMakeLists.txt
> >
> > While the source files do just do `#include `, as you say, the
> > CMakeLists.txt wants to find the CMake config files for cppzmq to check
> > for the version, linker flags required, etc:
> >
> > set(cppzmq_REQUIRED_VERSION 4.4.1)
> > find_package(cppzmq ${cppzmq_REQUIRED_VERSION} REQUIRED)
> > target_link_libraries(... PUBLIC ${CPPZMQ_TARGET_NAME} ...)
> >
> > The CMake files for cppzmq don't (as you'd expect) do much - define a
> > target which requires linking to libzmq and declare the version.
> >
> > So, to build the above project against the current debian libzmq3-dev is
> > possible, but some patching of the downstream package's CMakeLists is
> > required.
>
> Then why not just fix that project upstream to avoid all that? Sorry,
> but I am not going to take on additional work just because of the
> arbitrary choice of a downstream build system. Please fix that instead.
> Thank you.
>
I think it is unlikely that they'll be receptive to making such changes
for my benefit, given they have something that works and is supported
by cppzmq upstream.
However, the workarounds for not having CMake integration in this case
aren't too complicated, so I'll work on that instead.
> --
> Kind regards,
> Luca Boccassi
Bug#972785: zeromq3: Include cmake files for cppzmq
On Mon, Oct 26, 2020 at 11:52:17AM +, Luca Boccassi wrote:
> On Mon, 2020-10-26 at 11:40 +0000, Gordon Ball wrote:
> > On Mon, Oct 26, 2020 at 09:48:52AM +, Luca Boccassi wrote:
> > > On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> > > > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball
> > > > wrote:
> > > > > src:zeromq3 and libzmq3-dev currently embed headers from the separate
> > > > > cppzmq repository. However, the associated cmake files are not
> > > > > included,
> > > > > which means when trying to build downstream projects which use cppzmq
> > > > > and cmake, it's necessary to hack the buildsystem or embed the cmake
> > > > > files from cppzmq.
> > > > These are different projects and should be packaged differently. As
> > > > czmq is packaged by Luca, I think cppzmq should be packaged by him as
> > > > well. But let's hear what he says.
> > > >
> > > > Regards,
> > > > Laszlo/GCS
> > >
> > > Hi,
> > >
> > > Given it's just a header, I don't think it's necessary to do anything
> > > complicated - there's nothing to build and there's no dependencies to
> > > track. No point in having separate packages or cmake files or whatnot -
> > > #include is all a user needs.
> > >
> >
> > The CMake files aren't _needed_, but they're provided upstream and
> > downstream projects that use cppzmq and CMake expect them to be there,
> > and it feels like an unnecessary friction to need to patch/override the
> > buildsystem of downstream projects to get round us shipping the headers
> > but not the other parts of the cppzmq distribution.
>
> Sorry I still don't follow, why does the downstream build system need
> to be patched/overriden? Again, it's just a header. There's nothing to
> build - just install the package, #include and it's good to go.
>
This is probably a case where build tools provide you with extra ways to
shoot yourself in the foot. See, for example:
https://github.com/jupyter-xeus/xeus/blob/master/CMakeLists.txt
While the source files do just do `#include `, as you say, the
CMakeLists.txt wants to find the CMake config files for cppzmq to check
for the version, linker flags required, etc:
set(cppzmq_REQUIRED_VERSION 4.4.1)
find_package(cppzmq ${cppzmq_REQUIRED_VERSION} REQUIRED)
target_link_libraries(... PUBLIC ${CPPZMQ_TARGET_NAME} ...)
The CMake files for cppzmq don't (as you'd expect) do much - define a
target which requires linking to libzmq and declare the version.
So, to build the above project against the current debian libzmq3-dev is
possible, but some patching of the downstream package's CMakeLists is
required.
> > As observed, I don't know ZMQ that well, so I'm not trying to force
> > anything if you really don't think this is good idea, but from my
> > perspective either including the cmake files in libzmq3-dev or splitting
> > cppzmq into a separate source package which ships them would seem to be a
> > usability improvement.
> >
> > > --
> > > Kind regards,
> > > Luca Boccassi
> >
> >
>
Bug#972785: zeromq3: Include cmake files for cppzmq
On Mon, Oct 26, 2020 at 09:48:52AM +, Luca Boccassi wrote: > On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote: > > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball wrote: > > > src:zeromq3 and libzmq3-dev currently embed headers from the separate > > > cppzmq repository. However, the associated cmake files are not included, > > > which means when trying to build downstream projects which use cppzmq > > > and cmake, it's necessary to hack the buildsystem or embed the cmake > > > files from cppzmq. > > These are different projects and should be packaged differently. As > > czmq is packaged by Luca, I think cppzmq should be packaged by him as > > well. But let's hear what he says. > > > > Regards, > > Laszlo/GCS > > Hi, > > Given it's just a header, I don't think it's necessary to do anything > complicated - there's nothing to build and there's no dependencies to > track. No point in having separate packages or cmake files or whatnot - > #include is all a user needs. > The CMake files aren't _needed_, but they're provided upstream and downstream projects that use cppzmq and CMake expect them to be there, and it feels like an unnecessary friction to need to patch/override the buildsystem of downstream projects to get round us shipping the headers but not the other parts of the cppzmq distribution. As observed, I don't know ZMQ that well, so I'm not trying to force anything if you really don't think this is good idea, but from my perspective either including the cmake files in libzmq3-dev or splitting cppzmq into a separate source package which ships them would seem to be a usability improvement. > -- > Kind regards, > Luca Boccassi
Bug#972785: zeromq3: Include cmake files for cppzmq
On Sun, Oct 25, 2020 at 05:13:52PM +0100, László Böszörményi (GCS) wrote: > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball wrote: > > src:zeromq3 and libzmq3-dev currently embed headers from the separate > > cppzmq repository. However, the associated cmake files are not included, > > which means when trying to build downstream projects which use cppzmq > > and cmake, it's necessary to hack the buildsystem or embed the cmake > > files from cppzmq. > These are different projects and should be packaged differently. As > czmq is packaged by Luca, I think cppzmq should be packaged by him as > well. But let's hear what he says. > Yes, this seems reasonable. I'm quite willing to see the patch I prepared as a bit of a nasty hack. I prepared standalone packaging for cppzmq a while ago before I realised that it collided with headers already in libzmq3-dev. The packaging can be found here: https://salsa.debian.org/chronitis/cppzmq - it's pretty trivial since it's header only. The package should be more or less ready to upload if wanted (but probably should be moved out of my salsa namespace). However, the maintainer point is a good one. I'm coming at ZMQ in general as a downstream user and I'm not a domain expert; it would be very good if the packaging was maintained or co-maintained by someone who knows the details of ZMQ a bit better. > Regards, > Laszlo/GCS
Bug#972785: zeromq3: Include cmake files for cppzmq
Source: zeromq3
Severity: normal
Tags: patch
src:zeromq3 and libzmq3-dev currently embed headers from the separate
cppzmq repository. However, the associated cmake files are not included,
which means when trying to build downstream projects which use cppzmq
and cmake, it's necessary to hack the buildsystem or embed the cmake
files from cppzmq.
I've included a patch (against 4.3.3-2) which adds these files to the
source package and libzmq3-dev. Specifically:
* move the existing cppzmq files (zmq.hpp, zmq_addon.hpp) to
debian/cppzmq/ and add the cmake files from cppzmq 4.6.0
* add Provides: cppzmq-dev to libzmq3-dev, which would hopefully make
it easier to split the packages in future
* build-depend on cmake, and add an override after dh_auto_install to
process and install the cmake.in files from cppzmq
I appreciate this is a larger change than #951135. Other options would be to
* continue to bundle cppzmq in a common source package, but use
multiple upstream tarballs so cppzmq is a more obvious component and
the embedded files can be more readily updated together.
* split cppzmq into a separate source package. Some downstream
dependencies would need to be fixed. Codesearch suggests gnuradio,
libopenshot, thrift, tango, ignition-transport, horizon-eda
Gordon
From 5c8f7f94d1e62a8a51bf73484493d9ae2e332a4d Mon Sep 17 00:00:00 2001
From: Gordon Ball
Date: Tue, 15 Sep 2020 08:52:10 +
Subject: [PATCH] Add cppzmq cmake files
---
debian/changelog | 10 ++
debian/control| 5 +-
debian/copyright | 6 +-
debian/cppzmq/CMakeLists.txt | 102 ++
debian/cppzmq/cmake/DetectCPPZMQVersion.cmake | 8 ++
debian/cppzmq/cppzmqConfig.cmake.in | 36 +++
.../cppzmq/libzmq-pkg-config/FindZeroMQ.cmake | 26 +
debian/{ => cppzmq}/zmq.hpp | 0
debian/{ => cppzmq}/zmq_addon.hpp | 0
debian/libzmq3-dev.install| 3 +-
debian/rules | 9 ++
11 files changed, 199 insertions(+), 6 deletions(-)
create mode 100644 debian/cppzmq/CMakeLists.txt
create mode 100644 debian/cppzmq/cmake/DetectCPPZMQVersion.cmake
create mode 100644 debian/cppzmq/cppzmqConfig.cmake.in
create mode 100644 debian/cppzmq/libzmq-pkg-config/FindZeroMQ.cmake
rename debian/{ => cppzmq}/zmq.hpp (100%)
rename debian/{ => cppzmq}/zmq_addon.hpp (100%)
diff --git a/debian/changelog b/debian/changelog
index 072ba91..d020488 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+zeromq3 (4.3.3-3) UNRELEASED; urgency=medium
+
+ * In addition to the header files zmq.hpp and zmq_addon.hpp from cppzmq,
+libzmq3-dev now includes the associated CMake files for cppzmq
+ + The embedded cppzmq source files have been moved to d/cppzmq/
+ + Add Provides: cppzmq-dev to libzmq3-dev
+ + Add cmake to Build-Depends
+
+ -- Gordon Ball Tue, 25 Aug 2020 14:32:39 +
+
zeromq3 (4.3.3-2) unstable; urgency=medium
* Backport upstream fix of broken zmq_ctx_get API.
diff --git a/debian/control b/debian/control
index cac55c3..7eb56ac 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,8 @@ Build-Depends: debhelper-compat (= 11),
libkrb5-dev,
pkg-config,
xmlto,
- asciidoc
+ asciidoc,
+ cmake
Standards-Version: 4.5.0
#Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/zeromq3.git
#Vcs-Git: git://anonscm.debian.org/collab-maint/zeromq3.git
@@ -36,7 +37,7 @@ Section: libdevel
Depends: libzmq5 (= ${binary:Version}), ${misc:Depends}, libpgm-dev (>=
5.2.122~dfsg), libsodium-dev, libnorm-dev, libkrb5-dev
Conflicts: libzmq-dev, libzmq5-dev
Replaces: libzmq5-dev
-Provides: libzmq5-dev
+Provides: libzmq5-dev, cppzmq-dev
Multi-Arch: same
Description: lightweight messaging kernel (development files)
ØMQ is a library which extends the standard socket interfaces with features
diff --git a/debian/copyright b/debian/copyright
index a7cd247..f11fb19 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -55,12 +55,14 @@ Copyright: 2014-, Laszlo Boszormenyi (GCS)
2012, Alessandro Ghedini
License: LGPL-2.0+
-Files: debian/zmq.hpp
+Files: debian/cppzmq/*
Copyright: 2009-2011, 250bpm s.r.o.
2011, Botond Ballo
2007-2013, iMatix Corporation
+ 2016, VOCA AS / Harald Nøkland
+ 2016-2020, ZeroMQ community
License: MIT
-Comment: The C++ header was downloaded from https://github.com/zeromq/cppzmq
+Comment: Downloaded from https://github.com/zeromq/cppzmq
License: LGPL-2.0+
This package is free software; you can redistribute it and/or
diff --git a/debian/cppzmq/CMakeLists.txt b/debian/cppzmq/CMakeLists.txt
new file mode 100644
index 000..81e19e8
--- /dev/null
+++ b/debian/cppzmq/CMakeLists.txt
@@ -0,0 +1,102 @@
+cmake_minimum_required(VERSION 3.0.0)
+
+list (APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake&quo
Bug#968600: (no subject)
Thank you for the patch. Unfortunately, this bug probably does not meet the standard for a update to the "stable" release. The guidelines [0] are that a bug to be fixed in stable should have at least severity "important", which is defined as a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. which I think this probably doesn't justify. [0]: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
Bug#972083: ITP: python-jupyterlab-pygments -- Syntax coloring scheme for pygments using JupyterLab
On Mon, Oct 12, 2020 at 01:46:40PM +0200, Julien Puydt wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-pyt...@lists.debian.org > > * Package name : python-jupyterlab-pygments > Version: 0.1.2 > Upstream author: Project Jupyter Contributors > * URL : https://github.com/jupyterlab/jupyterlab_pygments > * License : BSD-3-clause > Description: Syntax coloring scheme for pygments using JupyterLab > Provides a syntax coloring scheme for pygments using JupyterLab, which > enables the use of JupyterLab's themes with pygments-generated HTML. > > > This is a new dependency of nbconvert, so it's needed to update this > existing package. > Thanks - I missed this one. Clearly I only got as far as spotting nbclient in the new dependencies list and missed this one. > I'm wondering if the source package shouldn't be named jupyterlab- > pygments instead of python-jupyterlab-pygments: there will be quite a > number of jupyterlab-related packages, all in the Python team, so the > python- prefix might not really be needed. What does the team think > about it? Seems pretty reasonable - most of the existing jupyter libraries have source packages named ^jupyter (-core, -client, -console, -notebook), so it's hardly unprecedented. >From this comment, are you planning to package jupyterlab itself? I looked at doing so in the past and found the JS part daunting, but maybe after 3.0 is a good time to look again. > > Cheers, > > JP >
Bug#970984: linux-image-5.8.0-2-amd64: Please replace console scrollback
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=209421 Hi Moritz, Moritz Mühlenhoff writes: > Yeah, I'm also bitten by this for my day-to-day workflows, but > unfortunately this was removed upstream, this is not a Debian-specific > patch, so this needs to be fixed upstream, before it becomes available > in Debian again. OK, I forwarded this upstream here: https://bugzilla.kernel.org/show_bug.cgi?id=209421 Thanks, Asher -- The marvels of today's modern technology include the development of a soda can, when discarded will last forever ... and a $7,000 car which when properly cared for will rust out in two or three years. I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
