#qi-hardware IRC log for Sunday, 2012-04-08

wpwrakbtw, one of the nice things in recent versions of kicad is that metric grids now work without weird rounding issues. didn't check if it's in fact an internal change (i.e., the switch to nanometers) or if the artefacts of using an internal imperial-based unit are simply covered up. may be the latter. but it still helps.00:01
wolfsprauldo they plan to also change the schematics file format?00:03
wpwraki think so, yes. it would make sense anyway00:05
wpwrakas long as it supports both the old and new format, we have a nice and unrushed migration path00:09
emebrunning MACHINE=beaglebone bitbake console-image. Why on earth is it building xorg & gtk?00:27
emebwhoops - wrong chl. srry...00:32
GNUtoo-desktopemeb, because some console software are built with Xorg use flags00:32
emebyep - figured it was some sort of silly dependency thing.00:33
qi-bot[commit] Wolfgang Spraul: upleveled cmdline patches to kicad bzr 3493 (master) http://qi-hw.com/p/eda-tools/49d4ae606:38
kyakHTTP 500 on http://projects.qi-hardware.com/index.php/p/qi-kernel/source/tree/master/ -\10:50
wolfspra1lyes, I know10:53
wolfspra1lbut thanks for reporting!10:53
kyakno problem :)10:57
mirkowolfspra1l: got the patches from xiangfu - however i'm a bit confused about them11:39
mirkothey now just affect the xburst-target - i thought the wpan-stuff should be moved into the generic part and be available for all targets?11:40
wolfspra1lmirko: well one by one. the wpan hardware and drivers are separate pieces, so this is just a clean kernel update now, which builds fine12:07
qi-botThe build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120407-0750 12:07
mirkowolfspra1l: ah, ok - got it12:13
mirkowolfspra1l: 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 :)12:18
wolfspra1lspeed & quality12:18
wolfspra1lthanks for your time to review!12:18
wolfspra1lthere's only a small number of Ben users now, so if that breaks use cases of far more widely available devices: bad12:19
qi-bot[commit] kyak: gcc-mips: correct md5sum (master) http://qi-hw.com/p/openwrt-packages/0bd9efe12:23
mirkowolfspra1l: commited (https://dev.openwrt.org/changeset/31218)12:41
mirkoi'd really love to get the wpan stuff upstream12:41
mirkoso don't hesitate to send me related patches for review12:42
wolfspra1loh sure, definitely. but there was some movement in kernel.org too I think, related to wpan12:42
wolfspra1llet me dig a little - plus some testing on non-xburst targets...12:43
wolfspra1lit's easy to plug an atusb into a router with usb support, so that should definitely work first - then patch12:43
kyakmirko: why did you decide not to commit some patches (like for modifier keys or for fbcon color fonts)?13:03
mirkokyak: most likely because they didn't go into my inbox? :)13:05
kyakah! :) i thought you based your work on what's in openwrt-xburst repo13:05
kyakso maybe xiangfu knows why13:06
mirkokyak: probably - at least he's the person i got the patches from13:06
wolfspra1lkyak: what is ready for upstream?13:06
kyakwolfspra1l: 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 idea13:07
wolfspra1lthe 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 mail13:08
mirkokyak: 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 versions13:08
kyakso 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)13:09
mirkoall targets not levelled up to a current version will get dropped therefore13:09
wolfspra1lI would love to upstream more, but there seems a bottleneck in the review process13:09
wolfspra1lI would think a good way are attachments in the bug tracker, or patches sent to the mailing list13:10
wolfspra1lbut I regularly hear and see them being ignored...13:10
kyakmirko: yea, i got you. I hope 3.2.1 version is sufficient not be get dropped? :)13:10
mirkoyou can still try to get them upstream via me - will try to give feedback asap then13:10
wolfspra1lmirko: do patches to the openwrt mailing list work?13:10
mirkowolfspra1l: should13:11
wolfspra1l;-)13:11
mirkowolfspra1l: you might also ping me additionally in irc/jabber13:12
kyaki agree with wolfgang - it is really hard to get response in openwrt ticket systems even with patches, unless i contact mirko or jow directly13:12
wolfspra1lkyak: I think if you have a high quality piece that you are reasonably sure will not break other targets, email mirko directly13:12
mirkoi agree as well, that's why i tried to get most OpenWrt devs together in athens13:12
mirkoto talk about that13:12
mirkothe meeting went quite productive and we're kina restructering and realizing agreed solutions13:13
kyakwolfspra1l: yep, i usually ping or pm in IRC :)13:13
mirkowolfspra1l: kyak: ack - if you think review overhead might be small send it to openwrt-devel / attach the patch to a ticket and ping me13:14
kyakmirko: thanks!13:15
mirkowelcome, we know about the openwrt patch situation and its perceived image, however there's no simple, immediat and satisfying solution 13:17
mirkothat's why we met in greece 2 weeks ago :)13:17
kyakhow many people were there? and how many openwrt devs are there overall?13:19
mirkowill definitely spend more time reviewing the mailing list and tickets from now on13:19
mirkokyak: there were 7 (and therewith most of the core team) present in greece13:20
mirkokyak: about the people having commit access take a look here: https://dev.openwrt.org/wiki/people13:21
kyaki see, so probably not so many developers visited13:22
mirkoas said, most of the core-team did13:22
mirkolemme re-phrase: most of the currently active devs participated13:23
mirkopeople get added to the wiki-page, however not removed :)13:24
kyakyou should call it "hall of fame" then ;)13:26
jow_laptopkyak: your gettext patches look fine, did you compile test them?15:44
jow_laptopI have to hunt down another regresion atm so I don't want to recompile gettext just now because it takes ages15:45
kyakjow_laptop: sure, recompiled and tested16:01
kyakjow_laptop: however, note the comment about DISABLE_NLS - you shouldn't apply the rules.mk patch16:04
jow_laptopyes, seen it16:05
kyakdid you set the nonexistant variable name CONFIG_ENABLE_LOCALE for the same reason, i.e. explicit --enable-nls brakes some packages?16:07
jow_laptopI don't know the background16:08
jow_laptopI inherited lots of it and cleaned it up step by step16:08
jow_laptopI believe --disable-nls is one of the first optimization attempts, before we started punching autofail into obedience16:08
kyakleaving 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 NLS16:10
jow_laptopyes, bringing solid nls support is an equally big task as introducing libtool 2.x into the tree16:11
jow_laptopso we cannot do it globablly for now16:11
kyakand there is actually just one package so far where i really wanted NLS.. probably there are more to come16:12
jow_laptopyeah. Point is it should work equally well with both nls on and off16:12
jow_laptopso there needs to be an automagic way to package up *.mo files16:12
kyakhm right.. 16:12
kyakprobable a job for nls.mk16:13
jow_laptopyeah, we could add another hook which does  find $(PKG_INSTALL_DIR) -name '*.mo' | xargs cp  somewhere16:13
kyakthis reminds me our discussion about automagical creation of *-dev packages :)16:19
jow_laptopright, me too16:20
kyakjow_laptop: do you know why the toolchain in staging_dir/toolchain-* requires STAGING_DIR env variable to be set?16:35
kyakit wasn't like that some time ago16:35
jow_laptopyes, I changed gcc to require it16:36
jow_laptopI got tired of the -I and -L crap16:36
jow_laptopand the brainfuck -sysroot is16:37
jow_laptopso its now all inferred from the STAGING_DIR env var16:37
jow_laptopand not even libtool and autofail are able to break it16:37
jow_laptopor other retarded build systems unable to deal with cross compilation16:38
kyakhm ok! i only used the toolchain to build external kernel, so i luckily never hit these problems16:38
jow_laptopthe theory is that you define STAGING_DIR to the dir where your target-libraries and includes are16:39
jow_laptopthen you stick gcc in PATH and maybe set CROSS_COMPILE and it all works16:40
jow_laptopopenwrt's versions of automake, autoconf, cmake, flex, bison, libtool etc. are respecting STAGING_DIR as well16:40
jow_laptopso the SDK becomes fully relocatable16:40
jow_laptopnot tied to specific absolute pathes anymore16:41
jow_laptophowever I have some patches in the queue to make a missing STAGING_DIR env var nonfatal in gcc16:41
jow_laptopjust haven't had the the time to test it16:42
kyakif there was a way to figure out the STAGING_DIR path from the compiler path16:43
jow_laptophttp://pastebin.com/V2NTWzqK16:44
jow_laptopkyak: no there is no way, we had a somewhat related discussion about that here a while ago16:44
jow_laptopthe problem is that on openwrt one toolchain may serve multiple targets16:44
jow_laptopso you cannot infer the target path from the toolchain16:45
jow_laptopthe toolchain may be even externally provided, in this case there'd be no connection to the target at all16:45
kyakyeah.. 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 directory16:46
kyakexternal toolchain - yeah, that's the problem..16:46
jow_laptopthen 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 ;)16:46
kyakyou are right :) btw, is the STAGING_DIR set automatically when using prebuilt Toolchain?16:48
jow_laptopits set whenever you compile using openwrt makefiles and -targets16:49
jow_laptopthe prebuilt one is bare, no setup or wrapper scripts16:49
jow_laptopso the answer is no, not set automatically16:49
jow_laptopbut I was thinking about shipping a setup.sh16:49
jow_laptopwhich exports some needed env vars to the current shell16:49
jow_laptopso the workflow would be like  ./setup.sh; make whatever16:50
jow_laptopor  ./setup.sh; mips-openwrt-linux-gcc -o test test.c16:50
kyakok, 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 adapt16:51
whitequarkkyak: better add autocrap17:03
whitequarkow17:26
whitequarkjust imagine17:26
whitequarkflash has OPCODES for dealing with XML.17:26
whitequarkwpwrak: consider adding xml opcodes to M1 SoC!17:26
whitequarkjust for lulz17:26
DocScrutinizeryeah, and a java p-code core17:36
DocScrutinizerwait, ARM already got that?17:37
DocScrutinizerjazelle17:37
whitequarkdamn17:40
whitequarkI found _another_ flash compiler bug17:40
kyakjow_laptop: just to confirm - are you waiting for gettext rebuild after the changes before you can accept it?17:43
jow_laptopkyak: no, I have to review some gsoc stuff currently17:48
kyakjow_laptop: ok, sorry for bothering and thanks!17:49
whitequarkI never laughed so hard like at the "RATIONALE" section in Flash compiler sources19:01
whitequarkthey should have called it "IRRATIONALE"19:02
rjeffriesEven though I'm aware that there's apparently little interest here in tablet form factor devices. ...20:22
rjeffriesand stipulating that indeed, this is not an OpenHardware device, even so it is interesting (to me) what $100usd buys today.20:23
rjeffrieshttp://www.the-digital-reader.com/2012/04/08/review-polaroid-pmid701-android-tablet/20:23
rjeffriesA 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)20:24
rjeffriesI 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. ;)20:26
rjeffriesNote 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 1024x60020:38
Aylaxzear, ghex21:02
Aylax(Sorry, wrong chan)21:02
DocScrutinizerwrong planet? sounds like klingon21:49
--- Mon Apr 9 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!