Processed: Re: Bug#672808: aylet: couldn't open sound device.
Processing commands for cont...@bugs.debian.org: severity 672808 normal Bug #672808 [aylet] aylet: couldn't open sound device. Severity set to 'normal' from 'important' thanks Stopping processing here. Please contact me if you need assistance. -- 672808: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672808 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.138226057526823.transcr...@bugs.debian.org
Bug#672808: aylet: couldn't open sound device.
severity 672808 normal thanks Dmitry Semyonov linu...@gmail.com writes: Package: aylet Version: 0.5-3 Severity: important aylet is compiled to use OSS driver, and it seems OSS compatibility layer is not installed by default in Debian Wheezy. As a workaround, one can install alsa-oss package and start aylet as follows: $ aoss aylet *.ay Given that there’s such a simple workaround, I’ve taken the liberty to lower the severity down to normal. Probably, there are other ways to solve the problem, but if going the suggested way it would be good to add alsa-oss into the list of aylet dependencies, and specifically mention the workaround in README.Debian. However, I believe that alsa-oss should /not/ be in Depends:, for aylet(1) can also be used on a completely mute system. (Think of a file server performing automated .ay to .oga conversion, for instance.) Suggests: seems to be a safe choice, though. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wql89ubi@violet.siamics.net
Bug#510051: Control keys do not work when aylet is started via xargs
Krystian Wlosek kwlo...@gmail.com writes: tags 510051 wontfix thanks Use command similar to the following to reproduce: echo AgentX.ay AgentX2.ay |xargs aylet JFTR, using xargs(1) with an interactive program doesn’t seem like a very clever idea, for with the number of passed command arguments being sufficiently large, xargs(1) may choose to (or even have to) invoke the command specified several times in a row, each time giving it a portion of the arguments’ list. The real solution to this issue would be to add support for the conventional --files-from= option. (And also --null.) aylet reads keys codes from standard input, stdin is connected to proper terminal (tty). xargs replace this stdin by own pipe not connected with terminal, so aylet doesn't receive any control keys. I’d argue that should such a condition be detected (via isatty ()), aylet(1) should just re-open its terminal, as in: /* call ctermid () to get the tty filename */ int tty_fd = open (tty, O_RDONLY); /* check for errors */ int rv = dup2 (tty_fd, STDIN_FILENO); /* check for errors */ Given that this issue has such a trivial fix, I see no reason not to implement it. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppr09tn2@violet.siamics.net
libsane
Hi, a new Version of libsane has been released : 1.24 Why isn' t it in sid published? Greetings Michel -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5263a094.6060...@web.de
Bug#726817: chrony: GPL-2-only program linking GPL-3+ libreadline6 on amd64
On Sat, Oct 19, 2013 at 04:06:06PM +0200, Ansgar Burchardt wrote: Package: chrony Severity: serious Version: 1.24-3+squeeze1 X-Debbugs-Cc: t...@security.debian.org, debian-rele...@lists.debian.org The security update for chrony links against libreadline6 on amd64. However chrony is licensed under GPL-2-only and libreadline6 is GPL-3-or-later. The buildd uploads still link against libreadline5 (GPL-2+). So it looks like the amd64 version was built in an unclean environment. So chrony needs either a, a binNMU on amd64 for the next point release, leaving the current version on security.d.o, or We should trigger a binBMU for amd64. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131020161020.GA4438@pisco.westfalen.local
Bug#672808: aylet: couldn't open sound device.
Another, probably better, workaround is oss-compat package: The purpose of this package is for applications that only support OSS to depend on it, hence preventing common /dev/dsp not found errors that would confuse unexperienced users. -- ...Bye..Dmitry. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGUoffCWTN9vJ5Mo0ZrScujtOY=Zxty0OAQoxPKKu9paA=s...@mail.gmail.com
Bug#672808: aylet: couldn't open sound device.
On 20 October 2013 13:15, Ivan Shmakov wrote: Dmitry Semyonov linu...@gmail.com writes: However, I believe that alsa-oss should /not/ be in Depends:, for aylet(1) can also be used on a completely mute system. (Think of a file server performing automated .ay to .oga conversion, for instance.) Suggests: seems to be a safe choice, though. Depends: is still feasible since package description claims: aylet plays music files. I.e. this is a significant amount of functionality which qualifies for Depends: per Debian Policy. Suggests: is too weak, in my opinion. I'd rather use Recommends: oss-compat if Depends is chosen to be avoided. -- ...Bye..Dmitry. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGUoffAXqJXLN=jEpdFip+mWdekPkq5ZJyS=xdkdppfjtkd...@mail.gmail.com
