Bug#658728: linux-image-3.2.0-1-amd64: No more sound
First off, thank you very much J. Nieder for providing so much
feedback, and for being an excellent middleman between Debian users and
upstream. It's amazing that a few user complaints can trickle up to
change parts of the whole Linux monolithic kernel. It's like the
metaphorical "miracle of the pencil", free software style.
On to catching a bug...
On Wed, 15 Feb 2012 14:57:45 -0600
Jonathan Nieder <jrnieder@gmail.com> wrote:
> A. Costa, could you try the attached patches, against 3.2.y? It works
> like this...
That might be difficult. I'm on dialup, I've tried to do what you said,
but at the 'git' point, after an hour of downloading the prompt was
still at '0%':
% git clone -o stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Cloning into 'linux-stable'...
remote: Counting objects: 2450707, done.
remote: Compressing objects: 100% (393726/393726), done.
^Cceiving objects: 0% (15033/2450707), 5.43 MiB | 12 KiB/s
It's not clear if 'git' is able to provide a reliable estimate of how
much time it needed. Worst case, I'm afraid it'd be 1% x 99 hours.
Maybe the objects are differing sizes, and the first '0%' takes the
longest. I'll try more tonight.
Is there some method that doesn't need so much bandwidth? If not,
I'll suggest one...
I regularly upgrade all my packages, including the kernel with 'cupt',
which calls 'debdelta', which uses so much less bandwidth.
(Excepting with the few odd package repositories I use that lack
'delta' files.)
Would you be able to easily produce such a delta, (containing the patch
you'd like tested, in binary -- no compiling on my end), from the stock
kernel I'm using? If not, there's clearly a need for a relatively
simple tool to do such jobs.
Advantages of Debian maintainers providing kernel test patches as binary
debdelta files:
1) Users with low bandwidth would be more able to test patches.
Particularly "Third World" users.
2) Users who, for various reasons (lack of time, inclination, skill),
aren't able to compile their kernel, wouldn't have to.
3) Maintainers would garner more feedback.
4) Maintainers wouldn't be obliged to spend as much time coaxing
users through compilation rituals.
5) The patch, being binary, would have zero chance of being miscompiled
by users who make mistakes during said rituals.
6) Such a tool would save time for the technically minded as well,
who might sometimes grow mentally weary of juggling incompatible patches.
7) Debian's servers save bandwidth.
8) By #7, the net saves bandwidth.
Of course this doesn't help today with #658728, but if we assume we'll
all still be using Debian in 10 years, those benefits would pile up.
Where should one file a "wishlist" for a package or tool that doesn't
exist?
PS: I haven't CC:'d T. Iwai, as this is something of a Debian issue,
though anything that reduces user feedback does affect upstream as well.
Reply to: