Bug#929171: unblock: espeakup/1:0.80-15

[Samuel Thibault]

Samuel Thibault, le mer. 05 juin 2019 22:16:00 +0200, a ecrit:
> Cyril Brulebois, le mar. 04 juin 2019 06:31:23 +0200, a ecrit:
> > Speaking of error messages, we're also getting invalid commands from
> > amixer. Is that expected/known/tracked somewhere? (I think I've been
> > seeing this for months, maybe years.)
> 
> I think I have always seen them, they are coming from 
> alsa-utils-udeb's /usr/share/alsa/utils.sh
> Before multi-card they used to be not visible because only shown
> briefly. The screen reader is not active when they trigger, so it's not
> actually hurting users.

It seems to be benign: utils.sh is just trying to set an apparently
read-only control and probably just needs to filter out the error,
reported on Bug#930226.

Samuel

Bug#929171: unblock: espeakup/1:0.80-15

[Samuel Thibault]

Cyril Brulebois, le mar. 04 juin 2019 06:31:23 +0200, a ecrit:
> Testing multi-cards support (-soundhw all), I'm seeing errors that are
> likely due to busybox's sleep not supporting decimal numbers (“sleep
> 0.1” is called).
> 
> Not a regression if I'm reading the diff correctly, but might be worth
> fixing at some point…

Uh, indeed.  I'll see that post-Buster.

> Speaking of error messages, we're also getting invalid commands from
> amixer. Is that expected/known/tracked somewhere? (I think I've been
> seeing this for months, maybe years.)

I think I have always seen them, they are coming from 
alsa-utils-udeb's /usr/share/alsa/utils.sh
Before multi-card they used to be not visible because only shown
briefly. The screen reader is not active when they trigger, so it's not
actually hurting users.

Keeping that also in my todo list.

Samuel

Bug#929171: unblock: espeakup/1:0.80-15

[Cyril Brulebois]

Niels Thykier  (2019-05-18):
> Samuel Thibault:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > 
> > Hello,
> > 
> > As reported on Bug#929169, “the Linux kernel in Buster seems to take
> > much longer (as much as 12s!) to detect some sound card such as the
> > widespread Intel HDA. The current timeout in espeakup-udeb is thus way
> > too short, and makes the Debian installer useless for blind people
> > having such audio cards.”
> > 
> > In version 1:0.80-15 (debdiff attached) I have thus made the timeout
> > longer. A proper solution would be to make espeakup startup event-based,
> > but that would be very involved at this stage of development.
> > 
> > This version was confirmed to be fixing the issue on a few user systems.
> > 
> > Samuel
> > 
> > unblock espeakup/1:0.80-15
> > 
> > [...]
> 
> Ack from here; CC'ing KiBi for a d-i ack before it is fully unblocked.

Testing multi-cards support (-soundhw all), I'm seeing errors that are
likely due to busybox's sleep not supporting decimal numbers (“sleep
0.1” is called).

Not a regression if I'm reading the diff correctly, but might be worth
fixing at some point…

Speaking of error messages, we're also getting invalid commands from
amixer. Is that expected/known/tracked somewhere? (I think I've been
seeing this for months, maybe years.)


Back to the actual unblock request, that looks reasonable.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#929171: unblock: espeakup/1:0.80-15

[Niels Thykier]

Control: tags -1 confirmed d-i

Samuel Thibault:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hello,
> 
> As reported on Bug#929169, “the Linux kernel in Buster seems to take
> much longer (as much as 12s!) to detect some sound card such as the
> widespread Intel HDA. The current timeout in espeakup-udeb is thus way
> too short, and makes the Debian installer useless for blind people
> having such audio cards.”
> 
> In version 1:0.80-15 (debdiff attached) I have thus made the timeout
> longer. A proper solution would be to make espeakup startup event-based,
> but that would be very involved at this stage of development.
> 
> This version was confirmed to be fixing the issue on a few user systems.
> 
> Samuel
> 
> unblock espeakup/1:0.80-15
> 
> [...]

Ack from here; CC'ing KiBi for a d-i ack before it is fully unblocked.

Thanks,
~Niels

Bug#929171: unblock: espeakup/1:0.80-15

[Samuel Thibault]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

As reported on Bug#929169, “the Linux kernel in Buster seems to take
much longer (as much as 12s!) to detect some sound card such as the
widespread Intel HDA. The current timeout in espeakup-udeb is thus way
too short, and makes the Debian installer useless for blind people
having such audio cards.”

In version 1:0.80-15 (debdiff attached) I have thus made the timeout
longer. A proper solution would be to make espeakup startup event-based,
but that would be very involved at this stage of development.

This version was confirmed to be fixing the issue on a few user systems.

Samuel

unblock espeakup/1:0.80-15

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
Be warned that typing \fBkillall \fIname\fP may not have the desired
effect on non-Linux systems, especially when done by a privileged user.
(From the killall manual page)
diff -Nru espeakup-0.80/debian/changelog espeakup-0.80/debian/changelog
--- espeakup-0.80/debian/changelog  2019-03-29 17:03:23.0 +0100
+++ espeakup-0.80/debian/changelog  2019-05-18 16:37:19.0 +0200
@@ -1,3 +1,9 @@
+espeakup (1:0.80-15) unstable; urgency=medium
+
+  * debian/espeakup-udeb.start: Wait longer for sound cards...
+
+ -- Samuel Thibault   Sat, 18 May 2019 16:37:19 +0200
+
 espeakup (1:0.80-14) unstable; urgency=medium
 
   * rules: Restart espeakup after upgrade (Closes: Bug#925973).
diff -Nru espeakup-0.80/debian/espeakup-udeb.start 
espeakup-0.80/debian/espeakup-udeb.start
--- espeakup-0.80/debian/espeakup-udeb.start2019-03-29 17:03:23.0 
+0100
+++ espeakup-0.80/debian/espeakup-udeb.start2019-05-18 16:35:42.0 
+0200
@@ -7,14 +7,39 @@
 
 if lsmod | grep -q speakup_soft; then
# Give drivers some time to detect boards :/
-   sleep 2
-   IDS=$(echo $BASE/card*/id)
-   N=$(echo $IDS | wc -w)
-   case $N in
-   0)
-   echo No sound card detected, can not do software speech 
synthesis... Press enter to continue anyway.
-   read
-   ;;
+   sleep 1
+   S=1
+   while true
+   do
+   IDS=$(echo $BASE/card*/id)
+   if [ "$IDS" = "$BASE/card*/id" ]; then
+   if [ "$S" -ge 3 ]; then
+   echo "No sound card detected after $S 
seconds..."
+   fi
+   if [ "$S" -lt 30 ]; then
+   # We have seen cards taking as much as 12s to 
get initialized...
+   sleep 1
+   S=$((S+1))
+   continue
+   else
+   echo "Can not do software speech synthesis... 
Press enter to continue anyway."
+   read
+   break
+   fi
+   fi
+
+   # Sleep again as much, in case more cards are to come :/
+   echo "Waiting for $S more seconds for any other card..."
+   sleep $S
+
+   . /usr/share/alsa/utils.sh
+   preinit_levels all
+   sanify_levels all
+
+   IDS=$(echo $BASE/card*/id)
+   N=$(echo $IDS | wc -w)
+
+   case $N in
1)
# Just one card, can not be wrong
echo $(strip $IDS) > /var/run/espeakup.card
@@ -51,5 +76,8 @@
done
echo "$CARD" > /var/run/espeakup.card
ALSA_CARD=$(cat /sys/class/sound/card$CARD/id) 
/usr/bin/espeakup -V en >> /var/log/espeakup.log 2>&1
-   esac
+   esac
+
+   break
+   done
 fi