Bug 659746 - Review Request: dee - Model to synchronize multiple instances over DBus
Review Request: dee - Model to synchronize multiple instances over DBus
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jef Spaleta
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-03 10:32 EST by Adam Williamson
Modified: 2011-01-14 12:47 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-14 12:47:21 EST
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)

  None (edit)
Description Adam Williamson 2010-12-03 10:32:38 EST
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 10:33:27 EST
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 14:44:44 EST
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 15:24:49 EST
"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 15:36:04 EST
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 16:10:40 EST
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 16:24:34 EST
that's fine, I wasn't really planning on targeting F14.
Comment 7 Jef Spaleta 2010-12-06 17:33:56 EST
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 13:53:13 EST
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 11:53:29 EST
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 12:17:13 EST
Git done (by process-git-requests).
Comment 11 Adam Williamson 2011-01-14 12:47:21 EST
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.