Bug#1070783: python3-gpumodules: fails to parse kernel version for +bpo debian backport kernels
Package: python3-gpumodules
Version: 3.8.0-1
Severity: normal
Tags: patch
> uname -a
Linux dirac 6.6.13+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.13-1~bpo12+1
(2024-02-15) x86_64 GNU/Linux
This seems to fix the problem and basic functionality appears to work:
--- /usr/lib/python3/dist-packages/GPUmodules/env.py.old2024-05-09
13:07:32.387667230 +1000
+++ /usr/lib/python3/dist-packages/GPUmodules/env.py2024-05-09
13:07:42.171546939 +1000
@@ -309,7 +309,7 @@
# Check Linux Kernel version
current_kversion_str = release()
-current_kversion = tuple([int(x) for x in re.sub('-.*', '',
current_kversion_str).split('.')])
+current_kversion = tuple([int(x) for x in re.sub('[-+].*', '',
current_kversion_str).split('.')])
LOGGER.debug('Using Linux Kernel: %s', current_kversion_str)
if current_kversion < __required_kversion__:
print('Using Linux Kernel {}, but {} requires > {}.{}.'.format(
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-gpumodules depends on:
ii lshw02.19.git.2021.06.19.996aaad9c7-2+b1
ii python3 3.11.2-1+b1
ii python3-matplotlib 3.6.3-1+b1
ii python3-pandas 1.5.3+dfsg-2
python3-gpumodules recommends no packages.
Versions of packages python3-gpumodules suggests:
ii ricks-amdgpu-utils 3.8.0-1
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/GPUmodules/env.py (from
python3-gpumodules package)
Bug#1070646: rust-gst-plugin-gtk4: Please package GStreamer plugin .so as well for use by non-Rust applications
Source: rust-gst-plugin-gtk4 Version: 0.12.5-1 Severity: wishlist X-Debbugs-Cc: werdah...@riseup.net, a...@sigxcpu.org It would be great if there was also a stand-alone package with the .so for the GStreamer Rust plugin(s) for use by normal/other GStreamer applications. Filing bug as discussed on IRC in #debian-rust with werdahias. Many thanks for your work. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1067661: condor: unable to install condor on armhf in Ubuntu
My apologies. I cut and pasted the wrong bug number. However, thank you for the patch. I have included it in the upcoming 23.6.2 release in Debian. I have also incorporated this patch upstream. -- Tim Theisen (he, him, his) Release Manager HTCondor & Open Science Grid Center for High Throughput Computing Department of Computer Sciences University of Wisconsin - Madison 4261 Computer Sciences and Statistics 1210 W Dayton St Madison, WI 53706-1685 +1 608 265 5736
Bug#1069674: openssh-client: multiplexed connections use incorrect DISPLAY etc, but no TOKENS exist to modify the connection socket
Package: openssh-client Version: 1:9.2p1-2+deb12u2 Severity: normal With .ssh/config: ControlMaster auto ControlPath ~/.ssh/cm_master/%r@%h:%p ControlPersist yes Set up the mux master on host a to host c: > echo $DISPLAY :0 > ssh c xterm xterm fires up on host a. Kill that Now, if we arrange for DISPLAY to point to another display (I sshed to another host b, set DISPLAY=:0, verified xterm opened up on that host, then sshed back to my original host a), and try to fire up ssh again: > echo $DISPLAY localhost:11.0 > ssh c xterm xterm fires up on host a instead of host b, which was where $DISPLAY was pointing. OK, so the muxing protocol isn't smart enough to allow DISPLAY to be dynamically set (a bit like bug #931187, ssh not properly acting as if a new connection has been made and handing out /etc/motd properly). So let's work around it by setting ControlPath according to what DISPLAY is being asked for. Hmmmf, there are no appropriate TOKENS. Perhaps there should be a %D TOKEN value for $DISPLAY? Or since I'm sure there's other connection properties that shouldn't be shared between multiplexed connections, can the protocol be modified to allow DISPLAY and other values to be properly set per multiplexed connection? -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 openssh-client depends on: ii adduser 3.134 ii libc6 2.36-9+deb12u4 ii libedit2 3.1-20221030-2 ii libfido2-11.12.0-2+b1 ii libgssapi-krb5-2 1.20.1-2+deb12u1 ii libselinux1 3.4-1+b6 ii libssl3 3.0.11-1~deb12u2 ii passwd1:4.13+dfsg1-1+b1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages openssh-client recommends: ii xauth 1:1.1.2-1 Versions of packages openssh-client suggests: ii keychain 2.8.5-3 pn libpam-ssh pn monkeysphere ii ssh-askpass 1:1.2.4.1-16 -- Configuration Files: /etc/ssh/ssh_config changed [not included] -- no debconf information
Bug#1069660: directvnc: Allow password file to be supplied vs just commandline
Package: directvnc Version: 0.7.8-1 Severity: normal man 1 directvnc: -p, --password password string to be passed to the server for authentication. Use this with care! OK, so what's care? Well, the password is available for all system users and crackers to view with just `ps faux | grep directvnc`. But what if there was a way to supply the password through a file, like on all other vnc servers? Looking at the documentation, I can't see any such way to provide the password through a file. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 directvnc depends on: ii libc6 2.36-9+deb12u4 ii libdirectfb-1.7-7 1.7.7-11 pn libdirectfb-1.7-7t64 ii libjpeg62-turbo 1:2.1.5-2 ii zlib1g1:1.2.13.dfsg-1 Versions of packages directvnc recommends: ii x11proto-core-dev 2022.1-1 ii x11proto-dev [x11proto-core-dev] 2022.1-1 directvnc suggests no packages.
Bug#887139: d-i daily 2018-01-14 amd64 damages UEFI setup on Fujitsu Lifebook AH532
A kernel-based workaround for the underlying issue has now landed in all currently supported linux-stable branches: linux-6.8: 6.8-rc7 (f45812cc23fb74bef62d4eb8a69fe7218f4b9f2a) linux-6.7: 6.7.9(cbf12e716a52d260fabecdca7d5f6e7cd07aed6c) linux-6.6: 6.6.21 (71da10e633a96593cf59af3f322a9c49a22cb71e) linux-6.1: 6.1.81 (249d6ca4ff0022a4b51a8eb9fac6d7bff2c94d1b) linux-5.15: 5.15.154 (9bc9c11c151ab27214cc204d954ee902e9bbe8e2) linux-5.10: 5.10.215 (f33255ccbb0f627da76364cce72cf980d027142c) linux-5.4: 5.4.274 (34b5d2ff9ed5cdea9f971f394c0d623761a4d357) linux-4.19: 4.19.312 (a7bd7dbaa2ddcf8c5ed5d96df240f1442447d252) Unfortunately, said kernel has to be used during installation, so the issue won't be fixed in practice until the next set of installation images are built. Afterwards, this issue can probably be considered "fixed", at least with regards to the Fujitsu Lifebook AH532 (and extended family). The other bug report for the Dell Latitude 5510 seems to be unrelated.
Bug#1066979: common-auth: sudo should not have incorrect password delay
Package: libpam-runtime Version: 1.5.2-6+rpt2+deb12u1 Severity: normal File: common-auth X-Debbugs-Cc: tdh...@gmail.com Dear Maintainer, By default, on Debian and derivatives, `sudo` has a ~2 second delay for incorrect password attempts. This serves no security purpose whatsoever and merely annoys the user. I think it would be great if it could be removed. Unfortunately it's not super simple because you do want a delay from other authentication clients (sshd, etc.), and they all use /etc/pam.d/auth-common, so you can't just add `nodelay` to `pam_unix.so` in that file. I can think of a few solutions, but I'm not super familiar with Debian's PAM system (especially `pam-auth-update`). Anyway: 1. Add `auth-common-nodelay` that's exactly the same as `auth-common` but with `nodelay`, and use that from `/etc/pam.d/sudo[-i]`. 2. Add `nodelay` in `auth-common` and then add `auth-delay` that uses `pam_faildelay.so` to add a delay. The `@include auth-delay` from all files *except* `sudo[-i]`. 3. Improve `pam_faillock.so` to support exponential delays. The use of exponential delays is a very obvious feature and surprising omission. I assume the delay was originally fixed because of PAM's weird architecture that makes stateless authentication easier. However `pam_faillock.so` is stateful and records failed authentication attempts so the hard work has already been done. Modifying it to have an exponential delay (0, 0, 0, 0, 0, 1, 2, 2, 5, 10s, ...) would be quite easy. I think 3 would be the best solution but is probably a fair bit of work. I'm not sure 2 is a great option because it isn't fail-safe. 1 is probably a reasonable option. Also, a 2 second delay may sound insignificant but think how many people in the world use sudo. It's a minor annoyance multiplied by millions. Cheers, Tim -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 6.1.0-rpi7-rpi-v8 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 libpam-runtime depends on: ii debconf [debconf-2.0] 1.5.82 ii libpam-modules 1.5.2-6+rpt2+deb12u1 libpam-runtime recommends no packages. libpam-runtime suggests no packages. -- debconf information: libpam-runtime/profiles: unix, systemd, chksshpwd libpam-runtime/override: false libpam-runtime/conflicts: libpam-runtime/no_profiles_chosen: libpam-runtime/title:
Bug#1066090: psmisc: killall --older-than doesn't work as documented in a container
Package: psmisc
Version: 23.6-1
Severity: normal
killall --older-than 30s restartx11vnc x11vnc vncserver x0tigervncserver
websockify
doesn't kill any processes inside my container, whereas it always used
to work on a VM and on hardware. Removing '--older-than 30s' kills
all such processes. I strongly suspect the culprit is how
/proc/$pid/stat is interpreted:
--older-than case:
3921851 openat(AT_FDCWD, "/proc/3918880", O_RDONLY|O_DIRECTORY) = 3
3921851 openat(3, "stat", O_RDONLY) = 4
3921851 fcntl(4, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
3921851 newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=0, ...},
AT_EMPTY_PATH) = 0
3921851 read(4, "3918880 (x11vnc) S 3918875 39184"..., 1024) = 336
3921851 close(4)= 0
3921851 openat(AT_FDCWD, "/proc/uptime", O_RDONLY) = 4
3921851 newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=23, ...},
AT_EMPTY_PATH) = 0
3921851 read(4, "82599.37 82599.37\n", 4096) = 18
3921851 close(4)= 0
3921851 close(3)= 0
no such flag:
3960244 openat(AT_FDCWD, "/proc/3918880", O_RDONLY|O_DIRECTORY) = 3
3960244 openat(3, "stat", O_RDONLY) = 4
3960244 fcntl(4, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
3960244 newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=0, ...},
AT_EMPTY_PATH) = 0
3960244 read(4, "3918880 (x11vnc) S 1 3918464 366"..., 1024) = 332
3960244 close(4)= 0
3960244 pidfd_send_signal(3, SIGTERM, NULL, 0) = 0
3960244 close(3)= 0
I'm guessing it's looking at field 22 starttime in /proc/$pid/stat?
starttime is seconds since boot. Since the process exists in the
parent system as well, starttime will surely be seconds since host
boot? But /proc/uptime is seconds since container boot.
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 psmisc depends on:
ii libc6 2.36-9+deb12u4
ii libtinfo6 6.4-4
psmisc recommends no packages.
psmisc suggests no packages.
-- no debconf information
Bug#944780: Info received (Many more cases where this fails - proposed patch included)
This bug is still present in bookworm. Attached updated patch. diff -urN bash-5.2.15.orig/execute_cmd.c bash-5.2.15/execute_cmd.c --- bash-5.2.15.orig/execute_cmd.c 2022-12-13 17:09:02.0 + +++ bash-5.2.15/execute_cmd.c 2022-12-13 17:09:02.0 + @@ -5633,7 +5633,12 @@ /* If we're optimizing out the fork (implicit `exec'), decrement the shell level like `exec' would do. Don't do this if we are already in a pipeline environment, assuming it's already been done. */ - if (nofork && pipe_in == NO_PIPE && pipe_out == NO_PIPE && (subshell_environment & SUBSHELL_PIPE) == 0) + if (nofork && pipe_in == NO_PIPE && pipe_out == NO_PIPE && + (subshell_environment & SUBSHELL_ASYNC) == 0 && + (subshell_environment & SUBSHELL_PAREN) == 0 && + (subshell_environment & SUBSHELL_COMSUB) == 0 && + (subshell_environment & SUBSHELL_PIPE) == 0 && + (subshell_environment & SUBSHELL_COPROC) == 0) adjust_shell_level (-1); maybe_make_export_env ();
Bug#1064960: orc: Please update to new upstream release orc 0.4.38
Source: orc Version: 1:0.4.34-3 Severity: wishlist Tags: upstream Hi, Would be great if the package in Debian could be updated to the upstream 0.4.38 release which adds AVX support for x86 architectures and has many fixes for MMX/SSE/Neon. Thanks! Tim -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022043: apt-cacher-ng sometimes fails with several concurrent
On Fri, 23 Feb 2024, Andreas B. Mundt wrote: Hi Tim, thanks for the provided patch! We see the same issue here, so I included it in a locally built package to give it a try on our infrastructure. So far it looks quite promising, no errors up to now . That's great! I've been running it for a few weeks now and also seen no errors since I started using it. I believe it's possibly fixed a second "buggette" too although I never confirmed that this really existed and I haven't confirmed that it's definitely gone away either. If you simultaneously install a big package on multiple machines at the same time (e.g. a kernel upgrade) then I believe that apt-cacher-ng used to download it from upstream multiple times. Only once it had a copy did it serve that up. This was noticable to me in the past because I was on a relatively slow download (c 2MB/s) so kernels would take a noticable amount of time to download and 10 in parallel could take a lot longer than a single download should have taken. I used to work around this by triggering the download on a single machine and then only triggering the rest once that one had completed downloading. Since applying this fix I've done another mass kernel upgrade. I'm on a much faster connection now so I didn't really think about triggering the download in advance but it only downloaded the kernel once. zgrep linux-image-5.10.0-28 * access.log.2.gz:1708183270.671 17321 TCP_MISS/200 55667185 GET http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-5.10.0-28-amd64_5.10.209-2_amd64.deb - HIER_DIRECT/2a04:4e42:4b::644 application/vnd.debian.binary-package Next time I'll try and take more care to watch what really happens here (although with my much faster connection a kernel downloads in a few seconds anyway) Tim.
Bug#1014625: xterm: screen corruption of scrollback buffer
On Sat, 9 Jul 2022, Thomas Dickey wrote: > On Sat, Jul 09, 2022 at 02:39:41PM +1000, Tim Connors wrote: > > This has happened ever since I changed my hardware -- mostly updating > > my video card to a radeon RX570 -- necessitating new versions of some > > drivers and kernel. While I would happily accept that the video card > > might have some dodgy memory (note to self: find a GPU memory stress > > tester), this corruption has not affected any other program other than > > xterm's scrollback buffer, so I wonder if it's a bug instead. > > > > Screengrabs of the symptom: > > > > https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption.png > > https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption2.png > > > > radeon amdgpu drivers and firmware are the latest version allowed by > > otherwise being on debian stable - ie, > > It looks like the problem is in the drivers (not xterm). > > That could be defective implementation of XCopyArea, for instance. > > https://bugs.freedesktop.org/show_bug.cgi?id=110214 For those following along at home, for debian bullseye, the solution was simply to downgrade back to (old)stable's kernels, but alas that is no longer a solution for debian bookworm - the framebuffer bug is still there in 6.1 and 6.5 kernels. However, one of those bugs somewhere hinted about using xcompmgr. Running that in fvwm has solved my problem (as well as solving excessive CPU usage in mozilla related to it wanting to continually update windows that aren't actually in view). No apparent sideeffects at all, which seems rather strange for something coming out of the shiny new world. I have no idea how xcompmgr fixes this, but it fixes the screen artefacts in xterm nevertheless! -- Tim Connors
Bug#1063890: libzydiscore-dev: Static library is missing
Package: libzydiscore-dev Severity: normal X-Debbugs-Cc: tim.rueh...@gmx.de Dear Maintainer, for software development, I need to build static binaries. Currently, I have to build my own static library. But it would be way easier to communicate the build steps in Zydis didn't need an extra recipe on how to build and install the static library. Please add the static library to the package (libzydis-dev is also affected). -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_AUX Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1063773: postfix-mysql upgrade add dynamicmaps.cf after postfix restart
Package: postfix-mysql Version: 3.7.10-0+deb12u1 Severity: normal Dear Maintainer, Today some of our servers upgraded there postfix and postfix-mysql packages. After upgrade we see these messages in postfix logs and of course we can't send mail anymore: postfix/proxymap[2428105]: warning: mysql:/etc/postfix/mysql-virtual-alias-maps.cf is unavailable. unsupported dictionary type: mysql postfix/trivial-rewrite[2428104]: warning: virtual_alias_domains: proxy:mysql:/etc/postfix/mysql-virtual-alias-maps.cf: table lookup problem postfix/trivial-rewrite[2428104]: warning: virtual_alias_domains lookup failure In /etc/postfix/dynamicmaps.cf postfix-mysql map appear so we restart postfix and everything is back again. In apt logs we found that postfix is configured before postfix-mysql finish his configuration: Préparation du dépaquetage de .../postfix-sqlite_3.7.10-0+deb12u1_amd64.deb ... Removing sqlite map entry from /etc/postfix/dynamicmaps.cf Dépaquetage de postfix-sqlite (3.7.10-0+deb12u1) sur (3.7.9-0+deb12u1) ... Préparation du dépaquetage de .../postfix-pcre_3.7.10-0+deb12u1_amd64.deb ... Removing pcre map entry from /etc/postfix/dynamicmaps.cf Dépaquetage de postfix-pcre (3.7.10-0+deb12u1) sur (3.7.9-0+deb12u1) ... Préparation du dépaquetage de .../postfix-mysql_3.7.10-0+deb12u1_amd64.deb ... Removing mysql map entry from /etc/postfix/dynamicmaps.cf Dépaquetage de postfix-mysql (3.7.10-0+deb12u1) sur (3.7.9-0+deb12u1) ... Préparation du dépaquetage de .../postfix_3.7.10-0+deb12u1_amd64.deb ... /etc/postfix/main.cf.proto modified, not updating. Dépaquetage de postfix (3.7.10-0+deb12u1) sur (3.7.9-0+deb12u1) ... Préparation du dépaquetage de .../postfix-doc_3.7.10-0+deb12u1_all.deb ... Dépaquetage de postfix-doc (3.7.10-0+deb12u1) sur (3.7.9-0+deb12u1) ... Paramétrage de postfix (3.7.10-0+deb12u1) ... Postfix (main.cf) configuration was not changed. If you need to make changes, edit /etc/postfix/main.cf (and others) as needed. To view Postfix configuration values, see postconf(1). After modifying main.cf, be sure to run 'systemctl reload postfix'. Paramétrage de postfix-doc (3.7.10-0+deb12u1) ... Paramétrage de postfix-pcre (3.7.10-0+deb12u1) ... Adding pcre map entry to /etc/postfix/dynamicmaps.cf Paramétrage de postfix-sqlite (3.7.10-0+deb12u1) ... Adding sqlite map entry to /etc/postfix/dynamicmaps.cf Paramétrage de postfix-mysql (3.7.10-0+deb12u1) ... Adding mysql map entry to /etc/postfix/dynamicmaps.cf Traitement des actions différées (« triggers ») pour man-db (2.11.2-2) ... So, in correlation with other logs we found that postfix is restarted before postfix-mysql add mysql map in dynamicmaps.cf. We have observed this scenario with postfix-pgsql, postfix-sqlite and postfix-pcre packages. Not sure but these packages have Breaks control field in Debian 10 and Debian 11. This control field doesn't appear in Debian 12. For example: Debian 12: https://tracker.debian.org/media/packages/p/postfix/control-3.7.10-0deb12u1 Debian 11: https://tracker.debian.org/media/packages/p/postfix/control-3.5.24-0deb11u1 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-26-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) Versions of packages postfix-mysql depends on: ii libc62.36-9+deb12u4 ii libmariadb3 1:10.11.6-0+deb12u1 ii postfix 3.7.10-0+deb12u1 postfix-mysql recommends no packages. postfix-mysql suggests no packages.
Bug#1063772: postfix-mysql upgrade add map in dynamicmaps.cf after postfix restart
Package: postfix-mysql Version: 3.7.10-0+deb12u1 Severity: normal Dear Maintainer, Today some of our servers upgraded there postfix and postfix-mysql packages. After upgrade we see these messages in postfix logs and of course we can't send mail anymore: postfix/proxymap[2428105]: warning: mysql:/etc/postfix/mysql-virtual-alias-maps.cf is unavailable. unsupported dictionary type: mysql postfix/trivial-rewrite[2428104]: warning: virtual_alias_domains: proxy:mysql:/etc/postfix/mysql-virtual-alias-maps.cf: table lookup problem postfix/trivial-rewrite[2428104]: warning: virtual_alias_domains lookup failure In /etc/postfix/dynamicmaps.cf postfix-mysql map appear so we restart postfix and everything is back again. In apt logs we found that postfix is configured before postfix-mysql finish his configuration: Préparation du dépaquetage de .../postfix-sqlite_3.7.10-0+deb12u1_amd64.deb ... Removing sqlite map entry from /etc/postfix/dynamicmaps.cf Dépaquetage de postfix-sqlite (3.7.10-0+deb12u1) sur (3.7.9-0+deb12u1) ... Préparation du dépaquetage de .../postfix-pcre_3.7.10-0+deb12u1_amd64.deb ... Removing pcre map entry from /etc/postfix/dynamicmaps.cf Dépaquetage de postfix-pcre (3.7.10-0+deb12u1) sur (3.7.9-0+deb12u1) ... Préparation du dépaquetage de .../postfix-mysql_3.7.10-0+deb12u1_amd64.deb ... Removing mysql map entry from /etc/postfix/dynamicmaps.cf Dépaquetage de postfix-mysql (3.7.10-0+deb12u1) sur (3.7.9-0+deb12u1) ... Préparation du dépaquetage de .../postfix_3.7.10-0+deb12u1_amd64.deb ... /etc/postfix/main.cf.proto modified, not updating. Dépaquetage de postfix (3.7.10-0+deb12u1) sur (3.7.9-0+deb12u1) ... Préparation du dépaquetage de .../postfix-doc_3.7.10-0+deb12u1_all.deb ... Dépaquetage de postfix-doc (3.7.10-0+deb12u1) sur (3.7.9-0+deb12u1) ... Paramétrage de postfix (3.7.10-0+deb12u1) ... Postfix (main.cf) configuration was not changed. If you need to make changes, edit /etc/postfix/main.cf (and others) as needed. To view Postfix configuration values, see postconf(1). After modifying main.cf, be sure to run 'systemctl reload postfix'. Paramétrage de postfix-doc (3.7.10-0+deb12u1) ... Paramétrage de postfix-pcre (3.7.10-0+deb12u1) ... Adding pcre map entry to /etc/postfix/dynamicmaps.cf Paramétrage de postfix-sqlite (3.7.10-0+deb12u1) ... Adding sqlite map entry to /etc/postfix/dynamicmaps.cf Paramétrage de postfix-mysql (3.7.10-0+deb12u1) ... Adding mysql map entry to /etc/postfix/dynamicmaps.cf Traitement des actions différées (« triggers ») pour man-db (2.11.2-2) ... So, in correlation with other logs we found that postfix is restarted before postfix-mysql add mysql map in dynamicmaps.cf. We have observed this scenario with postfix-pgsql, postfix-sqlite and postfix-pcre packages. Not sure but these packages have Breaks control field in Debian 10 and Debian 11. This control field doesn't appear in Debian 12. For example: Debian 12: https://tracker.debian.org/media/packages/p/postfix/control-3.7.10-0deb12u1 Debian 11: https://tracker.debian.org/media/packages/p/postfix/control-3.5.24-0deb11u1 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.2.16-19-pve (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) Versions of packages postfix-mysql depends on: ii libc62.36-9+deb12u4 ii libmariadb3 1:10.11.6-0+deb12u1 ii postfix 3.7.10-0+deb12u1 postfix-mysql recommends no packages. postfix-mysql suggests no packages. -- no debconf information
Bug#1022043: Info received (improved patch)
Try again - without the old patch at the top.diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..c53feb1 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,19 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+
+ lockuniq g{inProgressLock};
+
+ if (inProgress.contains(m_sFileLoc)) {
+// Check if another job is running. If so link to that.
+m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+USRDBG("Linked to other job");
+return;
+}
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@ -697,8 +710,13 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
if(cfg::trackfileuse && fistate >= fileitem::FIST_DLGOTHEAD && fistate < fileitem::FIST_DLERROR)
m_pItem.get()->UpdateHeadTimestamp();
- if(fistate==fileitem::FIST_COMPLETE)
+ if(fistate==fileitem::FIST_COMPLETE) {
+ // Tell everybody downloading this url that we already
+ // have a job to download it and register a cleanup
+ // when this job completes.
+ setInProgress(m_sFileLoc);
return; // perfect, done here
+ }
if(cfg::offlinemode) { // make sure there will be no problems later in SendData or prepare a user message
// error or needs download but freshness check was disabled, so it's really not complete.
@@ -760,6 +778,10 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
return report_overload(__LINE__);
}
}
+ // Tell everybody downloading this url that we already have a
+ // job to download it and register a cleanup when this job
+ // completes.
+ setInProgress(m_sFileLoc);
}
catch (const std::bad_alloc&) // OOM, may this ever happen here?
{
@@ -1190,4 +1212,16 @@ void job::AppendMetaHeaders()
<< "\r\nServer: Debian Apt-Cacher NG/" ACVERSION "\r\n"
"\r\n";
}
+
+job::inProgressCleanup::~inProgressCleanup() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ USRDBG("url=" << url);
+ if (url.size()) {
+ inProgress.erase(url);
+ }
+}
+
+std::set job::inProgress;
+base_with_mutex job::inProgressLock;
}
diff --git a/src/job.h b/src/job.h
index cb162a6..c79459b 100644
--- a/src/job.h
+++ b/src/job.h
@@ -16,6 +16,24 @@ class header;
class job
{
+private:
+ // Lock controlling access to inProgress
+ static base_with_mutex inProgressLock;
+
+ // If there is an item in here then there is already a job downloading url
+ static std::set inProgress;
+
+ // Simple class which is destroyed when the job is destroyed. It deletes the entry from inProgress.
+ struct inProgressCleanup {
+ std::string url;
+ inProgressCleanup() { }
+ ~inProgressCleanup();
+ };
+
+ void setInProgress(const std::string& url_) {
+ m_ipc.url = url_;
+ inProgress.insert(url_);
+ }
public:
enum eJobResult : short
@@ -48,6 +66,7 @@ public:
} eActivity;
TFileItemHolder m_pItem;
+ inProgressCleanup m_ipc; // This MUST be destroyed before m_pItem
unique_fd m_filefd;
bool m_bIsHttp11 = true;
Bug#1022043: improved patch
I've cleaned up the patch and got rid of a lot of the cruft that got
added while I was debugging.
Also found one more race condition in my original solution that I
believe is now fixed.
And I believe it's now safe even if different urls map to the same cache
file which the previous patch didn't get right.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..c53feb1 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,19 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+
+ lockuniq g{inProgressLock};
+
+ if (inProgress.contains(m_sFileLoc)) {
+// Check if another job is running. If so link to that.
+m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+USRDBG("Linked to other job");
+return;
+}
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@ -697,8 +710,13 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
if(cfg::trackfileuse && fistate >= fileitem::FIST_DLGOTHEAD && fistate < fileitem::FIST_DLERROR)
m_pItem.get()->UpdateHeadTimestamp();
- if(fistate==fileitem::FIST_COMPLETE)
+ if(fistate==fileitem::FIST_COMPLETE) {
+ // Tell everybody downloading this url that we already
+ // have a job to download it and register a cleanup
+ // when this job completes.
+ setInProgress(m_sFileLoc);
return; // perfect, done here
+ }
if(cfg::offlinemode) { // make sure there will be no problems later in SendData or prepare a user message
// error or needs download but freshness check was disabled, so it's really not complete.
@@ -760,6 +778,10 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
return report_overload(__LINE__);
}
}
+ // Tell everybody downloading this url that we already have a
+ // job to download it and register a cleanup when this job
+ // completes.
+ setInProgress(m_sFileLoc);
}
catch (const std::bad_alloc&) // OOM, may this ever happen here?
{
@@ -1190,4 +1212,16 @@ void job::AppendMetaHeaders()
<< "\r\nServer: Debian Apt-Cacher NG/" ACVERSION "\r\n"
"\r\n";
}
+
+job::inProgressCleanup::~inProgressCleanup() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ USRDBG("url=" << url);
+ if (url.size()) {
+ inProgress.erase(url);
+ }
+}
+
+std::set job::inProgress;
+base_with_mutex job::inProgressLock;
}
diff --git a/src/job.h b/src/job.h
index cb162a6..b4df3de 100644
--- a/src/job.h
+++ b/src/job.h
@@ -16,6 +16,26 @@ class header;
class job
{
+private:
+ // Lock controlling access to inProgress
+ static base_with_mutex inProgressLock;
+
+ // If there is an item in here then there is already a job downloading url
+ static std::set inProgress;
+
+ // Simple class which is destroyed when the job is destroyed. It deletes the entry from inProgress.
+ struct inProgressCleanup {
+ std::string url;
+ inProgressCleanup() { }
+ ~inProgressCleanup();
+ };
+
+ void setInProgress(const std::string& url_) {
+ m_ipc.url = url_;
+ inProgress.insert(url_);
+ }
+
+ inProgressCleanup m_ipc;
public:
enum eJobResult : short
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..c53feb1 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,19 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+
+ lockuniq g{inProgressLock};
+
+ if (inProgress.contains(m_sFileLoc)) {
+// Check if another job is running. If so link to that.
+m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+USRDBG("Linked to other job");
+return;
+}
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@
Bug#1022043: Race condition downloading index files.
I've managed to reproduce this issue when many hosts hit apt-cacher-ng
at the same time.
Attached a patch which fixes it for me - this is a quick and hacky
patch!
Sent debug logs of a run that reproduces this problem and a run with
this patch applied directly to the maintainer.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..5c003a9 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,18 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+ Lockstuff g{h.getRequestUrl()};
+
+ // Check if another job is running. If so link to that.
+ if(g.stuff->otherThread) {
+ m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+ USRDBG("Linked to other job");
+ return;
+ }
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@ -697,8 +709,14 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
if(cfg::trackfileuse && fistate >= fileitem::FIST_DLGOTHEAD && fistate < fileitem::FIST_DLERROR)
m_pItem.get()->UpdateHeadTimestamp();
- if(fistate==fileitem::FIST_COMPLETE)
+ if(fistate==fileitem::FIST_COMPLETE) {
+ // Tell everybody waiting for this thread to complete
+ // where to get their m_pItem and register a cleanup
+ // when this job completes.
+ g.setReturnValue(m_pItem.get());
+ m_ipc = std::make_unique(h.getRequestUrl());
return; // perfect, done here
+ }
if(cfg::offlinemode) { // make sure there will be no problems later in SendData or prepare a user message
// error or needs download but freshness check was disabled, so it's really not complete.
@@ -759,6 +777,11 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
USRERR("PANIC! Error creating download job for " << m_sFileLoc);
return report_overload(__LINE__);
}
+ // Tell everybody waiting for this thread to complete
+ // where to get their m_pItem and register a cleanup
+ // when this job completes.
+ g.setReturnValue(m_pItem.get());
+ m_ipc = std::make_unique(h.getRequestUrl());
}
}
catch (const std::bad_alloc&) // OOM, may this ever happen here?
@@ -1190,4 +1213,58 @@ void job::AppendMetaHeaders()
<< "\r\nServer: Debian Apt-Cacher NG/" ACVERSION "\r\n"
"\r\n";
}
+
+job::Lockstuff::Lockstuff(const std::string& url_): url(url_) {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ while(true) {
+ auto [it, ins] = inProgress.insert({url, nullptr});
+ if(!ins) {
+ stuff = it->second;
+ if (stuff->otherThread) {
+break;
+ }
+ // Someone is already downloading this. Add ourselves to the waiters.
+ stuff->cv.wait(g._guard);
+ } else {
+ stuff = it->second = std::make_shared();
+ owner = true;
+ break;
+ }
+ }
+}
+
+void job::Lockstuff::setReturnValue(tFileItemPtr tfip) {
+ LOGSTARTFUNC;
+ if (const auto& it = inProgress.find(url); it != inProgress.end()) {
+ stuff->otherThread = tfip;
+ }
+}
+
+job::Lockstuff::~Lockstuff() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ if(owner) {
+ stuff->cv.notify_all();
+ // After notify_all, any waiting threads are guaranteed to
+ // be blocked on inProgressLock, not on the condition so
+ // it's safe to delete it. However we have to use shared
+ // pointers because we don't know how long it will take the
+ // waiters to read the tFileItemPtr;
+ if (!stuff->otherThread) {
+ inProgress.erase(url);
+ }
+ }
+}
+
+job::inProgressCleanup::~inProgressCleanup() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ if (const auto& it = inProgress.find(url); it != inProgress.end()) {
+ inProgress.erase(it);
+ }
+}
+
+std::map> job::inProgress;
+base_with_mutex job::inProgressLock;
}
diff --git a/src/job.h b/src/job.h
index cb162a6..97446e2 100644
--- a/src/job.h
+++ b/src/job.h
@@ -16,6 +16,39 @@ class header;
class job
{
+private:
+ // Lock controlling access to inProgress
+ static base_with_mutex inProgressLock;
+
+ // The data that we store in inProgress
+ struct Stuff {
+ std::condition_variable cv;
+ tFileItemPtr otherThread = 0;
+ };
+
+ // Map from URL to Stuff for in progress jobs that are requesting this file.
+ // The entry is "owned" by the job that added it and it is deleted when the job completes.
+ static std::map> inProgress;
+
+ // Where all the real work is done.
+ struct Lockstuff {
+ const std::string
Bug#887139: d-i daily 2018-01-14 amd64 damages UEFI setup on Fujitsu Lifebook AH532
On Sun, 14 Jan 2018 13:38:11 +0100 Karsten Merker wrote: Machine: Fujitsu Lifebook AH532, first version (with BIOS version 1.09) [...] How can one bring the NVRAM back into a sane state that allows getting into the setup and booting from external devices? I personally had luck with doing a CMOS-reset (shorting the CL1_CL2 test point under the RAM slot while the machine is powered on is easier than uncovering the actual battery) to restore the device-based options in the boot menu, and then using the Fujitsu-provided BIOS flash utilities [1] (via a bootable FreeDOS USB) to restore the BIOS Setup option. If you are feeling adventurous (or the CMOS-reset-and-BIOS-update option does not work), you may want to try the small program I have written [2] (which is supposed to restore all relevant entries from within a running Linux system) instead. Please do note the disclaimer and supported configurations though. [1] https://support.ts.fujitsu.com/ [2] https://github.com/timschumi/ah532-biostools/
Bug#1059339: nv-codec-headers: Version mismatch with nvidia-driver package
Source: nv-codec-headers Version: 12.1.14.0-1 Severity: important Dear Maintainer, After I updated FFmpeg to version 7:6.1-5 hardware accelerated encoding via h264_nvenc stopped working. FFmpeg reports: Driver does not support the required nvenc API version. Required: 12.1 Found: 12.0 [1] states that the minimum required nvidia driver version to support nvenc 12.1 is 530.41.03 or higher. Yet the most recent version available in trixie is currently 525.147.05-1. I managed to compile FFmpeg against an older version (12.0.16.1) of the headers which fixed the bug for me. Please note that my graphics card is quite old (NVIDIA Corporation GM206 [GeForce GTX 960]), so I'm not sure if this bug affects people with more up to date cards. ~ Tim [1]: https://docs.nvidia.com/video-technologies/video-codec-sdk/12.1/read-me/index.html -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.68-1 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init)
Bug#995838: Should condor be removed?
Hello Bastian, I am working with Andeas Tilles to get this back into Debian. I have a small amount of work to complete on the debian/copyright file before it is ready to upload. I worked on this aspect this afternoon and I will complete the changes quite soon. ...Tim On 12/19/23 14:19, Bastian Germann wrote: Hi Tim, I have checked the git repo and found the work-in-progress v23.0.0+dfsg-1 to build fine. Maybe we should get it into Debian so that the pile of bugs that have accumulated can be resolved. I am happy to sponsor the update if Michael Hanke is not available. Cheers, Bastian On Tue, 1 Aug 2023 17:15:52 +0200 Bastian Germann wrote: Hi Tim, I see you imported 10.3 into Debian. Please let me know if I can help you. Thanks, Bastian On Fri, 2 Dec 2022 09:03:27 -0600 Tim Theisen wrote: > Hello Bastian, > > I am working on this. > > Twice I had everything building and ready for upload and then something > changed on sid. > > First change, moving to openssl 3 caused condor to FTBFS. > > Then migration to cgroups v2 caused condor to FTBFS. > > Right now I have it building. However, some change is causing the > install step to not place files in the proper directories. Perhaps, > something to do with usrmerge or some change in the build tools. Still > working on that one. > > ...Tim > > On 11/30/22 11:05, Bastian Germann wrote: > > X-Debbugs-Cc: andr...@an3as.eu > > > > Any news on condor? Upstream has released the announced version but > > the Debian package has only advanced in git. -- Tim Theisen (he, him, his) Release Manager HTCondor & Open Science Grid Center for High Throughput Computing Department of Computer Sciences University of Wisconsin - Madison 4261 Computer Sciences and Statistics 1210 W Dayton St Madison, WI 53706-1685 +1 608 265 5736
Bug#1057843: Guidelines for affected users
Meanwhile, can the ftp admins pull this faulty version? I just managed to download and install this, but fortunately didn't reboot on all of my systems before coming across this bug via LWN via reddit. If you're in such a pickle as myself, you're able to get around it for now by: apt install linux-image-amd64/bookworm-security dpkg --get-selections | grep 6.1.0.14 apt purge linux-image-6.1.0-14-amd64 (probably want to mark that one as uninstallable too, but there's only one of me, surely I'll remember not to install it at a later date??!) and at worst you'll be left on the kernel you're currently running. I am basing this off https://lwn.net/Articles/954285/ "- Stable kernels < 6.5 are affected if they have 91562895f803 (ext4 commit) - Kernels >= 6.5 are not affected, as they will _also_ have 936e114a245b6 (iomap commit)" 91562895f803 is not in 6.1.55-1 that anyone who last updated 3 weeks ago would have encountered, nor in the current bookworm-security version. -- Tim Connors
Bug#1053199: liferea does not show feed item contents after 1.15.2-1->1.15.3-1 update
Hi. Same error here. $ liferea eglExportDMABUFImageMESA failed eglExportDMABUFImageMESA failed eglExportDMABUFImageMESA failed sys:1: Warning: g_atomic_ref_count_dec: assertion 'old_value > 0' failed sys:1: Warning: g_uri_is_valid: assertion 'uri_string != NULL' failed I'm also using the nvidia proprietary driver (525.125.06-2). Window manager is Fluxbox. Downgrading liferea to the previous version doesn't fix the error though. I also tested downgrading all libwebkit2gtk related packages to version 2.40.5-1. After that the content window works again. ~Tim
Bug#1030129: ca-certificates-java - Fails to install: Error loading java.security file
I haven't been able to reproduce this on a Debian 12 container. For those that are still seeing this problem, is it always reproducible? If there is a race, is there a way to force this (e.g. via apt settings or manual package install ordering with dpkg etc.)? Thanks, Tim.
Bug#1052990: libc6: snprintf counts unwritten bytes in %n
Package: libc6
Version: 2.36-9+deb12u1
Severity: normal
X-Debbugs-Cc: tim.ba...@hitachivantara.com
Dear Maintainer,
Consider this test case:
#include
int main(void) {
char buf[3];
int n;
snprintf(buf, sizeof buf, "%s%n", "foobar", );
printf("%d\n", n);
}
I believe it ought, as specified, to output "2"; glibc prints "6". The
difference is in whether %n keeps counting when snprintf has no room for
more output.
I quote below from a C23 draft[1] but the salient points are essentially
unchanged since C99. The wording in POSIX[2] is also equivalent, and no
relevant parts are flagged as deliberate deviations from the C standard.
[1]
[2]
The %n conversion specifier is defined under fprintf (7.23.6.1/8 in the
abovementioned draft):
The number of characters written to the output stream so far by this
call to fprintf is stored into the integer object pointed to by the
argument.
For snprintf we then have (7.23.6.5/2):
The snprintf function is equivalent to fprintf, except that the
output is written into an array (specified by argument s) rather
than to a stream. If n is zero, nothing is written, and s may be
a null pointer. Otherwise, output characters beyond the n-1st are
discarded rather than being written to the array,
Assuming the text accurately reflects WG14's intent, the only consistent
interpretation here, it seems to me, is that: "nothing is written" or
"discarded rather than being written" implies not "written to the output
[array]". Therefore any bytes discarded ought not to be counted in the
value assigned by %n. It follows that that value should never exceed the
buffer length, and should be strictly less unless the latter is 0.
(Internally, glibc may implement snprintf by output to an in-memory
stream, as if using fmemopen, but that is purely an implementation
detail. It is not how C/POSIX define snprintf.)
The same obviously applies identically to vsnprintf; and similarly to
[v]swprintf, although the wording (7.31.2.3/2) is slightly different.
A related question also arises when output to a stream suffers an error.
In the event of an output error, glibc continues processing the format
string, correctly since fprintf "returns when the end of the format
string is encountered" (7.23.6.1/2); but what should %n do in that case?
It is much less clear whether "written" ought to be interpreted as
"successfully written". For example:
FILE *f = fopen("/dev/full", "w");
setbuf(f, 0);
fprintf(f, "%d%n", 12345, );
Should %n assign 5, or 0? There is no such difficulty of interpretation
with snprintf etc., as the text is clear that the excess characters are
not written at all.
-- System Information:
Debian Release: 12.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-10-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libc6 depends on:
ii libgcc-s1 12.2.0-14
Versions of packages libc6 recommends:
ii libidn2-0 2.3.3-1+b1
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.82
pn glibc-doc
ii libc-l10n 2.36-9+deb12u1
pn libnss-nis
pn libnss-nisplus
ii locales2.36-9+deb12u1
-- debconf information:
glibc/upgrade: true
glibc/kernel-too-old:
glibc/kernel-not-supported:
glibc/restart-failed:
glibc/disable-screensaver:
libraries/restart-without-asking: false
glibc/restart-services:
Bug#1052120: mirror submission for mirror.timkevin.us
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.timkevin.us Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x Archive-http: /debian/ Maintainer: Tim Kevin Country: US United States Location: San Jose, CA Comment: https://mirror.timkevin.us/debian http://mirror.timkevin.us/debian Trace Url: http://mirror.timkevin.us/debian/project/trace/ Trace Url: http://mirror.timkevin.us/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.timkevin.us/debian/project/trace/mirror.timkevin.us
Bug#912171: pcsxr: Cannot configure/use 2nd joypad
Package: pcsxr Version: 1.9.94-5 Followup-For: Bug #912171 X-Debbugs-Cc: t...@buttersideup.com I should add that in my tests (bookworm and bullseye on 3 different x86_64 machines), this bug makes pcsxr segfault when entering the configuration UI, or launching a game immediately if any joystick / joypad is connected to the system. For this reason, perhaps this bug should be upgraded to "important" severity. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 6.1.0-11-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pcsxr depends on: ii libc62.36-9+deb12u1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgl1 1.6.0-1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.37-2 ii libpango-1.0-0 1.50.12+ds-1 ii libsdl2-2.0-02.26.5+dfsg-1 ii libx11-6 2:1.8.4-2+deb12u1 ii libxext6 2:1.3.4-1+b1 ii libxtst6 2:1.2.3-1.1 ii libxv1 2:1.0.11-1.1 ii libxxf86vm1 1:1.1.4-1+b2 ii zlib1g 1:1.2.13.dfsg-1 pcsxr recommends no packages. pcsxr suggests no packages. -- no debconf information
Bug#912171: pcsxr: Cannot configure/use 2nd joypad
Package: pcsxr
Version: 1.9.94-5
Followup-For: Bug #912171
X-Debbugs-Cc: t...@buttersideup.com
This bug is still present. I independently found it, and can confirm that the
previous fix should work.
An alternative fix is to call SDL_JoystickNameForIndex()
The patch below lacks a guarding ifdef (for SDL1 users), but I doubt
anyone is using SDL1 these days (SDL2 being just a little under 10 years
old at time of writing).
--- pcsxr-1.9.94.orig/plugins/dfinput/cfg-gtk.c
+++ pcsxr-1.9.94/plugins/dfinput/cfg-gtk.c
@@ -607,7 +607,7 @@ static void PopulateDevList() {
n = SDL_NumJoysticks();
for (j = 0; j < n; j++) {
- sprintf(buf, "%d: %s", j + 1, SDL_JoystickName(j));
+ sprintf(buf, "%d: %s", j + 1,
SDL_JoystickNameForIndex(j));
gtk_list_store_append(store, );
gtk_list_store_set(store, , 0, buf, -1);
}
It would be super-cool if we could get one of these patches merged...
Thanks!
Tim.
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 6.1.0-11-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pcsxr depends on:
ii libc62.36-9+deb12u1
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libgl1 1.6.0-1
ii libglib2.0-0 2.74.6-2
ii libgtk-3-0 3.24.37-2
ii libpango-1.0-0 1.50.12+ds-1
ii libsdl2-2.0-02.26.5+dfsg-1
ii libx11-6 2:1.8.4-2+deb12u1
ii libxext6 2:1.3.4-1+b1
ii libxtst6 2:1.2.3-1.1
ii libxv1 2:1.0.11-1.1
ii libxxf86vm1 1:1.1.4-1+b2
ii zlib1g 1:1.2.13.dfsg-1
pcsxr recommends no packages.
pcsxr suggests no packages.
-- no debconf information
Bug#1037359: opensmtpd workaround
Hi, this bug indeed makes opensmtpd completely unusable for me (who sends mails unencrypted in the current year?). As a temporary workaround for my setup I have re-added the bullseye repo in sources.list, installed opensmtpd=6.8.0p2-3, and set it on hold (echo "opensmtpd hold" | sudo dpkg --set-selections). Regarding a permanent fix: I think normally major version upgrades don't happen within a Debian stable release. Although considering that opensmtpd in its current state is basically unusable I personally don't think the usual concerns around major version upgrades apply.
Bug#1041542: uuid: Memory unsafety for version 1 UUID with out-of-range timestamp
Package: uuid Version: 1.6.2-1.5+b11 Severity: normal Dear Maintainer, * What led up to the situation? I ran `uuid -d --1100-a000-` and noticed that the time content was strangely formatted with a dot where a digit should be: encode: STR: --1100-a000- SIV: 80291759423830037102592 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 1 (time and node based) content: time: 60266-07-14 05:26:.747955.2 UTC clock: 8192 (usually random) node: 00:00:00:00:00:00 (global unicast) * What exactly did you do (or not do) that was effective (or ineffective)? Suspecting memory unsafety, I reran the command in `valgrind` as valgrind uuid -d --1100-a000- * What was the outcome of this action? This showed a number of "use of uninitialized value" errors: ==6046== Memcheck, a memory error detector ==6046== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==6046== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==6046== Command: uuid -d --1100-a000- ==6046== ==6046== Conditional jump or move depends on uninitialised value(s) ==6046==at 0x4846798: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==6046==by 0x485D47A: uuid_str_vsnprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x485DDE5: uuid_str_vrsprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x485DF03: uuid_str_rsprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x48582AA: uuid_export (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x1098DE: ??? (in /usr/bin/uuid) ==6046==by 0x4889189: (below main) (libc_start_call_main.h:58) ==6046== ==6046== Conditional jump or move depends on uninitialised value(s) ==6046==at 0x485D509: uuid_str_vsnprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x485DDE5: uuid_str_vrsprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x485DF03: uuid_str_rsprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x48582AA: uuid_export (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x1098DE: ??? (in /usr/bin/uuid) ==6046==by 0x4889189: (below main) (libc_start_call_main.h:58) ==6046== ==6046== Conditional jump or move depends on uninitialised value(s) ==6046==at 0x4846798: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==6046==by 0x485D47A: uuid_str_vsnprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x485DE15: uuid_str_vrsprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x485DF03: uuid_str_rsprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x48582AA: uuid_export (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x1098DE: ??? (in /usr/bin/uuid) ==6046==by 0x4889189: (below main) (libc_start_call_main.h:58) ==6046== ==6046== Conditional jump or move depends on uninitialised value(s) ==6046==at 0x485D509: uuid_str_vsnprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x485DE15: uuid_str_vrsprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x485DF03: uuid_str_rsprintf (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x48582AA: uuid_export (in /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16.0.22) ==6046==by 0x1098DE: ??? (in /usr/bin/uuid) ==6046==by 0x4889189: (below main) (libc_start_call_main.h:58) ==6046== encode: STR: --1100-a000- SIV: 80291759423830037102592 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 1 (time and node based) content: time: 60266-07-14 05:26:.747955.2 UTC clock: 8192 (usually random) node: 00:00:00:00:00:00 (global unicast) ==6046== ==6046== HEAP SUMMARY: ==6046== in use at exit: 0 bytes in 0 blocks ==6046== total heap usage: 18 allocs, 18 frees, 10,431 bytes allocated ==6046== ==6046== All heap blocks were freed -- no leaks are possible ==6046== ==6046== Use --track-origins=yes to see where uninitialised values come from ==6046== For lists of detected and suppressed errors, rerun with: -s ==6046== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0) * What outcome did you expect instead? I did not expect any use of uninitialized values, even for malformatted / strange / out of range UUIDs. Instead the UUID should either be correctly handled or an error message
Bug#1041480: python3-h5py: I can't use the debian provided python3-h5py as a dependency in my package because it is called h5py.-debian-h5py-serial
Package: python3-h5py Version: 3.7.0-8 Severity: important X-Debbugs-Cc: t...@molteno.net Dear Maintainer, I am developing a package that depends on h5py. It is predominantly used on raspberry pi, and other single board computers. When I specify 'h5py' as a dependency, it does not pick up the system installed version. I think this is because it is named 'h5py.-debian-h5py-serial'. This causes huge problems because the attempt to build takes more than an hour and then fails on an rPi3. How should packages that wish to the debian python3-h5py as a dependency specify this. -- System Information: Debian Release: 12.0 APT prefers stable APT policy: (990, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-h5py depends on: ii python3-h5py-serial 3.7.0-8 python3-h5py recommends no packages. Versions of packages python3-h5py suggests: pn python-h5py-doc -- no debconf information
Bug#1040907: aerc: Freeze when pasting to body on email compose
On Fri Jul 14, 2023 at 1:35 PM CDT, Nilesh Patra wrote: > On Fri, Jul 14, 2023 at 08:13:16PM +0200, Robin Jarry wrote: > > Nilesh Patra, Jul 14, 2023 at 19:59: > > > There you go > > > > > > https://pb.envs.net/?816fb8c61575e2ba#4kD2xS4wJMGrsCd8tBhPfqHDJZ7qeM6qERaobgoYj46F > > > > Thanks a lot that helps. It looks like there is a deadlock due to two > > goroutines trying to interact with the terminal: > > I'm going ahead with an upload in debian with this patch backported. > From a distro pov I consider this a major breakeage. Given that aerc is > designed to facilitate patch workflow as a goal, it makes it useless if > I can't paste more than 4-5 lines in one go. I agree, this was a particularly bad breakage on this release. I think backporting this patch is a must. Thanks for backporting! -- Tim
Bug#1040907: aerc: Freeze when pasting to body on email compose
On Fri Jul 14, 2023 at 12:14 PM CDT, Nilesh Patra wrote: > On Fri, Jul 14, 2023 at 11:19:32AM -0500, Tim Culverhouse wrote: > > I also can't repro. I tried pasting "hello world\n"x100, and "hello > > world"x100 > > (all on the same line), both in vim and nvim, and in foot and wezterm - all > > of > > those combinations work. > > I tried with qterminal, kitty and deepin-terminal and I could repro it in > all the three. I really doubt if it is specific to terminal. > > And... I tried with wezterm. It worked on first try, but on trying to > paste the text 2-3 times in a row (on the same compose area) I'm able to > see a hang. Are you in insert mode when pasting? > Are you using debian though? No, I'm on Arch (btw). -- Tim
Bug#1040907: aerc: Freeze when pasting to body on email compose
On Fri Jul 14, 2023 at 11:36 AM CDT, Robin Jarry wrote: > pelle, Jul 14, 2023 at 18:23: > > > Robin and I are both on wayland...I'm guessing with xclip you are on > > > X? I wonder if that comes into play at all? > > > > I'm having the issue in Sway. I've noticed that the freeze happens in > > vim when pasting with `CTRL+V` or `SHIFT+INSERT` while pasting works > > fine with `p`. > > I assume that you enter insert mode before pasting with `CTRL+V` or > `SHIFT+INSERT`. Tim, could it be a race with tcell term? Could be...sounds like a race somewhere. I've tested tcell-term up and down with --race and can't find any races. -- Tim
Bug#1040907: aerc: Freeze when pasting to body on email compose
On Fri Jul 14, 2023 at 11:06 AM CDT, Nilesh Patra wrote:
> On Fri, Jul 14, 2023 at 05:49:41PM +0200, Robin Jarry wrote:
> > I cannot reproduce this but maybe Tim can have a look.
>
> This is an upstream bug, and I can repro it by building aerc via make,
> i.e. there are no debian go packages at play here.
>
> Interestingly, this bug does not get triggered when I use micro as my
> editor (a golang based text editor).
>
> Here's the way I could reproduce:
>
> $ for in in {0..100}; do echo 'hello world' >> /tmp/hwl; done
> $ cat /tmp/hwl | xclip -sel clipboard
> $ EDITOR=vim ./aerc
>
> :compose
>
> Goto the body and try paste using ctrl+shift+v or shift+Ins (whatever
> bindings are default for your terminal). You'll see it hanging --
> sometimes with half-pasted text.
>
> I get the same result when I try with EDITOR=nano.
>
> Best,
> Nilesh
I also can't repro. I tried pasting "hello world\n"x100, and "hello world"x100
(all on the same line), both in vim and nvim, and in foot and wezterm - all of
those combinations work.
Robin and I are both on wayland...I'm guessing with xclip you are on X? I wonder
if that comes into play at all?
--
Tim
Bug#1040716: libc6: Stack Traces
On Tue, 2023-07-11 at 22:34 +0200, Aurelien Jarno wrote: > Hi, > > On 2023-07-11 15:28, Tim McConnell wrote: > > > > > > On Tue, 2023-07-11 at 21:11 +0200, Aurelien Jarno wrote: > > > Hi, > > > > > > On 2023-07-11 11:21, Tim McConnell wrote: > > > > > > > > > > > > On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote: > > > > > You might want > > > > > to upgrade to version 2.37-5 to check if it solves your issue > > > > Okay that's done and it's still doing it. The entry from > > > > Journalctl > > > > shows module libudev1 if that's of any use. > > > > > > > > Started systemd-coredump@1785-616863-0.service - Process Core > > > > Dump > > > > (PID > > > > 616863/UID 0). > > > > Jul 11 10:52:06 DebianTim systemd-coredump[616865]: Process > > > > 616847 > > > > (collectd) of user 0 dumped core. > > > > > > > > Module > > > > libudev.so.1 > > > > from deb systemd-252.11-1.amd64 > > > > Stack trace > > > > of > > > > thread 616848: > > > > #0 > > > > 0x7fce1335e9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2) > > > > #1 > > > > 0x7fce131156d9 rrd_write (librrd.so.8 + 0x346d9) > > > > #2 > > > > 0x7fce13120acd n/a (librrd.so.8 + 0x3facd) > > > > #3 > > > > 0x7fce13122962 n/a (librrd.so.8 + 0x41962) > > > > #4 > > > > 0x7fce1317c370 n/a (rrdtool.so + 0x3370) > > > > #5 > > > > 0x7fce132793ec start_thread (libc.so.6 + 0x883ec) > > > > #6 > > > > 0x7fce132f9a1c __clone3 (libc.so.6 + 0x108a1c) > > > > > > > > > > Thanks for the details. This shows that the binary crashing > > > regularly > > > is > > > collectd. This is very unlikely that the issue is linked to the > > > locales, > > > and your test is confirming that. > > > > > > It's also not clear that it's a glibc issue, it's more likely an > > > issue > > > in collectd or librrd8. It appears that systemd-coredump saved a > > > coredump when the process crashed. You should be able do use > > > "coredumpctl" to get the list of cores. You can select one > > > coredump > > > and > > > examine it with gdb using "coredumpctl debug ". Then when > > > under > > > gdb > > > you should be able to run "thread apply all bt" to get the > > > backtrace. > > > That should allows to better understand the issue. > > > > > > Regards > > > Aurelien > > > > > I'm unsure how helpful this is ( I am not a programmer) but: > > thread apply all bt > > Thanks, that's already much more useful. However I forgot to tell you > to > install the libc6-dbg package before getting the backtrace, sorry > about > that. Could you please install it and follow the same procedure > again? > > Thanks > Aurelien > It's already there, any others?
Bug#1040716: libc6: Stack Traces
On Tue, 2023-07-11 at 21:11 +0200, Aurelien Jarno wrote: > Hi, > > On 2023-07-11 11:21, Tim McConnell wrote: > > > > > > On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote: > > > You might want > > > to upgrade to version 2.37-5 to check if it solves your issue > > Okay that's done and it's still doing it. The entry from Journalctl > > shows module libudev1 if that's of any use. > > > > Started systemd-coredump@1785-616863-0.service - Process Core Dump > > (PID > > 616863/UID 0). > > Jul 11 10:52:06 DebianTim systemd-coredump[616865]: Process 616847 > > (collectd) of user 0 dumped core. > > > > Module > > libudev.so.1 > > from deb systemd-252.11-1.amd64 > > Stack trace of > > thread 616848: > > #0 > > 0x7fce1335e9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2) > > #1 > > 0x7fce131156d9 rrd_write (librrd.so.8 + 0x346d9) > > #2 > > 0x7fce13120acd n/a (librrd.so.8 + 0x3facd) > > #3 > > 0x7fce13122962 n/a (librrd.so.8 + 0x41962) > > #4 > > 0x7fce1317c370 n/a (rrdtool.so + 0x3370) > > #5 > > 0x7fce132793ec start_thread (libc.so.6 + 0x883ec) > > #6 > > 0x7fce132f9a1c __clone3 (libc.so.6 + 0x108a1c) > > > > Thanks for the details. This shows that the binary crashing regularly > is > collectd. This is very unlikely that the issue is linked to the > locales, > and your test is confirming that. > > It's also not clear that it's a glibc issue, it's more likely an > issue > in collectd or librrd8. It appears that systemd-coredump saved a > coredump when the process crashed. You should be able do use > "coredumpctl" to get the list of cores. You can select one coredump > and > examine it with gdb using "coredumpctl debug ". Then when under > gdb > you should be able to run "thread apply all bt" to get the backtrace. > That should allows to better understand the issue. > > Regards > Aurelien > I'm unsure how helpful this is ( I am not a programmer) but: thread apply all bt Thread 12 (Thread 0x7fae021f96c0 (LWP 9783)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7fae021f8e60, op=393, expected=0, futex_word=0x556c7b80d488) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae021f8e60, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex- internal.c:87 #2 0x7fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae021f8e60, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x7fae08a3dafc in __pthread_cond_wait_common (abstime=0x7fae021f8e60, clockid=0, mutex=0x556c7b80d4a0, cond=0x556c7b80d460) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_timedwait64 (cond=0x556c7b80d460, mutex=0x556c7b80d4a0, abstime=0x7fae021f8e60) at ./nptl/pthread_cond_wait.c:643 #5 0x556c7b7e83a2 in () #6 0x7fae08a3e3ec in start_thread (arg=) at ./nptl/pthread_create.c:444 #7 0x7fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 11 (Thread 0x7fae08c1a740 (LWP 9776)): #0 0x7fae08a84a25 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7fff754277f0, rem=0x7fff754277f0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48 #1 0x7fae08a893f3 in __GI___nanosleep (req=, rem=) at ../sysdeps/unix/sysv/linux/nanosleep.c:25 #2 0x556c7b7de16b in () #3 0x556c7b7de7a8 in run_loop () #4 0x556c7b7dd934 in main () Thread 10 (Thread 0x7fae041fd6c0 (LWP 9779)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x556c7b80d3e8) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d3e8, expected=expected@entry=0, clockid=clockid@entry=0, abst--Type for more, q to quit, c to continue without paging-- ime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex-internal.c:87 #2 0x7fae08a
Bug#1040716: libc6: Stack Traces
On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote: > You might want > to upgrade to version 2.37-5 to check if it solves your issue Okay that's done and it's still doing it. The entry from Journalctl shows module libudev1 if that's of any use. Started systemd-coredump@1785-616863-0.service - Process Core Dump (PID 616863/UID 0). Jul 11 10:52:06 DebianTim systemd-coredump[616865]: Process 616847 (collectd) of user 0 dumped core. Module libudev.so.1 from deb systemd-252.11-1.amd64 Stack trace of thread 616848: #0 0x7fce1335e9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2) #1 0x7fce131156d9 rrd_write (librrd.so.8 + 0x346d9) #2 0x7fce13120acd n/a (librrd.so.8 + 0x3facd) #3 0x7fce13122962 n/a (librrd.so.8 + 0x41962) #4 0x7fce1317c370 n/a (rrdtool.so + 0x3370) #5 0x7fce132793ec start_thread (libc.so.6 + 0x883ec) #6 0x7fce132f9a1c __clone3 (libc.so.6 + 0x108a1c) Stack trace of thread 616847: #0 0x7fce132bfa25 __GI___clock_nanosleep (libc.so.6 + 0xcea25) #1 0x7fce132c43f3 __GI___nanosleep (libc.so.6 + 0xd33f3) #2 0x55ade3cad16b n/a (collectd + 0x816b) #3 0x55ade3cad7a8 run_loop (collectd + 0x87a8) #4 0x55ade3cac934 main (collectd + 0x7934) #5 0x7fce132186ca __libc_start_call_main (libc.so.6 + 0x276ca) #6 0x7fce13218785 __libc_start_main_impl (libc.so.6 + 0x27785) #7 0x55ade3cace21 _start (collectd + 0x7e21) Stack trace of thread 616849: #0 0x7fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7fce13278818 __pthread_cond_wait_common (libc.so.6 + 0x87818) #2 0x55ade3cb5d1b n/a (collectd + 0x10d1b) #3 0x7fce132793ec start_thread (libc.so.6 + 0x883ec) #4 0x7fce132f9a1c __clone3 (libc.so.6 + 0x108a1c) Stack trace of thread 616850: #0 0x7fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7fce13278818 __pthread_cond_wait_common (libc.so.6 + 0x87818) #2 0x55ade3cb5d1b n/a (collectd + 0x10d1b) #3 0x7fce132793ec start_thread (libc.so.6 + 0x883ec) #4 0x7fce132f9a1c __clone3 (libc.so.6 + 0x108a1c) Stack trace of thread 616851: #0 0x7fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7fce13278818 __pthread_cond_wait_common (libc.so.6 + 0x87818) #2 0x55ade3cb5d1b n/a (collectd + 0x10d1b) #3 0x7fce132793ec start_thread (libc.so.6 + 0x883ec) #4 0x7fce132f9a1c __clone3 (libc.so.6 + 0x108a1c) Stack trace of thread 616852: #0 0x7fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7fce13278818 __pthread_cond_wait_common (libc.so.6 + 0x87818) #2
Bug#1040716: libc6: Stack Traces
On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote: > Hi, > > On 2023-07-09 17:15, Tim McConnell wrote: > > Hi Aurelien, > > The Stack Traces started showing up in my System Event logs > > yesterday > > and has totaled up to 18 times so far. As far as issues, the system > > is > > slower than usual and occasionally freezes. > > I ran apt-file search lib.so and came up with libc6 so that's > > where I > > filed the bug. I tried running gdb on it (libc6) and it told me > > file > > not found, I'd be happy to give more information just tell me how > > to > > get it. > > Thanks for the details, however I am afraid it is not enough. libc6 > is a > library, for understanding the issue, I would need to know by which > program it is used in the corresponding stack traces. The issue might > not be in the library but in another library or another program. Do > you > have some more log entries around those stack traces? > > All that said, it appears that the locales package in versions 2.37-2 > to > 2.37-4 is buggy and might cause random crashes in libc6. You might > want > to upgrade to version 2.37-5 to check if it solves your issue. The > package is currently only available in sid, but it is expected to > migrate to testing in the next days. > > Regards > Aurelien > Checking Journalctl I found this: Jul 10 19:02:11 DebianTim systemd-coredump[3869]: [] Process 992 (collectd) of user 0 dumped core. Module libudev.so.1 from deb systemd-252.11-1.amd64 Stack trace of thread 1424: #0 0x7f7cbbfce9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2) #1 0x7f7cbbd856d9 rrd_write (librrd.so.8 + 0x346d9) #2 0x7f7cbbd90acd n/a (librrd.so.8 + 0x3facd) #3 0x7f7cbbd92962 n/a (librrd.so.8 + 0x41962) #4 0x7f7cbbdec370 n/a (rrdtool.so + 0x3370) #5 0x7f7cbbee93ec start_thread (libc.so.6 + 0x883ec) #6 0x7f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c) Stack trace of thread 1431: #0 0x7f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7f7cbbee8afc __pthread_cond_wait_common (libc.so.6 + 0x87afc) #2 0x5586e89f93a2 n/a (collectd + 0x123a2) #3 0x7f7cbbee93ec start_thread (libc.so.6 + 0x883ec) #4 0x7f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c) Stack trace of thread 1432: #0 0x7f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7f7cbbee8afc __pthread_cond_wait_common (libc.so.6 + 0x87afc) #2 0x5586e89f93a2 n/a (collectd + 0x123a2) #3 0x7f7cbbee93ec start_thread (libc.so.6 + 0x883ec) #4 0x7f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c) Stack trace of thread 1427: #0 0x7f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7f7cbbee8818 __pthread_cond_wait_common (libc.so.6 + 0x87818) #2 0x5586e89f7d1b n/a (collectd + 0x10d1b) #3 0x7f7cbbee93ec start_thread (libc.so.6 + 0x883ec) #4 0x7f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c) Stack trace of thread 1429: #0 0x7f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7f7cbbee8818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
Bug#1040716: libc6: Stack Traces
On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote: > Hi, > > On 2023-07-09 17:15, Tim McConnell wrote: > > Hi Aurelien, > > The Stack Traces started showing up in my System Event logs > > yesterday > > and has totaled up to 18 times so far. As far as issues, the system > > is > > slower than usual and occasionally freezes. > > I ran apt-file search lib.so and came up with libc6 so that's > > where I > > filed the bug. I tried running gdb on it (libc6) and it told me > > file > > not found, I'd be happy to give more information just tell me how > > to > > get it. > > Thanks for the details, however I am afraid it is not enough. libc6 > is a > library, for understanding the issue, I would need to know by which > program it is used in the corresponding stack traces. The issue might > not be in the library but in another library or another program. Do > you > have some more log entries around those stack traces? > > All that said, it appears that the locales package in versions 2.37-2 > to > 2.37-4 is buggy and might cause random crashes in libc6. You might > want > to upgrade to version 2.37-5 to check if it solves your issue. The > package is currently only available in sid, but it is expected to > migrate to testing in the next days. > > Regards > Aurelien > I'll check journalctl and see if that has better info. I'll also upgrade the package you were talking about to see if it fixes the issue . I will let you know.
Bug#1040716: libc6: Stack Traces
Hi Aurelien, The Stack Traces started showing up in my System Event logs yesterday and has totaled up to 18 times so far. As far as issues, the system is slower than usual and occasionally freezes. I ran apt-file search lib.so and came up with libc6 so that's where I filed the bug. I tried running gdb on it (libc6) and it told me file not found, I'd be happy to give more information just tell me how to get it. -- Tim McConnell On Sun, 2023-07-09 at 23:34 +0200, Aurelien Jarno wrote: > Hi, > > On 2023-07-09 15:05, Tim McConnell wrote: > > Package: libc6 > > Version: 2.37-3 > > Severity: normal > > > > Thanks for your bug report. Could you please explain me what are > those > stack traces, and what is the issue you encountered? Thanks. > > Regards > Aurelien >
Bug#1040357: conky-all: Stack trace of thread 4760
On Wed, 2023-07-05 at 08:22 -0700, Vincent Cheng wrote: > On Tue, Jul 4, 2023 at 12:51 PM Tim McConnell > wrote: > > > > Package: conky-all > > Version: 1.18.3-1 > > Severity: normal > > > > Stack trace of thread 4760: > > > > #0 > > 0x7f2a0c8a2ccc > > __pthread_kill_implementation (libc.so.6 + 0x8accc) > > #10 > > 0x565224f2323a n/a > > (conky + 0x8423a) > > #1 > > 0x7f2a0c853ef2 > > __GI_raise (libc.so.6 + 0x3bef2) > > #11 > > 0x565224f24abf n/a > > (conky + 0x85abf) > > #12 > > 0x565224f24e35 n/a > > (conky + 0x85e35) > > #13 > > 0x565224f28275 n/a > > (conky + 0x89275) > > #14 > > 0x565224f06897 n/a > > (conky + 0x67897) > > #15 > > 0x565224f074af n/a > > (conky + 0x684af) > > #16 > > 0x565224ecf1bc n/a > > (conky + 0x301bc) > > #17 > > 0x565224ebdb74 main > > (conky + 0x1eb74) > > #18 > > 0x7f2a0c83f18a > > __libc_start_call_main (libc.so.6 + 0x2718a) > > #19 > > 0x7f2a0c83f245 > > __libc_start_main_impl (libc.so.6 + 0x27245) > > #20 > > 0x565224ec4261 n/a > > (conky + 0x25261) > > #2 > > 0x7f2a0c83e472 > > __GI_abort (libc.so.6 + 0x26472) > > #3 > > 0x565224f23497 n/a > > (conky + 0x84497) > > #4 > > 0x7f2a0d7a699b > > _XError (libX11.so.6 + 0x4699b) > > #5 > > 0x7f2a0d7a3607 n/a > > (libX11.so.6 + 0x43607) > > #6 > > 0x7f2a0d7a36a5 n/a > > (libX11.so.6 + 0x436a5) > > #7 > > 0x7f2a0d7a47fd > > _XReply (libX11.so.6 + 0x447fd) > > #8 > > 0x7f2a0d78a8eb > > _XGetWindowAttributes (libX11.so.6 + 0x2a8eb) > > #9 > > 0x7f2a0d78aa49 > > XGetWindowAttributes (libX11.so.6 + 0x2aa49) > > ELF object binary > > architecture: AMD x86-64 > > I'm happy to give additional information just ask and give clear > > directions. > > Please report this directly to upstream's bug tracker at > https://github.com/brndnmtthws/conky/issues, thanks! > > Regards, > Vincent GITHUB Bug # Stack trace of thread 4760 #1586
Bug#1035472: bug 1035472
This can be closed the issue is no longer occurring. -- Tim McConnell
Bug#1036035: bug 1036035
THis can be closed Boxes works now -- Tim McConnell
Bug#1040357: conky-all: Stack trace of thread 4760
Package: conky-all
Version: 1.18.3-1
Severity: normal
Stack trace of thread 4760:
#0 0x7f2a0c8a2ccc
__pthread_kill_implementation (libc.so.6 + 0x8accc)
#10 0x565224f2323a n/a
(conky + 0x8423a)
#1 0x7f2a0c853ef2
__GI_raise (libc.so.6 + 0x3bef2)
#11 0x565224f24abf n/a
(conky + 0x85abf)
#12 0x565224f24e35 n/a
(conky + 0x85e35)
#13 0x565224f28275 n/a
(conky + 0x89275)
#14 0x565224f06897 n/a
(conky + 0x67897)
#15 0x565224f074af n/a
(conky + 0x684af)
#16 0x565224ecf1bc n/a
(conky + 0x301bc)
#17 0x565224ebdb74 main
(conky + 0x1eb74)
#18 0x7f2a0c83f18a
__libc_start_call_main (libc.so.6 + 0x2718a)
#19 0x7f2a0c83f245
__libc_start_main_impl (libc.so.6 + 0x27245)
#20 0x565224ec4261 n/a
(conky + 0x25261)
#2 0x7f2a0c83e472
__GI_abort (libc.so.6 + 0x26472)
#3 0x565224f23497 n/a
(conky + 0x84497)
#4 0x7f2a0d7a699b
_XError (libX11.so.6 + 0x4699b)
#5 0x7f2a0d7a3607 n/a
(libX11.so.6 + 0x43607)
#6 0x7f2a0d7a36a5 n/a
(libX11.so.6 + 0x436a5)
#7 0x7f2a0d7a47fd
_XReply (libX11.so.6 + 0x447fd)
#8 0x7f2a0d78a8eb
_XGetWindowAttributes (libX11.so.6 + 0x2a8eb)
#9 0x7f2a0d78aa49
XGetWindowAttributes (libX11.so.6 + 0x2aa49)
ELF object binary
architecture: AMD x86-64
I'm happy to give additional information just ask and give clear directions.
Tim
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.3.0-1-amd64 (SMP w/1 CPU thread; 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 conky-all depends on:
ii libaudclient23.5~rc2-1+b1
ii libc62.36-9
ii libcairo21.16.0-7
ii libcurl3-gnutls 7.88.1-10
ii libdbus-glib-1-2 0.112-3
ii libfontconfig1 2.14.1-4
ii libgcc-s113.1.0-6
ii libglib2.0-0 2.74.6-2
ii libical3 3.0.16-1+b1
ii libimlib21.10.0-4+b1
ii libircclient11.9-1+b2
ii libiw30 30~pre9-14
ii liblua5.3-0 5.3.6-2
ii libncurses6 6.4-4
ii libpango-1.0-0 1.50.14+ds-1
ii libpangocairo-1.0-0 1.50.14+ds-1
ii libpangoft2-1.0-01.50.14+ds-1
ii libpulse016.1+dfsg1-2+b1
ii librsvg2-2 2.54.5+dfsg-1
ii libstdc++6 13.1.0-6
ii libtinfo66.4-4
ii libwayland-client0 1.21.0-1
ii libx11-6 2:1.8.6-1
ii libxdamage1 1:1.1.6-1
ii libxext6 2:1.3.4-1+b1
ii libxfixes3 1:6.0.0-2
ii libxft2 2.3.6-1
ii libxinerama1 2:1.1.4-3
ii libxml2 2.9.14+dfsg-1.2
ii libxnvctrl0 525.85.05-1
conky-all recommends no packages.
Versions of packages conky-all suggests:
pn apcupsd
pn audacious
ii moc1:2.6.0~svn-r3005-3
ii mpd0.23.12-1+b2
-- Configuration Files:
/etc/conky/conky.conf changed:
-- Conky, a system monitor https://github.com/brndnmtthws/conky
--
-- This configuration file is Lua code. You can write code in here, and it will
-- execute when Conky loads. You can use it to generate your own advanced
-- configurations.
--
-- Try this (remove the `--`):
print("Loading Conky config")
--
-- For more on Lua, see:
-- https://www.lua.org/pil/contents.html
conky.config = {
alignment = 'bottom_left',
background = false,
border_width = 1,
cpu_avg_samples = 2,
default_color = 'purple',
default_outline_color = 'white',
default_shade_color = 'white',
double_buffer = true,
draw_borders = true,
draw_graph_borders = true,
draw_outline = false,
draw_shades = false,
extra_newline = false,
font = 'D
Bug#1023191: Clang 14 fix
I can confirm that this is a annoyance for Clang users on bookworm. It is necessary to compile programs with the rather uncommon compiler option -dgwarf-4 to be able to use valgrind. Tim On Mon, 31 Oct 2022 13:05:16 +0100 darkdragon wrote: > Package: valgrind > Version: 1:3.19.0-1 > > Please backport the following patch to all releases including Clang 14: > https://bugs.kde.org/show_bug.cgi?id=452758 > >
Bug#1038598: close this bug please
Hi Developer, Thanks for pushing the new version to testing, the issue is now fixed. This can be closed out. Issue description: High CPU usage when trying to view some HTML emails. Unable to scroll and scroll bar didn't appear to move. I could view those emails in Claws just fine. If I clicked off onee of the affected emails the CPU would go back to normal and email would be scroll-able again. Thanks ️ -- Tim McConnell
Bug#1038598: evolution: need 3.48.3 to fix issue
Package: evolution Version: 3.48.2-1 Severity: normal I reported an issue to the Evolution Mailing list and Milan Chra states: Hi, I suppose the mails also grow the vertical scrollbar (indefinitely) and cannot be scrolled. Update to 3.48.3, which contains related fixes: https://gitlab.gnome.org/GNOME/evolution/-/commit/e9b7c6bbcc0ed477182470ee6080999560f8b5d8 A workaround: change width of the preview panel, it sometimes helps, but the size can differ per viewed mail. Bye, Milan The workaround doesn't help the issue I'm having. The High CPU usage goes away but I'm still unable to scroll on certain HTML emails -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; 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 evolution depends on: ii dbus [default-dbus-system-bus] 1.14.6-1 ii dbus-broker [dbus-system-bus] 33-1 ii evolution-common3.48.2-1 ii evolution-data-server 3.48.2-1 ii libc6 2.36-9 ii libcamel-1.2-64 3.48.2-1 ii libecal-2.0-2 3.48.2-1 ii libedataserver-1.2-27 3.48.2-1 ii libevolution3.48.2-1 ii libglib2.0-02.74.6-2 ii libgtk-3-0 3.24.37-2 ii libical33.0.16-1+b1 ii libnotify4 0.8.2-1 ii libwebkit2gtk-4.1-0 2.40.2-1 ii libxml2 2.9.14+dfsg-1.2 ii psmisc 23.6-1 Versions of packages evolution recommends: ii evolution-plugin-bogofilter 3.48.2-1 ii evolution-plugin-pstimport 3.48.2-1 ii evolution-plugins3.48.2-1 ii yelp 42.2-1 Versions of packages evolution suggests: pn evolution-ews ii evolution-plugins-experimental 3.48.2-1 ii gnupg 2.2.40-1.1 ii network-manager 1.42.6-1 -- debconf-show failed
Bug#1036033: upgrade-reports: bullseye -> bookworm kernel package upgrade fails when ddcci-dkms package installed
This took a while to track down - sorry for the delay. The machine which was being upgraded had a non-functional shim in place instead of rpm. This had been done to satisfy a hardware-vendor provided firmware upgrade, which would not work unless an rpm executable was found on the system (despite the fact that the firmware upgrade did not use rpm). dkms preferentially uses rpm (even on Debian) to try and determine the architecture of the running system (instead of other methods such as `uname -m` or `dpkg --print-architecture`). dkms uses the architecture which it has determined to store compiled modules at /var/lib/dkms/$module/$version/$kernelver/$arch/modules/ This use of a non-functional rpm resulted in dkms setting its internal architecture to the empty string. This made dkms work correctly whilst installing modules (storing the resulting modules without the $arch path componenent) e.g. to /var/lib/dkms/ddcci/0.3.3/5.10.0-14-amd64/module/ddcci.ko and also detect the presence of already installed modules, but also resulted in it silently failing when asked to remove modules. If this is considered a bug, then it would seem reasonable for dkms to treat it's internal architecture variable being set to the empty string to be an error condition, and to exit and/or to fall back to using other methods of determining the architecture (which it does on Debian systems which don't have an rpm binary installed).
Bug#1036033: upgrade-reports: bullseye -> bookworm kernel package upgrade fails when ddcci-dkms package installed
Hi Stephen, Sorry for the delay - busy with family, work and other matters... I've restored a backup to a VM, and re-run the upgrade there, taking care to follow exactly the upgrade instructions at: https://www.debian.org/releases/testing/amd64/release-notes.en.pdf ...this lead to a recurrence of the failure. It looks like the problem is that the call to: dkms remove -m ddcci -v 0.3.3 ...which is made by /var/lib/dpkg/info/ddcci-dkms.prerm isn't working. On the restored backup, running this command manually doesn't uninstall the module, it also doesn't print any output - it just exits with return code 0. When the same ddcci-dkms 0.3.3-1 package is installed and built on a brand new Debian 11 VM, the prerm script works as expected and uninstalls correctly (and verbosely). This sounds like the same (correct) behaviour which you saw in your testing. I'll try and look into what's causing the dkms script to silently no-op on the failing VM in the next day or so, and let you know what I find. Cheers, Tim.
Bug#1037102: stack trace
Stack trace of thread 621419: #0 0x5608483faf53 n/a (distort + 0x5f53) #1 0x5608483fc62b n/a (distort + 0x762b) #2 0x5608483fa0cc n/a (distort + 0x50cc) #3 0x7f5197b2118a __libc_start_call_main (libc.so.6 + 0x2718a) #4 0x7f5197b21245 __libc_start_main_impl (libc.so.6 + 0x27245) #5 0x5608483fa9c1 n/a (distort + 0x59c1) ELF object binary architecture: AMD x86-64
Bug#1037005: prometheus-smokeping-prober: package is missing an /etc/init.d script
Package: prometheus-smokeping-prober
Version: 0.4.1-2+b5
Severity: normal
Tags: patch
X-Debbugs-Cc: tim_woot...@yahoo.com
Dear Maintainer,
Please include an /etc/init.d script as is provided with other prometheus
exporters
-- System Information:
Debian Release: 11.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-21-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
Versions of packages prometheus-smokeping-prober depends on:
ii adduser3.118
ii debconf [debconf-2.0] 1.5.77
ii libc6 2.31-13+deb11u6
ii libcap2-bin1:2.44-1
prometheus-smokeping-prober recommends no packages.
prometheus-smokeping-prober suggests no packages.
-- debconf information:
prometheus-smokeping-prober/want_cap_net_raw: false
Patch file /etc/init.d/prometheus-smokeping-prober, based on standard template:
#!/bin/sh
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
### BEGIN INIT INFO
# Provides: prometheus-smokeping-prober
# Required-Start:$remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Prometheus style "smokeping" prober
# Description: This prober sends a series of ICMP (or UDP) pings to a
target and records
#the responses in Prometheus histogram metrics. The
resulting metrics are
#useful for detecting changes in network latency (or round
trip time), as
#well as packet loss over a network path.
### END INIT INFO
DESC="Prometheus style smokeping prober"
NAME=prometheus-smokeping-prober
DAEMON=/usr/bin/$NAME
USER=prometheus
PIDFILE=/var/run/prometheus/$NAME.pid
LOGFILE=/var/log/prometheus/$NAME.log
HELPER=/usr/bin/daemon
HELPER_ARGS="--name=$NAME --output=$LOGFILE --pidfile=$PIDFILE --user=$USER"
ARGS=""
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
do_start_prepare()
{
mkdir -p `dirname $PIDFILE`
chown $USER: `dirname $LOGFILE`
chown $USER: `dirname $PIDFILE`
}
do_start_cmd_override()
{
# Return
# 0 if daemon has been started or already running
# 2 if daemon could not be started
$HELPER $HELPER_ARGS --running && return 0
$HELPER $HELPER_ARGS -- $DAEMON $ARGS || return 2
return 0
}
do_stop_cmd_override()
{
# Return
# 0 if daemon has been stopped or already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
$HELPER $HELPER_ARGS --running || return 0
$HELPER $HELPER_ARGS --stop || return 2
# wait for the process to really terminate
for n in 1 2 3 4 5; do
sleep $n
$HELPER $HELPER_ARGS --running || break
done
$HELPER $HELPER_ARGS --running || return 0
return 2
}
Bug#977037: Add timestamp to logs
Hi Paul, I've added an upstream MR here implementing the addition of relative timestamps in seconds https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/229 Please give me any feedback you have on the implementation and I'll amend it as you see fit! Tim
Bug#977037:
Hi Paul,
We've been discussing this amongst ourselves recently, and decided to open
up some communication about this bug/feature request. We looked at trying
to add timestamps in the way we wrap the autopkgtest runner, but ultimately
decided it made more sense and was cleaner to try and do something upstream
in autopkgtest.
I have a couple of questions regarding implementation. We thought it best
to get your feedback before creating an upstream MR.
I think it'd be possible to alter the tee command in the setup_trace
function in the autopkgtest executable to incorporate `ts`:
```
out_tee = subprocess.Popen(['tee', fifo_log],
stdin=subprocess.PIPE)
err_tee = subprocess.Popen(['tee', fifo_log, '-a', '/dev/stderr'],
stdin=subprocess.PIPE,
stdout=open('/dev/null', 'wb'))
```
But this'd make autopkgtest depend on the `moreutils` package.
Another option would be to have a different longer command which
essentially does the same as ts, but this removes the need for `moreutils`
as a dependency. Something like this:
```
exec &> >(stdbuf -o0 sed 's/%/%%/g' | xargs -d '\n' -I {} date '+%F %T
{}' | tee -a "/tmp/std.log" >/dev/null )
```
Another option to explore would be to add a similar option to the various
subprocesses in the runner executable. I worry by adding ts (or another
option) directly to the setup_trace function, we would get duplicate
timestamps, given that the autopkgtest runner uses adtlog, which already
has timestamps. So the main process has appropriate logs, but the
subprocesses do not.
Please let me know any feedback you have on the above ideas.
Regards,
Tim
Bug#977037: Test log timestamps
Hi Paul,
We've been discussing this amongst ourselves recently, and decided to open
up some communication about this bug/feature request. We looked at trying
to add timestamps in the way we wrap the autopkgtest runner, but ultimately
decided it made more sense and was cleaner to try and do something upstream
in autopkgtest.
I have a couple of questions regarding implementation. We thought it best
to get your feedback before creating an upstream MR.
I think it'd be possible to alter the tee command in the setup_trace
function in the autopkgtest executable to incorporate `ts`:
```
out_tee = subprocess.Popen(['tee', fifo_log],
stdin=subprocess.PIPE)
err_tee = subprocess.Popen(['tee', fifo_log, '-a', '/dev/stderr'],
stdin=subprocess.PIPE,
stdout=open('/dev/null', 'wb'))
```
But this'd make autopkgtest depend on the `moreutils` package.
Another option would be to have a different longer command which
essentially does the same as ts, but this removes the need for `moreutils`
as a dependency. Something like this:
```
exec &> >(stdbuf -o0 sed 's/%/%%/g' | xargs -d '\n' -I {} date '+%F %T
{}' | tee -a "/tmp/std.log" >/dev/null )
```
Another option to explore would be to add a similar option to the various
subprocesses in the runner executable. I worry by adding ts (or another
option) directly to the setup_trace function, we would get duplicate
timestamps, given that the autopkgtest runner uses adtlog, which already
has timestamps. So the main process has appropriate logs, but the
subprocesses do not.
Please let me know any feedback you have on the above ideas.
Regards,
Tim
Bug#1036041: upgrade-reports: Dell XPS 9550 fails to boot after bullseye to bookworm upgrade - grub/bios interaction bug?
Package: upgrade-reports Severity: normal X-Debbugs-Cc: t...@seoss.co.uk My previous release is: bullseye I am upgrading to: bookworm Upgrade date: 2022-05-06 Method: apt dist-upgrade Contents of /etc/apt/sources.list: deb http://deb.debian.org/debian/ bookworm main non-free non-free-firmware contrib deb-src http://deb.debian.org/debian/ bookworm main non-free non-free-firmware contrib # Security updates deb http://security.debian.org bookworm-security main contrib non-free non-free-firmware deb-src http://security.debian.org bookworm-security main contrib non-free non-free-firmware # bookworm-updates, previously known as 'volatile' deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware deb http://deb.debian.org/debian-debug/ bookworm-debug main # for security updates deb http://deb.debian.org/debian-debug/ bookworm-proposed-updates-debug main - Were there any problems with the system after upgrading? System fails to boot after upgrade - hangs after loading initramfs. On enabling debug within grub, the hang occurs at: kern/verifiers.c:88: file: /boot/initrd.img-6.1.0-8-amd64 type: 131076 kern/verifiers.c:103: trying verifier pgp kern/verifiers.c:103: trying verifier tpm Can be worked around with: GRUB_TERMINAL=console ... with this setting in place the system boots as expected.
Bug#1036035: gnome-boxes: can't launch since upgrading Kernel to 6.1.0-9
Package: gnome-boxes Version: 43.2-1 Severity: normal Upgraded my Kernel to 6.1.0-9 and now I get a spinning MATE Symbol and Boxes never launches (See screenshot) -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; 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 gnome-boxes depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii genisoimage 9:1.1.11-3.4 ii libarchive13 3.6.2-1 ii libc62.36-9 ii libcairo21.16.0-7 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.37-2 ii libgudev-1.0-0 237-2 ii libhandy-1-0 1.8.1-1 ii libosinfo-1.0-0 1.10.0-2 ii libosinfo-bin1.10.0-2 ii libsecret-1-00.20.5-3 ii libsoup-3.0-03.2.2-2 ii libspice-client-glib-2.0-8 0.42-1 ii libspice-client-gtk-3.0-50.42-1 ii libtracker-sparql-3.0-0 3.4.2-1 ii libusb-1.0-0 2:1.0.26-1 ii libvirt-daemon 9.0.0-3 ii libvirt-glib-1.0-0 4.0.0-2 ii libwebkit2gtk-4.1-0 2.40.1-1 ii libxml2 2.9.14+dfsg-1.2 ii tracker 3.4.2-1 Versions of packages gnome-boxes recommends: ii qemu-system-x86 1:7.2+dfsg-6 Versions of packages gnome-boxes suggests: pn gnome-connections -- debconf-show failed
Bug#1036033: upgrade-reports: bullseye -> bookworm kernel package upgrade fails when ddcci-dkms package installed
Package: upgrade-reports Severity: normal X-Debbugs-Cc: t...@seoss.co.uk (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) My previous release is: bullseye I am upgrading to: bookworm Upgrade date: 2023-05-06 Method: apt dist-upgrade Contents of /etc/apt/sources.list: deb http://deb.debian.org/debian/ bookworm main non-free non-free-firmware contrib deb-src http://deb.debian.org/debian/ bookworm main non-free non-free-firmware contrib # Security updates deb http://security.debian.org bookworm-security main contrib non-free non-free-firmware deb-src http://security.debian.org bookworm-security main contrib non-free non-free-firmware # bookworm-updates, previously known as 'volatile' deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware deb http://deb.debian.org/debian-debug/ bookworm-debug main # for security updates deb http://deb.debian.org/debian-debug/ bookworm-proposed-updates-debug main - Was the system pre-update a 'pure' system only containing packages from the previous release? If not, which packages were not from that release? yes - Did any packages fail to upgrade? linux-image-6.1.0-7-amd64 With the ddcci-dkms installed, and enabled for building before the upgrade, the following occurred during upgrade: /etc/kernel/postinst.d/dkms: dkms: running auto installation service for kernel 6.1.0-7-amd64. Error! Could not locate dkms.conf file. File: /var/lib/dkms/ddcci/0.3.3/source/dkms.conf does not exist. dkms: autoinstall for kernel: 6.1.0-7-amd64 failed! run-parts: /etc/kernel/postinst.d/dkms exited with return code 4 dpkg: error processing package linux-image-6.1.0-7-amd64 (--configure): installed linux-image-6.1.0-7-amd64 package post-installation script subprocess returned error exit status 1 Setting up linux-headers-6.1.0-7-amd64 (6.1.20-2) ... /etc/kernel/header_postinst.d/dkms: dkms: running auto installation service for kernel 6.1.0-7-amd64. Error! Could not locate dkms.conf file. File: /var/lib/dkms/ddcci/0.3.3/source/dkms.conf does not exist. dkms: autoinstall for kernel: 6.1.0-7-amd64 failed! run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 4 Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux-headers-6.1.0-7-amd64.postinst line 11. dpkg: error processing package linux-headers-6.1.0-7-amd64 (--configure): installed linux-headers-6.1.0-7-amd64 package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of linux-headers-amd64: linux-headers-amd64 depends on linux-headers-6.1.0-7-amd64 (= 6.1.20-2); however: Package linux-headers-6.1.0-7-amd64 is not configured yet. dpkg: error processing package linux-headers-amd64 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of linux-image-amd64: linux-image-amd64 depends on linux-image-6.1.0-7-amd64 (= 6.1.20-2); however: Package linux-image-6.1.0-7-amd64 is not configured yet. dpkg: error processing package linux-image-amd64 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: linux-image-6.1.0-7-amd64 linux-headers-6.1.0-7-amd64 linux-headers-amd64 linux-image-amd64 - Were there any problems with the system after upgrading? Further Comments/Problems: Please attach the output of "COLUMNS=200 dpkg -l" (or "env COLUMNS ...", depending on your shell) from before and after the upgrade so that we know what packages were installed on your system.
Bug#1036032: upgrade-reports: mariadb upgrade fails when KDE akonadi installed
Package: upgrade-reports Severity: normal X-Debbugs-Cc: t...@seoss.co.uk (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) My previous release is: Bullseye I am upgrading to: Bookworm Archive date: Upgrade date: 2023-05-06 20:00 UTC uname -a before upgrade: uname -a after upgrade: Method: apt dist-upgrade Contents of /etc/apt/sources.list: deb http://deb.debian.org/debian/ bookworm main non-free non-free-firmware contrib deb-src http://deb.debian.org/debian/ bookworm main non-free non-free-firmware contrib # Security updates deb http://security.debian.org bookworm-security main contrib non-free non-free-firmware deb-src http://security.debian.org bookworm-security main contrib non-free non-free-firmware # bookworm-updates, previously known as 'volatile' deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware deb http://deb.debian.org/debian-debug/ bookworm-debug main # for security updates deb http://deb.debian.org/debian-debug/ bookworm-proposed-updates-debug main - Were there any non-Debian packages installed before the upgrade? If so, what were they? signal, element-desktop - Was the system pre-update a 'pure' system only containing packages from the previous release? If not, which packages were not from that release? Yes - Did any packages fail to upgrade? Errors were encountered while processing: default-mysql-server kdepim-runtime kmail kaddressbook korganizer knotes With mariadb-server installed (but startup disabled), and also KDE akonadi/kde-pim installed (and using its own mysqld instance), the mariadb-server package upgrade fails: Preparing to unpack .../mariadb-server_1%3a10.11.2-1_amd64.deb ... /var/lib/mysql: found previous version 10.5 Failed to stop mysql.service: Unit mysql.service not loaded. invoke-rc.d: initscript mysql, action "stop" failed. Attempt to stop MariaDB/MySQL server returned exitcode 5 There is a MariaDB/MySQL server running, but we failed in our attempts to stop it. Stop it yourself and try again! dpkg: error processing archive /var/cache/apt/archives/mariadb-server_1%3a10.11.2-1_amd64.deb (--unpack): new mariadb-server package pre-installation script subprocess returned error exit status 1 Preparing to unpack .../libconfig-inifiles-perl_3.03-2_all.deb ... Unpacking libconfig-inifiles-perl (3.03-2) over (3.03-1) ... Preparing to unpack .../default-mysql-client_1.1.0_all.deb ... Unpacking default-mysql-client (1.1.0) over (1.0.7) ... : Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive. : Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive. : Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive. Errors were encountered while processing: /var/cache/apt/archives/mariadb-server_1%3a10.11.2-1_amd64.deb needrestart is being skipped since dpkg has failed Please attach the output of "COLUMNS=200 dpkg -l" (or "env COLUMNS ...", depending on your shell) from before and after the upgrade so that we know what packages were installed on your system.
Bug#1035896: tor: Stack trace
Package: tor Version: 0.4.7.13-1 Severity: normal Module /home/tmick/.local/share/torbrowser/tbb/x86_64/tor- browser/Browser/libplc4.so from deb systemd-252.6-1.amd64 Module libsystemd.so.0 from deb systemd-252.6-1.amd64 Stack trace of thread 1458911: #0 0x7f2a3faa8ccc __pthread_kill_implementation (libc.so.6 + 0x8accc) #1 0x7f2a3fa59ef2 __GI_raise (libc.so.6 + 0x3bef2) #2 0x7f2a38935991 n/a (/home/tmick/.local/share/torbrowser/tbb/x86_64/tor-browser/Browser/libxul.so + 0x3f35991) ELF object binary architecture: AMD x86-64 May 10 15:21:37 DebianTim systemd[1]: systemd-coredump@1-1459324-0.service: Deactivated successfully. Let me know if there is anything I can get for you and how to get it. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-8-amd64 (SMP w/1 CPU thread; 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 tor depends on: ii adduser3.132 ii libc6 2.36-9 ii libcap21:2.66-3 ii libevent-2.1-7 2.1.12-stable-8 ii liblzma5 5.4.1-0.2 ii libseccomp22.5.4-1+b3 ii libssl33.0.8-1 ii libsystemd0252.6-1 ii libzstd1 1.5.4+dfsg2-5 ii lsb-base 11.6 ii runit-helper 2.15.2 ii sysvinit-utils [lsb-base] 3.06-4 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages tor recommends: ii logrotate3.21.0-1 ii tor-geoipdb 0.4.7.13-1 ii torsocks 2.4.0-1 Versions of packages tor suggests: ii apparmor-utils 3.0.8-3 pn mixmaster ii nyx 2.1.0-2.2 ii obfs4proxy 0.0.14-1+b4 ii socat1.7.4.4-2 ii torbrowser-launcher 0.3.6-2 -- no debconf information
Bug#1035472: libstdc++.so: Core dump with libstdc++.so and index++
Package: libstdc++6 Version: 12.2.0-14 Severity: normal File: libstdc++.so #0 0x7f2c7daa4ccc __pthread_kill_implementation (libc.so.6 + 0x8accc) #10 0x556d13d51d8e n/a (index++ + 0xed8e) #1 0x7f2c7da55ef2 __GI_raise (libc.so.6 + 0x3bef2) #11 0x7f2c7da4118a __libc_start_call_main (libc.so.6 + 0x2718a) #12 0x7f2c7da41245 __libc_start_main_impl (libc.so.6 + 0x27245) #13 0x556d13d5482a n/a (index++ + 0x1182a) #2 0x7f2c7da40472 __GI_abort (libc.so.6 + 0x26472) #3 0x7f2c7dc9d919 n/a (libstdc++.so.6 + 0x9d919) #4 0x7f2c7dca8e1a n/a (libstdc++.so.6 + 0xa8e1a) #5 0x7f2c7dca8e85 _ZSt9terminatev (libstdc++.so.6 + 0xa8e85) #6 0x7f2c7dca90d8 __cxa_throw (libstdc++.so.6 + 0xa90d8) #7 0x7f2c7dca026d n/a (libstdc++.so.6 + 0xa026d) #8 0x556d13d598a6 n/a (index++ + 0x168a6) #9 0x556d13d608b6 n/a (index++ + 0x1d8b6) ELF object binary systemd-coredump[3959523]: Process 3959515 (index++) of user 0 dumped core. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/1 CPU thread; 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 libstdc++6:amd64 depends on: ii gcc-12-base 12.2.0-14 ii libc62.36-9 ii libgcc-s112.2.0-14 libstdc++6:amd64 recommends no packages. libstdc++6:amd64 suggests no packages. -- debconf-show failed
Bug#1033231: fixed in postgrey 1.37-2
Hello! After a little testing i can confirm that postgrey is installed fine: The user is created with uid=119 and gid=130, /etc/postgrey contains the files whitelist_clients and whitelist_recipients and the daemon seems to be running fine. Thanks a lot! Cheers, tim Tested version: 1.37-2 from unstable Platform: amd64 Debian version: 12/testing Recommended packages from testing On Sun, 30 Apr 2023 23:18:59 + Debian FTP Masters wrote: > Source: postgrey > Source-Version: 1.37-2 > Done: Jordi Mallach > > We believe that the bug you reported is fixed in the latest version of > postgrey, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 1033...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Jordi Mallach (supplier of updated postgrey package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Format: 1.8 > Date: Mon, 01 May 2023 00:57:30 +0200 > Source: postgrey > Architecture: source > Version: 1.37-2 > Distribution: unstable > Urgency: medium > Maintainer: Jordi Mallach > Changed-By: Jordi Mallach > Closes: 1031401 1033231 > Changes: > postgrey (1.37-2) unstable; urgency=medium > . > * Use %H in the service file to set the hostname in the rejection message > (closes: #1031401). > * Add missing ucf machinery so the default config file and whitelists get > installed correctly (closes: #1033231). > * Reinstate creation of postgrey user. > * Ensure /var/lib/postgrey exists and is owned by postgrey. > Checksums-Sha1: > 55f468de0bc7b115b24b782df971dc1d315977a0 1888 postgrey_1.37-2.dsc > 5d48d6399d98c4ff93a5298c4129a61607332284 18584 postgrey_1.37- 2.debian.tar.xz > f4ee4febb21d2bc5c5a256c3232ba10a64096289 6169 postgrey_1.37- 2_amd64.buildinfo > Checksums-Sha256: > 87c3ac7f80fab0a0bf2710ec1f4bd21614ff508d68a8c5c0a61191bce19c1455 1888 postgrey_1.37-2.dsc > 7920f5299346b1d29b20fb18779350264fa0de7275f18a3b9e6a956e0a8b1f6e 18584 postgrey_1.37-2.debian.tar.xz > 0c91dc74591a19387c8e82276a8d3bf1f224caac87c8d6e07830cf551a3e75da 6169 postgrey_1.37-2_amd64.buildinfo > Files: > d27b863757d844ed32d511bc7d5dc441 1888 mail optional postgrey_1.37- 2.dsc > b1d772f1519986eead7640c64a89bef0 18584 mail optional postgrey_1.37- 2.debian.tar.xz > 5e72d9727b2d0a152ff8a905803e6b44 6169 mail optional postgrey_1.37- 2_amd64.buildinfo > > -BEGIN PGP SIGNATURE- >
Bug#1033231: postgrey: Postgrey (testing) won't start after installation
Package: postgrey Version: 1.37-1.1 Followup-For: Bug #1033231 Dear maintainer, I just installed postgrey on my mail server and it won't start (canceled start after 5 attempts). /var/log/syslog states that ERROR: --unix or --inet must be specified among other things like missing config files and users. Outcome of my installation is that postgrey won't start unless i add options to /lib/systemd/system/postgrey.service. My expectation was that i install this little package and have it up and running in seconds. Thanks for providing this package nevertheless! Cheers, tim -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.2.11 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages postgrey depends on: ii adduser 3.132 ii init-system-helpers 1.65.2 ii libberkeleydb-perl 0.64-2+b1 ii libnet-dns-perl 1.36-1 ii libnet-server-perl 2.013-2 ii libnetaddr-ip-perl 4.079+dfsg-2+b1 ii perl 5.36.0-7 ii ucf 3.0043+nmu1 Versions of packages postgrey recommends: ii libnet-rblclient-perl 0.5-4 ii libparse-syslog-perl 1.10-4 ii postfix3.7.4-2 postgrey suggests no packages. -- no debconf information
Bug#1034592: systemd-coredump@0-9980-0.service
Package: systemd-coredump Version: 252.6-1 Severity: normal I see this in journalctl and my logs: Apr 18 18:10:55 kernel: MainThread[9976]: segfault at 0 ip 7f22f8e472f9 sp 7ffdd6ecba98 error 6 in libxul.so[7f22f8d> Apr 18 18:10:55 kernel: Code: 3f 08 48 8d 0d c8 ef 9a 06 48 89 08 31 c9 89 0c 25 00 00 00 00 0f 0b 48 8b 05 a3 4f 3f 08 48 8> Apr 18 18:10:55 systemd[1]: Created slice system-systemd\x2dcoredump.slice - Slice /system/systemd-coredump. Apr 18 18:10:55 systemd[1]: Started systemd-coredump@0-9980-0.service - Process Core Dump (PID 9980/UID 0). Apr 18 18:10:58 systemd-coredump[9981]: [] Process 9976 (MainThread) of user 1000 dumped core. Module libsystemd.so.0 from deb systemd-252.6-1.amd64 Stack trace of thread 9976: #0 0x7f22f8e472f9 n/a (libxul.so + 0xa472f9) #1 0x7f22f981382b n/a (libxul.so + 0x141382b) #2 0x7f22fb065b8e n/a (libxul.so + 0x2c65b8e) #3 0x7f22fb0b0acc n/a (libxul.so + 0x2cb0acc) #4 0x7f22f9815f1c n/a (libxul.so + 0x1415f1c) #5 0x7f22f981d77b n/a (libxul.so + 0x141d77b) #6 0x7f22f981deb7 n/a (libxul.so + 0x141deb7) #7 0x7f22f981e002 n/a (libxul.so + 0x141e002) #8 0x7f22f97cbecd n/a (libxul.so + 0x13cbecd) #9 0x7f22f97d3df0 n/a (libxul.so + 0x13d3df0) #10 0x7f22f97cc412 n/a (libxul.so + 0x13cc412) #11 0x7f22f97cb8de n/a (libxul.so + 0x13cb8de) #12 0x7f22fcd59aa6 n/a (libxul.so + 0x4959aa6) #13 0x55d29e055816 n/a (plugin-container + 0xe816) #14 0x55d29e0553db n/a (plugin-container + 0xe3db) #15 0x7f22f7e4218a __libc_start_call_main (libc.so.6 + 0x2718a) #16 0x7f22f7e42245 __libc_start_main_impl (libc.so.6 + 0x27245) #17 0x55d29e055701 _start (plugin-container + 0xe701) Stack trace of thread 9979: #0 0x7f22f7f23c06 epoll_wait (libc.so.6 + 0x108c06) #1 0x7f22f6a25f14 n/a (libevent-2.1.so.7 + 0x2af14) #2 0x7f22f6a1ca15 event_base_loop (libevent-2.1.so.7 + 0x21a15) #3 0x7f22f97cc271 n/a (libxul.so + 0x13cc271) #4 0x7f22f97cb8de n/a (libxul.so + 0x13cb8de) #5 0x7f22f97de161 n/a (libxul.so + 0x13de161) #6 0x7f22f97c79ea n/a (libxul.so + 0x13c79ea) #7 0x55d29e0cbadd _Z30set_alt_signal_stack_and_startP19PthreadCreateParams (plu> #8 0x7f22f7ea3fd4 start_thread (libc.so.6 + 0x88fd4) #9 0x7f22f7f245bc __clone3 (libc.so.6 + 0x1095bc) ELF object binary architecture: AMD x86-64 Apr 18 18:10:58 systemd[1]: systemd-coredump@0-9980-0.service: Deactivated successfully. Please let me know how to get more information if needed. Thanks -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/1 CPU thread; 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 systemd-coredump depends on: ii libc6 2.36-9 ii liblz4-1 1.9.4-1 ii liblzma5 5.4.1-0.2 ii libsystemd-shared 252.6-1 ii libzstd1 1.5.4+dfsg2-5 ii systemd252.6-1 Versions of packages systemd-coredump recommends: ii libdw1 0.188-2.1 systemd-coredump suggests no packages. -- no debconf information
Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI
On 3/29/2023 6:21 PM, Dima Kogan wrote: Package: installation-reports Severity: grave Hi. I just installed a bookworm candidate. This worked OK through partitioning and reboot, but I cannot boot into the system. This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA. I'm installing from a USB drive. To make this work, I had to turn off secure-boot and UEFI in the BIOS. I believe that the result of this is the Debian partitioner defaulted to an MBR partition, not a GPT partition. The BIOS of this laptop only allows booting from the PCIe SSD in UEFI mode (so I need to change the BIOS setting before even trying). But even after that, the machine doesn't let me boot off that disk. Some searching tells me this is because GPT partitions are required for UEFI booting, but Debian made an MBR partition. I'm not 100% sure of the exact cause. But I suspect strongly is that booting the install media without UEFI broke installing to an UEFI-only disk. Thanks. Just to confirm - you were not able to configure the USB Drive for EFI boot? -- This email has been checked for viruses by Avast antivirus software. www.avast.com
Bug#1018061: pads: segfault at 3a ip
Hi Bernhard, Well that explains that then, I didn't change anything to pin to the patched version. In that case it was fixed and I broke it. Hopefully the patch will be part of a future release and it'll be peachy again. Thanks for explaining what happened. -- Tim McConnell On Fri, 2023-03-24 at 11:52 +0100, Bernhard Übelacker wrote: > Am 23.03.23 um 17:38 schrieb Tim McConnell: > > Bernhard, > > Just cause I said it was fixed this happens to show up in > > journalctl: > > systemd-coredump[3614]: Process 1704 (pads) of user 0 dumped core. > > > > Module > > libsystemd.so.0 from deb systemd-252.5-2.amd64 > > Stack trace of > > thread 1704: > > #0 > > 0x5600f24f6954 print_arp_asset_screen (pads + 0x9954) > > #1 > > 0x5600f24f66f0 print_arp_asset (pads + 0x96f0) > > #2 > > 0x7fdc7fdb54f6 n/a (libpcap.so.0.8 + 0x84f6) > > #3 > > 0x7fdc7fdb58ec n/a (libpcap.so.0.8 + 0x88ec) > > #4 > > 0x7fdc7fdbcd1d pcap_loop (libpcap.so.0.8 + 0xfd1d) > > #5 > > 0x5600f24efe5b main_pads (pads + 0x2e5b) > > #6 > > 0x5600f24ef47b main (pads + 0x247b) > > #7 > > 0x7fdc7fbec18a __libc_start_call_main (libc.so.6 + 0x2718a) > > #8 > > 0x7fdc7fbec245 __libc_start_main_impl (libc.so.6 + 0x27245) > > #9 > > 0x5600f24ef4b1 _start (pads + 0x24b1) > > ELF object > > binary > > architecture: AMD x86-64 > > Mar 04 14:31:02 DebianTim systemd[1]: > > systemd-coredump@0-3613-0.service: Deactivated successfully. > > > > Well I thought it was fixed :-( > > > Hello Time, > are you sure that your rebuilt package is still in place? > The offsets in your new backtrace are exactly the same as > in the email from 8 Feb 2023. > > We have not changed the version of the rebuilt package. > Additionally built with "-b". > Then with a "apt dist-upgrade" always > the Debian version gets reinstalled. > > Sorry for not mentioning that extra care has to be taken > to hold the rebuilt package version in place. > > Kind regards, > Bernhard
Bug#1033398: linux-image-amd64: reproducible kernel freeze on 5.19+
Package: linux-image-amd64
Version: 6.1.20-1
Severity: important
X-Debbugs-Cc: tim.rueh...@gmx.de
Dear Maintainer,
* What led up to the situation?
We run a priviledged eBPF based tool with a communication between kernel and
user space.
It runs without issues on kernels 4.15 to 5.18.
On kernels 5.19+, the whole system freezes after a few minutes.
It seems that with more system activities (load, forks) the freeze happens
earlier.
The underlying hardware seems to play no role, we could reproduce this on
different
bare metal systems as well as within a qemu based VM.
Since the running program is rather complex, it is not easily possible to carve
out a small reproducer.
We can provide gdb backtraces from freezes inside qemu.
-- System Information:
Debian Release: 12.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500,
'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-image-amd64 depends on:
ii linux-image-6.1.0-7-amd64 6.1.20-1
linux-image-amd64 recommends no packages.
linux-image-amd64 suggests no packages.
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LC_MONETARY = "en_DE.UTF-8",
LC_COLLATE = "en_DE.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
(gdb) thread apply all bt full
Thread 8 (Thread 1.8 (CPU#7 [running])):
#0 arch_atomic_read (v=0x837c2b4c ) at
arch/x86/include/asm/atomic.h:29
No locals.
#1 atomic_read (v=0x837c2b4c ) at
include/linux/atomic/atomic-instrumented.h:28
No locals.
#2 pv_hybrid_queued_unfair_trylock (lock=0x837c2b4c )
at kernel/locking/qspinlock_paravirt.h:88
val =
#3 __pv_queued_spin_lock_slowpath (lock=0x837c2b4c ,
val=) at kernel/locking/qspinlock.c:446
prev =
next =
node = 0x88813bdf1b40
old =
tail = 2097152
idx = 0
queue =
cnt =
__PTR =
VAL =
_val =
__PTR =
VAL =
__vpp_verify =
_val =
__PTR =
VAL =
__vpp_verify =
pao_ID__ =
pao_tmp__ =
pto_val__ =
pto_tmp__ =
pao_ID__ =
pao_tmp__ =
pto_val__ =
pto_tmp__ =
pao_ID__ =
pao_tmp__ =
pto_val__ =
pto_tmp__ =
#4 0x81a2b6f0 in pv_queued_spin_lock_slowpath (val=7,
lock=0x837c2b4c ) at arch/x86/include/asm/paravirt.h:591
__esi =
__edx =
__edi =
__ecx =
__eax =
#5 queued_spin_lock_slowpath (val=7, lock=0x837c2b4c )
at arch/x86/include/asm/qspinlock.h:51
No locals.
#6 queued_spin_lock (lock=0x837c2b4c ) at
include/asm-generic/qspinlock.h:114
val = 7
val =
#7 do_raw_spin_lock (lock=0x837c2b4c ) at
include/linux/spinlock.h:186
No locals.
#8 __raw_spin_lock (lock=0x837c2b4c ) at
include/linux/spinlock_api_smp.h:134
No locals.
#9 _raw_spin_lock (lock=lock@entry=0x837c2b4c ) at
kernel/locking/spinlock.c:154
No locals.
#10 0x812e1ba7 in spin_lock (lock=0x837c2b4c )
at include/linux/spinlock.h:350
No locals.
#11 alloc_vmap_area (size=size@entry=20480, align=align@entry=16384,
vstart=vstart@entry=18446683600570023936, vend=vend@entry=18446718784942112767,
node=node@entry=-1, gfp_mask=3264, gfp_mask@entry=3520) at mm/vmalloc.c:1634
va = 0x88802dbb05c0
freed = 0
addr =
purged = 0
ret =
retry =
__func__ = "alloc_vmap_area"
#12 0x812e2111 in __get_vm_area_node (size=20480, size@entry=16384,
align=align@entry=16384, shift=shift@entry=12, flags=flags@entry=34,
start=start@entry=18446683600570023936, end=end@entry=18446718784942112767,
node=-1, gfp_mask=3520, caller=0x8109ad0f ) at
mm/vmalloc.c:2501
va =
area = 0x888113d8dfc0
requested_size = 16384
#13 0x812e52c4 in __vmalloc_node_range (size=,
size@entry=16384, align=align@entry=16384, start=,
end=, gfp_mask=gfp_mask@entry=3520, prot=...,
vm_flags=, node=, caller=) at
mm/vmalloc.c:3173
area =
ret =
kasan_flags =
real_size = 16384
real_align = 16384
shift = 12
again =
#14
Bug#1018061: pads: segfault at 3a ip
Bernhard, Just cause I said it was fixed this happens to show up in journalctl: systemd-coredump[3614]: Process 1704 (pads) of user 0 dumped core. Module libsystemd.so.0 from deb systemd-252.5-2.amd64 Stack trace of thread 1704: #0 0x5600f24f6954 print_arp_asset_screen (pads + 0x9954) #1 0x5600f24f66f0 print_arp_asset (pads + 0x96f0) #2 0x7fdc7fdb54f6 n/a (libpcap.so.0.8 + 0x84f6) #3 0x7fdc7fdb58ec n/a (libpcap.so.0.8 + 0x88ec) #4 0x7fdc7fdbcd1d pcap_loop (libpcap.so.0.8 + 0xfd1d) #5 0x5600f24efe5b main_pads (pads + 0x2e5b) #6 0x5600f24ef47b main (pads + 0x247b) #7 0x7fdc7fbec18a __libc_start_call_main (libc.so.6 + 0x2718a) #8 0x7fdc7fbec245 __libc_start_main_impl (libc.so.6 + 0x27245) #9 0x5600f24ef4b1 _start (pads + 0x24b1) ELF object binary architecture: AMD x86-64 Mar 04 14:31:02 DebianTim systemd[1]: systemd-coredump@0-3613-0.service: Deactivated successfully. Well I thought it was fixed :-( -- Tim McConnell On Wed, 2023-03-22 at 09:55 +0100, Bernhard Übelacker wrote: > control: tags -1 +patch > > > Hello Tim, > nice to hear it helps. Therefore adding the patch tag. > > Kind regards, > Bernhard > > > > Am 21.03.23 um 17:53 schrieb Tim McConnell: > > Hi Bernhard, > > I believe the patch has fixed the issue. I haven't seen any > > messages > > about psad since installing the patch. > > Thanks so much for the fix & patience with me. > > >
Bug#1021330: nvidia-cuda-dev appears to break nvidia xorg
Hi Andreas, Yes, so far as i can tell, this was resolved with the inclusion of 525 drivers. Tim On Wed, Mar 22, 2023 at 3:16 AM Andreas Beckmann wrote: > Control: tag -1 moreinfo > > On 06/10/2022 02.33, Timothy Hanson wrote: > > Package: nvidia-cuda-dev > > Version: 11.5.2-2 > > > Today ran apt-get upgrade, including updating nvidia-cuda-dev. The > update > > seems to have broken nvidia xorg driver; proximal reason seemsto be that > it > > pulls in nvidia-tesla-alternative nvidia-tesla-kernel-dkms > libnvidia-tesla- > > cuda1 (and others) which are a conflicting version (510.85.x). Video > driver > > is: > > ii nvidia-kernel-dkms > 470.141.03-2 > > amd64NVIDIA binary kernel module DKMS source > > That was probably a transitional issue while upgrading to new driver > series and/or CUDA tookit. May I assume that this has been solved in the > current versions (525 driver series, CUDA 11.8)? > > Andreas >
Bug#1000130: [htcondor-debian] Bug#1000130: condor: depends on obsolete pcre3 library
Hello, I am trying to get HTCondor 10.3.0 into shape. Then this bug will be resolved. ...Tim On 2/23/23 06:09, Kentaro Hayashi wrote: FYI: It seems that this issue was fixed in version 9.10.0 https://htcondor.readthedocs.io/en/latest/version-history/development-release-series-91.html#version-9-10-0 ___ htcondor-debian mailing list htcondor-deb...@cs.wisc.edu https://lists.cs.wisc.edu/mailman/listinfo/htcondor-debian -- Tim Theisen (he, him, his) Release Manager HTCondor & Open Science Grid Center for High Throughput Computing Department of Computer Sciences University of Wisconsin - Madison 4261 Computer Sciences and Statistics 1210 W Dayton St Madison, WI 53706-1685 +1 608 265 5736
Bug#1018061: pads: segfault at 3a ip
Hi Bernhard,
I believe the patch has fixed the issue. I haven't seen any messages
about psad since installing the patch.
Thanks so much for the fix & patience with me.
--
Tim McConnell
On Wed, 2023-03-15 at 12:10 +0100, Bernhard Übelacker wrote:
> Am 26.02.23 um 16:47 schrieb Tim McConnell:
>
> > Hi Bernhard,
> > The delay is fine, I'm sure it takes a minute to figure it out ;-)
> > and
> > no I didn't have anything other than defaults for GDB set. I'm not
> > a
> > programmer so I don't know all the tricks to GDB or when is best
> > to
> > use them. With that said, how would I go about installing /testing
> > the
> > patch you provide? I'm happy to test it out for you, I just need
> > the
> > knowledge of how to.
> > Thanks!
> >
>
>
> Hello Tim,
> if you are fine with installing a bunch of build dependencies
> you could use following steps to rebuild the package with the patch.
>
> As root:
> # apt build-dep pads
>
> As user:
> $ mkdir -p source/pads
>
> Put attached patch to the new directory and continue as user:
> $ cd source/pads
> $ apt source pads
> $ cd pads-1.2/
> $ patch -p1 < ../pads_print_arp_asset_initialize.patch
> $ dpkg-buildpackage -b
>
> As root (with the directory adjusted to your user):
> # dpkg -i /home/benutzer/source/pads/{pads_1.2-14_amd64.deb,pads-
> dbgsym_1.2-14_amd64.deb}
>
>
> And then see if it still works as expected and see
> if the crash happens again.
>
> Kind regards,
> Bernhard
Bug#1033200: apt, apt-get, aptitude and others have been failing for an extended period.
On 3/19/2023 10:19 AM, WILLIAM ORVILLE RICHMOND wrote: Err:1 http://deb.debian.org/debian bullseye/main amd64 lynx-common all 2.9.0dev.6-3~deb11u1 Connection failed [IP: 199.232.34.132 80] Err:2 http://deb.debian.org/debian bullseye/main amd64 lynx amd64 2.9.0dev.6-3~deb11u1 Connection failed [IP: 199.232.34.132 80] E: Failed to fetch http://security.debian.org/debian-security/pool/updates/main/l/lynx/lynx-common_2.9.0dev.6-3%7edeb11u1_all.deb Connection failed [IP: 199.232.34.132 80] E: Failed to fetch http://security.debian.org/debian-security/pool/updates/main/l/lynx/lynx_2.9.0dev.6-3%7edeb11u1_amd64.deb Connection failed [IP: 199.232.34.132 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? orville@flinta:~$ orville@flinta:~$ orville@flinta:~$ lynx -bash: lynx: command not found orville@flinta:~$ What does /etc/apt/sources.list look like? -- This email has been checked for viruses by Avast antivirus software. www.avast.com
Bug#1018061: pads: segfault at 3a ip
Hi Benhard,
Okay patch installed, the output is in the attached file.
I was already on 1.2-14 so we'll see if the patch helped or if it was
needed by me.
--
Tim McConnell
On Wed, 2023-03-15 at 12:10 +0100, Bernhard Übelacker wrote:
> Am 26.02.23 um 16:47 schrieb Tim McConnell:
>
> > Hi Bernhard,
> > The delay is fine, I'm sure it takes a minute to figure it out ;-)
> > and
> > no I didn't have anything other than defaults for GDB set. I'm not
> > a
> > programmer so I don't know all the tricks to GDB or when is best
> > to
> > use them. With that said, how would I go about installing /testing
> > the
> > patch you provide? I'm happy to test it out for you, I just need
> > the
> > knowledge of how to.
> > Thanks!
> >
>
>
> Hello Tim,
> if you are fine with installing a bunch of build dependencies
> you could use following steps to rebuild the package with the patch.
>
> As root:
> # apt build-dep pads
>
> As user:
> $ mkdir -p source/pads
>
> Put attached patch to the new directory and continue as user:
> $ cd source/pads
> $ apt source pads
> $ cd pads-1.2/
> $ patch -p1 < ../pads_print_arp_asset_initialize.patch
> $ dpkg-buildpackage -b
>
> As root (with the directory adjusted to your user):
> # dpkg -i /home/benutzer/source/pads/{pads_1.2-14_amd64.deb,pads-
> dbgsym_1.2-14_amd64.deb}
>
>
> And then see if it still works as expected and see
> if the crash happens again.
>
> Kind regards,
> Bernhard
| ^~~~
identification.c:325:26: note: in expansion of macro ‘bdata’
325 | strlcat(app, bdata(sig->title.misc), MAX_MISC);
| ^
util.h:56:39: note: expected ‘const char *’ but argument is of type ‘unsigned
char *’
56 | size_t strlcat(char *dst, const char *src, size_t len);
| ^~~
identification.c: In function ‘parse_raw_signature’:
identification.c:130:14: warning: ‘title’ may be used uninitialized
[-Wmaybe-uninitialized]
130 | if (title->qty < 3)
| ~^
identification.c:94:22: note: ‘title’ was declared here
94 | struct bstrList *title;
| ^
identification.c:170:8: warning: ‘pcre_string’ may be used uninitialized
[-Wmaybe-uninitialized]
170 | if (pcre_string != NULL)
|^
identification.c:96:13: note: ‘pcre_string’ was declared here
96 | bstring pcre_string;
| ^~~
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -Wdate-time -D_FORTIFY_SOURCE=2
-g -O2 -ffile-prefix-map=/home/tmick/source/pads/pads-1.2=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall -g -std=gnu89
-c -o packet.o packet.c
In file included from /usr/include/netinet/in.h:21,
from global.h:69,
from packet.h:44,
from packet.c:28:
/usr/include/features.h:194:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE
are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
194 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
_DEFAULT_SOURCE"
| ^~~
packet.c: In function ‘process_arp’:
packet.c:160:46: warning: pointer targets in passing argument 2 of
‘check_arp_asset’ differ in signedness [-Wpointer-sign]
160 | if (check_arp_asset(ip_addr, arph->arp_sha) == 1) {
| ^
| |
| uint8_t * {aka unsigned
char *}
In file included from packet.h:45:
storage.h:58:51: note: expected ‘char *’ but argument is of type ‘uint8_t *’
{aka ‘unsigned char *’}
58 | int check_arp_asset (struct in_addr ip_addr, char mac_addr[MAC_LEN]);
| ~^
packet.c:161:44: warning: pointer targets in passing argument 2 of
‘add_arp_asset’ differ in signedness [-Wpointer-sign]
161 | add_arp_asset(ip_addr, arph->arp_sha, 0);
|^
||
|uint8_t * {aka unsigned char
*}
storage.h:60:50: note: expected ‘char *’ but argument is of type ‘uint8_t *’
{aka ‘unsigned char *’}
60 | void add_arp_asset (struct in_addr ip_addr, char mac_addr[MAC_LEN],
time_t discovered);
| ~^
packet.c:162:47: warning: pointer targets in passing argument 2 of
‘print_arp_asset’ differ in signedness [-Wpointer-sign]
162 | print_arp_asset (ip_addr, arph->arp_sha);
| ^
|
Bug#961884: adding to this
I used ClamTK to schedule a scan every night at 23:00. I would have thought it would be no problem. I also get those messages from clamonacc. Which leaves me with 2 questions, 1. Shouldn't ClamTK auto-exclude the needed directories? 2. How long is normal for scanning a 91GB Home dir? To test if I could run the scan from Clamtk at all I started a scan at 20:30 and left it to run. I came back at 11:30 AM and it was still going. Just how long can I expect these to take? And is there a way to exclude directories? Thanks! -- Tim McConnell
Bug#1018061: pads: segfault at 3a ip
On Sun, 2023-02-26 at 16:03 +0100, Bernhard Übelacker wrote:
> Am 08.02.23 um 19:31 schrieb Tim McConnell:
> > Opppss I thought I had, here it is.
> > bt full
>
>
> Hello Tim,
> sorry for the delay. For some reason the debug information
> for libpcap.so.0.8 was missing in your backtrace (was the
> DEBUGINFOD_URLS variable set in that console?).
>
> But I guess I could fill in the gaps [2].
>
> And I think in function print_arp_asset the variable rec
> might get used uninitialized.
> This is also warned about in the build log [3].
>
> Therefore the crash could possibly avoided with the patch below [1].
>
> Kind regards,
> Bernhard
>
>
>
> [1]
> --- src/output/output.c.orig 2023-02-26 15:19:32.0 +0100
> +++ src/output/output.c 2023-02-26 15:54:54.007679051 +0100
> @@ -182,7 +182,7 @@ int print_arp_asset (struct in_addr ip_a
>
> /* Find Asset */
> ArpAsset *list;
> - ArpAsset *rec;
> + ArpAsset *rec = NULL;
>
> list = (ArpAsset *)get_arp_pointer();
> while (list != NULL) {
>
>
>
> [2]
> (gdb)
> #0 0x5641638af954 in print_arp_asset_screen (rec=0x2a) at
> ./src/output/output-screen.c:115
> #1 0x5641638af6f0 in print_arp_asset (ip_addr=...,
> mac_addr=0x7fa6db692384 "") at ./src/output/output.c:210
> head = 0x5641654a33f0
> list =
> rec = 0x2a
> #2 0x7fa6dbe004f6 in pcap_handle_packet_mmap () at ./pcap-
> linux.c:4072 from /lib/x86_64-linux-gnu/libpcap.so.0.8
> #3 0x7fa6dbe008ec in pcap_read_linux_mmap_v3 () at ./pcap-
> linux.c:4248 from /lib/x86_64-linux-gnu/libpcap.so.0.8
> #4 0x7fa6dbe07d1d in pcap_loop () at ./pcap.c:2923 from
> /lib/x86_64-linux-gnu/libpcap.so.0.8
> #5 0x5641638a8e5b in main_pads () at ./src/pads.c:278
> #6 0x5641638a847b in main (argc=, argv= out>) at ./src/pads.c:491
>
> (gdb) list output.c:210
> 179 int print_arp_asset (struct in_addr ip_addr, char
> mac_addr[MAC_LEN])
> 180 {
> 181 OutputPluginList *head;
> 182
> 183 /* Find Asset */
> 184 ArpAsset *list;
> 185 ArpAsset *rec;
> 186
> 187 list = (ArpAsset *)get_arp_pointer();
> 188 while (list != NULL) {
> 189 if (ip_addr.s_addr == list->ip_addr.s_addr
> 190 && (strcmp(mac_addr, list->mac_addr) == 0)) {
> 191
> 192 /* Found! */
> 193 rec = list;
> 194 break;
> 195 } else {
> 196 list = list->next;
> 197 }
> 198 }
> 199
> 200 /* Make sure that a record was found. */
> 201 if (rec == NULL)
> 202 return 1;
> 203
> 204 /* Cycle through output plugins and print to those that
> are active. */
> 205 head = output_plugin_list;
> 206 while (head != NULL) {
> 207 /* Only print to active plugins. */
> 208 if (head->active == 1) {
> 209 if (head->plugin->print_arp)
> 210 (*head->plugin->print_arp)(rec);
> 211 }
> 212
> 213 head = head->next;
> 214 }
>
>
> [3]
> https://buildd.debian.org/status/fetch.php?pkg=pads=amd64=1.2-14=1665671920=0
> output.c: In function ‘print_arp_asset’:
> output.c:210:18: warning: ‘rec’ may be used uninitialized [-Wmaybe-
> uninitialized]
> 210 | (*head->plugin->print_arp)(rec);
> | ~^~
> output.c:185:15: note: ‘rec’ was declared here
> 185 | ArpAsset *rec;
> | ^~~
>
Hi Bernhard,
The delay is fine, I'm sure it takes a minute to figure it out ;-) and
no I didn't have anything other than defaults for GDB set. I'm not a
programmer so I don't know all the tricks to GDB or when is best to
use them. With that said, how would I go about installing /testing the
patch you provide? I'm happy to test it out for you, I just need the
knowledge of how to.
Thanks!
--
Tim McConnell
Bug#1031179: Acknowledgement (libzvbi-dev: libzvbi.h unusable - missing version.h include)
Upstream issue: https://github.com/zapping-vbi/zvbi/issues/40
Bug#1031179: libzvbi-dev: libzvbi.h unusable - missing version.h include
Package: libzvbi-dev Version: 0.2.40-1 Severity: grave Tags: upstream Justification: renders package unusable Trying to build GStreamer (gst-plugins-bad) against the latest version results in In file included from ../subprojects/gst-plugins-bad/ext/teletextdec/gstteletextdec.h:26, from ../subprojects/gst-plugins-bad/ext/teletextdec/gstteletextdec.c:45: /usr/include/libzvbi.h:28:10: fatal error: version.h: No such file or directory 28 | #include "version.h" | ^~~ This header is not shipped by the libzvbi-dev package. On further investigation it appears to be an upstream bug actually, it also doesn't install the version.h file. Which is probably for the best because installing a version.h file into the general /usr/include directory is probably a bit questionable. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libzvbi-dev depends on: ii libpng-dev 1.6.39-2 ii libzvbi00.2.40-1 libzvbi-dev recommends no packages. libzvbi-dev suggests no packages. -- no debconf information
Bug#1028857: libpsl: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
On Sat, 11 Feb 2023 18:47:04 +0100 Florian Ernst wrote: Of course, updating to 0.21.2 with its "273 changed files with 70,410 additions and 1,392 deletions"[0] feels rather invasive this late in the Debian release cycle, so maybe a more targeted fix could be extracted. These files are mostly test corpora from OSS-Fuzz. So I wouldn't be too bothered, as those are only used with `make check`. Some other changes are updates of the copyright year and meson and msvc build files, both have no influence on the Debian build (autotools/make). I leave it to you to decide about the few remaining changed files. Regards, Tim OpenPGP_signature Description: OpenPGP digital signature
Bug#1018061: pads: segfault at 3a ip
Opppss I thought I had, here it is. bt full #0 0x5641638af954 in print_arp_asset_screen (rec=0x2a) at ./src/output/output-screen.c:115 No locals. #1 0x5641638af6f0 in print_arp_asset (ip_addr=..., mac_addr=0x7fa6db692384 "") at ./src/output/output.c:210 head = 0x5641654a33f0 list = rec = 0x2a #2 0x7fa6dbe004f6 in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #3 0x7fa6dbe008ec in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #4 0x7fa6dbe07d1d in pcap_loop () from /lib/x86_64-linux-gnu/libpcap.so.0.8 No symbol table info available. #5 0x5641638a8e5b in main_pads () at ./src/pads.c:278 No locals. #6 0x5641638a847b in main (argc=, argv=) at ./src/pads.c:491 No locals. (gdb) Quit (gdb) bt full #0 0x5641638af954 in print_arp_asset_screen (rec=0x2a) at ./src/output/output-screen.c:115 No locals. #1 0x5641638af6f0 in print_arp_asset (ip_addr=..., mac_addr=0x7fa6db692384 "") at ./src/output/output.c:210 head = 0x5641654a33f0 list = rec = 0x2a #2 0x7fa6dbe004f6 in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #3 0x7fa6dbe008ec in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #4 0x7fa6dbe07d1d in pcap_loop () from /lib/x86_64-linux-gnu/libpcap.so.0.8 No symbol table info available. #5 0x5641638a8e5b in main_pads () at ./src/pads.c:278 No locals. #6 0x5641638a847b in main (argc=, argv=) at ./src/pads.c:491 No locals. (gdb) #0 0x5641638af954 in print_arp_asset_screen (rec=0x2a) at ./src/output/output-screen.c:115 No locals. #1 0x5641638af6f0 in print_arp_asset (ip_addr=..., mac_addr=0x7fa6db692384 "") at ./src/output/output.c:210 head = 0x5641654a33f0 list = rec = 0x2a #2 0x7fa6dbe004f6 in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #3 0x7fa6dbe008ec in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #4 0x7fa6dbe07d1d in pcap_loop () from /lib/x86_64-linux-gnu/libpcap.so.0.8 No symbol table info available. #5 0x5641638a8e5b in main_pads () at ./src/pads.c:278 No locals. #6 0x5641638a847b in main (argc=, argv=) at ./src/pads.c:491 No locals. (gdb) -- Tim McConnell On Wed, 2023-02-08 at 19:26 +0100, Bernhard Übelacker wrote: > Am 08.02.23 um 18:42 schrieb Tim McConnell: > > Hi Bernhard, > > Okay I did that. Let me know if that was of any use. > > Hello Tim, > could you send the actual output below the `bt full`? > > Kind regards, > Bernhard
Bug#1018061: pads: segfault at 3a ip
Hi Bernhard, Okay I did that. Let me know if that was of any use. -- Tim McConnell On Wed, 2023-02-08 at 16:16 +0100, Bernhard Übelacker wrote: > bt full
Bug#1030857: transmission: New 4.0 version is available
Source: transmission Version: New 4.0 version is available Severity: normal Tags: upstream X-Debbugs-Cc: sti...@gmail.com Dear Maintainer, Transmission team has published new version that has many improvements and fixes. https://github.com/transmission/transmission/releases/tag/4.0.0 Please consider packaging it. Thank you -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1018061: pads: segfault at 3a ip
New Backtrace:
coredumpctl gdb -1
PID: 1546 (pads)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Tue 2023-02-07 10:08:03 CST (3h 14min ago)
Command Line: /usr/bin/pads -D -c /etc/pads/pads.conf
Executable: /usr/bin/pads
Control Group: /system.slice/pads.service
Unit: pads.service
Slice: system.slice
Boot ID: 90f7db29bc44436f8b4d1a2cbfc52a5c
Machine ID: dacda8ffae4a44148edc6518f73d4b00
Hostname: DebianTim
Storage:
/var/lib/systemd/coredump/core.pads.0.90f7db29bc44436f8b4d1a2cbfc52a5c.
1546.167578608300.zst (present)
Size on Disk: 329.8K
Message: Process 1546 (pads) of user 0 dumped core.
Module libsystemd.so.0 from deb systemd-252.5-2.amd64
Stack trace of thread 1546:
#0 0x5641638af954 print_arp_asset_screen (pads +
0x9954)
#1 0x5641638af6f0 print_arp_asset (pads + 0x96f0)
#2 0x7fa6dbe004f6 n/a (libpcap.so.0.8 + 0x84f6)
#3 0x7fa6dbe008ec n/a (libpcap.so.0.8 + 0x88ec)
#4 0x7fa6dbe07d1d pcap_loop (libpcap.so.0.8 +
0xfd1d)
#5 0x5641638a8e5b main_pads (pads + 0x2e5b)
#6 0x5641638a847b main (pads + 0x247b)
#7 0x7fa6dbc3718a __libc_start_call_main
(libc.so.6 + 0x2718a)
#8 0x7fa6dbc37245 __libc_start_main_impl
(libc.so.6 + 0x27245)
#9 0x5641638a84b1 _start (pads + 0x24b1)
ELF object binary architecture: AMD x86-64
--
Tim McConnell
On Tue, 2022-09-27 at 10:32 +0200, Bernhard Übelacker wrote:
> Hello Tim,
> I tried to have a look at those two dmesg lines and it seems
> they point to the function print_arp_asset_screen, line 115 [1],
> where parameter rec is dereferenced unconditionally.
>
> However, if it would be possible to install systemd-coredump then
> a backtrace of those crashes should be printed to the journal.
> This would give a way better information as the two dmesg lines
> alone,
> as it would also show the functions calling print_arp_asset_screen
> and therefore leading to the crash.
>
> The link [2] might give some more hints to collect
> more information for the maintainer.
>
> Kind regards,
> Bernhard
>
>
> [1]
> https://sources.debian.org/src/pads/1.2-13/src/output/output-screen.c/#L115
> 112 print_arp_asset_screen (ArpAsset *rec)
> 113 {
> 114 /* Print to Screen */
> 115 if(rec->mac_resolved != NULL) {
> 116fprintf(stdout, "[*] Asset Found: IP Address - %s /
> MAC Address - %s (%s)\n",
>
> [2] https://wiki.debian.org/HowToGetABacktrace
Bug#1019865: evolution Hangs and goes to 100% CPU usage on compose
Am Sonntag, dem 15.01.2023 um 13:10 -0500 schrieb Jeremy Bicha: > On Sun, Dec 11, 2022 at 9:29 AM Jeremy Bicha > wrote: > > Could y'all verify whether you still have this issue? > > > > Please upgrade to Evolution 3.46.2 which just landed in Testing > > today. > > Please log out and log back in to make sure you're running the > > latest > > version of evolution-data-server also. > > Could anyone affected by this issue please verify whether the issue > still happens with 3.46.2 or 3.46.3? > > Also, if you're running Unstable or Testing, you may get faster > results by reporting issues upstream: > > https://gitlab.gnome.org/GNOME/evolution/-/issues > > Thank you, > Jeremy Bicha Seems fixed for me, I'm on 3.46.3-1 right now.
Bug#1028857: libpsl: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
Hi Lucas, maybe @dkg has time to update the packaging ? Regards, Tim On 14.01.23 23:51, Lucas Nussbaum wrote: Hi Tim, I can't find that new version (0.21.2) in Debian? Lucas On 14/01/23 at 20:19 +0100, Tim Rühsen wrote: Hey Lucas, could you try with the latest release v0.21.2 ? I am working on Debian sid, and can't reproduce the issue. But I will examine the logs and/or try to build from the debian sources (in the next days). Regards, Tim On 14.01.23 13:59, Lucas Nussbaum wrote: Source: libpsl Version: 0.21.0-1.2 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20230113 ftbfs-bookworm Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): make[5]: Entering directory '/<>/tests' PASS: test-is-public-builtin PASS: test-registrable-domain PASS: test-is-public PASS: test-is-cookie-domain-acceptable FAIL: test-is-public-all = libpsl 0.21.0: tests/test-suite.log = # TOTAL: 5 # PASS: 4 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test-is-public-all loaded 9458 suffixes and 8 exceptions builtin PSL has 9458 suffixes and 8 exceptions psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) Summary: 28 out of 290640 tests failed FAIL test-is-public-all (exit status: 1) Testsuite summary for libpsl 0.21.0 # TOTAL: 5 # PASS: 4 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ER
Bug#1028857: libpsl: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
Hey Lucas, could you try with the latest release v0.21.2 ? I am working on Debian sid, and can't reproduce the issue. But I will examine the logs and/or try to build from the debian sources (in the next days). Regards, Tim On 14.01.23 13:59, Lucas Nussbaum wrote: Source: libpsl Version: 0.21.0-1.2 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20230113 ftbfs-bookworm Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): make[5]: Entering directory '/<>/tests' PASS: test-is-public-builtin PASS: test-registrable-domain PASS: test-is-public PASS: test-is-cookie-domain-acceptable FAIL: test-is-public-all = libpsl 0.21.0: tests/test-suite.log = # TOTAL: 5 # PASS: 4 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test-is-public-all loaded 9458 suffixes and 8 exceptions builtin PSL has 9458 suffixes and 8 exceptions psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, PSL_TYPE_PRIVATE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, PSL_TYPE_ANY)=0 (expected 1) psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1) Summary: 28 out of 290640 tests failed FAIL test-is-public-all (exit status: 1) Testsuite summary for libpsl 0.21.0 # TOTAL: 5 # PASS: 4 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See tests/test-suite.log Please report to tim.rueh...@gmx.de make[5]: *** [Makefile:802: test-suite.log] Error 1 make[5]: L
Bug#1028418: Bug#1028411: Bug#1028418: signed package uploaded
Control: tags -1 - moreinfo Op 11-01-2023 om 22:01 schreef Bastian Germann: Control: tags -1 moreinfo On Wed, 11 Jan 2023 20:59:21 +0100 Tim Kuijsten wrote: I have uploaded a signed version of the package. To access further information about this package, please visit the following URL: https://netsend.nl/mongovi/v2.0.0/ Alternatively, you can download the package with 'dget' using this command: dget -x https://netsend.nl/mongovi/v2.0.0/mongovi_2.0.0-1.dsc The package build fails on amd64: ./testshorten FAIL: 한 2 = exit: -1, expected: 2 FAIL: 한 3 = exit: -1, expected: 2 FAIL: 한한 2 = exit: -1, expected: 2 FAIL: 한한 3 = exit: -1, expected: 2 FAIL: 한한 4 = exit: -1, expected: 4 FAIL: 4 = exit: -1, expected: 4 FAIL: 5 = exit: -1, expected: 4 FAIL: 6 = exit: -1, expected: 6 FAIL: 7 = exit: -1, expected: 6 FAIL: 8 = exit: -1, expected: 8 FAIL: £ 2 = exit: -1, expected: 1 FAIL: £한 2 = exit: -1, expected: 2 FAIL: £한 3 = exit: -1, expected: 3 FAIL: £한한 2 = exit: -1, expected: 2 FAIL: £한한 3 = exit: -1, expected: 3 FAIL: £한한 4 = exit: -1, expected: 3 FAIL: £한한 5 = exit: -1, expected: 5 FAIL: 한£ 2 = exit: -1, expected: 2 FAIL: 한£ 3 = exit: -1, expected: 3 FAIL: 한한£ 2 = exit: -1, expected: 2 FAIL: 한한£ 3 = exit: -1, expected: 3 FAIL: 한한£ 4 = exit: -1, expected: 3 FAIL: 한한£ 5 = exit: -1, expected: 5 FAIL: £ह€한͈＄ 4 = exit: -1, expected: 4 FAIL: £ह€한͈＄ 5 = exit: -1, expected: 5 FAIL: £ह€한͈＄ 6 = exit: -1, expected: 6 FAIL: £ह€한͈＄ 7 = exit: -1, expected: 7 FAIL: £ह€한͈＄ 8 = exit: -1, expected: 8 FAIL: £ह€한͈＄£ह€한͈＄ ＄ 8 = exit: -1, expected: 8 FAIL: £＄ह€ 한͈＄£ह€한͈＄ 8 = exit: -1, expected: 8 FAIL: ＄ £ह€한͈＄£ह€한͈＄ 8 = exit: -1, expected: 8 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 8 = exit: -1, expected: 8 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 9 = exit: -1, expected: 9 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 10 = exit: -1, expected: 10 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 11 = exit: -1, expected: 11 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 12 = exit: -1, expected: 12 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 13 = exit: -1, expected: 13 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 14 = exit: -1, expected: 13 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 15 = exit: -1, expected: 15 make[1]: *** [Makefile:51: test] Error 39 make[1]: Leaving directory '/home/bage/mongovi-2.0.0' dh_auto_test: error: make -j4 test returned exit code 2 Please untag moreinfo when you have fixed this. Hi Bastian, thanks for your time! I have updated debian/rules to set LC_CTYPE=C.UTF-8, regenerated the packages and associated files and now the UTF-8 tests should pass. See the updated files in https://netsend.nl/mongovi/v2.0.0/
Bug#1028411: Bug#1028418: signed package uploaded
Control: tags - moreinfo Op 11-01-2023 om 22:01 schreef Bastian Germann: Control: tags -1 moreinfo On Wed, 11 Jan 2023 20:59:21 +0100 Tim Kuijsten wrote: I have uploaded a signed version of the package. To access further information about this package, please visit the following URL: https://netsend.nl/mongovi/v2.0.0/ Alternatively, you can download the package with 'dget' using this command: dget -x https://netsend.nl/mongovi/v2.0.0/mongovi_2.0.0-1.dsc The package build fails on amd64: ./testshorten FAIL: 한 2 = exit: -1, expected: 2 FAIL: 한 3 = exit: -1, expected: 2 FAIL: 한한 2 = exit: -1, expected: 2 FAIL: 한한 3 = exit: -1, expected: 2 FAIL: 한한 4 = exit: -1, expected: 4 FAIL: 4 = exit: -1, expected: 4 FAIL: 5 = exit: -1, expected: 4 FAIL: 6 = exit: -1, expected: 6 FAIL: 7 = exit: -1, expected: 6 FAIL: 8 = exit: -1, expected: 8 FAIL: £ 2 = exit: -1, expected: 1 FAIL: £한 2 = exit: -1, expected: 2 FAIL: £한 3 = exit: -1, expected: 3 FAIL: £한한 2 = exit: -1, expected: 2 FAIL: £한한 3 = exit: -1, expected: 3 FAIL: £한한 4 = exit: -1, expected: 3 FAIL: £한한 5 = exit: -1, expected: 5 FAIL: 한£ 2 = exit: -1, expected: 2 FAIL: 한£ 3 = exit: -1, expected: 3 FAIL: 한한£ 2 = exit: -1, expected: 2 FAIL: 한한£ 3 = exit: -1, expected: 3 FAIL: 한한£ 4 = exit: -1, expected: 3 FAIL: 한한£ 5 = exit: -1, expected: 5 FAIL: £ह€한͈＄ 4 = exit: -1, expected: 4 FAIL: £ह€한͈＄ 5 = exit: -1, expected: 5 FAIL: £ह€한͈＄ 6 = exit: -1, expected: 6 FAIL: £ह€한͈＄ 7 = exit: -1, expected: 7 FAIL: £ह€한͈＄ 8 = exit: -1, expected: 8 FAIL: £ह€한͈＄£ह€한͈＄ ＄ 8 = exit: -1, expected: 8 FAIL: £＄ह€ 한͈＄£ह€한͈＄ 8 = exit: -1, expected: 8 FAIL: ＄ £ह€한͈＄£ह€한͈＄ 8 = exit: -1, expected: 8 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 8 = exit: -1, expected: 8 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 9 = exit: -1, expected: 9 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 10 = exit: -1, expected: 10 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 11 = exit: -1, expected: 11 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 12 = exit: -1, expected: 12 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 13 = exit: -1, expected: 13 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 14 = exit: -1, expected: 13 FAIL: ＄£ह€ 한͈＄£ह€한͈＄ 15 = exit: -1, expected: 15 make[1]: *** [Makefile:51: test] Error 39 make[1]: Leaving directory '/home/bage/mongovi-2.0.0' dh_auto_test: error: make -j4 test returned exit code 2 Please untag moreinfo when you have fixed this. Hi Bastian, thanks for your time! I have updated debian/rules to set LC_CTYPE=C.UTF-8, regenerated the packages and associated files and now the UTF-8 tests should pass. See the updated files in https://netsend.nl/mongovi/v2.0.0/
Bug#1015764: logwatch: get random errors about Use of uninitialized value in Exim
This seems to have fixed itself. Please close this. -- Tim McConnell On Wed, 2022-07-20 at 15:20 -0500, Tim McConnell wrote: > Package: logwatch > Version: 7.5.6-1 > Severity: normal > X-Debbugs-Cc: tmcconnell...@gmail.com > > Dear Maintainer, > > What led up to the situation? Not sure, these started randomly > appearing in the > email that is sent. It will be okay one report, the next one has > these > errors(?) > > What exactly did you do (or not do) that was effective (or > ineffective)? > Nothing I know of was either. > > What was the outcome of this action?The error in the nightly email > reads: > - EXIM Begin > > Use of uninitialized value $SelfSigned in concatenation (.) or > string at > /usr/share/logwatch/scripts/services/exim line 334, line 420. > > --- Self-Signed Certificate in use ( Time(s)) > > -- EXIM End - > The line numbers change also. > > What outcome did you expect instead?To see: > - EXIM Begin > > > --- Self-Signed Certificate in use (2 Time(s)) > > -- EXIM End - > > > > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.18.0-2-amd64 (SMP w/1 CPU thread; 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 logwatch depends on: > ii exim4-daemon-light [mail-transport-agent] 4.96-3 > ii perl 5.34.0-5 > > Versions of packages logwatch recommends: > ii libdate-manip-perl 6.88-1 > ii libsys-cpu-perl 0.61-3 > ii libsys-meminfo-perl 0.99-2 > > logwatch suggests no packages. > > -- no debconf information
Bug#1028418: signed package uploaded
I have uploaded a signed version of the package. To access further information about this package, please visit the following URL: https://netsend.nl/mongovi/v2.0.0/ Alternatively, you can download the package with 'dget' using this command: dget -x https://netsend.nl/mongovi/v2.0.0/mongovi_2.0.0-1.dsc
Bug#1025784: [debian-mysql] Bug#1025784: Acknowledgement (mariadb-server-core-10.6: Can't connect to local server through socket '/run/mysqld/mysqld.sock' (111))
Hi Faustin, I do have libpam-tempdir installed: sudo dpkg -l | grep libpam-tmpdir [sudo] password for tmick: ii libpam-tmpdir 0.09+b2 amd64automatic per-user temporary directories However I was getting different errors. Like so: RROR 2013 (HY000): Lost connection to server at 'handshake: reading initial communication packet', system error: 104 and I have to use 'sudo systemctl start mariadb.socket' instead of 'sudo systemctl start mariadb.service' but it has to be restarted if authentication fails. And 2022-12-30 14:48:23 0 [ERROR] InnoDB: Operating system error number 13 in a file operation. 2022-12-30 14:48:23 0 [ERROR] InnoDB: The error means mariadbd does not have the access rights to the directory. MariaDB can't start because it can't read your files, the logs state it very clearly: Likely, you created the DB files and folders with the wrong permissions. Please run : chown -R mysql:mysql /var/lib/mysql to fix the issue and restart MariaDB again which allowed the DB to start etc. I then had to initialize it with the install_db command. So I'm not sure if it's a duplicate of the bug you mention, I'll leave that to you to decide. Thanks! -- Tim McConnell On Wed, 2023-01-11 at 10:52 +0100, Faustin Lammler wrote: > Hi Tim! > > Tim McConnell , > 10/01/2023 – 15:49:20 (-0600): > > > Hi Faustin, > > Steps to recreate: > > 1.Install Mariadb client/server > > 2. Attempt to run mysql -u root -p > > 3. fail to be able to login > > On a clean installation, I can't reproduce the problem with those > steps > and this is heavily tested in our CI pipelines. So, my best guess is > that there is something else with your setup that caused the problem. > > I can't be sure but what you described also in the mailing list makes > me > think of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022994, > is > it possible that you had libpam-tmpdir package installed before > installing MariaDB? > > You can verify with `dpkg -l | grep libpam-tmpdir`. > > If that's the case, then this will be fixed in the next release, see: > https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/cde8b8613e08ecb8d5f4a5de09d34418576d3040 > > And #1025784 should be marked as duplicate of #1022994. > > Cheers! >
Bug#1025784: [debian-mysql] Bug#1025784: Acknowledgement (mariadb-server-core-10.6: Can't connect to local server through socket '/run/mysqld/mysqld.sock' (111))
Hi Faustin, Steps to recreate: 1.Install Mariadb client/server 2. Attempt to run mysql -u root -p 3. fail to be able to login Note I have the problem corrected, I used Maria-discuss mailing list to get the answer. Steps to fix: run mysql_install_db and then chown -R mysql:mysql /var/lib/mysql to fix the issue and restart MariaDB again. It's working now. I'm unsure why the permissions were wrong from the install, I thought dpkg and the alternatives were supposed to set that "auto-magically". -- Tim McConnell On Tue, 2023-01-10 at 12:51 +0100, Faustin Lammler wrote: > Hi Tim! > Can you explain the steps you followed so I can try to reproduce > this? > > From your logs, it seems that your system tables are missing > (mysql.db) > so it may be a problem with your datadir (normally /var/lib/mysql). > > You may want to recreate those tables, see: > https://mariadb.com/kb/en/installing-system-tables-mysql_install_db/ > > Before touching your datadir, please make sure that you have backups. > > Cheers! >
Bug#1028418: RFS: mongovi/2.0.0-1 ITP -- mongovi - cli for mongodb
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "mongovi": * Package name : mongovi Version : 2.0.0-1 Upstream contact : Tim Kuijsten * URL : https://github.com/timkuijsten/mongovi * License : ISC * Vcs : https://github.com/timkuijsten/mongovi.git Section : database The source builds the following binary packages: mongovi - command line interface for MongoDB To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mongovi/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mongovi/mongovi_2.0.0-1.dsc Changes since the last upload: This is a new package. (a previous attempt for version 1.0.0 six years ago stalled: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845586) The current ITP is bug #1028411: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028411 Kind regards, Tim
Bug#1028411: this issue supersedes bug #845586
This issue supersedes bug #845586 which was an attempt to package mongovi v1.0.0 that stalled. 845586: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845586
Bug#1028411: ITP: mongovi -- mongovi is a command line interface for MongoDB
Package: wnpp Severity: wishlist Owner: Tim Kuijsten X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: mongovi Version : 2.0.0 Upstream Author : Tim Kuijsten * URL : https://github.com/timkuijsten/mongovi * License : ISC Programming Lang: C Description : mongovi is a command line interface for MongoDB mongovi is a command line interface for MongoDB. Features: * easy integration into shell pipelines by reading and writing MongoDB Extended JSON via stdin/stdout * move around databases and collections using the common `cd` idiom * easy and secure MongoDB authentication using ~/.mongovi * emacs-like and vi-like key bindings * tab-completion of commands, databases and collections
Bug#1012612: texinfo: Info documentation links to missing "pod2texi" manual
On Mon, Jan 09, 2023 at 07:45:04AM +0100, Hilmar Preuße wrote: > I've uploaded texinfo 7.0.1-3 to Debian experimental. Could you install > it and check if it solves the issue? Thanks! I downloaded the texinfo and texinfo-lib packages from the experimental repository and installed them. The issue is not solved: - /usr/share/info/dir still mentions "(pod2texi)Invoking pod2texi." - /usr/share/info/texinfo.info.gz still includes that link in its START-INFO-DIR-ENTRY section. - There's still no /usr/share/info/pod2texi.info(.gz) file Thank you for your packaging work! Tim.
Bug#1027921: linux-image-5.10.0-20-amd64: aacraid's expose_physicals=-1 is not functional
Hi Renato On 1/4/23 16:39, Renato Gallo wrote: 5.10 should be EOL by now According to https://www.kernel.org/category/releases.html, Linux 5.10 is supported until 2026. Whether a fix for this bug qualifies as an "important bugfix" acceptable for a LTS kernel I can't tell. In any case, 5.10 is the stock kernel for Debian Bullseye and thus I wanted to report the issue, if only to ensure it is tracked, even if the/a fix doesn't make the cut for Bullseye. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duester...@woltlab.com www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P
Bug#1027921: linux-image-5.10.0-20-amd64: aacraid's expose_physicals=-1 is not functional
Dear Maintainer, Forgot to include in my initial report that I found the workaround using this (German) thread in the Proxmox Support Forum: https://forum.proxmox.com/threads/adaptec-aacraid-expose_physicals-kernelbug.63256/ The thread is fairly light on details, but it appears to indicate the the issue already existed with Linux 5.3. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duester...@woltlab.com www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P
Bug#1027921: linux-image-5.10.0-20-amd64: aacraid's expose_physicals=-1 is not functional
Package: src:linux
Version: 5.10.158-2
Severity: normal
X-Debbugs-Cc: duester...@woltlab.com
Dear Maintainer,
after upgrading my server from Debian Buster to Debian Bullseye, I
noticed that the underlying devices attached to the Adaptec 6405E raid
controller were no longer exposed via the /dev/sgX devices and thus
reading the SMART values was no longer possible:
$ lsscsi
[0:0:0:0]diskAdaptec *redacted* V1.0 /dev/sda
[0:3:0:0]enclosu ADAPTEC Virtual SGPIO -
Booting into the Linux 4.19 kernel from Debian Buster correctly exposed
the devices with the new userland, indicating a Kernel issue.
I was able to work around the issue by adding the following
configuration to /etc/modprobe.d/:
options aacraid expose_physicals=1
After setting this configuration and rebooting the server the devices
are properly visible as they were before:
$ lsscsi
[0:0:0:0]diskAdaptec *redacted* V1.0 /dev/sda
[0:1:0:0]diskATA *redacted* /dev/sdb
[0:1:1:0]diskATA *redacted* /dev/sdc
[0:3:0:0]enclosu ADAPTEC Virtual SGPIO -
Unfortunately the setting `1` allows direct write access to the devices,
whereas the previous and to my understanding the default setting of `-1`
only allows read access, making this a safer option.
It appears that aacraid's `expose_physicals=-1` option got broken
somewhere between Linux 4.19 and 5.10.
Best regards
-- Package-specific info:
** Version:
Linux version 5.10.0-20-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP
Debian 5.10.158-2 (2022-12-13)
** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-20-amd64 root=ZFS=rpool/ROOT/debian ro boot=zfs
swapaccount=1 quiet
** Tainted: POE (12289)
* proprietary module was loaded
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
Unable to read kernel log; any relevant messages should be attached
** Model information
sys_vendor: Supermicro
product_name: X10SLH-F/X10SLM+-F
product_version: 0123456789
chassis_vendor: Supermicro
chassis_version: 0123456789
bios_vendor: American Megatrends Inc.
bios_version: 3.2a
board_vendor: Supermicro
board_name: X10SLH-F/X10SLM+-F
board_version: 1.02
** Loaded modules:
nft_reject_inet
nf_reject_ipv4
nf_reject_ipv6
nft_reject
nft_counter
intel_rapl_msr
intel_rapl_common
ipmi_ssif
nft_ct
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
kvm
ext4
irqbypass
ghash_clmulni_intel
crc16
mbcache
jbd2
aesni_intel
libaes
crypto_simd
cryptd
ast
glue_helper
drm_vram_helper
drm_ttm_helper
rapl
ttm
intel_cstate
intel_uncore
drm_kms_helper
pcspkr
joydev
at24
intel_pch_thermal
evdev
mei_me
cec
iTCO_wdt
mei
intel_pmc_bxt
sg
iTCO_vendor_support
watchdog
ie31200_edac
acpi_ipmi
ipmi_si
ipmi_devintf
ipmi_msghandler
acpi_pad
button
nf_tables
libcrc32c
crc32c_generic
nfnetlink
drm
fuse
configfs
ip_tables
x_tables
autofs4
hid_generic
usbhid
hid
zfs(POE)
zunicode(POE)
zzstd(OE)
zlua(OE)
zavl(POE)
icp(POE)
zcommon(POE)
znvpair(POE)
spl(OE)
ses
enclosure
sd_mod
scsi_transport_sas
t10_pi
crc_t10dif
crct10dif_generic
ahci
libahci
xhci_pci
libata
xhci_hcd
ehci_pci
crct10dif_pclmul
crct10dif_common
ehci_hcd
aacraid
crc32_pclmul
lpc_ich
igb
i2c_i801
usbcore
i2c_smbus
scsi_mod
crc32c_intel
i2c_algo_bit
dca
ptp
pps_core
usb_common
fan
video
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3 Processor DRAM
Controller [8086:0c08] (rev 06)
Subsystem: Super Micro Computer Inc Xeon E3-1200 v3 Processor DRAM
Controller [15d9:0803]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
Kernel driver in use: ie31200_edac
Kernel modules: ie31200_edac
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor PCI Express x16 Controller [8086:0c01] (rev 06) (prog-if 00 [Normal
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [88] Subsystem: Super Micro Computer Inc Xeon E3-1200
v3/4th Gen Core Processor PCI Express x16 Controller [15d9:0803]
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00218 Data:
Capabilities: [a0] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 256
Bug#1027443: python3-pyqt6: Package cannot be installed. It depends on 'qt6-base-abi =6.3.1' which does not exist.
Hi Dmitry, Wow that's great news, thanks! Tim On Sat, 31 Dec 2022 20:59:57 +0300 Dmitry Shachnev wrote: > Hi Tim! > > On Sat, Dec 31, 2022 at 03:10:10PM +, Tim Magee wrote: > > Package: python3-pyqt6 > > Version: 6.4.0-1 > > Severity: important > > > > Dear Maintainer, > > > > I'm using SID, so I realise that I've brought this on myself, but > > the package probably still needs fixing before it gets assimilated > > into a release. > > > > I wanted to install python3-pyqt6 using synaptic. > > > > I first tried using synaptic: select the package, mark for > > installation, apply -- the usual. > > > > When I saw that qt6-base-abi was missing I reloaded package > > information. qt6-base-abi was still missing but in an access of > > optimism I retried the install anyway, without success, same reason. > > We are in process of upgrading Qt from 6.3 to 6.4 [1], so some > packages are temporarily uninstallable. > > It will be resolved in a few days. > > [1]: https://release.debian.org/transitions/html/qt6baseabi-6.4.2.html > > -- > Dmitry Shachnev -- Tim Magee
Bug#1027443: python3-pyqt6: Package cannot be installed. It depends on 'qt6-base-abi =6.3.1' which does not exist.
Package: python3-pyqt6 Version: 6.4.0-1 Severity: important Dear Maintainer, I'm using SID, so I realise that I've brought this on myself, but the package probably still needs fixing before it gets assimilated into a release. I wanted to install python3-pyqt6 using synaptic. I first tried using synaptic: select the package, mark for installation, apply -- the usual. When I saw that qt6-base-abi was missing I reloaded package information. qt6-base-abi was still missing but in an access of optimism I retried the install anyway, without success, same reason. Desperation move: I dropped to CLI and tried 'sudo apt install python3-qt6', without much hope of success. My lack of hope was justified ;) My expected outcome: python3-pyqt6 to be installed, and perhaps some dependencies. I've marked this 'important' because it fits the description in reportbug: it's prevented the package from being installed, although probably only for my fellow SIDianites. Thanks! Tim -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pyqt6 depends on: ii libc6 2.36-7 ii libqt6core6 [qt6-base-abi] 6.4.2+dfsg~rc1-3 ii libqt6dbus6 6.4.2+dfsg~rc1-3 ii libqt6gui6 6.4.2+dfsg~rc1-3 ii libqt6network6 6.4.2+dfsg~rc1-3 ii libqt6opengl6 6.4.2+dfsg~rc1-3 ii libqt6openglwidgets66.4.2+dfsg~rc1-3 ii libqt6printsupport6 6.4.2+dfsg~rc1-3 ii libqt6sql6 6.4.2+dfsg~rc1-3 ii libqt6test6 6.4.2+dfsg~rc1-3 ii libqt6widgets6 6.4.2+dfsg~rc1-3 ii libqt6xml6 6.4.2+dfsg~rc1-3 ii libstdc++6 12.2.0-11 ii python3 3.10.6-3+b1 ii python3-pyqt6.sip 13.4.0-2+b1 python3-pyqt6 recommends no packages. python3-pyqt6 suggests no packages.
