Description of problem: The "Graphics" category of KDE laucher (kickoff or menu) has the icon of "Multimedia" category. Version-Release number of selected component (if applicable): KDE SC 4.6.0 Mageia package version 4.6.0-2.mga1 How reproductible : Every time Steps to reproduce : 1. Click on Kickoff or launcher menu and go to graphics category Reproducible: Steps to Reproduce:
This is all very temporary, the artwork final design isn't integrated yet.
Keywords: (none) => TriagedAssignee: bugsquad => ennael1
still on beta 1
CC: (none) => magnus.mud
also a bug in LXDE launcher
this is not a bug, this is because we need to redo all icons but that need "time"
CC: (none) => dmorganec
Assignee: ennael1 => dmorganec
*** Bug 1545 has been marked as a duplicate of this bug. ***
CC: (none) => le.berred
It's also affecting Gnome menu (bug 1545)
CC: (none) => balcaen.john
Summary: The "Graphics" category of KDE launcher has a wrong icon => The "Graphics" category has the wrong icon in the MenuSource RPM: (none) => desktop-common-data
Why is there no movement on this? Surely it can't be too hard to simply switch out the icon at such a prominent place?
CC: (none) => eagle150
Assignee: dmorganec => mageia-artwork
(In reply to comment #7) > Why is there no movement on this? Surely it can't be too hard to simply switch > out the icon at such a prominent place? @ Bicycle RepairMan: Well, if you want to help you're very welcome :) Even easy things need some time to work on them, and when more urgent things take all time there is, the easy things might never get done. @ mageia-artwork: Any news on this issue?
CC: (none) => marja11
No news on this yet. Will try to motivate a team mate, to take care of it. Thorsten
CC: (none) => tvl83
@BicycleRepairMan: If it's so easy to create such an icon for you, why don't you join artwork?
CC: (none) => oliver.bgr
@ Assignee I think this bug was assigned correctly, but please confirm by putting "OK" on the whiteboard or by confirming in a comment
Priority: Normal => release_blocker
It looks like this is not an Artwork bug. In the KDE settings there is an appropriate icon called "applications-graphics" under System icons>Categories. I was easily able to set that as the icon on my own computer. Furthermore, the fact that this bug appears in GNOME as well leads to the conclusion that it is a configurations issue, not an artwork one. I'm adding the dev mailing list to the cc of this bug. Screencaps: imgur.com/fRFpz,gz3sD
CC: (none) => bogusman222Assignee: mageia-artwork => bugsquad
so please people in CC can you tell in what desktop it works. (cauldron)
In fact maybe it's more something bogus in the icon set
it seems, we have some strange icons in that package. Most of them seem to be from the oxygen icon theme, but somehow we didn't take /usr/share/icons/oxygen/32x32/categories/applications-graphics.png but /usr/share/icons/oxygen/32x32/categories/applications-multimedia.png.
CC: (none) => seadx6, sysadmin-bugsComponent: RPM Packages => Release (media or process)Target Milestone: --- => Mageia 2Source RPM: desktop-common-data => (none)Whiteboard: (none) => user, user's password and root's password can not been created or setSeverity: minor => critical
@ Esaú Why didn't you just write a comment if you wanted to say something about this bug. What you now did was trolling. @ dmorgan assigning to you, because Ahmad set the RPM field to desktop-common-data and you maintain that package. Please set status to ASSIGNED if you think this bug was assigned correctly. If for work flow reasons you can't do that, then please put OK on the whiteboard instead. Of course, in case the bug isn't in a package you maintain, please assing back
CC: sysadmin-bugs => (none)Component: Release (media or process) => RPM PackagesSource RPM: (none) => desktop-common-dataWhiteboard: user, user's password and root's password can not been created or set => (none)Severity: critical => minor
(In reply to comment #16) > > @ dmorgan > > assigning to you, because Ahmad set the RPM field to desktop-common-data and > you maintain that package. > > Please set status to ASSIGNED if you think this bug was assigned correctly. If > for work flow reasons you can't do that, then please put OK on the whiteboard > instead. > > Of course, in case the bug isn't in a package you maintain, please assing back again assigning
Assignee: bugsquad => dmorganec
General ping for Alpha 3
Whiteboard: (none) => QA
Should I fix it? Should be straight-forward. But it's not my package.
@Oliver: yes, I think you can go with it.
CC: (none) => mageia
Status: NEW => ASSIGNEDAssignee: dmorganec => oliver.bgr
Fixed on cauldron
This is also a problem for the categories icons in rpmdrake. The following categories have the same icons: archiving, public keys, sound, system, terminals ("gear" icon) communications, networking ("globe" icon) databases, development, editors, emulators, file tools, shells, text tools ("hammer and banner icon") Also most of the sub-categories share the same icon. Just take a look with a file manager which supports image preview in /usr/share/icons and you will see the problem easily. For example, the blue "globe" icon is duplicated there 20 times, always with a different name. If we do such stuff, we could easily use symlinks to save a bit of space.
CC: (none) => doktor5000
The icons described in the original report are fixed on Cauldron and 1. The rest has to wait a bit, but should not be forgotten.
Assignee: oliver.bgr => qa-bugs
(In reply to comment #22) > This is also a problem for the categories icons in rpmdrake. The following > categories have the same icons: In rpmdrake ? :D And you should open a separate bug iirc The fix works for me (x86_64) with Gnome and after an killall of gnome-panel (so there is no need to logout).
Oliver, although this is a trivial update could I please remind you of the updates policy about writing an advisory for QA: https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29 Thankyou :) Testing i586 this appears to be fixed in Gnome but not in KDE.
rpmdrake does display correctly but KDE menu is still a video icon
The volume icon in the notification area has also changed in KDE
(In reply to comment #24) > (In reply to comment #22) > > This is also a problem for the categories icons in rpmdrake. The following > > categories have the same icons: > > In rpmdrake ? :D > And you should open a separate bug iirc OK, will open a new one. Sorry for the noise.
I'm not sure if it is related but this was strange. After logging out of KDE and into gnome to test then back into KDE the volume icon had changed, in fact I think the whole task bar was slightly different. The process kded4 was taking 100% CPU. After rebooting, those problems have returned to normal but the icon in the menu is still the video icon.
Since I did nothing but replace a few pngs all other side effects must be from something else. @KDE: Same on Cauldron. I don't know, why, does KDE have some kind of icon cache? Mikala?
(In reply to comment #30) > Since I did nothing but replace a few pngs all other side effects must be from > something else. > > @KDE: Same on Cauldron. I don't know, why, does KDE have some kind of icon > cache? Yes. Logging out to run level 3, deleting and recreating ~/tmp fixes the kde icons. As updates generally are not supposed to alter anything in /home, I don't think this can be fixed in the update. I consisder testing complete on i586 for the srpm desktop-common-data-1-12.1.mga1.src.rpm
CC: (none) => davidwhodgins
Good find Dave! Oliver, are you still working on this or happy for it to be validated as it is?
I'd like first to have a confirmed way for the user to fix the icons in KDE's menu. I tried Dave's solution after thoroghly looking at the contents of ~/tmp/. It didn't work and after what I saw of the files in ~/tmp/ there is no reason it should work. I assume it's some file in .kde4/cache-HOSTNAME.oli-home/, after deleting the "icon-cache.kcache" file in there it was working. I just need someone to confirm that. Oliver
$ find -L .kde4 -iname "icon-cache*" .kde4/cache-linux.local/icon-cache.kcache .kde4/cache-localhost/icon-cache.kcache .kde4/cache-localhost.localdomain/icon-cache.kcache The three folders are all symlinks to /var/tmp/kdecache-<username>/ Deleting icon-cache.kcache has no immediate affect but after logging out and back in the Graphics icon is showing correctly in KDE menu, also the 'More' submenu in the Graphics category is corrected.
$ echo $HOSTNAME localhost
For reference, KDE should update the icon cache by itself, if it was invalidated correctly. Just have a look f.ex. at http://osdir.com/ml/kde-devel/2011-03/msg00045.html @Oliver: Maybe this needs to be added to the SPEC? And in the future we should have an RPM filetrigger for that?
(In reply to comment #36) > @Oliver: And in the future we should have an RPM filetrigger for that? Replying to self: Seems our current filetrigger should be responsible for such updates, but as the icons are located directly below /usr/share/icons, the trigger does not fire. Check output/content of relevant triggers (they are shared between GNOME/KDE) ls -l /var/lib/rpm/filetriggers/gtk-icon-cache* @Oliver: Don't know how to solve this properly, as it would be a bad idea to relocate some default icons in a released distro. Maybe drop a mail to -dev?
Assigning Oliver until this is ready for QA. Please reassign when you're done :)
Priority: release_blocker => NormalCC: (none) => qa-bugsVersion: Cauldron => 1Assignee: qa-bugs => oliver.bgrTarget Milestone: Mageia 2 => Mageia 1
Hardware: i586 => All
Blocks: (none) => 4300
Blocks: 4300 => (none)
(sorry for the noise don't know what happen :/)
Ok, let's get this done. The update does fix the issue for all dekstops but KDE. On KDE nothing breaks, but you won't just see any change due to KDE's icon cache. I think we should push it unless the KDE guys (at least mikala is in cc) do tell us something new. -- This update fixes the wrong icon being used for the graphics section in the menu and rpmdrake See Bug #107 ---
Did you add something to remove the icon-cache.kcache file after installation? If not then this won't be fixed for KDE.
No, since packages should not touch the users HOME. That's why I'm still hoping for mikala or some other KDE guy to respond...
(In reply to comment #42) > No, since packages should not touch the users HOME. That's why I'm still hoping > for mikala or some other KDE guy to respond... Please look again at comment#37, our filetriggers should be updated to handle this, you should either mail to-dev how to handle this or directly ask dmorgan and mikala for this, the relevant filetrigger comes from oxygen-icon-theme package. If i understood upstream documentation correctly touch /usr/share/icons/ should also be enough to trigger reindexing of the cache for KDE as a workaround, but that's untested.
Ping?
So if I understand correctly the thing to do would be to add touch /usr/share/icons/ to /var/lib/rpm/filetriggers/gtk-icon-cache-oxygen.script ?
CC: (none) => juan.baptiste
(In reply to comment #45) > So if I understand correctly the thing to do would be to add > > touch /usr/share/icons/ > > to /var/lib/rpm/filetriggers/gtk-icon-cache-oxygen.script ? I don't think so. IIUC, we probably suffer from this upstream bug http://bugs.kde.org/show_bug.cgi?id=251288
CC: (none) => lmenut
(resolved in cauldron)
Blocks: 4300 => (none)Whiteboard: QA => (none)
Is there an update for the file triggers coming to Mageia 1, that this bug should depend on?
Reassigning to bugsquad, since it's not in my scope to do anything here.
Assignee: oliver.bgr => bugsquad
(In reply to comment #46) > (In reply to comment #45) > > So if I understand correctly the thing to do would be to add > > > > touch /usr/share/icons/ > > > > to /var/lib/rpm/filetriggers/gtk-icon-cache-oxygen.script ? > > I don't think so. > > IIUC, we probably suffer from this upstream bug > http://bugs.kde.org/show_bug.cgi?id=251288 (In reply to comment #49) > Reassigning to bugsquad, since it's not in my scope to do anything here. I doubt upstream will solve this for an old version of KDE
Keywords: (none) => UPSTREAMStatus: ASSIGNED => NEWSee Also: (none) => http://bugs.kde.org/show_bug.cgi?id=251288
This message is a reminder that Mageia 1 is nearing its end of life. In approximately 25 days from now, Mageia will stop maintaining and issuing updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '1'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 1's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 1 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- Mageia Bugsquad
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => WONTFIX