In the context of Bluetooth, "sap" refers to the SIM Access Profile,
designed to allow mobile phones to lend the use of their SIM or USIM
cards over Bluetooth to car handsfree kits that have their own mobile
phone radio module, which may have greater transmitter power and a
better antenna for
Sorry about the late reply. It seems my spam filter ate the messages
from bugs.debian.org - I'll fix that.
I can't test the https://github.com/miniupnp/miniupnp/pull/562 PR right
now, but reading through it, it certainly appears to achieve the same
goal, while also including some miniupnpd
Looks like my spam filter ate the notification that you answered, and/or
since my post was "additional information only", I did not get a
notification in the first place.
My /etc/pam.d/sddm:
(lines wrapped by email client marked with \)
-
#%PAM-1.0
# Block login if
The workaround/fix for this would be to not let pam-auth-update add
pam_ssh.so into common-auth and common-session, but add the necessary
lines *selectively* only to services that handle local logins like
/etc/pam.d/login and /etc/pam.d/*dm, but *not* to /etc/pam.d/sshd.
That should allow
Package: miniupnpd-nftables
Version: 2.2.1-1
Severity: normal
Tags: patch
Dear Maintainer,
I have a manually-crafted set of firewall rules, currently using
iptables-nft but still heavily based on classic iptables way of doing
things.
On update from Debian 10 to 11, miniupnpd transitioned to the
"Extremely verbose" indeed - it can produce gigabytes of log data in a
single day. Before I applied the workaround below, it filled the root
disk of my home server system three times.
Unfortunately it looks like the version in Bullseye does not have the
"start_daemon" configuration file
Package: ifupdown-extra
Version: 0.32
Severity: normal
Tags: ipv6 patch
Dear Maintainer,
When adding package "ifup-extra" on a fresh installation of Debian 11,
I started getting error messages referring to "wlan0" at ifup time.
This was unexpected as this system had no interface named "wlan0"
As far as I understand, different implementations had different ways to specify
the semantics of “disabling the account”.
So the developers of the passed command went to look for details that would be
un-ambiguous in all implementations, and this seems to be what they found:
- neither an
While waiting for a solution, the following workaround seems to work for
Stretch at least:
Step 1.)
Copy /usr/share/initramfs-tools/scripts/local-top/cryptroot to
/etc/initramfs-tools/scripts/local-top/cryptroot.
# cp /usr/share/initramfs-tools/scripts/local-top/cryptroot \
Package: zfs-fuse
Version: 0.7.0-16
Severity: normal
Dear Maintainer,
When installed on up-to-date stable Debian 9.1 system using systemd,
the zfs-fuse package causes an ordering cycle at boot time:
Oct 02 12:15:47 finmatkurk1 systemd[1]: sysinit.target: Found ordering
cycle on
If /var or /var/log is a separate filesystem, the udev rule for this can
often run before that filesystem is mounted, causing the
/var/log/uvcdynctrl-udev.log file to be "hidden" under the mountpoint -
where it is also unreachable by logrotate and similar tools, and thus
might grow forever
On Mon, 7 Mar 2011, Christian PERRIER wrote:
Thanks for this patch. I committed it.
(alternative approach to MS-DOS/Win3.1 detection)
I agree this would be more reliable. Do you think that you could
propose a patch for such improvement?
Certainly; however, I'm currently travelling and so
Package: os-prober
Version: 1.42
Severity: normal
Configuration:
- system is partitioned as follows:
/dev/sda1 = Linux /boot
/dev/sda2 = DOS 6.22
/dev/sda3 = extended partition
/dev/sda5 = Linux LVM PV, containing swap and Linux filesystems
- /dev/sda2 is mounted on /dos
(so the DOS
Package: xsensors
Version: 0.50-1
Severity: normal
Trying to run xsensors causes this error message:
$ xsensors
xsensors: error while loading shared libraries: libsysfs.so.1: cannot
open shared object file: No such file or directory
Etch contains libsysfs.so.2, so it looks like xsensors is
14 matches
Mail list logo
