Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
<wolfspraul>
do they plan to also change the schematics file format?
<wpwrak>
i think so, yes. it would make sense anyway
<wpwrak>
as long as it supports both the old and new format, we have a nice and unrushed migration path
<emeb>
running MACHINE=beaglebone bitbake console-image. Why on earth is it building xorg & gtk?
<emeb>
whoops - wrong chl. srry...
<GNUtoo-desktop>
emeb, because some console software are built with Xorg use flags
<emeb>
yep - figured it was some sort of silly dependency thing.
xwalk has joined #qi-hardware
antgreen has joined #qi-hardware
pabs3 has quit ["Don't rest until the streets are paved in poems."]
<mirko>
i'd really love to get the wpan stuff upstream
<mirko>
so don't hesitate to send me related patches for review
<wolfspra1l>
oh sure, definitely. but there was some movement in kernel.org too I think, related to wpan
<wolfspra1l>
let me dig a little - plus some testing on non-xburst targets...
<wolfspra1l>
it's easy to plug an atusb into a router with usb support, so that should definitely work first - then patch
<kyak>
mirko: why did you decide not to commit some patches (like for modifier keys or for fbcon color fonts)?
<mirko>
kyak: most likely because they didn't go into my inbox? :)
<kyak>
ah! :) i thought you based your work on what's in openwrt-xburst repo
<kyak>
so maybe xiangfu knows why
<mirko>
kyak: probably - at least he's the person i got the patches from
<wolfspra1l>
kyak: what is ready for upstream?
<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
<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
<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
<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)
<mirko>
all targets not levelled up to a current version will get dropped therefore
<wolfspra1l>
I would love to upstream more, but there seems a bottleneck in the review process
<wolfspra1l>
I would think a good way are attachments in the bug tracker, or patches sent to the mailing list
<wolfspra1l>
but I regularly hear and see them being ignored...
<kyak>
mirko: yea, i got you. I hope 3.2.1 version is sufficient not be get dropped? :)
<mirko>
you can still try to get them upstream via me - will try to give feedback asap then
<wolfspra1l>
mirko: do patches to the openwrt mailing list work?
<mirko>
wolfspra1l: should
<wolfspra1l>
;-)
<mirko>
wolfspra1l: you might also ping me additionally in irc/jabber
<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
<wolfspra1l>
kyak: I think if you have a high quality piece that you are reasonably sure will not break other targets, email mirko directly
<mirko>
i agree as well, that's why i tried to get most OpenWrt devs together in athens
<mirko>
to talk about that
<mirko>
the meeting went quite productive and we're kina restructering and realizing agreed solutions
<kyak>
wolfspra1l: yep, i usually ping or pm in IRC :)
<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
<kyak>
mirko: thanks!
<mirko>
welcome, we know about the openwrt patch situation and its perceived image, however there's no simple, immediat and satisfying solution
<mirko>
that's why we met in greece 2 weeks ago :)
<kyak>
how many people were there? and how many openwrt devs are there overall?
<mirko>
will definitely spend more time reviewing the mailing list and tickets from now on
<mirko>
kyak: there were 7 (and therewith most of the core team) present in greece
<jow_laptop>
kyak: no there is no way, we had a somewhat related discussion about that here a while ago
<jow_laptop>
the problem is that on openwrt one toolchain may serve multiple targets
<jow_laptop>
so you cannot infer the target path from the toolchain
<jow_laptop>
the toolchain may be even externally provided, in this case there'd be no connection to the target at all
<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
<kyak>
external toolchain - yeah, that's the problem..
<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 ;)
<kyak>
you are right :) btw, is the STAGING_DIR set automatically when using prebuilt Toolchain?
<jow_laptop>
its set whenever you compile using openwrt makefiles and -targets
<jow_laptop>
the prebuilt one is bare, no setup or wrapper scripts
<jow_laptop>
so the answer is no, not set automatically
<jow_laptop>
but I was thinking about shipping a setup.sh
<jow_laptop>
which exports some needed env vars to the current shell
<jow_laptop>
so the workflow would be like ./setup.sh; make whatever
<jow_laptop>
or ./setup.sh; mips-openwrt-linux-gcc -o test test.c
<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
<whitequark>
kyak: better add autocrap
<whitequark>
ow
<whitequark>
just imagine
<whitequark>
flash has OPCODES for dealing with XML.
<whitequark>
wpwrak: consider adding xml opcodes to M1 SoC!
<whitequark>
just for lulz
<DocScrutinizer>
yeah, and a java p-code core
<DocScrutinizer>
wait, ARM already got that?
<DocScrutinizer>
jazelle
Jay7 has joined #qi-hardware
<whitequark>
damn
<whitequark>
I found _another_ flash compiler bug
<kyak>
jow_laptop: just to confirm - are you waiting for gettext rebuild after the changes before you can accept it?
<jow_laptop>
kyak: no, I have to review some gsoc stuff currently
<kyak>
jow_laptop: ok, sorry for bothering and thanks!
jekhor_ has joined #qi-hardware
jekhor__ has joined #qi-hardware
<whitequark>
I never laughed so hard like at the "RATIONALE" section in Flash compiler sources
<whitequark>
they should have called it "IRRATIONALE"
jekhor_ has joined #qi-hardware
jekhor_ has joined #qi-hardware
qwebirc84988 has joined #qi-hardware
<rjeffries>
Even though I'm aware that there's apparently little interest here in tablet form factor devices. ...
<rjeffries>
and stipulating that indeed, this is not an OpenHardware device, even so it is interesting (to me) what $100usd buys today.
<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)
<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. ;)
<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
mth has joined #qi-hardware
Aylax has joined #qi-hardware
Aylax has joined #qi-hardware
<Aylax>
zear, ghex
<Aylax>
(Sorry, wrong chan)
Aylax has joined #qi-hardware
Aylax has joined #qi-hardware
Aylax has joined #qi-hardware
<DocScrutinizer>
wrong planet? sounds like klingon