**** BEGIN LOGGING AT Wed Feb 22 02:59:59 2012
Feb 22 03:24:13 <philipp64|laptop> crow: ping
Feb 22 07:10:00 <builder_> build #120 of uml is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/120
Feb 22 07:31:52 <Acinonyx> Olipro: it's on my TODO list
Feb 22 07:55:40 <builder_> build #140 of s3c24xx is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/140
Feb 22 08:28:24 <builder_> build #115 of avr32 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/115
Feb 22 11:58:38 <builder_> build #116 of sibyte is complete: Failure [failed compile_10]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/116
Feb 22 12:37:30 <danitool> which is the board target of the patch 455-board_ct536_ct5621.patch?
Feb 22 12:38:10 <danitool> the board ID of those routers are 96348GW-11
Feb 22 12:38:30 <danitool> not ct536_ct5621
Feb 22 12:39:04 <danitool> I suspect there isn't any board with the ID ct536_ct5621
Feb 22 12:39:27 <danitool> I think that patch is useless
Feb 22 13:00:39 <CIA-54> jow * r30678 /trunk/package/iwinfo/src/iwinfo_utils.c: [package] iwinfo: fix logic flaw in mtd partition check
Feb 22 13:19:56 <KanjiMonster> danitool: no it isn't; OpenWrt uses a reserved field in the images to fixup board names if the original board id is shared between devices with incompatible setups
Feb 22 13:25:11 <danitool> didn't know that, btw some people  with ct536 routers reported the built image for  ct536_ct5621 didn't work and used the generic one
Feb 22 13:26:21 <KanjiMonster> danitool: anyone with a bootlog?
Feb 22 13:27:27 <danitool> no, I don't remember the particular forum where it was posted
Feb 22 13:36:55 <CIA-54> juhosg * r30679 /trunk/target/linux/ramips/files/drivers/net/ethernet/ramips/ (Makefile ramips.c ramips_main.c): ramips: raeth: rename main source file
Feb 22 13:36:55 <CIA-54> juhosg * r30680 /trunk/target/linux/ramips/ (8 files in 4 dirs): ramips: raeth: add debugfs support
Feb 22 13:36:56 <CIA-54> juhosg * r30681 /trunk/target/linux/ramips/files/drivers/net/ethernet/ramips/ (ramips_debugfs.c ramips_eth.h ramips_main.c): ramips: raeth: show interrupt statistics in debugfs
Feb 22 14:09:28 <CIA-54> jow * r30682 /trunk/package/iwinfo/ (10 files in 4 dirs): [package] iwinfo: add per-station rate and mcs info to assoclist op
Feb 22 14:10:42 <CIA-54> jow * r30683 /trunk/package/iwinfo/src/iwinfo_lib.c:
Feb 22 14:10:42 <CIA-54> [PATCH] Adjust txpower offset for Nano and Picostation M2 in iwinfo
Feb 22 14:10:42 <CIA-54> Signed-off-by: Hanno Schupp <hanno.schupp@gmail.com>
Feb 22 14:12:03 <CIA-54> jow * r30684 /trunk/package/iwinfo/src/iwinfo_wl.c:
Feb 22 14:12:03 <CIA-54> [PATCH] Allow full 250mw (24dBm) on WRT54GL and related with wl legacy driver on iwinfo
Feb 22 14:12:03 <CIA-54> Signed-off-by: Hanno Schupp <hanno.schupp@gmail.com>
Feb 22 14:25:28 <KanjiMonster> jow_laptop: sorry for the late comment, I noticed this before but then forgot it again, then remembered it when I saw you committing it ;)
Feb 22 14:26:18 <CIA-54> jow * r30685 /trunk/package/iwinfo/src/iwinfo_wl.c: [package] iwinfo: fix array size mismatch after r30684
Feb 22 14:27:36 <jow_laptop> KanjiMonster: well I could've paid attention
Feb 22 14:30:19 <KanjiMonster> ah well, it's fixed, so everything is fine ;)
Feb 22 14:49:58 <WillieNL> dunno who was asking/working on android port possible this can help ftp://ftp.gpl-devices.org/pub/vendors/Wondermedia/
Feb 22 16:29:45 <builder_> build #107 of iop32x is complete: Exception [exception compile_4 shell_14 compile_12]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/107
Feb 22 16:29:45 <builder_> build #139 of at91 is complete: Exception [exception compile_4 shell_14 compile_12]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/139
Feb 22 16:29:47 <builder_> build #109 of au1000 is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/109
Feb 22 16:29:50 <builder_> build #106 of etrax is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org:8010/builders/etrax/builds/106
Feb 22 16:39:52 <builder_> build #137 of ubicom32 is complete: Failure [failed compile_1]  Build details are at http://buildbot.openwrt.org:8010/builders/ubicom32/builds/137
Feb 22 16:42:54 <crow> philipp64|laptop pong, thanks i will try the image in fev moments
Feb 22 16:58:59 <philipp64|laptop> ok.
Feb 22 17:34:29 <merbanan> KanjiMonster, [florian]: CFE with the 4.12 release will only flash the firmware image at the start of the rootfs header parameter
Feb 22 17:35:09 <merbanan> and CFE will only boot the kernel from the kernel offset parameter
Feb 22 17:35:28 <merbanan> so as in the sent patch I set them both to the same address
Feb 22 17:36:10 <merbanan> but then the flashdriver uses those values to get the offsets for the root partition
Feb 22 17:36:44 <merbanan> so it fails to mount the filesystem
Feb 22 17:37:26 <merbanan> as the filesystem partition points to the beginning of the kernel
Feb 22 17:38:17 <merbanan> can I just add another case an fix up the offset in the flash driver ?
Feb 22 17:38:25 <merbanan> would that be accepted ?
Feb 22 18:23:20 <blogic> philipp64|laptop: ping
Feb 22 18:23:28 <blogic> i am hunting a regression in lantiq
Feb 22 18:23:35 <blogic> looks like the atm backport is reponsible
Feb 22 18:23:41 <blogic> but i dont see why this could be
Feb 22 18:38:25 <KanjiMonster> merbanan: hm? isn't that the default behaviour of openwrt (setting rootfs and kernel address to the same address, and CFE booting from the kernel address)
Feb 22 18:40:02 <KanjiMonster> merbanan: also do you know by chance any public source for a 4.12 release? ;)
Feb 22 18:40:51 <merbanan> KanjiMonster: no sorry
Feb 22 18:42:14 <KanjiMonster> merbanan: also what flash driver are you talking about, the openwrt one or the broadcom original one?
Feb 22 18:42:29 <merbanan> KanjiMonster: openwrt flash driver
Feb 22 18:42:57 <merbanan> and it uses the values straight from the image header
Feb 22 18:43:10 <KanjiMonster> the openwrt one doesn't care for the rootfs address, it just puts the rootfs at kernel address + kernel length
Feb 22 18:44:36 <merbanan> hmm, I might have old sources then
Feb 22 18:44:41 <merbanan> I get this
Feb 22 18:44:44 <merbanan> bcm963xx_flash: Partition 1 is kernel offset 20100 and length 14ff00
Feb 22 18:44:44 <merbanan> bcm963xx_flash: Partition 2 is rootfs offset 20100 and length e60000
Feb 22 18:44:59 <KanjiMonster> hm, strange
Feb 22 18:45:22 <merbanan> it correlates to the code and what I write in the image
Feb 22 18:46:21 <merbanan> No filesystem could mount root, tried:  ext3 squashfs vfat fuseblk
Feb 22 18:46:50 <merbanan> and if it uses the same offset then it is an obvious error
Feb 22 18:47:19 <merbanan> but as you said, I'll check the latest driver source
Feb 22 18:47:59 <KanjiMonster> merbanan: see http://lxr.linux.no/#linux+v3.2.5/drivers/mtd/maps/bcm963xx-flash.c#L77 - it never uses the rootfs offset
Feb 22 18:48:38 <KanjiMonster> so I'm quite surprised how the rootfs offset can become something different than kernel offset + length
Feb 22 18:49:13 <merbanan> my code doesn't look like that :)
Feb 22 18:50:38 <KanjiMonster> merbanan: well, it should look mostly like that
Feb 22 18:54:01 <KanjiMonster> merbanan: how /does/ your code look like?
Feb 22 18:56:41 <merbanan> http://pastebin.com/RJHQ8FAx
Feb 22 18:56:49 <merbanan> for 2.6.30
Feb 22 18:57:02 <merbanan> but I'll just backport a sane version of the code
Feb 22 18:57:11 <merbanan> tnx for the help
Feb 22 18:57:20 <merbanan> have to go
Feb 22 18:57:45 <KanjiMonster> eh, 2.6.30? that's ancient ;)
Feb 22 18:57:49 <KanjiMonster> see you
Feb 22 19:12:08 <[florian]> KanjiMonster: that's what broadcom now distributes
Feb 22 19:13:19 <KanjiMonster> [florian]: I know, I don't expect it to show up gpl tarballs for a few months at least
Feb 22 19:13:52 <[florian]> probably not
Feb 22 19:40:12 <philipp64|laptop> blogic: pong
Feb 22 19:40:45 <blogic> philipp64|laptop: hi
Feb 22 19:40:51 <blogic> philipp64|laptop: the patch seems to break
Feb 22 19:41:02 <blogic> i will look into it in a sec
Feb 22 19:41:18 <blogic> but we have a repoducable setup where it blows up on a dsl line within 20 minutes
Feb 22 19:41:29 <blogic> i asked for a retest without the patches
Feb 22 19:41:43 <blogic> lets wait on the results and then find out why it blows up
Feb 22 19:46:40 <philipp64|laptop> ok.
Feb 22 19:48:31 <blogic> although i fail to see why
Feb 22 20:16:28 <CIA-54> juhosg * r30686 /trunk/target/linux/ramips/base-files/etc/uci-defaults/network: ramips: fix VLAN config of the RT-N15
Feb 22 20:16:30 <CIA-54> juhosg * r30687 /trunk/target/linux/ramips/base-files/etc/uci-defaults/network: ramips: use unified switch identifiers in uci-defaults/network
Feb 22 20:16:31 <CIA-54> juhosg * r30688 /trunk/target/linux/ramips/base-files/etc/uci-defaults/network: ramips: merge identical switch configuration entries
Feb 22 20:30:38 <Chocks> hmmm
Feb 22 20:30:43 <Chocks> more ramips stuff.  good, I think
Feb 22 20:55:05 <philipp64|laptop> nbd: ping
Feb 22 21:09:33 <philipp64|laptop> jow_laptop: ping
Feb 22 21:14:24 <Chocks> pingy
Feb 22 21:19:02 <philipp64|laptop> nbd: r30675 causes damage.
Feb 22 21:31:55 <nbd> philipp64|laptop: details?
Feb 22 21:32:39 <jow_laptop> nbd: devel list
Feb 22 21:32:46 <jow_laptop> though I fail to see the connection
Feb 22 21:33:14 <nbd> that's odd, it builds just fine in my tests
Feb 22 21:33:23 <nbd> and i did runtime tests as well
Feb 22 21:35:16 <jow_laptop> however that rdynamic thing brought back some memories; months ago when I was working on fwd I had to export two symbols, "kernel_version" and "get_kernel_version" in order to be able to load DNAT and SNAT
Feb 22 21:38:31 <nbd> right. i had overlooked those, but my later optimization fixes these dependencies, since it moves that code into the iptables binary
Feb 22 21:38:48 <jow_laptop> ah ok
Feb 22 21:39:29 <jow_laptop> unfortunately this also means that I can no longer load iptables extensions myself :(
Feb 22 21:39:38 <nbd> ?
Feb 22 21:39:59 <jow_laptop> I've a daemon which loads iptables *.so files and uses them to generate rules
Feb 22 21:40:03 <jow_laptop> through libxtables
Feb 22 21:40:06 <nbd> oh
Feb 22 21:40:11 <jow_laptop> without going through the crappy iptables frontend
Feb 22 21:40:31 <nbd> i didn't know about that daemon
Feb 22 21:40:43 <jow_laptop> but its no biggy, if I ever pick up work on that again we can work out a solution
Feb 22 21:40:49 <jow_laptop> I suppose static linking would work as well
Feb 22 21:44:39 <jow_laptop> iirc the only reason to load the *.so with dlopen() was that it's been easier than maintaining copy-pasted code
Feb 22 21:45:07 <jow_laptop> or compiling some objects out of the iptables tree
Feb 22 21:47:04 <jow_laptop> anyway, I'm getting sidetracked again
Feb 22 21:47:10 * jow_laptop goes back fighting nl80211
Feb 22 21:48:11 <philipp64|laptop> nbd: left out this line, of course:
Feb 22 21:48:12 <philipp64|laptop> install: missing destination file operand after `/home/philipp/openwrt-alix/build_dir/linux-x86_alix2/iptables-1.4.10/ipkg-install/usr/lib/iptables/'
Feb 22 21:52:59 <philipp64|laptop> nbd: a patch might be to echo the variable through "tr -d ' '"
Feb 22 22:04:06 <philipp64|laptop> nbd: http://fpaste.org/HiJx/
Feb 22 22:45:20 <dape> guys would a small c app to monitor only icmp6 RAs via raw sockets outperform some iptables LOG rules ?
Feb 22 22:45:43 <jow_laptop> possible
Feb 22 22:46:03 <jow_laptop> there's also a utility already
Feb 22 22:46:11 <dape> im thinking raw sockets get unprocessed packets but iptables gets tcp packets, right?
Feb 22 22:46:14 <dape> which?
Feb 22 22:46:33 <jow_laptop> need to look it up
Feb 22 22:46:37 <jow_laptop> they all have weird names
Feb 22 22:46:40 <dape> uu, thanks!
Feb 22 22:47:52 <jow_laptop> rdisc6
Feb 22 22:48:04 <dape> ah, hmm, ok
Feb 22 22:48:16 <dape> heard about it, didnt test it, thanks, good night
Feb 22 22:48:21 <jow_laptop> gn8
Feb 22 23:32:49 <philipp64|laptop> jow_laptop: ping
Feb 22 23:32:58 <jow_laptop> .
Feb 22 23:34:09 <philipp64|laptop> I'd really like to encourage making those UCI changes, where the excessive quoting is suppressed (i.e. quotes are only generated when needed to protect correct interpretation against globs, substitutions, whitespace, etc).
Feb 22 23:34:38 <jow_laptop> not my decision
Feb 22 23:34:49 <philipp64|laptop> since sysupgrade doesn't exist on the x86, I need to hand-create UCI files to propagate my changes every time I install a new image.
Feb 22 23:34:55 <jow_laptop> propose a patch for libuci and present it on the list
Feb 22 23:35:10 <philipp64|laptop> it's painful. it would be a lot less painful if every line didn't diff for no reason at all.
Feb 22 23:35:15 <jow_laptop> but I fail to see the point actually
Feb 22 23:35:29 <jow_laptop> just use the canonical form from the get-go and your diffs will look clean
Feb 22 23:35:38 <jow_laptop> your latest proposed patches sort of do the reverse
Feb 22 23:35:45 <philipp64|laptop> well, do a "diff -urN /rom/etc/config /overlay/etc/config" ...
Feb 22 23:36:29 <philipp64|laptop> but the files that we start from (in the source tree) don't start with the canonical form.
Feb 22 23:37:07 <philipp64|laptop> I have a script I run in /etc/config that undoes the unnecessary quotes, which is why my proposed patch looks the way it does.
Feb 22 23:37:37 <philipp64|laptop> in other words, the scripts make the redone config files look more like what's in the source-tree.
Feb 22 23:38:00 <philipp64|laptop> my patches just correct some inconsistencies... like having an unquoted * ...
Feb 22 23:38:26 <jow_laptop> I'd rather see the source using quoting all along
Feb 22 23:41:12 <jow_laptop> anyway, $someone needs to write a patch to libuci
Feb 22 23:41:24 <jow_laptop> I'm not going to do it and nbd will probably lack the time to do so
Feb 22 23:43:09 <jow_laptop> if its only about the diffs you can also modify your scripts to use  uci -c /rom/etc/config/ export ...  as original file
Feb 22 23:43:30 <philipp64|laptop> what does that do?
Feb 22 23:44:03 <jow_laptop> output the canonical form of a given config file
Feb 22 23:44:34 <philipp64|laptop> ah.
Feb 22 23:45:58 <philipp64|laptop> well, I'll write the patch for libuci... what characters need to be protected? I'm thinking []{}()*?$|><#\"!&~`;
Feb 22 23:47:38 <nbd> any output that is used by the shell code should still be fully quoted
Feb 22 23:48:06 <nbd> don't forget whitespaces, those would need to be quoted as well
Feb 22 23:48:38 <nbd> either way, i don't really see any real need for such a patch
Feb 22 23:48:44 <nbd> i think the extra complexity likely isn't worth it
Feb 22 23:48:53 <nbd> especially since you can get the diff properly working the way jow suggested
Feb 22 23:49:07 <nbd> which i think is a much better solution for handling diff anyway
Feb 22 23:49:24 <nbd> since it doesn't just work well with quoting
Feb 22 23:49:31 <nbd> it also ignores comments, whitespace formatting differences, etc.
Feb 22 23:49:43 <jow_laptop> splitnode \o/
Feb 22 23:50:15 <philipp64|laptop> comments and whitespace I don't care about... they're not substantive.
Feb 22 23:50:27 <nbd> yeah, but i really don't see the point in your proposed change
Feb 22 23:50:34 <philipp64|laptop> I just like the idea of the notation being as simple as possible, and being human-readable.
Feb 22 23:50:54 <nbd> i think quoted strings are readable just fine
Feb 22 23:50:59 <philipp64|laptop> well, you can have:
Feb 22 23:51:04 <philipp64|laptop> config network
Feb 22 23:51:07 <nbd> and actually encourage less carelessness when it comes to handling of strings with whitespaces
Feb 22 23:51:08 <philipp64|laptop> config 'network'
Feb 22 23:51:14 <philipp64|laptop> 'config' 'network'
Feb 22 23:51:19 <philipp64|laptop> and they all mean the same thing.
Feb 22 23:51:23 <nbd> 'config' 'network' doesn't make sense
Feb 22 23:51:30 <philipp64|laptop> exactly
Feb 22 23:51:33 <nbd> it doesn't actually like that
Feb 22 23:51:46 <nbd> right now, quotes are used where they make sense
Feb 22 23:51:51 <philipp64|laptop> so much for consistency.
Feb 22 23:51:52 <nbd> i.e. where there could be data that needs quoting
Feb 22 23:52:12 <nbd> section names must not contain characters that would need quoting anyway
Feb 22 23:52:41 <philipp64|laptop> and that's what I'm proposing... using quotes not where they *might* make sense, but where they *do* make sense (i,e, are actually required)
Feb 22 23:53:19 <nbd> i mean on the fields where they make sense
Feb 22 23:53:20 <philipp64|laptop> and yet UCI *does* generate:
Feb 22 23:53:26 <philipp64|laptop> config 'network' ... go figure.
Feb 22 23:53:31 <nbd> yeah
Feb 22 23:53:50 <nbd> that's the section type
Feb 22 23:53:51 <philipp64|laptop> I don't see how that's optimal.
Feb 22 23:53:56 <nbd> i don't care about optimal
Feb 22 23:53:58 <nbd> i'm a pragmatist
Feb 22 23:54:19 <philipp64|laptop> well, pragmatic for me means "what people are least likely to f-up"
Feb 22 23:54:35 <nbd> yeah, and the current way is in line with that
Feb 22 23:54:50 <nbd> within a config file with lots of quoted strings, people are likely to add new options as quoted strings as well
Feb 22 23:55:01 <nbd> and as such, they don't have to think about whether the quotes are necessary or not
Feb 22 23:55:12 <nbd> => less error potential
Feb 22 23:55:28 <philipp64|laptop> ok, so what's the chance of base-files and files getting canonicalized in the source tree?
Feb 22 23:56:10 <nbd> i wouldn't mind patches that do that
Feb 22 23:56:25 <nbd> i think it's better than patching uci
Feb 22 23:56:59 <nbd> either way, i'm off to bed now... bbl
Feb 22 23:57:02 <philipp64|laptop> wireless and other subsystems that crank out files would need to be patched too.
Feb 22 23:57:26 <philipp64|laptop> ok. night.
Feb 22 23:57:28 <nbd> the wireless stuff is going to be rewritten after switching to netifd anyway
Feb 22 23:58:03 <nbd> it'll probably start using libuci to manage generated template configs then
Feb 23 00:01:06 <philipp64|laptop> so "uci ... export network" generates:
Feb 23 00:01:08 <philipp64|laptop> config 'interface' 'lan'
Feb 23 00:01:25 <philipp64|laptop> 	option 'ifname' 'eth0.1'
Feb 23 00:01:52 <philipp64|laptop> I'm assuming that the only quotes that are really strictly required are the ones around 'eth0.1', right?
Feb 23 00:02:35 <philipp64|laptop> because the fields for 'interface', 'lan', and 'ifname' can never contain anything but an identifier.
Feb 23 00:03:30 <jow_laptop> I would support removing quotes from section types and option/list names, so that they're only left around values
Feb 23 00:04:37 <philipp64|laptop> works for me.
Feb 23 00:05:55 <philipp64|laptop> where is libuci? in package?
Feb 23 00:06:04 <jow_laptop> package/uci/
Feb 23 00:06:13 <jow_laptop> it references a git repo
Feb 23 00:08:28 <jow_laptop> to clarify, package/uci provides uci, libuci and libuci-lua
Feb 23 00:14:08 <philipp64|laptop> hmmm... http://fpaste.org/vC8p/
Feb 23 01:54:53 <philipp64|laptop> jow_laptop: done!
**** ENDING LOGGING AT Thu Feb 23 02:59:58 2012