Beep error could not open any device

Debian Bug report logs —
#922667
beep: Error: could not open any device

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: beep
Version: 1.4.3-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

After today's upgrade to version 1.4.x, beep no longer works and pops the above
error. After checking its man page, I found out that it tries to access these
devices, in that specific order

/dev/input/by-path/platform-pcspkr-event-spkr
/dev/tty0
/dev/vc/0

and although I have the 1st one (the pc speaker), beep does not seem to be able
to access it.
If I am correct. from the new developer's page in github, I found out that
there is this udev rule that needs to be present.

https://github.com/spkr-beep/beep/blob/master/90-pcspkr-beep.rules

If so, please add the above udev rule to your package.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages beep depends on:
ii  libc6  2.28-6

beep recommends no packages.

beep suggests no packages.

-- no debconf information

Message #10 received at 922667@bugs.debian.org (full text, mbox, reply):

Control: tag -1 - upstream
Control: severity -1 normal

   Hi.

On 2/19/19 6:46 AM, jim_p wrote:
> After today's upgrade to version 1.4.x, beep no longer works and pops the above
> error. After checking its man page, I found out that it tries to access these
> devices, in that specific order
> 
> /dev/input/by-path/platform-pcspkr-event-spkr
> /dev/tty0
> /dev/vc/0
> 
> and although I have the 1st one (the pc speaker), beep does not seem to be able
> to access it.
> If I am correct. from the new developer's page in github, I found out that
> there is this udev rule that needs to be present.
> 
> https://github.com/spkr-beep/beep/blob/master/90-pcspkr-beep.rules
> 
> If so, please add the above udev rule to your package.

 I would suggest to install the apt-listchanges package and/or read the
NEWS file that I added specifically about this.  For a start, this is
not an upstream bug, it's a packaging decision.  Secondly, it doesn't
render the package unusable, it can be used by root without any
troubles.  I'm not totally convinced that I want (or should) add the
udev rule.  It's on admin discretion to do so.

 I might consider it though.  I will have to update the package due to
build error on arm64 anyway.  Will locally try it out, but I'll discuss
it first with others if that is a reasonable approach, permission wise.

 Thanks for understanding,
Rhonda

Message #19 received at 922667@bugs.debian.org (full text, mbox, reply):

Package: beep
Version: 1.4.3-1
Followup-For: Bug #922667

Dear Maintainer,

I tried adding my user to the beep group, but nothing changed. Then I read
everything in /usr/share/doc/beep/INSTALL.md and here are my thoughts,

Before adding my user to the beep group, I had to create that group. I did
that, but still no beep. Why?

Because before making the group, I had to make the relevant udev rule. I
created it too, I rebooted, bust still no beep. Why?

Because I also had to change the device permissions, but I have no idea how to
to that. I tried whatever is suggested in the instructions but all I get is
this bit

# ls -lH /dev/input/by-path/platform-pcspkr-event-spkr
crw-rw---- 1 root input 13, 67 Feb 20 09:00 /dev/input/by-path/platform-pcspkr-
event-spkr

# getfacl /dev/input/by-path/platform-pcspkr-event-spkr
getfacl: Removing leading '/' from absolute path names
# file: dev/input/by-path/platform-pcspkr-event-spkr
# owner: root
# group: input
user::rw-
group::rw-
other::---

Maybe I am doing something wrong. But I think most, if not all, of this stuff
can be ommited if you provide the udev rule, make the group and change the
device permissions upon the install of the package.
On top of that, I think all that setup is a tedius job for something that, for
me at least, is used for a few milliseconds each time (I use beep to make an
audible notification for when transmission-daemon completes a download). The
1.3.x version was literally plug-n-play, because, after installing it, I could
use pcspkr with it instantly, with no extra setup at all.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages beep depends on:
ii  libc6  2.28-7

beep recommends no packages.

beep suggests no packages.

-- no debconf information

Message #24 received at 922667@bugs.debian.org (full text, mbox, reply):

     Hi,

 do you have the acl package installed? Because the suggested udev rule
makes use of ACLs.  And after adding the udev rule you probably need to
restart because it only triggers on activating the device.

 So yes, the documentation could be better for the steps needed, and
we'll think about improving that.

 Personally I'm not too keen on adding an additional dependency on the
acl package, no matter how useful it is.  The main reason for the update
was to get the security issues fixed, and given the state of the release
making it extra comfortable for end users to get it working for regular
users instead of only for root wasn't the priority.

 I hope you can understand that.
Rhonda


On 2/20/19 8:36 AM, jim_p wrote:
> Package: beep
> Version: 1.4.3-1
> Followup-For: Bug #922667
> 
> Dear Maintainer,
> 
> I tried adding my user to the beep group, but nothing changed. Then I read
> everything in /usr/share/doc/beep/INSTALL.md and here are my thoughts,
> 
> Before adding my user to the beep group, I had to create that group. I did
> that, but still no beep. Why?
> 
> Because before making the group, I had to make the relevant udev rule. I
> created it too, I rebooted, bust still no beep. Why?
> 
> Because I also had to change the device permissions, but I have no idea how to
> to that. I tried whatever is suggested in the instructions but all I get is
> this bit
> 
> # ls -lH /dev/input/by-path/platform-pcspkr-event-spkr
> crw-rw---- 1 root input 13, 67 Feb 20 09:00 /dev/input/by-path/platform-pcspkr-
> event-spkr
> 
> # getfacl /dev/input/by-path/platform-pcspkr-event-spkr
> getfacl: Removing leading '/' from absolute path names
> # file: dev/input/by-path/platform-pcspkr-event-spkr
> # owner: root
> # group: input
> user::rw-
> group::rw-
> other::---
> 
> Maybe I am doing something wrong. But I think most, if not all, of this stuff
> can be ommited if you provide the udev rule, make the group and change the
> device permissions upon the install of the package.
> On top of that, I think all that setup is a tedius job for something that, for
> me at least, is used for a few milliseconds each time (I use beep to make an
> audible notification for when transmission-daemon completes a download). The
> 1.3.x version was literally plug-n-play, because, after installing it, I could
> use pcspkr with it instantly, with no extra setup at all.
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages beep depends on:
> ii  libc6  2.28-7
> 
> beep recommends no packages.
> 
> beep suggests no packages.
> 
> -- no debconf information
> 

Message #29 received at 922667@bugs.debian.org (full text, mbox, reply):

Package: beep
Version: 1.4.3-1
Followup-For: Bug #922667

Dear Maintainer,

The instructions did work after a cold boot, done several hours after writing
the previous message. It seems a simple reboot was not enough :P
I installed acl by hand because it was not already installed, not even as a
dependency. Plus, getfacl is not available without the acl package.
On top of that, I also had to add debian-transmission (= the user transmission-
daemon runs as) to the beep group so that it would "beep when done".

Please reconsider about adding acl as a dependency (I assume it has to be a
direct dependency, not just a suggested/recommended one), creating the beep
group and adding the udev rule as well. I do not think it will harm any
existing setups but it will definitely make our lives easier. If all that is
done, documentation is almost not needed. A simple "please add your user to the
beep group" notification, after the installation, is enough.

Thank you :)



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages beep depends on:
ii  libc6  2.28-7

beep recommends no packages.

beep suggests no packages.

-- no debconf information

Message #34 received at 922667@bugs.debian.org (full text, mbox, reply):

Hello

I don't yet understand all the above, but I, too, was puzzled when my 
beeping scripts went silent.

Hugh Morris

Message #39 received at 922667@bugs.debian.org (full text, mbox, reply):

Package: beep
Followup-For: Bug #922667

Before it worked fine via sound card speakers as normal user, now not
even root can get beeps. I understand the user perms setup part being
not done yet, but not why root fails too (the only difference is if it
prints "Error: Could not open any device" or not).

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages beep depends on:
ii  libc6  2.28-7

beep recommends no packages.

beep suggests no packages.

-- no debconf information

Message #44 received at 922667-close@bugs.debian.org (full text, mbox, reply):

Source: beep
Source-Version: 1.4.3-2

We believe that the bug you reported is fixed in the latest version of
beep, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 922667@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Rhonda D'Vine <rhonda@debian.org> (supplier of updated beep package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 21 Feb 2019 11:26:35 +0100
Source: beep
Binary: beep beep-dbgsym beep-udeb
Architecture: source amd64
Version: 1.4.3-2
Distribution: unstable
Urgency: high
Maintainer: Rhonda D'Vine <rhonda@debian.org>
Changed-By: Rhonda D'Vine <rhonda@debian.org>
Description:
 beep       - advanced PC-speaker beeper
 beep-udeb  - advanced PC-speaker beeper - minimal package (udeb)
Closes: 767087 922667
Changes:
 beep (1.4.3-2) unstable; urgency=high
 .
   * New patch to use -g instead of -gstabs, which makes it compile with dh_dwz
     again, and fixes the FTBFS on arm64.
   * Shipping a udev rule that enables local users to use the beep tool.
     Updating the NEWS entry about it. (closes: #767087, #922667)
Checksums-Sha1:
 db010f9a088f5f18977613296278a18fb12e9764 1852 beep_1.4.3-2.dsc
 2d7b35e23df81e54bff122ed61aebecc53b7b044 8176 beep_1.4.3-2.debian.tar.xz
 00ad523e0a272cd1403115339b3d57e97e663615 18324 beep-dbgsym_1.4.3-2_amd64.deb
 70ab9e731be106765ee8d237cde7ace203a158cd 8048 beep-udeb_1.4.3-2_amd64.udeb
 12b5b0eea795c4ca92aa25b1fdd321ac5c51642c 5657 beep_1.4.3-2_amd64.buildinfo
 552998fe31735f9c3635e3c2636fad5ac9c74f7b 26812 beep_1.4.3-2_amd64.deb
Checksums-Sha256:
 7abf5ace48cba7e8e9495bd8a244b2ca7c485c9a32d3fee0e0a1fa75f7326b95 1852 beep_1.4.3-2.dsc
 d5f7ea0e4d2aee1dab6fa348c96589124c796075d0a59cfab99fed3548511668 8176 beep_1.4.3-2.debian.tar.xz
 4ebd6b44a1ba88e3a20abc2b0ab7aa2d3affee93acbc8680272b0f197e36554b 18324 beep-dbgsym_1.4.3-2_amd64.deb
 a2177326ba682805cbd2d532bc5609ca55da630b0edd432a83b8b618b0154220 8048 beep-udeb_1.4.3-2_amd64.udeb
 7e546c3d185f610c81efeeccf2df6a6b5ed01a4ac1e125d077c2da6d62ea2c5b 5657 beep_1.4.3-2_amd64.buildinfo
 54a5f76fed6b43db49744ddaef2649fa1fbfb21f831494707bef6101030a2ae0 26812 beep_1.4.3-2_amd64.deb
Files:
 1d94157a97aa525554aa708bd87054b6 1852 sound optional beep_1.4.3-2.dsc
 58401317de3ce48262c8c35862b2e1f6 8176 sound optional beep_1.4.3-2.debian.tar.xz
 a85d2316b75c8e0615ae1db4084ea5d7 18324 debug optional beep-dbgsym_1.4.3-2_amd64.deb
 d43512cc470980080f86a9e0d611c21e 8048 debian-installer optional beep-udeb_1.4.3-2_amd64.udeb
 d2a5259c8446e0bcc2d7be9f6deecf82 5657 sound optional beep_1.4.3-2_amd64.buildinfo
 1b6b4173a6ccc71d7865110719427575 26812 sound optional beep_1.4.3-2_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEELHLzKO0XByBPs0mU3ugEPuF+uzAFAlx+aKkACgkQ3ugEPuF+
uzAd4g/8Cd0/TjkXnHD4Ntc/YuPfidCbL6HCYrz9KaSn7hiU5EnLKt8jFBokik0c
HIbEGLPKYDrMJkRAn3pKAyInC2YMbMi7hXdiejnk3cKqSaPZwrDm7AKeTMSHt84n
SniT5nE7x+AI9PG+vwdjzZxALI5EiYTUqomKDvndHR6YVJGkLmOu2GrjiVkwD6qJ
f+nzQWtnPGSIHZ/58Aj3G94lAv1Iwm+/qKPVz3Yr2xzI2UFwF+IjWOAKDxeiywiy
M6sXeHe1QfaqNafkABsWPd3RU31/uVGyfsQIJVZmZZpVt6amnTjYkf+sUaPOpAhM
zULVcKTjtOhG7AEUQmLIKKLMXNIGVA7yCu0Xc5fz0eHJLDb3YlsIvNkBJoAV+Ii0
Hll658ApQXDvGjJnS9PEOAdZl/KyJnrR5Zp/lLShKCqNN2ovJR2X1aUDNbFbBUcA
Ov5JcuZYFBZyYTimNBKAJ9BrJuW7LuXrYBBYuUCez4sWqt4HSJL2ER9FL2PcLztV
J0Q15fZiFhtoW+jRqX0fikfafcqCZZzTOVxQcK6Ww3HBhLlcofZoI9IFK2uFDv6o
MJ2au/TnDgmUYWMM5a9hDRNhUhPfbfe+7XHWMqNqO6cs9+CmkteNWS7ZY95YrZQZ
HVRGYr51UNMxHw+9CUavJHePxLJJw0JT5w/Y0NVpr6KUxxp7r0E=
=tB8L
-----END PGP SIGNATURE-----

Message #49 received at 922667@bugs.debian.org (full text, mbox, reply):

Package: beep
Version: 1.4.3-2
Followup-For: Bug #922667

Dear Maintainer,

First of all, as soon as the package was updated to 1.4.3-2, I removed the
upstream udev rule and let it use the provided one. I see there is a small
difference between them, but I can not explain what that change actually does.
The problem is that that difference, imho, makes beep partialy broken.

It does work... most of the time, so let me mention my use cases in which it
does not work.

a) As I have said above, I mainly use beep as an audible notification for
transmission-daemon. The user debian-tranmission is on the beep group as seen
below

$ id debian-transmission
uid=110(debian-transmission) gid=110(debian-transmission) groups=110(debian-
transmission),999(beep)

but no beep is heard when it is supposed to.

b) Executing beep as a regular user, who is in the beep group obviously,
works... if the user is logged in locally.
Executing it as a the same user, connected via ssh, still pops up the "could
not open any device" error and getfacl reports the same as above for the
ownership stuff

# getfacl /dev/input/by-path/platform-pcspkr-event-spkr
getfacl: Removing leading '/' from absolute path names
# file: dev/input/by-path/platform-pcspkr-event-spkr
# owner: root
# group: input
user::rw-
group::rw-
other::---

Both these issues are completely solved when using the upstream udev rule, so I
think your rule needs some fixing.

Thanks for listening :)

p.s. mini rant:
I also noticed that the updated package still does not make the beep group, so
it is one more step for the user to do.
Other packages do that all the time (that's why I still have a debian-tor group
although I have removed removed torbrowser ~2 years ago), so I don't think it
will be hard or pointless to have a beep group as well. Special groups are
mandatory for various reasons.
And, because I had a small discussion about it with a fellow (and more
advanced) debian and beep user, if you consider a "security flaw" to have beep
running as a non-root user, why package beep at all? Plus, if I have to do all
that stuff by hand in order to make it "simply" work, why do I still have
debian and not gentoo (or arch at the very least)?



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages beep depends on:
ii  libc6  2.28-8

beep recommends no packages.

beep suggests no packages.

-- no debconf information

Message #54 received at 922667@bugs.debian.org (full text, mbox, reply):

  Hey there. :)

On 3/12/19 5:13 PM, jim_p wrote:
> First of all, as soon as the package was updated to 1.4.3-2, I removed the
> upstream udev rule and let it use the provided one. I see there is a small
> difference between them, but I can not explain what that change actually does.
> The problem is that that difference, imho, makes beep partialy broken.

 The shipped udev rule is to allow local logged in users access to the
device.  Which is the common case, because you actually would want
people in front of the computer to be able to beep it, others usually
won't be able to hear it anyways.

 But yes, your case is something different, and for that the upstream
suggested approach might be feasible.  I though am not convinced that
special casing for every corner cases of the usage of the package is the
best move forward.  It would add quite some complexity, and added
dependency which I doubt that most people actually would benefit from.

 For those corner cases please create the beep group yourself and use
the upstream suggested udev rule.  Even if I would consider of adding
the complexity needed for that (through facilitating debconf for
questioning which kind of setup the admin would prefer) it would require
testing and needs time to make sure it doesn't interfer with other
things - and like said, would pull in another dependency.  And given
that we are now in freeze for buster time doesn't really permit that.

 If people have patches and merge requests that I could look at it might
improve the chances for that to happen, but it still would be something
for the next release.

> p.s. mini rant:
> I also noticed that the updated package still does not make the beep group, so
> it is one more step for the user to do.

 The beep group would only be needed when doing the acl dance that
upstream suggested.  Given that we don't do that there is no need to
create the group in the first place.

> Other packages do that all the time (that's why I still have a debian-tor group
> although I have removed removed torbrowser ~2 years ago), so I don't think it
> will be hard or pointless to have a beep group as well. Special groups are
> mandatory for various reasons.

 The difference there is that torbrowser did actually use that group.
Which the beep package never did.  The older version of the package used
the existing audio group, which made a fair amount of sense to
facilitate for this.

> And, because I had a small discussion about it with a fellow (and more
> advanced) debian and beep user, if you consider a "security flaw" to have beep
> running as a non-root user, why package beep at all? Plus, if I have to do all
> that stuff by hand in order to make it "simply" work, why do I still have
> debian and not gentoo (or arch at the very least)?

 Just because something might expose information in specific usage
doesn't mean that it doesn't make sense for dedicated situations.  I
can't follow the reasoning that it would be beneficial to have it rather
not at all than to have it available for a specific environment.  I have
no idea what you try to achieve with that kind of argumentation?

 And it *does* simply work.  Just not for your special corner case,
which is unfortunate, but that requires a bit more work.  Depending on
acl, creating a dedicated group and shipping a rule that facilitates
that isn't that trivial to get right.  Otherwise I would assume you had
sent me already a patch for it, wouldn't you. :)

 Thanks for your interest in beep anyways, it's appreciated.
Rhonda

Send a report that this bug log contains spam.