**** BEGIN LOGGING AT Wed Aug 03 02:59:57 2011 Aug 03 10:44:17 build #53 of avr32 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/53 Aug 03 12:58:38 hcg * r27884 /packages/lang/pyclips/ (. Makefile): [packages] pyclips: Add new package pyclips Aug 03 13:24:10 florian * r27885 /trunk/target/linux/generic/ (8 files in 8 dirs): Aug 03 13:24:10 [kernel] remove 8*1-usb_serial_endpoint_size.patch Aug 03 13:24:10 This is breaking some devices out there such as Winchiphead CH341 adapters (#9601) Aug 03 13:56:54 build #57 of x86 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/57 **** BEGIN LOGGING AT Wed Aug 03 14:05:28 2011 Aug 03 14:18:08 * Chocky kicks acinoyx Aug 03 14:18:16 also, Acinonyx Aug 03 15:10:21 anybody want to apply my getline() darwin fixes.. https://lists.openwrt.org/pipermail/openwrt-devel/2011-July/011758.html and https://lists.openwrt.org/pipermail/openwrt-devel/2011-July/011757.html thanks! Aug 03 16:12:27 moo Aug 03 16:24:53 hmm wat is it with s775 coolers and pvc pins that release there self at 55C :( Aug 03 16:25:14 can't say that's a problem i've had.. Aug 03 16:25:22 box cooler and non intel cooler both same issue.. 2 tyraps do that job right now :( Aug 03 16:27:28 i'll stick to my zalman. Aug 03 16:27:53 not sure what i have in my gaming box mind you. Aug 03 16:31:31 not the first time that i (and others around me) trow away s775 cpu's for that :( Aug 03 16:31:42 this is OpenWrt then? Aug 03 16:32:29 EqUaTe: in generic the box cooler is ok but sometimes brands fail at that then i'll go for a hyper tx3 or some like that in 4U rackmount cases :) Aug 03 16:32:48 and yes i do use that hardware building my openwrt images and testing stuff before expecting it to work properly :) Aug 03 16:32:59 hehe Aug 03 16:33:43 also s775 or a am3 compatible platform.. lucky i have both here and not have to trow away am3 boards for multicore (+4 core) upgrades from dual core ;-) Aug 03 16:34:15 it is just that ddr2 ram is high priced compared to the mutch cheaper ddr3 kits nowdays. Aug 03 16:34:43 more ram create a ramdisk and mount the staging and build dir on your ram disk ;-) Aug 03 16:35:13 heh Aug 03 16:35:29 use the ramdisk as an overlay on top of your source dir.. :P Aug 03 16:35:43 obviously improving the build to be faster and do less stuff hasn't occured Aug 03 16:35:43 at least thats how i think about going faster.. reduce latency on configure and autoconf stuff.. Aug 03 16:36:02 without have to care about ssd/flash and write cycles. Aug 03 16:36:15 Chocky: you're somewhat restricted by the packages and stuff... Aug 03 16:36:37 ...no Aug 03 16:36:55 Chocky: for me reducing build time results in reducing testing process thats a main priority when have not that mutch time to sit behind a desk :( Aug 03 16:37:20 willie: reducing time for starters would be doing fewer builds as far as I can tell, you do an awful lot Aug 03 16:37:53 just tired of the hardware pr0n here. Aug 03 16:38:01 Chocky: hmmm yes i test where i think i need to test stuff before launching a stress test and have results i can count on when not test at all :) Aug 03 16:38:35 like /etc/init.d/serviceX restart must not result in a segfault on uclibc or eglibc due dunno.. then i start testing :) Aug 03 16:38:53 sigh Aug 03 16:39:08 Chocky: number of builds is imo irrelevant Aug 03 16:39:30 equate: oh, so doing 10 builds is the same about of time as doing 1? Aug 03 16:39:41 if 10x ok or 1 time 100% ok.. yes Aug 03 16:39:49 * Chocky coughs at the BS Aug 03 16:39:49 then 1 time is also enough indeed Aug 03 16:39:57 Chocky: i didn't say that Aug 03 16:40:09 i'm saying that the number of builds that you do is not relevant to the time a specific build takes Aug 03 16:40:22 in which fantasy universe is this? Aug 03 16:40:31 any optimisation efforts should be directed at optimising individual builds Aug 03 16:40:40 * WillieNL agree with EqUaTe here Aug 03 16:40:41 you can't properly optimise across multiple builds. Aug 03 16:40:44 nor should you try to Aug 03 16:40:53 right, so it's ok if I have to do 100 builds, rather than 1 Aug 03 16:41:03 eq: that's a hopeless generalization Aug 03 16:41:05 and if you're still arguing that you should be trying to optimise down the number of builds you have to do for testing purposes, then you're not getting the point Aug 03 16:41:06 with one exception empty ccache at the first build and nonempty at next build can reduce some time but still is pointless. Aug 03 16:41:14 the point is time. Aug 03 16:41:17 no Aug 03 16:41:21 the point is testing code variations Aug 03 16:41:24 for stability Aug 03 16:41:27 jup Aug 03 16:41:27 yes, it is. otherwise you wouldn't be going on about faster hardware Aug 03 16:41:39 that was not the context. Aug 03 16:41:49 the context was explained after you joined. Aug 03 16:41:53 oh please Aug 03 16:42:06 have you seen how many builds willie does? Aug 03 16:42:14 where WillieNL said that he does the number of builds he does for *testing* Aug 03 16:42:29 there's so much wrong with this argument. Aug 03 16:42:38 Chocky: i think your nr about howmutch builds i run is diffrent from wat is running over +4 week time here. Aug 03 16:43:25 willie: if only 1/2 of what you said made sense Aug 03 16:43:36 Chocky: you seem to be under the misconception that he does the number of builds he does for fun. Aug 03 16:43:36 for eglibc + glibc + defaults + glibc (new gcc) i have 4 builds and in the end will use just one out of them for multi purpose if posible.. Aug 03 16:44:01 no such assumption has been made Aug 03 16:44:32 you're either doing lots of builds for testing runtime optimisation, or for testing runtime stability. Aug 03 16:44:51 that's a false dichotomy Aug 03 16:44:55 i can not blindly start a discussion here like eglibc or uclibc is faster and just wanna know that also notice a lot other issues i wanna know about before make myself depending on something i have not fully tested and start blame other people for my own mistake by not looking further then it just works. Aug 03 16:44:58 either way, it will involve rebuilding large quantities of the codebase. Aug 03 16:45:03 I' Aug 03 16:45:14 I'm doing builds to generate a usable end user product. Aug 03 16:45:31 different people use openwrt for different things. Aug 03 16:45:36 Chocky: wat do you have in mind as usable end user product ? Aug 03 16:45:54 that's and obvious and disingenuous response. Aug 03 16:46:00 Chocky: since i do have " my uncle must be able to use it" as one of my requirements on the list ;-) Aug 03 16:46:02 but of course. Aug 03 16:46:08 right now, i'm spending quite a lot of time building various parts of openwrt to try and get the core and all the packages buildable w/o errors. Aug 03 16:46:31 so i'm running builds quite frequently, and i'm adding more and more machines that i'm doing it on. Aug 03 16:46:37 willie: I won't go into the details of my product. But OpenWrt must be fast and robust Aug 03 16:46:41 EqUaTe: sounds like a logic step to me before continue with other packages Aug 03 16:46:44 for testing different configurations Aug 03 16:46:52 WillieNL: yeah. Aug 03 16:47:09 and my work has lead me to the conclusion that uclibc is substantially slower than glibc. for my purposes. Aug 03 16:47:09 Chocky: so you have a different set of goals from WillieNL. Aug 03 16:47:36 and clearly you have different methodologies. Aug 03 16:47:54 I never claimed otherwise. I'm just disagreeing with broad suggestions about throwing extra hardware at stuff, which is something we've been weaned on from the wintel world Aug 03 16:48:08 and I know the OpenWrt build stuff is terribly CPU intensive Aug 03 16:48:22 it's more IO intensive really, and that's not openwrts fault Aug 03 16:48:24 Chocky: i did go think about glibc for having 4G storage on a full scare desktop like system without any limitations in the first place but do wanna push as mutch as posible performance out of it.. think my goal is totally offtopic from any generic openwrt topic there.. Aug 03 16:49:00 willie: ....er ok. Aug 03 16:49:03 Chocky: more hardware == more parallel builds == more configurations and optimisations to test. Aug 03 16:49:27 EqUaTe: hmm build is more about 100.000 time the 500 bytes instaid of big chuncks of code indeed .. Aug 03 16:49:44 EqUaTe: thats why i want the ramdisk and try to reduce some latency/seektimes Aug 03 16:49:45 OpenWrt *of course* has a big part to play in the build. It's its build system. And I've dealt with hundreds and written several. Aug 03 16:50:09 you've dealt with hundreds of build systems? whoa Aug 03 16:50:18 I have. Aug 03 16:50:28 Chocky: the majority of the build system is a wrapper around existing autoconf/aclocal/etc,etc,etc. configure is horrifically inefficient. Aug 03 16:50:41 autoconf is a dreadful pos Aug 03 16:50:46 indeed. Aug 03 16:50:53 it's made to torture developers Aug 03 16:50:54 it serves a purpose, but by god does it suck. Aug 03 16:51:01 sure. That doesn't mean that substantial gains cannot be made to it. Aug 03 16:51:18 maligor: did you have a point, or were you being flippant? Aug 03 16:51:18 oh you can make immense gains. replace autoconf/aclocal Aug 03 16:51:24 sigh Aug 03 16:51:37 Chocky, just stating facts Aug 03 16:51:39 it's *impractical* for openwrt to do this on its own. Aug 03 16:51:52 and frankly not a priority for the core dev team Aug 03 16:52:26 Chocky, I was mostly just curious as to if you consider two different Makefiles 'build systems' in the count Aug 03 16:52:42 they will always be more interested in stability, versatility, and device support. Aug 03 16:52:44 EqUaTe: hmm you can reduce 50% on your autoconf/aclocal/configure/testing stuff by moving away from a hard drive storage with your toolchain and build+staging dirs to something with lower seektimes like a ramdisk :) Aug 03 16:52:58 WillieNL: indeed. but impractical for lots of people :) Aug 03 16:53:05 ssd is not an option here with mlc/slc crap. Aug 03 16:53:17 EqUaTe: hmm 120 eur 24G ddr3 :) Aug 03 16:53:18 WillieNL, how so? Aug 03 16:53:23 thats why i do think about ramdisk. Aug 03 16:53:40 magnetic disks aren't eternal either Aug 03 16:53:45 WillieNL: yeah, but you need to have the suitable slots :P Aug 03 16:53:52 maligor: no, but they last a lot longer than ssd's at hte moment Aug 03 16:53:56 with constant writes Aug 03 16:54:16 maligor: hmm i do read a lot defects on slc/mlc flash setups that fail due write cycles :( normal ram will not do that. it just last mutch longer and i do ignore mlc/slc indeed do not even wanna try Aug 03 16:54:32 it *looks* like, and I could be completely wrong, since I haven't time it, that compiles against uClibc take a lot longer. Thjat Aug 03 16:54:38 that's quite apart from run time performance Aug 03 16:54:40 move from ramdisk to sata3 disk will not take that mutch time it a big data chunk mosthly.. Aug 03 16:54:51 it's rather sad they've moved to smaller mfg process with ssd too Aug 03 16:54:57 since it reduces write cycles Aug 03 16:55:20 hmm for me ssd wat like philips and the lightbulb with X.000 hours to use :) Aug 03 16:55:38 WillieNL, it's rather amusing too, they got intel i7 quad core laptops at work with 8gb of ram of developers Aug 03 16:55:40 lightspeed but last less long as a normal sata 7200rpm disk :) Aug 03 16:55:45 the 8gb is for disk cache ;P Aug 03 16:55:54 hehehe Aug 03 16:56:39 hmm also i7 if you have that money why not, else why not a amd am3+ 6 core system that is not mutch slower in the end for way less money ;-) Aug 03 16:56:58 if you know how to use it in the first place. Aug 03 16:57:06 they're laptops Aug 03 16:57:19 hmm my laptop is a c2d used as hmm vnc client xD Aug 03 16:57:22 eq: I know all the autoconf crap. I'm not saying there are easy fixes for everything, and I'm not saying OpenWrt can do it all. What I am saying is that there are likely notable build speed improvements with relatively little effort. One of those I already mentioned in a report on ar71xx build Aug 03 16:57:26 and since we do embedded software, the i7 is mostly overpowerful anyway Aug 03 16:57:40 as for dev's priority, I'm not even sure what that is. Aug 03 16:58:01 maligor: hmm make -J4 fails bootstrapping the toolchain here :) Aug 03 16:58:22 maligor: so i run that per job like default and not 4 job simultane :) Aug 03 16:58:26 I think -j from the top level is just a failure. you need to specific it in the .config Aug 03 16:58:37 hmm posible Aug 03 16:58:38 the system I have at home is a Phenom X6 1100T Aug 03 16:58:47 dirt cheap stuff Aug 03 16:59:05 maligor: mm i do think about replacing this x2 7750be for a x6 1090T :) Aug 03 16:59:19 maligor: but due the ddr3 price also think about replace this ddr2 mainboard Aug 03 16:59:27 still cheaper in the end. Aug 03 16:59:36 ddr3+mainbord or just ddr2.. Aug 03 16:59:38 yeah, I looked at the 1090T too, but the 1100T was the same price for some reason Aug 03 16:59:41 can we quite the hardware pr0n, please Aug 03 16:59:43 quit Aug 03 16:59:57 all desktop systems these days are "fast", it's just a matter of degre Aug 03 17:00:11 Chocky, I know, I just couldn't stop myself Aug 03 17:00:20 my previous C2D was plenty fast too Aug 03 17:00:46 maligor: hmm then i do something wrong on my t7200 :( Aug 03 17:01:01 it was a E6600 Aug 03 17:01:01 it is a laptop and not so fast as a prescot 3ghz HT desktop :( Aug 03 17:01:19 but it's a laptop not a power station :) Aug 03 17:02:03 anyway diner time brb. Aug 03 17:02:21 still need to test/debug that grub issue.. Aug 03 17:02:26 The only hardware porn I'm currently most tempted by is OpenRD Client ;P Aug 03 17:03:31 if you haven't seen it yet: https://forum.openwrt.org/viewtopic.php?pid=140537 Aug 03 17:04:32 maligor: looks funky :) Aug 03 17:04:44 glibc on wzr-hp-g300nh? Aug 03 17:04:58 WillieNL, yes, all those ports ;P Aug 03 17:05:01 maligor: is it better cooled then those dockstars ? Aug 03 17:05:24 dunno really Aug 03 17:05:33 you can buy it just as a board too Aug 03 17:06:08 aka, it's not really a Aug 03 17:06:11 err.. 'product' Aug 03 17:06:14 maligor: hmm looks like perfect as overkill soho router :) Aug 03 17:06:35 with esata nas option over samba :) Aug 03 17:06:46 yeah, so tempting Aug 03 17:06:59 250 usd or something Aug 03 17:08:03 i bumped into a centrino desktop board this year some idea that was already not going to happend untill bumped into a full desktop for just 30 eur ;-) Aug 03 17:08:36 nice Aug 03 17:08:38 will fix that first and later look at the arm/mips stuff here.. but then with a bit knowledge how openwrt is working instaid of no-idea Aug 03 17:09:24 maligor: with a p-m 735 on it http://www.aopen.nl/products_detail.aspx?auno=1173# Aug 03 17:09:25 Chocky, I think I tried building eglibc too at one point Aug 03 17:09:40 it was for another mips unit tho Aug 03 17:10:12 I only have a E-350 on that side Aug 03 17:10:27 maligor: before that i was looking around for a arm kirkwood based esata solution with dual gbit lan :) Aug 03 17:10:28 running plain old debian Aug 03 17:10:46 WillieNL, openrd client is pretty old tho Aug 03 17:11:04 I think it's one of the first kirkwood setups Aug 03 17:11:16 as long it works it is ok :) Aug 03 17:11:26 maligor: was there a question about my stuff? Aug 03 17:12:00 Chocky, hmm.. yes, I failed to make my point, it failed too Aug 03 17:12:11 I'm not sure if glibc worked or not Aug 03 17:12:17 see the notes in that thread about versions and patches Aug 03 17:12:18 it was half a year back Aug 03 17:12:26 I ended up using a buildroot environment on the device Aug 03 17:12:31 yuck Aug 03 17:12:55 I only needed something that had the right libraries that I had a toolchain against Aug 03 17:13:32 was for some mips32r2 dspase experiments Aug 03 17:13:49 the new broadcom chips have dspase for some reason Aug 03 17:15:09 one of the problems is that there is a lot of ranting against (e)glibc, esp. here. With little substance. and I've had some rather bad experiences with uClibc. So, it's good to have some actual numbers on size, performance, even if it's limited to my specific stuff for now. Aug 03 17:16:03 yeah, uclibc is nice most of the time, but sometimes it doesn't cut it Aug 03 17:17:54 not pr0ny enough Aug 03 17:32:12 moo Aug 03 17:32:30 where's bionic option ;P Aug 03 17:32:37 wut? Aug 03 17:32:55 bionic is the libc android uses Aug 03 17:33:03 right Aug 03 17:33:13 what does it do different? Aug 03 17:33:30 pretty much targets the same as uclibc Aug 03 17:34:04 is it new, or based upon something? Aug 03 17:35:10 I guess it's from bsd libc Aug 03 17:41:54 who wants to update udev for me? Aug 03 17:42:06 * Chocky tried and failed so far Aug 03 17:42:37 just solder off the flash and mount it on a desktop Aug 03 17:42:50 wut? Aug 03 17:42:54 heh Aug 03 17:43:04 I've worked too much on development units Aug 03 17:43:13 they have root on sdcards Aug 03 17:43:36 * Chocky accuses maligor of being a veteran embedded developer Aug 03 17:44:02 just 6 months as a 'professional' Aug 03 17:44:11 aw Aug 03 17:44:19 and before that? Aug 03 17:44:30 hobbyist student bum Aug 03 17:45:21 Chocky: uclibc needs to be updated for udev 17-something; some signals are wrong in mips and udev uses them starting with this version Aug 03 17:45:54 right. I'm using glibc, however. there is a build failure trying to find pci.ids, although it can find usb.ids fine Aug 03 17:46:03 although I'm not sure how it's finding the latter Aug 03 17:46:20 temporary server failure? Aug 03 17:46:20 I believe that older libudev is crashing my code Aug 03 17:46:34 nothing do to with that Aug 03 17:46:39 this is configure barfing Aug 03 17:47:02 bw, any size delta for udev ancient => udev current? Aug 03 17:47:07 *btw Aug 03 17:47:18 if I could build it, I'd tell you Aug 03 17:47:38 and old udev doesn't set up its .so symlinks properly Aug 03 17:50:30 just built fine on uclibc (the old udev) Aug 03 17:51:05 also pci.ids sounds like pciutils, not udev Aug 03 17:51:06 didn't suggest otherwise :o but look at the files in that post I made Aug 03 17:51:10 it is Aug 03 17:51:18 and usb.ids is usbutils Aug 03 17:52:16 you are welcome to the patched Makefile I have for udev, then you can try :p Aug 03 19:07:22 KanjiMonster: ping Aug 03 19:07:35 luka12345|wiik: pong Aug 03 19:08:57 hi, do you have commit access to packages/libs/libosip2 Aug 03 19:12:30 yes, why are you asking? (btw, the at not compiling is the doubled libelf's fault, not at's) Aug 03 19:13:41 i would like to bug you to commit something for me; sec Aug 03 19:14:32 this one: https://lists.openwrt.org/pipermail/openwrt-devel/2011-July/011670.html Aug 03 19:15:58 regarding at; did you fix libelf then? Aug 03 19:16:56 luka12345|wiik: not completely Aug 03 19:23:43 KanjiMonster: could you also commit this one: https://lists.openwrt.org/pipermail/openwrt-devel/2011-August/011794.html Aug 03 19:37:52 luka12345|wiik: what happened to the plugins of privoxd? not needed/dropped in 0.8? Aug 03 20:00:22 wah, what about all my patches? Aug 03 20:01:34 KanjiMonster: i removed them to save space, i can make menu to enable them or you can commit without removing that line Aug 03 20:22:15 luka12345|wiik: since I don't use VoIP at all, I can't really tell whether something is needed or not, so I have to ask you (especially since you never explained the resoning for removing the plugins in your patch subject ;) Aug 03 20:25:45 moo Aug 03 20:26:28 * Chocky threatens Kanji with a sharp patch Aug 03 20:39:52 Chocky: I don't even know which your patches are ;p Aug 03 20:40:11 https://dev.openwrt.org/ticket/9483 Aug 03 20:40:12 luka12345|wiik: looking at the plugins, they all look useful to me (except for the demo plugin ;) Aug 03 20:41:15 KanjiMonster: i'll send new patch with the MENU enabled so one can choose what to enable Aug 03 20:41:39 Chocky: ah, sorry, I won't touch (e)glibc stuff with a teen foot pole; no space/time for an additional toolchain build Aug 03 20:41:50 aw Aug 03 20:41:53 no one will Aug 03 20:42:00 KanjiMonster: can you then only commit libosip2? Aug 03 20:42:27 all you have to do is make sure it doesn't break uclibc. glibc is bust already. these are fixes Aug 03 20:42:40 so, you have nothing to lose Aug 03 20:46:12 * Chocky tickles kanji Aug 03 20:47:48 Chocky: yes, time - also why don't you testbuild them? You seem to have plenty of space, if you use (e)glibc ;p Aug 03 20:48:15 I have Aug 03 20:48:17 your patches would profit from a full path what they are patches; currently I have to guess *what* Makefile they are indented for Aug 03 20:48:19 hence the post Aug 03 20:48:23 *patching Aug 03 20:48:25 fair Aug 03 20:48:55 if I generate complete patches (where relevant) will you post them? Aug 03 20:49:37 or I could just tell you :p Aug 03 20:49:40 whatever is easy. Aug 03 20:52:36 moo? Aug 03 20:52:44 I was looking at the patches Aug 03 20:52:49 yay Aug 03 20:53:12 the newer glibc versions one is the only one that looks like it might be easy to fixup so it can be applied Aug 03 20:53:23 but you missed adding proper md5sums to the Makefile Aug 03 20:53:31 right, it's just to the package, config Aug 03 20:53:33 noted Aug 03 20:55:52 glibc-ports probably wants md5sums, too (and you might want to check if the patches there are still needed) Aug 03 20:56:07 no patches needed for 2.13, as noted Aug 03 20:56:20 I'd suggest ditching 2.6/2.7, way too old Aug 03 20:56:38 I meant the ones in glibc-ports Aug 03 20:57:13 well, those are for 2.4-2.7, so same deal Aug 03 21:01:55 let me regenerate the glibc/glibc-ports patch Aug 03 21:02:29 also generally you should try to keep it to one bug per ticket; makes it easier to track what's fixed and what isn't (or directly send patches to the ML - see https://dev.openwrt.org/wiki/SubmittingPatches ) - you can always send them as RFC or RFT (the response rate isn't the best though) Aug 03 21:09:30 jogo * r27886 /packages/libs/libosip2/ (Makefile patches/001-automake-compat.patch): Aug 03 21:09:30 [packages] upgrade libosip2 package Aug 03 21:09:30 Upgrade to new version and refresh patches. Aug 03 21:09:30 Signed-off-by: Luka Perkov < openwrt ->-to->- lukaperkov.net > Aug 03 21:19:14 stupid IRC Aug 03 21:20:50 kanji: moo Aug 03 21:33:07 KanjiMonster: thx, i'll update siproxd Makefile, add menu and send update to the list Aug 03 21:46:42 luka12345|wiik: I'm not 100% sure if a menu is needed, I'd probably just packages them in a -plugins package (they are small enough) Aug 03 22:38:31 * Chocky pokes Kanji Aug 03 22:44:40 Chocky: I'd say keep the older versions (also if you remove them, then at least do it properly and also remove their patches ;p) Aug 03 22:45:24 well, yes. that's pretty easy with SVN write access. :p Aug 03 22:45:35 my comments say that Aug 03 22:46:54 the older versions don't compile. they just waste people's time. and those are archaic versions of glibc Aug 03 22:49:04 been trying for weeks to get someone to deal with my patches :-( Aug 03 22:55:01 so...? Aug 03 22:55:03 :-( Aug 03 22:57:59 Chocky: I'm fine with adding a new version, but not with removing the older ones if I can't test the new one - I'd rather let someone with glibc experience do that Aug 03 22:58:30 so, what do I need to do? Aug 03 22:59:37 I have tested the glibc stuff about as extensively as I can, FWIW Aug 03 23:09:55 Chocky: there's not much you can do for me in that respect; I'm just not even a (e)glibc user, so I'm not confortable with poking to much into the (e)glibc parts Aug 03 23:11:30 like I said. the build is bust now, and has been for quite some time for glibc/eglibc. I have no interest in breaking uclibc. At least one other person has testing my patches. Who do I need to bribe/make see the light? Aug 03 23:12:13 I have offered to maintain the support. I'm not an openwrt dev of course, but nevertheless the offer is there Aug 03 23:16:57 perhaps my plan is to bug the devs enough until they make me one :p My OSS credentials are pretty extensive Aug 03 23:18:35 build #53 of ar71xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/53 Aug 03 23:19:22 ^ new kernel option Aug 03 23:19:49 FireWire sound devices (SND_FIREWIRE) [Y/n/?] (NEW) Aug 03 23:23:15 moo Aug 03 23:28:51 jogo * r27887 /trunk/target/linux/generic/ (config-2.6.39 config-3.0): [kernel] generic: Add missing config symbol Aug 03 23:29:01 Chocky: there, fixed Aug 03 23:29:06 * Chocky looks Aug 03 23:32:34 * Chocky wonders what he's looking at Aug 04 00:26:23 build #48 of au1000 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/48 Aug 04 00:36:04 nbd * r27888 /trunk/package/mac80211/patches/ (570-mac80211_send_bar.patch 571-ath9k_send_bar_fix.patch): ath9k: rework handling of sending BlockAckReq frames, should hopefully lead to fewer latency spikes Aug 04 00:36:08 nbd * r27889 /trunk/package/mac80211/patches/572-ath9k_sw_retry_reduce.patch: ath9k: reduce the number of software retries, include hardware a-mpdu retries in retry counting Aug 04 00:36:12 nbd * r27890 /trunk/package/mac80211/patches/ (2 files): ath9k: add some code to control internal driver queue length limits **** ENDING LOGGING AT Thu Aug 04 02:59:57 2011