Am Montag, 17. Dezember 2007 15:42:27 schrieb Jan de Groot:
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Dan McGee Verzonden: maandag 17 december 2007 15:38 Aan: Public mailing list for ArchLinux development Onderwerp: Re: [arch-dev-public] [signoff] kernel26-2.6.23.11-1
Ugh, I retract my signoff. Alsa is broken here, I hadn't bothered to check that, but once I saw an email about it on the arch-general list I did and noticed I had the same problem.
1. My fault for signing off here too early- I shouldn't do that, although see my next point. 2. I should be able to signoff on a minor version bump of a kernel without too many concerns- however, we make huge changes in each one. Do we REALLY need to bump the ALSA snapshot every single time? If it causes issues like this, that is unacceptable. For the one person's bug you might fix, you just broke every other users sound. 3. Instead of saying "plz signoff", we should post changelogs for upgrades (or say version bump only). You did say "updated alsa", but it sounds like cfs was updated too and that wasn't reported.
The problem with alsa snapshots is that we take snapshots from the development branch. When we took the snapshot, there had been a change in the kernel API that makes "old" alsa-libs incompatible. They reverted the change 3 hours ago, but the change is not in our kernel, so our kernel is broken when used with the current alsa-lib package. Alsa snapshots can be broken any time, it's wrong to just include a newer snapshot of alsa-kernel without looking at what issues are fixed and what things are changed. IMHO only driver updates are acceptable in our kernel, not alsa core feature changes like the one that broke the alsa kernel API.
I am not sure why this snapshots are really needed at all. I recompiled the kernel without alsa nor cfs patches and everything seems to be fine again. But there are still those strange warnings about pnpacpi: "pnpacpi: exceeded the max number of mem resources: 12". I did not notice any issue caused by this; so we might ignore this. -- archlinux.de