Bug#840879: rosegarden: Please announce supported hardware using AppStream

[Ted Felix]

Just added this upstream:

https://sourceforge.net/p/rosegarden/git/ci/934201c940081f6d9139f4977768058ec3f0e4e4/

There's already a  tag at the top and I added it (along with 
some documentation) to that instead of at the bottom.  Looks like this now:



  com.rosegardenmusic.rosegarden.desktop
  
  usb:*ic01isc03ip*

Bug#1007103: Rosegarden: malloc_consolidate(): unaligned fastbin chunk detected

[Ted Felix]

On 3/27/22 1:49 AM, Ron Murray wrote:
I have the same problem here. Removing lmms and fluidsynth-dssi made no 
difference.


I did a debug build and ran it with gdb. The resullt is attached.


  Thanks.  In your case it looks like something called "whysynth" is 
the issue:


/usr/lib/dssi/whysynth.so

  This is shown in the _dl_map_object() entry in the backtrace:

#10 0x77fd59cd in _dl_map_object (loader=0x0,
loader@entry=0x77ffe220, name=name@entry=0x7fffdc1a3e30 
"/usr/lib/dssi/whysynth.so", type=type@entry=2, 
trace_mode=trace_mode@entry=0, mode=mode@entry=-1879048191, 
nsid=) at dl-load.c:2336


  Try uninstalling that.  The others might still be an issue, so don't 
be surprised if it continues to crash and more plugins need to be 
uninstalled.


  There appear to be a number of issues with the various DSSI synth 
plugins.  Someone needs to open bug reports against each of these 
crashing plugins and mention all the others.  That should get us closer 
to finding the real problem.


  This bug report against rosegarden can be closed.

Bug#1007103: Further information

[Ted Felix]

  OP informs me that he tracked the problem down to the ZynAddSubFX 
DSSI plugin.  He switched to the ZynAddSubFX standalone app and all is 
well for him.


  This bug can be closed for rosegarden.

Bug#1007103: Further information

[Ted Felix]

  I just pushed improved plugin logging as [3a07309c].  If you can, 
please test latest git:


  https://sourceforge.net/p/rosegarden/git/ci/master/tree/

  A debug build should now let you know when it is trying to load a 
plugin.  And that should be the last thing you see from rosegarden when 
a plugin crashes on load.

Bug#1007103: Further information

[Ted Felix]

On 3/19/22 7:08 AM, Rainer Hans Liffers wrote:
> I compiled the latest version of rosegarden with debugging enabled 
and subsequently ran gdb as shown in attached file.  Is this information 
sufficient?


  Yes.  Thanks.

  The first line relevant to rg is this:

#19 0x55e3188e in Rosegarden::LADSPAPluginFactory::loadLibrary 
(this=0x7fffb0004fd0, soName=...)
  at 
/home/rainer/Downloads/rosegarden/src/sound/LADSPAPluginFactory.cpp:504


  And this is not unusual.  Unfortunately, if there are problems with 
plugins, rg does little to protect itself against them crashing.  We 
have a bug on our bug tracker related to this:


  https://sourceforge.net/p/rosegarden/bugs/1474/

  Not sure anyone will get around to fixing it, though.  And 
regardless, we can't really fix this issue.  The problem is actually in 
the fluidsynth-dssi.so plugin that we are trying to load:


#8  _dl_new_object (realname=realname@entry=0x7fffb014e0a0 
"/usr/lib/dssi/fluidsynth-dssi.so", libname=libname@entry=0x7fffb0153ab8 
"/usr/lib/dssi/fluidsynth-dssi.so",
type=type@entry=2, loader=loader@entry=0x0, 
mode=mode@entry=-1879048190, nsid=nsid@entry=0) at dl-object.c:89


  So fluidsynth's dssi plugin is the next place to look.  Of course, 
once again, the issue might actually be caused by something fluidsynth 
brings in.



BTW, this error only occurs on my laptop running Debian bookworm.
On my (dual boot) desktop, rosegarden works fine both under KDE neon
and EndeavourOS, using pipewire 0.3.48.


  Not surprising.  Could be a config difference, or something subtle 
about library versioning.


  I'm going to add some logging to help diagnose this in the future. 
This isn't the first time this has been an issue.  It would be nice to 
know exactly what is going on immediately.


  Thanks for the bug report.rainer@Freya:~$ gdb /usr/local/bin/rosegarden
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/rosegarden...
(gdb) run
Starting program: /usr/local/bin/rosegarden 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7145e640 (LWP 4384)]
[New Thread 0x7fffeac7a640 (LWP 4385)]
[main] System Locale: "en_AU"
[main] Qt translations path:  "/usr/share/qt5/translations"
[main] Qt translations loaded successfully.
[main] RG Translation: trying to load :locale/ "en_AU"
[main] RG Translations loaded successfully.
[main] Loaded application icon " "rg-rwb-rose3-16x16" "
[main] Loaded application icon " "rg-rwb-rose3-32x32" "
[main] Loaded application icon " "rg-rwb-rose3-48x48" "
[main] Loaded application icon " "rg-rwb-rose3-64x64" "
[main] Loaded application icon " "rg-rwb-rose3-128x128" "
[main] Unbundling examples...
[main] Unbundling templates...
[main] Unbundling libraries (device files)...
[New Thread 0x7fffdae94640 (LWP 4386)]
[New Thread 0x7fffda693640 (LWP 4387)]
[New Thread 0x7fffd9e92640 (LWP 4388)]
[New Thread 0x7fffd9691640 (LWP 4389)]
[New Thread 0x7fffd8e90640 (LWP 4390)]
[New Thread 0x7fffc3fff640 (LWP 4391)]
[New Thread 0x7fffbbfff640 (LWP 4392)]
[main] Creating RosegardenMainWindow instance...
[New Thread 0x7fffc2dee640 (LWP 4393)]
[SequencerThread] run()
[New Thread 0x7fffc25ed640 (LWP 4394)]
[PluginFactory] PluginFactory::instance( "dssi" ): creating new 
DSSIPluginFactory
[JackDriver] initialise() begin...
[New Thread 0x7fffc1dbd640 (LWP 4395)]
[New Thread 0x7fffc15bc640 (LWP 4396)]
[JackDriver] initialise() - JACK sample rate =  48000 Hz, buffer size =  1024
[JackDriver] initialise() - creating disk thread...
[New Thread 0x7fffd84e7640 (LWP 4397)]
[JackDriver] initialise() - found  9  JACK physical outputs
[JackDriver] initialise() - connecting from  " rosegarden:master out L " to " 
Tiger Lake-LP Smart Sound Technology Audio Controller Speaker + 
Headphones:playback_FL "
[JackDriver] initialise() - connecting from  " rosegarden:master out R " to " 
Tiger Lake-LP Smart Sound Technology Audio Controller Speaker + 
Headphones:playback_FR "
[JackDriver] initialise() - found  5  JACK physical inputs
[JackDriver] initialise() - connecting from  " Tiger Lake-LP Smart Sound 
Technology Audio Controller Digital Microphone:capture_FL " to " 
rosegarden:record in 1 L "
[JackDriver] initialise() - connecting from  " Tiger L

Bug#1007103: Further information

[Ted Felix]

malloc_consolidate(): unaligned fastbin chunk detected Aborted


  We've not seen this upstream.  Best bet would be to do a debug build 
from source and run under gdb.  Then do a backtrace when it crashes. 
That should help us determine whether it is Rosegarden or one of the 
many libraries it pulls in.  Let me know if you need help with this and 
I'll point you to the relevant pages on our wiki.

Bug#975143: rosegarden: FTBFS: Panner.cpp:138:18: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

[Ted Felix]

On 11/19/20 4:37 AM, Lucas Nussbaum wrote:

During a rebuild of all packages in sid, your package failed to build
on amd64.

/<>/src/gui/widgets/Panner.cpp:138:18: error: aggregate 
‘QPainterPath path’ has incomplete type and cannot be defined


  This was fixed in r15845 upstream:

https://sourceforge.net/p/rosegarden/code/15845/

  Patch attached.

Ted.
>From bdb6c75b733d4868e350af4baeeb15e309c7b62a Mon Sep 17 00:00:00 2001
From: Ted Felix 
Date: Tue, 16 Jun 2020 00:48:04 -0400
Subject: [PATCH] Fix QPainterPath compilation error

---
 src/gui/general/ThornStyle.cpp | 1 +
 src/gui/widgets/Panner.cpp | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/gui/general/ThornStyle.cpp b/src/gui/general/ThornStyle.cpp
index 43746078..de426f1a 100644
--- a/src/gui/general/ThornStyle.cpp
+++ b/src/gui/general/ThornStyle.cpp
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/src/gui/widgets/Panner.cpp b/src/gui/widgets/Panner.cpp
index ceba4eae..ead23faf 100644
--- a/src/gui/widgets/Panner.cpp
+++ b/src/gui/widgets/Panner.cpp
@@ -24,6 +24,7 @@
 #include "misc/Debug.h"
 #include "base/Profiler.h"
 
+#include 
 #include 
 #include 
 
-- 
2.25.1

Bug#904717: rosegarden "Tie Notes at Barlines" has no effect on some imported MIDI

[Ted Felix]

Confirmed.  This is likely working as designed.

In the Bass_sample.mid case, the note beginnings have been quantized, 
but the note durations have not been quantized.  Rosegarden seems to 
prefer exact note durations when doing ties.  If you double-click the 
note that you want to tie and set its duration to a dotted quarter, you 
can then tie across the barline.


It may be possible to improve this, but I'm not the one to ask.  I 
recommend closing this bug and starting a discussion on the upstream 
rosegarden-user mailing list:


https://sourceforge.net/projects/rosegarden/lists/rosegarden-user

Look forward to seeing you there.

Bug#933230: acpid: Race during startup can result in event devices not being opened

[Ted Felix]

On 7/27/19 4:21 PM, ano...@users.sourceforge.net wrote:

The attached patch...


Patch has been applied and pushed.  Test upstream at:

  https://sourceforge.net/p/acpid2/code/ci/master/tree/

Planning a release for 8/15 or 9/15.  Thanks again.

Bug#933230: acpid: Race during startup can result in event devices not being opened

[Ted Felix]

On 7/27/19 4:21 PM, ano...@users.sourceforge.net wrote:

On my system, this race happens frequently for /dev/input/event8 "Video
Bus" during boot, preventing acpid from handling my system's brightness
keys.


  Thanks for the patch.  I've posted the patch and this report upstream:

https://sourceforge.net/p/acpid2/tickets/18/

  Probably will do a new release with this in a month or so.

Bug#909399: kacpimon handles not more than 20 connections

[Ted Felix]

On 11/6/18 7:24 PM, Ted Felix wrote:

Will be included in the 2.0.31 release on November 15 or so.


  A new upstream version (2.0.31) is now available that addresses this 
issue.


https://sourceforge.net/projects/acpid2/files/

Bug#909399: kacpimon handles not more than 20 connections

[Ted Felix]

On 9/22/18 6:55 PM, zieg...@uni-freiburg.de wrote:

starting kacpimon fails because of "too many connections".


  I've bumped the limit from 20 to 100.  See upstream commit [9bc1579]:

https://sourceforge.net/p/acpid2/code/ci/9bc15796a5aed24719312a1505eb5d09965eef4d/

  Will be included in the 2.0.31 release on November 15 or so.

Bug#909399: kacpimon handles not more than 20 connections

[Ted Felix]

  Ah, now I get it.  It's kacpimon that is failing.  That's just a 
debugging tool.  I wouldn't even classify this as "important".  "minor" 
or "wishlist" at best.


  kacpimon is still using the older version of connection_list.c.  It's 
a bit of a mess.  And that one still has a 20 connection limit.  Should 
be fixable by upgrading that file, assuming it's compatible with the 
rest of kacpimon.  Or you can just jack MAX_CONNECTIONS up to 1024.  I 
really should fix this properly one day.


Ted.

Bug#909399: kacpimon handles not more than 20 connections

[Ted Felix]

On 09/22/2018 06:55 PM, zieg...@uni-freiburg.de wrote:

Version: 1:2.0.28-1+b1


  This is odd since this exact problem was fixed in 2.0.20.  It was 
fixed in response to #719659.  As a result, we should be able to handle 
1024 connections.  Do we somehow have a regression?  Or was this not 
properly tested back in 2.0.20?


  I'll have a closer look.

Ted.

Bug#808015: acpid: FTBFS: libnetlink.c:497:54: error: comparison between signed and unsigned integer expressions

[Ted Felix]

On 12/15/2015 11:19 AM, Chris Lamb wrote:

Yep, works great. (Both in ./libnetlink.c and ./kacpimon/libnetlink.c)


  Ok, this should be fixed upstream in [32f291].

https://sourceforge.net/p/acpid2/code/ci/32f291

  I'll do an official release 1/15/2016.  Unless you'd like it sooner.

Ted.

Bug#808015: acpid: FTBFS: libnetlink.c:497:54: error: comparison between signed and unsigned integer expressions

[Ted Felix]

On 12/15/2015 06:00 AM, Chris Lamb wrote:

acpid fails to build from source in unstable/amd64:
   libnetlink.c: In function 'addattr_l':
   libnetlink.c:497:54: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
 if ((int)NLMSG_ALIGN(n->nlmsg_len) + RTA_ALIGN(len) > maxlen) {
 ^
   libnetlink.c: In function 'rta_addattr32':
   libnetlink.c:527:36: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
 if (RTA_ALIGN(rta->rta_len) + len > maxlen) {
   ^
   libnetlink.c: In function 'rta_addattr_l':
   libnetlink.c:545:47: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
 if (RTA_ALIGN(rta->rta_len) + RTA_ALIGN(len) > maxlen) {
  ^


  As it is, it's building fine for me.  I assume I have an older 
rtnetlink.h.


  The common thread here is RTA_ALIGN().  My guess is that it's now 
returning an unsigned.  Adding an (int) to each one should fix it.  E.g.:


if ((int)RTA_ALIGN(rta->rta_len) + len > maxlen) {

  Give it a try and let me know.  If it works, I'll get it in upstream.

Ted.

Bug#773329: Upstream fix

[Ted Felix]

  This has now been fixed upstream in Rosegarden.  The relevant commits 
are r13910 and r13911.


https://sourceforge.net/p/rosegarden/code/13910/
https://sourceforge.net/p/rosegarden/code/13911/

Ted.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#773329: Incorrect Cflags line in jack.pc

[Ted Felix]

On 04/19/2015 09:10 AM, Adrian Knoth wrote:

The cflags from pkg-config for jack are incorrect which breaks makefiles
and configure scripts that depend on them (e.g. those for rosegarden).

I tend to disagree - more likely, rosegarden is broken, because a ton of
other software that relies on jackd compiles just fine.


  It appears that the issue is that rosegarden is using 
PKG_CHECK_MODULES() when it should be using AC_CHECK_LIB().  I just 
tried AC_CHECK_LIB() and it works fine.  I'll get it into the next 
release of rosegarden.



   Cflags: -I/usr/include

...should be this:

   Cflags: -I${includedir} -I${includedir}/jack

No, -I/usr/include is correct, because the appropriate include is

#include 


  I thought this too, but actually the issue is a quirk in the way 
pkg-config works.  The Cflags line in the .pc file has to follow a very 
specific and strange format (shown above) for PKG_CHECK_MODULES() to 
work.  It's really quite bizarre and perplexing.  AC_CHECK_LIB() is much 
more reliable.



So wontfix?


  I agree.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#773329: Incorrect Cflags line in jack.pc

[Ted Felix]

Package: libjack-jackd2-dev
Version: 1.9.10+20140719git3eb0ae6a~dfsg-2

The cflags from pkg-config for jack are incorrect which breaks makefiles 
and configure scripts that depend on them (e.g. those for rosegarden).


The culprit is the Cflags line at the end of 
/usr/lib/x86_64-linux-gnu/pkgconfig/jack.pc.  This:


  Cflags: -I/usr/include

...should be this:

  Cflags: -I${includedir} -I${includedir}/jack

This problem is present in both jessie and sid.  I didn't check wheezy 
or prior.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#766991: acpid: does not process events

[Ted Felix]

On 10/27/2014 09:05 AM, Norbert Preining wrote:

The reason is that acpid is not started automatically anymore, but
some systemd tells me that something about socket activation etc.


  I've not used systemd yet, but I'm pretty sure acpid works fine when 
the socket is sent in as the stdin fd (or something along those lines, 
there was a patch made to acpid to allow it to work with its socket sent 
in via a fd for the systemd folks).


  I would recommend comparing your acpid.service file with Fedora's:

http://pkgs.fedoraproject.org/cgit/acpid.git/tree/acpid.service

  Then have a look at this bug report on the acpid2 page:

http://sourceforge.net/p/acpid2/tickets/3/

  Just some thoughts.  Hopefully some of this helps you out.  Again, 
I've not used systemd yet, so I'm of limited help.  Let us know if any 
of this helps you out and what changes you had to make to the config 
files so we can get the changes into Debian.


Thanks for the bug report.
Ted.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752283: acpid: thinkpad t400s, suspend when LID closed stopped working

[Ted Felix]

On 06/22/2014 02:47 AM, Gijs Hillenius wrote:

Sometime following a recent update, closing the lid of this
Thinkpad T400s no longer suspends.


  This is not likely to be an acpid issue.  It could be a window 
manager issue, an acpi-support issue, or a kernel issue.  Here are some 
things to try:


1. Try using kacpimon to verify that lid close/open events are coming 
in.  See the man page for kacpimon.  If the events aren't coming in, 
you've got a kernel issue.


2. If you've got lid close/open events coming in, then you'll need to 
check and see if your window manager is responsible for handling lid 
open/close.  Some are, some aren't.  If yours is, and you've got it 
configured properly, then you may have a window manager issue.


3. Lastly, take a look in /etc/acpi/events (see the man page for acpid 
for more info).  Is there a lid closed configuration file in there (e.g. 
/etc/acpi/events/lidbtn)?  Is it properly connected to a script (e.g. 
/etc/acpi/lid.sh)?  Is that script working?  If there is a broken script 
or config file in here, then you've likely got an acpi-support issue.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#732277: Option for acpid to drop certain events completely

[Ted Felix]

On 12/16/2013 04:03 AM, Pigeon wrote:

event=battery.*
action=DIEDIEDIE


  Thanks for the patch.  I will review it today.  It sounds like an 
interesting feature.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#719659: acpid 2.0.20 released

[Ted Felix]

  This has been fixed in acpid 2.0.20 just released today.

http://sourceforge.net/projects/acpid2


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#719659: Full fix available

[Ted Felix]

  The full fix for this is now available in the git repo on sourceforge.

http://sourceforge.net/projects/acpid2/

  It now expands the connection list in increments of 20 connections as 
needed up to 1024.  add_connection() also has better error handling, so 
problems in there will now be logged.


  Any testing anyone can do would be appreciated.

  Unless the Debian folks need it sooner, I think I will shoot for the 
usual September 15 release date for this.  Let me know what you would 
prefer.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#719659: acpid ignores its unix socket on systems with many event interfaces

[Ted Felix]

On 08/13/2013 10:42 PM, Ben Winslow wrote:

The simplest
fix would be simply raising MAX_CONNECTIONS in connection_list.c


Thanks (again) for the bug report.  I've just pushed a quick fix to the
sourceforge repo with MAX_CONNECTIONS bumped to 100.  I will pursue a
more satisfactory solution next.  Here's the patch in case anyone needs
it immediately:

commit 903271fb387ad4cc630c29810eecaacfb3e21080
Author: Ted Felix 
Date:   Wed Aug 14 19:02:33 2013 -0400

Increase MAX_CONNECTIONS to 100

This is an interim fix for Debian 719659.

diff --git a/connection_list.c b/connection_list.c
index 0fc7c53..cf99162 100644
--- a/connection_list.c
+++ b/connection_list.c
@@ -35,7 +35,7 @@
 /*---*/
 /* private objects */

-#define MAX_CONNECTIONS 20
+#define MAX_CONNECTIONS 100

 static struct connection connection_list[MAX_CONNECTIONS];


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#701234: Elevation to "serious" - acpid 2.0.19

[Ted Felix]

  I just released acpid 2.0.19 in response to the elevation to 
"serious" severity.  It should fix the compilation issue.


Ted.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#701206: acpid: Mic mute button on Thinkpad X230 is not recognized

[Ted Felix]

On 04/24/2013 10:19 AM, Marek Elias wrote:

I did the changed you suggested and rebuilt the acpid package.
Now I can see the events and run scripts with it.


  I just added this change to the official source.  If you wouldn't 
mind retesting with the official source, I'd appreciate it.  You can 
find the sf git repo here:


http://sourceforge.net/p/acpid2/code/ci/master/tree/

  Let me know if it works.  Thanks.

Ted.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#701206: acpid: Mic mute button on Thinkpad X230 is not recognized

[Ted Felix]

On 04/24/2013 10:19 AM, Marek Elias wrote:

I did the changed you suggested and rebuilt the acpid package.
Now I can see the events and run scripts with it.


  Great.  Then I'll go ahead and add the lines to the official source. 
 It will appear in the next version.  Since there haven't been any 
major changes lately, that might be a while off.


Ted.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#701206: acpid: Mic mute button on Thinkpad X230 is not recognized

[Ted Felix]

On 04/24/2013 04:21 AM, Marek Elias wrote:

Input Layer:  Type: 1  Code: 28  Value: 0


  That's the Enter key.  Nothing to worry about.


Input Layer:  Type: 1  Code: 248  Value: 1


  This is "KEY_MICMUTE".  That can easily be added to acpid by adding 
the following lines to input_layer.c:


   {{{0,0}, EV_KEY, KEY_MICMUTE, 1},
  "button/micmute MICMUTE 0080 "},

  Add them to the "/*** AUDIO ***/" section.  Rebuild and try it. 
acpid should receive mic mute events.  This doesn't mean it will do 
anything with them.  You'll need to add a config file and a script to 
make something useful happen.  See the man page.


  If this works and you find this helpful, let me know and I'll include 
this change in the next release.


  If you just wanted the mic mute button to work in your window manager 
(e.g. Gnome or KDE), then it's best to get them to support these 
keys/buttons.  acpid is geared more towards those who are not running a 
window manager (servers).  You can still use it for this, but it's not 
really the best solution.


> The led inside mic mute button also does not switch on/off. This works
> fine for normal mute button.

  Your script for acpid will need to turn the light on and off.  Most 
likely, your window manager is doing this already for the mute button, 
but it is not aware of the mic mute button and the LED.


Ted.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#701206: acpid: Mic mute button on Thinkpad X230 is not recognized

[Ted Felix]

On 02/22/2013 10:00 PM, Yevgeny Kosarzhevsky wrote:

when I run acpi_listen and press MicMute button I get only ^@ output, no codes 
recognized.


  What does kacpimon report for that button?  You'll need to kill acpid 
for kacpimon to work.  Check the man page for more.


Ted.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#642227: WARNING: SegmentNotationHelper::makeNoteViable(): No valid split for event

[Ted Felix]

  Thanks for the bug report.

  r12743 (Jan 8, 2012) of rosegarden fixes a similar bug.  If you can 
attach a sample MIDI file that causes the problem, I can test it against 
the latest source.


Ted.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664705: acpid: weird socket permissions

[Ted Felix]

  Patch to 2.0.15 attached.  This fixes the fchmod() issue and should 
give the correct permissions.


  The "-g" option was a bit more tricky to fix.  I ended up having to 
go back to chown() and that seems to work ok.  No matter where I put 
fchown(), it just didn't work.


  If you can give it some testing, I would appreciate it.  I'll shoot 
for an early (perhaps 3/27) release of 2.0.16 with this fix.


Ted.
diff --git a/sock.c b/sock.c
index bd7c32d..dd69e3d 100644
--- a/sock.c
+++ b/sock.c
@@ -111,20 +111,13 @@ open_sock()
/* ??? Move CLOEXEC and NONBLOCK settings below up to here? */
} else {
/* create our own socket */
-   fd = ud_create_socket(socketfile);
+   fd = ud_create_socket(socketfile, socketmode);
if (fd < 0) {
acpid_log(LOG_ERR, "can't open socket %s: %s",
socketfile, strerror(errno));
exit(EXIT_FAILURE);
}
 
-   if (fchmod(fd, socketmode) < 0) {
-   close(fd);
-   acpid_log(LOG_ERR, "chmod() on socket %s: %s", 
-   socketfile, strerror(errno));
-   return;
-   }
-
/* if we need to change the socket's group, do so */
if (socketgroup) {
struct group *gr;
@@ -140,7 +133,11 @@ open_sock()
socketfile, strerror(errno));
exit(EXIT_FAILURE);
}
-   if (fchown(fd, buf.st_uid, gr->gr_gid) < 0) {
+   /* ??? I've tried using fchown(), however it doesn't 
work here.
+* It also doesn't work before bind().  The GNU 
docs seem to
+* indicate it isn't supposed to work with sockets. 
*/
+   /* if (fchown(fd, buf.st_uid, gr->gr_gid) < 0) { */
+   if (chown(socketfile, buf.st_uid, gr->gr_gid) < 0) {
acpid_log(LOG_ERR, "can't chown %s: %s", 
socketfile, strerror(errno));
exit(EXIT_FAILURE);
diff --git a/ud_socket.c b/ud_socket.c
index c3eb337..d9ab565 100644
--- a/ud_socket.c
+++ b/ud_socket.c
@@ -23,7 +23,7 @@
 #include "ud_socket.h"
 
 int
-ud_create_socket(const char *name)
+ud_create_socket(const char *name, mode_t socketmode)
 {
int fd;
int r;
@@ -46,6 +46,16 @@ ud_create_socket(const char *name)
return fd;
}
 
+   /* Clear the umask to guarantee predictable results from fchmod(). */
+   umask(0);
+
+   if (fchmod(fd, socketmode) < 0) {
+   close(fd);
+   acpid_log(LOG_ERR, "fchmod() on socket %s: %s",
+   name, strerror(errno));
+   return -1;
+   }
+
/* setup address struct */
memset(&uds_addr, 0, sizeof(uds_addr));
uds_addr.sun_family = AF_UNIX;
diff --git a/ud_socket.h b/ud_socket.h
index a59db95..46a2189 100644
--- a/ud_socket.h
+++ b/ud_socket.h
@@ -8,7 +8,7 @@
 #include 
 #include 
 
-int ud_create_socket(const char *name);
+int ud_create_socket(const char *name, mode_t socketmode);
 int ud_accept(int sock, struct ucred *cred);
 int ud_connect(const char *name);
 int ud_get_peercred(int fd, struct ucred *cred);

Bug#664705: acpid: weird socket permissions

[Ted Felix]

On 3/19/2012 9:18 PM, Salvo Tomaselli wrote:

after the upgrade
srwxr-xr-x 1 root root 0 mar 20 02:15 /var/run/acpid.socket

before the upgrade
srw-rw-rw- 1 root root 0 mar 20 02:15 /var/run/acpid.socket


Thanks for the bug report.

I've verified this and should have a fix by the end of the day.  Turns 
out that fchmod() and fchown() must be called prior to bind() on a 
socket.  A little code-shuffling should fix the problem.  I plan on 
moving the fchmod() and fchown() related code into ud_create_socket() 
and adding perm and group args.


Note that the -g option is also broken because of this.

Ted.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#663249: [Pkg-acpi-devel] Bug#663249: acpid: fcntl(fd, F_SETFD, O_NONBLOCK) should be fcntl(fd, F_SETFL, O_NONBLOCK)

[Ted Felix]

On Mon, Mar 12, 2012 at 10:28:14PM +0100, Luciano Bello wrote:
> Is it a security problem?

  Given that F_SETFD != F_SETFL, I would say that this is a security 
problem.  A userspace program can cause acpid to stop processing by 
blocking on a socket.


Ted.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#656676: acpi_listen(8) manpage has pointless See Also section

[Ted Felix]

On 1/20/2012 3:42 PM, Adam Heath wrote:
See Also in a manpage should provide useful links.  Maybe one pointed 
at acpid(8).


  Thanks for the bug report.

  This has been done in my local version.  It will appear in the next 
release of acpid (2.0.15).  In the meantime, a patch is attached that 
can be used to close this bug.


Ted.
diff --git a/acpi_listen.8 b/acpi_listen.8
index 43e95a7..d97efae 100644
--- a/acpi_listen.8
+++ b/acpi_listen.8
@@ -38,8 +38,10 @@ Show help and exit.
 .SH BUGS
 There are no known bugs.  To file bug reports, see \fBAUTHORS\fP below.
 .SH SEE ALSO
-regcomp(3), sh(1), socket(2), connect(2)
+acpid(8)
 .SH AUTHORS
+Ted Felix (www.tedfelix.com)
+.br
 Tim Hockin 
 .br
 Luca Capello 

Bug#656675: acpid(8) manpage mentions /proc/acpi/event

[Ted Felix]

On 1/20/2012 3:39 PM, Adam Heath wrote:
The manpage for acpid(8) mentions /proc/acpi/event.  That file doesn't 
exist in 3.2(probably 3.1, maybe others).  I'm guessing that the file 
hasn't actually existed for a large number of kernel revisions.


Since debian is going to be shipping a 3.x kernel, please modify the 
manpage to describe modern kernels


  Thanks for the bug report.

  The man page explains what happens if the /proc/acpi/events file does 
not exist:


"If the events file does not exist, acpid will attempt to connect to the
Linux kernel via the input layer and netlink."

So the man page covers both old and modern kernels.

  Michael, I recommend closing this.

Ted.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#635219: acpid: excessive power script invocation

[Ted Felix]

On 7/23/2011 6:34 PM, Samuel Thibault wrote:
> Shouldn't acpid somehow avoid calling the same script for the same 
event over and over?


  acpid's only purpose is to call scripts in response to acpi events.  
It is up to the script to avoid doing unnecessary things that result in 
writing to the console.  I think in this case, the script should detect 
that it is being called rapidly and decide what is best.  E.g. if it 
hasn't been called in the last 5 seconds, perhaps try what it needs to 
do again.  Or something similar.


Ted.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#620387: [Pkg-acpi-devel] Bug#620387: acpid: Keys Fn-F1 to Fn-F9 (vol mute, vol down, vol up, screen switch, bright up/down)

[Ted Felix]

On 4/5/2011 12:41 AM, Hannes Calitz wrote:
> It seems the only problem is
> detecting the hotkeys on F1 to F9. Maybe then not an acpi problem but
> rather a hal or xorg problem?

  Usually, this is a kernel driver issue.  It's easy to eliminate acpid 
as the cause simply by running a window manager that disables acpid, but 
handles the hotkeys.  If you are running GNOME, then acpid is not involved.


  To check and see whether the kernel is sending any events at all, use 
the kacpimon utility.  The man page for kacpimon explains how to use 
it.  And I believe Debian installs kacpimon along with acpid.  (Correct 
me if wrong, Michael.)


Ted.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#620387: acpid: Keys Fn-F1 to Fn-F9 (vol mute, vol down, vol up, screen switch, bright up/down)

[Ted Felix]

  Are you running a window manager like KDE, GNOME, Xfce... when this 
happens?


Ted.

On 4/1/2011 12:01 PM, HCalitz wrote:

Package: acpid
Version: 1:2.0.8-3
Severity: normal


The Fn-F1 to Fn-F9 keys does not work anymore.  They used to work fine until 
the last update.
There may be a problem with the fan as well, I am not sure, as the computer 
runs hotter than normal.

Lenovo Thinkpad Edge 15"

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages acpid depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared lib
ii  lsb-base  3.2-27 Linux Standard Base 3.2 init scrip
ii  module-init-tools 3.12-1 tools for managing Linux kernel mo

Versions of packages acpid recommends:
ii  acpi-support-base 0.138-8scripts for handling base ACPI eve

acpid suggests no packages.

-- Configuration Files:
/etc/default/acpid changed:
MODULES="all"


-- no debconf information





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#600564: add support for more buttons

[Ted Felix]

   Thanks for this.  I'll get it into my next release.

Ted.

On 10/18/2010 4:18 AM, Stanislav Maslovski wrote:

Package: acpid
Version: 1:2.0.6-1
Severity: wishlist
Tags: upstream patch

Hello,

I think that it is reasonable to add support for the very common CD
play/pause and related buttons found on many notebooks, as acpid
already reacts to the volume control buttons and video buttons. This
will help to keep the number of running daemons at the minimum in
minimalistic setups (there is esekeyd, but it is quite primitive and
not very reliable because it does not monitor the changes in
/dev/input/).

I attach a very simple patch to achieve this. I placed the CD buttons
in a separate "category": cd/*, so that their events will not
interfere with other button events, but this can be changed, of course.

--
Stanislav




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#598198: acpid: superfluous logging

[Ted Felix]

   Try the attached patch.
diff -N -r -U 10 -x '*.o' -x '*~' -x '.*' -x '*.out' -x CVS -x '*.moc' 
acpid-2.0.6/event.c acpid/event.c
--- acpid-2.0.6/event.c 2010-03-28 10:00:04.0 -0400
+++ acpid/event.c   2010-09-27 18:26:48.0 -0400
@@ -115,20 +115,26 @@
}
 
/* scan all the files */
while ((dirent = readdir(dir))) {
int len;
struct rule *r;
struct stat stat_buf;
 
len = strlen(dirent->d_name);
 
+   /* skip "." and ".." */
+   if (strncmp(dirent->d_name, ".", sizeof(dirent->d_name)) == 0)
+   continue;
+   if (strncmp(dirent->d_name, "..", sizeof(dirent->d_name)) == 0)
+   continue;
+
/* skip any files that don't match the run-parts convention */
if (regexec(&preg, dirent->d_name, 0, NULL, 0) != 0) {
acpid_log(LOG_INFO, "skipping conf file %s/%s\n", 
confdir, dirent->d_name);
continue;
}
 
/* Compute the length of the full path name adding one for */
/* the slash and one more for the NULL. */
len += strlen(confdir) + 2;
diff -N -r -U 10 -x '*.o' -x '*~' -x '.*' -x '*.out' -x CVS -x '*.moc' 
acpid-2.0.6/proc.c acpid/proc.c
--- acpid-2.0.6/proc.c  2010-03-28 10:02:42.0 -0400
+++ acpid/proc.c2010-09-27 18:30:28.0 -0400
@@ -81,21 +81,21 @@
 
 int
 open_proc()
 {
int fd;
struct connection c;

fd = open(eventfile, O_RDONLY);
if (fd < 0) {
if (errno == ENOENT) {
-   acpid_log(LOG_INFO, "Deprecated %s was not found.  "
+   acpid_log(LOG_DEBUG, "Deprecated %s was not found.  "
"Trying netlink and the input layer...\n", 
eventfile);
} else {
acpid_log(LOG_ERR, "can't open %s: %s (%d)\n", 
eventfile, 
strerror(errno), errno);
}
return -1;

}
fcntl(fd, F_SETFD, FD_CLOEXEC);
 

Bug#574848: [Pkg-acpi-devel] Bug#574848: acpid fails to notice button reload

[Ted Felix]

> My power button stops working after resume from suspend due to some 
kernel issue.
> To work around this issue I reload the button module in my suspend 
script and after reloading the module kacpimon shows events from the button.

> However, acpid still does not react to the button until restarted.

 Are you still having trouble with this?

 If so, here's an idea.  Try killing acpid

   sudo killall acpid

then running it in debug mode at the console.

   sudo /usr/sbin/acpid -d

 Now suspend and resume.  In debug mode, acpid should print a bunch of 
informational messages that might be of some help in tracking down why 
it is getting confused.  Post the output here and perhaps there will be 
something in there that might lead to a solution.


 I was able to stop and restart the button module and observe the 
correct behavior from acpid.  It looks like this:


 sudo /sbin/rmmod button

acpid: input device has been disconnected
acpid: input device has been disconnected
acpid: input device has been disconnected

 sudo /sbin/modprobe button

inotify read bytes: 32
inotify name len: 16
inotify about to open: /dev/input/event4
input layer /dev/input/event4 opened successfully
inotify read bytes: 32
inotify name len: 16
inotify about to open: /dev/input/event3
input layer /dev/input/event3 opened successfully
inotify read bytes: 32
inotify name len: 16
inotify about to open: /dev/input/event2
input layer /dev/input/event2 opened successfully

 So, it appears to work for me.

Ted.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#565908: acpid: causes Xorg to hang because of "too many connections"

[Ted Felix]

 Thanks for the patch.  It looks good and appears to work for me.  I'll 
get it into my next build, 2.0.2 scheduled for 2/15.


Ted.

Willi Mann wrote:

Ted Felix schrieb:
  

 If you don't mind grabbing the code and building it, you can go into
the file connection_list.c and change this line:

#define MAX_CONNECTIONS 10

 To this:

#define MAX_CONNECTIONS 20

 That will get rid of the "Too many connections." message in the log. 
Whether it will solve your problem, I'm not sure.  I will include this

change in my next monthly release on 2/15.  Let me know if you need more
info.



I've just found a more reliable way to reproduce this problem: Simply
switch 10 times between the X session and a console.

However, changing MAX_CONNECTIONS to 20 solves the problem - I tried to
switch more than 20 times and the problem did not reappear.

Attached is a patch that, apart from changing MAX_CONNECTIONS,
recalculates highestfd in delete_connection. I wrote that patch because
I first thought that this might be the source of the problem, but it
isn't. But it might be useful anyway.

WM
  




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#565908: acpid: causes Xorg to hang because of "too many connections"

[Ted Felix]

 If you don't mind grabbing the code and building it, you can go into 
the file connection_list.c and change this line:


#define MAX_CONNECTIONS 10

 To this:

#define MAX_CONNECTIONS 20

 That will get rid of the "Too many connections." message in the log.  
Whether it will solve your problem, I'm not sure.  I will include this 
change in my next monthly release on 2/15.  Let me know if you need more 
info.


Ted.

Willi Mann wrote:

Package: acpid
Version: 1:2.0.0-1
Severity: important

My machine is up since 5 days with about 10 hibernate sessions since that time 
- I could look at the logs to get the exact number.


After hibernate (uswsusp), the X Server hangs. That means, I just got the 
message
from s2disk on the otherwise black screen, and the input devices do not work 
at all, especially no Strg+Alt+Fn. 


So I logged in via ssh and got the following backtrace from the Xorg process:

 bt
#0  0xb77c4424 in __kernel_vsyscall ()
#1  0xb7775241 in connect () at ../sysdeps/unix/sysv/linux/i386/socket.S:61
#2  0x0814cdfa in ?? ()
#3  0x0814c17d in xf86OSPMOpen ()
#4  0x080b187c in xf86Wakeup ()
#5  0x0808a332 in WakeupHandler ()
#6  0x080a0b7a in WaitForSomething ()
#7  0x08073dc0 in ?? ()
#8  0x0806695a in _start ()

I had a similar problem about 2 weeks ago where I was able to see that it tried
to connect to the acpi daemon. Don't ask me how it found that out.

So I restarted the acpid daemon. Immediately, the X session was back and 
usable again. I looked in the syslog and found:


# grep -i acpi /var/log/syslog
Jan 19 12:46:27 host kernel: [217227.741166] ACPI: \_SB_.GDCK - undocking
Jan 19 16:06:35 host kernel: [217231.089455] ACPI handle has no context!
Jan 19 16:06:35 host kernel: [217231.089540] ACPI handle has no context!
Jan 19 16:06:35 host kernel: [217231.090598] ACPI handle has no context!
Jan 19 16:06:35 host kernel: [217231.090609] ACPI handle has no context!
Jan 19 16:06:35 host kernel: [217231.112136] ACPI handle has no context!
Jan 19 16:06:35 host kernel: [217231.464618] e1000e :00:19.0: wake-up 
capability enabled by ACPI
Jan 19 16:06:35 host kernel: [217231.996060] uhci_hcd :00:1a.0: power state 
changed by ACPI to D0
Jan 19 16:06:35 host kernel: [217232.004047] uhci_hcd :00:1a.2: power state 
changed by ACPI to D0
Jan 19 16:06:35 host kernel: [217232.012046] uhci_hcd :00:1d.0: power state 
changed by ACPI to D0
Jan 19 16:06:35 host kernel: [217232.660831] e1000e :00:19.0: wake-up 
capability disabled by ACPI
Jan 19 16:06:35 host kernel: [217233.041400] ata1.00: ACPI cmd 
ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
Jan 19 16:06:35 host kernel: [217233.041405] ata1.00: ACPI cmd 
f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
Jan 19 16:06:35 host kernel: [217233.041675] ata1.00: ACPI cmd 
ef/5f:00:00:00:00:a0 (SET FEATURES) succeeded
Jan 19 16:06:35 host kernel: [217233.041681] ata1.00: ACPI cmd 
ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
Jan 19 16:06:35 host kernel: [217233.044495] ata1.00: ACPI cmd 
ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
Jan 19 16:06:35 host kernel: [217233.044499] ata1.00: ACPI cmd 
f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
Jan 19 16:06:35 host kernel: [217233.044759] ata1.00: ACPI cmd 
ef/5f:00:00:00:00:a0 (SET FEATURES) succeeded
Jan 19 16:06:35 host kernel: [217233.044763] ata1.00: ACPI cmd 
ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
Jan 19 16:06:35 host kernel: [217233.446973] ata2.00: ACPI cmd 
e3/00:1f:00:00:00:a0 (IDLE) succeeded
Jan 19 16:06:35 host kernel: [217233.447775] ata2.00: ACPI cmd 
e3/00:02:00:00:00:a0 (IDLE) succeeded
Jan 19 16:06:35 host kernel: [217233.452712] ata2.00: ACPI cmd 
e3/00:1f:00:00:00:a0 (IDLE) succeeded
Jan 19 16:06:35 host kernel: [217233.453515] ata2.00: ACPI cmd 
e3/00:02:00:00:00:a0 (IDLE) succeeded
Jan 19 16:17:12 host acpid: exiting
Jan 19 16:17:13 host acpid: Too many connections.
Jan 19 16:17:13 host acpid: Too many connections.
Jan 19 16:17:13 host acpid: Too many connections.
Jan 19 16:17:13 host acpid: starting up with netlink and the input layer
Jan 19 16:17:13 host acpid: 47 rules loaded
Jan 19 16:17:13 host acpid: waiting for events: event logging is off

I may be able to provide more information, but the problem is that it requires 
some hibernating to actually reproduce this problem. (And I'm not sure if that's 
enough to reproduce the problem)


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages acpid depends on:
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  lsb-base  3.2-23 Linux Standard Base 3.2 init scrip
ii  module-init-tools 3.11-1 tools for managing Linux kernel mo

Bug#563343: acpid ignoring custom events if ends with '.sh'

[Ted Felix]

 Thanks for the bug report.

 This is working as designed.  acpid ignores any files with dots in 
their names.  ".sh" files aren't config files, they are shell scripts 
that are run by the config files.  Give your config files a name without 
a ".sh" then have the config file point to a shell script with the .sh 
in the name.


 See the latest man page for acpid for more details.

Ted.

Ritesh Raj Sarraf wrote:

Package: acpid
Version: 1:2.0.0-1
Severity: minor

I have added some custom events/actions to the acpid configuration. When I 
restart the daemon
so that it can read those additionanl events/actions, acpid complains that it 
will be
ignoring those custom events.

Mar  4 10:57:49 learner acpid: starting up with netlink and the input layer
Mar  4 10:57:49 learner acpid: ignoring conf file 
/etc/acpi/events/kill_shutdown.sh
Mar  4 10:57:49 learner acpid: parsing conf file /etc/acpi/events/lm_ac_adapter
Mar  4 10:57:49 learner acpid: parsing conf file /etc/acpi/events/lm_battery   
Mar  4 10:57:49 learner acpid: parsing conf file /etc/acpi/events/powerbtn-acpi-support
Mar  4 10:57:49 learner acpid: parsing conf file /etc/acpi/events/lm_lid   
Mar  4 10:57:49 learner acpid: ignoring conf file /etc/acpi/events/battery.sh  
Mar  4 10:57:49 learner acpid: 4 rules loaded  
Mar  4 10:57:49 learner acpid: waiting for events: event logging is on 
Mar  4 10:57:50 learner acpid: client connected from 1822[0:0] 
Mar  4 10:57:50 learner acpid: 1 client rule loaded
Mar  4 10:57:53 learner acpid: client connected from 1779[106:110] 
Mar  4 10:57:53 learner acpid: 1 client rule loaded
Mar  4 10:57:53 learner acpid: client connected from 1822[0:0] 
Mar  4 10:57:53 learner acpid: 1 client rule loaded
Mar  4 10:58:50 learner acpid: exiting 



r...@learner:~$ ls -l /etc/acpi/events/
total 24
-rw-r--r-- 1 root root 54 Mar  4 10:57 battery.sh
-rw-r--r-- 1 root root 59 Mar  4 10:57 kill_shutdown.sh
-rw-r--r-- 1 root root 61 Oct  8 16:13 lm_ac_adapter
-rw-r--r-- 1 root root 58 Oct  8 16:13 lm_battery
-rw-r--r-- 1 root root 58 Oct  8 16:13 lm_lid
-rw-r--r-- 1 root root 64 May 28  2009 powerbtn-acpi-support
r...@learner:~$ ls -l /etc/acpi/actions/
total 20
-rwxr-xr-x 1 root root  31 Mar  4 10:45 kill_shutdown.sh
-rwxr-xr-x 1 root root 111 Oct  8 16:13 lm_ac_adapter.sh
-rwxr-xr-x 1 root root 179 Oct  8 16:13 lm_battery.sh
-rwxr-xr-x 1 root root 125 Oct  8 16:13 lm_lid.sh
-rwxr-xr-x 1 root root  33 Mar  4 10:40 shutdown.sh



Renaming the events by removing the '.sh' from the name solves the problem.

Regards,
Ritesh


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages acpid depends on:
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  lsb-base  3.2-23 Linux Standard Base 3.2 init scrip
ii  module-init-tools 3.11-1 tools for managing Linux kernel mo

Versions of packages acpid recommends:
ii  acpi-support-base 0.130-1scripts for handling base ACPI eve

acpid suggests no packages.

-- no debconf information




  




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#560771: [Pkg-acpi-devel] Bug#560771: acpid: CVE-2009-4235: weak permissions on /var/log/acpid

[Ted Felix]

 Looks like the problem is in this line from open_logs():

logfd = open(logfile, O_WRONLY|O_CREAT|O_APPEND);

 It should be this:

logfd = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0640);

 And (theoretically, as I've not tested it) the problem is solved.

 As mentioned, this doesn't fix any existing log files that are hanging 
around, so maybe we need more code to destroy any old log file that has 
questionable permissions?  Is etch still even supported?  I'm not 
running etch, but if someone else is, perhaps they can test my releases?


 What would you like me to do?

Ted.

Raphael Geissert wrote:

2009/12/12 Michael Meskes :
  

On Fri, Dec 11, 2009 at 09:23:58PM -0600, Raphael Geissert wrote:


the following CVE (Common Vulnerabilities & Exposures) id was
published for acpid.

CVE-2009-4235[0]:
| acpid 1.0.4 sets an unrestrictive umask, which might allow local users
| to leverage weak permissions on /var/log/acpid, and obtain sensitive
| information by reading this file or cause a denial of service by
| overwriting this file, a different vulnerability than CVE-2009-4033.
  

This functonality was removed when going to version 1.0.6 which happened on
September 18th, 2007.



The vulnerability only seems to affect oldstable, but I noticed that none of
the versions remove the log file, so the permissions of the file need to be
fixed by all the other versions.
  

The file hasn't been used for more than 2 years and probably does not contain
sensible information at all. Anyway all information therein is probably
outdated. Shall we still release a new version deleting that file for
all versions?



The problem is not just the information it may (or not) contain, but
the file permissions.
If the file isn't removed, or the permissions corrected, it is
possible for a local user to fill the file until the partition runs
out of space. This could lead to missing log entries from other
daemons as there's no space left.

Cheers,
  




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org