Bug 444855 - No menu entry after fresh install
No menu entry after fresh install
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kdebase-workspace (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-01 05:30 EDT by Alain Portal
Modified: 2008-05-02 10:43 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-02 07:18:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 154503 None None None Never

  None (edit)
Description Alain Portal 2008-05-01 05:30:42 EDT
Description of problem:

After a fresh install of firefox using yum, there is no menu entry for firefox


Version-Release number of selected component (if applicable):

firefox-3.0-0.59.beta5.fc9.x86_64

How reproducible:

Untested, but probably always

Steps to Reproduce:
1. Install Fedora 9 Preview x86_64 Live KDE
2. Update all packages
3. yum install firefox
  
Actual results:

No menu entry in Applications -> Entry

Expected results:

A menu entry for firefox in Applications -> Entry

Additional info:

The firefox menu entry exists after a reboot.
Perhaps a session logout/login would be enough to get the menu entry
Comment 1 Alain Portal 2008-05-01 06:07:10 EDT
Humm...
Not sure this is a firefox package bug as I just get the same behaviour with
another one.
So, I don't know to which package report this "problem"
Comment 2 Christopher Aillon 2008-05-01 08:13:12 EDT
Hmm...  trying kdebase then for now as a best guess since you're using the kde
live cd.  obviously, firefox is installing the desktop file, and it's being used
by kde, just not on demand... 

Kick back if you think this really is a firefox bug.
Comment 3 Kevin Kofler 2008-05-01 08:18:30 EDT
Sounds like the ages-old KDE bug (which is also in KDE 3 and has been there for 
years) where new menu entries aren't always added to the menu right away. 
Logging out and back in or rebooting altogether should "fix" it.
Comment 4 Rex Dieter 2008-05-01 08:34:29 EDT
Not ages old exactly, it's always worked for me. :)  (kde uses fam/gamin to
"watch" the filesystem to changes, and is supposed to update automatically)

I'll see if I can reproduce.
Comment 5 Rex Dieter 2008-05-01 08:50:15 EDT
Confirmed.

steps to reproduce:

1.  confirm firefox is installed and in menus
2.  yum remove firefox
3.  confirm firefox is now gone from menus
4.  yum install firefox
5.  firefox isn't present in menus

Hrm, repeated this 3 times.  
trial 1: firefox didn't appear
trial 2 & 3: firefox *did* appear

wtf?

regardless, something isn't quite right here.  I'd say time to file issue
upstream @ bugs.kde.org
Comment 6 Kevin Kofler 2008-05-01 08:53:03 EDT
> and is supposed to update automatically

It's supposed to and it usually does, but sometimes it just doesn't work.
Comment 7 Rex Dieter 2008-05-01 08:59:51 EDT
"sometimes it just doesn't work.".  Bug report? :)
Comment 8 Steven M. Parrish 2008-05-01 09:23:33 EDT
Checked upstream and could not find a matching bug.  Please file with
bugs.kde.org and update this report with bug info.
Comment 9 Alain Portal 2008-05-01 09:42:51 EDT
Isn't it the role of the packager than doing that?
Comment 10 Kevin Kofler 2008-05-01 09:48:00 EDT
No.
This has been debated many times on the mailing list. Upstream will want to 
talk to the actual reporter, not a middle-man.
That said, in this case, at least Rex can reproduce it, so we can file it 
upstream if you really don't want to do it.
Comment 11 Rex Dieter 2008-05-01 09:49:45 EDT
> Isn't it the role of the packager than doing that?

:) yes and no.  I'm game to do it, since I can reproduce, but it may be awhile
till I get round-tuit.
Comment 12 Alain Portal 2008-05-01 09:57:57 EDT
(In reply to comment #10)
> No.
> This has been debated many times on the mailing list. Upstream will want to 
> talk to the actual reporter, not a middle-man.
> That said, in this case, at least Rex can reproduce it, so we can file it 
> upstream if you really don't want to do it.

I just ask a question!
I never say I didn't want to report it.

But I can't report it before tomorrow as I'm not on the machine where I have a 
KDE bug report account.
Comment 13 Alain Portal 2008-05-01 10:34:57 EDT
In addition, upstream often say "Update to the latest version", which, of 
course, isn't yet packaged.
Comment 14 Kevin Kofler 2008-05-01 10:41:09 EDT
4.0.3 is still the latest stable version. (They can't really expect you to have 
4.0.4 which was tagged 3 hours ago and which won't be on their own download 
site for about a week.)
Comment 15 Alain Portal 2008-05-01 11:14:50 EDT
I would have to be more precise, I am not talking just about this bug when I 
say upstream, I anted to say in general.
Sorry for the confusion.
Comment 16 Alain Portal 2008-05-01 11:43:09 EDT
(In reply to comment #11)
> > Isn't it the role of the packager than doing that?
> 
> :) yes and no. 

I say « yes ! » ;-)

> I'm game to do it, since I can reproduce, but it may be awhile
> till I get round-tuit.

Sorry Rex, but because my english, I didn't understand what you mean.

If you fill the bug, could you please put me as CC?
If not, I'll fill it tomorrow (I'm GMT + or - 1, I don't remember ;-) ), so, 
tell me if you want to be CCed
Comment 17 Steven M. Parrish 2008-05-02 07:18:53 EDT
Closing in favor of the upstream report.  Will continue to monitor it there.
Comment 18 Alain Portal 2008-05-02 07:44:54 EDT
Why closing this bug as it isn't fixed by upstream?
I monitor opened bugs, not closed
Comment 19 Matěj Cepl 2008-05-02 08:01:34 EDT
https://bugzilla.redhat.com/page.cgi?id=fields.html#upstream for more
explanation of what CLOSED/UPSTREAM means.
Comment 20 Kevin Kofler 2008-05-02 10:43:32 EDT
While we wait for an upstream answer, there's nothing we can do about this bug 
(as we don't have the resources to fix every single bug ourselves, and we have 
several more important ones to deal with), that's why it's closed. Once 
upstream has a fix, there are 2 possibilities:
1. we consider this important enough and the fix uninvasive enough to backport 
upstream's fix: we'll reopen the bug, apply the fix, and close the bug once we 
have applied upstream's fix.
2. we decide that this can wait for the next upstream release which will get us 
the patch automatically. In this case, we just leave the bug in CLOSED UPSTREAM 
state.

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