Spec URL: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec SRPM URL: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.12-1.fc11.src.rpm Description: RabbitVCS is a set of graphical tools written to provide simple and straightforward access to the version control systems you use. Currently, it is integrated into the Nautilus file manager and only supports Subversion, but their goal is to incorporate other version control systems as well as other file managers.
Hi, I'm not (yet) a packager, anyway I'd like to make an informal review of your package. * The spec. file in your SRPM is not the same than the one you gave the URL. I considered the last one for this review (the .spec refers to the version 0.12.1 of rabbitvcs whereas the SRPM refers to 0.12). Please upload an updated version of your SRPM. * You should use "%global" [1] instead of "%define" in %define title RabbitVCS * Your BuildRoot looks very strange. Why not using the standard way to declare it? BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) * It seems there is no arch-dependent file installed by your package so you should add in your .spec header this line : BuildArch: noarch [1] https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define Once your SRPM updated, the review will be continued with more details. [1] https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
Thanks for the review, and sorry for uploading an old SRPM. Here's the new SRPM: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.12.1-1.fc12.src.rpm The updated spec is on the same place as before: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec As for the noarch, nautilus-python wants to load /usr/lib/libpython2.6.so even on x86_64 (instead of /usr/lib64/libpython2.6.so), which is why I didn't make the package noarch. Nautilus-python itself isn't noarch, and won't load the proper libpython. See bug 474428
Thanks for the update. You're right indeed about the package architecture, sorry, I talked by the way with the phatch maintener who is exactely in the same case than you (a full-Python application with a Nautilus plugin that must be in %{_libdir}/) :-) Anyway you should had this line at the top of your spec file: %global debug_package %{nil} Otherwise a useless (and empty!) debug package will be generated In your %install section, you launch the installation with this command: %{__python} setup.py install -O1 --root $RPM_BUILD_ROOT Is there any reason to specify the « -O1 » option? Some optimizations at the installation are really required here? About the BuildRequires, neither gtk2-devel nor nautilus-python maybe required for the build. pygtk2 and python-devel are enough here. By the way, in the Requires, you don't need also python, it is detected automatically as a Requires by rpmbuild. You don't need also to add pyobject2 as a Requires since pygtk2 is always declared as a Requires and requires pyobject2. I've rebuild your package and rpmlint complains about some issues: - on your SRPM: rabbitvcs.src: W: strange-permission rabbitvcs-0.12.1.tar.gz 0777 rabbitvcs.src: W: strange-permission rabbitvcs.spec 0777 you should remove the executables bits from this files in your build root. - on your generated RPM: rabbitvcs.x86_64: W: obsolete-not-provided nautilussvn See http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages rabbitvcs.x86_64: E: no-binary It is a false-positive because of the Nautilus extension issue you explained above, no matter I think ;) rabbitvcs.x86_64: E: non-executable-script /usr/lib/python2.6/site-packages/rabbitvcs/debug/ipython_view.py 0644 /usr/bin/python rabbitvcs.x86_64: E: non-executable-script /usr/share/rabbitvcs/do-rabbitvcs-restart-nautilus 0644 /bin/sh This file has a shebang, you should remove it using sed as described here: http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Remove_shebang_from_files
I forgot also 2 points ^^ * Your icons scriplets look strange... Why not referring to the specific guidelines? http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Icon_Cache * You should also maybe tag of the files in %{_defaultdocdir}/%{name}/* (here AUTHORS and MAINTAINERS files) as "%doc", like this in your %files section: %doc %{_defaultdocdir}/%{name}/* Don't forget by the way to set the package as the owner of the %{_defaultdocdir}/%{name}/ directory by adding this in %files: %dir %{_defaultdocdir}/%{name}/
Sorry for the delay. I don't understand how to generate the SRPM to fix the permission errors. I understand I have to set the permissions to 0644, but I don't understand *where* on the spec do I specify it. I uploaded a newer spec with all your considerations, along with a new SRPM, that I placed here: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.12.1-2.fc12.src.rpm Using ExcludesArch while Bug 474428 is solved, after that, I'll make the package noarch. Thanks for your time.
Good initiative to refer to the bug 474428 in your .spec file -:) Anyway I don't think it's a good thing that the ExcludeArch is a good idea here. First it is not appropriated since this tag is only used when a package cannot be build/doesn't work in a particular arch (and it's not the case here ^^). Moreover, you exclude 64-bit users like me who want that very useful package ^^. And finally, there's several packages that have the same issue (I talked about phatch above) and that are arch-specific whereas they don't contain any binary. You should remove ExcludeArch and leave things like this for the arch. of your package :-) Be careful not to mix %{buildroot} and $RPM_BUILD_ROOT in your spec file: https://fedoraproject.org/wiki/Packaging/Guidelines#Using_.25.7Bbuildroot.7D_and_.25.7Boptflags.7D_vs_.24RPM_BUILD_ROOT_and_.24RPM_OPT_FLAGS About the doc: since the installer installs itself the files AUTHORS, COPYING and MAINTAINERS to %{_defaultdocdir}/%{name}, I suggested before to flag them as %doc by replacing this line in your %files section: %{_defaultdocdir}/%{name}/* By %dir %{_defaultdocdir}/%{name} %doc %{_defaultdocdir}/%{name}/* (and by this way, the fact that %{_defaultdocdir}/%{name} is not owned by your package is solved). But if you use this like you did: %doc AUTHORS COPYING MAINTAINERS rpmbuild will automatically copy them from your build directory into %{_defaultdocdir}/%{name}-%{version} and you'll have duplicate files in your RPM. If you keep « %doc AUTHORS COPYING MAINTAINERS », you should exclude the %{_defaultdocdir}/%{name} directory from being included in RPM by removing it for example in %install ;-)
Ping, could you address the issues mentioned in comment #6? Fix for bug #474428 is now in updates-testing for F-12 and newer, so you can remove ExcludeArch: x86_64. Also, please update to the new upstream RabbitVCS 0.13 release.
I updated the Spec and SRPM. Spec URL: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec SRPM URL: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.13-1.fc12.src.rpm I don't think I should add "Requires: nautilus-python >= 0.5.2", since it works with older nautilus-python on 32-bit systems. There's been one gigantic packaging change as of 0.13, and I'm not sure if I handled it properly. Rabbitvcs is now handing out an individual tarball for each plugin, so I added a source for each plugin, to generate subpackages. Otherwise, we'd have to get a basically useless rabbitvcs package, then approve each individual rabbitvcs plugin... Feedback regarding this change would be very welcome.
(In reply to comment #8) > I don't think I should add "Requires: nautilus-python >= 0.5.2", since it works > with older nautilus-python on 32-bit systems. I actually think it would be better to have versioned Requires >= 0.5.2: this way people who haven't applied all updates can just do "yum install rabbitvcs" and the new nautilus-python 0.5.2 automatically gets pulled in. It's pretty much required on x86_64, and having that require doesn't make anything worse for people who run 32-bit Fedora. > There's been one gigantic packaging change as of 0.13, and I'm not sure if I > handled it properly. > > Rabbitvcs is now handing out an individual tarball for each plugin, so I added > a source for each plugin, to generate subpackages. Otherwise, we'd have to get > a basically useless rabbitvcs package, then approve each individual rabbitvcs > plugin... > > Feedback regarding this change would be very welcome. I'm not sure why they would want to split out tarballs like that. The split would make sense if the components were independent, but right now they aren't: you probably need to keep all the tarballs strictly at the same version. Also, most of the plugin tarballs only contain ONE python file + readme, which in my opinion should just get a separate subdirectory in the main tarball. Maybe you could contact upstream and ask them about this change? I'm pretty sure it'd make life easier for you if they distributed it all in one tarball. Alternatively, if they want to keep the split tarballs, maybe they could also release a rabbitvcs-0.13.tgz with all the plugins bundled together, but keep the split ones too?
I added the requires for nautilus-python 0.5.2 (Same URLs as before) Spec URL: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec SRPM URL: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.13-1.fc12.src.rpm Adam Plumb (Upstream) is already CC'd to this review request, said he'd upload a tarball later, so I'll update this later when I repackage it. The reason for the plugin tarball split was the case of possible bugs on a particular plugin. They didn't want to reissue a separate tarball for rabbitvcs-nautilus, etc, if the only broken component was rabbitvcs-gedit, for instance.
New Spec / SRPM: Spec URL: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec SRPM URL: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.13-2.fc12.src.rpm Uses the new tarball that includes all the clients inside it.
This is mostly just nitpicking, but python_sitearch macro isn't used anywhere in this spec, so there's no need to define it in here. Also, the newly-approved Fedora python guidelines suggest to wrap the python_sitearch/python_sitelib definitions inside a conditional [1] like this: %if ! (0%{?fedora} > 12 || 0%{?rhel} > 5) ... insert python_sitelib definition here %endif [1] https://fedoraproject.org/wiki/Packaging:Python#Macros > Summary: Integrated Subversion support for Nautilus This is the summary for the main package which just contains the core components, but not the actual Nautilus integration. For Nautilus support one has to install rabbitvcs-nautilus instead. Can you rewrite the summary so that it doesn't sound like it's Nautilus extension package? Something like "Graphical user interface to version control systems" (I stole it from Debian package [2]) [2] http://svn.debian.org/viewsvn/python-modules/packages/rabbitvcs-core/trunk/debian/control?view=markup > URL: http://code.google.com/p/rabbitvcs/ Maybe http://www.rabbitvcs.org would be better? > BuildRequires: pygtk2-devel >= 2.12 Is pygtk2-devel really needed at build time? > BuildRequires: python-devel >= 2.5 You can drop the >= 2.5. All current Fedora versions have at least Python 2.6. Also, Fedora python guidelines suggest to BR python2-devel, not python-devel. > Provides: nautilussvn = 0.12 > Provides: rabbitvcs-core > Obsoletes: nautilussvn <= 0.13 For preserving upgrade path from the original vendor's rpms, you need obsoletes/provides for nautilussvn and rabbitvcs-core. Something like this: Provides: nautilussvn = %{version}-%{release} Obsoletes: nautilussvn < 0.13 Provides: rabbitvcs-core = %{version}-%{release} Obsoletes: rabbitvcs-core < 0.13-2 Note that rabbitvcs-core-0.13-1.fc12 is the last version available at rabbitvcs.org, so we need to make sure we obsolete that. > Requires: pygtk2 >= 2.12 No need to specify the version, as pygtk2-2.12 is available since F-8. I think you are missing Requires: pygtk2-libglade here, can you verify that? %package nautilus > Summary: rabbitvcs plugin for nautilus Summary should be capitalized. I have some links to various Debian rabbitvcs packages with really nicely written summaries/descriptions. Take a look, maybe there's something you can reuse here: http://svn.debian.org/viewsvn/python-modules/packages/rabbitvcs-core/trunk/debian/control?view=markup http://svn.debian.org/viewsvn/python-modules/packages/rabbitvcs-nautilus/trunk/debian/control?view=markup http://svn.debian.org/viewsvn/python-modules/packages/rabbitvcs-gedit/trunk/debian/control?view=markup http://svn.debian.org/viewsvn/python-modules/packages/rabbitvcs-core/trunk/debian/control?view=markup > %package nautilus > Requires: rabbitvcs-core = %{version} If you don't have rabbitvcs-core package (currently it's just a virtual provide), please require the actual package name instead (rabbitvcs). Also, the require should be tightened with -%{release} for subpackages which are built from the same srpm: Requires: rabbitvcs = %{version}-%{release} > %package nautilus > Requires: nautilus >= 2.22 > Requires: nautilus-python >= 0.5.2 > Requires: dbus-python > 0.80 The nautilus-python versioned require is needed, as the older version which shipped in F-11 and F-12 GA is buggy. But are the versioned requires really needed for others? > %package nautilus-old We don't have nautilus-1 in current Fedora releases and this subpackage should just be dropped. > %package thunar > Requires: thunarx-python >= 0.2.0 thunarx-python isn't in Fedora. Have you filed a review request for that yet? If yes, please mark thunarx-python review request as blocking this one. If not, lets drop or comment out that subpackage as well. > %setup -n %{name}-%{version} Please use the -q argument. -n %{name}-%{version} is the default, so you can just use: %setup -q > %{__python} setup.py install --root $RPM_BUILD_ROOT Please add --skip-build: %{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT > mkdir -p $RPM_BUILD_ROOT%{_libdir}/nautilus/extensions-2.0/python/ > mv clients/nautilus/%{title}.py $RPM_BUILD_ROOT%{_libdir}/nautilus/extensions-2.0/python/%{title}.py You are installing in %{_libdir}, but the whole package is marked as noarch. Subpackages which install into %{_libdir} certainly can't be noarch. I'm not sure how it's best to fix this. The main package (old -core) would be a good candidate for being noarch, but I don't think there's a way to mark that noarch without making the whole package build noarch. I can think of two options: a) not mark the whole package as noarch, but instead introduce the -core subpackage and mark that one as noarch, or b) not use noarch at all. Any ideas? You mentioned that Toshio helped you with this package, maybe he can help with the noarch problem?
That's an extremely long reply. I think I managed to get all points covered. New Python Macro - Python Sitearch: Done. URL, Summaries and Descriptions: Done. BuildRequires and versions: Done. Provides and Obsoletes: Fixed Added libglade requirement. Removed the nautilus-old package, as it obviously won't be used by Fedora, however I'll still build a "nautilus-old" package so CentOS / RHEL users can still use rabbitvcs. It would be hosted at their Website though. Regarding thunar, and the thunarx-python requirement? I'll comment it out for now. If noone else is interested, i'll start a review request for thunarx-python. I'd rather not have that block RabbitVCS though. Fixed %setup -q Added --skip-build on the setup.py install Removed the "noarch" directive, as you're right, %{_libdir} is /usr/lib64 on 64bit OS, which means it isn't really 'noarch'. I'll talk to Toshio when I get the change (Probably until Monday), but in the meantime, I guess rabbitvcs-core will be built for all archs.
I took a look at http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec where you seem to have updated the spec. Please post new spec and srpm links every time you update something. > # Installing Nautilus extension > mkdir -p $RPM_BUILD_ROOT%{_libdir}/nautilus/extensions-2.0/python/ > mv clients/nautilus/%{title}.py $RPM_BUILD_ROOT%{_libdir}/nautilus/extensions-2.0/python/%{title}.py Use "cp" or "install" instead, moving files like that breaks rpm's --short-circuit -bi, for example. You updated -nautilus subpackage to use fully versioned dependency rabbitvcs-core = %{version}-%{release}, can you do the same for other subpackages too?
There's a new rabbitvcs 0.13.1 point release available.
ping?
Sorry for the extremely long delay. SPEC: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec SRPM: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.13.1-1.fc12.src.rpm RPMs: http://nushio.fedorapeople.org/rabbitvcs/i686/ Changes: Using cp instead of mv to prevent the --short-cicuit breakage Removing "Obsoletes" Updated to the latest RabbitVCS, 0.13.1
I think it would be a good idea to rename rabbitvcs subpackage to rabbitvcs-core for the following reasons: 1) the name "rabbitvcs-core" is more consistent with Debian package naming; 2) we could drop rabbitvcs-core Obsoletes/Provides which are right now there to preserve upgrade path from upstream binary packages; 3) currently "rabbitvcs" package cannot be built as noarch as it's the main package, but renaming it to "rabbitvcs-core" would fix that; 4) I believe it's confusing for end users if a package is named "rabbitvcs". If I see a package named like that, I'd expect it to actually provide some functionality. In reality one needs to install one of the -nautilus, -gedit etc subpackages for basic functionality. Renaming the package to -core would make it more obvious that it only contains shared components. What do you think? There was a recent thread on fedora-devel list about -core subpackages and metapackages: http://lists.fedoraproject.org/pipermail/devel/2010-April/134735.html I am really not sure if it's a good idea, but perhaps there should also be a metapackage which pulls in all other rabbitvcs-* subpackages. P.S. Can you fix the commented out thunar sections wrt Requiring fully versioned main package and the mv -> cp change?
Ok, I think I got it: I wasn't sure what "wrt" is, so I just fixed the typos but left the commented out sections in. SPEC: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec SRPM: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.13.1-2.fc13.src.rpm Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2211869 Changes: added rabbitvcs-core, which is noarch. Moved the binaries to rabbitvcs-core Fixed the typos on the thunar comments
You can now also drop: Obsoletes: rabbitvcs-core < 0.13-2 I'd suggest to move the remaining items in rabbitvcs package to -core: -f %{title}.lang %doc AUTHORS COPYING MAINTAINERS %{_datadir}/%{name}/ The Requires of the rabbitvcs package now belong to -core: Requires: pygtk2 Requires: pysvn Requires: python-configobj Requires: subversion Requires: meld Requires: nautilus-python >= 0.5.2 Requires: pygtk2-libglade The following Provides and Obsoletes should probably go to -nautilus subpackage instead to ensure smooth update experience: #RabbitVCS is the new name for NautilusSVN. Provides: nautilussvn = %{version}-%{release} Obsoletes: nautilussvn < 0.13 -core subpackage lacks defattr(). %post/%postun/%posttrans need to be changed to run for -core subpackage.
-core subpackage also doesn't need Provides: rabbitvcs-core
SPEC: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec SRPM: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.13.1-2.fc13.src.rpm Did the changes you mentioned. I had completely forgotten to move the Requires from rabbitvcs to rabbitvcs-core, and I never considered the obsoletes/provides on the -nautilus subpackage. Fixed the defattrs, and fixed the post/un/trans
-core subpackage has Requires: rabbitvcs, but rabbitvcs package itself is not built any more, so it's now an unresolved dep. -cli subpackge can also be built as noarch. Now that rabbitvcs subpackage is no longer built, the %description line just below BuildRequires is probably best thought of as SRPM description. Currently it reads "Provides the rabbitvcs backend for various user interfaces.". Perhaps something like "RabbitVCS is a set of graphical tools written to provide simple and straightforward access to the version control systems you use." would be better. I took a look at http://code.google.com/p/rabbitvcs/downloads/list and it appears that they have rabbitvcs-0.13.1-1.fc12.i686.rpm available (probably taken from this review request). Should rabbitvcs-core have Provides/Obsoletes to properly replace that package?
Hey Kalev, I've been providing upstream with their current RPMs based on an older snapshot of the rabbitvcs spec (In fact, I've been uploading them to the downloads list) I don't think it requires provides/obsoletes, as a simple version check would make this package newer than the other one, and replace it properly. I uploaded a newer spec/srpm, making rabbitvcs-cli noarch. The rest can't be noarch though. I removed the unresolved dependency for rabbitvcs. It resolved here because I wasn't properly removing and installing the rpms. I'll get a VM to properly test the RPMs on a clean install. SPEC: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec SRPM: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.13.1-2.fc13.src.rpm Thanks a lot for your time and observations.
(In reply to comment #24) > I don't think it requires provides/obsoletes, as a simple version check would > make this package newer than the other one, and replace it properly. A simple version check would update the package if the name remained the same, but that's not the case here. What used to be rabbitvcs is now rabbitvcs-core. If someone installed rabbitvcs + rabbitvcs-nautilus from upstream page and now updates to the newer version in Fedora repos, the following will happen: 1) rabbitvcs package has no update so it will stay on the upstream version 2) rabbitvcs-nautilus will be updated 3) rabbitvcs-nautilus will pull in rabbitvcs-core 4) yum transaction check will fail because files from old rabbitvcs upstream package and rabbitvcs-core from Fedora repos will conflict. Proper way to fix it is by adding Obsoletes to rabbitvcs-core, but the question is if you want to preserve clean upgrade path from upstream packages or not. > I removed the unresolved dependency for rabbitvcs. It resolved here because I > wasn't properly removing and installing the rpms. I'll get a VM to properly > test the RPMs on a clean install. Yeah, I think it'd be a good idea to install packages from upstream page and try to update them to make sure they can be properly updated without having to uninstall anything by hand. > Thanks a lot for your time and observations. Glad to be of help.
Fedora review rabbitvcs-0.13.1-2.fc13.src.rpm 2010-05-27 + OK ! needs attention rpmlint output: rabbitvcs-cli.noarch: W: no-documentation rabbitvcs-cli.noarch: W: no-manual-page-for-binary rabbitvcs rabbitvcs-nautilus.i686: W: only-non-binary-in-usr-lib rabbitvcs-nautilus.i686: W: no-documentation rabbitvcs-core.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/rabbitvcs/debug/ipython_view.py 0644L /usr/bin/python rabbitvcs-gedit.i686: W: only-non-binary-in-usr-lib rabbitvcs-gedit.i686: W: no-documentation rabbitvcs.src: W: strange-permission rabbitvcs.spec 0777L rabbitvcs.src:64: W: macro-in-comment %package rabbitvcs.src:67: W: macro-in-comment %{version} rabbitvcs.src:67: W: macro-in-comment %{release} rabbitvcs.src:72: W: macro-in-comment %description rabbitvcs.src:114: W: macro-in-comment %{_libdir} rabbitvcs.src:115: W: macro-in-comment %{title} rabbitvcs.src:115: W: macro-in-comment %{_libdir} rabbitvcs.src:115: W: macro-in-comment %{title} rabbitvcs.src:157: W: macro-in-comment %files rabbitvcs.src:158: W: macro-in-comment %defattr rabbitvcs.src:159: W: macro-in-comment %{_libdir} rabbitvcs.src:159: W: macro-in-comment %{title} rabbitvcs.src: W: invalid-url Source0: http://rabbitvcs.googlecode.com/files/rabbitvcs-0.13.1.tar.gz HTTP Error 404: Not Found 5 packages and 0 specfiles checked; 1 errors, 20 warnings. E: non-executable-script is because ipython_view.py has python shebang. I don't think it's something that should be fixed up in Fedora's rpm package, but you can mention it to upstream instead. ! rabbitvcs.src: W: strange-permission rabbitvcs.spec 0777L Chmod the .spec file to 644. Other rpmlint warnings can be ignored. + The package is named according to the Package Naming Guidelines. + Spec file name matches the base package name + The package follows the Packaging Guidelines + The package is licensed with a Fedora approved license and meets the Licensing Guidelines. + The license field in the spec file matches the actual license + The package contains the license file (COPYING) + Spec file is written in American English + Spec file is legible + Upstream sources match sources in the srpm. md5sum: 861590f60bf2367a92861e44c1852b0d rabbitvcs-0.13.1.tar.gz 861590f60bf2367a92861e44c1852b0d Download/rabbitvcs-0.13.1.tar.gz + The package builds in koji n/a ExcludeArch bugs filed + BuildRequires look sane n/a The spec file handles locales properly + Package does not bundle copies of system libraries n/a Does not use Prefix: /usr + Package owns all directories it creates + No duplicate files in %files + Permissions are properly set and %files has %defattr + %clean contains rm -rf $RPM_BUILD_ROOT + Consistent use of macros + Package contains code or permissible content n/a Large documentation files should go in -doc subpackage + Files marked %doc should not affect package n/a Header files should be in -devel n/a Static libraries should be in -static n/a Library files that end in .so must go in a -devel package n/a -devel must require the fully versioned base n/a Packages should not contain libtool .la files n/a Packages containing GUI apps must include %{name}.desktop file ! Packages must not own files or directories owned by other packages hicolor-icon-theme already owns these directories: /usr/share/icons/hicolor/scalable/actions /usr/share/icons/hicolor/scalable/apps /usr/share/icons/hicolor/scalable/emblems To fix that, I'd suggest to change the glob from: %{_datadir}/icons/hicolor/scalable/* to: %{_datadir}/icons/hicolor/scalable/*/*.svg + Filenames must be valid UTF-8
Talked with upstream about the 'shebang' issue. I patched it out for 0.13.1, but it's been fixed upstream: http://code.google.com/p/rabbitvcs/source/detail?r=2529 Now Obsoletes rabbitvcs since I do care about the users that installed rabbitvcs rpms I provided :) Changed the glob to %{_datadir}/icons/hicolor/scalable/*/*.svg Fixed the spec permissions SPEC: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs.spec SRPM: http://nushio.fedorapeople.org/rabbitvcs/rabbitvcs-0.13.1-3.fc13.src.rpm rpmlint seems to complain that: rabbitvcs.src: W: invalid-url Source0: http://rabbitvcs.googlecode.com/files/rabbitvcs-0.13.1.tar.gz HTTP Error 404: Not Found However, the file *is* there, and I can download it from the same computer I used rpmlint. Weird, huh?
(In reply to comment #27) > rpmlint seems to complain that: > rabbitvcs.src: W: invalid-url Source0: > http://rabbitvcs.googlecode.com/files/rabbitvcs-0.13.1.tar.gz HTTP Error 404: > Not Found > > However, the file *is* there, and I can download it from the same computer I > used rpmlint. Weird, huh? No idea how rpmlint does the check, but I've seen it report the same bogus invalid-url warning for other googlecode urls too. The package looks good now. APPROVED
New Package CVS Request ======================= Package Name: rabbitvcs Short Description: RabbitVCS is a set of graphical tools written to provide simple and straightforward access to the version control systems you use. Owners: nushio Branches: F-12 F-13 devel InitialCC:
Just double checking: the ticket summary says "RabbitVCS", the CVS request says "rabbitvcs". Please verify that you want the package name to be lower case.
I think lowercase would be better. I usually download packages just doing "fedora-cvs packagename", and it wouldn't find RabbitCVS, only rabbitvcs. So, rabbitcvs please. Should I rename the ticket name? Thanks for double checking :)
Our scripts complain if the package name in the bugzilla ticket doesn't match the package name in the CVS request. This helps catch typos.
CVS done (by process-cvs-requests.py).
Thanks Jason! rabbitvcs packages are on the way. :)
rabbitvcs-0.13.1-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/rabbitvcs-0.13.1-3.fc12
rabbitvcs-0.13.1-3.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/rabbitvcs-0.13.1-3.fc13
rabbitvcs-0.13.1-3.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rabbitvcs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/rabbitvcs-0.13.1-3.fc13
rabbitvcs-0.13.1-3.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rabbitvcs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/rabbitvcs-0.13.1-3.fc12
rabbitvcs-0.13.2-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/rabbitvcs-0.13.2-1.fc12
rabbitvcs-0.13.2-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/rabbitvcs-0.13.2-1.fc13
rabbitvcs-0.13.2-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rabbitvcs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/rabbitvcs-0.13.2-1.fc12
rabbitvcs-0.13.2-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rabbitvcs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/rabbitvcs-0.13.2-1.fc13
rabbitvcs-0.13.2-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
rabbitvcs-0.13.2-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
I was wondering if the package owner (nushio = Juan) could maintain this package in EPEL as well. Only EPEL 6 would be necessary, since rabbitvcs requires python2.6, which RHEL 5 does not have. I am setting the needinfo flag to ? in hopes that someone will see this bug. :) Thanks!
This is the second attempt to contact the maintainer of rabbitvcs, nushio (= Juan). Please see comment 45. Thanks!
Adding needinfo flag...
Package Change Request ====================== Package Name: rabbitvcs New Branches: el6 Owners: limb nushio
Git done (by process-git-requests).
This package is live for EPEL 6, and works perfectly! Thanks a lot!
Excellent! Very welcome! I've also built thunarx-python which is needed for this.
Package Change Request ====================== Package Name: rabbitvcs New Branches: epel7 Owners: cicku nushio limb
Would it be possible to have 0.16 on EPEL 6?