<rafa>
kristianpaul: what does "hardware al reves" mean?.. I do not understand
<rafa>
kristianpaul: bootstrap is not toolchain.. or what do you mean with " are you sure is not danegours, just descopmresed ona separte folder and i'm seeeing  (bin  boot  dev  etc  home  lib  linuxrc..."?
<rafa>
kristianpaul: I guess that you are confusing files and stuff.. the dirs that you are writting (bin  boot  dev  etc  home  lib  linuxrc media  mnt  proc  sbin  sys  tmp  usr  var) are from a .tar.* to install jlime.. I do not know why you ask if that is dangerous.. it is not a toolchain.. it is to install jlime on your nn
<kristianpaul>
rafa: sorry uncopmresed wrong file
<kristianpaul>
i*
<rafa>
kristianpaul: or maybe you are talking about the old toolcain at jlime.com.. but then again.. here at qi we talk about stuff uploaded to qi servers.. so the toolchain which werner points you is from qi servers
<wolfspraul>
I think we can compress some of those files
<wolfspraul>
for example the BUILD_LOG can be BUILD_LOG.bz2
<wolfspraul>
and the -root.ubi can be -root.ubi.bz2
<wolfspraul>
if we bz2 the ubi file, reflash_ben.sh needs to support that as well
<wolfspraul>
but I think those two can be .bz2. especially if the -root.ubi is compressed, it will save a lot of download time and server bandwidth
<kyak>
wolfspraul: btw, how much downloads there are monthly? i.e. spent bandwidth
<xiangfu>
yes. sound good. after compass, it's 111M.
<xiangfu>
before it's 321M
<kyak>
xiangfu: i've got a list of packages that exist in full_system and missing from my build. I will install them one by one to find out what causes stardict to fail on start :)
<DocScrutinizer>
moinmoin
<wolfspraul>
DocScrutinizer: moin
<xiangfu>
kyak: sorry. don't have time look into stardict issue. I am port the netsurf libs. ~5 libs :)
<kyak>
xiangfu: yeah, i'm following your progress
<kyak>
would be great to have the netsurf :)
<wolfspraul>
kyak: in October, about 3GB outgoing traffic per day (the entire turandot machine, not just downloads)
<wolfspraul>
in November, ca. 4 GB/day
<kyak>
wolfspraul: not so bad :) means that every hour an image is downloaded :)
<DocScrutinizer>
what is stardict? Somebody complained about it yesterday, on #maemo
<wolfspraul>
definitely not, but that's good because as you know everything is still evolving
<kyak>
DocScrutinizer: it's a gtk2 dictionary
<wolfspraul>
kyak: we are building those 3 'extras' now each time - toolchain, sdk, imagebuilder
<wolfspraul>
the toolchain is rather small, just 15 MB
<wolfspraul>
I guess it's only compiler/link, but no libraries and headers
<wolfspraul>
the sdk is 270 MB (in xiangfu's latest image), the imagebuilder 315 mb
<wolfspraul>
is the imagebuilder a superset of the sdk?
<kyak>
yeah, the toolchain is self-sufficient.. will download and install what's needed itself
<wolfspraul>
if so, maybe we should only build the toolchain and imagebuilder
<wolfspraul>
and then point people to the imagebuilder by default
<kyak>
..and i never really built imagebuilder or sdk.. so can't answer that
<wolfspraul>
and to the toolchain only if they know why they only want the stripped-down toolchain?
<wolfspraul>
hmm, OK. I need to understand the function and usability of those 3 better. right now we just build all 3 because they are there, but maybe that's not ideal.
<kyak>
we might want to have a look at openwrt releases
<wolfspraul>
kyak: so the (15mb) toolchain will download libraries and headers as needed?
<wolfspraul>
ok, but if the imagebuilder is a superset of the sdk, probably the best is still to point everybody to the imagebuilder first
<kyak>
they only give away the imagebuilder
<kyak>
so yes, i think you are right
<wolfspraul>
it's a large file, = slow download, but then they have everything locally
<wolfspraul>
and we can focus our documentation on explaining how the ImageBuilder works
<wolfspraul>
that's assuming it is a superset of sdk and toolchain, and can replace those 2
<wolfspraul>
we can still leave the pure (small) toolchain binary on the server, for people 'in-the-know' who need a small download, or have a very small app and quicker ramp-up time than with the full ImageBuilder
<wolfspraul>
but we wouldn't focus our documentation or advice on that (small) toolchain, but rather on the ImageBuilder
<wolfspraul>
so I will try to get feedback on that idea, if anybody thinks it's wrong please let me know...
<kyak>
wolfspraul: me wrong
<kyak>
the toolchain only contains the binary toolchain
<kyak>
binaries + minimal headers
<kyak>
in fact, just a copy of staging_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1
<kyak>
the toolchain will be enough to build a simple application without external libriaries dependencies (unless you will build those libraries with this toolchain, too)
<kyak>
now the SDK.. the README fiel there is pretty explanatory
<kyak>
It contains a stripped-down version of
<kyak>
the buildroot. You can use it to test/develop packages without
<kyak>
having to compile your own toolchain or any of the libraries
<kyak>
included with OpenWrt.
<wolfspraul>
is the ImageBuilder a superset of the SDK?
<kyak>
To use it, just put your buildroot-compatible package directory
<kyak>
in the subdir 'package/' and run 'make' from this directory.
<kyak>
wolfspraul: haven't got to imagebuilder yet :)
<kyak>
wolfspraul: and yes, imagebuilder is a superset of SDK
<kyak>
ie.. you can build your apps as well as the whole image with imagebuilder
<kyak>
so for those people who only want to create a custom app, SDK is enough
<kyak>
for those who want to build a complete image, imagebuild is necessary.. though i'd suggest building from git in this case
<wolfspraul>
kyak: I come at this a bit differently.
<wolfspraul>
the imagebuilder is only 20% larger than the SDK
<kyak>
imagebuilder might be good to build exact the same image as release..
<wolfspraul>
and on the documentation and communication side, it is far easier to only have one thing to talk about, than to have two
<wolfspraul>
so if the ImageBuilder is a superset of the SDK, I would only provide that and focus all my documentation and explanatory energy on that one
<wolfspraul>
even as a development environment to 'only' build an installable app
<kyak>
wolfspraul: makes total sense
<wolfspraul>
kyak: what do you think? should we provide the small stand-alone toolchain at all?
<kyak>
those who really want the latest image from git, should be able to access those instructions though
<kyak>
on the wiki,
<wolfspraul>
the good argument for keeping it is that it is so drastically smaller and simpler
<wolfspraul>
so I wouldn't point anybody to it, but I would leave it built and published for those who know what it's for and when
<kyak>
wolfspraul: the toolchain can be used to compile a hello world :) like a demonstration.. maybe some users will like and would like to have more
<wolfspraul>
also some people might want to work with other rootfs environments, buildroot, who knows what
<wolfspraul>
and they may just want to get the toolchain proper
<wolfspraul>
so I would leave it there, but focus all documentation and advice towards the ImageBuilder
<kyak>
yes.. but please leave the instructions about how to get the latest image from git :)
<wolfspraul>
you mean how to build from source?
<wolfspraul>
sure of course, that will definitely stay that's a very important thing
<kyak>
yes, this one
<kyak>
wolfspraul: there are some errors though using iamgebuilder
<kyak>
it seems that kmod-input-core is not a part of base system?
<wolfspraul>
good question :-)
<wpwrak>
kyak, wolfspraul: perhaps the most flexible approach would be a toolchain plus a package installer, just like what we have on jlime now. so if you need, say, sdl_gfx, you just opkg-target install it.
<wpwrak>
no need for a pre-built environment that correctly predicts all your future needs
<wpwrak>
kyak: does openwrt have such an installation capability ?
<wpwrak>
(on the host)
<kyak>
wpwrak: i'm not sure i understand you
<kyak>
install on host?
<wpwrak>
kyak: if you have installed toolchain, sdk, or imagebuilder, and you notice there's some exotic library package that you don't have. that package is available somewhere as an .ipkg
<kyak>
yes
<wpwrak>
kyak: can you install that package into your cross-development environment ?
<kyak>
from the ipkg? i don't think so. installing a new package (or you would say, creating a new pacakge) is just a matter of copying a Makefile
<kyak>
there is not instructions inside the ipkg about how to build it.
<kyak>
(i think so)
<wpwrak>
but openwrt can build ipkgs, no ?
<kyak>
yes
<wpwrak>
so if you have one of these, there's no easy way to install it into a cross-development environment, such that its libraries, header files, etc., become available for cross-compilation ?
<kyak>
ipkg has binary files inside
<kyak>
+ some meta data
<wpwrak>
(there ought to be an all-manual way, though. e.g., pick the ipkg apart manually and untar it by hand)
<kyak>
this is irreversible :)
<wpwrak>
yup. in jlime, there's opkg-target that can do all this
<kyak>
you have to have the Makefiel which was used to build the ipkg
<wpwrak>
no no, you don't shouldn't the makefile
<kyak>
well i guess it's some kind of "source ipkg" there
<wpwrak>
ah, i see the problem. openwrt probably doesn't have -dev packages :)
<kyak>
i don't know about such thing in openwrt
<wpwrak>
or does it ?
<kyak>
dev files are not installed as a package
<kyak>
they are installed and live in your cross-development environment
<kyak>
they are not needed on target
<wpwrak>
ah, i see. so you can't have a full development environment on the ben either
<wpwrak>
(if you wanted to suffer the slowness)
<kyak>
you can, why not?
<kyak>
gcc-mips is ported :)
<kyak>
all the development files are there in your build envoronment
<kyak>
you should perhaps understand the primary goal of openwrt
<kyak>
building on a router is a little bit weird, right?
<kyak>
but you really wanna do it, you can
<wpwrak>
so if you need, say, libsdl_gfx.a, how would you get it on the ben ? scp openwrt/somewhere/libsdl_gfx.a ben:/usr/lib/
<kyak>
yep.
<kyak>
one could create a -dev pacakge of course
<kyak>
that would install these files
<wpwrak>
ah, so you DO have -dev packages ?
<kyak>
no :) i said "could"
<kyak>
these dev files are installed into your host
<kyak>
but they don't go into target
<wpwrak>
(primary goal) yup, but in qi-hw, we're trying to showhorn openwrt on a device that's more like a laptop than a router :) (of course, i realize that this is a difficult match. that's also why i keep pushing jlime)
<wpwrak>
i see. so it would be possible but need a lot of work
<kyak>
this is the reason why gcc was ported, and locales enabled, and widechar support and cyrillic input etc.. because Ben is not a router
<wpwrak>
i.e., you have all you need in the fridge, but that doesn't mean there's a nice meal in front of you right now :)
<wpwrak>
kyak: (not a router) yup. i was just trying to see if there were some low-hanging fruits for solving the host development environment problem elegantly also on openwrt.
<kyak>
wpwrak: so, if someone got openwrt SDK, and he wants to build a package he would just copy the package Makefile to hist sdk/package/
<wpwrak>
kyak: being able to just install packages (on the cross-development host) when you need some crazy new lib is a very nice capability.
<wpwrak>
kyak: that would also solve all the dependencies ?
<wpwrak>
(particularly build dependencies)
<kyak>
i don't know about the sdk. in openwrt, when you choose a pacakge to build, it wil enable all the dependencies
<kyak>
including build dependencies
<kyak>
that's why i don't completely understand what you are continuing to say about some wird lib
<kyak>
if this wierd lib is a dependency, it will be built
<wpwrak>
okay, so you enable the package and rebuild openwrt
<kyak>
build all depenedcies and the selected pacakge. wherether to rebuild or no is for the make system to decide
<wpwrak>
okay. so it's possible, just a bit involved.
<kyak>
uh..
<kyak>
i still don't feel understood :)
<kyak>
wpwrak: you should try the openwrt build system yourself some time
<wpwrak>
i think i understant. you do the menuconfig, enable the package, kick off a build, when you fish out the package's makefile, put it into your sdk/package/, then do whatever you do to make the SDK, and then you ... untar ? cp -a ? ... the new SDK on your host
<kyak>
not exactly
<kyak>
you do the menuconfig, the Makefile is already there
<kyak>
for each package
<kyak>
the SDK is nto related
<wpwrak>
but then the development lib gets built inside the openwrt build tree. do you assume that the SDK location and the location of the openwrt build tree are identical ?
<kyak>
you choose the package, kick off a build, you got the ipkg and all the realted libs/whtever as ipkgs too
<kyak>
SDK is not related to openwrt build tree at all
<kyak>
these are two Different things
<wpwrak>
the ipkgs will contain also the development libs ?
<kyak>
SDK can be generated from within openwrt build tree
<wpwrak>
before you said they don't
<kyak>
and unpacked somewhere else
<wpwrak>
(sdk) alright. so how does my libsdl_gfx get to this somewhere else ?
<wpwrak>
libsdl_gfx for development, plus headers
<kyak>
wpwrak: i'm sorry, i'm not here at the moment -\ will try to explain more later
<wpwrak>
no worry :)
<wpwrak>
we live in a mist of time anyway ;-)
<kristianpaul>
DocScrutinizer: (talking about taking pictures to ben display) bad news my camera is nor so good, (as expected), i get a black pic and high shutter speeds, or i got an usual display picture when i try get lower wich dint look like telling something interesting
<wpwrak>
rafa: in pkg/packages-mipsel, wireshark-tshark has very interesting Replaces/Conflicts, don't you think so ? ;-)
<wpwrak>
(there are a bunch more of this kind in wireshark* packages)
<kristianpaul>
Is it fair save a stream of bits in a uint32_t..
<wpwrak>
depends ... :)
<kristianpaul>
well is unsigned so who cares what is inside, if i can bitwise it later
<kristianpaul>
anyway i'm interested in the bits not the byte it self wich dint tell me nothing
<wpwrak>
how to you put data there and how do you retrieve it ?
<wpwrak>
both methods have to be compatible
<wpwrak>
this isn't always trivially so
<wpwrak>
particularly if your code may run on different platforms
<rafa>
wpwrak: yeah.. wireshark-tshark replaces wireshark and tshark .. what does that mean?.. maybe wireshark-tshark is a new software which merge both ? .. no idea
<wpwrak>
rafa: what along is a little peculiar, but look at the last item of that comma-SEPARATED list ...
<kristianpaul>
rafa: tshark is text version of wireshark i think
<wpwrak>
alonE
<kristianpaul>
merged seems, correct
<rafa>
wpwrak: yeah.. too weid :P
<rafa>
weird
<wpwrak>
rafa: now, where is that package called "(<1.0.5)" ? ;-)
<rafa>
wpwrak: and check the wireshark package.. it replaces wireshark :D
<wpwrak>
yup :) schroedinger would get a headache contemplating whether the package exists in the end or not
<rafa>
haha
<B_Lizzard>
Did you guys have any issues running netsurf?
<B_Lizzard>
I've compilled both the linux fb and sdl fb versions and the browser viewport is black
<wpwrak>
rafa: hmm, what do version numbers that begin with number: mean ?
<wpwrak>
rafa: e.g., libxfixes has version 1:4.0.4 but dependencies usually refer to it as >= 4.0.4, not >= 1:4.0.4
<rafa>
wpwrak: I have no idea.. but well.. as you said about dependences there is also just the right part of the number version on Filename.. for example the filename of libxfixes is libxfixes3_4.0.4-r0_mipsel.ipk .. it is like version is just 4.0.4-r0
<wpwrak>
hmm ...
<rafa>
wpwrak: and IIRC the file name of the packages is nameofthepackage_version_arch.ipk
<wpwrak>
looks like this, yes
<wpwrak>
minus "n:". if referenced with =, the n: is also included odd
<wpwrak>
well, i'll just skip it ...
<rafa>
wpwrak: yes.. I am almost sure.. opkg working with internet does not need the Filename field to know which is the filename to get.. it gets that from package name and version I guess
<wpwrak>
i can test that (later)
<rafa>
wpwrak: I mean, if you, for example, remove the "Filename:" lines from Packages file, and you use opkg install libxfixes3 it will know that the file to get from server is libxfixes3_4.0.4-r0_mipsel.ipk. We could ask OE channel as well
<wpwrak>
which is the right OE channel ?
<rafa>
#oe I think
<wpwrak>
ah, thought you were a resident there :)
<rafa>
wpwrak: nahh.. I am not a big fan :)
<rafa>
i just got in to test :)
<wpwrak>
let's see ...
<rafa>
I am a big fan of jlime.. because its people/devs.. I they tell me that now we will use puppy linux I will do :).. it is like to visit the same bars because your friends or cool guys you like go there.. if they change the bar to visit I will :)
<rafa>
I they=If they
<wpwrak>
just got a full dependency graph of abiword ;-)
<kyak>
wpwrak: sooo
<kyak>
where did we finish? :)
<wpwrak>
kyak: you declared defeat and retreated ;-)
<kyak>
hehe
<kyak>
it's job. they made me do that, blame them :)
<kyak>
so let me give a simple example for your understanding
<kyak>
it will first build libB (both dev and runtime libs) and will install it in openwrt buildroot. Then it will build appA against that libB. It will package appA and runtime libs of libB in separate ipkg, which you can install..
<kyak>
..then on your target
<kyak>
you run your appA
<kyak>
i hope this answers your question
<wpwrak>
kyak: let's assume i just have the SDK. how do i add the package of libB to it ?
<kyak>
wpwrak: i'm not familiar with the SDK
<kyak>
i assume you'll just copy the package Makefile to package/
<kyak>
(not only the Makefile, but patches and files ifi such exist)
<wpwrak>
kyak: the idea here is that you don't build from source but just install a binary package
<kyak>
install where?
<kyak>
my god
<kyak>
are talking about "opkg install" all this time??
<kyak>
i think i said you before there is "opkg" in openwrt
<kyak>
also by saying "host" you mean your PC, right?
<kyak>
because you mentioned several times about installign to "host"
<kyak>
also got me confused
<wpwrak>
yes, on the PC
<kyak>
then we got right where we were in the beginning.
<wpwrak>
;-)
<kyak>
wpwrak: when you fell like doing it, play with openwrt :) you will have some more specific questions, then we can discuss
<wpwrak>
the questions is still whether there will be an easy way for people to add things to their development environment with openwrt or not. if not, then the SDK (or whatever you call it in the end) environment should try to have lots of stuff. if yes, it can be fairly lean.
<kyak>
so you ended up writing your own package manager :)
<wpwrak>
kyak: not quite :) it just reads the package databases and can figure out the dependencies of a package
<wpwrak>
kyak: it leaves the rest of the work to opkg :)
<kyak>
i believe GUI is a matter of time :)
<wpwrak>
ah, where are the java bindings to opengl when you need them ? :)
<wpwrak>
now .. why does it bounce madly around libc6 when i feed it the installed status as well ... that should speed things up, not make them take forever :)
<wpwrak>
hmm ... libc6 says it depends on itself. that's already not so nice.
<qi-bot>
[commit] Werner Almesberger: qpkg/jrb.c: major whitespace readjustment (converted from GNU to K&R style) http://qi-hw.com/p/wernermisc/009f56c
<wpwrak>
rafa: about 7 s now to find the prerequisites of abiword (about the same for bash. calculating the prerequisites takes almost no time - only the loading and parsing of the data is slow)
<wpwrak>
rafa: and i can squeeze another 5% out of the CPU time (user) by skipping over things I can already predict ;-)
<qi-bot>
[commit] Werner Almesberger: qpkg/gobble.c (EXPECT): added variant that just skips over expected text http://qi-hw.com/p/wernermisc/ed0281f