<rafa_> wpwrak_: bus driver game: yeah :D.. and buenos aires would be definitely more exiting than that tokio version
<rafa_> :)
<wpwrak_> rafa_: "combat driver" ;-)
<qi-bot> [commit] Xiangfu Liu: cleanup output message, output the flash process http://qi-hw.com/p/xburst-tools/4960824
<viric> xiangfu: I saw you packaged links for openwrt
<viric> I'm trying to cross-build links too (not in openwrt), and I need to patch it otherwise it checks for openssl using the native compiler, not the cross compiler. Did you try to add openssl support into it, maybe?
<viric> (I see openwrt does not build links with openssl support)
<xiangfu> viric: I just make it compile.  doesn't tried openssl.
<rafa_> wpwrak_: ;-))
<viric> xiangfu: ok
<kyak> viric: links's configure script detects openssl automatically in openwrt environment
<kyak> therefore, build fine and with openssl
<viric> hm
<viric> weird
<viric> I've read its 'configure', and it clearly says to use the native gcc
<viric> instead of the host gcc
<kyak> what' line?
<viric> 1min
<viric> it's my fault I think :)
<viric> it calls CC-cc
<viric> ${CC-cc}
<viric> hmm
<viric> that is 'gcc', isn't it?
<kyak> i'm not sure where you found that..
<viric> So...
<viric> I think that 'links' configure script checks if your build-system gcc links properly with the build-system openssl
<kyak> but you made a good point anywy, the openssl dependency should be added explicitely
<viric> instead of checking the cross-built
<kyak> just in case if links is built BEFORE openssl
<viric> kyak: can you try to rename temporarily your build-system "/usr/include/openssl" ?
<viric> and see if links builds with SSL?
<kyak> what do you mean?
<kyak> yes, you are right, it succeeds at line echo "configure:5183: checking for OpenSSL" >&5
<kyak> so it tries to link against openssl
<kyak> from build system
<viric> it's their bug, right?
<kyak> no, why?
<viric> hm
<viric> you said 'you are right' :)
<kyak> i said it in regards to "I think that 'links' configure script checks if your build-system gcc links properly with the build-system openssl
<kyak> oh, ok :)
<viric> do you understand the difference about the 'build system' and the 'host system'? :)
<kyak> by "build system" i understood the openwrt build envoronment
<viric> ahh no
<kyak> yes, i understand the build-host-target thing
<viric> ok
<viric> 5 minutes... I'll try to reproduce what I had yesterday
<viric> (thank you for the effort :)
<viric> kyak: I'll go building that links again...
<viric> kyak: So, at configure:5183: checking for OpenSSL
<viric> the next line (in config.log) says:configure:5194: gcc -o conftest -g -O2   ....
<viric> ah it also says
<viric> checking for gcc... gcc
<viric> It's not getting the cross compiler at all. humm
<viric> It looks like ignoring --build and --host
<kyak> viric: pretty strange!
<kyak> i guess your environment doesn't set necessary variables
<viric> it needs CC set to the cross compiler
<viric> (it's not usual at all in autoconf packages! I never did that before)
<kyak> dunno, like GCC
<viric> usually the configure script understands "--host"
<kyak> in operwrt, it is started with a bunch of env. variables
<viric> clear. Now I'm successing...  I just noticed it needs directfb though. :)
<kyak> so you might want to override some of them
<viric> does links look good in the nanonote?
<viric> kyak: in the qemu, did you manage to set the same resolution as the nanonote?
<viric> argh. "links -g" says 'unsupported color depth' in the nanonote
<viric> kyak: you have links with "-driver fb" or "-driver directfb"?
<kyak> viric: not using links on Ben ;)
<kyak> though might wannt try its graphic mode
<viric> go on go on :)
<viric> I found xiangfu probliems like mine: http://www.mail-archive.com/directfb-dev@directfb.org/msg08450.html
<kyak> viric: qemu has the same resolution.. i guess it is because app have such resolution by default (like gmenu etc)
<viric> ah
<kyak> links is a good target, btw
<kyak> though w3m also has image support
<kyak> (i'm not sure it's working on fb)
<viric> I'm trying newer directfb and links
<viric> bah. same result.
<kyak> it's reproducible, good ;)
<viric> kyak: It was already reproducible. It's a pity that upgraading all pieces it's still reproducible! :)
<bartbes> kyak: did you just mention qemu?
<kyak> bartbes: i guess so :)
<bartbes> do you emulate the full system, or are you just running the binaries?
<viric> kyak: how did you enable the keyboard input in your malta?
<kyak> bartbes: the full system, but it's not Ben. it's malta board. you can search the mail lists, viric pretty much explained how he did that
<bartbes> so how close to the ben is that?
<kyak> viric: i enabled pretty much every keyboard ;)
<bartbes> I mean, if it works in qemu, will it work on the ben?
<bartbes> that looks too epic to not do
<kyak> bartbes: it's just the kernel that it differenet, everything else us the same
<viric> kyak: hehe. I pressed some keys, and it started to work, somehow.
<bartbes> but that can still cause incompatibilities ;)
<bartbes> but if libc etc is the same then I guess it's all binary compatible
<kyak> it's 100 % the same, it uses the same rootfs
<kyak> only the kernel is differenet.. but since it's still mips, who cares
<viric> :)
<viric> you enjoy the ubi boot, eh? :)
<viric> it works fine here too.
<viric> I'm trying links there now..
<kyak> viric: no, i'm copying the rootfs to ext2 image :)
<viric> ah stupid me
<viric> the keyboard does not work. I simply had typed ctrl-alt-3, and went to the serial port. hehe
<viric> kyak: ahhh bad.
<viric> 19:28 < viric> I found xiangfu probliems like mine:
<viric>                http://www.mail-archive.com/directfb-dev@directfb.org/msg08450.html
<viric> 19:28 < kyak> viric: qemu has the same resolution.. i guess it is because app have such
<viric>               resolution by default (like gmenu etc)
<viric> 19:28 < viric> ah
<viric> 19:29 < kyak> links is a good target, btw
<viric> 19:29 < kyak> though w3m also has image support
<viric> 19:29 < kyak> (i'm not sure it's working on fb)
<viric> 19:33 -!- kilae [~chatzilla@catv-161-018.tbwil.ch] has joined #qi-hardware
<viric> 19:36 < viric> I'm trying newer directfb and links
<viric> 19:38 < viric> bah. same result.
<viric> 19:43 < kyak> it's reproducible, good ;)
<viric> 19:44 -!- heberth [~heberth@190.97.69.91] has joined #qi-hardware
<viric> 19:59 -!- mirko [~mirko@p5DDBB020.dip.t-dialin.net] has quit [Quit: leaving]
<viric> 20:01 -!- bassel [~bassel@178.171.133.151] has quit [Ping timeout: 240 seconds]
<viric> 20:02 -!- bassel [~bassel@178.171.133.151] has joined #qi-hardware
<viric> 20:20 -!- bassel [~bassel@178.171.133.151] has quit [Ping timeout: 240 seconds]
<viric> 20:27 < viric> kyak: It was already reproducible. It's a pity that upgraading all pieces it's
<viric>                still reproducible! :)
<viric> 20:33 < bartbes> kyak: did you just mention qemu?
<viric> 20:34 < kyak> bartbes: i guess so :)
<viric> 20:34 < bartbes> do you emulate the full system, or are you just running the binaries?
<viric> 20:35 -!- SiENcE [~home@g225018047.adsl.alicedsl.de] has joined #qi-hardware
<viric> 20:40 < viric> kyak: how did you enable the keyboard input in your malta?
<viric> 20:40 < kyak> bartbes: the full system, but it's not Ben. it's malta board. you can search the
<viric>               mail lists, viric pretty much explained how he did that
<viric> 20:41 < bartbes> so how close to the ben is that?
<viric> 20:41 < kyak> viric: i enabled pretty much every keyboard ;)
<bartbes> ?!
<viric> 20:41 < bartbes> I mean, if it works in qemu, will it work on the ben?
<viric> 20:41 < bartbes> that looks too epic to not do
<viric> 20:41 < kyak> bartbes: it's just the kernel that it differenet, everything else us the same
<viric> 20:42 < viric> kyak: hehe. I pressed some keys, and it started to work, somehow.
<viric> 20:42 < bartbes> but
<viric> OUCH!
<viric> sorry
<viric> my mouse got mad
<wpwrak_> by the way, with qemu, it should be possible to run MIPS binaries directly on the x86 host. that way, one could set up a mixed environment, with the qemu system but the cross-toolchain compiled for a x86 host. that way, disto-builders could run natively.
<wpwrak_> i've heard there's some distribution that uses this, but i don't remember which
<bartbes> viric: you don't happen to have a ready-made (clean) qemu image for me? :P
<bartbes> wpwrak_: yeah, that's why I asked, this solution is way cooler though
<viric> bartbes: I run directly ubifs images
<viric> but I only have the serial port working...
<viric> I've to find what keyboard to enable
<viric> wpwrak_: mips binaries work fine for me, with qemu-mipsel
<viric> and nanonixos builds as well for i686, for arm or for mipsel ;)
<viric> (spam)
<wpwrak_> bartbes: which is cooler - what i described or some other "this" ? :)
<viric> bartbes: I sent to the list, how to run ubifs images in qemu.
<viric> (I had to restart the X server. The mouse got mad totally)
<bartbes> viric: yeah, but it involved compiling a kernel and creating a ubifs image :P
<viric> hm
<viric> the image, you can take any of openwrt or jlime
<wpwrak_> viric: the idea is to run the toolchain natively on x86, to avoid the performance penalty of emulation
<viric> wpwrak_: all run the toolchain in x86, isn't it?
<viric> wpwrak_: or what do you call 'the toolchain'?
<wpwrak_> viric: gcc and friends
<viric> Do you run that emulated!?
<wpwrak_> viric: basically everything that burns cycles when building a distro :)
<viric> I can't believe
<bartbes> wpwrak_: but the cool thing about running it as a VM is.. well, it's a working system! :P
<wpwrak_> viric: the idea is to have a cross-compiler but to run things as if on MIPS
<wpwrak_> bartbes: but you gcc is then emulated, right ? i.e., it's slower than a cross-gcc compiled for your host
<viric> What will there be of mips, in your "as if on mips"?
<viric> wpwrak_: noone uses an emulator to build anything, I think
<viric> (for the nanonote)
<bartbes> wpwrak_: I don't want to run it for the compiler
<wpwrak_> viric: the userland, minus the exceptions you make. you'd have a MIPS tree you could chroot to. if you try to run a  MIPS executable, qemu takes care of that, via binfmt_misc
<wpwrak_> bartbes: then it makes sense. what i'm referring to is to run a build without explicitly having to configure all the packages for cross-development
<wpwrak_> bartbes: or, for building unpackaged things from sources, without special arrangements for cross-development
<wpwrak_> e.g., if the build process compiles something and also runs it, that would then be a MIPS binary and run under qemu
<bartbes> I mostly want it for testing
<viric> wpwrak_: ahh you want to do a native build
<viric> wpwrak_: as if on a super-power mips
<rafa_> viric: do you have network connection to your qmeu system?.. does it have interent connection too?
<wpwrak_> yeah :)
<bartbes> so is there nobody who actually has a ready-made VM for me? :P
<viric> rafa_: yes
<viric> rafa_: I use -net user now though.
<rafa_> viric: cool.. so you do not just have serial.. you can ssh to your qemu system right?
<viric> rafa_: yes
<rafa_> nice ;)
<viric> rafa_: and I have framebuffer going fine
<viric> rafa_: but not the keyboard! :)
<bartbes> hmm, I wonder though...
<rafa_> viric: well.. almost complete :)
<bartbes> the image was mpc, right?
<viric> I'll try enabling CONFIG_KEYBOARD_XTKBD
<bartbes> *has
<viric> what is mpc?
<bartbes> a client for mpd
<bartbes> the Music Player Daemon
<viric> ah
<viric> I don't use it
<bartbes> anyway, I wondered whether I could easily stream the audio as well
<bartbes> I guess I could poke around.. if I weren't lazy :P
<bartbes> btw, what kernel source do you use? do you use the xburst source tree, or get one from kernel.org, or even somewhere else?
<viric> rafa_: I don't simply have a qemu system; 'nanonixos' can build an image for qemu, a rootfs for the nanonote (+ kernel + uboot), or it can write an "update" to a running nanonote system.
<rafa_> viric: I do not know nanonixos.. sorry.. which is the idea to build uboot?.. you mean .. for nn?
<viric> rafa_: yes. I don't like to depend on prebuilt binaries ;)
<rafa_> viric: I am not a fan of building systems to build kernel, rootfs and uboot (bootloaders).. I like openwrt/OE/other building systems to build repositories for specific archs and kind of devices (for example.. the packages which openwrt/OE buildfor mobile devices)
<rafa_> viric: but, for bootloaders, kernels, rootfs.. I like to have a proper standar way
<viric> :)
<viric> Well
<viric> I have my proper standard way
<bartbes> kyak: you don't happen to feel like sending me the stuff to run a 'ben' VM?
<rafa_> viric: yeah :).. just that all the people are liking openwrt/OE/etc... for thinkgs like building kernels, bootloaders, rootfs.. which I find hard to port between those systems
<wpwrak_> viric: "my standard" ;-)
<viric> wpwrak_: exactly! :)
<viric> Time for supper.
<rafa_> viric: are you from poland?
<viric> rafa_: haha let's say that the spaniards think so :)
<viric> rafa_: I'm catalan
<rafa_> :D
<rafa_> haha.. some devs from jlime, from poland, have those "time for supper" as well :)
<viric> "hora de sopar", in catalan
<rafa_> viric: barcelona vs real madrid right now
<viric> rafa_: ah yes.
<viric> rafa_: I'm not a fan of football :)
<viric> kyak: I think I may need SERIO_PCIPS2 to get the keyboard
<viric> rebuilding.
<viric> Argh
<viric> I just noticed the down arrow does not do anything in my nanonote
<viric> even 'showkey' does not show any number
<viric> ahhh I have to press it strongly
<viric> kyak: got it! CONFIG_SERIO_I8042 gave the keyboard.
<kristianpaul> prinitng rafless a gift for hollidalys
<kristianpaul> if it get good shape i can try wpan case again later :)