2012-04-08 00:01 do they plan to also change the schematics file format? 2012-04-08 00:03 i think so, yes. it would make sense anyway 2012-04-08 00:08 as long as it supports both the old and new format, we have a nice and unrushed migration path 2012-04-08 00:25 running MACHINE=beaglebone bitbake console-image. Why on earth is it building xorg & gtk? 2012-04-08 00:30 whoops - wrong chl. srry... 2012-04-08 00:30 emeb, because some console software are built with Xorg use flags 2012-04-08 00:31 yep - figured it was some sort of silly dependency thing. 2012-04-08 01:10 xwalk has joined #qi-hardware 2012-04-08 02:27 antgreen has joined #qi-hardware 2012-04-08 02:52 pabs3 has quit ["Don't rest until the streets are paved in poems."] 2012-04-08 02:53 pabs3 has joined #qi-hardware 2012-04-08 02:57 pabs3 has joined #qi-hardware 2012-04-08 04:09 GNUtoo-desktop has joined #qi-hardware 2012-04-08 04:24 rejon has joined #qi-hardware 2012-04-08 06:17 wolfspra1l has joined #qi-hardware 2012-04-08 06:36 [commit] Wolfgang Spraul: upleveled cmdline patches to kicad bzr 3493 (master) http://qi-hw.com/p/eda-tools/49d4ae6 2012-04-08 07:24 jekhor__ has joined #qi-hardware 2012-04-08 08:10 jekhor has joined #qi-hardware 2012-04-08 09:31 LunaVorax has joined #qi-hardware 2012-04-08 09:50 kristoffer has joined #qi-hardware 2012-04-08 10:12 Martix has joined #qi-hardware 2012-04-08 10:49 HTTP 500 on http://projects.qi-hardware.com/index.php/p/qi-kernel/source/tree/master/ -\ 2012-04-08 10:51 yes, I know 2012-04-08 10:51 but thanks for reporting! 2012-04-08 10:55 no problem :) 2012-04-08 11:08 GNUtoo-desktop has joined #qi-hardware 2012-04-08 11:16 xiangfu has joined #qi-hardware 2012-04-08 11:37 wolfspra1l: got the patches from xiangfu - however i'm a bit confused about them 2012-04-08 11:38 they now just affect the xburst-target - i thought the wpan-stuff should be moved into the generic part and be available for all targets? 2012-04-08 11:54 DocScrutinizer has joined #qi-hardware 2012-04-08 12:05 mirko: well one by one. the wpan hardware and drivers are separate pieces, so this is just a clean kernel update now, which builds fine 2012-04-08 12:05 The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120407-0750 2012-04-08 12:11 wolfspra1l: ah, ok - got it 2012-04-08 12:16 wolfspra1l: that makes the review far more easy since you're the main user space and it's (just) you who will be affected by bugs :) 2012-04-08 12:16 speed & quality 2012-04-08 12:16 thanks for your time to review! 2012-04-08 12:18 there's only a small number of Ben users now, so if that breaks use cases of far more widely available devices: bad 2012-04-08 12:21 [commit] kyak: gcc-mips: correct md5sum (master) http://qi-hw.com/p/openwrt-packages/0bd9efe 2012-04-08 12:39 wolfspra1l: commited (https://dev.openwrt.org/changeset/31218) 2012-04-08 12:40 i'd really love to get the wpan stuff upstream 2012-04-08 12:40 so don't hesitate to send me related patches for review 2012-04-08 12:41 oh sure, definitely. but there was some movement in kernel.org too I think, related to wpan 2012-04-08 12:41 let me dig a little - plus some testing on non-xburst targets... 2012-04-08 12:41 it's easy to plug an atusb into a router with usb support, so that should definitely work first - then patch 2012-04-08 13:01 mirko: why did you decide not to commit some patches (like for modifier keys or for fbcon color fonts)? 2012-04-08 13:03 kyak: most likely because they didn't go into my inbox? :) 2012-04-08 13:03 ah! :) i thought you based your work on what's in openwrt-xburst repo 2012-04-08 13:04 so maybe xiangfu knows why 2012-04-08 13:04 kyak: probably - at least he's the person i got the patches from 2012-04-08 13:05 kyak: what is ready for upstream? 2012-04-08 13:05 wolfspra1l: if you mean openwrt upstream - i think all of them are ready (we use them for Ben image releases after all). If we speak about kernel upstream - i have no idea 2012-04-08 13:06 the case with this patch was special because mirko said he wanted to get the xburst kernel updated and xiangfu sent a patch for just that directly to mirko by mail 2012-04-08 13:06 kyak: we (openwrt) are going to release in june/july and we want to get rid of old kernel versions, since currently we have to maintain generic patches for 8 kernel versions 2012-04-08 13:07 so maybe xiangfu decided some patches are not ready for openwrt upstream (or maybe he thought it would be more convenient to leave them at openwrt-xburst repo and have control over them) 2012-04-08 13:07 all targets not levelled up to a current version will get dropped therefore 2012-04-08 13:07 I would love to upstream more, but there seems a bottleneck in the review process 2012-04-08 13:08 I would think a good way are attachments in the bug tracker, or patches sent to the mailing list 2012-04-08 13:08 but I regularly hear and see them being ignored... 2012-04-08 13:08 mirko: yea, i got you. I hope 3.2.1 version is sufficient not be get dropped? :) 2012-04-08 13:08 you can still try to get them upstream via me - will try to give feedback asap then 2012-04-08 13:08 mirko: do patches to the openwrt mailing list work? 2012-04-08 13:09 wolfspra1l: should 2012-04-08 13:09 ;-) 2012-04-08 13:10 wolfspra1l: you might also ping me additionally in irc/jabber 2012-04-08 13:10 i agree with wolfgang - it is really hard to get response in openwrt ticket systems even with patches, unless i contact mirko or jow directly 2012-04-08 13:10 kyak: I think if you have a high quality piece that you are reasonably sure will not break other targets, email mirko directly 2012-04-08 13:10 i agree as well, that's why i tried to get most OpenWrt devs together in athens 2012-04-08 13:11 to talk about that 2012-04-08 13:11 the meeting went quite productive and we're kina restructering and realizing agreed solutions 2012-04-08 13:11 wolfspra1l: yep, i usually ping or pm in IRC :) 2012-04-08 13:12 wolfspra1l: kyak: ack - if you think review overhead might be small send it to openwrt-devel / attach the patch to a ticket and ping me 2012-04-08 13:13 mirko: thanks! 2012-04-08 13:15 welcome, we know about the openwrt patch situation and its perceived image, however there's no simple, immediat and satisfying solution 2012-04-08 13:15 that's why we met in greece 2 weeks ago :) 2012-04-08 13:17 how many people were there? and how many openwrt devs are there overall? 2012-04-08 13:18 will definitely spend more time reviewing the mailing list and tickets from now on 2012-04-08 13:18 kyak: there were 7 (and therewith most of the core team) present in greece 2012-04-08 13:19 kyak: about the people having commit access take a look here: https://dev.openwrt.org/wiki/people 2012-04-08 13:20 i see, so probably not so many developers visited 2012-04-08 13:20 as said, most of the core-team did 2012-04-08 13:21 lemme re-phrase: most of the currently active devs participated 2012-04-08 13:22 people get added to the wiki-page, however not removed :) 2012-04-08 13:24 you should call it "hall of fame" then ;) 2012-04-08 15:18 B_Lizzard has joined #qi-hardware 2012-04-08 15:18 B_Lizzard_ has joined #qi-hardware 2012-04-08 15:42 panda has joined #qi-hardware 2012-04-08 15:42 kyak: your gettext patches look fine, did you compile test them? 2012-04-08 15:43 I have to hunt down another regresion atm so I don't want to recompile gettext just now because it takes ages 2012-04-08 15:59 jow_laptop: sure, recompiled and tested 2012-04-08 16:02 jow_laptop: however, note the comment about DISABLE_NLS - you shouldn't apply the rules.mk patch 2012-04-08 16:03 yes, seen it 2012-04-08 16:04 emeb has joined #qi-hardware 2012-04-08 16:05 did you set the nonexistant variable name CONFIG_ENABLE_LOCALE for the same reason, i.e. explicit --enable-nls brakes some packages? 2012-04-08 16:06 I don't know the background 2012-04-08 16:06 I inherited lots of it and cleaned it up step by step 2012-04-08 16:06 I believe --disable-nls is one of the first optimization attempts, before we started punching autofail into obedience 2012-04-08 16:08 leaving rules.mk like it is now is pretty safe; then i just add DISABLE_NLS:=--enable-nls in the package's Makefile, if i really want NLS 2012-04-08 16:09 yes, bringing solid nls support is an equally big task as introducing libtool 2.x into the tree 2012-04-08 16:09 so we cannot do it globablly for now 2012-04-08 16:10 and there is actually just one package so far where i really wanted NLS.. probably there are more to come 2012-04-08 16:10 yeah. Point is it should work equally well with both nls on and off 2012-04-08 16:10 so there needs to be an automagic way to package up *.mo files 2012-04-08 16:10 hm right.. 2012-04-08 16:11 probable a job for nls.mk 2012-04-08 16:11 yeah, we could add another hook which does find $(PKG_INSTALL_DIR) -name '*.mo' | xargs cp somewhere 2012-04-08 16:17 this reminds me our discussion about automagical creation of *-dev packages :) 2012-04-08 16:18 right, me too 2012-04-08 16:33 jow_laptop: do you know why the toolchain in staging_dir/toolchain-* requires STAGING_DIR env variable to be set? 2012-04-08 16:33 it wasn't like that some time ago 2012-04-08 16:34 yes, I changed gcc to require it 2012-04-08 16:34 I got tired of the -I and -L crap 2012-04-08 16:35 and the brainfuck -sysroot is 2012-04-08 16:35 so its now all inferred from the STAGING_DIR env var 2012-04-08 16:35 and not even libtool and autofail are able to break it 2012-04-08 16:36 or other retarded build systems unable to deal with cross compilation 2012-04-08 16:36 hm ok! i only used the toolchain to build external kernel, so i luckily never hit these problems 2012-04-08 16:37 the theory is that you define STAGING_DIR to the dir where your target-libraries and includes are 2012-04-08 16:38 then you stick gcc in PATH and maybe set CROSS_COMPILE and it all works 2012-04-08 16:38 openwrt's versions of automake, autoconf, cmake, flex, bison, libtool etc. are respecting STAGING_DIR as well 2012-04-08 16:38 so the SDK becomes fully relocatable 2012-04-08 16:39 not tied to specific absolute pathes anymore 2012-04-08 16:40 however I have some patches in the queue to make a missing STAGING_DIR env var nonfatal in gcc 2012-04-08 16:40 just haven't had the the time to test it 2012-04-08 16:41 if there was a way to figure out the STAGING_DIR path from the compiler path 2012-04-08 16:42 http://pastebin.com/V2NTWzqK 2012-04-08 16:42 kyak: no there is no way, we had a somewhat related discussion about that here a while ago 2012-04-08 16:42 the problem is that on openwrt one toolchain may serve multiple targets 2012-04-08 16:43 so you cannot infer the target path from the toolchain 2012-04-08 16:43 the toolchain may be even externally provided, in this case there'd be no connection to the target at all 2012-04-08 16:44 yeah.. but what if there is just one staging_dir/target-* directory? then we coudl safely assume that this is the STAGING_DIR. In many cases there is just one target directory 2012-04-08 16:44 external toolchain - yeah, that's the problem.. 2012-04-08 16:44 then some gcc version switch occurs, you got two and get unexpected behaviours and angry users complaining about how "hard" and "unintuitive" it is to compiel C on openwrt ;) 2012-04-08 16:46 you are right :) btw, is the STAGING_DIR set automatically when using prebuilt Toolchain? 2012-04-08 16:47 its set whenever you compile using openwrt makefiles and -targets 2012-04-08 16:47 the prebuilt one is bare, no setup or wrapper scripts 2012-04-08 16:47 so the answer is no, not set automatically 2012-04-08 16:47 but I was thinking about shipping a setup.sh 2012-04-08 16:47 which exports some needed env vars to the current shell 2012-04-08 16:48 so the workflow would be like ./setup.sh; make whatever 2012-04-08 16:48 or ./setup.sh; mips-openwrt-linux-gcc -o test test.c 2012-04-08 16:49 ok, i got you.. one of my small projects (https://github.com/kyak/nanonote_ert) is using gcc from toolchain directly, so i might have to adapt 2012-04-08 17:01 kyak: better add autocrap 2012-04-08 17:24 ow 2012-04-08 17:24 just imagine 2012-04-08 17:24 flash has OPCODES for dealing with XML. 2012-04-08 17:24 wpwrak: consider adding xml opcodes to M1 SoC! 2012-04-08 17:24 just for lulz 2012-04-08 17:34 yeah, and a java p-code core 2012-04-08 17:35 wait, ARM already got that? 2012-04-08 17:35 jazelle 2012-04-08 17:36 Jay7 has joined #qi-hardware 2012-04-08 17:38 damn 2012-04-08 17:38 I found _another_ flash compiler bug 2012-04-08 17:41 jow_laptop: just to confirm - are you waiting for gettext rebuild after the changes before you can accept it? 2012-04-08 17:46 kyak: no, I have to review some gsoc stuff currently 2012-04-08 17:47 jow_laptop: ok, sorry for bothering and thanks! 2012-04-08 18:07 jekhor_ has joined #qi-hardware 2012-04-08 18:09 jekhor__ has joined #qi-hardware 2012-04-08 18:59 I never laughed so hard like at the "RATIONALE" section in Flash compiler sources 2012-04-08 19:00 they should have called it "IRRATIONALE" 2012-04-08 20:07 jekhor_ has joined #qi-hardware 2012-04-08 20:12 jekhor_ has joined #qi-hardware 2012-04-08 20:19 qwebirc84988 has joined #qi-hardware 2012-04-08 20:20 Even though I'm aware that there's apparently little interest here in tablet form factor devices. ... 2012-04-08 20:21 and stipulating that indeed, this is not an OpenHardware device, even so it is interesting (to me) what $100usd buys today. 2012-04-08 20:21 http://www.the-digital-reader.com/2012/04/08/review-polaroid-pmid701-android-tablet/ 2012-04-08 20:22 A couple of weeks ago I purchased the Lenovo 7 inch tablet for $200. It is a solid performer, in some ways better than this one (e.g. has Bluetooth, has two cameras) 2012-04-08 20:24 I find the 7 inch screen quite useable. Fine for email (my main use case) fabulous as a way to view photos. $99 is the new black. ;) 2012-04-08 20:36 Note that from a specs POV, the Lenovo ideaPad A1 trumps the Polaroid as it should for double the price. Biggest Lenovo advantage: screen resolution of 1024x600 2012-04-08 20:38 mth has joined #qi-hardware 2012-04-08 20:52 Aylax has joined #qi-hardware 2012-04-08 21:00 Aylax has joined #qi-hardware 2012-04-08 21:00 zear, ghex 2012-04-08 21:00 (Sorry, wrong chan) 2012-04-08 21:31 Aylax has joined #qi-hardware 2012-04-08 21:38 Aylax has joined #qi-hardware 2012-04-08 21:44 Aylax has joined #qi-hardware 2012-04-08 21:47 wrong planet? sounds like klingon 2012-04-08 23:07 Aylax has joined #qi-hardware