<kristianpaul>
wolfspraul: I'm back to debian, FEL is not usefull when most milkymist related sofware is upstream or need some patching from time to time :-)
<kristianpaul>
is good go back to home :-)
<kristianpaul>
phew i was close to confuse posix with ansi c, afortunally i still following the last one :-)
<wolfspraul>
kristianpaul: Debian has more Milkymist related things upstream than FEL?
<kristianpaul>
no
<kristianpaul>
but i feel better here to recompile stuff from time to time :-)
<xiangfu>
kyak: I make 'plplot' and 'gnuplot' compile fine.
<kyak>
xiangfu: however, only NanoMap and gmenu2x were updated. nanonote-files were not noticed by opkg, because PKG_RELEASE wasn't incremented
<xiangfu>
the release image is building...
<xiangfu>
kyak: ok. will add PKG_RELEASE to next release. ;-)
<kyak>
xiangfu: i have to run opkg update every time after reboot, guess it's because "lists_dir ext /var/opkg-lists" in /etc/opkg.conf. Should we change it to /etc/opkg-lists maybe? (/var points to /tmp and get swapped after every reboot)
<kyak>
xiangfu: btw, are we switching to weekly releases? ;)
<xiangfu>
/etc/opkg-lists sound good.
<xiangfu>
;-)
<xiangfu>
by the way I create a branch in openwrt-package. create a release tag in openwrt-xburst
<kyak>
sounds good :)
<xiangfu>
kyak: I found update form testing to release no needs to reflash. only need update and install some packages.
<xiangfu>
:)
<kyak>
yeah, that's what i thought, too
<kyak>
people would need just to opkg update && opkg upgrade
<xiangfu>
kyak: there is a bug in gcc-mips. (but I don't remember if it exit still)
<kyak>
should be no bugs
<xiangfu>
remove gcc-mips will remove a libc.*.so or libc++...so ( cann't remember exactly).
<xiangfu>
kyak: do you still have gcc-mips in your nanonote. Please test remove gcc-mips. and reboot.
<kyak>
ok, i got it
<kyak>
it overwrites some basic files
<kyak>
i'll check it
<kyak>
root@ben:~# opkg files gcc-mips | wc -l
<kyak>
1718
<kyak>
--)
<xiangfu>
maybe this line: " cp -r $(PKG_INSTALL_DIR)/usr/{bin,include,lib,libexec} $(1)/usr"
<kyak>
yeah, sure. We just need to copy more precisely
<kyak>
seems that installing and then removing gcc-mips would render Ben useless :)
<xiangfu>
I will NOTICE people once you install gcc-mips never remove it in this release. :)
<xiangfu>
the plplot compile error only happen in buildhost.
<xiangfu>
seems there is something wrong with buildhost perl.
<kyak>
well, pango compile errors happens only at my host :)
<kyak>
(and David's)
<xiangfu>
I have to export  PERL5LIB="/etc/perl:/usr/local/lib/perl/5.10.1:/usr/local/sha
<kyak>
xiangfu: another thing. When trying to install gcc-mips, opkg downloads it to /tmp. But /tmp is 15Mb only, so opkg fails. Should we increase /tmp size?
<kyak>
or maybe make opkg download to /root?
<xiangfu>
kyak: yes. how about name it "/root/.cache/opkg"
<xiangfu>
dest root /
<xiangfu>
dest ram /root/.opkg/archives
<xiangfu>
lists_dir ext /root/.opkg/opkg-lists
<xiangfu>
option overlay_root /overlay
<xiangfu>
kyak: how about change opkg.conf to this ^^
<kyak>
xiangfu: i think it's good
<xiangfu>
hmm... need talk info the detail of "dest ram"
<xiangfu>
after package installed. the folder will became empty only have some folders.
<kyak>
is it a problem?
<xiangfu>
kyak: not a problem. but I want understand. is that opkg extract package to this "dest ram" ?
<xiangfu>
then mv all file from "dest ram" to "dest root" ?
<kyak>
i think it would download to dest ram and then unpack (i.e. install) to dest root
<kyak>
xiangfu: ok, seems i got rid of all conflicting files in gcc-mips
<kyak>
i removed the --force-overwrite in include/package-ipkg.mk and went through a series of make package/gcc-mips/{clean,install} V=99 to find the conflicting files :)
<kyak>
it should not overwrite any system files now
<kyak>
there were less of them than i was expecting
<xiangfu>
kyak: the release image include more package. zgv ... and update gmenu2x and nanonote-files
<kyak>
yeah, gmenu2x and nanonote-files got updated
<kyak>
i don't have zgv installed yet
<xiangfu>
zgv, w3m plplot gnuplot included in release.
<kyak>
that's cool. so we have it all
<xiangfu>
yes.
<xiangfu>
only "/libstdc++.so*"
<tuxbrain_away>
are jlime - openwrt binary compatible? so I'm compiling the avr stuff on jlime, but I can then tar the binaries and place it on a openwrt and they should work? It we can have some fun with ploting programs and arduino then :)
<kyak>
tuxbrain_away: i could tell you for sure if you gave me those binaries
<kyak>
xiangfu: zgv is awesome. much better then imgv and fbi together :)
<xiangfu>
kyak: yes. I like it too. thanks to dvdk.
<tuxbrain_away>
kyak: once it finish I'm compiling in NN so it will take some time :P
<kyak>
the svgalib port opened so many opportunities
<tuxbrain_away>
love see devices compile their own stuff even if it take ages... I suppose is my gentoo inheritance
<kyak>
btw, mplayer can play in svgalib, but it's not working for some reason
<kyak>
basically only sdl output of mplayer is usable
<kyak>
all others are not working/crippled
<xiangfu>
kyak: still have some problem in mplayer. there are some libs not include in release. need opkg install
<xiangfu>
:(
<kyak>
xiangfu: hm, which ones?
<kyak>
mplayer is being the smartass all the time.. auto detecting everything :)
<tuxbrain_away>
damn error, what is the --disable to not build documentation on configure on binutils?
<xiangfu>
dvdk: the full build log of " make package/plplot/{clean,compile} "
<xiangfu>
dvdk: by the way the plplot-python have problem when install. some thing like can not find ....ipkg-install/usr/lib/..python....
<xiangfu>
cp: cannot stat `/home/xiangfu/openwrt-xburst.full_system/build_dir/target-mipsel_uClibc-0.9.30.1/plplot-5.9.7/ipkg-install/usr/lib/python/*/plplot/*.so*': No such file or directory
<xiangfu>
dvdk ^
<kyak>
dvdk: btw. i tried to set reasonable sound/music level in supertux be default. No problem to set it for sounds - but the music is a little bit problematic
<kyak>
the music volume can be set to somewhat quieter level, but since the music is looped, at the beginning of each loop there is a noticable raise of volume
<kyak>
as i was explained at #sdl, it might happen due to buffering
<kyak>
Ben is too slow
<zrafa>
or the buffer is too big ;)
<kyak>
so the music turns into quiet-load-quiet-etc
<kyak>
yes, decreasing the buffer could help. But this could lead to performance problems
<kyak>
anyway, i found it playing without sounds/music more comfortable. And the gameplay is faster
<kyak>
maybe i'll commit the sound patch, at least it's the half of the issue
<dvdk>
kyak: but  sound is really a very distinguishing feature, comparing it with the other NN games. very cool.
<dvdk>
kyak: is there an easy and obvious way to toggle sound on/off?
<kyak>
from settings
<kyak>
you can enable/disable sound/music separately
<dvdk>
xiangfu: plplot-python is known to NOT work (how do I mark such a packge @broken or something?)
<dvdk>
xiangfu: you should not enable it.
<dvdk>
xiangfu: maybe I should uncomment the plplot-python stuff in the Makefile?
<rjeffries>
tuxbrain_away how much have you used Spectec wifi on ben
<SeriousSam>
I just saw word "hardware" in a channel name. Sorry for disturbing.
<tuxbrain_away>
rjeffries: not much
<rjeffries>
thx
<tuxbrain_away>
SeriousSam: don't worry you are welcome :), but don't expect this question to be replied here :)
<SeriousSam>
Ok ;)
<Fusin>
erm, are there plans for an Ben v2.0?
<wpwrak>
tuxbrain_away: btw, how are the preorders coming along ?
<tuxbrain_away>
he, just view my last entusiatic report on this channel.... they have not increased since then ...
<wpwrak>
tuxbrain_away: so this means that people read their mail and act on it quickly :)
<rjeffries>
Fusin nothin firm in terms of new model of Ben
<zrafa>
tuxbrain_away: I worked for a company doing an embedded solution with linux/DOS plus extras periphericals which were plugged to linux/DOS embedded decive via zigbee and serial. I think that nn with UBB and atben would do the same :)
<zrafa>
tuxbrain_away: the shit that company used as embedded device was an ancient x86 product, discontinued, and 3x times expensier than nn
<tuxbrain_away>
:)
<rjeffries>
tuxbrain_away I agree that Werners 802.15.4 radio addon for Ben is imoortant
<zrafa>
tuxbrain_away: I guess that nn should be a nice product for companies doing solutions and need a central embedded linux computer controling the rest of stuff
<rjeffries>
zafra I have been preaching that gospel for a few months now
<tuxbrain_away>
I agree, I'm not demoralized on low preorders, I will be demoralized in those UBB doen't produce some more visibility on NN, and it's posibilities... is a way to have an wider audience once atben is released :)
<tuxbrain_away>
rjeffries: and we have listent to you , but time to time dude :)
<zrafa>
tuxbrain_away: I am not a business man, but I think that companies use this kind of embedded solution for many things (embedded solution=some central brain controling periphericals via serial or wireless). Dont know how to bring nn to those companies so they can know it exists.
<zrafa>
rjeffries: what is gospel?
<zrafa>
rjeffries: ah.. you mean the solution
<zrafa>
:)
<tuxbrain_away>
zrafa, facts are powerfull reclaim, so a good demos on that direction must be done before try to reach them.
<rjeffries>
zafra yes  after seeing JeeLabs stuff and reading about 802.15.4 my gut says NN could have a future as a small portable cheap controller
<zrafa>
tuxbrain_away: control a gps board via atben, and plug via ubb another thing :P
<rjeffries>
however I also now better understand why wolfspraul constantly talks about need to make Ben NN software work better and have smoother operation
<zrafa>
tuxbrain_away: we could offer that idea to any company doing that. The problem is that we can not offer all the periphericals as open hardware, which would do us no part of qi completely
<zrafa>
tuxbrain_away: I mean.. we can offer the idea and implement it
<zrafa>
tuxbrain_away: companies need to pay of course.
<zrafa>
:)
<wpwrak>
zrafa: doing paid-for design of open hardware peripherals should be a rather attractive market
<tuxbrain_away>
I'm not a copyleft taliban :) if something is a posible source of income and is not a crime I'm open to talk about it
<wpwrak>
zrafa: not only because it would put money into the pockets of the designers and maybe also sharism for production, but it may also attract more people with hardware skills
<rjeffries>
I know a creative engineer, I think he wrks in Arginnina, nost sure
<zrafa>
wpwrak: that is why I said to offer the idea (just nn with atben and ubb).. The rest of the periphericals should be provided by companies. We could integrate them with nn and do the software part.
<rjeffries>
like tuxbrain_away said !!!
<tuxbrain_away>
zrafa: in fact we have some of this works goind with rafael campos
<zrafa>
wpwrak: I did not meant to desing open hardware and companies paying for it. That would be nice but I know that companies will not like to do that of course
<tuxbrain_away>
not with nn , but the idea is similar
<wpwrak>
zrafa: (integrate) for proper integration, we need to "own" more of the ben core design. that would a strategic goal for the ya. once we truly have all the design files, adaptations would be relatively easy to produce.
<tuxbrain_away>
costumization to fit a solution the costumer is searching for.
<zrafa>
wpwrak: :( I think that we are talking about two or more different things
<rjeffries>
wpwrak what of ben core design do you mean? the palstic case?
<tuxbrain_away>
at the end mostly can be solve at software lever (zrafa I thing is taking that approach)
<tuxbrain_away>
lever-> level
<zrafa>
tuxbrain_away: yes
<zrafa>
tuxbrain_away: software level.. controling via ubb some other periphericals. bytes arrive you control them in nn
<zrafa>
wpwrak: I am not talking about modify nn or doing next open hardware things
<wpwrak>
rjeffries: schematics (these are almost there, except that the ones we have are not the "real" schematics"), layout, and case design.
<zrafa>
wpwrak: I am talking about your nice work with ubb and atben. Which I feel would be great for companies who need that.
<zrafa>
wpwrak: like the company where I worked.
<wpwrak>
zrafa: hmm, i think you need a more advanced device even for that. the ben is good for prototyping, though.
<zrafa>
wpwrak: and still if companies can do good desitions and cheaper solutions with closed hardware and not using nn at all, the company where I was working was using an embedded device 3x times expensier than nn.
<wpwrak>
zrafa: e.g., a ya with built-in ieee 802.15.4 and two 8:10 card slots would be considerably more attractive as an embedded controller.
<zrafa>
wpwrak: mm? why advanced?. If the device needs to control a keyboard, display, a gps, and something more.. I think nn is okey for that
<wpwrak>
zrafa: yes, if it's enough, it's enough :) but i'm afraid that, in many cases, you may need a bit more connectivity.
<zrafa>
wpwrak: yes sure. BUt nn exist now. Ya does not exist. And qi is going to live if qi, resellers sell 200 M1 and 1000 nn
<tuxbrain_away>
wpwrak: and with the power of netwalker on NN size and price will be even more atractive :P
<wpwrak>
tuxbrain_away: ;-) yeah, but the ya should be purely incremental ;-)
<wpwrak>
now the real question is where to find the money to do it :)
<tuxbrain_away>
he
<tuxbrain_away>
don't look at me
<rjeffries>
wpwrak please expand on "purely incrmental" I think that means for change to palastic case?
<rjeffries>
s/for/no
<tuxbrain_away>
rjeffries: easy changes, towards freedom, triying to no increase much the tech risk
<rjeffries>
inside the Ben case (assuming no change to plastic) a more recent Ingenic SOC + more RAM baklight for keybaord would significantly improve useability
<rjeffries>
doing a follow-on with same (exact) SOC makes no sense to me
<wpwrak>
rjeffries: the problem is that a more recent soc would need a lot of development effort. larsc said that the "next generation" chips is very different from the older series.
<wpwrak>
rjeffries: of course, if sufficient resources are available, ... :)
<tuxbrain_away>
wpwrak: again, don't look at me when talking about money and resources :P
<rjeffries>
okwell i guess that Ben NN is what it is. soon will have a few cool plug in accessories to8:10
<wpwrak>
tuxbrain_away: maybe you should do an IPO. advertize tuxbrain as something like the next facebook, a social network with a - as the novel idea - a physically tangible element. see how many greedy speculators read beyond this ;-)
<tuxbrain_away>
what IPO stands for?
<rjeffries>
wpwrak as to SOC I actually meant the slighly different model you like, not the fancy one that has a lot more changes
<tuxbrain_away>
but whatever... is not a bad message... mmmm not bad at all, inveeestooorss yuuuhuuuuu, I have something cloudy ,2.0, social new to show youuuuuu.
<tuxbrain_away>
c u guys later
<rjeffries>
wpwrak a curiosity question. ignoring the current Ben plastic case... (assume it would be replace dby something simpler and not as comsumer flashy..)
<rjeffries>
what wi=ould be involved wuth interfacing to a different display? Wolfspraul mentions oncce that the driver for current disolay is key technology
<wpwrak>
tuxbrain_away: (IPO) Initial Public Offer - when a company enters the stock market
<wpwrak>
rjeffries: (display) not sure. the display controllers are a somewhat murky territory
<wpwrak>
rjeffries: first of all, it's often hard to find documentation. so you have to include this in the sourcing decision.
<wpwrak>
rjeffries: second, those critters also need quite a bit of attention from the engineering side or you get flicker or suspend/resume problems
<rjeffries>
thanks
<rjeffries>
the latest OLPC is mildly interesting. good price, interesting display (and other things) control chip with open source drivers (as I understand things)
<kyak>
mirko: ping
<mirko>
kyak: pong
<kyak>
mirko: i was wondering. It seems that qt4 is not using fontconfig - why is it? /usr/lib/fonts just points to /usr/share/fonts/ttf-dejavu
<mirko>
kyak: fontconfig was afaik not available when using in qws mode
<kyak>
"Qt for Embedded Linux uses the FreeType 2 font engine to produce font output."
<kyak>
does it mean it uses fontconfig?
<mirko>
freetype != fontconfig
<mirko>
freetype is enabled by default
<kyak>
okay, got it
<kyak>
the problem is now that /usr/share/fonts/ttf-dejavu/* fonts don't have chinese symbols
<kyak>
i solved it by installing unifont-ttf into /usr/share/fonts/ttf-dejavu/
<mirko>
kyak: hmm - send me a set of ttf's, i'll commit it as a font package
<kyak>
then an application (kinyin) can use it
<mirko>
dejavue was the best "general purpose" set i found yet
<kyak>
mirko: not a problem, i can do it myself. We already have the "unifont" package, so far it only installs the pcf font. I can make it install ttf version, too. THe thing is, i'll have to install unifont to ttf-dejavu directory :)
<mirko>
kyak: it was just quick&dirrty that way - feel free to change the structure
<kyak>
well, i don't have a lot of ideas how make it nice and clean.. Maybe install fonts that come with qt in /usr/lib/fonts? this could be done in qt4-gui package
<kyak>
since qt doesn't care about fontconfig, this would make sense. Then additional fonts could be made avaialble to qt by symlinking from /usr/share/fonts/* to /usr/lib/fonts
<kyak>
we have this wqy-micrhei font. that has chinese
<kyak>
i do ln -s /usr/share/fonts/wqy-microhei/wqy-microhei.ttc /usr/share/font
<kyak>
s/ttf-dejavu/wqy-microhei.ttc
<kyak>
and chinese symbols are displayed
<kyak>
i think we need to install this symlink during installation of wqy. That would do it
<larsc>
just having /usr/lib/fonts pointed to /usr/share/fonts doesn't work?
<kyak>
it would not see inside the subdirs
<kyak>
it = qt
<kyak>
and there is nothing in /usr/share/fonts
<kyak>
(except for pcf unifont)
<larsc>
i guess a better solution then would be to let all fonts symlink their files to /usr/share/fonts
<kyak>
this could be good
<kyak>
i wonder if fontconfig will see these fonts twice?..
<larsc>
yea. that could be a problem
<larsc>
another solution might be to write a small script which symlinks all fonts from /usr/share/fonts/* to /usr/lib/fonts
<larsc>
for x in `find /usr/share/fonts/`; do ln -s $x /usr/lib`basename $x`; done
<kyak>
either as a script, or install these symlinks from fonts packages
<larsc>
/usr/lib/fonts/
<larsc>
/usr/lib/fonts/ seems to be qt specific?
<kyak>
seemsso
<larsc>
i guess it should be a script being part of the qt package then
<kyak>
what if some font gets installed after qt4 is installed?
<kyak>
maybe we could just leave it as it is and if some font wants to expose itself to qt, it would install symlink in /usr/share/fonts/ttf-dejavu?
<larsc>
/usr/lib/fonts would probably be better
<jow_laptop>
/usr/share/fonts/ sounds more logical :)
<kyak>
jow_laptop: not quite. This would confuse fontconfig
<jow_laptop>
ah ok
<jow_laptop>
well having fonts in /usr/lib sounds strange to me
<jow_laptop>
thats all
<larsc>
and qt is hardcoded to look in /usr/lib/fonts
<kyak>
that's qt! :)
<jow_laptop>
I thought /usr/share is for additional resources which are not binaries
<jow_laptop>
yeah, nothing said
<larsc>
best would probably to patch qt to do a recursive search in /usr/lib/fonts
<jow_laptop>
I have no insight in this matter anyway
<mth>
jow_laptop: "share" is for architecture independent data, regardless of whether that is binary or text
<kyak>
how do you guys think: 1) package contents of qt-everywhere-opensource-src-4.7.0/ipkg-install/usr/lib/fonts/ (that has some default fonts coming with qt) in qt4-gui and install it in /usr/lib/fonts. qt4 will be quite equipped with default fonts in this case. Then, 2) each font package willing to show its fonts to qt will install symlinks in /usr/lib/fonts?
<mth>
jow_laptop: then we agree :)
<kyak>
fontconfig and fonts will be leaving more or less separately in /usr/share/fonts, since qt is not aware of fontconfig
<mth>
Qt under X11 does use fontconfig, the framebuffer version does not?
<larsc>
nope
<mth>
would it be an option to configure/patch Qt to look in /usr/share/fonts then? since that is the proper location
<larsc>
yes. but you'd have to also patch it to look into  subfolders
<mth>
does it support more than one format?
<mth>
otherwise you could hardcode for example /usr/share/fonts/truetype
<kyak>
it supports many formats
<kyak>
including some of its own
<kyak>
i found QT_QWS_FONTDIR
<kyak>
env variable
<kyak>
seems that it will respect it (src/gui/text/qfontdatabase_qws.cpp, line 243)
<kyak>
still it won't recurse into subdirs
<kyak>
need to check
<kyak>
yes, it respects the varaible, but won't go into subdirs
<kyak>
ok, there can be a "fontdir" file in QT_QWS_FONTDIR
<rjeffries>
does the new release being tested now for BEN include an easy way to change font (font size) in a terminal for example
<kyak>
there is the setfont utility for that
<kyak>
and setfont2, too
<kyak>
likes the terminus-12 font. It is not as nice as setfont2's 6x10 font, but has colors and more glyphs, which is useful sometimes
<rjeffries>
my eyes are not great I need a bit larger font
<rjeffries>
when the image being tested goes gold I will reflash and see waht I can do
<rjeffries>
this Ben has an October build on it that is  semi-fubar
<kyak>
try using setfont with any font from /usr/share/kbd/consolefonts/ and see which is good for you
<rjeffries>
in the image I have it is not clear how I get into a shell or a terminal app
<rjeffries>
it may be best to just wait for the new image xiangful & co are polishing now
<kyak>
well, could be the best to go and read a little something about linux.. no offense, but it's like teaching you to click the "Start" button in Windows
<rjeffries>
I have used linux for years on desktops never had to set a font;)
<rjeffries>
and besides the fitsy screen on my Ben does not have a terminal option. like I said it is a bit screwed up
<rjeffries>
kyak I appreciate your comment, but it makes me smile. I can issue a setfont command, but need to get into a shellk forst and it is not clear
<rjeffries>
that is a usability issue, now a low IQ or linux knowledge issue. <g>
<zrafa>
no offense for both.. but you should use jlime ;)
<rjeffries>
point me to a URL and I can reflash with Jlime I am not an OpenWrt Taliban
<rjeffries>
if that is noy OK in this irc email me rjegffries@gmail.com
<rjeffries>
rjeffries rather
<zrafa>
you can find jlime at qi.. just write jlime at qi-hardware.com
<rjeffries>
I thought the qi-hardware versionb had stuff ripped out
<rjeffries>
if i replash I may as well get teh other stuff I want also to play certain types of music files
<rjeffries>
I will Google see ya
<zrafa>
rjeffries: you can install jlime on a sd as well. and you can have both openwrt on nand and jlime on sd
<kyak>
rjeffries: i'm not talking about setfont. I'm talking about getting to shell/terminal.
<rjeffries>
ok thx
<rjeffries>
on openwrt that is on my Ben        the graphical launcher does NOTR show a way to get into a terminal, period
<rjeffries>
I can shoot a photo of screen.'_
<kyak>
i don't require you to know the ctrl-alt-F* sequence. But not being able to find the relevant icon in gmenu2x? i doubt jlime would help you
<rjeffries>
I acknowledge this is an older (Oct 2010) release so it may be brojken
<rjeffries>
god damnb ity there IS NO ICOBN ok
<rjeffries>
it is not on my damn screen
<kyak>
so please, show your screen
<rjeffries>
i'll get my camera nd apolgies for the un needed profanity
<zrafa>
I would guess that both of you are talking about different distros
<kyak>
i have a feeling you haven't mastered the tab key yet to switch to other gmenu2x's tabs
<rjeffries>
how wouldI know to "master" the tab key?
<zrafa>
rjeffries: that is intuitive .. you need to press all the keys for all the functions every time you need to do something :)
<rjeffries>
by the way tab switchyes between applications and settings that is iy
<rjeffries>
the only other icons are fordgclock gmu nanomap srardict explorer
<rjeffries>
e
<rjeffries>
no icon for e.g. terminal ot shell
<zrafa>
rjeffries: you are luck you do not have the first version with that menu.. there were cripted keys to do things. So you should say thanks nowadays.. ANd it would be a good idea if you install latest qi-openwrt as well. You would find more support.