Your message dated Fri, 15 Apr 2016 08:06:15 +0200
with message-id <[email protected]>
and subject line Re: [Pkg-alsa-devel] Bug#821048: alsa-utils: arecord -d
broken, apply upstream patch
has caused the Debian Bug report #821048,
regarding alsa-utils: arecord -d broken, apply upstream patch
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
821048: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821048
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: alsa-utils
Version: 1.0.28-1
Severity: important
Tags: patch
Dear Maintainer,
>From the upstream repository git://git.alsa-project.org/alsa-utils
85827fbb6424 fixes the problem (see that commit message for the
details) and 8f361d83cfcb avoids the problem. In summary -d has a
very high likelihood of continually writing over the file you are
trying to record (after capturing that much audio), or continually
writing out 44 byte files, and I had 3.1 million to delete. This
hasn't been a problem upstream for nearly 2 years, but Debian stable
isn't on that release. Either patch, or both will address the
problem.
>From 8f361d83cfcb39887f5fc591633e68d9448e3425 Mon Sep 17 00:00:00 2001
From: Jaroslav Kysela <[email protected]>
Date: Wed, 1 Oct 2014 15:43:57 +0200
Subject: [PATCH] Revert "aplay: fix pcm_read() return value"
This reverts commit 8aa13eec80eac312e4b99423909387660fb99b8f.
The semantics for pcm_read() and pcm_readv() was changed, but the
callers expect the exact frame count as requested. It's possible
to fix callers, but the fix is more complicated than to revert the
change. Note that '-d' processing was broken in some cases.
Note: The reverted commit allows that the return value might be
greater than requested (see the first condition in read routines).
---
aplay/aplay.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/aplay/aplay.c b/aplay/aplay.c
index 30d3f31..e58e1bc 100644
--- a/aplay/aplay.c
+++ b/aplay/aplay.c
@@ -2039,7 +2039,7 @@ static ssize_t pcm_read(u_char *data, size_t rcount)
data += r * bits_per_frame / 8;
}
}
- return result;
+ return rcount;
}
static ssize_t pcm_readv(u_char **data, unsigned int channels, size_t rcount)
@@ -2084,7 +2084,7 @@ static ssize_t pcm_readv(u_char **data, unsigned int
channels, size_t rcount)
count -= r;
}
}
- return result;
+ return rcount;
}
/*
--
2.1.4
>From 85827fbb642463ab724a9471a7a88f93fa2a217d Mon Sep 17 00:00:00 2001
From: David Fries <[email protected]>
Date: Wed, 13 Apr 2016 23:32:46 -0500
Subject: [PATCH] aplay: fix lurking capture file overwrite bug
If -d was given to arecord while commit
8aa13eec80eac312e4b99423909387660fb99b8f (now reverted) was in effect,
the last read would be shorter than the chunk size, but pcm_read would
read and return the chunk size, the samples were discarded, and
capture() continued in a loop because count never reached 0. arecord
opens a new file each loop iteration, if arecord is dynamically naming
files, --use-strftime option or beyond the wave 2GB limit, this will
generate a series of header only wave files. If the file is unique
the originally recorded data is lost and it will continue overwriting
the same file with a header only wave file.
While the current pcm_read can't fail (it can exit), it is better to
just fix this lurking bug in case it is "fixed" again.
Signed-off-by: Takashi Iwai <[email protected]>
---
aplay/aplay.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/aplay/aplay.c b/aplay/aplay.c
index 7acaa83..2da7dda 100644
--- a/aplay/aplay.c
+++ b/aplay/aplay.c
@@ -3067,11 +3067,14 @@ static void capture(char *orig_name)
size_t c = (rest <= (off64_t)chunk_bytes) ?
(size_t)rest : chunk_bytes;
size_t f = c * 8 / bits_per_frame;
- if (pcm_read(audiobuf, f) != f)
+ if (pcm_read(audiobuf, f) != f) {
+ in_aborting = 1;
break;
+ }
if (write(fd, audiobuf, c) != c) {
perror(name);
- prg_exit(EXIT_FAILURE);
+ in_aborting = 1;
+ break;
}
count -= c;
rest -= c;
@@ -3091,7 +3094,7 @@ static void capture(char *orig_name)
}
if (in_aborting)
- break;
+ prg_exit(EXIT_FAILURE);
/* repeat the loop when format is raw without timelimit or
* requested counts of data are recorded
--
2.1.4
-- System Information:
Debian Release: 8.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-rc7+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages alsa-utils depends on:
ii dialog 1.2-20140911-1
ii kmod 18-3
ii libasound2 1.0.28-1
ii libc6 2.19-18+deb8u3
ii libncursesw5 5.9+20140913-1+b1
ii libsamplerate0 0.1.8-8
ii libtinfo5 5.9+20140913-1+b1
ii lsb-base 4.1+Debian13+nmu1
ii whiptail 0.52.17-1+b1
alsa-utils recommends no packages.
alsa-utils suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Control: severity -1 normal
Control: fixed -1 1.1.0-2
Control: tags -1 - patch
* David Fries <[email protected]> [2016-04-14 17:42 -0500]:
> Package: alsa-utils
> Version: 1.0.28-1
> Severity: important
> Tags: patch
>
> Dear Maintainer,
>
> >From the upstream repository git://git.alsa-project.org/alsa-utils
> 85827fbb6424 fixes the problem (see that commit message for the
> details) and 8f361d83cfcb avoids the problem. In summary -d has a
> very high likelihood of continually writing over the file you are
> trying to record (after capturing that much audio), or continually
> writing out 44 byte files, and I had 3.1 million to delete. This
> hasn't been a problem upstream for nearly 2 years, but Debian stable
> isn't on that release. Either patch, or both will address the
> problem.
Please update to alsa-utils 1.1.0-2 first. In stable there will be
only security patches accepted. Bug closed herewith. Backports are
not maintained from us.
Elimar
--
Do you smell something burning or is it me?
--- End Message ---
