Bug 659746 - Review Request: dee - Model to synchronize multiple instances over DBus
Summary: Review Request: dee - Model to synchronize multiple instances over DBus
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review   
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jef Spaleta
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-03 15:32 UTC by Adam Williamson
Modified: 2011-01-14 17:47 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-14 17:47:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jspaleta: fedora-review+
tibbs: fedora-cvs+


Attachments (Terms of Use)

Description Adam Williamson 2010-12-03 15:32:38 UTC
Spec URL: http://www.happyassassin.net/extras/dee.spec
SRPM URL: http://www.happyassassin.net/extras/dee-0.4.2-1.aw_fc15.src.rpm

Description: Libdee is a library that uses DBus to provide objects allowing you to create Model-View-Controller type programs across DBus. It also consists of utility objects which extend DBus allowing for peer-to-peer discoverability of known objects without needing a central registrar.

This is part of Ubuntu's Aytana stuff, and is a dependency for Unity, which I'm trying to work towards packaging.

Notes: there's some small licensing issues I filed an upstream bug for: https://bugs.launchpad.net/dee/+bug/684738 . Note that the source is dual LGPLv3 and GPLv3, but none of the GPLv3 bits (test and example binaries) are actually installed into the binary packages, so just LGPLv3 is the appropriate License: tag.

rpmlint:

[adamw@adam SPECS]$ rpmlint dee.spec 
dee.spec: W: no-cleaning-of-buildroot %clean
dee.spec: W: no-buildroot-tag
dee.spec: W: no-%clean-section
0 packages and 1 specfiles checked; 0 errors, 3 warnings.

these are all okay for F13+ (F12 is now EOL).

[adamw@adam SPECS]$ rpmlint /var/lib/mock/fedora-rawhide-x86_64/result/dee-0.4.2-1.fc15.x86_64.rpm 
dee.x86_64: W: spelling-error %description -l en_US discoverability -> discover ability, discover-ability, discoverable

I say it's a word so it is a word! (Comes from upstream, actually. I ripped off their description.)

[adamw@adam SPECS]$ rpmlint /var/lib/mock/fedora-rawhide-x86_64/result/dee-devel-0.4.2-1.fc15.x86_64.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

Comment 1 Adam Williamson 2010-12-03 15:33:27 UTC
one improvement here would be to use the in-built test suite, but I'd have to package dbus-test-runner too, for that. may do that if I get time later.

Comment 2 Jef Spaleta 2010-12-06 19:44:44 UTC
Just FYI, I don't think I can pass this through review until there is at least a comment from upstream concerning the missing license headers. At least a clarification of intention in the upstream report would be enough for me as a archived statement on record.


That being said......

I think you have to leave the GPLv3 in the license field because the srpm does ship with the example and test code. It's not just the binary..we do distribute the srpm's as well and the licensing tag has to make sense for both the srpm and the binary rpm.

-jef

Comment 3 Adam Williamson 2010-12-06 20:24:49 UTC
"Just FYI, I don't think I can pass this through review until there is at least
a comment from upstream concerning the missing license headers."

I think we're generally okay to ship source which has no specific header but is clearly marked with an acceptable license in other ways by upstream (dee is on the project page, and by the inclusion of the license files in the tarball); having a header on each specific source file is a 'nice-to-have', not a must. But I'll CC spot to check this.

"It's not just the binary..we do distribute the srpm's as well and the licensing tag has to make sense for both the srpm and the binary rpm."

No, it doesn't.

http://fedoraproject.org/wiki/Packaging/LicensingGuidelines

"The License: field refers to the licenses of the contents of the *binary* rpm. When in doubt, ask."

Comment 4 Jef Spaleta 2010-12-06 20:36:04 UTC
Indeed. i missed that. Yippie for expansive guidance!

spec file looks good.  I just need finish the local mock build and confirm binary build stuff on a primary arch.

-jef

Comment 5 Jef Spaleta 2010-12-06 21:10:40 UTC
This is lovely. When trying to build dee against F14 I get an error concerning
DBus-1.0.gir not available.

On rawhide this is available in gobject-introspection-devel
On F13 this is availabe in gir-repository-devel


On F14 it appears to be unavailable from any package.  

Not a review blocker. Just be aware that once dee goes in it is going to be F15+ only.

-jef

Comment 6 Adam Williamson 2010-12-06 21:24:34 UTC
that's fine, I wasn't really planning on targeting F14.

Comment 7 Jef Spaleta 2010-12-06 22:33:56 UTC
Looks good.  Builds without error on 64bit rawhide under mock. 
Binary packages appear well formed with correct ownership for files and directories.  

No executables or associated desktop files to worry about.
ldconfig called in scriptlets for install libraries.
 
Minimal docs in the main package with COPYING file

-devel subpackage looks good.


rpmlint runs have ignorable warnings. 


Passes review for rawhide and fc15+

Comment 8 Adam Williamson 2010-12-08 18:53:13 UTC
New Package SCM Request
=======================
Package Name: dee
Short Description: Model to synchronize multiple instances over DBus
Owners: adamwill
Branches: 
InitialCC:

Comment 9 Adam Williamson 2011-01-14 16:53:29 UTC
whoops, set the fedora-cvs flag to + instead of ?...doh.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Jason Tibbitts 2011-01-14 17:17:13 UTC
Git done (by process-git-requests).

Comment 11 Adam Williamson 2011-01-14 17:47:21 UTC
okay, thanks, closing.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers


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