The password-gorilla package that I recently sponsored contains the following files: /usr/share/icons/hicolor/16x16/password-gorilla.png /usr/share/icons/hicolor/32x32/password-gorilla.png /usr/share/icons/hicolor/48x48/password-gorilla.png These are incorrect and will not show up in freedesktop menus because the directory is not listed in the index.theme file. Please check that icons in /usr/share/icons/hicolor are in one of the below directories. Also, when there is a package that contains an index.theme file, it would be good if lintian could validate the locations of images in the package against the Directories parameter in it. $ grep Directories /usr/share/icons/hicolor/index.theme | sed 's/[=,]/\n/g' 16x16/actions 16x16/animations 16x16/apps 16x16/categories 16x16/devices 16x16/emblems 16x16/emotes 16x16/filesystems 16x16/intl 16x16/mimetypes 16x16/places 16x16/status 16x16/stock/chart 16x16/stock/code 16x16/stock/data 16x16/stock/form 16x16/stock/image 16x16/stock/io 16x16/stock/media 16x16/stock/navigation 16x16/stock/net 16x16/stock/object 16x16/stock/table 16x16/stock/text 22x22/actions 22x22/animations 22x22/apps 22x22/categories 22x22/devices 22x22/emblems 22x22/emotes 22x22/filesystems 22x22/intl 22x22/mimetypes 22x22/places 22x22/status 22x22/stock/chart 22x22/stock/code 22x22/stock/data 22x22/stock/form 22x22/stock/image 22x22/stock/io 22x22/stock/media 22x22/stock/navigation 22x22/stock/net 22x22/stock/object 22x22/stock/table 22x22/stock/text 24x24/actions 24x24/animations 24x24/apps 24x24/categories 24x24/devices 24x24/emblems 24x24/emotes 24x24/filesystems 24x24/intl 24x24/mimetypes 24x24/places 24x24/status 24x24/stock/chart 24x24/stock/code 24x24/stock/data 24x24/stock/form 24x24/stock/image 24x24/stock/io 24x24/stock/media 24x24/stock/navigation 24x24/stock/net 24x24/stock/object 24x24/stock/table 24x24/stock/text 32x32/actions 32x32/animations 32x32/apps 32x32/categories 32x32/devices 32x32/emblems 32x32/emotes 32x32/filesystems 32x32/intl 32x32/mimetypes 32x32/places 32x32/status 32x32/stock/chart 32x32/stock/code 32x32/stock/data 32x32/stock/form 32x32/stock/image 32x32/stock/io 32x32/stock/media 32x32/stock/navigation 32x32/stock/net 32x32/stock/object 32x32/stock/table 32x32/stock/text 36x36/actions 36x36/animations 36x36/apps 36x36/categories 36x36/devices 36x36/emblems 36x36/emotes 36x36/filesystems 36x36/intl 36x36/mimetypes 36x36/places 36x36/status 36x36/stock/chart 36x36/stock/code 36x36/stock/data 36x36/stock/form 36x36/stock/image 36x36/stock/io 36x36/stock/media 36x36/stock/navigation 36x36/stock/net 36x36/stock/object 36x36/stock/table 36x36/stock/text 48x48/actions 48x48/animations 48x48/apps 48x48/categories 48x48/devices 48x48/emblems 48x48/emotes 48x48/filesystems 48x48/intl 48x48/mimetypes 48x48/places 48x48/status 48x48/stock/chart 48x48/stock/code 48x48/stock/data 48x48/stock/form 48x48/stock/image 48x48/stock/io 48x48/stock/media 48x48/stock/navigation 48x48/stock/net 48x48/stock/object 48x48/stock/table 48x48/stock/text 64x64/actions 64x64/animations 64x64/apps 64x64/categories 64x64/devices 64x64/emblems 64x64/emotes 64x64/filesystems 64x64/intl 64x64/mimetypes 64x64/places 64x64/status 64x64/stock/chart 64x64/stock/code 64x64/stock/data 64x64/stock/form 64x64/stock/image 64x64/stock/io 64x64/stock/media 64x64/stock/navigation 64x64/stock/net 64x64/stock/object 64x64/stock/table 64x64/stock/text 72x72/actions 72x72/animations 72x72/apps 72x72/categories 72x72/devices 72x72/emblems 72x72/emotes 72x72/filesystems 72x72/intl 72x72/mimetypes 72x72/places 72x72/status 72x72/stock/chart 72x72/stock/code 72x72/stock/data 72x72/stock/form 72x72/stock/image 72x72/stock/io 72x72/stock/media 72x72/stock/navigation 72x72/stock/net 72x72/stock/object 72x72/stock/table 72x72/stock/text 96x96/actions 96x96/animations 96x96/apps 96x96/categories 96x96/devices 96x96/emblems 96x96/emotes 96x96/filesystems 96x96/intl 96x96/mimetypes 96x96/places 96x96/status 96x96/stock/chart 96x96/stock/code 96x96/stock/data 96x96/stock/form 96x96/stock/image 96x96/stock/io 96x96/stock/media 96x96/stock/navigation 96x96/stock/net 96x96/stock/object 96x96/stock/table 96x96/stock/text 128x128/actions 128x128/animations 128x128/apps 128x128/categories 128x128/devices 128x128/emblems 128x128/emotes 128x128/filesystems 128x128/intl 128x128/mimetypes 128x128/places 128x128/status 128x128/stock/chart 128x128/stock/code 128x128/stock/data 128x128/stock/form 128x128/stock/image 128x128/stock/io 128x128/stock/media 128x128/stock/navigation 128x128/stock/net 128x128/stock/object 128x128/stock/table 128x128/stock/text 192x192/actions 192x192/animations 192x192/apps 192x192/categories 192x192/devices 192x192/emblems 192x192/emotes 192x192/filesystems 192x192/intl 192x192/mimetypes 192x192/places 192x192/status 192x192/stock/chart 192x192/stock/code 192x192/stock/data 192x192/stock/form 192x192/stock/image 192x192/stock/io 192x192/stock/media 192x192/stock/navigation 192x192/stock/net 192x192/stock/object 192x192/stock/table 192x192/stock/text scalable/actions scalable/animations scalable/apps scalable/categories scalable/devices scalable/emblems scalable/emotes scalable/filesystems scalable/intl scalable/mimetypes scalable/places scalable/status scalable/stock/chart scalable/stock/code scalable/stock/data scalable/stock/form scalable/stock/image scalable/stock/io scalable/stock/media scalable/stock/navigation scalable/stock/net scalable/stock/object scalable/stock/table scalable/stock/text
Paul Wise <pabs@debian.org> writes: [snipped tons of directories] This looks rather unmaintainable from a lintian perspective unless there's some (rarely-changing) standard that specifies those directories. If I'm reading the implications of your message correctly, that list could change arbitrarily with each release of the hicolor theme package. I don't see any clean way that we could maintain this. (Also, this only applies to desktop files that don't give a full path to the icon, no?) Hm, I guess. Parsing desktop files and trying to verify things in them is really hard due to the lack of standardization of desktop files, but this looks reasonably self-contained.
See the Context table at the top if this: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html The hicolor standard theme is specified in this: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html Yah, which is most of them since it gives the icon system theme-ability. On my system, 32 desktop files out of 321 use an absolute icon path. IMO the ones that do are buggy since users cannot override the icons. Ones that use an extension like .png, .svg or .xpm in the Icon field are also buggy because users may want to provide their own versions in a different format. Isn't this the standard for desktop files? http://standards.freedesktop.org/desktop-entry-spec/latest/ I'd also like to see a lintian info/warning when a menu file is installed in the package, but a .desktop file is not. The reason for this is that in that case, GNOME users will not have the application in their menu unless they turned the Debian menu on, since it is off by default.
Paul Wise <pabs@debian.org> writes: That only lists some of the subdirectories of your list (it's missing all the stock/* ones) and doesn't use the same names (international instead of intl, applications instead of apps). All of those seem like things that could change on us, no? I wonder if desktop-file-validate would understand all of this. It's on the list to look at whether we can replace the desktop checks in lintian with it. Interesting, thanks. It would be really good if some of this information could be written up from the perspective of a Debian package maintainer, since right now there's approximately zero information anywhere for how to deal with desktop files if one doesn't personally use Gnome or KDE and isn't familiar with this whole system. I tried to figure this out for gnubg and didn't have a lot of luck. I expect that a lot of the people (like me) who are doing that had no idea what else to do, or that it was even kosher to install files into the hicolor directory. There's a lot of Debian communication missing in this area, I think. lintian can help somewhat, but right now people are working in a void, and adding a few lintian checks probably wouldn't be nearly as useful as writing a comprehensive guide to how a Debian maintainer should tackle these issues. (And then lintian checks can reference the guide.) It claims to be, but it's actually the standard for Gnome desktop files. *wry grin*. As I discovered when writing lintian checks against that standard, KDE does something different and uses various fields that aren't listed there. Let alone GnuSTEP, which is even weirder. lintian is currently trying to check sort of a subset of that specification, only desktop files of a particular type, and with additional workarounds for KDE-specific stuff that can't be checked. The last time someone proposed this, it sparked a huge flamewar on debian-devel. I'm not sure I want to wade back into that. Apparently the GNOME maintainers disabled the Debian menu because they think it's largely worthless, and just blindly reintroducing .desktop files for every .menu file would restore the previous situation. Logically, if every .menu file should correspond to a .desktop file, the GNOME maintainers could just include the Debian menu. Since they don't, that indicates to me that some logic (not yet documented) should be applied by Debian maintainers to decide whether or not to include a desktop file.
Argh, I guess that is true. I'm wondering if it would be OK to build-depend on the hicolor theme and extract the list of directories at build time. Hmm, seems error-prone though and build-dep bloating. Alternatively you could have the theme installed and have a pre-release hook that generates the directories from the hicolor theme package and sticks them in the lintian source package. I think that only understands .desktop files, not this icon stuff. I definitely agree with this, unfortunately I have little time to spare on it. Perhaps the gtk/gnome & kde teams could contact upstream to help get such a guide, or maybe Ubuntu already has one Ugh. Right, I forgot about that flamewar. IMO, there should either be both, or none or just a .desktop file. The menu package should become a conduit from .desktop files to desktop systems that don't support the fdo specs. I don't think Debian will make progress on this for at least a release or two though.
Hello, Good morning, We have gone through your samples from a partner and Here is our Order List. Please do bear in mind that we are very much in need of this order, quote your competitive prices. Kindly send the Order confirmation. Your early reply will be much appreciated. Best Regards, Maryanah Erwin. PT FINDORA INTERNUSA Jln Pahlawan 66 Kec. Arjawinangun 45162 CIREBON West-Java INDONESIA tel : +62 231 357334 fax: +62 231 357260 email: marketing@findora.com