wpwrak: about NN Nanowar edition , Only 3 selled but we have created some noise out of the techy sphere, a see a little more activity in normal NN after launch not espectacular but people start perciving NN as something more than a portatile console.

only one "fn" modifier (no arrow), no function keys, wide space bar, large enter. ideally, it would work on top of the existing domes. but i'm not sure a wide button straddling two domes works. maybe i need three. or maybe it simply doesn't work with > 1 domes.

third though, why don't sell them lets say at 3¬ instead of gift it? this may sound unpopular but also every one knows how our margins are so any extra income will benefit, and also give to NN a starting universe of complement for it

I will not not blame nor moan, we should be consequent so if you don't sell separatly I will do not, is enoght to listen the 99$=99¬ blaming time to time to add in addition hey in sharims the offer the pouch for free! you steeler

(driver reuse on SIE) would be very unlikely. these drivers generally don't do much beyond talking to the ADC or touch screen subsystem (some implement the whole X/Y measurement process, so there's no need to do this explicitly step by step)

I will talk to carlos to know what he thought about and to know what's the status of the project, at first sight the definition of the project at the wiki page seems quite complete but as wolfi will said is just paper

Photos: Please feel free to use our product photos in your project documentation or reports. If you would like to use a photo for a commercial venture, please contact us first at marketing@sparkfun.com

for each task, find a lot of really cheap ones and a few expensive but good ones. add a fat margin to the cheap ones (they'll still be cheap). then let the customer pick. advise them that you've only worked with the expensive ones before and that you'd recommend them.

if one of the cheap orders my some miracle turns out right, slap an even fatter margin on that one (your finder's fee) for the next customers and thus create a middle price segment. you can only win ;-)

wpwrak: about fped in qi/openmoko - the only thing Xiangfu is doing on the qi side right now is to do everything necessary to make it a clean Debian package and get it into Debian itself. that may include source code modifications but most likely won't. definitely no feature work.

it's not an urgent decision to make yet, given how fast (slow) things move at Debian, but at some point it would be good if you could decide what you want to do with this Debian packaging stuff, and where to move it

wolfspraul: several months ago there was some news at qi about "soon jlime also will have a version for nn".. and it finally appeared, so jlime will have a version free of patent problems soon ;) .. at least as kristoffer and me agreed, from your talks about patents which were a good thing

kristianpaul: :) no yet, because we are discussing our own way into jlime projetc yet.. but we can do something in the future. At least it will be possible to have some jlime versions on qi or resellers servers.

kristianpaul: there is a build server in jlime, which I do not use much, but I should. Anyway, we always report the changes in every version writting a changelog, and we try to send that news on every tool we use (ml, forums, wiki), so you know what we did. If you would like to know which new packages will appear, etc.. then you would like to follow the OE news which we use. For the rootfs image you can suggest whatever you want using any tool (bugtracker,

wolfspraul: (fped) what does the debian packaging work actually need from upstream ? do i actually have to see that at all ? (such things are usually transparent. given that the package building isn't something that i maintain anyway and that may be driven by external constraints/schedules, that's probably more natural anyway)

kristianpaul: every dev collaborating use his/her own svn/git whatever.. we already have a jlime development server but it is for devs so far and we do not use it much. What I do not understand is which things your want to have on git/cvs/whatever.. If you mean for the rootfs imagem which is a simple image made for OE plus extra packages, I do not see what things to track there.

wolfspraul: (fped) it's not very common to host packaging metadata in the source projects. i've done it a few times, but since i'm not the one pushing those packages anyway, it just means that this data becomes stale and packers just follow their own workflow, which means there's the metadata in their distro's repository, whichever form it takes

wpwrak: no recipes yet.. it is not something like : I know what I am doing to have the final image. It is just a work in progress.. I needed to write several tools from scratch for that tiny screen. But, tomorrow, I could say.. nahh.. i do not want how it looks, I will start a new one to compare.

rafa: he is ok, sleepless as I am, and doing web changes, incharge of accounting of tuxbrain, his other job, pursuing me to deliver administrative things on time, and rising me up when I'm down, all with a smile in his face, he let me the inet public relations

wolfspraul: yes. i think the current structure should pre pretty much the normal case for packaging. i.e., upstream doesn't know/care about who is using it. package maintainers keep track of upstream. otherwise, you get a cyclic dependency graph ;-)

wpwrak: I mean, we are not using the OE to build the final rootfs image, just for the minimal one which is already into OE. For the tiny tools we will see which ones are the best to include into OE. So you can see that we use, currently, OE to build the feed of packages and the minimal rootfs, no as a tool to develop the minimal rootfs. We would like, but we prefer to wait a bit to understand which is the

rafa: understood. you only put "mature" things into OE upstream. hence the question what you are using. since some things will live a while in that intermediate state. (or may even get killed if it turns out they're not good)

wpwrak: combine.. if you follow the links in muffinman wiki page you will find all the stuff of it. If you want to know how it is combined.. then you just read one script of 30 lines maybe? which does the modifications to the rootfs image built by OE :)

kristianpaul: hwoever, i think that's something that should live entirely inside the jlime universe. no need to create dependencies at that level between qi-hw and jlime. in fact, such dependencies could become a problem if, say, rafa is testing some MP3 player and thus would have receipes and what not for that one

rafa: the "standard" way would be to have a project-wide revision control system into which such things are checked in. so when someone wants to build a rootfs, they just check that out and run the bitbake process.

wpwrak: I did not do any patches whatever into OE to build the rootfs. The rootfs is just the angstrom rootfs image recipe that I copied with the muffinman name and added there a bit more of package names.

wolfspraul: it's probably no surprise that KiCad has quite a number of deeply obscure huge functions. simple because what should be a local implementation detail becomes something that looks much bigger

yes, unfortunantly. Im doing a programming project on the side :) and been considering rewriting everything to C++, just to get it fancy objectified. I have a fantasy that it will be easier to expand then

Ive used C for 6-7 years or so now, and I really like it. What Im pondering is if its easier to keep a large code base in C++ rather than C. Or if its better just to spend my time writing more organized

Action: djbclark probably has email he need to reply to from wolfgang, like everyone else... the "put important things off until you can reply to them completly and thoughtfully" method isn't working out so well :-/

kristianpaul: so FSF/RMS still come at it from a very software-centric POV; they just don't want anything that the user would usually modify to be nonfree software. Unfortunatly this sometimes clashes with the realities of the hardware world, but I have high hopes that eventually we will get to a place that will satisfy everyone.

kristianpaul: Even more so than with Openmoko, I'm unaware of anything other than the GNU Distribution that would have prevented FSF from endorsing Ben Nanonote, and LibreWRT should fix that. However you should be aware that not everyone really wants or things FSF endorsement will be useful; thae prof or disproof will be if there is a sizable spike in sales after it happens or not :-)

bartbes: btw, i'm a bit puzzled about this love thingy of yours. i see that there are some very nice games that have been implemented with it, yet what people talk about here tends to be at the level of worms or pong. why the gap ? i.e., why isn't there a huge flood of existing sexy games that come to the ben with love ?

I first heard about löve on the Pandora boards. I remember there were concerns that some of its dependencies interfered with its portability (which is one of the otherwise unquestionably awesome things about Lua.)

mirko looked into the problem with owner and permission info for the data/files in openwrt not being copied into the rootfs, but he couldn't reproduce the problem and says owners and permissions are copied into the rootfs