Summary: | alsa-driver-1.0.10_rc2 does not compile with 2.4.x kernels | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Oliver Walter <owb> |
Component: | Current packages | Assignee: | Gentoo Sound Team <sound> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hppa, ia64, kernel, mips, rajiv, sparc |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Oliver Walter
2005-11-13 11:53:56 UTC
Try with some kernel that is actually still in portage at least... Reopened because it is a bug. alsa-driver-1.0.10_rc3 works. --- >>> Merging media-sound/alsa-driver-1.0.10_rc3 to / [...] >>> media-sound/alsa-driver-1.0.10_rc3 merged. --- even "Takashi Iwai" says this is a bug. see: http://article.gmane.org/gmane.linux.alsa.devel/27757 http://article.gmane.org/gmane.linux.alsa.devel/27732 I see the exact same output, and I am using kernel 2.4.26-win4lin-r13. It also occurs if I try to just emerge this package, and a revdep-rebuild doesn't help. 2.4.28-gentoo-r9 In file included from memory.c:2: ../alsa-kernel/core/memory.c: In function `copy_to_user_fromio': ../alsa-kernel/core/memory.c:40: error: parse error before "__force" ../alsa-kernel/core/memory.c:40: error: parse error before "__force" ../alsa-kernel/core/memory.c: In function `copy_from_user_toio': ../alsa-kernel/core/memory.c:71: error: parse error before "__force" ../alsa-kernel/core/memory.c:71: error: parse error before "__force" make[1]: *** [memory.o] Error 1 I don't consider that major. Use rc3 in the mean time, the rc2 stabilization was an emergency way to fix the 2.6.14 problem, as soon as the final version of alsa is released, I'll push to mark that stable. (In reply to comment #5) > I don't consider that major. Use rc3 in the mean time, the rc2 stabilization > was an emergency way to fix the 2.6.14 problem Such a bug is a major one, when ebuilds which are marked stable are affected. It just shouldn't happen. The advice to test yet another rc is not a good idea in this context, since there is a stable working version. There're obviously no efforts upstream to keep the alsa-driver releases consistent with kernel releases, so it's probably better to keep it only for 2.4.x and drop supporting the alsa-driver for linux 2.6, than being forced creating such a mess. Erm... alsa-driver *does* fix for 2.6 as this is a newer version than the one 2.6.14 ships. Also, alsa-lib *must* be in sync with the kernel or we got problems. And as I said on IRC, too, go talk with arch teams and kernel devs to find a new solution. Go for rc3 that should work if you're still on 2.4, I can't really do anything about this. Should I patch rc2 to add the code in rc3? that would require a version bump and an ~arch bump. (In reply to comment #7) > Erm... alsa-driver *does* fix for 2.6 as this is a newer version than the one > 2.6.14 ships. Also, alsa-lib *must* be in sync with the kernel or we got > problems. Yes. Would warrant a blocker in that rc2 lib for 2.4.x kernels. > And as I said on IRC, too, go talk with arch teams and kernel devs to find a > new solution. Go for rc3 that should work if you're still on 2.4, I can't > really do anything about this. Should I patch rc2 to add the code in rc3? that > would require a version bump and an ~arch bump. Kernel 2.4 is still supported, so it should work. Saying "I can't do anything for you" is really bullshit. The proper advise would be stay with 1.0.9 (afaik there's not a vulnerability to fix) and adding blockers for 2.4.x kernels in rc2. But you're right, the only ones who can really fix the issue are the alsa/kernel developers. we could also block _rc2 for the 2.4 kernel profiles. fyi, i am running 2.4.31 on x86 and see this problem. Blocking on sources is not correct. If you really want to do something, contact the arch teams using 2.4 subprofiles and let them p.mask on that subprofile this version. Of course, I understand the implications of this but the best forward approach is to stabalise this across each arch to fix the 2.4 compatibility issues, and still accomodate for the recent security fixes. Can all arch teams which use alsa please test rc3 against both 2.6.31 and 2.6.14.2 and mark stable ASAP. I understand there is no real stabalisation period here, but this is an unfortunate situation. May I also just comment on the code changes I viewed between rc3 and rc2, by saying that rc3 should be mre stable than rc2 :) (In reply to comment #11) > > Can all arch teams which use alsa please test rc3 against both 2.6.31 and > 2.6.14.2 and mark stable ASAP. I understand there is no real stabalisation > period here, but this is an unfortunate situation. May I also just comment on > the code changes I viewed between rc3 and rc2, by saying that rc3 should be mre > stable than rc2 :) Did you also view all the other alsa-* packages we need to stabilize? Yep, with the exception of alsa-driver there is little change, the problem it appears is ppc with rc3 and the beep being re-written which flameeyes is aware of. ppc should be on 2.6 almost exclusively though, since 2.4 is very problematic if at all working on most ppc machines (as of my last update :)) Actually, I fixed rc3 for ppc :) (In reply to comment #13) > ppc should be on 2.6 almost exclusively though, since 2.4 is very problematic if > at all working on most ppc machines (as of my last update :)) The Gentoo/ppc team doesn't support 2.4.x anymore on ppc, so Gentoo on PowerPC should be on 2.6.x exclusively. Beside of that, 2.4.x on ppc isn't very easy in these days. Done... compile tested against gentoo-sources-2.4.31-r1... PPC already have rc3 stable. ppc64 does not support kernel 2.4. removing amd64 since we don't support 2.4 too. The only one to have stabled rc2 was x86 and now it's fixed. |