My gnome-session has been running from Nov 27 until today Dec 6.
Now pipewire-pulse stopped working again:
someuser@pureos:~$ paplay /usr/share/sounds/alsa/Front_Center.wav
Connection failure: Connection terminated
→ Can't play sound via pulseaudio
someuser@pureos:~$ pw-play
I've been running the patched version of pulseaudio for a few days now.
Open memfd for the software I'm using are staying a lot lower except for
gnome-shell:
`lsof | grep 'memfd:pulseaudio (deleted)' | cut -c1-16 | sort | uniq -c | sort
-n`
gives me
```
3 callaudio 47850
10
Thanks for filing this! The problem affects me, too.
Found this report and fixed printers.conf manually by deleting the line
Option print-color-mode monochrome
from it. Hope this gets fixed soon.
Package: libpulse0
Version: 16.1+dfsg1-2+b1
Severity: normal
Tags: patch fixed-upstream
(This will appear to be a pipewire bug, but in the end it looks like the
problem is pulseaudio not closing file handles. I therefor file this bug to
libpulse0 which I believe (no developer here) is used by
I saw in Boris logfile that the log is partly in german as well as my log on a
Debian Bullseye using rspamd 3.2.1 on a RockPro64.
I opened an issue for yunhost which is the system integration I use on that
system on the basis of Debian here:
https://github.com/YunoHost/issues/issues/2269
Package: u-boot-rockchip
Version: 2023.07+dfsg-1_arm64
Severity: normal
Hardware: RockPro64/4GB + DeLOCK 90498 SATA PCIe + 2 SATA SSDs
It's not possible to boot of the connected disks.
u-boot consoles output on a failed boot (falling back to eMMC):
```
Hit any key to stop autoboot: 0
=>
submited
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996003
to solve this issue. It is a backport from a patch accepted upstream at GNU
grub2.
-maintainer upload.
+ * apply patch from upstream:
+commit 0e5889b98ac202e0aadf04f4115a810304578219
+Author: Chris Vogel
+Date: Wed Sep 15 17:42:29 2021 +0200
+
+templates: Add GRUB_CMDLINE_LINUX_RECOVERY
+
+When generating grub.cfg using grub-mkc
Hi Michael,
thanks for the prompt answer!
On 18.06.2015 13:31, Michael Biebl wrote:
But mdadm (in jessie) ships it's own initramfs-tools hook
/usr/share/initramfs-tools/hooks/mdadm which is supposed to copy that
rules file into the initramfs.
Thanks for this information I missed. I looked
Please reassign the bug to package udev-215-17+deb8u1. I missed that
file /usr/share/initramfs-tools/hooks/udev belongs to udev.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: udev
Version: 215-17+deb8u1
Severity: normal
Dear Maintainer,
copying a Jessie installation from a server with hardware raid to a
system with software raid /dev/md* I found that the system would not
start on the new machine and would get stuck in initramfs.
Looking at /proc/mdstat
Package: initramfs-tools
Version: 0.120
Severity: normal
Dear Maintainer,
copying a Jessie installation from a server with hardware raid to a
system with software raid /dev/md* I found that the system would not
start on the new machine and would get stuck in initramfs.
Looking at
12 matches
Mail list logo
