<kyak> xiangfu: hi!
<kyak> this line "pixelformat=RGB24" is causing problems to stardict (maybe NanoMap, too) -\
<kyak> it gets shrinked
<kyak> in /etc/direcfbrc
<xiangfu> kyak: oh. yes. I am not well test. I will remove that
<qi-bot> [commit] Xiangfu Liu: remove the pixelformat=RGB24, make some program display not correct http://qi-hw.com/p/openwrt-xburst/340a6c5
<kyak> xiangfu: when i start stardict from gmenu2x, and then exit stardict, i'm back to gmenu2x - it is ok. If i try then to start ash, i have a blank screen (i need to press Alt+1 to switch to tty1 to see ash)
<kyak> do you have the same problem?
<kyak> if i start stardict from console, it doesn't release the screen correctly
<kyak> i think it is the problem
<kyak> for the NanoMap, i think mirko fixed it by force using linuxfb in Qt
<xiangfu> kyak: same here.
<kyak> maybe there is a similar trick for gtk..
<kyak> ok.. at least i'm not alone :)
<kyak> gtk is built with --with-gdktarget=directfb, i guess there is no way to make it use linuxfb at runtime (should be recompilde with --with-gdktarget=linux-fb)
<kyak> seems they obsoleted linuxfb
<kyak> and that's all the documentation they got
<kyak> pretty dissappoitning
<wpwrak_> zrafa: btw, we still have jlime in an "almost official" status. so you (or anyone else) have further plans for that ?
<zrafa> wpwrak_: hey, hi. For the stuff uploaded (images, kernels, crosscompiler, repository) there is a bit of work to do:
<zrafa> - write some doc about how to install, how to use
<zrafa> - decide if we change or not current jlime-pkg
<zrafa> - decide ip
<zrafa> - write a bit of doc about how to use cross toolchain
<wpwrak_> yup. that's the impression i had ... a few small things missing, but it's almost there
<zrafa> - explain the struct of the repository (for example: extra packages is the place to upload extra ipk packages built with toolchain for example, so everyone know that if we delete the whole extra-packages/ dir the repository is safe yet)
<wpwrak_> so .. what are the plans for those "small things" ? ;-)
<zrafa> - the rest of the repository is the base thing.. it should be untouched
<zrafa> - decide kernel NAND layout
<wpwrak_> ah right, the dreaded NAND layout :-(
<zrafa> wpwrak_: if we decide those few things I could have a bit of fun doing that :)
<wpwrak_> (small things) i'm also asking because qpkg, if you want to use it, will need a bit more work. there's mainly one somewhat hairy algorithm missing (cleanup after backtracking). i expect that this will take me a few days to hack.
<wpwrak_> for the IP, i think it would be best to just use the same as openwrt. so when you want to connect to your ben, you connect to your ben, no matter what it runs
<zrafa> wpwrak_: I would like, definitely, to use qpkg, but I do not have free time now. I would do the small things from time to time
<zrafa> wpwrak_: I have also a few extra packages more to upload on extra-packages: like emacs, git, and few other users asked
<zrafa> (packages I already built with toolchain)
<wpwrak_> (time) yep, i know that this is the difficult part :)
<zrafa> wpwrak_: yes, but every user should do something to tell ssh ignores known_hosts
<wpwrak_> so the plan is that things will happen when they happen ? :)
<wpwrak_> easy: StrictHostKeyChecking no UserKnownHostsFile /dev/null
<zrafa> I can change ip easily, uploaded packages. Then I could copy/paste documentation from jlime about how to install/how to use. kernel layout, toolchain explanation, repository doc explanations and jlime-pkg would be left for contributors
<zrafa> uploaded=upload
<wpwrak_> hm. that would leave us with an uSD-only distribution. okay, it's a start.
<zrafa> ubi no?
<zrafa> ubi as well
<wpwrak_> yes, bit you'd need the kernel/nand layout for this, no ?
<wpwrak_> s/bit/but/
<zrafa> wpwrak_: well, users can use current ubi.. when something is decided I can re build the kernel .. no idea if ubi rootfs needs to be re done. If so, I can do easily from .tar.gz images for uSD
<wpwrak_> which NAND layout are you using now ? the one with the 256 MB rootfs or the one with 512 MB ?
<wpwrak_> (i wonder what's happening in our installed base. i.e., how many people have actually switched so far)
<zrafa> wpwrak_: the original one: the whole nand for rootfs
<zrafa> well, bootloader, kernel, and then the rest for rootfs
<wpwrak_> so there may be a bit of a problem
<wpwrak_> heh, mirko hides :)
<zrafa> :)
<zrafa> bit of problem: well, I am not sure if all users use the same layout, still if they use the same distro :)
<wpwrak_> yeah. the absence of lots of problem reports on the list suggests that many may still have the old layout :)
<wolfspraul> I think current NanoNote users fall into 2 rather extreme groups
<wolfspraul> either they don't touch what is installed at all, just play with it, some give up quickly, some try longer and squeeze some limited use out of the limited software that is currently preinstalled
<wolfspraul> or they 'go pro', meaning that they try Debian, Jlime, or building their own OpenWrt from scratch
<wolfspraul> we need to make updating NanoNote software much much easier, it's one of my (many) priorities :-)
<Ornotermes> any one tried to connect a mouse to ben throgh uSD break out yet?
<wpwrak_> wolfspraul: good :) still, even some of those "going pro" should run into difficulties with a layout change. the silence surprises me a bit.
<wpwrak_> Ornotermes: you can be the first one ! ;-)
<Ornotermes> wpwrak_: maybe, how many data pins does ben wpan use?
<wpwrak_> it uses all pins. two of them carry data (MOSI and MISO)
<viric> wolfspraul: I build all - kernel, uboot, ... I run 2.6.36. No trouble. :)
<wolfspraul> viric: second category ;-)
<viric> hehe
<viric> wolfspraul: the openwrt-trunk kernel 2.6.35 and 2.6.36 still have that "old layout" I think
<bartbes> viric: you misspelled my name! :(
<viric> ouch :)
<bartbes> viric: well, I registered barbes on freenode as well, since you're not the first to spell my name that way
<bartbes> it does have an interesting ring to it
<bartbes> barbes..
<viric> hehe
<lekernel> http://www.cl.cam.ac.uk/~sd410/papers/pat7550858_trng2.pdf <= lol, I had a very similar idea... but to make a cloud chamber with DRAMs, not a RNG (I'm more a "physicist" than a "security researcher"...)
<lekernel> it didn't work, though, as it turns out the packages of DRAM seem pretty good at blocking alpha particles
<lekernel> and I didn't have any DRAMs that I could remove the package of
<wpwrak_> maybe use CCDs ? :)
<lekernel> yeah, already done (for a RNG again... usual hacker's obsession with security :p)
<lekernel> I can't find the URL I had, but there's http://inventgeek.com/Projects/alpharad/overview.aspx
<wpwrak_> heh :) well, for security, there's still the aircraft transponder stuff waiting. all you need is a USRP with the WBX board (a sub-1GHz transceiver) and you can receive those messages. there's little suggesting that you couldn't also transmit them ...
<wpwrak_> seems that this kind of stuff has come into reach for the average DIY saboteur :)
<lekernel> I'm not at all into security (anymore)
<lekernel> it's kinda boring
<lekernel> professional outcomes are telcos, governments, and mafias
<wpwrak_> (for the record, i don't have a WBX, and the BUE airspace is chaotic enough that i don't think they need any amateur help :)
<lekernel> (or staying in your basement doing "underground hacking" for the challenge only...)
<lekernel> ah, or, well, now there's wikileaks :)
<wpwrak_> ah yes.  wikileaks and the hydra effect.
<wpwrak_> chop off one head, two grow back :)
<wpwrak_> drill files are fun. they're right from the dark ages when standards were savage and very promiscuous.
<wpwrak_> .. and the space on your punch cards precious. if your technology was already that fancy.
<qi-bot> [commit] Werner Almesberger: cameo/gnuplot.c (gnuplot_do_write): only write r_tool hint if non-zero http://qi-hw.com/p/cae-tools/d31bd95
<qi-bot> [commit] Werner Almesberger: drl2gp: convert KiCad drill file (Excellon) to gnuplot (in progress) http://qi-hw.com/p/cae-tools/1ab2622
<kristianpaul> ( security - it's kinda boring) agree sadly i live from that :/