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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
