**** BEGIN LOGGING AT Tue Aug 02 02:59:57 2011 **** BEGIN LOGGING AT Tue Aug 02 03:41:18 2011 Aug 02 08:33:58 <_trine> EqUaTe, how did you get on with the asterisk problem? Aug 02 08:36:50 decided to put it on hold while i got as much as possible built Aug 02 08:37:02 and then come back to it Aug 02 08:38:03 so i turned off that module. also had to turn off batmand, and so far a couple of freeswitch modules Aug 02 09:27:37 nbd * r27873 /packages/lang/ruby/Makefile: ruby: add missing dependency on librt (#9867) Aug 02 09:53:59 jogo * r27874 /trunk/ (5 files in 2 dirs): Aug 02 09:54:00 kernel: Fix firewire for 2.6.37+ Aug 02 09:54:00 The old ieee1394 stack was removed in 2.6.37. The new firewire stack is Aug 02 09:54:00 available for all kernel versions, but experimental for the older one, so Aug 02 09:54:00 make both available where appropriate. Aug 02 09:58:57 jogo * r27875 /trunk/target/linux/generic/config-3.0: Aug 02 09:58:57 linux/generic: remove obsolete kernel options from 3.0 Aug 02 09:58:57 Also fix one typo. Aug 02 12:39:16 build #66 of s3c24xx is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/66 Aug 02 12:55:58 nbd: do you think it would make sense to introduce the new /run directory? (currently working on dbus-1.4 upgrade) Aug 02 12:57:21 what for? Aug 02 12:58:42 was /var/run before. stuff like /dev/.udev and such should go there Aug 02 12:59:30 doesn't matter much since /var is tmpfs on openwrt anyway.. Aug 02 13:04:13 all big distros have agreed to it (source: http://lwn.net/Articles/440818/). Most early boot things would start using it AFAIK Aug 02 13:04:17 also http://www.mail-archive.com/slitaz@lists.tuxfamily.org/msg00835.html Aug 02 13:04:26 donno if it fits into the context here Aug 02 13:04:33 we could add a symlink for it Aug 02 13:21:15 sounds like a good idea Aug 02 14:06:14 build #62 of cobalt is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/62 Aug 02 14:13:43 florian * r27876 /trunk/target/linux/rdc/patches-2.6.32/015-r6040_fix_multicast.patch: Aug 02 14:13:43 [rdc] fix r6040 multicast patch, thanks Aug 02 14:13:43 nicolas le falher Aug 02 14:13:56 florian * r27877 /branches/backfire/target/linux/rdc/patches-2.6.30/015-r6040_fix_multicast.patch: backport r27876 Aug 02 14:19:15 hmm is cobalt mips (raq/cube 1 and 2 series) still tested/supported or just regulair mipsel32 builds ? Aug 02 14:28:55 <[florian]> it's tested Aug 02 14:29:03 <[florian]> I run it pretty regularly on qube2 at least Aug 02 15:12:51 nbd * r27878 /trunk/target/linux/ar71xx/patches-2.6.39/910-unaligned_access_hacks.patch: Aug 02 15:12:51 ar71xx: add some hacks to work around the misalignment in IP packets received on AR71xx and AR91xx ethernet MACs Aug 02 15:12:51 decreases CPU load with the default firewall for routing 95 mbit/s from 78% to 55% Aug 02 15:25:06 moo Aug 02 15:26:41 nbd: I assume the cpu load is for ar724x/ar913x with 400 Mhz? Aug 02 15:27:43 nbd: can you please commit patch 1264? Aug 02 15:31:35 * Chocky pokes phillip Aug 02 15:32:04 http://pastebin.com/YDz3gLsP eglibc trunk build. Aug 02 15:32:09 also ndb Aug 02 15:37:11 KanjiMonster: ar9132, forgot to mention that Aug 02 15:46:04 * Chocky just sighs lots Aug 02 15:46:14 how much of an annoyance do I need to make of myself to get my patches accepted Aug 02 15:46:24 nbd. how gpios related to other features than leds and buttons should be exposed? in this case one gpio will change state if power supply voltage goes under 3.5V and another one will control is usb port +5V supply is enabled or not. Aug 02 15:46:45 looks like manufacturer (asus) turns usb power off when input power goes below 3.5 volts Aug 02 15:52:12 [florian]: sad part i had 3 of those mips cobalts (r2) Aug 02 15:52:45 [florian]: but donated them to someone who wanna continue with them for hobby :) Aug 02 16:20:57 anyone knows how /proc/dev/wifi0/switch_com in ath11n works and how i could get that done with ath9k? Aug 02 16:33:21 dangole: what is that supposed to do? Aug 02 16:35:07 nbd: it's fed from the web-interface to switch the antenna (off, horizontal, vertical) Aug 02 16:35:19 what kind of device? Aug 02 16:36:06 that switch_com thing is not a standard atheros 11n driver feature Aug 02 16:36:13 so you'd have to figure out what it does internally Aug 02 16:38:54 i guess it might just control (some of the) the gpio-pins of the ar9285 Aug 02 16:39:24 any way to dump the gpio registers using the 11n driver? Aug 02 16:39:35 what's 'the 11n driver'? Aug 02 16:39:44 ath_11n Aug 02 16:39:45 there's lots of them... Aug 02 16:40:17 based on ap91 Aug 02 16:40:23 still lots of them Aug 02 16:40:38 carrier, fusion, sagittarius, aquila, ... Aug 02 16:40:43 those are the atheros codenames Aug 02 16:40:48 an atheros sdk version might also narrow it down Aug 02 16:41:05 i'll boot the vendor firmware and find out Aug 02 16:41:21 do you have a gpl source for the vendor firmware that you can compile without breaking the wifi driver? Aug 02 16:41:26 also what device are you working on? Aug 02 16:42:15 only got the binary running from the device flash Aug 02 16:42:52 is the device on the market yet? Aug 02 16:43:24 yes, but not sold in europe Aug 02 16:43:50 ok, so it's violating the gpl? or do they tell you to 'request' the sources because they're too lazy to put it on a web page? Aug 02 16:47:52 aparently so, what to do? Aug 02 16:49:11 jtag? Aug 02 16:49:24 or write a program that accesses /dev/mem Aug 02 16:50:05 it got a 6 pin mips jtag header, but i got no mips jtag avail Aug 02 16:50:26 also the part on the board around the jtag seems unpopulated... Aug 02 16:51:29 in the log of the firmware it says Aug 02 16:51:30 ar5416SetSwitchCom, ant switch com = 0xa900120 Aug 02 16:52:17 oh, right. probably they used the internal antenna switching capabilities of the chip Aug 02 16:52:22 so probably no gpio involved Aug 02 16:52:56 so switching will work as soon as i add antenna control api support to ath9l Aug 02 16:53:50 i realized that Aug 02 16:53:51 root@OpenWrt:/# iw phy phy0 set antenna all Aug 02 16:53:51 command failed: Operation not supported (-122) Aug 02 16:57:36 * Chocky pokes nbd Aug 02 17:04:54 Chocky: ? Aug 02 17:05:48 nbd: can you give your current understanding of status of eglibc. Verisons working, size over glibc, and esp. stuff you aren't sure of. Aug 02 17:06:14 not really Aug 02 17:06:25 except that i tried eglibc 2.13 a while ago on mips Aug 02 17:06:27 and it worked Aug 02 17:06:55 was it you who is using it in some production environment and was raving about it, or someone else? Aug 02 17:07:19 must have been someone else Aug 02 17:07:21 i use uclibc Aug 02 17:09:38 do you recall the conversation we had about pthreads and uclibc, say 2 months ago? Aug 02 17:11:17 no Aug 02 17:12:40 what did we talk about? Aug 02 17:12:44 could you be a bit more specific? Aug 02 17:12:51 sec. Aug 02 17:17:06 so, I was finding that pthread_notify (IIRC) was causing one of my threads to exit. This prompted my current use of glibc. Aug 02 17:17:23 I know there's been a version bump recently in uclibc, so perhaps that is fixed Aug 02 17:17:55 right now, libc + libm + libstdc++ = 3MB or so. Aug 02 17:18:02 which is pretty bad Aug 02 17:19:42 yeah, maybe you should try the latest version Aug 02 17:23:01 eglibc will just use libstc++ too, right? Aug 02 17:23:04 there's no eglibc++ Aug 02 17:24:26 libstdc++ is part of the compiler Aug 02 17:24:29 not part of the libc Aug 02 17:24:48 yes, right. Aug 02 17:24:53 <-- too early Aug 02 17:25:08 but uClib++ is separate Aug 02 17:25:10 +c Aug 02 17:26:11 yes Aug 02 17:26:23 it's not a full replacement and it's not built as part of the toolchain Aug 02 17:26:46 but it's sufficiently complete to use against most anything in OpenWrt Aug 02 17:26:52 and hella smaller Aug 02 17:28:33 anyway, the build for eglibc 2.14 and trunk are bust Aug 02 17:28:49 did you try 2.13? Aug 02 17:29:32 I did make a build against that yet. I never tried it on a system, for reasons I forget, nor compared sizes. got distracted, no doubt Aug 02 17:39:26 crap Aug 02 17:39:34 stuff on remote syslog seems out of date Aug 02 17:39:40 how do I enable remote syslog? Aug 02 18:09:00 * Chocky finds it, eventually Aug 02 18:23:13 build #61 of orion is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/61 Aug 02 18:24:17 build #63 of lantiq is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/63 Aug 02 18:56:22 florian * r27879 /trunk/target/linux/generic/patches-3.0/ (2 files): [kernel] refresh 3.0 patches Aug 02 18:56:32 florian * r27880 /trunk/target/linux/brcm63xx/ (33 files in 2 dirs): Aug 02 18:56:32 [brcm63xx] improve BCM6345 support Aug 02 18:56:32 - runtime detect the amount of memory available Aug 02 18:56:32 - define EBI_BASE as MPI_BASE to get rid of chip-select specific hacks Aug 02 18:56:32 - fix GPIO control Aug 02 18:56:37 florian * r27881 /trunk/target/linux/brcm63xx/ (4 files in 2 dirs): [brcm63xx] add support for BCM6345 Ethernet DMA engine Aug 02 18:56:40 moo Aug 02 19:20:49 nbd: that's right, symbol stripping fails with eglibc 2.13. trying now. Aug 02 19:33:09 build #60 of ramips is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/60 Aug 02 19:33:38 symbol stripping hasn't been tested with glibc or eglibc Aug 02 19:33:54 I've tested it with glibc Aug 02 19:34:02 or at least, the build doesn't fail with it Aug 02 19:34:13 it won't strip much Aug 02 19:34:21 fair Aug 02 19:34:24 it only works properly with uclibc Aug 02 19:34:35 and even there it can sometimes break Aug 02 19:52:32 nbd: any news on qos-scripts? Wasn't there a problem with classifying inbound packets since the switch away from IMQ? Aug 02 19:56:30 build #60 of ps3 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ps3/builds/60 Aug 02 19:56:32 build #60 of pxcab is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/pxcab/builds/60 Aug 02 20:03:30 Is there anybody going to work on openwrt support for this one already? http://www.raspberrypi.org/ Aug 02 20:25:03 mb: you! Aug 02 20:32:52 loswillios: I saw it looking through a diff of the two tarballs Aug 02 20:43:35 mb__: Is it possible to get such a device? Aug 02 20:44:32 Hauke: I was planning to get one, once it is released, but I'm probably not able to fully port openwrt. Aug 02 20:44:40 time, etc. Aug 02 20:45:03 But it shouldn't be too hard. Aug 02 20:49:54 the device seems pretty cool, especially because there are about 16 GPIOs which seem to be usable for any external stuff. Aug 02 20:50:31 it looks quite tasty Aug 02 20:52:01 shouldn't it be supported by linux by when it is shipped? Aug 02 20:52:21 sure. They ship with fedora and ubuntu Aug 02 20:52:35 so it will be almost trivial to port openwrt Aug 02 20:52:35 what's the processor? i couldn't immediately see specs Aug 02 20:52:43 some ARM, I guess Aug 02 20:52:45 some armv6 Aug 02 20:52:52 ok Aug 02 20:53:00 that's almost not a challenge Aug 02 20:53:06 :D Aug 02 20:53:28 There seems to be some GPU firmware crap going on, but that seems ok. Aug 02 20:53:35 oh well Aug 02 20:57:20 oh, according to forums the arm is from broadcom - there go the chances of having good documentation available Aug 02 20:57:45 blah Aug 02 20:57:58 * Chocky gives BC a good slapping Aug 02 20:59:22 I thought the goal of this device should be to develop something with it, then it would be stupid to ship this without good documentation. Aug 02 20:59:43 haha Aug 02 21:00:22 * Chocky has give companies abuse of this very matter Aug 02 21:00:25 over Aug 02 21:06:16 build #56 of uml is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/56 Aug 02 21:08:20 ah, it seems to be the BCM2763 Aug 02 21:21:32 build #56 of ppc44x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/56 Aug 02 22:09:49 FWIW (maybe not much) the difference in size between libstdc++.so with various glibc/eglibc versions is only a few bytes. That's perhaps not very surprising Aug 02 22:17:53 libm also about the same size. that's disappointing, since I turned off the high precision stuff Aug 02 22:18:24 and libc itself is only slightly smaller Aug 02 22:19:41 I'd have to conclude that in glibc-2.13 vs eglibc-2.13, eglibc has no credible gain. unknown bugs notwithstanding Aug 02 22:20:06 * Chocky pokes phillip Aug 02 23:07:15 Chocky: the gain is not having drepper in the way of getting fixes comitted :) Aug 02 23:09:38 :o Aug 02 23:09:54 only helps if latest builds for openwrt ;-) Aug 02 23:10:18 roh: and that's quite a big gain ;) Aug 02 23:16:43 https://forum.openwrt.org/viewtopic.php?id=31174 Aug 02 23:16:53 that's my analysis of file sizes Aug 02 23:33:30 jogo * r27882 /trunk/toolchain/uClibc/Config.version: Aug 02 23:33:30 toolchain/uClibc: Make sure there's always a UCLIBC_VERSION_* Aug 02 23:33:30 UCLIBC_VERSION_* was only defined when toolchain options was enabled, Aug 02 23:33:30 breaking packages depending on (not) having certain uClibc versions. Aug 02 23:38:39 jogo * r27883 /branches/backfire/toolchain/uClibc/Config.version: Aug 02 23:38:39 [backfire] toolchain/uClibc: Make sure there's always a UCLIBC_VERSION_* Aug 02 23:38:39 Adapted backport of r27882. **** ENDING LOGGING AT Wed Aug 03 02:59:57 2011