**** BEGIN LOGGING AT Sat Mar 29 03:00:00 2014 Mar 29 03:10:29 hmm.. ignorance of what, in this case? Mar 29 03:10:54 they're not deliberatly disclosing Mar 29 03:11:03 not deliberately not disclosing sorry Mar 29 03:11:17 they're just too incompetent/stupid to realise that they should Mar 29 03:11:25 wouldn't it be easier for the development to happen in svn trunk? Mar 29 03:11:43 or for the main dev to have given some sign on openwrt-devel by now? Mar 29 03:11:53 (even just "go away, I'm working on a linksys project") Mar 29 03:12:42 you're thinking too logically :) Mar 29 03:13:04 my one weakness.. Mar 29 03:35:41 build #29 of sunxi is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/sunxi/builds/29 Mar 29 03:43:37 about to upgrade to trunk.. wish me luck Mar 29 03:59:24 success! Mar 29 04:16:31 build #11 of pxa is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/11 Mar 29 05:25:04 build #562 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/562 Mar 29 05:53:37 build #11 of brcm2708 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/brcm2708/builds/11 Mar 29 06:03:18 build #513 of ar7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/513 Mar 29 06:30:13 build #11 of omap is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/omap/builds/11 Mar 29 07:04:55 build #11 of x86_64 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/x86_64/builds/11 Mar 29 07:13:06 build #555 of cobalt is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/555 Mar 29 07:13:37 soma: ping Mar 29 07:26:47 build #423 of ep93xx is complete: Failure [failed shell_15] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/423 Mar 29 07:29:12 build #562 of atheros is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/562 Mar 29 07:32:54 build #105 of mvebu is complete: Failure [failed shell_15] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/105 Mar 29 13:06:28 build #11 of mpc83xx is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/11 Mar 29 14:40:33 build #11 of adm8668 is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/11 Mar 29 15:58:24 * swalker wonders why people are still so in love with linksys and their products Mar 29 16:01:17 because they are widely available, you can walk into any retail store, just about anywhere, and buy them Mar 29 16:01:28 availability is a big part of how folks choose things Mar 29 16:17:27 blogic: I hope you aren't completely denying the fact that people get annoyed when their patches sit on patchwork for amount of time with no comments or commits when any issues are addressed by the author(s) Mar 29 16:20:37 swalker: i hope you are not going to start a stupid conversation claiming we Mar 29 16:20:44 1) dont ever merge anyhting ever Mar 29 16:20:50 2) that it is because of belkin Mar 29 16:21:02 because in that case i would have to tell you the same thing i wrote on the ml Mar 29 16:21:26 swalker: i hope you are not cmpetley denying the fact that everyone is really busy making ends meet and building the best router os on the planet ? Mar 29 16:21:44 swalker: because to be honest we have 2 groups of users Mar 29 16:21:51 1) those doing good work and contributing Mar 29 16:22:32 2) those bitching about minor details and expecting the HEAD rev to always be on the latest version of everything within 1 day of upstream releasing a new version Mar 29 16:23:19 swalker: i hope you enjoy the amazing free product in future and feel free to rant about pointless details Mar 29 16:23:23 ;) Mar 29 16:24:56 Have to disagree blogic, it's not a routeros Mar 29 16:25:08 it's a stripped down embedded os, useful for far more than just routers Mar 29 16:25:33 works great in various data collecting and/or control applications too Mar 29 16:25:44 even if there is only one network connection, and no routing involved Mar 29 16:26:36 just my $0.02, and since pennies have been made redundant in Canada, it rounds to $0.00 today Mar 29 16:28:07 groz: sorry Mar 29 16:28:18 groz: to be precise it is a embedded build system Mar 29 16:29:01 groz: the fact that you comment on the technical description of owrt tells me that the rest of what i said seemed fine to you :) Mar 29 16:29:37 :) Mar 29 16:29:44 uh huh Mar 29 16:29:47 lol Mar 29 16:30:26 and I do stand corrected, it's not an embedded os, it is indeed a build system that produces an embedded os Mar 29 16:30:36 sometimes minor details make big differences :P Mar 29 16:30:45 well, i think it's more than a build system Mar 29 16:31:17 just think of all the code that we've written to turn the linux userspace into something decent ;) Mar 29 16:31:45 see, what this shows, it's actually 'all a matter of perspective' Mar 29 16:31:48 I don't agree with his "never merging" statement & the belkin accusation was unneeded. Mar 29 16:32:37 my project this weekend, is to try figure out the 'right' kernel patch bits for this airgateway Mar 29 16:32:44 swalker: your opinion forming rant disguised as a question was unneeded Mar 29 16:32:46 what I have is working, but, it's definitely not 'right' Mar 29 16:32:54 dont deal out if you cant handle the reply Mar 29 16:33:06 meh, never any point to ever discussing this Mar 29 16:33:16 cuz I'm using something out of the mailing list, that just hacks on the airrouter init code, to get the airgateway running Mar 29 16:33:29 groz: that ubnt hw ? Mar 29 16:33:34 yes Mar 29 16:33:39 ubnt airgateway Mar 29 16:33:40 brb .. baby is crying Mar 29 16:34:00 it's the little bullet that goes onto the poe injector Mar 29 16:34:15 I bought a few of them, cuz they are dirt cheap Mar 29 16:34:26 and i have a few surplus injectors Mar 29 16:35:17 I've worked up all the bits needed in userland for base files etc Mar 29 16:35:30 but now gotta figure out the 'right' way to do the init stuff in the kernel Mar 29 17:00:07 nbd r40297 trunk/package/network/ (7 files in 2 dirs) * dropbear: update to 2014.63 Mar 29 17:00:11 nbd r40298 trunk/package/network/services/dropbear/files/dropbear.init * dropbear: fix interface config setting Mar 29 17:05:33 iirc, netifd is an rpc.. service?! Mar 29 17:06:12 nbd r40299 trunk/package/network/services/dropbear/files/dropbear.init * dropbear: add options SSHKeepAlive and IdleTimeout. Mar 29 17:06:57 Devastator: it's a daemon for managing network interfaces (wireless and wired) Mar 29 17:07:18 and assuming the risk of talking non sense, I have to ask: is ifupdown (used by debian) an rpc service as well? If so, I wonder if someday netifd can replace ifupdown Mar 29 17:07:47 it seems way more modern and intelligent (eg: it tracks everything) Mar 29 17:07:48 i think ifupdown does not run as a daemon Mar 29 17:08:06 yes.. it's a bunch of old scripts Mar 29 17:08:17 it's possible to use netifd on a non-openwrt system as well Mar 29 17:08:28 you just need to pull in the library and config stuff as well Mar 29 17:08:45 nbd: can you please also apply https://github.com/cpatulea/openwrt/commit/0211a7b272fc5fabf9cce87dcaaa4f62892377c9 ? the original patch breaks incremental builds Mar 29 17:09:28 why the removal of --with-shared ? Mar 29 17:09:41 configure complains about not recognizing it Mar 29 17:09:42 size considerations? Mar 29 17:09:45 ah Mar 29 17:09:46 ok Mar 29 17:09:52 "drop --with-shared which is unknown to configure" Mar 29 17:09:57 I was wondering this for over a month now, because I saw your presentation you said lots of companies were using openwrt swconfig for example Mar 29 17:10:06 eigma: I only look at the red and green stuff ;) Mar 29 17:11:03 and with network setups becoming even more complex, something like netifd would help a lot in normal linux distros (like debian) Mar 29 17:11:14 at least is what I think Mar 29 17:11:25 well... I try to write good commit messages for a reason. it's a shame if no one reads them. Mar 29 17:11:30 nbd r40300 trunk/package/network/services/dropbear/Makefile * dropbear: move options.h editing to Build/Configure Mar 29 17:11:53 eigma: sorry about that - short attention span today Mar 29 17:12:05 nbd: thanks. Mar 29 17:12:11 np Mar 29 17:12:49 Devastator: I suppose it will not be accepted by the linux community until its absobed by systemd *heh* Mar 29 17:12:52 we could really use some people maintaining a staging queue with tested patches pulled from openwrt-devel Mar 29 17:13:15 nbd: the problem is the long term reliability of said people Mar 29 17:13:19 yep Mar 29 17:13:24 most of the activists are short lifespan Mar 29 17:13:30 jow_laptop tell me about it, this is still widely discussed Mar 29 17:13:31 because activism is not lifestyle Mar 29 17:13:57 we need people that are foss ahckers for a lifestyle and not a activity Mar 29 17:13:58 that's why it needs to be handled by multiple people Mar 29 17:14:04 yes Mar 29 17:14:19 we need for a start 1 person, that we trust to ahndle the acl of the github account Mar 29 17:14:19 if someone were sponsored to do this full time, it would be a different story Mar 29 17:14:21 i think part of it, folks tend to get things working, then move on to 'more pressing' stuff Mar 29 17:14:21 the whole patch acceptance stuff is something that could easily be handled by people that don't have too much spare time Mar 29 17:14:27 and manage who we pull from and so on Mar 29 17:14:33 groz: yes Mar 29 17:14:44 groz: that is called activist activity Mar 29 17:14:59 oh noes, I'm an activist :( Mar 29 17:15:08 i watch here a lot, but, I shudder at times when I build newer stuff, then start pushing it onto routers I actually use Mar 29 17:15:15 thats why I want people to found a git{hub,orious,whatever} feed and get their act together there Mar 29 17:15:16 Devastator: is that a bad thing ? Mar 29 17:15:19 for fear of things breking Mar 29 17:15:25 I'm reluctant to accept any new packages Mar 29 17:15:46 jow_laptop: i am going to propose on -hackers that we drop the majority of packages/ after te BB release Mar 29 17:15:48 blogic well, it is for the project itself Mar 29 17:15:53 then handle the most used 20% ourselves Mar 29 17:16:03 offload the rest to a github and let people deal with it Mar 29 17:16:13 the overall health of the project will immensly grow Mar 29 17:16:40 blogic: we must not strictly drop them, we move a copy to a public repo and stop touching it, then watch it falling apart until someone steps in and takes up maintainership of a few packages Mar 29 17:16:43 have a mainatined trunk and a packages feed of ~200 most used packages and maintain them aswell Mar 29 17:16:45 I have a whole tree of specialty stuff here, all dealing with astronomy hardware Mar 29 17:16:57 jow_laptop: yes, sorry was imprecise Mar 29 17:16:58 that I've been contemplating what is the right way to get 'out there' Mar 29 17:17:06 we also need to break down the monolythic packages/ into subsystems like networking, system tools, multimedia, ... Mar 29 17:17:10 groz: an astronomy feed Mar 29 17:17:16 jow_laptop: yep Mar 29 17:17:20 jow_laptop: i'm not sure we should split it up too much Mar 29 17:17:21 yes, but, where is appropriate to host it Mar 29 17:17:38 much of it comes via the indilib sourceforge, and I've built openwrt wrappers Mar 29 17:17:39 nbd: i would say more into multimedia, networking, telephony, X .... Mar 29 17:17:42 nbd: I do not want a super fine grained categorization Mar 29 17:17:46 I may just commit it into the indi sourceforge tree Mar 29 17:17:47 groz: git.openwrt.org Mar 29 17:18:00 groz: you are a founder after all, we can host your feed for you :) Mar 29 17:18:09 but stuff like vorbis encoder libraries and so on which are only used by streaming servers, mpd, minidlna etc. really belong all together into an own multimedia feed Mar 29 17:18:18 lol, well, I may have been really invovled years ago, I'm kinda on sidelines these days Mar 29 17:18:19 jow_laptop: +1 Mar 29 17:18:34 groz: so ... i am only aware of one dev that left the project Mar 29 17:18:39 and this stuff I'm doing, has very limited appeal Mar 29 17:18:42 the rest are still devs, regardless of activity Mar 29 17:18:43 jow_laptop: i think feeds need to be split up from a maintainer group point of view, not from a technical categorization point of view Mar 29 17:18:50 i mean we even have devs that never made a commit :) Mar 29 17:18:53 can I give a lousy suggestion? what about sending a list of unmaintained packages to the list and see if someone steps up to maintain it, and if a package is not claimed in X days it can be flagged out or something Mar 29 17:19:06 nbd: well the thing is, if I want icecast for openwrt I have to take care of the transcoding libraries too Mar 29 17:19:46 but there's probably going to be tons of libraries that don't fit into a clear category, or that start out as belonging to one feed, then suddenly get used elsewhere Mar 29 17:19:48 and libraries only needed by one specific package belong into the same feed as the requiring package Mar 29 17:19:55 brb ... need to make dinner Mar 29 17:19:57 I don't understand.. you talk about needing maintainers to step up, but people are already sending you patches. what is lacking there? Mar 29 17:19:58 if other people get feeds going, can we get some support for build infrastructure? Mar 29 17:20:15 stuff like that is easier to handle if it's spread over fewer trees, with informal agreements of tree maintainers over who handles what Mar 29 17:20:20 eigma maybe the quality of the patches? Mar 29 17:20:23 I maintain a "feed" of packages we maintain, but it's just the makefiles and patches, in a git hub tree Mar 29 17:20:32 karlp: nbd did some work to bring the SDK up to shape, the idea is to only build core openwrt in the future, then process all feeds using the generated SDK Mar 29 17:20:33 you can't point at it and get the binaries for other platforms Mar 29 17:20:46 karlp: this will allow asynchroneous building of feeds, untied from the snapshot build cycle Mar 29 17:20:54 yeah, if I maintain a tree, I would also want buildbot support, otherwise people won't care Mar 29 17:20:56 one of the issues I see with separation, is, folks dont have access, or often even inclination, to deal with different arch problems Mar 29 17:21:00 eigma: exactly, Mar 29 17:21:11 and I only have ar71xx devices Mar 29 17:21:14 example, one of the drive sets I ran into was heavily dependant on little endian Mar 29 17:21:27 and it was a fair amount of work to get the cameras working on a BE setup Mar 29 17:22:07 I have no idea what problems will start popping up on various different hardware configurations Mar 29 17:22:12 on the other hand we cannot simply build 3rd party feed heads on the buildserver Mar 29 17:22:13 it would be cool if a buildbot ran QEMU VMs to test bootup and a few basic things on the image Mar 29 17:22:29 its too dangerous Mar 29 17:23:03 I understand that, but if I just have a github feed and people have to build their own images, it's kinda pointless Mar 29 17:23:07 we already had situations where bad dependecy specifications in a 3rd party feed caused stuff like libsqlite3 to end up bui,ltin in the snapshot images Mar 29 17:23:40 I maintain a github feed but it's only really a staging area before it goes to openwrt packages (well, or whatever that will be in the future) Mar 29 17:23:44 right, but we can easily integrate sdk based builds into the buildbot stuff Mar 29 17:23:47 karlp: what I am getting at is that we will need to reference (reviewed) specific revisions of external feeds and Mar 29 17:23:57 so we won't run into that kind of issue with third party feeds ever again Mar 29 17:24:00 I could easily write a makefile, which once completed, and built, the buildbot in question is now owned Mar 29 17:24:04 i think we should probably even do it for BB already Mar 29 17:24:09 then have a mechanims to regularily bump the referenced revision, based on feed maintainer input Mar 29 17:24:10 reviewing every patch is tough and time consuming, and trusting people is also a delicate matter.. Mar 29 17:24:10 for the release build Mar 29 17:24:16 have separate binary feeds for packages Mar 29 17:24:39 right Mar 29 17:25:02 base snapshot is from some small core set of pkgs, and each source feed gets built into separate feeds of ipks Mar 29 17:25:11 so is there still a window for any package updates before BB gets released? Mar 29 17:25:41 on a completely different subject, is there an easy configurable option somewhere, to tell procd hands off the watchdog ? Mar 29 17:26:24 for a process control endpoint, I'd much rather have my process application take watchdog, and not a separate daemon Mar 29 17:26:24 -hackers is a private list? Mar 29 17:29:29 and what's going on with dev.openwrt.org? is it still having issues? Mar 29 17:30:04 I asked jow_laptop how much traffic it got, because I wanted to load test my own instance, but he never replied Mar 29 17:32:51 right now its being requested at a rate of ~16requests/second Mar 29 17:34:12 interstingly most of that by UAs identifying themselves as just "Mozilla/5.0", but from wildely different ip ranges Mar 29 17:34:29 seems to be same crawling operation running amok Mar 29 17:34:44 is ralink difficult to maintain or is just my impression? Mar 29 17:34:55 especially since the same /wiki/ urls are accesed over and over Mar 29 17:35:03 I believe it is a deliberate DoS attempt Mar 29 17:38:20 Devastator: just you Mar 29 17:38:35 Devastator: you are just not very good at getting support Mar 29 17:38:57 lots of people get good quality support because they know how to act in a manner that results in them getting what they want Mar 29 17:39:23 build #518 of rb532 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/518 Mar 29 17:39:24 nbd: thank you for the dropbear commits Mar 29 17:40:22 blogic maybe, but I'm didn't look for support in about.. 3 months, not complaining either, just wondered if ralink had poor code quality as broadcom has Mar 29 17:40:23 build #518 of ppc44x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/518 Mar 29 17:41:10 the only issue I have remaining will probably be fixed before BB release, so I just have to wait :) Mar 29 17:42:24 build #487 of sibyte is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/487 Mar 29 17:42:31 jow_laptop: ok. I need to know how much is to /browser and how much to /wiki, because those have very different serving costs. can you put an access.log up somewhere? with IPs removed if you want. Mar 29 17:42:35 build #425 of iop32x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/425 Mar 29 17:49:17 eigma: pm me your mailaddr Mar 29 18:22:13 build #547 of ramips is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/547 Mar 29 19:01:30 build #551 of lantiq is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/551 Mar 29 19:13:10 * dtaht_nuc2 awaits feedback and review of the SQM code Mar 29 19:32:42 dtaht_nuc2: are you able to put the patches in a git tree somewhere? Mar 29 19:34:39 All the patches I just posted are in the ceropackages feed already Mar 29 19:35:01 which can be had from https://github.com/dtaht/ceropackages-3.10.git Mar 29 19:35:02 Mar 29 19:35:25 so you can add that feed to your build, do a ./scripts/feeds update Mar 29 19:35:43 ./scripts/feeds install sqm-scripts luci-app-sqm bcp38 Mar 29 19:35:53 enable them to be built and give 'em a shot that way Mar 29 19:36:16 I will note that fact on the list in a second Mar 29 20:04:56 build #497 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/497 Mar 29 20:15:05 noted sqm's general availability in ceropackages-3.10. eigma, thx for pointing that out Mar 29 20:20:57 sure, I was just considering merging them into my own tree. I'll give them a test within the next few days Mar 29 20:21:33 what sort of hardware are you using? My biggest open question is how well the SQM system works on better hardware and higher bandwidths.... Mar 29 20:22:28 wzr-600dhp, essentially an wndr3800 (sorry, I know you've been looking for beefier hardware ;-) ) Mar 29 20:22:33 meh Mar 29 20:22:47 600dhp does have a little more RAM than 3800 Mar 29 20:22:55 no worries. I like the wzrs, there were the number 2 pick for the cerowrt project.... Mar 29 20:22:55 not by much though Mar 29 20:23:05 and my upstream connection is not near enough to saturate the CPU Mar 29 20:23:09 ram doesn't matter. k Mar 29 20:23:26 well, I look forward to hearing if sqm works better than qos-scripts in your case... Mar 29 20:23:41 I don't use qos-scripts actually, just a very simple custom setup in /etc/rc.local Mar 29 20:24:06 http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310 Mar 29 20:24:37 nothing fancy here.. http://sprunge.us/fYSX Mar 29 20:24:55 I trust my devices to set TOS honestly Mar 29 20:26:12 oh, cool, that's basically what eric uses. Mar 29 20:27:49 however at 1mbit, you will do better to use fq_codel quantum 300 target 15ms limit 600 interval 150ms Mar 29 20:28:15 * dtaht_nuc2 wonders how much more efficient tbf is than htb Mar 29 21:28:39 dtaht_nuc2: I'm not sure who Eric is Mar 29 21:32:40 the biggest difference in your fq_codel parameters from default are the quantum and limit Mar 29 21:32:51 quantum is 1514 default. this page suggests "The quantum must be a number of bytes at least as large as the network MTU" http://intronetworks.cs.luc.edu/html/queuing.html#quantum-algorithm Mar 29 21:35:00 although, to be fair, the full discussion tht follows is a bit beyond me Mar 29 21:35:22 the other difference is limit Mar 29 21:35:27 default 1024 Mar 29 21:35:29 *10240 Mar 29 21:36:47 eigma: eric dumazet wrote fq_codel. I'm the guy that got codel working in the first place from the paper. :) Mar 29 21:36:57 quantum should 300 on slow links. :) Mar 29 21:37:09 limit needent' be much bigger than a few hundred packets on slow links. Mar 29 21:37:13 trust me. :) Mar 29 21:37:25 mind explaining though? Mar 29 21:37:38 https://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00 Mar 29 21:37:55 https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/ Mar 29 21:38:22 http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html Mar 29 21:38:47 you want to deprioritize uploads at these sort of speeds, so Mar 29 21:39:24 using a smaller quantum pushes uploads in particular into fq_codel's slow queue. tcp acks, on the other hand, get serviced regularly (they are typically 66) making downloads not starve uploads and vice versa Mar 29 21:39:43 http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die Mar 29 21:39:55 hopefully that should supply sufficient background reading. :) Mar 29 21:40:18 and btw, in openwrt, fq_codel defaults to quantum 300 already. Mar 29 21:40:37 but we are finding at below 4mbit, it pays to increase the target latency to account for that mtu. Mar 29 21:41:10 indeed. qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn Mar 29 21:41:47 that's from a live 'tc qd show' Mar 29 21:42:16 signing off for a bit Mar 29 21:42:40 wow, that's a good page you sent. Mar 29 21:42:43 cya Mar 29 21:43:04 needs to be updated for fq_codel. :) **** ENDING LOGGING AT Sun Mar 30 02:59:59 2014