**** BEGIN LOGGING AT Fri Dec 13 03:00:00 2013
Dec 13 03:17:16 <[florian]> heffer: still here?
Dec 13 03:18:14 <DonkeyHotei> i'm here, for a bit
Dec 13 04:12:24 <russell--> still? i just got here! lol.
Dec 13 04:12:41 * russell-- recommends the elimination of timezones
Dec 13 04:14:02 * russell-- submits legislation so that the sun rises at the same time for everyone on the planet
Dec 13 04:33:10 <DonkeyHotei> russell--: you're in my time zone iirc
Dec 13 04:53:58 <russell--> i think so
Dec 13 04:54:07 <russell--> PST
Dec 13 04:56:55 <DonkeyHotei> just one state down
Dec 13 10:21:52 <Pteridium> blogic, luka: i can't confirm it, but seems that early firmwares of the livebox 2.1 were based in supertask, and now switched to uboot+openwrt like the easybox 904
Dec 13 10:23:23 <blogic> ah ok
Dec 13 10:23:33 <blogic> that could explain why 2 versions are floating around
Dec 13 10:25:17 <Pteridium> afaik early firm revisions had some problems
Dec 13 10:26:39 <blogic> ok
Dec 13 10:28:35 <blogic> heffer: ping
Dec 13 10:28:55 <blogic> heffer: https://dev.openwrt.org/ticket/14606 could you try to verify this on one of your 5350 units ?
Dec 13 10:29:10 <blogic> i tested trunk on 3052 5350 7620 and all work
Dec 13 10:29:54 <stintel> jow_laptop: ping
Dec 13 10:30:27 <stintel> nvm :)
Dec 13 10:30:27 <jow_laptop> stintel: pong
Dec 13 10:30:30 <jow_laptop> ok
Dec 13 10:30:41 <stintel> I found it in the fw3 source, had a question about ipset :)
Dec 13 10:34:41 <Pteridium> blogic: the firm in ticket #14606 was compiled with GCC 4.8 linaro, not with the default version
Dec 13 10:35:01 <jow_laptop> stintel: okay, let me know if there're problems withi t
Dec 13 10:35:51 <loblik> blogic: https://lists.openwrt.org/pipermail/openwrt-devel/2013-December/022872.html this is the patch for my board
Dec 13 10:35:54 <blogic> Pteridium: ah
Dec 13 10:36:09 <blogic> Pteridium: nice spotting
Dec 13 10:36:14 <blogic> let me try with 4.8 then
Dec 13 10:36:18 <loblik> will someone taky it? or how do you work here...
Dec 13 10:36:31 <blogic> loblik: yes i was going to reply
Dec 13 10:36:35 <blogic> basically ....
Dec 13 10:36:43 <blogic> the patch is good but a few things stilla re missing
Dec 13 10:36:59 <blogic> you will most likely also want to patch ...
Dec 13 10:37:23 <blogic> target/linux/ramips/base-files/etc/uci-defaults/01_leds
Dec 13 10:37:30 <blogic> target/linux/ramips/base-files/etc/uci-defaults/02_network
Dec 13 10:37:40 <blogic> target/linux/ramips/base-files/lib/ramips.sh
Dec 13 10:38:10 <blogic> target/linux/ramips/base-files/lib/ramips.sh <--- you patched that alread
Dec 13 10:38:21 <blogic> but you should add the 01_leds and 02_network patches aswell
Dec 13 10:38:37 <Pteridium> blogic: i've made the same mistake a lot of times :$
Dec 13 10:42:34 <OpenWrt-Commits> nbd r39038 trunk/include/package-ipkg.mk
Dec 13 10:42:34 <OpenWrt-Commits> build: remove SourceFile and SourceURL from opkg metadata - they are useless without the corresponding openwrt package directory
Dec 13 10:42:39 <OpenWrt-Commits> nbd r39039 trunk/package/system/opkg/patches/090-suppress-blank-provides-field.patch * opkg: do not add blank "Provides:" fields to package metadata
Dec 13 10:43:19 <loblik> blogic: ok. thanks i will look at that
Dec 13 10:55:48 <OpenWrt-Commits> blogic r39040 trunk/target/linux/ (22 files in 10 dirs) * ralink: add mt7621 support
Dec 13 11:00:19 <loblik> blogic: regarding the leds. the board have 5 of them and all works except wifi led. in programming guide they mention pin 72 as WLAN_LED hovever setting pin 72 to low has same effects as setting pin 40 to low. it activates the wan led.
Dec 13 11:00:45 <loblik> so i guess wifi led is not accessible via gpios?
Dec 13 11:04:19 <OpenWrt-Commits> nbd r39041 trunk/package/network/ utils/iw/patches/200-reduce_size.patch utils/iw/Makefile * iw: reduce size and make the phy dump output more readable
Dec 13 11:07:12 <blogic> loblik: nope
Dec 13 11:07:22 <blogic> actually it is
Dec 13 11:07:35 <blogic> hang on ...
Dec 13 11:31:44 <tripolar> nbd: is there a way to use normal openvpn config files directly without uci?
Dec 13 11:32:41 <jow_laptop> https://dev.openwrt.org/browser/trunk/package/network/services/openvpn/files/openvpn.config#L3
Dec 13 11:48:04 <OpenWrt-Commits> kaloz r39042 packages/net/nginx/ patches/300-crosscompile_ccflags.patch Makefile * [nginx]: fix compile errors and upgrade to 1.4.4
Dec 13 12:37:37 <Pteridium> [florian]: i didn't realized that the Cisco EPC3825 has a different bootloader
Dec 13 12:37:52 <Pteridium> somethin called SA bootloader
Dec 13 12:38:19 <Pteridium> SA=Scientific Atlanta i guess
Dec 13 12:42:05 <loblik> blogic: so is it some kind of offset overflow? i don't understand why these two pins do the same thing
Dec 13 12:47:11 <blogic> overflow of what kind ?
Dec 13 12:51:06 <loblik> i don't know much about the architecture and how gpio are accessed. i tought it could be a software bug somehow rounding 72 to 40 (base) and setting up wrong pin
Dec 13 12:52:34 <blogic> no
Dec 13 12:52:41 <blogic> the oinmxing is just not setup properly
Dec 13 12:52:50 <blogic> the pinmuxing is just not setup properly
Dec 13 13:40:17 <loblik> blogic: i suspect this is the problem http://sprunge.us/AHSB?diff
Dec 13 13:40:48 <loblik> going to test it properly
Dec 13 14:08:33 <blogic> loblik: i doubt it
Dec 13 14:08:39 <blogic> and i still think its the mux option ;)
Dec 13 14:17:35 <loblik> according to the programming guide. pin 72 data is at address 0x0698 but in the dts file for gpio2 there is base 0x0660 and length only 0x24.
Dec 13 14:18:23 <loblik> so it seem to me the length does not cover all the pins. or i'm completly wrong.
Dec 13 14:45:10 <OpenWrt-Commits> luka r39043 packages/net/strongswan/Makefile * [packages] strongswan: add second download mirror
Dec 13 15:04:26 <DonkeyHotei> blogic: you asked me to separate out the wifi eeprom patch so you could fold it into your git tree, then i never heard back
Dec 13 15:10:12 <loblik> blogic: what should i try then? whatever what i do echo 0 > gpio72/value still lights up wan led (same as gpio 40)...
Dec 13 15:18:41 <zajec> can someone help me to compile hello world application, please?
Dec 13 15:18:44 <zajec> Package zajec-hello is missing dependencies for the following libraries:
Dec 13 15:18:46 <zajec> libc.so.6
Dec 13 15:18:58 <zajec> my OpenWrt packages has:
Dec 13 15:19:00 <zajec> DEPENDS:=+libgcc +libc
Dec 13 15:19:09 <zajec> what am I missing./
Dec 13 15:25:55 <FriedZombie> https://forum.openwrt.org/viewtopic.php?id=44844
Dec 13 15:28:08 <jow_laptop> zajec: your package was not cross compiled
Dec 13 15:28:28 <jow_laptop> zajec: either because CC is not correctly set or because the source dir you try to cross compile already contains binaries built for your host
Dec 13 15:28:49 <jow_laptop> zajec: libc.so.6 is from the GNU libc of your host system
Dec 13 15:29:20 <jow_laptop> zajec: make sure the source dir is clean and check if the CC invoked by make is the cross one
Dec 13 15:30:55 <nbd> zajec: you don't need to specify libgcc and libc in your dependencies, those are automatically added
Dec 13 15:37:20 <zajec> i'm doing sth stupid I think
Dec 13 15:37:37 <tripolar> nbd: the wifi is still borken here - the fix you commited for netifd now doesn't crash netifd anymore but the wifi still doenst come up after i bring it up/down a few times
Dec 13 15:37:39 <zajec> is that ok?
Dec 13 15:37:41 <zajec> $(MAKE) -C $(PKG_BUILD_DIR) CC="$(TARGET_CC)" CFLAGS="$(TARGET_CFLAGS) -Wall" LDFLAGS="$(TARGET_LDFLAGS)"
Dec 13 15:37:50 <zajec> ah, wait
Dec 13 15:37:54 <zajec> my Makefile doesn't use CC
Dec 13 15:37:57 <zajec> but uses "gcc"
Dec 13 15:38:41 <zajec> ok
Dec 13 15:38:46 <zajec> sorry for the noise, it's fixed
Dec 13 15:40:29 <nbd> tripolar: please show me the process list and the output of 'wifi status' when it's in that state
Dec 13 15:40:43 <nbd> tripolar: preferably also the output of logread
Dec 13 15:42:37 <tripolar> nbd: http://nopaste.info/a0722b39e7.html
Dec 13 15:47:30 <nbd> there's nothing more in logread?
Dec 13 15:47:34 <nbd> from the up/down attempts?
Dec 13 15:53:53 <tripolar> nbd as it seeems not
Dec 13 15:54:38 <tripolar> nbd: that is the problem - this is the status after the wifi device doesnt come up
Dec 13 15:54:44 <nbd> what happens if you run 'wifi; wifi status'?
Dec 13 15:54:47 <nbd> an then logread
Dec 13 15:56:16 <tripolar> nbd wifi alone seems to work - wifi reload not - at least after some time it doesnt
Dec 13 15:56:56 <tripolar> some time == a few starts and stops
Dec 13 15:57:18 <nbd> wifi reload is not supposed to start an interface that is down
Dec 13 15:57:43 <tripolar> ahh okay
Dec 13 15:57:46 <tripolar> thanks nbd
Dec 13 15:57:59 <nbd> it only reloads the config
Dec 13 15:58:19 <nbd> since you're saying the issue is with bringing the device up/down
Dec 13 15:58:34 <nbd> how do you bring it up and down?
Dec 13 16:01:10 <tripolar> nbd: i used wifi down to bring it down and "wifi reload" and ubus call network reload
Dec 13 16:01:18 <tripolar> to bring it up
Dec 13 16:01:20 <tripolar> it tried both
Dec 13 16:01:24 <nbd> ah
Dec 13 16:01:32 <nbd> it's normal that this won't work
Dec 13 16:02:07 <tripolar> is wifi is the way to go when its down
Dec 13 16:02:13 <tripolar> is=si
Dec 13 16:02:15 <tripolar> is=so
Dec 13 16:02:23 <nbd> yes
Dec 13 16:02:29 <tripolar> thanks nbd
Dec 13 16:02:30 <nbd> wifi reload is for reloading, not for starting
Dec 13 16:02:33 <nbd> as the name implies ;)
Dec 13 16:02:37 <tripolar> :)
Dec 13 16:35:56 <blogic> loblik: oh ok
Dec 13 16:36:39 <blogic> loblik: i'll try it out in a sec
Dec 13 16:40:58 <OpenWrt-Commits> kaloz r39044 trunk/package/boot/uboot-omap/ patches patches/001-switch_omap4_ext4.patch patches/002-fix_jffs2.patch * [uboot-omap]: fix jffs2 with internal libgcc and switch omap4 to ext4
Dec 13 16:45:20 <OpenWrt-Commits> nbd r39045 trunk/scripts/download.pl
Dec 13 16:45:20 <OpenWrt-Commits> scripts/download.pl: prefer the GNU mirror redirect over the primary site (#14603)
Dec 13 16:45:24 <OpenWrt-Commits> nbd r39046 trunk/package/network/config/netifd/files/etc/init.d/network
Dec 13 16:45:24 <OpenWrt-Commits> netifd: prevent an unnecessary restart of netifd-managed wifi interfaces at boot time
Dec 13 16:45:28 <OpenWrt-Commits> nbd r39047 trunk/package/ utils/usbmode/Makefile utils/usbmode/files/usbmode.hotplug utils/usbmode/files/usbmode.init
Dec 13 16:45:28 <OpenWrt-Commits> usbmode: add an init script to switch devices that show up too early for the hotplug script
Dec 13 16:46:29 <loblik> blogic: but even if i make a length of gpio2 registers bigger it still triggers the wrong led.
Dec 13 16:49:47 <loblik> however adding new group gpio3 like this http://sprunge.us/YdCb?diff helps and finally right led lights up. don't understand why only this way it works.
Dec 13 17:18:12 <blogic> loblik: i'll check the offsets against the datasheet
Dec 13 17:18:18 <blogic> in mt7620a these mappings work
Dec 13 17:18:28 <blogic> thanks for the debugging
Dec 13 17:35:58 <loblik> it works even for me. but pin 72 is not defined in both dts. gpio2@660 covers 32 pins from 40 to 71. so i try to add 72 to gpio2 but it seems to wrap it to the pin 40.
Dec 13 17:36:51 <blogic> indeed there is a gpio72
Dec 13 17:37:00 <blogic> i'll add it to the dtsi files
Dec 13 19:08:26 <loblik> ramips/base-files/etc/uci-defaults/02_network shows some ports which have 't' as suffix...like 6t...does it mean trunk? so the port connected to the cpu?
Dec 13 20:22:06 <jmccrohan> Kaloz: I've had a trivial version bump patch sitting in patchwork for almost two months.. Could I perhaps get commit rights for that package? http://patchwork.openwrt.org/patch/4206/
Dec 13 20:27:11 <jmccrohan> Kaloz: I'd also be happy to spend more time dealing with patches for the packages tree too :)
Dec 14 00:53:54 <swalker> ^ sigh.
Dec 14 01:20:33 <jmccrohan> swalker: have I missed something?
Dec 14 01:39:03 <swalker> jmccrohan: no, that problem is just discouraging given it has been that way for years
**** ENDING LOGGING AT Sat Dec 14 02:59:59 2013