This package provides a bug fix for mageia #1060 and kde #270414 Renaming a file using folderview was not working before, it should be fixed with this update Advisory: « This package provides a bug fix to mageia bug #1060 allowing to rename a file using folderview without error. »
CC: (none) => balcaen.johnBlocks: (none) => 1060
After looking at bug 1060, I tried right clicking on kwrite in the tools menu, and selecting Add to desktop. That failed. I then tried dragging it to the desktop, selecting copy here. That worked, and renaming the icon does not generate an error. I then rebooted to an install that doesn't have updates testing enabled. Right clicking on kwrite, selecting Add to desktop, adds a widget, which cannot be renamed. Dragging kwrite to the desktop did create an icon, and renaming it did create the error message. So while the error is fixed, being unable to right click and select add to desktop, for a menu item appears to be a regression.
CC: (none) => davidwhodgins
(In reply to comment #1) > After looking at bug 1060, I tried right clicking on kwrite in the > tools menu, and selecting Add to desktop. That failed. Just to be sure, the widgets are unlocked ? because it's working correctly here in my netbook on mageia 1
Validated on x86_64 OK Before installing kdebase4-4.6.5-1.1.mga1 I confirmed Bug 1060 by Adding a 'Folder View' plasmoid to my desktop. As described in 1060 any application icon copied from the menu to the folder view plasmoid would be named xxxx.desktop. On renaming the icon an error message would appear saying file not found. (Note: the icon is dropped into the plasmoid, not onto the desktop itself) I also confirmed that a menu item could be right clicked and added to the desktop. I then installed kdebase4-4.6.5-1.1.mga1 and verified that menu icons can be dragged to a Folder View plasmoid and renamed without causing an error message. I also confirmed that a menu item could be right clicked and added to the desktop successfully.
CC: (none) => derekjenn
(In reply to comment #2) > (In reply to comment #1) > > After looking at bug 1060, I tried right clicking on kwrite in the > > tools menu, and selecting Add to desktop. That failed. > Just to be sure, the widgets are unlocked ? > because it's working correctly here in my netbook on mageia 1 Yes. With widgets locked, the option to Add to desktop doesn't appear. I just created a new user, and as that user, after unlocking the widgets, add to desktop worked ok, so there's some other setting within my .kde4 that's causing that problem. As Derek has tested 64 bit, I'll go ahead and validate this update. Can someone from the sysadmin team push the srpm kdebase4-4.6.5-1.1.mga1.src.rpm from Core Updates Testing to Core Updates. Advisory: This bug fix update for mageia bug 1060 allows renaming a file using folderview without generating an error message.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
pushed to updates.
CC: (none) => boklm
closing.
Status: NEW => RESOLVEDResolution: (none) => FIXED
According to our script this update requires some links to resolve possible update problems associated with bug 2317. ---------------------------------------- Running checks for "kdebase4-runtime" using media "Core Release" and "Core Updates". ---------------------------------------- Mageia release 1 (Official) for i586 Latest version found in "Core Release" is kdebase4-runtime-4.6.3-2.mga1 Latest version found in "Core Updates" is kdebase4-runtime-4.6.5-1.1.mga1 ---------------------------------------- The following packages will require linking: libclucene0-0.9.21b-3.mga1 (Core Release) libiodbc2-3.52.7-2.mga1 (Core Release) virtuoso-opensource-6.1.2-1.mga1 (Core Release) Could sysadmin please link the above packages into Core Updates. Thankyou!
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Depends on: (none) => 2317
Hum virtuoso & his dependencies are installed by default on every kde installation so we should not have to link virtuoso & libiodbc, same for clucene.
i links then anyway but i agree with comment #8
Status: REOPENED => RESOLVEDCC: (none) => dmorganecResolution: (none) => FIXED
The requires have changed between versions from soprano-plugin-redland to soprano and the script uses --requires-recursive so those must be added somewhere in soprano I would imagine? In fact.. Running checks for "soprano" using media "Core Release" and "Core Updates". ---------------------------------------- Mageia release 1 (Official) for i586 Latest version found in "Core Release" is soprano-2.5.63-2.mga1 Latest version found in "Core Updates" is soprano-2.6.0-0.1.mga1 ---------------------------------------- The following packages will require linking: libiodbc2-3.52.7-2.mga1 (Core Release) libraptor1-1.4.21-2.mga1 (Core Release) virtuoso-opensource-6.1.2-1.mga1 (Core Release) ---------------------------------------- So this could come from the soprano update as new require. Looking at soprano on sophie, soprano-plugin-virtuoso was a suggest and is now a require. It appears libraptor1 will also need linking?
link of raptor done.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
(In reply to comment #8) > Hum virtuoso & his dependencies are installed by default on every kde > installation > so we should not have to link virtuoso & libiodbc, same for clucene. They are installed by default but are we sure they are actually present on the user's system? I agree that the risk is probably not big in this situation, but I feel unconfortable when we discard new dependencies because they are *usually* present. That's why I prefer that we always link packages that were not pulled by strong dependencies when those strong dependencies are added afterwards. If a situation occurs where the number of packages to link is big, and the risk not big, then discussing it is still possible, but in the general case, until bug #2317 is solved, let's link :)
CC: (none) => stormi
To get them removed would mean that the user *especially* break his installation by removing with a --nodeps soprano for exemple or directly virtuoso-opensource & libiodbc.
ok, so if I understand correctly, those were new dependencies to soprano, but were already requires to other KDE packages? Am I right if I say that soprano can be installed without the KDE packages that require e.g. virtuoso-opensource and as such could (also unlikely) need those new deps from Core Release upon update?
CC: boklm => (none)