Impressive amount of work being done. 
1 Like
I am getting more and more tempted to do the insane and update my daily driver to Plasma 6 
But I am currently checking if my machine runs stable again (so far I diagnosed that the current BIOS version is not stable with my previous undervolting values - in addition I also had a faulty power supply that simply reset my machine in various load scenarios every other day) so I know it is an extremely bad idea to switch to development software xD But if my system proves that it is now stable again for another week, I might jump in ^^
There’s no guarantee that things will not break, though.
As a matter of fact:
On my setup after the latest update Dolphin doesn’t work: after clicking on its icon, it takes several minutes for Dolphin to show up - once it shows up opening a folder took very long as well.
Starting Dolphin from cli the same: first nothing happens, then Dolphin shows up, but takes a long time opening a folder.
Will monitor what’s going on, and try to get some logs.
Edit: Gwenview not working either at the moment.
OK, I took the plunge on a desktop.
Dolphin and Gwenview are working without any observable issue here.
For some reason the GUI on one monitor updates with ca. 30 fps only. Also kwin_wayland shows unusual(?) high CPU load (10% on one core).
But I’ll wait for the first beta before filing anything.
You’re a brave hearted soul.
Did
journalctl | grep dolphin
Nothing convincing found so far.
plasmashell[922]: QString::arg: 2 argument(s) missing in org.kde.dolphin
kwin_wayland[755]: QString::arg: 2 argument(s) missing in org.kde.dolphin
kconf_update[949]: kf.config.kconf_update: /usr/share/kconf_update/dolphin_detailsmodesettings.upd defined Version=5 but Version=6 was expected
On kde.bugs.org some Dolphin-bug-reports.
[1] is “close” to what I am seeing, but in my case the number of files in a directory doesn’t seem to play a role: even opening the “home” folder takes a long time (>30s I estimate). Once it has been opened, subsequent times it will open instantaneously. If I close Dolphin and restart it, then opening the home-folder takes a long time again.
Some more sleuthing is needed, me thinks.
Just fired up my trusty plasma5 setup; updated - and now, on Plasma 5, Dolphin as well as Gwenview are both showing the same behaviour as on Plasma 6.
So this behaviour may not be Plasma/Qt6 related. I now need to find out when either Dolphin or Gwenview, or packages they both are dependent upon, were last updated.
My gut feeling is that it’s connected to:
x-systemd.automount in fstab.
As this is possibly not Plasma 6 related, I won’t update on this issue in this topic for now.
Sorry for the confusion.
Edit: wouldn’t mind some help over at X-systemd.automount seems to give time outs when remote share is not online 
That makes sense…my dolphin is just fine (snappy as heck).
I umm fell into our Black Friday deal-mindset yesterday, new pc (as parts) on it’s way to me. My five year old desktop is getting a bit dated in regards to gaming. Should probably have it assembled (with luck and cursing) by mid next week (ie Dec 5-6). Then a fresh reload, maybe things will be better (though other than widgety behavior and ksplashqml, I haven’t had much issue).
As this Plasma 6/Qt6 setup is my daily driver I thought it was about time to do some maintenance[1].
Went swimmingly.
[1] A Complete Idiot's Guide To Endeavour OS Maintenance / Update / Upgrade
2 Likes
Reported a tiny bug[1] last week. People over at KDE are working to resolve it.
Yakuake icon in systray in colour when it should be black & white.
Edit: I find it remarkable that, as an end user, I can report bugs, then get notified about any process steps, have a look at the changes in the source code, then actually see the tester testing the change, and then get notified that the change is merged in “master”.
I know that this is what FOSS is all about, but to litterly see it in action is, I find, remarkable.
2 Likes
Nate Graham over at KDE asked for better logs or back trace, for the plasmashell crash.
He linked to a how-to[1] for creating better logs.
In short:
coredumpctl --reverse → PID
coredumpctl gdb [PID]
I added the resulting information to the bug report[2].
(I had to install gdb.)
[1] https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl
1 Like
Nice - I hope you get to play with it very soon 
For those interested:
[Edit: You can safely ignore this list. Please note @BS86’s comment below. ]
[1] KF6 Workboard: https://phabricator.kde.org/project/board/310/
[2] Plasma 6 issue board: https://invent.kde.org/plasma/plasma-desktop/-/boards
[3] Qt6/Plasma 6 bug list: https://bugs.kde.org/buglist.cgi?quicksearch=qt6&list_id=2531917
I’m no dev, so don’t really understand what I’m seeing, but it seems an impressive amount of work needs to be done to get everything ready for the official release.
2 Likes
many of the issues on the issue board are labelled enhancement, which means nice-to-have or quality of life changes, that are not bugs. Most of them can be moved to Plasma 6.1 or later releases.
The above is also partially true for the Workboard - but there a special low priority and backlog category exists for stuff that is not needed for the 6.0 release.
The bug list you posted is not a Plasma 6 bug list but a Qt6 bug list. While Plasma 6 uses Qt 6, it is definitely not necessary to fix all Qt6 bugs for Plasma 6. I am pretty sure that most of those bugs are not even triggered by Plasma 6, but by other applications that use Qt6.
Just today, Qt 6.6.1 was released fixing over 400 Qt bugs - that work was not done by the KDE developers but the Qt developers 
Theoretically, all the Qt bugs in the KDE bug tracker now have to be rechecked if they still occur with Qt 6.6.1
Thanks for the clarification.
I clearly have no idea what I’m doing or looking at - as my family will attest.
However, I’m glad you are (looking at), it drives others (including me) to take a gander.
I may not fix anything (probably not, I left ‘work’ behind me) but it’s still interesting and enlightening.
Tomorrow, November 29th, Beta 1 of Plasma 6 will be released.
From using Plasma 6 daily for some 2 weeks now, my impression is pretty positive.
For my use case I have not seen any situation that to me would be a real showstopper.
But I am a simple end user, doing some ordinary “household” stuff.
One of the things that I will test, once Plasma 6 Beta 1 is released, is editing the panel: moving it, make it float, change height, etc., because on my setup editing the panel leads to Plasma pre-Beta crashing almost every time. (Which is no big deal, by the way, because in a couple of seconds Plasma is back, right where things stood before the crash.)
I reported the crash day before yesterday, but at KDE they are not able to reproduce the crash.
If any one of you plans to test Plasma 6 and can confirm this crash, please head over to bugs.kde.org [1] and add your back traces, to help the dev’s triaging the crash.
If no one can conform this crash, then it’s just my setup and I’ll try to find out what’s wrong at my end.
https://bugs.kde.org/show_bug.cgi?id=477477
Edit: typo’s
3 Likes
A lot of that sort of issue (from my past experience) may be themes and other local customizations.
I hope it’s something simple like that (I’m assuming that if it is caused by theming, that it’s then something simple to resolve, but, frankly, I have no idea if that is true).
I don’t think I’ve done anything to the theme of my setup.
I’ll have a look later today.
Hey
just noticed that 29.11 is the first beta release date of plasma6, yayyyy
@SemLraug, I just read this thread, thank you for sharing your experience.
Before I get myself into the depths of compiling and setting up plasma 6, are the steps you posted at the beginning still correct?
From your experience, do you have any hints regarding installation, duplicates, conflicts of packages you think others (me) could use?
Best
Fabian