**** BEGIN LOGGING AT Wed Dec 05 02:59:59 2012
Dec 05 11:58:56 <dwmw2_gone> DonkeyHotei: I think I said I'd do the bit that doesn't actually need doing :)
Dec 05 11:59:19 <dwmw2_gone> I was going to fix 'ethtool -i' for br2684 to show what vcc it's connected to
Dec 05 11:59:35 <dwmw2_gone> but then realised that yo uwant to the the MAC address when the nas%d device is *created*, before it's connected. So that would be pointless
Dec 05 12:00:29 <dwmw2_gone> hm, I finally upgraded to AA on my geos for real
Dec 05 12:00:37 <dwmw2_gone> everything seems to work *except* openconnect in luci
Dec 05 12:00:41 * dwmw2_gone wonders if he ever submitted that patch
Dec 05 12:10:54 <OpenWrt-Commits> florian r34499 packages/utils/collectd/patches/130-fix_netlink_kernel_3.3-patch * collectd: remove empty 130-fix_netlink_kernel_3.3-patch file
Dec 05 12:21:26 <DonkeyHotei> dwmw2_gone: i'm sorry, i've completely lost track of what bits need to be done, then
Dec 05 12:37:30 <[florian]> dwmw2_gone: the openconnect luci patch is still in patchwork
Dec 05 12:40:03 <dwmw2_gone> DonkeyHotei: a script (for your platform) in /etc/hotplug.d/net which waits for ACTION==add INTERFACE==nas0 and does 'ip link set $INTERFACE $MACADDRESS' when it's created
Dec 05 12:40:38 <dwmw2_gone> you can get the desired address from /proc/cmdline
Dec 05 12:40:50 <dwmw2_gone> start with that, which will work. And refine it.
Dec 05 12:41:33 <DonkeyHotei> and if something is specified in /etc/config/network, it will override that?
Dec 05 12:41:51 <dwmw2_gone> you should integrate properly with whatever handles /etc/config/network
Dec 05 12:42:15 <dwmw2_gone> you (or someone) said that what handles /etc/config/network was broken. It only handles matching a device by its starting MAC address, not its name
Dec 05 12:42:36 <dwmw2_gone> which is kind of pointless and stupid, since the main reason you'd want to hard-code a MAC address for some device is because it doesn't *have* a stable or unique one...
Dec 05 12:43:00 <nbd> netifd certainly does not match a device by its starting MAC address
Dec 05 12:43:13 <dwmw2_gone> so you'll want to refer to it by some means *other* than its MAC address. Like "the device in PCI slot foo" (available from ethtool -i) or "the device which starts up as eth0" (if you only have one Ethernet on your system anyway)
Dec 05 12:43:30 <DonkeyHotei> nbd: /etc/config/wireless certainly did
Dec 05 12:43:34 <dwmw2_gone> ok, fine. So as long as you can matcb by name, and say "set the MAC address for the device 'nas0' to ..."
Dec 05 12:43:46 <nbd> DonkeyHotei: *did* is the right word ;)
Dec 05 12:43:48 <dwmw2_gone> in that case this whole conversation has been pointless :)
Dec 05 12:43:50 <nbd> it no longer does
Dec 05 12:44:18 <DonkeyHotei> nbd: since what revision, approximately+
Dec 05 12:44:21 <DonkeyHotei> ?
Dec 05 12:44:35 <nbd> DonkeyHotei: 33834
Dec 05 12:44:53 <DonkeyHotei> that's pretty recent
Dec 05 12:44:57 <nbd> it still supports it for compat reason, but new generated configs use the device path instead
Dec 05 12:45:38 <DonkeyHotei> was the race condition fixed too?
Dec 05 12:45:51 <nbd> 'the race condition'?
Dec 05 12:46:14 <DonkeyHotei> the one where it tried to get the name of the bridge before the bridge was created
Dec 05 12:46:39 <nbd> where what tried to get the name of the bridge?
Dec 05 12:47:06 <DonkeyHotei> on boot
Dec 05 12:47:18 <DonkeyHotei> requiring a longer delay
Dec 05 12:47:38 <nbd> please learn to be a bit more specific in what you say
Dec 05 12:47:42 <nbd> i still have no clue what you're talking about
Dec 05 12:48:00 <dwmw2_gone> nbd: does netifd handle getting a mac address from the command line (ethaddr=) too? Or is that done somewhere else.
Dec 05 12:48:24 <dwmw2_gone> that could be done each boot by a script running 'uci', right? Just effective at runtime, not stored?
Dec 05 12:48:25 <nbd> dwmw2_gone: from what command line?
Dec 05 12:48:35 <nbd> netifd takes all of its input from the config file
Dec 05 12:48:36 <dwmw2_gone> kernel command line... that's where some platforms put it, right?
Dec 05 12:49:01 <nbd> userspace doesn't take such things from the kernel command line
Dec 05 12:49:02 <dwmw2_gone> some platforms have a MAC address in main flash (an EEPROM would be more cost)
Dec 05 12:49:18 <nbd> arch code gets the info and uses platform devices to pass it
Dec 05 12:49:18 <dwmw2_gone> it's in nvram, and I *think* it ends up on the kernel command line too?
Dec 05 12:49:45 <nbd> s/platform devices/platform data/
Dec 05 12:50:01 <dwmw2_gone> userspace could find it in nvram and use uci to set it just for that boot, right? Without having to *store* it on the file system?
Dec 05 12:50:10 <dwmw2_gone> and then netifd would see the correct address and use it?
Dec 05 12:50:18 <nbd> what nvram, what platform?
Dec 05 12:50:40 <dwmw2_gone> doesn't matter. I'm speaking of uci behaviour really
Dec 05 12:51:04 <dwmw2_gone> let's assume that a startup script picks it out of thin air... it can then use uci to set it just for that boot, right, as if it were in the *file* /etc/config/network ?
Dec 05 12:51:13 <dwmw2_gone> and then netifd would set the desired MAC address.
Dec 05 12:51:15 <nbd> on all of the platforms i work with, the kernel extracts the info ensures that userspace doesn't have to do weird fixups
Dec 05 12:51:59 <dwmw2_gone> yeah, but when it gets extended to ATM drivers also using the same hacks it gets horrid and ugly. It really does live in a platform-specific userspace hack. Which *should* be as simple as what I've just described.
Dec 05 12:51:59 <DonkeyHotei> nbd: /etc/init.d/network
Dec 05 12:52:14 <nbd> DonkeyHotei: /etc/init.d/network only starts netifd
Dec 05 12:52:33 <DonkeyHotei>         include /lib/network
Dec 05 12:52:34 <DonkeyHotei>         setup_switch
Dec 05 12:52:34 <DonkeyHotei>         sleep 1
Dec 05 12:52:34 <nbd> DonkeyHotei: and swconfig, /sbin/wifi
Dec 05 12:52:45 <nbd> ah, now i know what you're talking about
Dec 05 12:52:53 <nbd> no, i haven't handled that yet
Dec 05 12:52:59 <nbd> and i won't until i pull in wifi support into netifd
Dec 05 12:54:33 <nbd> or or maybe a separate daemon
Dec 05 12:55:52 <DonkeyHotei> nbd: as for what dwmw2_gone is talking about, blogic was refusing to hack up the kernel for what he thought userspace should do: http://patchwork.openwrt.org/patch/2946/
Dec 05 12:56:46 <nbd> well, that patch is ugly
Dec 05 12:56:52 <nbd> so i'm not surprised that he didn't take it
Dec 05 12:57:07 <DonkeyHotei> i kept asking for better ideas
Dec 05 12:57:20 <DonkeyHotei> it always came down to userspace
Dec 05 12:58:49 <dwmw2_gone> userspace already *has* almost all of what you need to do this
Dec 05 13:00:05 <DonkeyHotei> [Wed 2012-12-05 04:49:01 AM PST] <nbd> userspace doesn't take such things from the kernel command line
Dec 05 13:00:06 <DonkeyHotei> [Wed 2012-12-05 04:49:18 AM PST] <nbd> arch code gets the info and uses platform data to pass it
Dec 05 13:01:09 <DonkeyHotei> nbd: what about /etc/preinit as a compromise?
Dec 05 13:03:46 <dwmw2_gone> all you need to do is run 'uci set network.nas0.macaddr $WHATEVER' at boot, right?
Dec 05 13:03:51 <dwmw2_gone> in a platform-specific script?
Dec 05 13:04:31 <nbd> something like that, but with uci set network.nas0=device before that (to create the section)
Dec 05 13:04:58 <dwmw2_gone> right. That would be done in advance, presumably, rather than each boot.
Dec 05 13:05:14 <nbd> in a uci-defaults script
Dec 05 13:05:17 <dwmw2_gone> does it need to be each boot (is it lost at reboot)? Or just once for the platform?
Dec 05 13:05:30 <nbd> uci-defaults scripts only get called once (and then deleted)
Dec 05 13:06:14 <dwmw2_gone> if the nvram (or whatever) is changed, I suppose that ought to be picked up on the next boot
Dec 05 13:07:11 <DonkeyHotei> the netif in actually created by userspace, though
Dec 05 13:07:25 <DonkeyHotei> s/in/is/
Dec 05 13:07:44 <dwmw2_gone> yeah
Dec 05 13:08:03 <nbd> dwmw2_gone: i don't think it's worth handling that corner case in a hack like this
Dec 05 13:08:31 <nbd> eventually this needs to go away anyway, once the atm driver is cleaned up to use device tree (or at least a platform device)
Dec 05 13:08:51 <DonkeyHotei> that's not likely to be any time soon
Dec 05 13:09:15 <DonkeyHotei> this is a vendor-supplied driver
Dec 05 13:09:29 <dwmw2_gone> it's a common problem. An EEPROM adds to the BOM
Dec 05 13:09:37 <nbd> vendor-supplied, but not vendor-maintained
Dec 05 13:09:40 <dwmw2_gone> better to keep  the MAC address in system flash
Dec 05 13:09:40 <nbd> blogic maintains that stuff
Dec 05 13:10:11 <stintel> DonkeyHotei: what a crazy long timestamp
Dec 05 13:10:23 <DonkeyHotei> stintel: :D
Dec 05 13:10:34 <dwmw2_gone> nbd: isn't it just as easy to run at boot, and set a uci setting temporarily? Or am I misremembering that, and can we not set them temporarily per-boot? Is it always committed to storage?
Dec 05 13:10:49 <nbd> dwmw2_gone: having such info isn't really much of a problem, it's quite common on most of our platforms
Dec 05 13:11:22 <nbd> dwmw2_gone: just on other platforms the kernel/driver code is a bit more sane to handle this
Dec 05 13:11:26 <nbd> without requiring ugly userspace fixups
Dec 05 13:12:04 <DonkeyHotei> nbd: you said yourself an ugly kernelspace fixup is not better
Dec 05 13:12:30 <nbd> DonkeyHotei: good kernel fix >> ugly userspace fix >> ugly kernelspace fix
Dec 05 13:12:39 <dwmw2_gone> there is no good kernel fix for this
Dec 05 13:12:46 <DonkeyHotei> exactly
Dec 05 13:12:57 <dwmw2_gone> unless it really is a device driver with device-tree bindings, and the MAC address can be given in DT
Dec 05 13:13:04 <dwmw2_gone> in which case it isn't even a kernel 'fix' :)
Dec 05 13:13:38 <dwmw2_gone> if a device driver is finding MAC information from somewhere *other* than an EEPROM attached to the device, or device-tree properties, it's a bad kernel hack.
Dec 05 13:13:52 <nbd> well, at some point the device will be registered in DT, and maybe a small platform specific command line handler will fix up the mac address in the DT data
Dec 05 13:14:11 <dwmw2_gone> Since userspace already *has* MAC-override facilities, it's basically a one-liner to run 'uci set net.foo.macaddr' with the right address in userspace. In a platform-specific script
Dec 05 13:14:12 <nbd> so the device driver only cares about the DT data
Dec 05 13:14:27 <dwmw2_gone> eventually that will be nice
Dec 05 13:14:49 <DonkeyHotei> eventually, but until then?
Dec 05 13:14:55 <nbd> userspace fixups would be much nicer if there was a sane way to override the permanent device addr
Dec 05 13:14:59 <nbd> early enough
Dec 05 13:15:07 <nbd> DonkeyHotei: until then we'll a userspace fixup
Dec 05 13:15:12 <dwmw2_gone> que?
Dec 05 13:15:17 <DonkeyHotei> nbd: what about /etc/preinit as a compromise?
Dec 05 13:15:23 <nbd> DonkeyHotei: why?
Dec 05 13:16:03 <DonkeyHotei> it's in userspace, and it's device-specific
Dec 05 13:16:11 <nbd> dwmw2_gone: with nas* devices, you could have any number of them, if you could just fix up the default addr for the ATM device, then those devices would come up with sane defaults
Dec 05 13:16:22 <[florian]> DonkeyHotei: are you aware that we can now throw in scripts that execute during preinit time?
Dec 05 13:16:30 <nbd> DonkeyHotei: you're not making much sense here
Dec 05 13:16:43 <DonkeyHotei> [florian]: that's exactly to which i refer
Dec 05 13:16:47 <nbd> probably because you're talking in way too vague terms
Dec 05 13:16:53 <dwmw2_gone> nbd: but we already have code to set MAC addresses on Ethernet devices
Dec 05 13:17:15 <DonkeyHotei> communication is not my forte
Dec 05 13:17:39 <nbd> dwmw2_gone: yeah, but running a fixup once outside of config is better than having to fix up the config
Dec 05 13:17:47 <dwmw2_gone> I think it *can* be done on ATM devices too; we could do that in userspace instead. But since nobody except br2684 users will care, it seemed saner just to let it get set on the Ethernet device
Dec 05 13:18:25 <nbd> i'd like to limit the amount of auto-generated fluff in the config files to a minimum
Dec 05 13:18:43 <dwmw2_gone> this is why I wanted it to be a transient uci setting, not stored permanently
Dec 05 13:18:51 <dwmw2_gone> is that possibility just something I *imagined*?
Dec 05 13:19:03 <DonkeyHotei> transient uci sounds ugly to me
Dec 05 13:19:09 <nbd> indeed
Dec 05 13:19:13 <nbd> it's ugly
Dec 05 13:19:49 <dwmw2_gone> ok, so a script in /etc/hotplug.d/atm which sets the ESI ?
Dec 05 13:19:49 <nbd> ignoring /var/state, uci only has permanent data (/etc/config) and yet-to-be-committed changes in /tmp
Dec 05 13:19:56 <nbd> yes
Dec 05 13:20:09 <dwmw2_gone> ok, I was probably getting confused with the yet-to-be-committed changes.
Dec 05 13:20:32 <dwmw2_gone> or maybe with /var/state.
Dec 05 13:20:33 <DonkeyHotei> sets the ESI how?
Dec 05 13:20:37 <dwmw2_gone> probably the latter
Dec 05 13:20:44 <nbd> /var/state is ignored by netifd
Dec 05 13:20:45 <dwmw2_gone> DonkeyHotei: with an ioctl?
Dec 05 13:20:48 <nbd> and it's on my list of things to get rid of
Dec 05 13:21:22 <DonkeyHotei> ioctls are not directly accessible from the shell
Dec 05 13:21:29 <dwmw2_gone> with a C program...
Dec 05 13:21:30 <nbd> who cares
Dec 05 13:22:12 <dwmw2_gone> there's an 'esi' tool in linux-atm
Dec 05 13:22:21 <DonkeyHotei> there is?
Dec 05 13:22:56 <nbd> ah, and there's ATM_SETESI and ATM_SETESIF
Dec 05 13:23:09 <nbd> so apparently no kernel changes necessary
Dec 05 13:23:11 <dwmw2_gone> in the last couple of minutes, I looked at kernel's net/atm/ioctl.c and found the ioctl, then grepped in linux-atm build dir for ATM_SETESI and found it in ./src/maint/esi.c
Dec 05 13:23:24 <dwmw2_gone> what do *you* do when you're not typing into the channel? :)
Dec 05 13:23:58 <DonkeyHotei> similar things, but apparently in the wrong places
Dec 05 13:28:37 <DonkeyHotei> the 'esi' tool is part of the atm-debug-tools pkg; requiring that is ugly
Dec 05 13:28:49 <dwmw2_gone> root@geos:~# ./esi -f 000000020305  1
Dec 05 13:28:49 <dwmw2_gone> root@geos:~# cat /sys/class/atm/solos-pci1/address
Dec 05 13:28:49 <dwmw2_gone> 00:00:00:02:03:05
Dec 05 13:28:59 <dwmw2_gone> DonkeyHotei: so move it to another package!
Dec 05 13:29:35 <OpenWrt-Commits> nbd r34500 trunk/package/network/config/netifd/Makefile
Dec 05 13:29:35 <OpenWrt-Commits> netifd: update to latest version, fixes resolv.conf writes on interface setting changes
Dec 05 13:30:27 <[florian]> we could create linux-atm-*foo* packages if that makes you happy
Dec 05 13:30:28 <DonkeyHotei> dwmw2_gone: linux-atm, or br2684ctl?
Dec 05 13:30:34 <[florian]> it's not like it's complicated to template
Dec 05 13:30:49 <DonkeyHotei> [florian]: they already exist
Dec 05 13:31:28 <[florian]> I know, I just propose to split the various atm-debug-tools into atm-esi atm-foo atm-bar each of them containing a single tool
Dec 05 13:31:34 <[florian]> and keep the "meta" package debug-tools for instance
Dec 05 13:31:40 <dwmw2_gone> makes sense
Dec 05 13:32:04 <DonkeyHotei> nbd: what say you?
Dec 05 13:33:22 <nbd> makes sense
Dec 05 13:33:47 <DonkeyHotei> trivial change
Dec 05 13:33:56 <DonkeyHotei> who's doing it?
Dec 05 13:34:51 <[florian]> I can do it within the next few minutes
Dec 05 13:35:25 <dwmw2_gone> could definitely do with ppp connect being triggered by ATM link being dertected
Dec 05 13:38:11 <nbd> maybe i should add some ATM awareness to netifd
Dec 05 13:38:44 <DonkeyHotei> nbd: thing is, ar7 has its own esi-setting code
Dec 05 13:39:12 <nbd> so?
Dec 05 13:39:30 <DonkeyHotei> nvm
Dec 05 13:40:20 <nbd> i could probably even make netifd replace the scripted use of br2684ctl
Dec 05 13:40:32 <nbd> thus also making it config reload safe
Dec 05 13:46:27 <DonkeyHotei> i don't want to make a default based on the behavior of only one device, but i can't seem to get a serial console on the gigaset
Dec 05 13:46:36 <DonkeyHotei> Delboy: how did you do it?
Dec 05 14:18:45 <OpenWrt-Commits> florian r34501 trunk/target/linux/ (6 files in 2 dirs) * kernel/3.3: move OHCI and EHCI platform drivers to generic
Dec 05 14:18:48 <OpenWrt-Commits> florian r34502 trunk/package/linux-atm/Makefile * linux-atm: package each available atm debug tool individually
Dec 05 14:22:47 <[florian]> DonkeyHotei: there you go, now you can hack something around esi
Dec 05 14:37:43 <OpenWrt-Commits> florian r34503 trunk/package/linux-atm/Makefile * linux-atm: fix typo introduced in r34502
Dec 05 14:43:09 <DonkeyHotei> [florian]: adding atm-esi to DEFAULT_PACKAGES+= in target/linux/lantiq/ar9/target.mk has no effect; why?
Dec 05 14:43:43 <[florian]> because you also need to select linux-atm
Dec 05 14:43:52 <DonkeyHotei> it's in there already
Dec 05 14:44:28 <[florian]> I don't think the config gets re-generated anytime a profile is updated
Dec 05 14:44:31 <DonkeyHotei> DEFAULT_PACKAGES+=kmod-pppoa ppp-mod-pppoa linux-atm atm-esi atm-tools br2684ctl kmod-ltq-dsl-ar9 ltq-dsl-app kmod-input-gpio-keys-polled kmod-ledtrig-netdev kmod-leds-gpio kmod-button-hotplug swconfig
Dec 05 14:44:40 <[florian]> so you might need to rmemove your .config file first
Dec 05 14:44:46 <DonkeyHotei> tried that
Dec 05 14:44:49 <DonkeyHotei> no effect
Dec 05 14:45:36 <[florian]> well there must be something specific to your setup
Dec 05 14:45:40 <[florian]> because that just works for me
Dec 05 14:45:54 <DonkeyHotei> you tried it exactly that way?
Dec 05 14:46:27 <DonkeyHotei> what happens when you do 'grep esi .config' ?
Dec 05 14:48:14 <DonkeyHotei> 'grep atm-tools .config' yields:
Dec 05 14:48:14 <DonkeyHotei> CONFIG_DEFAULT_atm-tools=y
Dec 05 14:48:15 <DonkeyHotei> CONFIG_PACKAGE_atm-tools=y
Dec 05 14:48:54 <DonkeyHotei> 'grep atm-esi .config' yields:
Dec 05 14:48:54 <DonkeyHotei> CONFIG_PACKAGE_atm-esi=y
Dec 05 14:49:31 <DonkeyHotei> nbd: any ideas?
Dec 05 14:50:13 <[florian]> indeed there is something fishy here
Dec 05 14:50:21 <[florian]> it does not work on lantiq, I tried with another target
Dec 05 14:54:25 <[florian]> ls
Dec 05 14:54:28 <[florian]> whops
Dec 05 14:59:33 <OpenWrt-Commits> florian r34504 trunk/package/linux-atm/Makefile * linux-atm: put all packages into their own submenus
Dec 05 15:03:49 <DonkeyHotei> [florian]: that didn't fix it
Dec 05 15:04:05 <[florian]> it was not meant to fix anything but make menuconfig prettier
Dec 05 15:32:15 <nbd> DonkeyHotei: after changing the profile, touch the target Makefile
Dec 05 15:34:17 <DonkeyHotei> nbd: worked, thx
Dec 05 15:35:54 <OpenWrt-Commits> nbd r34505 branches/attitude_adjustment/package/netifd/Makefile * netifd: update to latest version from trunk, as of r34500
Dec 05 15:38:56 <Delboy> DonkeyHotei: does your sx762 board look the same as the one on the wiki?
Dec 05 15:50:08 <DonkeyHotei> Delboy: yes
Dec 05 15:54:48 <fullstop> Got a serial console on the WZR-300HP
Dec 05 15:56:01 <fullstop> They did not connect the 3.3V supply on the serial header.  There was an 0402 resistor not placed directly adjacent.  I bridged it with some wire and the console came up.
Dec 05 16:01:34 <DonkeyHotei> fullstop: i'm using a usb to 3.3V dongle, so that shouldn't matter in my case
Dec 05 16:03:08 <fullstop> I have some old sipex transceiver connected to a usb <-> RS-232 adapter.
Dec 05 16:03:23 <DonkeyHotei> figured
Dec 05 16:06:07 <DonkeyHotei> [Wed 2012-12-05 05:19:50 AM PST] <dwmw2_gone> ok, so a script in /etc/hotplug.d/atm which sets the ESI ? <----- hotplug doesn't seem to have that, nbd
Dec 05 16:08:06 <nbd> hotplug doesn't seem to have what, DonkeyHotei
Dec 05 16:08:21 <DonkeyHotei> atm events
Dec 05 16:08:31 <nbd> how did you figure that?
Dec 05 16:08:38 <DonkeyHotei> no atm dir
Dec 05 16:08:50 <nbd> mkdir
Dec 05 16:09:13 <DonkeyHotei> and the events will just magically appear?
Dec 05 16:09:37 <nbd> it has nothing to do with magic, or the directory itself
Dec 05 16:10:07 <DonkeyHotei> then it could just go in iface
Dec 05 16:10:08 <nbd> from hotplug2.rules:
Dec 05 16:10:08 <nbd> SUBSYSTEM ~~ (^net$|^input$|^button$|^usb$|^ieee1394$|^block$|^atm$|^zaptel$|^tty$) { exec /sbin/hotplug-call %SUBSYSTEM%
Dec 05 16:10:12 <nbd> }
Dec 05 16:10:18 <DonkeyHotei> oh, nvm
Dec 05 16:10:37 <nbd> so atm is the right dir
Dec 05 16:10:42 <nbd> but creating it doesn't cause the events to appear
Dec 05 16:10:54 <nbd> having a script inside it means hotplug-call finds something to call when an atm event shows up
Dec 05 16:11:01 <DonkeyHotei> there is no iface rule in the above
Dec 05 16:11:15 <nbd> iface events were always virtual
Dec 05 16:11:19 <nbd> generated from user space, not the kernel
Dec 05 16:11:20 <DonkeyHotei> ok
Dec 05 16:20:28 <DonkeyHotei> Delboy: ideas?
Dec 05 16:50:27 <OpenWrt-Commits> nbd r34506 trunk/target/linux/ generic/patches-3.6/307-mips_oprofile_fix.patch generic/patches-3.7/307-mips_oprofile_fix.patch * kernel 3.6+: nuke obsolete patches that are messing up oprofile builds
Dec 05 17:31:40 <OpenWrt-Commits> florian r34507 packages/utils/ sane-backends/Makefile sane-backends/patches/000-upstream-libv4l.patch sane-backends/patches/001-upstream-keep-usb-device.patch * sane-backends: update to 1.0.23
Dec 05 17:31:41 <OpenWrt-Commits> florian r34508 packages/utils/ rsnapshot/patches/001-busybox-logger-i.patch rsnapshot/patches rsnapshot rsnapshot/Makefile * rsnapshot: add rsnapshot backup utility
Dec 05 17:31:44 <OpenWrt-Commits> florian r34509 packages/net/aria2/Makefile * aria2: update do 1.16.0
Dec 05 17:31:48 <OpenWrt-Commits> florian r34510 packages/utils/usb-modeswitch/Makefile * usb-modeswitch: update to 1.2.5
Dec 05 17:31:49 <OpenWrt-Commits> florian r34511 packages/utils/usb-modeswitch-data/Makefile * usb-modeswitch-data: update to 20121109
Dec 05 17:31:50 <OpenWrt-Commits> florian r34512 packages/libs/ libtheora/Makefile libtheora/patches/001-no_docs_tests.patch libtheora/patches/002-no_sdl_check.patch * libtheora: update to 1.1.1
Dec 05 17:31:52 <OpenWrt-Commits> florian r34513 packages/libs/libsoup/Makefile * libsoup: update to 2.38.1
Dec 05 17:31:58 <OpenWrt-Commits> florian r34514 packages/ lang/vala/Makefile lang/vala * vala: add package
Dec 05 17:32:01 <OpenWrt-Commits> florian r34515 packages/libs/ libgee libgee/Makefile * libgee: add package
Dec 05 17:32:02 <OpenWrt-Commits> florian r34516 packages/libs/ gssdp gssdp/Makefile * gssdp: add package
Dec 05 17:32:03 <OpenWrt-Commits> florian r34517 packages/libs/ gupnp gupnp/Makefile * gupnp: add package
Dec 05 17:32:06 <OpenWrt-Commits> florian r34518 packages/libs/ gupnp-av/Makefile gupnp-av * gupnp-av: add package
Dec 05 17:32:09 <OpenWrt-Commits> florian r34519 packages/libs/ gupnp-dlna gupnp-dlna/Makefile * gupnp-dlna: add package
Dec 05 17:32:12 <OpenWrt-Commits> florian r34520 packages/multimedia/gstreamer/Makefile * gstreamer: update to 0.10.36
Dec 05 17:32:15 <OpenWrt-Commits> florian r34521 packages/multimedia/gst-plugins-base/Makefile * gst-plugins-base: update to 0.10.36
Dec 05 17:32:18 <OpenWrt-Commits> florian r34522 packages/multimedia/ gst-plugins-ugly/Makefile gst-plugins-ugly/patches/003-no_translations.patch gst-plugins-ugly/patches/002-no_tests.patch gst-plugins-ugly/patches/001-no_docs.patch * gst-plugins-ugly: update to 0.10.19
Dec 05 17:32:22 <OpenWrt-Commits> florian r34523 packages/multimedia/gst-plugins-good/Makefile * gst-plugins-good: update to 0.10.31
Dec 05 17:32:25 <OpenWrt-Commits> florian r34524 packages/multimedia/gst-plugins-bad/Makefile * gst-plugins-bad: update to 0.10.23
Dec 05 17:32:28 <OpenWrt-Commits> florian r34525 packages/libs/ gupnp-vala/patches/010-no-tests.patch gupnp-vala/Makefile gupnp-vala/patches gupnp-vala * gupnp-vala: add package
Dec 05 17:32:32 <OpenWrt-Commits> florian r34526 packages/multimedia/gst-plugins-bad/Makefile * gst-plugins-bad: build the gstreamer faad plugin
Dec 05 17:32:35 <OpenWrt-Commits> florian r34527 packages/libs/ faad2/Makefile faad2/Config.in * faad2: add configurable fixed point build
Dec 05 17:32:38 <OpenWrt-Commits> florian r34528 packages/multimedia/ (15 files in 7 dirs) * rygel: add package
Dec 05 18:04:58 <OpenWrt-Commits> florian r34529 packages/libs/ libsml/Makefile libsml/patches/030-cross-compile.patch libsml/patches/030-cross_compile.patch * libsml: update to 0.2
Dec 05 18:05:43 <OpenWrt-Commits> florian r34530 trunk/package/libs/libiconv-full/Makefile * libiconv-full: add clause to Makefile to actually install iconv
Dec 05 18:23:00 <DonkeyHotei> Delboy: well?
Dec 05 19:07:27 <Delboy> DonkeyHotei: have you checked voltages on those pins, maybe serial is somehow
Dec 05 19:07:54 <DonkeyHotei> what should the voltages be?
Dec 05 19:07:55 <Delboy> also gnd is 4th pin from the top
Dec 05 19:08:04 <Delboy> around 3.3
Dec 05 19:08:18 <DonkeyHotei> i used the middle pin for gnd
Dec 05 19:08:33 <DonkeyHotei> it is definitely grounded
Dec 05 19:14:58 <DonkeyHotei> Delboy: the one you marked Rx is in the vicinity of 3.3 but the one you marked Tx is 0.05
Dec 05 20:12:37 <DonkeyHotei> nbd: hotplug does not generate atm events
Dec 05 20:22:24 <Delboy> DonkeyHotei: just checked my pins, both are around 3.3v
Dec 05 20:22:49 <DonkeyHotei> and they are in the exact spots in the pic?
Dec 05 20:23:15 <Delboy> yes
Dec 05 20:23:18 <DonkeyHotei> maybe they differ from 762 to 763
Dec 05 20:23:40 <DonkeyHotei> i might try resoldering that one if not
Dec 05 20:25:56 <Delboy> DonkeyHotei: this is on sx762: http://tau.rghost.ru/42036894/image.png
Dec 05 20:27:00 <DonkeyHotei> Delboy: too blurry to be of much use
Dec 05 20:27:48 <Delboy> i got that from someone some time ago, when i asked him where serial pins are
Dec 05 20:49:28 <swalker> [florian]: care to fix https://dev.openwrt.org/browser/packages/libs/radlib/Makefile?rev=34530#L16?
Dec 05 20:50:42 * swalker thought the plan was to limit new package additions
Dec 05 20:54:08 <swalker> [florian]: https://dev.openwrt.org/browser/packages/multimedia/rygel/Makefile#L16 as well
**** ENDING LOGGING AT Thu Dec 06 02:59:58 2012