[Stable Update] 2019-05-26 - Kernels, XFCE 4.14-pre1, Virtualbox, LibreOffice

When pacman gives messages about files already existing, it can be because those file belong to a package that you installed by some other method, not via pacman (or any gui or helper that works through pacman). Often the best way to get past such a block is to remove the files it mentioned, or uninstall the whole package they belong to (and install it again later via pacman).

This is only a hint. I can't tell you exactly how to fix it safely. You need to consider whether removing those files might indirectly cause any loss of personal data. Usually personal data files are not affected by removing packages, but you might need the package to successfully re-install to be able to access your data again. [I'm being paranoidly cautious. :slight_smile: ]

Well that won't happen as unstable has been on murmur-1.3.0rc1-3 since May 24th. :wink:

Feel free to switch branches to get it now, or wait until the next stable update.

Should be also available in testing by now.

pacman -R kholidays
checking dependencies…
error: can't prepare transaction (can't resolve dependencies)
:: plasma-workspace: removing kholidays breaks dependency 'kholidays'

Edit:
I copied the error message to Kate and changed it like this (for every line, using replace Ctrl+R):

#!/bin/sh
rm -rf /usr/share/locale/hi/LC_MESSAGES/libkholidays5_qt.qm
rm -rf /usr/share/locale/hne/LC_MESSAGES/libkholidays5_qt.qm

And executed this script. And after that update went without errors. And also my problems with this calendar bug that I linked earlier is solved.

The latest build of Firefox has GPU web rendering capability to offload rendering of pages from the CPU to the GPU. If you want to try it take into account the feature is not finalised for Linux so is still disabled and hidden by default. You can turn it on using a config flag though.

To turn on WebRender, go to about:config, enable the gfx.webrender.all pref (set to true instead of false), and restart the browser.

Note: doing so may cause pages to render incorrectly, your browser to crash, or other problems. Proceed with caution!

It should work with an Intel Core processor integrated GPU plus all modern NVIDIA and AMD GPU. The Intel GPU functionality is restricted to below 4K resolution though.

3 Likes

Well, sorry for not using murmur?

There is some testings involved. The point of Testing (and Unstable) is to see if incoming updates goes well or not and (when it is possible) fix issues before it goes on Stable. Volunteers on Testing and Unstable receives updates, upgrade their system as usual, and report issues they find if there is any issue on their systems, on their hardware+software configuration. And it does help, because Manjaro was close to publish in Stable a pretty broken version of a package, but because it just happened that one guy used that package and saw how f- up it was, we could fixed the issue before it goes on Stable.

But what happen if no one, absolutely no one in Testing/Unstable use that package in their daily use? Well, no one see if there is regressions or not. Therefore, the more people with different hardware+software configuration goes on development branches, the more software we can cover.

If you think we (people in Testing and Unstable, which would maybe nearly 100 people at best active on this forum if I check the pools in announcements) can cover all single combination of hardware+software on a distro that has like more than 10 000 packages, even the most obscure ones, you might have to revise your expectations a little bit honestly.

The question is if the fixed from Arch Linux got published before or after May 22nd, 2019, because the last big update set we got in Testing that updated packages imported from Arch Linux was published in May 22nd, 2019; if the fix was introduced in, let's say, May 23rd, 2019, well it appeared one day too late to be on Testing at that moment.

According to this ticket, it was fixed in May 23rd, 2019, therefore one day too late compared to the last big update set in Testing. That's why it wasn't introduced in Stable even if it was fixed before Stable received a big update release.

https://bugs.archlinux.org/task/62715

According to the logs, it is a rebuild against grpc 1.21. Only the pkgrel got bumped, with no changes in the build file.
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/murmur&id=2c0d912f8373988c093e948c6ebb00186d73a272

Also, "I'm curious how a broken package managed to get into Arch Linux Stable, I thought there was testing involved?"

7 Likes

Yeah, I was getting the same error. Nothing worked for me and had to disable indexing altogether using balooctl disable. Obviously not a solution, but I wasn't using KDE file search that often.

Another perfect update in KDE Stable. Thank you Manjaro Team!

Tested in Virtualbox upgrading a fresh install with the same results.

@shoozi If you use indexing, is it working properly for you?

XFCE still doesn't remember display configuration after reboot.
It's always set to mirror all displays after reboot.
I have to set expanded desktop everytime again.

@micsim35
I tried it. It works fine for the most part, but some text becomes a bit fuzzy. I'll be leaving it off for now.
[i7 2600 + GTX1070 (Nvidia Driver)]

11 posts were split to a new topic: Murmur broken after Stable Update

XFCE, 4.19.45-1

Everything went smoothly! Thanks for all the hard work.

Updates as smooth as my baby's skin. Thanks to Manjaro--the leaders and everyone involved!

Love,
Tita Nova :kissing_heart:

how to check XFCE version in terminal?

$ man inxi

:wink:

9 posts were merged into an existing topic: Boot process halts, ACPI errors?

I just pushed the latest murmur package to stable branch. If you don't want to wait for your mirror to update you can install it directly with
sudo pacman -U http://manjaro.melbourneitmirror.net/unstable/community/x86_64/murmur-1.3.0rc1-4-x86_64.pkg.tar.xz
Please do let me know if it works like this or if we need to rebuild it against differing grpc versions per branch ... :roll_eyes:

3 Likes

Thank you for the hint. I found some tips on
[[SOLVED] Mount --bind in fstab]
so i added the following lines to my fstab:

/var/nosnap/var/cache		/var/cache	none bind	0 0
/var/nosnap/var/spool		/var/spool	none bind	0 0

then i did:

mount /var/spool
mount /var/cache

I hope this will work in the long run. Because some time after my first post "someone" deleted the soft-link for spool and replaced it by a new dir :sob:

Soft-links from non-system-dirs seem to work and stay stable :sunglasses:

No problem. I've been bitten by symlink issues so many times (it's a real developer headache to remember to check for symlinks in scripts) that I consider them unreliable.

However, configuring systemd (which is executing fstab these days) is also a pain when your bind mounts should depend on some other mount/service.

Forum kindly sponsored by Bytemark