This bugreport will collect all the bugreports need to achieve the qt5/kf5/plasma/kde apps Update
Keywords: (none) => TRACKERAssignee: bugsquad => kdeCC: (none) => marja11
Qt5 Stack update: https://bugs.mageia.org/show_bug.cgi?id=22657
Depends on: (none) => 22657
KF5 Stack Update: https://bugs.mageia.org/show_bug.cgi?id=22658
Depends on: (none) => 22658
Plasma 5 Stack Update: https://bugs.mageia.org/show_bug.cgi?id=22659
Depends on: (none) => 22659
Kde Application Stack Update: https://bugs.mageia.org/show_bug.cgi?id=22660
Depends on: (none) => 22660
Assignee: kde => qa-bugs
Depends on: (none) => 22662
Depends on: (none) => 22661
Depends on: (none) => 22669
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?
CC: (none) => lists.jjorge, mageiaStatus: NEW => ASSIGNED
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.
CC: (none) => andrewsfarm
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
CC: (none) => jim
Blocks: (none) => 22717
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.
Blocks: (none) => 22722
Depends on: (none) => 22732
tests seems fine, can we start to validate ?
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
on mga6-64 4.14.25-desktop on this system: Machine: Device: desktop System: Dell product: Precision Tower 3620 Mobo: Dell model: 09WH54 v: A00 UEFI [Legacy] CPU: Quad core Intel Core i7-6700 (-HT-MCP-) Graphics: Card: Intel HD Graphics 530 Display Server: Mageia X.org 119.5 drivers: v4l,intel Resolution: 1920x1080@60.00hz GLX Renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2) GLX Version: 3.0 Mesa 17.3.6 Selected all of the qt, kf, plasma and kapps updates proposed by rpmdrake 536 packages installed cleanly in a single transaction (I did not change the urpmi defaults) So far, looks good for mga6-64 on this system
Blocks: (none) => 19293
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.
Blocks: 19293 => (none)
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
Suggest doing these huge updates in a separate temporary repository next time to ease testing. eg. core/plasma_testing
(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.
Error with VPN L2TP configuration : mars 19 23:57:19 xxxxxx NetworkManager[1019]: <warn> [1521500239.1100] vpn-connection[0x10262d0,bc850780-a839-45fa-b229-083d79a3a4b4,"VPN XXX L2TP",0]: VPN connection: failed to connect: 'property 'ipsec-ike' invalid or not supported' I think openswan must be updated.
CC: (none) => sebastien.guerin.news
Blocks: (none) => 22797
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.
Test on M6/64 real hardware. Update takes a long time to proceed. But in the end no problem to report. Everything working perfect in my point of view. Great work!
CC: (none) => mailing-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.
Good to know.
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#c37 https://bugs.mageia.org/show_bug.cgi?id=22660#c40 https://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.
Wait for LxQT, neoclust is fixing it up
CC: (none) => tmb
Blocking sub-bugs so they dont get pushed yet
Depends on: 22657, 22658, 22659, 22660, 22661, 22669, 22732, 22662 => (none)Blocks: (none) => 22657, 22658, 22659, 22660, 22661, 22669, 22732, 22662
Thomas, should this bug be closed now, so the others can be pushed?
CC: (none) => davidwhodgins
The big update is now on mirrors...
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED