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

Issue with gnucash, current file not opening at startup, no setting changes saved. It seems it has to do with its schema : many messages related to dconf entries when start in debug mode.
I reverted to previous version.

@philm: Thanks. I’ll see if the gdm and auto-rotate screen issues are fixed with the testing updates. :wink:

gnucash 4.8 works for me. 4.7 had configuration related bugs and was rapidly replaced by 4.8

I got 4.8 from the unstable channel

After update I got an issue audio output. When I don’t use audio channel (for example don’t use youtube) than linux audio system after few seconds disabling the channel and my audio speakers are starting to make an unpleasant background sound. When I again enable youtube watch than all ok.

Restart and shutdown entries in Gdm login screen work again after update. This Issue is fixed now.

This update has reintroduced the infamous AMDGPU crash-and-reset bug on my laptop. What made it interesting and frustrating is that it’s now reproducible almost every time I plug it in to AC power, and it has already made it to the point where Manjaro is unusable while plugged in. I’ve posted my observations and attempted workarounds so far in the linked thread. I haven’t applied the update on my desktop yet if it’s affected as well, since it also uses an AMD graphics card.

Edit/update: I narrowed down the cause of the crash-and-reset bugs to TLP, which was upgraded to 1.4.0 in this update. Downgrading it back to 1.3.1 stopped that annoying behavior for now.

Also, I’m happy to see the Manjaro project having their own penguin-like mascot; it’s pretty cute! Does it have a name, and is that mascot brand-new?

Ya, we launched it recently. Also in our Telegram Channel we added it as stickers.

3 Likes

At least my desktop (with Navi21) doesn’t show that behaviour, so maybe it’s just the APUs?

I’m not sure, to be honest, although some of the replies in the linked thread said they’re occurring in some Polaris GPUs as well, but they don’t specify exactly if they’re experiencing that on a laptop or desktop. For what it’s worth, my laptop has a Ryzen 7 3700 APU with RX Vega 10 (Picasso), while my desktop is running a dedicated RX 570 (Polaris) which never had those kinds of issues.

We might update our kernels by tomorrow. Some AMDGPU fixes are in queue …

3 Likes

Did you review and merge the tlp.conf.pacnew? There were a lot of changes. See pacman/Pacnew and Pacsave - ArchWiki

I already did, but even after I applied my old tlp.conf, the crashing still wouldn’t stop

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