**** BEGIN LOGGING AT Wed Mar 27 02:59:58 2013 Mar 27 04:07:01 build #196 of sibyte is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/196 Mar 27 05:07:42 build #201 of xburst is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/201 Mar 27 06:34:47 build #176 of iop32x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/176 Mar 27 07:18:49 is anyone working on updating lua? Mar 27 07:26:16 build #179 of ep93xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/179 Mar 27 07:40:25 russell--: not that i know of Mar 27 07:46:25 apparently the lnum patch isn't being maintained anymore, leading to some carnage Mar 27 07:47:07 lack of a proper vcs for lua makes tracking their improvements somewhat tedious Mar 27 08:18:55 build #172 of gemini is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/172 Mar 27 10:26:59 cyrusff: what exactly decides which IPv6-sub-prefix is assigned to an interface? Given any /48 prefix, I'd like to assign the xxxx:xxxx:xxxx:0::/64 prefix to lan, and the xxxx:xxxx:xxxx:1::/64 prefix to guest. Currently that is the case for the ULA prefix, but not for the prefix that's assigned once the 6in4 tunnel comes up (0 and 1 are reversed there). Mar 27 10:41:32 sungami: random Mar 27 10:41:39 if you want it fixed don' Mar 27 10:41:52 t use ip6assign but set the prefixes manually using ip6addr Mar 27 10:43:32 jow_laptop: that's what I thought. However, if I set the prefixes manually, they won't adjust to changes of the /48 on the wan-interface. Mar 27 10:43:45 right Mar 27 10:44:46 would it be possible to add some option to uci/netifd to always use a given sub-prefix on a network? Mar 27 10:44:57 possible yes Mar 27 10:45:02 easy? Mar 27 10:45:07 probably not Mar 27 10:46:16 netifd already remembers the sub-prefix across the restart of an interface. Would that be the place to hook a predetermined assignment into? Mar 27 10:46:35 had the idea to allow a syntax like "option ip6asssign 64@0, 64@1 etc. Mar 27 10:46:46 yep. Mar 27 10:46:52 but its up to cyrusff to judge how hard that would be Mar 27 10:47:04 that's why I asked him the question. Mar 27 11:24:30 there are plans to switch to compat-drivers-2013-03-14? Mar 27 11:24:44 eventually we will switch to something newer Mar 27 11:25:57 i'm trying to add a driver for the rtl8192su family but but with current version appears this error: http://pastebin.com/JppYtrdQ Mar 27 11:27:22 looking for the missing definition found this: https://patchwork.kernel.org/patch/2156741/ Mar 27 11:28:22 an this patch seems that was applied since compat-drivers-2013-03-14 Mar 27 11:29:02 the repo of the driver is this: https://github.com/chunkeey/rtl8192su/tree/master/r92su Mar 27 11:37:04 sungami: hmm that is a bit complicated i'm not exactly sure how to solve this, the problem is that we have to deal with a variety of upstream prefix-sizes (e.g. not only /48) and in the future there will probably be a service to furhter distribute prefix parts so that not all ip6assigns will be of size /64. other factors that complicate the matter are interfaces coming up and going down Mar 27 11:37:48 i mean sure it is possible somehow but i'm still looking for the right algorithm here Mar 27 11:42:34 however given that we most likely never need anything greater than a /48 or so i guess i can find some logic Mar 27 11:43:25 can the assignment at least be made predictable? Currently it seems completelty random whether e.g. an interface is assigned the :0: or :1: subnet (assuming two interfaces). In my case, the ULA derived prefix on lan is :0:, but the 6in4 derived one is :1:; on guest it's the other way round. Another router I own at least assigns the same derived subnet numbers to a given interface. Mar 27 11:44:30 yeah i will think about something and probably try it out in the coming weeks or so Mar 27 11:45:52 great. I'd be willing to test anything you come up with, or even dive into netifd code. Any hints where to start there? Mar 27 11:47:34 well if you want the function responsible is "interface_ip_set_prefix_assignment" in interface-ip.c Mar 27 11:47:58 but at the moment there is a different assignment table for each prefix that is the first thing that has to be dealt with Mar 27 11:48:17 which makes sense imo Mar 27 11:48:27 yeah in a way it does Mar 27 11:48:29 "just give them the same numbers" is a simple idea Mar 27 11:48:46 but only on paper :) Mar 27 11:50:01 also when for exmaple supporting specifying the sub-index, something like ip6assign 64@100 to use ...:100:.. Mar 27 11:50:14 what should happen if one prefix is large enough to provide this specific subnet and one not Mar 27 11:50:48 either not assign from the small one at all or use requested index module number of possible sub-prefixes maybe Mar 27 11:51:30 so given a hypothetical /63 , 64@100 -> 100 % 2 -> ...:0:... Mar 27 11:52:32 yeah well there is one thing that bothers me even more: what happens if you have configured an interface to have say :3::/64 and it is suddenly enabled but there is already another interface occupying the same number Mar 27 11:53:11 you'd need to excempt all reserved indexes from auto-random-assignment Mar 27 11:53:45 usign a bitmap or something Mar 27 11:54:27 yeah but then its still unclear how you deal with clashes Mar 27 11:55:05 you don't assign at all and log something like "no address space available for assigning requested prefix :3::/64" Mar 27 11:55:46 how could such a clash happen? as far as I see only during reconfiguration Mar 27 11:56:00 means user just defined new reservations and tries to make them active Mar 27 11:56:08 yeah something like this Mar 27 11:56:11 a full network restart or reboot should cure that Mar 27 11:56:47 well nevertheless it will mean that on a reload we have to recalculate all assignments Mar 27 11:57:02 probably, yes Mar 27 11:57:39 cyrusff: on a semiralted topic, does odhcp6c already support the prefix exclude option from rfc6603? Mar 27 11:58:15 probably not, have to read about it Mar 27 11:59:13 cyrusff: basically to tell in a predix delegation "here's your prefix, but don't use (e.g. because I already assigned you an ip from the subprefix)" Mar 27 11:59:42 oh well this screws up the assignment process even more Mar 27 12:00:03 ok seems we have to do some kind of bitmap Mar 27 12:00:30 hm, we can't actually because one could use different assigment sizes on each iface Mar 27 12:00:42 bitmaps would only work for evenly distributed chunks Mar 27 12:01:33 well pseudo-bitmaps, a sorted linked-list with assignment values and sizes Mar 27 12:01:38 yeah Mar 27 12:01:48 ok Mar 27 12:02:00 the more I think about it the more hairy it gets Mar 27 12:02:07 yeah Mar 27 12:02:07 as usualy with "simple ideas" ;) Mar 27 12:02:41 ip6assign :1::/63 and :2::/64 would intersect for example Mar 27 12:02:57 KanjiMonster: is anybody using / supporting this rfc already? Mar 27 12:03:14 jow_laptop: yeah we just have to log and deny them Mar 27 12:04:10 and we have to do this assignment-list for each prefix individually again Mar 27 12:04:50 cyrusff: I don't think anything supports it yet Mar 27 12:05:11 cyrusff: but if you want to support rfc6603 you need to do it anyway :D Mar 27 12:05:17 yeah right Mar 27 12:05:22 i'm convinced Mar 27 12:05:25 screw ipv6 Mar 27 12:05:32 right, too comple Mar 27 12:05:34 x Mar 27 12:05:51 we have nat and tunnels after all Mar 27 12:06:00 so no need for ipv6 :P Mar 27 12:25:22 jow_laptop: exactly, by just adding another nat layer we can have an infinite number of devices connected! Mar 27 12:34:57 but being serious again, i guess the following is more or less sane: whenever there is a new prefix, at first check for excluded areas, then go through all (active and inactive) interfaces with a preconfigured assignment, then go through all other interfaces with an automatic assignment (and maybe those where the preconfigured failed) Mar 27 12:35:28 and redo this at every netifd reload Mar 27 12:40:21 jogo r36133 trunk/package/base-files/files/sbin/firstboot * base-files: firstboot: only ask for confirmation on TTY Mar 27 12:40:30 jogo r36134 trunk/package/ mac80211/patches/300-pending_work.patch mac80211/patches/702-mwl8k-always-apply-configuration-even-when-device-is.patch mac80211/patches/701-mwl8k-don-t-overwrite-regulatory-settings.patch * mac80211: backport some upstream mwl8k fixes Mar 27 14:08:05 jow r36135 packages/libs/libjpeg-turbo/Makefile Mar 27 14:08:05 drop libjpeg-turbo - nothing depends on it and it breaks any libjpeg using package due to abi mismatches Mar 27 14:09:00 hmm, that's weird ? Mar 27 14:09:44 both libjpeg and libjpeg-turbo install a libjpeg.so into the same location Mar 27 14:09:57 both declare a jpeg-tools package with files that overwrite each other Mar 27 14:09:59 total mess Mar 27 14:10:02 gentoo migrated to libjpeg-turbo, rhel6 migrated to libjpeg-turbo, there are probably others Mar 27 14:10:15 and -turbo *is* faster, afaik Mar 27 14:10:22 I'm fine with migrating to libjpeg-turbo if someones does the proper work doing so Mar 27 14:10:38 I'm not going to fixup this half-assed mess someone dropped at us ina drive-by shooting manner Mar 27 14:10:47 ok Mar 27 14:11:21 stintel: afaict turbo is only faster on x86 and arm implementing the arm-equivalent of mmx Mar 27 14:17:19 <_trine> ra tata tat :) Mar 27 14:25:08 build #159 of octeon is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/159 Mar 27 14:32:23 Kanjimonster: but some MIPS cores has DSP ASE extensions. Doesn't this extensions help? Mar 27 14:32:35 KanjiMonster: but some MIPS cores has DSP ASE extensions. Doesn't this extensions help? Mar 27 14:33:51 <[florian]> they could, but we don't pass -mdsp/-mdspr2 because not all mips32r1 and mips32r2 CPUs implement these instructions Mar 27 14:34:05 <[florian]> and we would like to remain code compatible between these CPUs as much as possible Mar 27 14:34:11 I must improve my english urgently. :( Mar 27 14:35:51 of course. the user must pass this flags Mar 27 14:37:13 <[florian]> then yes, the compiler will certainly emit assembly using DSP related instructions Mar 27 14:37:39 <[florian]> but if you really want to have this optimized you probably need to replace some C function bodies with an assembly counterpart Mar 27 14:37:46 <[florian]> I don't expect GCC to magically optimize everything Mar 27 14:39:17 of course not, but aading -march=24kec -mdsp for a Lantiq danube compilation it performs much better Mar 27 14:39:49 <[florian]> at the expense of loosing binary compatibility Mar 27 14:40:10 <[florian]> how much better does it perform? Mar 27 14:41:00 a colleague calculated more than 15% in openssl speed Mar 27 14:41:22 and mpd worked better Mar 27 14:42:03 <[florian]> interesting Mar 27 14:42:27 openssl is not the best benchmark, but it gives an idea Mar 27 14:43:19 but, as you say, the user must pass the flags he wants Mar 27 14:46:04 the code in openwrt must be as generic as possible. Thanks. Mar 27 14:46:43 <[florian]> you are still given the possibility to optimize for your platform if you want to Mar 27 14:48:02 yes, is the best way: you selects the optimizations you want Mar 27 14:57:58 [Florian], a little collection of popular routers in Spain: http://foro.seguridadwireless.net/openwrt/openwrt-para-roters-astoria-de-ya-com/msg267654/#msg267654 Mar 27 14:58:07 sadly in spanish Mar 27 14:58:56 and a Geode GX based thin client at the bottom Mar 27 15:35:32 hauke r36136 trunk/target/linux/brcm47xx/image/Makefile * brcm47xx: generate images for more WRT...N models Mar 27 15:36:29 hauke r36137 trunk/target/linux/brcm47xx/image/Makefile Mar 27 15:36:29 brcm47xx: activate image generation for some Netgear devices which are on the market and should be supported. Mar 27 15:48:44 hauke r36138 trunk/target/linux/gemini/patches/130-usb-ehci-gemini-fot2gxx-support.patch * gemini: remove usage of ehci_port_power() it was removed in kernel 3.8 Mar 27 15:52:05 hauke r36139 trunk/target/linux/brcm47xx/image/Makefile * brcm47xx: generate images for Linksys E.... models Mar 27 15:54:57 {Nico}: you broke one of my packages… 17 months ago and I did not realize it before today. My fault I guess ;-) Mar 27 16:02:11 nbd: by the way, I just realize that you removed one of the scripts too, 11 months ago https://dev.openwrt.org/changeset/31728/ Mar 27 16:03:02 nbd: again, ok, I should have noticed earlier — but if you don't understand what it is useful for, just email the maintainer instead of "removing, it seems completely useless"… Mar 27 16:06:31 hmm, okay, actually it seem it was really useless Mar 27 16:06:41 I guess this package needs some love Mar 27 16:54:25 nbd: no, actually, it was useful: https://dev.openwrt.org/browser/packages/ipv6/ahcpd/files/ahcpd.init#L71 — I'll revert your removal and add a comment to explain what happens Mar 27 16:55:02 kerneis: it won't even work anymore Mar 27 16:55:08 (not compatible with netifd) Mar 27 16:56:09 also, it doesn't make any sense to have a fake proto that is processed by an init script Mar 27 16:56:50 better to either explicitly list interfaces in the ahcp config (and setting them to proto none or something else that works in the network config) Mar 27 16:56:58 or add an option enable_ahcp 1 Mar 27 16:57:08 bbl Mar 27 16:57:21 the problem is, ahcp is really a daemon Mar 27 16:57:38 you need to have a single one running for all your interfaces Mar 27 16:57:55 right, so list the interfaces in the ahcp config, port the init script to procd Mar 27 16:58:05 and make it call the init script with reload on an ifup event Mar 27 16:58:10 ok Mar 27 16:58:19 procd will detect if the generated command line changed Mar 27 16:58:34 and restart it if necessary Mar 27 16:59:23 procd is an alternative to start-stop-daemon? Mar 27 16:59:26 you can use the dropbear init script as reference Mar 27 16:59:26 yes Mar 27 16:59:45 we're going to replace the use of start-stop-daemon with procd Mar 27 16:59:47 i'll copy/paste this log to a bug report and do this some time next week, thanks Mar 27 17:00:00 because it handles multi-instance stuff better and it can be used to gracefully handle such config reload issues Mar 27 17:00:05 bbl (now really) Mar 27 17:00:06 i'll ping you again if i have any issue Mar 27 17:33:52 "On other types of systems, libjpeg-turbo can still outperform libjpeg by a significant amount, by virtue of its highly-optimized Huffman coding routines." Mar 27 17:37:27 I didn't remove libjpeg-turbo because of performance considerations but because the package wa badly implemented, breaking other libjpeg using packages in non-deterministic ways Mar 27 17:37:51 if someone implements it properly I have no objections merging it again Mar 27 17:38:51 but in the state it was in it broke automated full builds and nobody worked on fixing it, there its disadvantages outweighted the performance improvements Mar 27 19:04:55 jow_laptop: i don't use it directly (that i know of, so i don't have a ready way to test performance advantages)... would you take a patch that just paved over the old one with libjpeg-turbo? Mar 27 19:23:55 russell--: benchmarking libjpeg-turbo is not very difficult, just decode some jpeg image and check the time spent on it, for example on powerpc platform it was ~25% faster for me - http://forums.gentoo.org/viewtopic-p-7050414.html Mar 27 19:25:20 russell--: but on x86 with sse2 and on arm with neon it is expected to be several times faster Mar 27 21:21:45 Hi, can someone copy "trunk/toolchain/eglibc/patches/2.16/200-add-dl-search-paths.patch" in "trunk/toolchain/eglibc/patches/2.17/" Mar 27 21:21:57 same as in https://dev.openwrt.org/changeset/34290/ Mar 27 21:23:43 (i can send a patch but it will not svn copy Mar 27 21:23:45 ) Mar 28 00:55:45 hmm. the build of package/libs/libtool seems to ignore its Makefile's md5sum Mar 28 01:50:16 build #207 of rb532 is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/207 Mar 28 01:51:54 build #207 of ppc44x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/207 **** ENDING LOGGING AT Thu Mar 28 02:59:58 2013