Bug 542715 - Review Request: rabbitvcs - Easy version control
Summary: Review Request: rabbitvcs - Easy version control
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 474428
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-30 16:24 UTC by Juan Manuel Rodriguez
Modified: 2014-06-12 20:33 UTC (History)
10 users (show)

Fixed In Version: rabbitvcs-0.13.2-1.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-07 22:21:48 UTC
Type: ---
gwync: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Juan Manuel Rodriguez 2009-11-30 16:24:24 UTC
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.

Comment 1 Mohamed El Morabity 2009-12-14 16:56:49 UTC
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

Comment 2 Juan Manuel Rodriguez 2009-12-14 21:46:34 UTC
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

Comment 3 Mohamed El Morabity 2009-12-15 01:58:07 UTC
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

Comment 4 Mohamed El Morabity 2009-12-15 10:47:02 UTC
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}/

Comment 5 Juan Manuel Rodriguez 2009-12-17 19:31:39 UTC
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.

Comment 6 Mohamed El Morabity 2009-12-19 11:15:21 UTC
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 ;-)

Comment 7 Kalev Lember 2010-03-18 11:13:07 UTC
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.

Comment 8 Juan Manuel Rodriguez 2010-03-18 21:26:47 UTC
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.

Comment 9 Kalev Lember 2010-03-19 08:14:17 UTC
(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?

Comment 10 Juan Manuel Rodriguez 2010-03-19 16:24:38 UTC
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.

Comment 11 Juan Manuel Rodriguez 2010-03-19 18:24:29 UTC
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.

Comment 12 Kalev Lember 2010-03-20 16:56:52 UTC
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?

Comment 13 Juan Manuel Rodriguez 2010-03-20 18:32:44 UTC
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.

Comment 14 Kalev Lember 2010-03-23 21:15:41 UTC
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?

Comment 15 Kalev Lember 2010-04-09 04:35:32 UTC
There's a new rabbitvcs 0.13.1 point release available.

Comment 16 Kalev Lember 2010-04-26 06:34:14 UTC
ping?

Comment 17 Juan Manuel Rodriguez 2010-04-28 18:04:21 UTC
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

Comment 18 Kalev Lember 2010-05-13 12:04:31 UTC
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?

Comment 19 Juan Manuel Rodriguez 2010-05-26 23:15:54 UTC
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

Comment 20 Kalev Lember 2010-05-26 23:35:18 UTC
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.

Comment 21 Kalev Lember 2010-05-26 23:47:17 UTC
-core subpackage also doesn't need Provides: rabbitvcs-core

Comment 22 Juan Manuel Rodriguez 2010-05-26 23:53:29 UTC
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

Comment 23 Kalev Lember 2010-05-27 07:46:48 UTC
-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?

Comment 24 Juan Manuel Rodriguez 2010-05-27 15:11:00 UTC
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.

Comment 25 Kalev Lember 2010-05-27 15:47:44 UTC
(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.

Comment 26 Kalev Lember 2010-05-27 16:13:46 UTC
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

Comment 27 Juan Manuel Rodriguez 2010-05-27 17:00:58 UTC
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?

Comment 28 Kalev Lember 2010-05-27 17:25:54 UTC
(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

Comment 29 Juan Manuel Rodriguez 2010-05-27 17:55:43 UTC
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:

Comment 30 Jason Tibbitts 2010-05-27 22:36:38 UTC
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.

Comment 31 Juan Manuel Rodriguez 2010-05-27 23:22:16 UTC
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 :)

Comment 32 Jason Tibbitts 2010-05-27 23:48:31 UTC
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.

Comment 33 Jason Tibbitts 2010-05-27 23:52:18 UTC
CVS done (by process-cvs-requests.py).

Comment 34 Juan Manuel Rodriguez 2010-05-28 00:09:39 UTC
Thanks Jason! 

rabbitvcs packages are on the way. :)

Comment 35 Fedora Update System 2010-05-28 00:20:50 UTC
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

Comment 36 Fedora Update System 2010-05-28 00:21:45 UTC
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

Comment 37 Fedora Update System 2010-05-28 17:53:27 UTC
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

Comment 38 Fedora Update System 2010-05-28 18:10:01 UTC
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

Comment 39 Fedora Update System 2010-05-31 20:19:54 UTC
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

Comment 40 Fedora Update System 2010-05-31 20:21:39 UTC
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

Comment 41 Fedora Update System 2010-06-01 18:23:00 UTC
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

Comment 42 Fedora Update System 2010-06-01 18:23:24 UTC
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

Comment 43 Fedora Update System 2010-06-07 22:21:37 UTC
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.

Comment 44 Fedora Update System 2010-06-07 22:22:56 UTC
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.

Comment 45 Caghan Demirci 2011-12-16 14:53:45 UTC
  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!

Comment 46 Caghan Demirci 2012-04-05 19:31:09 UTC
  This is the second attempt to contact the maintainer of rabbitvcs, nushio (= Juan).  Please see comment 45.

  Thanks!

Comment 47 Caghan Demirci 2012-04-05 19:34:40 UTC
  Adding needinfo flag...

Comment 48 Gwyn Ciesla 2012-04-05 20:24:58 UTC
Package Change Request
======================
Package Name: rabbitvcs
New Branches: el6
Owners: limb nushio

Comment 49 Gwyn Ciesla 2012-04-05 20:27:41 UTC
Git done (by process-git-requests).

Comment 50 Caghan Demirci 2012-04-27 12:35:15 UTC
  This package is live for EPEL 6, and works perfectly!  Thanks a lot!

Comment 51 Gwyn Ciesla 2012-04-27 14:10:01 UTC
Excellent!  Very welcome!  I've also built thunarx-python which is needed for this.

Comment 52 Christopher Meng 2014-02-07 03:58:28 UTC
Package Change Request
======================
Package Name: rabbitvcs
New Branches: epel7
Owners: cicku nushio limb

Comment 53 Gwyn Ciesla 2014-02-07 05:20:22 UTC
Git done (by process-git-requests).

Comment 54 4dacres 2014-06-12 20:33:05 UTC
Would it be possible to have 0.16 on EPEL 6?


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