<kyak>
it seems like a good chance to finally have utf-8 working
<wolfspraul>
kyak: if you plan to commit into openwrt-packages, you will become the next beta-tester of my latest script fixes :-)
<kyak>
wolfspraul: cool :)
<wolfspraul>
let's see who thinks it's cool after you're done :-)
<wolfspraul>
I'm always amazed by these scripts, calling each other, piping, expecting, what not...
<wolfspraul>
kyak: btw, proper utf-8 would be AWESOME!
<wolfspraul>
we need that for Chinese, Japanese, Russian, etc. etc.
<wolfspraul>
as you know :-)
<kyak>
and the question is always "hwo this even works??" :)
<kyak>
yes, utf-8 is very important
<wolfspraul>
the problem was that I hooked the irc commitlog into the git mailing list commitlog, and stdout and stderr got mixed up
<kyak>
international input would be great, too
<wolfspraul>
should be fixed now, and I tested it, but who knows
<kyak>
and then - localized versions of NN keyboard buttons :)
<kyak>
btw, there's 33 letters in Russian alphabet; not sure how it can be fit on Ben's keyboard ;0
<wolfspraul>
kyak: I'd love to do a russian version, but with ... let me see ... maybe 5 customers there (?) it's not really worth it yet :-)
<wolfspraul>
but we get there!
<kyak>
5 customers, it's huge :)
<wolfspraul>
was guessing
<wolfspraul>
maybe 2-10, don't know
<wolfspraul>
actually it's nice, I like to start small and with a strong base, then grow
<wolfspraul>
better have a strong root first, then a lot of fluff huff, big announcements, etc.
<wolfspraul>
s/then/than/
<wolfspraul>
Russian customs is nasty, I think the proper way to get more in is via import companies in Finnland
<wolfspraul>
until then will only be individual units to real pioneers
<kyak>
it is nasty; actually our company has it's own "man" in customs to avoid problems during import (we import from China). I believe every big company has it's "representative" at customs to help move things faster
<wolfspraul>
yes, and the commitlog mailing list works as well
<wolfspraul>
neat
<wolfspraul>
kyak: very important commit btw, thanks a lot!
<kyak>
wolfspraul: i did nothing, but thanks :)
<tuxbrain>
any one has news on the video playing on openwrt?
<tuxbrain>
I want to launch a Nanonote-Nanowar version with the content of the group including his last album and if posible include some videos clips
<viric_>
tuxbrain: is there any problem with video playing?
<tuxbrain>
viric_: I see it working with the jlime os but I have no new on openwrt, it's already working?
<wolfspraul>
what you see may only be mpeg4, I think ogg theora is too slow
<wolfspraul>
simd acceleration instructions are not being used etc.
<tuxbrain>
wolfspraul: this guys wants to launch his new album on september, do you think if I make a call for devels in the list we can have some boost on this matter?
<wolfspraul>
he
<wolfspraul>
sure
<wolfspraul>
we need more pain! :-)
<tuxbrain>
Meanwhile I will create a wikipage about it, preparing a costumized gmenu, and adding the songs and letters
<tuxbrain>
hehehe :)
<zear>
btw "Nanowar" is a great name coincidence ;)
<zear>
would be a great promo for the NanoNote :D
<tuxbrain>
yes , that why I so exicet by the idea
<tuxbrain>
and the band is also involved, they will sendme the songs before they edit the album, they have just remixed it
<zear>
oh, so they're already aware of your project? GREAT! :D
<tuxbrain>
Gatto (Eduardo) is also a great Free source adbocate
<zear>
any chance of them getting a nanonote so they can make photo session with it?
<tuxbrain>
sure :)
<zear>
btw, where can i get their songs? I was looking for them before, but found only one song - the one they have a videoclip of
<tuxbrain>
I have to print the stickers to "costumize" a little bit the case, I will put the mockups on the wiki page
<shevek>
Is anyone here with a Ben NanoNote with a serial port and a micro-sd card who is willing to test something for me?
<viric_>
larsc: what tag should I consider there the stablest? v2.6.34-rc7 ?
<shevek>
If so, please set your serial port to raw at 9600 baud (stty -F $SERIAL raw 9600) and listen to it (cat $SERIAL), untar http://downloads.qi-hardware.com/people/bas/20100802-iris-sd.tar.gz into the first partition of the sd card (which must be fat), and use it to boot from (by holding 'S' while powering the Ben up).  Then please tell me what you see on the serial port.
<larsc>
viric_: v2.6.35
<viric_>
larsc: it's a branch
<viric_>
fine?
<viric_>
larsc: it's jz-2.6.35 right?
<larsc>
viric_: yes, thats what i meant, sorry
<wpwrak>
rafa:Â Â so ... jlime, its slow uptake by the qi-hw community, the problems with debian, and why openwrt is obsolete :)
<viric_>
ok
<viric_>
thank you
<rafa>
wpwrak: what do you think about?
<wpwrak>
rafa: i must say that i find the idea of having yet another distro with yet another build system, such as jlime, isn't very appealing
<wpwrak>
rafa: on the other hand, you guys are doing a lot of work to make the thing run nicely on the ben, so there is valuable work there that shouldn't be lost
<rafa>
debian is the best choice if there were some lightweight package manager to use its repository. And If you could set to install just the binary of a package, or something like that. No the extra files useless to run the application. Also we would need some way to easily to build rootfs for Debian.
<wpwrak>
rafa: then there's debian, which apparently isn't used much in the qi-hw community either
<rafa>
repositories*
<wpwrak>
rafa: i guess building a rootfs shouldn't be all that hard. unless they dependencies are really evil, you should be able to just install what you really need, no ?
<wpwrak>
rafa: e.g., i made that myrootfs based on the ipkgs for openmoko that can be as small as you want. of course, those ipkgs aren't fat to begin with
<rafa>
I see the "another build system" like this: use it just once. Build the whole repository just once and then upload. For that I think that OE is great because you can build the whole thing and it will build a huge repository. I do not like the idea to rebuild again and again.
<wpwrak>
rafa: i think there are two approaches to get lean packages: 1) you break them down into the essential and the non-essential parts and (in the small device case) only install the essentials, and 2) install the monster but then throw away anything you don't like
<wpwrak>
(build system) yes, but you still have to maintain the distro. that requires manpower that could probably be applied more usefully. i mean, while it's fun and you're full of energy, why not. but after a while, it will become a burden.
<rafa>
For debian yes, we would need some easy way to build different rootfs to install. And a lighweight replacement for apt, which seems heavy for tiny devices, but at the same time, it should be the current debian repositories.
<wpwrak>
rafa: so when you start a new distro, you better have an exit strategy for yourself :) if there's only a small group of people, the chances of finding someone to take care of the unpleasant work decrease
<wpwrak>
rafa: (apt) yeah, i wonder what the issue there is. also, what's preventing opkg to process debian's packages ?
<wpwrak>
s/to process/from processing/
<rafa>
maintain the distro: just build the whole thing (repository) once a year. I have not seen many users complaining because they want always the latest version of busybox or dillo.
<wpwrak>
(maintain) i don't mean the build time. you can do that in a central package repository anyway. but the effort to maintain the packages.
<rafa>
Your option 1) "split the packages into the essential and the non-essential parts" is a lot easier than crosscompiling/porting the sources to build a full repository
<rafa>
because you have already the whole thing built. Just need to set which parts are essentials and which no
<wpwrak>
(split) true. the build system could even help you with the split, and warn you of things you haven't assigned to one of the sub-packages
<wpwrak>
now, what would the debian guys say if one suggested to them to split their fat packages into many lean ones ? :)
<wpwrak>
if getting an excessively long package list is a concern, an option could be to extend the packaging mechanism to hide the split inside the package
<rafa>
we like our approach in jlime (OE repository). We can build the whole thing easily, and it already has the different parts of the packages for tiny devices. Also the opkg thing. Our approach is in the middle of openwrt (where a lot of effort is being used to have a minimal decent stable repository and the full huge (proper for PC) Debian repository)
<wpwrak>
e.g., instead of just apt-get install emacs-supersize-me, you could apt-get install emacs/base,examples,double-cream (or whatever the syntax)
<tuxbrain>
wpwrak: just for you info jlime exist a lot of time before than Ben NanoNote was already thinked, Ben is just another platform to run it :)
<wpwrak>
tuxbrain: i know, but isn't the current main focus of jlime the ben ? jlime has a fairly small installed base, as i understand things
<rafa>
wpwrak: yes, as tuxbrain says, when we were building the OE repositories for Hp jornadas, there was not SH3 binaries Debian repository
<wpwrak>
tuxbrain: rafa's concern is that the qi-hw community doesn't seem to be very interested in jlime, although it's a much friendlier environment than, say, openwrt
<rafa>
wpwrak: that is why that was really useful to keep. No other distributions had sh3 binaries
<wpwrak>
rafa: but sh3 is now in, say, debian ?
<shevek>
tuxbrain: Could you test if my new version of iris can boot from sd?
<rafa>
yes, they have now I think. At least sh4
<wpwrak>
tuxbrain: then there's debian, where you would have even more packages than in jlime, but nobody seems to use that either. instead, people are porting packages into openwrt, which is certainly a valient effort, but one has to wonder if it really makes sense
<tuxbrain>
rafa know what the problem is and why qi cannot embrace fully jlime, is our strict pattent free policy, but from this to asure that jlime is doesn't have our interest is by far not the same
<tuxbrain>
debian is slow and heavy
<tuxbrain>
shevek: Not right now, but I will try to do it some day of this week if you dont mind the delay
<shevek>
tuxbrain: No problem.
<wpwrak>
tuxbrain: i think the patent policy is a separate issue, and (technically) much simpler
<shevek>
tuxbrain: Thanks
<rafa>
I think that debian would be perfect if we could split the packages as wpwrak suggested. And a proper lightweight package manager.
<wpwrak>
rafa: such as opkg :)
<tuxbrain>
mmm and how per example you do on debian to install x using kdrive instad of xorg when installing a x depending package?
<tuxbrain>
not sarcams I really want to know :)
<rafa>
tuxbrain: no, I do not think in qi , I mean the community. If we ask in our #jlime chat or forums or mailing list (it is not useful yet though) there is not feedback from any user from the community.
<wpwrak>
tuxbrain: can debian packages provide a "feature" ? i.e., kdrive and xorg provide X, x-whatever depends on X.
<tuxbrain>
you mean to update debian package sistem or this is already implemented?
<wpwrak>
tuxbrain: (i don't know much about the debian package format, but i vaguely recally having seen such pseudo-packages in other formats)
<wpwrak>
tuxbrain: i don't know :) if they don't have it, they really should. but i think they must have something like this already. just think of "kernel", "syslog", etc.
<wpwrak>
there are lots of things where many different packages can provide the same functionality
<wpwrak>
the thing that makes openwrt attractive may be that there's a more direct way to contribute changes. that's of course important, and it gives the downstream project more control
<tuxbrain>
rafa: I just think is matter of critical mass, it's normal than the most users are in qi-hardwere channels due ben is qi, and I think we also still a few, we have to grew even more , and in term of maths you are a subset of qi-users, that means even low amount of mass, other jlime users , I thing is just natural. Whatever, I'm really really happy than an OE distro is so brilliant on NanoNote thanks to people like you. For me Jlime is a key part of th
<tuxbrain>
e whole thing. don't be dissapointed yet, we are on the beggining on the road :)
<wpwrak>
to achieve the same with debian, a qi-specific "buffer" or "overlay" could be created, where changes are rapidly integrated, and then - more slowly - propagated to upstream (or anything they don't like is kept at the overlay. if upstream really really hates it for a long time, there's probably something wrong with it anyway)
<wpwrak>
i guess it all depends on how the jlime folks see their own work. if they get the impression they're wasting their time supporting a platform that ignores them, it would be better to do something about this, before they just go away frustrated
<tuxbrain>
I'm still thining OE, and OpenWrt where thinked to just device like ben so that's why they really fits on it and we feel this easyness when working with them on NanoNote, debian is general porpouse monster, and was at first intended to servers and then to desktop and some brave man had achieved to bringing it down to more little devices, but once you start to work with it it easyly expands itself and you have a full Nand more quick than a apt-get upd
<tuxbrain>
ate
<wpwrak>
what fills your nand ? the package meta-data, the downloaded packages, or the installed stuff ?
<wpwrak>
tuxbrain: i'm very lazy, so i always look for a way to make small changes that add the most value, but let others do the bulk of the work :)
<wpwrak>
tuxbrain: also, Kant tought us that you should do onto others what you crave for yourself. so i assume others like it if they can be lazy, too :)
<tuxbrain>
meta-data is a big concern but the most is filled with unsued dependencies :)
<wpwrak>
s/tought/taught/Â Â # argh
<wpwrak>
so the dependency tree has problems. hmm. indeed, the sub-packages should have their own dependencies. e.g., if you install gnuplot but not gnuplot/x11, you don't need libgtk or whatever it uses
<tuxbrain>
regarding feeling ignored, is really a false sensation, me as distributor, an sharism as manufacturer are tied to not be able to promote a sistem that allows patented codecs to be part of the sistem, not for we don't like it, totally the contrary we are just amazed and pleased with jlime progress really, the only thing is that they have to promote by it self
<wpwrak>
i think what's troubling rafa is more the lack of end user responses
<tuxbrain>
well if it's for this, if you review the qi-hardware list the only ones proposing/discussing/participating are mainly developers and core stuff, there are some exeception but if you count we have selled 900 units, and there is not 900 users in the mailing list :) again, we are just a few, jlime is a subset of that few, patience and perseverance is the only medicine to the spirit in this situation
<rafa>
tuxbrain: I think that we have just mplayer and some mp* decoder packages in our repositories. What about if we set video player just for ogg and remove libmad and other mp* decoder packages from repositories? Would it be useful for you? To promove jlime, or to put jlime in microSD as extra accessory for nns?
<rafa>
There is not many stuff for patented codecs anyway.
<rafa>
SO that would not be a hard work to do.
<rafa>
some rm things :)
<tuxbrain>
wpwrak: also there where other projects involved in qi list than generates movement SACK ( a version of jlime will be cool as well) the Milkymist, and of course the philosophy of coplyleft hardware it self,
<wpwrak>
(900 units) i do indeed sometimes wonder where they all went ;-)
<wpwrak>
agreed on this being developer-heavy. maybe the time is just not quite ripe for jlime's hour of glory
<rafa>
wpwrak: tuxbrain: BTW, we are preparing a jlime version for SAKC as well (professor is helping me, and I am helping him  ;) )
<tuxbrain>
rafa: that's interesting, did you mind if I check with wolfgang before to pronounce about it, my heart says a BIG YES but laws are totally unsensitive to my heart desires.
<tuxbrain>
rafa: that awesome really :)
<rafa>
wpwrak: let me prepare the wikireader thing, perhaps that helps a bit more (as advertising haha)
<tuxbrain>
must leave to soup :) see you later
<rafa>
tuxbrain: I think that that would not be a big effort to do (remove the few annoy packages). we just would need to agree with kristoffer and other devs.
<rafa>
cya man
<viric>
For the nanonote, what -march=XXX you use in gcc?
<larsc>
mips32
<viric>
for a mipsel compiler, it will be redundant, if I set abi=32, right?
<viric>
I can write nothing
<viric>
larsc: can you advice to me a defconfig I could use for the system headers? Not to build the kernel...
<viric>
only for "make install_headers"
<viric>
I'm about to choose any mips1 little endian