acpid in 1.16.2 doesn't build on SLES 10.

Wed Jul 14 06:20:51 UTC 2010

On Wednesday 14 July 2010 00:07, Rob Landley wrote:
> By the way, I just dropped 1.17.0 into my build system and:
> 
>   CC      miscutils/rfkill.o
> miscutils/rfkill.c:10:26: error: linux/rfkill.h: No such file or directory
> miscutils/rfkill.c: In function 'rfkill_main':
> miscutils/rfkill.c:21: error: storage size of 'event' isn't known
> miscutils/rfkill.c:46: error: 'RFKILL_TYPE_ALL' undeclared (first use in this 
> function)
> miscutils/rfkill.c:46: error: (Each undeclared identifier is reported only once
> miscutils/rfkill.c:46: error: for each function it appears in.)
> miscutils/rfkill.c:65: error: 'RFKILL_EVENT_SIZE_V1' undeclared (first use in 
> this function)
> miscutils/rfkill.c:105: error: 'RFKILL_OP_CHANGE_ALL' undeclared (first use in 
> this function)
> miscutils/rfkill.c:110: error: 'RFKILL_OP_CHANGE' undeclared (first use in this 
> function)
> miscutils/rfkill.c:21: warning: unused variable 'event'
> 
> Doesn't like Ubuntu 9.04, I'm guessing.

I'd like to fix them all in 1.17.1. Do any other applets give you this trouble?

> > > So the group entry is hidden but the individual "Ext filesystem" and
> > > "btrfs filesystem" ones aren't, and I can't clean that up because I have
> > > no idea what you're trying to do with it.)
> >
> > CONFIG_VOLUMEID is used to enable compilation of common modules for
> > volume format/filesystem detection:
> >
> > lib-$(CONFIG_VOLUMEID) += volume_id.o util.o
> >
> > It is automatically turned on when used selects blkid, findfs or
> > FEATURE_MOUNT_LABEL, which makes FEATURE_VOLUMEID_foo options visible.
> > User does not really need to see VOLUMEID per se in menuconfig.
> 
> Yes, but makes them visible _where_?  Is the system-utilities menu (between 
> "more" and "linuxraid" really the appropriate place to stick this stuff?  At 
> the very least, there should be a sub-menu.  (And configuration options that 
> aren't attached to an applet general get segregated a bit from the Big Long 
> List of Applets.)

Yes. I didn't notice this ugliness since I never use menuconfig.
Please try this:

http://busybox.net/downloads/fixes-1.17.0/busybox-1.17.0-volumeid.patch

> > > So I'm out of the loop on acpi these days, and I dunno what acpid is
> > > actually doing.
> >
> > Me neither. I think it mimics "standard" one:
> > http://linux.die.net/man/8/acpid Looks like it's useful for things like:
> >
> > "Example
> >
> > This example - placed in /etc/acpi/events/power -
> > will shut down your system if you press the power button.
> >
> > event=button/power.*
> > action=/usr/local/sbin/power.sh "%e"
> > "
> 
> Considering that the output of /proc/acpi/event is things like:
> 
>   button/power PBTN 00000080 00000001
> 
> I just made a really small shell script that did it last time I cared (2006?), 
> doing something like "while read one two < /proc/acpi/event" and then some 
> simple if cases with string matching, or something.  It was a while ago, don't 
> remember the details...
> 
> I'm guessing you're looking at the magic binary data from /dev/event, whereas 
> I like human-readable text.  (Magic binary data is the windows approach, human 
> readable text is unix.)
> 
> Still, there's an existing acpid which you decided busybox needed for some 
> reason, so you're being compatible with it.  *shrug*

Vladimir wanted it:

Date:   Sat Nov 29 09:05:50 2008 +0000
acpid: new applet by Vladimir. +737 bytes

I decided to make one of our active patch submitters a bit happier/successful
in whatever he is doing using busybox. Perhaps because I was lazy and didn't
bother researching whether it can be writted in shell...

> I was attracted not just to busybox's small size, but to its _simplicity_.  
> You can't grow forever and stay simple.  Busybox wasn't just about "can we do 
> this more efficiently", it was about "do we actually need to do this in the first 
> place", "and "how can we get away with not doing this?"

Unfortunately, that approach would severely limit busybox's
possible user base: it will exclude desktop users, which is A LOT.

We can target the "how can we get away with not doing this?"
userbase relatively easily by supporting a separate
miniconfig.

> > > So, three policy questions:
> > >
> > > 1) What should and shouldn't be in defconfig.
> >
> > defconfig should have almost all options enabled; except these:
> > * debug build options
> 
> Check.
> 
> > * options which introduce incompatible behavior (e.g. "standalone shell"
> > option)
> 
> 
> > * options which are likely to require very vecent kernel headers
> >   (these options are to be turned on in future)
> > Other ideas?
> 
> My first idea is adding a FAQ entry with the rationale:
> 
> I use a "trimconfig" which "inadvisable" features, starting with:
> 
> CONFIG_FEATURE_ASSUME_UNICODE=n

(It's renamed to CONFIG_UNICODE_SUPPORT now)
I lean more to enabling it.

> CONFIG_FEATURE_CLEAN_UP=n
> CONFIG_SELINUX=n
> CONFIG_PAM=n
> CONFIG_FEATURE_PREFER_APPLETS=n
> CONFIG_STATIC=n
> CONFIG_PIE=n
> CONFIG_NOMMU=n
> CONFIG_BUILD_LIBBUSYBOX=n

These already default to n.

> Things like selinux and pam require optional stuff on the host and won't work 
> without them.  Things like PIE, static linking, nommu, and libbusybox are 
> things you know if you want and can explicitly request.  FEATURE_CLEAN_UP is a 
> debug thing, and unicode is both a "needs environmental support" thing

Not really. We have full internal implementation now.
No libc support is necessary. You can build uclibc without locale support
and still build unicode-aware busybox against it.

> and  
> something that (I think) belongs at the x11/qt/gtk level, not most command 
> line tools.

Apart from those people who really need to "rm HiFi-Запоминай.MP3"
from the shell command line, and they want line editing to not go belly up
when confronted with multi-byte characters. Not to mention Israeli users,
who have much pain entering filenames in Hebrew in reverse order.
Try it, and you'll understand.

> The following code is archaic and dead, quite possibly removed by now, I need 
> to check:
> 
> CONFIG_FEATURE_MTAB_SUPPORT=n
> CONFIG_FEATURE_DEVFS=n
> CONFIG_DEVFSD=n

These already default to n.

> # Switch off debug stuff
> 
> CONFIG_DEBUG=n
> CONFIG_WERROR=n
> CONFIG_INSTALL_NO_USR=n
> CONFIG_DEBUG_TFTP=n

These already default to n.

> CONFIG_FEATURE_UDHCP_DEBUG=n

It's renamed to UDHCP_DEBUG in 1.17.0, changed to be an int
and it's not a debug option (as in "do not use in production!"):

          Verbosity can be increased with multiple -v options.
          This options controls how high it can be cranked up.
          Bigger values result in bigger code. Levels above 1
          are very verbose and useful for debugging only.

I suggest setting it to 1 or 2. Diagnosing DCHP problems with it
is so much easier...

> # This doesn't build on some non-x86 targets (such as m68k).

Disabling for 1.17.1:
http://busybox.net/downloads/fixes-1.17.0/busybox-1.17.0-build_system.patch

> CONFIG_TASKSET=n

Disabling for 1.17.1

> # This doesn't build under Knoppix 5
> 
> CONFIG_INOTIFYD=n

Disabling for 1.17.1

> # This doesn't even build for i686 on Ubuntu 8.04.
> CONFIG_FLASHCP=n
> CONFIG_FLASH_LOCK=n
> CONFIG_FLASH_UNLOCK=n
> CONFIG_FLASH_ERASEALL=n

Disabling for 1.17.1

> # Contains a hardwired #ifdef staircase of known targets, breaks on hexagon.
> 
> CONFIG_FEATURE_OSF_LABEL=n

Defaults to n in 1.17.0 already

> 
> # Doesn't build on SLES 10
> 
> CONFIG_ACPID=n

fixed?
http://busybox.net/downloads/fixes-1.17.0/busybox-1.17.0-acpid.patch

> # Doesn't build on Ubuntu 9.04.
> 
> CONFIG_RFKILL=n

Disabling for 1.17.1

-- 
vda