| 00:01.19 | wpwrak | btw, 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:03.24 | wolfspraul | do they plan to also change the schematics file format? |
| 00:05.15 | wpwrak | i think so, yes. it would make sense anyway |
| 00:09.55 | wpwrak | as long as it supports both the old and new format, we have a nice and unrushed migration path |
| 00:27.21 | emeb | running MACHINE=beaglebone bitbake console-image. Why on earth is it building xorg & gtk? |
| 00:32.09 | emeb | whoops - wrong chl. srry... |
| 00:32.20 | GNUtoo-desktop | emeb, because some console software are built with Xorg use flags |
| 00:33.01 | emeb | yep - figured it was some sort of silly dependency thing. |
| 01:12.04 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 02:29.03 | *** join/#qi-hardware antgreen (~user@CPE0021910f07ac-CM0019477f82fc.cpe.net.cable.rogers.com) |
| 02:54.02 | *** part/#qi-hardware pabs3 (~pabs@d175-38-167-124.per801.wa.optusnet.com.au) |
| 02:54.59 | *** join/#qi-hardware pabs3 (~pabs@d175-38-167-124.per801.wa.optusnet.com.au) |
| 02:58.49 | *** join/#qi-hardware pabs3 (~pabs@d175-38-167-124.per801.wa.optusnet.com.au) |
| 04:11.29 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host149-73-dynamic.56-82-r.retail.telecomitalia.it) |
| 04:26.11 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 06:19.19 | *** join/#qi-hardware wolfspra1l (~wolfsprau@221.220.179.252) |
| 06:38.25 | qi-bot | [commit] Wolfgang Spraul: upleveled cmdline patches to kicad bzr 3493 (master) http://qi-hw.com/p/eda-tools/49d4ae6 |
| 07:26.36 | *** join/#qi-hardware jekhor__ (~jek@leased-line-46-53-195-5.telecom.by) |
| 08:11.55 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 09:33.12 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-79-226.w90-5.abo.wanadoo.fr) |
| 09:51.57 | *** join/#qi-hardware kristoffer (~kristoffe@host-95-206-8-221.mobileonline.telia.com) |
| 10:13.47 | *** join/#qi-hardware Martix (~martix@4.177.broadband3.iol.cz) |
| 10:50.50 | kyak | HTTP 500 on http://projects.qi-hardware.com/index.php/p/qi-kernel/source/tree/master/ -\ |
| 10:53.36 | wolfspra1l | yes, I know |
| 10:53.47 | wolfspra1l | but thanks for reporting! |
| 10:57.00 | kyak | no problem :) |
| 11:10.35 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host149-73-dynamic.56-82-r.retail.telecomitalia.it) |
| 11:18.01 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 11:39.45 | mirko | wolfspra1l: got the patches from xiangfu - however i'm a bit confused about them |
| 11:40.19 | mirko | 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? |
| 11:55.54 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 12:07.06 | wolfspra1l | 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 |
| 12:07.13 | qi-bot | The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120407-0750 |
| 12:13.38 | mirko | wolfspra1l: ah, ok - got it |
| 12:18.08 | mirko | 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 :) |
| 12:18.27 | wolfspra1l | speed & quality |
| 12:18.33 | wolfspra1l | thanks for your time to review! |
| 12:19.54 | wolfspra1l | there's only a small number of Ben users now, so if that breaks use cases of far more widely available devices: bad |
| 12:23.02 | qi-bot | [commit] kyak: gcc-mips: correct md5sum (master) http://qi-hw.com/p/openwrt-packages/0bd9efe |
| 12:41.42 | mirko | wolfspra1l: commited (https://dev.openwrt.org/changeset/31218) |
| 12:41.59 | mirko | i'd really love to get the wpan stuff upstream |
| 12:42.23 | mirko | so don't hesitate to send me related patches for review |
| 12:42.58 | wolfspra1l | oh sure, definitely. but there was some movement in kernel.org too I think, related to wpan |
| 12:43.08 | wolfspra1l | let me dig a little - plus some testing on non-xburst targets... |
| 12:43.37 | wolfspra1l | it's easy to plug an atusb into a router with usb support, so that should definitely work first - then patch |
| 13:03.13 | kyak | mirko: why did you decide not to commit some patches (like for modifier keys or for fbcon color fonts)? |
| 13:05.00 | mirko | kyak: most likely because they didn't go into my inbox? :) |
| 13:05.51 | kyak | ah! :) i thought you based your work on what's in openwrt-xburst repo |
| 13:06.24 | kyak | so maybe xiangfu knows why |
| 13:06.42 | mirko | kyak: probably - at least he's the person i got the patches from |
| 13:06.56 | wolfspra1l | kyak: what is ready for upstream? |
| 13:07.50 | kyak | 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 |
| 13:08.05 | wolfspra1l | 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 |
| 13:08.51 | mirko | 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 |
| 13:09.00 | kyak | 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) |
| 13:09.04 | mirko | all targets not levelled up to a current version will get dropped therefore |
| 13:09.25 | wolfspra1l | I would love to upstream more, but there seems a bottleneck in the review process |
| 13:10.01 | wolfspra1l | I would think a good way are attachments in the bug tracker, or patches sent to the mailing list |
| 13:10.08 | wolfspra1l | but I regularly hear and see them being ignored... |
| 13:10.23 | kyak | mirko: yea, i got you. I hope 3.2.1 version is sufficient not be get dropped? :) |
| 13:10.30 | mirko | you can still try to get them upstream via me - will try to give feedback asap then |
| 13:10.48 | wolfspra1l | mirko: do patches to the openwrt mailing list work? |
| 13:11.44 | mirko | wolfspra1l: should |
| 13:11.49 | wolfspra1l | ;-) |
| 13:12.01 | mirko | wolfspra1l: you might also ping me additionally in irc/jabber |
| 13:12.15 | kyak | 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 |
| 13:12.42 | wolfspra1l | kyak: I think if you have a high quality piece that you are reasonably sure will not break other targets, email mirko directly |
| 13:12.49 | mirko | i agree as well, that's why i tried to get most OpenWrt devs together in athens |
| 13:12.54 | mirko | to talk about that |
| 13:13.19 | mirko | the meeting went quite productive and we're kina restructering and realizing agreed solutions |
| 13:13.34 | kyak | wolfspra1l: yep, i usually ping or pm in IRC :) |
| 13:14.05 | mirko | 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 |
| 13:15.25 | kyak | mirko: thanks! |
| 13:17.12 | mirko | welcome, we know about the openwrt patch situation and its perceived image, however there's no simple, immediat and satisfying solution |
| 13:17.28 | mirko | that's why we met in greece 2 weeks ago :) |
| 13:19.52 | kyak | how many people were there? and how many openwrt devs are there overall? |
| 13:19.58 | mirko | will definitely spend more time reviewing the mailing list and tickets from now on |
| 13:20.43 | mirko | kyak: there were 7 (and therewith most of the core team) present in greece |
| 13:21.18 | mirko | kyak: about the people having commit access take a look here: https://dev.openwrt.org/wiki/people |
| 13:22.12 | kyak | i see, so probably not so many developers visited |
| 13:22.25 | mirko | as said, most of the core-team did |
| 13:23.38 | mirko | lemme re-phrase: most of the currently active devs participated |
| 13:24.46 | mirko | people get added to the wiki-page, however not removed :) |
| 13:26.12 | kyak | you should call it "hall of fame" then ;) |
| 15:20.37 | *** join/#qi-hardware B_Lizzard (~havoc@athedsl-432645.home.otenet.gr) |
| 15:20.41 | *** join/#qi-hardware B_Lizzard_ (~havoc@athedsl-432645.home.otenet.gr) |
| 15:44.42 | *** join/#qi-hardware panda (~hzhang@221.219.115.236) |
| 15:44.49 | jow_laptop | kyak: your gettext patches look fine, did you compile test them? |
| 15:45.12 | jow_laptop | I have to hunt down another regresion atm so I don't want to recompile gettext just now because it takes ages |
| 16:01.05 | kyak | jow_laptop: sure, recompiled and tested |
| 16:04.09 | kyak | jow_laptop: however, note the comment about DISABLE_NLS - you shouldn't apply the rules.mk patch |
| 16:05.09 | jow_laptop | yes, seen it |
| 16:06.10 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 16:07.01 | kyak | did you set the nonexistant variable name CONFIG_ENABLE_LOCALE for the same reason, i.e. explicit --enable-nls brakes some packages? |
| 16:08.04 | jow_laptop | I don't know the background |
| 16:08.15 | jow_laptop | I inherited lots of it and cleaned it up step by step |
| 16:08.51 | jow_laptop | I believe --disable-nls is one of the first optimization attempts, before we started punching autofail into obedience |
| 16:10.53 | kyak | 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 |
| 16:11.37 | jow_laptop | yes, bringing solid nls support is an equally big task as introducing libtool 2.x into the tree |
| 16:11.53 | jow_laptop | so we cannot do it globablly for now |
| 16:12.04 | kyak | and there is actually just one package so far where i really wanted NLS.. probably there are more to come |
| 16:12.19 | jow_laptop | yeah. Point is it should work equally well with both nls on and off |
| 16:12.30 | jow_laptop | so there needs to be an automagic way to package up *.mo files |
| 16:12.45 | kyak | hm right.. |
| 16:13.00 | kyak | probable a job for nls.mk |
| 16:13.40 | jow_laptop | yeah, we could add another hook which does find $(PKG_INSTALL_DIR) -name '*.mo' | xargs cp somewhere |
| 16:19.56 | kyak | this reminds me our discussion about automagical creation of *-dev packages :) |
| 16:20.06 | jow_laptop | right, me too |
| 16:35.47 | kyak | jow_laptop: do you know why the toolchain in staging_dir/toolchain-* requires STAGING_DIR env variable to be set? |
| 16:35.56 | kyak | it wasn't like that some time ago |
| 16:36.43 | jow_laptop | yes, I changed gcc to require it |
| 16:36.52 | jow_laptop | I got tired of the -I and -L crap |
| 16:37.00 | jow_laptop | and the brainfuck -sysroot is |
| 16:37.12 | jow_laptop | so its now all inferred from the STAGING_DIR env var |
| 16:37.24 | jow_laptop | and not even libtool and autofail are able to break it |
| 16:38.01 | jow_laptop | or other retarded build systems unable to deal with cross compilation |
| 16:38.49 | kyak | hm ok! i only used the toolchain to build external kernel, so i luckily never hit these problems |
| 16:39.51 | jow_laptop | the theory is that you define STAGING_DIR to the dir where your target-libraries and includes are |
| 16:40.04 | jow_laptop | then you stick gcc in PATH and maybe set CROSS_COMPILE and it all works |
| 16:40.43 | jow_laptop | openwrt's versions of automake, autoconf, cmake, flex, bison, libtool etc. are respecting STAGING_DIR as well |
| 16:40.51 | jow_laptop | so the SDK becomes fully relocatable |
| 16:40.59 | jow_laptop | not tied to specific absolute pathes anymore |
| 16:41.58 | jow_laptop | however I have some patches in the queue to make a missing STAGING_DIR env var nonfatal in gcc |
| 16:42.10 | jow_laptop | just haven't had the the time to test it |
| 16:43.49 | kyak | if there was a way to figure out the STAGING_DIR path from the compiler path |
| 16:44.13 | jow_laptop | http://pastebin.com/V2NTWzqK |
| 16:44.32 | jow_laptop | kyak: no there is no way, we had a somewhat related discussion about that here a while ago |
| 16:44.44 | jow_laptop | the problem is that on openwrt one toolchain may serve multiple targets |
| 16:45.01 | jow_laptop | so you cannot infer the target path from the toolchain |
| 16:45.21 | jow_laptop | the toolchain may be even externally provided, in this case there'd be no connection to the target at all |
| 16:46.03 | kyak | 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 |
| 16:46.23 | kyak | external toolchain - yeah, that's the problem.. |
| 16:46.43 | jow_laptop | 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 ;) |
| 16:48.29 | kyak | you are right :) btw, is the STAGING_DIR set automatically when using prebuilt Toolchain? |
| 16:49.02 | jow_laptop | its set whenever you compile using openwrt makefiles and -targets |
| 16:49.29 | jow_laptop | the prebuilt one is bare, no setup or wrapper scripts |
| 16:49.36 | jow_laptop | so the answer is no, not set automatically |
| 16:49.47 | jow_laptop | but I was thinking about shipping a setup.sh |
| 16:49.57 | jow_laptop | which exports some needed env vars to the current shell |
| 16:50.11 | jow_laptop | so the workflow would be like ./setup.sh; make whatever |
| 16:50.48 | jow_laptop | or ./setup.sh; mips-openwrt-linux-gcc -o test test.c |
| 16:51.19 | kyak | 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 |
| 17:03.25 | whitequark | kyak: better add autocrap |
| 17:26.02 | whitequark | ow |
| 17:26.05 | whitequark | just imagine |
| 17:26.20 | whitequark | flash has OPCODES for dealing with XML. |
| 17:26.33 | whitequark | wpwrak: consider adding xml opcodes to M1 SoC! |
| 17:26.41 | whitequark | just for lulz |
| 17:36.19 | DocScrutinizer | yeah, and a java p-code core |
| 17:37.00 | DocScrutinizer | wait, ARM already got that? |
| 17:37.08 | DocScrutinizer | jazelle |
| 17:38.58 | *** join/#qi-hardware Jay7 (jay@128-73-113-42.broadband.corbina.ru) |
| 17:40.02 | whitequark | damn |
| 17:40.06 | whitequark | I found _another_ flash compiler bug |
| 17:43.45 | kyak | jow_laptop: just to confirm - are you waiting for gettext rebuild after the changes before you can accept it? |
| 17:48.31 | jow_laptop | kyak: no, I have to review some gsoc stuff currently |
| 17:49.35 | kyak | jow_laptop: ok, sorry for bothering and thanks! |
| 18:09.33 | *** join/#qi-hardware jekhor_ (~jek@leased-line-46-53-195-143.telecom.by) |
| 18:11.09 | *** join/#qi-hardware jekhor__ (~jek@leased-line-46-53-195-5.telecom.by) |
| 19:01.55 | whitequark | I never laughed so hard like at the "RATIONALE" section in Flash compiler sources |
| 19:02.05 | whitequark | they should have called it "IRRATIONALE" |
| 20:09.45 | *** join/#qi-hardware jekhor_ (~jek@leased-line-46-53-195-143.telecom.by) |
| 20:14.54 | *** join/#qi-hardware jekhor_ (~jek@leased-line-46-53-195-5.telecom.by) |
| 20:21.19 | *** join/#qi-hardware qwebirc84988 (4766dbad@gateway/web/freenode/ip.71.102.219.173) |
| 20:22.37 | rjeffries | Even though I'm aware that there's apparently little interest here in tablet form factor devices. ... |
| 20:23.25 | rjeffries | and stipulating that indeed, this is not an OpenHardware device, even so it is interesting (to me) what $100usd buys today. |
| 20:23.33 | rjeffries | http://www.the-digital-reader.com/2012/04/08/review-polaroid-pmid701-android-tablet/ |
| 20:24.29 | rjeffries | 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) |
| 20:26.20 | rjeffries | 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. ;) |
| 20:38.56 | rjeffries | 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 |
| 20:40.46 | *** join/#qi-hardware mth (hcppqdif@dhcp-089-098-069-120.chello.nl) |
| 20:54.34 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.140) |
| 21:02.17 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.140) |
| 21:02.28 | Aylax | zear, ghex |
| 21:02.55 | Aylax | (Sorry, wrong chan) |
| 21:34.01 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.140) |
| 21:40.23 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.140) |
| 21:46.17 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.140) |
| 21:49.47 | DocScrutinizer | wrong planet? sounds like klingon |
| 23:09.43 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.140) |