Bug 205034 - Menu entry/icon, kernel config, rpath and other fixes
Menu entry/icon, kernel config, rpath and other fixes
Product: Fedora
Classification: Fedora
Component: smart (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
: Patch
Depends On:
  Show dependency treegraph
Reported: 2006-09-02 16:08 EDT by Ville Skyttä
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.42-40
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-25 16:08:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix ksmarttray icon path (382 bytes, patch)
2006-09-02 16:08 EDT, Ville Skyttä
no flags Details | Diff
Various fixes (4.23 KB, patch)
2006-11-25 09:27 EST, Ville Skyttä
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2006-09-02 16:08:35 EDT
ksmarttray's menu entry has appeared in the latest package revision, good. 
However, icon for the menu entry is missing -- or actually installed into a path
where it won't end up in the menu entry.

"mv /usr/share/apps/ksmarttray/icons/hicolor/48x48/apps/ksmarttray.png
/usr/share/icons/hicolor/48x48/apps/" fixes it and doesn't break anything.

Enrico's old smart package had a fix for this too, attached (not tested whether
it still applies).
Comment 1 Ville Skyttä 2006-09-02 16:08:35 EDT
Created attachment 135433 [details]
Fix ksmarttray icon path
Comment 2 Axel Thimm 2006-09-11 14:45:22 EDT
Where under gnome does the menu entry appear? Or does it only appear under KDE?
Comment 3 Ville Skyttä 2006-09-11 15:30:41 EDT
I don't have a GNOME setup handy, but in my FC5 KDE it's in the top-level
"System" menu, same place as smart-gui.
Comment 4 Ville Skyttä 2006-11-25 09:27:23 EST
Created attachment 142112 [details]
Various fixes

Ping?  Here's a new patch containing a cleaner fix for the ksmarttray menu
icon, as well as a bunch of other things:

* Sat Nov 25 2006 Ville Skyttä <ville.skytta at iki.fi>
- Flag -xen and -PAE kernels as multi-version.
- Update desktop entry categories and icon installation paths.
- Avoid lib64 RPATHs in ksmarttray, fix menu icon.
- Build with dependency tracking disabled and SMP make flags.
- Source Qt config during build.

Sourcing the Qt config fixes a problem with local builds in the usual sequence
of rpmbuild smart -> no qt-devel installed -> install qt-devel -> rpmbuild
smart -> fails because the QT* environment variables are not yet available in
this shell.

rpmlint isn't happy with the PAM config - perhaps look into syncing it with for
example pup?  Dunno how old distro versions would support this:
auth		include 	config-util
account 	include 	config-util
session 	include 	config-util
Comment 5 Axel Thimm 2006-11-25 10:32:49 EST
Thanks! BTW what about --vendor fedora? Shouldn't it become --vendor=""?
Comment 6 Axel Thimm 2006-11-25 10:34:56 EST
pam `include' breaks on FC <= 4 and EL <= 4. Perhaps I could add a %bcond macro.
Comment 7 Ville Skyttä 2006-11-25 10:39:34 EST
(In reply to comment #5)
> BTW what about --vendor fedora? Shouldn't it become --vendor=""?

Nope, the most important rule of using --vendor is that it does not change
(well, to be more exact, the filename does not change) between package revisions
(even if it would change upstream), because menu editing cannot currently cope
with that and the result is borkage for people's local menu customizations/panel
additions etc.  http://fedoraproject.org/wiki/Packaging/Guidelines#desktop

(In reply to comment #6)
> pam `include' breaks on FC <= 4 and EL <= 4. Perhaps I could add a %bcond
> macro.

%bcond_* will break on EL too ;)

Comment 8 Ville Skyttä 2006-11-25 10:43:03 EST
By the way, I don't know if there's actually anything really wrong with the PAM
config per se, I just reported rpmlint's findings.

If you wish to change things, I guess one way of conditionalizing would be to
BuildRequire pam (if not pulled in by the current dep chain) and then check in
%install if /etc/pam.d/config-util exists - if yes, ship the "include
config-util" version, if not, ship something else, eg. the current one.
Comment 9 Ville Skyttä 2006-11-25 14:55:45 EST
Ouch, I see the desktop filenames have changed in the packages currently being
pushed after all :( (see comment 7)
Comment 10 Axel Thimm 2006-11-25 16:08:02 EST
Yes, I had done the change when I posted the comment about it, but even after
reading through the rationale on keeping even incorrect --vendor settings I
prefer to "fix/break" it for two reasons: 1) I and I guess many others usually
cut & paste from their specfiles and thus buglets get carried on and 2) in an
upcoming EPEL co-world it would look twice as wrong to have fedora-vendors.

Anyway I hope that's not that harmful, if a customized menu misses an item the
user often uses, he will dnd it back into the menu. If the user doesn't even
notice it means it shouldn't be there.

Thanks for the patch, again, and let's hope 0.50 get properly released soon:
smart at the speed of apt (almost ... ;).
Comment 11 Ville Skyttä 2006-11-25 16:50:46 EST
Well, knowingly breaking existing desktop items this way is plain unacceptable
IMO, and directly against the most stressed point of the relevant section of the
packaging packaging guidelines.

If you think the guidelines are bad, please start a discussion for changing them
- seeing a packaging committee member knowingly act against them sets bad
examples for others.

In EPEL, "fedora" as a vendor might be suboptimal, that's right.  Maybe a
%desktop_vendor macro or something like it in the buildsys would make sense,
used like --vendor="%{?desktop_vendor}" and defined as "fedora" or "epel"
respectively (intentionally resulting in empty vendor string if it's not defined).
Comment 12 Axel Thimm 2006-11-25 17:40:15 EST
OK, you are right. As I said the change was done and underway and I just didn't
feel worth while to pull the handbrakes by pushing another package onto the queue.

I'll raise that on the list.
Comment 13 Axel Thimm 2006-11-27 15:08:51 EST
Looks like the patch removed the icon of smart (in FC5 at least). Any idea why?
Comment 14 Ville Skyttä 2006-11-27 15:40:35 EST
I have a dim memory of some (buggy) old distributions requiring the
"Application" category to be in .desktop entry files in order for them to show
up in menus; I don't remember exactly what distro versions or desktop
environments are affected.

If that's why, note that the Application category is non-standard, and there
have been versions of desktop-file-{install,validate} around in newer
distributions which have (rightfully) rejected to install a .desktop file
containing it, so you may want to make sure it's added only for distro versions
that require it (if that's why it's missing in them, obviously).
Comment 15 Axel Thimm 2006-11-27 16:12:09 EST
Well, it's about FC5, I haven't gone further back - FC5 doesn't count yet as
(buggy) and old :)

But adding Application didn't get it back anyway, so it's something else. :/

Note You need to log in before you can comment on or make changes to this bug.