When building a LiveCD with USE=hal, the ebuild dies when it cannot find a configured kernel. Kernel configuration is done in livecd-stage2, whereas packages are installed in livecd-stage1. Honestly, I don't see why the package fails to build in any way. The checks are somewhat worthless considering someone can change their kernel after the fact to be incompatible. While I wouldn't mind seeing the checks go away completely, they should at least be downgraded to a warning since the package builds fine without these checks. This will block the 2006.1 release. Removing linux-info_pkg_setup and changing the notify_uevent stuff to be a warning only works perfectly. The same thing needs to be done for the ACPI check, too. Really, the kernel version check should probably be changed, too.
Please CC gentopia on hal bugs :)
-r2 no longer dies on the failed checks.
(In reply to comment #2) > -r2 no longer dies on the failed checks. It still fails. The problem is is line 551 in linux-info.eclass: get_version || die "Unable to calculate Linux Kernel version" I exchanged the die with ewarn (yes, ugly, but for testing only) and hal is still able to compile. Please make sure, that hal could be compiled without a kernel installed. Otherwise it's a showstopper for the 2006.1-release.
Can we get this resolved? This is blocking my snapshot, currently.
Created attachment 90561 [details, diff] hal 0.5.5.1 patch This patch applies to the current stable hal version. To apply it to newer versions, it'll need to be adjusted slightly. If this is not resolved by the time I take my snapshot, then this is the patch I'll be using for the official release media. Quite simply, a non-kernel module should *never* die if it can't find the sources.
We are in the time after release now and every catalyst-test-run fails on it. It would be nice when not every self-made snapshot for a test needs to be patched.
I fixed this in current stable, hal-0.5.7-r3.ebuild and ~arch hal-0.5.7.1-r1.ebuild, thank you!
