[Unstable Update] 2023-05-21 - Repository changes

Yochanan · 17 June 2023 19:45

Yochanan · 18 June 2023 13:57

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 old texlive-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 the tlmgr utility, eg.
$ tlmgr info euler | grep collection
collection:  collection-latexrecommended
which means the euler CTAN package is contained in texlive-latexrecommended. You may also use pacman -F to query for specific files.

A new metapackage texlive-meta is available to install all subpackages (except for language specific ones), and the new texlive-doc package provides the full documentation for offline use.

mithrial · 19 June 2023 08:00

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.

Yochanan · 19 June 2023 14:48

It’s fixed with 2023.66594-13.

freggel.doe · 20 June 2023 11:16

systemd in it’s current state has a regression which leads to (some) problems with libvirtd and other services:

github.com/systemd/systemd

libvirtd socket activation not working since 253.5

opened 12:34PM - 07 Jun 23 UTC

closed 04:18PM - 19 Jun 23 UTC

lkrms

bug 🐛 pid1 regression ⚠️ rc-blocker 🚧

### systemd version the issue has been seen with 253.5 ### Used distribution …Arch Linux (rolling) ### Linux kernel version used 6.3.5-arch1-1 ### CPU architectures issue was seen on x86_64 ### Component systemd ### Expected behaviour you didn't see In its default configuration, `libvirtd.service` starts a `libvirtd` process that times out after 120 seconds of inactivity (no running domains and no connected clients). The service remains active and `libvirtd` is respawned on-demand via systemd socket activation (`libvirtd-ro.socket`, `libvirtd.socket` and `libvirtd-admin.socket` correspond to `/var/lib/libvirt/`{`libvirt-sock-ro`,`libvirt-sock`,`libvirt-admin-sock`}` respectively by default). ### Unexpected behaviour you saw After updating from systemd 253.4 to 253.5, socket activation stopped working. Attempting to connect to `libvirtd` via a socket after it times out yields nothing. Client software (I'm using `virsh` and `virt-manager` on the same host) halts indefinitely as soon as a `libvirtd`-dependent command is issued, and no errors are reported or logged before or after they are terminated (e.g. with Ctrl+C), including by systemd. If `systemctl restart libvirtd.service` is issued in a separate terminal, `libvirtd` starts as normal and any processes trying to connect via a socket succeed immediately (there is no need to cancel the attempt and try again). After rolling back systemd, libvirt and other updates installed at the same time in various combinations, the culprit appears to be systemd 253.5. Downgrading to 253.4 restores the desired behaviour. ### Steps to reproduce the problem - Install a libvirt package with stock systemd unit files - Start libvirtd and/or enable its sockets as needed - Wait for the libvirtd process to terminate after 2 minutes - Run `sudo virsh list` or similar - Wait indefinitely ### Additional program output to the terminal or log subsystem illustrating the issue ```sh Here's output from strace, in the absence of anything appearing in a log entry: https://gist.github.com/lkrms/5bb9ef2e7ad8aa5d89e164b6e3f4d4a6#file-gistfile1-txt ```

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:

Yochanan · 21 June 2023 18:14

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

Zesko · 21 June 2023 20:04

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 == &GTK_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.950: _gtk_css_corner_value_get_y: assertion 'corner->class == &GTK_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_x: assertion 'corner->class == &GTK_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_y: assertion 'corner->class == &GTK_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_x: assertion 'corner->class == &GTK_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_y: assertion 'corner->class == &GTK_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.993: _gtk_css_corner_value_get_x: assertion 'corner->class == &GTK_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.993: _gtk_css_corner_value_get_y: assertion 'corner->class == &GTK_CSS_VALUE_CORNER' failed
...

I reported the issue.

Locutus · 21 June 2023 22:52

How will the gtk4 version affect the Flatpak and Snap plugins?

Yochanan · 21 June 2023 23:09

They’re not related as they’re part of libpamac.

freggel.doe · 22 June 2023 06:43

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.

Locutus · 22 June 2023 09:30

It still has to interact with them.

jrichard326 · 22 June 2023 10:10

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.

Zesko · 22 June 2023 10:25

Changing some Pamac preferences can not be saved when using pamac-gtk (gtk4)

How to reproduce the issue:

Open pamac-manager
Click Pamac meu → Click “Preferences”
Change number of “Parallel downloads”
or change “mirrors”
or change “Number of versions of each package to keep”
Close and reopen “Preferences”.
As a result, it does not change.

dmt · 22 June 2023 11:17

Presumably through libpamac.

Yochanan · 24 June 2023 14:59

3 posts were split to a new topic: Pamac-gtk does not match Xfce theme

cscs · 25 June 2023 02:46

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:

…and its maybe being fixed:

koshikas · 25 June 2023 06:10

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

Zesko · 25 June 2023 07:04

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.

stasadev · 25 June 2023 10:28

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.

GaVenga · 25 June 2023 16:21

ostree 2023.4-1 is broken - 2023.3-1 works:

github.com/ostreedev/ostree

2023.4 appears to have made Flatpak regress

opened 01:22PM - 23 Jun 23 UTC

smcv

As reported on https://github.com/flatpak/flatpak/issues/5452, multiple Fedora u…sers seem to be seeing Flatpak update failures since their OS was upgraded from libostree 2023.3 to 2023.4. @yuntaz0 reports in https://github.com/flatpak/flatpak/issues/5452#issuecomment-1604140400 that rolling back to a previous OS image resolves this for them; only a few packages were involved in that rollback, of which libostree seems like the most likely cause for a Flatpak regression. I haven't packaged 2023.4 for my OS (Debian) yet, so I have no particular insight into this myself.