<bartbes>
and I called it love instead of mutroxports, but yeah
<bartbes>
I know it finds the feed
<bartbes>
I can see the symlink in feeds/love/
<bartbes>
(symlink to the makefile)
<bartbes>
wait a sec..
<bartbes>
I think it works now
<bartbes>
I guess I simply needed to run make package/synlinks again
<bartbes>
*symlinks
<tuxbrain>
hehehe that is what gonna to suggest now
<bartbes>
but I ran it before
<kyak>
before what?
<bartbes>
but I did that when the makefile was incorrect
<bartbes>
so I guess that was the problem
<bartbes>
thanks for your help guys
<bartbes>
btw, I have to say the toolchain is amazingly slow
<bartbes>
and ofc now I can't find the package
<bartbes>
because there is no bin folder
<bartbes>
heh
<bartbes>
my mistake
<jirkab>
bin/xburst/packages
<bartbes>
wasn't there yet
<bartbes>
but that is definately my fault
<bartbes>
so don't worry
<bartbes>
*definitely
<kyak>
it's slow for the first time
<bartbes>
for the first time?
<bartbes>
I've done a few compiles already
<bartbes>
but yeah
<kyak>
of course it has to download tons of source and then fresh compile it
<bartbes>
never a complete one (what killed me)
<kyak>
then it will be faster
<bartbes>
anyway, I'll report back in 3 days
<bartbes>
hopefully it will have finished then
<bartbes>
:D
<kyak>
depends on the crapiness of your vsp
<kyak>
vps
<bartbes>
running this on my own comp
<bartbes>
why would I build this on a vps?
<ao2>
hi, wolfspraul I asked for you yesterday, it was about the SDW-823 MicroSD wlan card: I am testing it on a pxa27x system, and porting the ks7010 driver to 2.6.35-rc kernel. Are there patches for that already that you know of?
<wolfspraul>
ao2: hmm
<wolfspraul>
when you say 'porting the ks7010 driver' - where are those sources from?
<wolfspraul>
I only know the stuff that is in our openwrt tree
<ao2>
wolfspraul, I took the source from openwrt-xburst, added some kconfig stuff to build it in kernel without openwrt and going on from that
<wolfspraul>
good, nothing I can add to that
<ao2>
wolfspraul, ok, so I'll tell you about the patches for 2.6.35-rc once I am done
<bartbes>
oh god
<bartbes>
I stopped compiling the toolkit
<bartbes>
to move it over to another harddisk
<bartbes>
and the moving takes just as long as the compiling..
<jirkab>
bartbes: please send me your Makefile to jirka (at) penguin (dot) cz
<bartbes>
let's hope I get the hang of it soon
<bartbes>
...
<jirkab>
wolfspraul: yes, surely. But we probably need more detailed beginners guide
<wolfspraul>
ok
<jirkab>
wolfspraul: with description of typical problems and most common errors
<wolfspraul>
once we have more scripting languages on the ben I want to make it possible to write a script in the wiki, then have it picked up for packaging directly out of the wiki
<wolfspraul>
(that's unrelated, just an old idea/dream of mine...)
<bartbes>
heh
<bartbes>
nice idea
<bartbes>
jirkab: sent
<jirkab>
wolfspraul: nice idea
<wolfspraul>
thanks - need to give me a kick to really make it working..
<bartbes>
jirkab: so, have you seen an obvious mistake yet? :P
<jirkab>
bartbes: it's probably unrelated to the problem, but nobody knows:Â Â CATEGORY:=Utilities
<bartbes>
oh I just put it there to make it stand out in the menu
<bartbes>
forgot to revert when I did get it to show up
<jirkab>
bartbes: I still con't find any other problem (hope "cmake ." is OK)
<bartbes>
because it is nice if you're not working on the term
<kyak>
huh-huh.. sorry for that :) i'm learning the strange ways of git
<bartbes>
git isn't that bad :D
<bartbes>
jirkab: do you know where it normally puts the downloads and/or tgz?
<kyak>
it is that good, actually :)
<bartbes>
:P
<kyak>
in dl/
<jirkab>
surely, in dl/ directory
<bartbes>
oh heh
<bartbes>
I've seen that dir
<bartbes>
no physfs dir
<bartbes>
*tgz
<bartbes>
leading to the conclusion, it doesn't download it
<jirkab>
you are right, it ignores ut
<jirkab>
us
<jirkab>
totally
<jirkab>
no idea why
<bartbes>
I tried the menuconfig way
<bartbes>
oh, can I complain again about the speed of the toolchain?
<jirkab>
bartbes: it is unusually fast, isn't it?
<jirkab>
;-)
<bartbes>
unusually fast
<bartbes>
where the usual speed is higher
<bartbes>
or maybe even unusably fast :P
<bartbes>
well, i can tell it failed anyway
<bartbes>
:(
<bartbes>
even on different servers
<bartbes>
are there any rules for the dir tree?
<jirkab>
bartbes: that's really strange: I can normally download the file with "wget" (SDK uses the same), I can not see any difference from other Makefiles and it still doesn't dowload
<bartbes>
isn't there a debug mode?
<jirkab>
I have physfs under openwrt-xburst/package/physfs
<jirkab>
like other packages
<bartbes>
right
<jirkab>
make V=99
<bartbes>
I have it in another place
<bartbes>
I meant, debug debug
<bartbes>
:P
<bartbes>
so you can actually see the wget and stuff
<jirkab>
V=99 shows debug messages for make
<jirkab>
wget output should be seen with V=99
<bartbes>
seriously?
<bartbes>
:O
<bartbes>
don't see it
<jirkab>
now I think that is simply even doesn't try to dowload the package
<bartbes>
my thoughts exactly
<jirkab>
well, "make package/physfs-prepare V=99" downloads the thing
<bartbes>
- or /?
<jirkab>
- and -
<jirkab>
sorry / and -
<bartbes>
oh
<bartbes>
works too
<jirkab>
I just compiled the command line here
<bartbes>
/ works too
<jirkab>
copied
<bartbes>
I have a build dir now
<bartbes>
only configure fails
<bartbes>
so any reason why it doesn't detect Build/Configure?
<jirkab>
I don't know
<bartbes>
I manually ran cmake .
<bartbes>
so let's see if I can get it to compile now
<bartbes>
it's horrible
<bartbes>
horrible
<bartbes>
I'll just write a small test app
<bartbes>
but not today
<bartbes>
time to kill some aliens
<jirkab>
bartbes: I got it build
<jirkab>
bartbes: not packaged, yet but still trying
<jirkab>
bartbes: looks like few typos were the problem :-(
<rafa>
wolfspraul: have you seen xiangfu? :) Do you know if there is a uboot binary/version which tries to boot from uSD first, and if it fails from there, then NAND?.. The current bootloader on SAKC just try to boot from NAND, and without keyboard it is hard to boot from uSD
<jirkab>
bartbes: DONE - it compiles
<wolfspraul>
rafa: he's probably sleeping, and so will I in a few minutes :-)
<jirkab>
bartbes: well, I was too optimistic :-(
<wolfspraul>
I don't know whether there is a binary of such u-boot, or how to simulate an 'm' press otherwise
<rafa>
wolfspraul: yeah, I was guessing that :)
<wolfspraul>
plus on sakc I believe you need a u-boot compilation anyway, I'm not sure whether it's only because of the boot order or also other things that need to be initialized differently...
<rafa>
wolfspraul: I need to modify a bit uboot for the sakc. we would like this behaviour: first, try to boot Linux from uSD, if it fails, then boot Linux from NAND
<wolfspraul>
so sorry, cannot help much. I think in u-boot there is a sakc config option somewhere, but you need to build from source
<wolfspraul>
rafa: take the sources (in the openwrt tree), then start from there
<rafa>
wolfspraul: yeah, let me check
<wolfspraul>
n8
<rafa>
and I will write to ml if I do not understand or if I find problems
<rafa>
sweet dreams
<wolfspraul>
yes, mailing list is good
<rafa>
thanks.
<bartbes>
jirkab: wow
<bartbes>
I'll reboot to linux
<jirkab>
bartbes: I just have sent the corrected Makefile by e-mail.
<bartbes>
k
<bartbes>
wait, did I actually send you my email 5 times or is gmail somehow messing up displaying it?
<jirkab>
bartbes: I got only one
<bartbes>
good
<bartbes>
the most interesting thing about the toolchain is that during the longest wait (the startup) there seems to be no activity at all
<bartbes>
ehm "make[1]: *** No rule to make target `package/libphysfs/compile'.  Stop."
<bartbes>
so, did something change?
<jirkab>
bartbes: I used: "make menuconfig ; make V=99" and it have worked
<bartbes>
interesting: WARNING: skipping libphysfs -- package not selected
<bartbes>
:P
<jirkab>
select it in the menu ;-)
<jirkab>
I changed the name so it surely is not selected
<bartbes>
interesting how I spent at least 4x the time on compiling
<bartbes>
ehm
<bartbes>
don't know how to finish that sentence :P
<bartbes>
category games?
<jirkab>
yes
<bartbes>
it's a lib
<jirkab>
you can change the category
<bartbes>
I know
<bartbes>
just figured it belonged in libraries
<bartbes>
:O
<bartbes>
cc1: error: include location "/usr/include/wx-2.8" is unsafe for cross-compilation
<jirkab>
?
<bartbes>
that's the error I got
<bartbes>
no idea what wx-2.8 is supposed to be
<bartbes>
wxwidgets maybe?
<bartbes>
but then, why?
<jirkab>
do you have selected sometihng related to wx? (wxwidgets probably?)
<bartbes>
that's when compiling physfs
<jirkab>
I don't see such error
<jirkab>
bartbes: try to uncheck the libwxbase in Libraries (make menuconfig)
<bartbes>
I will
<bartbes>
it's not checked
<bartbes>
I'll look at it tomorrow
<bartbes>
I spent enough hours on it today
<larsc>
you probably got wxwidgets installed on your host system. and libphysfs picks it up
<bartbes>
probably
<larsc>
you should be able to tell libphysfs configure not to look for wxwidgets
<bartbes>
cmake
<bartbes>
but yeah
<bartbes>
jirkab: thanks for the patch
<bartbes>
it seems to work
<bartbes>
now to transfer it to my nn
<bartbes>
now would you look at that
<bartbes>
it even install
<bartbes>
thanks jirkab!
<jirkab>
;-)
<bartbes>
*installs
<bartbes>
great
<bartbes>
then I think I have all my deps ported
<bartbes>
that helps
<bartbes>
I'll write some test app tomorrow
<bartbes>
and then I'll start porting
<jirkab>
just check file /usr/lib/libphysfs.so.2.0.0 if it is really a MIPS library...
<bartbes>
how?
<bartbes>
(I once knew, but I forgot.. ofc)
<jirkab>
write: file /usr/lib/libphysfs.so.2.0.0
<bartbes>
ah
<bartbes>
file
<jirkab>
to command line on jour NanoNote
<jirkab>
your
<bartbes>
I knew it was something obvious :P
<bartbes>
/bin/ash: file: not found
<jirkab>
bartbes: so it is not installed
<bartbes>
that's obviously in some other package
<jirkab>
the package is "file"
<bartbes>
my comp however
<bartbes>
does have file
<bartbes>
and it tells me:
<bartbes>
libphysfs.so.2.0.0: ELF 32-bit LSB shared object, MIPS, MIPS32 version 1 (SYSV), dynamically linked, with unknown capability 0xf41 = 0x756e6700, not stripped
<bartbes>
which seems correct
<jirkab>
that's OK
<jirkab>
nice
<bartbes>
great
<bartbes>
thanks again
<jirkab>
:-)
<bartbes>
thanks to you I cross-compiled my first lib within 36 hours of arrival of nanonote
<jirkab>
bartbes: but thanks to your effort we now have sample Makefile for cmake-based things