<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>
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>
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>
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>
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'
<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 !
<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
<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.