After updating the libraw1394 package, The only thing that failed to emerge on the revdep-rebuild is pwlib. Reproducible: Always Steps to Reproduce: 1.update libraw1394 to sys-libs/libraw1394-2.0.0 2. revdep-rebuild 3.build of pwlib fails. Actual Results: pwlib failed to build Expected Results: pwlib should have built correctly emerge --info Portage 2.1.6.13 (default/linux/amd64/2008.0, gcc-4.3.3, glibc-2.10.1-r0, 2.6.29-gentoo-r3 x86_64) ================================================================= System uname: Linux-2.6.29-gentoo-r3-x86_64-Dual_Core_AMD_Opteron-tm-_Processor_875_HE-with-gentoo-2.0.1 Timestamp of tree: Fri, 05 Jun 2009 22:30:01 +0000 app-shells/bash: 4.0_p24 dev-java/java-config: 1.3.7-r1, 2.1.8 dev-lang/python: 2.3.6-r3, 2.4.4-r6, 2.5.4-r2, 2.6.2-r1 dev-python/pycrypto: 2.0.1-r8 dev-util/cmake: 2.6.4 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r2 sys-apps/sandbox: 2.0 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.29 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/red5/conf /usr/kde/3.2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/red5-webapps" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=opteron -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://gentoo.mirrors.pair.com/ http://mirror.datapipe.net/gentoo http://mirror.clarkson.edu/pub/distributions/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/pro-audio" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X a52 aac acl alsa amd64 apache2 asf avahi berkdb bzip2 cairo cdr cli consolekit cracklib crypt cups dbus dlloader dri dts dvd dvdr dvdread embedded esd f77 ffmpeg flac fortran freetype g77 gdbm gif gnome gpm gsm gtk gtk2 h264 hal iconv ieee1394 ipv6 isdnlog jack jingle jpeg jpeg2k juju lzo mad midi mjpej mmx modplug mp3 mp4 mpeg msn mudflap multilib mysql ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcre pdf perl pic png pppd python qt qt3 quicktime readline reflection sdk sdl session spell spl sse sse2 ssl svg sysfs tcltk tcpd theora tiff truetype unicode usb v4l v4l2 vorbis webkit x264 xcb xcomposite xfs xine xinerama xorg xulrunner xvid xvmc yahoo zlib" ALSA_CARDS="emu10k1 intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Attach build.log.
Created attachment 193672 [details] cut/paste of the error and emerge error
Created attachment 193674 [details] full build.log
raw1394_start_iso_rcv and raw1394_stop_iso_rcv was deprecated and are removed from sys-libs/libraw1394-2. http://www.linux1394.org/doc/libraw1394/r3028.html version 1.11.1 of pwlib does not solve this, downgrade (or port to new version) is necessary.
confirming
Here too. .. but with USE "-ieee1394" (disabling) I got around it.
That's the point, though, to have ieee1394 in the library..
By the way, the functions which were removed from libraw1394 v2 are not implemented in the kernel anymore since 2.6.23 inclusive, from October 2007.
The "avc" and "dc" video input modules are both controlled by the ieee1394 use flag. 1. The "dc" module uses libdc1394 v1 (and minimally libraw1394, v1 or v2 should both work from what I saw in the source). The dc module is for IIDC (a.k.a. DCAM) cameras which send uncompressed video. Those are industrial-grade cameras, and a few webcams which are no longer produced. 2. The "avc" module uses libraw1394 and must depend on <= libraw1394 v1, as noted in comment 4. The avc module is for DV camcorders (which follow the AV/C standard; DV is compressed video). So, should there perhaps be separate dc1394 and avc1394 use flags instead of the shared ieee1394 use flag?
It looks like Debian choosed to disable avc and dc support in pwlib and redirect people to v4l: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519047 (In reply to comment #9) > The "avc" and "dc" video input modules are both controlled by the ieee1394 use > flag. > > 1. The "dc" module uses libdc1394 v1 (and minimally libraw1394, v1 or v2 should > both work from what I saw in the source). You're right Stefan, --enable-dc --disable-avc is working. However, is it really usefull to keep dc support as you said it was for old devices ? My opinion is we can do like Debian did and remove ieee1394 USE flag or just remove avc support. Anyway, pwlib will not be patched to let it works with ieee1394 as pwlib is not maintained since a long time and ptlib should be used instead. What's your opinion about it ?
> However, is it > really usefull to keep dc support as you said it was for old devices ? IIDC webcams are long out of production (but still traded 2nd hand). There is a large active market of industrial grade IIDC cameras, but these are in a price region _way_ apart from webcams. I don't know if anyone is using such cameras together with ptlib or pwlib. Could be (in research settings perhaps, but not in SOHOs), but such users might run into other trouble in the mid term or long term because libdc1394 v1 --- the basis for pwlib's and ptlib's current dc module --- is not in active maintenance anymore as far as I understood. > My opinion is we can do like Debian did and remove ieee1394 USE flag or > just remove avc support. Would a libraw1394 v1 dependency (IOW < libraw1394 v2 dependency) implicate maintenance burdens? > Anyway, pwlib will not be patched to let it works with ieee1394 as pwlib > is not maintained since a long time and ptlib should be used instead. Well, OK, since migration to ptlib is going on, any super clever tweaks of pwlib (i.e. avc -- dc split) are probably not called for at this point anymore.
> It looks like Debian choosed to disable avc and dc support in pwlib and > redirect people to v4l: v4l or v4l2 are no replacement for avc or dc. Except if you count the out-of-tree, AFAIK now unmaintained, vloopback kernel module as an option, or if the replacement includes the purchase of a (admittedly cheap) USB webcam to replace AV/C ( = DV) or IIDC hardware at a user. There is an idea to develop a V4L2 kernel module for AV/C hardware, but no work has been started yet. Affected users (are there any?) shouldn't hold their breath.
(In reply to comment #11) > > My opinion is we can do like Debian did and remove ieee1394 USE flag or > > just remove avc support. > > Would a libraw1394 v1 dependency (IOW < libraw1394 v2 dependency) implicate > maintenance burdens? We can't change libraw1394 depends to =libraw1394-1* because it will leads to conflicts if another app needs >libraw1394-1 and it will be the beginning of the end ;) > > Anyway, pwlib will not be patched to let it works with ieee1394 as pwlib > > is not maintained since a long time and ptlib should be used instead. > > Well, OK, since migration to ptlib is going on, any super clever tweaks of > pwlib (i.e. avc -- dc split) are probably not called for at this point anymore. I'm not against super-clever trick but against super-long one. So, after your message, i'm still with removing av/dc support from pwlib and see what we can do for ptlib. By the way, two questions: - is the bug present in ptlib ? - if someone is using pwlib av/dc support, in which context ? (ie. with which app). The app should be moved to ptlib asap.
On my system, there are two things that use pwlib: ekaterine ~ # equery d pwlib * Searching for pwlib ... net-libs/opal-2.2.11 (~dev-libs/pwlib-1.10.10) net-voip/ekiga-2.0.12 (~dev-libs/pwlib-1.10.10[ldap]) The original apple iSight cameras are ieee1394a devices and were quite expensive..
>> - is the bug present in ptlib ? I scrolled through the code of ptlib a few days ago. Its avc and dc plugins looked the same as pwlib's. > The original apple iSight cameras are ieee1394a devices and were quite > expensive.. That's right. Apple has discontinued FireWire iSights quite a while ago, but they are surely still well in use; last time I checked they were still quite popular at the 'bay. These cameras are IIDC cameras, i.e. driven by the "dc" plugin. Hence it would be good to keep the dc plugin until libdc1394 v1 is EOLed or somebody updates these plugins for newer 1394 libraries in upstream ptlib.
>>> - is the bug present in ptlib ? > > I scrolled through the code of ptlib a few days ago. Its avc and dc plugins > looked the same as pwlib's. I forgot: bug 276514
I've added a pwlib-1.10.10-r2 ebuild with disabled AVC plugin. As libraw1394-2 is not stable and pwlib-1.10.10-r1 is stable, -r1 can live until libraw1393-2 becomes stable. So, bug is fixed. Re-open it if it shows again (ie. libraw1394-2 goes stable and pwlib-1.10.10-r1 is still there) Thanks Stefan and Daniel for your help :)
