It still has to interact with them.
FS#78884 : powerdevil 5.27.6-2 requires ddutil added as a package dependency
Flyspray, a Bug Tracking System written in PHP.
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
.
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.
ostree 2023.4-1 is broken - 2023.3-1 works:
As reported on https://github.com/flatpak/flatpak/issues/5452, multiple Fedora u…
Pleases test ostree
2023.4-1.0 (soon 2023.4-2 from Arch) with the problematic commit reverted.
ostree
2023.4-1.0 (Manjaro unstable/extra)
results in: (sd-execu[307]: /usr/lib/systemd/system-generators/ostree-system-generator failed with exit status 1.
ostree
2023.4-2.0 (ARCH/testing) the same ERROR!!
ostree
2023.3-1.0 (Manjaro testing/extra) works…
In case anyone experiences issues with snaps recently, installing AppArmor 3.1.6 from Arch’s Testing might resolve them. I’ve been testing it the for a day already and it seems it is quite safe at least for Manjaro Unstable branch. I know many people dislike snaps but sometimes there’s no other way except rebuilding the entire Qt which is not a fun game.
With kernel 6.4 being released, can someone confirm or check that the issues with BTRFS from before are resolved?
Calamares is broken it complains about user@user module can’t be loaded.
I believe this is due to icu package being at 73 and calamares wants 72.
Fixed with the update of calamares to 3.2.62-3 yesterday
I’m seeing bluetoothd
core dumps with bluez 5.67-1
.
After downgrading to 5.66-1
bluetooth works as before.
(5.66 was fine) bisected to https://github.com/bluez/bluez/commit/3030883005c…
I can reproduce it and an Arch bug report has been filed: FS#78937 - [bluez] coredump when playing audio since 5.67-1
Ah, that bluez
report wasn’t filed yet when I looked.
On another note:
Sometimes my amd machine gets hit by a kernel bug on boot. Seems to be included in multiple kernels, I’ve seen this on linux63
and linux61
so far.
A recent mention in a testing announcement thread sees this in linux515
:
amd64 linux515-5.15.118 brings buggy amdgpu [ 67.671434] r8169 0000:02:00.0 enp2s0: Link is Down [ 68.408959] BUG: kernel NULL pointer dereference, address: 00000000000002b0 [ 68.415453] #PF: supervisor read access in kernel mode [ 68.417069] #PF: error_code(0x0000) - not-present page [ 68.418629] PGD 0 P4D 0 [ 68.420172] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 68.421737] CPU: 0 PID: 741 Comm: Xorg.wrap Not tainted 5.15.118-1-MANJARO #1 14999a6f5ec48d886528316cca06ede77d2fe88b [ 68…
There is a thread on arch forums about it.
Possible fix mentioned in post #17:
Only low priority rings are using chunks to save the offset. Bypass the mark offset callings from high priority rings. Signed-off-by: Jiadong Zhu Acked-by: Alex Deucher
After the most recent update from unstable and reboot, the pipewire-pulse service starts and then subsequently crashes (SIGSEGV).
alex@alex-pc ~]$ systemctl --user status --lines=50 pipewire-pulse
× pipewire-pulse.service - PipeWire PulseAudio
Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; preset: enabled)
Active: failed (Result: core-dump) since Sat 2023-07-01 19:12:21 PDT; 2min 8s ago
Duration: 625ms
TriggeredBy: × pipewire-pulse.socket
Process: 11998 ExecStart=/usr/bin/pipewire-pulse (code=dumped, signal=SEGV)
Main PID: 11998 (code=dumped, signal=SEGV)
CPU: 46ms
Jul 01 19:12:21 alex-pc systemd[1751]: pipewire-pulse.service: Main process exited, code=dumped, status=11/SEGV
Jul 01 19:12:21 alex-pc systemd[1751]: pipewire-pulse.service: Failed with result 'core-dump'.
Jul 01 19:12:21 alex-pc systemd[1751]: pipewire-pulse.service: Scheduled restart job, restart counter is at 5.
Jul 01 19:12:21 alex-pc systemd[1751]: Stopped PipeWire PulseAudio.
Jul 01 19:12:21 alex-pc systemd[1751]: pipewire-pulse.service: Start request repeated too quickly.
Jul 01 19:12:21 alex-pc systemd[1751]: pipewire-pulse.service: Failed with result 'core-dump'.
Jul 01 19:12:21 alex-pc systemd[1751]: Failed to start PipeWire PulseAudio.
[ble: exit 3]
[alex@alex-pc ~]$
Is this known? If so, is there something I should do to handle it?
I cannot reproduce here.
$ systemctl --user status pipewire-pulse.service
● pipewire-pulse.service - PipeWire PulseAudio
Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; preset: enabled)
Active: active (running) since Sat 2023-07-01 17:21:49; 2h 5min ago
TriggeredBy: ● pipewire-pulse.socket
Main PID: 1705 (pipewire-pulse)
Tasks: 2 (limit: 8173)
Memory: 24.8M
CPU: 1min 39.233s
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire-pulse.service
└─1705 /usr/bin/pipewire-pulse
Jul 01 17:21:49 manjaro systemd[1057]: Started PipeWire PulseAudio.
What does the coredump say?