Bug 629744
| Summary: | Review Request: sparkleshare - sharing work made easy | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alex Hudson (Fedora Address) <fedora> |
| Component: | Package Review | Assignee: | Adam Williamson <awilliam> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | a.j.delaney, awilliam, bloch, comzeradd, eric, fedora-package-review, ggillies, notting, palango |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-03 20:35:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Alex Hudson (Fedora Address)
2010-09-02 20:22:59 UTC
Have you addressed these known issues? Perhaps an upgrade to beta. I'll happily work the review. 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. 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. 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
.
<snip>
.
+ 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.
Hey all, Thanks for the congrats Aidan, much appreciated ;) I've rebuilt the latest sparkleshare for f13/14/15: http://repos.fedorapeople.org/repos/alexh/sparkleshare/ 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. If it's ready for review, perhaps you could post working links to the spec and srpm? The only ones I see are invalid. 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. 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! rpmlint: [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! oh, I see that was kinda addressed in the first post, but do let me know if it still applies. *** This bug has been marked as a duplicate of bug 787293 *** |