Bug 629744 - Review Request: sparkleshare - sharing work made easy
Summary: Review Request: sparkleshare - sharing work made easy
Status: CLOSED DUPLICATE of bug 787293
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adam Williamson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-09-02 20:22 UTC by Alex Hudson (Fedora Address)
Modified: 2014-07-12 13:31 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-02-03 20:35:47 UTC

Attachments (Terms of Use)

Description Alex Hudson (Fedora Address) 2010-09-02 20:22:59 UTC
Spec URL: http://www.alexhudson.com/stuff/sparkleshare/sparkleshare.spec
SRPM URL: http://www.alexhudson.com/stuff/sparkleshare/sparkleshare-0.2.alpha2-5.fc13.src.rpm
Description: Easy file sharing based on git repositories. A special folder is setup, and directories/files placed within are placed in a git-based version control system and synchronized elsewhere.

The website for SparkleShare is at http://www.sparkleshare.org/

rpmlint for the spec and SRPM offers the same warning:

sparkleshare.src: W: invalid-url Source0: http://alexh.fedorapeople.org/sources/sparkleshare-0.2.alpha2.tar.bz2 HTTP Error 404: Not Found

Fair enough warning; there isn't a valid upstream tarball available yet. I'm working on this and the beta release, coming within the next week, should have this available.

rpmlint offers a further set of warnings on the binary RPM:

sparkleshare.x86_64: E: no-binary
sparkleshare.x86_64: W: only-non-binary-in-usr-lib

As I understand it, these messages can both be ignored, since this is a Mono-based application and won't have binaries but also cannot be noarch.

I have built this under mock, and am making versions available on http://repos.fedorapeople.org/repos/alexh/sparkleshare/ - I intend for that repo to track upstream more aggressively.

Known issues:

* the libraries are not installed into the GAC. They have no strong name yet, so other applications should not be using them - so I consider this a future issue to resolve rather than a critical bug;
* I've tweaked the version on the package slightly to make it compliant with Fedora versioning. This has also been discussed with upstream, and future releases will use a standard numbering that requires no tweaking;
* Source0 is incorrect (as mentioned above)
* debug_info is turned off for this. I'm not exactly sure what would go into such a package; possibly the .mdb files - I'm still researching this?

Comment 1 eric@christensenplace.us 2011-03-02 19:29:57 UTC
Have you addressed these known issues?  Perhaps an upgrade to beta.  I'll happily work the review.

Comment 2 Alex Hudson (Fedora Address) 2011-03-13 16:32:42 UTC
Hi Eric, apologies for not updating this sooner.

I stopped updating the SparkleShare package after the notification-over-IRC stuff got merged, because I didn't really like the idea of it silently spilling information out into a public forum without people "knowing".

I'll review the latest code but I suspect that is still the case. However, I'll have a chat with Hylke and if it is, see if there's something we can do about it - e.g. writing some sort of alternative system.

Comment 3 Alex Hudson (Fedora Address) 2011-03-27 19:30:46 UTC
Another update.

I've made 0.2rc1 packages available via my fedorapeople repo. They're F14-only for now: it doesn't want to build on F15/rawhide, which I believe is actually a mono problem.

The public irc thing is still in there, but there is a mechanism to disable it which I'll document in the package. Otherwise it seems very usable: I'm going to check through a bit more of the package but it's getting close to being reviewable again.

Comment 4 Aidan Delaney 2011-04-29 16:40:33 UTC
The buildrequires both python2-devel and python3-devel, is this by design?

I get build failures on F15 with the following
$ rpmbuld -ba sparkleshare.spec
+ chmod 644 '/home/aidan/tmp/rpm/BUILDROOT/sparkleshare-0.2.beta1-5.fc15.x86_64/usr/lib64/nautilus/extensions-2.0/python/*.py'
chmod: cannot access `/home/aidan/tmp/rpm/BUILDROOT/sparkleshare-0.2.beta1-5.fc15.x86_64/usr/lib64/nautilus/extensions-2.0/python/*.py': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.5xqF1R (%install)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.5xqF1R (%install)

So something to do with 64bit Fedora 15.  I'd dig deeper but I've got two screaming kids....which reminds me, (@alex) congrats on the nipper.  We'll get this bug sorted over the next month or two, as I know small people can keep you busy.

Comment 5 Alex Hudson (Fedora Address) 2011-05-20 17:06:14 UTC
Hey all,

Thanks for the congrats Aidan, much appreciated ;)

I've rebuilt the latest sparkleshare for f13/14/15:


The F15 SRPM/spec is the latest.

The python stuff I'm in two minds about at the moment. I've fixed the problems - basically, nautilus-python-devel wants to see extensions in the python 3 folder, whether or not the extension will work from there, I have no idea - I couldn't get the extension to work on gnome 2 yet.

The B-R on python-devel 2 and 3 is what the Python SIG say you should do - I need to do more testing with it, I think it's correct but obviously without getting the extension working...

I think this package is basically ready for review, with an eye for this going into F16 but possibly F15 too.

Comment 6 Jason Tibbitts 2011-06-08 21:55:36 UTC
If it's ready for review, perhaps you could post working links to the spec and srpm?  The only ones I see are invalid.

Comment 7 Alex Hudson (Fedora Address) 2011-06-09 12:33:14 UTC
Sorry, I was just in the process of cleaning it up further!

Spec URL: http://alexh.fedorapeople.org/reviews/sparkleshare/sparkleshare.spec
SRPM URL: http://alexh.fedorapeople.org/reviews/sparkleshare/sparkleshare-0.2.1-1.fc15.src.rpm

I've also added a dependency to bug #712069, which separates out the SmartIrc4Net library which is otherwise included within SparkleShare.

The packages are rpmlint clean:

$ rpmlint SPECS/sparkleshare.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

$ rpmlint SRPMS/sparkleshare-0.2.1-1.fc15.src.rpm 
sparkleshare.src: W: file-size-mismatch sparkleshare-0.2.1.tar.gz = 1413871, https://github.com/downloads/hbons/SparkleShare/sparkleshare-0.2.1.tar.gz = 1521334
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

This warning is because I have packaged an updated copy of the source, which includes the patch to separate out SmartIrc4Net. I wrote this patch for SparkleShare, and I'm hopeful that a 0.2.2 release won't be too far away. Usually I would have done this via a patch, but it's a change early in the build system which would be a substantial patch to the released (i.e., post-autogen) tarball.

$ rpmlint RPMS/x86_64/sparkleshare-0.2.1-1.fc15.x86_64.rpm 
sparkleshare.x86_64: E: no-binary
sparkleshare.x86_64: W: only-non-binary-in-usr-lib
1 packages and 0 specfiles checked; 1 errors, 1 warnings.

This error/warning I believe is normal for a Mono-based app, as the binaries are not detected as such.

Comment 8 Adam Williamson 2011-09-01 23:02:42 UTC
Picking up the review...

0.2.4 is slightly old now - upstream is up to 0.2.5 - but meh, no biggie.

It builds on 64-bit F16 - good!


[adamw@adam SRPMS]$ rpmlint /var/lib/mock/fedora-16-x86_64/result/*.rpm
sparkleshare.x86_64: E: no-binary
sparkleshare.x86_64: W: only-non-binary-in-usr-lib

these are OK, as per Alex's comment #7, as this is a Mono app.

smartirc4net isn't split out yet as that review isn't complete, I guess I'll pick that up too. So proceeding as if smartirc4net was split out:

all the MUSTs and SHOULDs look good. Concerning the Mono policy, I have one issue:

"For a while, Fedora considered mono packages to be architecture-specific, and installed assemblies to %{_libdir}. However, after discussions with upstream, we now consider mono packages to be architecture (and platform) independent. This means that mono packages should be correctly installed into the GAC in /usr/lib or installed into /usr/lib/PACKAGENAME.

As a notable exception, any ELF binary libraries generated in a mono package must be correctly installed into %{_libdir}, because these files are architecture-specific."

This spec installs both DLLs and the EXE to %_libdir, not /usr/lib . Are they 'ELF binary libraries' and hence arch-specific, or should they in fact be in /usr/lib ?

Seems a bit odd that the file list specifies /usr/bin and /usr/share/blahblah; I'd expect to see %_bindir and %_datadir instead.

I'd usually use a slightly less specific form for the manpage in the files list, so additional manpages get picked up without adjusting the spec, and if we ever decide to compress man pages with something other than gzip that wouldn't be a problem either.

With the above caveats, I'd say this is looking good; please respond to the major point raised. thanks!

Comment 9 Adam Williamson 2011-09-01 23:03:44 UTC
oh, I see that was kinda addressed in the first post, but do let me know if it still applies.

Comment 10 Nikos Roussos 2012-02-03 20:35:47 UTC

*** This bug has been marked as a duplicate of bug 787293 ***

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