[Testing Update] 2021-04-16 - Kernels, Mesa, Wine, Plasma5, KDE Frameworks, LibreOffice, Bluez

This contains an update for protobuf, so compiz-easy-patch needs to be rebuilt against that.

Remember the Gnome Wifi dialog’s buttons do not work in the testing branch, but somebody said it only works in the unstable branch with full Gnome Shell 4.0.

Learned that the hard way - how could one exit the dialog actually? anything besides killing the DE?

After update (and even reboot), some icons were missing in my KDE Taskbars(after reboot: steam and telegram desktop) - switching to normal breeze icons and back to breeze dark seems to have solved that.

Else it seems fine on first glance :+1:

Finalizing wrapper for an already freed object of type: Gtk.ListBox (#163) · Issues · GNOME / Weather · GitLab this is the only problem i have had since the update. PrivacyTools Pastebin

5 posts were split to a new topic: Issues with Kvantum correctly applying themes to QT applications

Interestingly, compiz appears to be working normally after the protobuf update without a rebuild. Is this the case for you?

Everything worked smoothly. Thank you for such wonderful free operating system. Greetings from Poland, linux noob here.

2 Likes

I now updated one of my machines and unbelievably compiz really doesn’t seem to need a rebuild against this new version of protobuf, I think this is a first ^^

1 Like

i do not understand why Stable kernels create new version one day after …
https://www.kernel.org/

it is possible to update kernels version ?

has anyone tried testing on gnome?
the administrator access problem still remains?

It’s fixed with gvfs 1.48.0+13+gc615cfe1-1 available in the testing branch, yes.

1 Like

My update… failed :frowning:
Usually I have no issues but this time I was greeted by the info in terminal (rough translation):

Error: failed to commit transaction (unexpected error)
There was an error, no package was updated.

My guess is, there were some server connection issues. I’ll try again.

EDIT: The second attempt was successful. Probably linux-firmware failed to download correctly, because it lasted too long and with many server errors.

The only thing that I may mark as failure was this info:

==> Checking for 'os-prober' setup ...
    'os-prober' is disabled by default on this system.
    Your system won't detect other Operating Systems.
    For enabling it, uncomment the following in '/etc/default/grub':
    #GRUB_DISABLE_OS_PROBER=false

In my config, this line is already not hashed and yet the check showed as it was, so it failed at its job and showed me incorrect message " ‘os-prober’ is disabled by default on this system" when os-prober is in fact enabled.

A post was merged into an existing topic: Issues with Kvantum correctly applying themes to QT applications

The line in /etc/default/grub should be “GRUB_DISABLE_OS_PROBER=false” or just “#” in the begining of the line.
You should do a “sudo update-grub” in terminal.

The OS Prober message is expected, this is not a failure of any sort. It warns you that OS Prober is disabled in your Grub config file so it won’t detect other OS. Show you Grub config file maybe you overlooked something.

@servimo && @omano: If I understood @michaldybczak’s post correctly they are reporting a mis-detection of the current config state on their machine and subsequently a wrong (not fitting) message.

1 Like

I understood, hence the need to see his Grub config file, when I update Grub with the configuration he says he has, it works as intended.

Generating grub configuration file ...
Found theme: /boot/grub/themes/pacbang/theme.txt
Found linux image: /boot/vmlinuz-5.10-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.10-x86_64.img
Found initrd fallback image: /boot/initramfs-5.10-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
It's output will be used to detect bootable binaries on them and create new boot entries.
Found Windows Boot Manager on /dev/sdc1@/efi/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

(And I just noticed a typo in the message, it should be “Its” and not “It’s”)

1 Like

Exactly. My os-prober was disabled with that fatal update some time ago (a month or two ago?) but I fixed it with the recommended command, which added a proper line in config and updated it. Since then, os-prober is working fine, Win10 is detected.

The message in the current update erroneously claims that os-prober is disabled, which is not and claims that I should uncomment line that is already uncommented. As far I understand, the script in the update simply failed its task as it fed me with an incorrect message.

So basically, I didn’t have to do anything but the update suggested otherwise.

2 Likes

The check isn’t fit to work with multiple occurences of the word GRUB_DISABLE_OS_PROBER in /etc/default/grub - that might be the case with @michaldybczak’s file.

2 Likes