I report it here, as I don't know if it is linked to kf5 or another update : Digikam does not show the images in the album view anymore after installing all KF5 updates.
So please rebuild it, or better push 5.8 version?

After installing each stack listed above, one at a time, in a vbox 64-bit guest, that guest appears to be running a stable Plasma 5.12.2.
Next step: Go back to the saved version of the above guest before all these updates, and try them all at once.

Installed all updates in a vbox guest in one operation. Even in this minimal install, over 400 packages! A pain in the neck to select only the pertinent packages in Updates Testing, but I persevered.
Afterward, the updated guest appeared to be stable, though I did not try to do much with it before retiring for the night.

on mga6-64 in a vbox VM
Installed all the (492) updates offered by rpmdrake, for QT5, KF5, plasma5 and kde-applications, in a single transaction. All installed cleanly. Re-booted and logged into plasma. All my settings appear to have been preserved. No regressions noted so far although I'm familiar with only a small number of the KDE applications.
For what I need, this looks OK for mga6-64

32-bit install on real hardware, Probook 6550b, i3 processor.
Installed all packages, including vlc, in one session, though not in one transaction. I did it in stages, 60-120 packages at a time, selecting from the list one at a time and OKing all dependencies as I went.
Update went smoothly, with a successful reboot. Everything looks good.
Unfortunately, I no longer have non-SSE2 hardware, so cannot test if Plasma will work on that.

on mga6-32 in a vbox VM 4.14.25-desktop
installed all of the QT5-KF5-plasma5-kapps packages offered by rpmdrake, in a single transaction
all 522 packages installed cleanly
re-booted into plasma5 normally
looks OK so far for mga6-32 in a vbox VM

i remove 19293 from blocker.
It was open "BEFORE" the new plasma update.
Do not forget that this update will not magically fix all bugs ( from mageiawelcome for example ).
We need here to see if there is regressions or not.
Please do not add blocker bugs here, for bugs open before our new updates and bug for producs not related to plasma.

Testing M6/64 real hardware with Radeon graphics,
using Plasma after re-starting X.
22657 Qt5 update: 54 pkgs at 5.9.4-1, 1 at 5.9.4-3
22658 KF5 update: 125 pkgs at 5.42.0-1, 4 at 5.42.0-2, 1 at 5.42.0-4
22659 Plasma update: 61 pkgs at 5.12.2-1
To do, 22660 KDE apps: 156 still at 16.12.3-1, 30 @ 3-2, 2 @ 3-3, 5 @ 3-5
I have by chance four 17.12.2-1 (i.e. updated) versions of these pkgs, okular & kamera, which curiously do *not* appear in the Plasma application menus. But they are there, and function.
I specifically tested these NON-updated KDE applications on this updated lower-level stack, and they all *seemed to function OK* with just a few glitches (which may have been there before). I started (& sometimes a bit more) *every* KDE application that I had in the menus. The main glitch was Kdenlive not starting; and I noticed that the first-use Kmail dialogue asking about importing from another e-mail client was greyed, inoperable

(In reply to claire robinson from comment #15)
> Suggest doing these huge updates in a separate temporary repository next
> time to ease testing. eg. core/plasma_testing
Wholeheartedly agree, Claire. The biggest problem for QA in this gigantic update seems to be determining what to select and what not to select from the testing repositories. A dedicated repository would help a LOT with that.
Perhaps one of the little-used repositories, like say one of the debug repositories could be commandeered temporarily. Make that two of them, a second one for any tainted packages that might be involved.
A secondary problem for QA is the apprehension of updating so many packages all at once. Unfortunately, this time attempting to break a complicated problem into several smaller, simpler problems only serves to make the overall problem even more complicated.

Tested M6/64 real hardware
At the end of the road, I can scarcely fault these updates. All KDE applications worked (started) not just under updated Plasma, but the 5 other main desktops. Only Konqueror misbehaved; and I can no longer raise kamera, still installed - see c14 above.
I should mention that of the 'extra' applications in c1 of the KDE update bug, Qupzilla browser still 'works' as it did before - still Mageia login problem. Most other extra applications are KDE ones tried along with the main lot; and 'phonon' is not in that bug RPMs list.

(In reply to Thomas Andrews from comment #16)
> (In reply to claire robinson from comment #15)
> > Suggest doing these huge updates in a separate temporary repository next
> > time to ease testing. eg. core/plasma_testing
>
> Wholeheartedly agree, Claire. The biggest problem for QA in this gigantic
> update seems to be determining what to select and what not to select from
> the testing repositories. A dedicated repository would help a LOT with that.
I selected all. No problem to report here.

(In reply to Jeff Trueg from comment #20)
>
> I selected all. No problem to report here.
That may have worked for you this time, but it's not generally a recommended procedure.
If something WERE to have gone wrong, it could be difficult to determine if the cause was the Plasma update, or, say, the kernel candidate packages that are currently in testing but apparently not yet ready for QA's attention.

Tested M8 x64 real hardware; tests under Plasma from SDDM.
All the updates-in-one-go.
I created a tailored base system for testing all these updates *in one go*: Qt5, KF5, Plasma, KDE applications; LXQt.
Started with the Plasma Live ISO which I updated normally (500 pkgs), to which I then added LXQt (+ LightDM), and as many other KDE applications as I could find & recognise. <3000 pkgs at the end; a bloated Qt5/Plasma/KDE system, a good test platform.
Enabled Updates Testing, and (due to earlier comments from Brian) with screenlock DISabled, did MCC->Update System (as will users), and accepted the entire pkg list offered. Note that this is a *superset* of the mass updates, of which:
- the greatest part comprise the updates in question.
- all pkgs will be at their latest version.
- any additional updates included are very unlikely to influence the outcome.
So I defend this approach - in the present situation - despite earlier objections.
646 pkgs. This 'total' update *went without a hitch* (including a kernel update), and after a precautionary re-boot, I am writing from Firefox under LXQt via LightDM - because it does not work from SDDM, see
https://bugs.mageia.org/show_bug.cgi?id=22669#c31)
I have yet to try all menu applications after this integral 'total' update; but we can be optimistic from my earlier tests:
https://bugs.mageia.org/show_bug.cgi?id=22660#c37https://bugs.mageia.org/show_bug.cgi?id=22660#c40https://bugs.mageia.org/show_bug.cgi?id=22656#c18
All feedback has said that if all the elements of this mass update are applied, *the result works*. We should think about pushing them.

Tested M6/64 real hardware
Further to the previous comment, I have found nothing to stop this update. I have started (sometimes a bit more) every application menu entry on this bloated KDE/Plasma + LXQt system. A few trivial application glitches noted under the KDE applications & LXQt bugs. I am writing this from Firefox on LXQt (ex LightDM); curiously, Qupzilla does not work reliably under LXQt, though it does under Plasma!

More M6 x64 tests, real hardware.
Repeated the *all-in-one* stack updates, starting with an up-to-date tailored 'fat' KDE/Plasma + LXQt system. Invoked Updates_Testing, this time I did:
# urpmi --auto-update |should I have added --auto ?]
Se c23 for justification.
691 packages, 648Mb, took 55m including 2 kernel updates, always loooong. I had DISabled SCREENLOCK in the base system. The update went without a hitch. >3000 installed packages at the end.
I re-booted for prudence, and the new kernel is now 4.14.32-desktop-1.mga6
Am writing from Qupzilla under Plasma from SDDM. Video & sound OK.
I will try a few tests, but only report further if they differ from c23, c24. This test is a serious one, and gives the thumbs-up to the whole stack of updates. For packagers to judge.

From what I can see, the only thing that would be stopping this bug from being validated is the status of Bug #22699, the LxQT update.
Please advise if this is accurate, or more importantly, inaccurate.
If the bug is OK to validate before the LxQT problem is resolved, I am perfectly willing to do so. However, I don't want to be premature, nor do I want to violate established procedures.