Bug 229591

For a start:
- It would have made life easier for reviewers if you had provided links to the
spec and src.rpm, not to a tar
- Vendor should not be used, it will set by the build system
- Source should be a full URL to the downloadable file
- BuildRoot does not respect the current mandatory value (you can leave it alone
for now, the value is still under discussion) as specified by
wiki/PackagingGuidelines
- There is no Changelog entry

More comments later

Here we go: comments after successfully building in mock/rawhide/i386:
- build step does not take into account $RPM_OPT_FLAGS
- the generated debuginfo package is empty
- according to wiki/PackagingGuidelines/Conditional dependencies, the GUI rpm
should be generated by default, so I suggest to use as default the "with_gui"
flag rather then "without gui"
- what is the rationale behind installing the binaries with bin.bin as owner and
555 as permissions?
- I see no reason in defining the name, version and release in private macros
and then using them to set the Name, Version and Release tags. You can as well
define directly those three and use them later in the spec.
- last but nit least, rpmlint says
E: lshw description-line-too-long
Please split the line in chunks of no more then 72 chars

PS: in the previous comment, the line about the Vendor tag should have been:
Vendor should not be used, it will be set by the build system (see
wiki/PackagingGuidelines/Tags)

You should also fix the following warnings triggers by rpmlint when processing
the src.rpm obtained via rpmbuild -ts lshw.tar.gz:

W: lshw strange-permission lshw.spec 0600
Obvious fix here
W: lshw setup-not-quiet
Just use %setup -q
W: lshw mixed-use-of-spaces-and-tabs (spaces: line 2, tab: line 54)
Please use either spaces or tabs

Patrick? Any progess in fixing the spec ?

I have contacted the owner of that software. He has mentioned that he is going
to work on fixing some of those issue.

See http://ezix.org/project/ticket/111

I have discussed with my friend and he is having difficulties with the 'the
generated debuginfo package is empty' He has no clue on what should be done.

On the other side he is also short of time, so if you can recommend update to
the .spec he might be able to take them.

On the with_gui option by default, this is valid only if you have a GTK
environment, so I think it is more reasonable to have by default only without_gtk

Here is an updated version of the .spec more in line with Fedora Packaging
requirements

http://ezix.org/project/browser/packages/lshw/development/src/lshw.spec.in

I will try to look at it as soon as my time permits.

Please provide the src.rpm and spec in a downloadable format. I've tried to find
out how to download them from trac but I did not discover the right buttons to
press. wget
http://ezix.org/project/browser/packages/lshw/development/src/lshw.spec.in gives
some useless html stuff.

Created attachment 154834 [details]
lshw.spec

Created attachment 154835 [details]
rpm source package

The correct path to get the .spec.in is :
http://ezix.org/source/packages/lshw/development/src/lshw.spec.in

The spec provided by the link in comment #12 contains the string @VERSION@
instead of the current version, which makes it unusable.


I have built in mock the src.rpm from comment #11 and I have found the following
issues:
- the release field does not use %dist. It is not mandatory and you are allowed
to not use it, but in this case it would be useful to provide a reason for
avoiding to use it
- Source 0 is not available
(http://www.ezix.org/software/files/lshw-0.20070516152048.tar.gz)
Please fix the path.
- /usr/bin/install is part of the default buildroot, no need to specifically
request it via BR
- timestamps of the files included (docs mostly) are not preserved; usually this
can be solved using "cp -p" or "install -p", as needed (for instance you could
probably add INSTALL="%__install -p" to the make commands )
- the generated debuginfo rpm is empty. You should patch the Makefiles and
remove the references to strip. In addition to that, at the first glance it
looks like the "STRIP=/bin/true" lines from %install are useless
- the changelog has not been updated to reflect the current version of the spec

 * The .spec file link of comment #12 is a *template* .spec file, that means
that @VERSION@ is replaced at release time by proper version number. -> wontfix

 * %dist is Fedora-specific -> wontfix

 * only released versions are made available, therefore Source0 doesn't exist
for snapshots -> wontfix

 * /usr/bin/install build requirement will be removed

 * good point about timestamps, this will be fixed

 * 'stripping' of executables needs some rework

 * changelog will only be updated for released versions -> wontfix

If Source0 only exists for snapshots, then do not submit for review source rpms
which rely on them. Please see
http://fedoraproject.org/wiki/Packaging/Guidelines#head-c17fb8c1ce9be40da720a2b25d1e2a241062038f
and http://fedoraproject.org/wiki/Packaging/SourceURL. 
Same goes for Changelog (see
http://fedoraproject.org/wiki/Packaging/Guidelines#head-b7d622f4bb245300199c6a33128acce5fb453213
for details).

-debuginfo generation should be fixed now (in Subversion, cf. comment #12).

Once again, please be as kind as to provide full URL for the actual spec and
src.rpm that you want to be reviewed, not to templates. I really do not have the
time to figure out how to retrieve the info from yet another svn

I am giving up the review, I do not have the time to dig for specs in svn.

To the submitter and upstream. 
While the spec template in the upstream tarball can be used as a starting point,
its not what is under review here, and there are no expectations on the part of
fedora on whats in it. It would not be used in any way during the build of the
fedora package. 
The result of the review process should be a fedora specific spec file for the
software in question to be included in the fedora cvs repo. It should conform to
the fedora packaging guidelines. It should be prepared by the submitter and
linked here for review.

I was a bit quick and created a package before I saw this bz report.

I have now posted my work here:

SPEC: http://web.phys.ntnu.no/~terjeros/lshw/lshw.spec
SRPMS: http://web.phys.ntnu.no/~terjeros/lshw/lshw-2.10-2.fc7.src.rpm

It's based on the 2.10 release tarball, the following is fixed:

patch to avoid stripping (debuginfo package is non empty),
create desktop file for the GUI app (with icon),
moved bins to /usr/bin, fixed buildroot, src url and url, 
build with %{optflags} and is rpmlint clean.

I can maintain this for Fedora over reporter can use my work
to maintain it.

Anyway, of course it has to be reviewed first, Manuel do want
to have a look?

Patrick: Yanko is correct in stating the spec needs to be Fedora specific and
live in the fedora cvs. Are you happy for Terje to take over and develop the
spec for fedora ?

Terje: I am not a reviewer nor sponsor, but I want to help get this package into
a suitable state to be included in Fedora. One thing I noticed is that upstream
have released a later version: 
http://dev.ezix.org/software/files/lshw-B.02.11.tar.gz

Are you still keen to be maintainer for lshw ?

> Are you still keen to be maintainer for lshw ?

Yes, updated to 2.11:

SPECS: http://terjeros.fedorapeople.org/lshw/lshw.spec
SRPMS: http://terjeros.fedorapeople.org/lshw/lshw-2.11-1.fc7.src.rpm

Thank you Terje for taking care of the Fedora flavour ;)

Just one thing: the version is B.02.11, not 2.11. Please stick to the official
version numbers to prevent confusion and problems with upgrades (RPM seems to
think that B.02.11 < 2.04).

(In reply to comment #22)
> > Are you still keen to be maintainer for lshw ?
> 
> Yes, updated to 2.11:
> 
> SPECS: http://terjeros.fedorapeople.org/lshw/lshw.spec
> SRPMS: http://terjeros.fedorapeople.org/lshw/lshw-2.11-1.fc7.src.rpm
> 
> 

> Just one thing: the version is B.02.11, not 2.11. Please stick to the official
> version numbers to prevent confusion and problems with upgrades (RPM seems to
> think that B.02.11 < 2.04).

Ok, will your next major release be C.x.y or 1.0.x?

Different issue: does lshw need dmidecode or other tools to work?

 - Terje

(In reply to comment #23)
> Just one thing: the version is B.02.11, not 2.11. Please stick to the official
> version numbers to prevent confusion and problems with upgrades (RPM seems to
> think that B.02.11 < 2.04).

Your version numbers might make sense to you but they are way off the normal
package versioning practices, and certainly alien to any distribution versioning
scheme (which has the purpose of preventing stuff like B.02.11 < 2.04). 
So, since you seem to be keeping al least the numeric part of the version in
some common order thats what he is using.

 * all releases are named T.x.y[.z] so there may be B.02.12 < B.02.20 < C.03.01

 * lshw is trying to be self-contained so it doesn't require dmidecode, lspci, etc.

cheers,
Lyonel.

(In reply to comment #24)
> > Just one thing: the version is B.02.11, not 2.11. Please stick to the official
> > version numbers to prevent confusion and problems with upgrades (RPM seems to
> > think that B.02.11 < 2.04).
> 
> Ok, will your next major release be C.x.y or 1.0.x?
> 
> Different issue: does lshw need dmidecode or other tools to work?
> 
>  - Terje
> 

>  * all releases are named T.x.y[.z] so there may be B.02.12 < B.02.20 < C.03.01

Ok, that's fine.
 
>  * lshw is trying to be self-contained so it doesn't require dmidecode, lspci, 

Good.

Updated package:

SPECS: http://terjeros.fedorapeople.org/lshw/lshw.spec
SRPMS: http://terjeros.fedorapeople.org/lshw/lshw-B.02.11-1.fc7.src.rpm

as a sidenote: for an explanation of that (weird?) versioning scheme, you can
have a look at http://ezix.org/project/wiki/VersionNumbers

(In reply to comment #25)
> (In reply to comment #23)
> > Just one thing: the version is B.02.11, not 2.11. Please stick to the official
> > version numbers to prevent confusion and problems with upgrades (RPM seems to
> > think that B.02.11 < 2.04).
> 
> Your version numbers might make sense to you but they are way off the normal
> package versioning practices, and certainly alien to any distribution versioning
> scheme (which has the purpose of preventing stuff like B.02.11 < 2.04). 
> So, since you seem to be keeping al least the numeric part of the version in
> some common order thats what he is using.

(In reply to comment #28)
> as a sidenote: for an explanation of that (weird?) versioning scheme, you can
> have a look at http://ezix.org/project/wiki/VersionNumbers

Some points on that.
- You cannot expect people to obey your desire to not package your X.. or T..
versions. Especially in bleading edge Fedora land. And this is where this
version scheme fails with rpm because X.00 > T.01 > C.02
- Fedora has guidelines on including such non-numeric information in the release
field. These guidelines are probably the reason there is not a single package
with non-numeric version in the repository.
- All the other major distributions have stripped this field when packaging lshw. 


> (In reply to comment #25)
> > (In reply to comment #23)
> > > Just one thing: the version is B.02.11, not 2.11. Please stick to the official
> > > version numbers to prevent confusion and problems with upgrades (RPM seems to
> > > think that B.02.11 < 2.04).
> > 
> > Your version numbers might make sense to you but they are way off the normal
> > package versioning practices, and certainly alien to any distribution versioning
> > scheme (which has the purpose of preventing stuff like B.02.11 < 2.04). 
> > So, since you seem to be keeping al least the numeric part of the version in
> > some common order thats what he is using.
> 
> 

(In reply to comment #29)
> ...there is not a single package with non-numeric version in the repository.

Apparently I am wrong. There are 7.
Still given the X. > T. > C. argument I think it would be wiser not to let that
particular release distinction be first in the version.

Even if it does include its own copy of PCI/USB/etc. database (normally provided
by hwdata on Fedora I think), lshw can make use of it (if installed under the
usual locations like /usr/share, etc.), especially if the hwdata version is more
recent than lshw's...

Is there a way to "recommend" a package (as it's not really a dependency)? I
think Debian has something similar to this.
In practice requiring hwdata wouldn't be a big problem I guess...

>especially if the hwdata version is more
> recent than lshw's...

And one point of maintaining the db, I will look into this issue and make a 
decision, thanks for the hands up.
 
> Is there a way to "recommend" a package (as it's not really a dependency)? I
> think Debian has something similar to this.

It's on Panu's (fedora rpm maintainer) TODO list if I am not mistaken.
 

(In reply to comment #28)
> as a sidenote: for an explanation of that (weird?) versioning scheme, you can
> have a look at http://ezix.org/project/wiki/VersionNumbers
A= alpha ?
B= beta ?
These would be the values that most quickly pop into my mind. 
If we ever packaged a T test or X experimental version, then this versioning
system can no longer work (I understand they are not intended for release). 
They seem to tell me nothing more than the major version number. I would be keen
to drop those preceding letter.

(In reply to comment #32)
> >especially if the hwdata version is more
> > recent than lshw's...
> 
> And one point of maintaining the db, I will look into this issue and make a 
> decision, thanks for the hands up.
I would suggest that there should be only one implementation of each of these
files within Fedora and hwdata package is currently the place for this
information. My current F7 hwdata is a release from 2007-04, though.

My suggestion would be to not include in the lshw package files already supplied
by hwdata. This means that when the source of those files is updated, and we
want lshw to be able to use them, we would request an update to the hwdata
package. lshw would Requires hwdata.

Lyonel: Is updated hwdata files a sole cause for a new lshw release ?
If you are preparing to release a fix/enhancement, do you always
retrieve/include updated hwdata files ?

(In reply to comment #27)
> SPECS: http://terjeros.fedorapeople.org/lshw/lshw.spec
Just a quick look at this stage:
. Should the comment for lshw be different from lshw-gui to indicate the second
is a gui app ? Can the gui output the described file formats ?

. Does the gui app require the cli app ?

> SRPMS: http://terjeros.fedorapeople.org/lshw/lshw-B.02.11-1.fc7.src.rpm
That does not appear to be a src rpm. You need to rpmbuild the .spec to get a
.src.rpm. That is what you need to post, along with the spec for review. Lots of
good information on fedoraproject wiki.

(In reply to comment #35)
> > SRPMS: http://terjeros.fedorapeople.org/lshw/lshw-B.02.11-1.fc7.src.rpm
> That does not appear to be a src rpm.
Sorry, I was thinking bin rpm when I wrote this - please ignore, DaveT.

Can you please provide the output of rpmlint on both the src and bin rpms ?

> Should the comment for lshw be different from lshw-gui to indicate the second
> is a gui app ? 

Yes, good point, will change.

> Can the gui output the described file formats ?
>
> Does the gui app require the cli app ?

Will check.

> That does not appear to be a src rpm. You need to rpmbuild the .spec to get a
> .src.rpm. That is what you need to post, along with the spec for review. Lots of
> good information on fedoraproject wiki.

Sorry, but currently I maintain 9 packages in Fedora, I know how to create a
srpm...

> Can you please provide the output of rpmlint on both the src and bin rpms ?

There are no output :-)

Just for clarification: lshw always uses *both* DBs (its own copy, which is
updated before every release, therefore usually more recent) and the system's,
so it gets the most up-to-date information. Stripping lshw from its DB would
mean that we force it to use outdated data (10 April 2007 on my machine).

(In reply to comment #34)
> (In reply to comment #32)
> > >especially if the hwdata version is more
> > > recent than lshw's...
> > 
> > And one point of maintaining the db, I will look into this issue and make a 
> > decision, thanks for the hands up.
> I would suggest that there should be only one implementation of each of these
> files within Fedora and hwdata package is currently the place for this
> information. My current F7 hwdata is a release from 2007-04, though.
> 
> My suggestion would be to not include in the lshw package files already supplied
> by hwdata. This means that when the source of those files is updated, and we
> want lshw to be able to use them, we would request an update to the hwdata
> package. lshw would Requires hwdata.
> 
> Lyonel: Is updated hwdata files a sole cause for a new lshw release ?
> If you are preparing to release a fix/enhancement, do you always
> retrieve/include updated hwdata files ?

(In reply to comment #35)
> (In reply to comment #27)
> > SPECS: http://terjeros.fedorapeople.org/lshw/lshw.spec
> Just a quick look at this stage:
> . Should the comment for lshw be different from lshw-gui to indicate the second
> is a gui app ? Can the gui output the described file formats ?

yes it can save hw config as XML, HTML and text
 
> . Does the gui app require the cli app ?

no, but they both share some data files. I think Debian (or is it Ubuntu) split
lshw into 3 packages: lshw-data, lshw and lshw-gui

> > SRPMS: http://terjeros.fedorapeople.org/lshw/lshw-B.02.11-1.fc7.src.rpm
> That does not appear to be a src rpm. You need to rpmbuild the .spec to get a
> .src.rpm. That is what you need to post, along with the spec for review. Lots of
> good information on fedoraproject wiki.

New version is uploaded:

 SPEC: http://terjeros.fedorapeople.org/lshw/lshw.spec
 SRPM: http://terjeros.fedorapeople.org/lshw/lshw-B.02.11-2.fc7.src.rpm

I have verified that lshw-gui need lshw and that lshw is using data
from hwdata (if found).

hwdata is not very frequent updated in Fedora, hence it's little value
in requiring hwdata. If this changes and lshw releases is slowing down,
hwdata can be a requirement in later lshw releases in fedora.

License tag is changed to GPLv2 (as I read COPYING to be GPL versoin 2 only,
correct?)

More information about license tag:
 
 http://thread.gmane.org/gmane.linux.redhat.fedora.devel/60553

Looks good to me. I'd have separated SVG cliparts from core lshw package,
though: they're only used by lshw-gui.

You are correct about the license: it is still GPLv2 (I still have no firm
stance on GPLv3 so I decided to stick to a well-known and well-accepted license
for now).

Another useful trick w/ GUI could be an integration with Fedora's consolehelper
(as lshw must be run as root to report anything useful)

(In reply to comment #41)
> New version is uploaded:
> 
>  SPEC: http://terjeros.fedorapeople.org/lshw/lshw.spec
>  SRPM: http://terjeros.fedorapeople.org/lshw/lshw-B.02.11-2.fc7.src.rpm
> 
> I have verified that lshw-gui need lshw and that lshw is using data
> from hwdata (if found).
> 
> hwdata is not very frequent updated in Fedora, hence it's little value
> in requiring hwdata. If this changes and lshw releases is slowing down,
> hwdata can be a requirement in later lshw releases in fedora.
> 
> License tag is changed to GPLv2 (as I read COPYING to be GPL versoin 2 only,
> correct?)
> 
> More information about license tag:
>  
>  http://thread.gmane.org/gmane.linux.redhat.fedora.devel/60553
> 
> 

> Looks good to me. I'd have separated SVG cliparts from core lshw package,
> though: they're only used by lshw-gui.

Yes, will do.
 
> Another useful trick w/ GUI could be an integration with Fedora's consolehelper
> (as lshw must be run as root to report anything useful)

Will look into this, it would indeed be nice.

Updated packages:
 o moved artwork to gui subpackage
 o support for consolehelper (it seems to work too :-)

SPEC: http://terjeros.fedorapeople.org/lshw/lshw.spec
SRPM: http://terjeros.fedorapeople.org/lshw/lshw-B.02.11-3.fc7.src.rpm

One concern as I look through this in detail: is the included clipart patent /
copyright free. That is: is it developed by the lshw project, or used with an
appropriate open license for fedora - the ones I noticed were AMD, Apple,
bluetooth, PowerPC, USB.
I am not a licensing person, so I think we need to find the history of these
images, and determine if they are consider restricted content within the Fedora
{US based} world.

All the cliparts except the Intel logo were created from scratch using Inkscape
and are released under GPLv2 (cf. the tags in SVG files).
The Intel logo was converted from the official Intel EPS.

hope that helps...

(In reply to comment #45)
> One concern as I look through this in detail: is the included clipart patent /
> copyright free. That is: is it developed by the lshw project, or used with an
> appropriate open license for fedora - the ones I noticed were AMD, Apple,
> bluetooth, PowerPC, USB.
> I am not a licensing person, so I think we need to find the history of these
> images, and determine if they are consider restricted content within the Fedora
> {US based} world.

*** This bug has been marked as a duplicate of 251019 ***

Closing as dup to change reporter.