Spec URL: 
http://kwizart.free.fr/fedora/rpmfusion/libdc1394.spec
SRPM URL:
http://kwizart.free.fr/fedora/rpmfusion/libdc1394-1.2.1-2.kwizart.fc6.src.rpm
Description: High level API for IEEE 1394 based cameras

Iv'e made something quite stupid with the examples package. I hope this is less...
Now it provides real examples binaries...

You should make sure there are no patent issues (IIRC there are). Check the
mpeg-la patent portfolio and the upstream mailing lists.

Patents? Argh. FE-LEGAL?
I just wanted this package to go into Fedora in order to be able to build VLC
with direct DV camera streaming capabilities enabled. I don't really care if
it's version 1.x or 2.x as long as it works, nor who maintains the package.
Also, I proposed version 2.x since the home page states that it's the
recommended version... which apparently isn't really the case, for binary
packages at least.

Both could go in, as long as they don't conflict. I'll take care of this one, too.

Well, currently they do conflict, and the first thing to do would be to check
what Axel mentioned about possible patent issues...

Well i've tryed to check what Axel said about mpeg-la patent.
I was searching into upstream ml but i didn't manage to do ... 
(webserver propose me to download the php search result file... i'll give a try
later...)

There is a need to check the current status of a patent possibly inside libdc1394

Quote of Axel ...But I
just checked the svn and the patents are even named in the source by
their U.S. patent numbers, so it looks rather patent-encumbered to my
non-lawyer eyes (unless the patents are ancient and expired - I didn't
go as far as to check that, OTOH MPEG-LA claims to have a portfolio of
active patents on 1394).
---/Quote

(In reply to comment #7)
> Quote of Axel ...But I
> just checked the svn and the patents are even named in the source by
> their U.S. patent numbers, [...]

Don't consider Axel authoritative in any way, he's not a lawyer or any close
substitute. Just check out the code and make up your own mind, soureforge has a
code searching facility, entering patent in there you get:

http://sourceforge.krugle.com/kse/files?query=patent&project=%221394-based%20DC%20Control%20Library%22

Doesn't build in mock x86_64/devel:
make[2]: Entering directory `/builddir/build/BUILD/libdc1394-1.2.1/examples'
...
if gcc -DHAVE_CONFIG_H -I. -I. -I..     -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
-m64 -mtune=generic -Wall -Wunused -MT affine.o -MD -MP -MF ".deps/affine.Tpo"
-c -o affine.o affine.c; \
        then mv -f ".deps/affine.Tpo" ".deps/affine.Po"; else rm -f
".deps/affine.Tpo"; exit 1; fi
/bin/sh ../libtool --tag=CC --mode=link gcc  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
-m64 -mtune=generic -Wall -Wunused   -o dc1394_vloopback  dc1394_vloopback.o
affine.o -lm ../libdc1394/libdc1394_control.la -lraw1394 -lraw1394
mkdir .libs
DIE_RPATH_DIE="/usr/lib64:$DIE_RPATH_DIE" gcc -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
-m64 -mtune=generic -Wall -Wunused -o .libs/dc1394_vloopback dc1394_vloopback.o
affine.o  -lm ../libdc1394/.libs/libdc1394_control.so -lraw1394
../libdc1394/.libs/libdc1394_control.so: undefined reference to
`raw1394_set_iso_handler'
../libdc1394/.libs/libdc1394_control.so: undefined reference to
`raw1394_stop_iso_rcv'
../libdc1394/.libs/libdc1394_control.so: undefined reference to
`raw1394_start_iso_rcv'
collect2: ld returned 1 exit status

Some comments about the specfile:

1. I don't like the name libdc1394-libs, seems redundant -> move libs back to
main  package and binaries to -tools
2. There are some Provides/Obsoletes -> what for?

Attached patch addresses the above issues.

Created attachment 154349 [details]
specfile fixes

After a cursory look at the code I haven't found anything complicated enough to
be patentable. The same cannot be said about 2.x version, which seem to
explicitly name at least one US patent. Nevertheless, I think 1.x is safe.

For F7, we've got a whole new firewire stack, and libraw1394 has been patched
accordingly. Pretty sure libdc1394 is going to need similar love, or it has no
hope of working in F7.

Thx for your quick reply! Here is the current spec file

Spec URL: 
http://kwizart.free.fr/fedora/rpmfusion/libdc1394.spec
SRPM URL:
http://kwizart.free.fr/fedora/rpmfusion/libdc1394-1.2.1-4.kwizart.fc6.src.rpm
Description: High level API for IEEE 1394 based cameras

I've check the svn repository and version 1 changes are 6 months old whereas
release tarball are more than one year old. I may do a snapshoot if needed...

I would prefer a patch applied over the tarball instead. Snapshots tend to be
difficult to reproduce.

...and its unlikely the svn repo has stuff to support the new firewire
interfaces if there's been no change in 6 mo. I believe the stack is newer than
that, and the patches to libraw1394 were done by krh, who also wrote the new
kernel stack. Dunno if he's pushed them upstream or not...

There is nothing more than we already have with libdc1394-1.1.0-clktck.patch.
The other patch hasn't been merged upstream so i may remove it (it bring nothing
new about what we want to care about, for sure...)

cc krh since he may be the preferred person to have info about this...
Until then, we may test it on FC-6... do this kernel change about 1394 are
planned to be backported from F7 to FC-6?

> do this kernel change about 1394 are
> planned to be backported from F7 to FC-6?

Nope.

Adding Jay to the Cc list.  Upstream libdc1394 2.0 (soon to be released)
supports the new firewire stack in rawhide.  We should package the 2.0 version
instead.  But I'm guessing that there's an interest in having this working with
libdc1394 1.x, but that should be possible too, we just have to backport the
support from the 2.0 version.

Hi Kristian!
As i known some projects that use libdc1394-1 aren't currently aware about -2
API. So indeed that would be fine to have a -1 release unless upstream can
support -2 API... 

Asking to do so about videolan... Others projets may also be concerned...

(In reply to comment #19)
> Adding Jay to the Cc list.  Upstream libdc1394 2.0 (soon to be released)
> supports the new firewire stack in rawhide.  We should package the 2.0 version
> instead.

That might be a problem. A cursory look at the code reveals a patented
algorithm, see bug 239043. I've blocked FE-Legal on that.

> But I'm guessing that there's an interest in having this working with
> libdc1394 1.x, but that should be possible too, we just have to backport the
> support from the 2.0 version.

That would be best, yes.

Perhaps add to the description in the package spec that IIDC (Instrumentation &
Industrial Digital Camera) is for, well, industrial cameras and some webcams,
not for DV cameras (camcorders).

Kristian! you are the prefered person that can backport the juju code from
libdc1394 2.0 to 1.0!

Additionnaly where can i have a start page about theses changes ?
I was using eth1394.ko! how can i do as a replacement with Fedora 7... 
I will try to document this then...

libdc1394 1.2.2 has been updated but no juju support for Fedora 7 for now!
same error Rathann reported in #9

Kristian, how can we backport juju for libdc1394-1 ?

Spec URL: 
http://kwizart.free.fr/fedora/rpmfusion/libdc1394.spec
SRPM URL:
http://kwizart.free.fr/fedora/rpmfusion/libdc1394-1.2.2-1.kwizart.fc6.src.rpm
Description: High level API for IEEE 1394 based cameras

Is there any point of having this in F-7 or newer? It doesn't seem useful if
there's no juju support. FC-6 is going away soon.

Is there work going on to add juju support? Since we rely on this library for
almost all of our cameras on our robots it would be really unfortunate if that
went away, as this would mean that we have to stick to FC6 for quite a while :-/

No support added yet... it would work for FC-6 but F-7 and later will need
libdc1394-2... For now upstream projects that use it are not ready to use -2 but
if we can, maybe some patching could be done (i'm not enought aware to do this...)

If we want to live in a compat-world with ieee1394, i've made an external kmod
(1) with the old ieee1394, but this will requires "also" compat userland and it
seems from http://wiki.linux1394.org/JujuMigration that compat libraw1394 isn't
ready (need to be rebuilt at least the old libraw1394 )

(1) it is missing some blacklist script and eth1394 have to be removed as it do
not work... But see here http://kwizart.free.fr/fedora/7/testing/ieee1394/

Sorry, I missed that this is libdc1394-1. We are using version 2. Works like a
charm. Is that compatible with juju already?

So with this made clear I have no problem with removing this version. Maybe
someone else still needs this though?

libdc1394-2 is here: https://bugzilla.redhat.com/239043
(juju compatible)...

But indeed some apps still need it but it cannot be used with juju for now...

(In reply to comment #27)
> No support added yet... it would work for FC-6 but F-7 and later will need
> libdc1394-2... For now upstream projects that use it are not ready to use -2 but
> if we can, maybe some patching could be done (i'm not enought aware to do this...)
> 
> If we want to live in a compat-world with ieee1394, i've made an external kmod
> (1) with the old ieee1394, but this will requires "also" compat userland and it
> seems from http://wiki.linux1394.org/JujuMigration that compat libraw1394 isn't
> ready (need to be rebuilt at least the old libraw1394 )
> 
> (1) it is missing some blacklist script and eth1394 have to be removed as it do
> not work... But see here http://kwizart.free.fr/fedora/7/testing/ieee1394/
> 

when i rebuild the src packages ieee1394-kmod-2.6.22.10-1.fc7.src.rpm from
kwizart.free.fr the following warning appears:
WARNING: "hpsb_config_rom_ip1394_remove"
[/usr/src/redhat/BUILD/ieee1394-kmod-2.6.22.10/_kmod_build_/eth1394.ko] undefined!
WARNING: "hpsb_config_rom_ip1394_add"
[/usr/src/redhat/BUILD/ieee1394-kmod-2.6.22.10/_kmod_build_/eth1394.ko] undefined!
What means this ?

eth1394 is a kernel module to use firewire as an ipv4 network interface...
I cannot make it work with this method, so it would be safe to remove it...

> WARNING: "hpsb_config_rom_ip1394_remove"
> [/usr/src/redhat/BUILD/ieee1394-kmod-2.6.22.10/_kmod_build_/eth1394.ko]
> undefined!
> WARNING: "hpsb_config_rom_ip1394_add"
> [/usr/src/redhat/BUILD/ieee1394-kmod-2.6.22.10/_kmod_build_/eth1394.ko]
> undefined!
> What means this ?

It means that you try to build an out-of-tree derivative of the ieee1394 kernel
drivers which is broken.  These things happen --- the mainline sources are meant
to be built from within a complete kernel source tree.  You could ask the author
of that package to fix his bug.

(In reply to comment #25)
> Is there any point of having this in F-7 or newer? It doesn't seem useful if
> there's no juju support. FC-6 is going away soon.

Well? FC-6 is gone.

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