Bug#1010714: sane-pixma: sane can't find scanner
tags 1010714 + moreinfo thanks Hello Alexandre, thank you for spending your time helping to make Debian better with this bug report. Please attach the config files - /etc/sane.d/pixma.conf - /etc/sane.d/dll.conf and the output of export SANE_DEBUG_BJNP="5" && scanimage -L CU Jörg Am Samstag, dem 07.05.2022 um 23:00 -0300 schrieb Alexandre Lymberopoulos: > Package: libsane1 > Version: 1.1.1-5 > Severity: normal > File: sane-pixma > > Dear Maintainer, > > Any software here usanig sane can't detect my PIXMA MG3510 over > wireless network. For testing purposes I installed the proprietary > software from Canon and eveything woked ok. > > I may provide any futher information upon request. > > Best, Alexandre > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable- > security') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages libsane1:amd64 depends on: > ii acl 2.3.1-1 > ii adduser 3.121 > ii libavahi-client3 0.8-5 > ii libavahi-common3 0.8-5 > ii libc6 2.33-7 > ii libcairo2 1.16.0-5 > ii libcurl3-gnutls 7.83.0-1 > ii libgcc-s1 12-20220428-1 > ii libglib2.0-0 2.72.1-1 > ii libgphoto2-6 2.5.27-1 > ii libgphoto2-port12 2.5.27-1 > ii libieee1284-3 0.2.11-14 > ii libjpeg62-turbo 1:2.1.2-1 > ii libpng16-16 1.6.37-5 > ii libpoppler-glib8 22.02.0-3 > ii libsane-common 1.1.1-5 > ii libsnmp40 5.9.1+dfsg-1+b1 > ii libstdc++6 12-20220428-1 > ii libtiff5 4.3.0-7 > ii libusb-1.0-0 2:1.0.26-1 > ii libxml2 2.9.13+dfsg-1+b1 > ii udev 250.4-1 > > Versions of packages libsane1:amd64 recommends: > pn ipp-usb > pn sane-airscan > ii sane-utils 1.1.1-5 > > Versions of packages libsane1:amd64 suggests: > ii avahi-daemon 0.8-5 > ii hplip 3.22.2+dfsg0-1 > > -- no debconf information -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#1010713: simple-scan: Scanner not detected
Hello Alexandre, thank you for spending your time helping to make Debian better with this bug report. You have open the same issue for libsane1, which is the right package. So I close this bug. CU Jörg Am Samstag, dem 07.05.2022 um 22:41 -0300 schrieb Alexandre Lymberopoulos: > Package: simple-scan > Version: 42.0-1 > Severity: normal > > Dear Maintainer, > > Not sure to who I should write, so I chose the toplevel software that > allowed me to notice the problem. > > When I open simple-scan it can't detct my PIXMA MG-3510 scanner > anymore (it used to work). For testing purposes I installed the > proprietary software from Canon and it recognizes the device and > scans > correctly. > > I may provide any further information uopn request. > > Best, Alexandre > > -- Package-specific info: > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable- > security') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages simple-scan depends on: > ii dbus-user-session [default-dbus-session-bus] 1.14.0-1 > ii dbus-x11 [dbus-session-bus] 1.14.0-1 > ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 > ii libc6 2.33-7 > ii libcairo2 1.16.0-5 > ii libcolord2 1.4.6-1 > ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1 > ii libglib2.0-0 2.72.1-1 > ii libgtk-3-0 3.24.33-1 > ii libgusb2 0.3.10-1 > ii libhandy-1-0 1.6.2-1 > ii libpackagekit-glib2-18 1.2.5-3 > ii libsane1 1.1.1-5 > ii libwebp7 1.2.2-2+b1 > ii libwebpmux3 1.2.2-2+b1 > ii xdg-utils 1.1.3-4.1 > ii zlib1g 1:1.2.11.dfsg-4 > > simple-scan recommends no packages. > > simple-scan suggests no packages. > > -- no debconf information -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#968670: dwz: Fails with "Unknown DWARF DW_OP_1" (more info needed)
On Sat, 6 Feb 2021 08:54:57 +0100 Dennis Filder wrote: Control: tag -1 - patch + moreinfo After looking into this some more, I don't think this is necessarily a bug in dwz, but it could also be either someone using rogue DW_OP_* definitions with values 0x00 and 0x01 or a buggy compiler/assembler backend emitting junk. While applying the patch probably won't hurt, it will most probably not help either. This prob now started appearing on ppc64el and s390x buildds on regular bullseye builds, f.e. https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=s390x&ver=1%3A7.0%2Bdfsg-2%7Ebpo11%2B1&stamp=1651985111&raw=0 https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=ppc64el&ver=1%3A7.0%2Bdfsg-2%7Ebpo11%2B1&stamp=1651980296&raw=0 dh_dwz -a -a dwz: debian/qemu-system-misc/usr/bin/qemu-system-alpha: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-hppa: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-riscv32: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-riscv64: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-s390x: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-sh4: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-sh4eb: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-xtensa: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-xtensaeb: Unknown DWARF DW_OP_0 dh_dwz: error: dwz -mdebian/qemu-system-misc/usr/lib/debug/.dwz/powerpc64le-linux-gnu/qemu-system-misc.debug -M/usr/lib/debug/.dwz/powerpc64le-linux-gnu/qemu-system-misc.debug -- debian/qemu-system-misc/usr/bin/qemu-system-alpha debian/qemu-system-misc/usr/bin/qemu-system-avr debian/qemu-system-misc/usr/bin/qemu-system-cris debian/qemu-system-misc/usr/bin/qemu-system-hppa debian/qemu-system-misc/usr/bin/qemu-system-m68k debian/qemu-system-misc/usr/bin/qemu-system-microblaze debian/qemu-system-misc/usr/bin/qemu-system-microblazeel debian/qemu-system-misc/usr/bin/qemu-system-nios2 debian/qemu-system-misc/usr/bin/qemu-system-or1k debian/qemu-system-misc/usr/bin/qemu-system-riscv32 debian/qemu-system-misc/usr/bin/qemu-system-riscv64 debian/qemu-system-misc/usr/bin/qemu-system-rx debian/qemu-system-misc/usr/bin/qemu-system-s390x debian/qemu-system-misc/usr/bin/qemu-system-sh4 debian/qemu-system-misc/usr/bin/qemu-system-sh4eb debian/qemu-system-misc/usr/bin/qemu-system-tricore debian/qemu-system-misc/usr/bin/qemu-system-xtensa debian/qemu-system-misc/usr/bin/qemu-system-xtensaeb returned exit code 1 make[1]: *** [debian/rules:636: install-arch] Error 25 (it is DW_OP_0 not DW_OP_1, but since the above note suggests both should not be seen "in wild", maybe these are related). Is dwz or compiler broken on bullseye? Thanks, /mjt
Bug#1010717: Spamassassin config causes errors on ubuntu 22.04
Package: aide Version: 0.17.4-2 When running AIDE on Ubuntu 22.04 with spamassassin installed I get this error: Errors produced (4 lines): ERROR: /etc/aide/aide.conf.d/21_aide_spamassassin: stderr> /etc/aide/aide.conf.d/21_aide_spamassassin: line 13: printf: 3.4.6-1build3: invalid number ERROR: /etc/aide/aide.conf.d/21_aide_spamassassin: stderr> /etc/aide/aide.conf.d/21_aide_spamassassin: line 13: printf: 3.4.6-1build3: invalid number ERROR: /etc/aide/aide.conf.d/21_aide_spamassassin: stderr> /etc/aide/aide.conf.d/21_aide_spamassassin: line 13: printf: 3.4.6-1build3: invalid number ERROR: /etc/aide/aide.conf.d/21_aide_spamassassin: execution failed (exit status: 1) It looks like it’s caused by changes in 21_aide_spamassassin introduced late 2021. I’ve submitted a PR to fix. Adam smime.p7s Description: S/MIME cryptographic signature
Bug#1010718: After installed portsentry doesn't create automatically portsentry.history
Package: portsentry Version: 1.2-14 Hi team, I´m Michel Gabriel Ramirez Fournier, Cybersecurity engineer and Debian user since many moons ago. I´m a passionate Linux predicator which loves to recommend the good things of Debian as a server in search of security and stability for PYMES. For that reason a few days ago i was showing to a company the benefits of the integration of the application PORTSENTRY with FAIL2BAN to block attackers efforts to scan the server target ports and at same time blocking possible (future) brute force attacks coming from the same aggressor or source. The configuration is indeed very easy, but i detected a malfunction in PORTSENTRY behavior when is installed, and this is caused because it doesn´t create automatically (after being installed) the registry file which stores the list of aggressor IPs detected: */var/lib/portsentry/portsentry.history* This file is just created when a security event (like a port scan) trigger the file creation by the active PORTSENTRY process. The absent file doesn´t interfere the normal functioning of PORTSENTRY but if FAIL2BAN is enabled with the jail to integrate with PORTSENTRY this scenario of missing file will cause a FAIL2BAN crash: *[portsentry]* *logpath = /var/lib/portsentry/portsentry.history* As part of an exercise i successfully started to use this flaw of PORTSENTRY as part of an attack in a capture the flag simulation, and with just erasing the file /var/lib/portsentry/portsentry.history and waiting a few seconds for the demon reload the result is the subsequent crash of FAIL2BAN. I also recently send an email to the PORTSENTRY maintainer mid...@debian.org (but still without answer) informing about the flaw detected because maybe this malfunction of PORTSENTRY can be fixed just by creating the missing file /var/lib/portsentry/portsentry.history after the installation and checking if the file is present in the root folder after every daemon reload. By doing this steps the dependence with FAIL2BAN won’t cause the FAIL2BAN crash. *I am using Linux debian 5.10.0-14-amd64.* I appreciate all the help received from *t...@security.debian.org * to report this bug. Respectfully Michel
Bug#968670: dwz: Fails with "Unknown DWARF DW_OP_1" (more info needed)
It is the same on arm64 too, eg: https://buildd.debian.org/status/package.php?p=qemu&suite=bullseye-backports /mjt
Bug#1010719: Animated GIFs only animate on window resize
Package: gpicview Version: 0.2.5-3+b1 Hello, Someone on a French Debian forum noticed me that GIFs only animate on window resize. I tryed myself to reproduce the bug and I succeed. I could not find any option on the software to start or stop the animation. Regards, -- Sasha MOREL « C'était un de ces originaux que le Créateur invente dans un moment de fantaisie et dont il brise aussitôt le moule. » − Jules VERNE
Bug#1009977: gdm3: Fails to start since 2022/04/19 on Debian/testing
Dear Jeremy, after a new gnome-shell package went into Debian/testing, logging in is possible again. But the load time of GDM3 is still very long, and the login-procedure takes minutes. After entering the credentials, GDM is thinking very long and does nothing, then the login proceeds. Also the login in the shell, when issuing ksu to login to root via kererberos takes some seconds long. So it might be a bug in conjunction with the authentification too. In addition to that, I am currently experiencing a bug in the 5.17 kernel from Debian/testing, where after some hours of uptime one core gets loaded fully with a kernel process. In the 5.16 and 5.17 kernels the load time of the ZSH shell is very slow (may be disk access), so I am currently using an old 5.15 kernel. My system: adrian@g6 ~ % inxi CPU: quad core Intel Xeon X3430 (-MCP-) speed/min/max: 2085/1197/2394 MHz Kernel: 5.15.0-2-amd64 x86_64 Up: 4h 17m Mem: 10022.3/15999.3 MiB (62.6%) Storage: 11.79 TiB (49.1% used) Procs: 387 Shell: Zsh inxi: 3.3.15 Thank you very much for your attention. Sincerely, Adrian Kieß On Thu, 21 Apr 2022 12:34:37 -0400 Jeremy Bicha wrote: > On Thu, Apr 21, 2022 at 11:51 AM Adrian Immanuel Kiess > wrote: > > GDM3 fails to load, after bringing up the system. > > Please switch to a virtual terminal (like Ctrl+Alt+F3) and look for > interesting messages in > journalctl -b > > Probably especially messages from gnome-shell or gdm > > Thank you, > Jeremy Bicha
Bug#1010720: git: Bump version to 2.36.1
Package: git Version: 1:2.36.0-1 Severity: normal X-Debbugs-Cc: sedat.di...@gmail.com Dear Maintainer, can you please bump git to version 2.36.1? It contains several bug-fixes. Thanks. Regards, -Sedat- -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (99, 'buildd-unstable'), (99, 'buildd-experimental'), (99, 'experimental'), (99, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git depends on: ii git-man 1:2.36.0-1 ii libc62.33-7 ii libcurl3-gnutls 7.83.0-1 ii liberror-perl0.17029-1 ii libexpat12.4.8-1 ii libpcre2-8-0 10.40-1 ii perl 5.34.0-4 ii zlib1g 1:1.2.11.dfsg-4 Versions of packages git recommends: ii ca-certificates 20211016 ii less 590-1 ii openssh-client [ssh-client] 1:9.0p1-1 ii patch2.7.6-7 Versions of packages git suggests: ii gettext-base 0.21-6 pn git-cvs pn git-daemon-run | git-daemon-sysvinit pn git-doc ii git-email 1:2.36.0-1 pn git-gui pn git-mediawiki pn git-svn pn gitk pn gitweb -- no debconf information
Bug#929983: bug 929983: ipxe-qemu: virtio booting no longer works after upgrade to buster
Control: severity -1 normal 08.05.2022 02:18, Thorsten Glaser wrote: .. In this bugreport, I see it is/was broken with -machine pc-1.1. There's no indication if it is broken with other machine types. As of qemu 5.2 (bullseye) machine types below pc-1.3 are deprecated, and in 7.0 (current bookworm) they're removed. This is rather bad, this will break existing VMs on upgrade with almost certainly zero clues why. these machine definitions are more than 10 years old. qemu can not keep them the way it were 10 years ago (and as we observed in this bugreport, this makes it bitrot). That wasn't an easy decision but the line must be drawn somewhere, we can't support really old stuff forever. Please note that in qemu, these machine types are kept mostly in order to make the VMs migratable from one version of qemu to another (which in practice quite often does not work anyway). During reboot it is possible to switch to a more recent machine. I know some operating systems can not tolerate hardware changes though, - at least linux is not one of them. Do you agree with this assessment of the bug you reported? If so, let's tag this bug with buster and bullseye as indeed I conclude it's not a bug in bookworm then. I'd rather consider this a second RC bug in bookworm, if so. I don't see why it is marked with this severity. To me it definitely is a "normal" bug (if not "minor" due to too old hw definitions). It works by default, and even in rare situations when it doesn't, there are easy workarounds (switch to another NIC for example). Or do you refer to the qemu dropping ancient machine types instead of this netbooting thing? If that's the case, such bug will be "wontfix" for sure. I'm lowering severity of this bug to "normal" now. Please feel free to set it to other value and provide the reasons why do you think this way. I'm currently in a really bad situation to look at anything in detail (waiting for my brain to remember the luks password of my work laptop), please excuse brevity. I hope you'll succeed there. It's sad when this happen. Thanks! /mjt
Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory
Hi Andreas, Quoting Andreas Tille (2022-05-04 17:15:49) > > Well, yes, it would be more convenient for me, but you are doing the work, > > so I'm not going to make any demands. :D I think the stronger reason to go > > roll back to dcmtk-3.6.7+really3.6.6 is, that Sebastian Ramacher as a > > release team member pointed out that they would prefer that option. > > I think I'll go that route then (but probably tomorrow). BTW, I had (again) > a look into ants and think the new upstream version can help to fix the > open RC bugs. I once worked on this but at that point of time we did not > yet had insighttoolkit5. Now the issue hopefully boiled down to some issue > I've reported upstream[1]. do you need any assistance? Sebastian Ramacher asked me on IRC about the status of dcmtk and wants to add some blocks on the reverse dependencies so that they don't migrate, should you choose not to revert dcmtk. Thanks! cheers, josch signature.asc Description: signature
Bug#1010721: ITP: pysolid -- Python interface to the OpenSCAD declarative geometry language
Package: wnpp Severity: wishlist Owner: Antonio Valentino * Package name: pysolid Version : 0.2.1 Upstream Author : Zhang Yunjun * URL : https://github.com/insarlab/PySolid * License : GPL+ Programming Lang: Python Description : Python wrapper for solid Earth tides Binary package names: python3-pysolid Python based solid Earth tides (PySolid) is a thin Python wrapper of the solid.for program (by Dennis Milbert based on dehanttideinelMJD.f from V. Dehant, S. Mathews, J. Gipson and C. Bruyninx) to calculate solid Earth tides in east/north/up direction (section 7.1.1 in the 2010 IERS Conventions). Solid Earth tides introduces very long spatial wavelength components in SAR/InSAR observations, as shown in the Sentinel-1 data with regular acquisitions and large swaths (Yunjun et al., 2022). -- Antonio Valentino
Bug#1010215: closed by Georges Khaznadar (The new NMUed release is uploaded ...)
Hello Paul, I fixed the issue about python3-numba, and the recently uploaded package (release 0.3.0-2.3) is OK to enter testing. I made a push request in salsa: https://salsa.debian.org/debian-astro-team/einsteinpy/-/merge_requests/4 Best regards, Georges. signature.asc Description: PGP signature
Bug#1010722: RM: pktanon [armel armhf] -- ANAIS; binaries broken on some archs
Package: ftp.debian.org Severity: normal As the maintainer for pktanon, I would like to have old arm binary packages removed from unstable and testing. They are bult but do not work on these architectures due to alignment problems. See [0]. I have already removed the architectures with my latest source updates and would like to make sure that can migrate to testing again. Thanks and best regards Sascha [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999620
Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory
Hi Johannes, Am Sun, May 08, 2022 at 11:34:15AM +0200 schrieb Johannes Schauer Marin Rodrigues: > > I think I'll go that route then (but probably tomorrow). BTW, I had (again) > > a look into ants and think the new upstream version can help to fix the > > open RC bugs. I once worked on this but at that point of time we did not > > yet had insighttoolkit5. Now the issue hopefully boiled down to some issue > > I've reported upstream[1]. > > do you need any assistance? Sebastian Ramacher asked me on IRC about the > status > of dcmtk and wants to add some blocks on the reverse dependencies so that they > don't migrate, should you choose not to revert dcmtk. I admit I've lost track on this and I'm effectively on vac until 12.5. Before I went on vac I've tried to build some dependencies against dcmtk 3.6.7 which worked with easy patches. Kind regards Andreas. -- http://fam-tille.de
Bug#997293: pinfo: diff for NMU version 0.6.13-1.2
Control: tags 997293 + patch
Control: tags 997293 + pending
Dear maintainer,
I've prepared an NMU for pinfo (versioned as 0.6.13-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
diff -Nru pinfo-0.6.13/debian/changelog pinfo-0.6.13/debian/changelog
--- pinfo-0.6.13/debian/changelog 2020-10-28 20:06:48.0 +0100
+++ pinfo-0.6.13/debian/changelog 2022-05-08 14:36:50.0 +0200
@@ -1,3 +1,13 @@
+pinfo (0.6.13-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix "FTBFS: video.c:112:26: error: format '%d' expects argument of type
+'int', but argument 2 has type 'long unsigned int' [- Werror=format=]":
+Add patch from upstream Git repository to use %ld to print longs.
+(Closes:#997293)
+
+ -- gregor herrmann Sun, 08 May 2022 14:36:50 +0200
+
pinfo (0.6.13-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru pinfo-0.6.13/debian/patches/Werror-format.patch pinfo-0.6.13/debian/patches/Werror-format.patch
--- pinfo-0.6.13/debian/patches/Werror-format.patch 1970-01-01 01:00:00.0 +0100
+++ pinfo-0.6.13/debian/patches/Werror-format.patch 2022-05-08 14:36:46.0 +0200
@@ -0,0 +1,39 @@
+From ab604fdb67296dad27f3a25f3c9aabdd2fb8c3fa Mon Sep 17 00:00:00 2001
+From: Sergei Trofimovich
+Date: Thu, 11 Nov 2021 19:02:24 +
+Subject: [PATCH] src/video.c: use %ld to print longs
+
+ncurses-6.3 added printf()-stype attribute annotations for gcc-like
+compilers that can now detect argument mismatches:
+
+video.c:114:26: error: format '%d' expects argument of type 'int',
+ but argument 3 has type 'long unsigned int' [-Werror=format=]
+ 114 | printw(_("Viewing line %d/%d, 100%%"), lines, lines);
+ | ^~~
+---
+ src/video.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+
+Origin: https://github.com/baszoetekouw/pinfo/commit/ab604fdb67296dad27f3a25f3c9aabdd2fb8c3fa
+Bug-Debian: https://bugs.debian.org/997293
+Reviewed-by: gregor herrmann
+Last-Update: 2022-05-08
+Applied-Upstream: https://github.com/baszoetekouw/pinfo/commit/3d76eecde211e41ccc28b04e229f159b3f924399
+
+diff --git a/src/video.c b/src/video.c
+index f6b444a..195d781 100644
+--- a/src/video.c
b/src/video.c
+@@ -109,9 +109,9 @@ showscreen(char **message, unsigned long lines, unsigned long pos, long cursor,
+ mymvhline(maxy - 1, 0, ' ', maxx);
+ move(maxy - 1, 0);
+ if ((pos < lines - 1) &&(lines > pos + maxy - 2))
+- printw(_("Viewing line %d/%d, %d%%"), pos + maxy - 2, lines,((pos + maxy - 2) * 100) / lines);
++ printw(_("Viewing line %ld/%ld, %ld%%"), pos + maxy - 2, lines,((pos + maxy - 2) * 100) / lines);
+ else
+- printw(_("Viewing line %d/%d, 100%%"), lines, lines);
++ printw(_("Viewing line %ld/%ld, 100%%"), lines, lines);
+ info_add_highlights(pos, cursor, lines, column, message);
+ attrset(normal);
+ move(0, 0);
diff -Nru pinfo-0.6.13/debian/patches/series pinfo-0.6.13/debian/patches/series
--- pinfo-0.6.13/debian/patches/series 2020-10-28 19:56:45.0 +0100
+++ pinfo-0.6.13/debian/patches/series 2022-05-08 14:33:18.0 +0200
@@ -1 +1,2 @@
fix_gcc-10.patch
+Werror-format.patch
signature.asc
Description: Digital Signature
Bug#997851: Update on doas package status
Thanks for the update. Having a Debian package (even an unofficial one) would be nice. I can still post install instructions for it in our README file. Is it possible to rename the existing package or add warning to it to let people know the "doas" package in Debian is actually OpenDoas and not the slicer69/doas package. I'd like to avoid confusion on that front. Jesse On 2022-05-06 8:04 p.m., Scupake wrote: > Hello, > > A little update on this issue. I found out that I am not be able to > upload both packages into the Debian repositories since the two programs are > too similar to each other. However I can provide packages for slicer69/doas on > a git repo since the packaging for it is pretty much done. > I am sorry about not being able to include slicer69/doas in the Debian > repos. >
Bug#1010724: libinovasdk-dev must have the same architecture list as libinovasdk1
Package: libinovasdk-dev Version: 1.3.6-2 Severity: serious X-Debbugs-Cc: Thorsten Alteholz Control: block 1008276 by -1 ∙ libinovasdk-dev/armhf has unsatisfiable dependency Building libinovasdk-dev on architectures where its dependency libinovasdk1 is not being built make libinovasdk-dev uninstallable.
Bug#1010725: Since some weeks, gimp icons are displays as identical cross
Package: gimp Version: 2.10.30-1+b1 Severity: important Since several weeks, gimp displays only small identical icons with a red cross instead of the tools icons or tab icons. It is absolutly not usable this way as one has to wait for the context help to pop up to see, which tool the mouse is over. This might, however, be a bug ig GTK as inkscape, as I seen today, suffers from the same bug. But here, the most icons are a landscape paper image with an A (or a triangle with an exclamation mark) in it. -- System Information: Debian Release: bookworm/sid APT prefers experimental APT policy: (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.17 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gimp depends on: ii gimp-data2.10.30-1 ii graphviz 2.42.2-6+b3 ii libaa1 1.4p5-50 ii libbabl-0.1-01:0.1.92-1 ii libbz2-1.0 1.0.8-5 ii libc62.33-7 ii libcairo21.16.0-5 ii libfontconfig1 2.13.1-4.4 ii libfreetype6 2.11.1+dfsg-2 ii libgcc-s112-20220428-1 ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1 ii libgegl-0.4-01:0.4.36-3 ii libgexiv2-2 0.14.0-1 ii libgimp2.0 2.10.30-1+b1 ii libglib2.0-0 2.72.1-1 ii libgs9 9.56.1~dfsg-1 ii libgtk2.0-0 2.24.33-2 ii libgudev-1.0-0 237-2 ii libharfbuzz0b2.7.4-1+b1 ii libheif1 1.12.0-2+b3 ii libilmbase25 2.5.7-2 ii libjpeg62-turbo 1:2.1.2-1 ii libjson-glib-1.0-0 1.6.6-1 ii liblcms2-2 2.12~rc1-2 ii liblzma5 5.2.5-2.1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.5-1 1:1.5.1-dmo2 ii libopenexr25 2.5.7-1 ii libopenjp2-7 2.4.0-6 ii libpango-1.0-0 1.50.7+ds-1 ii libpangocairo-1.0-0 1.50.7+ds-1 ii libpangoft2-1.0-01.50.7+ds-1 ii libpng16-16 1.6.37-5 ii libpoppler-glib8 22.02.0-3 ii librsvg2-2 2.52.5+dfsg-3+b1 ii libstdc++6 12-20220428-1 ii libtiff5 4.3.0-7 ii libwebp7 1.2.2-2+b1 ii libwebpdemux21.2.2-2+b1 ii libwebpmux3 1.2.2-2+b1 ii libwmf-0.2-7 0.2.12-5 ii libwmflite-0.2-7 0.2.12-5 ii libx11-6 2:1.7.5-1 ii libxcursor1 1:1.2.1-1 ii libxext6 2:1.3.4-1 ii libxfixes3 1:6.0.0-1 ii libxmu6 2:1.1.3-3 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-4.1 ii zlib1g 1:1.2.11.dfsg-4 Versions of packages gimp recommends: ii ghostscript 9.56.1~dfsg-1 Versions of packages gimp suggests: ii gimp-data-extras 1:2.0.2-1.1 ii gimp-help-de [gimp-help] 2.10.0-1 ii gimp-help-en [gimp-help] 2.10.0-1 pn gvfs-backends ii libasound21.2.6.1-2+b1 -- no debconf information -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C signature.asc Description: PGP signature
Bug#1010726: libricohcamerasdk-dev must have the same architecture list as libricohcamerasdk
Package: libricohcamerasdk-dev Version: libricohcamerasdk-dev Severity: serious ∙ libricohcamerasdk-dev/armel has unsatisfiable dependency ∙ libricohcamerasdk-dev/i386 has unsatisfiable dependency Building libricohcamerasdk-dev on architectures where its dependency libricohcamerasdk is not being built makes libricohcamerasdk-dev uninstallable.
Bug#1010714: sane-pixma: sane can't find scanner
Hello Jörg, The requested files are attached. It may be important to mention that I never edited them. And here is the output of 'export SANE_DEBUG_BJNP="5" && scanimage -L': [10:35:28.690309] [sanei_debug] Setting debug level of bjnp to 5. [10:35:28.690398] [bjnp] sanei_bjnp_find_devices, pixma backend version: 0.28.6 [10:35:28.690417] [bjnp] sanei_bjnp_find_devices: Configuration file is empty, No devices specified. [10:35:28.690427] [bjnp] sanei_bjnp_find_devices: Start auto-detection. [10:35:28.690612] [bjnp] prepare_socket: lo is not a valid IPv4 interface, skipping... [10:35:28.690645] [bjnp] prepare_socket: eth0 is IPv4 capable, sending broadcast, socket = 7 [10:35:28.690668] [bjnp] prepare_socket: wlan0 is IPv4 capable, sending broadcast, socket = 8 [10:35:28.690683] [bjnp] prepare_socket: lo is not a valid IPv6 interface, skipping... [10:35:28.690709] [bjnp] prepare_socket: eth0 is IPv6 capable, sending broadcast, socket = 9 [10:35:28.690730] [bjnp] prepare_socket: wlan0 is IPv6 capable, sending broadcast, socket = 10 [10:35:29.211886] [bjnp] sanei_find_devices: scanner discovery finished... No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). Best, Alexandre P.S.: Now I noticed that pixma.conf has all lines as a comment. Is it right? On May 08 2022, Jörg Frings-Fürst wrote: > tags 1010714 + moreinfo > thanks > > Hello Alexandre, > > thank you for spending your time helping to make Debian better with > this bug report. > > > Please attach the config files > > - /etc/sane.d/pixma.conf > - /etc/sane.d/dll.conf > > and the output of > > export SANE_DEBUG_BJNP="5" && scanimage -L > > > CU > Jörg > > Am Samstag, dem 07.05.2022 um 23:00 -0300 schrieb Alexandre > Lymberopoulos: > > Package: libsane1 > > Version: 1.1.1-5 > > Severity: normal > > File: sane-pixma > > > > Dear Maintainer, > > > > Any software here usanig sane can't detect my PIXMA MG3510 over > > wireless network. For testing purposes I installed the proprietary > > software from Canon and eveything woked ok. > > > > I may provide any futher information upon request. > > > > Best, Alexandre > > > > -- System Information: > > Debian Release: bookworm/sid > > APT prefers testing > > APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable- > > security') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > LANGUAGE=en_US:en > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > > > Versions of packages libsane1:amd64 depends on: > > ii acl 2.3.1-1 > > ii adduser 3.121 > > ii libavahi-client3 0.8-5 > > ii libavahi-common3 0.8-5 > > ii libc6 2.33-7 > > ii libcairo2 1.16.0-5 > > ii libcurl3-gnutls 7.83.0-1 > > ii libgcc-s1 12-20220428-1 > > ii libglib2.0-0 2.72.1-1 > > ii libgphoto2-6 2.5.27-1 > > ii libgphoto2-port12 2.5.27-1 > > ii libieee1284-3 0.2.11-14 > > ii libjpeg62-turbo 1:2.1.2-1 > > ii libpng16-16 1.6.37-5 > > ii libpoppler-glib8 22.02.0-3 > > ii libsane-common 1.1.1-5 > > ii libsnmp40 5.9.1+dfsg-1+b1 > > ii libstdc++6 12-20220428-1 > > ii libtiff5 4.3.0-7 > > ii libusb-1.0-0 2:1.0.26-1 > > ii libxml2 2.9.13+dfsg-1+b1 > > ii udev 250.4-1 > > > > Versions of packages libsane1:amd64 recommends: > > pn ipp-usb > > pn sane-airscan > > ii sane-utils 1.1.1-5 > > > > Versions of packages libsane1:amd64 suggests: > > ii avahi-daemon 0.8-5 > > ii hplip 3.22.2+dfsg0-1 > > > > -- no debconf information > > -- > New: > GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D > GPG key (long) : 09F89F3C8CA1D25D > GPG Key: 8CA1D25D > CAcert Key S/N : 0E:D4:56 > > Old pgp Key: BE581B6E (revoked since 2014-12-31). > > Jörg Frings-Fürst > D-54470 Lieser > > > git: https://jff.email/cgit/ > > Threema: SYR8SJXB > Wire: @joergfringsfuerst > Skype: joergpenguin > Ring: jff > Telegram: @joergfringsfuerst > > > My wish list: > - Please send me a picture from the nature at your home. > -- === Alexandre Lymberopoulos - lym...@gmail.com === # dll.conf - Configuration file for the SANE dynamic backend loader # # Backends can also be enabled by configuration snippets under the dll.d/ # directory -- third party backends can drop their configuration file in # this in this directory, named after the backend. # # The next line enables the network backend; comment it o
Bug#1010725: Since some weeks, gimp icons are displays as identical cross
On Sun, 08 May 2022 at 15:33:07 +0200, Klaus Ethgen wrote: > Since several weeks, gimp displays only small identical icons with a red > cross instead of the tools icons or tab icons. What icon theme are you using, and what version is it? Do you have librsvg2-common installed? > Debian Release: bookworm/sid > APT prefers experimental > APT policy: (1, 'experimental') That seems wrong: to use packages from experimental, you should also have unstable apt sources available. > ii libmypaint-1.5-1 1:1.5.1-dmo2 Debian does not support the unofficial packages from deb-multimedia.org, and those packages sometimes cause problems, although in this case it's probably not directly relevant. For more information: https://wiki.debian.org/DebianMultimedia/FAQ#There_is_.27Debian_Multimedia_Maintainers.27_and_.27deb-multimedia.org.27._So_what.27s_the_difference.3F smcv
Bug#1010698: stunnel4: debci testsuite fails after openssl version update.
Control: retitle -1 stunnel4: runtime check on openssl too tight? Control: user debian...@lists.debian.org Control: usertag -1 - flaky Hi, On 07-05-2022 21:40, Sebastian Andrzej Siewior wrote: On 2022-05-07 20:52:41 [+0200], Paul Gevers wrote: On 07-05-2022 18:22, Sebastian Andrzej Siewior wrote: Usertags: flaky Why do you conclude that? Normally we call something flaky if it has a reasonable amount of failures in pure testing environments (so no migration runs). I'm not seeing that for tunnel4 on amd64, nor arm64. Maybe I missunderstood. According to the tracking page, it failed everywhere: We use the flaky usertag for tests that without changes sometimes pass and sometimes fail. In this case, there have hardly been failures in the past, and there is clearly a change (a new version of openssl). So there's a clear issue, but we normally don't call this situation flaky. If your claim is true (and I trust it is), I do agree that it seems that the test (and I guess this comes from a runtime check) is too strict. Retitling accordingly. Seems my retitling command was heavily flawed, let's try again. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#933396: this bug is currently fixed
The debian source package features a patch: debian/patches/fixes/Dont-run-reboot-jobs-on-restart.patch which fixes the issue. I shall close the bug report, please reopen it if necessary. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1010727: src:pngnq: fails to migrate to testing for too long: FTBFS
Source: pngnq Version: 1.0-2.3 Severity: serious Control: close -1 1.1+ds-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1008342 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:pngnq has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package fails to build from source as reported in bug #1008342. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=pngnq OpenPGP_signature Description: OpenPGP digital signature
Bug#1010728: Please provide libatomic-dev package with unversioned libatomic.so
Package: libatomic1 Version: 12-20220428-1 Severity: wishlist Dear Maintainer, Currently we have libatomic.so.1 but no unversioned libatomic.so. The next version of Qt (6.3.1) will have this CMake code to find atomic library when there std::atomic does not work out of the box: find_library(atomic_LIB atomic REQUIRED) This searches for unversioned libatomic.so. I proposed a patch for Qt to support libatomic.so.1, but upstream Qt Core maintainer responded with the following: > That's just a packaging mistake in your Linux distribution. libatomic.so > exists on OpenSUSE: > > $ rpm -ql gcc12 | grep libatomic > /usr/lib64/gcc/x86_64-suse-linux/12/libatomic.a > /usr/lib64/gcc/x86_64-suse-linux/12/libatomic.so > $ rpm -ql gcc11 | grep libatomic > /usr/lib64/gcc/x86_64-suse-linux/11/libatomic.a > /usr/lib64/gcc/x86_64-suse-linux/11/libatomic.so > > I also see it in the listing for gcc in Fedora > (https://fedora.pkgs.org/35/fedora-updates-x86_64/gcc-11.3.1-2.fc35.x86_64.rpm.html), > CentOS Stream 9 > (https://centos.pkgs.org/9-stream/centos-appstream-aarch64/gcc-11.3.1-2.el9.aarch64.rpm.html), > Alpine Linux > (https://alpine.pkgs.org/3.15/alpine-main-aarch64/gcc-10.3.1_git20211027-r0.apk.html), > Slackware > (https://slackware.pkgs.org/current/slackware-x86_64/gcc-11.3.0-x86_64-1.txz.html), > even FreeBSD Ports > (https://freebsd.pkgs.org/13/freebsd-amd64/gcc11-11.3.0.pkg.html). > Plus as a separate package for Mageia and OpenMandriva > (https://pkgs.org/download/libatomic-devel). > > So if it's missing in your distro, report it as a bug there. > > Hardcoding the soversion is not a good idea because it could change. See our discussion here: https://codereview.qt-project.org/c/qt/qtbase/+/410167 So can we please have libatomic.so like all these distros? -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#983421: init-system-helpers: please respect DPKG_ROOT when checking for /usr/sbin/policy-rc.d
Hi Michael, On Thu, 17 Mar 2022 11:28:04 + Luca Boccassi wrote: > On Thu, 2022-03-17 at 11:33 +0100, Michael Biebl wrote: > > Am 17.03.22 um 08:24 schrieb Johannes Schauer Marin Rodrigues: > > > > > the Release Team announced the freeze dates for bookworm, so I wanted to > > > send > > > > fwiw, I'm pretty sure those dates are off by 1 year *) and Paul just > > didn't manage to send a follow-up to dda due to troubles with his email > > client > > Yeah, I think the idea was to have the change in testing for as many > months as possible to ensure it's ok. > > I can do the merge and upload, but I believe you had some reservations > regarding DPKG_ROOT as a concept, Michael? > To me it seems fine, and it matches the behaviour of all systemd's > tools very well (--root switch). it seems that progress in this hangs or your ACK or NACK. Luca's last mail was from more than a month ago. Could you please clarify your position so that I can fix or change the things that you would prefer to be done differently? Thanks! cheers, josch signature.asc Description: signature
Bug#1003554: will not fix this bug report
Hi Brian Knapp, only root can modify crontab files which specify a user account, so if there is a bogus user account mentioned, the fault is up to root. The modification which you are wishing should be decided by upstream developers of cron, not by debian maintainers, so please send this request to them. Currently, we are trying to have a package working in debian which complies as tight as possible to the documentation authored by upstream developers. I will not try to fix this issue, and shall close this bug report. Please feel free to repopen it if you have some argument specific to debian distribution about it. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1010729: dcmtk: Default path to DICOM dictionaries is wrong
Package: dcmtk Version: 3.6.7-1 Severity: normal Default path to DICOM dictionaries encoded in binaries is wrong, e.g.: storescu -aet ME -aec PACS 127.0.0.1 105 -v file E: DcmDataDictionary: Cannot open file: /usr/share/dicom.dic E: DcmDataDictionary: Cannot open file: /usr/share/private.dic W: no data dictionary loaded, check environment variable: DCMDICTPATH same affect dcmdump and other binaries -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (10, 'focal-updates'), (10, 'focal-security'), (10, 'focal-backports'), (10, 'focal'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.5-finwe (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dcmtk depends on: ii adduser 3.121 ii libc6 2.33-7 ii libdcmtk16 3.6.7-1 ii libgcc-s1 12-20220428-1 ii libstdc++6 12-20220428-1 ii libxml2 2.9.14+dfsg-1 ii zlib1g 1:1.2.11.dfsg-4 dcmtk recommends no packages. dcmtk suggests no packages. -- no debconf information
Bug#634215: bugs homekeeping
Hello, this bug report is 13 years old and has received no information for this long time. Either it is still useful or not. Many changes have occured since the publication of this bug, some have touched deep features of cron, and many people have lived their life with debian's cron without activating this bug report again. Please check whether this bug should reopened currently. I shall close it now. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#742880: Closing this bug report
Hi, this bug report seems to be a duplicate of #990026, which is closed now. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1010725: Since some weeks, gimp icons are displays as identical cross
Am So den 8. Mai 2022 um 14:47 schrieb Simon McVittie: > On Sun, 08 May 2022 at 15:33:07 +0200, Klaus Ethgen wrote: > > Since several weeks, gimp displays only small identical icons with a red > > cross instead of the tools icons or tab icons. > > What icon theme are you using, and what version is it? I don't know. How to see that? > Do you have librsvg2-common installed? Yes. > > Debian Release: bookworm/sid > > APT prefers experimental > > APT policy: (1, 'experimental') > > That seems wrong: to use packages from experimental, you should also have > unstable apt sources available. I use Devuan unstable. > > ii libmypaint-1.5-1 1:1.5.1-dmo2 > > Debian does not support the unofficial packages from deb-multimedia.org, I installed the debian version with the same problem. So libmypaint is not the problem. ii libmypaint-1.5-1:amd64 1.6.0-2 amd64brush library for mypaint Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C signature.asc Description: PGP signature
Bug#1010730: python-numpy-doc: HTML documentation contains an invalid link
Package: python-numpy-doc Severity: normal Dear Maintainer, I found an invalid link in html numpy documentation. Steps to reproduce: 1. Open index.html 2. Using "Quick search" find ndarray 3. First link of "numpy.ndarray" is invalid (contains unneeded `undefined`) Documentation available online https://numpy.org/doc/1.19/ does not have this issue. Thank You for taking the time to look into this issue, Paweł Dietrich
Bug#1010731: rust-semver-parser-0.9: should this package be removed.
Package: rust-semver-parser-0.9 I added the rust-semver-parser-0.9 package to fix the (build-)dependencies of rust-debcargo. Debcargo no longer uses semver-parser and no other packages use version 0.9 of semver-parser, so I think it's time for it to go. If noone objects I will turn this bug into a removal request in a week or two.
Bug#1010703: haskell-hashable: FTBFS on i386: unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'
Control: reassign -1 haskell-devscripts
Control: retitle -1 haskell-devscripts: Shell expansion breaks nested
quotes in GHC arguments
Control: affects -1 haskell-hashable
Hi,
> unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'
I believe the quotes in haskell-hashable here: [1]
DEB_SETUP_GHC_CONFIGURE_ARGS = --hsc2hs-options="$(LFS_CFLAGS)"
--gcc-options="$(LFS_CFLAGS)" --ghc-options="$(GHC_LFSFLAGS)"
are lost when the environment variable is shell-expanded in
haskell-devscripts here: [2]
# DEB_SETUP_GHC_CONFIGURE_ARGS can contain multiple arguments
# with their own quoting so run through a shell expansion
my $ghc_configure_args = run_quiet(
qw{sh -c},
'echo -n '
. $DOUBLE_QUOTE
. ($ENV{DEB_SETUP_GHC_CONFIGURE_ARGS} // $EMPTY)
. $DOUBLE_QUOTE
);
Kind regards,
Felix Lechner
[1]
https://salsa.debian.org/haskell-team/DHG_packages/-/blob/master/p/haskell-hashable/debian/rules#L6
[2]
https://salsa.debian.org/haskell-team/haskell-devscripts/-/blob/master/lib/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm#L597-605
Bug#1010714: sane-pixma: sane can't find scanner
Hello, thanks for your answer. Please add something like this bjnp://ScannerIP into your pixma.conf For the exact syntax and further parameters please look in 'man sane- pixma'. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. Am Sonntag, dem 08.05.2022 um 10:42 -0300 schrieb Alexandre Lymberopoulos: > Hello Jörg, > > The requested files are attached. It may be important to mention that > I > never edited them. And here is the output of 'export > SANE_DEBUG_BJNP="5" && scanimage -L': > > [10:35:28.690309] [sanei_debug] Setting debug level of bjnp to 5. > [10:35:28.690398] [bjnp] sanei_bjnp_find_devices, pixma backend > version: 0.28.6 > [10:35:28.690417] [bjnp] sanei_bjnp_find_devices: Configuration file > is empty, No devices specified. > [10:35:28.690427] [bjnp] sanei_bjnp_find_devices: Start auto- > detection. > [10:35:28.690612] [bjnp] prepare_socket: lo is not a valid IPv4 > interface, skipping... > [10:35:28.690645] [bjnp] prepare_socket: eth0 is IPv4 capable, > sending broadcast, socket = 7 > [10:35:28.690668] [bjnp] prepare_socket: wlan0 is IPv4 capable, > sending broadcast, socket = 8 > [10:35:28.690683] [bjnp] prepare_socket: lo is not a valid IPv6 > interface, skipping... > [10:35:28.690709] [bjnp] prepare_socket: eth0 is IPv6 capable, > sending broadcast, socket = 9 > [10:35:28.690730] [bjnp] prepare_socket: wlan0 is IPv6 capable, > sending broadcast, socket = 10 > [10:35:29.211886] [bjnp] sanei_find_devices: scanner discovery > finished... > > No scanners were identified. If you were expecting something > different, > check that the scanner is plugged in, turned on and detected by the > sane-find-scanner tool (if appropriate). Please read the > documentation > which came with this software (README, FAQ, manpages). > > Best, Alexandre > P.S.: Now I noticed that pixma.conf has all lines as a comment. Is it > right? > > On May 08 2022, Jörg Frings-Fürst wrote: > > tags 1010714 + moreinfo > > thanks > > > > Hello Alexandre, > > > > thank you for spending your time helping to make Debian better with > > this bug report. > > > > > > Please attach the config files > > > > - /etc/sane.d/pixma.conf > > - /etc/sane.d/dll.conf > > > > and the output of > > > > export SANE_DEBUG_BJNP="5" && scanimage -L > > > > > > CU > > Jörg > > > > Am Samstag, dem 07.05.2022 um 23:00 -0300 schrieb Alexandre > > Lymberopoulos: > > > Package: libsane1 > > > Version: 1.1.1-5 > > > Severity: normal > > > File: sane-pixma > > > > > > Dear Maintainer, > > > > > > Any software here usanig sane can't detect my PIXMA MG3510 over > > > wireless network. For testing purposes I installed the > > > proprietary > > > software from Canon and eveything woked ok. > > > > > > I may provide any futher information upon request. > > > > > > Best, Alexandre > > > > > > -- System Information: > > > Debian Release: bookworm/sid > > > APT prefers testing > > > APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable- > > > security') > > > Architecture: amd64 (x86_64) > > > > > > Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) > > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > > LANGUAGE=en_US:en > > > Shell: /bin/sh linked to /bin/dash > > > Init: systemd (via /run/systemd/system) > > > > > > Versions of packages libsane1:amd64 depends on: > > > ii acl 2.3.1-1 > > > ii adduser 3.121 > > > ii libavahi-client3 0.8-5 > > > ii libavahi-common3 0.8-5 > > > ii libc6 2.33-7 > > > ii libcairo2 1.16.0-5 > > > ii libcurl3-gnutls 7.83.0-1 > > > ii libgcc-s1 12-20220428-1 > > > ii libglib2.0-0 2.72.1-1 > > > ii libgphoto2-6 2.5.27-1 > > > ii libgphoto2-port12 2.5.27-1 > > > ii libieee1284-3 0.2.11-14 > > > ii libjpeg62-turbo 1:2.1.2-1 > > > ii libpng16-16 1.6.37-5 > > > ii libpoppler-glib8 22.02.0-3 > > > ii libsane-common 1.1.1-5 > > > ii libsnmp40 5.9.1+dfsg-1+b1 > > > ii libstdc++6 12-20220428-1 > > > ii libtiff5 4.3.0-7 > > > ii libusb-1.0-0 2:1.0.26-1 > > > ii libxml2 2.9.13+dfsg-1+b1 > > > ii udev 250.4-1 > > > > > > Versions of packages libsane1:amd64 recommends: > > > pn ipp-usb > > > pn sane-airscan > > > ii sane-utils 1.1.1-5 > > > > > > Versions of packages libsane1:amd64 suggests: > > > ii avahi-daemon 0.8-5 > > > ii hplip 3.22.2+dfsg0-1 > > > > > > -- no debconf information > > [...] signature.asc Description: This is a digitally signed
Bug#1010732: Import new upstream release
Source: rinetd Severity: important Upstream has several new releases. Please package the latest one.
Bug#1010376: RFS: rinetd/0.73-0.1 [NMU] [ITA] -- Internet TCP/UDP redirection server
On Fri, 29 Apr 2022 22:55:25 +0200 Helmar Gerloni wrote:
Changes since the last upload:
rinetd (0.73-0.1) unstable; urgency=medium
.
* Non-maintainer upload.
* New upstream release (from https://github.com/samhocevar/rinetd).
That is already the upstream. Instead of mentioning the URL, please say "Closes:
#1010732".
A NMU must address open bugs that are not addressed by the maintainer.
* Added systemd service file debian/rinetd.service.
* Added debian/watch.
* debian/rules: CHANGES renamed to CHANGES.md.
* debian/docs: README renamed to README.md.
* debian/copyright: Update to DEP5 format.
* Removed debian/compat.
* debian/control:
+ Added debhelper-compat to Build-Depends.
+ Added lsb-base to Depends (lintian error).
+ Removed dh-autoreconf from Depends (lintian warning).
+ Added ${misc:Pre-Depends} to Pre-Depends (lintian warning).
+ Added UDP to Description (supported since 0.70).
+ Updated Standards-Version to 4.6.0.1
This is quite extensive for a NMU. Still I would consider sponsoring it with the comment above
addressed.
Bug#1010733: linux-image-5.10.0-13-amd64: see Bug 215079 no sound after dist-upgrade - Thinkpad specific
Package: src:linux
Version: 5.10.106-1
Severity: important
X-Debbugs-Cc: piob...@mindspring.com
Dear Maintainer,
* What led up to the situation?
did an "apt-get dist-upgrade" from Buster to Bullseye
* What exactly did you do (or not do) that was effective (or
ineffective)?
pavucontrol does not report any input or output devices
audacity successfully records from an external (USB) microphone
Rebooted the machine. At bootup, scrolled down to boot from Buster instead of
Bullseye
Booting from Buster provided sound output. Note: The Thinkpad internal
microphone has never worked with Debian. Audacity reports that it is there, but
fails to record.
lspci reports "00:1f.3 Audio device: Intel Corporation Cannon Point-LP High
Definition Audio Controller (rev 11)"
* What outcome did you expect instead?
Expected the OS to recognize the internal microphone and speaker
*** End of the template - remove these template lines ***
-- Package-specific info:
** Version:
Linux version 5.10.0-13-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.106-1 (2022-03-17)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-13-amd64
root=UUID=51a3ecda-a499-4425-9d2f-4ec7ce8591c8 ro quiet
** Tainted: OE (12288)
* 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: LENOVO
product_name: 20QF0016US
product_version: ThinkPad X1 Yoga 4th
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N2HET39W (1.22 )
board_vendor: LENOVO
board_name: 20QF0016US
board_version: SDK0J40697 WIN
** Loaded modules:
ctr
ccm
rfcomm
hid_sensor_gyro_3d
hid_sensor_accel_3d
hid_sensor_trigger
hid_sensor_iio_common
industrialio_triggered_buffer
kfifo_buf
industrialio
hid_sensor_custom
hid_sensor_hub
intel_ishtp_hid
cmac
algif_hash
algif_skcipher
af_alg
bnep
btusb
btrtl
btbcm
btintel
bluetooth
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
jitterentropy_rng
wacom
videodev
drbg
usbhid
ansi_cprng
mc
ecdh_generic
ecc
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
snd_hda_codec_hdmi
snd_hda_codec_realtek
x86_pkg_temp_thermal
intel_powerclamp
snd_hda_codec_generic
coretemp
snd_soc_dmic
snd_sof_pci
snd_sof_intel_byt
joydev
kvm_intel
snd_sof_intel_ipc
kvm
snd_sof_intel_hda_common
snd_sof_xtensa_dsp
snd_sof
irqbypass
crc32_pclmul
snd_sof_intel_hda
snd_soc_skl
iTCO_wdt
snd_soc_hdac_hda
intel_pmc_bxt
snd_hda_ext_core
hid_multitouch
iTCO_vendor_support
mei_wdt
snd_soc_sst_ipc
ghash_clmulni_intel
hid_generic
watchdog
mei_hdcp
intel_rapl_msr
snd_soc_sst_dsp
aesni_intel
libaes
crypto_simd
snd_soc_acpi_intel_match
cryptd
wmi_bmof
glue_helper
iwlmvm
intel_wmi_thunderbolt
rapl
snd_soc_acpi
snd_hda_intel
snd_intel_dspcfg
soundwire_intel
soundwire_generic_allocation
intel_cstate
mac80211
snd_soc_core
intel_uncore
snd_compress
soundwire_cadence
binfmt_misc
libarc4
snd_hda_codec
snd_hda_core
e1000e
iwlwifi
snd_hwdep
soundwire_bus
nls_ascii
snd_pcm
nls_cp437
i2c_i801
ptp
vfat
xhci_pci
pcspkr
efi_pstore
tpm_crb
fat
pps_core
i2c_smbus
cfg80211
snd_timer
thunderbolt
xhci_hcd
mei_me
usbcore
thinkpad_acpi
mei
tpm_tis
intel_lpss_pci
nvram
intel_lpss
ledtrig_audio
idma64
snd
processor_thermal_device
tpm_tis_core
ucsi_acpi
i2c_hid
intel_rapl_common
usb_common
tpm
typec_ucsi
intel_ish_ipc
soundcore
intel_ishtp
intel_pch_thermal
intel_soc_dts_iosf
typec
rng_core
hid
wmi
rfkill
battery
int3403_thermal
ac
int340x_thermal_zone
intel_pmc_core
int3400_thermal
acpi_thermal_rel
acpi_pad
acpi_tad
button
parport_pc
ppdev
lp
parport
fuse
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
i915
i2c_algo_bit
drm_kms_helper
cec
drm
nvme
psmouse
nvme_core
evdev
crc32c_intel
t10_pi
serio_raw
crc_t10dif
crct10dif_generic
crct10dif_pclmul
crct10dif_common
video
** Network interface configuration:
*** /etc/network/interfaces:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
** Network status:
*** IP interfaces and addresses:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s31f6: mtu 1500 qdisc pfifo_fast
state DOWN group default qlen 1000
link/ether f8:75:a4:12:93:d2 brd ff:ff:ff:ff:ff:ff
3: wlp0s20f3: mtu 1500 qdisc noqueue state UP
group default qlen 1000
link/ether 94:e6:f7:92:67:bf brd ff:ff:ff:ff:ff:ff
inet 192.168.1.222/24 brd 192.168.1.255 scope global dynamic noprefixroute
wlp0s20f3
valid_lft 84833sec preferred_lft 84833sec
inet6 2600:4040:1043:8c00:6307:8bb8:7424:67cd/64 scope global dynamic
noprefixroute
valid_lft 529sec preferred_lft 529sec
inet6 fe80::bbc7:8700
Bug#1010734: kpartx fails, but the image is created anyways
Package: vmdb2
Version: 0.26-1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I see the following error even with successful builds:
[..]
Removing /tmp/tmpe5io4xoc.yaml
Removing /tmp/tmp7_tev8wl
Exec: ['zerofree', '-v', '/dev/mapper/loop0p2']
Exec: ['kpartx', '-dsv', 'fantronics.arm64.img']
ERROR: Program failed: 1
ERROR: RuncmdError('Program failed: 1')
All went fine.
This is from the .log file:
[..]
2022-05-08 16:48:04 INFO Exec: ['kpartx', '-dsv', 'myproject.arm64.img']
2022-05-08 16:48:05 DEBUG STDOUT: del devmap : loop0p1
loop0p2 is in use. Not removing
???
2022-05-08 16:48:05 DEBUG STDERR: loop deleted : /dev/loop0
2022-05-08 16:48:05 ERROR Program failed: 1
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/vmdb/app.py", line 243, in
run_steps_helper
method(values, settings, state)
File "/usr/lib/python3/dist-packages/vmdb/plugins/kpartx_plugin.py", line 51,
in teardown
vmdb.runcmd(["kpartx", "-dsv", device])
File "/usr/lib/python3/dist-packages/vmdb/runcmd.py", line 58, in runcmd
raise RuncmdError("Program failed: {}".format(p.returncode))
vmdb.runcmd.RuncmdError: Program failed: 1
2022-05-08 16:48:05 ERROR RuncmdError('Program failed: 1')
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/vmdb/app.py", line 243, in
run_steps_helper
method(values, settings, state)
File "/usr/lib/python3/dist-packages/vmdb/plugins/kpartx_plugin.py", line 51,
in teardown
vmdb.runcmd(["kpartx", "-dsv", device])
File "/usr/lib/python3/dist-packages/vmdb/runcmd.py", line 58, in runcmd
raise RuncmdError("Program failed: {}".format(p.returncode))
vmdb.runcmd.RuncmdError: Program failed: 1
Is it the underlined line? Interestingly this works fine in a docker container.
If I can provide more information, please let me know.
Regards, Daniel
- -- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages vmdb2 depends on:
ii cmdtest 0.32.14.gcdfe14e-2
ii debootstrap 1.0.126+nmu1
ii e2fsprogs 1.46.5-2
ii kpartx 0.8.8-1
ii parted 3.5-1
ii python3 3.10.4-1+b1
ii python3-jinja2 3.0.3-1
ii python3-yaml5.4.1-1+b1
ii qemu-utils 1:7.0+dfsg-5
Versions of packages vmdb2 recommends:
ii ansible 5.5.0-1
ii dosfstools4.2-1
ii qemu-user-static 1:7.0+dfsg-5
vmdb2 suggests no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEIB9kcJqmmF4VguFXclr8JZgo7DMFAmJ4AdIACgkQclr8JZgo
7DMKWQ/+Ju9gSdfcd/kmKyBs0sRLG/1ZFAWQ8VWpYaG7Dn3yiyo1W+KdemVvIZlS
SzPpiI+NOuY+AVC9QuC8LwuQeAvJ+koSsw8XQDHF9rzu3YM+63DchJIenUca4xdi
EgB73i4LTvE3AyAMoacCooz1Jwu18xQ2ZRUVYNnKZYpIhZE1xYUKeRUcZ8eIb2hC
7CteZIU3DUcb7sA8/XMhWwRuqS8v+q1lniw+2HPTDA23KT9GHxAeItJ5NVMd9D9k
JmZcWsL16+PUmFLN9GEdIIcebTUVP4GSqGg8ZfpA8IIADdkgUtixXi9a5zh+5Z90
rVgCuYM/4ZVw1Iu2IqjjNWU+uibY1YwrF2wD7GMg2FwyhQJapIs8dIOMpAniFlMG
lgcItd3IkftMYYjjtYE7luiiMOlhwGRlS0QTWIKGrzD0BLYQWEx1QD5hPtoIH+om
IxicYb+FraHc6JsHmY9m3NODjYRULeUR3z8tqQUMGbCF0EyRuzEzrri424hbtZHG
bffQTNlSWLKqU1G8ygE/bn5bqnCSZ5ZMqcGFiPVLmAFi+ssK5MioxdVZrwHjh4ZW
OIyxINh2oxcXk+r0ke0+Tyvy+cV2uMYnFLFhOS6pss5a76rw2WeasahJzim8xEVa
uHIxiwjIzLi9v+WjqlNOnL3+BoYaFRD7iOz+tESO0XEvv0wiXwk=
=nSGu
-END PGP SIGNATURE-
Bug#1010658: mutt: SMTP SASL authentication broken (base64 encoding?)
On Fri, 6 May 2022 13:04:50 -0700 "Kevin J. McCarthy" wrote: However, in the mean time I've pushed a commit up to branch 'kevin/gsasl-smtp-plain-workarounds' on gitlab: I've merged this branch into stable, and it will be a part of 2.2.5 sometime in the next few weeks. Antonio if this starts to cause problems for others and 2.2.5 isn't out yet, feel free to grab the patch and apply to 2.2.4-2: https://gitlab.com/muttmua/mutt/-/commit/9d5db7cb7e53be20bb3b87dd5877e7145660b931.patch -Kevin signature.asc Description: PGP signature
Bug#1010735: Update to sagemath 9.6 requires jupyter-sphinx requires ipywidgets >= 7
Source: sagemath Version: 9.5-4 Severity: normal Control: block -1 by 950598 Control: block -1 by 896460 The need for ipywidgets >= 7 is getting even bigger in sagemath 9.6. Sagemath now depends on jupyter-sphinx, see https://trac.sagemath.org/ticket/33507 jupyter-sphinx is broken in Debian because it depends on ipywidgets >= 7 (#950598). I'm not sure if we are stuck with sagemath 9.5 until we have ipywidgets >=7 or if it is an option to revert even more upstream commits in sagemath to keep this going.
Bug#1009663: pipewire: Stream properties `lfe-cutoff` and `upmix` don't work.
Sorry for the late reply. Email ended up in spam. Am currently sitting
on 0.3.51 and LFE is still not being generated. I have attached my
~/.config/pipewire/client.conf file in case I am missing something
obvious since no one else seems to be having this issue.
On Thu, 2022-04-14 at 10:29 +0200, Dylan Aïssi wrote:
> Hi,
>
> Le mer. 13 avr. 2022 à 23:00, Mladen Mijatov
> a écrit :
> >
> > Configuring `lfe-cutoff` and `upmix` in stream properties it's
> > suppose to
> > generate audio for subwoofer speaker on 5.1 sound card
> > configuration. This
> > doesn't happen. No matter if configuration is made in
> > ~/.config/pipewire/client.conf or /usr/share/pipewire/client.conf
> > it simply
> > won't generate LFE channel.
> >
>
> I just uploaded pipewire 0.3.50 to unstable, it should be available
> soon.
> This new version includes some changes that could fix your issue.
> Can you check if it works? Otherwise, can you forward this issue to
> upstream devs?
>
> Best,
> Dylan
--
Mladen Mijatov
Head of R&D, Way2CU
CEO, AGM Development
Key ID: 4096R/83EFD5A0 2013-08-18
# Client config file for PipeWire version "0.3.49" #
#
# Copy and edit this file in /etc/pipewire for system-wide changes
# or in ~/.config/pipewire for local changes.
#
# It is also possible to place a file with an updated section in
# /etc/pipewire/client.conf.d/ for system-wide changes or in
# ~/.config/pipewire/client.conf.d/ for local changes.
#
context.properties = {
## Configure properties in the system.
#mem.warn-mlock = false
#mem.allow-mlock = true
#mem.mlock-all = false
log.level= 0
default.clock.rate = 192000
#default.clock.quantum-limit = 8192
}
context.spa-libs = {
# =
#
# Used to find spa factory names. It maps an spa factory name
# regular expression to a library name that should contain
# that factory.
#
audio.convert.* = audioconvert/libspa-audioconvert
support.* = support/libspa-support
}
context.modules = [
#{ name =
#[ args = { = ... } ]
#[ flags = [ [ ifexists ] [ nofail ] ]
#}
#
# Loads a module with the given parameters.
# If ifexists is given, the module is ignored when it is not found.
# If nofail is given, module initialization failures are ignored.
#
# The native communication protocol.
{ name = libpipewire-module-protocol-native }
# Allows creating nodes that run in the context of the
# client. Is used by all clients that want to provide
# data to PipeWire.
{ name = libpipewire-module-client-node }
# Allows creating devices that run in the context of the
# client. Is used by the session manager.
{ name = libpipewire-module-client-device }
# Makes a factory for wrapping nodes in an adapter with a
# converter and resampler.
{ name = libpipewire-module-adapter }
# Allows applications to create metadata objects. It creates
# a factory for Metadata objects.
{ name = libpipewire-module-metadata }
# Provides factories to make session manager objects.
{ name = libpipewire-module-session-manager }
]
filter.properties = {
#node.latency = 1024/48000
}
stream.properties = {
# node.latency = 1024/48000
#node.autoconnect = true
# resample.quality = 10
# channelmix.normalize = false
channelmix.mix-lfe= true
channelmix.upmix = true
# channelmix.upmix-method = simple # none, psd
channelmix.lfe-cutoff = 200
#channelmix.fc-cutoff = 6000
#channelmix.rear-delay = 12.0
#channelmix.stereo-widen = 0.1
#channelmix.hilbert-taps = 0
}
Bug#1005818: task-lxde-desktop: libreoffice is used as default pdf reader
Am Sun, May 08, 2022 at 07:59:02PM +0200 schrieb Holger Wansing: > > set to "disabled" and I can not change anything here. > > Since evince is automatically installed, it's "just" a matter of setting > evince as the default application for PDF - as you already have tried to :-) Sure. > I managed to get this done easily by right-clicking on the PDF file, choose > "Open with...", then select the app "Document Viewer" (this is evince) from > "Office" section, set the checkbox for "Set selected application as default > action for this file type" - and you are done. ... and this should be done as system default for users convenience. > I did another test install with XFCE desktop environment, and there this > problem did not exist. Installed PDF viewer was here Atril (from the MATE > environment). > > So, it's after all an problem either with LXDE (the environment) or with > evince | libreoffice (the packages). > > I will reassign this bug to LXDE for now. Hope it can be fixed there. BTW, I'm not 100% sure whether some unusual default is also for xfce4 where I have seen starting Gimp to display PDF. Kind regards Andreas. -- http://fam-tille.de
Bug#1010376: RFS: rinetd/0.73-0.1 [NMU] [ITA] -- Internet TCP/UDP redirection server
Upload #2 is now on Mentors with the "New upstream release (Closes: #1010732)." comment. Thanks for your help!
Bug#1010676: chromium-l10n: -l10n version behind chromium version in Sid
Hi, Le sam. 7 mai 2022 à 20:39, Andres Salomon a écrit : > It should all be installable now. Is it? > Yes, it installed tonight ! Thank you. Sébastien
Bug#1000648: clevis: unlocking 2nd device doesn't happen
Control: tags 1000648 pending Paul Slootman wrote... > Perhaps this info could be added to a README.Debian in the clevis-luks > package? I looked for any documentation but unfortunately there isn't > any... I'd consider this bug closed if the initramfs option for crypttab > was mentioned in a README. Thanks for that input, it shouldn't hurt to do this. The typo fix is also on its way. Christoph signature.asc Description: PGP signature
Bug#1010736: gimp: Gimp crashed while quitting the software
Package: gimp
Version: 2.10.30-1+b1
Severity: normal
Dear Maintainer,
I was working in GIMP on a file. I was quitting the software when the GIMP
Crash Debug window appeared. I just followed the instructions requested.
Since I had already saved the file I was working on I didn't loose anything so
for now it's not to severe.
Here's the bug information from the GIMP Crash Debug window:
```
GNU Image Manipulation Program version 2.10.30
git-describe: GIMP_2_10_30
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
11.2.0-16' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-
languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-
major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-
libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto --enable-
objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-
arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nvptx-
none=/build/gcc-11-PrvGcK/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-
amdhsa=/build/gcc-11-PrvGcK/gcc-11-11.2.0/debian/tmp-gcn/usr --without-cuda-
driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-
gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-
link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-16)
# Libraries #
using babl version 0.1.92 (compiled against version 0.1.88)
using GEGL version 0.4.36 (compiled against version 0.4.34)
using GLib version 2.72.1 (compiled against version 2.70.4)
using GdkPixbuf version 2.42.8 (compiled against version 2.42.6)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.7 (compiled against version 1.50.4)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)
```
> fatal error: Abandon
Stack trace:
```
# Stack traces obtained from PID 7204 - Thread 7237 #
[New LWP 7235]
[New LWP 7237]
[New LWP 7245]
[New LWP 7246]
[New LWP 13117]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f324ac990fa in __futex_abstimed_wait_common64
(futex_word=futex_word@entry=0x7f3222ffd910, expected=7235,
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=128,
cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74
Id Target IdFrame
* 1Thread 0x7f32499fbe80 (LWP 7204) "gimp-2.10" 0x7f324ac990fa in
__futex_abstimed_wait_common64 (futex_word=futex_word@entry=0x7f3222ffd910,
expected=7235, clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=128, cancel=cancel@entry=true) at ../sysdeps/nptl/futex-
internal.c:74
2Thread 0x7f3222ffd640 (LWP 7235) "worker"__libc_read (nbytes=256,
buf=0x7f3222ffb480, fd=17) at ../sysdeps/unix/sysv/linux/read.c:26
3Thread 0x7f3221ffb640 (LWP 7237) "worker"__libc_read (nbytes=256,
buf=0x7f3221ff9480, fd=21) at ../sysdeps/unix/sysv/linux/read.c:26
4Thread 0x7f3220aa3640 (LWP 7245) "gmain" 0x7f324ab9a87f in
__GI___poll (fds=0x56414fc81a90, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
5Thread 0x7f3203fff640 (LWP 7246) "gdbus" 0x7f324ab9a87f in
__GI___poll (fds=0x56414fc9a8d0, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
6Thread 0x7f31deffa640 (LWP 13117) "paint"syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
Thread 6 (Thread 0x7f31deffa640 (LWP 13117) "paint"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x7f324ae99e5f in g_cond_wait () at /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2 0x56414ea2c5e1 in ()
#3 0x7f324ae7059d in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x7f324ac8cd80 in start_thread (arg=0x7f31deffa640) at
pthread_create.c:481
ret =
pd = 0x7f31deffa640
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139852171421248,
-5144567604252858972, 140721399094270, 140721399094271, 0, 139852171421248,
5114240873215206820, 5115603832376567204}, mask_was_saved = 0}}, priv = {p
Bug#903161: Patch included upstream
On Sun, 12 Apr 2020 15:45:22 +0200 Milan wrote: > I use Dovecot 1:2.3.4.1-5+deb10u1 on Debian 10. Setting > "stats_writer_socket_path=" does not resolve the issue in my case, I > also get "net_connect_unix() failed". The following patch is supposed > to fix the issue: > > https://dovecot.org/pipermail/dovecot/2019-January/114170.html > https://github.com/dovecot/core/commit/3fdb968687bf896a3e13c846e5eb6f0310dff65b > > Can this patch be included in Dovecot on Debian 10? > > Best regards. > > Has there been any updates that should fix this issue? Thanks.
Bug#1010714: sane-pixma: sane can't find scanner
Hi! It worked adding the fixed IP I setup on the router. Commenting that line makes scanner invisible to sane again. (all of this with the proprietary software uninstalled). Thanks! Best, Alexandre On May 08 2022, Jörg Frings-Fürst wrote: > Hello, > > thanks for your answer. > > Please add something like this > > bjnp://ScannerIP > > into your pixma.conf > > For the exact syntax and further parameters please look in 'man sane- > pixma'. > > CU > Jörg > > -- > New: > GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D > GPG key (long) : 09F89F3C8CA1D25D > GPG Key: 8CA1D25D > CAcert Key S/N : 0E:D4:56 > > Old pgp Key: BE581B6E (revoked since 2014-12-31). > > Jörg Frings-Fürst > D-54470 Lieser > > > git: https://jff.email/cgit/ > > Threema: SYR8SJXB > Wire: @joergfringsfuerst > Skype: joergpenguin > Ring: jff > Telegram: @joergfringsfuerst > > > My wish list: > - Please send me a picture from the nature at your home. > > > Am Sonntag, dem 08.05.2022 um 10:42 -0300 schrieb Alexandre > Lymberopoulos: > > Hello Jörg, > > > > The requested files are attached. It may be important to mention that > > I > > never edited them. And here is the output of 'export > > SANE_DEBUG_BJNP="5" && scanimage -L': > > > > [10:35:28.690309] [sanei_debug] Setting debug level of bjnp to 5. > > [10:35:28.690398] [bjnp] sanei_bjnp_find_devices, pixma backend > > version: 0.28.6 > > [10:35:28.690417] [bjnp] sanei_bjnp_find_devices: Configuration file > > is empty, No devices specified. > > [10:35:28.690427] [bjnp] sanei_bjnp_find_devices: Start auto- > > detection. > > [10:35:28.690612] [bjnp] prepare_socket: lo is not a valid IPv4 > > interface, skipping... > > [10:35:28.690645] [bjnp] prepare_socket: eth0 is IPv4 capable, > > sending broadcast, socket = 7 > > [10:35:28.690668] [bjnp] prepare_socket: wlan0 is IPv4 capable, > > sending broadcast, socket = 8 > > [10:35:28.690683] [bjnp] prepare_socket: lo is not a valid IPv6 > > interface, skipping... > > [10:35:28.690709] [bjnp] prepare_socket: eth0 is IPv6 capable, > > sending broadcast, socket = 9 > > [10:35:28.690730] [bjnp] prepare_socket: wlan0 is IPv6 capable, > > sending broadcast, socket = 10 > > [10:35:29.211886] [bjnp] sanei_find_devices: scanner discovery > > finished... > > > > No scanners were identified. If you were expecting something > > different, > > check that the scanner is plugged in, turned on and detected by the > > sane-find-scanner tool (if appropriate). Please read the > > documentation > > which came with this software (README, FAQ, manpages). > > > > Best, Alexandre > > P.S.: Now I noticed that pixma.conf has all lines as a comment. Is it > > right? > > > > On May 08 2022, Jörg Frings-Fürst wrote: > > > tags 1010714 + moreinfo > > > thanks > > > > > > Hello Alexandre, > > > > > > thank you for spending your time helping to make Debian better with > > > this bug report. > > > > > > > > > Please attach the config files > > > > > > - /etc/sane.d/pixma.conf > > > - /etc/sane.d/dll.conf > > > > > > and the output of > > > > > > export SANE_DEBUG_BJNP="5" && scanimage -L > > > > > > > > > CU > > > Jörg > > > > > > Am Samstag, dem 07.05.2022 um 23:00 -0300 schrieb Alexandre > > > Lymberopoulos: > > > > Package: libsane1 > > > > Version: 1.1.1-5 > > > > Severity: normal > > > > File: sane-pixma > > > > > > > > Dear Maintainer, > > > > > > > > Any software here usanig sane can't detect my PIXMA MG3510 over > > > > wireless network. For testing purposes I installed the > > > > proprietary > > > > software from Canon and eveything woked ok. > > > > > > > > I may provide any futher information upon request. > > > > > > > > Best, Alexandre > > > > > > > > -- System Information: > > > > Debian Release: bookworm/sid > > > > APT prefers testing > > > > APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable- > > > > security') > > > > Architecture: amd64 (x86_64) > > > > > > > > Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) > > > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > > > LANGUAGE=en_US:en > > > > Shell: /bin/sh linked to /bin/dash > > > > Init: systemd (via /run/systemd/system) > > > > > > > > Versions of packages libsane1:amd64 depends on: > > > > ii acl 2.3.1-1 > > > > ii adduser 3.121 > > > > ii libavahi-client3 0.8-5 > > > > ii libavahi-common3 0.8-5 > > > > ii libc6 2.33-7 > > > > ii libcairo2 1.16.0-5 > > > > ii libcurl3-gnutls 7.83.0-1 > > > > ii libgcc-s1 12-20220428-1 > > > > ii libglib2.0-0 2.72.1-1 > > > > ii libgphoto2-6 2.5.27-1 > > > > ii libgphoto2-port12 2.5.27-1 > > > > ii libieee1284-3 0.2.11-14 > > > > ii libjpeg62-turbo 1:2.1.2-1 > > > > ii libpng16-16 1.6.37-5 > > > > ii libpoppler-glib8 22.02.0-3 > > > > ii libsane-common 1.1.1-5 > > > > ii libsnmp40 5.9.1+dfsg-1+b1 > > > > ii libstdc++6
Bug#971249: [Pkg-samba-maint] Bug#971249: waf: CHECK_VALUEOF does not work during cross compilation
On Fri, 2022-05-06 at 11:40 +0300, Michael Tokarev wrote: > On Mon, 28 Sep 2020 06:53:03 +0200 Helmut Grohne > wrote: > > Source: tevent > > Version: 0.10.2-1 > > Tags: patch upstream > > User: debian-cr...@lists.debian.org > > Usertags: ftcbfs > > > > Thank you for applying my previous cross build patches. My previous > > installment ended with: > > > > > 5. waf has a mandatory run test for determining whether mkstemp > > > works. > > > 6. probably more > > > > I've now looked into this and think that there are two bigger steps > > to > > solve these. In the "probably more" department, there is a > > recurring > > scheme of using a "CHECK_VALUEOF". It is used to determine the > > value of > > an integer. If that value happens to be a compile time constant, it > > can > > be determined using bisection. waf already does something similar > > in > > CHECK_SIZEOF. I've implemented it for CHECK_VALUEOF and it now > > works > > similar to autoconf's AC_COMPUTE_INT. In particular, it only does > > the > > expensive bisection during cross compilation. In a native build, it > > continues to use the quick run test it did before. I've attached a > > patch > > for this. > > Umm. waf in samba is doing many "bad" things which can be done in a > more > efficient way not requiring to run compiled binaries. Yes, > sizeof(foo) is > a good example, valueof is another example. > > I think it is too much work to patch all these things out in debian. > It might be a good idea to try to ping upstream about this, maybe > they'll > include similar change(s) to make cross-compilations easier. But > probably > not in Debian. Samba regularly accepts changes to improve cross-compilation. We test a lame cross-compilation mode in our autobuild and would love to have both an improved test (that is more realistic) and any improvements our user community can find. > I'd not spend more time on trying to make waf-based samba builds to > be > cross-compilable, unless upstream is actually willing to accept the > work somehow. So far, it seems like upstream isn't willing even to > accept simple spelling fixes. We regularly accept patches that are correctly signed off and submitted to GitLab per https://wiki.samba.org/index.php/Contribute > FWIW, Helmut, what do you think about using qemu-user[-static] to > help > cross-compiling stuff? It should significantly help in situations > like > this one, to be able to run the small test binaries in an emulated > mode, > provided you do have the foreign libs installed on the system. Yes > it > is not the fastest, but for sizeof/valueof tests like this it will > Just Work, hopefully... This would seem to be the best route forward, per: https://wiki.samba.org/index.php/Waf#Using_--cross-execute Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/ Samba Team Member (since 2001) https://samba.org Samba Team Lead, Catalyst IT https://catalyst.net.nz/services/samba Samba Development and Support, Catalyst IT - Expert Open Source Solutions
Bug#1010711: RFS: codelite/16.0.0 dfsg2-1 [QA] -- Powerful and lightweight IDE
On Sat, 07 May 2022 22:29:46 + Håvard F. Aasen wrote: > I am looking for a sponsor for my package "codelite": > > [...] > > The changes is pushed here [1] since I don't have access to the > official repo. Håvard, thanks for your QA work. I only made a small change to the watch file before uploading (it hardcoded "dfsg2" in the version mangling), and consequently also retagged the debian release. I'll push all missing commits from your fork to the package's standard repo soon so it all appears in the expected location. pgpNukxL5aSWV.pgp Description: OpenPGP digital signature
Bug#921556: busybox: Enable more applets to support initramfs-tools
Control: tag -1 + upstream On Wed, 06 Feb 2019 18:58:06 + Ben Hutchings wrote: Package: busybox Version: 1:1.27.2-3 Severity: wishlist Once we have busybox 1.28.0, we could enable these extra applets on Linux: ipconfig [CONFIG_IPCONFIG] nuke [CONFIG_NUKE] resume[CONFIG_RESUME] run-init [CONFIG_RUN_INIT] So this is almost there, except of ipconfig which is not implemented yet. There's just a wip version, a first draft, klibc-utils/ipconfig.c.txt, not touched since initial import in Sep-2017. It's an interesting goal there, to have everything in busybox to stop providing two libCs and two shells and two everything in initramfs.. Thanks, /mjt
Bug#964579: lsblk not included in busybox version used with installer
Control: tag -1 + moreinfo On Wed, 8 Jul 2020 23:23:51 + Holger Levsen wrote: Package: busybox Version: 1:1.30.1-4 Severity: wishlist x-debbugs-cc: Russell Weber submitter: Russell Weber On Wed, Jul 08, 2020 at 02:43:43PM -0600, Russell Weber wrote: > Package: busybox > Version: 1:1.30.1-4 > Severity: wishlist > lsblk is a very useful tool for understanding your current disks and block > devices. It can be used to > query lots of information including disk manufacturer, serial number, model > number, the structure of your disks if the disk is already in use for > another block device. Given that the installer has mission critical goals > associated with the disks, it's a bit of a mystery that lsblk isn't > included into the busy box implementation used in the installer. This is > especially important when seeding automatic/unattended installs for debian > since many of the seed files used will query information from disks in > scripts using the "d-i partman/early_command string" of debconf. I can see > that this issue has been raised in multiple places online: stack overflow, > IRC. However, scanning older tickets, I was not able to find a ticket > which raises the issue. Is there any reason that lsblk as a command is not > included? As far as I can tell, the bloat size would only be around 20-40 > KiB in size. May I suggest that we start including the lsblk binaries in > the next versions of Debian? Hi Russel! Thank you for the detailed bug description. The only question remain is who will write lsblk for busybox, who writes the actual code to do all this? Can you help with that, to collect all the mentioned information in a useful for the user form? This applet is not written. Thanks, /mjt
Bug#980127: busybox-static: Please enable the "hush" applet
Control: tag -1 + moreinfo On Thu, 14 Jan 2021 13:12:58 -0800 Josh Triplett wrote: Package: busybox-static Version: 1:1.30.1-6 Severity: wishlist X-Debbugs-Cc: j...@joshtriplett.org For busybox-static, I'd love to have the "hush" applet available. It's a more feature-complete shell, including features such as brace expansion. Please consider enabling CONFIG_HUSH and CONFIG_HUSH_BASH_COMPAT in busybox-static. Hi Josh! Myself I haven't used hush in busybox but I always used ash. If we're to enable hush, I think we should remove ash and make hush the only shell. And do that in regular deb config too, - there's no good reason to keep them different. But I wonder what implications we might have there, if we switch from ash to hush. How compatible the two shells are? I dunno. I think it needs to be verified at least.. busybox's ash is very limited indeed. Thanks, /mjt
Bug#1010737: logwatch: dhcpd service doesn't output anything
Package: logwatch Version: 7.5.5-1 Severity: normal Running logwatch with the dhcpd service doesn't result in any output despite there being lots of dhcpd log lines. I've spent a little while trying to understand how dhcpd parsing is supposed to work, but I'm not quickly able to figure out where the problem is. $ sudo grep dhcpd /var/log/syslog.1 | wc 6218990 67996 $ sudo /usr/sbin/logwatch --service dhcpd $ -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: i386 (i586) Kernel: Linux 5.10.0-13-686 (SMP w/1 CPU thread) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages logwatch depends on: ii perl5.32.1-4+deb11u2 ii postfix [mail-transport-agent] 3.5.6-1+b1 Versions of packages logwatch recommends: pn libdate-manip-perl ii libsys-cpu-perl 0.61-2+b6 ii libsys-meminfo-perl 0.99-1+b5 logwatch suggests no packages. -- no debconf information
Bug#995636: transition: openssl
Control: tags -1 = confirmed On 2022-03-01 23:39:13 +0100, Sebastian Andrzej Siewior wrote: > Control: tags -1 - moreinfo > > Removing moreinfo tag since I provide more information in my previous > reply. > > On 2022-02-28 00:23:22 [+0100], To 995...@bugs.debian.org wrote: > > On 2022-02-14 15:01:34 [+0100], To Sebastian Ramacher wrote: > > > On 2022-02-01 21:11:11 [+0100], Sebastian Ramacher wrote: > > > > > Could you please update this transition request? It's open for four > > > > > months and no visible response. > > > > > > > > Kurt mention some 100 packages failing to build. I only see a handfull > > > > of bugs filed. So what's the status on those build failures? > > > > > > So new logs probably… > > > > Gathered new logs and finally processed them \o/. The list at > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org&tag=ftbfs-3.0 > > > > has been updated accordingly. I added bugs for packages for FTBFS which > > existed without new openssl (say due new gcc, old debhelper, …). I was > > not able to build a few packages (25) because the build dependency could > > not have been satisfied at the time. Please go ahead Cheers -- Sebastian Ramacher
Bug#1009425: prewikka: FTBFS: AttributeError: module 'collections' has no
On Sun, 8 May 2022 09:42:13 +0200 s3v wrote: > Dear Maintainer, > > > File "/usr/lib/python3/dist-packages/lesscpy/lessc/utility.py", line 28, in flatten > > if isinstance(elm, collections.Iterable) and not isinstance(elm, string_types): > > AttributeError: module 'collections' has no attribute 'Iterable' > > This issue belongs to python3-lesscpy and has been fixed upstream [1] So I need to fix something or just wait python3-lesscpy to be fixed ? Thanks for your help > > Kind Regards > > [1] https://github.com/lesscpy/lesscpy/commit/0bbcf058e9ca6715c73f8e438529a837476978c3 > >
Bug#1010738: node-rollup-plugin-uglify: depends on node-uglify (not node-uglify-js)
Package: node-rollup-plugin-uglify Version: 6.0.4+repack1-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 node-rollup-plugin-uglify depends on node-uglify which provides v2 of UglifyJS. Upstream release 6.0.4 pckage.json indicates that it requires v3 of UglifyJS. Please ensure that the package depends on the correct version. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJ4Ro0ACgkQLHwxRsGg ASEE4hAAm7oFNZVGDTmwMoC7dJUYYTE8GnR5BqM55TumbjsJGjIllKjml5Ydon0r QfXR0Kr9Wn8LN8kpEs+xqa9vmpREwM+fT+TbyBb/SR+cs/UqW4FtkFS9uDmytfds c1ZL79JcvE9+kMM03JhX6zMJEQhlVsy9Pnh8v7Kz1K73sTW0xNik56NVz/11aXo+ M//dHCyxmrxT1oLm8yQN3ARkmB4YvdM3zFXjXfHfpLubLDQwuY6fpWxd09DpjlKZ FMkqAajz0UFVnNi/YsFuXBJ7goBrABBxQmSJWzq/0b7nTSPnZd7jupwaMgGMVo9U guI+Mwpp7Jab12LiFBv+4qe2wCN8SgeGNUpyfnvrnN7pIYeZW4BwdTfIW3Dk9nUY VoUGoXiOV8KotINDQPb0zFKPPpvhvWdUW7lNpVcJyJ2inx+GEJTqsB2PofbzwOiE SeMc1KYkGP29bVCoTBXoqvE+LPZ4Yp/RJVvBerQV7rjQWOoJctmeG6FTSaVf7naJ 7ujhTx4sDA88bxDyNh4QsltubMG2MkT0R2jLIXpJtqxkEGRRAJvuwOrf6TRVrVZ/ TpuCPMHgaGDSA+gmMmXaEU5A2KsXzwF+TUJA44W1nif5qb3mMVynOJS9qYkQMPsh 0N2lXB1Ffe9kYGIflhcFYKQiJS3BwIe9lNO6Xzaix3RxqH3jMUU= =Y++U -END PGP SIGNATURE-
Bug#1010418: Proposed bugfix
I don't understand this code in that patch:
+ while (true) {
+ unowned Posix.Passwd passwd =
Posix.getpwent();
+ if (passwd.pw_name ==
GLib.Environment.get_user_name()) {
+ found = true;
+ cmd += passwd.pw_shell;
+ break;
+ }
+ }
Will that loop forever if get_user_name returns something that doesn't
have an entry in /etc/passwd?
Bug#1010739: haskell-distributive: FTBFS: doctests: : cannot satisfy -package distributive-0.6.2
Source: haskell-distributive
Version: 0.6.2-1
Severity: serious
>From my sbuild build log (on amd64, and haskell-devscripts version was
>0.16.14):
...
Running debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct
Non-zero exit code 1.
Running 2 test suites...
Test suite doctests: RUNNING...
-i
-i/<>/dist-ghc/build/autogen
-i/<>/dist-ghc/build
-i/<>/src
-package-env=-
-hide-all-packages
-no-user-package-db
-package-db=/var/lib/ghc/package.conf.d
-package-db=dist-ghc/package.conf.inplace
-optP-include
-optPdist-ghc/build/autogen/cabal_macros.h
-package-id=base-4.13.0.0
-package-id=base-orphans-0.8.2-1Y1ZqNmIsRFEurBzE3x0AA
-package-id=tagged-0.8.6-FYc8l1vwILF5OSKkSTSNII
-package-id=transformers-0.5.6.2
-package=distributive-0.6.2
-package-id=doctest-0.16.3-5Rdunu33bocFtnt3QIeq3L
Data.Distributive
Data.Distributive.Generic
Test suite doctests: FAIL
Test suite logged to: dist-ghc/test/distributive-0.6.2-doctests.log
Test suite spec: RUNNING...
Generics
Id
distribute idExample = idExample
Stream
runId (shead (stail (distribute streamExample))) = 1
PolyRec
runId (plast (runId (pinit (distribute polyRecExample = 1
Finished in 0.0240 seconds
3 examples, 0 failures
Test suite spec: PASS
Test suite logged to: dist-ghc/test/distributive-0.6.2-spec.log
1 of 2 test suites (1 of 2 test cases) passed.
doctests: : cannot satisfy -package distributive-0.6.2
(use -v for more information)
at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 106.
Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
"test", "--builddir=dist-ghc", "--show-details=direct") called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line
130
Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup",
"test", "--builddir=dist-ghc", "--show-details=direct") called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line
685
Debian::Debhelper::Buildsystem::Haskell::Recipes::check_recipe()
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
exit status 2
--
Daniel Schepler
Bug#1010740: ruby-bootsnap: FTBFS on ppc64el: test suite hangs
Source: ruby-bootsnap Version: 1.9.3-1 Severity: serious Tags: upstream ftbfs Justification: fails to build from source Forwarded: https://github.com/Shopify/bootsnap/issues/415 The ruby-bootsnap test suite hangs forever on ppc64el. This has been reported upstream at the link above, and happens on both the version in testing and the one in unstable. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#1010710: Bugs #1010712 and #1010710, feel free to adopt/take over
Golang FTBFS are funny...and it turns out neither golang-github-pierrec-cmdflag, nor its dependency golang-github-xo-dburl are actually needed for golang-github-pierrec-lz4.v4 That said, I did the work in the process of debugging golang-github-pierrec-lz4.v4's FTBFS while learning Golang packaging, and the packages are in good shape, and are only waiting for someone who is willing to maintain them: https://salsa.debian.org/go-team/packages/golang-github-xo-dburl.git * Use debian/sid branch. Upstream was created first due to a bug in dh-make-golang and I have insufficient salsa permissions to fix this. https://salsa.debian.org/go-team/packages/golang-github-pierrec-cmdflag.git * Aha, that's not necessarily a dh-make-golang bug, but may be a method to prevent commit history from flooding #debian-golang on IRC Best, Nicholas signature.asc Description: PGP signature
Bug#1009179: dkms: Upstream has removed mkdeb|mkdsc|mkbmdeb
The commit message for https://github.com/dell/dkms/commit/68b083eaa3f71c166adfece8e4f760e0cdf96185 says: "Distributions know much better than us, what is the proper way to package a DKMS module. Remove in-tree, semi-constantly out-of-date code." and a comment on https://github.com/dell/dkms/issues/70 says: "Distribution specific packaging was severely broken for most distributions and has been dropped in the latest release." This indicates that upstream has no interest in including or maintaining distro-specific module packaging (and, indeed, mkrpm has been removed from dkms too). So, if upstream won't do it, perhaps debian's package of dkms should include extra scripts providing the debian-specific functionality removed from dkms. `dkms-mkbmdeb`, for example, could be a standalone wrapper script that uses `dkms mktarball --binaries-only`. It could be based on the mkbmdeb code removed from dkms. ditto for `dkms-mkdeb` and `dkms-mkdsc` scripts. Having separate scripts would also make it easier to keep dkms up-to-date with upstream without having to patch it on every build. craig PS: not having to have the linux headers and a complete build environment on every machine would be useful. My fastest machine, for example, can compile the ZFS dkms module in a minute or so (per kernel version, and I typically have at least two, current and previous on every machine) while my other machines can easily take 15 or 20 minutes or more.
Bug#1010648: RFP: golang-github-pierrec-lz4.v4 -- LZ4 compression and decompression in pure Go (v4)
Control: retitle -1 ITP: golang-github-pierrec-lz4.v4 -- LZ4 compression and decompression in pure Go (v4) Control: owner -1 !
Bug#1010741: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc4 in position 136: invalid continuation byte
Package: dopewars Version: 1.5.12-19 Severity: normal Python's configparser cannot parse /usr/share/applications/dopewars.desktop. This is because that file is using ISO 8859-1 when it should be using UTF-8. Please fix the encoding of the .desktop file. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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
Bug#1010742: xonsh: 0.12.2+dfsg-2 package doesn't install if python3.9 is installed
Package: xonsh Version: 0.12.2+dfsg-2 Severity: important Hi, Upgrading xonsh to 0.12.2+dfsg-2 fails with Setting up xonsh (0.12.2+dfsg-2) ... File "/usr/lib/python3/dist-packages/xonsh/parsers/v310.py", line 79 match list(p): ^ SyntaxError: invalid syntax dpkg: error processing package xonsh (--configure): installed xonsh package post-installation script subprocess returned error exit status 1 This is because Python 3.9 is also installed on my system. # py3compile -p xonsh File "/usr/lib/python3/dist-packages/xonsh/parsers/v310.py", line 79 match list(p): ^ SyntaxError: invalid syntax # py3compile -V 3.10- -p xonsh (runs fine) Thanks, Fred -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xonsh depends on: ii python3 3.10.4-1+b1 ii python3-ply [python3-ply-yacc-3.10] 3.11-5 Versions of packages xonsh recommends: ii python3-prompt-toolkit 3.0.29-1 ii python3-pygments2.11.2+dfsg-2 ii python3-setproctitle1.2.2-2+b1 Versions of packages xonsh suggests: pn python3-pyperclip ii xonsh-doc 0.12.2+dfsg-2 -- no debconf information
Bug#1010284: python3-pip: runs into infinite loop when installing package with pyproject.toml file
I've encountered the same issue when attempting to install the aiohttp
package or anything that depends on it, which seems to be a lot.
File "/usr/lib/python3.10/_distutils_system_mod.py", line 125, in
_inject_headers
scheme['headers'] =
orig_install._load_schemes()['posix_prefix']['headers']
File "/usr/lib/python3.10/_distutils_system_mod.py", line 137, in
wrapped_load_schemes
_inject_headers(name, scheme)
File "/usr/lib/python3.10/_distutils_system_mod.py", line 125, in
_inject_headers
scheme['headers'] =
orig_install._load_schemes()['posix_prefix']['headers']
File "/usr/lib/python3.10/_distutils_system_mod.py", line 135, in
wrapped_load_schemes
schemes = _load_schemes()
File
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/install.py",
line 103, in _load_schemes
sysconfig_schemes = _load_sysconfig_schemes() or {}
File
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/install.py",
line 91, in _load_sysconfig_
schemes
with contextlib.suppress(AttributeError):
RecursionError: maximum recursion depth exceeded
[end of output]
Failed to build aiohttp
ERROR: Could not build wheels for aiohttp, which is required to install
pyproject.toml-based projects
Bug#1010743: ITP: cbetar2 -- A Buddhist text reader using CBETA APIs
Package: wnpp Severity: wishlist Owner: Meng-Yuan Huang X-Debbugs-Cc: debian-de...@lists.debian.org, m...@live.com * Package name: cbetar2 Version : 19.2.1 Upstream Author : Meng-Yuan Huang * URL : https://github.com/MrMYHuang/cbetar2 * License : MIT Programming Lang: TypeScript, C++ Description : A Buddhist text reader using CBETA APIs CBETA Electronic Buddhist Text Reader 2 app features: search by categories, full text search, bookmarks, share by link, offline browsing, Buddhism dictionary, themes, pagination, adjustable font size, Kai font, vertical text layout, Buddhist text printing, cross platforms, no ad, open source. CBETA is a rich Electronic Buddhist Text database with 1 GB size approximately. cbetar2 is like an RSS reader: it fetches interest Buddhist texts from the database and stores them to storage on demand for saving storage space and offline use. cbetar2 features many settings as shown above. cbetar2 has already been packaged and tested for amd64 & arm64 debs / Snap Store, x86_64 & aarch64 rpms / FlatHub / Fedora COPR, x86_64 & aarch64 AppImage, x86_64 & arm64e macOS, x64 & arm64 Windows. All use some degree of CI/CD. I can maintain this package alone. However, I am not a Debian Maintainer, so I need a sponsor.
Bug#1010714: sane-pixma: sane can't find scanner
tags 1010714 - moreinfo thanks Hello Alexandre, glad I could help you. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. Am Sonntag, dem 08.05.2022 um 17:24 -0300 schrieb Alexandre Lymberopoulos: > Hi! > > It worked adding the fixed IP I setup on the router. Commenting that > line makes scanner invisible to sane again. (all of this with the > proprietary software uninstalled). > > Thanks! > > Best, Alexandre > > On May 08 2022, Jörg Frings-Fürst wrote: > > Hello, > > > > thanks for your answer. > > > > Please add something like this > > > > bjnp://ScannerIP > > > > into your pixma.conf > > > > For the exact syntax and further parameters please look in 'man > > sane- > > pixma'. > > > > CU > > Jörg > > [...] signature.asc Description: This is a digitally signed message part
Bug#1010744: krename: Cannot open KRename via desktop file when using Wayland session
Package: krename Version: 5.0.1-1+b2 Dear Maintainer, Trying to start KRename via the application launcer when using a Wayland session fails. Running `krename` from a terminal is fine. This line is shown in `journalctl`: plasmashell[5276]: krename: Unknown option 'icon'. Doing research, seems like this has been reported [1] and fixed upstream [2] in Oct 2020, there just hasn't been a release in a while. It is a trivial fix (a change of the `Exec` line in .desktop file), perhaps it could be brought to Debian before the upstream release? Many thanks, Sam [1] https://bugs.kde.org/show_bug.cgi?id=427207 [2] https://invent.kde.org/utilities/krename/-/commit/9e21688a -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/1 CPU thread; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages krename depends on: ii kio5.90.0-3 ii libc6 2.33-7 ii libexiv2-270.27.5-3 ii libfreetype6 2.11.1+dfsg-2 ii libgcc-s1 12-20220428-1 ii libkf5completion5 5.90.0-1 ii libkf5configcore5 5.90.0-1 ii libkf5coreaddons5 5.90.0-1 ii libkf5crash5 5.90.0-1 ii libkf5i18n55.90.0-1 ii libkf5iconthemes5 5.90.0-1 ii libkf5itemviews5 5.90.0-1 ii libkf5jobwidgets5 5.90.0-1 ii libkf5jsapi5 5.90.0-1 ii libkf5kiocore5 5.90.0-3 ii libkf5kiofilewidgets5 5.90.0-3 ii libkf5kiowidgets5 5.90.0-3 ii libkf5service-bin 5.90.0-1 ii libkf5service5 5.90.0-1 ii libkf5widgetsaddons5 5.90.0-1 ii libkf5xmlgui5 5.90.0-1 ii libpodofo0.9.8 0.9.8+dfsg-2 ii libqt5core5a 5.15.2+dfsg-16+b1 ii libqt5gui5 5.15.2+dfsg-16+b1 ii libqt5widgets5 5.15.2+dfsg-16+b1 ii libqt5xml5 5.15.2+dfsg-16+b1 ii libstdc++6 12-20220428-1 ii libtag1v5 1.12-1 krename recommends no packages. krename suggests no packages. -- no debconf information
Bug#1010745: usb-storage: kernel taks hung when copying data via USB SATA adapter from external SSD with bad blocks
Package: src:linux Version: 5.16.12-1~bpo11+1 Severity: normal Dear Maintainer, It seems we can't use Linux for cloning drive data from faulty drives (with bad blocks) using USB SATA adapters. I wanted to clone data from this old SSD: ``` Device Model: LITEONIT LCM-128M3S 2.5" 7mm 128GB Serial Number:TW00RNVG550853138965 Add. Product Id: WQDA Firmware Version: WQDA User Capacity:128,035,676,160 bytes [128 GB] ``` using : ``` dd if=/dev/disk/by-id/source of=/some/destination iflag=fullblock conv=sync,noerror bs=8M status=progress ``` But the copying hangs after ~400MB. It seems that drive has some bad blocks, but I expected `dd` to be able to skip those due to `conv=sync,noerror` parameter. What happens is that kernel task is hung: ``` May 09 08:29:56 kernel: usb-storage 2-2.2:1.0: USB Mass Storage device detected May 09 08:29:56 kernel: scsi host6: usb-storage 2-2.2:1.0 May 09 08:29:57 kernel: scsi host6: scsi scan: INQUIRY result too short (5), using 36 May 09 08:29:57 kernel: scsi 6:0:0:0: Direct-Access LITEONIT LCM-128M3S 2.5" 7mm PQ: 0 ANSI: 0 May 09 08:29:57 kernel: scsi 6:0:0:0: Attached scsi generic sg0 type 0 May 09 08:29:57 kernel: sd 6:0:0:0: [sda] 250069680 512-byte logical blocks: (128 GB/119 GiB) May 09 08:29:57 kernel: sd 6:0:0:0: [sda] Write Protect is off May 09 08:29:57 kernel: sd 6:0:0:0: [sda] Mode Sense: 3b 00 00 00 May 09 08:29:57 kernel: sd 6:0:0:0: [sda] No Caching mode page found May 09 08:29:57 kernel: sd 6:0:0:0: [sda] Assuming drive cache: write through May 09 08:29:57 kernel: sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 May 09 08:29:57 kernel: sd 6:0:0:0: [sda] Attached SCSI disk May 09 08:31:03 kernel: usb 2-2.2: Disable of device-initiated U1 failed. May 09 08:31:08 kernel: usb 2-2.2: Disable of device-initiated U2 failed. May 09 08:31:08 kernel: usb 2-2.2: reset SuperSpeed USB device number 5 using xhci_hcd May 09 08:32:55 kernel: usb 2-2.2: reset SuperSpeed USB device number 5 using xhci_hcd May 09 08:32:55 kernel: sd 6:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=32s May 09 08:32:55 kernel: sd 6:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 0c fc 00 00 08 00 00 May 09 08:32:55 kernel: I/O error, dev sda, sector 850944 op 0x0:(READ) flags 0x80700 phys_seg 38 prio class 0 May 09 08:33:26 kernel: usb 2-2.2: reset SuperSpeed USB device number 5 using xhci_hcd May 09 08:36:01 kernel: INFO: task scsi_eh_6:564989 blocked for more than 120 seconds. May 09 08:36:01 kernel: Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1 May 09 08:36:01 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 09 08:36:01 kernel: task:scsi_eh_6 state:D stack:0 pid:564989 ppid: 2 flags:0x4000 May 09 08:36:01 kernel: Call Trace: May 09 08:36:01 kernel: May 09 08:36:01 kernel: __schedule+0x307/0x9f0 May 09 08:36:01 kernel: schedule+0x4e/0xc0 May 09 08:36:01 kernel: schedule_preempt_disabled+0x14/0x20 May 09 08:36:01 kernel: __mutex_lock.constprop.0+0x23f/0x460 May 09 08:36:01 kernel: ? try_module_get.part.0+0x4e/0xc0 May 09 08:36:01 kernel: device_reset+0x1d/0x50 [usb_storage] May 09 08:36:01 kernel: scsi_eh_ready_devs+0x6b3/0xcf0 [scsi_mod] May 09 08:36:01 kernel: ? _raw_spin_unlock_irqrestore+0x25/0x40 May 09 08:36:01 kernel: ? __pm_runtime_resume+0x58/0x80 May 09 08:36:01 kernel: scsi_error_handler+0x433/0x510 [scsi_mod] May 09 08:36:01 kernel: ? scsi_eh_get_sense+0x250/0x250 [scsi_mod] May 09 08:36:01 kernel: kthread+0x169/0x190 May 09 08:36:01 kernel: ? set_kthread_struct+0x40/0x40 May 09 08:36:01 kernel: ret_from_fork+0x1f/0x30 May 09 08:36:01 kernel: May 09 08:38:02 kernel: INFO: task scsi_eh_6:564989 blocked for more than 241 seconds. May 09 08:38:02 kernel: Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1 May 09 08:38:02 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 09 08:38:02 kernel: task:scsi_eh_6 state:D stack:0 pid:564989 ppid: 2 flags:0x4000 May 09 08:38:02 kernel: Call Trace: May 09 08:38:02 kernel: May 09 08:38:02 kernel: __schedule+0x307/0x9f0 May 09 08:38:02 kernel: schedule+0x4e/0xc0 May 09 08:38:02 kernel: schedule_preempt_disabled+0x14/0x20 May 09 08:38:02 kernel: __mutex_lock.constprop.0+0x23f/0x460 May 09 08:38:02 kernel: ? try_module_get.part.0+0x4e/0xc0 May 09 08:38:02 kernel: device_reset+0x1d/0x50 [usb_storage] May 09 08:38:02 kernel: scsi_eh_ready_devs+0x6b3/0xcf0 [scsi_mod] May 09 08:38:02 kernel: ? _raw_spin_unlock_irqrestore+0x25/0x40 May 09 08:38:02 kernel: ? __pm_runtime_resume+0x58/0x80 May 09 08:38:02 kernel: scsi_error_handler+0x433/0x510 [scsi_mod] May 09 08:38:02 kernel: ? scsi_eh_get_sense+0x250/0x250 [scsi_mod] May 09 08:38:02 kernel: kthread+0x169/0x190 May 09 08:38:02 kernel: ? set_kthread_struct+0x40/0x40 May 09 08:38:02 kernel: ret_from_fork+0x1f/0x30 May 09 08:38:02 kernel:
