Bug 809114 - Review Request: novacom-server - Utility to connect to WebOS devices
Review Request: novacom-server - Utility to connect to WebOS devices
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mohamed El Morabity
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-02 10:10 EDT by Jonathan Dieter
Modified: 2012-05-26 02:58 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-26 02:58:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pikachu.2014: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Jonathan Dieter 2012-04-02 10:10:09 EDT
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
Comment 1 Mohamed El Morabity 2012-04-02 10:22:41 EDT
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.
Comment 2 Jonathan Dieter 2012-04-02 11:30:59 EDT
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?
Comment 3 Jacek Pliszka 2012-04-04 04:44:28 EDT
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;
Comment 4 Mohamed El Morabity 2012-04-04 05:53:19 EDT
(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.
Comment 5 Jonathan Dieter 2012-04-04 06:06:44 EDT
(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
Comment 6 Mohamed El Morabity 2012-04-04 06:16:13 EDT
(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.
Comment 7 Jonathan Dieter 2012-04-04 06:20:58 EDT
(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?
Comment 8 Mohamed El Morabity 2012-04-11 11:17:09 EDT
(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.
Comment 9 Jonathan Dieter 2012-04-12 09:47:45 EDT
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".
Comment 10 Jonathan Dieter 2012-04-14 05:37:15 EDT
Mohamed, I went ahead and assigned this to you.  Is there anything else you think I need to do with this?
Comment 11 Jonathan Dieter 2012-04-19 15:27:54 EDT
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.
Comment 12 Mohamed El Morabity 2012-04-26 05:31:40 EDT
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.
Comment 13 Mohamed El Morabity 2012-04-26 05:35:01 EDT
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
Comment 14 Jonathan Dieter 2012-04-26 13:50:55 EDT
(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.
Comment 16 Jacek Pliszka 2012-04-30 04:23:46 EDT
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.
Comment 17 Jonathan Dieter 2012-05-02 07:44:55 EDT
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.
Comment 18 Jacek Pliszka 2012-05-02 16:27:54 EDT
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
Comment 19 Jonathan Dieter 2012-05-06 09:22:25 EDT
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!
Comment 20 Jacek Pliszka 2012-05-07 04:18:33 EDT
Thank you Jonathan, not it is fixed - everything works fine.

All we need now is approval.
Comment 21 Mohamed El Morabity 2012-05-07 07:32:07 EDT
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.
Comment 22 Jonathan Dieter 2012-05-07 08:19:22 EDT
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).
Comment 23 Jonathan Dieter 2012-05-07 08:21:09 EDT
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:
Comment 24 Gwyn Ciesla 2012-05-07 08:31:21 EDT
Git done (by process-git-requests).
Comment 25 Fedora Update System 2012-05-07 10:44:50 EDT
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
Comment 26 Fedora Update System 2012-05-07 18:25:38 EDT
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.
Comment 27 Fedora Update System 2012-05-26 02:58:26 EDT
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.

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