Bug 273701

Summary: Review Request: gnome-main-menu - Gnome Main Menu
Product: [Fedora] Fedora Reporter: Karl Lattimer <karl>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: rawhideCC: aidan, alex.smith.ixium, alex.smith.lx+rhbz, alexsmith.z.xl.i, andreasantilli, anshu.pg, che666, ch.nolte, davidz, dominik, fedora, fedora-package-review, hez, jensk.maps, jpmahowald, kazimieras.vaina, ken.crandall, ma, maxx, michel, mike, mkemp2, notting, rgjames, sangu.fedora, sundaram, tim, tjb
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-17 13:30:25 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 201449    
Attachments:
Description Flags
patch for xdg-user-dirs
none
Patch to fix build on Fedora 11
none
FC11 src rpm
none
SPEC file for Fedora 11 to build gnome-main-menu
none
updated spec file works around rpath problem
none
updated src rpm to fix rpath problem none

Description Karl Lattimer 2007-09-01 06:47:30 EDT
Somewhat disheartened by the recent closure of bug #199681 I've put together
some new RPMs for gnome-main-menu, this package was built against revision 317
in the gnome svn server. 

spec: http://www.wine-doors.org/rpm/gnome-main-menu.spec
rpm: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.8-1.i386.rpm
src: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.8-1.src.rpm
dev: http://www.wine-doors.org/rpm/gnome-main-menu-devel-0.9.8-1.i386.rpm
dbg: http://www.wine-doors.org/rpm/gnome-main-menu-debuginfo-0.9.8-1.i386.rpm

There are only really a few minor differences with the current trunk, some of
the bookmarks named differently etc...
Comment 1 sangu 2007-09-01 07:36:02 EDT
Error: Missing Dependency

$ sudo yum install gnome-main-menu-0.9.8-1.i386.rpm 
Repository development is listed more than once in the configuration
Repository development-debuginfo is listed more than once in the configuration
Setting up Install Process
Parsing package install arguments
Examining gnome-main-menu-0.9.8-1.i386.rpm: gnome-main-menu - 0.9.8-1.i386
Marking gnome-main-menu-0.9.8-1.i386.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package gnome-main-menu.i386 0:0.9.8-1 set to be updated
--> Processing Dependency: libiw.so.28 for package: gnome-main-menu
--> Finished Dependency Resolution
Error: Missing Dependency: libiw.so.28 is needed by package gnome-main-menu
Comment 2 Till Maas 2007-09-01 08:28:59 EDT
imho the summary tag should be more descriptive than only repeating the package
name.
Comment 3 David Zeuthen 2007-09-01 10:15:43 EDT
You need wireless-tools-devel as a BR. Also, why is it bringing in gdk-pixbuf?
The latter is unfortunate as it pulls in the GTK 1.x stack.
Comment 4 David Zeuthen 2007-09-01 11:32:38 EDT
In fact, turns out the gdk-pixbuf BR is bogus.
Comment 5 David Nielsen 2007-09-01 16:40:25 EDT
It seems that /usr/lib64/libslab.so.0.0.0 creates a comflict with
control-center-2.18.0-20.fc7
Comment 6 Till Maas 2007-09-05 16:54:38 EDT
GPL is not a valid license tag anymore:

http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#head-f21ae23bf2f278444e2c385463cfa74a502396b8
Comment 7 Till Maas 2007-09-05 16:56:15 EDT
And Source0: should be a full URL: http://fedoraproject.org/wiki/Packaging/SourceURL
Comment 8 Karl Lattimer 2007-10-12 12:54:54 EDT
The modifications mentioned here have been done in a new build of the package,
however using the system libslab.so.0 makes GNOME main menu crash. So using
--force to overwrite the libs left by gnome-control-center. 

I think libslab should be split off into a separate package in order to allow
easy replacement of it using obsoletes in this package.

The updated package will be uploaded soon, I'll post the relevant URLs here when
done.
Comment 9 Moacyr Prado 2007-11-18 17:18:32 EST
I am using the release 367 on fedora 8 from svn, without any patch and  I hadn't
any bug yet.
Comment 10 Mamoru TASAKA 2007-12-04 09:29:37 EST
Well, what is the status of this bug?
Comment 11 Karl Lattimer 2007-12-04 09:39:44 EST
I'm about to start looking into some minor changes to the gnome-control-center
specs to split libslab out to its own library (as it should be, a bug will be
filed and the update specs provided in the bug), then provide two new RPMS for
gnome-main-menu the first RPM will be the updated libslab RPM required only by
gnome-main-menu, the second the menu itself.

In doing this the above requested clean-ups and those I intend to include myself
will be added I'll update to the latest SVN and include any patches required for
fedora.

I'm hoping to have a free weekend to catch up on my FOSS work this coming
weekend, this is on my todo list for then.

Let me know if you're looking for anything else to be done.
Comment 12 Ken Crandall 2008-01-31 13:58:21 EST
Any updates on this, or updated packages for testing on Fedora 8?
Comment 13 John Mahowald 2008-02-19 15:55:31 EST
Even with BuildRequires on NetworkManager-devel it fails on development.
Evidently it's not ported to latest NM as of revision 390. Build error:

network-status-agent.c: In function 'init_nm_connection':
network-status-agent.c:157: error: 'NM_DBUS_SIGNAL_STATE_CHANGE' undeclared (fir
st use in this function)
network-status-agent.c:157: error: (Each undeclared identifier is reported only
once
network-status-agent.c:157: error: for each function it appears in.)
network-status-agent.c: In function 'nm_get_device_info':
network-status-agent.c:251: error: 'NM_DBUS_INTERFACE_DEVICES' undeclared (first
 use in this function)
make[2]: *** [network-status-agent.o] Error 1
Comment 14 Anshuman 2008-03-07 02:18:43 EST
so any new news on this? I wanted to try rebuilding this but gave errors on
updated Fedora 8.
Comment 15 Andrea Santilli 2008-04-23 10:08:17 EDT
about NM_DBUS_SIGNAL_STATE_CHANGE you can safely add the following lines to
network-status-agent.c:
#ifndef NM_DBUS_SIGNAL_STATE_CHANGE
#define NM_DBUS_SIGNAL_STATE_CHANGE "StateChange"
#endif

but about NM_DBUS_INTERFACE_DEVICES I don't really know. that was a macro that
used to point to org.freedesktop.NetworkManager.Devices but that class doesn't
exist anymore in the dbus api.

I've found this link about the old api, hoping it's of any help:
http://people.redhat.com/dcbw/NetworkManager/NetworkManager%20DBUS%20API.txt

sigh, I hate both nm and dbus!! how can they change the api that way without
documenting it???
Comment 16 Andrea Santilli 2008-04-23 10:13:45 EDT
Oh I forgot to mention that what we're looking for could be
org.freedesktop.NetworkManager.getDevices() that indeed returns an array of devices.
Comment 17 Andrea Santilli 2008-04-23 11:23:22 EDT
ok all obsolete now sorry. revision 448 has fixed it.
Comment 18 Karl Lattimer 2008-05-06 09:07:22 EDT
Updated packages, may need a little tweaking but work fine here;

spec: http://www.wine-doors.org/rpm/gnome-main-menu.spec
rpm: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.10-1.i386.rpm
src: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.10-1.src.rpm
dev: http://www.wine-doors.org/rpm/gnome-main-menu-devel-0.9.10-1.i386.rpm
dbg: http://www.wine-doors.org/rpm/gnome-main-menu-debuginfo-0.9.10-1.i386.rpm

Sorry for the late response to various questions regarding this, it had been
broken a while and saw no reason to help out, now we've got a working revision
its nice to get the menu back.

Enjoy :)
Comment 19 David Zeuthen 2008-05-06 15:35:52 EDT
(In reply to comment #18)
> its nice to get the menu back.
> 
> Enjoy :)

Thanks a lot for bringing back the menu, I love it. Here's to hoping it will
land in Fedora soon. Thanks!
Comment 20 Mads Villadsen 2008-05-06 16:38:35 EDT
I tried building the src.rpm in mock but it failed:

mock -r fedora-rawhide-i386 gnome-main-menu-0.9.10-1.src.rpm

Relevant lines from the build.log:

checking for LIBSLAB... 
configure: error: Package requirements ( glib-2.0 gobject-2.0 gtk+-2.0 gdk-2.0
gnome-desktop-2.0 librsvg-2.0 libgnome-menu pango eel-2.0 ) were not met:
No package 'eel-2.0' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables LIBSLAB_CFLAGS
and LIBSLAB_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.


There should probably be a BuildRequires line for eel2
Comment 21 Thomas J. Baker 2008-05-07 18:11:00 EDT
I just built it under F9 and it needs NetworkManager-glib-devel in addition to
eel2-devel build requirements. Also, it show correctly that my network
connection is wireless but it reports I'm connected to (null).
Comment 22 Karl Lattimer 2008-05-08 02:07:14 EDT
I'll add the suggested build deps, thanks for testing. 

Please report the wireless connection issue to http://bugzilla.gnome.org this
bug is just a package review request.

The thing I think needs fixing is the top right links, Logout/Shutdown needs to
be corrected, add a link to yelp, any other suggestions here are welcome we have
quite a bit of space to fill.
Comment 23 Andrea Santilli 2008-05-08 03:19:35 EDT
last packages build and install fine but the applet crashes as soon as i try to
add it to the panel.
moreover the log of the crash doesnt seem to report anything related to the
applet itself.
Comment 24 Martin Jürgens 2008-05-08 04:03:18 EDT
Some feedback: installs fine for me. First click on "Computer" after session
login takes long, then it works like a charm. In "Documents" tab, "More
documents" links up to /home/martin/Documents which is not my translated
location, /home/martin/Dokumente. It should rather create the files "New
spreadsheet" etc. in my localized location, also. In "Places" "more Places" does
not work. Gnome-main-menu only has an option to log off, maybe there should be
logout and shutdown which spawns up the usual dialogs from the System menu.
That's all :)
Comment 25 Karl Lattimer 2008-05-08 04:30:26 EDT
Again please file bugs on http://bugzilla.gnome.org

I will restate louder so you can all hear

*** THIS IS ONLY A PACKAGE REVIEW REQUEST ***
  **** NO BUG FIXING WILL HAPPEN HERE! ****

The issue with logout I have already acknowledged and intend to fix, this IS a
packaging issue. I'm unsure about the places issue, this may also be a packaging
issue but I don't have places displayed on my applet at the moment (gconf thing).

As far as the applet crashing is concerned I am unsure but as this package is
being reviewed now for F9 it would be a good idea to run in rawhide until the
release next week if you intend to test it.
Comment 26 Ralf Corsepius 2008-05-08 04:39:13 EDT
(In reply to comment #25)
> Again please file bugs on http://bugzilla.gnome.org
> 
> I will restate louder so you can all hear
> 
> *** THIS IS ONLY A PACKAGE REVIEW REQUEST ***
>   **** NO BUG FIXING WILL HAPPEN HERE! ****

Then 
a) This package is not ready for inclusion in Fedora.
b) You probably should refrain from maintaining packages in Fedora.

Fedora is not a junk yard for defective SW nor a playground to play in.

> As far as the applet crashing is concerned I am unsure but as this package is
> being reviewed now for F9 it would be a good idea to run in rawhide until the
> release next week if you intend to test it.

Then this package and the review should better be postponed until this package
has reached a usable state.
Comment 27 Martin Jürgens 2008-05-08 05:03:46 EDT
Well, bugs and package inclusion go hand in hand. I am not sure if we want
packages that have lots of bugs included in Fedora. That's why I just made a
note about them so that it won't be included before. And how should I know that
it is no packaging issue? The situation without real releases with g-m-m is bad,
I just had the thought to use the releases that are used in OpenSuSE stable
versions instead of some SVN version. They seem to be more stable.
Comment 28 Karl Lattimer 2008-05-08 06:16:53 EDT
> Then 
> a) This package is not ready for inclusion in Fedora.

Not yet it isn't, but if you haven't noticed there is active development going
on in GNOME. I don't tell your grandmother that your mother is shit in bed. File
bug reports in the right place, then they'll get fixed.

> b) You probably should refrain from maintaining packages in Fedora.

I don't maintain packages in fedora, I've added this for review request because
I use it, and have packaged it up, and continued to package it up because I use it.

> Fedora is not a junk yard for defective SW nor a playground to play in.

Nobody said it was, but you can't expect Novell to monitor _THIS_ bugzilla for
bugs relating to software being developed in GNOME svn.
 
> Then this package and the review should better be postponed until this package
> has reached a usable state.

I don't see an @redhat.com email address, I think davidz will be happy to retain
this bug open, here with package refreshes from time to time until the
application _AND_ package has stabilised to the point of inclusion.
Comment 29 Karl Lattimer 2008-05-08 06:25:38 EDT
(In reply to comment #27)
> Well, bugs and package inclusion go hand in hand.

Unfortunately one hand is here, and the other is at GNOME, which doesn't mean
things are necessarily separate, bugzilla's can be used to co-ordinate this but
you must understand that it is USELESS filing bugs here.

> I am not sure if we want packages that have lots of bugs included in Fedora. 

Who said this would be the case?

> That's why I just made a note about them so that it won't be included before.

We know there will be bugs, instead of making "notes" here, file bug reports at
gnome and comment here that those bugs (including URL) are blockers on inclusion
in fedora.

> And how should I know that it is no packaging issue? 

Well, translation? Does that come from the .rpm package, or from the .tar.gz
package? Give yourself a moment to think about this one.

> The situation without real releases with g-m-m is bad,

I agree, the situation is poor unfortunately GNOME aren't willing to accept this
until it comes into alignment with GNOME libs, which from what I can see is what
is currently happening in SVN.

> I just had the thought to use the releases that are used in OpenSuSE stable
> versions instead of some SVN version. They seem to be more stable.

This cannot be done at present because the current OpenSUSE version does not
build on fedora AFAIK, we're using SVN because of this, and monitoring the
situation as needs be. There are also lots of differences between OpenSUSE and
Fedora which thankfully come down to spec files now, but may require patches to
be applied.
Comment 30 Ralf Corsepius 2008-05-08 12:16:31 EDT
(In reply to comment #28)

> > b) You probably should refrain from maintaining packages in Fedora.
> 
> I don't maintain packages in fedora, I've added this for review request because
> I use it, and have packaged it up, and continued to package it up because I
use it.
=> So you do not volunteer to maintain this package in Fedora?

In this case, unless somebody volunteers to takes over maintainership, this
review request needs to be rejected, because a submitter is supposed to 
maintain a package in Fedora.
 
> Nobody said it was, but you can't expect Novell to monitor _THIS_ bugzilla for
> bugs relating to software being developed in GNOME svn.
I don't care about Novell nor who might be behind this. 

I simply say: There should be no room in Fedora for known to be broken SW nor
for maintainers refusing to take care about known bugs.
Comment 31 Tim Niemueller 2008-05-08 16:19:00 EDT
Please calm down a bit. We can handle this in a more friendly and cooperative way.

Karl, the basic question is: would you be willing to maintain this package
within Fedora for some time according to
http://fedoraproject.org/wiki/Development/Schedule/MaintainerResponsibilityPolicy
? Or is there someone else who would take over otherwise? Thanks for the work
you have done so far in any case!

If the software does work and there are only minor issues I'd say it's ready for
inclusion. The crasher in comment #23 needs some investigation if others can
reproduce it, but the xdg folder issues can be fixed even after an inclusion I'd
say.

What do you think?
Comment 32 Karl Lattimer 2008-05-09 01:27:04 EDT
(In reply to comment #30)
> (In reply to comment #28)
> 
> > > b) You probably should refrain from maintaining packages in Fedora.
> > 
> > I don't maintain packages in fedora, I've added this for review request because
> > I use it, and have packaged it up, and continued to package it up because I
> use it.
> => So you do not volunteer to maintain this package in Fedora?
> 
> In this case, unless somebody volunteers to takes over maintainership, this
> review request needs to be rejected, because a submitter is supposed to 
> maintain a package in Fedora.

Well unfortunately I have a job, and a girlfriend, and a social life, and a
major project of my own...

I don't mind putting packages together when I build them for myself, and
submitting them here, especially ones which don't require much maintenance but
I'm not willing to chase gnome bugs and reference them, and put up with the
whining of people like you who seem to have something against me building
packages. Just one point I'd like to make, rules are guidelines, not things you
can use to belittle people. <<invoke godwins law here>>
 
> > Nobody said it was, but you can't expect Novell to monitor _THIS_ bugzilla for
> > bugs relating to software being developed in GNOME svn.

> I don't care about Novell nor who might be behind this. 

Arrogance... I give thanks to Novell, as it is a lovely menu. As I give thanks
to all the open source developers in the world. If you wish to bring that kind
of arrogance into a distribution then it will have a negative impact for us all.

The point being, we do need to care who and where stuff comes from, and thank
them, and give props to them, and treat them seriously cool because we're not
competitors we're collaborators.
 
> I simply say: There should be no room in Fedora for known to be broken SW nor
> for maintainers refusing to take care about known bugs.

See note on rules above.
Comment 33 Karl Lattimer 2008-05-09 01:32:54 EDT
(In reply to comment #31)
> Please calm down a bit. We can handle this in a more friendly and cooperative way.

*** take a moment, find your center, ignore the prick ***

> Karl, the basic question is: would you be willing to maintain this package
> within Fedora for some time according to
> http://fedoraproject.org/wiki/Development/Schedule/MaintainerResponsibilityPolicy
> ? Or is there someone else who would take over otherwise? Thanks for the work
> you have done so far in any case!

The original submitter may be interested (check the previous bug report
referenced in the summary), but as you're possibly aware from comment #32 I'm
quite busy with lots of things. This isn't to say I wouldn't do this, and of
course will be around from time to time to hack bits and bobs up as me and this
menu have become quite good friends.

> If the software does work and there are only minor issues I'd say it's ready for
> inclusion. The crasher in comment #23 needs some investigation if others can
> reproduce it, but the xdg folder issues can be fixed even after an inclusion I'd
> say.

I'll fix the xdg folder issues and provide some updates packages tomorrow
probably, I think the crasher is something machine specific or version specific.
Not sure but we can get some widespread testing by releasing it in F9 as it has
only been reported once.
Comment 34 Ralf Corsepius 2008-05-10 00:04:06 EDT
(In reply to comment #32)
> > I don't care about Novell nor who might be behind this. 
> 
> Arrogance... I give thanks to Novell, as it is a lovely menu. As I give thanks
> to all the open source developers in the world. If you wish to bring that kind
> of arrogance into a distribution then it will have a negative impact for us all.
What? Fact is, the origin of a package is irrelevant, be it Pres. Bush, 
Bill Gates, Steve Jobs, Novell, RH or anybody else.

So, question: Who of you is going to volunteer to _maintain_ and _be in charge
for this package in Fedora? So far I don't see anybody.




Comment 35 Karl Lattimer 2008-05-11 15:51:50 EDT
Update:

 * Network button issue appears to be fixed upstream. Updated to latest SVN
 * Fixed Help/Add software icons

Todo:

 * Cannot locate a method of calling shutdown from a .desktop file, ideas
welcome? I'm sure this used to be possible, current gnome-session-save --kill is
called. Maybe we should get ourselves a snazzy logout screen?
 * More places button is redundant, I might remove this and push it upstream
after speaking with jpr/danw @ novell

@ralf, the origin isn't irrelevant at all you goit. The origin is half the
problem ubuntu have, they don't work properly with upstream so everyone hates
them in the upstream community, people like redhat/novell because they do it
right. Please don't bring ubuntu style behaviour here.
Comment 36 Anshuman 2008-05-11 16:27:20 EDT
(In reply to comment #35)
> Update:
> 
>  * Network button issue appears to be fixed upstream. Updated to latest SVN
>  * Fixed Help/Add software icons
> 

Thanks for allll your efforts man. :) 

Now where is the new file link? (updated i mean) I already got 
src: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.8-1.src.rpm working last
week on my Fedora 8 nicely.
Comment 38 Ralf Corsepius 2008-05-12 01:58:28 EDT
(In reply to comment #35)
> @ralf, the origin isn't irrelevant at all you goit.
Nonsense, Karl. Names are "noise and smoke" (German proverb) on the technical level.

> The origin is half the
> problem ubuntu have, they don't work properly with upstream so everyone hates
> them in the upstream community, people like redhat/novell because they do it
> right. Please don't bring ubuntu style behaviour here.
More nonsense.

I reiterate my questions for the last time:  Who is going to maintain this package?

Shouldn't I see an answer to this question by Friday this week, I am going to
close this request - period.
Comment 39 Karl Lattimer 2008-05-12 02:23:31 EDT
(In reply to comment #38)
> (In reply to comment #35)
> > @ralf, the origin isn't irrelevant at all you goit.
> Nonsense, Karl. Names are "noise and smoke" (German proverb) on the technical
level.
> 
> > The origin is half the
> > problem ubuntu have, they don't work properly with upstream so everyone hates
> > them in the upstream community, people like redhat/novell because they do it
> > right. Please don't bring ubuntu style behaviour here.
> More nonsense.

It isn't nonsense at all, working well with upstream is very important.
Otherwise you're just leeching their work and giving nothing back. You have to
be able to contribute upstream, at the very least upstreaming bug reports
appropriately.

It seems to me you have no experience with working with upstream developers,
consider this your first run in with one.

> I reiterate my questions for the last time:  Who is going to maintain this
package?
> 
> Shouldn't I see an answer to this question by Friday this week, I am going to
> close this request - period.
> 

Ralf I have one question for you, who exactly do you think you are? You appear
to have a personal issue with me and therefore want to close this review request
prematurely because you can't find someone to maintain it. Which is merely a
pathetic excuse because you want to win a battle I think is irrelevant. 

What is the problem with leaving this request open? Because if you close it, I
will simply open it again, and again, and again, and again.

Also I'll make your comments about upstream being irrelevant public on planet
gnome. In which case any community respect you hope to gain will drop sharply.

You really need to grow up dude, you don't have any power, this is a meritocracy
. From what I see nothing you do has any merit, other than to further alienate
developers from distributions.

Well done.
Comment 40 Tim Niemueller 2008-05-12 03:19:22 EDT
(In reply to comment #35)

> @ralf, the origin isn't irrelevant at all you goit. The origin is half the
> problem ubuntu have, they don't work properly with upstream so everyone hates
> them in the upstream community, people like redhat/novell because they do it
> right. Please don't bring ubuntu style behaviour here.

Agreed! Upstream work is a damn good thing and needs a test ground, Fedora is in
the front row. We don't want utterly buggy software but we won't reject someone
who is willing to do the work and needs testers.
Comment 41 Tim Niemueller 2008-05-12 03:53:30 EDT
(In reply to comment #38)

> More nonsense.
> 
> I reiterate my questions for the last time:  Who is going to maintain this
package?
> 
> Shouldn't I see an answer to this question by Friday this week, I am going to
> close this request - period.

I'm astonished about the level of unfriendlyness and almost aggressiveness that
you show. If it bothers you so much why don't you just un-CC yourself and let
Karl do the upstream work and have someone else the review when it is at the
right point instead of setting an ultimatum pretty much taken out of the air. I
personally don't mind if this bug stays open for another few weeks if this is
the time that is needed to make upstream fit.

Ralf, calm down and be cooperative and actually helpful! I have not seen a
single useful comment that provides anything to make the package better and
ready for inclusion. Just saying "no" is not something I want to see in Fedora,
but rather cooperation and work being done.
Comment 42 Patrice Dumas 2008-05-12 04:14:43 EDT
I don't see any trouble having the package being approved to be
in good shape, and  then being taken over by a fedora maintainer 
and then formally reviewed.

This should be closed only if, after the package being stated
to be in good shape, nobody wants to maintain it. It is perfectly
right to swap maintainers at the end of a review, though it is 
better if it is not swapped with the reviewer. 
Comment 43 Anshuman 2008-05-12 05:42:30 EDT
(In reply to comment #37)
> I knew there was something I forgot to do before I went to bed last night :)
> 
> spec: http://www.wine-doors.org/rpm/gnome-main-menu.spec
> rpm: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.10-2.i386.rpm
> src: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.10-2.src.rpm
> dev: http://www.wine-doors.org/rpm/gnome-main-menu-devel-0.9.10-2.i386.rpm
> dbg: http://www.wine-doors.org/rpm/gnome-main-menu-debuginfo-0.9.10-2.i386.rpm
> 


Alrighty, the RPM in this version and previous version give same error.

===========================================================
[root@Fedora8 Download]# rpm -ivh gnome-main-menu-0.9.10-2.i386.rpm 
error: Failed dependencies:
        libgio-2.0.so.0 is needed by gnome-main-menu-0.9.10-2.i386
[root@Fedora8 Download]# locate libgio
[root@Fedora8 Download]# 
===========================================================


And last time, I rebuild src. and installed it, worked perfectly fine. this time
 that too is giving error.

=====================================================
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -o .libs/main-menu main-menu.o main-menu-ui.o
main-menu-migration.o tile-table.o hard-drive-status-tile.o
network-status-tile.o network-status-agent.o network-status-info.o
tomboykeybinder.o eggaccelerators.o -pthread  -L/lib -lpanel-applet-2 -lgtop-2.0
-ldbus-glib-1 -lnm_glib -lhal-storage -lhal -ldbus-1 -liw
../../libslab/.libs/libslab.so -lgnome-desktop-2 -lstartup-notification-1
-lrsvg-2 -lgnome-menu -leel-2 -lgnomeui-2 -lSM -lICE -lgailutil -lglade-2.0
-lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2
-lbonobo-activation -lart_lgpl_2 -lgconf-2 -lORBit-2 -lgthread-2.0 -lrt
-lgtk-x11-2.0 -lxml2 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0
-lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 
network-status-agent.o: In function `init_nm_connection':
/usr/src/redhat/BUILD/gnome-main-menu-0.9.10/main-menu/src/network-status-agent.c:134:
undefined reference to `nm_client_get_manager_running'
collect2: ld returned 1 exit status
make[2]: *** [main-menu] Error 1
make[2]: Leaving directory
`/usr/src/redhat/BUILD/gnome-main-menu-0.9.10/main-menu/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/gnome-main-menu-0.9.10'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.77364 (%build)


RPM build errors:
    user karl does not exist - using root
    group karl does not exist - using root
    Bad exit status from /var/tmp/rpm-tmp.77364 (%build)
[sysmin@Fedora8 Other]$ 

=====================================================



Now? :|
Comment 44 Tim Niemueller 2008-05-12 05:49:53 EDT
It needs a really new NetworkManager version available only on Fedora 9. This
should be reflected by BR the current F9 NM version. Additionally eel2-devel is
still missing as BR. I'm currently upgrading my F-9 in the virtual machine to
give it a try there.
Comment 45 Anshuman 2008-05-12 05:58:29 EDT
shit, so i must kiss goodbye to any new version of GMM ? thought karl too was on
F8, anyway, F9 is going to be released on 13 and i am surely going to upgrade.
Still it would had been good to get this new one working. Anyway . back to
previous version. Thanks tim for clarifying this. 
Comment 46 Karl Lattimer 2008-05-12 06:25:10 EDT
(In reply to comment #43)

> Now? :|

Let me poke at this tonight, I need to push some GSM releases out this evening
then I'm free to get my hands dirty on this again. I can even try a build on F8.
Comment 47 Karl Lattimer 2008-05-12 06:26:16 EDT
(In reply to comment #44)
> It needs a really new NetworkManager version available only on Fedora 9. This
> should be reflected by BR the current F9 NM version. Additionally eel2-devel is
> still missing as BR. I'm currently upgrading my F-9 in the virtual machine to
> give it a try there.

Good point, I knew there was something else I forgot, I had much happening last
night :) So I'll work out some of the other issues and possibly get the shutdown
thing going tonight after a poke at the gnome-panel source.

Comment 48 Bug Zapper 2008-05-14 10:11:26 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

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 Fedora version prior to Fedora 7'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 Fedora 7 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 Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

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 Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 49 Tim Niemueller 2008-05-14 19:24:52 EDT
I have compiled it on F-9 and it works nicely so far. The XDG bug is there as
already reported. Additionally I noted the following:
 * I'm using the standard upper panel (size 25 pixels). As applet a button seems
to be used. This cuts of text and icon on top and bottom. Preferably it should
be menu style like the default apps menu I think.
 * Besides the minimum version of NetworkManager at all the BR
NetworkManager-glib-devel is missing completely. Will not build without.

No crashes after some using, only the mentioned minor issues. Network connection
was correctly displayed.
Comment 50 David Zeuthen 2008-05-22 15:52:40 EDT
Seems the 0.9.10-2 src rpm needs the following BR's

 - eel2-devel
 - NetworkManager-glib-devel

to build. At least this is what I needed on a F9 x86_64 fresh install. With this
the package builds fine. 

(Btw, the main menu itself is claiming I'm connected to the wireless network
"Miller Time" (which does exist according to NM at least) when in fact I'm
connected to the network "davidznet". But this shouldn't block the review /
getting this into Fedora)
Comment 51 Karl Lattimer 2008-05-31 04:40:09 EDT
Updated to latest SVN
Added build requirements
Added a fedora specific patch for menu items/schemas
Added a temporary patch to reverse recent changes to network status agent
preventing broken build on fedora, patch can be removed when network manager in
fedora is updated.

spec: http://www.wine-doors.org/rpm/gnome-main-menu.spec
rpm: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.11-1.i386.rpm
src: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.11-1.src.rpm
dev: http://www.wine-doors.org/rpm/gnome-main-menu-devel-0.9.11-1.i386.rpm
dbg: http://www.wine-doors.org/rpm/gnome-main-menu-debuginfo-0.9.11-1.i386.rpm
Comment 52 Alexander Smith 2008-06-11 04:21:39 EDT
(In reply to comment #51)
> Updated to latest SVN
> Added build requirements
> Added a fedora specific patch for menu items/schemas
> Added a temporary patch to reverse recent changes to network status agent
> preventing broken build on fedora, patch can be removed when network manager in
> fedora is updated.
> 
> spec: http://www.wine-doors.org/rpm/gnome-main-menu.spec
> rpm: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.11-1.i386.rpm
> src: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.11-1.src.rpm
> dev: http://www.wine-doors.org/rpm/gnome-main-menu-devel-0.9.11-1.i386.rpm
> dbg: http://www.wine-doors.org/rpm/gnome-main-menu-debuginfo-0.9.11-1.i386.rpm
> 

(In reply to comment #51)
> Updated to latest SVN
> Added build requirements
> Added a fedora specific patch for menu items/schemas
> Added a temporary patch to reverse recent changes to network status agent
> preventing broken build on fedora, patch can be removed when network manager in
> fedora is updated.
> 
> spec: http://www.wine-doors.org/rpm/gnome-main-menu.spec
> rpm: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.11-1.i386.rpm
> src: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.11-1.src.rpm
> dev: http://www.wine-doors.org/rpm/gnome-main-menu-devel-0.9.11-1.i386.rpm
> dbg: http://www.wine-doors.org/rpm/gnome-main-menu-debuginfo-0.9.11-1.i386.rpm
> 

The link to the source RPM down :(
Comment 53 Karl Lattimer 2008-06-14 05:01:27 EDT
Sorry I've uploaded the src.rpm now :)
Comment 54 Karl Lattimer 2008-06-14 06:22:55 EDT
Minor update:
 * Removed network manager patch, as latest fedora network manager works with
upstream
 * Updated to upstream SVN, upstream changelog notes a fix for multiple monitors

spec: http://www.wine-doors.org/rpm/gnome-main-menu.spec
rpm: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.11-2.i386.rpm
src: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.11-2.src.rpm
dev: http://www.wine-doors.org/rpm/gnome-main-menu-devel-0.9.11-2.i386.rpm
dbg: http://www.wine-doors.org/rpm/gnome-main-menu-debuginfo-0.9.11-2.i386.rpm
Comment 55 Ken Crandall 2008-07-10 02:03:19 EDT
With the latest NetworkManager errata pushed out, this works for F8 too, now.
Comment 56 Andrea Santilli 2008-08-06 17:41:28 EDT
you might want to add this little patch to make it compatible to the xdg user directories.
Comment 57 Andrea Santilli 2008-08-06 17:42:14 EDT
Created attachment 313646 [details]
patch for xdg-user-dirs
Comment 58 Ken Crandall 2008-10-01 02:37:14 EDT
The latest NetworkManager broke it.  The applet won't even load on FC9 or FC8.
Comment 59 Karl Lattimer 2008-10-21 07:08:12 EDT
Latest update, this only works on fedora rawhide, I thought I'd get in early for f10's release :)

This has been updated to the latest SVN, which means that some of the older quirks of network manager are gone. Also, as gnome-session has been improved enough we now have a shutdown button!!!!

spec: http://www.wine-doors.org/rpm/gnome-main-menu.spec
rpm: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.12-2.i386.rpm
src: http://www.wine-doors.org/rpm/gnome-main-menu-0.9.12-2.src.rpm
dev: http://www.wine-doors.org/rpm/gnome-main-menu-devel-0.9.12-2.i386.rpm
dbg: http://www.wine-doors.org/rpm/gnome-main-menu-debuginfo-0.9.12-2.i386.rpm

@Andrea Santilli, Sorry I haven't included your patch. Although I expect there'll be a further update quite soon so I'll put it in next time the SVN has a significant update.

Maybe your patch is an upstream patch and you should then send it up to gnome bugzilla rather than here?
Comment 60 Karl Lattimer 2008-10-21 07:10:22 EDT
@Andrea Santilli, after looking at your patch I'd say this is an upstream patch rather than a review request patch. Submit it up on http://bugzilla.gnome.org and it may be approved in the upstream project.
Comment 61 Michael Cronenworth 2009-01-23 00:30:30 EST
Stumbled on this bug looking for a new main menu.

I recommend that you update your spec and rpms with the official 0.9.12 release for NetworkManager API changes. Plus you can remove the patch for the shutdown desktop file. I'm really liking this menu with the "file-browser-applet." This should be the default setup.
Comment 62 Jeffrey Goh 2009-02-28 05:21:32 EST
SLAB is nice. This was the most up to date I could find for fedora 10,
but since I'm on fc10 and not rawhide, this didn't exactly work "straight out of the box" for me.

I ended up amending Karl's patch file before I found the "official" 0.9.12
release.

Here is my replacement patch.  You'll want it in your rpmbuild/SOURCES directory
after you install Karl's src.rpm

http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-2/fedora-main-menu.patch

I'll get the official 0.9.12 release into the RPM in due course.
The network button doesn't work for me still, so I'll have to figure that out ...

Hope this helps.
Comment 63 Michael Cronenworth 2009-02-28 13:21:47 EST
(In reply to comment #62)
> The network button doesn't work for me still, so I'll have to figure that out
> ...

You need 0.9.12 in order to have the network button work as mentioned in my comment right above yours.
Comment 64 Jeffrey Goh 2009-02-28 13:48:39 EST
Thanks, Mike. Was just about to summarise my findings re: network button

I already had 0.9.12 final release, but the problem was that NetworkManager wasn't running.

[jeff@localhost ~]$ gconftool-2 -R /desktop/gnome/applications/main-menu
 network_config_tool_nm = /usr/share/applications/nm-connection-editor.desktop
 ...
 network_config_tool = /usr/share/applications/YaST2/lan.desktop

There are two things that can happen when you click the network-status-tile:

1. If NetworkManager is running, it'll run "nm-connection-editor"
2. If NM is not running, it'll run "yast2 -lan" (assuming you have
   some flavor of suse installed).

There's two ways to "fix" this.  The problem stays hidden if you run NM,
but being the perfectionist that I am, here's my fix:


[jeff@localhost ~]$ gconftool-2 -t string -s /desktop/gnome/applications/main-menu/network_config_tool /usr/share/applications/redhat-system-config-network.desktop 

Now to figure out where in the source tree that actually lives so that installing the RPM "just works".  Neither the final release from gnome, nor any of Karl's patches addresses this niggly (but irritating) issue.

0.9.12-final now compiles just fine, but I need to package the patches for a proper fedora build before posting.  Does anyone know if 0.9.13 real? The download page and the SVN don't seem to agree on what the latest version is.
Comment 66 Jeffrey Goh 2009-03-01 00:09:19 EST
Sorry for the delay. Turns out also that the previous patch didn't run but the problem didn't show up because gnome caches stuff.

Regardless of whether you installed 0.9.12-3 or 0.9.12-4, you'll need to do this in order for the newly installed menu items to show up:

$ rm -rf ~/.local/share/gnome-main-menu/

Follow instructions here:
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-4/index.html


src-rpm/spec
============

http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-4/gnome-main-menu-0.9.12-4.src.rpm 
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-4/gnome-main-menu.spec

x86_64 RPMS
===========

http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-4/gnome-main-menu-0.9.12-4.x86_64.rpm 
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-4/gnome-main-menu-debuginfo-0.9.12-4.x86_64.rpm 
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-4/gnome-main-menu-devel-0.9.12-4.x86_64.rpm

i386
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-3/gnome-main-menu-0.9.12-4.i386.rpm 
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-3/gnome-main-menu-debuginfo-0.9.12-4.i386.rpm 
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-3/gnome-main-menu-devel-0.9.12-4.i386.rpm

I had just one person download 0.9.12-3(via Comcast) at about 4am Singapore time. Hopefully he reads this and gets the latest version.
Comment 67 Dominik 'Rathann' Mierzejewski 2009-03-08 15:46:16 EDT
Some small issues with the spec file:


Packager:		Lightspeed Technologies
Vendor:			Lightspeed Technologies

These fields will be overwritten by Fedora build system, hence they can be dropped.


For readability's sake I'd ask you to reformat BuildRequires, i.e. put each in its own line and sort them alphabetically. This will also make diffs smaller if there are any updates to them.


Additionally, I'm pretty certain that some of the BuildRequires are redundant. I'll try to provide a list later.


The -devel subpackage is missing Requires: pkgconfig, which is mandatory for all packages that ship .pc files.


%{_datadir}/applications/*

For just one file you could simply spell it out:
%{_datadir}/applications/application-browser.desktop


%{_datadir}/gnome-main-menu/*

%{_includedir}/slab/*

makes %{_datadir}/gnome-main-menu and %{_includedir}/slab directories unowned, so just drop the /*.
Comment 68 Jeffrey Goh 2009-03-12 13:19:33 EDT
repackaging as per Comment #67, and with reference to:

http://fedoraproject.org/wiki/PackagingGuidelines#Packaging_Guidelines

Vendor/Packager removed (as per #67 above)

"# The Packager tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the Packager tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header. See also the Maximum RPM definition of the Packager tag at www.rpm.org . If you need to include information about the packager in the rpms you built, use %packager in your ~/.rpmmacros instead.
# The Vendor tag should not be used. It is set automatically by the build system."

BuildRequires one per line (done)

Rediscovered BuildRequires via rpmdev-rmdevelrpms

re #67: %{datadir}/applications/* -

/usr/share/applications/application-browser.desktop
/usr/share/applications/gnome-screensaver-lock.desktop
/usr/share/applications/gnome-session-logout.desktop
/usr/share/applications/gnome-session-shutdown.desktop
/usr/share/applications/trigger-panel-run-dialog.desktop

re #67: unowned directories problem - fixed, but with "...slab/" instead of "...slab" as suggested by Dominik

from https://fedoraproject.org/wiki/Packaging/UnownedDirectories

 %{_datadir}/foo/*

This includes everything _in_ "foo", but not "foo" itself. "rpm -qlv pkgname" will show a missing drwxr-xr-x entry for "foo". Correct would be:

 %{_datadir}/foo/

to include the directory _and_ the entire tree below it. 


=========== updated package fixing spec file only, no need to update unless you're interested in rebuilding, I guess

Follow instructions here:
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-5/index.html


src-rpm/spec
============

http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-5/gnome-main-menu-0.9.12-5.src.rpm 
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-5/gnome-main-menu.spec

x86_64 RPMS
===========

http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-5/gnome-main-menu-0.9.12-5.x86_64.rpm 
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-5/gnome-main-menu-debuginfo-0.9.12-5.x86_64.rpm 
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-5/gnome-main-menu-devel-0.9.12-5.x86_64.rpm

i386
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-5/gnome-main-menu-0.9.12-5.i386.rpm 
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-5/gnome-main-menu-debuginfo-0.9.12-5.i386.rpm 
http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-5/gnome-main-menu-devel-0.9.12-5.i386.rpm
Comment 69 Dominik 'Rathann' Mierzejewski 2009-03-13 10:15:55 EDT
Looking at fedora-main-menu.patch, I found some odd hunks:

-  <bookmark href="banshee-1.desktop" added="2007-01-16T05:51:22Z" modified="2007-01-16T05:51:22Z" visited="2007-01-16T05:51:22Z">
+  <bookmark href="openoffice.org-1.9-calc.desktop" added="2007-01-16T05:51:22Z" modified="2007-01-16T05:51:22Z" visited="2007-01-16T05:51:22Z">

-  <bookmark href="f-spot.desktop" added="2007-01-16T05:51:22Z" modified="2007-01-16T05:51:22Z" visited="2007-01-16T05:51:22Z">
+  <bookmark href="banshee-1-media-player.desktop" added="2007-01-16T05:51:22Z" modified="2007-01-16T05:51:22Z" visited="2007-01-16T05:51:22Z">

-          <bookmark:application name="F-Spot" exec="f-spot" timestamp="1168926682" count="1"/>
+          <bookmark:application name="Helix Banshee" exec="banshee-1 --redirect-log --device-activate=%u" timestamp="1168926682" count="1"/>

-  <bookmark href="nautilus.desktop" added="2007-01-16T05:51:22Z" modified="2007-01-16T05:51:22Z" visited="2007-01-16T05:51:22Z">
+  <bookmark href="gnome-terminal.desktop" added="2007-01-16T05:51:22Z" modified="2007-01-16T05:51:22Z" visited="2007-01-16T05:51:22Z">
+    <info>
+      <metadata owner="http://freedesktop.org">
+        <mime:mime-type type="application/x-desktop"/>
+        <bookmark:groups>
+          <bookmark:group>rank-4</bookmark:group>
+        </bookmark:groups>
+        <bookmark:applications>
+          <bookmark:application name="Terminal" exec="f-spot" timestamp="1168926682" count="1"/>
+        </bookmark:applications>
+      </metadata>
+    </info>
+  </bookmark>
+  <bookmark href="picasa.desktop" added="2007-01-16T05:51:22Z" modified="2007-01-16T05:51:22Z" visited="2007-01-16T05:51:22Z">
+    <info>
+      <metadata owner="http://freedesktop.org">
+        <mime:mime-type type="application/x-desktop"/>
+        <bookmark:groups>
+          <bookmark:group>rank-5</bookmark:group>
+        </bookmark:groups>
+        <bookmark:applications>
+          <bookmark:application name="Google Picasa" exec="/opt/google/picasa/3.0/bin/picasa" timestamp="1168926682" count="1"/>
+        </bookmark:applications>
+      </metadata>
+    </info>
+  </bookmark>
+  <bookmark href="AdobeReader.desktop" added="2007-01-16T05:51:22Z" modified="2007-01-16T05:51:22Z" visited="2007-01-16T05:51:22Z">

-          <bookmark:application name="Nautilus" exec="nautilus --no-desktop --browser %U" timestamp="1168926682" count="1"/>
+          <bookmark:application name="Adobe Acrobat" exec="/opt/google/picasa/3.0/bin/picasa" timestamp="1168926682" count="1"/>

-  <bookmark href="package-manager.desktop" added="2007-01-16T05:53:36Z" modified="2007-01-16T05:53:36Z" visited="2007-01-16T05:53:36Z">
+  <bookmark href="gpk-application.desktop" added="2007-01-16T05:53:36Z" modified="2007-01-16T05:53:36Z" visited="2007-01-16T05:53:36Z">

Would you care to explain these changes? Especially those introducing links to proprietary apps in /opt.
Comment 70 Jeffrey Goh 2009-03-14 00:53:48 EDT
oops. those look almost like they came off of my home desktop environment ... 
which I made the same as my work desktop, which is SLED.

Let me go see what apps make sense for a default "clean" Fedora environment.
Comment 71 Dominik 'Rathann' Mierzejewski 2009-04-14 06:22:46 EDT
Ping?
Comment 72 Jeffrey Goh 2009-04-14 10:16:55 EDT
Sorry for the delay. It's been a busy month.

After digging around, I managed to find a "User Guide" to the fedora
desktop to use as a reference point.

As a result, I have taken out Google Picasa and Adobe Acrobat from the default
applications list.

Nautilus doesn't make sense to be in applications, because all of "places" is basically nautilus, as I understand it (happy to be corrected), so I didn't add it back in.

So, here is my proposed default apps list - any missing apps just don't get displayed, no weird behaviour whatsoever.  Note that you can right click on any app to make it in/out of the favorite applications.

1. Firefox
2. Thunderbird
3. Spreadsheet (openoffice.org -calc)
4. Writer (openoffice.org -writer)
5. Banshee
6. Terminal (gnome-terminal)

I'm thinking maybe the following makes sense as well:

7. Presentation (openoffice.org -impress)
8. Evolution - I never actually use this, since I'm able to crash
   it ever so often, but it's apparently the 
   default mail app for both Fedora and SLED *shrug*

If that's generally acceptable, I'll remake the RPM.
Comment 73 Jeffrey Goh 2009-04-14 10:24:59 EDT
Oh. Forgot

9. Pidgin (I use Spark)
10. Gnucash *wince*


and the URL for the user guide is probably helpful -

http://fedoraproject.org/wiki/F8_User_Guide
Comment 74 Tim Niemueller 2009-04-14 18:51:00 EDT
(In reply to comment #72)

> 5. Banshee

Should probably be Rhythmbox as this is the default media player in Fedora AFAIK.
Comment 75 Rudolf Kastl 2009-04-14 20:10:19 EDT
how about using those that are set as preferred applications in gnome instead of hardcoding applications again?
Comment 76 Ken Crandall 2009-06-17 13:53:41 EDT
0.9.12 does not build on F11:

main-menu.c: In function 'main_menu_applet_init':
main-menu.c:67: warning: implicit declaration of function 'gnome_program_init'
main-menu.c:67: error: 'LIBGNOMEUI_MODULE' undeclared (first use in this function)
main-menu.c:67: error: (Each undeclared identifier is reported only once
main-menu.c:67: error: for each function it appears in.)
make[2]: *** [main-menu.o] Error 1
make[2]: *** Waiting for unfinished jobs....
main-menu-ui.c: In function 'item_to_recent_doc_tile':
main-menu-ui.c:1087: warning: unused variable 'node'
main-menu-ui.c:1085: warning: unused variable 'is_local'
main-menu-ui.c:1084: warning: unused variable 'is_nfs'
main-menu-ui.c:1083: warning: unused variable 'nfs_id'
main-menu-ui.c:1082: warning: unused variable 'file'
main-menu-ui.c:1081: warning: unused variable 'volume'
main-menu-ui.c:1080: warning: unused variable 'mount'
main-menu-ui.c: In function 'item_to_system_tile':
main-menu-ui.c:1132: warning: unused variable 'basename'
main-menu-ui.c: In function 'app_is_in_blacklist':
main-menu-ui.c:1248: warning: implicit declaration of function 'geteuid'
make[2]: Leaving directory `/home/ken/redhat/BUILD/gnome-main-menu-0.9.12/main-menu/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ken/redhat/BUILD/gnome-main-menu-0.9.12'
make: *** [all] Error 2
error: Bad exit status from /home/ken/redhat/TEMP/rpm-tmp.MVyvPe (%build)


RPM build errors:
    Bad exit status from /home/ken/redhat/TEMP/rpm-tmp.MVyvPe (%build)


Working on a patch...
Comment 77 Hezekiah M. Carty 2009-06-17 14:01:56 EDT
The Debian patches may be a good places to start:

http://patch-tracking.debian.net/package/gnome-main-menu/0.9.12-3
Comment 78 Ken Crandall 2009-06-17 14:08:09 EDT
Created attachment 348312 [details]
Patch to fix build on Fedora 11

This patch adds libgnomeui include files (which were missing) and causing the build to fail on Fedora 11.

It now builds and works for me.
Comment 79 Rahul Sundaram 2009-06-22 06:33:12 EDT
Ken Crandall,

If you are submitting it for review, please provide the spec file and srpm instead of a patch.
Comment 80 Jeffrey Goh 2009-06-22 09:14:30 EDT
0.9.12-5 still works on F10.  I haven't tested Ken's patch in F10
since I ended up doing an in-situ upgrade to F11 (not my favorite process ...
but it seems to work OK).  I have put together the SRPM and spec files
for Fedora 11 based on applying Ken's patch:

I'm posting the x86_64 RPMs first. 32 bit RPMs out shortly.  Follow
instructions in

http://www.linux.com.sg/projects/47-slab-0-9-12-6-fc11.html

The x86_64 RPMs for Fedora 11:

http://www.linux.com.sg/fedora11/gnome-main-menu/0.9.12-6/gnome-main-menu-0.9.12-6.fc11.x86_64.rpm 
http://www.linux.com.sg/fedora11/gnome-main-menu/0.9.12-6/gnome-main-menu-debuginfo-0.9.12-6.fc11.x86_64.rpm 
http://www.linux.com.sg/fedora11/gnome-main-menu/0.9.12-6/gnome-main-menu-devel-0.9.12-6.fc11.x86_64.rpm  

For the more technically inclined:

http://www.linux.com.sg/fedora11/gnome-main-menu/0.9.12-6/gnome-main-menu.spec
http://www.linux.com.sg/fedora11/gnome-main-menu-0.9.12-6.fc11.src.rpm
Comment 81 Jeffrey Goh 2009-06-22 09:17:02 EDT
Created attachment 348889 [details]
FC11 src rpm

Here's the src rpm that builds for Fedora 11
Comment 82 Jeffrey Goh 2009-06-22 09:18:31 EDT
Created attachment 348890 [details]
SPEC file for Fedora 11 to build gnome-main-menu
Comment 83 Rudolf Kastl 2009-06-23 05:55:16 EDT
there are rpath issues:

ERROR   0001: file '/usr/bin/application-browser' contains a standard rpath '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/libexec/main-menu' contains a standard rpath '/usr/lib64' in [/usr/lib64]

you will have to use chrpath to remove rpath from those binaries.
Comment 84 Jeffrey Goh 2009-06-23 11:04:24 EDT
rpath is the symptom. Real problem is that libtool inside the tarball is not fedora multilib compliant.  Here's the "fix", I think. Uploading new attachments here and to http://www.linux.com.sg/fedora11/gnome-main-menu/0.9.12-6/gnome-main-menu.spec, but so is every other way of dealing with the rpath issue:

RCS file: RCS/gnome-main-menu.spec,v
retrieving revision 1.11
diff -r1.11 gnome-main-menu.spec
40a41
> BuildRequires:		libtool
86c87
< make %{?_smp_mflags} 
---
> make LIBTOOL=/usr/bin/libtool %{?_smp_mflags} 
159a161
> %exclude %{_libdir}/*.a
Comment 85 Jeffrey Goh 2009-06-23 11:05:24 EDT
Created attachment 349100 [details]
updated spec file works around rpath problem
Comment 86 Jeffrey Goh 2009-06-23 11:10:41 EDT
Created attachment 349101 [details]
updated src rpm to fix rpath problem
Comment 87 Jason Tibbitts 2009-07-10 20:38:49 EDT
It has been over a year since the last comment by the submitter of this ticket.  Karl, if you still intend to submit this package, please address the review commentary.  Otherwise I'll close this ticket soon.

If someone else is going to submit this then please submit your own review ticket and close this one as a duplicate.  We have a lot of package review tickets and not many reviewers, so please help us keep things straight.
Comment 88 Jason Tibbitts 2009-07-17 13:30:25 EDT
No response; closing.