Bug#1065247: new lighttpd servers mangled file names
FYI, I submitted a patch to Debian on 19 March, over two months ago. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067126 It has taken Debian developers (volunteers) over 10 weeks (!!!) to pick up a simple patch that I packaged for them and signed on salsa.debian.org. :(
Bug#1067126: RFS: lighttpd/1.4.76-3 -- light, fast, functional web server
Gianfranco, thank you for sponsoring this upload. > Please some nitpicks for a future upload > 1) wait for the sponsor upload before tagging, >many of your entries were never uploaded ack. Still, this seems like unnecessary latency between humans once a Debian developer volunteer picks up the sponsorship-request. This sponsorship-request bug was filed March 19 and as I write this, today is May 29, over two months later. > 2) don't create new entries if the previous ones are not yet in the archive Should the now-incorrect tags in the repository be deleted and re-tagged? I prefer not to move tags once the tag matches code on the master branch, hence why I created new entries in the changelog and new tags. Also, this sounds like a fragile limitation for which a bug should be filed. When uploading, it should be possible to programmatically query the current version in the archive, find that changelog entry, and then process the newer entries with versions between the current version in the archive and the new version being submitted. Cheers, Glenn
Bug#1067126: RFS: lighttpd/1.4.76-3 -- light, fast, functional web server
lighttpd-1.4.76-3 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.76-3 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 lighttpd (1.4.76-3) unstable; urgency=medium * Patch to fix graceful shutdown timeout
Bug#1061743: Gramps in Debian
On 5/26/24 23:56, Dr. Tobias Quathamer wrote: The package builds on my machine, although I had to disable a single test for now. You'll find it in the newly created patch. Maybe you have an idea what's causing the failure, so it can be fixed properly. https://gramps-project.org/bugs/view.php?id=13305 i think this is just a wrong assumption on the side of the upstream testsuite (shadowed by their workflows). upstream evades this by ensuring that "~/.gramps/" is there before running the tests (both in their GitHub action, and in their debian/ packaging). i think that for now the proper resolution for the problem is to simply do a `mkdir "$CURDIR)/build/.gramps` before running the tests. (which i've now pushed to the 'experimental' branch) as a sidenote: the testsuite now creates a *very* verbose buildlog (~420MB). is that ok? gf,madsr IOhannes OpenPGP_0xB65019C47F7A36F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1016685: v4l2loopback: CVE-2022-2652 - leaking kernel memory via crafted card labels
On Mon, 8 Aug 2022 07:29:01 +0100 Neil Williams wrote: No changes are required in the misfiled bug report. so how to proceed? should i just close this bug-report? mgfdsa IOhannes
Bug#1070829: ITP: wprs -- rootless remote desktop access for remote Wayland and x11 applications like xpra
Package: wnpp Subject: ITP: wprs -- rootless remote desktop access for remote Wayland and X11 applications like xpra X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Yifei Zhan Severity: wishlist * Package name: wprs Version : 0.1.0 Upstream Contact: Nicolas Avrutin * URL : https://github.com/wayland-transpositor/wprs * License : Apache 2.0 Programming Lang: Rust Description : rootless remote desktop access for remote Wayland (and X11, via XWayland) applications like xpra wprs implements rootless remote desktop access for remote Wayland (and X11, via XWayland) applications with supports for session resumption (running applications will survive wprsc disconnection and later reconnection and wprsc restarts). Currently only the the Core and XDG shell protocols are implemented and hardware rendering/dmabuf support is not yet implemented. Generally, wprs will aim to support as many protocols as feasible, it's a question of time and prioritization.
Bug#1070800: ITP: evremap -- keyboard input remapper for Linux/Wayland systems
Subject: ITP: evremap -- keyboard input remapper for Linux/Wayland systems Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Yifei Zhan Severity: wishlist * Package name: evremap Version : 0.1.0 Upstream Author : Wez Furlong * URL : https://github.com/wez/evremap * License : MIT Programming Lang: Rust Description : keyboard input remapper for Linux/Wayland systems evremap works by grabbing exclusive access to an input device and maintaining a model of the keys that are pressed. It then applies your remapping configuration to produce the effective set of pressed keys and emits appropriate changes to a virtual output device. Because evremap targets the evdev layer of libinput, its remapping is effective system-wide: in Wayland, X11 and the linux console. (^ from project readme) It works well on my machines and supports more complex mapping (e.g. dual role key based on tapping/holding and M <-> N mapping (F3 -> Ctrl-K / Shift-K -> F5)) while maintaining a simple configure syntax.
Bug#1070793: security.debian.org: Hibernate does not work from KDE Plasma menu. System does not power off.
2024-05-09
Thread
Hibernation does not work after update to Debian GNU/Linux, with Linux 5.10.0-29-amd64
Package: security.debian.org Severity: normal X-Debbugs-Cc: martin@rod.cz Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines ***
Bug#1067126: RFS: lighttpd/1.4.76-2 -- light, fast, functional web server
lighttpd-1.4.76-2 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.76-2 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 lighttpd (1.4.76-2) unstable; urgency=medium * Fix FTBFS Linux on SPARC * Declare compliance with policy 4.7.0 - no changes needed.
Bug#1067126: RFS: lighttpd/1.4.76-1 -- light, fast, functional web server
lighttpd-1.4.76-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.76-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 lighttpd (1.4.76-1) unstable; urgency=medium * New upstream version 1.4.76 * Detect VU#421644 HTTP/2 CONTINUATION Flood * Avoid CVE-2024-3094 xz supply chain attack
Bug#1030150: freeplane fails to start with java 18 (openJDK 18) and openJDK 17.
Hi Felix, as Debian (and many derivates) still ship with old JDK, there is in my eyes no reason to remove Freeplane because of that. Also it would be a shame if it maybe would vanish from it, in that way. FTR: I am tunning OpenJDK 1.17.10 on Devuan, and Freeplane 1.7.0 runs fine (also still a 32bit system) Best, Alex Felix Natter am Sonntag, 31. März 2024, 17:11:02: > Dear users, > > you can download and install the .deb version that upstream provides: > - https://sourceforge.net/projects/freeplane/ > - select "Files" > - select "freeplane stable" > - select freeplane_1.11.11~upstream-1_all.deb > - install with "sudo apt install > /path/to/freeplane_1.11.11~upstream-1_all.deb" > > (the file name of the stable version may change over time!) > > Note this bug related to ibus: > https://github.com/freeplane/freeplane/issues/1069 > > You can also, as the reporter noted, switch to an old JRE (mind security > issues though!), either through JAVA_CMD or FREEPLANE_JAVA_HOME. > > I cannot package freeplane-1.11.x for Debian because it requires > gradle >= 7.x. > > I am discussing with the debian-java team whether to remove freeplane > from Debian/Ubuntu for security reasons (old JRE versions...), unless > you disagree strongly [1]! > > [1] https://lists.debian.org/debian-java/2024/03/msg00016.html > > Cheers and Best Regards, > Felix > -- > Felix Natter >
Bug#1067126: RFS: lighttpd/1.4.75-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.75-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.75-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Thank you. Glenn P.S. There is a regression in lighttpd 1.4.74 that is fixed with a patch in tag lighttpd-1.4.74-3 on salsa.d.o. Does that need to go through the release process for the changelog entries to automatically close bugs? If so, please upload 1.4.74-3 to Unstable, and in a few days 1.4.75-1. With the time64 migration, everything is stuck in Unstable, anyway. Note: with lighttpd 1.4.74-3, lighttpd is time64 agnostic and so this package could safely go to Testing, and will work properly (with 64-bit time_t) on 32-bit platforms even without the rest of the time64 libs.
Bug#1067053: qa.debian.org: Documented policy needed for bug archival + archival transparency needed
Package: qa.debian.org Severity: normal X-Debbugs-Cc: debbug.qa.debian@sideload.33mail.com Control: affects -1 +www.debian.org There are essentially no documented policies or procedures for bug report archival. The only disclosure on the website is here: https://www.debian.org/Bugs/server-control#unarchive It’s so minimal I will just copy it here: > archive bugnumber > > Archives a bug that had been archived at some point in the past but > is currently not archived if the bug fulfills the requirements for > archival, ignoring time. > > unarchive bugnumber > > Unarchives a bug that was previously archived. Unarchival should > generally be coupled with reopen and found/fixed as > appropriate. Bugs that have been unarchived can be archived using > archive assuming the non-time based archival requirements are > met. You should not be using unarchive to make trivial changes to > archived bugs, such as changing the submitter; its primary purpose > is to allow for the reopening of bugs which have been archived > without the intervention of BTS administrators. That’s it. There is no further guidance in the www.debian.org/Bugs/* tree. It seems to say artificial archival can only be requested on bugs that were previously archived. Yet there are bugs that have been archived just 1 month after opening. This indicates undisclosed / non-transparent procedures are in play. Then it says unarchival should only be requested on naturally archived bugs (due to aging). Should that “policy” be revisited? Is archival a synonym for bug closure? What are the reasons a bug report can or should be artificially archived by intervention? The Debian Social Contract (DSC) has a transparency clause: > 3. We will not hide problems > >We will keep our entire bug report database open for public view >at all times. Reports that people file online will promptly >become visible to others. That’s a good start but IMO it would improve quality if that were to go a step further and (by extension) state that open public /discussion/ of problems will also be facilitated. The archival of a bug report has the speech/idea-chilling effect of closing it and blocking further discussion. This bug report is motivated by another. I thought of a new feature that would improve the reportbug application. A search of bug reports showed that someone already put forward the same idea (bug 1002906). There’s more to say on that, so I responded. My contribution was suppressed because the bug was archived. In fact it was archived just a month or so after it was opened. Big transparency problem: even the verbose view of the bug report showing extraneous control messages gives no indication of /how/ or /why/ the bug was archived, or /who/ initiated it. We can only guess that based on the very short timeframe open that it was archived by intervention. Which means requesting unarchival goes against what I quoted from the server control page. I don’t imagine that whoever initiated the archival actually intended to suppress the discussion. It was likely maintainers looking to get the bug report out of their view (out of sight, out of mind) for organizational reasons. But since archival has the effect of suppressing discussion, it’s not a proper mechanism for that. ** Proposal ** I propose several actions to remedy all this. ① Revision to the DSC to include public discourse w.r.t bug reports. ② Drafting a clear and comprehensive policy informing everyone as to proper and improper usage of bug archival and unarchival. Adapt Bugs/server-control#unarchive as needed. ③ Modify the BTS as needed to include basic archival information in the public views of bug reports, such as: * who initiated the archival * why it was archived (age or intervention; and if intervention then the rationale for the intervention) ④ Reopen bug 1002906 if it’s deemed to have been archived without good cause.
Bug#1037327: MariaDB upgrade fails if page compressed tables exist already due to plugin dependency
I also have this issue but it is with the audit plugin, and it impacts MariaDB upgrades over apt, rather than an install of MariaDB from scratch. I receive this message in the syslog from mariadb-server-10.3.postinst Installation of system tables failed! ... In /var/log/mysql/error.log, I see this: [ERROR] mysqld: Can't open shared library '/usr/server_audit.so' (errno: 22, cannot open shared object file: No such file or directory) [ERROR] Couldn't load plugins from 'server_audit.so'. [ERROR] /usr/sbin/mysqld: unknown variable 'server_audit=FORCE_PLUS_PERMANENT'[ERROR] Aborting The database server continues to function correctly after the service starts. The audit plugin is functional outside of the postinst script. This issue has happened for about a year or two and I never noticed any issues otherwise. I was concerned about a new patch adding newly required system tables failing, such as with an upgrade from Buster to Bullseye, etc. I am unsure if this is the exact same issue as this big. If not, let me know and I can open a new bug report. On a mostly normal Buster: dpkg -l | grep maria ii libmariadb3:amd64 1:10.4.14+maria~buster amd64 MariaDB database client library ii mariadb-client-10.3 1:10.3.39-0+deb10u2 amd64 MariaDB database client binaries ii mariadb-client-core-10.3 1:10.3.39-0+deb10u2 amd64 MariaDB database core client binaries ii mariadb-common 1:10.4.14+maria~buster all MariaDB database common files (e.g. /etc/mysql/conf.d/mariadb.cnf) ii mariadb-server 1:10.3.39-0+deb10u2 all MariaDB database server (metapackage depending on the latest version) ii mariadb-server-10.3 1:10.3.39-0+deb10u2 amd64 MariaDB database server binaries ii mariadb-server-core-10.3 1:10.3.39-0+deb10u2 amd64 MariaDB database core server files ii mysql-common 1:10.4.14+maria~buster all MariaDB database common files (e.g. /etc/mysql/my.cnf)
Bug#1064903: ITP: slm -- school library management
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: slm Version : 0.4 Upstream Contact: Georges Khaznadar * URL : https://salsa.debian.org/georgesk/slm0 * License : GPL-3+ Programming Lang: Python, Javascript Description : school library management SLM stands for "school library management". It provides a web service useful for teams who lend school books to students. Here are some features: . - defining constants for the school, like name, logo, manager's name - creating a catalogue of available books - managing the inventory of books, each one identified by a unique barcode - importing lists of students, with their optional curricula - lending quickly a few books to every student, with the help of a barcode reader - managing the book returns, with the help of a barcode reader - replying to some request, like "whom is this book?", list of students which still owe books, list of students who have no book lended, and so on. - every web page comes with a contextual help I am using SML in my school's cooperative association to lend school books to students, and already packaged extra dependencies which were not part of Debian previously: python3-pylabels, node-html5-qrcode, python3-trml2pdf. This package's source is maintained in Salsa: https://salsa.debian.org/debian/slm
Bug#1064572: RFS: lighttpd/1.4.74-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.74-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.74-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Thank you. Glenn
Bug#1063563: ghostscript: ps2epsi fails with Error: /undefined in /finddevice
Sorry, with all the testing with different versions, the email picked some bogus attachments. The second message should be good. On Sun, 18 Feb 2024 13:16:53 +0100 =?utf-8?Q?Stephan_B=C3=B6ttcher?= wrote: > > Tha attached ps file was made with > > $ lepton-schematic --version > Lepton EDA/lepton-schematic 1.9.18.20220529 (git: d24967d) > via Print to File, PDF, > and ps2pdf. > -- Stephan
Bug#1062756: cryptsetup-initramfs: cryptkeyctl script fails to discover decrypt_keyctl even when present
That does indeed seem to be the case. It appears that my distro activated a temporary directory override recently, and I already had /tmp mounted as NOEXEC. Bug report for my distro for anyone that comes across this: https://github.com/Kicksecure/security-misc/issues/198 Thank you On Friday, February 2nd, 2024 at 7:39 PM, Guilhem Moulin - guilhem at debian.org wrote: > > > Control: tag -1 moreinfo > > Hi, > > On Fri, 02 Feb 2024 at 18:44:43 -0500, abrasamji wrote: > > > update-initramfs log excerpt with set -x: > > > > Calling hook cryptkeyctl > > + PREREQ=cryptroot > > + . /usr/share/initramfs-tools/hook-functions > > + [ ! -x > > /tmp/user/0/mkinitramfs_LhQz6c/lib/cryptsetup/scripts/decrypt_keyctl ] > > + exit 0 > > > > A check with ls -la while update-initramfs was running, prior to > > cryptkeyctl being executed, in order to prove it's presence: > > > > /tmp/user/0/mkinitramfs_LhQz6c/usr/lib/cryptsetup/scripts: > > total 4 > > drwxr-xr-x 2 root root 60 Feb 2 17:44 . > > drwxr-xr-x 3 root root 100 Feb 2 17:44 .. > > -rwxr-xr-x 1 root root 2042 Apr 20 2023 decrypt_keyctl > > > > I changed the '-x' flag in the if statement to a '-s' flag. This fixed > > it and I don't know why, and I don't know if its a bug in initramfs, > > dash, or cryptsetup or something else. > > > Seems like your update-initramfs is running under TMPDIR=/tmp/user/0, is > is perhaps mounted with the ‘noexec’ flag set? > > That would cause `test -x` to fail on an existing path with the exec bit > set, and per mkinitramfs(8) this not supported: > > ENVIRONMENT > > mkinitramfs honours the TMPDIR environment variable. If set, it > uses subdirectories in the given directory to create its > temporary working directories. Else it uses /var/tmp as default > value for that purpose. The given directory should be on a > filesystem which allows the execution of files stored there, i.e. > should not be mounted with the noexec mount option. > > -- > Guilhem.
Bug#1062756: cryptsetup-initramfs: cryptkeyctl script fails to discover decrypt_keyctl even when present
In case anyone else is having this issue, error appears to the end user as: decrypt_keyctl: empty input from stdin keyctl: command not found Cryptsetup then gives an error about the password being incorrect.
Bug#1059796: tilda: fails to respond to show/hide command depending on active application
Hi, and thanks for the quick reponse. Sorry, I didn't know that this was a "known issue", despite some searching for related terms. Thanks for the fix, and the workarounds. I can confirm that using an Xorg session gives reliable show/hide responses from Tilda as before. Thank you, and feel free to close this issue or keep it open until you have uploaded, as you wish :) On 14/01/2024 16:04, Sebastian Geiger wrote: This is a known issue that will be resolved once the D-Bus enabled update of tilda will reach the distribution. I am planning a new upload in the next weeks that will ship a new tilda version. In the mean time, there are two workarounds: * one is to build tilda from source if you are on Wayland as the current master branch of tilda already has the D-Bus support. * another one is to use an Xorg session instead of Wayland.
Bug#1061602: vmtouch invalid option parsing
Package: vmtouch Version: 1.3.1-2 Severity: important looking at the cmdline arguments the service actually provides to vmtouch it is mangling the provided ones and thereby creates invalid arguments. esp. for "-p 0-50k" which becomes "-p 0 50" and "-P /run/vmtouch" which somehow gets joined together with the first provided item to cache. `cat /etc/default/vmtouch`: ``` # Change to yes to enable running vmtouch as a daemon ENABLE_VMTOUCH=yes # User and group to run as VMTOUCH_USER_GROUP=root:root # Whitespace separated list of files and directories for vmtouch to operate on VMTOUCH_FILES="/folder001/ /folder002/ /folder003/ /folder004/ /folder005/ /folder006/" # Options to pass to vmtouch itself. See vmtouch(8). VMTOUCH_OPTIONS="-d -L -p 0-50k -f -P /run/vmtouch.pid" ``` `systemctl status vmtouch.service | grep CGroup -A1`: ``` CGroup: /system.slice/vmtouch.service └─10341 /usr/bin/vmtouch -d -L -p 0 50 "" -f -P /run/vmtouch.pid /folder001 "" /folder002 "" /folder003 "" /folder004 /folder005 /folder006 ``` `dpkg --search vmtouch` ``` vmtouch: /etc/init.d/vmtouch vmtouch: /usr/share/doc/vmtouch/TODO vmtouch: /usr/share/doc/vmtouch/TUNING.md vmtouch: /etc/default/vmtouch vmtouch: /usr/share/doc/vmtouch/changelog.gz vmtouch: /usr/share/doc/vmtouch/changelog.Debian.gz vmtouch: /usr/share/doc/vmtouch vmtouch: /usr/share/doc/vmtouch/copyright vmtouch: /usr/bin/vmtouch vmtouch: /usr/share/doc/vmtouch/README.md vmtouch: /usr/share/man/man8/vmtouch.8.gz ``` `dpkg --list vmtouch`: ``` Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---== ii vmtouch1.3.1-2 amd64Portable file system cache diagnostics and control ``` `dpkg --status vmtouch` ``` Package: vmtouch Status: install ok installed Priority: optional Section: admin Installed-Size: 68 Maintainer: Lucas Nussbaum Architecture: amd64 Version: 1.3.1-2 Depends: lsb-base (>= 3.0-6), libc6 (>= 2.15) Pre-Depends: init-system-helpers (>= 1.54~) Conffiles: /etc/default/vmtouch ed573c189b71c232b5fcd2057b634b51 /etc/init.d/vmtouch 45af12b8bbff820fbbe73145fce96c19 Description: Portable file system cache diagnostics and control vmtouch is a tool for learning about and controlling the file system cache of unix and unix-like systems. It can discover which files the OS is caching, tell the OS to cache or evict some files or regions of files, lock files into memory so the OS won't evict them, and more. Homepage: https://hoytech.com/vmtouch/ ```
Bug#1036079: firecracker: change from RFP to ITP and assign to self
retitle 1036079 ITP: firecracker -- micro KVM-based virtual machine monitor owner 1036079 !
Bug#1060326: reverse dependencies
On Sun, 14 Jan 2024 17:16:55 + (UTC) Thorsten Alteholz wrote: Control: tags -1 + moreinfo Hi IOhannes, there are reverse dependencies that need to be taken care of: indeed. In case they matter, this needs to be addressed first. Please remove the moreinfo tag once that is done. my gut feeling tells me, the ppc64el versions of all these reverse dependencies do not really matter. infact, these source packages only build plugins for obs-studio (and therefore useless without obs-studio). as such i would vote to remove theire ppc64el builds as well. what is required from my side? do i need to contact the maintainers of these packages to coordinate? mgdsar IOhannes
Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12
Good day, does grub 2.12 (without rc1) help? There are a good pile of fixups between rc1 and release. E.g. https://git.savannah.gnu.org/cgit/grub.git/commit/?h=grub-2.12=1f5b180742ff2706bc3a696d115ddbc677ec75b9 or https://git.savannah.gnu.org/cgit/grub.git/commit/?h=grub-2.12=67ae3981dc5113e5af3a0539174bcd7eab8f7722 could help. Additionally, the ZFS fixes are needed to boot from volumes touched by ZFS 2.2 ( https://github.com/openzfs/zfs/issues/13873 ), so migrating to 2.12 is helpful in either case. Best regards, Michael Fritscher On Sat, 25 Nov 2023 17:36:41 -0500 Nicolas Haller wrote: > Package: grub-efi-amd64 > Version: 2.06-13 > Severity: critical > Justification: breaks the whole system > > Dear Maintainer, > > My old laptop (Lenovo 11e) runs Sid and all was right before I updated > it the other day (I don't do that very often). After that upgrade, GRUB > wasn't able to load any kernel with the pretty much generic error > "Error: can't load image". The version of GRUB was 2.12~rc1-12. > If I try to boot again, GRUB tells me that I need to load the image > first (I guess it somehow ignores the linux command and sends that when > trying to load the initrd). > > I tried to reinstall grub, grub-install /dev/sda, update-grub, reinstall > the kernel, update-initramfs from the rescue mode but nothing worked. > The "file" command was able to read the vmlinuz file and none seemed > truncated. The system has one partition with both / and /boot and isn't > running out of space. > I did not see any error message during those operation besides GRUB > saying it wasn't able to update EFI parameters. > > I don't know if there is a way to get more logs or error message during > the boot explaining why it wasn't able to load the image. > > I tried to get the last version of GRUB from Bookworm, that is > 2.06-13, and now I'm able to boot. The kernel version did not change, > the only change I did is to downgrade GRUB (and dependencies apt was > asking for). > > I'm not sure which GRUB package I should use for reporting so I took the > one that seems the most specific to my system. Apologies if it is not > correct. > > Let me know if you need more info. > > Thanks, > > -- > Nicolas Haller > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- Package-specific info: > > *** BEGIN /proc/mounts > /dev/sda2 / ext4 rw,relatime,errors=remount-ro 0 0 > /dev/sda1 /boot/efi vfat > rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro > 0 0 > *** END /proc/mounts >
Bug#1035902: obs-studio: NVENC codec fails unless I use ffmpeg to encode a video first
Package: obs-studio Followup-For: Bug #1035902 Hi, i cannot reproduce this problem. i'm using ffmpeg_7:6.1.1-1 and nvidia-driver_535.43.02-1 (from experimental, as the version in stable currently cannot be used by ffmpeg to run nvenc). Does the problem still exist on your side? -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.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 obs-studio depends on: ii libavcodec60 7:6.1.1-1 ii libavdevice60 7:6.1.1-1 ii libavformat60 7:6.1.1-1 ii libavutil587:6.1.1-1 ii libc6 2.37-13 ii libcurl3-gnutls8.5.0-2 ii libfontconfig1 2.14.2-6+b1 ii libfreetype6 2.13.2+dfsg-1+b1 ii libgcc-s1 13.2.0-9 ii libglx01.7.0-1 ii libjansson42.14-2+b2 ii libluajit-5.1-22.1.0~beta3+git20220320+dfsg-4.1 ii libmbedcrypto7 2.28.6-1 ii libmbedtls14 2.28.6-1 ii libmbedx509-1 2.28.6-1 ii libobs030.0.2+dfsg-2 ii libopengl0 1.7.0-1 ii libpci31:3.10.0-2 ii libpulse0 16.1+dfsg1-3 ii libpython3.11 3.11.7-2 ii libqrcodegencpp1 1.8.0-1.2 ii libqt6core66.4.2+dfsg-20 ii libqt6gui6 6.4.2+dfsg-20 ii libqt6network6 6.4.2+dfsg-20 ii libqt6svg6 6.4.2-4 ii libqt6widgets6 6.4.2+dfsg-20 ii libqt6xml6 6.4.2+dfsg-20 ii librist4 0.2.10+dfsg-1 ii libspeexdsp1 1.2.1-1 ii libsrt1.5-openssl 1.5.3-1 ii libstdc++6 13.2.0-9 ii libswscale77:6.1.1-1 ii libudev1 255.2-4 ii libv4l-0 1.26.1-2+b1 ii libva-drm2 2.20.0-2 ii libva2 2.20.0-2 ii libx11-6 2:1.8.7-1 ii libx264-1642:0.164.3095+gitbaee400-3+b2 ii libxcb-composite0 1.15-1 ii libxcb-randr0 1.15-1 ii libxcb-shm01.15-1 ii libxcb-xfixes0 1.15-1 ii libxcb-xinerama0 1.15-1 ii libxcb11.15-1 ii libxkbcommon0 1.6.0-1 ii python33.11.6-1 ii python3.11 3.11.7-2 ii qt6-image-formats-plugins 6.4.2-5 ii qt6-wayland6.4.2-5 Versions of packages obs-studio recommends: ii obs-plugins 30.0.2+dfsg-2 Versions of packages obs-studio suggests: ii pkexec 123-3 ii policykit-1123-3 ii v4l2loopback-dkms 0.12.7-2 -- no debconf information
Bug#1057767: Info received (Bug#1057767: pipewire: Last upgrade completely broke bluetooth connection: : org.bluez.Error.Failed br-connection-unknown)
Seems to be solved with the latest update I ran on Friday (all 4 packages to 1.0.0.-3).
Bug#1058934: apt install ./foo.deb re-downloads the package
On 12/18/23 15:38, Stuart Prescott wrote: This is a regression since bookworm. note that i am experiencing this on a bookworm system. while i don't use backports (so 'apt' should be indeed the one that comes with bookworm), i do have some third-party repository enabled (gitlab). i did notice the problem when using 'apt-get' (rather than 'apt') to install a local .deb file (which happens to be >1GB, so the re-download is quite noticeable): ```sh apt-get install /dev/shm/gitlab-ce_16.6.2-ce.0_amd64.deb ``` (that's just for completeness sake; i'm full aware that i'm on my own when enabling 3rd party repositories; but given that stuart was able to reproduce this on a (presumably) pristine system, it might help that others experience this before trixie) gmasdr IOhannes OpenPGP_0xB65019C47F7A36F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057767: pipewire: Last upgrade completely broke bluetooth connection: : org.bluez.Error.Failed br-connection-unknown
That was the first thing. Only after that didn't help I downgraded those four packages. From my POV I _don't_ use PipeWire -- I have no idea why those packages are pulled in since I sue PulseAudio. Since I don't know what exactly happens I am unable to say if it is PW related (and if it were, wouldn't that make it a Debian issue since I don't use PW, but PA and do try to actively avoid PW?). On 12/12/2023 11:25, Dylan Aïssi wrote: Hi, Le ven. 8 déc. 2023 à 10:48, arne anka a écrit : * What led up to the situation? On Dec 6 I upgraded and since the my BT thingy does not connect to my PC anymore. I am hearing impaired and need to use a BT thingy called RemoteMic+ (by Starkey) to be able to listen to music or make calls/attend meetings via PC. So, this is a major issue for me. Among others these packages were upgraded: firmware-iwlwifi libpipewire-0.3-0 libpipewire-0.3-common libspa-0.2-bluetooth libspa-0.2-modules * What exactly did you do (or not do) that was effective (or ineffective)? First I downgraded firmware-iwlwifi to version 20230210-5 -- to no avail. Did you try downgrading only firmware-iwlwifi to the last working version without downgrading pipewire? Was the kernel updated at the same time? If you can confirm that the problem comes from pipewire, it's worth filling a bug report upstream at: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues Best regards, Dylan
Bug#1058072: linux-image-6.5.0-0.deb12.1-amd64: Backport 6.5 kernel for bookworm is very good
Package: src:linux Version: 6.5.3-1~bpo12+1 Severity: wishlist Tags: upstream Dear Maintainer, $ uptime 19:56:14 up 27 days, 8:01, 3 users, load average: 0.69, 0.49, 0.45 $ apt policy linux-image-6.5.0-0.deb12.1-amd64 linux-image-6.5.0-0.deb12.1-amd64: Installed: 6.5.3-1~bpo12+1 Candidate: 6.5.3-1~bpo12+1 Version table: *** 6.5.3-1~bpo12+1 100 100 /var/lib/dpkg/status I wish you the the best. I wish you all the best. Thanks, bw -- Package-specific info: ** Version: Linux version 6.5.0-0.deb12.1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1~bpo12+1 (2023-10-08) ** Command line: BOOT_IMAGE=/vmlinuz root=UUID=2c03d937-09c2-4f1f-9d40-4901f2cdd3f0 ro quiet splash loglevel=3 ** Tainted: W (512) * kernel issued warning ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: HP product_name: HP Laptop 15-ef2xxx product_version: chassis_vendor: HP chassis_version: Chassis Version bios_vendor: AMI bios_version: F.30 board_vendor: HP board_name: 887A board_version: 59.22 ** Loaded modules: sr_mod cdrom ccm xpad ff_memless rfcomm cmac algif_hash algif_skcipher af_alg ipheth qrtr bnep intel_rapl_msr sunrpc intel_rapl_common binfmt_misc btusb btrtl btbcm nls_ascii edac_mce_amd snd_ctl_led btintel nls_cp437 snd_hda_codec_realtek kvm_amd btmtk snd_hda_codec_generic vfat bluetooth ledtrig_audio kvm snd_hda_codec_hdmi rtw88_8822ce fat snd_hda_intel rtw88_8822c irqbypass sha3_generic snd_soc_dmic snd_acp3x_pdm_dma snd_acp3x_rn uvcvideo snd_intel_dspcfg rtw88_pci jitterentropy_rng ghash_clmulni_intel snd_soc_core videobuf2_vmalloc snd_intel_sdw_acpi rtw88_core snd_hda_codec sha512_ssse3 snd_compress uvc sha512_generic snd_hda_core videobuf2_memops snd_pci_acp6x ctr snd_hwdep mac80211 videobuf2_v4l2 snd_pci_acp5x aesni_intel drbg hp_wmi snd_pcm videodev libarc4 snd_rn_pci_acp3x crypto_simd ansi_cprng sparse_keymap snd_timer snd_acp_config videobuf2_common cryptd ecdh_generic cfg80211 joydev sp5100_tco platform_profile snd snd_soc_acpi apple_mfi_fastcharge mc rapl ecc wmi_bmof pcspkr k10temp watchdog rfkill soundcore ccp snd_pci_acp3x sg ac amd_pmc acpi_tad hid_multitouch serio_raw evdev msr parport_pc ppdev lp parport fuse loop efi_pstore dm_mod configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic xor raid6_pq libcrc32c crc32c_generic sd_mod ums_realtek uas usb_storage amdgpu scsi_mod scsi_common amdxcp drm_buddy gpu_sched i2c_algo_bit nvme drm_suballoc_helper nvme_core drm_display_helper t10_pi cec crc64_rocksoft rc_core crc64 xhci_pci drm_ttm_helper crc_t10dif xhci_hcd ttm hid_generic crct10dif_generic usbcore drm_kms_helper crct10dif_pclmul crc32_pclmul i2c_hid_acpi video i2c_hid drm crc32c_intel i2c_piix4 usb_common crct10dif_common battery button wmi hid ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex [1022:1630] Subsystem: Hewlett-Packard Company Renoir/Cezanne Root Complex [103c:887a] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1634] (prog-if 00 [Normal decode]) Subsystem: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1453] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 51) Subsystem: Advanced Micro
Bug#1057767: Acknowledgement (pipewire: Last upgrade completely broke bluetooth connection: : org.bluez.Error.Failed br-connection-unknown)
Resumed from hibernate today and again got the error Failed to connect: org.bluez.Error.Failed br-connection-unknown despite downgrading those 4 pipewire packages. After reboot and _before_ logging on to KDE, I switched to a console and connected the RemoteMic+. That worked. After login the RemoteMic+ still was connected and found by PulseAudio with both A2DP and HSP/HFP and works. May there be some miscommunication between bluez and PulseAudio? (I fail to understand why _any_ PipeWire stuff is pulled in at all when I use PulseAudio _only_ -- PW fails miserably to work with RemoteMic+, even in version 1.0.0). On 08/12/2023 10:48, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1057767: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057767. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to deb...@ginguppin.de (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Utopia Maintenance Team If you wish to submit further information on this problem, please send it to 1057...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
Bug#1057385: lighttpd FTCBFS: host CFLAGS leak into build compiler invocation
On Mon, Dec 04, 2023 at 11:49:30AM +0100, Emanuele Rocca wrote: > With the attached patch lighttpd cleanly cross-builds from source. Thanks, Emanuele. A slightly different patch: https://salsa.debian.org/debian/lighttpd/-/commit/a7d695d59c9a8bffe154aae29e335102beaaf3f2 was committed a few weeks ago to salsa.debian.org, which I based off comments in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021292? Is your suggested approach (above) preferred to this patch (below)? @@ -50,9 +50,9 @@ override_dh_auto_configure: --with-xxhash \ --with-zstd \ $(if $(filter pkg.lighttpd.libunwind,$(DEB_BUILD_PROFILES)),--with-libunwind) \ - CFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get CFLAGS)" \ - LDFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get LDFLAGS)" \ - CPPFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get CPPFLAGS)" \ + CFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get CFLAGS)" \ + LDFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get LDFLAGS)" \ + CPPFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get CPPFLAGS)" \ override_dh_install: cp NEWS debian/tmp/changelog
Bug#1056621: reportbug: http://www.crbug.com
Package: reportbug Version: 12.0.0 Severity: serious Justification: Please do not redirect bugs to third party sites Dear Maintainer, pkg chromium is redirecting bugs through reportbug to http://www.crbug.com $ apt policy chromium chromium: Installed: 119.0.6045.159-1~deb12u1 I do not appreciate this. thanks, bw -- Package-specific info: ** Environment settings: INTERFACE="text" ** /home/user/.reportbugrc: reportbug_version "7.1.7" mode standard ui text email "bwtn...@yahoo.com" no-cc smtphost reportbug.debian.org -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt2.6.1 ii python33.11.2-1+b1 ii python3-reportbug 12.0.0 ii sensible-utils 0.0.17+nmu1 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf1.5.82 pn debsums pn dlocate pn emacs-bin-common ii exim4-daemon-light [mail-transport-agent] 4.96-15+deb12u2 ii file 1:5.44-3 ii gnupg 2.2.40-1.1 pn python3-urwid pn reportbug-gtk ii xdg-utils 1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt2.6.1 ii file 1:5.44-3 ii python33.11.2-1+b1 ii python3-apt 2.6.0 ii python3-debian 0.1.49 ii python3-debianbts 4.0.1 ii python3-requests 2.28.1+dfsg-1 ii sensible-utils 0.0.17+nmu1 python3-reportbug suggests no packages. -- no debconf information
Bug#1056620: chromium: EVIL
Package: chromium Version: 119.0.6045.159-1~deb12u1 Severity: wishlist Dear Maintainer, This app is evil. Eevry 'upgrade' is worse, especially for webmail access. Users might consider tossing this browser, as a longtime debian user I am concerneced I might quickly toss gmail and chromium in the garbage. I won't try to explain how they are mining personal ino, it's so daMN OBVIOUS. http://www.crbug.com -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common119.0.6045.159-1~deb12u1 ii libasound2 1.2.8-1+b1 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-02.46.0-5 ii libatomic1 12.2.0-14 ii libatspi2.0-0 2.46.0-5 ii libc6 2.36-9+deb12u3 ii libcairo2 1.16.0-7 ii libcups2 2.4.2-3+deb12u4 ii libdbus-1-31.14.10-1~deb12u1 ii libdouble-conversion3 3.2.1-1 ii libdrm22.4.114-1+b1 ii libevent-2.1-7 2.1.12-stable-8 ii libexpat1 2.5.0-1 ii libflac12 1.4.2+ds-2 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgbm122.3.6-1+deb12u1 ii libgcc-s1 12.2.0-14 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libjpeg62-turbo1:2.1.5-2 ii libjsoncpp25 1.9.5-4 ii liblcms2-2 2.14-2 ii libminizip11.1-8+b1 ii libnspr4 2:4.35-1 ii libnss32:3.87.1-1 ii libopenh264-7 2.3.1+dfsg-3 ii libopenjp2-7 2.5.0-2 ii libopus0 1.3.1-3 ii libpango-1.0-0 1.50.12+ds-1 ii libpng16-161.6.39-2 ii libpulse0 16.1+dfsg1-2+b1 ii libsnappy1v5 1.1.9-3 ii libstdc++6 12.2.0-14 ii libwebp7 1.2.4-0.2+deb12u1 ii libwebpdemux2 1.2.4-0.2+deb12u1 ii libwebpmux31.2.4-0.2+deb12u1 ii libwoff1 1.0.2-2 ii libx11-6 2:1.8.4-2+deb12u2 ii libxcb11.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage11:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxkbcommon0 1.5.0-1 ii libxml22.9.14+dfsg-1.3~deb12u1 ii libxnvctrl0525.85.05-3~deb12u1 ii libxrandr2 2:1.5.2-2+b1 ii libxslt1.1 1.1.35-1 ii xdg-desktop-portal-kde [xdg-desktop-portal-backen 5.27.5-2 d] ii zlib1g 1:1.2.13.dfsg-1 Versions of packages chromium recommends: pn chromium-sandbox Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.36-9+deb12u3 ii libjsoncpp25 1.9.5-4 ii libstdc++612.2.0-14 ii libx11-6 2:1.8.4-2+deb12u2 ii libxnvctrl0 525.85.05-3~deb12u1 ii x11-utils 7.7+5 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages chromium-common recommends: pn chromium-sandbox ii fonts-liberation1
Bug#1056162: linux-cpupower: could use a little amd support
Package: linux-cpupower Version: 6.5.3-1~bpo12+1 Severity: wishlist Tags: upstream Dear Maintainer, The linux-cpupower pkg doesn't seem able to support CPU frequency control mechanism on modern AMD APU and CPU series in Linux kernel. current kernel efforts for amd cpu: https://www.kernel.org/doc/html/latest/admin-guide/pm/amd-pstate.html -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-cpupower depends on: ii libc6 2.36-9+deb12u3 ii libcap2 1:2.66-4 ii libcpupower1 6.5.3-1~bpo12+1 ii libpci3 1:3.9.0-4 linux-cpupower recommends no packages. linux-cpupower suggests no packages. -- no debconf information #!/bin/sh # /usr/local/sbin/amdepp.sh # uncomment one in each group to enable ACTIVE_GOV=powersave #ACTIVE_GOV=performance #ACTIVE_PREF=performance ACTIVE_PREF=balance_performance #ACTIVE_PREF=balance_power #ACTIVE_PREF=power #PASSIVE_GOV=powersave PASSIVE_GOV=ondemand #PASSIVE_GOV=conservative #PASSIVE_GOV=performance TEEPATH=/sys/devices/system/cpu/cpu*/cpufreq READPATH=/sys/devices/system/cpu/cpufreq/policy0 if [ ! -d /sys/devices/system/cpu/amd_pstate ] ; then echo not amd_pstate compatible cpu exit 1 fi read DRIVER_NAME <$READPATH/scaling_driver || exit 2 case "$1" in set) case $DRIVER_NAME in amd-pstate-epp) echo $ACTIVE_GOV | /usr/bin/tee $TEEPATH/scaling_governor echo $ACTIVE_PREF | /usr/bin/tee $TEEPATH/energy_performance_preference ;; amd-pstate|acpi-cpufreq) [ -d /sys/module/cpufreq_$PASSIVE_GOV ] || modprobe cpufreq_$PASSIVE_GOV echo $PASSIVE_GOV | /usr/bin/tee $TEEPATH/scaling_governor ;; *) echo no compatible scaling driver esac ;; *|get) # default info only echo driver: $DRIVER_NAME read DRIVER_MODE
Bug#1055651: mirror submission for mirror.dhakacom.com
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.dhakacom.com Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: http://mirror.dhakacom.com/debian Country: BD Bangladesh Location: http://mirror.dhakacom.com/debian Trace Url: http://mirror.dhakacom.com/debian/project/trace/ Trace Url: http://mirror.dhakacom.com/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.dhakacom.com/debian/project/trace/mirror.dhakacom.com
Bug#1053511: Problem found
Am 08.11.23 um 18:14 schrieb Thorsten Alteholz: But this looks rather like a local problem. If your /var/*/cups is not at the default location, you should adapt your apparmor files on your own, shouldn't you? Thorsten Oh yes - that's true. Embarrassing ... There was already an alias defined for apparmor, but the content of the partition has moved. It has been forgotten that this has to be altered and the problem has been searched at a wrong place. The directory /var is only a symbolic link, because the SSD should not get so many write operations for it. Then this bug will be closed. Thanks! karsten
Bug#1053511: Problem found
|| Because there is no logging for cups I have done some basic checks: # systemctl status cups ●cups.service - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running)since Wed 2023-11-08 14:23:09 CET; 19s ago TriggeredBy: ● cups.path ●cups.socket Docs: man:cupsd(8) Main PID: 9417 (cupsd) Status: "Scheduler is running..." Tasks: 1 (limit: 9336) Memory: 1.3M CPU: 13ms CGroup: /system.slice/cups.service └─9417 /usr/sbin/cupsd -l Nov 08 14:23:09 PC cupsd[9417]: Unable to open log file "/var/log/cups/error_log" - No such file or directory Nov 08 14:23:09 PC cupsd[9417]: Unable to create directory "/var/log/cups" - Permission denied Nov 08 14:23:09 PC cupsd[9417]: Unable to open log file "/var/log/cups/error_log" - No such file or directory Nov 08 14:23:09 PC cupsd[9417]: Unable to create directory "/var/log/cups" - Permission denied Nov 08 14:23:09 PC cupsd[9417]: Unable to open log file "/var/log/cups/error_log" - No such file or directory Nov 08 14:23:09 PC cupsd[9417]: Unable to create directory "/var/log/cups" - Permission denied Nov 08 14:23:09 PC cupsd[9417]: Unable to open log file "/var/log/cups/error_log" - No such file or directory Nov 08 14:23:09 PC cupsd[9417]: Unable to create directory "/var/log/cups" - Permission denied Nov 08 14:23:09 PC cupsd[9417]: Unable to open log file "/var/log/cups/error_log" - No such file or directory Nov 08 14:23:09 PC systemd[1]: Started CUPS Scheduler. drwxr-xr-x 2 root root 4,0K 5. Okt 16:35 cups It did not help to change the group of /var/log/cups to lpadmin! So I tried to delete the directory and let it be created new with dpkg-reconfigure cups-daemon Job failed. See "journalctl -xe" for details. # journalctl -xe Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="chown" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/spool/cups/" pid=95> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="mkdir" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/log/cups/" pid=9568> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=9568 comm="cupsd" capability=12 > Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="chown" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/cache/cups/" pid=95> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="mkdir" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/log/cups/" pid=9568> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="chown" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/cache/cups/rss/" pi> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="mkdir" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/log/cups/" pid=9568> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="chown" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/spool/cups/tmp/" pi> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="mkdir" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/log/cups/" pid=9568> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/spool/cups/" pid=956> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="mkdir" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/log/cups/" pid=9568> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/spool/cups/tmp/" pid> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="mkdir" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/log/cups/" pid=9568> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/cache/cups/" pid=956> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="mkdir" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/log/cups/" pid=9568> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="mknod" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/cache/cups/org.cups> Nov 08 14:24:04 PC audit[9568]: AVC apparmor="DENIED" operation="mkdir" profile="/usr/sbin/cupsd" name="/srv/ssd1/var/log/cups/" pid=9568> Nov 08 14:24:04 PC cupsd[9568]: Unable to open log file "/var/log/cups/error_log" - No such file or directory Nov 08 14:24:04 PC cupsd[9568]: Unable to create directory "/var/log/cups" - Permission denied Nov 08 14:24:04 PC cupsd[9568]: Unable to open log file "/var/log/cups/error_log" - No such file or directory Nov 08 14:24:04 PC cupsd[9568]: Unable to create directory "/var/log/cups" - Permission denied Nov 08 14:24:04 PC kernel: audit: type=1400 audit(1699449844.150:6618): apparmor="DENIED" operation="chown" profile="/usr/sbin/cupsd" nam> Nov 08 14:24:04 PC kernel: audit: type=1400 audit(1699449844.150:6619): apparmor="DENIED" operation="mkdir" profile="/usr/sbin/cupsd" nam> Nov 08 14:24:04 PC kernel: audit: type=1400 audit(1699449844.150:6620):
Bug#1053511: Opened an issue at cups
Please refer to https://github.com/apple/cups/issues/6155 A solution is needed now. A desktop PC without printer is unusable. Is it possible to get somewhere the packages before the upgrade? How it is possible to install packages of cups from Debian 10?
Bug#1055131: RFS: lighttpd/1.4.73-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.73-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.73-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Important changes in lighttpd 1.4.73: * HTTP/2 detect and log rapid reset attack While lighttpd is not affected by HTTP/2 rapid reset attacks any more than by other DoS attacks, changes have been made to lighttpd to detect and log when a rapid reset attack occurs, and to close the HTTP/2 connection. Log watchers might subsequently use the trace to block IPs. The goal is to make lightpd 1.4.73 available in unstable, testing, and then backports (or sloppy-backports) to maintained Debian versions. Please advise next steps. Thank you. Glenn P.S. The version of lighttpd in Debian Experimental is 1.4.71-1+exp1 and can be retired.
Bug#1012016: fix broken poi-ooxml-schemas-4.0.1.jar
Dear maintainers, the file /usr/share/java/poi-ooxml-schemas-4.0.1.jar is broken for the bookworm release. With this broken file the apache poi library is currently not usable. Is there a chance that this file is getting fixed soon? How can I help, as it is pretty important for my use? Thank you and best regards Florian Paul
Bug#1012016: possible solution for libapache-poi-java needs updates for newer xmlbeans
Hi all, I am a Java developer and I faced the same problem after upgrading debian from bullseye to bookworm. I compared the file /usr/share/java/poi-ooxml-schemas-4.0.1.jar between bullseye, bookworm and those from the maven central repo. The version of bookworm contains a very reduced amount of files. So I tested the reproducer problem.java from Erik with the corresponding jar from bullseye and the test was OK. I assume, that there has been a problem in creating the poi-ooxml-schemas-4.0.1.jar for bookworm. Could a maintainer please fix this file? Thank you and best regards Florian Paul
Bug#1054155: Missing new needed dependency on libgtk-4-media-gstreamer
Package: gnome-clocks Version: 45.0-1 Since the merge of https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests/253, GNOME Clocks uses GTK MediaStream, which is provided by libgtk-4-media-gstreamer, but that package has not been added to the dependencies of gnome-clocks in Debian. This results in no sound for events (alarms, countdown timers). Manually installing the package fixes the issue.
Bug#1053511: Printing with cups not possible any more after system upgrade
Package: cups-daemon Version: 2.3.3op2-3+deb11u5 Severity: important Dear Maintainer, can you please tell, what is going on that printing becomes impossible in all versions of Debian? Yesterday I give up working with Debian 12 and one of the reasons is this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039983 that color printing is not possible any more. So I reactivated an backup of Debian 11 and for security reasons it has been upgraded. CUPS is part of this upgrade and after the upgrade no printing is possible any more (see log of upgrade below). In the printer configuration http://localhost:631/printers/Kyocera_Kyocera_ECOSYS_P5021cdw_ the printer cannot be deleted or jobs cancelled, all of them are resulting in "Gesamte Anfrage zu groß" translated "request to big"! When you print, the print job keeps "on hold" and cannot be started or released. Then again you enter "request to big". Some screenshots are attached. Now i am really desparated, because I invested much work to reactivate the backup that is running really good excluding CUPS and printing. I already need to boot Debian 8 when I want to send a fax, because CUPS has been altered and so Roger Router Fax is not working any more afterwards. So different installations are needed and have to be booted now to print in Debian Gnu/Linux ? Cheers karsten -- System Information: Debian Release: 11.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-26-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-daemon depends on: ii adduser 3.118+deb11u1 ii bc 1.07.1-2+b2 ii init-system-helpers 1.60 ii libavahi-client3 0.8-5+deb11u2 ii libavahi-common3 0.8-5+deb11u2 ii libc6 2.31-13+deb11u6 ii libcups2 2.3.3op2-3+deb11u5 ii libdbus-1-3 1.12.28-0+deb11u1 ii libgssapi-krb5-2 1.18.3-6+deb11u4 ii libpam0g 1.4.0-9+deb11u1 ii libpaper1 1.1.28+b1 ii libsystemd0 247.3-7+deb11u4 ii lsb-base 11.1.0 ii procps 2:3.3.17-5 ii ssl-cert 1.1.0+nmu1 Upgrade of this packages: Start-Date: 2023-10-03 16:32:30 Install: linux-image-5.10.0-26-amd64:amd64 (5.10.197-1, automatic), linux-headers-5.10.0-26-common:amd64 (5.10.197-1, automatic), linux-headers-5.10.0-26-amd64:amd64 (5.10.197-1, automatic) Upgrade: dpkg:amd64 (1.20.12, 1.20.13), openjdk-11-jre:amd64 (11.0.18+10-1~deb11u1, 11.0.20+8-1~deb11u1), libcups2:amd64 (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u5), libcups2:i386 (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u5), linux-kbuild-5.10:amd64 (5.10.179-1, 5.10.197-1), libcurl4:amd64 (7.74.0-1.3+deb11u7, 7.74.0-1.3+deb11u9), libcurl4:i386 (7.74.0-1.3+deb11u7, 7.74.0-1.3+deb11u9), python2.7-minimal:amd64 (2.7.18-8, 2.7.18-8+deb11u1), libwebpmux3:amd64 (0.6.1-2.1+deb11u1, 0.6.1-2.1+deb11u2), openjdk-11-jre-headless:amd64 (11.0.18+10-1~deb11u1, 11.0.20+8-1~deb11u1), krb5-locales:amd64 (1.18.3-6+deb11u3, 1.18.3-6+deb11u4), bind9-host:amd64 (1:9.16.42-1~deb11u1, 1:9.16.44-1~deb11u1), libgssapi-krb5-2:amd64 (1.18.3-6+deb11u3, 1.18.3-6+deb11u4), libgssapi-krb5-2:i386 (1.18.3-6+deb11u3, 1.18.3-6+deb11u4), libcurl3-gnutls:amd64 (7.74.0-1.3+deb11u7, 7.74.0-1.3+deb11u9), libcurl3-gnutls:i386 (7.74.0-1.3+deb11u7, 7.74.0-1.3+deb11u9), openssh-client:amd64 (1:8.4p1-5+deb11u1, 1:8.4p1-5+deb11u2), gstreamer1.0-plugins-ugly:amd64 (1:1.18.4-dmo3, 1:1.18.4-dmo3+deb11u1), cups-bsd:amd64 (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u5), libtinfo5:amd64 (6.2+20201114-2+deb11u1, 6.2+20201114-2+deb11u2), libtinfo6:amd64 (6.2+20201114-2+deb11u1, 6.2+20201114-2+deb11u2), libtinfo6:i386 (6.2+20201114-2+deb11u1, 6.2+20201114-2+deb11u2), nvidia-alternative:amd64 (470.182.03-1, 470.199.02-1), cups-common:amd64 (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u5), libmagic-mgc:amd64 (1:5.39-3, 1:5.39-3+deb11u1), yt-dlp:amd64 (1:2023.06.22-dmo1, 1:2023.09.24-dmo1), gstreamer1.0-gl:amd64 (1.18.4-dmo1, 1.18.4-dmo1+deb11u1), linux-image-5.10.0-23-amd64:amd64 (5.10.179-1, 5.10.179-3), rar:amd64 (2:5.5.0-1, 2:6.23-1~deb11u1), linux-compiler-gcc-10-x86:amd64 (5.10.179-1, 5.10.197-1), libblas3:amd64 (3.9.0-3, 3.9.0-3+deb11u1), cups-client:amd64 (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u5), cups-ppdc:amd64 (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u5), opera-stable:amd64 (100.0.4815.20, 103.0.4928.16), libmagic1:amd64 (1:5.39-3, 1:5.39-3+deb11u1), cups-daemon:amd64 (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u5), liblua5.3-0:amd64 (5.3.3-1.1
Bug#1050684:
According to https://packages.debian.org/trixie/clang it was bumped to clang-16 and this bug is fixed and can be closed. Thank you!
Bug#1052530: installation-reports: HP 15-ef2033dx likes bookworm w/plasma
Package: installation-reports Severity: normal Boot method: usb Image version: Official Debian GNU/Linux Live 12.1.0 kde 2023-07-22T09:48:34Z] Date: 27 Sep 21 12:22 Machine: HP 15-ef2033dx Partitions: Disk /dev/nvme0n1: 500118192 sectors, 238.5 GiB Model: SK hynix BC711 HFM256GD3JX013N Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): BEFEDC3E-B565-4089-86B1-A8D2EFC41469 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 500118158 Partitions will be aligned on 2048-sector boundaries Total free space is 58722925 sectors (28.0 GiB) Number Start (sector)End (sector) Size Code Name 12048 1050623 512.0 MiB EF00 2 105062468159487 32.0 GiB8300 bookworm 368159488 435161087 175.0 GiB 8300 storage 4 493881344 500117503 3.0 GiB 8200 Linux swap Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [ ] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [ ] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [ ] Install boot loader:[O] Overall install:[O] Comments/Problems: It was very pleasant. Thank you. Too much cleanup of pkgs installed for no reason, no big deal, used to it... I think installer logs are attached if not I'll follow upand attach them. The attachment file /var/log/installer/installer.tar size is bigger than the maximum of 10485760 bytes: reduce its size else the report cannot be sent Much obliged, this very brand new computer is very happy with bookworm. I really appreciate the free os. L8r, bw
Bug#885426: typo?
On Wed, Sep 06, 2023 at 11:29:30AM -0600, Jeffrey Cliff wrote: >is this a typo? Shouldn't this be electrum-cash ? Not a typo. The Electrum fork for BCH is called Electron Cash. -- Daniel González Gasull
Bug#1051829: guix requires netbase package
Package: guix Version: 1.4.0-5 Severity: normal Dear Maintainer, Installing guix does not install the netbase package, thus guix fails to connect to the internet. For example, "guix install hello" fails with: accepted connection from pid 4456, user root guix install: warning: Consider running 'guix pull' followed by 'guix package -u' to get up-to-date packages and security updates. The following package will be installed: hello 2.12.1 ... ... ... |builder for `/gnu/store/5r4kjzprkhajila6xbykbc40ip1r68jy-gzip-1.10.tar.xz.drv' failed to produce output path `/gnu/store/5dh059d365953arhixlx4xqkngwv2jmr-gzip-1.10.tar.xz' build of /gnu/store/5r4kjzprkhajila6xbykbc40ip1r68jy-gzip-1.10.tar.xz.drv failed View build log at '/var/log/guix/drvs/5r/4kjzprkhajila6xbykbc40ip1r68jy-gzip-1.10.tar.xz.drv.gz'. building /gnu/store/s6vd2hy2aj1pd5kqz0sa9y5x2hjkf030-Python-3.5.9.tar.xz.drv... cannot build derivation `/gnu/store/2pm02klijbsmqvdv852vavj8irzy0kzx-gzip-1.10.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/9161x6x6xrpwg6l05ahsx9x4ihs1xkzi-gzip-1.10.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/bl9sa8f5b4l1icaz13dpvs3f6rzf40rp-gzip-1.10.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/8wrlkm74fg8j01ixjarbgsdr4l7zx38s-glibc-utf8-locales-2.33.drv': 1 dependencies couldn't be built guix install: error: build of `/gnu/store/8wrlkm74fg8j01ixjarbgsdr4l7zx38s-glibc-utf8-locales-2.33.drv' failed With the log being: Starting download of /gnu/store/5dh059d365953arhixlx4xqkngwv2jmr-gzip-1.10.tar.xz >From ... ... ... In procedure getaddrinfo: Servname not supported for ai_socktype It would be good to fix this by installing the netbase package along with guix. Thanks -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: riscv64
Bug#1040525: Lighttpd disregards ssl.dh-file setting
Repeating: lighttpd TLS configuration recommendations supercede the issue reported here. (https://wiki.lighttpd.net/Docs_SSL) > I now removed that cipher list (falling back to the default), and this > disabled the 2 remaining ciphers (DHE-RSA-AES256-GCM-SHA384 and > DHE-RSA-AES128-GCM-SHA256) that used Diffie Hellman :-) As you noticed, using the lighttpd TLS configuration recommendations does not include the ciphers using the finite field Diffie-Hellman parameters which caused Nexpose to generate warnings. --- Regarding the DH parameters used by default by lighttpd when finite field Diffie-Hellman parameters are used: > > Please clarify why you think this is insecure. > I trust Nexpose on this one. The theory goes that any "standard" > parameter is insecure, as a would be attacker would only need to "crack" > it once, and then be able to use it against a huge number of sites. I trust the published RFCs by experts more than I trust Nexpose. > I'm not really sure that it is a good idea to rely on *any* standard > Diffie-Hellman parameters :-( I'm not familiar with your expertise in this security area. What are your credentials that would give weight to your opinion? On the contrary: While there is the theoretical possibility of the well-known standard parameters being cracked, there are different potential pitfalls for generating custom parameters and then not cryptographically analyzing those custom parameters for weaknesses. It does not appear that you are performing that analysis on your custom parameters, and so my recommendation is to use the standard parameters which have been analyzed by experts for weaknesses. That does not guarantee safety, but does add more confidence to safety of the standard parameters when compared to custom parameters lacking expert analysis for weaknesses. As you have outsourced your security analysis to Nexpose, I recommend you follow up with Nexpose for more detailed guidance. I suggest that removing those ciphers is best practices at this point, unless you must support older clients which do not support more modern ciphers. If you still trust Nexpose more than other experts, I urge you to reconsider. Do you think Nexpose knows better than the OpenSSL developers? `man SSL_CTX_set_dh_auto` ``` Typically applications should use well know DH parameters that have built-in support in OpenSSL. The macros SSL_CTX_set_dh_auto() and SSL_set_dh_auto() configure OpenSSL to use the default built-in DH parameters for the SSL_CTX and SSL objects respectively. Passing a value of 1 in the onoff parameter switches the feature on, and passing a value of 0 switches it off. The default setting is off. If "auto" DH parameters are switched on then the parameters will be selected to be consistent with the size of the key associated with the server's certificate. If there is no certificate (e.g. for PSK ciphersuites), then it it will be consistent with the size of the negotiated symmetric cipher key. Applications may supply their own DH parameters instead of using the built-in values. This approach is discouraged and applications should in preference use the built-in parameter support described above. ``` Note: other TLS libraries such as GnuTLS use the expert-recommended standard parameters and no longer provide an option to set custom DH parameters. ``` Prior to GnuTLS 3.6.0 for the ephemeral or anonymous Diffie-Hellman (DH) TLS ciphersuites the application was required to generate or provide DH parameters. That is no longer necessary as GnuTLS utilizes DH parameters and negotiation from [RFC7919]. ``` --- Issue resolution: Since lighttpd 1.4.60, lighttpd switches on SSL_CTX_set_dh_auto() in lighttpd mod_openssl, and this causes openssl to ignore "DHParameters" even when explicitly set. This will be fixed in lighttpd 1.4.72. In lighttpd 1.4.72, if you explicitly set "DHParameters", lighttpd will switch off SSL_CTX_set_dh_auto() so that openssl will honor the user-supplied parameters. Even so, the expert recommendation is to allow openssl 3.0.0 and later to select the DH parameters (which lighttpd does by enabling SSL_CTX_set_dh_auto()).
Bug#1034586: always reports inactive/expired certificate on armhf
Marco, please review my previous messages and try to help provide additional information. Thank you. Glenn
Bug#1041044: Opened bug at KDE
Please refer to https://bugs.kde.org/show_bug.cgi?id=474325
Bug#1051531: PTP file copy with kio_kamera.so looses contact to a camera
Package: kamera Version: 4:22.12.3-1 Severity: important Please refer additional to https://bugs.kde.org/show_bug.cgi?id=474324 Trying to copy pictures and video via PTP from a camera does not work any more. Booting of an older Debian 8 is needed and there it works without problem. Some pictures are maybe copied and then the copy goes into hold. Afterwards a try to reconnect to the camera shows up error 150 (wrong parameter). After camera is switched off and reconnected the same result occurs. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-11-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kamera depends on: ii kio 5.103.0-1 ii libc6 2.36-9+deb12u1 ii libgphoto2-6 2.5.30-1 ii libgphoto2-port12 2.5.30-1 ii libkf5configcore5 5.103.0-2 ii libkf5configwidgets5 5.103.0-1 ii libkf5coreaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5kiocore5 5.103.0-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5xmlgui5 5.103.0-1 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5widgets5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 ii systemsettings 4:5.27.5-2
Bug#1050684: /usr/lib/llvm-14/bin/clang: Default clang++ -std=c++20 does not work with default libstdc++ on trixie
Package: clang-14
Version: 1:14.0.6-13
Severity: important
File: /usr/lib/llvm-14/bin/clang
Dear Maintainer,
The default clang++ version on trixie and sid is 14. However, this
version of clang++ does not go well with C++20 and the default
libstdc++ (version 13).
It would be good to bump the default clang version to 15, or 16 (both
of which are already available in trixie), or even clang-17, once and
if it is released.
Steps to reproduce bug on a fresh install of Debian Trixie:
cat t.cpp && clang++ --version && clang++ -std=c++20 -o t -Weverything t.cpp
#include
int main() { return 0; }
Debian clang version 14.0.6
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
In file included from t.cpp:1:
/usr/bin/../lib/gcc/aarch64-linux-gnu/13/../../../../include/c++/13/chrono:2320:48:
error: call to consteval function
'std::chrono::hh_mm_ss::_S_fractional_width' is not a constant
expression
static constexpr unsigned fractional_width = {_S_fractional_width()};
^
/usr/bin/../lib/gcc/aarch64-linux-gnu/13/../../../../include/c++/13/chrono:2320:48:
note: undefined function '_S_fractional_width' cannot be used in a
constant expression
/usr/bin/../lib/gcc/aarch64-linux-gnu/13/../../../../include/c++/13/chrono:2275:2:
note: declared here
_S_fractional_width()
^
1 error generated.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: arm64 (aarch64)
Versions of packages clang-14 depends on:
ii binutils2.41-4
ii libc6 2.37-7
ii libc6-dev 2.37-7
ii libclang-common-14-dev 1:14.0.6-13
ii libclang-cpp14 1:14.0.6-13
ii libclang1-141:14.0.6-13
ii libgcc-13-dev 13.2.0-2
ii libgcc-s1 13.2.0-2
ii libllvm14 1:14.0.6-13
ii libobjc-13-dev 13.2.0-2
ii libstdc++-13-dev13.2.0-2
ii libstdc++6 13.2.0-2
ii llvm-14-linker-tools1:14.0.6-13
Bug#1031046: Unacceptable - Asterisk is too popular to exclude
Hello Moritz, I've read your bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031046 I believe it to be unacceptable to exclude Asterisk from Bookworm. Asterisk is used by a LOT of users worldwide and, as you've noted, is frequently the subject of security concerns. The VoIP Team is currently working on a plan to resolve your concerns. If we don't provide Debian users with secure packages, they will use packages from less reputable sources and chaos will ensue. I believe the VoIP team can deliver on the commitments you are asking for, we are working on raising a bigger team of volunteers so we can more effectively address CVEs. Stay tuned. David
Bug#1050625: asterisk: Downgrade to lua5.1
On 2023-08-27 12:14, Jonas Smedegaard wrote: Hi David, Quoting debian@spam.lublink.net (2023-08-27 16:04:20) I wrote and applied the required patch ( see attached ). I built the asterisk package 1:20.4.0~dfsg+~cs6.13.40431414-2 and signed it successfully. I installed the new package on my local machine and tested a lua dialplan. I connected using chan_sip+baresip, and setup a new lua context in extensions.lua. I called this context and listened to some menus. ( I had audio ). Thanks a lot for the thorough testing! I am now building the package and (unless something surprising happens) will release it within an hour. Since the patch only affects lua integration, I saw no reason to do further testing. Agreed. Since I am a new contributor, I'll need help actually pushing this patch into Salsa and Debian master. For a change this tiny there is really no need to make a formal patch - simply posting here on the list that you've succesfully tested a build with build-dependency changed from liblua5.2-dev to liblua5.1-dev is fine. @jonas can you grant me salsa access and/or review my patch and integrate it into salsa? Please don't use the merge-request feature: I am not comfortable using that, but more importantly I find it better to keep conversation about the packaging in bugreports, not some parts in gitlab. (In addition to concerete discussions about bugs I am happy to have casual conversations as well, at our irc channel that we don't need to keep track of - I just currently have trouble reaching it from matrix). In future, please make simple git commits pushed directly to the branch debian/latest where first line of your commit message is sensible to list in Debian changelog - and please *don't* edit debian/changelog. This approach makes it easier to revert or cherry-pick e.g. for a stable backport, and debian/changelog is easily populated using "gpb dch" just before building the package. In bug #1023306 I am looking at version bumping to 3.4.0. Should I also commit this directly to debian/latest or should I use a branch? Please request membership at https://salsa.debian.org/pkg-voip-team/asterisk/-/project_members to gain write access to the git repo. I've sent my request. I'm waiting for approval. (I have now disabled the MR feature for this package, which also killed the conversation you started there - I forgot to take note of your account so cannot invite you into the group myself). ...and while writing this the build finished and I have now pushed it to Debian :-) Nice! Also, I ran dput, but got no response from debian masters ( probably because I am not authorized to build the asterisk package ) . Correct: dput works but the resulting uploaded source package gets silently dropped because a) your OpenPGP signature is not in the list of trusted Debian Developers, and b) because it was uploaded by someone not trusted that someone could have forged a bogus contact address so it won't be contacted to avoid backscatter. thank you for the explanation. How can I learn more about the VoIP Team workflow so that I can contribute more effectively ? - Jonas - David
Bug#1050625: asterisk: Downgrade to lua5.1
Merge request is in Salsa : https://salsa.debian.org/pkg-voip-team/asterisk/-/merge_requests/4 On 2023-08-27 10:04, debian@spam.lublink.net wrote: I wrote and applied the required patch ( see attached ). I built the asterisk package 1:20.4.0~dfsg+~cs6.13.40431414-2 and signed it successfully. I installed the new package on my local machine and tested a lua dialplan. I connected using chan_sip+baresip, and setup a new lua context in extensions.lua. I called this context and listened to some menus. ( I had audio ). Since the patch only affects lua integration, I saw no reason to do further testing. Since I am a new contributor, I'll need help actually pushing this patch into Salsa and Debian master. @jonas can you grant me salsa access and/or review my patch and integrate it into salsa? Also, I ran dput, but got no response from debian masters ( probably because I am not authorized to build the asterisk package ) . Thank you, David
Bug#1050625: asterisk: Downgrade to lua5.1
I wrote and applied the required patch ( see attached ). I built the asterisk package 1:20.4.0~dfsg+~cs6.13.40431414-2 and signed it successfully. I installed the new package on my local machine and tested a lua dialplan. I connected using chan_sip+baresip, and setup a new lua context in extensions.lua. I called this context and listened to some menus. ( I had audio ). Since the patch only affects lua integration, I saw no reason to do further testing. Since I am a new contributor, I'll need help actually pushing this patch into Salsa and Debian master. @jonas can you grant me salsa access and/or review my patch and integrate it into salsa? Also, I ran dput, but got no response from debian masters ( probably because I am not authorized to build the asterisk package ) . Thank you, David-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - From 1bb7f853f963a05846f4994b0737657e2e9754d3 Mon Sep 17 00:00:00 2001 From: david Date: Sun, 27 Aug 2023 08:56:30 -0400 Subject: [PATCH] * downgrade liblua dependency to 5.1 closes bug #1050625 - --- debian/changelog | 10 ++ debian/control | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 3c752b06..d36f5e39 100644 - --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +asterisk (1:20.4.0~dfsg+~cs6.13.40431414-2) unstable; urgency=medium + + [ upstream ] + * no change + + [ David Lublink ] + * downgrade liblua dependency to 5.1 closes bug #1050625 + + -- David Lublink Sun, 27 Aug 2023 08:54:59 -0400 + asterisk (1:20.4.0~dfsg+~cs6.13.40431414-1) unstable; urgency=medium [ upstream ] diff --git a/debian/control b/debian/control index 1e56e578..ade1e090 100644 - --- a/debian/control +++ b/debian/control @@ -34,7 +34,7 @@ Build-Depends: libjack-dev, libjansson-dev, libldap-dev, - - liblua5.2-dev, + liblua5.1-dev, libncurses-dev, libneon27-dev, libnewt-dev, - -- 2.39.2 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmsrHNiyThbxy/27E6Uk97Y34rXwFAmTrU9cACgkQ6Uk97Y34 rXx+8g/9HD3KBpIvsLgUUUrQWX7beGdt6rIzP6+v2Tjpj6tGQBvnQ3PzR24CWTSp /68D1d0udxo+wNnglC5bNsl7GZ5qUILamefMcgq5kPHT5JT1okhRuoaRc0J7qDes ZUtEypdshfNrJ7jnyS/in+o3EPhw3OB9tzZaOJLvs8JhJM4+UavRmr3gR5eBwExV 16QWPlKje9wuuhhvkl8YJBw+IejtYCWOOilxaEJezpL/fuWAt+BPODf9v5hsicEJ ldQuAPd35uz238ZJhczmR2LoiY4R5PRXsjqQzNp4CZUrcVzOAXTq4FLyvL3BVgbk X2iObdEnEEC7WRW2yCsZSP8mjY1IBuoQFhby8Lvc3IVbAtvTAACyypreP+2UVvOr FE/lrgRj1tKOIM420jK1vfAnyRwcPiRQHfwoDOMob3o/bzrVJ2WoQc0SjIV/+yoU zGTUs+354tnC2oFPFlS975cZ+Qx2gN0IbrY57ukuJdkKjydXmz/OSTVwgqbcLnqC Lu6HsKb3v/V8epo7WDV2x5Kg19trvbLHDjzHA4oPwnvbJKlUmpO6E69reC103VGq mzn0jMgK5+ITfiMJlYUp0pyXK2IgFn6Ft3aQR5+uq+BbSgbdy7spRpQIrBc5Zf5T figB7HwRIx/ELALvKt8r3yAdGqs8X3gm2kKYekSI+pCbpnv5Wg0= =0WlF -END PGP SIGNATURE-
Bug#999458: zynaddsubfx: Feature Request: Integration of Zyn-fusion (new GUI)
By the way, some people tell that Zyn-fusion is not working well (see messages on http://lists.sourceforge.net/mailman/listinfo/zynaddsubfx-user). I didn't test it myself but upgrading to Zyn-fusion does not seem to be a priority. Another solution (if possible): compile two versions of zynaddsubfx, the "old" interface and the new one (zyn-fusion).
Bug#999458: zynaddsubfx: Feature Request: Integration of Zyn-fusion (new GUI)
Hi, I think the following link can help devs for upgrading zynaddsubfx to the Zyn-fusion interface: https://github.com/zynaddsubfx/zyn-fusion-build Summary of the Readme: Zyn-Fusion Build Scripts These are the build scripts used to generate the Zyn-Fusion packages. These build scripts (and only these build scripts) are licensed under the WTFPL Regards Jean-Philippe
Bug#1050194: cloud.debian.org: Custom Script extension is not working in latest Debian 12 Azure image
Package: cloud.debian.org Severity: important X-Debbugs-Cc: alex.agra...@audiocodes.com Hello, Latest version of Debian 12 image in Azure marketplace (0.20230802.1460) broke support for Custom Script extension. If one tries to deploy Custom Script extension - either via ARM template during initial VM creation or for existing VM via Azure portal - deployment gets stuck forever and never completes. The following log is produced in /var/log/waagent.log: 2023-08-21T16:55:09.998510Z WARNING ExtHandler ExtHandler No handler status found for Microsoft.Azure.Extensions.CustomScript. Not reporting anything for it. In previous Azure marketplace image versions (e.g. 0.20230723.1450) Custom Script extension works just fine. Detailed information about Custom Script extension is available here: https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-linux Both latest (0.20230802.1460) and previous (0.20230723.1450) images use the same Azure Linux Agent version - WALinuxAgent-2.7.3.0. The bug essentially blocks provisioning of new VMs in Azure based on latest Debian 12 image that deploys configuration via Custom Script extension. Thanks, Alex
Bug#1042399: I confirm there is a problem
Hi I am new to this Debian mailing lists and have started to learn what and how things are working here because I want to support Debian in some way in future. About this issue: The MariaDB Website say there is even a newer version "MariaDB 10.11.5 Stable (GA)" released. https://mariadb.com/kb/en/mariadb-10-11-5-changelog/ I am not sure this issue here is fixed with the newer version. What would be the right way to report this to the issue? Should I just post it to the mailing list or directly to some responsible person? Sorry for asking you best, Carsten. On Sat, 2023-08-19 at 03:59 +0300, Владимир wrote: > When is the fix planned to be rolled out. The bug is critical, on > some > systems the file growth reaches about 10GB per day, and at the moment > it > can only be cleaned by recreating the database and files. I tried > downloading and uploading the /usr/sbin/mariadbd binary, but it looks > like it's not just about it, since it doesn't even start, you > probably > need to re-upload all related binaries. This procedure does not > inspire > confidence. >
Bug#1023306: Version 3.4.0
It would seem there is now a release 3.4.0. https://github.com/baresip/baresip/tree/v3.4.0
Bug#1043367: thunderbird 115.1 is unresponsive
Package: thunderbird Version: 1:115.1.0-1 Severity: important Dear Maintainer, after upgrading thunderbird to 1:115.1.0-1, it has become unusable. starting works nicely and i get the password prompt, after which the main screen is shown. however, the window is totally unresponsive, and thunderbird works happily at 100% for hours. my system is not super-new, but not that old either: ``` $ lscpu Architecture:x86_64 CPU op-mode(s):32-bit, 64-bit Address sizes: 39 bits physical, 48 bits virtual Byte Order:Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Vendor ID: GenuineIntel Model name:Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz CPU family: 6 Model: 158 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 Stepping:9 CPU(s) scaling MHz: 50% CPU max MHz: 4200. CPU min MHz: 800. BogoMIPS:7200.00 [...] $ cat /proc/meminfo MemTotal: 32783544 kB [...] $ lspci | grep -i nvidia 01:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1080] (rev a1) [...] $ df -h Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p2 202G 183G 9.2G 96% / [...] $ ``` As you can see i'm slightly tight on disk space (and my ~/.thunderbird/ folder takes about 5.2GB), but i *think* this should be a usable setup. of course, thunderbird_115 upgraded my profile, so i can no longer downgrade to the thunderbird from bookworm :-( dfmasr IOhannes -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.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 thunderbird depends on: ii debianutils 5.8-1 ii fontconfig 2.14.1-4 ii libasound2 1.2.9-1 ii libatk1.0-0 2.49.90-2 ii libc62.37-7 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libdbus-1-3 1.14.8-2 ii libdbus-glib-1-2 0.112-3 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.4-1 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.13.0+dfsg-1 ii libgcc-s113.2.0-1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.77.1-2 ii libgtk-3-0 3.24.38-2 ii libicu72 72.1-3 ii libnspr4 2:4.35-1.1 ii libnss3 2:3.91-1 ii libotr5 4.1.1-5 ii libpango-1.0-0 1.50.14+ds-1 ii librnp0 0.16.3-1 ii libstdc++6 13.2.0-1 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.6-1 ii libx11-xcb1 2:1.8.6-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxext6 2:1.3.4-1+b1 ii libxrandr2 2:1.5.2-2+b1 ii psmisc 23.6-1 ii x11-utils7.7+5 ii zenity 3.44.0-3 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages thunderbird recommends: ii hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2 Versions of packages thunderbird suggests: ii apparmor 3.0.8-3 ii fonts-lyx 2.3.7-1 ii libgssapi-krb5-2 1.20.1-2 -- no debconf information
Bug#1043336: collectd: Recommends unavailable package "libgps28"
Package: collectd Version: 5.12.0-14 Severity: serious Justification: Policy 2.2.1 Dear Maintainer, collectd Recommens the binary package "libgps28". However, "libgps28" has been superseded by "libgps30" after the bookworm release and is no longer available. Since this is contradition with the debian policy [2.2.1], would you be so kind and remove the offending "Recommends" line? I guess this should have been caught by some gpsd-transition, dunno why this didn't trigger a binNMU... cheers [2.2.1] https://www.debian.org/doc/debian-policy/ch-archive.html#the-main-archive-area
Bug#1043333: python3-sugar3: Recommends unavailable package 'telepathy-salut'
Package: python3-sugar3 Version: 0.120-1 Severity: serious Justification: Policy 2.2.1 Dear Maintainer, python3-sugar3 Recommens the binary package "telepathy-salut". However, "telepathy-salut" has been removed in 2022-12 from both unstable and testing (bookworm, thus now stable). See bug [938645] Since this is contradition with the debian policy [2.2.1], would you be so kind and remove the offending "Recommends" line? cheers [938645] https://bugs.debian.org/938645 [2.2.1] https://www.debian.org/doc/debian-policy/ch-archive.html#the-main-archive-area
Bug#1042953: smokeping: Recommends non-existing package 'echoping'
Source: smokeping Severity: serious Justification: Policy 2.2.1 Dear Maintainer, The current version of smokeping in Debian (2.7.3-4.1) still depends on 'echoping' which was removed from the archives on 2020-08-07, so the last release that shipped it was buster (currently: old-old-stable). Please remove this dependency (as it violates Debian policy §2.2.1, see https://www.debian.org/doc/debian-policy/ch-archive.html#the-main-archive-area) cheers, and thanks for packaging 'smokeping'. gdamsr IOhannes
Bug#1004308: smokeping: New upstream version 2.8.2 needs to be packaged
Source: smokeping Followup-For: Bug #1004308 it seems that libobject-result-perl is now available in Debian (at least in unstable; but a source-only upload was done yesterday and all tests are passing, so it should migrate to testing in the next 2 days or so). so: could you revive the upgrade of smokeping to 2.8.2 (or whatever the latest and greatest version)? cheers, vgfmdar IOhannes
Bug#1042813: debian-installer: use ntp-server obtained via dhcp
Package: debian-installer Severity: wishlist Dear Maintainer, one thing that has been bothering me for ages is the use of hardcoded NTP-servers in the installer. Since NTP can obviously easily be abused for DDoS reflection attacks, many ISPs block the use of arbitrary NTP-servers, and instead provide an internal NTP server, which is typically announced via DHCP (in environments that use DHCP for setting up networking). Of course my university ids among these "ISPs", which means that for the last decade all of my Debian installations that i did on premises stalled (for a while) when the installer tries to get the network time (for which i think it queries *.debian.pool.ntp.org, but i haven't actually checked). it would be nice if the installer would *prefer* any NTP servers announced via DHCP (and use the debian.pool as a fallback). the current behaviour is not exactly a show-stopper, as it is easy to just cancel the time synchronisation (assuming that the hardware clock is within reasonable range). nevertheless it is annoying. otherwise i have been enjoying the installer. thank you very much. gasdmr IOhannes
Bug#1041044: Freeze of the system not primary caused by firefox
There where two addtional freezes caused by firefox on other webpages like windy.com. It seems that webpages with intense graphics can cause the system freeze. But there are two other events where the system freezes obvious in other applications. In many cases the process plasmashell is going into 100% cpu usage, so I will try to move this bug to KDE. Attached is an screenshot of the system in freezing KDE state, made by logging in from another PC via ssh. As already described the KDE is absolutely dead and only reset of the PC helps.
Bug#1042577: Vokoscreen crashes directly trying to start it
Package: vokoscreen-ng Version: 3.5.0-1 Severity: important I have an old installarion of vokoscreen V2.5 in the HDD that can be started and used. Installing this debian package V3.5 it crashes when trying to start. Here is the console output: $ vokoscreenNG [vokoscreenNG] Desktop session is a X11 session nouveau: kernel rejected pushbuf: Kein passendes Gerät gefunden nouveau: ch21: krec 0 pushes 1 bufs 8 relocs 0 nouveau: ch21: buf 0031 0004 0004 0x7fb989d7f000 0x111c000 0x8 nouveau: ch21: buf 0001 0006 0004 0004 0x7fb99b173000 0x215000 0x1000 nouveau: ch21: buf 0002 0046 0004 0004 0x7fb990a08000 0x133 0x1000 nouveau: ch21: buf 0003 0043 0002 0002 (nil) 0xf02000 0x1000 nouveau: ch21: buf 0004 0047 0004 0004 0x7fb990a07000 0x1331000 0x1000 nouveau: ch21: buf 0005 0044 0002 0002 (nil) 0xf08000 0x1000 nouveau: ch21: buf 0006 0048 0004 0004 0x7fb990a06000 0x1332000 0x1000 nouveau: ch21: buf 0007 0045 0002 0002 (nil) 0x132f000 0x1000 nouveau: ch21: psh 000978 000a80 nouveau: 0x200140c5 nouveau: 0x0040 nouveau: 0x20054088 nouveau: 0x0030 nouveau: 0x0040 nouveau: 0x0040 nouveau: 0x0001 nouveau: 0x nouveau: 0x200240c3 nouveau: 0x nouveau: 0x0133 nouveau: 0x2002408e nouveau: 0x nouveau: 0x00f02000 nouveau: 0x200240d3 nouveau: 0x nouveau: 0x nouveau: 0x200240c7 nouveau: 0x0040 nouveau: 0x0040 nouveau: 0x200140c0 nouveau: 0x00100010 nouveau: 0x200140c5 nouveau: 0x0040 nouveau: 0x20054088 nouveau: 0x0030 nouveau: 0x0040 nouveau: 0x0040 nouveau: 0x0001 nouveau: 0x nouveau: 0x200240c3 nouveau: 0x nouveau: 0x01331000 nouveau: 0x2002408e nouveau: 0x nouveau: 0x00f08000 nouveau: 0x200240d3 nouveau: 0x nouveau: 0x nouveau: 0x200240c7 nouveau: 0x0040 nouveau: 0x0040 nouveau: 0x200140c0 nouveau: 0x00100010 nouveau: 0x200140c5 nouveau: 0x0040 nouveau: 0x20054088 nouveau: 0x0030 nouveau: 0x0040 nouveau: 0x0040 nouveau: 0x0001 nouveau: 0x nouveau: 0x200240c3 nouveau: 0x nouveau: 0x01332000 nouveau: 0x2002408e nouveau: 0x nouveau: 0x0132f000 nouveau: 0x200240d3 nouveau: 0x nouveau: 0x nouveau: 0x200240c7 nouveau: 0x0040 nouveau: 0x0040 nouveau: 0x200140c0 nouveau: 0x00100010 vokoscreenNG: ../nouveau/pushbuf.c:730: nouveau_pushbuf_data: Zusicherung »kref« nicht erfüllt. Abgebrochen (Speicherabzug geschrieben) -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/4 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
Bug#1042575: GuVCView does record no video
Package: guvcview Version: 2.0.8-2 Severity: normal In previous releases of Debian GuVCView was always a good tool for easy video recording with an webcam. In Debian 12 everything works except the recording of a video. The recorded file only contains the sound and no video! Every option has been tried out and always there is only the sound recorded. What is going wrong? -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/4 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
Bug#1041829: lf: lf is outdated
Package: lf Version: 28-1+b3 Severity: normal Dear Maintainer, The last lf version is 30 (since 20/04/2023, see https://github.com/gokcehan/lf/releases). The Debian testing and sid version is 28. Perhaps I am misunderstood something but is there any policy reason to not update the lf package? Regards *** End of the template - remove these template lines *** -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled lf depends on no packages. Versions of packages lf recommends: ii ueberzug 18.1.9-4+b1 Versions of packages lf suggests: ii libimage-exiftool-perl [exiftool] 12.63+dfsg-2 -- no debconf information
Bug#1039983: Color Laser-Printer does only print in greyscale after upgrade to Debian 12
Package: cups Version: 2.4.2-3+deb12u1 Severity: important Dear Maintainer, here is the same problem with a Kyocera ECOSYS P5021cdw that works perfectly in Debian 11, but with the same settings after the upgrade to Debian 12 it is only possible to print in greyscales. Every settings are set to color but it is only possible to print in black and greyscales! -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/4 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 cups depends on: ii cups-client 2.4.2-3+deb12u1 ii cups-common 2.4.2-3+deb12u1 ii cups-core-drivers 2.4.2-3+deb12u1 ii cups-daemon 2.4.2-3+deb12u1 ii cups-filters 1.28.17-3 ii cups-ppdc 2.4.2-3+deb12u1 ii cups-server-common 2.4.2-3+deb12u1 ii debconf [debconf-2.0] 1.5.82 ii ghostscript 10.0.0~dfsg-11+deb12u1 ii libavahi-client3 0.8-10 ii libavahi-common3 0.8-10 ii libc6 2.36-9+deb12u1 ii libcups2 2.4.2-3+deb12u1 ii libgcc-s1 12.2.0-14 ii libstdc++6 12.2.0-14 ii libusb-1.0-0 2:1.0.26-1 ii poppler-utils 22.12.0-2+b1 ii procps 2:4.0.2-3
Bug#1041522: portmidi: new upstream available
Source: portmidi Severity: normal Dear Maintainer, thanks for packaging portmidi. unfortunately, it seems that Debian is lagging behind seriously. PortMidi-217 (as found in Debian) was released in 2010. However, the latest and greatest PortMidi release is v2.0.4 and was released in late 2022. Hooray for using another versioning scheme! (but then: Debian already uses an epoch, so we are probably safe :-)) The sourceforge page ships v2.0.2 (released in early 2022), but it seems that the project has now moved to GitHub https://github.com/PortMidi/portmidi Please update the package.
Bug#1041461: RM: ardour [mipsel mips64el] -- ROM; FTBFS on mips*el
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ard...@packages.debian.org Control: affects -1 + src:ardour 'ardour' FTBFS on the mips*el architectures. Rather than spending time on fixing these obscure errors, I would like to just drop these architectures. Reasoning: - Ardour is a full-fledged DAW (Digital Audio Workstation) for studio production (multichannel recordings, postproduction,...). I do not think there is any mips*el hardware out there that can be put to practical use for such a task. - Just today the main porter suggested to remove the entire mipsel architecture (although not mips64el) from the supported archs. https://lists.debian.org/debian-devel/2023/07/msg00217.html Thanks for your consideration.
Bug#1041044: Upgrade to firefox-esr 102.13.0esr-1~deb12u1
Today the next system upgrade has been done. Firefox is now version 102.13.0esr-1~deb12u1 I tested the above URL and it did not crash. I will report any new crash that will happen ...
Bug#1041044: Firefox hangs on certain web pages and crashes the complete KDE
Package: firefox-esr X-Debbugs-Cc: deb...@decotrain.de Version: 102.12.0esr-1~deb12u1 Severity: important Hello, since the upgrade vom Debian 11 to 12 there is the problem of a hanging KDE when using Firefox. For example opening this URL https://slidealama.eu is loading the webpage and then the complete KDE is freezing including the mouse pointer. gdb cannot be used, because you don't get any console window again. But it is possible to login remote from another PC, so the kernel is still alive. Requesting a kill of a process or a shutdown does not work - a reset of the PC is needed. Any ideas how to find out what is happening? Best regards karsten -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 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 -- no debconf information
Bug#1040525: Lighttpd disregards ssl.dh-file setting
On Fri, Jul 07, 2023 at 09:28:24AM +, Alain Knaff wrote: > Package: lighttpd > Version: 1.4.69-1 > > Since our upgrade to Debian 12, lighttpd now uses insecure > Diffie-Hellman parameters > c90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63 > b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d5 > 1c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899f > a5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39 > a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d6 > 70c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b > 2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2 > 261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb8 > 50458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94 > e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18 > 177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce > 0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186 > af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fb > ecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2 > d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c0 > 8f4df435c934063199 What are you sharing? What command did you use to obtain this info? Please clarify why you think this is insecure. This does not look like lighttpd mod_openssl default DH parameters used since lighttpd 1.4.56. Since lighttpd 1.4.56, lighttpd mod_openssl configures default DH parameters to use RFC 7919 FFDHE2048 2048-bit group https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/10c65e88f773d361db48e0135e1f4be3a932bf83 RFC 7919: https://datatracker.ietf.org/doc/html/rfc7919#appendix-A.1 Nowadays, FFDHE3072 is preferred, and a future version of lighttpd may change lighttpd mod_openssl to use FFDHE3072 by default in the future. Please note: if using GnuTLS (with lighttpd mod_gnutls) or using mbedTLS (with lighttpd mod_mbedtls), the Diffie-Hellman group is chosen to be secure according to RFC7919 DH parameter negotiation, and there is no default set by lighttpd. > And this despite having pointed ssl.dh-file to a self generated dh param > file, as described in https://weakdh.org/sysadmin.html That page is out-dated, at least for lighttpd. Since lighttpd 1.4.68, if you are using ssl.cipher-list specified in https://weakdh.org/sysadmin.html, then you are WEAKENING the cipher list now used by default since lighttpd 1.4.68. https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68 > In Debian 11, an identical configuration was using our locally generated > secure dh parameters. Since lighttpd 1.4.65 (released Jun 2022), lighttpd has been announcing the future scheduled removal of ssl.dh-file. https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_65 https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_66 https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_67 The removal of ssl.dh-file occurred in lighttpd 1.4.68 (Jan 2023) https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68 As linked in the lighttpd release notes: See https://wiki.lighttpd.net/Docs_SSL for replacements with `ssl.openssl.ssl-conf-cmd`, but prefer lighttpd defaults instead. Since lighttpd 1.4.68, use ssl.openssl.ssl-conf-cmd "DHParameters" to specify your own DH parameters file, as ssl.dh-file has been removed. If you have custom DH parameters, then please review RFC7919 and modern security papers to make sure what you think is secure is still considered secure by experts, as the use of parameters derived from "safe" primes is strongly recommended. It is my understanding that FFDHE3072 is the current recommendation if you are going to set explicit DH parameters. Cheers, Glenn
Bug#1039725: Pidgin crashes when a file transfer begins
Package: pidgin X-Debbugs-Cc: deb...@decotrain.de Version: 2.14.12-1 Severity: normal Hello, some years ago it was possible to transfer files within a pidgin chat. Then it becomes slower and in Debian 11 it was nearly impossible. Now after upgrade to Debian 12 it is impossible, because Pidgin crashes whenever a file transfer begins. This looks this way in the console: $ pidgin Pidgin 2.14.12 hat einen Speicherzugriffsfehler festgestellt und versucht, eine Core-Datei zu schreiben. Dies ist ein Fehler im Programm und kein Fehler von Ihnen. Wenn Sie den Absturz reproduzieren können, informieren Sie bitte die Entwickler mit einem Fehlerbericht auf: https://pidgin.im/development/simpleticket/ Bitte geben Sie unbedingt an, was Sie getan haben als der Fehler aufgetreten ist, und posten Sie den Backtrace aus der Core-Datei. Falls Sie nicht wissen, wie man einen Backtrace erstellt, lesen Sie bitte die Informationen auf https://pidgin.im/development/wiki/GetABacktrace Abgebrochen (Speicherabzug geschrieben) Speicherzugriffsfehler = segmentation fault There is no dump afterwards. A start with gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 'thread apply all bt full' --args pidgin only shows at the crash: Thread 1 (Thread 0x7fb3feadeb00 (LWP 19842) "pidgin"): #0 0x7fb3ffcdf324 in purple_xfer_prpl_ready () from /lib/x86_64-linux-gnu/libpurple.so.0 No symbol table info available. #1 0x7fb3fc669636 in jabber_iq_parse () from /usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0 No symbol table info available. #2 0x7fb3fc67e824 in ?? () from /usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0 No symbol table info available. #3 0x7fb3fef81bbb in ?? () from /lib/x86_64-linux-gnu/libxml2.so.2 No symbol table info available. #4 0x7fb3fef8270b in xmlParseChunk () from /lib/x86_64-linux-gnu/libxml2.so.2 No symbol table info available. #5 0x7fb3fc67ecdd in jabber_parser_process () from /usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0 No symbol table info available. #6 0x7fb3fc66d7f9 in ?? () from /usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0 No symbol table info available. #7 0x55f72c71401e in ?? () No symbol table info available. #8 0x7fb3fff5267f in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #9 0x7fb3fff52a38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #10 0x7fb3fff52cef in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #11 0x7fb400536b2a in gtk_main () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #12 0x55f72c6d7e55 in main () No symbol table info available. The hope was that the slow speed is fixed now, but it could not be proved, because it crashes always. https://issues.imfreedom.org/issue/PIDGIN-17293 This should be fixed in https://keep.imfreedom.org/pidgin/pidgin/rev/12e26d298873 <https://keep.imfreedom.org/pidgin/pidgin/rev/12e26d298873> and will in the 2.14.11 release. Now we have version 2.14.12 and it crashes instead of being slow. What can be done? -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 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
Bug#1039723: pysolfc does not start any more
Package: pysolfc Version: 2.6.4-3 Severity: grave Hello, trying to start the program after the upgrade from Debian 11 to 12 shows on the console this error message: $ pysolfc Traceback (most recent call last): File "/usr/games/pysolfc", line 36, in from pysollib.main import main # noqa: E402,I202 ^^ File "/usr/share/games/pysolfc/pysollib/main.py", line 30, in from pysollib.app import Application File "/usr/share/games/pysolfc/pysollib/app.py", line 32, in from pysollib.images import Images, SubsampledImages File "/usr/share/games/pysolfc/pysollib/images.py", line 28, in from pysollib.pysoltk import copyImage, createBottom, createImage, loadImage File "/usr/share/games/pysolfc/pysollib/pysoltk.py", line 35, in from pysollib.tile.tkhtml import * # noqa: F401,F403 ^^ File "/usr/share/games/pysolfc/pysollib/tile/tkhtml.py", line 29, in from pysollib.ui.tktile.tkhtml import Base_HTMLViewer File "/usr/share/games/pysolfc/pysollib/ui/tktile/tkhtml.py", line 24, in import formatter ModuleNotFoundError: No module named 'formatter' Which package must be installed to get the needed python module into the system? -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/6 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pysolfc depends on: ii python3 3.11.2-1+b1 ii python3-configobj 5.0.8-1 ii python3-pygame 2.1.2+dfsg-5+b1 ii python3-random2 1.0.1-2.1 ii python3-six 1.16.0-4 ii python3-tk 3.11.2-3 Versions of packages pysolfc recommends: ii python3-pil.imagetk 9.4.0-1.1+b1 Versions of packages pysolfc suggests: pn freecell-solver-bin pn pysolfc-cardsets -- no debconf information
Bug#1039558: qemu-system: Error starting domain: operation failed: Unable to find a satisfying virtiofsd
Package: qemu-system
Version: 1:8.0.2+dfsg-2
Severity: normal
X-Debbugs-Cc: 04_jujitsu_r...@icloud.com
Dear Maintainer,
After upgrading to qemu 1:8.0.2+dfsg-2, VMs with virtiofsd now fails to start.
See errors below. Downgrading to 1:7.2+dfsg-7 seemed to work fine. Probably
something changed in 8.0?
-- Error message:
Error starting domain: operation failed: Unable to find a satisfying virtiofsd
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57,
in newfn
ret = fn(self, *args, **kwargs)
^
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1402, in
startup
self._backend.create()
File "/usr/lib/python3/dist-packages/libvirt.py", line 1373, in create
raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: operation failed: Unable to find a satisfying virtiofsd
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-1-amd64
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages qemu-system depends on:
ii qemu-system-arm1:7.2+dfsg-7
ii qemu-system-mips 1:7.2+dfsg-7
ii qemu-system-misc 1:7.2+dfsg-7
ii qemu-system-ppc1:7.2+dfsg-7
ii qemu-system-sparc 1:7.2+dfsg-7
ii qemu-system-x861:7.2+dfsg-7
qemu-system recommends no packages.
qemu-system suggests no packages.
-- no debconf information
Bug#1037099: RFS: lighttpd/1.4.71-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.71-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.71-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036020 for lighttpd 1.4.70, this currently targets experimental, though I would like to get this into testing and into Bookworm in due time. Please advise. Thank you. Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
Macro, please review my previous messages and try to help provide additional information. Thank you. Glenn
Bug#1035926: lighttpd conf-enabled files cannot override IPV6 port number
On Thu, May 11, 2023 at 11:49:21AM +0200, Michael Moore wrote: ... > Issue and suggested fix: > === > In lighttpd.conf the includes for conf-enabled/*.conf happens after passing > server.port to the use-ipv6.pl script. Re-ordering these lines so that the > conf files are included first allows the server.port value to be > overridden. > > include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port > include_shell "/usr/share/lighttpd/create-mime.conf.pl" > include "/etc/lighttpd/conf-enabled/*.conf" Thank you for the thorough description. Yes, I agree with your suggestion. use-ipv6.pl is simple and its output can be placed anywhere in lighttpd.conf. Therefore, it should be safe to move to follow conf-enabled/*.conf I'll mark this fixed once the change is included in a release. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Tue, May 02, 2023 at 02:35:05AM -0400, gs-debian@gluelogic.com wrote: > On Fri, Apr 21, 2023 at 01:47:22PM -0400, gs-debian@gluelogic.com wrote: > > On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote: > > > On Apr 21, gs-debian@gluelogic.com wrote: > > > > > > > I probably should have started with the most basic thing: > > > > > > > > What is the date on your device? > > > NTP-accurate. > > > > Perhaps there is something amiss in the Debian 32-bit build of lighttpd > > or openssl for aarch64. (Is there any particular reason that you are > > running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?) > > Apologies for the delay. I installed Debian Bookworm onto a QEMU > aarch64 VM and the (64-bit!) lighttpd package for Debian aarch64 works > as expected when I tested with an expired LE cert (warning issued), and > when I tested with a current LE cert (no warning issued). > > From where did you obtain a 32-bit build of lighttpd for aarch64? > If you know, how was that 32-bit lighttpd built? I would like to try to > reproduce (as closely as possible) the 32-bit build. Is your system based on raspbian? My understanding is that a while back, raspbian was using a 32-bit kernel and 32-bit userland, even on aarch64-capable ARM chips. Then, they upgraded the kernel to be 64-bit on aarch64-capable ARM chips, but userland may still be 32-bit. In any case, I have tested that things work as expected for me on a physical 32-bit ARM processor running 32-bit lighttpd, and on a 64-bit ARM VM running 64-bit lighttpd. I'll need more info to get any further. You might try testing using lighttpd mod_gnutls instead of mod_openssl to see if that makes a difference. If it does, then the issue might be in the 32-bit armhf build of openssl that you are running under your aarch64 kernel. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 01:47:22PM -0400, gs-debian@gluelogic.com wrote: > On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote: > > On Apr 21, gs-debian@gluelogic.com wrote: > > > > > I probably should have started with the most basic thing: > > > > > > What is the date on your device? > > NTP-accurate. > > Perhaps there is something amiss in the Debian 32-bit build of lighttpd > or openssl for aarch64. (Is there any particular reason that you are > running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?) Apologies for the delay. I installed Debian Bookworm onto a QEMU aarch64 VM and the (64-bit!) lighttpd package for Debian aarch64 works as expected when I tested with an expired LE cert (warning issued), and when I tested with a current LE cert (no warning issued). >From where did you obtain a 32-bit build of lighttpd for aarch64? If you know, how was that 32-bit lighttpd built? I would like to try to reproduce (as closely as possible) the 32-bit build. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote:
> On Apr 21, gs-debian@gluelogic.com wrote:
>
> > I probably should have started with the most basic thing:
> >
> > What is the date on your device?
> NTP-accurate.
Perhaps there is something amiss in the Debian 32-bit build of lighttpd
or openssl for aarch64. (Is there any particular reason that you are
running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?)
If you are able to build lighttpd on your aarch64, you can use my
local (internal) code to parse ASN1_TIME, rather than the openssl
ASN1_TIME_cmp_time_t() routine to parse and compare. (Be sure to build
32-bit for testing to better match your current system configuration.)
For *testing only*, the following patch "disables" the check for openssl
1.1.1, which added ASN1_TIME_cmp_time_t(), so that the local (internal)
ASN1_TIME parsing is used.
--- a/src/mod_openssl.c
+++ b/src/mod_openssl.c
@@ -1272,7 +1272,7 @@ network_ssl_servername_callback (SSL *ssl, int *al, void
*srv)
#endif
-#if OPENSSL_VERSION_NUMBER < 0x10101000L \
+#if OPENSSL_VERSION_NUMBER < 0xL \
|| defined(BORINGSSL_API_VERSION) \
||(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x306fL)
static unix_time64_t
@@ -1291,7 +1291,7 @@ mod_openssl_cert_is_active (const X509 *crt)
{
const ASN1_TIME *notBefore = X509_get0_notBefore(crt);
const ASN1_TIME *notAfter = X509_get0_notAfter(crt);
- #if OPENSSL_VERSION_NUMBER < 0x10101000L \
+ #if OPENSSL_VERSION_NUMBER < 0xL \
|| defined(BORINGSSL_API_VERSION) \
||(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <
0x306fL)
const unix_time64_t before = mod_openssl_asn1_time_to_posix(notBefore);
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 09:38:31AM +0200, Marco d'Itri wrote: > On Apr 21, gs-debian@gluelogic.com wrote: > > > What your `uname -a` ? > Linux omitted.mi.bofh.it 6.1.0-7-arm64 #1 SMP Debian 6.1.20-2 (2023-04-08) > aarch64 GNU/Linux > > > What is the output of the following for you? > > $ lighttpd -V | grep "Y2038 support" > > + Y2038 support > Same. I probably should have started with the most basic thing: What is the date on your device? If the `date` is incorrect, e.g. starts at 1970 after reboot, then that might explain lighttpd's trace when starting lighttpd.
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 07:41:13AM +0200, Marco d'Itri wrote: > On Apr 21, gs-debian@gluelogic.com wrote: > > > Please confirm you are running an arm64 kernel, as you posted above. > Confirmed. What your `uname -a` ? What is the output of the following for you? $ lighttpd -V | grep "Y2038 support" + Y2038 support I'll build a Debian VM image this weekend to try to repro with the Debian packages. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Wed, Apr 19, 2023 at 01:39:02AM +0200, Marco d'Itri wrote: > Package: lighttpd > Version: 1.4.69-1 > Severity: normal > > I am using the latest openssl and lighttpd packages on an armhf (with an > arm64 kernel) and an amd64 system, and only on the armhf system I always > get this warning at startup even just after having created a Let's > Encrypt certificate. > > Apr 19 01:23:31 omitted.mi.bofh.it lighttpd[8876]: 2023-04-19 01:23:30: > (mod_openssl.c.1335) SSL: inactive/expired X509 certificate > '/var/lib/dehydrated/certs/omitted.mi.bofh.it/fullchain.pem' > > # openssl x509 -noout -text -in > /var/lib/dehydrated/certs/bokassa.mi.bofh.it/fullchain.pem | grep -A2 Validity > Validity > Not Before: Apr 18 22:13:45 2023 GMT > Not After : Jul 17 22:13:44 2023 GMT > > After looking at > https://github.com/lighttpd/lighttpd1.4/blob/fdb7ffed88b9dfe09a51e7fb58e5ddfe938c1ec9/src/mod_openssl.c#L1284 > > I wonder if this is common on all 32 bit systems instead. No, this is not common on all 32-bit systems, though I am curious as to why you are seeing that warning with a valid certificate. To try to reproduce this, I took some LE certs and put them on a 32-bit ARM system I have (which is running openwrt, not Debian) $ uname -m armv7l $ cat /proc/cpuinfo | egrep "model|Features" model name : ARMv7 Processor rev 1 (v7l) Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 $ file /usr/sbin/lighttpd /usr/sbin/lighttpd: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, no section header The vfpv3 and /lib/ld-musl-armhf.so.1 confirms to me this is an armhf. See also: https://www.baeldung.com/linux/arm64-armel-armhf-overview My cert: $ openssl x509 -noout -text -in /tmp/x.com/fullchain.pem | grep -A2 Validity Validity Not Before: Apr 10 22:15:43 2023 GMT Not After : Jul 9 22:15:42 2023 GMT ==> I did not get any warning trace on that system with: $ lighttpd -f test.conf -tt using my LE certificates, though that test system has only lighttpd 1.4.67 at the moment. My test system is running a 32-bit kernel. Please confirm you are running an arm64 kernel, as you posted above. What lighttpd package (from which architecture) do you have installed? $ file /usr/sbin/lighttpd might be useful. Please ensure that you have installed the proper package for your architecture. Is your system openssl-based or libressl-based? The only changes between lighttpd 1.4.67 and lighttpd 1.4.69 in lighttpd mod_openssl that seemed to be related to this issue is that lighttpd mod_openssl started using libressl ASN1_TIME_cmp_time_t() when LIBRESSL_VERSION_NUMBER >= 0x306fL and this also requires that lighttpd mod_openssl was built with libressl. The standard Debian package for lighttpd mod_openssl is built with openssl.
Bug#1034375: trurl_0.4-1: ACCEPTED on mentors (unstable)
Hi. Your upload of the package 'trurl' to mentors.debian.net was successful. Others can now see it. The URL of your package is: https://mentors.debian.net/package/trurl/ The respective dsc file can be found at: https://mentors.debian.net/debian/pool/main/t/trurl/trurl_0.4-1.dsc If you do not yet have a sponsor for your package you may want to go to: https://mentors.debian.net/sponsors/rfs-howto/trurl/ and set the "Seeking a sponsor" option to highlight your package on the welcome page. You can also send an RFS (request for sponsorship) to the debian-mentors mailing list. Your package page will give you suggestions on how to send that mail. Good luck in finding a sponsor! Thanks, -- mentors.debian.net
Bug#979308: This Bug is already fixed in Ubuntu
Ubuntu fixed this bug with jq (1.6-2.1ubuntu1) hirsute; urgency=medium [ Alex Murray ] * Fix fromdate when local time is during daylight savings (LP: #1910162) - d/p/fix-ftbfs-when-localtime-is-dst.patch: Backport upstream patch which ensures fromdate uses the correct time during daylight savings -- Christian Ehrhardt Tue, 05 Jan 2021 08:03:50 +0100
Bug#1031718: Problem identified
The problem could be identified - it is not a problem with this library. There port forwarding was manipulated on the incoming router, so that port 25 has not been forwarded any more. This bug can be closed.
Bug#1031810: mirror listing update for debian.mirror.net.in
Package: mirrors Severity: minor User: mirr...@packages.debian.org Usertags: mirror-list Submission-Type: update Site: debian.mirror.net.in Type: leaf Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Mirror Admin Debian Country: IN India Location: Mumbai Sponsor: Digital Dreams Consulting Pvt Ltd https://www.ddcpl.com Trace Url: http://debian.mirror.net.in/debian/project/trace/ Trace Url: http://debian.mirror.net.in/debian/project/trace/ftp-master.debian.org Trace Url: http://debian.mirror.net.in/debian/project/trace/debian.mirror.net.in
Bug#1031718: Same problem with BTS server
Maybe this error can be tracked within the Debian BTS email server? (There should be one more reply from the system for this email that will fail.) There could be found other suspect log entries in the exim log: 2023-02-21 13:39:03 TLS error on connection from scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): Error in the pull function. 2023-02-21 13:39:04 TLS error on connection from scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): Error in the pull function. 2023-02-21 13:39:04 TLS error on connection from scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): No supported cipher suites have been found. 2023-02-21 13:39:05 TLS error on connection from scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): Error in the pull function. 2023-02-21 13:39:06 TLS error on connection from scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): Error in the pull function. 2023-02-21 13:39:06 TLS error on connection from scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): Error in the pull function. 2023-02-21 13:39:06 TLS error on connection from scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): Error in the pull function. 2023-02-21 13:39:07 TLS error on connection from scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): Error in the pull function. 2023-02-21 13:39:07 TLS error on connection from scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): No supported cipher suites have been found. 2023-02-21 13:39:08 TLS error on connection from scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): Error in the pull function. = email at ow...@bugs.debian.org = Hello Debian BTS administrators, can you please check the log files of the mail system for a missing email? It shoud have been send at 21 Feb 2023 13:45:01 UTC It is regarding https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031718 Normally I get emails from the BTS engine without any problem. As you can see the email for submit was received and processed by the system. The log for this submit mail is: 2023-02-21 14:41:44 1pUSXU-002AnH-Kx => sub...@bugs.debian.org R=dnslookup T=remote_smtp H=buxtehude.debian.org [209.87.16.39] X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=no DN="C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=buxtehude.debian.org,EMAIL=hostmas...@buxtehude.debian.org" K C="250- 7971 byte chunk, total 7971\\n250 OK id=1pUSts-00Ad0p-7V" 2023-02-21 14:41:44 1pUSXU-002AnH-Kx Completed The exact error why the mail response fails would help to solve the bug 1031718. Thank you for your help and support karsten
Bug#1031718: In some cases there is the error: connection refused (Socket error code 10061)
Package: libgnutls30 X-Debbugs-Cc: deb...@decotrain.de Version: 3.7.1-5+deb11u2 Severity: normal Hello, this is more a question for ideas and support, because a bug cannot be proven. There is a problem with the mail system on a server, that does not receive emails from certain providers any more. The sender of the emails don't get any notice that the emails are not delivered and there is only one sender that could provide an error message. This is: 2/17/2023 12:43:19 PM - Server at PAWP195MB2418.EURP195.PROD.OUTLOOK.COM returned '550 5.4.316 Message expired, connection refused(Socket error code 10061)' 2/17/2023 12:33:05 PM - Server at domain.de (xx.79.98.xx) returned '450 4.4.316 Connection refused [Message=Socket error code 10061] Searching the internet shows that will be caused by a routing problem, but the mail system generally works and emails are received from other senders. The problem exists since 2023-02-15 so the idea is to search what has changed. The only thing that has changed is that an automated security update has happened: Start-Date: 2023-02-15 07:38:27 Commandline: apt-get upgrade -y -o Dir::Etc::SourceList=/etc/apt/security.sources.list Upgrade: libgnutls30:amd64 (3.7.1-5+deb11u2, 3.7.1-5+deb11u3), libgnutls-dane0:amd64 (3.7.1-5+deb11u2, 3.7.1-5+deb11u3) End-Date: 2023-02-15 07:38:32 That's the reason why the question is placed here. The changelog only tells about an "Fix double free": https://metadata.ftp-master.debian.org/changelogs//main/g/gnutls28/gnutls28_3.7.1-5+deb11u2_changelog It makes no sense that this bug was needed to avoid routing problems!? Is there any other idea for the reason of the problem? Best regards karsten -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1031200: hylafax-server: faxgetty.service doesn't work with iaxmodem
Hi Giuseppe, > > [...] > > The question is: could you confirm that you cannot > > add/remove/start/stop > > IAX devices without stopping the iaxmodem.service? In other words, no > > (device) events would be possibile once iaxmodem is started? > > No. You can add/remove devices with a seperate call of iaxmodem > > while iaxmodem.service is running. You can even (re)start > > running devices. There is no lock or similar for a device once iaxmodem > > is started. > > > > Could you please verify if any of the proposed configuration works also > when adding/removing a new IAX device when iaxmodem is already up and > running? Same. I think the behavior is not a systemd issue but an issue of iaxmodem. Once iaxmodem is started, it reads all available config files and assigns any existing symlinks to a new device of /dev/pts/. It doesn't check if it's already running and just overwrites existing symlinks. It doesn't terminate itself either, so any previously started process of iaxmodem remains still active. So, when I type /usr/bin/iaxmodem two times, the result with two available configfiles under /etc/iaxmodem is four iaxmodem processes running at the same time. As far as I understand the code of iaxmodem.c this is the intended behavior (which, for me, is wrong). Maybe I should file a bug report against iaxmodem first before we work on faxgetty's systemd unit - what do you think? Thanks, Tino
Bug#1031200: hylafax-server: faxgetty.service doesn't work with iaxmodem
Hi Giuseppe, > The problem is if we may just wait for iaxmodem or if we need to wait for > the device. I agree. > The dev-%i.device has events when udev sends them, but since that path is > not a real device, no udev events are sent. This probably means that using > dev-%i.device on any systemd unit is useless. I don't think they're useless. The intended behavior (from my understanding) of BindsTo=dev-%i.device is, to make sure faxgetty binds to that device and start it once the device becomes available or terminate it immediately when the underlying real device (say: /dev/ttyS0) is not available anymore. Therefore, the BindsTo-dependency makes sense to me. And this is why I wanted to keep them and add iaxmodem.service in this line with an OR statement, which seems not to be supported by systemd. > So, I am wondering if the minimal working unit is just > > [Unit] > Description=HylaFAX faxgetty %I > BindsTo=iaxmodem.service > After=iaxmodem.service This works. > The question is: could you confirm that you cannot add/remove/start/stop > IAX devices without stopping the iaxmodem.service? In other words, no > (device) events would be possibile once iaxmodem is started? No. You can add/remove devices with a seperate call of iaxmodem while iaxmodem.service is running. You can even (re)start running devices. There is no lock or similar for a device once iaxmodem is started. Thanks, Tino
Bug#1031200: hylafax-server: faxgetty.service doesn't work with iaxmodem
Hello Giuseppe, from my point of view all we need is a logical OR (||) in this systemd unit. Unfortunately I couldn't find such an option in systemd's manpages. So, I gave it a shot and tried this: [Unit] Description=HylaFAX faxgetty %I BindsTo=iaxmodem.service || dev-%i.device After=network.target Well, it works as expected: The devices come up and if I stop iaxmodem.service manually, all faxgetty services are immediately terminated as well. If I start faxgetty again, iaxmodem.service is started automatically. This is just for the iaxmodem part, I couldn't test with a real serial modem though. The After line is to make sure iaxmodem.service is running if faxgetty wants to start an iax device. But, again, I am not sure if this logical OR is officially supported by systemd. Tino
Bug#1031200: hylafax-server: faxgetty.service doesn't work with iaxmodem
> Does iaxmodem create the link in /dev when you configure the line, or when > it starts up? It's created at the start of iaxmodem. > Is the link present when iaxmodem service is stopped? No.
Bug#1031200: hylafax-server: faxgetty.service doesn't work with iaxmodem
Hello Giuseppe, thank you for working on this and responding so quickly. Yes, the Wants line is also working with two or more iax modems. Tino
