-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Dan McGee Verzonden: maandag 17 december 2007 1:55 Aan: Public mailing list for ArchLinux development Onderwerp: Re: [arch-dev-public] [signoff] kernel26-2.6.23.11-1

On Dec 16, 2007 8:46 AM, Tobias Powalowski wrote:

...

Hi kernel for both arches in testing, please signoff - cleaned up cvs - updated alsa - updated unionfs

No noticed problems after a reboot, although for some reason I got the following warning while fsck started up: primary superblock features different from backup, check forced

Not sure why that happened, but I'll signoff for i686.

Looking at FS#8948 and FS#8949, I don't think it's wise to put this one into core.

-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Pierre Schmitz Verzonden: maandag 17 december 2007 10:58 Aan: arch-dev-public@archlinux.org Onderwerp: Re: [arch-dev-public] [signoff] kernel26-2.6.23.11-1

Am Montag, 17. Dezember 2007 08:43:53 schrieb Jan de Groot:

...

Looking at FS#8948 and FS#8949, I don't think it's wise to put this one into core.

This kernel is somehow broken. Are those alsa and cfs patches really needed? Afaik the vanilla kernel does not have those problems.

I wonder where this latest cfs scheduler patch comes from. The header says 2.6.23.8 v24, the filename says 2.6.23.11 v24 and the upstream site only has 2.6.23.9 v24. Was this .11 patch we have some hacked up 2.6.23.8 patch to compile with .11?

-----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.

On Dec 17, 2007 11:11 AM, Pierre Schmitz wrote:

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.

I've wondered this myself - why do we use the lastest-and-greatest direct-from-source-control alsa snapshots? Is there a reason? Tpowa, could you fill us in? I mean, it DOES make sense to do this in some regards, but sound isn't really mission critical. It seems like we have lots of sound issues every so often and the fix is usually "reverted the alsa snapshot". Could you please explain so the rest of us understand?

On Mon, 2007-12-17 at 15:19 -0600, Aaron Griffin wrote:

...

On Dec 17, 2007 11:11 AM, Pierre Schmitz wrote:

...

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. The CFS doesn't affect your pnpacpi problem nor alsa. It speeds up the scheduler to .24 speed and fixes wlan wpa issues, as reported in the last kernel signoffs.

Am Dienstag, 18. Dezember 2007 schrieb Jan de Groot: the patch is from ingo molnar (redhat kernel hacker), only cleaned up to apply to latest kernel source which already included some minor changes already. pnpacpi will be fixed in 2.6.23.12 kernel -> upstream issue

...

I've wondered this myself - why do we use the lastest-and-greatest direct-from-source-control alsa snapshots? Is there a reason? Tpowa, could you fill us in? I mean, it DOES make sense to do this in some regards, but sound isn't really mission critical. It seems like we have lots of sound issues every so often and the fix is usually "reverted the alsa snapshot". Could you please explain so the rest of us understand?

Usually it's the other way around. With all these random HDA codecs on the market, it's a pain to maintain driver support for these things. Usually it's "update to new alsa snapshot" to fix bugs, but in this case we got a broken snapshot. New snapshot should be fine though, they fixed the missing IOCTL today. new snapshot is included in new 2.6.23.12 kernel that should fix those issues too.

greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org