Since I have a (irrational?) dislike of the hal stuff I made an ebuild patch to add a nohal use flag that makes k9copy compile without sys-apps/hal. It may not be that useful to most but maybe it can be added anyway.
Created attachment 126690 [details, diff] adds nohal use flag
Did you test that? Compilation (without having sys-apps/hal installed) with --disable-hal fails for me with the following error: k9cddrive.cpp:63: warning: unused parameter '_device' /bin/sh ../libtool --silent --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -W -Wpointer-arith -Wwrite-strings -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -DNDEBUG -DNO_DEBUG -O2 -march=k8 -O2 -pipe -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -o libk9devices.la -L/usr/lib64 -L/usr/qt/3/lib64 -L/usr/kde/3.5/lib64 -L/usr/kde/3.5/lib64 k9halconnection.lo k9haldevice.lo k9cddrive.lo k9dbusdispatch.lo -lk3bdevice grep: /usr/lib64/libhal.la: No such file or directory /bin/sed: can't read /usr/lib64/libhal.la: No such file or directory libtool: link: `/usr/lib64/libhal.la' is not a valid libtool archive make[2]: *** [libk9devices.la] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-cdr/k9copy-1.1.1_p3-r1/work/k9copy-1.1.1-3/k9devices' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-cdr/k9copy-1.1.1_p3-r1/work/k9copy-1.1.1-3' make: *** [all] Error 2 * * ERROR: app-cdr/k9copy-1.1.1_p3-r1 failed. * Call stack: * ebuild.sh, line 1648: Called dyn_compile * ebuild.sh, line 988: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * k9copy-1.1.1_p3-r1.ebuild, line 41: Called kde_src_compile * kde.eclass, line 170: Called kde_src_compile 'all' * kde.eclass, line 340: Called kde_src_compile 'myconf' 'configure' 'make' * kde.eclass, line 336: Called die * * died running emake, kde_src_compile:make If you get the same error, we should consider this to be an upstream bug. If it works for you, please let me know. By the way, "noblah" style USE flags should be avoided. I'd add a normal "hal" USE flag. :)
> Did you test that? Compilation (without having sys-apps/hal installed) with > --disable-hal fails for me with the following error: Yes, it works for me, and I do not have hal installed (and never had - actually I did this because this is the only package that isn't just as happy with a fake package.provided entry for it). It is not exactly the same situation though, I have a pure 64 bit, non-multilib version. > grep: /usr/lib64/libhal.la: No such file or directory > /bin/sed: can't read /usr/lib64/libhal.la: No such file or directory > libtool: link: `/usr/lib64/libhal.la' is not a valid libtool archive Sounds to me like some other .la file still references libhal.la. Tried revdep-rebuild? > By the way, "noblah" style USE flags should be avoided. I'd add a normal "hal" > USE flag. :) Well, I assumed that using hal was very much desired since it was added as a hard dependency, and I do not know how to add a USE flag that is enabled by default...
(In reply to comment #3) > Yes, it works for me, and I do not have hal installed (and never had - actually > [snip] > > grep: /usr/lib64/libhal.la: No such file or directory > > /bin/sed: can't read /usr/lib64/libhal.la: No such file or directory > > libtool: link: `/usr/lib64/libhal.la' is not a valid libtool archive > > Sounds to me like some other .la file still references libhal.la. Tried > revdep-rebuild? Yes, but now I think the problem is somewhere else. Seems the --disable-hal configure switch doesn't work correctly. configure still looks for the headers/libraries for me: checking for dvdread/dvd_reader.h... yes checking for the HAL... headers /usr/include libraries /usr/lib64 checking if doc should be compiled... yes So no matter what the compilation error is; configure shouldn't even try to look for the headers. This part of configure.in shouldn't be parsed when the --disable-hal switch is set (or I made a mistake while reading configure.in). > > By the way, "noblah" style USE flags should be avoided. I'd add a normal "hal" > > USE flag. :) > > Well, I assumed that using hal was very much desired since it was added as a > hard dependency, and I do not know how to add a USE flag that is enabled by > default... > The hal USE flag is enabled by default (at least with 2007.0 profile). People who want HAL, keep it enabled; those who don't, simply disable it. Also, noblah USE flags cause some other problems, see http://devmanual.gentoo.org/general-concepts/use-flags/index.html for further information. :)
Filed an upstream bug: https://bugs.kde.org/show_bug.cgi?id=148496
Created attachment 126846 [details, diff] Add hal use-flag instead Weird thing is, now compilation works even with hal USE flag set (and a dummy hal in package.provided), so --enable-hal and --disable-hal seem to do exactly the same thing?? [suppress rant about auto*]
OK, reopen when this gets sorted out upstream and --disable-hal works as intended. As it is now, we can't add the flag because it would be broken. Thanks.
