<kyak>
actually, wolfspraul expressed many of my own concerns
<wolfspraul>
hah, let's wait until the netsplit is over :-)
<kyak>
yeah :)
<kyak>
xMff: you were asking about the list of apps that require iconv/intl - should I just grep apps that DEPEND on iconv/intl from qi's openwrt-packages or you need something else?
<kyak>
if you wanted to have a look at those apps, you could just add qi's openwrt feed and see it yourself
<bartbes>
more interestingly, *your* failing packages
<bartbes>
the efl feed has 'enlightenment'
<bartbes>
it's upstream, and doesn't compile
<bartbes>
I'm guessing there are more of those
<kyak>
oh, ok
<bartbes>
kyak: that was at xMff, I have no idea what he asked for
<bartbes>
:P
<kyak>
i think you got it right
<kyak>
anyway, i got stuck at fbterm compilation
<kyak>
with "tiny" libiconv
<kyak>
maybe something else was affected, i don't know, because then i wanted "full" libiconv back
<kyak>
now i'll try to build against tiny libiconv and see what else fails
<kyak>
and i have to believe xMff that the tiny libiconv is a real replacement for libiconv, and if an app builds fine, there will be no problems during runtime
<kyak>
but to tell the tryuth, i'm not sure about that
<kyak>
i think that's all from me, xiangfu might have other opened tickets
<wolfspraul>
ok we have 4 open ones right now - 8603, 8413, 8594, 8282
<kyak>
yes; btw, 8413 is what has been bugging bartbes for a while now
<kyak>
bartbes: am i right?
<bartbes>
no
<bartbes>
I get a link error
<wolfspraul>
kyak: can you build bootable/working images now? I was a little surprised that you and xiangfu said you could not build a working image since mid-December
<wolfspraul>
my one and only focus is how we get to the next image, with improvements and all the stuff contributed in recent weeks, and without regressions
<kyak>
yes, we can now that we've overriden libiconv, gettext and glib2
<wolfspraul>
ok I see
<bartbes>
but then again, I patched it to link against libiconv-full
<kyak>
what's the error?
<bartbes>
missing iconv_open, iconv_close and iconv symbols
<kyak>
oh, pretty strange.. are your libiconv-full and gettext-full different from the ones in openwrt-packfges?
<kyak>
because as i mentioned yesterday, libiconv-full and gettext-full are basically renamed to libiconv and gettext and now present in openwrt-packages (overriding the ones from openwrt feeds)
<bartbes>
I heard it was some header issue probably
<bartbes>
oh, I know
<bartbes>
that might have been an error I did
<bartbes>
anyway
<bartbes>
still
<bartbes>
since gettext creates no actual lib
<kyak>
i just wonder, why you have this error
<bartbes>
nothing can link against this
<kyak>
hm, it created libintl
<bartbes>
oh, I probably messed up, I'll try again later
<bartbes>
it.. did?
<kyak>
have a look into Makefile
<kyak>
you should link against libintl
<bartbes>
because I'm pretty sure the makefile doesn't install anything but headers and autoconf data
<wpwrak>
kyak: ah, thanks. seems that e-wm could be the right name. but there's no e-wm package. well, i'll just wait for zrafa's comment :)
<wpwrak>
bartbes: if you didn't have X, what windows would the window manager manage ?
<bartbes>
true
<bartbes>
but it could at least give you a desktop
<wpwrak>
without windows ? hmm ...
<wpwrak>
bartbes: zrafa's been doing a lot of work around e* lately, maybe he knows if what you have in mind is a perversion raster has already indulged in
<bartbes>
hmm
<bartbes>
edje can be used to create a launcher
<wpwrak>
hmm. now why did i leave that 0R in the clock line atusd ? doesn't get any more useless ...
<zrafa>
wpwrak: I just checked.. Yes, it should be e-wm, and it is not there :P.. but.. I tried to build the packages with OE and it looks like it built the e-wm just fine :P
<zrafa>
wpwrak: because I think that jlime repo at qi is okey if we keep it stable (or frozen) I would prefer to upload these new packages on extra-packages. For opkg, jlime-pkg or qpkg would not have difference. So those packages would be there for installation
<zrafa>
SO jlime-pkg update; jlime-pkg install e_wm (or whatever) would work
<zrafa>
wpwrak: what do you think?
<xMff>
kyak: they do really stupid stuff in their code :(
<kyak>
xMff: thanks! i'll try to stop what else packages might have problems.. most of all i'm afraid of runtime problems
<kyak>
*try to spot
<bartbes>
great, jlime boot failed
<bartbes>
*sigh*
<bartbes>
it's never easy
<xMff>
kyak: basically (void *)-1 must be changed to (iconv_t)(-1)
<xMff>
kyak: in io.cpp
<kyak>
xMff: i agree, the code might be out of date and stupid.. but rewriting libiconb from scratch is not good, too :)
<zrafa>
bartbes: why it is never easy?
<wpwrak>
zrafa: yeah, as long as it works, that's good :)
<kyak>
xMff: thanks for the hint
<xMff>
kyak: point is that it probably fail with other non-gnu iconv implementations too. iconv_t is not guaranteed to be void * (or a pointer at all)
<zrafa>
wpwrak: yeah, that will work out of the box.. NO idea if e17 will work, we need to test :)
<wpwrak>
zrafa: i think we ultimately should move the jlime repo at qi-hw from "stable" (= frozen) status to "alive". but that's work for another day ;-)
<bartbes>
zrafa: I meant in general, not jlime
<kyak>
xMff: yeah, i think fbterm is build with gnu iconv in 99% of cases...
<bartbes>
;)
<bartbes>
in this case a reboot fixed it
<bartbes>
'fixed'
<kyak>
xMff: thanks a lot for your explanations yesterday and patience, too
<zrafa>
bartbes: ah :).. well, I remember that I failed to have the bootloader file.. and when I did the command for installation on NAND it did not install the bootloader.. so after that system did not boot (of course) but worse.. I was not able to have the usbboot again :P
<bartbes>
there's always hardware usb boot
<zrafa>
bartbes: yeah, but that was my first time trying that hardware usb boot.. so it took a lot of time I think
<wpwrak>
gah. i solder like a spider on dope. that death-by-caffeine breakfast probably wasn't such a good idea. hmm, perhaps a bit of beer will sooth my itchy hands ...
<bartbes>
right
<kyak>
wpwrak: just for info, what's your time zone? you seem to be always active :)
<bartbes>
zrafa: so when can we expext an e-wm package?
<kyak>
wpwrak: or, you have that AI bot speaking instead of you, while you are sleeping :)
<wpwrak>
kyak: WTZ, werner's time zone :) the external stimulus (that day star) would be buenos aires time
<kyak>
heh
<zrafa>
bartbes: those built just fine, I should upload but no remember exactly how to do that :P
<zrafa>
bartbes: checking my notes..
<zrafa>
wpwrak: do you remember the wiki page link explaining details about how to upload stuff to downloads.qi.. etc?
<wpwrak>
www-data@downloads.qi-hardware.com ?
<zrafa>
bartbes: I have other nice things to upload to extra packages yet, like emacs as well which was cross compiled (with the final binary dump, no the huge thing which takes a lot to run), but lazy or no time to make the proper ipk these days :(
<zrafa>
wpwrak: is downloads.qi-hardware.com?.. I guessed that I used another server name
<zrafa>
wpwrak: let me try..
<zrafa>
wpwrak: yes.. works :)
<zrafa>
bartbes: almost uploading..
<bartbes>
alright
<zrafa>
uploading..
<bartbes>
powers on ben
<zrafa>
E : well.. uploaded... And I tried to install. It installs, but you have to modify jlime-pkg. replace into /usr/bin/jlime-pkg the line  "opkg install *.ipk"  with  "opkg  --force-overwrite install *.ipk"
<zrafa>
Also, we should install the recommended packages that installation suggests. Those packages are on repo
<zrafa>
export DISPLAY=:0 ; enlightenment_start
<zrafa>
I guess that we need the recommended packages installed before.
<zrafa>
wpwrak: bartbes: I modified /etc/muffinman-extras/startx, commented out matchbox lines.. and added enlightenment_start after Xfbdev line..
<zrafa>
it runs..
<zrafa>
now I do not know what to do :D
<bartbes>
get proper keybinds? :P
<zrafa>
(I installed the recommended packages suggested before)
<zrafa>
bartbes: yeah
<zrafa>
bartbes: let me check if I find some documentation useful
<bartbes>
zrafa: I can't run update via jlime-pkg?
<zrafa>
bartbes: which jlime version you have? the one from qi?
<bartbes>
ehm..
<bartbes>
one I saw announced in the mailing list..
<bartbes>
I guess it's the one you introduced jlime-pkg in..
<bartbes>
how do I get the version?
<zrafa>
ah.. okey. You have the version under OE+jlime development. The current with the e-wm packages is the uploaded to downloads.qi
<zrafa>
bartbes: let me give you the link
<bartbes>
so.. what's the diff?
<wpwrak>
bartbes: can your jlime'd ben see the intertubes, google, youporn, etc. ?
<zrafa>
bartbes: several things. Mainly you have the version which is being merged with OE. The version at qi servers does not have packages with patented technologies.
<zrafa>
bartbes: that is the main link of the version with the e-wm packages I uploaded.
<bartbes>
does it have an sd rootfs?
<bartbes>
oh it does
<bartbes>
yay
<zrafa>
bartbes: mainly there are several jlime version because I did that version at qi for this project. But also B_Lizzard is working hard on merge his jlime version work for nn into OE. So there are some diffs. But more or less it is the same :)
<zrafa>
bartbes: yes, there is a version for SD
<bartbes>
what's the diff between the normal and the bootstrap version?
<zrafa>
bartbes: bootstrap is a minimal system.. it boots and lets you on a shell.. YOu can play to convert that version on your dreamed version for installing packages
<zrafa>
you want and GUI you want, etc
<bartbes>
hmm so that would be ideal for e17 ;)
<bartbes>
I'll stick with stock for now
<zrafa>
bartbes: maybe.. yes, but full version would be faster to run perhaps.
<zrafa>
bartbes: but yes. bootstrap is nice to play :)
<bartbes>
opkg_prep_intercepts: mkdtemp: No space left on device
<bartbes>
zrafa: that went well (see above)
<wpwrak>
seems that the intercept was successful
<kristianpaul>
zrafa: boostrap is nice for sie
<kristianpaul>
e low-level software (ogusb-lite.exe) provided with the board takes the samples and dumps them to a file as 8 bit values...inefficient but easy to work with.
<zrafa>
kristianpaul: yeah, I guess that it should be a good start point for sie
<zrafa>
kristianpaul: and you can add just you need
<zrafa>
bartbes: no space left?.. poor jlime :)
<bartbes>
poor me
<bartbes>
:P
<zrafa>
haha :)
<zrafa>
I have a new 2gb uSD card.. old one broke
<bartbes>
mine is...
<kristianpaul>
literally broke or just stop working?
<bartbes>
4gb
<bartbes>
I just partitioned really well
<bartbes>
;)
<zrafa>
;-))
<wpwrak>
roh, kristianpaul: for the "case", i was thinking of a U-shaped (in 3D) piece of silicone. slightly thicker but less wide than the board, so that one has to squeeze/tear it to make it fit, and it would stay in place mainly by friction
<roh>
wpwrak: sounds like some experiments are needed
<wpwrak>
roh, kristianpaul: this ought to be relatively simple to make, provided a two-component silicone preparation and a suitable release agent can be found. (the easily available acetone-based silicones used as bathroom/kitchen/etc. sealants may take a very long time to cure in this kind of mold, due to limited air flow.)
<wpwrak>
roh: aren't they always ? ;-)
<wpwrak>
"ten years of intensive research show that more research is needed" ;-)
<viric>
hmm isn't there any bluetooth µsd device around?
<viric>
I imagine wpan is the only way to go :)
<wpwrak>
(BT) dunno. maybe, if there's wlan, there may be BT, too. but spectec themselves only have BT for mini-SDIO
<viric>
ok
<viric>
what is that 'io' after sd?
<viric>
anything relevant?
<wpwrak>
SDIO is an extension of the SD (memory card) protocol
<wpwrak>
adds new commands to access registers and also introduces an interrupt signaling mechanism
<qi-bot>
[commit] Werner Almesberger: tools/: renamed OpenWRT target from "ben" to "ben_openwrt" and added "ben_jlime" http://qi-hw.com/p/ben-wpan/45e55fe
<qi-bot>
[commit] Werner Almesberger: tools/lib/misctxrx.c: decode AMI and CCA_ED_DONE interrupts (231 only) http://qi-hw.com/p/ben-wpan/1befc69
<viric>
The SDIO-Linux project provides an open source SDIO-stack. The stack comes complete with drivers for the Host and Bus controllers, SD/MMC memory cards, SDIO-bluetooth and Atheros WLAN driver.
<viric>
so some SDIO-bluetooth card should work
<viric>
maybe not µsd
<wpwrak>
dunno how compatible all the SDIO-BT cards are with respect to each other
<wpwrak>
there's no difference in the protocol between SD, miniSD, and uSD
<qi-bot>
[commit] Werner Almesberger: atrf-txrx: small 231 continuous transmission mode cleanup (doesn't work yet) http://qi-hw.com/p/ben-wpan/9b498ae