Hide Forgot
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
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
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.
(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.
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.
Sorry, wrong link to SRPM. Correct link: http://rishi.fedorapeople.org/dleyna-connector-dbus-0.1.0-3.fc19.src.rpm
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.
New Package SCM Request ======================= Package Name: dleyna-connector-dbus Short Description: D-Bus connector for dLeyna services Owners: rishi Branches: F20 InitialCC:
Git done (by process-git-requests).
Package built for F20.