Bug 107

This is all very temporary, the artwork final design isn't integrated yet.

Keywords: (none) => Triaged
Assignee: 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

*** 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

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

(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

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) => bogusman222
Assignee: 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.

@ 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 Packages
Source RPM: (none) => desktop-common-data
Whiteboard: 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

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 => Normal
CC: (none) => qa-bugs
Version: Cauldron => 1
Assignee: qa-bugs => oliver.bgr
Target Milestone: Mageia 2 => Mageia 1

(sorry for the noise don't know what happen :/)

Blocks: (none) => 4300

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) => UPSTREAM
Status: ASSIGNED => NEW
See 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 => RESOLVED
Resolution: (none) => WONTFIX