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...
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
imho the summary tag should be more descriptive than only repeating the package name.
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.
In fact, turns out the gdk-pixbuf BR is bogus.
It seems that /usr/lib64/libslab.so.0.0.0 creates a comflict with control-center-2.18.0-20.fc7
GPL is not a valid license tag anymore: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#head-f21ae23bf2f278444e2c385463cfa74a502396b8
And Source0: should be a full URL: http://fedoraproject.org/wiki/Packaging/SourceURL
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.
I am using the release 367 on fedora 8 from svn, without any patch and I hadn't any bug yet.
Well, what is the status of this bug?
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.
Any updates on this, or updated packages for testing on Fedora 8?
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
so any new news on this? I wanted to try rebuilding this but gave errors on updated Fedora 8.
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???
Oh I forgot to mention that what we're looking for could be org.freedesktop.NetworkManager.getDevices() that indeed returns an array of devices.
ok all obsolete now sorry. revision 448 has fixed it.
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 :)
(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!
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
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).
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.
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.
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 :)
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.
(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.
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.
> 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.
(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.
(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.
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?
(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.
(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.
(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.
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.
(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.
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
(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.
(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.
(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.
(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.
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.
(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? :|
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.
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.
(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.
(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.
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
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.
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)
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 > (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 :(
Sorry I've uploaded the src.rpm now :)
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
With the latest NetworkManager errata pushed out, this works for F8 too, now.
you might want to add this little patch to make it compatible to the xdg user directories.
Created attachment 313646 [details] patch for xdg-user-dirs
The latest NetworkManager broke it. The applet won't even load on FC9 or FC8.
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?
@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.
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.
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.
(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.
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.
I'm posting the x86_64 RPMs first. 32 bit RPMs out shortly. Follow instructions in http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-3/index.html http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-3/gnome-main-menu-0.9.12-3.src.rpm http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-3/gnome-main-menu-0.9.12-3.x86_64.rpm http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-3/gnome-main-menu-debuginfo-0.9.12-3.x86_64.rpm http://www.linux.com.sg/fedora10/gnome-main-menu/0.9.12-3/gnome-main-menu-devel-0.9.12-3.x86_64.rpm
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.
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 /*.
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
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.
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.
Ping?
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.
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
(In reply to comment #72) > 5. Banshee Should probably be Rhythmbox as this is the default media player in Fedora AFAIK.
how about using those that are set as preferred applications in gnome instead of hardcoding applications again?
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...
The Debian patches may be a good places to start: http://patch-tracking.debian.net/package/gnome-main-menu/0.9.12-3
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.
Ken Crandall, If you are submitting it for review, please provide the spec file and srpm instead of a patch.
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
Created attachment 348889 [details] FC11 src rpm Here's the src rpm that builds for Fedora 11
Created attachment 348890 [details] SPEC file for Fedora 11 to build gnome-main-menu
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.
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
Created attachment 349100 [details] updated spec file works around rpath problem
Created attachment 349101 [details] updated src rpm to fix rpath problem
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.
No response; closing.