<kyak>
xiangfu: now that gmenu2x is running from initd, setfont2 has to be invoked manually each time -\
<wpwrak>
rafa: wheee !
<wpwrak>
rafa: just poking around the jlime resources ... regarding PS1='\h$ ', why not PS1='\h\$ ' ? (in case you haven't found this one already)
<wpwrak>
rafa: if i install jlime and i want to compile a "hello world" for it, how do i do this ? i.e., what do i install on my host and what do i put into my Makefile ? (i hope the answer to the first question isn't "OE" ;-)
<rafa>
wpwrak: the prompt was meant to use a short space on the current line.. but it shoulg be \h\$
<rafa>
and your PATH should be something like PATH=$PATH:/usr/local/jlime/mipsel-toolchain/usr/bin/
<rafa>
under /usr/local/jlime/mipsel-toolchain/usr/bin/ you will find th
<rafa>
e mipsel-toolcahin-* gcc and friends
<rafa>
wpwrak: because this toolcahin comes from OE it will complain if you try to build with it using something like -I/usr/include or -L/usr/lib (it does not like if you try to use your host headers or libs)
<rafa>
GCC should be mipsel-toolchain-gcc , LD should be mipsel-toolchain-ld .. etc.
<wpwrak>
rafa: btw, the toolchain shouldn't really need -I and -L for standard includes/libs. but let's see ...
<wpwrak>
rafa: btw, all the directories in that URL are inaccessible. that's not so nice. e.g., when a URL changes, one can often find the right name by searching around a bit. if directory listings are blocked, you don't have a chance
<rafa>
wpwrak: (toolchain): no idea.. I have had problems with the toolchain complaining when some Makefile spec /usr/lib or /usr/include
<wpwrak>
hehe, a toolchain with /etc/rc* ;-)
<wpwrak>
yes, if they specify -I and -L of absolute paths directly, they're doomed
<rafa>
wpwrak: ha.. (stuff on toolchain) ..: that comes from extra libs I would say (from packages I unpackaged under toolchain)
<wpwrak>
it tries interesting paths ;-) /mnt/sda6/programas/stuff/tmp/staging/mipsel-linux/lib/mipsel-linux/4.4.2/crt1.o
<wpwrak>
there's a bit of weird stuff, e.g., /usr/local/jlime/mipsel-toolchain/usr/bin/../lib/gcc/mipsel-linux/4.4.2/../../../../mipsel-linux/lib -> /mnt/sda6/programas/stuff/tmp/staging/mipsel-linux/usr/lib
<wpwrak>
i wonder if the toolchain is really fully relocatable in general. it's very close to working, but ...
<wpwrak>
anyway, i'll be back after a nap
<rafa>
wpwrak: at least it does not try /porn_downloadedbysister/ or stuff like that :) .. Those paths are from the host built. THere are few recipes to build an external toolchain. I will buid and I will upload
<wpwrak>
yeah, such paths could be revealing ;-)
<wpwrak>
(ext toolchain) great, thanks !
<wolfspraul>
rafa: are we ready to move to the dual-booting stage?
<wolfspraul>
maybe we need another (hard-coded) partition scheme for that :-) how about this: 4 mb u-boot, 8 mb kernel1, 8mb kernel2, 512mb rootfs1, 512mb rootfs2, rest is (ubi-formatted?) data partition?
<kyak>
lol
<kyak>
talks about another change :)
<kyak>
how about 5 kernels?
<wolfspraul>
kyak: so how would you go about the jlime/openwrt dual booting?
<kyak>
wolfspraul: do you plan shipping new devices with two operating systems?
<kyak>
this might be so very confusing
<kyak>
i imagine that i buy a new phone, switch it on and have two options to boot
<wolfspraul>
kyak: I can't make decisions so broadly, there are too many pros and cons.
<wolfspraul>
of course asking "do you want jlime or openwrt?" is, well, laughable :-)
<wolfspraul>
and all sorts of solutions can be imagined, too many (and too many pros and cons for each) to discuss.
<wolfspraul>
so I rather go along very practical lines.
<wolfspraul>
do we have a Jlime image now? yes
<wolfspraul>
is it patent-safe so that distributors can (with some certainty) resell NanoNote with that image? yes
<wolfspraul>
is the image functional? many people like it, so yes
<wolfspraul>
so if that's the case, wouldn't we want to make it easier for people to try out this work? especially considering that we ship the NanoNote with a >80% empty NAND?
<wolfspraul>
I think yes, we should make that easier.
<wolfspraul>
why not? why is that a bad idea?
<wolfspraul>
my biggest concern is how maintainable the image is, especially on the patent side. But I think we can be assured by rafa and the Jlime crew, these guys are in for the long run.
<wolfspraul>
mirko: hey good morning :-)
<wolfspraul>
I'm writing an email with some of my image observations/testing now
<wolfspraul>
I only ran into 1 big bug, I think: I cannot quit NanoMap (it hangs), and kyak and others think that in general every Qt app will hang on exit.
<kyak>
wolfspraul: we need to come up with some plan, to fix partitions once and for all..
<wolfspraul>
kyak: what exactly bugs you about the partitions?
<wolfspraul>
what does the 'fix' need to make easier?
<kyak>
i don't want to save and move my data often
<kyak>
in fact, i even stayed with 256 Mb because i don't want to move my data
<wolfspraul>
so basically your data starts at 4+4+256=264MB, and then to the end of the 2GB?
<kyak>
indeed
<kyak>
it doesn't occupy all available space though
<wolfspraul>
and as we are coming out with new stuff, you don't want to move those 1.7GB around all the time...
<wolfspraul>
what filesystem are you using for your data partition?
<kyak>
it's ubifs
<kyak>
it's just a usual data partition
<kyak>
per instruction in wiki
<wolfspraul>
ok let me just get a complete picture now - at which mountpoint do you have it mounted?
<kyak>
/data
<wolfspraul>
and if you stay with the 256 MB layout, that means you will not be able to reflash rootfs images if they become larger than 256 mb?
<kyak>
yes, this is right.. but my customs images won't get bigger than that
<kyak>
i've thrown away unnecessary things
<kyak>
like php or ruby, and many other i won't ever need
<wolfspraul>
ok so you are building your own openwrt rootfs anyway
<kyak>
yeah..
<wolfspraul>
but if the partition map is hardcoded in the kernel that's yet another thing you need to fix before building your stuff?
<kyak>
yes, this is what i have to do
<wolfspraul>
how full is your data partition?
<kyak>
it's usually arounf 1 Gb full
<kyak>
sometimes i fill it completely with movies
<wolfspraul>
ok needs some thinking :-)
<wolfspraul>
I'd say no worries, if your life doesn't get easier we are doing something wrong...
<kyak>
wolfspraul: don't waste your time thinking about it.. it's not so hard for me to make some changes to hardcoded partitions
<kyak>
before i build
<wolfspraul>
so as long as you give some feedback, if we (or me :-)) are coming up with stupid ideas, they should get corrected before they can cause damage... :-)
<wolfspraul>
sure I can understand, but still
<wolfspraul>
those are good use cases you have there
<wolfspraul>
in marketing speak, our 'upgrade story' is still very very bad
<wolfspraul>
and if you look at successful computing devices, it's always those with the best 'upgrade story' that have a chance to become really successful
<wolfspraul>
whether that's installing apps, or OS updates, or good backups (device lost/stolen), etc. etc.
<wolfspraul>
so we have quite a way to go there...
<wolfspraul>
I'm definitely not only thinking about the "how can I reflash stuff" side of things. you are one step ahead. you have 1gb of data in your nand that you want to protect.
<wolfspraul>
makes perfect sense!
<kyak>
i think the project right now in the state when it is still possible to make really big changes.. but with the time, it would not be possible any more
<kyak>
xiangfu: nanoterm looks interesting, but it's not usable?
<kyak>
i can type (in capital letters for some reason), but nothing happens
<xiangfu>
kyak: someone write a terminal only for NanoNote. so we would like included by openwrt-package.git
<kyak>
xiangfu: btw, i'm fighting with strdict -\ it hangs at start
<kyak>
with strace i see that one of the threads is segfaulted
<kyak>
i believe i might be because i have a somewhat minimal installation in comparison to you.. maybe stardict lacks for some library at start (though it builds fine)
<kyak>
maybe you have some idea?
<wolfspraul>
xiangfu: are you aware of any downside of disabling syslogd and klogd?
<wolfspraul>
kyak: looking through the process list I also noticed a lot of 'loggers', if you think those 2 can be disabled then yeah, unless someone complains let's do it
<xiangfu>
wolfspraul: I don't know that.
<xiangfu>
kyak: does the "loading " windows show up??
<kyak>
xiangfu: yeah, it hangs right ther
<kyak>
at "Loading"
<wolfspraul>
xiangfu: if you don't know, then I'd say let's remove them. even if there is a good reason, we will surely find it after removal :-)
<kyak>
wolfspraul: another thing to free a little memory - disable unused ttys in /etc/inittab
<kyak>
i think tty3 and tty3 are not needed.. maybe tts is also not needed
<kyak>
*tty3/4
<wpwrak>
wolfspraul: (loggers) i would consider data on such a device as ephemeral anyway, particularly considering that people often upgrade their system by wiping out entire partitions
<kyak>
wpwrak: those are not logging to file anyway
<kyak>
they log somewhere in the memory, can be accessed with "logread"
<kyak>
totally useless
<wpwrak>
wolfspraul: so there's little point in filling them with log data. sometimes, it can be useful to be able to enable temporary logging, though. e.g., to debug ssh problems. of course, the way dropbear fails usually means that you'll only find out with strace anyway ... :)
<wpwrak>
kyak: (log to memory) ah, that's actually a bit more reasonable. but probably still not worth the effort.
<kyak>
yeah..
<kyak>
xiangfu: what do you think about adding tcl to full_system?
<wolfspraul>
kyak: how can we remove tty3/4/s?
<kyak>
wolfspraul: just comment those line in /etc/inittab
<kyak>
*lines
<wolfspraul>
kyak: except for tcl, are there any other things you have enabled that are not in full_system?
<kyak>
wolfspraul: i don't think so...
<bartbes>
hmm has tk been ported?
<kyak>
haven't seen it there
<kyak>
wolfspraul: have abook enabled which is also not in full_system
<kyak>
(and MPlayer, but this one is build patented)
<wejp>
why do you want to remove the other virtual terminals?
<kyak>
to save memory; they are not used most of the time
<wejp>
but then you can't do any multi-tasking anymore
<wejp>
i don't think this is a good idea
<wejp>
and it doesn't really save much memory anyway
<kyak>
do you mean "you can't do three-tasking"? :)
<kyak>
use screen for that
<wejp>
screen uses alot more memory than some terminals
<wejp>
and is very slow on such machines
<kyak>
there are alternatives
<kyak>
tmux, for example
<kyak>
can you tell me about the use case?
<kyak>
how do you use those terminals on Ben?
<wejp>
everytime you want to run multiple applications at the same time
<kyak>
just give an exmaple
<wejp>
listening to music in the background and editing some files at the same time for example
<wolfspraul>
kyak: wejp btw, along the lines of screen, we now have this quite interesting byobu on the NanoNote
<wolfspraul>
but it's a screen enhancement, so if screen is slow or needs a lot of memory, this will need even more... anyway some of what they say sounds promising, I think
<bartbes>
something totally unrelated: every time I start the nn, especially whilst not at home, I feel kind of.. good, booting linux on an embedded device
<bartbes>
it's just a great feeling
<bartbes>
it feels like you're holding a lot of power in your hands
<wejp>
byobu... interesting
<kyak>
wejp: it's not a problem, cause gmu is not occupying the terminal
<bartbes>
wolfspraul: afaik byobu is mostly a set of config files for screen?
<kyak>
wejp: besides, i don't say to get rid of all terminals
<wejp>
then edit two files, or have one open for reference while editing the other
<wolfspraul>
bartbes: could be yes, I never got far beyond readon their project homepage. but it sounds cool :-)
<kyak>
wejp: well, my case might be special, i'm living happily without tty3 and tty4. i even use tty2 very rarely
<wejp>
yeah, i guess, but since there are other usecases as well, i think those terminals should just be kept as they are now
<wejp>
it really does not save much memory
<wejp>
a few KB at most
<bartbes>
so seeing as I just realized owrt has mutt, has anyone set it up in a particularly epic fashion? I can't imagine it being easy to use considering you normally lack internet, and it lacking a small pop and/or smtp server (afaik), so what is mutt used for?
<bartbes>
oh I seem to be asking random questions, do tell if I get annoying
<kyak>
wejp: not a few KB. each terminal is running init, it is 1620 KB
<wejp>
kyak, no it isn't
<kyak>
it makes 1620*3 useless KB for me
<kyak>
wejp: run top
<wejp>
these 1620 KB is shared memory and it is only used ONCE by all applications that are part of busybox
<bartbes>
wow, go busybox!
<wejp>
yep
<wejp>
that's why openwrt uses busybox
<wejp>
to use as little memory as possible
<wolfspraul>
bartbes: I should try mutt one day, I use it on my notebook. I would think I can use it first of all as a reader of my mail archives. for writing, I would need to think about the workflow, although I'm sure it's possible.
<kyak>
wejp: hm ok
<wejp>
that's why they all use the same amount of memory
<kyak>
wejp: how can i see RSS?
<bartbes>
wolfspraul: I guess it just needs to have a queue and a script which then mails it all (using sendmail?), if you then hook it up to udev it can all get very coolk
<bartbes>
*-k
<kyak>
bartbes: same as openvpn
<kyak>
i always wondered whe is it in full_system
<wejp>
mh, i think that depends on the top or ps version being used
<bartbes>
wolfspraul: atm however I get an error when I want to send (even though I'm connected to the internet), my guess is a lack of sendmail (or alternative, like exim)
<wolfspraul>
bartbes: which smtp clients are in openwrt and which one should we include in the image?
<bartbes>
I'll go research
<wolfspraul>
can't mutt speak smtp as well?
<kyak>
bassel: have a look at msmtp
<bartbes>
I believe it normally uses sendmail
<kyak>
bartbes: have a look at msmtp
<bartbes>
(or compatible alternative)
<kyak>
bassel: sorry :)
<wolfspraul>
I use mutt to do some mass emailing once in a while. but never looked deeper into what mutt actually does to get it out.
<bartbes>
kyak: I'll go check out mutt manual then decide what it needs
<kyak>
you can use whatever MTA you want with mutt
<bartbes>
wolfspraul: but I guess you *can* set it up to use smtp, since I think I do that on my desktop..
<kyak>
and mutt itself is not aware of smtp
<bartbes>
yeah, I guess it's all a matter of how it's set up
<kyak>
it needs MTA for that
<bartbes>
kyak: well, I just checked my muttrc and I directly use smtp
<bartbes>
(with ubuntu package)
<kyak>
can you show it?
<bartbes>
just smtp_url
<bartbes>
I'll go read the docs
<bartbes>
"Update: Recent versions (1.5.x) of Mutt has built-in SMTP support."
<kyak>
i'm so out of date :)
<bartbes>
and on the nn I have 1.5.20
<bartbes>
so that should work
<bartbes>
anyway, a sendmail equivalent may be easier, since it requires no setup, and has queueing, I guess
<bartbes>
interesting
<bartbes>
you can use ssh to execute sendmail on a remote system
<bartbes>
btw, what packages are built automatically?
<bartbes>
(and as such added to the repos)
<wpwrak>
wolfspraul: what's the successor of the ya in the ben-ya-... naming scheme again ?
<wolfspraul>
ben-ya-mu-guo
<wolfspraul>
bartbes: what do you mean?
<wpwrak>
thanks !
<wolfspraul>
first we have config.full_system
<wolfspraul>
that's like an 'all-inclusive' of apps that work well on the NanoNote. as long as they don't increase boot time, or memory usage, at the moment we are just adding anything there that someone finds useful.
<wolfspraul>
then we _should_ also build all packages (as separately installable .ipk files), but we haven't done so since April
<wolfspraul>
at least we have a buildhost machine now, so give it another month or two and this should work as well
<bartbes>
kyak: I guess mutt was built without smtp
<wolfspraul>
bartbes: if you have suggestions on what to add, please just list them here and we'll do it. or of course you can edit/commit to config.full_system yourself
<wolfspraul>
did this answer your question?
<bartbes>
yeah, and then some :P
<wolfspraul>
bartbes: for one, I would love to have great love support on the NN :-) and lots of preinstalled love games...
<wolfspraul>
so if you have pointers, please holler
<wolfspraul>
I saw nlove is already in the latest image, not sure how functional it is right now, or whether there are any games in the image as well.
<wolfspraul>
we'll get there...
<bartbes>
no games yet
<bartbes>
(in the image)
<bartbes>
anyway, I just sent the first mail via mutt + msmtp
<bartbes>
now let's see if I receive it
<bartbes>
and then see what happens when I unplug the nn
<bartbes>
humm, the message was received on the smtp server, but then timed out when trying to forward to gmail smtp servers
<bartbes>
:(
<bartbes>
but hey, at least it works thus far
<bartbes>
alright, so that works
<bartbes>
and msmtp errors..
<wolfspraul>
you want to say the NanoNote is already more reliable for email than gmail?
<wolfspraul>
:-)
<wolfspraul>
but it sounds like we should include msmtp
<bartbes>
once I figure out how I can get it to queue it'll be fully working
<bartbes>
and even if that isn't the case, that + a default muttrc makes for a working mutt
<bartbes>
I see, there's a msmtpq script, which I guess needs to be included in the package
<xiangfu>
kyak: about tcl, it's ok to me. just add it to config.full_system (since it's not auto start when boot :)
<wolfspraul>
when I am in gmenu2x, is there a way to close it (exit the process)?
<bartbes>
I think there was..
<bartbes>
I can't find it though
<wolfspraul>
short of 'kill `pidof gmenu2x`' which is what I do normally
<bartbes>
I guess you could create a 'close' launcher
<wpwrak>
no killall ?
<wpwrak>
bartbes: + to launch, - to kill :)
<wolfspraul>
wpwrak: good idea, forgot
<wolfspraul>
killall is there...
<bartbes>
wpwrak: ?
<wolfspraul>
a 'close' launcher is a nice idea, the only problem is with someone who accidentally closes it and then doesn't know how to return
<xiangfu>
I just add a "ash" and "bash" in gmenu2x.
<wolfspraul>
which one is the best/recommended shell?
<xiangfu>
so if we want goto terminal we can use 'ash'
<xiangfu>
then "CTRL + D" or "exit" will return to gmenu2x
<wolfspraul>
maybe if we have two icons it adds more confusion than necessary, unless there are good reasons for both
<xiangfu>
wolfspraul: ash
<wolfspraul>
then I would suggest to not include a 'bash' icon
<wolfspraul>
my idea was not so much running a shell (that's another nice idea, I usually do ctrl-alt-f1 right now, but more options is good), my idea was to close the gmenu2x process to save memory
<wolfspraul>
but one by one
<wolfspraul>
launching a shell from an icon is nice, I like it
<wolfspraul>
xiangfu: is that what you added?
<bartbes>
I just added a launcher which just add prints some text (a thank you for using and then how to start gmenu2x again)
<bartbes>
which has the wrapper disabled, so it closes gmenu2x with a quit message
<wolfspraul>
xiangfu: when I run nightsky I get several error messages about missing files, then a segmentation fault
<xiangfu>
wolfspraul: yes, I have add two icon, "ash" and "bash",
<xiangfu>
I think we rename the "ash" to "Terminal",
<wolfspraul>
xiangfu: why do we need two icons? when would someone choose bash over ash?
<xiangfu>
wolfspraul: it's just one option for users.
<bartbes>
I made a vid of my launcher
<bartbes>
time to convert it to ogv
<xiangfu>
if we don't add the 'bash' , then do you think we should remove it from full_system?
<xiangfu>
wolfspraul: I will look into the nightsky later
<xiangfu>
bartbes: now we have add the "gmenu2x" to inittab. so when we clock the "Terminal" , it will exit the gmenu2x
<bartbes>
wait, what?
<xiangfu>
bartbes: s/clock/click/
<bartbes>
that close launcher actually just closes gmenu2x, it doesn't start a new shell
<bartbes>
:O
<xiangfu>
bartbes: yes.
<bartbes>
I know why my build of msmtp failed
<bartbes>
my / partition is full
<bartbes>
:(
<wolfspraul>
xiangfu: I don't think those 2 things are related
<wolfspraul>
one question is whether we add an icon for 'bash' in the launcher
<wolfspraul>
the other question is whether we add bash into the image
<wolfspraul>
I'm sure there are good reasons why to add it to the image, at least it's easier to imagine those.
<wolfspraul>
for I'm not so sure about the value of having 2 icons in the launcher, both launching a shell
<wolfspraul>
I think we are doing a better service by picking the better one of the two only, at that place.
<xiangfu>
wolfspraul: ok, now I understand. let's just remove hte 'bash' icon in gmenu2x.
<wolfspraul>
xiangfu: well, back to my question. what would be the reason that someone would choose bash over ash at that point (in the launcher)?
<wolfspraul>
I understand if a script needs bash-specific features, OK it refers to bash and bash needs to be there to run the script
<wolfspraul>
but for the 'manual' shell, I think we should pick what we believe is the most appropriate on the NanoNote, and only have an icon for that?
<wolfspraul>
how about fbterm?
<wpwrak>
for an interactive shell, i guess you'd want the "nicest". not sure how friendly ash is as an interactive shell.
<wolfspraul>
sure then let's do that. I'm just saying two icons, one for 'bash' and one for 'ash' is asking for trouble :-)
<wolfspraul>
I know it...
<wolfspraul>
next we have a third icon for zsh
<wolfspraul>
and so on
<bartbes>
fbterm makes more sense as a launcher in gmenu2x
<wpwrak>
too much of a choice is a bad thing :)
<wpwrak>
tcsh !
<wolfspraul>
bartbes: I think the problem with fbterm is that the nice small NanoNote fonts don't work
<wolfspraul>
I just started fbterm manually and it's ugly :-)
<bartbes>
I would say it would be capable of going smaller
<wolfspraul>
I guess I'm used to those nice polished fonts now.
<wolfspraul>
oh, and we should have an easy way to cycle through console fonts as well
<wolfspraul>
there is some command line that does it, but man it's long...
<xiangfu>
I am not thinking of the 'user experiment', I just think add one option to users. so I am not sure about this.
<bartbes>
you mean the fonts I think I don't have?
<bartbes>
so when is the first *stable* release going to be?
<wolfspraul>
maybe once we have this more general keymapper daemon (triggerhappy), we can have some nice key mappings to cycle through console fonts?
<bartbes>
because I'm still running 2010-06-15
<bartbes>
(with some updated packages)
<wolfspraul>
that's a good image, maybe we have a worthy successor soon...
<wolfspraul>
not sure about 'stable', we'll get there
<wolfspraul>
xiangfu: so basically you are saying 'ash' is the better shell for manual use, wpwrak says 'bash'
<wolfspraul>
I don't want to blow this discussion out of proportion, maybe add 2 icons for now, we can trim later :-)
<xiangfu>
'ash' is the default shell in openwrt. and it's busybox.
<wolfspraul>
that's good, saves memory
<wolfspraul>
so my vote is: for now only 1 icon, for ash
<xiangfu>
'bash' is separate.
<xiangfu>
wolfspraul: my vote. add one section in gmenu2x. name "Terminal", we list "ash(default)" "bash" "fbterm" "jfbterm" "nanoterm" :)
<xiangfu>
we add all terminal stuff in "Terminal" section.
<wolfspraul>
he
<wolfspraul>
FINE! :-)
<wolfspraul>
I like the (default) idea, if it's visible...
<wolfspraul>
that achieves 80% of what I had in mind...
<xiangfu>
BTW, I already add "Games" section, list all games.
<wolfspraul>
yes I saw it, nice
<wolfspraul>
once we can stabilize all this a little, I hope we can add some nice little scripts to bring out the functionality of some of the console apps we have
<wolfspraul>
for example sox
<wolfspraul>
if I just run 'sox' in the console, that's outright scary
<wolfspraul>
looks like 5 pages of options are scrolling by
<wolfspraul>
so maybe one day we can have a neat little script that just starts recording, saves it in a meaningful place with a meaningful name, and stops upon whatever action
<xiangfu>
there are so many apps  like 'sox'
<wolfspraul>
those recordings could then be listed and listened to in gmu maybe? well something like that...
<wolfspraul>
yes we need more scripts to bring out easy default functionality of those apps, and link them into the launcher
<wolfspraul>
needs a bit more time...
<xiangfu>
how about a script list all those apps
<xiangfu>
like:
<xiangfu>
Terminal Applications in NanoNOte:
<xiangfu>
sox -- sound
<xiangfu>
aplay -- play wav
<xiangfu>
arecode -- recode wav
<xiangfu>
...
<wolfspraul>
you can see a list with opkg list_installed already, not sure what you suggest
<xiangfu>
my idea is let users know there are some command he can try in terminal.
<wolfspraul>
opkg list_installed
<xiangfu>
oh. yes.
<wolfspraul>
plus we need a wiki page to document them, for several reasons (also to start specifying test steps)
<wpwrak>
(shell choice) i you have bash on your system, you'll almost certainly want bash. it's much nicer as an interactive shell. ash suffers the usual problems of busybox-ish things, with every once in a while something not working the way you expect. if you've chosen not to install bash on your system, then you should of course launch ash.
<wpwrak>
(shell choice) so maybe just call is "shell" and pick the best that's available
<wolfspraul>
and then we may need little 'script apps' to connect some of that stuff into the launcher, if a direct invocation is not enough (those are a good start for now)
<bartbes>
re recording, you could take a look at that new recording thing jlime has
<kristianpaul>
bartbes: awesome thing !
<kristianpaul>
rafa: :)
<bartbes>
can anyone tell me why I can barely control the output volume?
<bartbes>
if I set output volume to 0 in alsamixer it's still extremely loud
<wolfspraul>
chinese electrical design?
<wolfspraul>
:-)
<wolfspraul>
maybe we need a software volume control, is that possible?
<bartbes>
who knows enough about the hardware to know that?
<viric>
wolfspraul: alsa has something called "softvol", that many people use in the nanonote, I think
<viric>
(due to what I think are hardware problems in that volume)
<bartbes>
oh right, I was working on msmtp..
<wolfspraul>
bartbes: larsc does, but he repeatedly said on this channel things along the lines of "but i can tell you for sure that the hw only has 4 volume levels ranging from loud to very loud"
<wolfspraul>
viric: not a hardware problem, typical 'default' volume settings in China
<viric>
a loud coutry then
<wolfspraul>
yes it's crazy. with all culture respects, it's nuts.
<wolfspraul>
people are yelling and shouting everywhere.
<bartbes>
in that case we need global volume lowering
<wolfspraul>
they are selling toys here, they must be illegal in the US or Europe if only for sound volume. I mean those things are so crazy loud.
<viric>
It looks like here, immigration, use to go with loud music in speakers of mobile phones and alike, that give even a sound quality close to the 19th century
<wolfspraul>
not that the speakers are any good, the sound quality is also horrible. but I could show you a toy, with sound from say 1-7, and we would probably both agree only 1 is BEARABLE in an otherwise quiet room.
<viric>
And I'm sure not only immigration, and not all of the imimgration. But it's a phenomena I see mostly on them.
<wolfspraul>
2 and 3 remind me more of a rock concert or such
<bartbes>
viric: so, softvol, any more information?
<wolfspraul>
and for everything above that I am seriously questioning the sanity of anyone letting a child play with this thing...
<viric>
bartbes: it's usual alsa configuration. Nothing special of the nanonote.
<bartbes>
oh now I suddenly know..
<viric>
wolfspraul: well, western sanity on education is questionable maybe not in loudness, but in many other aspects :)
<wolfspraul>
fine but if I would demonstate those toys to you you would know what I mean :-)
<bartbes>
wolfspraul: btw, I checked and the scripts are there, they simply aren't installed
<viric>
:)
<kristianpaul>
wolfspraul: i tought volume control was a menu in gmenu2x
<bartbes>
so who has commit access to upstream packages?
<wolfspraul>
and btw, for phones, the #1 features many people care about is how loud the ringtone can be
<kristianpaul>
*a working menu*
<wolfspraul>
you can imagine them trying it out in a super noisy super crowded market, and you get the idea
<bartbes>
wolfspraul: you don't happen to have access to the upstream 'packages' repo?
<wolfspraul>
no I don't, but you can send a patch to the qi list or openwrt-devel list right away. or xiangfu can do it for you.
<wolfspraul>
depends on whether your improvement is generic enough to be added there, or we keep it on the qi server?
<bartbes>
it's just installing some scripts which are pretty.. useful
<wolfspraul>
sure let's install them. so where are they and how can they be added?
<bartbes>
it's not like they're a separate download, they need no compile-time option
<bartbes>
they just need to be copied
<kyak>
xiangfu: there is no need to remove "bash" icon; gmenu2x won't display it if the binary is not available
<wolfspraul>
part of which package is this?
<wolfspraul>
let's just make a patch, send to openwrt-devel. if they don't like it we can always make a alsa-full package or so that we keep in openwrt-packages on the qi server
<bartbes>
I was talking about queueing in msmtp
<kyak>
wolfspraul: about the nightsky, you need to have /root/.nightsky.yml (see example in /usr/share/nightsky/)
<wolfspraul>
bartbes: oh I see. well it all starts with a patch. either someone likes it for upstream inclusion, or we keep it on the qi side.
<kyak>
wolfspraul: there is another thing is have different in my build.. a bunch of rc files in $HOME - .mplayer, .vimrc, .tclshrc, .nightsky.yml
<kyak>
i recreate them on every build
<wolfspraul>
how do you recreate them?
<kyak>
after reflash, i boot and run a script
<kyak>
every time i change soemthing in the system, i reflect it in that script
<kyak>
then i can reflash, run this script - and i'm restored
<kyak>
all my settings are safe
<wolfspraul>
hmm, on our side I guess we would need to look at those config options one by one and then at what the best way is to set them as default
<wolfspraul>
some ideas would be ugly, i.e. probably not wanted. like including /root/.nightsky.yml in the nightsky .ipk
<bartbes>
yay, a working queue!
<bartbes>
wolfspraul: alright, I guess I can create a package msmtp-mutt or similar, which just installs those queue scripts + a conf for mutt
<wolfspraul>
we could include them in the data/ rootfs section I guess, that would be a quick (if also ugly) bandaid
<bartbes>
but it gets ugly
<bartbes>
:(
<wolfspraul>
sure go ahead, then it's saved at least
<wolfspraul>
and we can see how/whether any of this should go upstream, or whether there is a cleaner way
<wolfspraul>
first the hack, then the cleanup :-)
<bartbes>
good
<bartbes>
the hack I can do :P
<bartbes>
I'll make the version the number of msmtp, because that would be the version of the scripts
<kyak>
wolfspraul: i was thinking about including some of those configs.. maybe not with ipk, but from data/qi_lb60/files/.. but it might be that the package is not really installed
<kyak>
so the config is not really necessary
<bartbes>
how do I make it depend on *either* msmtp or msmtp-nossl?
<bartbes>
(or does that happen automatically when I specify the generic name, and no variant?)
<wolfspraul>
kyak: sure but when in doubt, pragmatism trumps, no?
<wolfspraul>
so those files are very small, and we know we have them in config.full_system
<wolfspraul>
even if people build their own rootfs, ok, they have a few small files they don't need. so what. I am sure there are many other things in the rootfs yet that could be optimized if we would identify them.
<wolfspraul>
bottom line: given that these files are really useful once the apps are installed, I think it's perfectly fine to add them to data/files for now, as a quick first solution.
<wolfspraul>
bartbes: don't know about the dependencies, maybe xiangfu knows?
<bartbes>
I'll just check in the menuconfig
<wolfspraul>
kyak: so how do you like the idea of committing your configs to data/qi_lb60/files ?
<kyak>
wolfspraul: thank you for allowing to do things that might be doubtfull :) this really helps bring the default image to my needs, and i can only hope that my needs are not so diferent from other people's needs after all
<bartbes>
:@
<bartbes>
I fail to get the scripts to be packaged
<kyak>
i thought it is not necessary to force it, because it wouldn't download locales by default.. but it seems that in some cases it still tries to do that
<kyak>
kristianpaul: you still need to clean your build root
<kyak>
and to git pull of course
<kristianpaul>
sure
<kristianpaul>
compiling now
<kristianpaul>
build root= ?
<kristianpaul>
bin flder?
<kyak>
by "buildroot" i mean openwrt-xburst directory :)
<kyak>
cleaning it is make clean and removing build_dir and staging_dir
<kyak>
this will start everything from scratch
<kristianpaul>
sure
<kristianpaul>
scratch include download tons of software again?
<kyak>
downloaded things get in dl/ dir
<kyak>
no need to delete that
<bartbes>
wolfspraul: so where should I put this diff (and how should I create it?)
<kyak>
make clean won't delete it either
<kyak>
kristianpaul: when you pass the uClibc prepare stage, would you be so kind to show "grep LOCALE build_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc/.config"?
<kristianpaul>
kyak: sure
<kristianpaul>
but how i know i pass it?
<kyak>
you'll see the message from make
<kristianpaul>
ok but i'm not follwing all time
<kyak>
like make[3] toolchain/uClibc/prepare
<kristianpaul>
k
<kyak>
make[3] -C toolchain/uClibc prepare
<kyak>
this one to be exact
<wolfspraul>
bartbes: how to create the diff? well you must have done something, first thing just document that?
<wolfspraul>
can tell you where to put it after I know what it is :-)
<bartbes>
I mean, I edited the msmtp Makefile
<bartbes>
but in what format do the openwrt guys like their diffs?
<bartbes>
urandom__: btw, haven't spoken to you in a while, have you seen what has happened to nlove lately?
<wolfspraul>
first guess would be unified diff, how big is the diff anyway?
<bartbes>
3 lines added + 1 line modified (release number)
<kyak>
kristianpaul: when it passes the uCLibc prepare stage
<kyak>
this file will appear
<kristianpaul>
ah so not yet
<kristianpaul>
:)
<kyak>
and you don't necessarily have to stop the build process, in case you've stopped it :)
<kristianpaul>
i just have one and less than 1gn in ram  core my machine is slow
<kristianpaul>
no i dont
<wolfspraul>
bartbes: well just email/upload/paste it somewhere, then we go from there...
<bartbes>
hmm but where
<kyak>
kristianpaul: i just discovered i can speak perfect Spanish ;)
<kyak>
No existe el fichero o el directorio
<kristianpaul>
No such file or directory
<wolfspraul>
bartbes: pastebin?
<wolfspraul>
if it's as short as you say it is, even our conversation lines about it here in the chat are longer...
<wolfspraul>
:-)
<bartbes>
true
<urandom__>
bartbes nah was busy with other stuff (learning languages) , so what happened?
<bartbes>
mostly music
<urandom__>
ah
<urandom__>
so where can i find the latest versions of nlove?
<rafa>
wolfspraul: I read the mirko mail.. he wrote: /etc/banner .. added by Y. I would suggest no to add many files under /etc.. so system is a little standar.. and great if it follows the Linux FHS (Filesystem Hierarchy Standard) or something like that. Adding files under /etc does the system odd for every new user.
<bartbes>
urandom__: it has been committed, but an ipk..
<bartbes>
I guess I can put one up
<rafa>
wolfspraul: BTW, I added a lot of crap under /etc on jlime.. but it was a really hobboy work.. I did not do it thinking
<kristianpaul>
kyak: it is fun, it is asking me again
<kristianpaul>
Support glibc's "'" flag for allowing locale-specific digit grouping (UCLIBC_HAS_GLIBC_DIGIT_GROUPING) [N/y/?] (NEW)
<rafa>
wolfspraul: that it would be great for future.. My
<wolfspraul>
rafa: agreed, if it were just me I wouldn't add that banner at all but if it makes others feel good, why not...
<rafa>
wolfspraul: idea was just to test different ideas.. But for a development thing /etc should be cleam
<kyak>
kristianpaul: this will not ask you anything.. however, i think your next error might be related to something else -\
<kyak>
setlocale(LC_CTYPE,"en_US.UTF-8") failed!
<kyak>
i don't like it...
<kyak>
kristianpaul: what is your build host?
<urandom__>
bartbes got it, thanks
<kristianpaul>
kyak: my home computer
<kristianpaul>
i was using fidelio but is x86_64 i need x86 sdk
<kyak>
what is it? x86, x64? what OS?
<kristianpaul>
debian squeeze x86
<kyak>
well ok.. almost my config
<kyak>
x86 and linux
<kyak>
let's see if this error goes away now, ok?
<kristianpaul>
sure
<kristianpaul>
compiling now
<kyak>
kristianpaul: have to go now.. hope it'll work well for you. If not, we will have to investigate.. if you need to finish your build, then blame me and check out older version of toolchain/uClibc/config-0.9.30.1/mipsel file
<rafa>
larsc: wpwrak : technically.. is there some nice way to have on boot moment a chroot or similar before init starts?.. (or being made by init). Wolfgang asked me some way to have dual boot and he suggested new layout for partition like :Â Â 4 mb u-boot, 8 mb kernel1, 8mb kernel2, 512mb rootfs1, 512mb rootfs2, rest is
<rafa>
                    (ubi-formatted?) data partition?
<rafa>
larsc: wpwrak : that is a terrible change for me  :).. I would like (ideally): uboot, just one kernel (yes, it is not so easy when openwrt and OE are not so identical).
<rafa>
larsc: wpwrak : one rootfs and there something like two folders : /openwrt-qi /jlime, then when kernel mounts rootfs init should change the root / to /openwrt-qi or /jlime
<rafa>
larsc: wpwrak : and another /data partition. With this layout you would keep just one partition for rootfs and another for /data.. If another distro appears and all is okey to have there.. it should be installed under some new dir on rootfs partition. For example rootfs would be :
<rafa>
- /qi-openwrt
<rafa>
- /jlime
<rafa>
- /debian
<rafa>
(if debian is the new one)
<rafa>
kernel mounts rootfs and should change the dir of root / (or init would do) before to continue booting
<wpwrak>
(chroot) sure. that's what initrd/iniramfs is all about :)
<wpwrak>
(tons of partitions) that idea scares me too :)
<rafa>
wpwrak: I would like to think some nice way to have avoid many partitions and change that from time to time :)
<rafa>
to have avoid = to avoid
<rafa>
wpwrak: (chroot, initrd/initramfs).. cool, we should check how to manage that (no sure if uboot is happy with big kernels or if it currently can read initrd from outside of kernel)
<wpwrak>
(shared /) hmm, that could get tricky if distributions make assumptions about the nature of /. e.g., that it corresponds to a device. not sure if this is an issue, though.
<wpwrak>
another problem you'll have it rootfs size. one thing you could do to reduce it is hard-link identical files ;-)
<wpwrak>
like this: iterate over all files. for each file, compute the md5sum. check in an associative array if it's already there. if not, store it, along with the path. if yes, delete the current file and hardlink it to the one previously found.
<wpwrak>
may need a bit of adjusting to skip variable directories, e.g., /var and /etc
<wpwrak>
(uboot limitations) uboot should die anyway :)
<rafa>
(distributions making assumptions): well, if those are running under some chrooted dir these should not detect that right? whatever they do on /* would be made on their /distribution/* folder if I understand it okey
<wpwrak>
(one kernel for everyone) i like the idea. not sure about the practical implications, though.
<wpwrak>
(chroot) yes, but they could try to find out what the underlying device is and do something stupid with the information. again, not sure if this happens. i've never considered that case. you may be the first to find out ;-)
<rafa>
paper: cool, let me see. Maybe I checked some time ago (when reading your web site)
<wpwrak>
it explains some of the background. some of the stuff is obsolete now, e.g., the change_root mechanism. union mounts never happened. and kexec came a bit later, so it's not mmentioned.
<wpwrak>
also, initrd is now initramfs. but by and large, the architecture is still the same. just that what was brand new back then is now the way it's always been ;-)
<rafa>
wpwrak: I built a clean toolchain from OE "external toolchain" recipes, which are the proper ones to do that. No idea if it works .. let me test
<wpwrak>
rafa: my greedy little hands are shaking :)
<rafa>
wpwrak: I will upload so you can test as well :) .. it built two files :
<rafa>
jlime-2010.1-2010.1-mipsel-linux-toolchain-extras.tar.bz2Â Â jlime-2010.1-2010.1-mipsel-linux-toolchain.tar.bz2
<wpwrak>
extras is things like sdl, gtk, ... ?
<rafa>
wpwrak: let me tar tv..
<rafa>
wpwrak: no.. it has a lot of eglibc locale files and similar stuff very basic it seems
<rafa>
wpwrak: but well, adding libsd and libsdl-dev ipk on toolchain should not be hard I guess
<rafa>
wpwrak: I mean, if we need extra libs on toolchain we can download the ipks files and unpackage them on toolchain installation
<wpwrak>
is there a tool to unpack an ipkg on the host ?
<wpwrak>
(i.e., an opkg adapted for this purpose. i know we had one at openmoko, but i don't know what they had to change there)
<rafa>
dpkg from ubuntu/debian can unpack.. but it just extract the files.. there is a opkg-cl
<rafa>
which I do not know well
<rafa>
wpwrak: I often add some libs downloading the ipk files and running something like "dpkg -x package.ipkg /toolchain/rootfs/dir/"
<rafa>
wpwrak: I do not know yet how to use them :D
<rafa>
(yet)
<rafa>
wpwrak: there is a file : ./usr/local/jlime-2010.1/mipsel/environment-setup which has an alias "opkg" and other stuff.. maybe that alias is useful to add packages to the toolchain
<wpwrak>
let's see ...
<wpwrak>
by the way, why 2 x 2010.1 ?
<rafa>
wpwrak: no idea.. OE adds those .. when kristoffer was pushing jlime stuff on OE (at the beggining of this year).. he added that IIRC (2010.1)
<wpwrak>
okay. random OE weirdness then :)
<rafa>
wpwrak: surely there is a meaning.. which I do not know of course
<rafa>
wpwrak: the openmoko toolchain wiki page explains how to use that ./usr/local/jlime-2010.1/mipsel/environment-setup file to add new libraries to the toolchain
<wpwrak>
oh. that thingy comes from OE directly. i always thought it was an OM-local hack
<wpwrak>
hello.c compiles :-)
<rafa>
wpwrak: yes, it seems that it comes from OE. That file which OE put into toolchain (./usr/local/jlime-2010.1/mipsel/environment-setup) set an opkg alias.. so it should be the proper way to add libs surely.
<rafa>
wpwrak: hello.c compiles.. ah.. great!..
<rafa>
wpwrak: can you show me a basic Makefile for it?
<rafa>
you are luck that customer service know the libsdl packages :D
<wpwrak>
now i still have to resolve the dependencies ...
<rafa>
wpwrak: but we should try the opkg-update and friends.. I will try to upload the Packages.gz
<rafa>
wpwrak: dependencies for libsdl?.. it should not have much
<wpwrak>
libsdl (without -dev), libts, .. let's see what else ...
<wpwrak>
tslib-conf. that's it
<wpwrak>
complains about recommendation and tells me it's not running preinst/postinst scripts. let's see what happens now
<rafa>
yes.. libsdl needs libts I see
<wpwrak>
grmbl. sdl-config says -L/usr/lib :-(
<rafa>
:( we need to use opkg surely.. preinst/postint scripts..
<wpwrak>
getting better. now just SDL_gfx is missing. searching ...
<rafa>
you are fast :)
<wpwrak>
successfully compiled ! :)
<wpwrak>
now i need to install jlime to actually run it ...
<rafa>
wpwrak: if you have a SD that is the easy way
<wpwrak>
hm,, there must be some uSD cards around here ...
<wpwrak>
well, i'll attack that problem tomorrow. still have to migrate my RF lab to a room where there's no bag of electrolytes wandering around, distorting the measurements.
<rafa>
cool, I should write a bit explaining why those file are under downloads.qi and how to use them :)
<rafa>
wpwrak: (makefile).. ah.. you just define CC.. great
<rafa>
(for hello)
<kristianpaul>
wpwrak: i have done some first SDL test with not ptoblem using jlime on the Ben
<wpwrak>
it would be great if  opkg-target update  worked. with that, almost everything would be automatic
<rafa>
wpwrak: I will upload the missing Packages.gz so we can use opkg-target
<kristianpaul>
gfx?
<wpwrak>
rafa: shouldn't opkg-target know where it can download Packages.gz ?
<kristianpaul>
ah you're cross compiling i see
<kristianpaul>
s/re/were
<rafa>
wpwrak: yes.. that is explained on openmoko toolchain page as well I would say. But anyway, if we set the proper links for opkg-target it will not find the Packages.gz yet
<wpwrak>
rafa: ah, i see. well, it's pretty close to perfection already :)
<kristianpaul>
he i'm using jlime just to avoid cross ompile and i wonder what you want with jlime then ;-)
<wpwrak>
kristianpaul: so you're compiling directly on the ben/sie ?
<kristianpaul>
yes :D
<wpwrak>
oh dear :)
<rafa>
kristianpaul: well, we uploaded a new jlime toolchain on downloads.qi.. and it was built properly from OE (the previous one, on jlime.com, is old and it was just a tar.gz from the toolchain that OE built to build the rest of stuff, which is not the proper one to use)
<kristianpaul>
basically i like jlime because that
<kristianpaul>
jej
<kristianpaul>
wpwrak: sure not linux ;-)
<kristianpaul>
rafa: you me i can chroot that and feel like if i we're in jlime?
<wpwrak>
i've heard of the following rather interesting approach: install a MIPS environment on the host. then set up qemu such that it gets invoked when you're trying to run a MIPS binary. (apparently, there's some way to accomplish this. i never tried, though)
<rafa>
kristianpaul: so you just like jlime because we are a sex gcc thing? :(
<rafa>
kristianpaul: ;)
<wpwrak>
now, in order to speed up compilation, replace the MIPS toolchain with a native cross-toolchain.
<kristianpaul>
rafa: i like the X too :)
<kristianpaul>
and bunch of sofware
<kristianpaul>
even the one i dont know exists yet
<rafa>
kristianpaul: well.. the toolchain just bring a proper env to crosscompile stuff.. no chroot I would say. But I could be wrong
<kristianpaul>
rafa: just kidding (gcc) sure i like all your hard work around GUI and support in news apps :)
<rafa>
wpwrak: you would have to see what OE tries to do when you want to build the emacs* packages using OE.. and you would like to leave the IT world :P
<kristianpaul>
huh?
<wpwrak>
rafa: what does it do ? :)
<rafa>
kristianpaul: all is okey.. I was just kidding as well.. My stuff is just a bunch of ides from users and I tried to put that on some rootfs from OE ;)
<kristianpaul>
:)
<kristianpaul>
ah i tought wpwrak had already installed Jlime in their nanonote!
<kristianpaul>
hope he will do
<rafa>
wpwrak: first, I do not exactly what it tries to do .. :D .. but ..it tried to use many GBs of disk space.. so I was checking WTF was doing.. Apparently.. it was trying to create a rootfs thing to use with qemu to build emacs.. and becuse the OE had already around 2GB of ipkg packages, it tried to put all of them under that rootfs being created
<rafa>
I do not= I do not know
<rafa>
wpwrak: it used around 100GB or more to say finally that he could not build emacs
<rafa>
wpwrak: and it also did a lot more garbage in the middle
<wpwrak>
rafa: sweet. did it also hack into the arecibo telescope and send a message back to its alien masters ?
<kristianpaul>
100Gb !! O_o
<rafa>
kristianpaul: yes.. something was not working well surely :D.. some random temp or who knows
<kristianpaul>
rafa: btw is llvm in OE repo?
<wpwrak>
maybe it's time to rename it then. EMACS was for Eight Megabytes And Constantly Swapping.
<wpwrak>
(that was in an innocent age when 8 MB was considered a lot of RAM)
<rafa>
wpwrak: (message for its alien mastesr) :D .. maybe it did and I did not realized
<kristianpaul>
jajaja
<kristianpaul>
i wonder if he dint realize nothing since began the porting
<rafa>
kristianpaul: I see the recipes to build llvm and llvm2.. but I do not see the packages on repo.. maybe those did not build
<rafa>
kristianpaul: I can check the logs
<qi-bot>
[commit] Mirko Vogt: remove version string from /etc/banner - include it from /etc/VERSION instead to avoid unneeded redundancy http://qi-hw.com/p/openwrt-xburst/8ae840f
<qi-bot>
[commit] Mirko Vogt: remove version string from /etc/banner - include it from /etc/VERSION instead to avoid unneeded redundancy http://qi-hw.com/p/openwrt-xburst/ced8773