Bug 250970 - Review Request: ivtv-firmware - Firmware for the PVR 250/350/150/500/USB2 model series
Summary: Review Request: ivtv-firmware - Firmware for the PVR 250/350/150/500/USB2 mod...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jarod Wilson
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
: 346171 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-06 09:02 UTC by Axel Thimm
Modified: 2014-01-21 22:59 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-16 09:55:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jarod: fedora-review+
kevin: fedora-cvs+

Attachments (Terms of Use)

Description Axel Thimm 2007-08-06 09:02:09 UTC
Spec URL: http://dl.atrpms.net/all/ivtv-firmware-fedora.spec
SRPM URL: http://dl.atrpms.net/all/ivtv-firmware-20070217-13.src.rpm
This package contains the firmware for WinTV PVR 250/350/150/500 cards.

Comment 1 Nicolas Chauvet (kwizart) 2007-08-24 18:48:43 UTC
So, found it !

We should probably block requirement at the bugzilla level
 (if it needs for exemple ivtv and perls scripts)
I've found ivtv but not perls scripts whereas they are still Required by ivtv
ivtv is here #250971

From preliminaries comments :

1- Requirements: Check if it is necessay for the firmware to requires ivtv (or
ivtv to requires the firmware..)- then set the appropriate blocks in bugzilla

2- We should drop compats locations to only provides firmwares in /lib/firmware
for F7 -> devel

3- Buildroot: those are others values but the one choosen is acceptable also...
%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

4- ivtv-firmware.spec is the name of the spec (this is the case from the src.rpm
so everything is right...)

5- Version field is wrong: 20070217 you be taken from a release tag. If we have
0 in a version tag, I think it is acceptable to have release tag not <1. This
leads to have:
epoch: 3
version: 0
release: 1.%{snapshoot}snap
Using this if upstream ever provides version 1.0 of the firmware or else, this
scheme will continue to work...

6- setup -n %{name}-%{version} is unneeded at this time, but it will more likely
have to be replaced by -n %{name}-%{snapshot}

7- /lib/firmware/v4l-cx2341x-init.mpg is also a requirement but is arch
independant and could benefit to be bundled from an arch independant package
instead of ivtv (which one is arch dependant) - Anyway as we shouldn't be
concerned by multilibs problems with ivtv, this shouldn't be really important...

8- mv *.fw %{buildroot}/lib/firmware/ - you should better use install -pm 0644
to prevent timestamp.

9- A license to allow redistribution of the firmware is missing from the
package... Theres is Licenses files from the firmware archive and they need to
be provided in the %doc directory.

I'm not abble to state if this license allow Fedora to redistribute the firmware
within an iso so users can uses ivtv "out of the box"...

Comment 2 Nicolas Chauvet (kwizart) 2007-08-24 18:57:35 UTC
10 - URL produced a 404

Comment 3 Nicolas Mailhot 2007-08-26 18:55:14 UTC
Ok, my take (not a full review since that's already started, just a few

1. there is a lot of legacy garbage in the spec (symlinks, deps, epochs, etc).
ivtv took enough time to get cleanly upstream, IMHO the supporting packages need
the same cleanup too. Cleaning up later will be painful and users expect some
changes at Fedora inclusion time

2. URL should be http://www.ivtvdriver.org/

3. I'd simplify %install in
rm -rf %{buildroot}
install -d -m 0755 %{buildroot}/lib/firmware
install -p -m 0644 *.fw *.mpg %{buildroot}/lib/firmware/

4. I'd simplify %files in
%doc *.txt

5. I'd add a %build, even if it's empty, because %build-less specs are not
tested against @rpm.org

6. I'd change the summary to only include the actual chip reference and out the
full "… for hardware based on Conexant's CX23415/CX23416 codec chip such as the
Hauppauge PVR 150/250/350/500 models and other supported hardware." in
%description, as the current string is misleading and overly restrictive

7. the deps if any should go in the tools not in the firmware package

Comment 4 Nicolas Chauvet (kwizart) 2007-09-06 16:18:48 UTC
Axel are you still here ?
Please comments if something seems wrong to you...

Maybe someone can help packaging perl scripts if you are short in time ?

Comment 5 Axel Thimm 2007-10-24 11:46:33 UTC
(In reply to comment #4)
> Axel are you still here ?
> Please comments if something seems wrong to you...

I was not there, see the matching wiki page of that time.

> Maybe someone can help packaging perl scripts if you are short in time ?

Perl scripts for the firmware package? Which firmware related scripts are you
thinking of?

Comment 6 Axel Thimm 2007-10-24 11:55:51 UTC
(In reply to comment #3)
> 6. I'd change the summary to only include the actual chip reference and out the
> full "… for hardware based on Conexant's CX23415/CX23416 codec chip such as the
> Hauppauge PVR 150/250/350/500 models and other supported hardware." in
> %description, as the current string is misleading and overly restrictive

There are technical and legal problems:

a) the firmware is procuded by Hauppauge (with Conexant's tools) and is adjusted
   to Hauppauge's board layout. Not every board using the Mako chip can boot of
   the same firmware.

b) Even though many boards share the base schematics the firmware under
   considerartion has been channeled through Hauppauge and the license is by
   Hauppauge. IANAL, but I think you will be violating both Hauppauge's and
   another manufacturer's license if you simply use this on another board.

This is not to say that users cannot use this if they think they know there are
no technical issues and no legal ones as well. But it means that Fedora cannot
put itself in technical and legal battles with either side.

BTW no non-Hauppauge user was ever confused by the choice of the summary or
description, all PVR clones knew what firmware they needed.

Comment 7 Nicolas Chauvet (kwizart) 2007-10-24 17:15:50 UTC
Axel! I'm happy to have news from you!

But actually I would like the problem to be solved before the F8 release, so
i've took some advance:
see #346171

I will change the summary from the problem you have raised, add an epoch (or can
we drop it?) and add you to the cvs access (or you might need to request it )

Please can you make comments about the current spec I've used , before I import
it ? (ivtv-firmware and xorg-x11-drv-ivtv are not imported yet)...

see also: #346161 for xorg-x11-drv-ivtv

Comment 8 Axel Thimm 2007-10-24 17:49:53 UTC
I don't think that this rushing out was a good move. There was a reason I kept
packages compatible to what ATrpms is shipping for four year plus now. I'm also
strongly involved upstream (I even both own and host the main developer and user
site) and Fedora's credo was to keep upstream as much packaging as possible,

Comment 9 Axel Thimm 2007-10-26 06:23:33 UTC

* Wed Oct 24 2007 Axel Thimm <Axel.Thimm@ATrpms.net> - 2:20070217-15
- Add v4l-cx2341x-init.mpg as a pseudo-firmware.

Comment 10 Nicolas Chauvet (kwizart) 2007-10-26 13:25:13 UTC
OK well I still do not understand why we should keep old version compatibility ?
Because of the license, the firmware can only be provided since Fedora 7 (not
for FC6). This mean why should we keep old compatibility firmware location ?...

The main problem with that is the current package conflict with "Filesystem
Hierarchy Standard" and directory ownership may be wrong if those directory do
not exist anymore:

- Please keep timestamps as this is an easy fix
- Do what you think is right for symlink and version (note that the ubuntu
package from the upstream site uses version 0-%{date} )...

Comment 11 Nicolas Chauvet (kwizart) 2007-11-08 15:49:52 UTC
Still no news...?!

Comment 12 Axel Thimm 2007-11-29 16:56:56 UTC
What news should I be offering? I disagree with both the takeover mentality and
the wish to drop compatibility to established usage over half a decade now.
Sure, drop compatibility when it's in the way, but not for just dropping it.

The same package works under RHEL3 for example ...

Comment 13 Nicolas Chauvet (kwizart) 2007-11-29 20:08:48 UTC
Axel,I wouldn't ask you if you have some news if I just want to takeover the
package... nothing as been imported yet.

This is not a aim by itself to have a package that will be usable from RHEL3 to
F-9. For example we do not use the hotplug directory anymore, nor is possible to
have compatibility firmwares locations since they are not used within Fedora
(since kernel 2.6.22).

What is wrong in this package are directory ownership,
This must be fixed... (even if this is a minor thing)

Then any third part package can provided the needed compatibility firmware
locations (if ever a third part repo will package an older version of the ivtv's
kernel modules).

Also it is really desirable to prevent timestamps changes while packaging the
the files provided...

Comment 14 Nicolas Chauvet (kwizart) 2007-12-12 12:23:44 UTC
ping ?

Comment 15 Axel Thimm 2007-12-12 14:59:38 UTC
Note that the timestamps are not original. When I wrote the license on
Haupauge's behalf I also asked if I could pick the original files and that is
not possible due to internal reasons. So the timestamps that the files have on
both of my sites, ivtvdriver.org and atrpms.net are the ones from the extraction
time, not any upstream time.

Despite of that I agree it is better for people learning by reading specfiles to
keep timestamps otherwise they will be copying wrong idioms.

Comment 16 Nicolas Chauvet (kwizart) 2007-12-15 12:17:44 UTC
Well, I'm not sure if I understand: do you agree to keep timestramp in the next
release ? timestamps could be a problem with delta rpms when changes are not
made to the firmware but they have not keepted from "original" source files.

Keeping the timestamps from the original package gives more info. For example
this indicate that the files wasn't modified since years instead of when the
package was build on our Build system.

As soon as you update to the new release i will change cvs so you can import it
Maybe you could use conditionals for compatibility firmware locations so we it
get rebuild on a EL-3 or FC-4 system, it it have the compatibility part...

Comment 17 Axel Thimm 2007-12-22 12:17:39 UTC
OK, your timestamp comment was a red herring, I should had checked earlier. All
timestamps had already "original" from the beginning:

# ls -ltrAd `rpm -ql ivtv-firmware` | grep -v lrwxrwxrwx
-rw-r--r-- 1 root root  16382 May 26  2006 /lib/firmware/v4l-cx25840.fw
-rw-r--r-- 1 root root 262144 May 26  2006 /lib/firmware/v4l-cx2341x-dec.fw
-rw-r--r-- 1 root root 155648 May 26  2006 /lib/firmware/v4l-cx2341x-init.mpg
-rw-r--r-- 1 root root   8192 Jul  1  2006 /lib/firmware/v4l-pvrusb2-29xxx-01.fw
-rw-r--r-- 1 root root   8192 Oct  6  2006 /lib/firmware/v4l-pvrusb2-24xxx-01.fw
-rw-r--r-- 1 root root 376836 Feb 17  2007 /lib/firmware/v4l-cx2341x-enc.fw

Comment 18 Nicolas Chauvet (kwizart) 2007-12-24 15:00:35 UTC
I will check again this week. But I wonder It will work if rebuilt in mock 
(it should work like this in all cases anyway...)

Also about the compat section... Do you have something against building with
Fedora   conditionnals? So, if build tag is from Fedora 7 (or older, depend on
last time hotplug was used). then the entire compat part will be dropped. (so
the same spec will be used for all version).

Comment 19 Axel Thimm 2007-12-26 11:15:35 UTC
Spec URL: http://dl.atrpms.net/all/ivtv-firmware.spec
SRPM URL: http://dl.atrpms.net/all/ivtv-firmware-20070217-15.1.src.rpm

* Sat Dec 22 2007 Axel Thimm <Axel.Thimm@ATrpms.net> - 2:20070217-15.1
- Own directories from legacy paths.

This addresses the following comment further up:
> What is wrong in this package are directory ownership,
> This must be fixed... (even if this is a minor thing)

Comment 20 Nicolas Chauvet (kwizart) 2008-01-02 15:33:21 UTC
Happy New Year Axel!

(In reply to comment #19)
> This addresses the following comment further up:
> > What is wrong in this package are directory ownership,
> > This must be fixed... (even if this is a minor thing)

I think you miss me, your package cannot own directories that are targeted to
the filesystem, that's why I think it is better to remove them. That way, the
package will be good for the next half decade (as i expect).
That been said, keeping compat location are fine for RHEL4 and RHEL5, (if this
make sense to have them, but i don't think so as your repository have 0.10.6 for
RHEL5 and 2.6.18 kernels)... But for the currently supported Fedora version
(since Fedora 7 and Rawhide), I don't see any reason for keeping them... since
we use kernel 2.6.22 and later...

About preventing timestamps, you are right so this is fine as it is...

What remain are:
- compat location problem.
- no Doc are provided (this is mandatory to have them when they are provided
within the package: license-oemihvisv.txt and license-end-user.txt - so probably
both are needed).
All others points raised in this review are acceptable...

So to avoid conflict with the compat location problem I will try to ask advices
from others reviewers as:
- I don't see any reason to keep them as this will be useful only for older
version of the ivtv kernel module that I expect not to build against current
Fedora kernels.
- Fedora version that still use hotplug can have an older ivtv-firmware version
(as such I can agree to have a build conditional to provide them with older
Fedora version but not with the currently supported Fedora - Or to have
different specs in cvs branches for RHEL4/5 and Fedora)
- No userland application (in Fedora or elsewhere) really needs theses compat
location in currently maintained Fedora versions.
- Theses compat locations produce ownership directory problems , as such
deprecated location must be cleaned from the package.

If you disagree with some of theses points, please explain why.

Comment 21 Nicolas Chauvet (kwizart) 2008-01-10 02:46:01 UTC
It would be fine to have this fixed for the alpha for F-9...

I mean before 15/01/2008

Comment 22 Juha Tuomala 2008-01-10 10:20:34 UTC
Speaking of targets, hopefully this will see daylight in f8 too as f9 is still 
quite far away.

Comment 23 Nicolas Chauvet (kwizart) 2008-02-02 10:53:19 UTC

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

Comment 24 Axel Thimm 2008-02-02 21:17:56 UTC
*** Bug 346171 has been marked as a duplicate of this bug. ***

Comment 25 Axel Thimm 2008-02-02 22:14:38 UTC
The compat bits don't harm and they do cater now for their removal by rpm itself
once the package is commissioned to be deinstalled.

The licenses have been placed next to firmware location, although I removed that
specific wording when writing the licenses. But let's not split hairs.

Spec URL: http://dl.atrpms.net/all/ivtv-firmware.spec
SRPM URL: http://dl.atrpms.net/all/ivtv-firmware-20070217-16.src.rpm

Comment 26 Nicolas Chauvet (kwizart) 2008-02-04 10:26:01 UTC
Axel, I see no improvement about the compat location field with this version.

I've learn that when ivtv was in work to be merged within the kernel, they was a
problem because it was using it owns firmware loader, instead of the one within
the kernel. Actually the compat needs may not be related to using hotplug or
else, but using the firmware loader of an older ivtv version when it wasn't
merged in yet.

I don't knwow the status of userland app (mythtv), that can use the kernel
version or the "external" version.

Am I right ? or the compat location is only related to have the same package for
all dist ?

Comment 27 Axel Thimm 2008-02-14 19:30:59 UTC
(In reply to comment #26)
> I see no improvement about the compat location field with this version.

Any "issues" whatsoever with the compatibility with RHEL have been resolved, I
would call that improvement.

I don't see compatibility with RHEL a blocker, why do you resist passing this

Comment 28 Nicolas Chauvet (kwizart) 2008-02-19 00:26:21 UTC
I don't understand! You mean you want to maintain this package for RHEL via EPEL ?
I don't even know which kernel is there. 

Comment 29 Axel Thimm 2008-02-19 10:16:33 UTC
If you don't even know what kernel resides in RHEL, why not simply trust me on
that or investigate that the same firmware applies ...

At any rate the compatibility bits do not hurt and people can only benefit from
it. Please either pass this package or stop stalling.

Comment 30 Nicolas Chauvet (kwizart) 2008-02-19 14:42:24 UTC
(In reply to comment #29)
> If you don't even know what kernel resides in RHEL, why not simply trust me on
> that or investigate that the same firmware applies ...
Because a review isn't a matter of blind trust but questions/answears.
Questions are here, answears not.

> At any rate the compatibility bits do not hurt and people can only benefit from
> it. Please either pass this package or stop stalling.
Well the review have been approved here: #346171 is now imported into cvs and
will hit stable on next push.

Comment 31 Axel Thimm 2008-02-19 15:36:58 UTC
Bug #346171 is a rogue takeover.

Comment 32 Seth Vidal 2008-02-19 21:09:59 UTC

Nicolas: you're not being cool. Don't play this game on a single package
Axel: Don't talk down to Nicolas - or at least that's how I'm perceiving it.
Answer the questions he has. 

Seriously, play nice.

Comment 33 Axel Thimm 2008-02-20 09:14:28 UTC
The problem is that these questions are just for stalling. For example in
comment #20 the reviewer already showed that he knows which kernels are in RHEL5
for example and now pretends that he doesn't and wants to spin the discussion
into something else.

FWIW the kernels in RHEL3-5 are based on 2.4.21/2.6.9/2.6.18, but the version of
the base kernel does not say much about what capabilities the kernels have as
especially RHEL3/4 kernels are heavily patched compared to upstream. Well, that
technically answers the last question the reviewer posed.

Comment 34 Nicolas Chauvet (kwizart) 2008-02-20 11:53:06 UTC
From  #20
>That been said, keeping compat location are fine for RHEL4 and RHEL5, (if this
>make sense to have them, but i don't think so as your repository have 0.10.6 for
>RHEL5 and 2.6.18 kernels)... 

Let me rephrase: EPEL may need packages to be functional by itself.
ivtv-firmware is missing the needed kernel module. It is possible to use
ivtv-kmdl from any third part repo to use ivtv-firmware. But using ivtv-firmware
alone is pointless. At this time ivtv.ko hasn't been backported for last RHEL
kernels AFAIK. Note that if it was done or requested this would make the
compat-location pointless. I leave the decition about epel to another reviewer

So to sum-up, if any of the people involved in the EPEL repository accept this
package, i have nothing against preventing axel to own epel-4 and epel-5
branches. (just ask and i will request cvs for epel-4 and epel-5 once approved
by someone else).

Comment 35 Axel Thimm 2008-02-20 12:14:41 UTC
This has nothing to do with an EPEL branch, I submitted a Fedora package that is
compatible to RHEL, and that's what I want to maintain - tthe whole idea was not
to have to do split branches at all. You can't simply go around stealing other
people's packages - you will have to step down from ownership if you want this
to deescalate.

Comment 36 Jarod Wilson 2008-02-21 22:18:40 UTC
So... I've been asked to step in and be the mediator here, since I've not been
involved in the debate at all. Though full disclosure: I do have past history as
a contributor to Axel's ATrpms.net repo, and know a fair amount about the work
he's put in to get to the point where we (fedora) could actually distribute an
ivtv-firmware package. I'm still reading over everything on the matter (the
bugs, some emails, fesco meeting notes, etc), and will give some feedback soonish...

Comment 37 Jarod Wilson 2008-02-22 21:48:41 UTC
Okay. So I've read over everything, including both spec files. For the most
part, I believe this boils down to a misunderstanding that has simply escalated
out of control. Whether or not the fact the two individuals have histories of
contributing to 3rd-party package repos that themselves have a history of
conflict somehow contributed more fuel to the fire, I don't know, but I wouldn't
doubt it...

Anyhow, I understand Nicolas' frustration for his review comments being
dismissed, as well as Axel's frustration over Nicolas going and submitting his
own review. Honestly, I think BOTH of you are in the wrong here, to some extent.

Nicolas, I'm not wild about seeing a competing review submitted for the very
same package you were already the primary reviewer on, especially given that
Axel posted that he was on vacation (though apparently, you were unaware of
this). It does feel a bit like hostile takeover. I understand wanting to get the
package into the distro asap, but still, it wasn't the most courteous thing. If
your problems with Axel's package can be resolved, I think you ought to
relinquish ownership back to Axel.

Axel, I'm still not wild about your spec file and all the legacy crud its going
to lay down on a clean Fedora system. Nicolas' objections to your version are
entirely valid. However, they're quite easily remedied in a way that doesn't
break RHEL compatibility. Simply wrap those sections of the spec with '%if
0%{?rhel}', which a number of other packages using shared specs between fedora
and epel do. The license files really could use renaming too, generic license
file names in a system-wide firmware directory are not cool. Pretty sure the
license doesn't prevent renaming those files to something less generic (such as
is done in Nicolas' spec). Using mv to transfer files from the sourcedir to the
buildroot also doesn't sit well with me, the sourcedir should be left intact.
Use either install or cp instead. PVR-USB2 firmware is also included, should be
mentioned in the description and summary.

So yeah, as I've already hinted... Going forward, I believe Axel should be the
owner and primary maintainer of this package *if his version can pass review*.
My reasoning, beyond what I've already said:

1) Axel submitted the package for review first, didn't abandon it (though it may
have seemed like it to the casual observer), and he's still working on it.
Abandoned package takeover guidelines don't apply here, since Axel did leave
proper notice that he was on vacation (well, moving, actually).

2) Axel basically *is* upstream for this package, and did all the legwork to
make it even *possible* for fedora to package it and distribute it. Ripping it
out from under him at the last minute simply isn't cool.

3) Axel has also submitted the ivtv userspace for review. It depends on this
package. Having the same maintainer for both of these packages only makes sense.

Of course, as stated, this is all assuming Axel does address the remaining
*valid* issues Nicolas (and myself and others) have with his version of the
package. If these issues aren't resolved by the time Fedora 9 beta release hits
the streets[*], then we stay with the current situation with Nicolas' package
and him as owner/primary maintainer.

That's my story, and I'm sticking to it. Hopefully, we can put this mess to rest
and all move along with our lives, to things far more interesting than packaging
up firmware for devices that are quickly approaching obsolescence. Thank you,
and good night.

[*] http://fedoraproject.org/wiki/Releases/9/Schedule says March 13.

Suggested changes to Axel's spec in diff form, which would satisfy my own
complaints with his version:

--- ivtv-firmware.spec.orig     2008-02-22 14:44:51.000000000 -0500
+++ ivtv-firmware.spec  2008-02-22 15:39:12.000000000 -0500
@@ -1,7 +1,7 @@
 %define version_enc 2.06.039
 %define version_dec 2.02.023
-Summary: Firmware for the PVR 250/350/150/500 model series
+Summary: Firmware for the Hauppauge PVR 250/350/150/500/USB2 model series
 Name: ivtv-firmware
 Version: 20070217
 Release: 16
@@ -20,7 +20,7 @@ Obsoletes: %{name}-enc < %{version_enc}
 Provides: %{name}-enc = %{version_enc}
-This package contains the firmware for WinTV PVR 250/350/150/500 cards.
+This package contains the firmware for Hauppauge WinTV PVR 250/350/150/500/USB2
 %setup -q -c
@@ -31,10 +31,15 @@ This package contains the firmware for W
 rm -rf %{buildroot}
 mkdir -p %{buildroot}/lib/firmware
-mv *.fw %{buildroot}/lib/firmware/
-mv v4l-cx2341x-init.mpg %{buildroot}/lib/firmware/v4l-cx2341x-init.mpg
-mv license-*.txt %{buildroot}/lib/firmware/
+cp -p *.fw %{buildroot}/lib/firmware/
+cp -p v4l-cx2341x-init.mpg %{buildroot}/lib/firmware/v4l-cx2341x-init.mpg
+# license requires that the licenses go in the same place as the firmware
+for f in license-*.txt
+  cp -p $f %{buildroot}/lib/firmware/%{name}-$f
+%if 0%{?rhel}
 # compatibility firmware locations
 for dir in %{_sysconfdir}/firmware %{_libdir}/hotplug/firmware /lib/modules; do
   mkdir -p %{buildroot}$dir
@@ -47,16 +52,19 @@ ln -s /lib/firmware/v4l-cx2341x-init.mpg
 ln -s /lib/firmware/v4l-cx2341x-enc.fw %{buildroot}/lib/modules/ivtv-fw-enc.bin
 ln -s /lib/firmware/v4l-cx2341x-dec.fw %{buildroot}/lib/modules/ivtv-fw-dec.bin
 ln -s /lib/firmware/v4l-cx25840.fw %{buildroot}/lib/modules/HcwMakoA.ROM
 rm -rf %{buildroot}
+%doc license-*.txt
+%if 0%{?rhel}
 # compatibility firmware locations
 %dir %{_sysconfdir}/firmware
@@ -70,6 +78,7 @@ rm -rf %{buildroot}

Comment 38 Nicolas Chauvet (kwizart) 2008-02-23 15:36:23 UTC
I agree with what is written upper.
I will completely release ownership of this package then.
(including removal of my spec to replace it with the Axel's one, when Approved).

Comment 39 Nicolas Chauvet (kwizart) 2008-03-06 01:56:34 UTC
Axel spec has been updated...
I will release ivtv-firmware owership as request

Comment 40 Jarod Wilson 2008-03-11 15:15:22 UTC

All requested changes (and then some -- compat bits are completely removed,
rather than just %if %{?rhel}'d out) have been made, new spec is acceptable for


Package Change Request
Package Name: ivtv-firmware
Updated Fedora Owners: athimm
Updated Fedora CC: jwilson kwizart

Nicolas is relinquishing ownership and we're handing it over to Axel.

Comment 41 Kevin Fenzi 2008-03-12 05:11:08 UTC
cvs done.

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