**** BEGIN LOGGING AT Fri Apr 09 02:59:56 2010
Apr 09 03:16:01 <CIA-39> swalker * r20749 /packages/net/darkstat/Makefile: [packages] darkstat: update to 3.0.713, use PKG_INSTALL and Build/Compile/Default, fix now invalid configure argument, description display and title typo
Apr 09 08:38:49 <CIA-39> juhosg * r20750 /trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ (ag71xx.h ag71xx_main.c):
Apr 09 08:38:49 <CIA-39> ar71xx: ag71xx: call the phy driver's netif_receive_skb()
Apr 09 08:38:49 <CIA-39> Ag71xx needs to call the phy's netif_receive_skb() to allow phy drivers
Apr 09 08:38:49 <CIA-39> to mangle rx packets. This patch fixes it.
Apr 09 08:38:49 <CIA-39> This fixes the header mangling of the AR8216 driver.
Apr 09 08:38:49 <CIA-39> Signed-off-by: Jonas Gorski <jonas.gorski+openwrt@gmail.com>
Apr 09 08:38:50 <CIA-39> Cc:backfire@openwrt.org
Apr 09 08:40:08 <CIA-39> juhosg * r20751 /trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ (ag71xx.h ag71xx_main.c):
Apr 09 08:40:08 <CIA-39> ar71xx: ag71xx: avoid unalinged accesses when using the phy specific receive functions
Apr 09 08:40:08 <CIA-39> Cc: backfire@openwrt.org
Apr 09 08:40:11 <CIA-39> juhosg * r20752 /trunk/target/linux/ar71xx/ (5 files in 3 dirs):
Apr 09 08:40:11 <CIA-39> ar71xx: make the AR8216 driver usable on the TEW-632BRP/DIR-615-Cx boards
Apr 09 08:40:11 <CIA-39> Cc: backfire@openwrt.org
Apr 09 08:40:14 <CIA-39> juhosg * r20753 /trunk/target/linux/generic-2.6/files/drivers/net/phy/ar8216.c:
Apr 09 08:40:14 <CIA-39> generic: make chip detection more reliable in the AR8216 driver
Apr 09 08:40:14 <CIA-39> Fixes broken ethernet on the Planex MZK-W04NU/W300NH boards.
Apr 09 08:40:14 <CIA-39> Cc: bacfire@openwrt.org
Apr 09 08:40:20 <CIA-39> juhosg * r20754 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/ (mach-mzk-w04nu.c mach-mzk-w300nh.c):
Apr 09 08:40:20 <CIA-39> ar71xx: update phy masks for the Planex boards
Apr 09 08:40:20 <CIA-39> This avoids probing of the AR8216 chip on the eth0 interface.
Apr 09 08:40:20 <CIA-39> Cc: backfire@openwrt.org
Apr 09 09:00:13 <Acinonyx> gmonring
Apr 09 10:25:11 <CIA-39> ralph * r20755 /trunk/package/ifxmips-dsl-api/Makefile: [ifxmips-dsl-api] fix firmware handling
Apr 09 10:44:50 <CIA-39> ralph * r20756 /trunk/package/uboot-lantiq/ (6 files in 2 dirs):
Apr 09 10:44:50 <CIA-39> [uboot-lantiq] update to version 2010.3
Apr 09 10:44:50 <CIA-39> httpd-failsafe: removed warnings, cleanup html pages
Apr 09 10:44:50 <CIA-39> httpd-failsafe: kicking in if boot command fails
Apr 09 10:44:50 <CIA-39> httpd-failsafe: support of ctrl-c
Apr 09 10:44:51 <CIA-39> httpd-failsafe: fixed ether addr
Apr 09 10:44:51 <CIA-39> thanks to Stas
Apr 09 11:31:20 <CIA-39> acoul * r20757 /trunk/target/linux/x86/generic/config-default: x86: generic: fix soekris support (closes #7081)
Apr 09 11:38:20 <CIA-39> acoul * r20758 /branches/backfire/target/linux/x86/generic/config-default: [backfire] merge r20757
Apr 09 12:06:03 <CIA-39> juhosg * r20759 /branches/backfire/target/linux/ar71xx/files/drivers/net/ag71xx/ (ag71xx.h ag71xx_main.c):
Apr 09 12:06:03 <CIA-39> backfire: ar71xx: ag71xx: call the phy driver's netif_receive_skb() (backport of r20750)
Apr 09 12:06:03 <CIA-39> Ag71xx needs to call the phy's netif_receive_skb() to allow phy drivers
Apr 09 12:06:03 <CIA-39> to mangle rx packets. This patch fixes it.
Apr 09 12:06:03 <CIA-39> This fixes the header mangling of the AR8216 driver.
Apr 09 12:06:04 <CIA-39> Signed-off-by: Jonas Gorski <jonas.gorski+openwrt@gmail.com>
Apr 09 12:06:08 <CIA-39> juhosg * r20760 /branches/backfire/target/linux/ar71xx/files/drivers/net/ag71xx/ (ag71xx.h ag71xx_main.c): backfire: ar71xx: ag71xx: avoid unalinged accesses when using the phy specific receive functions (backport of r20751)
Apr 09 12:06:13 <CIA-39> juhosg * r20761 /branches/backfire/target/linux/ar71xx/ (5 files in 3 dirs): backfire: ar71xx: make the AR8216 driver usable on the TEW-632BRP/DIR-615-Cx boards (backport of r20752)
Apr 09 12:06:19 <CIA-39> juhosg * r20762 /branches/backfire/target/linux/generic-2.6/files/drivers/net/phy/ar8216.c:
Apr 09 12:06:19 <CIA-39> backfire: generic: make chip detection more reliable in the AR8216 driver (backport of r20753)
Apr 09 12:06:19 <CIA-39> Fixes broken ethernet on the Planex MZK-W04NU/W300NH boards.
Apr 09 12:06:25 <CIA-39> juhosg * r20763 /branches/backfire/target/linux/ar71xx/files/arch/mips/ar71xx/ (mach-mzk-w04nu.c mach-mzk-w300nh.c):
Apr 09 12:06:25 <CIA-39> backfire: ar71xx: update phy masks for the Planex boards (backport of r20754)
Apr 09 12:06:25 <CIA-39> This avoids probing of the AR8216 chip on the eth0 interface.
Apr 09 12:14:54 <rtz2> [florian]: ping
Apr 09 12:15:39 <[florian]> rtz2: pong
Apr 09 12:16:47 <rtz2> [florian]: you remember the problem with the switch on the sitecom?
Apr 09 12:17:06 <[florian]> rtz2: yes
Apr 09 12:19:02 <rtz2> [florian]: there are basically two ways to solv this: 1. write a kinda hackish phy driver like it's currently done for all the other switches
Apr 09 12:19:20 <rtz2> [florian]: 2. add proper switch support to libphy
Apr 09 12:19:43 <rtz2> 2. is better but much harder
Apr 09 12:19:53 <[florian]> rtz2: let's do it the realistic way
Apr 09 12:19:59 <[florian]> rtz2: 1) you write a switch driver
Apr 09 12:20:08 <[florian]> 2) you start discussing your ides on the linux-netdev mailing list
Apr 09 12:20:55 <[florian]> s/ides/ideas/
Apr 09 12:21:13 <rtz2> [florian]: ok, will do
Apr 09 12:21:32 <nbd> and please don't post patches that rewrite 90% of the code in one chunk ;)
Apr 09 12:21:37 <nbd> that doesn't go well with upstream
Apr 09 12:23:28 <KanjiMonster> I have to admit, the DSA in linux looks like the perfect place for switches, but feels quite unmaintained (and lacks too many features to be really usable)
Apr 09 12:23:44 <[florian]> it's too marvell-centric
Apr 09 12:24:18 <rtz2> KanjiMonster: DSA?
Apr 09 12:24:28 <[florian]> distributed switch architecture in net/dsa
Apr 09 12:24:42 <rtz2> I will take a look at it
Apr 09 12:24:49 <[florian]> KanjiMonster: I think it does not fit well with some simpler switches connected via GPIOs or pseudo-phys
Apr 09 12:25:12 <rtz2> nbd: it was mainly a prototype to see if it would work
Apr 09 12:25:21 <KanjiMonster> yeah, it definitely needs to be worked
Apr 09 12:25:47 <[florian]> rtz2: having proper switch support in linux is going to be a tight discussion, since I am pretty sure most people will say "hey, there's dsa, do we need something else?"
Apr 09 12:27:08 <rtz2> there is no drivers/net/dsa
Apr 09 12:27:15 <[florian]> it's net/dsa
Apr 09 12:27:17 <nbd> DSA only handles switches with their own packet format
Apr 09 12:27:23 <nbd> it's not for switches with 802.1q support
Apr 09 12:27:38 <rtz2> ahh, right
Apr 09 12:27:39 <rtz2> thanks
Apr 09 12:28:02 <nbd> also the way it was intended to handle forwarding between ports is quite weird
Apr 09 12:28:14 <nbd> the model is to treat a switch as a 'bridging accelerator'
Apr 09 12:28:26 <nbd> by intercepting bridge config messages and using that to configure the switches
Apr 09 12:28:34 <nbd> which i think is somewhat of a layering violation
Apr 09 12:28:50 <nbd> if switches can do 802.1q and port based vlan, that's a better choice than messing with the bridging layer, imho
Apr 09 12:29:01 <builder> build #38 of ramips is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/38
Apr 09 12:29:06 <nbd> fortunately switches that cannot do 802.1q are pretty rare
Apr 09 12:29:17 <nbd> though unfortunately some switches such as AR8216 need help with that
Apr 09 12:29:18 <acoul> good points
Apr 09 12:29:20 <nbd> because of hw bugs
Apr 09 12:29:38 <nbd> so we need an easy way of hooking switch drivers into the data path
Apr 09 12:30:03 <nbd> but i'd prefer something with less overhead than DSA here
Apr 09 12:30:16 <nbd> since cpu time is precious on embedded stuff
Apr 09 12:30:30 <rtz2> nbd: well, the switch seems to be connected to the mdio bus, so maybe I can extract some common routines and have net/switch/dsa and net/switch/whatever
Apr 09 12:30:37 <nbd> the hack that i did to the phy layer for intercepting tx/rx works, but it probably won't make it upstream (not sure)
Apr 09 12:31:05 <nbd> i don't think we need a net/switch
Apr 09 12:31:06 <_trine> cshore_, are you here?
Apr 09 12:31:22 <[florian]> nbd: having them reside a "special" phy drivers is pretty good
Apr 09 12:31:23 <nbd> the phy layer just needs some minor cleanups and some way of exposing multiple PHYs behind one device
Apr 09 12:31:26 <nbd> in a grogup
Apr 09 12:32:28 <rtz2> nbd: the current problem is also the state machine and the way, linkup/down stuff is handled
Apr 09 12:33:01 <rtz2> nbd: currently it's phy centric, but this wouldn't work for switches
Apr 09 12:33:32 <nbd> this could probably be expanded
Apr 09 12:33:50 <nbd> to add a concept of a phy group
Apr 09 12:34:12 <nbd> inbetween individual PHYs and the ethernet driver
Apr 09 12:34:21 <rtz2> nbd: I tried to do this, but I run into serious problems
Apr 09 12:34:39 <rtz2> nbd: that was the reason I changed libphy so much
Apr 09 12:34:57 <nbd> what problems?
Apr 09 12:34:59 <rtz2> but I don't remember the details, maybe I can come up with something
Apr 09 12:36:31 <rtz2> nbd: I will give it another shoot and will ask you again, once I run into trouble :)
Apr 09 12:36:40 <nbd> ok
Apr 09 12:36:41 <nbd> brb
Apr 09 12:37:04 <rtz2> nbd: but it may take some time
Apr 09 12:37:35 <nbd> btw. i have a suggestion
Apr 09 12:37:43 <nbd> try to make it possible to decouple a phy from an ethernet device
Apr 09 12:38:48 <nbd> then you could attach multiple phy devices (for ports) attaching to one phy device (switch) which then attaches to the ethernet device
Apr 09 12:39:05 <nbd> because that also somewhat matches how the hardware works
Apr 09 12:39:20 <nbd> and parts of the code of the switch phy device could then be moved to library code
Apr 09 12:39:29 <nbd> this might work without too much restructuring
Apr 09 12:52:01 <KanjiMonster> having a way of providing plaform data to a switch driver would be nice too
Apr 09 12:52:28 <[florian]> KanjiMonster: you think about default vlan/port mappings for instance ?
Apr 09 12:53:45 <KanjiMonster> [florian]: for example. or in case of the ar8316, how many ports are actually usable, whether the 5th port is separated, whether it needs special initialization - which is currently hardcoded for it
Apr 09 12:54:07 * jow_laptop wants a way to read switch layouts in userspace (# ports, ...)  :)
Apr 09 12:56:14 <rtz2> once I have a plan of attack, I will collect a wish-list :)
Apr 09 12:56:41 <[florian]> rtz2: would be good yes
Apr 09 12:57:02 <KanjiMonster> jow_laptop: you can get the number of ports already with swconfig dev <dev> help ;)
Apr 09 12:59:09 <jow_laptop> KanjiMonster: okay, this would do the trick, is it safe to assume that the highest port is always the cpu?
Apr 09 12:59:41 <KanjiMonster> jow_laptop: unfortunately no. atheros switches have 0 as the cpu port
Apr 09 13:00:22 <KanjiMonster> the info is already in the switch_dev, but isn't provided by swconfig; so providing this should be a oneliner
Apr 09 13:28:54 <xl0> Hey, guys. Is there a plan to switch to git, or will it always be just an alternative?
Apr 09 13:31:17 <KanjiMonster> jow_laptop: actually, it isn't. cpu_port isn't exposed by the kernel part. I'll see if I can create a patch.
Apr 09 13:31:59 <thepeople> xl0: there are no plans to switch to git
Apr 09 13:32:14 <jow_laptop> KanjiMonster: this would be good
Apr 09 13:32:22 <xl0> ;(
Apr 09 13:32:38 <thepeople> use git-svn if you want to use git as a frontend, or nbd's git mirror
Apr 09 13:33:01 <xl0> That's what I do. ;)
Apr 09 13:33:05 <CIA-39> juhosg * r20764 /trunk/target/linux/ar71xx/ (3 files in 3 dirs): ar71xx: nuke clocksource init patches, it is not required since 2.6.27
Apr 09 13:35:36 <rtz2> [florian]: you still here?
Apr 09 13:35:40 <[florian]> yes
Apr 09 13:37:03 <rtz2> [florian]: I have a question about USB on the ar7
Apr 09 13:37:30 <rtz2> [florian]: I want to connect a printer to it, but it's kinda unclear if it supports usb host mode at all
Apr 09 13:37:43 <rtz2> [florian]: do you have any additional informations about it?
Apr 09 13:38:00 <[florian]> not more unfortunately
Apr 09 13:38:08 <[florian]> but it suppors usb host for sure
Apr 09 13:38:19 <rtz2> [florian]: on all devices?
Apr 09 13:38:27 <rtz2> because I only have a B port
Apr 09 13:38:38 <[florian]> rtz2: not on all devices, on devices which have the usb host connector only
Apr 09 13:38:49 <[florian]> rtz2: it does not do not on-the-go afair
Apr 09 13:39:44 <rtz2> ahh crap
Apr 09 14:08:14 <KanjiMonster> jow_laptop: any suggestions on how to display the cpu port number? I currently have it as "ports: %d (cpu: %d),", but this might be a bit cryptic if don't what it tries to say
Apr 09 14:09:20 <jow_laptop> maybe cpu @ %d
Apr 09 14:10:44 <KanjiMonster> sounds good
Apr 09 14:11:13 <KanjiMonster> now a quick test that it actually works, and then I'll prepare the patch
Apr 09 14:14:44 <jow_laptop> btw, aren't there switches that have unpopulated ports?
Apr 09 14:18:01 <KanjiMonster> there are, the routerstation pro is one of them
Apr 09 14:19:24 <_trine> cshore_, ping
Apr 09 14:24:37 <KanjiMonster> jow_laptop: I think this information would make the help too big - better would be a separate, easier parsable output, where perhaps even the correct internal port -> external label mapping can be provided
Apr 09 14:27:14 <jow_laptop> KanjiMonster: yes, thats waht I meant
Apr 09 14:34:09 <jow_laptop> KanjiMonster: something like "swconfig eth0 explain"
Apr 09 14:34:19 <KanjiMonster> yeah
Apr 09 15:36:37 <KanjiMonster> jow_laptop: how about that one: http://page.mi.fu-berlin.de/jgorski/openwrt/wip/trunk/0002-swconfig-Add-CPU-port-number-to-help-output.patch
Apr 09 15:37:31 <jow_laptop> KanjiMonster: this would be great help already
Apr 09 15:37:36 <jow_laptop> +a
Apr 09 15:51:25 <KanjiMonster> ok, then I'll post it sometime later
Apr 09 18:09:15 <xMff> ping cshore_
Apr 09 18:12:11 <_trine> xMff: I have been waitng th ask cshore_ a question in relation to extroot
Apr 09 18:12:43 <_trine> when you use sysupgrade all the folders on the pendrive get deleted and renewed
Apr 09 18:13:06 <_trine> even for example my asterisk config folder
Apr 09 18:15:30 <xMff> hm
Apr 09 18:15:38 <cshore_> pong _trine, xMff
Apr 09 18:15:45 <xMff> maybe you should disconnect the drive during sysupgrade?
Apr 09 18:15:59 <xMff> cshore_: have you seen the preinit keyec and extroot subdir patches?
Apr 09 18:16:05 <xMff> *kexec
Apr 09 18:16:19 <cshore_> xMff: I haven't look at the closely but they look interesting
Apr 09 18:17:16 <xMff> yep, especially kexec
Apr 09 18:19:37 <cshore_> I'll look at them this weekend
Apr 09 18:20:49 <xMff> no hurry
Apr 09 18:21:22 <cshore_> ok, maybe later then...I'm pretty busy, but I do want to look at those patches....
Apr 09 18:21:50 <maligor> why kexec?
Apr 09 18:22:08 <maligor> isn't that just loading a new kernel from a running one
Apr 09 18:22:20 <cshore_> _trine: for sysupgrade are you also reformatting?
Apr 09 18:22:23 <xMff> maligor: would be interesting to have the on-flash system just serve as a kind of second stage loader
Apr 09 18:22:38 <xMff> maligor: for example for 2mb devices with usb
Apr 09 18:22:41 <_trine> cshore_: not that I know of
Apr 09 18:22:42 <maligor> on what system?-)
Apr 09 18:22:50 <xMff> maligor: it is also great to test newer kernels etc.
Apr 09 18:23:11 <maligor> sure, if you don't have a serial attached
Apr 09 18:23:43 <maligor> oh, right..
Apr 09 18:23:54 <maligor> yeah, never really figured out the uboot usb support
Apr 09 18:23:59 <_trine> cshore_: I have just used sysupgrade openwrt_wrt160nl.bin
Apr 09 18:23:59 <maligor> it's very odd
Apr 09 18:24:00 <cshore_> _trine: oh, wait, you're having your /etc rewritten is what you mean, right?
Apr 09 18:24:12 <_trine> cshore_: yes
Apr 09 18:24:33 <cshore_> _trine: yeah, I have to modify sysupgrade to be extroot-aware
Apr 09 18:24:42 <_trine> cshore_: in /etc I have other folders for other progs
Apr 09 18:24:46 <maligor> using usb for kernel uploads would be very convenient tho, since you can easily replace it
Apr 09 18:25:03 <cshore_> _trine: forget what I said
Apr 09 18:25:21 <cshore_> _trine: the /etc/ issue is where you need to specify folders to save in LuCI
Apr 09 18:25:32 <maligor> I only looked into that with the marvell orion tho, now I just have it loading the kernel directly off the hdd
Apr 09 18:25:46 <maligor> (loading from usb with uboot I mean, not kexec)
Apr 09 18:25:53 <xMff> maligor: or swap systems quickly etc., not a common usecase though
Apr 09 18:25:58 <_trine> cshore_: I don't use luci
Apr 09 18:25:59 <cshore_> _trine:if you're not using LuCI, then currently it won't save anything except some hard-coded dirs and files
Apr 09 18:26:06 <cshore_> brb
Apr 09 18:26:44 <_trine> cshore_: it wiped out my /etc/asterisk/* folder
Apr 09 18:27:03 <_trine> amonst other things
Apr 09 18:27:17 <xMff> from the usb disk?
Apr 09 18:27:25 <_trine> yes
Apr 09 18:27:40 <xMff> so it was connected while you ran sysupgrade?
Apr 09 18:27:44 <_trine> yes
Apr 09 18:27:55 <xMff> well sysupgrade does not know about the overlay
Apr 09 18:28:15 <xMff> but it does not remove stuff
Apr 09 18:28:22 <xMff> just not save everything
Apr 09 18:28:31 <philipp64> xMff: what does one need to do to become a committer?
Apr 09 18:28:42 <xMff> maybe firstboot reformatted your disk?
Apr 09 18:28:54 <xMff> philipp64: ask thepeople, he coordinates this
Apr 09 18:29:12 <philipp64> thepeople: you here?
Apr 09 18:29:44 <KanjiMonster> xMff: I'm thinking about cleaning up the wl500gp article and merging the v2 info, is this ok?
Apr 09 18:29:48 <thepeople> intermintaint pong
Apr 09 18:29:59 <thepeople> philipp64: whats up
Apr 09 18:30:11 <xMff> KanjiMonster: yes, greatly appreciated
Apr 09 18:30:31 <philipp64> thepeople: I'm interested in becoming a committer, and maybe taking ownership of a few things.
Apr 09 18:30:39 <xMff> KanjiMonster: let me move it to the toh before you proceed
Apr 09 18:30:55 <KanjiMonster> ok
Apr 09 18:31:10 <thepeople> philipp64: ok, right now anything in packages/ is open for maintainers, trunk/ is currently maintained by the core devs
Apr 09 18:31:24 <xMff> KanjiMonster: http://wiki.openwrt.org/toh/asus/wl500gp
Apr 09 18:31:33 <KanjiMonster> xMff: great, thanks
Apr 09 18:31:34 <philipp64> thepeople: how about getting my own branch then?
Apr 09 18:31:36 <cshore_> thepeople: btw would it be possible for me to become a core dev?
Apr 09 18:32:20 <philipp64> I'm adding the net5501 support... was going to add net6501 support, and Traverse Technologies GEOS support...
Apr 09 18:32:35 <philipp64> kind of a pain to have to send in patches and have someone else commit them.
Apr 09 18:32:52 <philipp64> I could commit to a private branch and have the core devs pick them upstream...
Apr 09 18:33:12 <philipp64> just a thought.
Apr 09 18:33:45 <cshore_> philipp64: it's a pain, but it's the way I've working for many months now
Apr 09 18:33:50 <KanjiMonster> git sendemail makes it quite easy to spam openwrt-devel with patches
Apr 09 18:33:54 <thepeople> philipp64: I have no hard rules to becoming a core dev, but to start with if you could submit patches it would be good, as far as a branch you are the first to ask about that so I would have to run it by the devs, I wouldn't get your hopes up for that
Apr 09 18:34:08 <thepeople> cshore_: I will run it by the devs
Apr 09 18:34:17 <cshore_> thepeople: thank you
Apr 09 18:34:48 <thepeople> philipp64: if you are around for awhile doing patches and generally helping, it is more likely to happen
Apr 09 18:34:50 <philipp64> thepeople: ok, I'm already a core dev on astlinux, and a contributor to Fedora...
Apr 09 18:35:05 <philipp64> and CPAN and Arno's Iptables firewalll...
Apr 09 18:35:32 <cshore_> thepeople: also, if you seed {Nico} before me, could you ask him how he feels about my maintaining freeswtich.  He doesn't have much time right now, and I now have 1.0.6 working and am ready to commit it to packages, but don't want to step on his toes
Apr 09 18:35:41 <cshore_> I have packages commit access
Apr 09 18:35:43 <philipp64> well, I'm tired of maintaining the build environment for astlinux... and we've diverged too much from buildroot (v1).
Apr 09 18:36:12 <cshore_> seed = see
Apr 09 18:36:16 <philipp64> so I was thinking that it would be easier to build our stuff on top of openwrt... that way I don't have to maintain linux, uclibc, gcc, binutils, etc.
Apr 09 18:36:28 <[florian]> ali1234: your fix works for me on my device, good job!
Apr 09 18:36:31 <_trine> cshore_: freeswitch is good news
Apr 09 18:36:31 <philipp64> I can focus on platforms and the particular packages we own.
Apr 09 18:37:32 <xMff> philipp64: would it be a derivate like packetprotektor or do you intend to get everything fully integrated?
Apr 09 18:38:04 <thepeople> philipp64: can you send me your name, I know some devs are currently aprehensive about adding more people to trunk/ but I will run it by them
Apr 09 18:38:07 <philipp64> integrated, I hope... then you could build it as an optional package.
Apr 09 18:39:23 <philipp64> thepeople: I understand... that's why I suggested a branch as a "playpen" or "sandbox" where I could commit stuff, and the core devs could pick up my commits at their own pace.
Apr 09 18:39:27 <xMff> philipp64: the "fix core system and maintain external package feed" approach generall works well, once everything is matured, packages can be added to the official feed
Apr 09 18:39:55 <philipp64> we could also use external repos... I'm fine with either.
Apr 09 18:40:10 <philipp64> I just don't want to be fixing linux and wireless patches indefinitely. :-)
Apr 09 18:40:11 <xMff> philipp64: there are git mirrors of openwrt if it helps you
Apr 09 18:40:23 <thepeople> we do have the ability to do external feeds for packages
Apr 09 18:40:32 <philipp64> xMff: don't understand... what does that change?
Apr 09 18:40:45 <thepeople> and we could add you in commented out so it is easy for users to enable it
Apr 09 18:41:06 <xMff> philipp64: most people claim it is easier to maintain extra branches with it, so that they can be submitted as patches later on
Apr 09 18:41:33 <philipp64> thepeople: good... say I was asking on the mailing list about adding a target that gets invoked right after all the packages have been built, but before the image gets "packaged"...
Apr 09 18:42:42 <OutBackDingo> ouch 1 out of 5 hunks FAILED -- rejects in file arch/mips/kernel/machine_kexec.c
Apr 09 18:42:48 <thepeople> what would this target do?
Apr 09 18:43:00 <thepeople> not sure of its use
Apr 09 18:43:09 <philipp64> thepeople: this would allow someone to add a local makefile that would then (for instance) 'sed' files in /etc/config/* to change the out-of-the-box parameters...
Apr 09 18:43:12 <thepeople> I could go find you on the ml as well I suppose :-P
Apr 09 18:43:38 <OutBackDingo> trunky broken
Apr 09 18:43:41 <CIA-39> florian * r20765 /trunk/target/linux/brcm63xx/ (2 files in 2 dirs): [brcm63xx] do not overwrite ENET_CTL_REG, fixes ethernet on bcm6338
Apr 09 18:44:40 <thepeople> philipp64: I don't see that happening (that doesn't mean it won't), I was asking for depends to apply to install time for the same reason
Apr 09 18:44:58 <CIA-39> florian * r20766 /branches/backfire/target/linux/brcm63xx/patches-2.6.32/230-external_phy_fix.patch: backport r20765 to backfire
Apr 09 18:45:00 <OutBackDingo> [florian]: ping
Apr 09 18:45:08 <[florian]> OutBackDingo: pong
Apr 09 18:45:43 <OutBackDingo> [florian]: kexec broken from commmit 20745  ??
Apr 09 18:45:54 <[florian]> OutBackDingo: on which kernel version and for which target?
Apr 09 18:45:59 <OutBackDingo> rejects in file arch/mips/kernel/machine_kexec.c
Apr 09 18:46:04 <OutBackDingo> atheros mips
Apr 09 18:46:11 <[florian]> default kernel version?
Apr 09 18:46:15 <OutBackDingo> yupp
Apr 09 18:46:21 <[florian]> ok, let me fix that
Apr 09 18:46:36 <OutBackDingo> linux-2.6.30.10
Apr 09 18:46:43 <OutBackDingo> [florian]: thanks
Apr 09 18:46:45 <xMff> philipp64: the current way of doing defconfig alterations is either provide different, complete default config files in topdir/files/ or embedding uci-defaults scripts in the image which get executed once on firstboot and are removed afterwards
Apr 09 18:46:52 <cshore_> There are a couple things you have to do to change out of the box parameters
Apr 09 18:46:59 <OutBackDingo> [florian]: ouch 1 out of 5 hunks FAILED
Apr 09 18:47:03 <OutBackDingo> :P
Apr 09 18:47:03 <cshore_> xMff: beat me to it
Apr 09 18:47:29 <xMff> philipp64: in selected cases, default configs are converted into templates and populated with values from menuconfig
Apr 09 18:47:43 <xMff> for example grub's menu.lst
Apr 09 18:53:03 <cshore_> Anyone noticed that LuCI images seem smaller than before, now?
Apr 09 18:53:20 <cshore_> 3.2 vs 3.6
Apr 09 18:53:27 <xMff> on which arach?
Apr 09 18:53:31 <xMff> *arch
Apr 09 18:53:35 <cshore_> brcm63xx
Apr 09 18:53:49 <cshore_> but this is a custom build
Apr 09 18:54:03 <xMff> with default options?
Apr 09 18:54:04 <cshore_> I know wapd saves space
Apr 09 18:54:13 <KanjiMonster> nbd: ping
Apr 09 18:54:14 <cshore_> xMff: no
Apr 09 18:54:24 <cshore_> xMff: just the same options as I have been using
Apr 09 18:54:31 <nbd> KanjiMonster: pong
Apr 09 18:54:31 <xMff> cshore_: interesting
Apr 09 18:54:38 <cshore_> xMff: and uhttpd probably saved some space
Apr 09 18:54:47 <xMff> cshore_: hm not really
Apr 09 18:54:51 <cshore_> hmm.....
Apr 09 18:55:13 <xMff> however, the lua nixio library no longer links against a ssl library
Apr 09 18:55:21 <xMff> and lua code is precompiled by default now
Apr 09 18:55:21 <cshore_> xMff: I don't know then....ah, maybe that's it
Apr 09 18:55:29 <cshore_> xMff: cool
Apr 09 18:56:26 <cshore_> xMff: all told it seems to be 300-400k smaller than I was getting before (wpa-supplicant+hostap+LuCI stuff)
Apr 09 18:56:27 <KanjiMonster> nbd: I'm looking for the right place to add range checks for vlan/port attributes to swconfig - obviously this belongs in the kernel part, but i'm torn between lookup_attr (where it would be a single place) and get_attr/set_attr (where it "logically" belongs)
Apr 09 18:58:21 <nbd> i think it should be in lookup_attr
Apr 09 18:58:26 <KanjiMonster> ok
Apr 09 18:58:26 <nbd> i don't like duplication
Apr 09 18:58:30 <nbd> ;)
Apr 09 18:58:47 <KanjiMonster> yeah, me neither, but somehow it feels a bit wrong logically ;)
Apr 09 18:59:01 <xMff> cshore_: well finally a positive sign :) Sometimes I think whatever you do, it will grow bigger anyway
Apr 09 18:59:30 <nbd> heh, atheros uboot is nice
Apr 09 18:59:31 <nbd> ar7240> flinfo
Apr 09 18:59:31 <nbd> Bank # 1: The hell do you want flinfo for??
Apr 09 19:02:32 <cshore_> xMff: that's okay, I just discovered that FreeSwitch doesn't use system libraries....for everything it uses it downloads and statics links it
Apr 09 19:03:09 <cshore_> xMff: OR uses modified versions
Apr 09 19:05:00 <cshore_> xMff: based on that alone, if it was my decision I'd forget about FS and use Asterisk
Apr 09 19:05:05 <rtz2> is stuff like the ppl and gmp libraries available on solaris/osx?
Apr 09 19:06:22 <[florian]> oh I think so
Apr 09 19:06:34 <thepeople> cshore_: I do like freeswitch tho
Apr 09 19:06:54 <thepeople> even if it is a little rough around the edges in places
Apr 09 19:07:40 <rtz2> [florian]: in this case, it would probably be a good idea to use the system version for gcc instead of building them
Apr 09 19:07:55 <rtz2> [florian]: because especially ppl isn't exactly small
Apr 09 19:08:01 <[florian]> rtz2: yes
Apr 09 19:08:19 <rtz2> let me run a few tests
Apr 09 19:09:00 <nbd> rtz2: i don't think we should use the host's ppl and gmp
Apr 09 19:09:19 <nbd> we might encounter weird or broken versions on various distros
Apr 09 19:09:44 <cshore_> thepeople: you're probably right, it just kind of annoyed me
Apr 09 19:10:44 <thepeople> cshore_: yea it is crappy that they staticly link everything, their reasoning is that it keeps them from encountering broken versions in distros
Apr 09 19:10:56 <rtz2> nbd: maybe a menuconfig option? because this is really annoying on slow systems
Apr 09 19:10:57 <cshore_> thepeople: I know
Apr 09 19:11:13 <cshore_> thepeople: but other projects seem to manage
Apr 09 19:11:25 <thepeople> cshore_: I know
Apr 09 19:11:26 <nbd> rtz2: menuconfig option would be fine, but it should be off by default
Apr 09 19:11:33 <cshore_> thepeople: oh well
Apr 09 19:11:43 <rtz2> maybe something in the developer options
Apr 09 19:11:57 <thepeople> cshore_: I guess what can you do, we know and they are not likely to change
Apr 09 19:26:59 <CIA-39> florian * r20767 /trunk/target/linux/ (9 files in 4 dirs): [kernel] refresh patches
Apr 09 20:19:59 <rtz2> nbd: ping
Apr 09 20:22:02 <nbd> rtz2: pong
Apr 09 20:23:02 <rtz2> nbd: regarding the graphite framework and the config option for it
Apr 09 20:23:28 <rtz2> nbd: how does it actually work? I don't see any place where it passes something to configure
Apr 09 20:25:53 <rtz2> besides the libstdc++ option
Apr 09 20:47:30 <CIA-39> jow * r20768 /trunk/package/broadcom-wl/files/lib/wifi/broadcom.sh: [package] broadcom-wl: fix 11bg hwmode, add lrs mode
Apr 09 20:48:09 <CIA-39> jow * r20769 /branches/backfire/package/broadcom-wl/files/lib/wifi/broadcom.sh: [backfire] merge r20768
Apr 09 20:48:33 <OutBackDingo> [florian]: thanks
Apr 09 21:28:28 <philipp64> anyone here a hotplug expert?  I was trying to figure out how to add a rule in hotplug2-common.rules yesterday that would do a "print-event" (but no "next", so it would continue with the rest of the rules) or else use logger to trap the %DEVICENAME% and %DEVPATH% ... any takers?
Apr 09 21:29:31 <cshore_> philipp64: not an expert, but I think what you want is an exec rule
Apr 09 21:47:25 <philipp64> yeah, I could do that too...  I tried adding: run "echo %DEVPATH% %DEVICENAME% >> /tmp/hotplug.log" as the rule, but this just caused the system to hang at boot.
Apr 09 21:48:18 <cshore_> philipp64: yeah, echo is not a hotplug command
Apr 09 21:48:33 <cshore_> philipp64: exec isn't exec like in shell
Apr 09 21:49:17 <cshore_> philipp64: IIUC it's just the command used to execute arbitrary commands
Apr 09 21:49:33 <philipp64> I'm looking at hotplug2-201/docs/rules.txt right now....
Apr 09 21:49:51 <cshore_> philipp64: ah, yes, soon you wll know more than I
Apr 09 21:50:17 <philipp64> what's the difference between "exec" and "run", anyway?
Apr 09 21:50:41 <philipp64> run claims to use a shell... so redirection should work...
Apr 09 21:51:50 <philipp64> exec logger ... should work anyway... how does one add a rule that gets executed for every event before all others?
Apr 09 21:52:38 <cshore_> phillipp64: your guess is as good as mine
Apr 09 21:53:11 <xMff> philipp64: add it as first rule and use something that always matches
Apr 09 21:53:26 <philipp64> I tried ~~ (*)
Apr 09 21:54:12 <xMff> try:  XYZ is set { }
Apr 09 21:57:23 <philipp64> for what values of XYZ?
Apr 09 21:57:56 <cshore_> ping nbd
Apr 09 21:58:13 <philipp64> ah, DEVPATH is set { }
Apr 09 21:58:21 <xMff> philipp64: ... yep
Apr 09 22:15:29 <philipp64> xMff: no joy
Apr 09 22:49:56 <philipp64> ok, this time it didn't crash, but it didn't do anything either... was using: logger -s -t hotplug -p daemon.info "name=%DEVICENAME%, path=%DEVPATH%"
Apr 09 22:49:59 <philipp64> as the command.
Apr 09 23:07:44 <cshore_> logread | grep hotplug showed nothing?
Apr 09 23:27:34 <cshore_> xMff: I think for the wiki we need more explicit version information for the docs (e.g. Kamikaze, Backfire, trunk)
Apr 09 23:27:58 <cshore_> xMff: I mean some of the docs are from WhiteRussian!
Apr 09 23:28:37 <cshore_> like the FAQ
Apr 09 23:29:59 <cshore_> I need golems like in Kiln People
Apr 09 23:45:38 <rtz2> cshore_: we could make a list and then force every developer to fix up one article per week ;)
Apr 09 23:45:56 <cshore_> heh
Apr 09 23:46:18 <cshore_> I'm as guilty as anyone else
Apr 09 23:46:26 <rtz2> i'm too
Apr 09 23:46:40 <rtz2> but one article per week is doable
Apr 09 23:47:06 <rtz2> cshore_: and without such a table, the wiki will never get better
Apr 09 23:47:29 <cshore_> right
Apr 10 00:33:49 <CIA-39> dingo * r20770 /packages/net/nocatsplash/Makefile: [patchteam] - updates nocatsplash to a functional version
Apr 10 00:38:06 <CIA-39> dingo * r20771 /packages/net/nocatsplash/Makefile: [patchteam] - fixes url to get 0.93pre2 from nocat.net
**** ENDING LOGGING AT Sat Apr 10 02:59:57 2010