**** BEGIN LOGGING AT Sat Jan 23 02:59:57 2010 Jan 23 03:44:20 nbd * r19283 /trunk/target/linux/ifxmips/files/arch/mips/include/asm/mach-ifxmips/ifxmips.h: ifxmips: fix mdio register access bitmask Jan 23 03:45:09 ugh..managed to hit a key at the beginning the file...I always have trouble finding those Jan 23 05:33:15 jow_laptop: thoughts about #4735? input accept mime type restrictions perhaps? Jan 23 05:41:02 cshore: is #5070 still valid? Jan 23 05:49:47 jow_laptop: want to dupe #6190 to #5842 and #5512 to #5453? #5055 also exists as LuCI #19 Jan 23 05:50:55 swalker: no #5070 is fixed Jan 23 05:55:45 somebody want to close that then? Jan 23 05:57:29 closed. Jan 23 06:00:24 Bartman007: there's also a ticket about recent shell-fm sources missing on the mirror(s), #5518, although the package is now up to 0.7 Jan 23 06:03:16 cshore: how about #5456? Jan 23 06:04:11 I haven't tried anytime recently Jan 23 06:06:07 swalker: k. I'm running my hacked download tree so I can upload any other version controlled source tarballs. Jan 23 06:11:47 cshore: I'd think it'd still be valid considering http://luci.subsignal.org/trac/browser/luci/trunk/themes/openwrt-light/root/etc/uci-defaults/luci-theme-openwrtlight hasn't changed in the meantime Jan 23 06:38:50 actually its http://luci.subsignal.org/trac/browser/luci/trunk/libs/web/root/etc/config/luci Jan 23 06:38:53 that's the problem Jan 23 06:39:04 and it's not changed Jan 23 06:39:56 would uci-defaults for mediaurlbase, from openwrt-light, solve the problem? Jan 23 07:44:49 shouldn't include/download.mk rm -rf the $(TMP_DIR)/dl/$(SUBDIR)s after it packs and mv's the $(FILE) to $(DL_DIR)/? Jan 23 08:28:17 nbd * r19284 /trunk/scripts/metadata.pm: metadata: allow build variants to contain "-" Jan 23 08:28:22 nbd * r19285 /trunk/package/mac80211/files/lib/wifi/mac80211.sh: mac80211: improve wifi interface cleanup Jan 23 08:28:28 nbd * r19286 /trunk/package/ (28 files in 6 dirs): hostapd: add a build variant for wpa_supplicant and one for a multicall hostapd+supplicant program (wpad) and remove the old wpa_supplicant package Jan 23 08:29:06 phew... that was a big change Jan 23 08:29:45 could you guys please test wpad as well? Jan 23 08:29:53 it works for me in ap and sta on mac80211 and madwifi Jan 23 08:30:21 simply deselect hostapd/wpa_supplicant and select wpad-mini instead - it's a drop-in replacement Jan 23 08:30:32 * nbd should get some sleep now Jan 23 08:32:20 <_trine> blimey nbd you are working a night shift Jan 23 08:33:56 i'm more productive during the night than during the day ;) Jan 23 09:08:14 yay, all packages should be able to properly download their sources now. on a related note, openwrt x86 requires 1.3GB of sources to be downloaded. Jan 23 09:52:38 swalker * r19287 /packages/net/transmission/ (Makefile patches/001-debian_dont_build_libevent.patch): [packages] transmission: update to 1.81 Jan 23 10:02:39 swalker * r19288 /packages/net/subversion/Makefile: [packages] subversion: update to 1.6.9 Jan 23 11:05:59 build #19 of ixp4xx-trunk is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ixp4xx-trunk/builds/19 Jan 23 11:42:35 * swalker wonders why stunnel's pid is two more than the number it wrote to the pidfile Jan 23 11:59:23 swalker: how many stunnel processes do you have? stunnel uses more than one PID IIRC Jan 23 12:01:29 cshore: one Jan 23 12:02:13 * cshore is whistling past a graveyard Jan 23 12:59:12 build #19 of rb532-trunk is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/rb532-trunk/builds/19 Jan 23 13:32:04 RTL8366S driver DEBUG_FS support (RTL8366_SMI_DEBUG_FS) [N/y] (NEW) Jan 23 13:32:27 is that known, or have I messed up my svn checkout Jan 23 13:36:24 <[Fate]> nbd: ping Jan 23 13:49:47 ah, seems I just needed another make clean Jan 23 14:33:45 nbd * r19289 /trunk/package/hostapd/Makefile: hostapd: fix build error Jan 23 15:12:59 nbd * r19290 /trunk/package/hostapd/ (Makefile patches/340-roboswitch_fix.patch): hostapd: fix compile error in the roboswitch driver Jan 23 15:54:01 [florian]: ping Jan 23 16:39:33 nico * r19291 /trunk/package/ (4 files in 3 dirs): [package] add explicit dependency on kmod-crypto-core when required (closes: #6557) Jan 23 16:43:56 {Nico}: imho there's still a '+' missing in that commit Jan 23 16:44:48 but it's not important Jan 23 16:44:53 imho we should nuke that package anyway Jan 23 16:45:08 since it has @LINUX_2_4||@LINUX_2_6_21||LINUX_2_6_25 in its dependency Jan 23 16:45:46 and the 2.4 dependency is even invalid Jan 23 16:46:31 <{Nico}> nbd: i would like to remove the -core suffix for kmod-crypto-core, kmod-usb, kmod-video, etc Jan 23 16:46:49 <{Nico}> and switch to + depends for all packages that depends to them Jan 23 16:47:10 <{Nico}> is that ok with you? Jan 23 16:48:13 ok Jan 23 16:48:42 i'll nuke some obsolete 2.6.21/2.6.25 related stuff first, ok? Jan 23 16:49:24 <{Nico}> ok, go ahead, i'll search & replace in the meantime :) Jan 23 16:51:09 $(call KernelPackage/usb-net/Depends,@LINUX_2_6 @!LINUX_2_6_21 @!LINUX_2_6_25 +!TARGET_rb532||!TARGET_avr32||!TARGET_brcm47xx||!TARGET_s3c24xx||!TARGET_ifxmips||!TARGET_atheros||!TARGET_adm5120||!TARGET_ar7||!TARGET_ppc40x||!TARGET_ixp4xx||!TARGET_rdc:kmod-rfkill) Jan 23 16:51:19 what is this supposed to be for? Jan 23 16:51:25 i mean the long target list Jan 23 17:03:39 swalker: "stunnel's pid is two more than the number it wrote to the pidfile" - I think start-stop-daemon writes the pid and stunnel forks itself again leading to the mismatch Jan 23 17:04:06 pong cshore Jan 23 17:08:01 nbd * r19292 /trunk/package/kernel/modules/ (6 files): remove obsolete dependencies and checks Jan 23 17:11:54 is "wifi0: ath_bstuck_tasklet: Stuck beacon; resetting (beacon miss count: 11)" something to worry about? using an atheros device with madwifi here Jan 23 17:13:01 or "wifi0: ath_uapsd_processtriggers: Dropping; skb is NULL in receive"? Jan 23 17:13:23 on what version of openwrt? Jan 23 17:13:45 18405 Jan 23 17:13:50 trunk 18405? Jan 23 17:13:58 or 8.09/ Jan 23 17:14:11 ah, don't mind the last message, there has been a different kernel module crashing Jan 23 17:14:15 yep, trunk Jan 23 17:14:45 the stuck beacon issue is not fatal, but could lead to clients losing their link Jan 23 17:14:56 if you upgrade to a newer trunk version, it should be more reliable Jan 23 17:15:03 ah, ok. but 11 ones during Jan 23 17:15:14 20 hours or so, that's ok, isn't it? Jan 23 17:15:24 yes Jan 23 17:15:29 happens during interference Jan 23 17:15:37 ah, okay? were there any madwifi patches in the last couple of months? Jan 23 17:16:23 ah, ok. then this sounds ok then, had those 9 routers next to each other here, so interferences were expected Jan 23 17:16:28 :) Jan 23 17:16:34 fixes were added in 18739 and 18740 Jan 23 17:16:46 i mean fixes related to stuck beacon issues Jan 23 17:17:04 xMff: so, any idea what about what's wrong with the firewall scripts that prevents me from blocking individual IPs? Jan 23 17:17:39 Plouj: yes, the order of the rules, there was quite some refactoring in the scripts recently which most likely caused that Jan 23 17:18:17 is someone going ot fix that soon? Jan 23 17:18:32 probably Jan 23 17:18:52 xMff: just a regression from the upstream sighup changes afaict and stunnel doesn't use start-stop-daemon Jan 23 17:18:56 nbd: ah, I see, thanks Jan 23 17:19:07 swalker: ah ok Jan 23 17:21:20 nbd * r19293 /trunk/target/linux/ (10 files in 10 dirs): replace the hostapd preselection with a wpad preselection to enable proper client mode support in the default images Jan 23 17:30:13 build #18 of rdc321x-trunk is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/rdc321x-trunk/builds/18 Jan 23 17:52:39 nbd * r19294 /trunk/target/linux/generic-2.6/ (3 files in 3 dirs): gpiommc: fix dependencies on the spi gpio module - fixes the mmc_over_gpio package build Jan 23 18:25:06 nbd * r19295 /trunk/package/hostapd/Makefile: hostapd: fix wpad compile error by preventing make spam from showing up in the cflags/ldflags dump files Jan 23 18:25:46 nbd * r19296 /trunk/package/mac80211/patches/590-ath9k_init_fix.patch: ath9k: fix an initialization error on 2GHz-only cards (based on discussion on ath9k-devel@) Jan 23 18:54:28 hmm, when in wlanconfig, there is something weird. I'm having a about 4 routers on channel 3 and another 4 on channel 1. but "wlanconfig athx list sta" on a channel 1 router is always claiming all the other routers being on channel 1 as well Jan 23 18:54:38 -when Jan 23 18:55:21 and the other way round as well, all channel 3 routers claim all other routers being on channel 3 as well Jan 23 18:56:22 again while using madwifi and still 18405 trunk Jan 23 19:00:09 and ethernet frames of channel 1/3 routers even arrive on channel 3/1. is this supposed to be like this in ad-hoc mode? (not using ahdemo here) Jan 23 19:15:34 channels 1 and 3 overlap Jan 23 19:16:03 the card doesn't know which channel the frame it just picked up was really meant for Jan 23 19:19:06 ah, hmm, okay. thought it might know that because of the beacons Jan 23 19:19:24 it ignores beacons from other channels Jan 23 19:19:27 but not other frames Jan 23 19:24:01 xMff: do you think I should submit a bug report about that? Jan 23 19:24:31 is it safe to post my iptables -nvL output online? Jan 23 19:45:40 ping xMff Jan 23 19:46:39 XMff: sorry, I'll have to come back...my dog is wanting a walk Jan 23 20:27:14 ping xMff Jan 23 21:06:34 pong cshore Jan 23 21:07:20 Hi. Just wanted to let you know I've put what should be the final release, barring any requested changes, of the patch on the -devel list Jan 23 21:07:34 Also wondering how your build went Jan 23 21:08:23 looked good Jan 23 21:17:54 The patch on the list adds patches for every platform with a preinit.arch (moving it to the new system), combines failsafe and preinit message setup (no real reason to have both), and makes it possible to turn off the network messages Jan 23 21:18:26 rtz2 suggested that Jan 23 21:18:41 (turning of network messages that is) Jan 23 21:28:56 ping rtz3 Jan 23 21:29:57 xMff: will you have to chance to look at it today? Jan 23 21:31:15 cshore: we'll see, quite a few luci problems accumulated over the last weeks, I'd rather spend my time with that tonight Jan 23 21:31:25 xMff: ok Jan 23 21:31:38 xMff: anything I can help with? Jan 23 21:38:24 btw luci #75 can be closed - backup for brcm63xx works Jan 23 21:39:05 cshore: unlikely that you can help, it is mostly rewrite stuff of the ui, syncing with semantic config changes and so on Jan 23 21:40:10 ok...once things are more stable I'll see about poking around NIU and moving some stuff to it, if you want Jan 23 21:40:47 would be awesome... we're undermanned ;) Jan 23 21:41:05 just let me know when it's in a state I can do that Jan 23 21:45:32 oh, also, do you know that luci-firewall (at least) has a memory leak? Jan 23 21:45:56 the ui component? Jan 23 21:46:36 I'm not sure...when I add/change rules via the ui, eventually I run out of memory Jan 23 21:46:44 even if I apply Jan 23 21:47:30 I don't noticed on a 32M router, but on a 16MB it's a problem Jan 23 21:47:37 jow * r19297 /packages/net/krb5/Makefile: [packages] krb5: add libpthread dependency (#6530) Jan 23 21:48:32 could be a simple concurrency issue Jan 23 21:49:34 jow * r19298 /packages/libs/howl/Makefile: [packages] howl: add libpthread dependency (#6530) Jan 23 21:50:59 jow * r19299 /packages/sound/mt-daapd/Makefile: [packages] mt-daapd: add libpthread dependency (#6530) Jan 23 21:57:58 ? Jan 23 21:58:02 jow * r19300 /trunk/package/base-files/files/etc/hotplug.d/block/10-mount: [package] base-files: try to activate hotplugged partitions as swap and fall back to lazy mount (#6517) Jan 23 21:58:21 too much at once? (i.e. not yet applied?) Jan 23 21:59:06 well the firewall script has a long run time and it calls iptables frequently Jan 23 21:59:15 I see Jan 23 21:59:18 the webif is blocking while waiting for the firewall script to finish Jan 23 21:59:23 right Jan 23 21:59:38 both processes compete for memory and luci uses a fair chunk of it Jan 23 21:59:43 right Jan 23 21:59:55 that's waht I mean with concurrency issue Jan 23 22:00:21 I've been thinking about detaching the apply processes from the ui to allow it to return immediately Jan 23 22:00:51 but I have no clean way to signalize when the background process is finished Jan 23 22:00:59 hmmm..... Jan 23 22:01:04 too much IPC, I'd like to avoid that Jan 23 22:01:08 right Jan 23 22:01:10 it is already complex enough Jan 23 22:01:53 on the other hand, maybe no user actually cares, maybe it is enough to state "wait a few seconds" in the ui Jan 23 22:02:04 I think so Jan 23 22:02:33 if you have too many concurrent processes memory could become an issue Jan 23 22:03:15 it is getting worse if you have to apply several configs at once Jan 23 22:03:19 :) Jan 23 22:04:41 then there's the new ucitrigger mechanism which I haven't even explored yet Jan 23 22:04:49 right Jan 23 22:04:53 it should simplify some of that stuff Jan 23 22:05:27 but yet another bunch of work to do so I keep postponing it Jan 23 22:05:33 heh Jan 23 22:05:45 need more bodies and brains (or at least brains) Jan 23 22:06:39 (people I mean) Jan 23 22:07:02 or to be paid to do it full time Jan 23 22:07:05 but ucitrigger would allow us splitting the integration work into writing triggers and the ui stuff, then one can start implementing the apply logic independent from the actual ui in use Jan 23 22:07:22 cool Jan 23 22:08:13 the idea is that "uci commit" triggers a series of apply actions dependent on the changed values (per section, per config, per option) Jan 23 22:09:24 in the simplest case it is just an init script restart but could be more sophisticated for certain operations - for example modifying the wifi mac blacklist or chaning the ssid/channel Jan 23 22:09:50 http://luci.subsignal.org/trac/browser/luci/trunk/libs/web/root/etc/config/luci causes #5456; would adding uci-defaults to change this in openwrt-light fix it? Jan 23 22:10:21 xMff: that would allow for non-reboot config changes, right? Jan 23 22:10:28 yes Jan 23 22:11:13 ... to both Jan 23 22:11:21 that would be cool...it's one of those I wanted to look into Jan 23 22:11:29 ok, I'll hack on that in a sec Jan 23 22:15:31 #6074 is fixed Jan 23 22:16:38 #5534 is also fixed Jan 23 22:18:20 jow * r19301 /packages/net/pptpd/ (4 files in 2 dirs): [packages] pptpd: update to v1.3.4 - patch by Edgar Soldin Jan 23 22:19:03 fixed by what? Jan 23 22:19:20 could you look at #5478? it fixes hotplug to use the /etc/config/fstab mountpoints instead of /mnt/xxx, if present....at present if the device is hotplugged /etc/config/fstab is not used Jan 23 22:19:43 wasn't that fixed by {Nico} a while ago? Jan 23 22:19:45 xMff: I'm not sure what revision fixed it, but I don't have the problem anymore Jan 23 22:19:58 xMff: I think he only added swap Jan 23 22:20:49 10-mount (under hotplug.d/block) is what needs to change Jan 23 22:21:07 yeah I know, just touched that Jan 23 22:22:05 maybe something like "mount /dev/$device || ( mkdir -p /mnt/$device; mount /dev/$device /mnt/$device )" would be enough to pick up settings from fstab Jan 23 22:22:48 does fstab run before hotplug though? Jan 23 22:22:52 race condition Jan 23 22:22:58 probably not Jan 23 22:23:01 exactly Jan 23 22:23:04 also we want e2fsck Jan 23 22:23:08 if present Jan 23 22:23:24 ... and fs in question is e2 Jan 23 22:23:30 yes Jan 23 22:23:48 it some amount of work to get it right, no oneliner Jan 23 22:23:56 yes Jan 23 22:24:05 cshore: pong Jan 23 22:24:27 rtz3: hi, do you have time to look at that patch? Jan 23 22:26:22 5057 is part of 5478 Jan 23 22:26:38 also 5056 Jan 23 22:28:24 cshore: no, sorry Jan 23 22:28:34 jow * r19302 /trunk/package/iptables/ (6 files in 3 dirs): [package] iptables: update to v1.4.6, relocate patches - patch by Edgar Soldin Jan 23 22:28:40 rtz3: ok, another time then Jan 23 22:29:00 cshore: I fucked up the irq config or something and had to spend like 10h to repair it :/ Jan 23 22:29:09 rtz3: ugh Jan 23 22:29:35 rtz3: so you're a little behind Jan 23 22:32:23 cshore: you could say so Jan 23 22:32:57 xMff: #5458 has a 10-mount that should resolve the issues I mention and 5056/5067 Jan 23 22:33:49 5458 is "i2c-gpio-cystom, does not show in the list of packages" Jan 23 22:33:53 seems to be unrelated Jan 23 22:34:03 sorry 5478 Jan 23 22:36:17 cshore: can you integrate r19300 and fallback to /mnt/$device if no /etc/fstab definition exists? Jan 23 22:37:34 I can....if we do that we should close 5056 as invalid Jan 23 22:37:56 you can just post an amendment :) Jan 23 22:38:12 xMff: yes Jan 23 22:42:02 #5056 is the complaint that we can't not automount if we don't want to Jan 23 22:42:37 it is starting to get complex :) Jan 23 22:43:08 next candidate is 3g dongles with mass storage emulation Jan 23 22:43:09 xMff: that's probably why it wasn't applied right away (7 months ago) Jan 23 22:43:40 this would need a blacklist unless there's a kill switch for automount Jan 23 22:43:52 then what happens if both usb disk and 3g dongle are attached Jan 23 22:44:09 they be different scsi devices wouldn't they? Jan 23 22:44:24 or are you referring the which device am I problem? Jan 23 22:44:28 well for one you want automount for the other not Jan 23 22:44:33 ah, ok Jan 23 22:45:46 maybe add a parameter to fstab called disable_automount Jan 23 22:46:06 well there is option auto already Jan 23 22:47:12 xMff: I meant as global....but ok, we could do per-device...but the problem of changing scsi device names is something that will likely come up too Jan 23 22:47:28 we could switch to uuids ;) Jan 23 22:47:56 I'd make it an option... Jan 23 22:48:01 in any case it is going to be quite a bit of boilerplate code for something that can be easily done manually in a few lines Jan 23 22:48:22 as usual when one wants to do it right & generic :) Jan 23 22:48:28 :) Jan 23 22:49:15 I think I need use /lib/functions and share functions between /etc/init.d/fstab and /etc/hotplug.d/block/10-mount though Jan 23 22:49:31 /lib/functions/mount.sh Jan 23 22:49:33 or something Jan 23 22:50:12 or do all devices hotplug? Jan 23 22:53:30 oh, and should we mount /dev/sdAX or /dev/UUID? Jan 23 22:53:43 /mnt I mean Jan 23 22:55:13 oh wait, we don't have UUID unless we have udev (via cli that is) Jan 23 22:56:00 so we can mount via UUID, but we can't create the mountpoint UUID because we don't have that info Jan 23 22:56:08 jow * r19303 /trunk/package/base-files/files/lib/network/config.sh: [package] base-files: ensure that the ip6addr of the main interface stays the primary ip by re-adding it after alias setup is completed - patch by Alina Friedrichsen Jan 23 23:01:20 I wonder though if mounting shouldn't moved to preinit Jan 23 23:01:49 hmm, I'm getting this backtrace after running the router for about 1-2 hours: http://pastebin.com/m15792bac Jan 23 23:01:56 does anyone have an idea what could cause it? or could that be any of those modules? Jan 23 23:02:22 looks like a simple load issue Jan 23 23:03:28 or radio is jammed and can't transmit packets fast enough - something like that Jan 23 23:04:29 <_trine> r19303 seems to fail to compile Jan 23 23:04:42 details Jan 23 23:06:55 xMff: hmm, okay. so it is very likely a wifi driver issue? for instance the batman-adv kernel module, which is using the wifi, also had some memory locking trouble a couple of months ago Jan 23 23:07:07 <_trine> it's the new ipv6 tables patch Jan 23 23:07:30 <_trine> just doing V=99 now Jan 23 23:08:11 <_trine> http://dpaste.com/149581/ Jan 23 23:08:39 I see no error Jan 23 23:08:45 please repeat without -j Jan 23 23:09:10 well yes, I see a failure but no reason Jan 23 23:09:12 <_trine> ok Jan 23 23:10:30 <_trine> without V=99 it showed the new iptables patch Jan 23 23:10:48 <_trine> http://dpaste.com/149582/ Jan 23 23:11:45 <_trine> cp: cannot stat `libip6t_*.so': No such file or directory Jan 23 23:12:26 I'll recheck Jan 23 23:12:31 <_trine> k Jan 23 23:35:03 xMff: I think I'll work on the openwrt-light thing then come back to this...I think part of the solution will involve changes to preinit Jan 23 23:38:31 cshore: I'm still think a binary preinit and init replacement would be a better idea ... Jan 23 23:39:43 rtz3: This just keeps snowballing...I'm worried about just how massive the changes will be Jan 23 23:40:00 hello guys Jan 23 23:40:38 cshore: a pretty common problem for me :/ Jan 23 23:40:45 rtz3: heh Jan 23 23:41:11 cshore: but the point is, making preinit more and more complex has also lots of problems Jan 23 23:41:30 besides, I would really like to speed up the boottime of openwrt Jan 23 23:41:32 rtz3: I'm not sure a binary a good idea...but I think switching to a single init would be good Jan 23 23:41:53 it takes nearly 2 min to boot for me Jan 23 23:42:08 starting stuff in parallel would be a real help Jan 23 23:42:16 rtz3: yeah me too Jan 23 23:42:30 rtz3: upstart anyone ? :) Jan 23 23:42:46 cshore: checked it already out ;) Jan 23 23:43:12 cshore: the problem is, it heaviely uses dbus Jan 23 23:43:23 rtz3: yeah, that wouldn't work Jan 23 23:43:29 cshore: and it's hard to remove dbus support from it Jan 23 23:43:40 it's more or less directly tied to it's core Jan 23 23:44:11 there are also some other init replacements Jan 23 23:44:16 rtz3: what about insserv? Jan 23 23:44:41 rtz3: or does that just change how it's defined, but still single process? Jan 23 23:44:50 initng for example looks pretty good, but it's unmaintained since like 3 years Jan 23 23:45:12 don't know insserv, let me take a look Jan 23 23:45:25 sorry, i don't understand your last question Jan 23 23:48:26 cshore: Insserv - Enable an installed system init script Jan 23 23:48:35 not what i'm looking for Jan 23 23:49:41 rtz3: insserv is actually the new debian boot system...unless they switch to even-based one like upstart Jan 23 23:50:06 insserv start in parallel Jan 23 23:50:15 and is also a command Jan 23 23:50:31 openrc ftw :-) Jan 23 23:51:26 cshore: ok, let me look further Jan 23 23:51:49 rtz3: I think we need an event-based one anyway...we're already going that route with hotplug stuff Jan 23 23:52:08 rtz3: so not insserv Jan 23 23:53:18 cshore: let's see, if I can throw something together Jan 23 23:53:50 but I would have to parse some config files and I hate writing file parse Jan 23 23:54:05 rzt3: we should use uci configs anyway Jan 23 23:54:22 there's libuci Jan 23 23:54:29 no need to reinvent the wheel ;) Jan 23 23:55:03 right Jan 23 23:55:11 it's also a library Jan 23 23:55:13 forgot that Jan 23 23:55:56 xMff: 2 questions Jan 23 23:56:09 xMff: 1. are there any api docs for libuci? Jan 23 23:56:43 xMff: 2. would an even based init + preinit replacement have a chance of getting merged? Jan 23 23:57:00 there's example code in the source tarball, the cli.c covers any function exposed by libuci Jan 23 23:57:42 event based Jan 23 23:57:48 2) it depends how versatile it is... one point of using ash scripts is the ability to easily edit stuff, working with binaries always implies a working sdk Jan 23 23:59:37 I agree...I don't like the idea of a binary replacing the scripts...only for the controlling 'glue' Jan 24 00:02:47 well, I didn't plan to port the scripts to C Jan 24 00:03:15 as for the event based init... on what "events" would you base it on? Jan 24 00:03:23 more like something, that can start programs if certain conditions are met Jan 24 00:03:48 We already have quite a bit of race conditions introduced by hotplug, a non-linear init /could/ ask for more trouble Jan 24 00:03:58 at least without some sort of inter-service-dependencies Jan 24 00:04:10 xMff: yes we would need that Jan 24 00:04:10 ... this is where stuff gets complex Jan 24 00:04:26 xMff: well, mainly on the fact that everything neccesary for a certain task is finished Jan 24 00:05:07 I agree but in the end a router should route, not boot ... if you know what I mean Jan 24 00:05:22 yes, right Jan 24 00:05:37 in other words I'm not sure what such a system would gain us Jan 24 00:05:37 but at the moment, openwrt spends a lot of time booting Jan 24 00:05:48 ok, faster startup time Jan 24 00:06:08 and an event based system with depencies would help with the race conditions Jan 24 00:06:25 also you need to be very careful with ram usage if you init multiple services concurrently Jan 24 00:06:48 hmmmm Jan 24 00:06:48 16MB routers.... Jan 24 00:06:56 running firewall and network init in parallel for example would certainly oom a 16MB device Jan 24 00:07:35 well, I will try to write a replacement for preinit and see where it goes from there Jan 24 00:07:51 it's a much easier enviroment then init Jan 24 00:08:07 can't hurt to give it a try Jan 24 00:08:54 rtz3: don't forgot that there's arch-specific stuff in preinit Jan 24 00:08:58 what is the particular problem with the long boot time? I mean stuff like basic routing and firewall is operational far before init is completely finished Jan 24 00:09:15 rtz3: preinit doesn't take long...it's init Jan 24 00:09:41 thne there are also some timeouts involved in the process, like waiting for ctrl-c Jan 24 00:09:55 rtz3: and that's because of the daemons, not the init process Jan 24 00:10:01 xMff: which kinda doesn't work anyway Jan 24 00:10:26 rtz3: I fixed it (well replaced Ctrl-C with f) Jan 24 00:10:27 yes, but preinit is a much easier target Jan 24 00:11:01 rtz3: because Ctrl-C doesn't work on /dev/console Jan 24 00:11:37 rtz3: because making it a conrolling terminal is a bad idea once your in normal mode Jan 24 00:12:50 rtz3: I don't think the way we're doing init is what makes the process slow...it's that starting the daemons is slow Jan 24 00:13:28 rtz3: and the slow daemon can't be parallized on 16MB routers Jan 24 00:14:22 rtz3: my reason for thinking switch to a single init would be good, is because it'd unify the init process...cleaner Jan 24 00:17:37 cshore: that's also my point Jan 24 00:18:07 rtz3: but I'm not sure that cleaner is worth the amount of change what would be necessary Jan 24 00:18:45 that's also a reason I want to target preinit first Jan 24 00:18:57 it's much smaller Jan 24 00:19:11 and it would be possible to gradually move stuff over from init Jan 24 00:19:30 as I said, it can't hurt to give it a try Jan 24 00:19:48 rtz3: will one be able to drop in packages (that add files) that let you change preinit behaviour...that's why I did the changes I did Jan 24 00:22:34 yes Jan 24 00:22:46 I did rember your original goal Jan 24 00:27:47 rtz3: well, if you want to try, that's up to you...it might be useful Jan 24 00:47:22 cshore: a vote of confidence :D Jan 24 00:48:23 xMff: To change config 'core' 'main' option 'mediaurlbase' '/luci-static/openwrt.org' Jan 24 00:48:23 would I use luci.core.medualurlbase or luci.main.mediaurlbase? Jan 24 00:48:25 jow * r19304 /trunk/package/iptables/Makefile: [package] iptables: --enable-static and --enable-shared don't work well together, drop --enable-static Jan 24 00:48:42 rtz3: heh, that bad, eh? Jan 24 00:48:51 main Jan 24 00:53:13 xMff: is there any description of the uci configfile syntax? Jan 24 00:53:36 http://wiki.openwrt.org/doc/uci#file.syntax Jan 24 00:53:44 ... is the best I can offer Jan 24 00:55:16 :/ Jan 24 00:55:26 I mean there is not much more Jan 24 00:55:34 what else is unclear? Jan 24 00:55:36 xMff: what does the package statment do? Jan 24 00:56:13 it defines the name of the config, this is only useful for batch operations, usually the package name is derived from the filename Jan 24 00:56:35 package comes into play when the config has no filename (piped from stdin etc.) Jan 24 00:56:55 hmm Jan 24 00:57:00 for traditional files it is legal to ommit it, in this case the parser shall derive it from the filename Jan 24 00:59:38 xMff: ok, then the second part of a statement like this: option 'string' 'some value' Jan 24 01:00:07 is it treated specially? Jan 24 01:00:15 as a datatype? Jan 24 01:00:18 you mean 'string' ? Jan 24 01:00:39 no, uci files convey no meta information Jan 24 01:00:47 the identifier 'string' is arbitary Jan 24 01:01:16 all values are treated as string, it is up to the processing application to decided whether to treat a value as string, number, bool Jan 24 01:01:23 -d Jan 24 01:02:43 hmmm Jan 24 01:03:09 what's the story with plugins in the libuci api? Jan 24 01:03:18 xMff: what exactly are thy used for? Jan 24 01:03:37 they allow one to implement other storage backends as far as I know Jan 24 01:04:00 ok Jan 24 01:04:06 thanks for the answeres Jan 24 01:04:07 you need to ask nbd for the specifics Jan 24 01:04:30 xMff: i'm sure there will be more questions :) Jan 24 01:19:59 _trine: ah btw, the iptables issue should be gone with the latest commit Jan 24 01:31:28 jow * r19305 /packages/libs/libxml2/Makefile: [packages] libxml2: enable Canonical XML support (c14n), required by php5 (#6559) Jan 24 01:35:19 jow * r19306 /packages/lang/php5/ (Makefile files/php.ini): Jan 24 01:35:19 [packages] php5 (#6559) Jan 24 01:35:19 - sync with upstream php.ini Jan 24 01:35:19 - EXIF extension moved out of core Jan 24 01:35:19 - enable more extensions Jan 24 01:35:20 - optional linking against libxml2 Jan 24 02:27:01 jow * r19307 /trunk/package/mac80211/files/host_bin/b43-fwsquash.py: [package] mac80211: make b43-fwsquash.py work with python 3.x Jan 24 02:27:32 nbd * r19308 /trunk/package/mac80211/patches/600-ath9k_rc_tries.patch: ath9k: improve max rate retry handling Jan 24 02:40:19 nbd: you still here? Jan 24 02:41:40 yes Jan 24 02:42:17 nbd: is it possible to split a package into different files in uci? Jan 24 02:43:38 no Jan 24 02:43:44 a package is mapped to a file with the same name Jan 24 02:44:51 ok **** ENDING LOGGING AT Sun Jan 24 02:59:57 2010