[00:00] --- Fri Jun 30 2006
[13:48] <florian___> ola
[15:15] <florian___> how should I tag my makefiles for instance ?
[20:28] <nbd> db90h: it should be very usable
[20:28] <nbd> db90h: but many packages are still missing and need to be ported
[20:28] <nbd> but porting a package over isn't that hard, even though the format is a lot different
[20:28] <db90h> ah, k.. i'll check it out and give it a go
[20:29] <db90h> what was the rationale for switching anyway? sorry with the questions
[20:29] <nbd> when you want to port packages yourself, let me know. i can help you with that
[20:29] <nbd> switching to what
[20:29] <nbd> ?
[20:29] <db90h> k, will do
[20:29] <db90h> buildroot-ng
[20:29] <nbd> the old build system was becoming too messy
[20:29] <nbd> and to add a single package you had to edit lots of files
[20:30] <nbd> you couldn't just copy in a package directory and expect it to be there
[20:30] <nbd> (like you can with buildroot-ng now)
[20:30] <nbd> also you had to add lots of redundant information
[20:30] <nbd> e.g. the description once for the menuconfig file, once for the ipkg control file, etc.
[20:30] <db90h> yea, i created a package on the old buildroot..did have to edit a few files
[20:30] <nbd> that all got merged into the main makefile, which contains all the metadata now
[20:30] <db90h> ah, that's cool..
[20:31] <nbd> if you copy in a package directory and run make menuconfig, it'll be integrated immediately
[20:31] <db90h> neat ;)
[20:32] <nbd> and the whole templating stuff that we use make it a lot easier to extend the format without breaking compatibility
[20:32] <nbd> so it's really a huge step forward
[20:37] <db90h> looking at optimize_lib.sh.. my *sh scripting isn't so developed, but it looks like it searches all ELFs in the filesystem for use of every symbol in every library and removes ones not used..?
[20:38] <nbd> correct
[20:38] <nbd> it's a bit tricky to integrate into the build system while still keeping sstrip
[20:38] <nbd> but i already have some ideas on how to pull that off
[20:39] <florian___> nbd: do you think porting lzma to jffs2 is hard ?
[20:39] <nbd> i think it's unnecessary and it complicates things because of ++
[20:39] <nbd> c++
[20:40] <florian___> ah true
[20:40] <db90h> florian___: I asked him about that just yesterday ;).. i too would like to integrate LZMA, but it's apparently not as trivial as I thought
[20:40] <florian___> how do I handle the flash partition reprogrammation ? with the bootloarder or with the kernel ?
[20:40] <nbd> and the main reason for jffs2 having worse compression than squashfs is the fact that it's a writable filesystem
[20:40] <db90h> nbd: i need to look into sstrip's role, but my assumption is that its removing of symbols prevents the search for unused symbols?
[20:41] <nbd> florian___: you don't need to 'change' any partition maps. write an appropriate mtd map driver that figures things out at run time
[20:41] <db90h> i may be totally whack on sstrip tho, need to look into it
[20:41] <nbd> db90h: sstrip removes the section header table from the elf files
[20:41] <nbd> db90h: libbfd (from binutils) can't deal with that yet
[20:41] <db90h> ah, k..
[20:41] <nbd> db90h: which means any libbfd based program will fail to even open sstripped elf files
[20:42] <florian___> nbd: so, the flash memory is dynamically divided into the partition size ?
[20:42] <florian___> I mean, if the kernel fits in x kb, it's partition is x kb ?
[20:42] <nbd> florian___: yes. the ar7 flash map driver is a good example
[20:43] <florian___> ok, is it standard ?
[20:43] <nbd> florian___: it knows where the kernel starts and figures out how big it is and how big the filesystem partition should be
[20:43] <db90h> i had misunderstood sstrip's function.. i'll take a look at its source and get up to speed with everything that's going on .. need to read up on ELF file format too
[20:43] <nbd> florian___: all of the mtd stuff that we have can be considered non-standard
[20:43] <nbd> florian___: because every device uses its own mtd mapping code
[20:43] <nbd> florian___: a lot of devices simply pull the mtd map from the boot loader
[20:43] <florian___> ok
[20:44] <florian___> I have another question
[20:45] <florian___> if I want to add a fetch target, how would I do it ?
[20:45] <nbd> fetch target for what?
[20:45] <florian___> fetching all packages before building
[20:46] <nbd> buildroot-ng already does that
[20:46] <nbd> 'make download'
[20:46] <florian___> ah ok
[20:46] <florian___> great :)
[20:46] <nbd> i added it a while ago because i thought it was about time we made something like that after so many people requested it :)
[20:47] <florian___> it's useful by the way
[20:47] <nbd> btw. what do you think about moving the kernel module packaging to package/kernel-modules?
[20:47] <nbd> (to reuse the existing packaging code, maybe extending it with a few more templates)
[20:47] <florian___> I think it's a good idea
[20:47] <nbd> i think i'll work on this today
[20:48] <florian___> ok
[20:48] <florian___> I will add some libs tonight
[20:48] <nbd> i'll start with a few modules, maybe you can help me with the rest
[20:48] <florian___> ok
[20:48] <nbd> there's quite a lot of them :)
[20:55] <florian___> right :)
[21:11] <db90h> i wonder how much unused code there ends up being in the entire linux kernel, on say, a Broadcom router?
[21:14] <db90h> i mean, like old stuff for backwards compatibility... for instance, the JFFS2's inclusion of decoders for the older compression algorithms (note: of course, the decoders are tiny in that example)
[21:14] <db90h> probalby not worth it to go try to pick out such shit
[21:14] <db90h> as u might end up with headaches when packages expect something to be there
[21:14] <nbd> well, it is worth looking into things that waste space, but only the large ones
[21:15] <db90h> yea..
[21:15] <db90h> man i gotta quit mucking around with this embedded linux shit, u see what you've done to me? ;p
[21:16] <nbd> yeah... doesn't take long to get addicted
[21:16] <nbd> :)
[21:20] <db90h> so can one sstrip everything after you've removed unused symbols?
[21:23] <nbd> yes
[21:25] <db90h> so that's the issue, just hacking up the build system so sstrip is done after the symbol stripping.. i dunno how much difference this will make, but maybe i'll mess with it
[21:26] <nbd> you need to wait with the sstrip for *all* packages
[21:26] <nbd> and the optimize_lib can only be done if all packages are compiled as well
[21:26] <nbd> so the required change is a bit more than tha
[21:30] <db90h> right
[21:31] <db90h> in my case, I won't worry with making sure I build and search all packages, just the ones I'm including in my particular firmware image..
[21:31] <db90h> of course it will muck up some packages installed afterwards, but for this super micro build, allowing installing of new packages isn't part of the plan
[21:32] <db90h> well, i won't disallow installation, but won't support it.. the plan is to create an openwrt buiild that has as many common packages in the squashfs as possible
[21:33] <db90h> ..add to this a non-existant web UI and you've got a kickass new micro firmware.. but in the end what I'd be doing is re-creating dd-wrt micro with openwrt as a base ;p
[21:37] <db90h> dunno..now that i think about it, this is kinda pointless.. however, this is what people should be doing, starting with openwrt as a base and building pre-setup firmwares.. this brings openwrt to the masses in a pure openwrt system, instead of bits and pieces added to stock firmware
[21:38] <nbd> i agree. in the future we should have a web based imagebuilder
[21:38] <db90h> that'd be awesome
[21:39] <florian___> you submit your makefile and you get the ipk ?
[21:39] <nbd> no
[21:39] <nbd> custom makefiles would make it easy to run code on our server
[21:39] <nbd> i mean an image builder
[21:39] <florian___> ah sorry
[21:39] <nbd> where you can select your packages
[21:39] <florian___> ok
[21:40] <db90h> the one thing missing, perpetually, is a good web UI.. that's why I kinda hated to hear you are re-writing webif (as much as it may need it).. cuz people would have eventually extended it to the point of it being easy to use by the masses
[21:41] <nbd> people were complaining that it's too hard to write webif pages
[21:41] <florian___> well, I think that one thing we could have expected from webif was a lot of modules coming from various contributions
[21:41] <florian___> as nbd is just saying, even with the abstraction it's quite tricky to do things
[21:42] <nbd> in the next version the webif engines should be somewhat pluggable
[21:42] <nbd> so you could replace the plain old engine with something AJAXy
[21:43] <florian___> lol
[21:43] <nbd> or with a ncurses frontend :)
[21:43] <nbd> ideally a webif page should just define a basic form structure and handle configuration reads/writes
[21:43] <nbd> and the shared code should do the rendering
[21:44] <db90h> yea
[21:44] <nbd> making the pages pure-awk will probably also help
[21:45] <florian___> it will certainly refrain people from writing stuff
[21:45] <nbd> ?
[21:45] <db90h> it's kinda a big chore to do right, and another big chore to create the pages build on it..
[21:45] <florian___> awk is not that simple to learn
[21:46] <florian___> and I am sure people will want to hack inside the core functionning as well as the rendering
[21:46] <nbd> another solution would be integrating awk well enough so that you don't notice it's awk
[21:46] <nbd> kind of like the new config format where you don't notice it's actually a shell script
[21:46] <nbd> anyway... awk is necessary
[21:46] <nbd> i don't want to make a dead-slow shell based interface
[21:46] <florian___> it is fast enough
[21:47] <db90h> u know.. this might be insane, but there's another way.. u could write a terminal based configuration tool (and perhaps even make its templates compatible with the eventual web UI)
[21:47] <nbd> db90h: that's what i mentioned above
[21:47] <nbd> db90h: (ncurses frontend)
[21:47] <db90h> ah, sorry
[21:47] <db90h> i didn't know what ncurses was (again my linux ignorance ;p)..
[21:47] <nbd> no problem
[21:50] <db90h> well i'm glad to hear this is a priority.. sometimes i get the impression many would prefer openwrt never have a web UI ;)
[21:50] <nbd> db90h: the problem is: a good webui is really hard to implement properly
[21:50] <nbd> db90h: because it has to be really small, really modular and usable at the same time
[21:51] <db90h> yea, i can see the problem.. much easier to hack something together that works for a particular platform and set of packages (ala dd-wrt)
[21:51] <nbd> yep
[21:52] <nbd> one option i'm also considering is cleaning up haserl and doing a real cgi wrapper with more embedded templating code
[21:53] <nbd> so that i can really customize the syntax without having to rely too much on awk/shell
[21:53] <nbd> but that's a bit of work and my c (for user space) is a bit rusty
[21:53] <nbd> i hate writing parsers and stuff in c
[21:53] <nbd> because i don't know much about it
[21:53] <florian___> parsers are a real pain in general :)
[21:54] <db90h> amen to that
[21:54] <nbd> but doing something like that would solve lots of problems
[21:54] <florian___> probably more in c because of the mm you have to do
[21:54] <nbd> maybe i really should take some time to read up on bison et al
[21:55] <florian___> yeah bison is great for that
[21:55] <florian___> string -> action
[21:55] <nbd> we should design a webif page syntax together
[21:55] <florian___> sure
[21:55] <nbd> and then try to get it right once we've agreed on something
[21:56] <nbd> we can use some elements to save some work, e.g. haserl's way of spawning a subshell for interpreting certain code sections
[21:58] <nbd> so we don't have to write our own interpreted scripting language
[21:58] <nbd> that would be too much
[21:59] <db90h> hmm.. this is unrelated to doing things properly.. way unrelated.. but for playing around, what if a person ripped out DD-WRT's web UI (and facilitating modules), assumed a specific set of packages to be installed, and then wrote an NVRAM->config file translator to do things like set up iptables for port forwarding, etc..
[21:59] <db90h> ;p
[22:00] <db90h> this wouldn't be usable for openwrt, of course.. i'm still speaking of my own specific firmware (let's call it dbwrt ;p)
[22:00] <nbd> i think that would be a complete waste of time
[22:01] <db90h> hehe, yea.. the best you could hope for is getting a result as good as dd-wrt
[22:01] <nbd> nvram->config translation would be a bit tricky as well
[22:01] <db90h> (well, maybe with slightly better performance with better packages..)..
[22:01] <nbd> because the new format is structured differently
[22:01] <nbd> and the dd-wrt web interface contains huge amounts of bloat
[22:02] <db90h> yea, i guess i will have to give up that notion.. i just keep wanting to merge dd-wrt's web UI and openwrt's base, can't get it out of my head ;p
[22:02] <nbd> :)
[22:03] <db90h> what new format are you talking about anyway?
[22:03] <nbd> the one we're moving to. i'll look up an example for you
[22:04] <nbd> this is for the wifi config: http://pastebin.ca/75948
[22:05] <db90h> ah, cool
[22:06] <nbd> it can be interpreted with pure shell
[22:06] <nbd> and manipulated with awk
[22:06] <florian___> nbd just a question
[22:06] <florian___> I want to test some packages
[22:07] <florian___> well testing the package building
[22:07] <florian___> so I made a symlink from packages/<category>/<pkg name> to buildroot-ng/package/
[22:07] <florian___> I see it in the menuconfig, but it is not built, any mistake I could have made ?
[22:08] <nbd> can you show me the makefile?
[22:08] <florian___> sure
[22:09] <florian___> http://pastebin.ca/75951
[22:10] <florian___> I think it has not been added to targets probably ?
[22:10] <nbd> looks ok to me
[22:10] <nbd> what happens if you run make package/<pkgname>-compile?
[22:12] <florian___> it works
[22:12] <nbd> is it integrated into openwrt/.pkgdeps?
[22:13] <florian___> .pkgdeps is empty
[22:14] <florian___> but .pkginfo contains the <pkg>
[22:14] <nbd> .pkgdeps should never be empty
[22:15] <florian___> ah, what can make it empty ?
[22:15] <florian___> I have choosen other packages as well : busybox ...
[22:15] <nbd> try scripts/gen_deps.pl < .pkginfo
[22:15] <nbd> see if it outputs anything
[22:16] <florian___> nothing
[22:16] <nbd> that's odd
[22:16] <florian___> I have the latest revision
[22:16] <nbd> try rm .pkg*; make oldconfig
[22:16] <nbd> wait
[22:16] <nbd> before you do
[22:16] <nbd> please give me a paste of .pkginfo
[22:18] <florian___> ah what happens, I can't see the packages anymore ?
[22:18] <nbd> seems like it fails to properly generate .pkgdeps
[22:18] <nbd> did you change anything in rules.mk or so?/
[22:19] <florian___> in package.mk, actually, I have just restored the version
[22:19] <nbd> ok
[22:20] <florian___> I got warnings regarding undefined symbols we found in package configurations
[22:21] <florian___> well, I can use a clean svn revision
[22:21] <florian___> ok it's fixed now
[22:22] <florian___> here is my .pkginfo before make oldconfig
[22:22] <florian___> ah, it's far better, now I have the control file displayed
[22:22] <florian___> I did not have it before
[22:22] <florian___> I think it will work now
[22:59] <CIA-17> nbd * r4100 /branches/buildroot-ng/openwrt/toolchain/gcc/patches/4.1.1/900-c++_fixes.patch: add hack for building c++ with gcc 4.1.1
[23:06] <florian___> nbd I tought it was fixed in fact it is not :(
[23:06] <nbd> is .pkgdeps still empty?
[23:06] <florian___> not this time
[23:07] <nbd> does your package appear in .pkgdeps?
[23:10] <florian___> yep
[23:10] <nbd> ah, i know
[23:11] <nbd> the menuconfig option probably won't take the '+'
[23:11] <nbd> let me check sth...
[23:11] <florian___> ok
[23:13] <nbd> maybe you should edit package.mk to allow the user to override the menuconfig name
[23:14] <nbd> oh, wait
[23:14] <nbd> that would not be enough
[23:14] <nbd> you should allow the user to override the name of the ipkg
[23:15] <nbd> and then call all variables like Package/uclibcxx
[23:15] <nbd> because there are more variables that contain the package name
[23:15] <nbd> does that make sense?
[23:25] <florian___> ah I did not think about that
[23:28] <florian___> ok that was the trick
[23:29] <nbd> when we've moved the kmod-* packages to package/kernel-modules, we'll also finally have a proper way of adding dependencies on them
[23:29] <[mbm]> as I pointed out before, if you have any typo in one of the package makefiles the page will be silently dropped from .pkgdeps .. no warning given
[23:29] <nbd> [mbm]: it wasn't dropped entirely
[23:29] <nbd> [mbm]: it was displayed but not built
[23:29] <[mbm]> ah, ok
[23:30] <[mbm]> (we still need to address the other issue though)
[23:30] <nbd> should be easy to fix
[23:30] <florian___> well renaming it to uclibcxx is not that bad
[23:30] <nbd> i mean the silent drop thing
[23:31] <nbd> florian___: but the ipkg and the menuconfig entry should still be called uclibc++
[23:34] <florian___> ah ok, just the call BuildPackage ?
[23:35] <nbd> the templates and the BuildPackage call should refer to uclibcxx
[23:35] <nbd> and the Package/uclibcxx template should contain something like NAME:=uclibc++
[23:35] <nbd> which should override things in include/package.mk
[23:35] <florian___> ok
[23:35] <florian___> what's the difference between := and = ?
[23:36] <nbd> you should always use :=
[23:36] <nbd> with = you can define variables at a later point
[23:36] <nbd> and have them apply to lines preceding them
[23:36] <nbd> which is a bit confusing
[23:36] <nbd> := means 'from now on make it have this value'
[23:37] <florian___> ok
[00:00] --- Sat Jul 1 2006
[13:48] <florian___> ola
[15:15] <florian___> how should I tag my makefiles for instance ?
[20:28] <nbd> db90h: it should be very usable
[20:28] <nbd> db90h: but many packages are still missing and need to be ported
[20:28] <nbd> but porting a package over isn't that hard, even though the format is a lot different
[20:28] <db90h> ah, k.. i'll check it out and give it a go
[20:29] <db90h> what was the rationale for switching anyway? sorry with the questions
[20:29] <nbd> when you want to port packages yourself, let me know. i can help you with that
[20:29] <nbd> switching to what
[20:29] <nbd> ?
[20:29] <db90h> k, will do
[20:29] <db90h> buildroot-ng
[20:29] <nbd> the old build system was becoming too messy
[20:29] <nbd> and to add a single package you had to edit lots of files
[20:30] <nbd> you couldn't just copy in a package directory and expect it to be there
[20:30] <nbd> (like you can with buildroot-ng now)
[20:30] <nbd> also you had to add lots of redundant information
[20:30] <nbd> e.g. the description once for the menuconfig file, once for the ipkg control file, etc.
[20:30] <db90h> yea, i created a package on the old buildroot..did have to edit a few files
[20:30] <nbd> that all got merged into the main makefile, which contains all the metadata now
[20:30] <db90h> ah, that's cool..
[20:31] <nbd> if you copy in a package directory and run make menuconfig, it'll be integrated immediately
[20:31] <db90h> neat ;)
[20:32] <nbd> and the whole templating stuff that we use make it a lot easier to extend the format without breaking compatibility
[20:32] <nbd> so it's really a huge step forward
[20:37] <db90h> looking at optimize_lib.sh.. my *sh scripting isn't so developed, but it looks like it searches all ELFs in the filesystem for use of every symbol in every library and removes ones not used..?
[20:38] <nbd> correct
[20:38] <nbd> it's a bit tricky to integrate into the build system while still keeping sstrip
[20:38] <nbd> but i already have some ideas on how to pull that off
[20:39] <florian___> nbd: do you think porting lzma to jffs2 is hard ?
[20:39] <nbd> i think it's unnecessary and it complicates things because of ++
[20:39] <nbd> c++
[20:40] <florian___> ah true
[20:40] <db90h> florian___: I asked him about that just yesterday ;).. i too would like to integrate LZMA, but it's apparently not as trivial as I thought
[20:40] <florian___> how do I handle the flash partition reprogrammation ? with the bootloarder or with the kernel ?
[20:40] <nbd> and the main reason for jffs2 having worse compression than squashfs is the fact that it's a writable filesystem
[20:40] <db90h> nbd: i need to look into sstrip's role, but my assumption is that its removing of symbols prevents the search for unused symbols?
[20:41] <nbd> florian___: you don't need to 'change' any partition maps. write an appropriate mtd map driver that figures things out at run time
[20:41] <db90h> i may be totally whack on sstrip tho, need to look into it
[20:41] <nbd> db90h: sstrip removes the section header table from the elf files
[20:41] <nbd> db90h: libbfd (from binutils) can't deal with that yet
[20:41] <db90h> ah, k..
[20:41] <nbd> db90h: which means any libbfd based program will fail to even open sstripped elf files
[20:42] <florian___> nbd: so, the flash memory is dynamically divided into the partition size ?
[20:42] <florian___> I mean, if the kernel fits in x kb, it's partition is x kb ?
[20:42] <nbd> florian___: yes. the ar7 flash map driver is a good example
[20:43] <florian___> ok, is it standard ?
[20:43] <nbd> florian___: it knows where the kernel starts and figures out how big it is and how big the filesystem partition should be
[20:43] <db90h> i had misunderstood sstrip's function.. i'll take a look at its source and get up to speed with everything that's going on .. need to read up on ELF file format too
[20:43] <nbd> florian___: all of the mtd stuff that we have can be considered non-standard
[20:43] <nbd> florian___: because every device uses its own mtd mapping code
[20:43] <nbd> florian___: a lot of devices simply pull the mtd map from the boot loader
[20:43] <florian___> ok
[20:44] <florian___> I have another question
[20:45] <florian___> if I want to add a fetch target, how would I do it ?
[20:45] <nbd> fetch target for what?
[20:45] <florian___> fetching all packages before building
[20:46] <nbd> buildroot-ng already does that
[20:46] <nbd> 'make download'
[20:46] <florian___> ah ok
[20:46] <florian___> great :)
[20:46] <nbd> i added it a while ago because i thought it was about time we made something like that after so many people requested it :)
[20:47] <florian___> it's useful by the way
[20:47] <nbd> btw. what do you think about moving the kernel module packaging to package/kernel-modules?
[20:47] <nbd> (to reuse the existing packaging code, maybe extending it with a few more templates)
[20:47] <florian___> I think it's a good idea
[20:47] <nbd> i think i'll work on this today
[20:48] <florian___> ok
[20:48] <florian___> I will add some libs tonight
[20:48] <nbd> i'll start with a few modules, maybe you can help me with the rest
[20:48] <florian___> ok
[20:48] <nbd> there's quite a lot of them :)
[20:55] <florian___> right :)
[21:11] <db90h> i wonder how much unused code there ends up being in the entire linux kernel, on say, a Broadcom router?
[21:14] <db90h> i mean, like old stuff for backwards compatibility... for instance, the JFFS2's inclusion of decoders for the older compression algorithms (note: of course, the decoders are tiny in that example)
[21:14] <db90h> probalby not worth it to go try to pick out such shit
[21:14] <db90h> as u might end up with headaches when packages expect something to be there
[21:14] <nbd> well, it is worth looking into things that waste space, but only the large ones
[21:15] <db90h> yea..
[21:15] <db90h> man i gotta quit mucking around with this embedded linux shit, u see what you've done to me? ;p
[21:16] <nbd> yeah... doesn't take long to get addicted
[21:16] <nbd> :)
[21:20] <db90h> so can one sstrip everything after you've removed unused symbols?
[21:23] <nbd> yes
[21:25] <db90h> so that's the issue, just hacking up the build system so sstrip is done after the symbol stripping.. i dunno how much difference this will make, but maybe i'll mess with it
[21:26] <nbd> you need to wait with the sstrip for *all* packages
[21:26] <nbd> and the optimize_lib can only be done if all packages are compiled as well
[21:26] <nbd> so the required change is a bit more than tha
[21:30] <db90h> right
[21:31] <db90h> in my case, I won't worry with making sure I build and search all packages, just the ones I'm including in my particular firmware image..
[21:31] <db90h> of course it will muck up some packages installed afterwards, but for this super micro build, allowing installing of new packages isn't part of the plan
[21:32] <db90h> well, i won't disallow installation, but won't support it.. the plan is to create an openwrt buiild that has as many common packages in the squashfs as possible
[21:33] <db90h> ..add to this a non-existant web UI and you've got a kickass new micro firmware.. but in the end what I'd be doing is re-creating dd-wrt micro with openwrt as a base ;p
[21:37] <db90h> dunno..now that i think about it, this is kinda pointless.. however, this is what people should be doing, starting with openwrt as a base and building pre-setup firmwares.. this brings openwrt to the masses in a pure openwrt system, instead of bits and pieces added to stock firmware
[21:38] <nbd> i agree. in the future we should have a web based imagebuilder
[21:38] <db90h> that'd be awesome
[21:39] <florian___> you submit your makefile and you get the ipk ?
[21:39] <nbd> no
[21:39] <nbd> custom makefiles would make it easy to run code on our server
[21:39] <nbd> i mean an image builder
[21:39] <florian___> ah sorry
[21:39] <nbd> where you can select your packages
[21:39] <florian___> ok
[21:40] <db90h> the one thing missing, perpetually, is a good web UI.. that's why I kinda hated to hear you are re-writing webif (as much as it may need it).. cuz people would have eventually extended it to the point of it being easy to use by the masses
[21:41] <nbd> people were complaining that it's too hard to write webif pages
[21:41] <florian___> well, I think that one thing we could have expected from webif was a lot of modules coming from various contributions
[21:41] <florian___> as nbd is just saying, even with the abstraction it's quite tricky to do things
[21:42] <nbd> in the next version the webif engines should be somewhat pluggable
[21:42] <nbd> so you could replace the plain old engine with something AJAXy
[21:43] <florian___> lol
[21:43] <nbd> or with a ncurses frontend :)
[21:43] <nbd> ideally a webif page should just define a basic form structure and handle configuration reads/writes
[21:43] <nbd> and the shared code should do the rendering
[21:44] <db90h> yea
[21:44] <nbd> making the pages pure-awk will probably also help
[21:45] <florian___> it will certainly refrain people from writing stuff
[21:45] <nbd> ?
[21:45] <db90h> it's kinda a big chore to do right, and another big chore to create the pages build on it..
[21:45] <florian___> awk is not that simple to learn
[21:46] <florian___> and I am sure people will want to hack inside the core functionning as well as the rendering
[21:46] <nbd> another solution would be integrating awk well enough so that you don't notice it's awk
[21:46] <nbd> kind of like the new config format where you don't notice it's actually a shell script
[21:46] <nbd> anyway... awk is necessary
[21:46] <nbd> i don't want to make a dead-slow shell based interface
[21:46] <florian___> it is fast enough
[21:47] <db90h> u know.. this might be insane, but there's another way.. u could write a terminal based configuration tool (and perhaps even make its templates compatible with the eventual web UI)
[21:47] <nbd> db90h: that's what i mentioned above
[21:47] <nbd> db90h: (ncurses frontend)
[21:47] <db90h> ah, sorry
[21:47] <db90h> i didn't know what ncurses was (again my linux ignorance ;p)..
[21:47] <nbd> no problem
[21:50] <db90h> well i'm glad to hear this is a priority.. sometimes i get the impression many would prefer openwrt never have a web UI ;)
[21:50] <nbd> db90h: the problem is: a good webui is really hard to implement properly
[21:50] <nbd> db90h: because it has to be really small, really modular and usable at the same time
[21:51] <db90h> yea, i can see the problem.. much easier to hack something together that works for a particular platform and set of packages (ala dd-wrt)
[21:51] <nbd> yep
[21:52] <nbd> one option i'm also considering is cleaning up haserl and doing a real cgi wrapper with more embedded templating code
[21:53] <nbd> so that i can really customize the syntax without having to rely too much on awk/shell
[21:53] <nbd> but that's a bit of work and my c (for user space) is a bit rusty
[21:53] <nbd> i hate writing parsers and stuff in c
[21:53] <nbd> because i don't know much about it
[21:53] <florian___> parsers are a real pain in general :)
[21:54] <db90h> amen to that
[21:54] <nbd> but doing something like that would solve lots of problems
[21:54] <florian___> probably more in c because of the mm you have to do
[21:54] <nbd> maybe i really should take some time to read up on bison et al
[21:55] <florian___> yeah bison is great for that
[21:55] <florian___> string -> action
[21:55] <nbd> we should design a webif page syntax together
[21:55] <florian___> sure
[21:55] <nbd> and then try to get it right once we've agreed on something
[21:56] <nbd> we can use some elements to save some work, e.g. haserl's way of spawning a subshell for interpreting certain code sections
[21:58] <nbd> so we don't have to write our own interpreted scripting language
[21:58] <nbd> that would be too much
[21:59] <db90h> hmm.. this is unrelated to doing things properly.. way unrelated.. but for playing around, what if a person ripped out DD-WRT's web UI (and facilitating modules), assumed a specific set of packages to be installed, and then wrote an NVRAM->config file translator to do things like set up iptables for port forwarding, etc..
[21:59] <db90h> ;p
[22:00] <db90h> this wouldn't be usable for openwrt, of course.. i'm still speaking of my own specific firmware (let's call it dbwrt ;p)
[22:00] <nbd> i think that would be a complete waste of time
[22:01] <db90h> hehe, yea.. the best you could hope for is getting a result as good as dd-wrt
[22:01] <nbd> nvram->config translation would be a bit tricky as well
[22:01] <db90h> (well, maybe with slightly better performance with better packages..)..
[22:01] <nbd> because the new format is structured differently
[22:01] <nbd> and the dd-wrt web interface contains huge amounts of bloat
[22:02] <db90h> yea, i guess i will have to give up that notion.. i just keep wanting to merge dd-wrt's web UI and openwrt's base, can't get it out of my head ;p
[22:02] <nbd> :)
[22:03] <db90h> what new format are you talking about anyway?
[22:03] <nbd> the one we're moving to. i'll look up an example for you
[22:04] <nbd> this is for the wifi config: http://pastebin.ca/75948
[22:05] <db90h> ah, cool
[22:06] <nbd> it can be interpreted with pure shell
[22:06] <nbd> and manipulated with awk
[22:06] <florian___> nbd just a question
[22:06] <florian___> I want to test some packages
[22:07] <florian___> well testing the package building
[22:07] <florian___> so I made a symlink from packages/<category>/<pkg name> to buildroot-ng/package/
[22:07] <florian___> I see it in the menuconfig, but it is not built, any mistake I could have made ?
[22:08] <nbd> can you show me the makefile?
[22:08] <florian___> sure
[22:09] <florian___> http://pastebin.ca/75951
[22:10] <florian___> I think it has not been added to targets probably ?
[22:10] <nbd> looks ok to me
[22:10] <nbd> what happens if you run make package/<pkgname>-compile?
[22:12] <florian___> it works
[22:12] <nbd> is it integrated into openwrt/.pkgdeps?
[22:13] <florian___> .pkgdeps is empty
[22:14] <florian___> but .pkginfo contains the <pkg>
[22:14] <nbd> .pkgdeps should never be empty
[22:15] <florian___> ah, what can make it empty ?
[22:15] <florian___> I have choosen other packages as well : busybox ...
[22:15] <nbd> try scripts/gen_deps.pl < .pkginfo
[22:15] <nbd> see if it outputs anything
[22:16] <florian___> nothing
[22:16] <nbd> that's odd
[22:16] <florian___> I have the latest revision
[22:16] <nbd> try rm .pkg*; make oldconfig
[22:16] <nbd> wait
[22:16] <nbd> before you do
[22:16] <nbd> please give me a paste of .pkginfo
[22:18] <florian___> ah what happens, I can't see the packages anymore ?
[22:18] <nbd> seems like it fails to properly generate .pkgdeps
[22:18] <nbd> did you change anything in rules.mk or so?/
[22:19] <florian___> in package.mk, actually, I have just restored the version
[22:19] <nbd> ok
[22:20] <florian___> I got warnings regarding undefined symbols we found in package configurations
[22:21] <florian___> well, I can use a clean svn revision
[22:21] <florian___> ok it's fixed now
[22:22] <florian___> here is my .pkginfo before make oldconfig
[22:22] <florian___> ah, it's far better, now I have the control file displayed
[22:22] <florian___> I did not have it before
[22:22] <florian___> I think it will work now
[22:59] <CIA-17> nbd * r4100 /branches/buildroot-ng/openwrt/toolchain/gcc/patches/4.1.1/900-c++_fixes.patch: add hack for building c++ with gcc 4.1.1
[23:06] <florian___> nbd I tought it was fixed in fact it is not :(
[23:06] <nbd> is .pkgdeps still empty?
[23:06] <florian___> not this time
[23:07] <nbd> does your package appear in .pkgdeps?
[23:10] <florian___> yep
[23:10] <nbd> ah, i know
[23:11] <nbd> the menuconfig option probably won't take the '+'
[23:11] <nbd> let me check sth...
[23:11] <florian___> ok
[23:13] <nbd> maybe you should edit package.mk to allow the user to override the menuconfig name
[23:14] <nbd> oh, wait
[23:14] <nbd> that would not be enough
[23:14] <nbd> you should allow the user to override the name of the ipkg
[23:15] <nbd> and then call all variables like Package/uclibcxx
[23:15] <nbd> because there are more variables that contain the package name
[23:15] <nbd> does that make sense?
[23:25] <florian___> ah I did not think about that
[23:28] <florian___> ok that was the trick
[23:29] <nbd> when we've moved the kmod-* packages to package/kernel-modules, we'll also finally have a proper way of adding dependencies on them
[23:29] <[mbm]> as I pointed out before, if you have any typo in one of the package makefiles the page will be silently dropped from .pkgdeps .. no warning given
[23:29] <nbd> [mbm]: it wasn't dropped entirely
[23:29] <nbd> [mbm]: it was displayed but not built
[23:29] <[mbm]> ah, ok
[23:30] <[mbm]> (we still need to address the other issue though)
[23:30] <nbd> should be easy to fix
[23:30] <florian___> well renaming it to uclibcxx is not that bad
[23:30] <nbd> i mean the silent drop thing
[23:31] <nbd> florian___: but the ipkg and the menuconfig entry should still be called uclibc++
[23:34] <florian___> ah ok, just the call BuildPackage ?
[23:35] <nbd> the templates and the BuildPackage call should refer to uclibcxx
[23:35] <nbd> and the Package/uclibcxx template should contain something like NAME:=uclibc++
[23:35] <nbd> which should override things in include/package.mk
[23:35] <florian___> ok
[23:35] <florian___> what's the difference between := and = ?
[23:36] <nbd> you should always use :=
[23:36] <nbd> with = you can define variables at a later point
[23:36] <nbd> and have them apply to lines preceding them
[23:36] <nbd> which is a bit confusing
[23:36] <nbd> := means 'from now on make it have this value'
[23:37] <florian___> ok
[00:00] --- Sat Jul 1 2006