**** BEGIN LOGGING AT Sat Jul 30 02:59:56 2011
Jul 30 06:39:12 <CIA-89> mhei * r27838 /packages/lang/php5/ (3 files in 2 dirs): [packages] php5: PECL: include support for libevent
Jul 30 08:22:16 <CIA-89> mhei * r27839 /packages/lang/php5/Makefile:
Jul 30 08:22:16 <CIA-89> [packages] php5: fix dependencies for apc and sqlite3 (closes #9368)
Jul 30 08:22:16 <CIA-89> When using CONFIGURE_LIBS the php binary itself depends on these libs,
Jul 30 08:22:16 <CIA-89> so the opkg depends also reflected this. But in this case it was
Jul 30 08:22:16 <CIA-89> required to install those libs even when they were never planned to use.
Jul 30 12:36:58 <mazilo> Has anyone noticed that there are two libelf packages where each from libs/elfutils and libs/libelf ?
Jul 30 13:41:02 <blaise> elfutils = Libraries/utilities to handle ELF objects (drop in replacement for libelf)
Jul 30 13:41:17 <blaise> libelf = A ELF object file access library
Jul 30 13:41:28 <blaise> they are different.
Jul 30 13:55:35 <larsc> I guess the problem is that both proivde a package by the same name, so only one of them will ever be selectable at the same time
Jul 30 13:58:18 <larsc> if it is really a drop-in replacement it is probably best to get rid of the original libelf package
Jul 30 14:04:22 <mazilo> Well, if one is selected, the other also gets selected.
Jul 30 14:04:49 <mazilo> They should not have the same package name.
Jul 30 14:05:33 <larsc> that doesn't solve the problem since they also provide the same files
Jul 30 14:06:47 <mazilo> IC. At least, if they have different name, only one (and not both) package will be selected.
Jul 30 14:11:21 <larsc> i think only one of them will be build due to how openwrt handles this internally
Jul 30 14:14:11 <mazilo> If the the libelf from elfutils is a drop-in replacement, then I agree with lars that libelf should be removed. Right now, if libelf is called, I believe it is the old libelf (not from elfutils package) gets selected/compiled by default (see the .config file).
Jul 30 15:40:14 <CIA-89> nbd * r27840 /trunk/target/linux/generic/ (8 files in 2 dirs): kernel: add a new version of my netfilter speedup patches for linux 2.6.39 and 3.0
Jul 30 18:13:19 <blaise> how do we go about getting a package Makefile into the repo?
Jul 30 18:14:02 <blaise> I would like to post something for submittion to the openwrt repository
Jul 30 18:32:04 <loswillios> blaise: read https://dev.openwrt.org/wiki/SubmittingPatches
Jul 30 18:44:36 <blaise> loswillios: yeh, nbd pointed me to that url..
Jul 30 18:45:54 <blaise> I kinda figured it would be like submitting a bug report..
Jul 30 19:28:58 <philipp64|laptop> is there really no cron? bummer.
Jul 30 19:54:08 <philipp64|laptop> oh, no, wait... part of busybox. duh.
Jul 30 20:55:14 <builder_> build #44 of ep93xx is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/44
Jul 30 21:20:01 <EqUaTe> who's the freeswitch maintainer?
Jul 30 21:57:50 <CIA-89> nbd * r27841 /branches/backfire/ (3 files in 3 dirs): ar71xx: backport tl-wr740n support from r24811 (#9843)
Jul 30 22:04:48 <[florian]> EqUaTe: it's cshore
Jul 30 22:09:45 <KanjiMonster> EqUaTe, [florian]: it's mazilo -> https://dev.openwrt.org/browser/packages/net/freeswitch/Makefile#L165 ;)
Jul 30 22:10:24 <EqUaTe> ahar. well, the dl link for the current version is wrong.. :) it needs to have the historic bit removed..
Jul 30 22:10:26 <mazilo> EqUaTe: I maintain FreeSWITCH.
Jul 30 22:10:48 <EqUaTe> either that or have the tarball sync'd to one of the openwrt mirrors
Jul 30 22:10:48 <mazilo> EqUaTe: Which history bit?
Jul 30 22:12:20 <EqUaTe> ah wait
Jul 30 22:12:27 <EqUaTe> dammit, which one was it
Jul 30 22:12:30 <mazilo> EqUaTe: I don't see OpenWRT is storing any FS git tarball. When FS is compile the 1st time, it will go to FS to download the FS git version of tarball.
Jul 30 22:12:40 <EqUaTe> ah yes
Jul 30 22:12:44 <EqUaTe> it was the zeromq part
Jul 30 22:12:55 <EqUaTe> it came up as part of freeswitch, though it may not be
Jul 30 22:13:17 <EqUaTe> zeromq-2.1.7 isn't in http://download.zeromq.org/historic/
Jul 30 22:13:39 <mazilo> EqUaTe: All the additional package sources will be downloaded when FS is compiled.
Jul 30 22:13:55 <EqUaTe> or when you run make download
Jul 30 22:14:19 <EqUaTe> the dl of zeromq fails with the urls that are listed
Jul 30 22:14:20 <mazilo> EqUaTe: I have never done that, but I believe that will do.
Jul 30 22:14:47 <EqUaTe> because it looks for it on the two openwrt mirrors, and in the dir that i pasted the link to
Jul 30 22:16:12 <mazilo> EqUaTe: It should automatically switch to download the zeromq source from the link you pointed out above.
Jul 30 22:16:20 <EqUaTe> yes
Jul 30 22:16:25 <EqUaTe> *it isn't there*
Jul 30 22:16:35 <EqUaTe> 2.1.7 is in the level above
Jul 30 22:17:04 <EqUaTe> the historic subdir only contains the old versions
Jul 30 22:17:54 <mazilo> EqUaTe: It must have been removed from the download site.
Jul 30 22:18:25 <CIA-89> jow * r27842 /packages/net/freeswitch/Makefile: [packages] freeswitch: fix ZeroMQ download location
Jul 30 22:18:28 <mazilo> EqUaTe: I tried to download it "http://download.zeromq.org/historic/zeromq-2.1.7.tar.gz" and got 404.
Jul 30 22:18:33 <EqUaTe> yes
Jul 30 22:18:38 <EqUaTe> it's at the level above
Jul 30 22:18:42 <mazilo> jow: Thanks.
Jul 30 22:18:46 <EqUaTe> remove 'historic/' from the link and it works
Jul 30 22:19:10 <mazilo> jow: Yes and they just moved it there.
Jul 30 22:20:16 <philipp64|laptop> anyone have any issues with my revised +kmod-input-core fix?
Jul 30 22:21:00 * jow_laptop just remembers zeromq for its supid choice of -Werror
Jul 30 22:21:08 <jow_laptop> which breaks the backfire builds
Jul 30 22:21:20 * jow_laptop also hates freeswitch for its stupid bundling
Jul 30 22:21:24 <jow_laptop> which breaks patching
Jul 30 22:21:50 <EqUaTe> heh
Jul 30 22:22:12 * philipp64|laptop notices that jow_laptop seems to be having a conversation with his inner-self.
Jul 30 22:22:47 <philipp64|laptop> oh, wait, I guess that would mean I am too.
Jul 30 22:23:42 <philipp64|laptop> ok, enough staring at the CS5535 databook for today. time to do some chores.
Jul 30 22:33:29 <Chocky> kids
Jul 30 22:34:12 <Chocky> I'm pretty sure the switch is still bust on my buffalo
Jul 30 22:34:23 <Chocky> G300NH
Jul 30 22:34:40 * Chocky pokes jow/others
Jul 30 22:34:51 <nbd> what did you do to it? ;)
Jul 30 22:35:16 <Chocky> pulled trunk after the 30x was merged with 300
Jul 30 22:35:31 <Chocky> and did a clean build after the misc fixes yesterday, etc
Jul 30 22:38:24 * Chocky pokes nbd
Jul 30 22:38:44 <nbd> i have a wzr-hp-g300nh sitting here right next to me
Jul 30 22:38:50 <nbd> and it's working
Jul 30 22:39:14 <Chocky> but was it formerly the 301 subarch?
Jul 30 22:39:32 <Chocky> and is it running a build from the last day or so?
Jul 30 22:39:47 <nbd> no, it has a s switch, not the rb one
Jul 30 22:39:53 <nbd> it's running the very latest code
Jul 30 22:40:08 <nbd> so what are the symptoms?
Jul 30 22:40:37 <Chocky> it looks configured properly, interface is up.  don't see any packets from ping from other end
Jul 30 22:41:11 <nbd> and 'swconfig dev switch0 load network' returns no errors?
Jul 30 22:41:23 <Chocky> that's right, no errors
Jul 30 22:41:26 <Chocky> I have that fix
Jul 30 22:41:29 <nbd> show me your /etc/config/network
Jul 30 22:41:37 <nbd> and a kernel bootlog
Jul 30 22:41:54 <Chocky> there is however, a segfault during boot.  from what, I dunno
Jul 30 22:41:56 <Chocky> just a sec
Jul 30 22:44:58 <Chocky> http://pastebin.com/2QxX37FG
Jul 30 22:45:05 <Chocky> and yes, lan and wan are different subnets.
Jul 30 22:45:31 <Chocky> I opened wan in firewall, so I could actually get in and see system
Jul 30 22:47:14 <nbd> and does ifconfig show any packets on eth0?
Jul 30 22:47:43 <Chocky>           RX packets:13220 errors:0 dropped:13197 overruns:91322 frame:0
Jul 30 22:47:44 <Chocky>           TX packets:285 errors:0 dropped:0 overruns:0 carrier:0
Jul 30 22:48:06 <nbd> that's weird
Jul 30 22:48:18 <Chocky> indeed
Jul 30 22:49:04 <nbd> so was that working with a previous build at some point?
Jul 30 22:49:15 <Chocky> before the subarch changes, yes
Jul 30 22:49:25 <Chocky> that's not to say other stuff didn't change, but that seems far and away most likely
Jul 30 22:49:58 <Chocky> I'm looking at the swconfig command.  what kind of command should work with that?
Jul 30 22:51:07 <nbd> try swconfig dev switch0 show (will generate long output, so throw it in a text file)
Jul 30 22:51:15 <Chocky> ah.
Jul 30 22:51:23 <Chocky> swconfig dev switch0 load /etc/config/network
Jul 30 22:51:23 <Chocky> Segmentation fault
Jul 30 22:51:35 <Chocky> also seg fault
Jul 30 22:51:49 <nbd> maybe caused by gcc 4.6
Jul 30 22:52:03 <Chocky> right
Jul 30 22:52:27 <Chocky> or something naive about that change in swconfig
Jul 30 22:52:45 <nbd> well, swconfig doesn't care about the differences between the s and the rb switch
Jul 30 22:52:53 <Chocky> what is eth0.1?
Jul 30 22:52:53 <nbd> and it works here on my wzr-hp-g300nh
Jul 30 22:53:00 <nbd> vlan 1 on top of eth0
Jul 30 22:53:26 <Chocky> blame the compiler! woo! ;-)
Jul 30 22:53:59 <Chocky> the other major difference of course is that I'm using glibc.
Jul 30 22:54:06 <nbd> also a likely cause
Jul 30 22:54:13 <nbd> i've tested with neither of those
Jul 30 22:54:23 * Chocky pokes at the code
Jul 30 22:54:41 <nbd> i still wonder why people use glibc instead of eglibc
Jul 30 22:55:15 <Chocky> glibc worked for me at a time when ulibc was broken for my use and eglibc didn't build.
Jul 30 22:55:28 <Chocky> I will do an eglibc build shortly, but need to fix this first
Jul 30 22:56:03 <nbd> i don't really expect eglibc to behave differently here by the way
Jul 30 22:56:22 <Chocky> I'm not sure if there are pending changes that are still required to support eglibc, that are on my glibc ticket
Jul 30 22:56:58 <nbd> it would be helpful if you could track down the swconfig segfault with gdb
Jul 30 22:57:07 <Chocky> good idea
Jul 30 22:57:11 <nbd> i'm about to go to sleep
Jul 30 22:57:13 <Chocky> aw
Jul 30 22:57:17 <nbd> if you track it down, i'll fix it tomorrow
Jul 30 22:57:21 <Chocky> ta
Jul 30 23:01:37 <WillieNL> Chocky: before your going to sleep thanks from this side for the ticket and patches.. i'm running a seperate test build fresh with patches.
Jul 30 23:01:51 <WillieNL> about the glibc patches/fixes :)
Jul 30 23:02:10 <Chocky> ndb sleep, it's only 4pm here
Jul 30 23:02:32 <Chocky> but that's good, yes
Jul 30 23:02:35 <nbd> 1am here
Jul 30 23:02:36 <WillieNL> 1:01 am :p
Jul 30 23:02:57 <nbd> and i'm currently on a somewhat normal sleep cycle
Jul 30 23:03:04 <nbd> that's why i'm leaving so early ;)
Jul 30 23:03:30 <WillieNL> hmm sleeping is not a bad thing mate :)
Jul 30 23:03:56 <Chocky> mad dogs and Englishmen
Jul 30 23:04:06 <nbd> i know, i almost always get my eight hours of sleep
Jul 30 23:05:59 <WillieNL> jup and now we wait.. make -j 4.
Jul 30 23:30:45 <solca> ping nbd
Jul 30 23:31:34 <nbd> pong
Jul 30 23:32:08 <solca> nbd: hi, somedays ago I refresehd ar71xx target to 3.0
Jul 30 23:32:19 <solca> but can't test it
Jul 30 23:33:47 <Chocky> moo
Jul 30 23:33:54 <Chocky> why can't you test it?
Jul 30 23:34:47 <solca> b/c currently I don't have access to a WRT160NL until next week
Jul 30 23:34:58 <m4t> hey nbd, only 1/4 games i played today had the period of high latency
Jul 30 23:35:03 <solca> so I would like to know if somebody could give it a test
Jul 30 23:35:04 <m4t> i upgraded to svn as of a few hrs ago
Jul 30 23:35:11 <solca> and review if anything is ok?
Jul 30 23:35:16 <nbd> i can test it tomorrow
Jul 30 23:35:18 <m4t> even though the lag shot up, it didnt drop the connection
Jul 30 23:35:24 <nbd> about to go to sleep
Jul 30 23:35:28 <Chocky> maybe tomorrow
Jul 30 23:35:34 <m4t> i do have a capture if you want
Jul 30 23:35:42 <nbd> m4t: yes, good idea
Jul 30 23:35:45 <solca> nbd: I generate the patch with git diff?
Jul 30 23:35:52 <nbd> yes
Jul 30 23:36:02 <solca> ok!
Jul 30 23:51:16 <philipp64|laptop> Chocky: let me know if there are eglibc issues still and I'll try and fix them.
Jul 30 23:51:25 <Chocky> right
Jul 30 23:51:31 <Chocky> might be a day or too.
Jul 30 23:55:13 <Chocky> the crash in swconfig is caused by a call to genlmsg_put
Jul 30 23:57:38 <Chocky> grr
Jul 30 23:57:41 * Chocky changes compiler back
Jul 31 00:01:24 <philipp64|laptop> hmmm....  we changes swconfig to use libnl and not libnl-tiny, as I remember.
Jul 31 00:03:00 <philipp64|laptop> nope, take that back. it still links to libnl-tiny.
Jul 31 00:07:15 <Chocky> oh well, building now.  will try tomorrow and see
Jul 31 00:07:34 <Chocky> it also bitches about including kernel headers into user space.  I don't know if that's an issue or not
Jul 31 00:08:21 <Chocky> while we're at it, gdb requires libexpat, but there's no dependency in the package
Jul 31 00:09:22 <Chocky> back tomorrow
**** ENDING LOGGING AT Sun Jul 31 02:59:57 2011