Spec URL: http://kwizart.free.fr/fedora/rpmfusion/libdc1394.spec SRPM URL: http://kwizart.free.fr/fedora/rpmfusion/libdc1394-1.2.1-1.kwizart.fc6.src.rpm Description: High level API for IEEE 1394 based cameras rpmlint is silent enought on binaries and sources... As this spec files was taken from atrpms version. I will request Axel some advices about replacement policy for this package and his packaging scheme... For example, what is the aim for : %lib_package dc1394_control 13 ? Whereas libs are : [root@Kwizatz lib64]# ls -al total 84 drwxr-xr-x 2 builder builder 4096 mai 5 21:02 . drwxr-xr-x 8 builder builder 4096 mai 5 21:02 .. lrwxrwxrwx 1 builder builder 27 mai 5 21:02 libdc1394_control.so -> libdc1394_control.so.12.1.1 lrwxrwxrwx 1 builder builder 27 mai 5 21:02 libdc1394_control.so.12 -> libdc1394_control.so.12.1.1 -rwxr-xr-x 1 builder builder 73168 mai 5 21:02 libdc1394_control.so.12.1.1 I was working on libdc1394(-1) before seen -2 from Matthias i would like to work with him in case we choose to provides a -2 version... See: https://bugzilla.redhat.com/239043
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 ***