Spec URL: http://leon.fedorapeople.org/files/googsystray/googsystray.spec SRPM URL: http://leon.fedorapeople.org/files/googsystray/googsystray-1.0.0-1.fc12.src.rpm Description: Googsystray is a system tray app for Google Voice, GMail, Google Calendar, Google Reader, and Google Wave. The idea is to be able to keep track of all that stuff without having to keep a bunch of browser tabs open, or constantly checking them. It notifies on new messages, alerts, etc., and provides basic services quickly (Reading or sending a new SMS message, or marking an email read, for example.)
Hello Leon! This is an informal review. I gave the package a try, it compiled, installed and worked but, after the preference dialog, I could not see the icon in the taskbar nor use it in any other way. It might be a problem with the proxy or something with my configuration. I'll try again later on with a little more time. Reviewing the package everything seems ok: # MUST: rpmlint must be run on every package. The output should be posted in the review. $ rpmlint googsystray.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint ../SRPMS/googsystray-1.0.0-1.fc12.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. $ rpmlint ../RPMS/noarch/googsystray-1.0.0-1.fc12.noarch.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. # MUST: The package must be named according to the Package Naming Guidelines . ok # MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. Ok # MUST: The package must meet the Packaging Guidelines . Ok # MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . Ok # MUST: The License field in the package spec file must match the actual license. Ok # MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. Ok # MUST: The spec file must be written in American English. Ok # MUST: The spec file for the package MUST be legible. Ok # MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. Verified: fcd12ed1bd0780943e607c5c43c2f680 googsystray-1.0.0.tar.gz # MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. Ok on Fedora 12 i686 # MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. n.a. # MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense. Ok # MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. Ok # MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. n.a. # MUST: Packages must NOT bundle copies of system libraries. n.a. # MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. n.a. # MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. Ok # MUST: A Fedora package must not list a file more than once in the spec file's %files listings. Ok # MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. Ok # MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). Ok # MUST: Each package must consistently use macros. Ok # MUST: The package must contain code, or permissable content. Ok # MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). n.a. # MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. Ok # MUST: Header files must be in a -devel package. n.a. # MUST: Static libraries must be in a -static package. n.a. # MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). n.a. # MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. n.a. # MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} n.a. # MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built. n.a. # MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. n.a. # MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. n.a. # MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT). ok # MUST: All filenames in rpm packages must be valid UTF-8. ok Please note that I'm not a sponsor and I've just started my experience with Fedora packages. Anyway I find your contribution very interesting. Thanks for your work, Mario
Mario, since you are sponsored, you are now able to make the formal reviews. So I strongly advice you to re-assing this package to yourselr, raise fedora-review flag and proceed with reviewing (actually, you almost finished :) See this link for further details: https://fedoraproject.org/wiki/Package_Review_Process#Reviewer
Ehi cool! then I'll finish reviewing it: * SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. n.a. * SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. It seems that none is available from homepage * SHOULD: The reviewer should test that the package builds in mock. Ok * SHOULD: The package should compile and build into binary rpms on all supported architectures. As the package is marked as noarch, this should be n.a. as well * SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. __NOTE__ After installing and configuring, there is no tray icon/or is invisible and nothing happens. There are a couple of bugs related to this upstream though so it is not a packaging problem: http://sourceforge.net/tracker/?func=detail&aid=2911136&group_id=277278&atid=1177508 * SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. n.a. * SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. n.a. * SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. n.a. * SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. n.a. ***************Summary: Everything seem ok, except for the problem I had in executing it (but see earlier in the SHOULD list). The authors specify dependencies on python >= 2.6 and pygtk2 >= 2.14: http://sourceforge.net/apps/mediawiki/googsystray/index.php?title=Installation I tried to remove the Requires line and the python dependence is picked up correctly but pygtk2 is not. My proposal is to remove python from the Requires and put pygtk2 >= 2.14. But it might be not needed to put the full version as my two f11 and f12 machines have these dependencies already satisfied. Peter, what do you think about this? If the problem in usage and the version are not blockers I think to approve the package. Cheers, Mario
(In reply to comment #3) > ***************Summary: > Everything seem ok, except for the problem I had in executing it (but see > earlier in the SHOULD list). > > The authors specify dependencies on python >= 2.6 and pygtk2 >= 2.14: > http://sourceforge.net/apps/mediawiki/googsystray/index.php?title=Installation > > I tried to remove the Requires line and the python dependence is picked up > correctly but pygtk2 is not. My proposal is to remove python from the Requires > and put pygtk2 >= 2.14. But it might be not needed to put the full version as > my two f11 and f12 machines have these dependencies already satisfied. > > Peter, what do you think about this? If the problem in usage and the version > are not blockers I think to approve the package. I strongly recommend to use version of required components in Requires if upstream mentioned them. So I really don't like the idea to remove python version from Requires (the same for PyGTK). Also this might confuse those packagers, who will package googsystray for other RPM-based distros and who will rely on Fedora srpm as the starting point. One more note, Mario - you mislooked one bundled library, already packaged in Fedora - python-xlib (which is bundled under the name gXlib). This should be either removed (sources should be fixed to properly use the system library) or reporter should argue for usage of the bundled copy (was forked and heavily changed from upstream, for example).
And some more notes: - missing 'Requires' - hicolor-icon-theme (owner of the %{_datadir}/icons/hicolor/*x*/apps/ directories) - unowned directory - %{python_sitelib}/%{name} - Mario, please, try to rebuild the package in Koji (and provide link to the build). Other things looks sane for me.
Thanks Peter for your comments! Hello Leon, so what it seems to be missing now is: - Asking to the developers why gXlib has been included and if could be removed. FYI: I used kdiff3 to check for differences between python-xlib-0.14-5.fc12.noarch.html and the gXlib included version and there are many differences. - Adding to the spec: Requires: python >= 2.6 Requires: pygtk2 >= 2.14 Requires: hicolor-icon-theme - Change %{python_sitelib}/%{name}/* to %{python_sitelib}/%{name}/ As far as I understand this should own the directory and all its files. - I'll post koji's links from home. Peter: if you spot any error in what I told to Leon, please correct me. I still have a lot to learn before doing good revisions :) Mario
(In reply to comment #6) > - Change %{python_sitelib}/%{name}/* to %{python_sitelib}/%{name}/ > As far as I understand this should own the directory and all its files. Yes, exactly. Just for the record - this should be fixed also by the following: %dir %{python_sitelib}/%{name} %{python_sitelib}/%{name}/* > Peter: if you spot any error in what I told to Leon, please correct me. Everything is ok so far.
(In reply to comment #6) > - Asking to the developers why gXlib has been included and if could be removed. > FYI: I used kdiff3 to check for differences between > python-xlib-0.14-5.fc12.noarch.html and the gXlib included version and there > are many differences. I have emailed upstream about this. > - Adding to the spec: > Requires: python >= 2.6 > Requires: pygtk2 >= 2.14 > Requires: hicolor-icon-theme Done. > - Change %{python_sitelib}/%{name}/* to %{python_sitelib}/%{name}/ > As far as I understand this should own the directory and all its files. Done. New spec: http://leon.fedorapeople.org/files/googsystray/googsystray.spec New srpm: http://leon.fedorapeople.org/files/googsystray/googsystray-1.0.0-2.fc12.src.rpm Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1864863
Reply from the author about gXlib: """ python-xlib is an uncommon package. I absolutely despise having to install an obscure dependency (when downloading a source package), and I don't want to make anyone do the same. It's fine with package managers, but sucks from source. So I took the source, cut it down to what I needed, and included it (I really just needed a single feature from it). """ What i could do is in the %install section don't use the python installer but install each file seperately, excluding the gXlib dir and adding the python-xlib package to Requires ... but that seems like an awful lot of work and error prone. I could also just let it sit there in a subdir of the package and IMO it won't conflict with anything. Suggestions?
Hello Leon, sorry for the delay. I was trying to understand with Peter which is the policy for this type of problems. As far as I understand, if modifications are quite big, I can accept it as-is. On the other hand if modifications are a simple renaming to gXlib and removal of the unused bits, then I'm afraid but you'll have to remove gXlib, patch and require python-xlib before I can approve the submission. I'll try and dwell a bit into the code to understand how deep was xlib modified when copied and renamed, and if I could figure an easy patch to decouple from gXlib. You might want to politely ask the developers how would they proceed should they have to remove the gXlib dependency and rely instead on a system wide package, and post the link to the answer. This might be very helpful! Please be patient :) Mario
Yeah, don't worry, thanks for reviewing this pkg :) I had an couple of ideas on how to handle this: 1) the python distutils setup.py tool is very flexible. You can make a subcommand that, for example, will install everything except the gXlib files. To be used for example like this: % setup.py install-without-python-xlib I'm not an expert python programmer, but if the author doesn't have time to make it (or doesn't want to?), i can give it a shot and create a patch. 2) install everything as normal and then rm -rf the gXlib dir. And rpmlint will most likely complain about using dangerous commands. 3) ask the author if he can pretty-please drop python-xlib and have the INSTALL file point to the download link from where they can download the dependency and install it themselves. Although IMO option 3 would be the best way package-wise, i doubt it would go well with the entire Fedora 'motto' which includes freedom. For the developers to create the application the way they want to (why should upstream adjust a perfectly good working application just because we can't package it nicely?).
Hello Leon, I hope you spent a merry Christmas! At last I figured how to patch the program to remove gXLib. It was pretty easy: 1) start with the source dir 2) patch googsystray-1.0.0/googsystray/GMain.py as follows: 144c144 < from gXlib import X, display, XK, protocol --- > from Xlib import X, display, XK, protocol 3) remove googsystray-1.0.0/googsystray: gXlib 4) Patch googsystray-1.0.0/setup.py: 126,132c126 < packages = ['googsystray', < 'googsystray/gXlib', < 'googsystray/gXlib/protocol', < 'googsystray/gXlib/support', < 'googsystray/gXlib/keysymdef', < 'googsystray/gXlib/xobject', < ], --- > packages = ['googsystray'], 5) # yum install python-xlib Then I did a $ python setup.py install $ googsystray and it worked like a charm. When you have time, if you could regenerate the spec (adding Requires: python-xlib) and the source rpm, we can complete the checks and finally approve the package! :) Thanks and regards, Mario
Hello, Mario! I'd bet, that unified diff will be more useful for Leon :) Just send us "diff -u" output instead of plain diff (note -u switch).
Hello Peter, hello Leon, here you are :) [mario@shadow SOURCES]$ diff -ru googsystray-1.0.0_orig/ googsystray-1.0.0/ Only in googsystray-1.0.0_orig/bin: googsystray~ diff -ru googsystray-1.0.0_orig/build/lib/googsystray/GMain.py googsystray-1.0.0/build/lib/googsystray/GMain.py --- googsystray-1.0.0_orig/build/lib/googsystray/GMain.py 2009-11-28 20:22:41.000000000 +0100 +++ googsystray-1.0.0/build/lib/googsystray/GMain.py 2009-12-27 17:18:23.000000000 +0100 @@ -141,7 +141,7 @@ else: - from gXlib import X, display, XK, protocol + from Xlib import X, display, XK, protocol import GIcon, GConf, GV, GReader, GMail, GCal, GContacts, GIPC, GWave Only in googsystray-1.0.0_orig/build/lib/googsystray: gXlib diff -ru googsystray-1.0.0_orig/googsystray/GMain.py googsystray-1.0.0/googsystray/GMain.py --- googsystray-1.0.0_orig/googsystray/GMain.py 2009-11-28 20:22:41.000000000 +0100 +++ googsystray-1.0.0/googsystray/GMain.py 2009-12-27 17:18:23.000000000 +0100 @@ -141,7 +141,7 @@ else: - from gXlib import X, display, XK, protocol + from Xlib import X, display, XK, protocol import GIcon, GConf, GV, GReader, GMail, GCal, GContacts, GIPC, GWave Only in googsystray-1.0.0/googsystray: googsystray Only in googsystray-1.0.0_orig/googsystray: gXlib diff -ru googsystray-1.0.0_orig/setup.py googsystray-1.0.0/setup.py --- googsystray-1.0.0_orig/setup.py 2009-12-01 18:39:01.000000000 +0100 +++ googsystray-1.0.0/setup.py 2009-12-27 17:23:47.000000000 +0100 @@ -123,13 +123,7 @@ author_email = "jim.duchek", url = "http://www.sourceforge.net/projects/googsystray/", data_files = files, - packages = ['googsystray', - 'googsystray/gXlib', - 'googsystray/gXlib/protocol', - 'googsystray/gXlib/support', - 'googsystray/gXlib/keysymdef', - 'googsystray/gXlib/xobject', - ], + packages = ['googsystray'], package_data = { "googsystray" : ["sounds/*","icons/*"] }, scripts = ["bin/googsystray"], long_description = """Really long text here.""", Cheers, Mario
Thanks for the patch and your time spent so far. Yeah, christmas and newyear went by really fine, thanks. Hope you had a nice time as well :) I just started working again today and will pick up all of this as soon as time allows. Upstream released a new version as well, so i'll combine the two and report back here with a fresh srpm.
Hi Mario, Peter, Family issues and work prevented me from picking up where i left off. Should be all back to (relatively) normal again. I have updated everything to the latest version by upstream and (after some small modifications) applied Mario's patch. New files uploaded: SPEC: http://leon.fedorapeople.org/files/googsystray/googsystray.spec SRPM: http://leon.fedorapeople.org/files/googsystray/googsystray-1.1.4-1.fc12.src.rpm PATCH: http://leon.fedorapeople.org/files/googsystray/googsystray-nogxlib.patch RPM: http://leon.fedorapeople.org/files/googsystray/googsystray-1.1.4-1.fc12.noarch.rpm rpmlint shows this error though: $ rpmlint -i /tmp/fedora-pkg/googsystray-1.1.4-1.fc12.noarch.rpm googsystray.noarch: E: explicit-lib-dependency python-xlib You must let rpm find the library dependencies by itself. Do not put unneeded explicit Requires: tags. 1 packages and 0 specfiles checked; 1 errors, 0 warnings. If i don't specify the 'python-xlib' requirement, the package builds fine but then the application doesn't work. I'm not sure what's going wrong here.
Hello Leon, I'm glad to hearing from you and I hope that nothing serious passed to your family. As for the review, I think we are very close to the approval: please note that the python packaging guidelines at: https://fedoraproject.org/wiki/Packaging:Python have been recently updated. In summary: - python-sitelib, python_sitearch macro are now automatically defined in F13, so the first line of the spec should be: %if ! (0%{?fedora} > 12 || 0%{?rhel} > 5) %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")} %endif - You should remove manually the gXlib dir in %prep section, after patching, as an additional security measure to be sure that it's gone at build/exec time %{__rm} -rf googsystray/gXlib/ + Source code is the same as upstream $ md5sum googsystray-1.1.4.tar.gz 2c079c139cdd2e5cbe733816bf27e8ae googsystray-1.1.4.tar.gz $ md5sum rpmbuild/SOURCES/googsystray-1.1.4.tar.gz 2c079c139cdd2e5cbe733816bf27e8ae rpmbuild/SOURCES/googsystray-1.1.4.tar.gz + Builds ok on koji (F12, F13) http://koji.fedoraproject.org/koji/taskinfo?taskID=2066494 http://koji.fedoraproject.org/koji/taskinfo?taskID=2066503 I don't know why rpm does not pick up automatically python-xlib. Maybe Peter knows if we are missing something here. Mario
(In reply to comment #17) > - python-sitelib, python_sitearch macro are now automatically defined in F13, > so the first line of the spec should be: -snip- Gotcha. I'll modify the spec accordingly. > - You should remove manually the gXlib dir in %prep section, after patching, as > an additional security measure to be sure that it's gone at build/exec time Hm. I don't see the extra benefit of removing the directory, since setup.py won't include it in the build anyway. And it's not in the %files section, so if setup.py will change at some point in the future, the files don't get included anyway. But i guess that apart from the warning from rpmlint (dangerous cmd), it won't do any harm in removing the gXlib dir in %prep. > I don't know why rpm does not pick up automatically python-xlib. Maybe Peter > knows if we are missing something here. I'll post a msg to the list, to see if someone else has some insight. It's been 3 months since i first posted this review request, and Peter could be busy with other things.
Okay, got a reply [1] from Tom Callaway: """ Safe to ignore. rpmlint assumes all dependencies which contain the explicit string "lib" are traditional library (with .so files inside) packages and can be autodetected, as opposed to explicitly stated. In your case, the explicit Requires is correct. """ I have updated the SRPM and SPEC files: http://leon.fedorapeople.org/files/googsystray/googsystray.spec http://leon.fedorapeople.org/files/googsystray/googsystray-1.1.4-2.fc12.src.rpm [1] http://lists.fedoraproject.org/pipermail/devel/2010-March/133955.html
Hello Leon! You are right: removing the entire dir is not necessary, but it sometimes helped me to pick up include/linking issue, and was for this reason that I suggested it. Maybe for a python package was not really necessary. Everithing else seems good so the package is: APPROVED congratulations and thanks for your work, Mario
New Package CVS Request ======================= Package Name: googsystray Short Description: A system tray application for various Google apps Owners: leon Branches: F-12 F-13
CVS done (by process-cvs-requests.py).
googsystray-1.1.4-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/googsystray-1.1.4-2.fc13
googsystray-1.1.4-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
@Mario: Some things got overlooked during this review, please read my comments below. No need to worry, this is why we have sponsors and public mailing lists for the commits. @Leon: Please don't use macros for trivial things like %{__rm} or %{__python}. This was discussed on devel list recently, please read the thread that evolted after this mail: http://lists.fedoraproject.org/pipermail/devel/2010-March/133466.html %{__python} setup.py install --root %{buildroot} should normally be %{__python} setup.py install -O1 --skip-build --root %{buildroot} if you take a look at the buildlog, you will see that the build step is run twice The locales are not built built but the precompiled mo files are taken. You will need to build them which required gettext and intltool. %{_datadir}/applications/googsystray-settings.desktop %{_datadir}/applications/googsystray.desktop These files should have been installed desktop-file-install or at least be validated with desktop-file-validate. see https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files %{_datadir}/icons/googsystray.png This file should go into %{_datadir}/pixmaps/ %{_datadir}/icons/hicolor/16x16/apps/googsystray.png %{_datadir}/icons/hicolor/32x32/apps/googsystray.png %{_datadir}/icons/hicolor/48x48/apps/googsystray.png %{_datadir}/icons/hicolor/64x64/apps/googsystray.png You should use wildcards here: %{_datadir}/icons/hicolor/*/apps/googsystray.png
Hi Christoph, Thanks for the comments. I will modify the SPEC file accordingly and upload it as soon as i can.
All suggestions applied: SPEC: http://leon.fedorapeople.org/files/googsystray/googsystray.spec SRPM: http://leon.fedorapeople.org/files/googsystray/googsystray-1.1.4-3.fc12.src.rpm Note: since the python setup.py installs the icon file in %{_datadir}/icons/googsystray.png , i chose to rm it in the %install section No idea why the build line was there twice. I don't have it in my own tree. Must have slipped in at some point.
(In reply to comment #27) > All suggestions applied: Leon, just push new packages into repository - no need to upload them at fedorapeople :)
Yeah, i know ;) but i wanted to make sure the package is conform Christoph's suggestions before pushing update after update.
(In reply to comment #27) > All suggestions applied: You are still using the prebuilt locales. I think they will be built when if you remove them. There also seems to be an option to overwrite them, take a look at setup.py. > Note: since the python setup.py installs the icon file in > %{_datadir}/icons/googsystray.png , i chose to rm it in the %install section I would prefer a patch here because this is something that you can also send to upstream. In Fedora we try to take care of upstreaming our changes. > No idea why the build line was there twice. It's not there twice, but --skip-build was missing in the setup.py call in %install.
(In reply to comment #30) > You are still using the prebuilt locales. I think they will be built when if > you remove them. There also seems to be an option to overwrite them, take a > look at setup.py. Okay, i have included an extra line in the %build section: python setup.py i18n --force right before the 'build' command. Comparing the resulting locale files' timestamp, they now seem to be built correctly. > > Note: since the python setup.py installs the icon file in > > %{_datadir}/icons/googsystray.png , i chose to rm it in the %install section > > I would prefer a patch here because this is something that you can also send to > upstream. In Fedora we try to take care of upstreaming our changes. Could you help me with the reason for this? I'm willing to contact upstream and ask him for the changes, but i'm not sure why :) From http://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout i looked at http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA but can't find the pixmaps dir (or icon dir, for that matter) specified. > > No idea why the build line was there twice. > > It's not there twice, but --skip-build was missing in the setup.py call in > %install. Now i see what you meant. I've modified the line in the %install section to match your suggestion. http://leon.fedorapeople.org/files/googsystray/googsystray.spec