Good job figuring it out.
If updating UEFI(that's a UEFI board, not a BIOS one, though it's not
much relevant here) and re-enabling the PCI-E resume still exhibits
the issue, you should report a bug, presumably to the kernel.
Might've already been fixed by now if the people from that 2011 thread
warning: directory permissions differ on /usr/share/polkit-1/rules.d/
filesystem: 750 package: 755
(5/6) upgrading polkit
[]
100%warning: directory permissions differ on /usr/share/polkit-1/rules.d/
filesystem: 750 package: 7
On 1/18/24 11:59, Martin Rys wrote:
Good job figuring it out.
If updating UEFI(that's a UEFI board, not a BIOS one, though it's not
much relevant here) and re-enabling the PCI-E resume still exhibits
the issue, you should report a bug, presumably to the kernel.
UEFI upgrade was the first thing
On Thu, 2024-01-18 at 10:32 -0500, Jude DaShiell wrote:
> What are correct permissions for these directories and has the upgrade
> corrected permissions that neede correction?
Hi,
the correct permissions are those, that are correct from your point of
view. No, the upgrade does not change your ind
On Thu, Jan 18, 2024 at 5:51 PM Jude DaShiell wrote:
> warning: directory permissions differ on /usr/share/polkit-1/rules.d/
> filesystem: 750 package: 755
> (5/6) upgrading polkit
> []
> 100%warning: directory permissions d
Am Thu, Jan 18, 2024 at 08:01:45PM +0100 schrieb Jan Alexander Steffens
(heftig):
> The permissions were recently changed to conform to upstream expectations.
> You can correct them on your system using:
>
> install -d -o root -g root -m 0755 /usr/share/polkit-1/rules.d
Not OP but thanks for you
The terminal output does suggest your gqrx was compiled with rtlsdr support.
Try compiling gqrx-git from the AUR, preferably with rtl-sdr-git installed.
Or follow the upstream build instructions.
If that doesn't work, I think it's best to submit an issue upstream.[1]
[1]: https://github.com/gqrx
On Thu, 2024-01-18 at 22:21 +0100, deMaio wrote:
> why doesn't pacman change the permissions at package upgrade?
Hi,
I am not an Arch developer, just another Arch user.
Custom, unusual permissions may be required for a user's system.
If upstream or an Arch developer sees reasons to change the p
PS:
Have you never been bitten by an /etc/foo.d/99.conf that made other
configurations null and void?
The *.pacnew approach fails when a package introduces a new
configuration through a drop-in file.
The advantage of a drop-in file is that it can automatically add
something new, but the disadvan
