Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 978489 - Review Request: dleyna-connector-dbus - D-Bus connector for dLeyna services
Summary: Review Request: dleyna-connector-dbus - D-Bus connector for dLeyna services
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mathieu Bridon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 978381
Blocks: 978494
TreeView+ depends on / blocked
 
Reported: 2013-06-26 17:36 UTC by Debarshi Ray
Modified: 2013-07-09 14:04 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-09 14:04:54 UTC
Type: ---
bochecha: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Debarshi Ray 2013-06-26 17:36:47 UTC
Spec URL: http://rishi.fedorapeople.org/dleyna-connector-dbus.spec
SRPM URL: http://rishi.fedorapeople.org/dleyna-connector-dbus-0.1.0-1.fc19.src.rpm

Description:
D-Bus connector for dLeyna services.

Fedora Account System Username: rishi

Comment 1 Mathieu Bridon 2013-07-03 03:36:12 UTC
Package is almost good to go, there's just a few little things to fix.

Summary
=======

[!]: Package requires other packages for directories it uses.
[!]: Package must own all directories that it creates.

    => Package installs %{_libdir}/dleyna-%{api}/connectors/libdleyna-connector-dbus.so
       but does not provide the %{_libdir}/dleyna-%{api} and
       %{_libdir}/dleyna-%{api}/connectors folders.

    => Maybe the right fix here would be to have dleyna-core provide these
       folders (it does not at the moment) and then dleyna-connector-dbus
       could just explicitly require dleyna-core?

[!]: Spec use %global instead of %define.
     Note: %define api 1.0

    => Just s/define/global/ in that line.

[!]: Final provides and requires are sane (see attachments).

    => Should the private .so file be filtered from provides?
       This is a real question, I can't answer it as I don't know what this
       file is supposed to do. I'll trust your judgement on this point.


Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed



===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[x]: Development files must be in a -devel package
[!]: Package requires other packages for directories it uses.

    => See the other directory-related issue for details.

[x]: Package uses nothing in %doc for runtime.
[x]: Package is not known to require ExcludeArch.
[!]: Package complies to the Packaging Guidelines

    => See other issues.

[x]: License field in the package spec file matches the actual license.
[x]: License file installed when any subpackage combination is installed.
[x]: Package consistently uses macro is (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[!]: Package must own all directories that it creates.

    => Package installs %{_libdir}/dleyna-%{api}/connectors/libdleyna-connector-dbus.so
       but does not provide the %{_libdir}/dleyna-%{api} and
       %{_libdir}/dleyna-%{api}/connectors folders.

    => Maybe the right fix here would be to have dleyna-core provide these
       folders (it does not at the moment) and then dleyna-connector-dbus
       could just explicitly require dleyna-core?

[x]: Package does not own files or directories owned by other packages.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[-]: Large documentation must go in a -doc subpackage.
     Note: Documentation size is 40960 bytes in 4 files.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[-]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Fully versioned dependency in subpackages, if present.
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).

===== SHOULD items =====

Generic:
[!]: Spec use %global instead of %define.
     Note: %define api 1.0

    => Just s/define/global/ in that line.

[-]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[!]: Final provides and requires are sane (see attachments).

    => Should the private .so file be filtered from provides?
       This is a real question, I can't answer it as I don't know what this
       file is supposed to do. I'll trust your judgement on this point.

[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: Dist tag is present.
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Uses parallel make.
[x]: The placement of pkgconfig(.pc) files are correct.
[x]: SourceX tarball generation or download is documented.
[x]: SourceX is a working URL.

===== EXTRA items =====

Generic:
[-]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: dleyna-connector-dbus-0.1.0-1.fc20.x86_64.rpm
          dleyna-connector-dbus-devel-0.1.0-1.fc20.x86_64.rpm
dleyna-connector-dbus-devel.x86_64: W: no-documentation
2 packages and 0 specfiles checked; 0 errors, 1 warnings.




Rpmlint (installed packages)
----------------------------
# rpmlint dleyna-connector-dbus-devel dleyna-connector-dbus
dleyna-connector-dbus-devel.x86_64: W: no-documentation
2 packages and 0 specfiles checked; 0 errors, 1 warnings.
# echo 'rpmlint-done:'



Requires
--------
dleyna-connector-dbus-devel (rpmlib, GLIBC filtered):
    /usr/bin/pkg-config
    dleyna-connector-dbus(x86-64)
    pkgconfig(dbus-1)
    pkgconfig(gio-2.0)
    pkgconfig(glib-2.0)

dleyna-connector-dbus (rpmlib, GLIBC filtered):
    libc.so.6()(64bit)
    libdleyna-core-1.0.so.1()(64bit)
    libgio-2.0.so.0()(64bit)
    libglib-2.0.so.0()(64bit)
    libgmodule-2.0.so.0()(64bit)
    libgobject-2.0.so.0()(64bit)
    libgupnp-1.0.so.4()(64bit)
    libpthread.so.0()(64bit)
    rtld(GNU_HASH)



Provides
--------
dleyna-connector-dbus-devel:
    dleyna-connector-dbus-devel
    dleyna-connector-dbus-devel(x86-64)
    pkgconfig(dleyna-connector-dbus-1.0)

dleyna-connector-dbus:
    dleyna-connector-dbus
    dleyna-connector-dbus(x86-64)
    libdleyna-connector-dbus.so()(64bit)



Unversioned so-files
--------------------
dleyna-connector-dbus: /usr/lib64/dleyna-1.0/connectors/libdleyna-connector-dbus.so

Source checksums
----------------
https://01.org/dleyna/sites/default/files/downloads/dleyna-connector-dbus-0.1.0.tar.gz :
  CHECKSUM(SHA256) this package     : 73b0bbcfb81e2b4d4b1b1b25bd5f7a089d6707ddf233fcc09b1c0c732f90bb2b
  CHECKSUM(SHA256) upstream package : 73b0bbcfb81e2b4d4b1b1b25bd5f7a089d6707ddf233fcc09b1c0c732f90bb2b


Generated by fedora-review 0.4.1 (b2e211f) last change: 2013-04-29
Buildroot used: fedora-rawhide-x86_64
Command line :/usr/bin/fedora-review -b 978489 -m fedora-rawhide-x86_64

Comment 2 Debarshi Ray 2013-07-08 11:36:52 UTC
Spec: http://rishi.fedorapeople.org/dleyna-connector-dbus.spec
SRPM: http://rishi.fedorapeople.org/dleyna-connector-dbus-0.1.0-2.fc19.src.rpm

(In reply to Mathieu Bridon from comment #1)
> Package is almost good to go, there's just a few little things to fix.
> 
> Summary
> =======
> 
> [!]: Package requires other packages for directories it uses.
> [!]: Package must own all directories that it creates.
> 
>     => Package installs
> %{_libdir}/dleyna-%{api}/connectors/libdleyna-connector-dbus.so
>        but does not provide the %{_libdir}/dleyna-%{api} and
>        %{_libdir}/dleyna-%{api}/connectors folders.
> 
>     => Maybe the right fix here would be to have dleyna-core provide these
>        folders (it does not at the moment) and then dleyna-connector-dbus
>        could just explicitly require dleyna-core?

Good catch. To me it seemed more sane to have dleyna-connector-dbus own those two directories. eg., I don't know if other dLeyna components will be creating more such directories. Up to you.

> 
> [!]: Spec use %global instead of %define.
>      Note: %define api 1.0
> 
>     => Just s/define/global/ in that line.

Done.

> [!]: Final provides and requires are sane (see attachments).
> 
>     => Should the private .so file be filtered from provides?
>        This is a real question, I can't answer it as I don't know what this
>        file is supposed to do. I'll trust your judgement on this point.

I don't know either. dLeyna supports different IPC mechanisms (see connector-name in /etc/dleyna-renderer-service.conf) via a plugin architecture. This particular file implements support for D-Bus.

Comment 3 Mathieu Bridon 2013-07-08 13:10:57 UTC
(In reply to Debarshi Ray from comment #2)
> Spec: http://rishi.fedorapeople.org/dleyna-connector-dbus.spec
> SRPM:
> http://rishi.fedorapeople.org/dleyna-connector-dbus-0.1.0-2.fc19.src.rpm
> 
> (In reply to Mathieu Bridon from comment #1)
> > Package is almost good to go, there's just a few little things to fix.
> > 
> > Summary
> > =======
> > 
> > [!]: Package requires other packages for directories it uses.
> > [!]: Package must own all directories that it creates.
> > 
> >     => Package installs
> > %{_libdir}/dleyna-%{api}/connectors/libdleyna-connector-dbus.so
> >        but does not provide the %{_libdir}/dleyna-%{api} and
> >        %{_libdir}/dleyna-%{api}/connectors folders.
> > 
> >     => Maybe the right fix here would be to have dleyna-core provide these
> >        folders (it does not at the moment) and then dleyna-connector-dbus
> >        could just explicitly require dleyna-core?
> 
> Good catch. To me it seemed more sane to have dleyna-connector-dbus own
> those two directories. eg., I don't know if other dLeyna components will be
> creating more such directories. Up to you.

I would have seen it owned by dleyna-core because the name made it sound like there might be other connectors which would drop stuff in there.

But this works for me, as long as the dir is owned by something.

> > [!]: Final provides and requires are sane (see attachments).
> > 
> >     => Should the private .so file be filtered from provides?
> >        This is a real question, I can't answer it as I don't know what this
> >        file is supposed to do. I'll trust your judgement on this point.
> 
> I don't know either. dLeyna supports different IPC mechanisms (see
> connector-name in /etc/dleyna-renderer-service.conf) via a plugin
> architecture. This particular file implements support for D-Bus.

What will load this plugin?

If it's something which just loads whatever is installed and configured, then there wouldn't be any requirement, and as such I'd filter the Provides out.

If it's something that needs to link against it, then the Provides should stay.

But these are just examples I can think of off the top of my head, this package could be in a different situation, dunno.

In any case, the Provides shouldn't cause any harm (e.g given its name, it's unlikely to conflict with anything else), so I won't block the review on this.

----------

All my issues with the package are fixed by this new one, see diff below.

$ diff -u dleyna-connector-dbus.spec.old dleyna-connector-dbus.spec
--- dleyna-connector-dbus.spec.old	2013-06-27 01:32:08.000000000 +0800
+++ dleyna-connector-dbus.spec	2013-07-08 19:25:53.000000000 +0800
@@ -1,8 +1,8 @@
-%define api 1.0
+%global api 1.0
 
 Name:           dleyna-connector-dbus
 Version:        0.1.0
-Release:        1%{?dist}
+Release:        2%{?dist}
 Summary:        D-Bus connector for dLeyna services
 
 License:        LGPLv2
@@ -48,6 +48,8 @@
 %doc COPYING
 %doc ChangeLog
 %doc README
+%dir %{_libdir}/dleyna-%{api}
+%dir %{_libdir}/dleyna-%{api}/connectors
 %{_libdir}/dleyna-%{api}/connectors/libdleyna-connector-dbus.so
 
 %files devel
@@ -55,5 +57,9 @@
 
 
 %changelog
+* Sun Jul 07 2013 Debarshi Ray <rishi@fedoraproject.org> - 0.1.0-2
+- Use %%global instead of %%define.
+- Own %%{_libdir}/dleyna-%%{api} and %%{_libdir}/dleyna-%%{api}/connectors.
+
 * Wed Jun 26 2013 Debarshi Ray <rishi@fedoraproject.org> - 0.1.0-1
 - Initial spec.

----------

Package is approved.

Comment 4 Debarshi Ray 2013-07-09 10:25:56 UTC
Spec: http://rishi.fedorapeople.org/dleyna-connector-dbus.spec
SRPM: http://rishi.fedorapeople.org/dleyna-connector-dbus-0.1.0-2.fc19.src.rpm

>> I don't know either. dLeyna supports different IPC mechanisms (see
>> connector-name in /etc/dleyna-renderer-service.conf) via a plugin
>> architecture. This particular file implements support for D-Bus.
> 
> What will load this plugin?
> 
> If it's something which just loads whatever is installed and configured,
> then there wouldn't be any requirement, and as such I'd filter the Provides
> out.
> 
> If it's something that needs to link against it, then the Provides should
> stay.

I think you were right in saying that they should be filtered. After reading https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering I think that it matches the Pidgin plugin scenario. Things like dleyna-renderer load this connector plugin at run-time. If the plugin is absent, the dleyna-renderer service will start and exit immediately.

Interestingly the mechanism for loading the connector plugins are in dleyna-core (grep for dleyna_connector_get_interface).

Since dleyna-connector-dbus requires dleyna-core, we can't possibly have dleyna-core require the connector because it will be a circular dependency.

Hence I filtered out the provides as you suggested initially.

Comment 5 Debarshi Ray 2013-07-09 10:41:49 UTC
Sorry, wrong link to SRPM.
Correct link: http://rishi.fedorapeople.org/dleyna-connector-dbus-0.1.0-3.fc19.src.rpm

Comment 6 Mathieu Bridon 2013-07-09 10:44:34 UTC
Provides filtering seems sane, and it's the only change in this new spec so the rest of the review still stands, package is still approved.

Comment 7 Debarshi Ray 2013-07-09 10:45:56 UTC
New Package SCM Request
=======================
Package Name: dleyna-connector-dbus
Short Description: D-Bus connector for dLeyna services
Owners: rishi
Branches: F20
InitialCC:

Comment 8 Gwyn Ciesla 2013-07-09 11:00:18 UTC
Git done (by process-git-requests).

Comment 9 Debarshi Ray 2013-07-09 14:04:54 UTC
Package built for F20.


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