<kyak> xiangfu: hi! how is your success with the latest build?
<kyak> mine is not very good
<kyak> NanoMap is not working (complains that now driver could be found, lookinf for /usr/bin/gfxdrivers/)
<kyak> startdict is hanging is before, during startup
<kyak> nlove couldn't be started, too
<bartbes> oh
<bartbes> that's not a problem with the image though
<bartbes> the default screen you see when there are no arguments passed is still 800x600
<kyak> bartbes: yeah.. it complains something about booter.lua
<bartbes> so it can't open the display
<bartbes> or.. that
<bartbes> if you feed it a game it'll work
<kyak> hm, how do i do it?
<kyak> i just 'nlove'
<xiangfu> kyak: :( mine is still compiling.  I start is 4 hours before.
<bartbes> well, first you get a game, so npong: http://dl.dropbox.com/u/440010/nlove/npong.love
<bartbes> then you run nlove <game.love>
<bartbes> I should fix the no game stuff sometime
<bartbes> :P
<kyak> bartbes: ok, thanks! gonna give it a try :)
<kyak> for some reson, i thought that "nlove" IS the game :) though i remember you explained it's just a framework
<kyak> xiangfu: well, ok, maybe you'll have a better luck :)
<kyak> xiangfu: is your latest config commited to git?
<xiangfu> kyak: no. since it's still compiling.
<kyak> i mean, the one from 3rd September
<kyak> or when you made the previous build
<xiangfu> kyak: hmm.. I am not keep that one.
<wolfspraul> xiangfu: I think you should commit the config file before you even start the build. what is the advantage of keeping it local?
<wolfspraul> the revision control system can handle a few revisions :-)
<xiangfu> wolfspraul: I want test before commit. :)
<xiangfu> wolfspraul: I don't think without test , then just commit is a good idea.
<wolfspraul> yes but it's a config file, and it needs to be copied to .config manually
<wolfspraul> so whatever you commit, even if you commit a 'broken' config file, the build process that involves it is still manual
<xiangfu> wolfspraul: ok.
<wolfspraul> it's more like a documentation file, give its position in the directory tree
<wolfspraul> well that's my opinion only, if someone disagrees fine. do what you think is right.
<xiangfu> wolfspraul: understand. :)  thanks.
<wolfspraul> but you see there were several people already asking now, and you send the file by mail, or you don't have it anymore, etc.
<wolfspraul> sounds like if you would use revision control, you could point everybody to what they are asking for
<xiangfu> wolfspraul: yes.
<wolfspraul> and you don't break the build, because this file is in a manual-use location in the tree anyway
<xiangfu> wolfspraul: yes
<xiangfu> wolfspraul: I have add a sample music file to /root/Music
<qi-bot> [commit] Xiangfu Liu: add some sample music file. http://qi-hw.com/p/openwrt-xburst/e39e43e
<qi-bot> [commit] Xiangfu Liu: update config to use uClibc, change VERSION to 2010-09-06 http://qi-hw.com/p/openwrt-xburst/0b9c16f
<wolfspraul> ok
<wolfspraul> we need to think about that 'including data' problem later in more detail
<wolfspraul> but some sample files are good for now
<xiangfu> wolfspraul: I follow the roh's suggest. put a README file and attach the sample URL. license.
<wolfspraul> later if we want to include more data, say entire dictionaries, wiki content, maps, etc. we need a way to package them. should we use normal openwrt .ipks for the data? or some other mechanism? I don't know.
<wolfspraul> sure that's OK for now, that's about satisfying the attribution requirement.
<wolfspraul> I am talking about larger amounts of data now, say entire offline wikis, or larger amounts of map data.
<wolfspraul> how should they come to the nano, packaged in which way? openwrt is typically only used for binaries (executables), maybe some small amount of documentation files
<wolfspraul> but entire music albums? hundreds of megabytes of data? like I said don't know.
<xiangfu> wolfspraul: hmm.. me either.
<bartbes> slackware tgzs
<wolfspraul> bartbes: slackware tgzs what? can you be more precise?
<wolfspraul> I think the normal packaging systems are suited for binaries and especially dependencies/versioning of packages.
<bartbes> it's just a tgz but it includes full paths
<bartbes> so if you want to install something to /usr/share/gmenu2x/epic-wallpaper.png
<wolfspraul> so what? we put such files on the server somewhere? how do they get installed, how uninstalled? are updates necessary?
<wolfspraul> for example offline wiki content, dictionaries, map data
<bartbes> you have a tgz containing a folder usr, which contains share, which contains gmenu2x which then contains the wallpaper
<wolfspraul> cannot have all maps of the whole world on the nanonote
<bartbes> to install you just extract
<wolfspraul> say for nanomap
<bartbes> of course removing is.. somewhat.. harder
<wolfspraul> let's say you go to a trip in nothern italy
<wolfspraul> florence, venice, verona
<wolfspraul> how can you quickly get all of northern italy onto your nanonote?
<wolfspraul> and when you are back home, do you quickly delete it
<bartbes> yes, I know what you want to do
<wolfspraul> or say offline english wiki data
<wolfspraul> here the main issue is probably updates
<wolfspraul> how to update it?
<wolfspraul> sure we can throw everything into .ipk and reuse that system
<bartbes> a super-intelligent bash (ehm.. ash) script
<wolfspraul> but : 1. that's definitely a different usage of the packaging system than what anybody upstream would use it for. 2. it may not be suited well to the needs of large amounts of data, incremental updates, etc.
<wolfspraul> for example I would like to quickly have a couple of Chinese cities in nanomap
<wolfspraul> the whole guangzhou/shenzhen/hongkong section :-)
<wolfspraul> well we see, don't need to find a perfect system today
<bartbes> I'd suggest a vcs if they weren't so inefficient (with space)
<wolfspraul> but as the software gets better (the viewers & editors), the question of how to get larger amounts of data to the ben and removed becomes more important
<wolfspraul> otherwise why have viewers?
<wolfspraul> :-)
<wolfspraul> for larger amounts, incremental updates would also be cool
<bartbes> squashfs
<bartbes> ofc you would have to mount a lot
<wolfspraul> my feeling is data is just different from binaries, maybe some solutions already exist
<bartbes> but you'd get self-contained data 'files'
<wolfspraul> the normal packaging systems are geared towards the needs of binaries
<wolfspraul> heavy on dependencies, versioning
<wolfspraul> bartbes: what do you mean with vcs?
<wolfspraul> sorry that abbreviation doesn't ring a bell
<bartbes> version control system
<bartbes> (git, hg, etc)
<wolfspraul> most are really weak with binary data
<bartbes> they are inefficient anyway
<wolfspraul> but in a lot of cases we may be dealing with binary data
<bartbes> so, I then said squashfs
<wolfspraul> I don't know. how does that help with the delivery problem, incremental updates, removal of data.
<bartbes> well, removal is easy
<bartbes> just remove the sfs file, done
<bartbes> updates are a problem, yes
<wolfspraul> I think we need some software, just like dpkg/opkg, but tailored to the needs of data
<bartbes> but at least it contains all data in a 'package'
<wolfspraul> I don't believe in twisting tools that were made for a particular purpose to do something else.
<wolfspraul> I cannot believe that we are the first ones to look into this problem.
<wolfspraul> the nanonote has 2gb today, not that much
<wolfspraul> and tomorrow? 16gb, 32gb, etc?
<wolfspraul> what to do with all this space?
<wolfspraul> nothing?
<wolfspraul> just need some good 'data manager' that knows what type of data it is managing, can get updates, can visualize amounts of data, make it easy to remove etc.
<wolfspraul> what data are we talking about?
<wolfspraul> music, videos, dictionaries/wiki content, maps
<wolfspraul> more?
<bartbes> games :P
<wolfspraul> books
<bartbes> pictures
<wolfspraul> yes sure, games. but many of those are still well suited to be managed by normal package managers, no?
<bartbes> (/images)
<bartbes> it seems a bit useless to make a ipk for a single .love file
<wolfspraul> sure but then you just package suites of games
<wolfspraul> unless the data content becomes really large, I think normal .ipks will just do fine
<wolfspraul> what I am talking about is more about music albums, maps, etc.
<wolfspraul> for a music album, there will never be dependencies
<wolfspraul> nor will there be an 'update' or a 'new version'
<bartbes> true
<wolfspraul> there may be different music. I may get bored with some album.
<bartbes> but for maps there will be updates
<wolfspraul> yes
<wolfspraul> but maps will be so big, you cannot have the whole world on your nano
<wolfspraul> to it should be easy to swap in and out, for trips
<wolfspraul> and it should be easy to update, if you are in a region a bit longer, say your home region
<bartbes> but what I meant is, that you should not rule out versioning
<wolfspraul> also let's say your device is full, but you need some free space, the data manager should be able to quickly help you free a couple hundred meg
<bartbes> also, I wondered.. wouldn't it be great if it were capable of installing straight from your computer?
<wolfspraul> saying "there is these 5 music albums that you haven't listened to in a year anyway" - click here to delete
<wolfspraul> the data manager should present me with 'unused data', the same way dpkg can tell me about orphaned or unused packages
<bartbes> big diff
<bartbes> it does that based on deps
<wolfspraul> bartbes: yes, fine [versioning] but my point is, if the people writing the tool, say opkg, don't really wrap their head around the needs of data, in the use cases we are talking about here, then abusing their tool for data may work for a while, but will never be really god
<bartbes> not on whether you actually use it or not
<bartbes> anyway
<bartbes> gt
<bartbes> *gtg
<wolfspraul> and if you explain your problems to them, they will be like "oh, we never use our tool like this"
<wolfspraul> I don't feel right packaging a 100 mb music album into an .ipk file
<wolfspraul> does anybody else do that?
<wolfspraul> there's some activity in distributed filesystems, but not sure whether it applies
<wolfspraul> I don't believe massaging this into sql databases either, they were built for relational data... doesn't fit.
<wolfspraul> are any of the distributed file systems any good nowadays? andrew, coda, etc? do they apply to this problem?
<wpwrak> Ornotermes: hmm, have you tried drawing power from VDD ? I'm getting ridiculously little current
<Ornotermes> wpwrak: i got a slow voltage drop when i connected my scope, so i suspect the fet transistor is switched off
<wpwrak> wolfspraul: the real solution for xiangfu's slow updates will be to get him a faster PC :) also, even if the config is copied manually, if I understand what this is about, people who follow the manual process would still pick up the untested file, no ?
<Ornotermes> wpwrak: check the state of PD02
<wpwrak> I see the voltage rise and fall like it should. but when i add any kind of significant load, it drops badly.
<wpwrak> i modified an otherwide empty board to have a 100 Ohm resistor between VDD and GND. voltage drops to about 66 mV. that can't be right.
<wpwrak> oh, wait. i have GPD06, not GPD02. hmm :)
<Ornotermes> i traced it to PD02 anyway, but i could ofc be wrong :P
<wpwrak> PD02 definitely looks right.
<wpwrak> not sure where i got the GPD6 from
<wolfspraul> wpwrak: if we only commit the config file after a successful image release, we have created a huge bottleneck to ever improve the image in the sense that more stuff is included
<wolfspraul> in fact, this is why after over a year, we still don't have at least 50 easily included apps included, and sometimes even some apps 'drop out'
<wolfspraul> it must be the other way round. whenever someone commits an app that compiles, the respective line in the config file is set to Y, and the config file is committed
<wolfspraul> if someone builds an image later, and some apps don't compile, it's easy to set them to N again
<wolfspraul> the other way round simply means that there will never be progress in completing the apps that are included
<wolfspraul> or maybe it takes a few centuries, at the speed we give feedback such as 'sox is missing', and then it takes x months until that is reflected in the image
<wolfspraul> so like I said - everybody should feel free to 'enable' a nice little app in the config file, and commit that 1-line change right away
<wolfspraul> at least until we feel we have a really strong set of 'base apps' in the image and running out of space in the rootfs
<wpwrak> will people who follow the build instructions pick up such untested configs ? if yes, that would be bad
<wolfspraul> currently we have 2 config files (remember, at that location the configs are more like documentation / starting points)
<wpwrak> one "stable" and one "testing" ?
<wolfspraul> one is for xbboot (rescue image to be booted via usbboot), and the other one is an image that should include as complete as possible set of 'base apps'
<wolfspraul> we could have a third config file, empty base system
<wolfspraul> config.base
<wolfspraul> config.factory_default
<wolfspraul> config.xbboot
<wolfspraul> but when would someone need config.base? I don't know
<wpwrak> seems that you need a stage for yet to be tested configs. that way, people who can't wait for xiangfu's pc can pick the bleeding edge config, while those who just want to build anything recent will get the stable one
<wolfspraul> no no. I don't see the config files as having anything to do with development. it's not about unstable/testing/stable
<wolfspraul> it's just a list of apps, Y or N
<wolfspraul> so the xbboot image needs to be small
<wolfspraul> a few megs
<wolfspraul> and only needs tools you would want in a rescue situation
<wolfspraul> since this is an initramfs that is loaded to boot/unbrick a nanonote directly from usbboot
<wolfspraul> the smaller the better (in that case)
<wolfspraul> the factory default should make some use of the NAND, which otherwise is just empty, and include all meaningful apps contributed or tailored for the Ben NanoNote
<wolfspraul>                     reflected in the image
<wolfspraul> (sorry)
<wpwrak> did a config change ever have to be reverted due to problems ?
<wolfspraul> of course, whenever an app actually doesnt' compile
<wpwrak> aha ! so it is "development" :)
<wolfspraul> most of the time, when someone wants to make an image, and app whatever doesn't compile, that person will just kick that app out of the list
<wolfspraul> it's an app list
<wolfspraul> there is no concept of unstable/testing/stable here
<wpwrak> but that reference list should be reliable, no ?
<wolfspraul> if a kernel module doesn't compile, people will just disable it and build the rest
<wolfspraul> there are many kernel modules :-)
<wolfspraul> unless that is a truly essential one that won't even boot the system
<wpwrak> i mean, if i just want to build the whole stuff, i don't really want to have to debug the thing too
<wolfspraul> people deal with this config file the same way
<wolfspraul> of course if uclibc doesn't build, the image build cannot proceed
<wolfspraul> but if yacas doesn't built, it's just set to 'N' for this time
<wolfspraul> what is 'whole stuff'?
<wpwrak> sure, people can work around this. but why is it a benefit if they have to ?
<wpwrak> well, build the "standard system"
<wolfspraul> we may need different config files
<wolfspraul> ok, I described the xbboot system to you
<wolfspraul> :-)
<wolfspraul> that one is easy
<wolfspraul> the smaller the better
<wolfspraul> rescue tools
<wolfspraul> then we need a factory image
<wpwrak> xboot config may not change all that often anyway
<wolfspraul> that one should include all meaningful ben nanonote apps
<wpwrak> yup, that one
<wolfspraul> don't you see that if you don't commit first, and then remove apps that don't build, the config file will simply never get updated?
<wolfspraul> because, big surprise, it will always work, nothing will ever break
<wolfspraul> only that all apps are missing :-)
<wpwrak> what's wrong with updating it after testing ?
<wolfspraul> how do you want to break out of this circle?
<wolfspraul> yes, but people work on apps one by one
<wolfspraul> the problem is that they never get turned on in the config file
<wpwrak> make a "testing" variant and a "tested" variant
<wpwrak> those who just want a build take the tested variant. those who don't mind debugging the latest config take the untested one. xiangfu seems to do the full build regularly anyway, so there is a process for pushing the untested to the tested version.
<wpwrak> are you saying that people working on apps don't cross-compile them themselves with "make" but use openwrt as their IDE ?
<wpwrak> please, not that insanity again :)
<wolfspraul> I think this idea will successfully reduce the commits into both variants, because now people will be unsure which one to commit to.
<wolfspraul> the config file is just an app list
<wpwrak> a makefile is also a list of object files :)
<wolfspraul> whenever someone works on an app, and gets that app to work, the last step is to enable the app in the config file
<wolfspraul> when someone builds an image later, and out of 20 apps 17 build, and 3 break, then those 3 need to be removed (set to 'N') at that point.
<wpwrak> and it doesn't matter what the config file is. the issue is that it can break.
<wpwrak> so you say there's no build process that can be trusted to work, and that's even intentional ?
<wolfspraul> the other way round. when someone completes work on an app, they know it builds. why would they not set the app to 'Y' in the app list now?
<wolfspraul> because they don't trust the build process in general?
<qi-bot> [commit] Xiangfu Liu: [poke] remove BROKEN, update to r5975 http://qi-hw.com/p/openwrt-packages/807277d
<wolfspraul> and even though it works on their own system now, they just keep it disabled?
<wpwrak> the use scenario i have in mind is someone who just wants to have a reasonably up to date system
<wpwrak> they probably disable the rest locally to get a faster build
<wolfspraul> wpwrak: ok good, which use case do you have in mind?
<wolfspraul> someone wants to make a new image, why?
<wolfspraul> I have two in mind right now, xbboot and factory default.
<wpwrak> to get new things. features and fixes. update the system from time to time.
<wolfspraul> why wouldn't they just reflash from the published images?
<wolfspraul> (actually I hope we can move to upgrades via packages, but that's another story...)
<wolfspraul> we are talking about a config file here that defines which apps are included when that config file is used
<wolfspraul> an app list
<wolfspraul> we can have multiple app lists
<wpwrak> (from images) well, there's admittedly that option. makes them quite blind, though.
<wolfspraul> yes sure, so they want to compile from source
<wolfspraul> but why?
<wolfspraul> if they want to compile the exact same image they had on their device, they can check /etc/VERSION and get the matching config file which is always kept right next to the image file anyway
<wolfspraul> totally outside the revision control system
<wpwrak> source build is also so far the only way to get a toolchain
<wolfspraul> so we are not talking about that case
<wolfspraul> true, we need to look into that (toolchain), but what does that have to do with the config file?
<wpwrak> (matching config file) ah, okay. so there _is_ a place for the "tested" config
<wolfspraul> it's not a default config file, it's just a config file at a place in the tree where it needs to be (can be) manually taken from
<wolfspraul> yes
<wpwrak> (toolchain) the config file is still necessary for the openwrt build, no ?
<wpwrak> at least that's how i understood the build process
<wolfspraul> yes it selects the target too
<wolfspraul> one sec look here
<wolfspraul> that's a released image
<wolfspraul> the config file that was used to create this image is right there with it, together with all other things that hopefully make it possible to recreate this exact image
<wpwrak> alright. that one has a config. good :)
<wolfspraul> (although I have never tried and I thnk it's hard with all the many versions updates everywhere)
<wolfspraul> so in a way, that's the 'tested' config you talked about before
<wolfspraul> you are right, thinking about toolchain
<wolfspraul> but it's painful that someone has to build all factory default apps only to get the toolchain
<wpwrak> okay, looks good then
<wpwrak> (toolchain) indeed
<wolfspraul> we could have a config file config.base
<wolfspraul> or config.toolchain
<wpwrak> and even worse if they have to fix any config glitches :)
<wolfspraul> of course, total nonsense
<wpwrak> how about making a toolchain tarball, like we had at openmoko ? i think that one worked rather nicely
<wolfspraul> but I am talking about the app list in the factory images, and our very painful process of ever getting that app list to grow to include all useful apps
<wolfspraul> which at the current speed will not happen for decades :-)
<wpwrak> (app list) is it really that bad ? isn't it just those ~10 hours it takes xiangfu to build the image ?
<wolfspraul> yes but we are committing config file updates too slowly (this is how this discussion started)
<wolfspraul> I think apps must be enabled in the config file at the same time the (working) app Makefile is commited
<wolfspraul> otherwise why work on the app? and who will later remember to enable that app?
<wolfspraul> it can't work, already proven for x months now
<wolfspraul> xiangfu actually has a quite powerful machine, if it's only 10 hr for the whole thing that's quite good
<wolfspraul> so what's the solution now? we have realized that there are in fact 'stable/tested' config files, together with the released images
<wpwrak> (who gets to enable the app) ok, i see what you mean.
<wolfspraul> we may rename that 'config' file to 'config.factory_default'?
<wolfspraul> and change the commit policy into that config file to 'first set to Y when app is committed, then remove when it breaks'?
<wolfspraul> create another config file for a base/empty system, maybe for people who only want the toolchain?
<wpwrak> and the build instructions have a "stable" config, correct ? (http://en.qi-hardware.com/wiki/Building_Software_Image)
<wolfspraul> (there may be better ways to do this in OpenWrt, have to check)
<Ornotermes> i have added CC BY-SA for all my nanonote related pictures now: http://gallery.slashhome.se/main.php?g2_itemId=2616 and http://gallery.slashhome.se/main.php?g2_itemId=2856
<wolfspraul> wpwrak: yes it points to the stable/tested one
<wolfspraul> which is correct
<wolfspraul> Ornotermes: nice. your pictures are great, I really like them.
<wpwrak> wolfspraul: okay, perfect then
<Ornotermes> wolfspraul: thanks! :)
<wpwrak> so the config in git is really meant to be "unstable at all times", but we have a nice and tested one as well.
<wolfspraul> you can see it like that
<wolfspraul> I think we should rename it to config.factory_default
<wpwrak> i was missing that last point. that works then. thanks for explaining :)
<wolfspraul> ah thanks for pointing out the loose ends
<wolfspraul> and encourage people to enable their apps in config.factory_default if they think it should be included in every NanoNote
<wpwrak> hmm, "factory default" sounds a bit like "fall back to minimum", which isn't the case here
<wolfspraul> ok then what?
<wolfspraul> config.factory_full
<wolfspraul> :-)
<wpwrak> full_system ? just full ?
<wpwrak> "factory" may also scare people
<wolfspraul> true, I thought about that too. so config.full_system ?
<wpwrak> sounds good to me
<wolfspraul> alright, great
<wolfspraul> let me see what the easiest way is to build just the toolchain
<wolfspraul> (we can still offer a binary toolchain, that's separate)
<wpwrak> you don't like the tarball idea ?
<wolfspraul> there are 2 options in OpenWrt
<wpwrak> ah. you anticipated the question :)
<wolfspraul> "Build the OpenWrt SDK"
<wolfspraul> "Build the OpenWrt based Toolchain"
<wolfspraul> ironically, both seem to be OFF in our config files :-)
<wolfspraul> maybe the toolchain is automatically built as a dependency? or the "OpenWrt based Toolchain" is something else?
<wolfspraul> need to find out...
<wpwrak> sounds interesting :) the toolchain is built and stays around with the "standard" build, so that works
<wolfspraul> which standard build?
<wolfspraul> I just built the SDK, it created a 25 MB .tar.bz2 file
<wolfspraul> hmm, the SDK just seems to be a tarball of part of the OpenWrt tree. I am wondering whether it is not even better to tarball the entire OpenWrt tree then, including everything downloaded and pre-built as in the full_system image?
<wolfspraul> that will be bigger in MB, but maybe a faster starting point?
<wolfspraul> we are really talking about speed to get started with the various options. build everything from source, toolchain. Or download a tarball with toolchain binaries, and maybe also full_system sources and binaries all included?
<wolfspraul> that's a couple hundred MB download probably
<wolfspraul> or direct people to always start with git, then compile everything from source?
<wolfspraul> personally I'm not a big fan of pre-built binaries (although I run Debian, not Gentoo)
<wolfspraul> wpwrak: what do you think? what should we offer?
<Ornotermes> if you are going to make big files, use bittorrent as an alternative download source
<wolfspraul> if I select that second option 'OpenWrt based Toolchain', it gives me a 15 MB tarball containing just the toolchain I think
<kristianpaul> done duilding date command fail :p
<kristianpaul> Btw i noticed NanoMap is working now, i'll try test it with my non.free gps later
<kyak> well i noticed quite the opposite, that NanoMap is no longer working :)
<kristianpaul> ah?
<kristianpaul> i dint test it in the last-lastest image from xiangu
<kristianpaul> but the lsat that the flash script isntal me had nanomap, i jut said wow !
<GNUtoo|laptop> kristianpaul, seem interesting....does nanomap works with Xorg?
<kristianpaul> GNUtoo|laptop: nope fb as i now
<GNUtoo|laptop> ok
<kristianpaul> as openwrt dont work with fb and X and same time
<kyak> well, it can work in X. too
<kyak> if we had X
<GNUtoo|laptop> nice
<GNUtoo|laptop> ok
<kyak> at least it works on my laptop just fine
<GNUtoo|laptop> nice
<wolfspraul> well my feeling is that the OpenWrt SDK is a better starting point for people who want to port an app, and not start with the entire openwrt tree and build from scratch
<wolfspraul> better than the plain 'OpenWrt Toolchain' which is missing libraries, if I see this right
<wolfspraul> so maybe we should publish this .tar.bz2 SDK tarball along with the images?
<qi-bot> [commit] Xiangfu Liu: rename the config to config.full_system http://qi-hw.com/p/openwrt-xburst/49ac818
<wpwrak> wolfspraul: toolchain plus the essential libraries sounds good, yes
<wolfspraul> I think we will publish both first, then ask what people like, then remove what they don't want
<wpwrak> wolfspraul: the definiion of "essential" can differ, of course :)
<wolfspraul> I want to publish as few options as possible, because the problem is that the quality of documentation may matter more than what binaries are available for download somewhere
<wolfspraul> if the documentation quality is junk, people will get lost in all the lousy documented options
<wolfspraul> so rather have fewer options that are better documented and linked to
<wolfspraul> but let's start with both, then remove one after a few weeks
<wpwrak> yes, people who want to get started will prefer not to have to have too many choices
<wpwrak> Ornotermes: power to the board now seems to work, but when switching it on, there seems to be enough inrush current to crash the ben :-(
<wpwrak> Ornotermes: and there's an interaction with the kernel driver, too: when it detects the card, it tries to power it up, which then of course also kills the system
<wpwrak> Ornotermes: i don't think 33 mA or so should really be a problem. let's see what's really going on there ...
<Ornotermes> wpwrak: how mych can the voltage regulator supply?
<kristianpaul> what is included in a openwrt SDK?
<wolfspraul> there is a total of three options 1) toolchain 2) sdk 3) image builder
<wolfspraul> I think basically they include more and more of the entire tree
<wolfspraul> toolchain is just the cross-compiler
<wolfspraul> I think you can only compare simple binaries with that
<wolfspraul> 'sdk' includes a lot more, libraries from the device rootfs, package making tools?
<wolfspraul> image builder contains even more, I think basically all binaries that appear in the image, so you can make a modified image without rebuilding anything that was already in the image before
<wolfspraul> I think we will just publish all three options, and then find out what people use, and remove the unused ones
<wolfspraul> you can always do the 'gentoo style' and get the source tree from git, and build it all from scratch
<wolfspraul> just takes a bit longer, couple hours maybe 1 day, depending on your machine
<wolfspraul> this is my understanding right now, if I'm wrong please let me know
<kristianpaul> yeah also i must be skilled in openwrt packaging wich is not so hard but takes time
<kristianpaul> s/I/you
<kristianpaul> hope thereare package makign tools in that :)
<qi-bot> [commit] Xiangfu Liu: select ImageBuilder, Toolchain, SDK http://qi-hw.com/p/openwrt-xburst/4c4035c
<qi-bot> [commit] Xiangfu Liu: enable the IPV6 option http://qi-hw.com/p/openwrt-xburst/1566c3b
<qi-bot> [commit] Xiangfu Liu: include [sox] and [poke] http://qi-hw.com/p/openwrt-xburst/19ee485
<qi-bot> [commit] Xiangfu Liu: switch uClibc 0.9.30 to 0.9.32 http://qi-hw.com/p/openwrt-xburst/2af4183
<qi-bot> [commit] Xiangfu Liu: include qt4-* package http://qi-hw.com/p/openwrt-xburst/b9f0c00
<kristianpaul> sox good :)
<kristianpaul> This is getting better every day :)
<bartbes> ipv6
<bartbes> that is what I'm liking
<bartbes> btw, about pke
<bartbes> *poke
<bartbes> I imagine it's like the c64 poke
<bartbes> but.. are there any fixed mem addresses?
<kristianpaul> wolfspraul: one missing SDK is i think a easy (not bloated) way of UI design for some usefull software like sox that lacks one
<kristianpaul> i guess others are in the same state
<kristianpaul> there is SDL toolkit or SDK? :)
<wolfspraul> we just have to make sure that sox doesn't drag in patented codecs
<wolfspraul> it was in a while ago, then we kicked it out, so let's see now...
<kristianpaul> good point (as always)
<kristianpaul> i never used
<bartbes> got ignored
<kristianpaul> bartbes: no no :)
<kristianpaul> bartbes: wpwrak will read the log eventually :)
<bartbes> right..
<wolfspraul> the sox Makefile looks good. looks like we removed libmad, lame, etc. when the non-patented flag is on
<kristianpaul> QT have a IDE, not sure how bloated is..
<wolfspraul> does anybody know why we don't include ffmpeg in the openwrt images?
<bartbes> kristianpaul: QtCreator.. well, it's pretty heavy, but it's nice
<kristianpaul> bartbes: i dont care is heavy at the time of design, i care most about the final result
<Ornotermes> wolfspraul: might be something like patents maybe?
<kristianpaul> bartbes: what's your experience with it?
<bartbes> I am not sure how the ide would change that
<bartbes> if the code is the same, why would the ide matter?
<kristianpaul> wolfspraul: probaly as i use it at home to convert some patented format to free ones.
<kristianpaul> bartbes: ahh no matter then :)
<wpwrak> Ornotermes: 600 mA, if the source (USB or battery) provides that
<Ornotermes> wpwrak: try to switch off the screen and see if it powers down then too
<wpwrak> bartbes: you need jz4740_pm.pdf for the addresses
<wpwrak> bartbes: (of the cpu register, that is)
<bartbes> ehm
<bartbes> and how do I obtain that?
<wolfspraul> Ornotermes: yes but we can configure all patented codecs out of it, that still leaves valuable functionality I would think
<bartbes> and what can I do with them?>
<wolfspraul> bartbes: I will email it to you (if you want)
<tuxbrain2> mmm ffmpeg without mpeg :P
<wpwrak> Ornotermes: i'm running just the bare board, no screen attached
<tuxbrain2> coffe without caffein
<Ornotermes> wolfspraul: then i think that should be another package name, like ffmepg-free so user can install the real deal without problems
<Ornotermes> wpwrak: ah, then it's harder :P
<kristianpaul> tuxbrain2: use it to convert ogv to ogv for jlime for example :)
<kristianpaul> i dint tried yet jsut saying :)
<Ornotermes> wpwrak: what happens if you connect the load between main +V3.3 and VSS?
<wpwrak> Ornotermes: haven't tried that yet. right now i'm looking at the dynamic behaviour.
<wpwrak> i'm optimistic - don't want to do tests that could only prove that it's impossible ;-)
<tuxbrain2> convert video inside nano itself? well in case of emergency maybe but better do it on the host pc, isn't it?
<kristianpaul> tuxbrain2: ahh yes sorry inside nano no
<Ornotermes> wpwrak: what kind of power does it use without any extra loads?
<wpwrak> tuxbrain2: must be a very slow emergency ;-)
<kristianpaul> tuxbrain2: yeah performance is other issue with
<bartbes> wpwrak: hehe
<wpwrak> Ornotermes: dunno. my USB current probe cable doesn't work with the Ben :-(
<Ornotermes> :/
<kristianpaul> thats sounds crazier that coffe without coffe, so now make sense this
<Ornotermes> i guess you don't want to carve the trace of the VDD either? :P
<tuxbrain2> I have convert some videos to jlime using mencoder
<kristianpaul> tuxbrain2: ogv?
<tuxbrain2> no ogv no way for now
<kristianpaul> yeah :(
<tuxbrain2> unable to reproduce even in the most low and small resolution
<tuxbrain2> rafa has some hope on a demo ogv player included in theora libraries, it works but must be developed to include some kinkd of playcontrol
<wpwrak> Ornotermes: oh, there is a TP with VDD on the board. but one thing at a time :)
<bartbes> urandom__: now I'm playing snake all day.. :@
<kristianpaul> any one know agood logic siffer sofware client that DO NOT REQUIRE JAVA :(
<kristianpaul> i cant make this sump work, and i installed rxtx already
<urandom__> bartbes you better work at font rendering for nlove :P
<kristianpaul> hmm may be i can plug gnuplot to the seria port
<bartbes> :(
<urandom__> ;)
<kristianpaul> GNUtoo|laptop: your gnuplot in the bug reads a file or the port directly?
<GNUtoo|laptop> kristianpaul, hi
<GNUtoo|laptop> gnuplot didn't run on the bug
<GNUtoo|laptop> basically I did it that way
<urandom__> but yeah snake is the kind of game that never gets boring
<GNUtoo|laptop> bug->serial->eeepc->gnuplot on eeepc
<GNUtoo|laptop> that's because poky for bug was really outdated
<GNUtoo|laptop> I didn't want to port gnuplot on it
<GNUtoo|laptop> but with bug 2.0 this problem will be solved
<GNUtoo|laptop> or I could backport bug 2.0 software to bug 1.x
<kristianpaul> GNUtoo|laptop: can you sahre pulbi the bug->serial->eeepc->gnuplot code somwhere?
<kristianpaul> pulbi/public
<GNUtoo|laptop> it's public
<GNUtoo|laptop> it's on the wiki
<GNUtoo|laptop> it's the python code
<kristianpaul> ah ok
<GNUtoo|laptop> basically the gnuplot bindings were too slow
<GNUtoo|laptop> that's why I used that
<kristianpaul> bug wiki i guess?
<GNUtoo|laptop> yes
<GNUtoo|laptop> also the app is published in the app part of buglabs wiki
<GNUtoo|laptop> but it's written in java
<kristianpaul> ah?
<GNUtoo|laptop> but you can see the sources
<kristianpaul> rxtx?
<GNUtoo|laptop> yes
<kristianpaul> noo]
<kristianpaul> :{
<GNUtoo|laptop> it uses that
<GNUtoo|laptop> simply re-do it in python
<kristianpaul> i think i will need it faster
<kristianpaul> and learn
<kristianpaul> ok
<urandom__> oh and bartbes in case you didnt notice: press p to pause ;)
<bartbes> I did not..
<bartbes> facepalms
<urandom__> lol
<urandom__> are you using wasd or arrow keys to move it?
<GNUtoo|laptop> kristianpaul, the wifi cafee closes soon
<bartbes> arrows
<GNUtoo|laptop> kristianpaul, what do you want to do exactly?
<GNUtoo|laptop> you've a got an von-hippel module without the bug device?
<GNUtoo|laptop> if so I wrote a howto that permit you to write code faster than when trying to read the full specs
<GNUtoo|laptop> it's not so java-specifc
<bartbes> urandom__: 2 things about snake
<bartbes> 1 it should keep record of the longest length you had, not the last
<bartbes> 2 don't spawn 'apples' *in* the snake
<urandom__> 1 the love version of snake has an highscore and all, i just wait for font rendering
<urandom__> i used to have an snake game where is spawned apples in the snake, not sure how ist was in the original one
<urandom__> now time for some rl
<wpwrak> tuxbrain2: thanks for the address !
<tuxbrain2> wpwrak: I'm searching for alternative to ups, I will keep you informed
<wpwrak> tuxbrain2: ah, okay. if all else fails, we can still use EMS. they're not very expensive.
<tuxbrain2> I got a revelation now than wolfgang is not arround.... NanoNotes series must evolve to have touchscreen
<wpwrak> tuxbrain2: how did you realize that ? :)
<tuxbrain2> I have created a pdf with history of the band for Nanowar edition, and I have in the screen the picture of the four albums , .... so I have start to thinking if this instead of a pdf was and html... and I found my self touching the pics to know more about... I we want than NanoNote series to become a handy information repo, so then Mister Obvious apears and tells to me we must mantain the keyboard for the searches and include a touch screen to navi
<tuxbrain2> gate
<tuxbrain2> I we want-> If we want
<wpwrak> hehe ;-) good reasoning. i agree that we need something better than just keys.
<wpwrak> not sure if a touch screen would be very difficult to get, though
<wpwrak> a plan B could be to have a sensor array on the right side of the display. that way, one could display soft buttons there.
<wpwrak> but yes, a touch screen would be nice to have
<tuxbrain2> It should not be a hires capacitive , a cheap resistive one should fit
<wpwrak> and get rid of the function keys :)
<wpwrak> sure. the simpler, the better :)
<tuxbrain2> ok , end of futuribles , lets continue pinping jlime
<wpwrak> hehe :)
<tuxbrain2> btw, Hexen, heretic & Doom,  works like a charm :)
<roh> tuxbrain2 what are you trying to do? (low-res R-touch)
<zear> tuxbrain2, dingux versions? or someone ported them to the nanonote?
<tuxbrain2> well the ones rafa puts on http://fz.hobby-site.org/hp660lx/nn/games/
<zear> looks like his own ports ;)
<zear> btw, i've seen with him in person for the last 4 days ;)
<zear> a great guy
<tuxbrain2> He is a fantastic guy
<tuxbrain2> yea
<zear> donated him my old dingoo :)
<tuxbrain2> he loses on NN on the trip :(
<tuxbrain2> one
<zear> i know :(
<SiENcE> hey
<SiENcE> zear, i tried the qi gmenu2x version and i have problems adding icons
<tuxbrain2> desire a lot bad Nand blocks to the ripper
<SiENcE> some appear ...some not
<SiENcE> is this a known issue?
<zear> SiENcE, yes, same happens for me
<zear> for a weird reason only supertux and bubble dizzy icons work with qi version
<zear> i reported this bug to mth, so i believe it's a known issue
<SiENcE> yeah...soem work some not
<mth> I don't have a good memory; if you want to be sure a bug report is remembered, please put it in the bug tracker
<tuxbrain2> roh : I was not trying to do anything, just an obvious revelation than I want to share by chat... a kind of procrastination to avoid some work a have done before (so boring)
<tuxbrain2> once finished , the next funny thing will be to reproduce the "knight rider" BNN , the 3V3 blue leds have arrived today :)
<mth> SiENcE: can you find anything pattern among the PNGs regarding image dimensions and true color vs indexed?
<mth> what happens with icons that are not displayed correctly? do they display incorrectly, do they not display at all or are they replaced by the default gear icon?
<wpwrak> tuxbrain2: ah, there's an idea :)
<tuxbrain2> wpwrak: what idea
<tuxbrain2> ?
<wpwrak> tuxbrain2: to use blue LEDs
<Ornotermes> blue leds is over rated :P
<bartbes> urandom__: guess what just successfully ran?
<qi-bot> [commit] bartbes: New version of nlove (0.0.2) http://qi-hw.com/p/openwrt-packages/ef090fa
<tuxbrain2> Ornotermes: not more than rgb ones :P
<Ornotermes> tuxbrain2: fading lights is kind of pretty, but just blie is kind of hard on the eyes
<Ornotermes> i have a kind of green leds i really like
<Ornotermes> i think they are based on phosporecense (in the same way white leds does)
<bartbes> ehm
<bartbes> how do I quit mc?
<bartbes> :P
<tuxbrain2> I didn't kwow there were such passion on led colours :)
<bartbes> seriously
<bartbes> how do I do f12?
<bartbes> :O
<tuxbrain2> I just bought the blues due it where the cheaper 3v3 option :P
<tuxbrain2> must leave c u later
<bartbes> :(
<bartbes> I killed it
<bartbes> left my tty broken though
<bartbes> btw, what packages are built on qi-hardware?
<bartbes> that was very informative
<bartbes> I see 2 spaces?
<bartbes> 1 actuall
<bartbes> y
<GNUtoo|laptop> kristianpaul, what was your project with my bug stuff?
<GNUtoo|laptop> (the more details you know the better you can help)
<kristianpaul> GNUtoo|laptop:  i need to do some logic analizer basic program with the nanonote
<GNUtoo|laptop> ok
<GNUtoo|laptop> so you don't need my java part right?
<GNUtoo|laptop> just the python part
<kristianpaul> nope just python right
<kristianpaul> or whatever it draw mea  pulso on screen
<kristianpaul> pulse*
<kristianpaul> if is not done i will do anyway
<GNUtoo|laptop> ok
<kristianpaul> why the last xburst-tool is asking me for mipsel-openwrt-linux-gcc ?
<kristianpaul> damm i cant compile the whole openwrt-xburst, will take ages on my mipsel latop..
<kristianpaul> noooo
<kristianpaul> i must
<kristianpaul> that will hurt
<kristianpaul> but why??
<GNUtoo|laptop> kristianpaul, mipsel laptop,nice
<GNUtoo|laptop> I bet the same than stallman?
<bartbes> is it binary compatible too?
<qi-bot> [commit] kyak: stardict actually depends on gtk2 http://qi-hw.com/p/openwrt-packages/dbd4afd
<qi-bot> [commit] kyak: Merge branch 'master' of projects.qi-hardware.com:openwrt-packages http://qi-hw.com/p/openwrt-packages/4ee7a75
<Textmode> morning all
<Textmode> I'm still getting errors with opkg on jlime.
<Textmode> "*** glibc detected *** pkg: double free or corruption (out): 0x00419368 *** Aborted"
<rafa> Textmode: do you have swap?
<Textmode> rafa: if I'm reading this right, a bit under 2gb of swap.
<Textmode> (overhead, i guess)
<rafa> Textmode: have you installed beta3? have you read the changelog and announce of beta3?
<Textmode> nope.
<rafa> Textmode: so you run free and swap says?
<Textmode> since I've never heard of beta3
<rafa> 1.XGB?
<rafa> Textmode: ah.. you have an old version of jlime
<Textmode> probably.
<Textmode> still though, should it really be out-right dying?
<rafa> Textmode: how do you follow the news about soft? just curious
<Textmode> about what?
<rafa> we announced on jlime mailing list and qi mailing list
<rafa> the beta3
<rafa> Textmode: with swap on you should not get that problem
<rafa> maybe something more .. if you want we can help you.. Please report the problem with specific details about your system, either jlime forums or jlime ml
<Textmode> I'll propbably just upgrade.
<Textmode> or try something else (no offence, ofcause. but I might as well try all thats out there)
<rafa> Textmode: it seems that debian is working really cool now. I read somethin on ml today
<Textmode> Been meaning to look at NN-debian, good -a next stop as any.
<rafa> Textmode: you should instll latest versions of different linux OS for nn and tell us which one you like more ;)
<Textmode> hehe
<Textmode> not sure my bandwidth is up to doing that fast enough to make it current.
<tuxbrain> lakernel -> pachy? :) a very common name in vasque territory :)
<Textmode> feep.
<tuxbrain> there is a said here that: A vasque can born wherever it want :), it still a vasque
<tuxbrain> it ->he
<Textmode> Its going to be one of those days, I can tell.
<kristianpaul> GNUtoo|laptop: dont now if same
<kristianpaul> now/know
<GNUtoo|laptop> kristianpaul, hi
<kristianpaul> hey
<kristianpaul> but i wish i could compile things faster
<kristianpaul> but seems cross compile is even faster
<kristianpaul> not sure
<GNUtoo|laptop> ok
<kristianpaul> i meant cross compile for mipsel
<kristianpaul> may me Xbusrt SoC can achive more speed in the coming years
<kristianpaul> me/be
<GNUtoo|laptop> ah ok
<kristianpaul> GNUtoo|laptop: if i could i will replace my AMD for a dual cored fast mipsel but i need it for binary compatible with Xilinx devel tools
<kristianpaul> :(
<GNUtoo|laptop> ok
<GNUtoo|laptop> what about sparc cpu?
<kristianpaul> cool
<GNUtoo|laptop> not compatible either with that proprietary stuff I bet
<kristianpaul> is just a bit non-free but means a lot for next years of copyleft hardware
<kristianpaul> may be evetually fpga will got free sintesis sofware
<GNUtoo|laptop> yes I know
<GNUtoo|laptop> altough if I ever use that I would need another computer only for it or something like that
<GNUtoo|laptop> and that's not great
<pachy> kristianpaul, heh, why don't you start writing it? it will not happen by itself...
<kristianpaul> pachy: i dont hav e the knowledge for that yet, i think you have more exprience than me on the field
<kristianpaul> shut mouth about free sistensis tool topic
<kristianpaul> pachy: not saying you should do it, but other people think same
<kristianpaul> i know you just focused on MM
<kristianpaul> :)
<Textmode> In my attempts to get the Nano's networking to work with my computer, I seem to have transformed it into some kinda of etherbane, the simple act of hooking up the nanonote now renders the machine unable to properly comprehend the task of using any form of networking.
<wpwrak> grmbl. weirdness rules. now even my usb-based ieee 802.15.4 devices have joined the uSD-based one in its strike :-(
<Elvashi> is anyone awake in here?
<mth> yes, but you might need a better question to get them to respond ;)
<Textmode> does anyone happen to know the dimentions of the default NN term? its definitely not the standard 80x25
<qi-bot> [commit] Carlos Camargo: Adding LUA tutorials: lua_calls_C1 - lua_calls_C5 http://qi-hw.com/p/nn-usb-fpga/7d9b7b8
<qi-bot> [commit] Carlos Camargo: Removing jz_test_gpio.c file from lua examples. http://qi-hw.com/p/nn-usb-fpga/5a6f0b5
<qi-bot> [commit] Carlos Camargo: Enabling Set port and pin in blinker example http://qi-hw.com/p/nn-usb-fpga/91fdaa2
<kristianpaul> xiangfu: bad luck i dont know why the image i built dint come with gmenu2x
<kristianpaul> and i guess more stuff
<qi-bot> [commit] Carlos Camargo: Some changes to lua's blink demo http://qi-hw.com/p/nn-usb-fpga/d01e4f4
<qi-bot> [commit] Juan64Bits: Routing attiny. http://qi-hw.com/p/xue/1e22c59
<wpwrak> hehe, i see another blinkenlight come along :)
<wolfspraul> wpwrak: how did the power issues end up?
<wpwrak> wolfspraul: i think uSD power has some inrush current issues. i haven't measured the effect on the 3.3V supply directly yet, but all circumstancial evidence points to it operating just about at the limit
<wpwrak> wolfspraul: good enough for uSD cards, which should be almost no capacitative load, but probably lethal for most SDIO or breakout board type applications