On Thu, 10 Oct 2024 16:41:36 +0200 Vincent Blut wrote:
Sorry, I never saw this back in October - just came across it when I
checked on the bug at bugs.debian.
> As you correctly pointed out, AppArmor is not able to follow symlinks,
AppArmor is, as was so often said back before it was shoved dow
Package: chrony
Version: 4.3-2+deb12u1
Similar to old #970421, apparmor blocks chrony from reading
/sys/class/hwmon/hwmon0/temp1_input, reporting:
audit[2374]: AVC apparmor="DENIED" operation="open"
profile="/usr/sbin/chronyd"
name="/sys/devices/pci:00/:00:18.3/hwmon/hwmon1/temp1_in
On Sun, May 07, 2023 at 07:36:49PM +0300, Michael Tokarev wrote:
> Control: tag -1 + moreinfo
>
> 07.05.2023 19:17, Martin Maney wrote:
>
> > Like qemu-system-x86, which xen-utils recommends in Bullseye and
> > earlier, qemu-system-xen needs to depend on ipxe-firmware or
Package: qemu-system-xen
Version: 1:7.2+dfsg-6
Like qemu-system-x86, which xen-utils recommends in Bullseye and
earlier, qemu-system-xen needs to depend on ipxe-firmware or attempts
to start an HVM domU using uefi will fail with "failed to find romfile"
error.
The workaround is, of course, to man
Correction: does not apply to ntp package. I seem to have looked for
it on the wrong machine (one that was in fact using ntpsec).
And apologies for the link munging - I've been forced to route through
sendgrid ever since the connection here was upgraded to fiber, and
despite repeated claims to
First, an answer that I happen to have handy to Hans's question from
Feb 2019:
"TBH, I'm not an expert at all in this area, I never figured out yet
how all these systemd<->init-script compatibility layers work yet."
Neither am I an expert, and I'd really prefer not needing to become
one, but fr
Package: src:vlc
Version: 3.0.8-0+deb10u1
Still present in Buster (vlc 3.0.8-0+deb10u1).
There are other characters that are mishandled by either the m3u
parsing or the path handling (as the path is built from local names in
the m3u), but apparently I didn't report them as they were discovered
an
Correction: the Realtek NIC doesn't, in fact, require that firmware.
System works the same (aside from the boot message abouit not finding
the firmware file) without it, devices renamed the same... And I
booted into d-i far enough to see that, yep, it sees the new name when
it sets up the NIC.
Package: installation-reports
Boot method: netboot
Image version:
http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/debian-installer/amd64/{linux,initrd.gz}
Date: 2017-05-13 18:00:00 CDT
Machine: Gigabyte E350 based box-o-parts (previously had Jessie, etc.
Two months later, there's no fix for Stable (1.12.1 is the current
version). Is it stuck somewhere in process?
Thanks.
On Wed, 18 Jan 2017 21:19:01 + Robert Luberda wrote:
> Source: dwww
> Source-Version: 1.13.3
>
> We believe that the bug you reported is fixed in the latest version of
>
Package: nethogs
Version: 0.8.0-1
Severity: grave
Tags: patch
Justification: renders package unusable
Bug has already been fixed in NMU upload for stretch & unstable, but nethogs
still crashes in Jessie. Patch is in #808433, which perhaps oughtn't have been
closed quite so soon.
-- System Infor
Nothing to add, really, other than the system is amd64 and nethogs was
installed right after updating everything else. Looks like the fix has
just never been pushed to Jessie.
Thanks!
--
The only non-renewable resource you truly have
is your time. -- Clay Johnson
Package: qpdfview
Version: 0.4.12-1
Severity: important
Yes, if the same file is foo.PDF rather than foo.pdf, qpdfview will fail to
list it in the open file dialog. The exact name can be typed in, or it can
be opened in any of the other ways that don't require qpdfview itself to suss
out the "sup
Package: debian-installer
Version: 20150422
Sadly, I can't report this from the machine where this occured, but the
setting is simple: new net-install on a machine with one SSD (sda) and
three HDs (sdb,c,d). Trying to setup a maintenance partition before
completing final setup & install, so it's
Package: apt-proxy
Version: 1.9.36.3+nmu1
Followup-For: Bug #460338
I've had apt-proxy running for the Debian (was Etch, just migrated the Xen
dom0 to Lenny, which was the last and the most troublesome, but that's
another bug report, maybe). Today I inadvertently demonstrated the apt-proxy
hang
After upgrading to Lenny I saw these dhcpd log messages leaking through
logcheck once again - I'd taken the new version of the file because it
obviously had some additions, and I'd hoped the underscore in interface
name issue might have been fixed, but no luck there.
Attached is the diff of the m
I had a chance to test this on the Lenny machine where the problem was
first seen. Replacing one line in the init script allows the machine
to send the shutdown command to the UPS:
poweroff)
flag=`sed -ne 's#^ *POWERDOWNFLAG *\(.*\)$#\1#p' /etc/nut/upsmon.conf`
wait_delay=`sed -ne 's
Subject: nut: Lenny: NUT doesn't shutdown UPS on powerfail
Package: nut
Version: 2.2.2-6.4
Severity: grave
Justification: renders package unusable
This tells the essence of the story:
$ ldd /sbin/upsmon
linux-gate.so.1 => (0xb7fad000)
libupsclient.so.1 => /usr/lib/libupsclient.so
Package: logcheck-database
Version: 1.2.54
Severity: normal
This is Yet Another Character In An Interface Name Not Accepted By The DHCP
Ignore Ruleset. The culprit in this case was br_lan, and the fix I've
applied recreated that suggested in bug #470929 (I might have saved myself a
few minutes if
19 matches
Mail list logo
