KDE 4.11.5 has recently been pushed to 4/core/updates. We would like to have as many feedbacks as possible from users in order to push it to 4/core/updates. It you please notice any regression with this update, signal it as quickly as possible. Thank you all for your help ! Reproducible: Steps to Reproduce:
Keywords: (none) => TriagedAssignee: bugsquad => mageiaCC: (none) => balcaen.john, lmenut
Created attachment 5119 [details] KDE 4.11.5 SRPMS
Created attachment 5120 [details] KDE 4.11.5 RPMS
DigiKam needed to be rebuilt because of this update too, so add these to the list: digikam-3.5.0-3.1.mga4 libkface-common-3.5.0-3.1.mga4 libkgeomap-common-3.5.0-3.1.mga4 showfoto-3.5.0-3.1.mga4 libdigikamdatabase3-3.5.0-3.1.mga4 libdigikamcore3-3.5.0-3.1.mga4 libkface2-3.5.0-3.1.mga4 libkgeomap1-3.5.0-3.1.mga4 libmediawiki1-3.5.0-3.1.mga4 libkipiplugins3-3.5.0-3.1.mga4 kipi-plugins-3.5.0-3.1.mga4 kipi-plugins-timeadjust-3.5.0-3.1.mga4 kipi-plugins-smug-3.5.0-3.1.mga4 kipi-plugins-shwup-3.5.0-3.1.mga4 kipi-plugins-piwigoexport-3.5.0-3.1.mga4 kipi-plugins-picasa-3.5.0-3.1.mga4 kipi-plugins-metadataedit-3.5.0-3.1.mga4 kipi-plugins-kopete-3.5.0-3.1.mga4 kipi-plugins-kioexportimport-3.5.0-3.1.mga4 kipi-plugins-jpeglossless-3.5.0-3.1.mga4 kipi-plugins-ipodexport-3.5.0-3.1.mga4 kipi-plugins-imageviewer-3.5.0-3.1.mga4 kipi-plugins-debianscreenshot-3.5.0-3.1.mga4 kipi-plugins-gpssync-3.5.0-3.1.mga4 kipi-plugins-flickr-3.5.0-3.1.mga4 kipi-plugins-expoblending-3.5.0-3.1.mga4 kipi-plugins-calendar-3.5.0-3.1.mga4 kipi-plugins-batchprocess-3.5.0-3.1.mga4 kipi-plugins-advancedslideshow-3.5.0-3.1.mga4 kipi-plugins-printimages-3.5.0-3.1.mga4 kipi-plugins-dngconverter-3.5.0-3.1.mga4 kipi-plugins-galleryexport-3.5.0-3.1.mga4 kipi-plugins-flashexport-3.5.0-3.1.mga4 kipi-plugins-facebook-3.5.0-3.1.mga4 kipi-plugins-acquireimages-3.5.0-3.1.mga4 kipi-plugins-rawconverter-3.5.0-3.1.mga4 kipi-plugins-removeredeyes-3.5.0-3.1.mga4 kipi-plugins-sendimages-3.5.0-3.1.mga4 kipi-plugins-kmlexport-3.5.0-3.1.mga4 kipi-plugins-yandexfotki-3.5.0-3.1.mga4 kipi-plugins-rajceexport-3.5.0-3.1.mga4 kipi-plugins-photolayouts-editor-3.5.0-3.1.mga4 kipi-plugins-panorama-3.5.0-3.1.mga4 kipi-plugins-imageshackexport-3.5.0-3.1.mga4 kipi-plugins-imgurexport-3.5.0-3.1.mga4 kipi-plugins-wikimedia-3.5.0-3.1.mga4 kipi-plugins-vkontakte-3.5.0-3.1.mga4 kipi-plugins-htmlexport-3.5.0-3.1.mga4 kipi-plugins-dlna-3.5.0-3.1.mga4 kipi-plugins-jalbumexport-3.5.0-3.1.mga4 libmediawiki-devel-3.5.0-3.1.mga4 libkface-devel-3.5.0-3.1.mga4 libkgeomap-devel-3.5.0-3.1.mga4 libdigikam-devel-3.5.0-3.1.mga4 from digikam-3.5.0-3.1.mga4.src.rpm
I tried to check as much as possible all the components. Ok for me on i586 setup. I'm running KDE 4.11.5 since near a month now.
Tested mga4_64, on a real hardware. Same for me, I'm running KDE 4.11.5 since near a month now and nothing to report at this time. No regression found too. I have found just one string who is not translate : When you install a new package, we can see on KDE Application menu the section: -Recently installed (in default language) This one on a French system must be "Récemment installés" but it isn't translate since 4.11.5 update.
CC: (none) => geiger.david68210
Well done David ! I checked on the KDE Translations website, it seems not to be an upstream bug. Did it appear when you upgraded or do you think it also existed before ?
Not before it was good, it appeared only after updating.
I don't find the .po file with correct translations on the KDE website, sorry David. How many feedbacks do we need do you think ? To my mind, 3 on i586 and 3 on x86_64 will be reasonable.
And I thought why KDE 4.11.5 is so long in updates/testing... Upgraded my KDE 4.11.4 to 4.11.5, running it here several days and do not see any regression. Mageia 4 i586 real hardware here. Is KDE 4.11.5 the last KDE SC update for Mageia 4 or are there any plans to bring eg KDE 4.13 to Mageia 4?
CC: (none) => jyri2000
KDE 4.11.5 will normaly be the last KDE version to land in mageia 4. Nicolas (neoclust) asked on a french forum that he could try to push KDE 4.12 or greater in backports or updates for instance. I have no news about that. It is an idea that will require many testers, and not from QA. Tested on another i586 setup. I added the ok for mga4-32 because, according to me, this is a stable release (bugfixes release). The only thing we can notice is a regression or a missing dependancy. Did somebody test Digikam on i586 ? I'd'like to have KDE packagers' feedback about it, please. Tests on x86_64 requiered. Then, next steps will be : - more tests on 64 bits hardware. - write the advisory (with some help from packagers) - contact QA team to validate the process - push to 4/core/updates Thank you for your help !
Whiteboard: (none) => mga4-32-ok
kde 4.12+ is in "pause" for now the time we fix backport policy.
Depends on: (none) => 13545
Depends on: (none) => 13559
Depends on: (none) => 13555
Blocks: (none) => 13545Depends on: 13545 => (none)
Blocks: (none) => 13555, 13559Depends on: 13555, 13559 => (none)Whiteboard: mga4-32-ok => (none)
Blocks: (none) => 12982
Blocks: (none) => 12612
Blocks: (none) => 13292
Blocks: (none) => 13275
Blocks: (none) => 13531
With 4.12.5, the only change I've noticed so far, is that the systray icons at least doubled in size. As per the message on the qa discuss mailing list, I don't really consider that to be a problem.
CC: (none) => davidwhodgins
Blocks: (none) => 13792
Blocks: (none) => 13933
(In reply to Dave Hodgins from comment #12) > With 4.12.5, the only change I've noticed so far, is that the systray > icons at least doubled in size. Happens with default KDE too in some cases, check https://wiki.mageia.org/en/Mageia_4_Errata#default_panel_icon_size_too_big Running fine here since more then 6 weeks as main desktop, no regressions. Even fixes two bugs introduced by last KDE security update, see https://bugs.mageia.org/show_bug.cgi?id=13555 and https://bugs.mageia.org/show_bug.cgi?id=13559 Asking on council ml about the status of this one.
CC: (none) => doktor5000
Summary: Update Candidate : KDE 4.11.5 (mga4) => Update Candidate : KDE 4.12.5 (mga4)
Blocks: 13933 => (none)
I get freezes very often with 4.12.5 desktop freeze itself to 5-10 second and nothing works mouse or anything else.
CC: (none) => ozkyster
Blocks: (none) => 13778
Blocks: (none) => 13300
(In reply to Otto Leipälä from comment #14) > I get freezes very often with 4.12.5 desktop freeze itself to 5-10 second > and nothing works mouse or anything else. please, could you open a separate bugreport for these freezes.
Created attachment 5429 [details] KDE 4.12.5 SRPMS
Attachment 5119 is obsolete: 0 => 1
Created attachment 5430 [details] KDE 4.12.5 i586 rpm
Attachment 5120 is obsolete: 0 => 1
Attachment 5430 description: KDE 4.12.5 i586.rpm => KDE 4.12.5 i586 rpm
Created attachment 5431 [details] KDE 4.12.5 x86_64 rpm
Done https://bugs.mageia.org/show_bug.cgi?id=14144
(In reply to Otto Leipälä from comment #19) > Done https://bugs.mageia.org/show_bug.cgi?id=14144 Thanks. From bug #14144#c3 this doesn't seem related to this update, but a kernel problem.
Created attachment 5473 [details] KDE 4.12.5 SRPMS (update)
Attachment 5429 is obsolete: 0 => 1
Created attachment 5474 [details] KDE 4.12.5 i586 rpm (update)
Attachment 5430 is obsolete: 0 => 1
Created attachment 5475 [details] KDE 4.12.5 x86_64 rpm (update)
Attachment 5431 is obsolete: 0 => 1
Blocks: (none) => 12751
Blocks: (none) => 13618
Blocks: (none) => 13728
Blocks: (none) => 12008
Sorry for the delay on this update. I'm going to write the advisory soon, but the QA team can already start the tests.
Assignee: mageia => qa-bugsCC: (none) => mageiaQA Contact: (none) => security
I will start testing this it will need lot of testing.
(In reply to Luc Menut from comment #20) > (In reply to Otto Leipälä from comment #19) > > Done https://bugs.mageia.org/show_bug.cgi?id=14144 > > Thanks. From bug #14144#c3 this doesn't seem related to this update, but a > kernel problem. Yes because i changed it against kernel from kde because i find out in my main install when i updated kernel that it's not kde bug it's kernel bug.
Testing on Mageia4-64 real H/W Installed KDE Version : 3:4.12.5-1.mga4 Installation OK after upgrading manually some libraries (eg lib64dolphinprivate4 Version : 1:4.12.5-1.1.mga4) I'll continue using it to see how it goes.
CC: (none) => olchal
The only safe way to test this update is to enable core/updates_testing as update media and let urpmi automatically update installed packages. If you don't want to update other packages than the KDE update (lists in comment #22 for i586, and comment #23 for x86_64), you can add unwanted packages to /etc/urpmi/skip.list or directly with --skip eg to skip kernel-desktop and cpupower urpmi --update --auto-update --skip=/kernel-desktop/,/cpupower/
Please don't install all packages from updates testing! Use MageiaUpdate to cherry pick the packages from the lists.
I'll have a look at Mga4 32 bit.
CC: (none) => cmrisolde
Well, looking at my list of packages, for the kipi-plugins ones it shows that I currently have 3.5.0.3 installed and the update candidates are 3.5.0.3.2, so I don't know what happened to 3.5.0.3.1.
(In reply to Carolyn Rowse from comment #31) > Well, looking at my list of packages, for the kipi-plugins ones it shows > that I currently have 3.5.0.3 installed and the update candidates are > 3.5.0.3.2, so I don't know what happened to 3.5.0.3.1. Most likely it was a first update that wasn't good enough for QA and a second update candidate has been pushed, removing the first one. You shouldn't wonder too much about it, what's important is to test the version listed in the SRPMs list.
CC: (none) => remi
But the ones listed in comment #3 are the 3.1 ones which I haven't got. I think the actual KDE ones are right, so I can test those.
Ah, wait a minute, I see the 3.2 ones are further down the list in comment #22, I thought the digikam ones were still listed separately. Sorry.
I'm not going to have time to test everything on that long list, and some things like bluedevil I can't test, but this is what I have managed to test on my 32-bit computer with no unexpected problems: General desktop use, including changing workspace behaviour, appearance of digital clock, screensaver, wallpaper, default desktop view, cursor theme Apps: Konsole Digikam Okular Dolphin Kwrite Kate KHangman Gwenview Palapeli KCharSelect KMahjongg KGeography KSnapshot
Tested few days and not found any bugs so far but still needs more testing.
I've been using the previous version of this update candidate for weeks, without noticing issues, and am now using the current update candidate, no issue seen for now.
CC: (none) => stormi
In VirtualBox, M4, KDE, 32-bit Package(s) under test: kde virtualbox-guest-additions default install of kde [root@localhost wilcal]# urpmi kdebase4-runtime Package kdebase4-runtime-4.11.4-2.mga4.i586 is already installed [root@localhost wilcal]# urpmi virtualbox-guest-additions Package virtualbox-guest-additions-4.3.16-1.mga4.i586 is already installed Testing packages Firefox24, KompoZer, FIleZilla, Konsole, Kwrite, Gimp, Audacity, VLC, OpenShot, Konversation, sysmon, Kino, Writer, Calc, guvcview, Volume, usbview, EasyTAG, K3b, Xsane, Htop, KSnapshot. Screen resolution: 1920x1200 All work fine. Allow system updates from updates_testing [root@localhost wilcal]# urpmi --auto-update Proceed with the installation of the 449 packages? (Y/n) Y reboot system [root@localhost wilcal]# urpmi kdebase4-runtime Package kdebase4-runtime-4.12.5-1.1.mga4.i586 is already installed [root@localhost wilcal]# urpmi virtualbox-guest-additions Package virtualbox-guest-additions-4.3.16-1.mga4.i586 is already installed The Vbox client system lost it's ability to go to 1920x1200. Max size is now 1600x1200. Do we need updates to virtualbox-guest-additions also? Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver virtualbox-4.3.10-1.1.mga4.x86_64 virtualbox-guest-additions-4.3.10-1.1.mga4.x86_64
CC: (none) => wilcal.int
The KDE update has nothing to do with virtualbox guest additions. It appears that you just blindly updated everything in updates_testing, so who knows what could have caused your issue.
Testing on Mageia 4 64-bits since a few days and I did not find (yet?) any bad behaviour in all the programs I tested.
CC: (none) => olivier.delaune
Updated my KDE 4.11.5 to 4.12.5 about 2 weeks ago and do not see any regression so far. Mageia 4 i586 real hardware here.
(In reply to David Walser from comment #39) > The KDE update has nothing to do with virtualbox guest additions. > > It appears that you just blindly updated everything in updates_testing, so > who knows what could have caused your issue. The how should we update only the relevent kde files? See comment #28. Same thing happens in 64-bit
(In reply to William Kenney from comment #42) > The how should we update only the relevent kde files? > See comment #28. > Same thing happens in 64-bit The same way you should install any update from updates_testing. Enable the testing media, run MageiaUpdate, unselect all, and then only select the packages relevant to the update that you're testing (yes it's a lot of clicks for this one). I'm pretty sure this is documented on the wiki somewhere.
(In reply to David Walser from comment #43) > The same way you should install any update from updates_testing. Enable the > testing media, run MageiaUpdate, unselect all, and then only select the > packages relevant to the update that you're testing (yes it's a lot of > clicks for this one). I'm pretty sure this is documented on the wiki > somewhere. Thanks, seems like hit and miss. I wish there was a better way to test this big app.
There is install mageia to vbox with lxde and install to it task-kde4 from updates testing.
I was intrigued to find *ruby* added to the KDE updates. Removing that would apparently have taken *Dolphin* with it! Is this for real?
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #46) > I was intrigued to find *ruby* added to the KDE updates. Removing that would > apparently have taken *Dolphin* with it! Is this for real? yep, servicemenuinstallation and servicemenudeinstallation are written in ruby head -1 /usr/bin/servicemenuinstallation /usr/bin/servicemenudeinstallation ==> /usr/bin/servicemenuinstallation <== #!/usr/bin/env ruby ==> /usr/bin/servicemenudeinstallation <== #!/usr/bin/env ruby
In VirtualBox, M4, KDE, 32-bit Default KDE4 package installed is task-kde4-minimal Package(s) under test: task-kde4-minimal & virtualbox-guest-additions default install of task-kde4-minimal & virtualbox-guest-additions [root@localhost wilcal]# urpmi task-kde4-minimal Package task-kde4-minimal-4.11.4-1.mga4.noarch is already installed [root@localhost wilcal]# urpmi virtualbox-guest-additions Package virtualbox-guest-additions-4.3.16-1.mga4.i586 is already installed Testing packages Firefox24, KompoZer, FIleZilla, Konsole, Kwrite, Gimp, Audacity, VLC, OpenShot, Konversation, sysmon, Kino, Writer, Calc, guvcview, Volume, usbview, EasyTAG, K3b, Xsane, Htop, KSnapshot. Screen resolution: 1920x1200 All work fine. Install task-kde4-minimal update from updates_testing Log out, log back in. Screen is now all white and unusable. Reboot system Screen remains all white and unusable. Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver virtualbox-4.3.10-1.1.mga4.x86_64 virtualbox-guest-additions-4.3.10-1.1.mga4.x86_64
On real hardware, M4, KDE, 32-bit Full up brand new, and updated, install from Mageia-4.1-i586-DVD.iso Default package installed is task-kde4-minimal Package(s) under test: task-kde4-minimal default install of task-kde4-minimal [root@localhost wilcal]# urpmi task-kde4-minimal Package task-kde4-minimal-4.11.4-1.mga4.noarch is already installed Testing packages Firefox24, KompoZer, FIleZilla, Konsole, Kwrite, Gimp, Audacity, VLC, OpenShot, Konversation, sysmon, Kino, Writer, Calc, guvcview, Volume, usbview, EasyTAG, K3b, Xsane, Htop, KSnapshot. Screen resolution: 1920x1200 All work fine. Install task-kde4-minimal update from updates_testing Log out, log back in. Screen is now all white and unusable. Reboot system Screen remains all white and unusable. In the white workspace I can Ctrl + Alt + Backspace back to the user login page, log in, and it still returns to an all white, unusable, workspace. Test platform: Intel, P4 530J 3.0 GHz, 800MHz FSB, 1MB L2, LGA 775 GigaByte GA-81915G Pro F4 i915G LGA 775 MoBo Marvel Yukon 88E8001 Gigabit LAN Intel High Def Audio, Azalia (C-Media 9880) (snd-hda-intel) Intel Graphics Media Accelerator 900 (Intel 82915G) Kingston 4GB (2 x 2GB) DDR400 PC-3200 250GB Seagate Kingwin KF-91-BK SATA Mobile Rack Kingwin KF-91-T-BK SATA Mobile Rack Tray Sony CD/DVD-RW DWQ120AB2
Bill, as with all updates, you need to manually select all the packages listed. You can find these in comment 22 or 23 depending on your arch. It is easiest to use MageiaUpdate to do this.
Dear all, I have a stange issue (I don't test before). If I lock the session with the button "lock", I arrive on a screen to unlock it or change the user. it's work, no problem. If I close the screen off the laptop, the laptop lock the session. When I open the screen, I arrive on same windows for unlock the session, but not possible to unlock, I have the message it not possible to unlock, message: "Not possible to unlock the session, the authentification system don't arrive to work!" . There is no password on the user. If you need, I have a movie!! Juste ask for the link. Stephane.
CC: (none) => megastorage
(In reply to William Kenney from comment #49) > On real hardware, M4, KDE, 32-bit > > Full up brand new, and updated, install from Mageia-4.1-i586-DVD.iso > > Default package installed is task-kde4-minimal > > Package(s) under test: > task-kde4-minimal > > default install of task-kde4-minimal > > [root@localhost wilcal]# urpmi task-kde4-minimal > Package task-kde4-minimal-4.11.4-1.mga4.noarch is already installed > > Testing packages Firefox24, KompoZer, FIleZilla, Konsole, Kwrite, > Gimp, Audacity, VLC, OpenShot, Konversation, sysmon, Kino, Writer, > Calc, guvcview, Volume, usbview, EasyTAG, K3b, Xsane, Htop, KSnapshot. > Screen resolution: 1920x1200 > All work fine. > > Install task-kde4-minimal update from updates_testing > Log out, log back in. > Screen is now all white and unusable. > Reboot system > Screen remains all white and unusable. > In the white workspace I can Ctrl + Alt + Backspace back > to the user login page, log in, and it still returns > to an all white, unusable, workspace. > > Test platform: > Intel, P4 530J 3.0 GHz, 800MHz FSB, 1MB L2, LGA 775 > GigaByte GA-81915G Pro F4 i915G LGA 775 MoBo > Marvel Yukon 88E8001 Gigabit LAN > Intel High Def Audio, Azalia (C-Media 9880) (snd-hda-intel) > Intel Graphics Media Accelerator 900 (Intel 82915G) > Kingston 4GB (2 x 2GB) DDR400 PC-3200 > 250GB Seagate > Kingwin KF-91-BK SATA Mobile Rack > Kingwin KF-91-T-BK SATA Mobile Rack Tray > Sony CD/DVD-RW DWQ120AB2 You are testing wrong packages again read this list to packags you need to test. https://bugs.mageia.org/attachment.cgi?id=5475 Gimp firefox etc.... those are not part of this kde update.
(In reply to stephane FLAVIGNY from comment #51) > Dear all, > > I have a stange issue (I don't test before). > > If I lock the session with the button "lock", I arrive on a screen to unlock > it or change the user. it's work, no problem. > > If I close the screen off the laptop, the laptop lock the session. When I > open the screen, I arrive on same windows for unlock the session, but not > possible to unlock, I have the message it not possible to unlock, message: > "Not possible to unlock the session, the authentification system don't > arrive to work!" . > > There is no password on the user. > If you need, I have a movie!! Juste ask for the link. > > > Stephane. You should use bugzilla search. https://bugs.mageia.org/show_bug.cgi?id=8520 https://bugs.mageia.org/show_bug.cgi?id=9229
Otto, can you be more specific to your answer to comment #51? First link is a closed old bug, second link is not the problème Stéphane reported. So what does your answer mean? Is there a regression and isn't there one?
Yes i can and you are right there is no regression at all.
Testing on a fresh install of Mageia4-64 in V-box with gnome-minimal and no KDE at all Installed : - task-kde4-minimal-4.12.5-1.mga4.noarch (which brought 486 other packages) Installation OK, kde4 desktop functionnal. The only complaint (which is the same with fresh install of - task-kde4-minimal-4.11.4-1.mga4.noarch), is that though automatic login was set, with gnome as the desktop, it rebooted directly in kde4. The automatic login was still set on gnome desktop though.
You should install task-kde4 too to get full kde,all packages what needs to testing are not in task-kde4-minimal.
Sorry, I was not thorough enough in comment 56. I am already testing and using full KDE 4-12-5-1 on H/W Mageai4-64 since 5th of october. Everything OK so far. That was further testing to see if install on a clean state in a virtualbox was functionnal as well. And it is.
(In reply to Otto Leipälä from comment #57) > You should install task-kde4 too to get full kde,all packages what needs to > testing are not in task-kde4-minimal. And if you do this, or use task-kde4-minimal, that will result in what I reported in Comments #38, #48 & #49, an unusable system. I have to share that I am not comfortable with the way this is being testing. I would not validate this update unless it would successfully updated using task-kde4-minimal at least. task-kde4-minimal is the default install and should work properly.
Is the lack of it working with task-kde4-minimal a regression?
(In reply to William Kenney from comment #59) > (In reply to Otto Leipälä from comment #57) > > > You should install task-kde4 too to get full kde,all packages what needs to > > testing are not in task-kde4-minimal. > > And if you do this, or use task-kde4-minimal, that will result in what > I reported in Comments #38, #48 & #49, an unusable system. I have to share > that I am not comfortable with the way this is being testing. I would > not validate this update unless it would successfully updated using > task-kde4-minimal at least. task-kde4-minimal is the default install > and should work properly. Yes because that package is already installed,you cannot update kde packages with urpmi task-kde4-minimal it's to install packages not to upgrade them. You can test task-kde4-minimal but with that this update cannot validated until all packages are tested,there is lot packages what need testing what are not required by task-kde4-minimal but are required by task-kde4 like kipi-plugins tons of plasma applets kate,etc.....
As Otto has suggested, I am under the impression as well that William's problems stem from not properly updating all relevant packages. That being said, testing it by starting with no KDE packages installed and then installing it should work to test it. Of course, starting with an existing KDE installation and updating is a better test, as that's how users will actually get the update installed (that and fresh installations with updates repositories enabled).
(In reply to David Walser from comment #62) > Of course, starting with an existing > KDE installation and updating is a better test, as that's how users will > actually get the update installed (that and fresh installations with updates > repositories enabled). And is that not exactly what I did in Comment 49. That was a brand new fresh on hardware install from the 4.1 Classic Installer, then updated. No other packages installed. Then run task-kde4-minimal with the updates_testing repo enabled. Is that not too much to ask?
(In reply to William Kenney from comment #63) > And is that not exactly what I did in Comment 49. That was a brand new > fresh on hardware install from the 4.1 Classic Installer, then updated. > No other packages installed. Then run task-kde4-minimal with the > updates_testing repo enabled. Is that not too much to ask? A brand new install that did or did not include any of the affected packages? If it did, you'll still need to use MageiaUpdate to make sure they get updated, just urpmi'ing task-kde4-minimal is not sufficient. However, if none of the affected packages were installed before you did that, then yes technically it should work, but I'm not 100% sure if that works as it is, which is why I asked if it does (Comment 60). If it's not a regression, it's not critical that we fix it although it would be nice. Knowing whether or not it is a regression would also help in fixing it.
This isn't an update we want to be rushing out so if there are issues we will need to consider them. Having said that, I just did a fresh vbox install from gnome livedvd i586 and updated/rebooted then installed task-kde4-minimal with updates testing enabled and set as update medium and it logs into a working kde desktop.
(In reply to claire robinson from comment #65) > Having said that, I just did a fresh vbox install from gnome livedvd i586 > and updated/rebooted then installed task-kde4-minimal with updates testing > enabled and set as update medium and it logs into a working kde desktop. That ain't fair. :-))
New bugfix to plasma workspaces 4.11.13 can luc build it to mageia 4 ?. https://www.kde.org/announcements/announce-4.14.2.php
I installed new vbox install with kde and then task-kde4 to get full kde and tons of plasma applets and kate and lot of packages needs still testing,then updated it to 4.12.5 to see how upgrade works from 4.11 and it went smooth no problems found.
(In reply to Otto Leipälä from comment #67) > New bugfix to plasma workspaces 4.11.13 can luc build it to mageia 4 ?. > https://www.kde.org/announcements/announce-4.14.2.php Sounds reasonable. Adding feedback marker for now.
Whiteboard: (none) => feedback
KDE Workspaces 4.11 is updated regularly. KDE Workspaces 4.11.14 is already planned for Tuesday, November 11 2014. Changes between 4.11.12 and 4.11.13 are quite minor. http://quickgit.kde.org/?p=kde-workspace.git&a=shortlog&h=f4f9c7a0ad19fb6ead3cc60eeb3fe02bdf38b002 I wouldn't delay this update too much just for kde-workspace 4.11.13; if updating kdebase4-workspace to 4.11.13 implies to restart all the tests from QA, I would prefer to stay with 4.11.12, otherwise we will never finish tests, and never push. Claire, WDYT?
The changes do indeed appear to be minor. I don't think that updating just that package would invalidate all testing that's been done, but still at some point we do have to settle at which version of that package to ship for this update. We could update it again later if we felt there was a compelling reason to. The only commit in 4.11.13 that looks like it might have some importance from a functionality perspective is Laurent Montel's commit "Fix order" (I'm not sure exactly what it is doing). The rest appears to be cosmetic. I think we can worry about updating it later and go with what we have for now.
Whiteboard: feedback => (none)
That's sound reasonable to delay it and push this update with 4.11.12 to get testing finish.
(In reply to Luc Menut from comment #70) > KDE Workspaces 4.11 is updated regularly. > KDE Workspaces 4.11.14 is already planned for Tuesday, November 11 2014. > > Changes between 4.11.12 and 4.11.13 are quite minor. > http://quickgit.kde.org/?p=kde-workspace. > git&a=shortlog&h=f4f9c7a0ad19fb6ead3cc60eeb3fe02bdf38b002 > > I wouldn't delay this update too much just for kde-workspace 4.11.13; if > updating kdebase4-workspace to 4.11.13 implies to restart all the tests from > QA, I would prefer to stay with 4.11.12, otherwise we will never finish > tests, and never push. > > Claire, WDYT? I agree Luc. Let's finish getting this tested and released as is. There will always be a newer version this or that. The bugfixes/enhancements seem relatively minor in the newer version anyway.
To aid the release of this behemoth... Just to note that after carefully installing all the updates for the KDE components I had from a Classic installation, and using KDE since: no problems.
Following my conversation with Dave H at the QA meeting, this is just to confirm that mine is shutting down OK again now, I don't know why it didn't the other day. Carolyn
I have now tested mageia 4 both arch with full kde task-kde4 and installed from rpmdrake tons of apps/packages like kate marble lot plasmoids kipi-plugins other packages can read from that list what i have tested,i tested too upgrade with full kde and it seems to be working ok. s://bugs.mageia.org/attachment.cgi?id=5475
Mageia 4 x86_64: installed the update candidate using MageiaUpdate over a clean LiveDVD KDE4 install. Everything works fine for now, I'll report back if I notice anything while using KDE and its software.
kde 4.12.5 on 586 ... it's ok for me cg radeon rv700 4Go magiea 4 but the bug N° : https://bugs.mageia.org/show_bug.cgi?id=12204 still not resolved
CC: (none) => marcounet
dolphin ok gwenview ok kipi ok digikam ok kwrite ok 3.14.22-desktop586-1.mga4 kde 4.12.5
hi, Dell Latitude D630. x86_64. Firefox, LO, Open Office, Digikam (APN EOS 500D well detected) > OK. Impossible to open Dolphin, in a console : [sam4@localhost ~]$ dolphin dolphin: symbol lookup error: /lib64/libkdeinit4_dolphin.so: undefined symbol: _ZNK13KItemLi
CC: (none) => lebarhon
(In reply to André DESMOTTES from comment #80) > hi, > Dell Latitude D630. x86_64. > Firefox, LO, Open Office, Digikam (APN EOS 500D well detected) > OK. > Impossible to open Dolphin, in a console : > > [sam4@localhost ~]$ dolphin > dolphin: symbol lookup error: /lib64/libkdeinit4_dolphin.so: undefined > symbol: _ZNK13KItemLi Besides the dolphin package, make sure these are also updated to 4.12.5 (put a 64 after the lib since you're on x86_64): libdolphinprivate4 libkactivities6 libkcmutils4 libkdecore5 libkdeui5 libkdewebkit5 libkdnssd4 libkfile4 libkio5 libknewstuff3_4 libkonq5 libkparts4 libnepomuk4 libnepomukcore4 libnepomukquery4 libnepomukutils4 libnepomukwidget4 libplasma3 libsolid4 libthreadweaver4
It was a MageiaUpdate problem. Now KDE 4.12.5 is working fine. I also updated KDE on a noname PC, mobo Gigabyte H81M, x86_64. Firefox, LO, Digikam (APN EOS 500D well detected): No problem found.
The update candidate is good enough to be pushed IMO (we might just want to make sure not to push it at the same time as the kernel update, and maybe wait for the dbus bug 14251 to be fixed?). @Luc: Could you write the advisory? (and also provide the list of SRPMS if it changed since comment 21).
Tested mga4_64, on a real hardware. I'm running KDE 4.12.5 since a few month now and nothing to report at this time. No regression found too.
(In reply to Rémi Verschelde from comment #83) > The update candidate is good enough to be pushed IMO (we might just want to > make sure not to push it at the same time as the kernel update, and maybe > wait for the dbus bug 14251 to be fixed?). > > @Luc: Could you write the advisory? (and also provide the list of SRPMS if > it changed since comment 21). Yes all should be pushed same time but it's delayed until release of beta1.
(In reply to Otto Leipälä from comment #85) > Yes all should be pushed same time but it's delayed until release of beta1. No, my point was precisely that we should have a delay between all those major updates to be able to bisect any issue that user might encounter.
Yes it was in irc meeting if i don't remember wrong. Testing updates - Any issues? (DavidWHodgins, 19:59:19) we won't validate kernels, vbox, kde updates whilst iso testing. Better to get a good look at them before we do. (MrsB, 20:03:43)
Hups i readed it wrong sorry remi my bad :(
Even after iso testing, kernel, dbus and kde updates shouldn't be pushed together probably, that was Remi's point. Best first do dbus as bugfix/regression update, and then kernel and kde. KDE has taken so long to push at all, so one more week probably won't hurt :p
I've been waiting (several months) for the KDE update to be pushed before upgrading my desktop at work from mga3 to mga4, so I'd like to still have some time to do that before we hit the mga3 EOL, ideally. As for the kernels, tmb will probably need to update them again before too much longer as there's new CVEs out already, but I have a host vbox issue on mga3 so those aren't ready to push just yet anyway. So if the KDE update is ready, maybe we should get it pushed in the upcoming week (after the dbus update of course).
(In reply to David Walser from comment #90) > So if the KDE update is ready, > maybe we should get it pushed in the upcoming week (after the dbus update of > course). Agree. I think we are making life more difficult than necessary by *not* pushing the KDE update ASAP (excepting the dbus thing?). It is well proven, and I see no gain in holding it up to follow other major updates like Kernel/VBox; nor any relevance to M5 Beta1 release. It is just cluttering the decks.
Yes David and Lewis is right we should just push it now and no any waiting anymore we have waited already too long this update.So somebody need to write advisory and i can validate it when all are ready to do it.
Lists for srpm, i586 rpm and x86_64 rpm from comments 21, 22 and 23 are up to date. Suggested advisory Updated KDE 4 and related packages move to KDE 4.12.5 This KDE 4 update provides an upgrade to the last stable version of KDE Applications and Development Platform for the 4.12 series, and updates Plasma Workspaces to 4.11.12. This update fixes several security vulnerabilities - KMail/KIO POP3 SSL MITM Flaw (CVE-2014-3494 - mga#13545) - KAuth PID Reuse Flaw (CVE-2014-5033 - mga#13792) - krfb: possible denial of service or code execution via integer overflow CVE-2014-4607 - mga#13933) - krfb: multiple security issues in libvncserver (mga#14205) (CVE-2014-6053, CVE-2014-6054, CVE-2014-6055) and additional issues - poxml is compiled without antlr (mga#12612) - crashes in bluedevil (mga#12751, mga#13618, mga#13728) - kdelibs file dialog isn't properly translated in pure Qt apps (mga#12982) - kate: self-closing xml tag breaks indentation (mga#13275, bko#330174) - krdc missing dependency on freerdp (mga#13292) - lock screen: can't start a new session after playing around with buttons (mga#13300, bko#331761) - kbreakout missing dependency on libkdegames-corebindings (mga#13531) - meinproc4 doesn't substitute entity with fixed libxml2 (mga#13555, mga#13559, bko#335001) - calligra-words missing dependency on soprano-plugin-redland (mga#12008) - digikam can't export to flickr (mga#13778, bko#336835) See the referenced buglists in KDE announcements for the complete list of fixes. References https://bugs.mageia.org/show_bug.cgi?id=13221 https://www.kde.org/announcements/4.12 https://www.kde.org/announcements/announce-4.12.1.php https://www.kde.org/announcements/announce-4.12.2.php https://www.kde.org/announcements/announce-4.12.3.php https://www.kde.org/announcements/announce-4.12.4.php https://www.kde.org/announcements/announce-4.12.5.php https://bugs.mageia.org/show_bug.cgi?id=13545 http://www.kde.org/info/security/advisory-20140618-1.txt http://lwn.net/Vulnerabilities/604032/ http://openwall.com/lists/oss-security/2014/06/18/16 https://bugs.mageia.org/show_bug.cgi?id=13792 http://www.kde.org/info/security/advisory-20140730-1.txt http://lwn.net/Vulnerabilities/607289/ http://openwall.com/lists/oss-security/2014/07/23/4 https://bugs.mageia.org/show_bug.cgi?id=13933 http://www.kde.org/info/security/advisory-20140803-1.txt http://lwn.net/Vulnerabilities/604237/ https://bugs.mageia.org/show_bug.cgi?id=14205 https://www.kde.org/info/security/advisory-20140923-1.txt http://lwn.net/Vulnerabilities/614039/ http://openwall.com/lists/oss-security/2014/09/23/6 http://www.ocert.org/advisories/ocert-2014-007.html https://bugs.mageia.org/show_bug.cgi?id=12612 https://bugs.mageia.org/show_bug.cgi?id=12751 https://bugs.mageia.org/show_bug.cgi?id=13618 https://bugs.mageia.org/show_bug.cgi?id=13728 https://bugs.mageia.org/show_bug.cgi?id=12982 https://bugs.mageia.org/show_bug.cgi?id=13275 https://bugs.kde.org/show_bug.cgi?id=330174 https://bugs.mageia.org/show_bug.cgi?id=13292 https://bugs.mageia.org/show_bug.cgi?id=13300 https://bugs.kde.org/show_bug.cgi?id=331761 https://bugs.mageia.org/show_bug.cgi?id=13531 https://bugs.mageia.org/show_bug.cgi?id=13555 https://bugs.mageia.org/show_bug.cgi?id=13559 https://bugs.kde.org/show_bug.cgi?id=335001 https://bugs.mageia.org/show_bug.cgi?id=12008 https://bugs.mageia.org/show_bug.cgi?id=13778 https://bugs.kde.org/show_bug.cgi?id=336835 @David: please, could you check this advisory, especially the security part, do I need to detail more? Do I need to add cve.mitre org references for CVE, or are they added automatically?
Whiteboard: (none) => MGA4-32-OK MGA4-64-OK
Thanks Luc! The advisory looks good. Yes, the CVE links are added automatically as long as the CVEs are correctly listed when the advisory is checked into SVN. For the references section, I don't generally use the LWN links as references, since those are just cataloging other distros' advisories; I use the advisory links directly. The oss-security links I use sometimes, but they're usually not needed when I have another distro advisory link. These are the references I'd use for the security bugs (middle set of links in Luc's list above): http://www.kde.org/info/security/advisory-20140618-1.txt https://lists.fedoraproject.org/pipermail/package-announce/2014-July/134961.html https://bugs.mageia.org/show_bug.cgi?id=13545 http://www.kde.org/info/security/advisory-20140730-1.txt https://lists.fedoraproject.org/pipermail/package-announce/2014-October/140293.html https://lists.fedoraproject.org/pipermail/package-announce/2014-September/137844.html https://bugs.mageia.org/show_bug.cgi?id=13792 http://www.kde.org/info/security/advisory-20140803-1.txt https://lists.fedoraproject.org/pipermail/package-announce/2014-August/136758.html https://bugs.mageia.org/show_bug.cgi?id=13933 https://www.kde.org/info/security/advisory-20140923-1.txt http://www.ocert.org/advisories/ocert-2014-007.html https://lists.fedoraproject.org/pipermail/package-announce/2014-September/139445.html https://bugs.mageia.org/show_bug.cgi?id=14205
CC: (none) => luigiwalser
I can validate this so it will wait only somebody upload advisory to svn.
Update validated sysadmins push this to updates when advisory uploaded to svn and all are ready to do this.:)
CC: (none) => sysadmin-bugsKeywords: (none) => validated_update
Unvalidating for now, we want the dbus update pushed first.
Keywords: validated_update => (none)Whiteboard: MGA4-32-OK MGA4-64-OK => MGA4-32-OK MGA4-64-OK
Advisory uploaded.
Whiteboard: MGA4-32-OK MGA4-64-OK => MGA4-32-OK MGA4-64-OK advisory
I think sysadmins will know to push first dbus update and then kde so you don't need to unvalidate it.
The updates are pushed by a script, so unless we specify that this one is blocked by the dbus update, the sysadmins probably won't be able to handle it easily if it's validated. And if an update is not ready to be pushed, then it's not ready to be validated :-)
So now we need to wait that dbus update is pushed and then validate kde again.:)
Dbus update is pushed to updates i revalidate this. Sysadmin push this to updates thx.
Keywords: (none) => validated_update
Component: RPM Packages => Security
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0432.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Blocks: (none) => 14416
Blocks: 14416 => (none)