Thanks for letting me know. I never would have found out unless you told me.
FS#78884 : powerdevil 5.27.6-2 requires ddutil added as a package dependency
Flyspray, a Bug Tracking System written in PHP.
Thanks for letting me know. I never would have found out unless you told me.
TeX Live package reorganization
2023-06-18 - Antonio Rojas
Starting from version 2023.66594-9, TeX Live packages have been reorganized to mirror upstream collections. Even though the new
texlive-basic
replaces the oldtexlive-core
, many of the texlive-core contents (including language specific files) are now split between different packages. To find out which Arch package contains a specific CTAN package, you can use thetlmgr
utility, eg.$ tlmgr info euler | grep collection collection: collection-latexrecommended
which means the euler CTAN package is contained in
texlive-latexrecommended
. You may also usepacman -F
to query for specific files.A new metapackage
texlive-meta
is available to install all subpackages (except for language specific ones), and the newtexlive-doc
package provides the full documentation for offline use.
This broke latexmk
:
$ pamac search --files /usr/bin/latexmk
/usr/bin/latexmk is owned by texlive-bin
$ pamac info texlive-bin
Name : texlive-bin
Version : 2023.66984-7
[...]
Build Date : Sa 17 Jun 2023 01:29:09 CEST
Install Date : Mo 19 Jun 2023 09:57:19 CEST
$ which latexmk
latexmk not found
Edit: You have to install texlive-binextra
to actually install latexmk
.
The file that texlive-bin
provides is a broken symlink to /usr//share/texmf-dist/scripts/latexmk/latexmk.pl
which can only be resolved by installing the binextra package.
It’s fixed with 2023.66594-13.
systemd
in it’s current state has a regression which leads to (some) problems with libvirtd
and other services:
It seems to be resolved now by reverting the offending commit:
Arch has already released a fixed systemd
package with this single cherry-pick:
As we do not inherit systemd
from arch, I’m hoping for an updated package…
edit: Thanks to @Yochanan the patch has landed:
The
pamac-gtk
Gtk 4 port is finally finished!
Make sure you’re fully up to date first:
sudo pacman -Syu
Then choose which version you prefer:
Install Gtk 4 version:
sudo pacman -S pamac-gtk
Install Gtk 3 version:
sudo pacman -S pamac-gtk3
I get a lot of GTK critical messages when clicking on Pamac menu in the GUI in KDE Plasma, this is pamac-gtk
. but pamac-gtk3
has no issue. I can reproduce the issue on my system and VM without custom config.
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.950: _gtk_css_corner_value_get_x: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.950: _gtk_css_corner_value_get_y: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_x: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_y: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_x: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_y: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.993: _gtk_css_corner_value_get_x: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.993: _gtk_css_corner_value_get_y: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
...
I reported the issue.
How will the gtk4 version affect the Flatpak and Snap plugins?
They’re not related as they’re part of libpamac
.
pamac-gtk
and pamac-gtk3
should properly conflict reach other.
edit: Ah, the current pamac-gtk3
package conflicts with pamac-gtk
but the current pamac-gtk
doesn’t conflict with pamac-gtk3
.
It still has to interact with them.
The description of pamac-gtk (gtk4 version) still notes gtk3 in the description. I have installed the gtk4 version and it seems to function well for my use case. Nice work and thank you.
Changing some Pamac preferences can not be saved when using pamac-gtk
(gtk4)
pamac-manager
Presumably through libpamac
.
3 posts were split to a new topic: Pamac-gtk does not match Xfce theme
This could be my fault somehow … but
after powerdevil
upgrade … the services no longer seem to work.
I’ve tried downgrading to no avail. Ive tried refreshing/reloading the services and dbus …
There shows it failed - battery icon missing.
In systemctl --user status powerdevil
It shows:
org.kde.powerdevil: KDE Power Management System init failed!
Similar to journalctl:
systemd[949]: plasma-powerdevil.service: start operation timed out. Terminating.
systemd[949]: plasma-powerdevil.service: Failed with result 'timeout'.
systemd[949]: plasma-powerdevil.service: Scheduled restart job, restart counter is at 199.
org_kde_powerdevil[6025]: org.kde.powerdevil: KDE Power Management System init failed!
Manually doing
killall org_kde_powerdevil
kstart5 /usr/lib/org_kde_powerdevil
and restarting the user service … seems to ~work … as in the logs become clean … but the rest of the desktop (system settings, icon) still acts as if powerdevil is not functioning (no progress if plasma is restarted either).
A reboot returns to the same problematic state … new test user exhibits the same.
Note - the battery itself is somewhat old/damaged at 60% life … but this displays fine in other utilities, and a clean ISO acts as expected.
EDIT.
Found it
Theres just about no documentation to go off of … and the package certainly doesnt have any dependencies that point this way … but …
ddcutil
- without that installed powerdevil will fail. After install everything is s
…and it looks like someone noticed at Arch:
Flyspray, a Bug Tracking System written in PHP.
…and its maybe being fixed:
GitLab Enterprise Edition
with the new sddm
got a slightly different form of PAM configuration file for sddm. suggested generic configuration file (/etc/pam.d/sddm);
auth include system-login
-auth optional pam_gnome_keyring.so
-auth optional pam_kwallet5.so
account include system-login
password include system-login
-password optional pam_gnome_keyring.so use_authtok
session optional pam_keyinit.so force revoke
session include system-login
-session optional pam_gnome_keyring.so auto_start
-session optional pam_kwallet5.so auto_start
so for someone running KDE on sddm i guess omitting lines with pam_gnome_keyring.so
is fine;
auth include system-login
-auth optional pam_kwallet5.so
account include system-login
password include system-login
session optional pam_keyinit.so force revoke
session include system-login
-session optional pam_kwallet5.so auto_start
likewise for someone running Gnome DE on GDM omitting pam_kwallet5.so
lines is fine. please advice if additional configuration is required.
also, is this really necessary;
session optional pam_keyinit.so force revoke
so for someone running KDE on sddm i guess omitting lines with
pam_gnome_keyring.so
is fine;
Reinstalling or updating sddm
would reset this configuration including pam_gnome_keyring.so
.
I think you don’t need to remove the line pam_gnome_keyring.so
again after update sddm
.
please advice if additional configuration is required.
-auth optional pam_gnome_keyring.so -auth optional pam_kwallet5.so
From pam.conf:
If the type value from the list above is prepended with a - character the PAM library will not log to the system log if it is not possible to load the module because it is missing in the system. This can be useful especially for modules which are not always installed on the system and are not required for correct authentication and authorization of the login session.
It’s fine to leave everything as it is, the only available configuration will be loaded.