Spec URL: http://lesloueizeh.com/jdieter/novacomd.spec SRPM URL: http://lesloueizeh.com/jdieter/novacomd-1.1.0-0.1.rc1.fc16.src.rpm Description: This service should be run as root and allows novacom to connect to WebOS devices that are connected over USB
I'd be glad to review it, since I'm having a WebOS device. Just some comments: - %defattr in %files is useless now: http://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions - %clean section, as well as buildroot cleaning in %install and the BuildRoot tag, is useless too: http://fedoraproject.org/wiki/Packaging:Guidelines#.25clean http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag - it looks like the sources provide an Upstart service file. This service was also available in the binary packages delivered by HP: https://developer.palm.com/content/resources/develop/sdk_pdk_download.html#linux I think you should write a very simple Systemd file to launch novacomd at startup for this package.
Thanks much for your willingness to review. Comments inline. (In reply to comment #1) > I'd be glad to review it, since I'm having a WebOS device. Just some comments: > - %defattr in %files is useless now: > http://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions Ok, will fix in next revision. > - %clean section, as well as buildroot cleaning in %install and the BuildRoot > tag, is useless too: > http://fedoraproject.org/wiki/Packaging:Guidelines#.25clean > http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag I'll probably leave this in as I'd like to build this for EPEL-5 > - it looks like the sources provide an Upstart service file. This service was > also available in the binary packages delivered by HP: > > https://developer.palm.com/content/resources/develop/sdk_pdk_download.html#linux > I think you should write a very simple Systemd file to launch novacomd at > startup for this package. That's a very good idea, though I was wondering about possibly setting up socket activation for novacomd. Novacom is a separate review (as they have separate upstreams) and is available at bug 809116. I have wondered whether it would make sense to package novacomd as novacom-server, novacom as novacom-client and have a metapackage, novacom, that installs both. What do you think?
I would be against splitting into several packages. There are few files and the size is small. If you also could include icon and .desktop file for novaterm. Something like: [Desktop Entry] Version=1.0 Name=Novaterm Comment=Novaterm for command line access to WebOS device Exec=/home/pliszka/palm/novacom/novaterm Icon=/home/pliszka/icons/Palm_logo_2003.svg Terminal=true Type=Application Categories=Own;
(In reply to comment #2) > > - %clean section, as well as buildroot cleaning in %install and the BuildRoot > > tag, is useless too: > > http://fedoraproject.org/wiki/Packaging:Guidelines#.25clean > > http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag > > I'll probably leave this in as I'd like to build this for EPEL-5 It's OK :) > Novacom is a separate review (as they have separate upstreams) and is available > at bug 809116. I will review it too. > I have wondered whether it would make sense to package novacomd as > novacom-server, novacom as novacom-client and have a metapackage, novacom, that > installs both. What do you think? I'd let the original names for each package, as recommended by the guidelines, and add a Requires on novacomd in the novacom package, since the client cannot work without the service. If novacom and novacomd were available from the same source, I'd even package it as a single RPM. (In reply to comment #3) > If you also could include icon and .desktop file for novaterm. > > Something like: > > > [Desktop Entry] > Version=1.0 > Name=Novaterm > Comment=Novaterm for command line access to WebOS device > Exec=/home/pliszka/palm/novacom/novaterm > Icon=/home/pliszka/icons/Palm_logo_2003.svg > Terminal=true > Type=Application > Categories=Own; This comment is rather relative to the novacom package. I don't think providing a desktop file for novaterm is worthy since novacom is clearly described as a set of command-line tools.
(In reply to comment #4) > (In reply to comment #2) > > I have wondered whether it would make sense to package novacomd as > > novacom-server, novacom as novacom-client and have a metapackage, novacom, that > > installs both. What do you think? > I'd let the original names for each package, as recommended by the guidelines, > and add a Requires on novacomd in the novacom package, since the client cannot > work without the service. Novacom can actually connect to a novacomd server on a different machine, which is why I'd prefer not to have a hard requires on novacomd. Having said that, if you feel strongly about it, we can do the hard requires. > If novacom and novacomd were available from the same source, I'd even package > it as a single RPM. ACK. It would make life *way* easier, but, unfortunately, HP has seen fit to release them as two separate sources. > (In reply to comment #3) > > If you also could include icon and .desktop file for novaterm. > > > > Something like: > > > > > > [Desktop Entry] > > Version=1.0 > > Name=Novaterm > > Comment=Novaterm for command line access to WebOS device > > Exec=/home/pliszka/palm/novacom/novaterm > > Icon=/home/pliszka/icons/Palm_logo_2003.svg > > Terminal=true > > Type=Application > > Categories=Own; > > > This comment is rather relative to the novacom package. I don't think providing > a desktop file for novaterm is worthy since novacom is clearly described as a > set of command-line tools. +1
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #2) > > > I have wondered whether it would make sense to package novacomd as > > > novacom-server, novacom as novacom-client and have a metapackage, novacom, that > > > installs both. What do you think? > > I'd let the original names for each package, as recommended by the guidelines, > > and add a Requires on novacomd in the novacom package, since the client cannot > > work without the service. > > Novacom can actually connect to a novacomd server on a different machine, which > is why I'd prefer not to have a hard requires on novacomd. Having said that, > if you feel strongly about it, we can do the hard requires. I've just discover the remote connection options for novacomd... And it works ^^. So you're right, it's useless to force such a Requires. Forget about my comment on novacom too, then.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #2) > > > > I have wondered whether it would make sense to package novacomd as > > > > novacom-server, novacom as novacom-client and have a metapackage, novacom, that > > > > installs both. What do you think? > > > I'd let the original names for each package, as recommended by the guidelines, > > > and add a Requires on novacomd in the novacom package, since the client cannot > > > work without the service. > > > > Novacom can actually connect to a novacomd server on a different machine, which > > is why I'd prefer not to have a hard requires on novacomd. Having said that, > > if you feel strongly about it, we can do the hard requires. > > > I've just discover the remote connection options for novacomd... And it works > ^^. So you're right, it's useless to force such a Requires. Forget about my > comment on novacom too, then. Ok, which brings me back to the original question. As the most common scenario is to have both server and client on the same machine, should we have novacom-server, novacom-client and novacom which brings in both?
(In reply to comment #7) > Ok, which brings me back to the original question. As the most common scenario > is to have both server and client on the same machine, should we have > novacom-server, novacom-client and novacom which brings in both? Sorry for this late answer. The scheme you suggest is OK for me: renaming your current novacomd package to novacom-server, the novacom package to novacom-client; the "empty" novacom package can be set as a subpackage of novacom-client.
Ok, new release: Spec URL: http://lesloueizeh.com/jdieter/novacom-server.spec SRPM URL: http://lesloueizeh.com/jdieter/novacom-server-1.1.0-0.2.rc1.fc16.src.rpm This adds a systemd service and renames the package in accordance with comment #8. The package still provides novacomd so a user can install it by typing "yum install novacomd".
Mohamed, I went ahead and assigned this to you. Is there anything else you think I need to do with this?
Mohamed, I don't want to pressure you at all, but are you still happy to review these two packages? If you're just busy, it's no problem at all, but if you've lost interest, I have someone else who's volunteered to do the review.
Sorry for the late answer, I had quite a lot of work these last days. The systemd file looks fine to me, but the specific scriptlets are missing. You can have a look at this page to fix it: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd Since you will make this package available for EL, you'll need a SysV service file too. Do you intend to provide different spec files for EL and Fedora branches, or to use a unique spec file with version conditions? Be careful no to mix macro and variable style in your spec file: you should not use %{optflags} and $RPM_BUILD_ROOT together: http://fedoraproject.org/wiki/Packaging:Guidelines#Using_.25.7Bbuildroot.7D_and_.25.7Boptflags.7D_vs_.24RPM_BUILD_ROOT_and_.24RPM_OPT_FLAGS The Provides you set is a really good idea, but don't forget to specify also the release to avoid any ambiguity in the dep solving: Provides: novacomd = %{version}-%{release} Once these issues fixed I will approve at last this package.
I forget a last point: since gcc is part of the implicit BuildRequires, you don't need to add glibc-devel to the list of BR: http://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2
(In reply to comment #12) > Sorry for the late answer, I had quite a lot of work these last days. > > The systemd file looks fine to me, but the specific scriptlets are missing. You > can have a look at this page to fix it: > http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd Fixed, thanks for the catch. > Since you will make this package available for EL, you'll need a SysV service > file too. Do you intend to provide different spec files for EL and Fedora > branches, or to use a unique spec file with version conditions? I've put together a SysV script, but I'm going to do totally different spec files, mainly because of the differences between the SysV scriptlets and systemd scriptlets. I feel that having conditionals for such a huge change makes the spec file less readable. > Be careful no to mix macro and variable style in your spec file: you should not > use %{optflags} and $RPM_BUILD_ROOT together: > > http://fedoraproject.org/wiki/Packaging:Guidelines#Using_.25.7Bbuildroot.7D_and_.25.7Boptflags.7D_vs_.24RPM_BUILD_ROOT_and_.24RPM_OPT_FLAGS Fixed. Again, thanks for the catch. > The Provides you set is a really good idea, but don't forget to specify also > the release to avoid any ambiguity in the dep solving: > Provides: novacomd = %{version}-%{release} Fixed. > Once these issues fixed I will approve at last this package. > > I forget a last point: since gcc is part of the implicit BuildRequires, you > don't need to add glibc-devel to the list of BR: > http://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 This line has now been removed.
New release: Spec URL: http://lesloueizeh.com/jdieter/novacom-server.spec SRPM URL: http://lesloueizeh.com/jdieter/novacom-server-1.1.0-0.3.rc1.fc17.src.rpm
There is one small thing needed to be fixed before release: /var/log/messages fills with the following messages: Apr 30 10:23:45 jpliszka3 novacomd(..local..root@jpliszka3..20120430..09:48:24): novacom_usb_tx_thread:358: usbll(0001000b) wrote tx packet len=61 Apr 30 10:23:46 jpliszka3 novacomd(..local..root@jpliszka3..20120430..09:48:24): novacom_usb_tx_thread:358: usbll(0001000b) wrote tx packet len=61 Could it be fixed in 0.4 ? Apart from that - works great.
New release: Spec URL: http://lesloueizeh.com/jdieter/novacom-server.spec SRPM URL: http://lesloueizeh.com/jdieter/novacom-server-1.1.0-0.4.rc1.fc17.src.rpm This release muffles the logging of *every* packet transmitted to the WebOS device. Mohamed, anything else that you would like to see fixed? If you're happy with this, I'd love to get it approved and into Fedora quickly.
Not working for me - I'm still getting log entry every second: May 2 22:26:02 jpliszka3 novacomd(..local..root@jpliszka3..20120502..22:18:45): usbll(0002000b) wrote tx packet len=61 May 2 22:26:03 jpliszka3 novacomd(..local..root@jpliszka3..20120502..22:18:45): usbll(0002000b) wrote tx packet len=61 May 2 22:26:04 jpliszka3 novacomd(..local..root@jpliszka3..20120502..22:18:45): usbll(0002000b) wrote tx packet len=61 May 2 22:26:05 jpliszka3 novacomd(..local..root@jpliszka3..20120502..22:18:45): usbll(0002000b) wrote tx packet len=61 ^C [root@jpliszka3 ~]# rpm -qa | grep novacom-s novacom-server-1.1.0-0.4.rc1.fc17.x86_64
New release: Spec URL: http://lesloueizeh.com/jdieter/novacom-server.spec SRPM URL: http://lesloueizeh.com/jdieter/novacom-server-1.1.0-0.5.rc1.fc17.src.rpm This *really* muffles the packet logging. Jacek, my apologies for getting it wrong last time. Mohamed, is there anything else you need? If not, do you mind approving it and novacom-client? Thanks much!
Thank you Jonathan, not it is fixed - everything works fine. All we need now is approval.
Sorry, I was just waiting that the logging issue was solved. Here is the review: Package Review ============== Key: - = N/A x = Pass ! = Fail ? = Not evaluated ==== C/C++ ==== [x]: MUST Header files in -devel subpackage, if present. [x]: MUST Package does not contain any libtool archives (.la) [x]: MUST Package does not contain kernel modules. [x]: MUST Package contains no static executables. [x]: MUST Rpath absent or only used for internal libs. [ ]: MUST Package is not relocatable. ==== Generic ==== [x]: MUST Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: MUST Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: MUST %build honors applicable compiler flags or justifies otherwise. [x]: MUST All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: MUST Buildroot is not present Note: Buildroot is not needed unless packager plans to package for EPEL5 [x]: MUST Package contains no bundled libraries. [x]: MUST Changelog in prescribed format. [x]: MUST Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) Note: Clean is needed only if supporting EPEL [x]: MUST Sources contain only permissible code or content. [x]: MUST %config files are marked noreplace or the reason is justified. [x]: MUST Each %files section contains %defattr if rpm < 4.4 Note: defattr(....) present in %files section. This is OK if packaging for EPEL5. Otherwise not needed [x]: MUST Macros in Summary, %description expandable at SRPM build time. [x]: MUST Package requires other packages for directories it uses. [x]: MUST Package uses nothing in %doc for runtime. [x]: MUST Package is not known to require ExcludeArch. [x]: MUST Permissions on files are set properly. [x]: MUST Package does not contain duplicates in %files. [x]: MUST Spec file lacks Packager, Vendor, PreReq tags. [x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. Note: rm -rf is only needed if supporting EPEL5 [x]: MUST Large documentation files are in a -doc subpackage, if required. [x]: MUST 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]: MUST License field in the package spec file matches the actual license. [x]: MUST Package consistently uses macros (instead of hard-coded directory names). [x]: MUST Package is named according to the Package Naming Guidelines. [x]: MUST No %config files under /usr. [x]: MUST Package does not generate any conflict. [x]: MUST Package obeys FHS, except libexecdir and /usr/target. [x]: MUST Package must own all directories that it creates. [x]: MUST Package does not own files or directories owned by other packages. [x]: MUST Package installs properly. [x]: MUST Requires correct, justified where necessary. [!]: MUST Rpmlint output is silent. rpmlint novacom-server-1.1.0-0.5.rc1.fc18.src.rpm novacom-server.src: W: spelling-error %description -l en_US systemctl -> systemic novacom-server.src: W: spelling-error %description -l en_US novacomd -> Donovan 1 packages and 0 specfiles checked; 0 errors, 2 warnings. rpmlint novacom-server-1.1.0-0.5.rc1.fc18.i686.rpm novacom-server.i686: W: spelling-error %description -l en_US systemctl -> systemic novacom-server.i686: W: only-non-binary-in-usr-lib novacom-server.i686: W: no-manual-page-for-binary novacomd 1 packages and 0 specfiles checked; 0 errors, 3 warnings. rpmlint novacom-server-debuginfo-1.1.0-0.5.rc1.fc18.i686.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. >>> Can be safely ignored [x]: MUST Sources used to build the package match the upstream source, as provided in the spec URL. /home/mohamed/809114/openwebos-novacomd-submissions-119.1-0-ge77d336.tar.gz : MD5SUM this package : 9cdb4ee0de1942100a9000506889dfb2 MD5SUM upstream package : 9cdb4ee0de1942100a9000506889dfb2 [x]: MUST Spec file is legible and written in American English. [x]: MUST Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: MUST Package contains a SysV-style init script if in need of one. [x]: MUST File names are valid UTF-8. [x]: MUST Useful -debuginfo package or justification otherwise. [x]: SHOULD Reviewer should test that the package builds in mock. [x]: SHOULD If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: SHOULD Dist tag is present. [x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q --requires). [x]: SHOULD Package functions as described. [x]: SHOULD Latest version is packaged. [x]: SHOULD Package does not include license text files separate from upstream. [ ]: SHOULD Patches link to upstream bugs/comments/lists or are otherwise justified. [x]: SHOULD Scriptlets must be sane, if used. [!]: SHOULD SourceX / PatchY prefixed with %{name}. Note: Source0: https://github.com/openwebos/novacomd/tarball/versions/1.1.0-rc1 /openwebos-novacomd-submissions-119.1-0-ge77d336.tar.gz (openwebos- novacomd-submissions-119.1-0-ge77d336.tar.gz) Source1: novacomd.service (novacomd.service) Source2: config-novacomd (config-novacomd) Patch0: 0001-Use-usb_bulk_-read-write-instead-of-homemade-handler.patch (0001 -Use-usb_bulk_-read-write-instead-of-homemade-handler.patch) Patch1: novacomd_add_cflags.patch (novacomd_add_cflags.patch) Patch2: novacomd- quiet-logging.patch (novacomd-quiet-logging.patch) >>> Not a blocker [x]: SHOULD SourceX is a working URL. [ ]: SHOULD Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: SHOULD Package should compile and build into binary rpms on all supported architectures. [ ]: SHOULD %check is present and all tests pass. [!]: SHOULD Packages should try to preserve timestamps of original installed files. >>> See below [x]: SHOULD Spec use %global instead of %define. Issues: [x]: MUST Buildroot is not present Note: Buildroot is not needed unless packager plans to package for EPEL5 See: http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag [x]: MUST Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) Note: Clean is needed only if supporting EPEL See: http://fedoraproject.org/wiki/Packaging/Guidelines#.25clean [x]: MUST Each %files section contains %defattr if rpm < 4.4 Note: defattr(....) present in %files section. This is OK if packaging for EPEL5. Otherwise not needed See: http://fedoraproject.org/wiki/Packaging/Guidelines#FilePermissions [x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. Note: rm -rf is only needed if supporting EPEL5 See: None [ ]: MUST Rpmlint output is silent. rpmlint novacom-server-1.1.0-0.5.rc1.fc18.src.rpm novacom-server.src: W: spelling-error %description -l en_US systemctl -> systemic novacom-server.src: W: spelling-error %description -l en_US novacomd -> Donovan 1 packages and 0 specfiles checked; 0 errors, 2 warnings. rpmlint novacom-server-1.1.0-0.5.rc1.fc18.i686.rpm novacom-server.i686: W: spelling-error %description -l en_US systemctl -> systemic novacom-server.i686: W: only-non-binary-in-usr-lib novacom-server.i686: W: no-manual-page-for-binary novacomd 1 packages and 0 specfiles checked; 0 errors, 3 warnings. >>> Can be ignored safely. rpmlint novacom-server-debuginfo-1.1.0-0.5.rc1.fc18.i686.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. ---- Some (last!) comments, according to the above tests: - you should add the -p flag to the install command to preserve timestamps; - the sources embed parts of zlib (see in src/lib/cksum/), fortunately neither used nor called by novacomd. You could drop them as you did with libtomcrypt in novacom-client. Anyway, these two issues are minor enough not be blockers. I trust you to fix them before importing the package. So this package is APPROVED.
Mohamed, thanks much for the review!!! I'll go ahead and fix the last few things before pushing the first builds. And I will be maintaining two separate specs for EL and Fedora (mainly because of the SysV vs. systemd differences).
New Package SCM Request ======================= Package Name: novacom-server Short Description: Utility to connect to WebOS devices Owners: jdieter Branches: f15 f16 f17 el5 el6 InitialCC:
Git done (by process-git-requests).
novacom-server-1.1.0-0.6.rc1.fc17,novacom-client-1.1.0-0.4.rc1.git.ff7641193a.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/novacom-server-1.1.0-0.6.rc1.fc17,novacom-client-1.1.0-0.4.rc1.git.ff7641193a.fc17
novacom-server-1.1.0-0.6.rc1.fc17, novacom-client-1.1.0-0.4.rc1.git.ff7641193a.fc17 has been pushed to the Fedora 17 testing repository.
novacom-server-1.1.0-0.6.rc1.fc17, novacom-client-1.1.0-0.4.rc1.git.ff7641193a.fc17 has been pushed to the Fedora 17 stable repository.