<wolfspraul>
kyak: thanks for helping with the images!
<wolfspraul>
if an account on our new buildhost machine does any good to you, let me know and you have one right away...
<kyak>
wolfspraul: it's my pleasure! ok, if i need the account, i'll let you know, thanks
<wolfspraul>
kyak: don't hesitate to update the config.full_system file in openwrt-xburst either
<wolfspraul>
if you see a package that is useful on the Ben NanoNote but not included in the image, whether it's a library, console app, GUI app, etc. just enable it and commit the update into config.full_system
<wolfspraul>
I also still see things in there that don't make much sense, like ntfs utilities. I hardly can see anyone connecting an NTFS formatted microSD to the Ben...
<wolfspraul>
so I will also start enabling/disabling things in there. since it's a whole OS, the more eyes the better.
<bartbes>
yeah, me neither...
<kyak>
wolfspraul: i'm doing right now quite opposite.. i started from scratch, i.e. default config wit hno packages and now adding one by one necessary (from my opinion) packages
<kyak>
there is a lot of useless things in config.full_system
<kyak>
but RIGHT now i'm trying to port mupdf. I've seen it in Jlime, and it's quite good
<kyak>
it has two dependencies that are not in openwrt yet, openjpeg and jbig2dec
<kyak>
so not so straight forward
<bartbes>
well it all depends on the deps
<bartbes>
I remember physfs
<bartbes>
apart from it being the first cmake project (that I know of) it was easy
<bartbes>
(well of course it has been done before, but then someone must've shot down a plane by throwing a rock at it as well)
<wolfspraul>
kyak: excellent!
<wolfspraul>
yes of course, let's kick out useless stuff from config.full_system
<wolfspraul>
totally with you
<wolfspraul>
I work on another config right now, config.debug
<wolfspraul>
I want it to be a minimal system, just bootable but with most system libraries installed. then debug options should be enabled.
<wolfspraul>
so if we run into a problem, it should be easy to add another package, rebuild config.debug, and be in a good position to fix the bug fast
<bartbes>
have the sdl problems been fixed btw?
<wolfspraul>
kyak: how did you get to your 'default config' that you started from?
<wolfspraul>
bartbes: no, not fixed. And I need an image to reflash 1000 nanos next week...
<wolfspraul>
worst case I have to use the old 06-15 image, with heavy flickering and all...
<wolfspraul>
but still some time, so we see
<kyak>
wolfspraul: make distclean, then make menuconfig. then select our target, and after make and reflash your Ben you will end up with 3Mb Linux distribution with busybox and base-files
<bartbes>
then add lua
<bartbes>
sdl
<bartbes>
physfs
<bartbes>
freetype
<bartbes>
and nlove
<bartbes>
and you have a love machine
<bartbes>
>:)
<kyak>
bartbes: actually, only add "nlove", all other must be selected automatically :)
<bartbes>
true
<kyak>
actually, by building from scratch i've detected some missing depenedcies
<bartbes>
though..
<bartbes>
I might have forgotten freetype..
<bartbes>
now that I think of it
<wolfspraul>
kyak: when you select a package in make menuconfig, OpenWrt will automatically select the dependencies?
<bartbes>
actually..
<bartbes>
wut
<bartbes>
I'll need to check this out this afternoon
<kyak>
wolfspraul: yes
<bartbes>
wolfspraul: if they are defined properly in the makefile
<bartbes>
yes
<wolfspraul>
sometimes I am wondering whether it's a good idea to commit entire config files, maybe it's better to write a little script that can process a list of apps, and will manually edit the config file with sed or so, from 'is not set' to '=y'
<wolfspraul>
ah OK, then an external script is not a good idea
<kyak>
wolfspraul: not a good idea, yes.. should keep consistency via make menuconfig
<wolfspraul>
although OpenWrt would probably 'pick up' the dependencies when running make?
<wolfspraul>
or are they enforced while make menuconfig is running?
<wolfspraul>
they may have 'make oldconfig' and others things, no?
<kyak>
when you run make, it doesn't alter you .config, so dependencies are not "picked up"
<kyak>
when you run menuconfig, OpenWrt is cross-checking for dependencies and when you have the menu, these dependencies are already there
<wolfspraul>
how about 'make oldconfig'
<kyak>
example, if you added a new dependency for some package, then run make menuconfig and exited with saving (actually changing nothing manually in that menuconfig), you will see your added dependepcies in .config
<wolfspraul>
do they have some way to automatically cross-check dependencies?
<kyak>
not sure about oldconfig, never used it
<kyak>
stupid developers. .naming their tarball as openjpeg_v1.2.tar.gz
<kyak>
and inside is trunk/ dir
<kyak>
of course, not using autotools
<kyak>
god, they have things like install -m 644 -o root -g root in their Makefile
<kyak>
angry
<viric>
urgh. ubifs decided to do several torture tests to a PEB
<viric>
it looks like in a loop
<viric>
two minutes, running a torture test on the same block every two seconds
<viric>
and still did not stop
<viric>
Should I stop the ben?
<viric>
4 minutes
<wolfspraul>
viric: is the whole device stuck? how do you know ubifs is doing something?
<viric>
wolfspraul: no
<viric>
wolfspraul: I could login, run programs...
<viric>
wolfspraul: they run slow though
<viric>
wolfspraul: I could run 'halt', and boot again. Then the problem disappeared.
<wolfspraul>
ok
<viric>
But ubifs was in the loop for 6 minutes, until halt switched all off
<wolfspraul>
it's a long story. nand is difficult and ubifs is the best shot free software has to offer.
<viric>
here I saw a comment about a torture test getting into loop
<wolfspraul>
:-)
<wolfspraul>
don't worry
<viric>
no?
<wolfspraul>
no.
<wolfspraul>
we know too little facts about nand and the exact ubifs behavior to be worried
<wolfspraul>
the best we can do is to run very recent Linux kernels, which more or less we are doing.
<wolfspraul>
another cool thing would be if the ubifs developesr would use NanoNotes for development :-)
<wolfspraul>
scary link indeed
<wolfspraul>
if someone can still say in 2010 with a straight face that they only support SLC, and doesn't seem to be worried about that the slightest little bit
<wolfspraul>
it's as if the storage guys would happily say that they only support scsi, never heard or want to be bothered about ata or any of that sata stuff. overhyped, ya know? :-)
<kyak>
trying to redefine TAR command, is not so obvious
<wpwrak>
wolfspraul, kyak: if you want script-driven configuration, switching on what you like and then running "make oldconfig" should indeed work. after all, one of its purposes is to take an old .config and process it in the context of a new set of Kconfig files.
<wpwrak>
(i've used this sort of approach on some occasions)
<kristianpaul>
a
<wpwrak>
wolfspraul: maybe all the people who understand NAND are moving away from bare NAND ? (-:C
<kristianpaul>
wolfspraul: ^ why i cant remove stuff from tmp?..
<kristianpaul>
wpwrak: (morning), moving to ... ?
<wpwrak>
kristianpaul: something nicely packaged. uSD, for example :)
<kristianpaul>
:)
<kristianpaul>
but speed?
<kristianpaul>
cause NAND memory are parallel isnt?
<wpwrak>
kristianpaul: on the Ben, uSD is 4 bits, NAND is 8 bits, DRAM is 16 bits
<wpwrak>
kristianpaul: so there's less of a difference than you may expect
<wpwrak>
and i've heard that uSD is actually faster than NAND on the Ben (haven't measured it myself, though)
<kristianpaul>
well Jlime works like a charm most of the time
<kristianpaul>
but is not a serios test
<kristianpaul>
indeed i need measure that, i wonder if i can save around 2Mb raw data per second and not hurt the whole system I/O
<zear>
kristianpaul, everything rafa works like a charm ;)
<zear>
*rafa makes
<wolfspraul>
kristianpaul: you can ssh into the machine as root
<wolfspraul>
have you fixed your /tmp and sudo problem? feel free to install stuff as you need
<wolfspraul>
if you make bigger config changes shoot me a note so I can update the documentation, or update it yourself
<kyak>
hm
<kyak>
has anyone ever overriden the /bin/gtar as unpacking application in openwrt toolchain?
<kyak>
i set TAR:=/bin/gtar (with whateve my parameters) in Makefile, but it doesn't work
<wolfspraul>
kyak: I tried to start with no .config and then just setting the target as you suggested. worked great, the .ubi file is 9.5mb though, not 3.5mb (maybe you meant .tar.gz size, or another filesystem type?)
<wolfspraul>
if it works (trying now), I will document what to enable on the wiki page
<kyak>
wolfspraul: yes, ubi file is bigger, i meant the output of df -h on your Ben :)
<wolfspraul>
ok
<wolfspraul>
if make oldconfig works well, maybe we can switch to much shorter, more meaningful, and more maintainable config files as starting points
<wolfspraul>
and then the first step will always be 'make oldconfig' to mix it with whatever openwrt defaults
<wolfspraul>
need to try though...
<kyak>
yes, good intention
<kyak>
if it works
<kyak>
then we just define a list of "our" apps: 1) to be included in image 2) to be built as "modules"
<kyak>
override TAR:=/bin/gtars
<kyak>
must be like this :)
<wolfspraul>
yes but first we need a system of config files that is cleaner. right now the config file is 100kb or more, and diffs are meaningless (too big) because it seems openwrt always moves options around.
<kyak>
yes, you are right
<wolfspraul>
my hopes for the 'cleaner' part rest on 'make oldconfig' right now :-)
<kyak>
it's PKG_UNPACK, actually..
<kyak>
damn those openjpeg people
<wolfspraul>
xiangfu: when I boot from that minimal image, it gets stuck at 'kernel panic ... unable to mount rootfs'
<aisa>
wolfspraul: can you give me details about the problem with the current testing image?
<aisa>
Specifically: When did it become a problem, and what is happening?
<wolfspraul>
aisa: xiangfu can probably describe it better
<wolfspraul>
in general the plan says every release image should be better than the one before
<aisa>
xiangfu: I have one more question for you.  ^_^
<wolfspraul>
but since 2010-06-15, we haven't really managed to do that, we currently have regressions that are so severe that we think they overshadow the progress that was also made
<wolfspraul>
like for example SDL apps don't work, or Qt apps don't work, or both
<aisa>
I would assume that the compiler, an essential library, or the kernel was updated after that point?
<wolfspraul>
the latest testing image is 2010-08-26 by Mirko and then 2010-09-06 by Xiangfu, but both have serious bugs
<wolfspraul>
now it also hurts us that the release process is not fully documented and nailed down, neither is there a definitive app list or test plan :-)
<aisa>
I made some corrections and additionals to the build instructions this morning,
<wolfspraul>
pretty hard to come out with incrementally better images, without regressions, in that environment...
<aisa>
and I noticed in doing so that making a release was scattered across several wiki pages, not directly linked to each other.
<aisa>
I imagine I'll continue to clean up as I go.
<wolfspraul>
btw, in terms of disk space, a minimal config needed about 3GB for me, the config.full_system one with debug symbols turned on was already 31 GB
<wolfspraul>
fantastic. you will become our release hero.
<aisa>
I'm using 5.0GB of disk, having checked out openwrt-xburst and openwrt-trunk, plus compiling a build image.
<aisa>
How do you turn on debug symbols, is it an option in .config?
<aisa>
As I've played with the build I regret not ordering two NanoNotes right away.
<wpwrak>
wolfspraul: (stress) yeah, i've seen that :) just want to know what your plans are. it doesn't run away ;-)
<aisa>
OT: can someone remind me how to scroll up and down in irssi?  (*sheepish*)
<wolfspraul>
aisa: just pg-up, pg-down works for me
<wolfspraul>
aisa: I gladly create an account for you on our buildhost
<xiangfu>
aisa: what is the question?
<wolfspraul>
there's a couple hundred gig of HDD space and a decent, though single-core, Athlon64 compiling away...
<aisa>
xiangfu: I would like more details on the instability in the current image.
<aisa>
Enough to be able to do some debugging:
<aisa>
What do you do to create a problem?  What do you see?  What did you expect to see instead?
<aisa>
wolfspraul: I would welcome a better machine to do builds on, I kept my laptop pegged all day yesterday and I had other work to do...
<aisa>
(I do data analysis, so my CPU can be precious at times.)
<wolfspraul>
do you have a url to your public key, or can you email it to me? what account name do you want?
<aisa>
May I have the account name 'a'?  That is what I use on my computers.
<aisa>
I will upload my public key and post, one moment.
<wolfspraul>
btw, for the images, one thing to keep in mind is that we are currently trying to follow the upstream 'Backfire' release, although it seems some packages have already been upticked beyond Backfire
<aisa>
oh good, that answered one of my questions.  Who is working with openwrt to push patches upstream?
<wolfspraul>
if we are brave enough, and feel we are wasting our time, we can leave the Backfire path in our 'xburst' branch and track upstream trunk
<wolfspraul>
aisa: several people do, mostly mirko (on vacation this month), and larsc (though mostly for the kernel I think)
<xiangfu>
aisa: we have update uClibc to 0.9.32. then some program just hang. even "mkfs.ext2 --help". seems all SDL program not work,
<wolfspraul>
xiangfu: we have two branches in openwrt-xburst, 'master' and 'xburst'
<xiangfu>
aisa: <xiangfu> here is the "strace mkfs.ext2 --help" for 0.9.30:
<wolfspraul>
which one is 'master' tracking, and which one is 'xburst' tracking? can we document somewhere how we are tracking?
<aisa>
xiangfu: I'm happy to see it is a uClibc problem.  I'm going to be much better at debugging that than if it was a kernel upgrade.  I'm fairly good at how the C library interfaces with the kernel and applications.
<xiangfu>
hmm. 'master' is a clone of svn://svn.openwrt.org/openwrt/trunk/
<xiangfu>
wolfspraul: 'xburst' follow the svn://svn.openwrt.org/openwrt/branches/backfire
<aisa>
xiangfu: wiki page [[Building Software Image]]
<wolfspraul>
yes that's the account name he asked for, and actually I like it, less typing even when setting up the account :-)
<kristianpaul>
indeed
<kristianpaul>
i like too
<wolfspraul>
12 times easier than yours!
<kristianpaul>
heehhe
<wolfspraul>
you want k?
<aisa>
kristianpaul: I had a boss at my first job whose unix name was 'n'.  I was quite inspired by that!
<kristianpaul>
wolfspraul: well no bother, i like my nick :)
<aisa>
wolfspraul: I am able to log into this system using my rsa key.
<aisa>
Will it be ok to document using the system on the wiki?
<wolfspraul>
should work, yes. please try.
<wolfspraul>
don't understand [document using the system on the wiki?]
<xiangfu>
wolfspraul: hmm... I don't think we need add prefix 'openwrt_', but I am thinking change master --> upstream, xburst --> master
<aisa>
wolfspraul: I was thinking something along the lines of:
<kristianpaul>
wolfspraul: xiangfu the /tmp problem i had is because a build was a as root i think, then some folder in tmp are root owned, then my build try same file, then.. O_o
<aisa>
nightly builds, location of testing workspaces, filesystem layout for the project.
<wolfspraul>
kristianpaul: a build was run as root on the buildhost?
<xiangfu>
kristianpaul: I found this: rules.mk:17:TMP_DIR:=$(TOPDIR)/tmp
<wolfspraul>
xiangfu: I think those names are even more confusing. we should clearly express the upstream relation in the branch name, imho
<wolfspraul>
openwrt_trunk and openwrt_backfire
<kristianpaul>
wolfspraul: yes
<kristianpaul>
xiangfu: great !
<xiangfu>
wolfspraul: hmm.. it's git tradition. "master" branch is always the branch you current working on.
<kristianpaul>
wolfspraul: it seems
<kristianpaul>
or
<kristianpaul>
with a user wich is not me
<kristianpaul>
that could make sense too
<kristianpaul>
any way xiangu pointed the solution
<aisa>
wiki has information on trunk and backfire branches:
<kristianpaul>
xiangfu: i guess i change that TOPDIR for HOME or something more local?
<kristianpaul>
so we can build at same time and no worries about use same temp directories
<xiangfu>
kristianpaul: git diff :)
<kristianpaul>
xiangfu: :)
<kristianpaul>
i learn a new git command today :D
<wolfspraul>
so running multiple openwrt builds in parallel on the buildhost is not safe right now?
<kristianpaul>
seems not if my theory is correct
<wolfspraul>
xiangfu: yes I know [master]. but this is a public server, shared by multiple people. its only purpose is to track upstream. so I cannot decide which master 'we currently work on', and it's better to have no master at all.
<kristianpaul>
as the /tmp is common for the builds
<wolfspraul>
that's actually precisely why I would not have a master, to make that clear. different people will use different starting points, or contribute to different branches.
<xiangfu>
wolfspraul: oopenwrt_trunk is ok for me . but openwrt_backfire will make people think it's another backfire branch. not ours
<wolfspraul>
let's see when/where the complaints will be coming...
<aisa>
I think each person is going to have to modify their .git/config file to update the branch names.
<aisa>
I believe it is the merge= line in each [branch] section.
<kyak>
hm.. what should I do? (not a power user of git)
<aisa>
open .git/config
<aisa>
there are two lines that say merge = in them.
<aisa>
one says refs/heads/master, the other says refs/heads/xburst
<wolfspraul>
kristianpaul: /wi 36
<aisa>
change them to refs/heads/openwrt_trunk and refs/heads/openwrt_backfire, respectively.
<wolfspraul>
kristianpaul: you need to run scripts/feeds update -a && scripts/feeds install -a, then the frotz problem should be fixed
<kyak>
aisa: ok, got it.. then i should always "git pull origin openwrt_backfire"?
<aisa>
I just type git pull, but I think that one works too.
<aisa>
wiki page is updated.  again.
<wolfspraul>
xiangfu: if I run a git clone from scratch, I can't checkout at all anymore
<wolfspraul>
maybe the 'master' branch better always be there in fact, or some other problem?
<wolfspraul>
just try git clone git://projects.qi-hardware.com/openwrt-xburst.git
<mth>
afaik "master" is only a naming convention for the main development branch, like "trunk" in SVN
<wolfspraul>
at the end it will say: warning: remote HEAD refers to nonexistent ref, unable to checkout.
<wolfspraul>
mth: that's what I thought. just a string. but who knows...
<aisa>
git clone [blah] is working for me...
<xiangfu>
wolfspraul:hmm.. just need to "make package/frotz/{clean,compile} " will fix the frotz /tmp problem. since we don't update the frotz's Makefile. we don't need run ./scripts/feeds ....
<aisa>
waiting to see what it actually gives me...
<aisa>
ah: warning: remote HEAD refers to nonexistent ref, unable to checkout
<aisa>
we, uh, need to fix our refs.
<aisa>
the problem isn't that master isn't there, but that HEAD thinks it is.
<aisa>
I'll be happy to fix it myself if someone wants to give me commit access :-)
<wolfspraul>
aisa: do you have an account on projects.qi-hardware.com ?
<aisa>
no, one moment.
<aisa>
oh, right.  The "sign in or create your account" has no "create your account" option.
<aisa>
I tried yesterday.
<xiangfu>
aisa: I update the HEAD by 'git remote set-head origin openwrt_trunk' but it not update the remote git.
<aisa>
xiangfu: I think you'll need to make a no-op change to have something to commit.
<aisa>
oh, sorry.
<aisa>
ignore that.
<wolfspraul>
aisa: just go to 'sign in', say 'I am new here', etc.
<aisa>
xiangfu: do you have access to the remote directly?  like from the command-line and can run that command there?
<wolfspraul>
did you do that?
<aisa>
wolfspraul: dur, I see it now.
<xiangfu>
aisa: you mean, this must change at 'terminal' , like edit .git/config??
<wolfspraul>
need to disappoint you, I think Indefero (the software behind the projects server) demands 3 characters minimum for account names :-)
<aisa>
wolfspraul: I'll use alanpost, same as my wiki account :-)
<xiangfu>
aisa: yes. I have.
<aisa>
and done, btw.
<aisa>
xiangfu: I wonder if you should just set the remote there directly, using a similar command.
<xiangfu>
aisa: I need edit the .git/HEAD file right? because that command seems change .git/HEAD file
<aisa>
xiangfu: let me experiment to be sure, lest I give you terrible advice...
<aisa>
what does cat .git/HEAD say?
<xiangfu>
aisa: very thanks
<xiangfu>
aisa: in my local: it's ref: refs/heads/openwrt_backfire (after run set-head)
<aisa>
good, mine too.
<aisa>
what about the remote?
<xiangfu>
aisa: remote: [ref: refs/heads/master]
<wolfspraul>
aisa: I added you as member to both openwrt-xburst and openwrt-packages
<wolfspraul>
you probably need to upload your public ssh key but then at some point you should be able to commit
<wolfspraul>
thanks a lot!
<wolfspraul>
very motivating to have you here pushing us :-)
<aisa>
xiangfu: edit that file, yes.  s/master/openwrt_trunk
<wolfspraul>
better openwrt_backfire for now
<aisa>
awww... thank you.  I can't tell you how excited I am about the NanoNote, it fills a need I've had that nothing else works for.
<aisa>
wolfspraul: where do I upload my public key at?  I see also there is a way to link gravatar information, I imagine it is in same place.  But I do not see it.
<kristianpaul>
aisa: prefences
<aisa>
kristianpaul: I don't see that on my screen.
<kristianpaul>
sorry not wait
<aisa>
I have Sign Out | Project List | Help
<kristianpaul>
hmm
<xiangfu>
wolfspraul, aisa: done and tested.
<aisa>
fantastic.  let me try to download the whole thing again to test.
<xiangfu>
aisa: click you name  after the "Welcome"
<aisa>
xiangfu: that's it!  Yay!
<xiangfu>
aisa: then at left (maybe the third line) : Update your account.
<xiangfu>
aisa: no need to config gravatar. it's automatic link to yours by indefero system.
<xiangfu>
aisa: no need to checkout to openwrt_backfire anymore.
<wolfspraul>
xiangfu: should we update the wiki page to say git checkout --track -b local_backfire origin/openwrt_backfire ?
<xiangfu>
aisa: I setup the HEAD to openwrt_backfire.
<wolfspraul>
xiangfu: yes but I think people should create a local branch, no? so they can commit locally etc.
<xiangfu>
wolfspraul: no need to checkout a new branch anymore.
<wolfspraul>
you shouldn't directly operate on a remote branch I think
<wolfspraul>
there's no 'need' but I thought it makes things easier, no?
<wolfspraul>
aisa: you could say git checkout --track -b local_backfire origin/openwrt_backfire, but let's see whether xiangfu or others think that's not needed.
<kristianpaul>
please no, i relly apreciate a stable branch to work on localy
<kristianpaul>
really*
<kristianpaul>
yes and then i can creame my loca branch to work locally
<wolfspraul>
kristianpaul: so you are saying the wiki should advise to create a local tracking branch or not?
<kristianpaul>
wolfspraul: yes i do
<kristianpaul>
my point is i'll like have the source for the image my Ben nano have the be ablo to hack around
<kristianpaul>
and sure if i want something more bleeding edge in develoment i can checkout devel brnahc
<kristianpaul>
and take my risks :)
<xiangfu>
wolfspraul: hmm... for the READ-ONLY user. no need to create a new branch. becuase he don't have right to commit.
<wolfspraul>
yes but there is no harm either. create it once, done.
<xiangfu>
for the READ-WRITE users. I think it's depends personal habit
<wolfspraul>
so rather have some instructions on the wiki everybody follows and everybody is safe.
<xiangfu>
wolfspraul: ok.
<wolfspraul>
I'll edit the wiki. let's just call it local_backfire
<aisa>
wolfspraul: local_backfire does work.
<aisa>
I can't see why it thinks I have a local branch called openwrt_backfire... :-(
<wolfspraul>
is that 'git fetch origin' actually needed right after git clone?
<aisa>
no.
<wolfspraul>
if nobody objects, let's take it out from the wiki steps then
<aisa>
I agree with kristianpaul, I need a local branch.  I make lots of small commits and then package them up to ship them out.
<aisa>
I don't object, remove it.
<aisa>
make sure you get both of them.
<wolfspraul>
xiangfu: do you agree we can remove the 'git fetch origin' in the wiki?
<wolfspraul>
I am not 100% clear what it does, but it looks like not needed here...
<xiangfu>
wolfspraul: we can remove one.
<kristianpaul>
i think is just to make sure the local repo is up to date to the remote branch
<xiangfu>
kristianpaul: no. it's fetch all remove branch to local.
<xiangfu>
then we only have origin/openwrt_backfire. but we don't have the origin/openwrt_trunk branch.
<wolfspraul>
really?
<wolfspraul>
well maybe we should leave it in then
<xiangfu>
don't have it in local.
<wolfspraul>
then it sounds better to leave it in
<xiangfu>
kristianpaul: up to date is "git pull origin ...."
<kristianpaul>
xiangfu: ah ok
<wolfspraul>
if that's true I suggest to leave it in, so that someone unsuspecting who thinks he has everything now won't suddenly need to go online when looking for something in the trunk branch, only to discover that there was some detail he overlooked when 'getting the sources'.
<kristianpaul>
fecth is not pull i see
<wolfspraul>
I won't touch it now... it's a wiki :-)
<wolfspraul>
if someone feels strongly it shouldn't be there - delete it
<xiangfu>
by the way . we should run "git remote prune origin" in local to remove the useless remote branch. or the 'master' and 'xburst' will be still there.
<kristianpaul>
hmm
<xiangfu>
kristianpaul: is there 'master' or 'xburst' in [git branch -a] ??
<kristianpaul>
xiangfu: both
<kristianpaul>
ahh wait
<kristianpaul>
i miss -a
<kristianpaul>
  master
<kristianpaul>
* xburst
<kristianpaul>
  remotes/origin/HEAD -> origin/master
<kristianpaul>
  remotes/origin/openwrt_backfire
<kristianpaul>
  remotes/origin/openwrt_trunk
<kristianpaul>
xiangfu: ^
<wpwrak>
(btw, regarding /tmp, assuming the system is quiet and it's okay to risk upsetting it: mkdir -p $HOME/tmp; export TMPDIR=$HOME/tmp; sudo chown 750 /tmp; then see what happens :)
<kristianpaul>
wolfspraul: the tmp is on openwrt folder
<xiangfu>
kristianpaul: ok. then not need "git remote prune origin", but you need "git remote set-head origin openwrt_backfire" :-)
<kristianpaul>
wolfspraul: you mean a home/tmp jsut in case?
<wpwrak>
kristianpaul: you mean me ? :)
<kristianpaul>
wpwrak: you
<wpwrak>
kristianpaul: i meant just to take away access to the "bad" tmp (thought you guys meant /tmp). so anything that tries to access it will fail.
<kristianpaul>
ah ok
<kristianpaul>
yes i see the point now :)
<kristianpaul>
i must leave see you on monday :)
<wpwrak>
of course, you better hope it doesn't do things like ... cd /; cd tmp; cd my_dir; rm -rf *Â Â :-)
<kristianpaul>
lol
<wpwrak>
(of course, if it does, it may be rather interesting to find about that, too :)
<wpwrak>
kristianpaul: have a nice offline weekend ! :)
<wolfspraul>
I will continue with hopefully cleaner OpenWrt configs tomorrow... n8 everybody
<aisa>
co'o la'oi wolfspraul
<kristianpaul>
noches wolfspraul
<wpwrak>
larsc: if i get a project's kernel tree that tracks upstream, what would be a quick way to find out if it has decent support for the Ben ? e.g., what file(s) should i look for that have/has the "latest important changes" ?
<wpwrak>
larsc: ah, i think i found it. arch/mips/jz4740/Kconfig should be a good hint. hmm, seems linux-zigbee won't catch up before 2.6.36.
<tuxbrain2>
urandom__: hi
<urandom__>
tuxbrain2 oh hi
<tuxbrain2>
sorry I ask you a question about the port on supertux, but I can't connect until today
<tuxbrain2>
what's the status on it? any port on openwrt or jlime?
<urandom__>
there is a supertux version for dingoo i got to work on nanonote but it crashed when you had done a level, shouldnt be to hard to fix i think
<tuxbrain2>
I'm collecting cool games to include on NN , until now I got prboom, hexen, heretic, gnurobo(really addictive), blockrage,  running awesomly on jlime
<tuxbrain2>
also freenukum
<tuxbrain2>
I hope when bartbes finish also to port love, we can increase the number, but super tux will be a really hot stuff to include.
<urandom__>
supertux shouldnt be much work, its just someone has to do it and i dont feel like it
<tuxbrain2>
well guys, two really intensive days in valencia spreading the copyleft hardware word to a crowd of very interested university and enterprise guys on embedded computer, to much tired, but very happy, I think a bunch of SIE boards will have soon home in various universities in south of spain, and new company espcializedn in artificial vision willing to collaborate on Milkymist  proyect on the FPGA part, with an eye on Xue. now time to some sleep.
<tuxbrain2>
urandom__: ok no problem we will find out a solution :) regards and goodk8
<tuxbrain_away>
btw: Nanonote was the start in our table in the clousurance dinner you will see the pics later on
<tuxbrain_away>
start->star
<mth>
tuxbrain_away: what are the criteria for inclusion? openMSX (MSX emulator) is GPL and the BIOS it uses is BSD licensed; there is a lot of freeware MSX software to run on it but most of that does not come with sources
<aisa>
I'm trying to make my first commit openwrt-packages.  *crosses fingers*
<wolfspraul>
aisa: after sleeping over my suggestion last night, now I believe the branch names tracking_trunk and tracking_backfire would be better :-)
<wolfspraul>
I need to become more calm...
<aisa>
ha!  all right.
<aisa>
well, we fixed it once already...
<aisa>
have you made the change yet?
<aisa>
new change, that is.
<wolfspraul>
no, not again. I'm quiet.
<aisa>
When I try to commit,
<wolfspraul>
but personally I now agree Xiangfu was right, openwrt_backfire may make some people believe that this is in fact the openwrt_backfire repository, but it is not.
<aisa>
I'm currently getting an error message.
<wolfspraul>
tracking_backfire would be clearer
<aisa>
I can agree to this, it is a very good point.
<wolfspraul>
ok, what do you get?
<aisa>
well, I pulled this repository anonymously.
<wolfspraul>
you can try to edit .git/config
<aisa>
using git pull this way,
<aisa>
it works.
<aisa>
but yes, I want to add my username.
<wolfspraul>
url, should be url = git@projects.qi-hardware.com:openwrt-xburst.git
<aisa>
is it my projects.qi-hardware.com username?  alanpost?  or is it my unix account name, 'a'?
<wolfspraul>
can you look in your .git/config, see what the url is and change it to the one I just wrote?
<aisa>
Obviously, I could not test this package, as my NanoNote is still 1000 miles away.
<aisa>
But I tested what I could.
<wolfspraul>
maybe you are the first NanoNote customer ever to commit a package before even receiving the device.
<wolfspraul>
aisa: btw, when you get the device and turn it on - don't worry about the flickering. it's a software bug :-)
<wolfspraul>
the LCM itself is rock stable, we have been able to fix some of those bugs recently so newer images should be better
<aisa>
Sorry, I was afk.  I am happy to be the first to commit a package before receiving my device!
<aisa>
I wanted to ask:
<aisa>
I'm going to get my device, then I will be away from the internet for several days.
<aisa>
I guess I should not flash the machine, and deal with the flickering,
<aisa>
and then flash when I come back and start to debug the instability.
<aisa>
As in, the testing images aren't stable enough to play around with?
<wolfspraul>
hmm
<wolfspraul>
most of the 'playing around' with will be flashing & trying (installing) software
<wolfspraul>
you should try Jlime and Debian too, if you are really adventurous even Iris?
<wolfspraul>
but all of this will require internet access, download this and that
<wolfspraul>
that's exactly our big problem, that as of today we haven't been able to bring a lot of good stuff into _one_ image in NAND, and ship devices like that
<wolfspraul>
maybe Jlime actually has the best all-around experience right now
<wolfspraul>
I don't know, hard to compare
<wolfspraul>
Debian also of course, but it's very slow, slow boot time, too little memory
<mth>
aisa: if you can generate a NAND image, qemu-jz should be able to run it
<aisa>
interesting.  I read that you selected OpenWRT because it was what you used on OpenMoko and were therefor familiar with it.
<aisa>
I certainly have an interest in having a stable platform to build from.
<wolfspraul>
the NanoNote should have a 06-15 image on it. I doubt you can spend several days just with it (offline).
<mth>
and added things like support for larger NAND chips
<wolfspraul>
aisa: that's what we are working on here, to fill those 2 GB with some really valuable stuff! :-)
<wolfspraul>
aisa: for OpenWrt vs. OpenEmbedded, it's a long story
<aisa>
The last time I was involved in embedded linux, it was with OpenEmbedded.  But that was many years ago.
<wolfspraul>
what I like about OpenWrt is that it seems to function well as a kernel development and upstreaming environment
<aisa>
mth: I've "watched" your github project to bookmark it, so I can come back to it.
<wolfspraul>
maybe because of the way the patches are managed, in individual files etc.
<wolfspraul>
then it's easier to make images with fast bootup times
<wolfspraul>
I don't like bitbake (a tool in OpenEmbedded), feel much more comfortable with the Makefile driven approach in OpenWrt.
<wolfspraul>
but then, the Jlime people use OE and they are able to make great images
<aisa>
The thing I notice about OpenWRT is that it is very basic.
<aisa>
So if you want an advanced runtime environment, there is a lot of work to do on the infrastructure.
<wolfspraul>
I would have no problem reflashing Jlime onto NanoNotes and shipping them out like that, as long as the patent problems are addressed (another story), and maybe in a dual-boot config with OpenWrt? don't know...
<wolfspraul>
aisa: what are you missing mostly?
<aisa>
Oh, I'm going to have to write packages for nearly everything I want.  My version 1.0 dream is to have an environment to study lojban.
<aisa>
this means: dictionary, parser, and flashcard program.
<aisa>
I just uploaded the dictionary.
<aisa>
NanoNote will very easily support this.
<aisa>
My longer term dream is to have a Tex environment and the ability to view .dvi files.
<aisa>
I want to display typeset text with embedded images.
<aisa>
basically, I want to display the following .pdf file:
<aisa>
Outside of being a study platform, I kind of plan to stick to the terminal:
<aisa>
vi, wordgrinder, and sc.
<aisa>
I'm in the middle of writing up longer-term vision type documents.
<aisa>
As to what kind of environment I'd like to see.
<aisa>
I don't really know if it will be broadly appealing.
<wolfspraul>
just reading about Lojban on Wikipedia :-)
<wolfspraul>
interesting, never heard about it
<aisa>
ah, wonderful.
<wolfspraul>
I think we already have a lot of stuff working on the NanoNote, just not all coming together in one image.
<wolfspraul>
so if you can help with that process (which you started with already) - great!
<aisa>
Well, that means at least there are patches to make something work.
<aisa>
I'm quite happy to work on making the images generally better,
<aisa>
while pursuing the packages I'm personally interested in.
<wolfspraul>
well give you one example. there are 85 subdirectories (apps or libs) in openwrt-packages now
<wolfspraul>
they were all specifically done for the Ben NanoNote, otherwise how could they end up on the qi server
<wolfspraul>
and they all worked at some point, for someone, in their build environment
<wolfspraul>
but as of right now, 22 are marked BROKEN
<aisa>
I find it odd they aren't first arranged by category, because as more get added...
<aisa>
Oh wow.
<aisa>
that is too bad.
<wolfspraul>
and from the other 63, there may be a lot that just build, but don't really work
<wolfspraul>
because:
<wolfspraul>
no definitely app list to check release images against, so things 'drop out'
<wolfspraul>
config file system broken, config files are too big and changing too much so diffs are huge and cannot be reviewed
<wolfspraul>
no test plan, so it's nearly impossible to avoid regressions in images, because nobody even knows what to test :-)
<aisa>
my config file system, do you mean /etc/* or do you meen config.full_system?
<wolfspraul>
OpenWrt configs
<aisa>
s/my config/by config/
<aisa>
yes, ok.
<aisa>
What is the one sentence or one paragraph vision of Ben NanoNote?
<aisa>
I ask because I need to keep a vision in mind as I work on this,
<wolfspraul>
people have done some cool stuff, like imgv, NanoMap
<aisa>
so I can use it to make decisions.
<aisa>
Also, after answering that, please make this idea better.  It is the best one I've got:
<aisa>
What if we created an x86-flavor of our build, something we could run in qemu?  That way we could test without having to flash a device?
<aisa>
My second-best answer is to keep a device plugged into a build computer for testing.
<wolfspraul>
I prefer to make working with the device easier, faster.
<aisa>
This is good.  I saw on the wiki brainstorm sessions about use cases.  That was very valuable, but a clear vision did not emerge from it, as far as a target market.
<aisa>
to which I could ask: What are we making easier?
<aisa>
easier to hack on?  easier to use for a particular task?
<wolfspraul>
for now I can only describe the technical challenges, it's too early for me to focus on applications as seen by the user. of course that is the goal later.
<aisa>
that is perfect.  It gives me a very clear idea about what is next.
<wolfspraul>
on the technical side, updating the software on the device is still very weak, and syncing data with a notebook/desktop is also weak.
<aisa>
I agree.
<wolfspraul>
those are 2 big areas that are very important and a foundation for anything that comes later.
<wolfspraul>
how to update, how to sync
<aisa>
I remember watching SquashFS projects wither on the vine for this very reason.
<aisa>
It isn't clear to me what kind of relationship we have with openwrt.
<aisa>
namely about getting patches moved upstream.
<aisa>
Is anyone at qi-hardware also on the openwrt project?
<wolfspraul>
yes there is overlap. Qi hardware is a copyleft hardware project, OpenWrt is a free software distribution.
<wolfspraul>
so in a perfect world, we could just always use OpenWrt upstream to build our software. but realistically we may want to keep some local stuff, like the config files, maybe some experimental/development boards that OpenWrt is not interested in, etc.
<aisa>
I think you are correct.
<wolfspraul>
but I would like to get anything into a state and quality that it would become acceptable in OpenWrt proper
<aisa>
This is good to know.  And I like this plan.
<wolfspraul>
in fact some people do XBurst hacking right in OpenWrt upstream.
<wolfspraul>
there are two repositories: openwrt-xburst and openwrt-packages
<wolfspraul>
openwrt-packages will not go upstream, unless some other package feed wants to carry these packages. openwrt-packages is to get new packages, new apps, into OpenWrt
<aisa>
That was a question of mine.
<wolfspraul>
so if a package already exists somewhere else (as a feed), and we want changes, we would try to send our patches to that location
<aisa>
It seems we have a mission slightly different from OpenWRT.
<wolfspraul>
we had this once with joe & qijoe, I forgot the details of the solution but there was some solution.
<aisa>
We want features that may not be appropriate for wireless routing.
<wolfspraul>
sure we are building images for specific devices, but OpenWrt is a build system
<aisa>
That helps me very much, thank you.
<wolfspraul>
OpenWrt is not just for routers, I think it's fair to say that that is only the origin nowadays.
<aisa>
good.
<wolfspraul>
so with openwrt-xburst, it's a bit different. ideally the diff between that and upstream should be zero.
<wolfspraul>
if it's not zero, we will work towards zero, unless there are really one-off or Qi-specific things like config files, prototype boards and such
<wolfspraul>
so in the upstream strategy, openwrt-xburst and openwrt-packages are very different
<wolfspraul>
openwrt-packages is a permanent OpenWrt package feed with new apps that we couldn't find in other package feeds
<aisa>
Yes, I am happy to hear this.  It matches what I would want to see.
<wolfspraul>
if a package is in openwrt-packages that also shows up elsewhere, we should try to reconcile with that repository
<wolfspraul>
the 'qijoe' package needs to be cleaned up, we don't want to prefix packages with 'qi' (there was a big thread about this, like I said I forgot the details of the solution)
<aisa>
The actionable direction I have taken from this conversation is this:
<aisa>
That we need to document and formalize our build system, and in so doing improve our testing procedures.
<aisa>
The measure of how well we do this is in the number of packages not marked broken, and perhaps the number of packages included in the base system image.
<aisa>
Oh, and that the first goal is to make it easier to move data between a Ben NanoNote and another computer: images, repositories, packages, and data.
<wolfspraul>
for the last one more specifically, how to update software on the Ben, how to sync (backup) user/original data from the Ben
<wolfspraul>
'move data' sounds very abstract
<aisa>
Good, thank you.  I'm going to clean this up and put it on my product backlog.  Probably at this point as a theme rather than a task.
<aisa>
I will decompose it into tasks as I get there.
<aisa>
You can say that again when we achieve the goal :-D
<wolfspraul>
aisa: do you have a problem in naming the 2 branches in openwrt-xburst tracking_trunk and tracking_backfire?
<wolfspraul>
when xiangfu is back I will ask him what he thinks :-)
<aisa>
I think tracking is a better name, so I support this.
<aisa>
I'm surprised no one complained in the last many hours on the mailing list.
<aisa>
so we should take advantage of this and rename them again!
<wolfspraul>
we haven't emailed the list yet (quite a few people will need to update their local repos), so renaming again quickly should do little damage
<wolfspraul>
yes, that's exactly how I think :-)
<wolfspraul>
well there are not that many people who have the tree locally, maybe 10-20 I would estimate
<aisa>
I'm really amazed you build this device with so few people.  You're really awesome.
<wolfspraul>
and not many active contributors _right now_, partially because the process of stuff getting into images is very slow, so it doesn't encourage quick feedback and progress
<wolfspraul>
the last usable image was 06-15, 3 months ago :-)
<aisa>
As soon as we fix that we'll have to decide what is worthy of being in the image.
<aisa>
not that I'm saying we shouldn't get there as soon as we can.
<wolfspraul>
so you can imagine even someone who commits an app doesn't expect feedback, or the need for a better version, for at least 'a couple of months'
<wolfspraul>
maybe we are overdoing the SlowFi lifestyle a bit
<aisa>
Was this true of the Neo too?  Or is it unique to the NanoNote?
<wolfspraul>
if a new image could come out once a month, or later even some other way to upgrade software (smoother, not needing a full reflash), that would be cool
<aisa>
I agree.
<aisa>
Of course, a new image coming out every month will also mean we'll need something interesting.
<aisa>
either from upstream or packages that people have written.
<wolfspraul>
oh there is tons of stuff
<aisa>
but releasing often can come first.
<wolfspraul>
we just have to package it right
<wolfspraul>
that's what we are talking about here
<aisa>
good, ok.
<wolfspraul>
too many regressions so far, too much chaos over which apps are in, out, broken, buggy, etc.
<wolfspraul>
if I see all the individual success stories of people talking about app a, b, c, and imagine we could have all this happiness in one image - WOW!
<wolfspraul>
that's the challenge
<aisa>
I learned a lot from the lesson's learned document posted on the wiki.
<wolfspraul>
aisa: makfa-cli has no license?
<aisa>
It doesn't in the source code.
<aisa>
It does, in a looser sense,
<aisa>
in that it is hosted on github.org, which I believe has a standard by which to judge a project.
<wolfspraul>
that's not good, we do need to clarify that quickly. I would hesitate to include software with unclear licensing in the images, package repositories or Qi servers
<aisa>
Oh indeed.
<wolfspraul>
ah no worries you are doing the right thing, emailing the author etc.
<aisa>
If I don't get an answer, I'll either pull it or just never include it in the install.
<wolfspraul>
yes we need to spend some time to clarify this
<aisa>
I will say that everyone in the Lojban community uses this program, so I believe it is an honest oversight.
<wolfspraul>
sure, like I said I appreciate you are going after this. it's good!
<wolfspraul>
we really try to do a very clean and proper job on the freedom side.
<aisa>
I notice we don't even, say, link to the debian free software guidelines.
<wolfspraul>
a BSD license would be enough, even public domain :-)
<aisa>
so we don't have official guidance on the wiki, as to what our definition of free software is.
<wolfspraul>
but the author has to clarify the license
<wolfspraul>
it's funny but Debian includes patented codecs that can cause problems for us, so in general we avoid direct links to it
<wolfspraul>
there's nanohacks.org :-)00000
<aisa>
aha, I didn't know that.
<aisa>
I just discovered this site :-)
<wolfspraul>
that is nebajoth's site, not very active right now but he will definitely get back to it later, I think
<nebajoth>
for sure
<nebajoth>
I'm down but I'm not out
<nebajoth>
when I try to power on the NN, it says "Wrong Image Format for bootm command"
<nebajoth>
ERROR: can't get kern!@#*$(@#)$*
<aisa>
wiggle the cord?
<aisa>
:-(
<nebajoth>
no, I'm sure I've compiled the kernel wrong
<nebajoth>
its 2.6.36
<nebajoth>
it was my first kernel compile for the unit
<nebajoth>
bound to fail
<nebajoth>
just not sure yet what I did wrong, as I haven't had time to investigate too closely
<nebajoth>
its not a built environment failure, since I compiled ON the nanonote itself
<wolfspraul>
nebajoth: how long did that take?
<nebajoth>
I recorded it, but its on the other computer
<nebajoth>
I believe it took about 4-5 hours
<nebajoth>
iirc
<wolfspraul>
not too bad
<nebajoth>
actually I was pleasantly surprised
<nebajoth>
I do remember that
<nebajoth>
I expected it to be still going when I woke up the next day
<nebajoth>
I intentionally did it last thing before bed
<nebajoth>
it'd be faster if it didn't have to swap to the sd card
<nebajoth>
I bet
<nebajoth>
I had zram compiled in and used the new mainline nanonote support and everything
<nebajoth>
I wonder if I didn't prepare the resultant kernel image in the proper way
<wolfspraul>
wow nice, but... :-) it didn't boot :-)
<nebajoth>
yeah
<nebajoth>
almost only counts in handshoes and hand grenades