**** BEGIN LOGGING AT Sat Jul 23 02:59:57 2011
Jul 23 05:42:54 <builder_> build #39 of mpc52xx is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/39
Jul 23 07:06:11 <builder_> build #61 of at91 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/61
Jul 23 07:42:37 <builder_> build #59 of ubicom32 is complete: Failure [failed compile_3]  Build details are at http://buildbot.openwrt.org:8010/builders/ubicom32/builds/59
Jul 23 11:21:53 <KanjiMonster> philipp64|laptop: pong
Jul 23 11:23:05 <CIA-89> hauke * r27731 /trunk/target/linux/generic/ (30 files in 7 dirs): kernel: update bcma and ssb to version master-2011-07-22 from wireless-testing
Jul 23 11:23:37 <CIA-89> hauke * r27732 /trunk/package/kernel/modules/other.mk: kernel: add bcma package
Jul 23 11:25:58 <CIA-89> hauke * r27733 /trunk/target/linux/brcm47xx/config-2.6.39:
Jul 23 11:25:58 <CIA-89> brcm47xx: build bcma into the kernel
Jul 23 11:25:58 <CIA-89> Now we can assume that every brcm47xx kernel has the bcma module build
Jul 23 11:25:58 <CIA-89> into the kernel. This is not needed for this version as this does not
Jul 23 11:25:58 <CIA-89> support bcma as system bus but kernel 3.0 will.
Jul 23 11:26:34 <KanjiMonster> Hauke: how big is bcma?
Jul 23 11:27:32 <Hauke> KanjiMonster: 9218 bytes on x86
Jul 23 11:27:55 <KanjiMonster> ah, that sounds acceptable
Jul 23 11:29:26 <Hauke> in the next openwrt major release the brcm47xx image will support bcma as system bus so all images wil contain this
Jul 23 11:30:07 <KanjiMonster> b43 probably could be changed soon (after the next wireless-next update) to optionally depend on bcma and ssb only if these are compiled (something like +PACKAGE_kmod-ssb:kmod-ssb)
Jul 23 11:31:06 <CIA-89> hauke * r27734 /trunk/package/mac80211/ (6 files in 2 dirs):
Jul 23 11:31:06 <CIA-89> mca80211: add support for b43 on bcma bus.
Jul 23 11:31:06 <CIA-89> This makes b43 work on broadcom SoCs using bcma as system bus.
Jul 23 11:32:13 <Hauke> KanjiMonster: now it depends on both
Jul 23 11:32:37 <KanjiMonster> ymca80211 ;D
Jul 23 11:34:17 <KanjiMonster> Hauke: "Currently borken." borkborkbork! (shouldn't this then depend on BROKEN?)
Jul 23 11:35:17 <Hauke> KanjiMonster: yes sounds good
Jul 23 11:38:19 <CIA-89> hauke * r27735 /trunk/package/mac80211/Makefile: mac80211: fix typo and make broken options depend on BROKEN
Jul 23 17:19:43 <builder_> build #61 of s3c24xx is complete: Exception [exception compile_10 interrupted]  Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/61
Jul 23 17:30:59 <philipp64|laptop> KanjiMonster: why not just put a "|" ordering dependency in the makefiles then?
Jul 23 17:31:42 <KanjiMonster> philipp64|laptop: a what?
Jul 23 17:41:00 <philipp64|laptop> you can force make to build targets in a specified order, the syntax:
Jul 23 17:41:04 <philipp64|laptop> a : b | c
Jul 23 17:41:35 <philipp64|laptop> means "a" depends directly on "b" for freshness, but if "c" is going to be rebuilt in this make instantiation, build "c" before "a".
Jul 23 17:42:00 <philipp64|laptop> "c" in this case would be "libpthread install" before "asterisk install".
Jul 23 17:46:20 <KanjiMonster> philipp64|laptop: why? there's nothing to gain; the error messages are purely cosmetical - the build system already takes care of that all required packages are installed (even if the order is wrong - but packages depending on a install order are broken anyway ;)
Jul 23 18:42:30 <builder_> build #37 of octeon is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/37
Jul 23 19:16:59 <builder_> build #63 of brcm63xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/63
Jul 23 20:44:32 <Kevin`> what software is responsible for creating wds sub-interfaces? it's assigning the phy default mac address to them instead of the ap mac address
Jul 23 20:45:25 <builder_> build #59 of brcm47xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/59
Jul 23 20:48:36 <philipp64|laptop> KanjiMonster: so if install order doesn't matter, why does it bother checking and reporting it? seems like it just adds confusion.
Jul 23 20:49:02 <CIA-89> kaloz * r27736 /trunk/target/linux/generic/patches-3.0/999-drop_sublevel.patch: [generic]: 3.0 is out
Jul 23 20:49:56 <CIA-89> kaloz * r27737 /trunk/target/linux/orion/Makefile: [orion]: upgrade to 3.0
Jul 23 20:49:58 <KanjiMonster> philipp64|laptop: because opkg always complains, even when forcing the install
Jul 23 20:50:11 <CIA-89> kaloz * r27738 /trunk/target/linux/ppc44x/ (4 files in 2 dirs): [ppc44x]: upgrade to 3.0
Jul 23 20:51:35 <Kevin`> I also have a far easier bug to fix if any developers are here ;p
Jul 23 20:52:10 <KanjiMonster> Kevin`: have you ever thought about just opening a ticket on trac? ;p
Jul 23 20:52:24 <Kevin`> thought about it
Jul 23 20:53:07 <KanjiMonster> makes the bug visible and stuff - things said on irc are easily forgotten ;)
Jul 23 20:53:37 <Kevin`> i'll probably have to do that for the two wds bugs. but the txpower bug really is easy to fix
Jul 23 20:57:46 <Kevin`> is there a way to search active tickets?
Jul 23 21:14:08 <philipp64|laptop> any committers around? can someone (Kaloz?) commit 1242 and 1213 for instance?
Jul 23 21:14:43 <Kevin`> there, have a ticket: https://dev.openwrt.org/ticket/9794
Jul 23 21:51:41 <KanjiMonster> philipp64|laptop: "I'm thinking that retiring these version would be good. " <- Thanks for volunteering to port the 12 targets stuck on 2.6.30 - 32 to a recent kernel! ;p
Jul 23 21:54:39 <seuros> hi
Jul 23 21:55:29 <philipp64|laptop> KanjiMonster: so when do orphaned platforms get retired? you'd think that if someone used them, they'd maintain them.
Jul 23 21:56:24 <seuros> Can someone tell me what is wrong with this compile : http://pastebin.com/BpKKGKYx ...  Platform : Lantiq danube.
Jul 23 22:04:04 <EqUaTe> philipp64|laptop: you seem to be under the misconception that people that use openwrt are all coders/people that understand software development
Jul 23 22:04:35 <philipp64|laptop> EqUaTe: no, I came to the conclusion that it didn't magically appear in the tree initially, but someone put it there.
Jul 23 22:04:59 <EqUaTe> that part is true, yes. but developers often move on to other products or replace their hardware
Jul 23 22:05:10 <EqUaTe> this has a history of orphaning projects
Jul 23 22:05:42 <philipp64|laptop> ok, so... the fact that they've moved on... should their initial contribution (which was a benefit) turn into a drag on the project after they leave? that seems counter-productive.
Jul 23 22:05:46 <EqUaTe> that doesn't mean that the projects in question are unused
Jul 23 22:06:10 <philipp64|laptop> no, but it doesn't mean that the users are helpless to recruit a new maintainer, either.
Jul 23 22:06:16 <EqUaTe> perhaps a call for maintainers should be issued?
Jul 23 22:06:25 <EqUaTe> that assumes that the users are aware the maintainer has gone
Jul 23 22:06:48 <Kevin`> anyone know what software is responsible for creating wds station sub-interfaces, or better, assigning the mac address they use?
Jul 23 22:06:48 <philipp64|laptop> well, there's an easy way to make that part clear... :-)
Jul 23 22:06:48 <EqUaTe> i've *never* seen anything on any part of the openwrt website that suggests that a platform is unmaintained or undeveloped
Jul 23 22:07:55 <philipp64|laptop> EqUaTe: that's true, and it's definitely something we could do a better job at. perhaps swalker could maintain a list of platforms that need maintainers... in addition to the list of packages that need version bumps.
Jul 23 22:08:10 <EqUaTe> there may have been mentions on the mailing list, but i'm on enough high volume lists as it is
Jul 23 22:08:25 <philipp64|laptop> I think part of the problem is that the maintainers themselves are sometimes the last to realize they've abandoned their charges. :-(
Jul 23 22:08:39 <EqUaTe> i'm almost at 12k unread messages on nanog :-/
Jul 23 22:09:00 <philipp64|laptop> you need an AI.
Jul 23 22:09:07 <EqUaTe> i need a time machine
Jul 23 22:09:25 <philipp64|laptop> so you're a wireless backbone carrier? didn't know there was such a thing. :-)
Jul 23 22:09:53 <EqUaTe> eh?
Jul 23 22:09:56 <philipp64|laptop> just as well... I'm always tripping all over these damn cables lying all over the place... so untidy.
Jul 23 22:10:20 <philipp64|laptop> Nanog... North American Network Operations Group?
Jul 23 22:10:27 <EqUaTe> yes..
Jul 23 22:10:27 <philipp64|laptop> *Operators
Jul 23 22:10:34 <philipp64|laptop> trunk operators?
Jul 23 22:10:40 <EqUaTe> what i don't get is where you got the wireless backbone carrier from
Jul 23 22:10:44 <EqUaTe> no, anyone that operates any network
Jul 23 22:11:10 <philipp64|laptop> ah...
Jul 23 22:11:20 <philipp64|laptop> thought it was ISP's and IXC's only.
Jul 23 22:11:33 <philipp64|laptop> but mostly IXC's.
Jul 23 22:11:35 <EqUaTe> not really, but i work at a company that is part isp
Jul 23 22:11:44 <philipp64|laptop> which one?
Jul 23 22:11:50 <EqUaTe> isp's, companies with large networks, that sort of thing
Jul 23 22:11:54 <EqUaTe> www.sohonet.com
Jul 23 22:12:03 <philipp64|laptop> don't know it.
Jul 23 22:12:19 <EqUaTe> i wouldn't expect you to
Jul 23 22:12:22 <EqUaTe> we're pretty specialist
Jul 23 22:12:58 <philipp64|laptop> looks like it. carriage and colo services?
Jul 23 22:13:04 <philipp64|laptop> like Level-3?
Jul 23 22:13:12 <EqUaTe> we don't do a huge amount of colo
Jul 23 22:13:21 <EqUaTe> we're more of a community of interest, with value-add products
Jul 23 22:13:28 <philipp64|laptop> ok.
Jul 23 22:13:39 <EqUaTe> our main customers are post production facilities, film studios.. things like that
Jul 23 22:14:03 <EqUaTe> if you like watching credits at the end of tv shows and films, you'll recognise a lot of the names
Jul 23 22:15:39 <philipp64|laptop> "No aliens were harmed in the making of this film." (Mars Attacks)
Jul 23 22:15:51 <EqUaTe> hehe
Jul 23 22:15:58 <EqUaTe> shame they didn't harm tom jones :P
Jul 23 22:16:19 <philipp64|laptop> oh, he's great. he's just Welsh.
Jul 23 22:16:24 <philipp64|laptop> you gotta make allowances.
Jul 23 22:16:30 <philipp64|laptop> they're not like the rest of us.
Jul 23 22:20:31 <EqUaTe> hehe
Jul 23 22:40:13 <philipp64|laptop> build build build...
Jul 23 22:40:45 <seuros> Can someone tell me what is wrong with this compile : http://pastebin.com/BpKKGKYx ...  Platform : Lantiq danube.
Jul 23 23:02:21 <philipp64|laptop> Hauke: ping
Jul 23 23:05:24 <philipp64|laptop> EqUaTe: for what it's worth, my build of 2.6.30.10 just stalled because of all the missing config symbols...
Jul 23 23:05:52 <philipp64|laptop> so I'm not sure what the point of being required to put more effort maintaining it than anyone else does... sigh.
Jul 23 23:10:09 <philipp64|laptop> EqUaTe: can you file a bug please for the missing symbols for 2.6.30?
Jul 23 23:10:24 <EqUaTe> that would require knowing anything about it :)
Jul 23 23:11:11 <philipp64|laptop> ok, well, who uses a platform that's frozen at 2.6.30 that might know how to do a build?
Jul 23 23:13:12 <seuros> It freeze for me with  2.6.32.33
Jul 23 23:13:21 <seuros> it just cannot generate u-boot
Jul 23 23:14:33 <EqUaTe> what platforms are stuck to your knowledge?
Jul 23 23:15:41 <philipp64|laptop> who are you asking?
Jul 23 23:17:31 <EqUaTe> anyone who might know
Jul 23 23:17:37 <EqUaTe> you probably know a fair amount of it
Jul 23 23:18:45 <EqUaTe> at least from what you're saying :)
Jul 23 23:39:53 <philipp64|laptop> EqUaTe: I work mostly on x86 platforms, all of which support the head of git.kernel.org ...
Jul 23 23:40:31 <EqUaTe> yeah, i have seen a fair amount of stuff about the 3.0 kernel.. :)
Jul 23 23:44:24 <philipp64|laptop> what's the handle for Peter Wagner?
Jul 23 23:45:29 <KanjiMonster> EqUaTe: http://pastebin.com/CQZgXUd4 (two of these already have patches for a newer version)
Jul 23 23:46:02 <KanjiMonster> philipp64|laptop: tripolar
Jul 23 23:46:22 <philipp64|laptop> ah... anyone else have any luck building 3.0?
Jul 23 23:47:04 <KanjiMonster> I'm currently building 3.0 for bcm63xx
Jul 23 23:47:33 <EqUaTe> KanjiMonster: going to finally get around to shipping you those devices this week..
Jul 23 23:47:36 * EqUaTe whistles
Jul 23 23:47:42 <KanjiMonster> \o/
Jul 23 23:48:30 <KanjiMonster> EqUaTe: maybe you've seen the patches from today, I managed to make the switch on the wnr2000v1 configurable
Jul 23 23:49:34 <EqUaTe> nice.. how's the build for it actually working? did you put a loader of some sort in, or did you manage to make it work with the stock flash layout?
Jul 23 23:49:59 <KanjiMonster> I'm just tftpbooting a init-ramfs kernel
Jul 23 23:50:08 <EqUaTe> ah ok
Jul 23 23:50:19 <EqUaTe> i thought you had a v2?
Jul 23 23:50:31 <KanjiMonster> I do
Jul 23 23:50:42 <EqUaTe> you got a v1 as well now?
Jul 23 23:50:56 <KanjiMonster> but I also have a wn2000rpt, which is quite similar to the v1 (it has no wan port)
Jul 23 23:51:03 <EqUaTe> ah ok
Jul 23 23:51:11 <EqUaTe> so still worth shipping the v1 then :)
Jul 23 23:51:29 <KanjiMonster> read somewhere it was supposed to have a ar8236, but it turned out to be the old ar8216 :/
Jul 23 23:51:42 <EqUaTe> d'oh
Jul 23 23:52:34 <KanjiMonster> otoh its psu works perfectly with my sky dsl-2640s ;)
Jul 23 23:52:50 <EqUaTe> heh
Jul 23 23:53:02 <EqUaTe> well, the 12v 1a psu's are pretty common :P
Jul 23 23:53:08 <KanjiMonster> yeah
Jul 24 00:05:20 <KanjiMonster> philipp64|laptop: working fine here (well, more or less): "Linux OpenWrt 3.0.0 #1 Sun Jul 24 01:57:35 CEST 2011 mips GNU/Linux"
Jul 24 00:09:46 <KanjiMonster> philipp64|laptop: loading modules is broken, though
**** ENDING LOGGING AT Sun Jul 24 02:59:56 2011