<kyak>
xiangfu: hm, i don't understand.. after i did git pull, i got 21 commits ahead of trunk?...
<xiangfu>
kyak, I rebase the trunk branch, for get some last commit from 'master'
<xiangfu>
I guess there is a 'git merge master' in your local git
<kyak>
xiangfu: what's the difference between rebasing and merging? I think the history is lost during rebase.. So we should merge
<kyak>
xiangfu: btw, i answered you e-mail
<xiangfu>
rebaseing: is try to apply the pathes on top of another branch. if there are same commits like "nanonote-files: feeds.conf: disable useless", will only have one after rebase.
<xiangfu>
merge will just mix them together for simple :)
<kyak>
damn.. why it has to be so hard :)
<kyak>
anyway, i wonder why i do 'git co master' and see centerim5 package there
<xiangfu>
kyak, last rebase done. you can 'git fetch -a && git reset --hard origin/trunk' under local trunk branch
<xiangfu>
then run 'gitk' you will see all commits is on top of master
<kyak>
ok, never merge, always rebase :)
<xiangfu>
the merge is used like: there are three branch 'master' 'ben-naonote' 'ya-naonote', then we can merge 'ben-nanonote' under 'master', merge 'ya-nanonote' under 'master'
<xiangfu>
but our case is we have to rebase on top of openwrt upstream, also this rebase help us find the different with upstrem
<xiangfu>
just fyi, :)
<kyak>
yep, i got it.
<kyak>
just i still don't understand why some files in web interface don't have history
<xiangfu>
the projects.qi-hardware.com using 'indefero' cache a lot, so we better check that again tomorrow :)
<xiangfu>
hmm.. there is no 'age' and 'message' on ben_ru_uni.map
<kyak>
yes
<kyak>
and the same for some other files
<kyak>
i'd say that all commits to trunk don't have such history
<xiangfu>
seems it's 'indefero' cache problem. let's give 'indefero' 24 hours for caching :)
<kyak>
it's not caching, most commits are much more than 24 hrs old
<kyak>
like that gcc-mips commit
<xiangfu>
but we just rebased.
<kyak>
hmm
<kyak>
this is tricky.. i thought the commit identifier is kept
<kyak>
ok, let's see in some time :)
<xiangfu>
kyak, if the last openwrt release don't have big bug/problem, we can switch to 'trunk' after that.
<xiangfu>
kyak, also we can think about Jlime/Openwrt dual boot,
<xiangfu>
think about nand partition, since we have fast mount time,
<xiangfu>
add atben support
<kyak>
i'm using trunk for quite some time now, without apparent problems. Btw, plplot fails to build for some reason, i guess we could ask dvdk to have a look..
<xiangfu>
yes.
<kyak>
xiangfu: dual boot - i think it's working already by holding a button during power on. What more can we wish?
<kyak>
some menu.. i'm not sure, it only waste precious seconds during bootup
<xiangfu>
yes. then the Jlime/Openwrt have to install in two partition.
<kyak>
2 Gb is not much at all :)
<xiangfu>
I don't have clear idea on dual boot. :(
<kyak>
taking into account the growing number of uSD slot hacks
<kyak>
not everyone would have spare uSD slot for jlime :)
<kyak>
i'm happy with the current partition layout
<kyak>
more than 512 Mb for rootfs is good if you need to pre-install all the software. but in real life, one person doesn't need that much
<kyak>
512 Mb rootfs with around 150 Mb free space for installation of additional pacakges is good
<kyak>
having 2 Gb rootfs would make me hesitate to reflash
<kyak>
because i'm lazy to backup and then restor my user files after reflash
<xiangfu>
back/restore is bad. me either
<xiangfu>
I mean I also don't want to do backup/restore.
<kyak>
having some space that can survive between reflashes is good.
<kyak>
frankly, i wouldn't give another 512 Mb of NAND for the second OS.. 1.5 Gb of datafs is not that much at all
<kyak>
also, i don't know who will be using both OSs actively at the same time
<kyak>
i.e. constantly switching between each other
<kyak>
another OS that would be just a waste of space
<kyak>
for someone using jlime, 512 Mb of openwrt (that he doesn't use or uses very rare) is a waste of NAND
<kyak>
and vice versa
<kyak>
and, having two OS's means doubling of support efforts
<kyak>
i see that checking for root has been removed
<xiangfu>
kyak, me too, before setup the udev :)
<kyak>
i'll setup udev :)
<kyak>
it was buggin me to run that as root, but not as much as to take measures :)
<kyak>
xiangfu: couple of days ago, i merged openwrt-trunk into qi-openwrt-trunk. Should i now rebase instead?
<xiangfu>
which repos? openwrt-xburst.git?
<kyak>
there was only one conflict at that time.. i think it lead to creation of "double" merge
<kyak>
yeah, openwrt-xburst.git
<kyak>
i.e. our local change in sound.mk got merged with upstream change in another (third) commit
<kyak>
instead of rebasing on top of that upstream change
<xiangfu>
yes. rebase is better for maintain our commits.
<xiangfu>
you can use 'git rebase -i OPENWRT_TRUNK_BRANCH_NAME'
<xiangfu>
then it will bring a text for you to edit. decide which commit you want.
<kyak>
yep, it brings the text
<kyak>
i want all of them :)
<kyak>
not sure if this one "pick a85f9e8 trunk: build sound modules in kernel"
<kyak>
will rebase without conflicts
<xiangfu>
just save and exit. see if there is conflicts?
<xiangfu>
if no. then everything is find. if there is we have to manually fix the conflict.
<kyak>
Could not apply a85f9e8... trunk: build sound modules in kernel
<kyak>
just like i said
<kyak>
after i fix the conflict. How should i proceed?
<kyak>
add/rm this file, or git rebase --continue ?
<xiangfu>
'git rebase --continue'
<xiangfu>
you can run 'git mergetools'
<xiangfu>
sorry, 'git mergetool'
<kyak>
one minute..
<kyak>
Could not apply 21fdcfd... package/kernel: Remove all 2.4 definitions
<kyak>
but files require merging.. wtf?
<kyak>
*no files
<xiangfu>
this commit is from upstream?
<xiangfu>
sorry. should be from ours.
<xiangfu>
where is this commit from ? are you sure you have correct branch? current branch and which branch you are rebase on?
<kyak>
that commit is from upstream
<kyak>
i know how it got there..
<kyak>
that' because of merging..
<kyak>
fixing it now..
<qi-bot>
[commit] jow: [package] iw: fix calculation of fractional multicast rates like 5.5Mbps due to wrong operator precedence http://qi-hw.com/p/openwrt-xburst/030f9c1
<lunavorax_frizzl>
Oh I never realized how much space Xorg was using in RAM
<lunavorax_frizzl>
~580MB
<DocScrutinizer>
nt exactly xorg but probably all the apps allocating rather large canvas aka webpages aka oversized scrollable windows
<DocScrutinizer>
which are usually larger than the framebuffer for the screen's real resolution
<vladkorotnev>
hello everyone :D
<vladkorotnev>
I know it's a noob question, but how do I insert a microSD card into the ben nanonote?
<wpwrak>
vladkorotnev: so it arrived ? congratulations !
<wpwrak>
vladkorotnev: you insert the card with the contacts facing upward
<vladkorotnev>
wpwrak: thanks!
<vladkorotnev>
wpwrak: it tries to get back out :P
<wpwrak>
push it in a little more. then it should lock (you can still pry it out, but it resists a little)
<vladkorotnev>
oh thanks, I got it
<vladkorotnev>
but where's its mount point?
<wpwrak>
puuh. not sure if there's any kind of automount. maybe you have to mount manually.
<ron_>
thinking about possible futre nanonote derivative, a question: changing toi a different LCD display module implies (??) a new lcm controller? Â
<ron_>
from something I read here months ago, apparently the lcd controller was especially tough to crack (open up code). is that correct
<wpwrak>
ron_: you mean the chip on the lcd module ? yes, there's a number of such chips and you can never quite tell which one they use
<wpwrak>
ron_: this happened before i got involved, byt lcd controllers are generally a mess, so i wouldn't be surprised if it was a pain
<wpwrak>
s/byt/but/
<ron_>
wpwrak my real question is it practical to go to a new and larger display with higher resolution
<ron_>
i understrand that having more bits to move around is a challenge
<wpwrak>
roh: well, i wouldn't change the form factor of the nanonote much. but a slightly wider display should be possible
<ron_>
on the other hand 4760 will run about 2x faster
<ron_>
on the other hand the main attraction of Ben is it is very open. on a spec basis, it is very weak compared to many other portable devices that can be used with Linux. e.g. Palm Pre run a nice linux.
<wpwrak>
yeah, a new design would have a lot more memory bandwidth. maybe faster clock, sdr->ddr or even ddr2, a wider bus. you could drive a very large screen.
<wpwrak>
it specs are weak, but the price is low :) i think that's an interesting niche.
<kyak>
vladkorotnev: it arrived at the right time to give it a try to new testing image from xiangfu :)
<wpwrak>
ron_: i would also hope that more opened design would be easier to adapt. e.g., you could make a laptop-sized variant with a moderate investment. still a few kbucks, but far less than what it would cost today.
<kristianpaul>
valhalla: great it arrives indeed
<kristianpaul>
oops
<kristianpaul>
is gone..
<kristianpaul>
sorry valhalla
<wpwrak>
ron_: all we'd need to make this happen is a pot of gold. anyone stumbled upon one by chance ? :)
<wpwrak>
kristianpaul: the curse of auto-completion :)
<kristianpaul>
yeah.. :S
<Jay7>
wpwrak. ron_: I'll prefer case and keyboard like HP Jornada ;)
<Jay7>
interesting, is Pandora case schematics awailable?
<Jay7>
I mean OpenPandora
<qwebirc145>
hello how is the development going?
<valhalla>
kristianpaul: np, the conversation looks interesting anyway :D
<valhalla>
Jay7: no, the openpandora is not open as far as hardware is concerned
<Jay7>
valhalla: I mean case
<valhalla>
Jay7: yes, case included
<Jay7>
bad OpenPandora, bad!
<valhalla>
they are dead scared of clones appearing before they have managed to finish builiding the preorders
<Jay7>
they are failed almost anything
<Jay7>
but they was one of pioneers
<valhalla>
exactly, when they started they were sort of "open enough for now"
<wpwrak>
we have to keep raising the bar :) there's still a lot to do.
<valhalla>
well, the nanonote is also "open enough for now", since the SoC is still proprietary, only the "now" of the nanonote is later than  the "now" of pandora
<wpwrak>
the nanonote also lacks open schematics that were used for production (the "real" schematics are in a proprietary format), an open layout, and an open case designs.
<wpwrak>
schematics and layout should be easy enough to "do right" in a future device. the case is harder.
<Jay7>
case design is very special thing..
<wpwrak>
wolfspraul: btw, someone asked for the ben layout a few days ago. have you ever released the gerbers ?
<wpwrak>
Jay7: it's different from electronics. but hey, it should certainly be doable for a few lads with sharp wits and some CNC system (mill, printer, whatever) :-)
<wolfspraul>
wpwrak: the avt2 gerbers are published in both kicad and pads, I believe.
<wolfspraul>
the other gerbers are irretrievable due to the process back then with multiple companies involved
<wpwrak>
(avt) cool. (others) :-(
<wolfspraul>
but for all practical purposes the lb60 and avt2 gerbers are the same, it's only a technical problem
<wolfspraul>
The ben gerbers are released as avt2, in both pads and kicad format.
<wolfspraul>
that's the bottom line
<wolfspraul>
the pads version is even production tested (the kicad version is not)
<wolfspraul>
the naming of lb60 and avt2 was unfortunate
<wolfspraul>
naming pcb revisions in open projects is a pain
<wpwrak>
wolfspraul: (naming pcb revisions) hmm, what do you mean ?
<wolfspraul>
the kicad run never made it though, so the kicad files are untested
<wolfspraul>
those random numbers lb60 and avt2 are a bad idea
<wolfspraul>
it just doesn't work
<wpwrak>
ah. well, they look "professional" :)
<wolfspraul>
the best is to only have one file format (say kicad), to start in that file format from day 1, always stay in that file format
<wolfspraul>
any derivatives or generated files should be generated in a clean and reproducible process, from a known revision of the original open kicad files
<wolfspraul>
and all boards should be named after the product they are being part of, and then just a date code, or revision number
<wolfspraul>
that's the theory
<wpwrak>
hmm yes, including the git revision would be an interesting idea
<wolfspraul>
in practice it's sometimes not like that :-)
<wpwrak>
well, ben-wpan is pretty close. i still maintain my version number (basically a date code) manually, but besides that, everything originates from the kicad design files
<wpwrak>
(plus some auxiliary material for BOM, CNC, etc. but that's kinda unavoidable)
<DocScrutinizer>
PADS \o/ :-S
<Jay7>
is looking at google analytics for kexecboot.org site
<Jay7>
wpwrak: seems you made lot of traffic ;)
<Jay7>
I see interesting sources like acessa.me, google.com.pe
<Jay7>
location chart is interesting too.. Brazil, Pery, Colombia, Mexico, Argentina
<Jay7>
s/Pery/Peru/
<wpwrak>
Jay7: (traffic) hm no, i just mentioned it on a forum in germany. don't think it spread far from there
<wpwrak>
Jay7: maybe someone else discovered it independently ;-)
<Jay7>
well, may be :)
<Jay7>
btw, now USA visitors count is greater than Russia visitors count :)
<Jay7>
good sign
<Jay7>
USA is at 1st place now :)
<wpwrak>
whee ! :)
<wpwrak>
if you translate the page to chinese, maybe even more people will come ;-)
<Jay7>
I don't speak chinese :(
<Jay7>
btw, some people from South Korea was here too
<Jay7>
and Japan
<wpwrak>
now you've earned global fame :)
<Jay7>
and India
<Jay7>
hehe
<Jay7>
well.. I should commit something then :)
<kristianpaul>
btw what happend with kexecboot and nanonote?
<Jay7>
almost nothing :)
<kristianpaul>
ah :-)
<Jay7>
I have no time to find and fix kexec problem on NN
<Jay7>
and kexecboot is unusable w/o working kexec at this moment
<Jay7>
so work is kinda stalled
<kristianpaul>
i hope your followers are not here
<Jay7>
I'll add support for switch_root and switch_root + losetup soon :)
<Jay7>
then kexecboot may be usable even w/o kexec :)