<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>
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?
<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>
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?
<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?
<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 :)
<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?
<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?
<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
<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