<bartbes> oh..
<bartbes> I just read the mailing list and saw jirka talking about this weird build system
<bartbes> from what I've seen so far it's pretty easy actually
<qi-bot> [commit] Jiri Brozovsky: Compilation problems should be fixed. http://qi-hw.com/p/openwrt-packages/34a4bbc
<bartbes> what are the sections in the menu?
<bartbes> and the categories?
<bartbes> :P
<bartbes> small question
<bartbes> I'm working on the wordgrinder Makefile
<bartbes> but what section and category would that be?
<bartbes> I went for Utilities/Editors in the end
<bartbes> in case anyone was ever wondering
<qi-bot> [commit] Mirko Vogt: add new gmu icon http://qi-hw.com/p/openwrt-xburst/cd8e663
<qi-bot> [commit] Mirko Vogt: adjust config to 2 new packages in feed packages/ http://qi-hw.com/p/openwrt-xburst/11ee72f
<qi-bot> [commit] Mirko Vogt: [config] preselect bsd-games (tetris, backgammon, primes, worms) and calcurse http://qi-hw.com/p/openwrt-xburst/ddfccf5
<qi-bot> [commit] Mirko Vogt: [config] adjust config to new feed versions (once again) http://qi-hw.com/p/openwrt-xburst/9c13c44
<qi-bot> [commit] Mirko Vogt: [config] do not include packages <ntpdate> and <ntpclient> http://qi-hw.com/p/openwrt-xburst/df798b6
<wolfspraul> stress test
<wolfspraul> mirko: I fixed another but in the commitlog, I think (ahem) it should be stable now...
<qi-bot> [commit] Mirko Vogt: [gmu] update 0.7.0 -> 0.7.1 http://qi-hw.com/p/openwrt-packages/4f0bbdf
<qi-bot> [commit] Mirko Vogt: Merge branch 'master' of projects.qi-hardware.com:openwrt-packages http://qi-hw.com/p/openwrt-packages/5340103
<mirko> wolfspraul: hehe :) - ok
<mirko> wolfspraul: let's see when we do the next merge with owrt-backfire-upstream
<mirko> wolfspraul: startup time should be improved by the way in the next image
<mirko> wolfspraul: found some bugs causing heavy cpu load and timeouts which could be avoided
<wolfspraul> oh nice!
<mirko> wolfspraul: i suggest i'll upload a "testing"-image tomorrow, announce it on the mailing list and we'll wait 1 week for feedback / input
<wolfspraul> great
<wolfspraul> hopefully a lot of the packages that got contributed in recent weeks are included
<mirko> wolfspraul: after that 1 week there's 1 week left till my holidays
<wolfspraul> :-)
<mirko> do there should be enough time then, to fix possible bugs, build ,upload and announce the new official image
<mirko> wolfspraul: there are
<mirko> i update the config ~twice a week because i include new packages
<mirko> ~twice a day i mean
<mirko> bsd-games, new gmu version, new gmenu2x version, calcurse, mandoc, new qt4-features, NanoMap, alsa-settings and so on...
<wolfspraul> sounds good, there are a lot now
<jirkab> bartbes: probably Utilies
<wolfspraul> I count 80 subfolders in openwrt-packages now
<bartbes> yeah, I put it in Utilities/Editor
<jirkab> bartbes: I see no better  category
<bartbes> I got it to fail on ncurses
<mirko> hmm, the keypad layout changed in gmenu2x
<bartbes> so I'm currently compiling ncurses
<bartbes> but as you might know that means I got quite a lot already
<bartbes> mirko: it did
<bartbes> do you need any help with the new keys?
<mirko> wolfspraul: unfortunately some do not compile
<mirko> bartbes: i need documentation ;)
<bartbes> *cough* gforth *cough*
<mirko> bartbes: ?
<bartbes> mirko: x = enter
<bartbes> that's most important :P
<mirko> bartbes: please write it down somewhere i can link to in the announce mail
<bartbes> the full keymap is in /usr/share/gmenu2x/input.conf iirc
<bartbes> something like it though
<mirko> otherwise there'll be lot's of questions what happened to gmenu2x in the new image
<jirkab> bartbes: does Wordgrinder request wide character support in ncurses?
<bartbes> f2 is the old esc
<bartbes> jirkab: it does..
<mirko> bartbes: please write it down somewhere public
<mirko> bartbes: :)
<bartbes> mirko: give me a wiki page and I'll write it there
<bartbes> wow, the path was spot-on
<bartbes> gives his memory a cookie
<mirko> bartbes: ok, mom
<mirko> bartbes: uh, there is one already
<mirko> bartbes: http://en.qi-hardware.com/wiki/Gmenu2x - is that the current layout?
<bartbes> let's see
<bartbes> the "Plan to"
<bartbes> that one is correct
<mirko> hmm, well - changing sections was "p" and "q" and is now "tab" and "l"?
<bartbes> yeah, I don't like l, but tab is nice
<bartbes> makes sense
<mirko> these keys are not even in the same row :P
<bartbes> hehe, no
<bartbes> but I don't know they keymap for VOLUP and VOLDOWN either..
<bartbes> well, at least enter, tab and f2 make some sense :P
<bartbes> (note that I did not change the keymap)
<mirko> :)
<mirko> let's see what the folks say, when they have to switch :)
<bartbes> meh, the old keymap wasn't too good either imo
<mirko> bartbes: i don't they the new one is bad - some things just do not make sense yet to me ;)
<bartbes> jirkab: the only problem I have left (as far as I can tell) is the lack of ncursesw
<jirkab> bartbes: is sound very good (though I have not idea how much difficult is compilation of ncursesw )
<bartbes> I have no idea what the big diff is
<bartbes> let me look it up
<bartbes> (compiling-wise that is)
<bartbes> it sounds like it's just a compile-time option
<qi-bot> [commit] Mirko Vogt: [mandoc] (re)add mandoc, as compilation issues were fixed http://qi-hw.com/p/openwrt-xburst/37b39cd
<bartbes> jirkab: I think you need to add "--enable-widec" to the configure flags
<bartbes> so I simply added that to the makefile of ncurses
<bartbes> to see if it is indeed that simple
<bartbes> btw, is there a way to turn off the screen (like gmu does)?
<larsc> echo 4 > /sys/class/graphics/fb0/blank
<bartbes> jirkab: ncursesw doesn't build
<bartbes> larsc: thanks I'll test it now
<bartbes> it immediately turns back on though
<bartbes> ah, because of new output, of course
<larsc> no, because somebody turns it on gain
<bartbes> ehm..
<bartbes> maybe it still registers my enter?
<bartbes> anyway, when I run it via ssh it works flawlessly
<bartbes> jirkab: shall I send you the makefile and patch?
<jirkab> bartbes yes, many thanks (sorry for my delayed response - 'm doing too much things at once :-\ )
<jirkab> bartbes: ncursesw are needed for more applications so it woudl be usefull to make it work
<bartbes> it would
<bartbes> but it's some weird error in one of the header
<bartbes> which I wasn't able to track down in the very short time I spent trying
<bartbes> and this is the error I get when I compile ncurses(w)
<jirkab> bartbes: thanks. the error looks strange
<jirkab> bartbes: looks like it's similar to this Gentoo bug: http://bugs.gentoo.org/show_bug.cgi?id=214642
<bartbes> jirkab: hmm
<jirkab> bartbes: looks like GCC can't find definition of wchar_t type
<bartbes> not wint_t?
<bartbes> I think it simply needs an extra include statement
<bartbes> #include <wchar.h>
<jirkab> bartbes maybe too, but it stops on the line with wchar_t
<bartbes> no it doesn't?
<jirkab> bartbes: where you have wchar.h?
<bartbes> as far as I can tell it errors here: http://paste.ubuntu.com/478359/
<bartbes> and there's a wchar.h in staging_dir/include
<bartbes> hm no
<bartbes> not there
<bartbes> /usr/include
<jirkab> bartbes: see include/curses.h.in in ncurses directory
<bartbes> so how do we set NEED_WCHAR_H?
<bartbes> shall I try "--with-build-cppflags=-D_GNU_SOURCE" as mentioned in the gentoo thread?
<jirkab> bartbes: please try it
<bartbes> compiles
<jirkab> bartbes: I will try to understand the  curses.h
<bartbes> heh, that mess? enjoy!
<bartbes> something totally unrelated (while compiling) where can I set the persistent options again?
<bartbes> (like I did with fstab)
<bartbes> nvm found it
<bartbes> jirkab: IT BUILT
<jirkab> bartbes: nice!
<bartbes> only problem is it only built ncursesw
<bartbes> now to make it build both
<jirkab> bartbes: probably the easises solution is to make two packages individual - ncurses and ncursesw
<bartbes> yeah probably
<bartbes> I can put those in the same makefile, can't I?
<bartbes> or
<bartbes> wait
<bartbes> I can't commit this anyway
<bartbes> so I might as well copy this package over
<bartbes> and restore the old one
<bartbes> make it ncursesw
<bartbes> agreed?
<jirkab> bartbes: yes
<bartbes> will do
<jirkab> bartbes: great
<jirkab> bartbes: don't forget change ncurses->ncursesw in the Makefile ;-)
<bartbes> yeah, just did that
<bartbes> now.. what is the easiest way to restore the old package?
<bartbes> the entire thing was a git repo, right?
<jirkab> bartbes: wait
<jirkab> git checkout FILE_NAME
<jirkab> bartbes: git checkout FILE_NAME
<bartbes> so git checkout package/ncurses/Makefile?
<jirkab> I think so
<bartbes> no
<jirkab> I never used this
<bartbes> checkout is for changing commits
<bartbes> I think you mean git reset
<bartbes> or not
<bartbes> git should document their shit better
<bartbes> :@
<jirkab> bartbes: I have this in my notes - so it can be incorrect :-(
<bartbes> oh it worked
<bartbes> thx
<bartbes> runs menuconfig to enable ncursesw
<bartbes> compiles
<bartbes> jirkab: btw, when I depend on this, the folder is called ncursesw but the package libncursesw, which one do I use?
<jirkab> bartbes: I think it depends on the name whic his used inside the Makefile
<bartbes> makes sense
<jirkab> bartbes: like here: $(eval $(call BuildPackage,libncursesw))
<bartbes> though.. I remember this being different when I added lua.. hmm
<bartbes> ah we'll see
<bartbes> I guess when you do the wrong thing it tells you it lacks the dependency
<jirkab> bartbes: well, sometimes
<bartbes> oh look, no errors!
<jirkab> bartbes: you are right - at installation it will tell
<bartbes> now I will try to build wordgrinder
<jirkab> bartbes: nice
<bartbes> ehm
<bartbes> some fixes I have yet to do ;)
<bartbes> because apparently it forgot to use the toolchain..
<bartbes> wonders what pm does with environment variables..
<jirkab> bartbes: it ignores your environment variables?
<bartbes> I think... I forgot some settings ;)
<bartbes> what were the openwrt set env variables again?
<bartbes> TARGET_CC?
<jirkab> don't know
<bartbes> right, let's see what it does now
<bartbes> yeah, I believe it was
<bartbes> if not then it has no compiler now ;)
<jirkab> must exit :-(
<bartbes> awww
<bartbes> almost there...
<bartbes> and it built
<bartbes> now to install it on my nn
<bartbes> right, some bugs in the ncursesw file
<bartbes> (it installs the some of the same stuff as ncurses, so those are now ripped and instead it depends on ncurses)
<wolfspraul> bartbes: fascinating read, logging out for the day, but good luck!
<bartbes> hehe
<bartbes> that was just a rant
<bartbes> ;)
<bartbes> sleep well wolfspraul
<bartbes> (I assume you sleep at the end of the day..)
<wolfspraul> yes, correct :-)
<wolfspraul> n8
<bartbes> okay, I'm not quite sure about the rules here
<bartbes> it builds, but it still needs some fixes
<bartbes> so, how do I commit it? do I mark it BROKEN, or is that only for broken builds?
<bartbes> (as in failing compiles)
<mirko> bartbes: is there's any case, that it might fail zu compile
<mirko> mark it as broken please
<mirko> otherwise full-builds stop
<bartbes> well, don't think so
<mirko> okay
<bartbes> it only needs some fixes regarding screen size and keymap
<mirko> then feel free :)
<bartbes> oh
<bartbes> the biggest problem however
<bartbes> is ncursesw
<bartbes> I managed to get it to build
<bartbes> however, it is a separate package (due tohow ncurses' is set up you'd need 2 separate builds anyway)
<bartbes> but, since they use the same source package
<bartbes> they keep overwriting each other
<bartbes> so every time you compile something that depends on ncursesw it recompiles both ncurses and ncursesw
<bartbes> which.. is not a fun way to spend your time
<mirko> when why not modifying the ncurses-package?
<bartbes> because.. you *need* to build it twice
<bartbes> you can't build ncurses and ncursesw at the same time anyway
<bartbes> and this meant we didn't have to fork ncurses from openwrt
<mirko> bartbes: yes, so it sounds like it's better having build_dir/target-*/{ncurses,ncursesw}-version directories
<bartbes> yes, it is
<larsc> what you want is BuildVariants
<bartbes> larsc: are you going to save me, you holy man?
<mirko> larsc: yep
<bartbes> are you going to elaborate?
<mirko> looking for a package which uses that currently...
<bartbes> no openwrt docs?
<larsc> no docs, as usual ;)
<larsc> take a look at the uboot-xburst package
<bartbes> don't I just need PKG_BUILD_DIR?
<mirko> bartbes: that way would need 2 Makefiles
<bartbes> the rest looks a bit black-magic-y and a bit over-the-top
<larsc> you add a VARIANT field to each define Package/ncurses{,w}
<mirko> bartbes: with build-variance you can use just one Makefile
<larsc> and when Build/Compile or Build/Configure you'll have the VARIANT for your package in $BUILD_VARIANT
<bartbes> well that isn't entirely possible either
<bartbes> if you look at the ncurses makefile you see CONFIGURE_ARGS
<bartbes> that is what I'm modifying
<larsc> ifdef BUILD_VARIANT
<bartbes> it's that and the install
<larsc> CONFIGURE_ARGS+=--variant=$BUILD_VARIANT
<larsc> endif
<bartbes> ?!
<bartbes> see, you guys just throw me some makefile keywords
<bartbes> how am I supposed to make sense out of that?!
<bartbes> so, I modify: define Package/libncurses/install
<larsc> by thinking
<bartbes> to: define Package/libncurses{,w}/install
<larsc> ;)
<larsc> no
<bartbes> I need to make 2?
<larsc> yes
<larsc> one for each package
<bartbes> right, did that
<bartbes> now what do I do with Build/InstallDev?
<larsc> you need to check $BUILD_VARIANT there
<bartbes> so...
<bartbes> makefile ifs?
<bartbes> ifeq ($(BUILD_VARIANT),ncurses), that?
<larsc> yes
<bartbes> right, did that for Build/InstallDev
<bartbes> now I guess the same with the CONFIGURE)ARGS
<larsc> yes
<bartbes> so, now what do I do with the eval lines?
<bartbes> just leave in both?
<larsc> yes, one for each package
<bartbes> right, now what else?
<bartbes> the PKG_BUILD_DIR?
<bartbes> or just leave that alone?
<larsc> should work fine with the default
<bartbes> right
<bartbes> so now how do I build them?
<bartbes> make package/ncurses/compile should build them both?
<larsc> no
<larsc> well
<larsc> depends
<larsc> if both are selected yes
<larsc> but I just found out, that you need to change PKG_BUILD_DIR to something like PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
<bartbes> right
<bartbes> I'll compile both of them now
<bartbes> then a program depending on them
<bartbes> to see if they need to recompile
<bartbes> but what if it works?
<bartbes> do I need to add the ncurses to qi-packages?
<bartbes> that seems weird
<bartbes> well, it failed
<bartbes> can i do make package/ncurses/compile?
<bartbes> because obviously the build variant is empty..
<bartbes> (as the build dir shows)
<larsc> please show your current Makefile
<bartbes> give me a sec while I install xclip
<bartbes> now of course I made some horrible mistake..
<qmasterrr> hello
<bartbes> hello
<larsc> bartbes: you need to add a VARIANT field to each package
<bartbes> what should the contents be?
<larsc> the contens is what ends up in BUILD_VARIANT, when the package is build
<bartbes> right
<larsc> so in your case you want ncurses and ncursesw
<bartbes> fixes it all
<qmasterrr> I managed to crosscompile mpg123 but if i try to play a mp3 file on my BNN the cpu cant keep up, i thought it would be a fast way of getting mp3 support for gmu
<wejp> qmasterrr, you have to use the fixed-point-math decoder
<wejp> with fpu emulation it is way too slow
<qmasterrr> wejp, thanks :)
<wejp> :)
<qmasterrr> wejp: then mpg123 is not an option and i need to check if i can run GMU with some other mp3 decoder (like mad)?
<wejp> no, of course mpg123 is an option, jst compile it with the fixed-point decoder instead of the floating point decoder
<wejp> libmad is slower than mpg123 and has a horrible api, so it is no use
<qmasterrr> i'm new to the openwrt build system and Makefile style so its a bit hard to figure out
<wejp> you could also just use libmpg123 from the dingoo package of gmu. works just fine on the ben as well
<bartbes> larsc: well, it tells me I have an endef too little
<bartbes> yet grep + wc tell me the number is the same
<qmasterrr> that would be the easy way, i was planning to create a (openwrt) Makefile for libmpg123
<larsc> bartbes: well, i can't help you without seeing the Makfiles content
<bartbes> heh, nice syntax highlighting
<bartbes> it calls just about everything illegal ;)
<larsc> hm, indeed. looks about right
<wejp> qmasterrr, ah, i see. there are examples on how to create openwrt packages for programs using a configure script. you could check out those or just have a look at one of the packages already in openwrt. many of them use a configure script. it isn't that difficult
<qmasterrr> yes, i have created a makefile its a little bit of a mess but it works :)
<bartbes> wejp: it always assumes you use the autotools
<qmasterrr> now i have upgradet to gcc version 4.4.4 and im starting to getting errors on Makefiles i haven't touched
<wejp> bartbes, even if it recreates the configure script each time, it still needs to call it at one point ;)
<bartbes> larsc: line 115, it says...
<bartbes> wejp: no, I mean it always does that
<bartbes> by default
<wejp> what?
<bartbes> you only need to specify it separately if you have additional arguments
<bartbes> anyway, dinner
<wejp> that's the point, it needs to be called with additional arguments
<wejp> but it looks like qmasterrr got it working already
<qmasterrr> kind of :D
<wejp> hehe
<qmasterrr> quick question what gcc version do you use?
<wejp> 4.3.3 i think
<wejp> the one for openwrt that is
<wejp> my native gcc is 4.5.0
<qmasterrr> hum, if it complains about an makefile since i have updatet to make 3.82 should get wondering?
<qmasterrr> stupid me makefile syntax error is not gcc its Make :)
<wejp> weird
<qmasterrr> openwrt-xburst/build_dir/target-mipsel_uClibc-0.9.32/busybox-1.15.3 \ Makefile:431: *** mixed implicit and normal rules.  Stop.
<qmasterrr> it seems to me that the new Make version doesn't like "target %target:"
<lekernel> seems to be good shit
<lekernel> according to the paper it's better than quartus
<lekernel> "The BDS-pga program is for academic purposes use only" "This research has been funded by Altera Corporation."
<lekernel> whoa there's even a verilog compiler to the BLIW language they use
<lekernel> i need to try it
<lekernel> so far it's the most serious open source (but not free it seems) synthesis tool i've seen
<lekernel> damn, it compiled... this is so rare for academic tools
<bartbes> larsc: apparently endef can't be indented...
<bartbes> larsc: thx for the help, it all works now
<bartbes> now, how should I commit this?
<lekernel> ...but it segfaults. back to normal :)
<larsc> bartbes: send a patch
<bartbes> ehm, I can commit
<bartbes> I just mean, how should I commit the ncurses stuff?
<larsc> not to the openwrt repo
<bartbes> oh
<bartbes> but then
<bartbes> wordgrinder is going to have to wait for ages probably
<bartbes> :(
<larsc> why?
<bartbes> because it depends on ncursesw
<bartbes> right, so how should I create the patch?
<larsc> svn diff
<bartbes> so I need to clone their svn repo, copy my new one over and diff?
<larsc> or just send me the makefile
<bartbes> heh, that sounds easier ;)
<bartbes> how should I send it to you?
<larsc> email
<larsc> lars at metafoo.de
<bartbes> sent
<bartbes> btw, should I just commit wordgrinder and set it as broken in the mean time?
<bartbes> maybe it would be easier for you guys if there was a simple guide which stated what the rules are for the repo (what is to be committed, what not, what is to be marked broken, etc)
<bartbes> P
<bartbes> *:P
<larsc> if in doubt: commit. Its usally easy to revert it later it shouldn't have been commited
<bartbes> hehe
<bartbes> time to commit porn then ;)
<bartbes> good thing it's hard to erase history
<bartbes> safe storage for ever!
<bartbes> :P
<larsc> with git it is
<bartbes> btw, I just add a depend BROKEN right?
<larsc> does ncursesw really depend on ncurses?
<bartbes> no
<bartbes> but
<bartbes> it depends on some of the stuff in the ncurses package
<bartbes> if I include them in both you can't install them side-by-side
<larsc> ok
<bartbes> the terminfo stuff
<bartbes> cleans up his wordgrinder patch (newlines etc)
<larsc> maybe we should move the terminfo stuff into it's own package
<larsc> debian for example has a ncurses-base package
<bartbes> that might not be a bad idea
<bartbes> but
<bartbes> can you build it separately?
<qi-bot> [commit] bartbes: Wordgrinder: Builds, marked broken until upstream accepts ncurses patch http://qi-hw.com/p/openwrt-packages/8479332
<bartbes> there we go
<larsc> well, you could, but you don't have to
<bartbes> *if* they accept it of course
<bartbes> :P
<larsc> they?
<bartbes> openwrt
<larsc> i can commit to the openwrt repo, so thats not a problem
<bartbes> oh
<bartbes> well in that case
<bartbes> btw, shall I create the separate termlib package?
<larsc> well, if you want to, sure
<bartbes> I wonder if --with-termlib *only* builds it
<bartbes> "generate separate terminfo library"
<bartbes> simple solution
<bartbes> normal compile
<bartbes> ;)
<bartbes> as far as I can tell it builds both
<bartbes> which.. sucks
<bartbes> well, then I'm too lazy
<bartbes> spent enough time on it already
<larsc> hm, ncursesw and ncruses ship header files with the same name but different content
<bartbes> they do?
<bartbes> well, yes, I guess it makes sense that there's diff content
<bartbes> debian's solution is making ncursesw install its headers in /usr/include/ncursesw
<bartbes> we can do the same thing I guess
<larsc> yes
<bartbes> that's why I'm glad I'm only lead dev of 1 big project, I'd hate it to have to make these decisions ;)
<bartbes> larsc: so, do I need to do anything?
<larsc> nope
<bartbes> cool
<bartbes> not to sound pushy, but when can I expect the 'patch' to be into the openwrt tree?
<larsc> soon
<larsc> it does not seem to work as expected
<bartbes> care to elaborate?
<larsc> only the dev files for ncuresesw get installed if both are selected
<bartbes> can I help?
<larsc> don't think so
<bartbes> :(
<larsc> i guess InstallDev doesn't handle VARIANTs correctly yet
<bartbes> I'm pretty sure you need to if that
<bartbes> evening Textmode
<Textmode> huggles bartbes
<bartbes> wordgrinder is pretty nice btw
<bartbes> but it really can't handle terminals smaller than 80x24 I guess
<bartbes> its menus are simply hardcoded
<Chubs> Hello
<Chubs> is it ok to buy a GTX 480 for an old Q9400 2,67 ghz Quadcore, or would it just be slowed down?
<bartbes> that seems.. slightly.. off-topic
<Chubs> sorry
<Chubs> cant find a right tech help chat
<jirkab> bartbes: WordGrinder fits easily at 53x20 console
<jirkab> bartbes: I think this is one of the resolutions of future release
<bartbes> well in that case
<bartbes> yay
<bartbes> you read the logs, didn't you?
<jirkab> bartbes: I just looked at http://en.qi-hardware.com/irclogs/latest.log.html
<bartbes> that's what I said
<bartbes> right, I think that the keymap is the worst problem
<bartbes> and you can change it easily
<bartbes> however, it stores it in the document
<bartbes> not in a conf file
<jirkab> bartbes: that's not very good
<bartbes> it is not
<bartbes> btw, I did some nice tricks
<bartbes> ;)
<bartbes> for example it used to use luac to compile the lua into bytecode
<bartbes> but since that is non-portable and there's no mipsel luac to run
<jirkab> hm
<bartbes> I simply made it use cat
<bartbes> and now it runs nicely ;)
<jirkab> great!
<bartbes> I've committed it already btw
<jirkab> must see and try :-) congratulations!
<larsc> hu? I though luac was portable
<bartbes> the bytecode isn't
<bartbes> it's platform-dependent version-dependent
<bartbes> and much more-dependent
<bartbes> though man pages seem to disagree with me
<bartbes> "The binary files created by luac are portable to all architectures with the same word size. This means that binary files created on a 32-bit platform (such as Intel) can be read without change in another 32-bit platform (such as Sparc), even if the byte order (``endianess'') is different. On the other hand, binary files created on a 16-bit platform cannot be read in a 32-bit platform. "
<bartbes> However, I know from personal experience it is not
<bartbes> (it errored before I fixed it of course, but I have previous experience)
<jirkab> nothing is perfect ;-)
<jirkab> but it's good to know that it doesn't work
<bartbes> jirkab: if you want to compile it I can send you the makefile of ncurses
<larsc> but shouldn't luac simply preprocess the lua file just as a lua interpreter does when it loads the same lua script?
<bartbes> not.. entirely
<bartbes> well, a bit yes
<bartbes> but it compiles
<bartbes> and since we're using a modified version of lua
<bartbes> (lnum most notably)
<jirkab> bartbes: yes, thanks. I want to try it ;-)
<bartbes> the bytecode might not be interpreted the same way
<bartbes> (in this case it already failed in the header, as it always should, I guess)
<bartbes> jirkab: just tell me where and how to send it
<larsc> ah ok, luac is run on the host building the package
<larsc> ?
<bartbes> larsc: yes
<bartbes> larsc: btw, have you got the installdev sections to work yet, or shall I take a look at it?
<larsc> bartbes: not yet
<bartbes> larsc: does only ncursesw install headers in your attempt?
<larsc> well, both install them, but wenn ncursesw headers are installed ncurses headers are removed again
<bartbes> oh
<bartbes> I see
<bartbes> that explains the weird behavior
<bartbes> can't we just merge them both into one InstallDev?
<larsc> i don't think so
<bartbes> I tried, it's compiling now
<bartbes> hmm
<bartbes> another idea
<larsc> we'll need to add support for this to the build system
<bartbes> right..
<bartbes> there is no support for multiple InstallDevs yet?
<bartbes> I even tried puttin an if in the define
<bartbes> that failed too
<bartbes> --: eval: line 0: syntax error near unexpected token `libncurses,libncursesw'
<bartbes> we *can* add multiple hooks
<larsc> nope
<bartbes> $(foreach hook,$(Hooks/InstallDev/Post),\
<bartbes> doesn't that mean it loops over them?
<larsc> yes, but that wont help us
<larsc> the problem is that files installed by DevInstall are removed the next time DevInstall for the same Makefile is run
<bartbes> right
<bartbes> that makes absolute sense though
<bartbes> so your build variants aren't the working solution after all (for now) :P
<larsc> well, we need to teach the DevInstall stuff about variants
<larsc> or introduce a per paket DevInstall
<bartbes> well, what is the easiest, and what is the most useful?
<larsc> the later is more usefull
<larsc> but the other is easier (just did it)
<bartbes> heh
<bartbes> easy way is best :P
<bartbes> so, did it work?
<larsc> yes
<bartbes> cool
<bartbes> so I even made sure the openwrt build system 'improves'
<bartbes> what an amazingly productive day ;)
<bartbes> in retrospect wordg... something was easy to port compared to the trouble I went through to get ncursesw
<rafa> larsc: could you tell me how to create the /dev/rtc or /dev/misc/rtc device for nn? I built 2.6.34 with RTC support and I see the rtc driver init at boot time.. but hwclock -w complains
<larsc> rafa: hm, you need CONFIG_RTC_DEV or something like that
<rafa> it (hwclock) tries to use /dev/misc/rtc.. but no sure which proper mknod arguments to use
<rafa> larsc: yes, kernel has rtc support I guess
<rafa> the problem is the lack of /dev/*rtc* device files
<rafa> I think.
<rafa> larsc: I set rtc driver in menuconfig. and kernel messages at boot time says:
<rafa> $ dmesg | grep -i rtc
<rafa> jz4740-rtc jz4740-rtc: rtc core: registered jz4740-rtc as rtc0
<rafa> jz4740-rtc jz4740-rtc: setting system clock to 1970-01-04 21:06:54 UTC (335214)
<larsc> yes. there is a seperate option for the /dev/rtc devices
<larsc> CONFIG_RTC_INTF_DEV:
<rafa> larsc: it was there. I mknod /dev/rtc0 and then I did a symbolic link rtc -> rtc0 and it works now. I do not have udev right now
<rafa> that is why I needed to create those
<larsc> ok
<bartbes> jirkab: for when you're reading this (you will, I know that), I found *a* 'keymap' in src/c/arch/unix/cursesw/dpy.c
<Textmode> bartbes: ?
<bartbes> Textmode: ?
<Textmode> bartbes: !
<bartbes> Textmode: so what do you want to know?
<Textmode> bartbes: I was wondering why a "keymap" was notable.
<bartbes> because it isn't available in a config
<bartbes> yet is set on a per-file basis
<Textmode> hmm...
<rafa> larsc: wolfspraul: any idea how to add swap using nand?.. if that is possible.. a swapfile on ubifs would fail it seems
<wolfspraul> I think swap is equally bad on NAND and SD, it's only a temporary solution (the user turns it on, does something, turns it off).
<wolfspraul> but that means it cannot be the 'default' for an end user
<kristianpaul> :/
<wolfspraul> from those 2, SD is probably still better at least the microSD is easily replaceable :-)
<rafa> wolfspraul: why do you think that? we have used swap partitions on sd with jlime for years
<wolfspraul> rafa: ok then you know more than me that's good! Most people try to reduce NAND writes, so generally don't swap on nand.
<rafa> wolfspraul: with just 16 mb of machines, so kernel used that often. For nn we have better environment with 32MB
<rafa> of Ram.
<wolfspraul> anyway, you want swap on nand, so why not! :-) But I cannot answer your question, unfortunately.
<kristianpaul> good point avoid nand writes
<wolfspraul> ubifs may not even implement the special locked-only code paths that are normally needed to support swap files (don't know Linux internals about this, just guessing)
<kristianpaul> rafa: you said once linux require swap why is not the same with openwrt?
<wolfspraul> so maybe you need a new partition as a block device, then put swap on it?
<rafa> wolfspraul: that I know is that swap is a nice thing for the system almost always, for programs doing mallocs at least (many).
<rafa> kristianpaul: I do not know much current openwrt. For the openwrt image on nn it looks like just a sdl application on fb, which is not eating much ram. But I can give you an example for openwrt where an application will not work because the kernl will kill it without swap.
<rafa> kristianpaul: just do a proper malloc still if your program will not use that memory.
<rafa> wolfspraul: I was asking to test it on nand. But I do not know if that works. I read that flash filesystem are not useful for swapfiles, and when I tried swapon it fails.
<kristianpaul> is not posible format NAND as ext?
<kristianpaul> are you using ubifs isnt?
<kristianpaul> any way i need sleep (just arrived from trip), g8 4 all !
<rafa> kristianpaul: perhaps you find this cool to read: http://sourcefrog.net/weblog/software/linux-kernel/swap.html  (still if it is obsolete, nice to read)
<rafa> kristianpaul: yes, ubifs.
<rafa> cya man
<wolfspraul> you should definitely test it, would be a nice stress test too :-)
<rafa> wolfspraul: yes, perhaps I need that (a new partition as a block device).. I would need to learn how to do that first ;) (if that is possible for current nand and system)
<wolfspraul> but I don't know how to quickly make it work on nand, sorry...
<rafa> wolfspraul: well, If I learn and test then I will let you to know the tests
<wolfspraul> I don't know how the kernel gets information about the partition starts, maybe over the command line? from u-boot? where does u-boot get it from? statically compiled in somewhere?
<wolfspraul> maybe it's statically compiled into the kernel
<rafa> wolfspraul: I will check
<xiangfu> rafa:  the partition is statically compiled into kernel.
<lunavorax> Morning everyone
<lunavorax> I wonder if there's anyone still awake here
<xiangfu> lunavorax: yes
<lunavorax> hey :)
<lunavorax> i'm looking for information about compiling a simple hello world for the ben
<lunavorax> I'm a real noob so I don't really know where to search
<Textmode> ...compile a boilerplate "hello world" with the xburst compiler?
<xiangfu> lunavorax: you need get the cross compiler first.
<lunavorax> Thanks xiangfu but what is that
<lunavorax> Do I have to compile on the ben or can I do it on my x86_64 computer ?
<xiangfu> lunavorax: do it on your x86_64 computer.
<Textmode> lunavorax: its a cross-compiler chain
<Textmode> xiangfu: stop being better at this than me! ;_;
<lunavorax> ok
<lunavorax> As I do use Ubuntu I suppose I have to do the whole aptitude install thing as shown on the wiki right ?
<lunavorax> Or is there some packages i don't need
<lunavorax> Oh btw
<lunavorax> Is there a way to change the size of the letters ?
<lunavorax> When I hit Ctrl + Alt + F1
<lunavorax> The letters are way to big and I can't find a way to switch to a way smaller police
<Textmode> I think it selected during kernel configuration.
<lunavorax> Oh so it cannot be changed then
<xiangfu> lunavorax: just follow the wiki.  and here is what is cross compiler : http://en.wikipedia.org/wiki/Cross_compiler
<lunavorax> Ok sorry xiangfu maybe i ask too much questions :/
<xiangfu> lunavorax: it's can not changed in the last release. because in last release 2010-06-15, there is no font package, no kbd utilities.
<xiangfu> lunavorax: no. I like question. that mean someone start working with NanoNote. or learning NanoNote. :)
<xiangfu> lunavorax: we will add more fonts in next release.
<lunavorax> Well I bought the nanonote in order to program on it yeah... even if I'm a very beginner :/
<xiangfu> Textmode: yes. by default it's selected during kernel configuration.
<lunavorax> That's great to hear xiangfu I was tired of doing ssh only to have correct text display
<lunavorax> (also i'm waiting for screen flickering fix, you know)
<lunavorax> Dingux have a 4x3 font while displaying text at boot, that's much better
<xiangfu> lunavorax: 4x3 is too small I think. we have test 4x8. 6x10, 6x11, never test 4x3.
<xiangfu> lunavorax: you can found the screenshot here: http://en.qi-hardware.com/wiki/Ben_NanoNote_fonts#Screenshots
<lunavorax> I said 4x3 but I don't really know the size. However i'm sure that was the smallest possible
<lunavorax> 4x8 looks ok for me
<lunavorax> Also text fits correctly
<lunavorax> Oh I almost forgot
<lunavorax> I tried an experiment w/ the nanonote but apparently it's wasn't designed for that
<lunavorax> I bought a mini-b male usb to usb A female adaptor
<lunavorax> And plugged in a usb flash key but apparently it doesn't work. I bought this adapter in order to use it w/ a wifi usb key. But if it doesn't work.. <_<
<xiangfu> lunavorax: the usb port in nanonote is Device. not HOST.
<Textmode> basically.
<Textmode> personally, I wish it was USB2Go, or somethign of that ilk. but meh.
<lunavorax> ok so i was wrong
<Textmode> lunavorax: even if it did work, you'd need drivers.
<lunavorax> indeed
<Textmode> lunavorax: there are SDIO cards that work, though they are a pretty penny from what I hear.
<lunavorax> Too expensive for me i think
<lunavorax> IIRC