Bug 229591 - Review Request: lshw - Hardware Lister (lshw)
Review Request: lshw - Hardware Lister (lshw)
Status: CLOSED DUPLICATE of bug 251019
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-21 16:57 EST by Patrick Pichon
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-06 11:20:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lshw.spec (2.95 KB, text/plain)
2007-05-16 11:24 EDT, Patrick Pichon
no flags Details
rpm source package (1.09 MB, application/x-rpm)
2007-05-16 11:24 EDT, Patrick Pichon
no flags Details

  None (edit)
Description Patrick Pichon 2007-02-21 16:57:29 EST
Spec URL: http://ezix.org/software/files/lshw-B.02.10.tar.gz
SRPM URL: http://ezix.org/software/files/lshw-B.02.10.tar.gz
Description: lshw (Hardware Lister) is a small tool to provide detailed information on the hardware configuration of the machine. It can report exact memory configuration, firmware version, mainboard configuration, CPU version and speed, cache configuration, bus speed, etc. on DMI-capable x86 or EFI (IA-64) systems and on some PowerPC machines

PS/ I have found that tools very useful and already available on various distribution
Comment 1 manuel wolfshant 2007-02-22 14:21:18 EST
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
Comment 2 manuel wolfshant 2007-02-22 14:54:47 EST
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)

Comment 3 manuel wolfshant 2007-02-22 15:00:50 EST
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
Comment 4 manuel wolfshant 2007-03-09 21:29:13 EST
Patrick? Any progess in fixing the spec ?
Comment 5 Patrick Pichon 2007-03-10 07:28:59 EST
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
Comment 6 Patrick Pichon 2007-05-15 10:47:19 EDT
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
Comment 7 Patrick Pichon 2007-05-15 10:49:01 EDT
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
Comment 8 manuel wolfshant 2007-05-15 10:54:39 EDT
I will try to look at it as soon as my time permits.
Comment 9 manuel wolfshant 2007-05-16 08:18:16 EDT
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.
Comment 10 Patrick Pichon 2007-05-16 11:24:18 EDT
Created attachment 154834 [details]
lshw.spec
Comment 11 Patrick Pichon 2007-05-16 11:24:52 EDT
Created attachment 154835 [details]
rpm source package
Comment 12 Patrick Pichon 2007-05-16 11:29:25 EDT
The correct path to get the .spec.in is :
http://ezix.org/source/packages/lshw/development/src/lshw.spec.in

Comment 13 manuel wolfshant 2007-05-16 16:42:30 EDT
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
Comment 14 Lyonel Vincent 2007-05-16 19:08:30 EDT
 * 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
Comment 15 manuel wolfshant 2007-05-17 03:30:46 EDT
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).
Comment 16 Lyonel Vincent 2007-06-05 16:23:06 EDT
-debuginfo generation should be fixed now (in Subversion, cf. comment #12).
Comment 17 manuel wolfshant 2007-06-05 18:10:44 EDT
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
Comment 18 manuel wolfshant 2007-06-08 10:08:03 EDT
I am giving up the review, I do not have the time to dig for specs in svn.
Comment 19 Yanko Kaneti 2007-06-27 08:24:24 EDT
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.
Comment 20 Terje Røsten 2007-06-27 11:30:17 EDT
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?

Comment 21 David Timms 2007-08-01 09:16:42 EDT
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 ?
Comment 22 Terje Røsten 2007-08-01 11:11:06 EDT
> 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

Comment 23 Lyonel Vincent 2007-08-01 11:40:00 EDT
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
> 
> 

Comment 24 Terje Røsten 2007-08-01 11:52:47 EDT
> 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
Comment 25 Yanko Kaneti 2007-08-01 11:58:55 EDT
(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.
Comment 26 Lyonel Vincent 2007-08-01 12:08:19 EDT
 * 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
> 

Comment 27 Terje Røsten 2007-08-01 12:18:06 EDT
>  * 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
Comment 28 Lyonel Vincent 2007-08-01 12:36:15 EDT
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.

Comment 29 Yanko Kaneti 2007-08-01 12:54:55 EDT
(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.
> 
> 

Comment 30 Yanko Kaneti 2007-08-01 13:10:43 EDT
(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.
Comment 31 Lyonel Vincent 2007-08-01 14:42:48 EDT
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...
Comment 32 Terje Røsten 2007-08-01 18:31:40 EDT
>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.
 
Comment 33 David Timms 2007-08-01 20:05:22 EDT
(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.
Comment 34 David Timms 2007-08-01 20:07:46 EDT
(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 ?
Comment 35 David Timms 2007-08-01 20:42:18 EDT
(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.
Comment 36 David Timms 2007-08-01 20:46:31 EDT
(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.
Comment 37 David Timms 2007-08-01 20:48:47 EDT
Can you please provide the output of rpmlint on both the src and bin rpms ?
Comment 38 Terje Røsten 2007-08-02 03:06:46 EDT
> 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 :-)
Comment 39 Lyonel Vincent 2007-08-02 03:20:30 EDT
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 ?

Comment 40 Lyonel Vincent 2007-08-02 03:23:34 EDT
(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.

Comment 41 Terje Røsten 2007-08-04 14:08:35 EDT
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

Comment 42 Lyonel Vincent 2007-08-05 08:32:29 EDT
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
> 
> 

Comment 43 Terje Røsten 2007-08-05 08:41:07 EDT
> 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.
Comment 44 Terje Røsten 2007-08-05 10:07:23 EDT
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

Comment 45 David Timms 2007-08-06 07:16:57 EDT
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.
Comment 46 Lyonel Vincent 2007-08-06 08:29:19 EDT
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.

Comment 47 Terje Røsten 2007-08-06 11:20:47 EDT

*** This bug has been marked as a duplicate of 251019 ***
Comment 48 Terje Røsten 2007-08-06 11:24:15 EDT
Closing as dup to change reporter.

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