Please answer directly to the bug. This is for the record ;)
Elimar
--
Experience is something you don't get until
just after you need it!
--- Begin Message ---
On Thu, Feb 12, 2009 at 07:58:13PM +0100, Elimar Riesebieter wrote:
> * Lionel Elie Mamane [090212 08:36 +0100]
>> But I have _finally_ figured it out! Removing the exclamation mark
>> _and_ applying this patch to /usr/share/alsa/alsa.conf does the
>> trick.
> Will this fix #505089? If so, I_ll include it in 1.0.19.
Yes, but to fix the bug, you need to change both alsa-utils (so that
it does not put the exclamation mark) and alsa-lib (to make alsa
accept a string, and not only an integer, there); that's why I cloned
the bug and reassigned the clone to alsa-lib.
--
Lionel
--- End Message ---
--- Begin Message ---
On Thu, Feb 12, 2009 at 08:27:14PM +0100, Elimar Riesebieter wrote:
> As far as this bug is tagged unreproducible: I checked it again and
> can't reproduce.
Have you tried with a nanosecond-resolution-timestamp filesystem, and
the autotools installed? If your filesystem rounds timestamps to the
second (for example, ext2 or ext3), you would only very rarely see the
problem. You can use a XFS loop-filesystem to test it out if your
/home/ or /var/ filesystem has only second resolution. If the
autotools are not installed, the problem is not triggered either.
> Lional, (...) please check your build within a chroot like pbuilder
> and argue again, though.
Been there, done that. Did it again now. As soon as the chroot is on a
nanosecond-resolution-timestamp filesystem and the autotools are
installed, the second build fails. This sequence fails:
dpkg-source -x alsa-lib_1.0.16-2.dsc
cd alsa-lib-1.0.16
dpkg-buildpackage -uc -us -b
dpkg-buildpackage -uc -us -b
--
Lionel
--- End Message ---
