Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.

Summary: Review Request: lshw - Hardware lister

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251019

dtimms@iinet.net.au changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |dtimms@iinet.net.au, | |lyonel@ezix.org

------- Additional Comments From dtimms@iinet.net.au 2007-08-06 19:07 EST ------- Note: The bug "duplicate"d tracks the original submitters requests of upstream to make fedora specific changes to the upstream spec. Terje has since picked up this package, and the initial discussions and changes to the package are documented in the duplicated bug. --- Re: SPEC: http://terjeros.fedorapeople.org/lshw/lshw.spec There is something a bit weird about the versions: the upstream Changelog log is calling this B.02.12, while the src and this spec, web site call it B.02.11.01. That's probably just an oversight. --- From: http://fedoraproject.org/wiki/PackageReviewProcess#head-f3a689ab03b01268036d... "If the package is legally risky for whatever reason (known patent or copyright infringement, trademark concerns) close the bug WONTFIX and leave an appropriate comment (i.e. we don't ship mp3, so stop submitting it). Set the fedora-review flag to -, and have the review ticket block FE-Legal."

For an external trademarked logo, I believe you would have to get specific permission to use the logo in other settings/software. I don't think it would matter whether the image is an original from the owner of the trademark or recreated by an upstream project, it would still be content that can't be included.

I'll ask on f-devel-l whether such logos would be permissible content.

Lionel: if we aren't able to use other entities' trademarks, can lshw-gui operate if it can't find these images ? Would you be prepared to provide alternative non-trademarked content - eg an artistic rendering like the images of Apple boxes ? --- I notice the the installed location is now /sbin. Is it the intent that gtk-lshw not be called through consolehelper, but lshw-gui is ? {I haven't experience in this area}.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.

Summary: Review Request: lshw - Hardware lister

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251019

------- Additional Comments From terjeros@phys.ntnu.no 2007-08-07 02:27 EST -------

• I think there is a mixup in the installation section: make install

SBINDIR=/usr/sbin doesn't do anything.

Well, bins are installed in /usr/sbin

• shouldn't /usr/sbin be replaced by some %{value} (in .consolehelper)?

As %{_sbin}/%{name}-qui ?

• shouldn't /usr/bin be removed from .desktop launcher?

Why? I want to launch /usr/bin/lshw-gui, not anything else.

I notice the the installed location is now /sbin.

Yes, Lyonel said lshw* had to run as root, then they belong in /usr/sbin, the consolehelper is of course in /usr/bin, see consolehelper(8) .

Is it the intent that gtk-lshw not be called through consolehelper, but lshw-gui is ? {I haven't experienc in this area}.

A choice I made, the result is that normal users will not see the gtk-lshw command, only lshw-gui. Don't a big problem?

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.

Summary: Review Request: lshw - Hardware lister

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251019

------- Additional Comments From terjeros@phys.ntnu.no 2007-08-07 12:54 EST ------- spot, fedora's license guru has spoken:

http://article.gmane.org/gmane.linux.redhat.fedora.devel/60831

I will rm -f the in svgs that can't be shipped.

Would of course be nice to have those replaced, however I don't see this as blocker for inclusion in fedora (as long the app will work without the svgs.)

Thanks for the help, David.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.

Summary: Review Request: lshw - Hardware lister

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251019

------- Additional Comments From dtimms@iinet.net.au 2007-08-11 10:15 EST ------- (In reply to comment #7)

After talking with spot I have removed some logos, package should be safe now.

lshw-gui seems to work ok without the logos.

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

In terms of the requiring admin privileges to run: lshw can run as a normal user - if so, only hardware information available as a normal user will be shown. More information is show if run as root {or through consolehelper}.

Pre-review of lshw-B.02.11.01-2.fc7.src.rpm: ===== key: .x = Not ok .? = Either I don't understand enough to confirm that the element is acceptable, or I don't understand what the spec is doing. I would request some comment to explain if you believe that the item is OK. ./ = tick - OK. No work required. Usually a comment was included after: to describe what I found. ===== MUST Items: ./ rpmlint result: no warnings nor errors. ./ named according to the Package Naming Guidelines: matches upstream project and source download name. ./ spec file name matches the base package: lshw.spec lshw .? package must meet the Packaging Guidelines. ./ package must be licensed with an open-source compatible license: - web site indicates GPL and upstream source includes GPLv2. ./ License field in the package spec file must match the actual license: - GPLv2 as required by new licensing guideline ./ source package includes the text of the license, so text of the license(s) for the package must be included in %doc: - COPYING is included as required. - 6* Trademark svg graphics are included in the source tarball, but the spec removes them. Discussion on fedora-devel and with spot lead to this requirement. - build log shows successful removal: + for f in powermacg5 intel powermac amd mini powerpc + rm -fv /var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powermacg5.svg removed `/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powermacg5.svg' + for f in powermacg5 intel powermac amd mini powerpc + rm -fv /var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/intel.svg removed `/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/intel.svg' + for f in powermacg5 intel powermac amd mini powerpc + rm -fv /var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powermac.svg removed `/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powermac.svg' + for f in powermacg5 intel powermac amd mini powerpc + rm -fv /var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/amd.svg removed `/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/amd.svg' + for f in powermacg5 intel powermac amd mini powerpc + rm -fv /var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/mini.svg removed `/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/mini.svg' + for f in powermacg5 intel powermac amd mini powerpc + rm -fv /var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powerpc.svg removed `/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powerpc.svg'

- emac.svg {artistic view of apple logo} is still included - is it OK to include in Fedora ?

./ The spec file must be written in American English. ./ spec file for the package must be legible: ./ source in .src.rpm matches upstream md5sum: - $ md5sum lshw-B.02.11.01.tar.gz 23debbc3c0a719f301861cfc079b3f4b lshw-B.02.11.01.tar.gz {web source} 23debbc3c0a719f301861cfc079b3f4b /usr/src/redhat/SOURCES/lshw-B.02.11.01.tar.gz

./ successfully compiles and builds into binary rpms: i386 {athlon} .? If the package does not successfully compile, build or work on an architecture - : - I tried only on i386{i686/athlon} - no excludearchs listed. - have you tested on x86_64 or mac ?

./ build dependencies must be listed in BuildRequires: - no listed BR is in the auto included list - the package built on my system - package built in mock - built package runs OK, works as expected ./ spec file MUST handle locales properly: - neither find_lang macro nor %{_datadir}/locale are used. ./ has no shared library files: - contains only standalone executables with external text lookup files ./ not relocatable and does not use Prefix: /usr ./ package must own all directories that it creates: - ./ A package must not contain any duplicate files in the %files listing: - does not appear to. ./ Permissions on files must be set properly. - Executables are set with executable permissions - other files aren't - %files section includes a %defattr(...) line. .x must have a %clean section, containing rm -rf %{buildroot} (or $RPM_BUILD_ROOT): - %{__rm} -rf %{buildroot} differs from this requirement.

.? Each package must consistently use macros: - no new macros are defined. - %{x} are actually %{__X}, again, why ?

./ The package must contain code, or permissable content. - contains a GUI app ./ Large documentation files: - no. total doc is 43kB ? - COPYING is included in both lshw and lshw-gui. However, lshw-gui Requires lshw, so the COPYING is guaranteed to be installed already. I don't know if that is normal, or whether it could / should be removed.

./ %doc files must not affect the runtime of the application: - OK. ./ Header files must be in a -devel package: - no header files. ./ Static libraries must be in a -static package: - no static libraries. ./ has no pkgconfig(.pc) files. ./ library files with a suffix: no libraries ./ devel packages must require the base package: - no -devel package ./ Packages must NOT contain any .la libtool archives - no .la's ./ Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install - done and the menu entry works. ./ Packages must not own files or directories already owned by other packages. .x At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT): - the command is: %{__rm} -rf %{buildroot}, which is not standard, why ?

./ All filenames in rpm packages must be valid UTF-8.

SHOULD Items: ./ If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it: included. ./ The description and summary sections in the package spec file should contain translations for supported Non-English languages: - no other translations available .? The package should compile and build into binary rpms on all supported architectures: - only tested on i386 {athlon}

./ package functions as described - both GUI and CLI provide a lot of hw information as the summary describes ./ If scriptlets are used, those scriptlets must be sane: - none used. ./ subpackages other than devel should require the base package using a fully versioned dependency. ./ no pkgconfig(.pc) files. ./ no file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin. ===== Personally, I think console helper should be saying ~"this program performs better when run with root privileges", and give the normal user a chance to ~run unprivileged". This makes the app at least somewhat useful if you do not have root rights on the system. This might also means not placing in /usr/sbin ?

I also suggest: that even though lshw includes a copy of hw data, that any such files included by fedora hwdata should not be packaged. This has the advantages of: - removes any confusion / discrepancy that would otherwise occur if the result of other fedora hardware tools is compared to lshw that included different hwdata files. - shouldn't require updates to lshw when only hw data has been updated.

disadvantages: - fedora's hwdata does not seem to be updated very often - but perhaps it should get updated say once a month or so to take into account newly released hardware. - if lshw is updated {upstream updates all hw data before a release}, the fedora lshw would not be able to immediately use new data. This is countered by the fact that a package should be essentially static during a distribution's release life. If the main change is to hw data - then only a new hwdata should be released.

What do others think ?

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.

Summary: Review Request: lshw - Hardware lister

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251019

------- Additional Comments From lyonel@ezix.org 2007-08-11 12:56 EST ------- (In reply to comment #8)

(In reply to comment #7)

...

After talking with spot I have removed some logos, package should be safe now.

lshw-gui seems to work ok without the logos.

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

In terms of the requiring admin privileges to run: lshw can run as a normal user

• if so, only hardware information available as a normal user will be shown.

More information is show if run as root {or through consolehelper}.

The problem is that the reported information will be highly inaccurate (and, on certain platforms like x86, not only incomplete but *different* from what you get as root) when lshw is run as normal user. Maybe I should add a warning in the GUI (like what you get when running the CLI as non-root user). What do others think?

Pre-review of lshw-B.02.11.01-2.fc7.src.rpm: ===== key: .x = Not ok .? = Either I don't understand enough to confirm that the element is acceptable, or I don't understand what the spec is doing. I would request some comment to explain if you believe that the item is OK. ./ = tick - OK. No work required. Usually a comment was included after: to describe what I found. ===== MUST Items: ./ rpmlint result: no warnings nor errors. ./ named according to the Package Naming Guidelines: matches upstream project and source download name. ./ spec file name matches the base package: lshw.spec lshw .? package must meet the Packaging Guidelines. ./ package must be licensed with an open-source compatible license:

• web site indicates GPL and upstream source includes GPLv2.

./ License field in the package spec file must match the actual license:

• GPLv2 as required by new licensing guideline

./ source package includes the text of the license, so text of the license(s) for the package must be included in %doc:

• COPYING is included as required.
• 6* Trademark svg graphics are included in the source tarball, but the spec

removes them. Discussion on fedora-devel and with spot lead to this requirement.

• build log shows successful removal:

• for f in powermacg5 intel powermac amd mini powerpc
• rm -fv

/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powermacg5.svg

removed

`/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powermacg5.svg'

• for f in powermacg5 intel powermac amd mini powerpc
• rm -fv

/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/intel.svg removed `/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/intel.svg'

• for f in powermacg5 intel powermac amd mini powerpc
• rm -fv

/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powermac.svg removed

`/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powermac.svg'

• for f in powermacg5 intel powermac amd mini powerpc
• rm -fv

/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/amd.svg removed `/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/amd.svg'

• for f in powermacg5 intel powermac amd mini powerpc
• rm -fv

/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/mini.svg removed `/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/mini.svg'

• for f in powermacg5 intel powermac amd mini powerpc
• rm -fv

/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powerpc.svg removed

`/var/tmp/lshw-B.02.11.01-2.fc7-root-mockbuild/usr/share/lshw/artwork/powerpc.svg'

I have added to lshw's SVN some drawings without logos and also "replacement" logos for intel, amd, powerpc (cf. http://dev.ezix.org/source/packages/artwork/nologo/ comments welcome).

• emac.svg {artistic view of apple logo} is still included - is it OK to

include in Fedora ?

./ The spec file must be written in American English. ./ spec file for the package must be legible: ./ source in .src.rpm matches upstream md5sum:

• $ md5sum lshw-B.02.11.01.tar.gz

23debbc3c0a719f301861cfc079b3f4b lshw-B.02.11.01.tar.gz {web source} 23debbc3c0a719f301861cfc079b3f4b /usr/src/redhat/SOURCES/lshw-B.02.11.01.tar.gz

./ successfully compiles and builds into binary rpms: i386 {athlon} .? If the package does not successfully compile, build or work on an architecture - :

• I tried only on i386{i686/athlon}
• no excludearchs listed.
• have you tested on x86_64 or mac ?

ppc is OK, that's my test/dev machine.

./ build dependencies must be listed in BuildRequires:

• no listed BR is in the auto included list
• the package built on my system
• package built in mock
• built package runs OK, works as expected

./ spec file MUST handle locales properly:

• neither find_lang macro nor %{_datadir}/locale are used.

./ has no shared library files:

• contains only standalone executables with external text lookup files

./ not relocatable and does not use Prefix: /usr ./ package must own all directories that it creates:

./ A package must not contain any duplicate files in the %files listing:

• does not appear to.

./ Permissions on files must be set properly.

• Executables are set with executable permissions
• other files aren't
• %files section includes a %defattr(...) line.

.x must have a %clean section, containing rm -rf %{buildroot} (or

$RPM_BUILD_ROOT):

• %{__rm} -rf %{buildroot} differs from this requirement.

.? Each package must consistently use macros:

• no new macros are defined.
• %{x} are actually %{__X}, again, why ?

./ The package must contain code, or permissable content.

• contains a GUI app

./ Large documentation files:

• no. total doc is 43kB

? - COPYING is included in both lshw and lshw-gui. However, lshw-gui Requires lshw, so the COPYING is guaranteed to be installed already. I don't know if that is normal, or whether it could / should be removed.

./ %doc files must not affect the runtime of the application:

• OK.

./ Header files must be in a -devel package:

• no header files.

./ Static libraries must be in a -static package:

• no static libraries.

./ has no pkgconfig(.pc) files. ./ library files with a suffix: no libraries ./ devel packages must require the base package:

• no -devel package

./ Packages must NOT contain any .la libtool archives

• no .la's

./ Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install

• done and the menu entry works.

./ Packages must not own files or directories already owned by other packages. .x At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT):

• the command is: %{__rm} -rf %{buildroot}, which is not standard, why ?

./ All filenames in rpm packages must be valid UTF-8.

SHOULD Items: ./ If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it: included. ./ The description and summary sections in the package spec file should contain translations for supported Non-English languages:

• no other translations available

.? The package should compile and build into binary rpms on all supported architectures:

• only tested on i386 {athlon}

./ package functions as described

• both GUI and CLI provide a lot of hw information as the summary describes

./ If scriptlets are used, those scriptlets must be sane:

• none used.

./ subpackages other than devel should require the base package using a fully versioned dependency. ./ no pkgconfig(.pc) files. ./ no file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin. ===== Personally, I think console helper should be saying ~"this program performs better when run with root privileges", and give the normal user a chance to ~run unprivileged". This makes the app at least somewhat useful if you do not have root rights on the system. This might also means not placing in /usr/sbin ?

I also suggest: that even though lshw includes a copy of hw data, that any such files included by fedora hwdata should not be packaged. This has the

advantages of:

• removes any confusion / discrepancy that would otherwise occur if the result

of other fedora hardware tools is compared to lshw that included different hwdata files.

• shouldn't require updates to lshw when only hw data has been updated.

disadvantages:

• fedora's hwdata does not seem to be updated very often - but perhaps it should

get updated say once a month or so to take into account newly released hardware.

• if lshw is updated {upstream updates all hw data before a release}, the fedora

lshw would not be able to immediately use new data. This is countered by the fact that a package should be essentially static during a distribution's release life. If the main change is to hw data - then only a new hwdata should be

released.

What do others think ?

as discussed earlier (cf. duplicate BR), lshw makes use of *both* sources (system's hwdata and bundled data files) so it always uses the most recent data. It'd be good to have Fedora's hwdata updated once a month but it's currently very old and updated infrequently. I may add an option (in the GUI) to download fresher files in the future and cache them in $XDG_CACHE_HOME/lshw (usually $HOME/.cache/lshw).

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.

Summary: Review Request: lshw - Hardware lister

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251019

------- Additional Comments From dtimms@iinet.net.au 2007-08-11 20:56 EST ------- (In reply to comment #10)

I have added to lshw's SVN some drawings without logos and also "replacement" logos for intel, amd, powerpc (cf. http://dev.ezix.org/source/packages/artwork/nologo/ comments welcome).

Perusing the nologo images, I find that actual trademarks have been replaced with chip-like icons with a plain font describing the type {alpha /amx /intel /mips /pa-risc /powerpc /sparc} and the boxen graphics show the form of the apple boxes, without using a logo.

I would say these are acceptable for inclusion in Fedora. Lyonel, will these be included in a future source release ?

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.

Summary: Review Request: lshw - Hardware lister

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251019

------- Additional Comments From terjeros@phys.ntnu.no 2007-08-13 15:04 EST -------

The problem is that the reported information will be highly inaccurate (and, on certain platforms like x86, not only incomplete but *different* from what you get as root) when lshw is run as normal user.

Agree, you should be root to run the tool consolehelper solves this.

Maybe I should add a warning in the GUI (like what you get when running the CLI as non-root user). What do others think?

A warning would be nice, however that's is feature request in lshw, is not critical for this review which is about inclusion in Fedora (let's not forget that).

I have added to lshw's SVN some drawings without logos and also "replacement" logos for intel, amd, powerpc (cf. http://dev.ezix.org/source/packages/artwork/nologo/ comments welcome).

Looks great, will include them when they are part of a proper release. Again: lshw works great without logs, this issue is not critical for this Fedora inclusion review.

as discussed earlier (cf. duplicate BR), lshw makes use of *both* sources (system's hwdata and bundled data files) so it always uses the most recent data. It'd be good to have Fedora's hwdata updated once a month but it's currently very old and updated infrequently.

In a perfect world hwdata would be updated every month, it's not so lshw must be included it's own data. Things might change and then we will adapt.

I may add an option (in the GUI) to download fresher files in the future and cache them in $XDG_CACHE_HOME/lshw (usually $HOME/.cache/lshw).

Nothing stop you, it's your software, however it outside the scope of this review.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.

Summary: Review Request: lshw - Hardware lister

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251019

------- Additional Comments From terjeros@phys.ntnu.no 2007-08-14 13:05 EST -------

=== Issues ===

1. I am not sure which license is used by the program. The Copying file mentions

the GPLv2 or later clauses,which would mean that the correct tag is GPLv2+. However I might misinterpretate it, so Lyonel, please assist and let us know what is the intended licensing scheme.

GPLv2 is correct, ref:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229591#c42

2. The source URL included was not accesible, the site seemed to be down at the

moment of the review 3. The file named "Changes" references a later version of the source. As the site for upstream was not accessible, I could not check

That is a known issue, ref: comment #3 over.

4. I will verify this a bit later.
5. Please use separate files for the pam and desktop files. Creating them in the

spec is technically OK, but is prone to errors, while using separate files allows better time/version/MD5 checking

Fixed.

6. (pedantic, feel free to ignore): Please verify if "make" and "make gui" are

both needed. I cannot test now, but at the first glance I think that "make gui" is enough, it will build everything.

You are right, fixed.

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

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.

Summary: Review Request: lshw - Hardware lister

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251019

terjeros@phys.ntnu.no changed:

What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-cvs?

------- Additional Comments From terjeros@phys.ntnu.no 2007-08-15 13:23 EST -------

Package APPROVED

Thanks for the review manuel!

Thanks to other guys too, and of course to a very helpful upstream maintainer!

- Terje

New Package CVS Request ======================= Package Name: lshw Short Description: Hardware lister Owners: terjeros Branches: FC-6 F-7 InitialCC: Cvsextras Commits: yes

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.

Summary: Review Request: lshw - Hardware lister

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251019

terjeros@phys.ntnu.no changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE

------- Additional Comments From terjeros@phys.ntnu.no 2007-08-15 17:38 EST -------

Note that your License tag should be: GPLv2+ if it's really GPL version 2 or

later.

It's GPLv2.

Bodhi done. Closing.

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=251019

--- Comment #22 from Jon Ciesla limburgher@gmail.com 2012-02-06 08:10:14 EST --- Already has EL-6 branch, to add owners see pkgdb.