[Testing Update] 2024-03-16 - Kernel, Calamares, Mesa, Plasma 6, KF 6, KDE Gear 24.04, LibreOffice

[zomberman]

I changed my branch from stable to testing for touching by hands on plasma 6.
I tested it so far in vm but never in real hw.
I’m surprised that it is usable, seems to be stable and the upgrade doesn’t brake things from how they were on plasma 5.
I experienced the first two points you listed: no more manjaro logo in the panel menu, I had the Papirus-Dark-Maia icon theme and now its different: many beautiful monochrome icons became different and colorful.
I didn’t see the floating panel, maybe 'cause I have the windows can cover option (or because I tried it before and went back to the non-floating option on plasma 5).

[Hanzel]

The part below seems relevant. the session fails for some reason. according to your profile you are on the stable branch, is this correct? Since this is a thread about the testing branch. This seems machine/config specific, split this off into a support request and supply machine info.

Summary

Mär 17 22:30:02 office /usr/lib/gdm-wayland-session[1168]: dbus-daemon[1168]: [session uid=120 pid=1168] Activating service name='org.a11y.Bus' requested by ':1.4' (uid=120 pid=1181 comm="/usr/bin/gnome-shell")

Mär 17 22:30:02 office /usr/lib/gdm-wayland-session[1168]: dbus-daemon[1168]: [session uid=120 pid=1168] Successfully activated service 'org.a11y.Bus'

Mär 17 22:30:02 office /usr/lib/gdm-wayland-session[1168]: dbus-daemon[1168]: [session uid=120 pid=1168] Activating service name='ca.desrt.dconf' requested by ':1.2' (uid=120 pid=1169 comm="/usr/lib/gnome-session-binary --autostart /usr/sha")

Mär 17 22:30:02 office /usr/lib/gdm-wayland-session[1168]: dbus-daemon[1168]: [session uid=120 pid=1168] Successfully activated service 'ca.desrt.dconf'

Mär 17 22:30:02 office gdm[1047]: Gdm: GdmDisplay: Session never registered, failing

Mär 17 22:30:02 office gdm[1047]: Gdm: Child process -1160 was already dead.

Mär 17 22:30:02 office gdm[1047]: Gdm: GdmDisplay: Session never registered, failing

Mär 17 22:30:02 office gdm[1047]: Gdm: Child process -1160 was already dead.

Mär 17 22:30:02 office systemd-logind[815]: New session 3 of user gdm.

Mär 17 22:30:02 office systemd[1]: Started Session 3 of User gdm.

[Yochanan]

@michaldybczak

Will [ … ] be somehow automated?

Automated how, exactly?

:

To be straightforward and blunt:

No.

[Consideration] Is Manjaro the right distribution for you?

Manjaro is NOT suitable for absolute beginners No, it’s not. And we — as the helpful community members of this forum — regularly have to explain this to the newcomers. Or at least, if we get the chance, because it is not exactly unheard of that a vocal newbie throws it out there themselves in a fit of frustration — if not arrogance or entitlement, because there’s a lot of that going round as well. So why is Manjaro not a distribution for absolute beginners? 1. Manjaro is a rolling-release d…

@michaldybczak

Can I …

I don’t know, can you? You are the master of your own PC. That’s the point. You make the decisions.

Having said that, if you have questions, feel free to create your own Support topic. Myself and helpful volunteers will be happy to continue the discussion.

[neovision]

I do and I noticed that, too.

I’m still trying to get to how it was before, i. e. the window having transparency and sticking to the desktop (so that I can get to it simply by clicking the “show desktop” symbol in the taskbar).

Right now, for me it’s either the former (own_window_type = ‘normal’,) or the latter (own_window_type = ‘desktop’,), while ‘dock’ comes with the annoyance you’re describing.

I haven’t found a solution yet.

[Frog]

@michaldybczak

@Frog

for some reasons, my display manager wanted to use Plasma on Wayland by default for some unknown reasons

This was announced many times very clear, that Plasma 6 defaults to Wayland. You may check out your configs and environmental variables. Some bugs on Nvidia probably happen, but for many, it works well.

Oh yeah, I just didn’t expect it to overwrite the DE and with which display service I wanted to use. That’s it. Maybe one day I’ll check out how to make Wayland work on NVIDIA now that it is (supposed to be) working properly on KDE nowadays instead of being more or less experimental.

@michaldybczak

1. What about those mkinitcpio changes on stable branch? Will this be somehow automated? Or maybe users of stable branch must do the same manual changes?

What manual changes? I don’t see anything to do aside from simply having to upgrade all your packages at the same time, which should not be a complicated thing to do since it’s what you do normally (and have to do usually too). Is there something I’m missing?

[meru]

Hi, I’ve updated my desktop to Plasma 6 (I’m on testing branch) and even though it is working well after all the nvidia workarounds for wayland, there are some visual issues I’m having that I haven’t seen people mentioning.

I tried re-applying Breath Dark completely but it didn’t solve the issue.

The borders on the start menu disappeared, the same goes for krunner, I can’t see what’s currently selected, clock is huge as well not sure if there’s a way to make it look smaller. Also, mouse cursor is not respecting night light.

I tried creating a brand new user but no luck, is there anything I can do that’s not a reinstall to fix this? Even the login screen doesn’t show any border on the input box, I’m hoping this is an easy fix.

I tried adding print screens here but looks like I’m not allowed to do this here, is there another way to upload images or something in a post?

Edit: Tried to also push images to imgur and link here but I get a 422 error so I guess it’s just because I’m a new user I can’t do that. Hopefully that will eventually be possible.

Another Edit : After a few hours now of use I noticed more things, example when I Alt+Tab there’s no indication of which window is selected with the exception of the X that shows up when it’s selected. Volume changing shows the percentage but the slider is gone, I can’t see in the bottom bar which app is the one currently open, it shows all icons but there’s no distinction between the in focus or not.

I tried even downloading some themes online to try to see if a completely different theme would fix that but no luck at all.

Final Edit: Managed to create a support post with the image I wanted to upload here: [Testing] Plasma 6 not showing selected menu entries

[Frog]

@Frog

Maybe one day I’ll check out how to make Wayland work on NVIDIA now that it is (supposed to be) working properly on KDE nowadays instead of being more or less experimental.

Well, that was much easier than I expected. It was just a matter of setting up a kernel parameter. Quoting the Arch Wiki:

To enable it, set the modeset=1 kernel module parameter for the nvidia_drm module.

If you are an NVIDIA user with the proprietary nvidia driver and wish to use the Wayland session, enable the DRM kernel mode setting.

Source: KDE - ArchWiki and NVIDIA - ArchWiki

It’s really easy to implement by adding this line in a configuration file in /etc/modprobe.d.

options nvidia_drm modeset=1

It could even be configured automatically by MHWD when it is creating the modprobe configuration file for proprietary NVIDIA drivers, unless it causes issues for other DEs…

…Or if they want to be so not-beginner-friendly-only-for-real-geekz and be so close to Arch Linux they want to offer an unusable KDE experience by default unless you think about changing your display server.

@Yochanan

To be straightforward and blunt:

No.

Manjaro is NOT suitable for absolute beginners No, it’s not. And we — as the helpful community members of this forum — regularly have to explain this to the newcomers. Or at least, if we get the chance, because it is not exactly unheard of that a vocal newbie throws it out there themselves in a fit of frustration — if not arrogance or entitlement, because there’s a lot of that going round as well. So why is Manjaro not a distribution for absolute beginners? 1. Manjaro is a rolling-release d…

Ok, enough trolling for today (I was just quite stunned to see something like this from the staff, although I haven’t read much of the forum for months outside diagonally reading announcements once in a while, I might have missed something big), I’m quite somehow unreasonably excited to finally be able to run my graphical interface with Wayland, or anything other than xorg.

So exciting!

[dva20]

After updates doesn’t mount my iphone

[MrLavender]

@michaldybczak

Some of them look obsolete, like qt5-wayland. What is the rule here? Can I remove them all, or maybe some of them? If so, how can I know which ones are to go?

qt5-wayland is a dependency of qt5-base which will still be required if you have any non-KDE applications installed that haven’t been updated to qt6. Same for many other qt5 packages. Just check dependencies, would you normally remove packages without doing that?

[freggel.doe]

@michaldybczak

2. Do we need to uninstall all qt5 packages?

I’ve tackled this as always when dealing with packages I think I don’t need: I set the install reason to “installed as dependency” and check/clean orphans afterwards.
They will go away when all depending packages have made the switch to their newer counterparts.

[bedna]

For consistency for a “basic manjaro user”, before plasma 6 moves to stable.

I have a laptop on testing, not changed much in form of theming other than the SDDM background and my desktop background.

After update to plasma 6 on this machine (and supposedly on lots of other manjaro installs as well) the icon on the application menu is now plasma logo, not manjaro.

It’s a tiny thing, but I point this out so it does not fall between the cracks.
And for consistency of manjaro, the icon should still be Manjaro.
Not sure this is possible to push through the update though but still wanted to point it out.

Fix is obv: just change the icon manually.

Also have to add a new profile in Konsole with the MesloLGS NF font to get the manjaro zsh theme to work properly.

Otherwise the update went through flawlessly.

Also, don’t forget to remind about pacnews.

[Mysak0CZ]

Yesterday I updated to Plasma 6.
Even before update I was using the Breeze dark theme, so I didn’t actually need to perform any changes at all to get a fully working system while I stayed on X11.

I also tried switching to Wayland, where I encountered some stuttering, especially during various animations (window movement, system tray menus open/close, Yakuake open/close).
For me it helped to go into “Display Configuration” and set “Adaptive sync” to “Never” - that seems to have resolved any such visual stutter as far as I can see.

[pheiduck]

@nikgnomic I added this line as its not enough to only install the package.

@philm

If Theme shows wrong colors:

cd $HOME; ln -s .profile .xprofile

[michaldybczak]

@Frog

Maybe one day I’ll check out how to make Wayland work on NVIDIA now that it is (supposed to be) working properly on KDE nowadays instead of being more or less experimental.

On one of my laptops, I have a hybrid setup with Nvidia GTX 970M (an old card) and I didn’t have to do anything, it just worked (although in the past it didn’t). However, the thing is, the desktop is run on Intel via modesetting driver, while Nvidia is on demand for games. This works flawlessly. I haven’t tried full Nvidia mode, because I see no benefits of running desktop through Nvidia. Additionally, the hybrid mode is created by optimus-manager. I could do pure MHWD hybrid from Manjaro, but then multimonitors wouldn’t work for me, no idea why. I tried to debug it or solve it but couldn’t figure it out. There is too little info about how Wayland and graphics on Wayland works and forum users were not overly helpful, because they didn’t know either. So I dropped the topic and returned to optimus-manager, which fixed the multimonitor support. However, even without optimus-manager, hybrid MHWD setup worked on Wayland automatically.

@Frog

What manual changes? I don’t see anything to do aside from simply having to upgrade all your packages at the same time, which should not be a complicated thing to do since it’s what you do normally (and have to do usually too). Is there something I’m missing?

Mkinitcpio hooks need to be changed manually. There is a chance that if you don’t do that, some fallback GRUB settings will be used and the system will still boot, but not for everyone. Basically, you need to add microcode hook in mkinitcpio and regenerate it. At least this is how it was explained in the announcement regarding unstable update. I did that and all works, no errors or warnings during the boot. The packages that need to be upgraded together were also important, but they come in update together, so nothing to do here.

@freggel.doe

I’ve tackled this as always when dealing with packages I think I don’t need: I set the install reason to “installed as dependency” and check/clean orphans afterwards.
They will go away when all depending packages have made the switch to their newer counterparts.

Wow, what a simple and brilliant idea :). I’ll do that. However, how do I mark packages as installed as dependencies? It’s easy to do the opposite, because there is a button in pamac that changes from “installed as dependency” to “installed directly”, but it doesn’t show any option when package is marked as installed directly.
Ah, nevermind, found it:

sudo pacman -D --asdeps package-name

[Frog]

@michaldybczak

Mkinitcpio hooks need to be changed manually. There is a chance that if you don’t do that, some fallback GRUB settings will be used and the system will still boot, but not for everyone. Basically, you need to add microcode hook in mkinitcpio and regenerate it. At least this is how it was explained in the announcement regarding unstable update. I did that and all works, no errors or warnings during the boot. The packages that need to be upgraded together were also important, but they come in update together, so nothing to do here.

Welp, yolo. I’ll wait for further, more obvious, direct and on point instructions I suppose, if there’s any to provide.

@Yochanan

The Microcode Arch wiki page was just updated yesterday and is still being improved based on recent upstream and Mkinitcpio changes.

EDIT: OK so, I read a bit in this thread [Unstable Update] March 2024 Edition and read the .pacnew file, and the article on microcodes on Arch Linux wiki (at the same time Yochanan posted it).

But is it really necessary? I don’t think it is a mandatory thing to do for most people and I don’t understand what the panic is about actually and why we are expecting the next unbootable armageddon suddenly. I mean for GRUB users, which is 99% of people on Manjaro will have anyway since it is provided with GRUB by default, the microcode updates are added automatically in the boot process independently of the initramfs and how it has been generated if you have the microcode packages installed on your system, at least according to Arch Wiki and assuming Manjaro’s implementation of GRUB follows the same rule:

-Microcode in a separate initramfs file

Early microcode updates must otherwise be enabled by adding /boot/amd-ucode.img or /boot/intel-ucode.img as the first initrd in the bootloader configuration file. This is before the normal initrd file. See below for instructions for common bootloaders.

In the following sections replace cpu_manufacturer with your CPU manufacturer, i.e. amd or intel.
-GRUB

grub-mkconfig will automatically detect the microcode update and configure GRUB appropriately. After installing the microcode package, regenerate the GRUB configuration to activate loading the microcode update by running:

# grub-mkconfig -o /boot/grub/grub.cfg

Alternatively, users that manage their GRUB configuration file manually can add /boot/cpu_manufacturer-ucode.img (or /cpu_manufacturer-ucode.img if /boot is a separate partition) as follows:

/boot/grub/grub.cfg

...
echo 'Loading initial ramdisk'
initrd	/boot/cpu_manufacturer-ucode.img /boot/initramfs-linux.img
...

Repeat it for each menu entry.

As far as I understand it, it only has to be done if one actually desires to add the microcode updates into the initramfs and doesn’t want to have to apply the microcode updates at the boot process separately in the initrd configuration, and doing it twice is pointless. For those specific uses, that would be extremely important to implement the change or else, the microcode updates won’t be applied anymore. But for everyone else? I would not even bother to touch /etc/mkinitcpio.conf in this instance.

[Yochanan]

The Microcode Arch wiki page was just updated yesterday and is still being improved based on recent upstream and Mkinitcpio changes.

[Frog]

Yup I just read that while editing my post, but after reading it, I have even more doubts that a manual intervention is actually necessary for most people and I don’t get why many people are making a big deal about it.

[bedna]

I found one more thing not working after update to plasma 6.

If you have any Dolphin context menues, they migh have dissapeared but are still visible in the settings of Dolphin.

Re download them from the Dophin settings > context menu > download new services (to download the version ported to plasma 6), in my case it was “open as root”.
Remove the old desktop file in ~/.local/share/kio/servicemenus/ and the menu works again.

[anon51566685]

@Frog

I have even more doubts that a manual intervention is actually necessary for most people

It’s necessary for ALL people (that use mkinitcpio at least) regardless of whatever you think. But you can do whatever you want of course.

[omano]

Are you able to untick this service menu from Dolphin setting in Context Menu, and can you confirm that unticking it removes the context menu? For me the whole service menu thing is broken I can’t configure service menus, ALL entries show up (example with Root Actions from AUR, or Meld Menu, all their entries show up in context menu when you right click inside a folder).

//EDIT: in the file /home/omano/.config/kservicemenurc I can see my configuration, where all the actions from my service menus are set to FALSE but they still show in Doplhin.