[Testing Update] 2021-10-05 - Kernels, Mesa, Browsers, Python, UKUI, PHP, Thunderbird, Pipewire

You should try with the new config file for TLP instead of your old config.

3 Likes

Thanks for the suggestion. I replaced the old config file with the .pacnew one, and my system didn’t crash or had a display reset after reloading tlp.service and plugged my laptop back in. Then, I plopped back in my merged tlp.conf, and I found out that the crashes only occurred when RADEON_DPM_PERF_LEVEL_ON_AC is set to "high". I guess I should report this strange behavior in the TLP GitHub repo, even though setting that to the default (auto) solved my issue here.

Edit: I submitted a GitHub issue about this matter on the said repository.

4 Likes

Hi, Code 1.60.2-1 (community repository) stoped working after the last update.

When I check journalctl -p 3 -xb I get a long list which concludes with: Process 101947 (electron) crashed and dumped core.

Solved :white_check_mark: by reinstalling electron 13

Thanks!

Solved by setting XDG_DATA_DIRS=/usr/share/ in my .profile
gnucash 4.8 seems to need this variable to find its schema.
Do you know how XDG_DATA_DIRS is usually set ?

On my system, that is already set.

I don’t know how it gets set though

$ grep -rn XDG_DATA_DIRS /etc 2> /dev/null
/etc/profile.d/flatpak.sh:2:    # set XDG_DATA_DIRS to include Flatpak installations
/etc/profile.d/flatpak.sh:14:                case ":$XDG_DATA_DIRS:" in
/etc/profile.d/flatpak.sh:24:    export XDG_DATA_DIRS
/etc/profile.d/flatpak.sh:25:    XDG_DATA_DIRS="${new_dirs:+${new_dirs}:}${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"
$ pacman -Qo /etc/profile.d/flatpak.sh
/etc/profile.d/flatpak.sh is owned by flatpak 1.11.3-1

OK, thanks.
But flatpack is not installed on my system. So perhaps should it be a gnucash’s dependency now

Ehm, no: guncash should definitely not depend on flatpak.

It just happens, that the flatpak package tries to extend the XDG_DATA_DIRS variable and therefore sets/exports it. It’s the only package on my system that does the export, but there are numerous counts of code trying to evaluate/use that variable - most with fallbacks like seen here:

${XDG_DATA_DIRS:-/usr/local/share:/usr/share}

guncash should implement a similar fallback where it tries to use $XDG_DATA_DIRS - that’s all.

You can remedy your problem for the time being by ensuring XDG_DATA_DIRS is set on your system:

$ echo 'export XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"' | sudo tee /etc/profile.d/xdg-data-dirs-for-gnucash.sh

The Issue was with configuration of pulseaudio-sink-always-suspended - https://unix.stackexchange.com/questions/114602/pulseaudio-sink-always-suspended

1 Like

Started getting issues with certificates and pacman after this update. Kernel 5.14
On every database sync, pacman errors with

error: failed retrieving file ‘community.db’ from mirrors.manjaro.org : SSL certificate problem: unable to get local issuer certificate
error: failed retrieving file ‘multilib.db’ from mirrors.manjaro.org : SSL certificate problem: unable to get local issuer certificate
error: failed retrieving file ‘core.db’ from mirrors.manjaro.org : SSL certificate problem: unable to get local issuer certificate
error: failed retrieving file ‘extra.db’ from mirrors.manjaro.org : SSL certificate problem: unable to get local issuer certificate
warning: too many errors from mirrors.manjaro.org, skipping for the remainder of this transaction

Then switch to a different mirror.

Thanks for the update! watchdog problem fixed!

Issue: pamac-gui has a big keyboard-delay when searching for packages

It is probably not a “keyboard delay”, I submitted a bug report last month Pamac windows unresponsive while searching when bandwidth saturated (#1097) · Issues · Applications / pamac · GitLab basically the interface hangs when it searches, and you can exacerbate this behavior when bandwidth is saturated.

Done, Thanks !

One thing i’m noticing since this update is that my HDDs are spinning up once in a while without using data on them. That didn’t happen before.
I can’t seem to figure out how to monitor which process is accessing these drives - iotop can’t be narrowed to just one disk, using lsof /mountpoint when i hear the disk spin up seems to be too slow - maybe someone has an idea on how to narrow it down? ^^

This is fixed now

1 Like

I remember you posting about it in an old testing update thread last month, and I forgot to ask you about it by the time it closed. In my own experience, I stopped those annoying “watchdog did not stop” messages and the occasional shutdown/reboot hang by blacklisting sp5100_tco and iTCO_wdt per the ArchWiki. Did you fix it yourself or did the update solve that for you?

No vhba-module for kernel 515. Is this an error or not? If so - where should i report it?

3 posts were split to a new topic: Can’t install package without signature with Pacman