[00:20] <nbd> groz: yes
[00:20] <groz> ok, got a quick question for ya
[00:20] <groz> when you redid the kmod stuff
[00:21] <groz> did you do a build against a 2.6 kernel
[00:21] <groz> or just against the brcm 2.4 stuff ?
[00:21] <groz> i think the problems i had the other nite, before i had to leave for the weekend are related to 2.6 vs 2.4
[00:22] <groz> and i'm just now getting started on sorting out what it is, that's a part of the build system i haven't looked at in any detail yet
[00:22] <groz> but i've got x86 building and booting now using 2.4 with the latest scripts you set in
[00:23] <groz> just going to make some hardware additions there now, so i can get the modules for usb storage working right
[00:23] <groz> and add via ethernet
[00:24] <groz> the first quick look, it looks like none of the iptables stuff is actually going in and building when using 2.6
[00:25] <nbd> i think my tests were on brcm-2.4
[00:26] <groz> ok, that's all i needed to know
[00:26] <nbd> are the packages missing on 2.6 or are the files inside the packages missing?
[00:26] <groz> i built brcm-2.4, it went ok
[00:26] <groz> the packages are not there
[00:26] <groz> and the .o files to make em aren't either
[00:26] <groz> it pukes at the point of trying to make the packages, cuz all of the iptables modules are missing
[00:27] <groz> and i haven't started to look at why
[00:27] <nbd> are the modules in the kernel config?
[00:27] <groz> getting 2.4 up and going correctly on this hardware first
[00:27] <groz> no, and the menuconfig option to add em seems to be missing too
[00:27] <groz> that's why i moved over to 2.4 for now, get it all running on this hardware first with 2.4
[00:27] <groz> then go look at the 2.6 issues
[00:27] <nbd> k
[00:27] <groz> i'm still unravelling how it all works in that area
[00:28] <groz> so i cant make any intelligent changes yet
[00:31] <{Nico}> nbd: same for me, your latest kernel modules packaging changes are really hard to digest
[00:32] <groz> lol nico, i'm just trying to do small bites, and digest a piece at a time
[00:32] <nbd> any way i can help?
[00:32] <groz> the 2.4 build seems to work, and i am unravelling from there
[00:32] <nbd> mostly it's just a wrapper around the regular package building code
[00:33] <nbd> with some stuff to remove code duplication for all the kernel stuff
[00:34] <{Nico}> nbd: did your port your changes to add -ng to the WR sdk to trunk?
[00:35] <nbd> which changes?
[00:36] <{Nico}> sorry, i missed some words: you added ability to build -ng packages in the WR sdk, right?
[00:37] <nbd> yes
[00:37] <nbd> and the ability to build old packages in the -ng sdk
[00:37] <{Nico}> is it in trunk too?
[00:37] <nbd> no
[00:38] <{Nico}> the latest wasn't supposed to be advertised :)
[00:38] <nbd> :)
[00:42] <{Nico}> any objections putting an rc5-ng backports online?
[00:42] <nbd> good idea
[00:42] <nbd> but it should be built automatically
[00:42] <nbd> maybe daily package snapshots
[00:43] <nbd> and when everything stabilizes, probably firmware snapshots as well
[00:48] <{Nico}> nbd: we need some changes in the sdk for that
[00:49] <{Nico}> log the output of package builds
[00:49] <nbd> yeah
[00:49] <{Nico}> and don't fail on build errors
[00:54] <groz> sorry, i got dragged away by the phone
[00:57] <groz> ok nbd, think i found the issue
[00:57] <groz> when i do make menuconfig under 2.4
[00:58] <groz> I get a netfilter extensions submenu
[00:58] <groz> in the 'kernel modules' section
[00:58] <groz> when 2.6
[00:58] <groz> the 'kernel modules' submenu doesn't exist
[00:58] <groz> so i cannot get there to enable the netfilter stuff
[00:58] <groz> now, i'm not 100% sure yet were that comes from
[00:59] <groz> oh wait
[00:59] <groz> it is there, just move
[00:59] <groz> moved
[00:59] <groz> but that whole section doesn't appear to be built
[01:00] <groz> i'll start digging, this could be some kind of dependancy thing
[01:44] <{Nico}> i'm building -ng packages with latest WR sdk now
[01:45] <{Nico}> avahi is failing (some ipv6 defs missing in uclibc)
[01:46] <crazy_imp> {Nico}: what do you think about my changes at the download.pl ?
[01:47] <groz> nbd, got a sec ?
[01:52] <{Nico}> crazy_imp: i'll take a look tomorrow, i'm falling asleep right now
[01:52] <{Nico}> 'night all
[01:52] <crazy_imp> ack
[09:30] <florian__> ola
[09:31] <groz> good morning
[09:33] <groz> got a quick dumb question
[09:33] <groz> do you know of a cleaner way than findstring to case out kernel version in the makefiles ?
[09:34] <groz> i've got a couple iv'e stumbled on that i need to case out for 2.6
[09:34] <florian__> depends on what you have to determine the kernel version
[09:34] <groz> in netfilter.mk
[09:34] <florian__> if you only have the makefile, I guess findstring is the best way
[09:35] <florian__> or grep with cut
[09:35] <groz> yah, 2.6 doesn't have a couple of the netfilter modules in the nat group
[09:35] <florian__> right
[09:35] <groz> i just put in a findstring, but was wondering about something cleaner
[09:35] <groz> <--- not a make/scripts guru
[09:36] <florian__> you can use /me ;)
[09:36] <florian__> like /me is not a make/scripts guru :)
[09:36] Action: groz thinks /me is boring
[09:36] <florian__> lol
[09:36] <florian__> getting back to serious things, findstring is a make internal command
[09:36] <groz> i'm just working over some of these things
[09:37] <florian__> so that you don't use external shell utils
[09:37] <groz> example, via rhine support
[09:37] <groz> and a few other _details_
[09:37] <groz> so i can get my via boards up and going
[09:37] <florian__> via rhine support for a particular device ?
[09:37] <groz> yah, via itx motherboard
[09:37] <groz> wonderful little board, you know them ?
[09:37] <florian__> sure :)
[09:37] <groz> 2 ethernet 4 serial, fanless
[09:38] <florian__> yep good workstation I think
[09:38] <groz> so re-wroking a few things to get them going
[09:38] <groz> i think they are an ok thinstation, a GREAT router
[09:38] <groz> this one has 4 serial ports
[09:38] <groz> i use them in a couple spots for handling a ton of serial stuff
[09:38] <groz> i have one mounted on a ship, it's got gps, solid state gyros on serial ports for input
[09:38] <groz> and then it drives a set of steppers on outputs
[09:39] <groz> to keep a sattelite antenna aimed
[09:39] <groz> using 3 of the 4 serial ports righ tnow
[09:39] <groz> got 2 more on my desk here
[09:39] <florian__> I don't think they are a great router
[09:40] <groz> you dont ? why not ?
[09:40] <florian__> mostly because dedicated hardware will be far more efficient
[09:40] <florian__> the only advantage I see in using this box as a router is the complete ownership of both hardware/software for routing and other various IP services
[09:40] <florian__> ah, but via itx boards have aes-padlock right ?
[09:41] <groz> depends which variant you have, some of them do
[09:41] <florian__> then they can be as efficient as dedicated hardware for SSL VPN's and IPsec
[09:41] <groz> i like these cuz it allows 'complete ownership' of the software, and i use them for 'special case' places
[09:41] <groz> nice little solid state boxes
[09:41] <groz> with plenty of horsepower to do more than 'just route'
[09:42] <florian__> right
[09:42] <Bartman007> groz: but the via rhine drivers can be a PITA.
[09:42] <groz> nahh, they 'just work' here
[09:42] <florian__> they are far better than rtl8139 anyway ;)
[09:42] <groz> they are a pain with some of the cards all right
[09:42] <groz> but when it's an all via motherboard
[09:42] <groz> they 'just work'
[09:43] <florian__> well, ethernet chips are quite well documented/not secret, and the ethernet technology is far from being complicated
[09:43] <groz> which brings up an interesting question
[09:43] <groz> how many folks are adverse to one file system, probably ext2 being 'in the kernel' rather than a module
[09:43] <groz> so we can set these up to make netboot images too
[09:44] <groz> i'm netbooting here
[09:44] <florian__> I really don't like initrd at all
[09:44] <florian__> at least on my all day boxes
[09:44] <groz> but that requires one file system 'in the kernel' to deal with the net boot image
[09:44] <Bartman007> florian__: that makes 2 of us
[09:44] <groz> well, initrd/ramdisk, no difference on a device with no hardware for storage on it
[09:45] <groz> i build them up as a motherboard, with a stick of ram, and that's it
[09:45] <groz> netboot them
[09:45] <groz> and they sit there 'just working'
[09:47] <florian__> yeah, it's another approach
[10:01] <[mbm]> .
[10:22] <CIA-17> florian * r4274 /branches/whiterussian/openwrt/package/busybox/patches/ (350-ping-opt-srcaddr.patch 351-telnet-opt-srcaddr.patch): Add ping -l (preload) and telnet -b (bind alias), closes #528
[10:40] <florian__> anyone working on the busybox upgrade to 1.2.0 ?
[10:43] <[mbm]> no, but that sounds like a good idea
[10:44] <florian__> I am trying to fix as much rc6 tickets as I can
[10:46] <[mbm]> :)
[10:46] Action: [mbm] needs to find time to fix a few things for rc6
[10:48] <florian__> damn, Brainslayer is laughting at me, he told me he had a working mtd map for bcm963xx, and I can't find it anywhere
[10:48] <florian__> once again, we commit the patches, he takes them
[10:48] <florian__> grr
[10:49] <[mbm]> lame
[10:50] <florian__> the mp3 decoder ;) ?
[10:52] <[mbm]> yes.
[11:00] <florian__> by the way, do you know how I can replace cli() by spinlocks ?
[11:01] <florian__> oh, I think I found them
[11:01] <nbd> spin_lock_irqsave maybe?
[11:02] <florian__> looks like it is not that simple
[11:02] <florian__> you have to define a spinlock
[11:02] <[mbm]> what driver still uses cli?
[11:03] <florian__> the serial console driver for brcm63xx
[11:04] <[mbm]> doesn't seem like the type of thing that really needs it
[11:04] <florian__> well currently it's cli(), which is deprecated, and I want to replace it to have clean patches
[11:06] <nbd> spin_lock_irqsave disables irqs locally and saves the flags
[11:06] <nbd> it should be enough to replace a cli call
[11:06] <florian__> ok
[11:06] <[mbm]> right, that's the correct replacement
[11:07] <[mbm]> there's a document somewhere that explains the whole transition
[11:08] <florian__> If you have any link
[11:09] <florian__> ok I think it's in the kernel Documentation
[11:12] <[mbm]> it was a pdf released by one of the kernel devs .. I'll have to dig it up later
[11:13] <florian__> I found it
[11:13] <florian__> it's in Documentation/Docbooks ..
[11:13] <florian__> don't exactly remember the name, but it's here
[11:13] <{Nico}> florian__: i have pending patches for busybox-1.2.0 + ipkg
[11:13] <florian__> {Nico}: ok
[11:13] <nbd> we should turn ipkg into a plugin
[11:14] <florian__> nbd: do you think it's worth fixing webif tickets for rc6 or not ?
[11:14] <[mbm]> heh, finally make use of that plugin hack I wrote?
[11:14] <nbd> [mbm]: exactly
[11:14] <nbd> florian__: what kind of tickets?
[11:14] <[mbm]> florian__: I intend to do some cleanup of webif
[11:15] <florian__> nbd: #25, #298, #609, #435 ...
[11:15] <groz> i've got a bunch of little changes that'll go into the x-86 stuff either later tonite or tomorrow
[11:16] <groz> just gotta do pcmcia yet for the routerboard
[11:16] <{Nico}> nbd: what name should i put in PKG_BUILDDEP? package name or source name?
[11:17] <nbd> source name, iirc
[11:18] <groz> nbd, i found the issue i was having finally with that kmod change
[11:18] <groz> there's a couple that dont exist in the 2.6 kernel, i'll have commits going in shortly
[11:19] <groz> it was a trivial fix, once i unwould myself inot it far enough to figure out how that all works
[11:20] <florian__> {Nico}: if you have time to test the au1000 port, tell me if you can get the atheros cards working
[11:20] <{Nico}> nbd: it does not seem to work when buidling -ng packages with WR sdk
[11:22] Action: [mbm] pokes florian__ msg
[11:22] <florian__> [mbm]: do you read me ?
[11:34] <{Nico}> florian__: i'll try tonight
[12:15] <db90h> patch this one liner please, it's been annoying me forever that this uselses decoder is in 2.4 jffs2 -> http://www.bitsum.com/files/jffs2_dynrubin_decoder_removed.patch.tar.gz .. you might want to remove the compr_rubin object from the makefile too, tho as long as it's not used it shouldn't be linked in to the kernel (i think)
[12:16] <db90h> i got sidetracked on my jffs2 lzma decoder (only) + mkfs.jffs2 lzma encoder addition, but i'll have a patch for it for WR RC5 maybe before RC6
[12:20] <db90h> it's really been done forever, but I got demotivated while I was porting the changes back to White Russian RC5, so a couple little things left to do
[12:21] <db90h> also, I have begun to question the usefulness of JFFS2 only filesystems.. they are neat, but it seems Squashfs-lzma + mini_fo + JFFS2 is the most size optimal distribution feasible with White Russian right now
[12:25] <[mbm]> the jffs2 only was designed with the idea that ipkg might actually work, and that you'd be able to upgrade an entire distribution with ipkg
[12:25] <[mbm]> doesn't actually happen that way and most of the people that are running jffs2 are those that didn't pay attention to the docs which suggested squashfs
[12:26] <[mbm]> plus its already possible to switch from squashfs to jffs2 without reflashing
[12:26] <[mbm]> so the whole jffs2 only images are somewhat useless
[12:28] <db90h> mark this date, because i think i agree with you
[12:28] <db90h> ;p
[12:29] <malbon> db90h: hols
[12:29] <malbon> or hola even
[12:29] <db90h> i didn't know about the plans to use ipkg to upgrade the entire distribution, that would be cool if it did work and would necessitate JFFS2
[12:29] <malbon> your tool working in linux now?
[12:30] <db90h> which tool?
[12:30] <db90h> oh, the vx firwmare tool
[12:30] <db90h> yea
[12:30] <malbon> the bsp updater
[12:30] <db90h> oh yea, that is too
[12:30] <[mbm]> db90h: :P .. you act as though we're oblivious to the issues
[12:32] Action: [mbm] knows whiterussian sucks, is obsolete and many things should have been done differently
[12:32] <db90h> malbon: i've got a vxworks reversion firwmare /w mac and serial embedding capabilities pretty much done, but I added bsptool as an OpenWrt pacakge and gotta track down one little bug in its build, then its done
[12:33] <[mbm]> I'm actually looking forward to the 1.0 transition were we basically abandon all the old legacy code and introduce the "new" stuff we've been woring on
[12:33] <malbon> db90h: okiedoke. I've a few atheros thingies here ready to test.
[12:34] <db90h> [mbm]: how is the 2.6 kernel builds doing now?
[12:35] <db90h> is 1.0 planned to be a 2.6 release?
[12:35] <[mbm]> "now"? I've been running 2.6 kernels for at least the last 6 months
[12:36] <[mbm]> for some platforms
[12:36] <db90h> freewrt claimed there were issues with the Broadcom wl driver (nbd says unfinished scripts to configure it properly), so I assumed that it wasn't really ready..
[12:37] <[mbm]> wl doesn't run on 2.6
[12:37] <db90h> whatever the wireless driver is i mean
[12:37] <[mbm]> so basically the brcm-2.4 (basically the whiterussian tree) is the only thing still using a 2.4 kernel
[12:38] <[mbm]> there's teh opensource bcm43xx to replace the wireless driver, which is now getting integrated with the kernel
[12:38] <db90h> cool
[12:39] <[mbm]> I have no idea how stable it is, I basically stopped using broadcom wireless chips
[12:39] <db90h> dd-wrt is using the proprietary one and seems to have had some success getting it to work right, but there's still issues
[12:39] <[mbm]> you're confusing multiple issues
[12:39] <db90h> oh, i am?
[12:39] <[mbm]> there is no proprietary wireless driver for 2.6
[12:40] <[mbm]> if there was we'd be using it and 2.6
[12:40] <murb> [mbm]: I've had some success with it on an ibook.
[12:40] <murb> (the reverse engineered wl driver)
[12:41] <[mbm]> the proprietary driver (wl) works fine on 2.4, and since it's basically provided by broadcom it actually works
[12:42] <db90h> oh, yes, i see now.. i was confused and thought the new proprietary driver dd-wrt v24 is using was for the 2.6 kernel
[12:42] <[mbm]> the same can't be said about the bcm43xx driver because it's really based on speculation and reverse engineering -- I'm sure if they actually had documentation it'd be done by now
[12:42] <[mbm]> nobody has released a 2.6 based firmware for the broadcom yet
[12:42] <db90h> i had just assumed dd-wrt v24 was v2.6, i'm glad we had this conversation, that clears up a lot ;p
[12:43] <murb> well there is still the argument about which 802.11 stack to use in the kernel.
[12:43] <[mbm]> (although you can easily build one with buildroot-ng)
[12:43] <[mbm]> murb: yeah, although at this point I honestly don't give a damn as long as they pick one
[12:43] <[mbm]> I'm sick of each driver having it's own 802.11 stack
[12:44] <[mbm]> looks like they've settled on the decicescape stack
[12:45] <db90h> ok, so the 2.6 open source bcm43xx driver isn't fully mature and wlconf doesn't work with it? is that right?
[12:46] <malbon> with the new driver isn't wlconf obsolete?
[12:46] <[mbm]> wlconf was basically written for the brcm-2.4 platform
[12:46] <[mbm]> it depens on the broadcom ioctl interface and nvram
[12:46] <[mbm]> both of which will be obsoleted
[12:46] <db90h> ok, so wlconf has to be replaced
[12:47] <[mbm]> (likewise wlcompat will also be useless)
[12:50] <db90h> it's been a long hard road out of the fog of assumptions and ignorance
[12:51] <[mbm]> I'm sure there's still some left
[12:51] <[mbm]> also doesn't help that when you finally agree with me you follow up with what's basically an insult of "mark this occasion"
[12:53] <db90h> there's more ignorance than anything left ;).. and I didn't mean that as an insult at all, just was a joke
[13:05] <db90h> anyway, i'm socially inept and quite insane (seriously), so i advise not taking me too seriously
[13:05] <db90h> here's my next question.. how much do you think removing unused symbols will really save on post-compressed size?
[13:05] <[mbm]> symbols from what?
[13:06] <db90h> all libs
[13:06] <[mbm]> sounds like you'd break the lib and probably wouldn't save much space for it
[13:06] <db90h> i assumed anyway..better check that too since my other assumptions have been bad
[13:07] <db90h> what symbols does dd-wrt remove? from the kernel?
[13:07] <db90h> surely not..
[13:07] <db90h> tho maybe so
[13:07] <db90h> let me look here
[13:07] <[mbm]> this isn't dd-wrt, so I have no idea
[13:07] <db90h> nbd said this is something he was going to do someday for micro distributions
[13:08] <db90h> but u have to build all packages to make sure you have a comprehensive list of used symbols (and even then new packages could use one that you removed)
[13:08] <[mbm]> honestly though you should read the elf specification (there's a pdf in my dir) .. after you strip the debugging contexts and useless sections like .note and .comment there really isn't much to be saved by further stripping
[13:09] <[mbm]> and by strip I mean the 'strip' or 'sstrip' programs
[13:09] <db90h> yea, i'm not famaliar with the ELF specs, that's been on my todo list
[13:09] <[mbm]> if you actually want to remove functions, you can save some space
[13:09] <[mbm]> but that's not what those programs do
[13:10] <db90h> yea, the reason i asked was i figured it surely couldn't help much in post-compressed image size..
[13:10] <[mbm]> you also run compatibility issues when you start removing stuff
[13:10] <[mbm]> we tried to remove libgcc and got nothing but headaches
[13:11] <db90h> definitely.. but for micro builds you often have a static set of packages, so maintaining compatibility with third-party packages isn't as big a deal
[13:11] <db90h> (a static set of packages is obviously not in line with openwrt's philosophy)
[13:12] <[mbm]> for micro images things should basically be linked into multicall binaries and compiled as statically as possible
[13:12] <[mbm]> but openwrt isn't aimed at the micro platforms
[13:12] <[mbm]> the time involved vs the benefits of it really don't make it time well spent
[13:14] <db90h> yea, that's true
[13:15] <florian__> maybe we could make some efforts for wap54g for instance ?
[13:15] <[mbm]> I'd rather unify the platforms as much as possible instead of adding more special cases for plaforms with limited resources
[13:16] <florian__> yes I understand, how could we have a general mean to reduce the image size ?
[13:16] <[mbm]> basically the stuff you'd have to do to make a good micro image conflicts with the stuff we do for the other platforms
[13:17] <db90h> yea, there is a seemingly unresolvable conflict here between size optimization and the design ideals of openwrt
[13:17] <db90h> that said, trying to reduce the size of openwrt in any way that doesnt' compromise the design ideals is definitely a good thing.. tho not sure how much more of a difference can be made in this area
[13:18] <[mbm]> florian__: we've basically reduced things down as far as they'll go without breaking compatiblity or expansion
[13:18] <florian__> sure, does jffs2-lzma makes sense ?
[13:19] <[mbm]> yes, and I'm sure once the patch is working we'll do it
[13:19] <db90h> florian__: you saw my project where i added an lzma decoder to jffs2, and an lzma encoder to mfks.jffs2 so that pre-included files are compressed with lzma?
[13:19] <malbon> yeah I think so. it'd be slow to compress, but it'd be small.
[13:19] <florian__> db90h: sorry I did not see that
[13:19] <db90h> it improves compression 10-20%.. i need to finish this up today before it dies forever.. i started to try to backport the 2.6 JFFS2 code to 2.4, but it was a pain
[13:20] <[mbm]> :)
[13:20] <db90h> malbon: yea, as far as addign the lzma encoder to the jffs2 filesystem, there is an issue with it being C++ .. but when a C encoder is created, or when the C++ issues are worked with, an LZMA encoder is definitely no slower than runing JFFS2-BBC in size mode (which iterates through some 5 compressors for each block of data compressed)
[13:21] <db90h> keep in mind the JFFS2 compressed data in 4kb blocks, so there isn't much overhead to encoding
[13:21] <malbon> db90h: nope, you can use the standalone compressor
[13:21] <db90h> because the maximum dictionary size (for LZ based encoders) is 4KB, making the memory overhead of the phrase tries and CPU overhead of phrase searching not bad at all
[13:22] <malbon> db90h: got the sdk?
[13:22] <db90h> yea, of course.. the LZMA_Alone u mean?
[13:22] <db90h> that's just the decoder..
[13:22] <db90h> the Encoder is C++..highly OO, hard to port directly to C.. tho Igor Pavlov is working on a C build mirable tells me..
[13:23] <db90h> if I am wrong on this, please let me know, cuz I'd love to go ahead and add the lzma encoder
[13:24] <[mbm]> there's a C directory in the lzma code but if I remember right that's only the decoder (and it was an absolute mess of #if statements)
[13:25] <malbon> yes, your right, all the encoders do seem to be c++
[13:25] <db90h> the C folder contains sub-folders that have the C++ encoder and C decoder
[13:25] <db90h> adding the encoder to mkfs.jffs2 took just a minute tho, the code is easy to use.. just nbd tells me that C++ in the kernel is not trivial, so I've trusted him on this and not tried
[13:26] <db90h> one thing that got me distracted on this was trying to port the 2.6 JFFS2 code to 2.4.. why? cuz this code is a lot better. It takes many of the BBC enhancements and merges them with the base code, resulting in a cleaner source
[13:26] <[mbm]> C++ in the kernel is very annoying to do and will basically get you kicked out of places like the linux kernel mailing list
[13:27] <[mbm]> c++ just isn't a good language for system level stuff
[13:28] <florian__> why does nobody made a C portage of lzma ?
[13:28] <[mbm]> (I'm not particularly fond of c++ userspace applications wither)
[13:28] <db90h> [mbm]: what do you think of the feasibility of porting jffs2 in 2.6 to 2.4?
[13:29] <CIA-17> florian * r4275 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/patches/ (001-brcm_boards.patch 020-bcmdrivers.patch): Clean up patches : remove warnings, move cli() and save_flags to spinlock mechanisms
[13:29] <[mbm]> florian__: lzma isn't yet a popular compression scheme so theres basically only one copy of the source
[13:29] <db90h> and lzma is so highly OO that it won't be easy for even the author to port to C, tho he's supposedly working on this
[13:30] <[mbm]> plus the fact that the proceedure isn't commented for anyone else to write it
[13:30] <[mbm]> you basically have to read and understand the c++ version (which is a mess) before you can write a c version
[13:30] <db90h> yep, tho he's improved the code some over the last year, it's no pleasant thing to work with .. i think he must strip comments before he releases ;p
[13:31] <florian__> hu
[13:31] <db90h> the 7zip code is even messier
[13:31] <db90h> it would be easier to re-write the LZMA algorithm
[13:31] <[mbm]> every time I see the lzma code I'm tempted to run it through a parser to get rid of the tons and tons of #ifs and then run it through lindent
[13:32] <db90h> hehehe, yea i hear ya
[13:33] <[mbm]> as for the jffs2 backport, it'd be nice but it sounds painful .. are you sure it'd be worth it?
[13:33] <db90h> no, not sure at all
[13:35] <[mbm]> there's some people that like new code just because it has a higher version number .. I usually insist on some measureable improvement first
[13:36] <db90h> the code is cleaner thanks to the 'proper' integration of most of the BBC ideas, and I wanted to have a 2.4 and 2.6 lzma decoder patch that was very close to the same for easier maintenance.. but as far as advantages to OpenWrt, i don't know
[13:37] <db90h> it might improve compression speed in size mode cuz it doesn't have all the encoders of BBC (many of which are seldom used anyway i think), but i doubt it'll improve comprsession ratio
[13:37] <[mbm]> if it makes it easier for the lzma patch then I'd probably backport jffs2
[13:38] <[mbm]> dwm2 has been in #openwrt a few times, you might see what he has to say about it
[13:38] <db90h> well the lzma patch itself is super-simple, it's easy to extend jffs2 with new compression algorithsm.. so it's no huge deal to maintain two copies i guess
[13:40] <db90h> ok, i'll ask him if i see him
[13:40] <CIA-17> florian * r4276 /branches/whiterussian/openwrt/package/lighttpd/ (Makefile patches/500-configure_cross.patch): Upgrade lighttpd to 1.4.11, fixes the mod_proxy issue, closes #652
[13:43] <db90h> what if I brought the lzma in white russian rc5 up-to-date? is there any reason u guys haven't done this already?
[13:44] <[mbm]> you mean the squashfs-lzma or the lzma compression we use on the kernel?
[13:44] <db90h> the squashfs-lzma
[13:44] <db90h> the lzma folder it uses i'm also using the mkfs.jffs2 extension, as a 'shared' lzma folder
[13:45] <[mbm]> probably could use an update .. hasn't been a high priority though
[13:45] <florian__> yeah you mean lzma-432 right ?
[13:45] <db90h> yea
[13:45] <db90h> tho there's newer one now
[13:45] <[mbm]> btw since squashfs and jffs2 are both going to be using lzma you should make it a common library in the kernel
[13:45] <florian__> right 437 or newer ?
[13:46] <db90h> [mbm]: yep, i ran into that.. currently i have a seperate lzma decoder for the jffs2 fs cuz the squashfs lzma decoder is compiled with different flags, but i planned to use only one.. this is on the todo list
[13:47] <db90h> 4.43 is newest
[13:48] <florian__> right
[13:48] <db90h> [mbm]: as far as turning it into a proper library in the kernel, this would take me a bit of time to integrate right.. squashfs-lzma patch just shoves the lzma decoder in there i think, so i'd have to modify it, create a proper library, then change makefile and config, and more stuff i guess.. not as easy as just using the pre-existing lzma decoder squashfs shoved in there
[13:49] <db90h> but in cases where squashfs-lzma isn't linked in, i need to put in my own lzma decoder.. so gotta figure out how to detect and handle that in the make
[13:49] <[mbm]> yeah, takes slightly mor work
[13:49] <[mbm]> I'd suggest looking at how crc32 is handled
[13:50] <db90h> ok, thanks, i'll take a look at it
[13:50] <db90h> making it a library is the right thing to do and solves the case where squashfs-lzma is missing
[13:51] <[mbm]> right, then both squashfs and jffs2 depend on the libary
[13:51] <db90h> this will add some time for sure, but i'll do that .. good idea, thanks
[13:51] <[mbm]> you can even get fancy and have the encoder as a separate config symbol so that the encoder only gets enabled when using jffs
[13:52] <db90h> u mean for when and if we ever add the lzma encoder to the kernel?
[13:53] <[mbm]> ;)
[13:53] <[mbm]> well, the lzma encoder in the kernel will basically be a requirement for jffs2-lzma
[13:54] <[mbm]> I take it that for now you only made the patches to mkjffs2 and only put the decoder in the kernel?
[13:55] <db90h> yea, i'm leaving that to be done somewhere done the line tho.. i'm just adding it to mkfs.jffs2 and at least improving the compression of all those pre-included files
[13:55] <db90h> right
[13:55] <[mbm]> heh, cheater but I suppose I'd do the exact same thing
[13:56] <db90h> hehe
[13:56] <[mbm]> does mean that if you even sneeze on a file it's size jumps by 10% even if the file didn't technically change
[13:56] <db90h> the difference in difficulty (considering the lzma encoder is still only c++) is like 1/100
[13:56] <db90h> yep, that's right
[13:56] Action: [mbm] has a similar problem with mini_fo
[13:57] <db90h> but i figure the majority of the pre-included filesystem never changes.. the issue that makes this kinda useless is the fact really mksquashfs-lzma should be what everyone uses for static files
[13:57] <[mbm]> soon as you poke at a file it creates a copy of the file on the overlay (jffs2)
[13:57] <db90h> if u just open it for writing and the close it withotu changes even?
[13:58] <[mbm]> haven't tested all of the cases but it is entirely possible to have two identical copies of the file
[13:58] <[mbm]> was going to fix that before rc6
[14:00] <db90h> yes, that definitely needs to be addressed.. i assume it's not too difficult.. but if it was, a user space tool could scan the filesystem and delete files whose backing file is the same as the new one
[14:00] <[mbm]> it's trivial, I already wrote the userspace util for it
[14:00] <[mbm]> just haven't gotten to the kernel part
[14:00] <db90h> cool
[14:01] <db90h> it'd be really awesome if u could use the backing file as an initial dictionary for the new file (or some other delta type compression).. this would reduce compressed size to almost nothing for small changes
[14:02] <[mbm]> that'd be fun for upgrades
[14:02] <db90h> but this seems like it would require huge changes and transcend several different drivers
[14:03] <db90h> yea, it'd be perfect for upgrades
[14:03] <[mbm]> wait, you're not suppose to agree with me :P
[14:03] <db90h> hehehe
[14:10] <florian__> anyway you'd better agree with [mbm] ;)
[14:11] <db90h> is anyone working on a web-based image builder so people can more easily do the right thing and pre-include their desired packges in squashfs-lzma?
[14:12] <Kaloz> o.O
[14:23] <db90h> what, is that ur job? ;p
[14:24] <Kaloz> no way :P
[14:24] <[mbm]> we've talked about it and it's been something on the todo list but it hasn't been done yet
[14:25] <[mbm]> figured it'd be something fun to do for the 1.0 stuff
[14:25] <Kaloz> dunno, imho it will be pretty much (ab)used :P
[14:26] <Kaloz> eg. with adding simply normal packages, i see it pretty useless
[14:26] <Kaloz> and if we let people upload anything and premodified config files
[14:26] <Kaloz> it will be insane
[14:27] <[mbm]> we'd only give them the ability to compile with packages already on the server
[14:27] <db90h> yea, most openwrt users can use linux and build their own images, but i have a tendency to focus on less linux-happy users..
[14:27] <florian__> I think we should also try to make openwrt cygwin buildable
[14:27] <[mbm]> db90h: they're the cause of many headaches -- for your own helth I suggest you either ignore them or switch them to linux users
[14:27] <florian__> I will take a look at this
[14:27] <db90h> lol
[14:28] <florian__> why lol ? ;) ?
[14:28] <db90h> mbm's comment
[14:28] <db90h> not you ;p.. i shoulda specified
[14:29] <db90h> i'd like to see openwrt cygwin buildable, tho i find it easier to just use linux in a VM than muck with cygwin
[14:29] <[mbm]> I'd worry about osx before I worried about cygwin
[14:29] <db90h> might be cool to release a pre-built virtual machine for vmplayer (free)
[14:29] <db90h> ...that is able to build openwrt
[14:30] <[mbm]> haven't checked laytely but last time I tried to compile on osx it was an absolute mess
[14:30] <Kaloz> db90h: was thinking about that
[14:30] <florian__> [mbm]: I worried about OSX, there was so many patches to commit, that I let them in a ftp
[14:30] <Kaloz> db90h: i find it more logical then a cygwin build
[14:30] <[mbm]> db90h: colinux is more efficient
[14:30] <crazy_imp> or a small livecd with the svn tree from the day?
[14:30] <Kaloz> nah, livecd isn't that good
[14:30] <db90h> i prefer virtual machines to live CDs
[14:30] <Kaloz> with vmplayer image
[14:30] <Kaloz> they can do whatever they want in the meantime
[14:30] <crazy_imp> (but there would be the problem for windows pc's where they could unpack all the packages)
[14:31] <crazy_imp> ack
[14:31] <Kaloz> the image can be big enough uncompressed
[14:31] <Kaloz> and honestly, if a windows user needs 1 or 2gb to compile anything
[14:31] <Kaloz> they will be happy anough
[14:31] <Kaloz> imho
[14:31] <db90h> [mbm]: cool, i never herad of colinux before
[14:33] <db90h> anymore tho virtual machines run pretty well even on processors without virtualization support
[14:33] <db90h> these more optimal solutions that avoid virtual machines will eventually have little use as hardware gets more and more virtualization friendly
[14:33] <florian__> well, I think I will reinstall macosx on my ibook and try to build openwrt on it anyway ;)
[14:34] <db90h> florian__: that's the spirit ;)
[14:34] <[mbm]> db90h: colinux is uml ported to windows .. runs faster than emulating an entire machine
[14:34] <db90h> [mbm]: yea, definitely it's much faster to avoid a VM.. but my comment was VM's are 'fast enough' for most people on most hardware, and are getting faster
[14:35] <[mbm]> btw, colinux tends to be a bitch when you're writing the initial xml config
[14:35] <murb> or when you typo the name of te network adaptor you wish to use..
[14:36] <db90h> I use a Ubuntu in a VM to much around with this embedded linux stuff, and it runs just peachy
[14:36] <db90h> err to muck around, not much around
[14:36] <murb> and discover microsoft turn have spanning treee turned on by default in their bridge device.
[14:36] Action: [mbm] never could understand people that ran windows as their os but then ran linux in vm .. worst of both worlds?
[14:36] <murb> [mbm]: a nice toy, but i like qemu more.
[14:37] <murb> [mbm]: i used to use it for remote support of a windows user, somewhere to tunnel vnc/ica to/from.
[14:37] <[mbm]> if anything I'd run windows in the vm
[14:38] <[mbm]> I'd hate to reboot my linux just because of some annoying windows program forcing the os to reboot
[14:38] <murb> [mbm]: win2k in qemu solves most sof my must use windows problems.
[14:38] <[mbm]> 'a new software update! you must reboot now!' .. go away .. 'automatically restarting in 10 minutes ...'
[14:39] <db90h> lol, i see u do use windows ;p
[14:39] <[mbm]> windows has some pretty damned annoying settings
[14:39] <db90h> I thought about swapping to Linux as my primary OS, but 1.) I'm a Windows developer by profession and 2.) I don't want to go through painful driver problems
[14:40] <[mbm]> 2 isn't so bad .. the real pain comes from WGA crap
[14:40] <[mbm]> soon as you switch XP over to a VM it yells at you to reactivate
[14:40] <murb> [mbm]: unless you cheat and activate it in a VM
[14:41] <murb> but you can't do taht with oem versions.
[14:41] <db90h> yea, I bet it does
[14:41] <db90h> u get like 5 different re-activations due to substantial hardware changes before u have to call
[14:41] <[mbm]> murb: yeah, you do that and then it doesn't want to boot native until you activate again
[14:41] <murb> [mbm]: any idea what it probes, you could always fix up the vm to lie to windows couldn't you?
[14:41] <[mbm]> probes tons of things
[14:41] <db90h> yea, it builds a key from a shitload of things
[14:41] <db90h> its been reversed
[14:42] <db90h> its designed to allow one or two updates and still be ok
[14:42] <[mbm]> cpu id, harddisk label, mac address, amount of memory, bios version ..
[14:42] <[mbm]> it's easier just to "find" a corporate edition that doesn't have the activation crap
[14:42] <db90h> hehe, yea
[14:42] <db90h> activation is a pain in the ass
[14:43] <db90h> as if MIcrosoft wasn't rich enough already
[14:43] <db90h> they should be happy people are using Windows, even if they are pirating it
[14:43] <[mbm]> went to the ms site for the first time in 5 years looking to download ie7 since someone told me it wasn't rendering right
[14:43] <[mbm]> my god they're annoying with wga crap
[14:43] <db90h> hehe, it's bullshit
[14:44] <[mbm]> it really is
[14:44] <db90h> WPA is bad enough, but WGA is over the line
[14:44] <[mbm]> click here to download the util .. run it.. copy the text that appears into the box
[14:44] <db90h> simple solution for me is i won't install their shit
[14:44] <[mbm]> so what makes them think I actually ran it?
[14:44] <db90h> but in times when u need it, like u did, sux
[14:44] <[mbm]> and then when I actually went to install ie7 it insisted on performing it's own wga checks
[14:45] <[mbm]> and ie7 looks like crap under the classic theme
[14:45] <{Nico}> florian__: i was working on #652
[14:45] <db90h> WGA is very arrogant for sure
[14:45] <[mbm]> (I absolutely hate the xp theme)
[14:45] <db90h> I use Windowblinds, which runs without a seperate process since it integrates well with XP.. it's surprisingly optimal
[14:46] <db90h> if it had much overhead, i'd never use it..but it doesn't
[14:46] <Kaloz> db90h: you can simply patch the themexp.dll or what, and then you can use the skins without 3rd party crap :)
[14:46] <florian__> {Nico}: ah sorry, I tought it was pending for so much time that you forgot it
[14:46] <[mbm]> if I ever find the person that said "let's make everythign a gradient with rounded edges and use bright primary colors" I'll probably strangle them
[14:46] <{Nico}> florian__: i just accepted it yesterday
[14:46] <db90h> Kaloz: true that, but WindowBlinds has a few other capabilities and isn't a bad deal
[14:48] <florian__> {Nico}: ah sorry then
[15:25] <nbd> .
[15:39] <florian__> ..
[15:50] <crazy_imp> {Nico}: heyho
[16:05] <CIA-17> florian * r4277 /packages/net/aodv-uu/ (. Makefile patches/ patches/001-normalize.patch): Add aodv-uu userspace daemon, kernel module needs makefile rewriting
[16:44] <CIA-17> nbd * r4278 /branches/buildroot-ng/openwrt/package/kernel/Makefile: don't try to create kmod packages that contain no files
[16:53] <[mbm]> nbd: wouldn't that also suggest that the modules-*.mk has the wrong deps?
[16:53] <nbd> modules-*.mk is obsolete
[16:53] <[mbm]> ah
[16:54] <[mbm]> it was there a week ago when I looked :P
[16:54] <nbd> it's still there
[16:54] <nbd> but when the transition is done, we can remove those files
[16:54] <[mbm]> ah
[16:58] Last message repeated 1 time(s).
[16:58] <[mbm]> nbd: so does that fix #653?
[17:00] <nbd> oh, yeah. it does
[17:00] <nbd> i'll close it
[17:57] <groz> nbd you around this morning ?
[17:57] <CIA-17> nbd * r4279 /branches/buildroot-ng/openwrt/target/linux/ar7-2.4/patches/003-net_driver_cpmac.patch: change cpmac to use the internal phy by default (#596)
[17:58] <nbd> groz: i'm around, yes :)
[17:58] <groz> good morning
[17:58] <groz> just want to touch base on that kmod stuff just a bit
[17:59] <groz> are you planning more major changes in the real short term for it ?
[17:59] <groz> the reason the 2.6 stuff was failing boiled down to simply some missing modules
[18:00] <groz> the question i have for you, are you real familiar with the iptables changes in 2.6
[18:01] <groz> the DNAT and SNAT modules are not there when you build it, and, there's apparently no option to enable them
[18:01] <groz> just wondering if you know offhand what they got changed to ?
[18:01] <groz> as well, i've been adding some other network devices and a few little things to the kmod package builds
[18:01] <groz> just wondering if your next batch of changes will change that all again ?
[18:02] <nbd> the kernel module stuff won't change much
[18:02] <groz> ok
[18:02] <nbd> except that the stuff from include/modules-*.mk will be ported over to the new system
[18:03] <groz> ok, hmmm, that's where i've been putting a bunch of it
[18:03] <nbd> include/modules-*.mk is obsolete
[18:03] <groz> but, it needs to be there right now no, or is there an alternate place to put that now ?
[18:03] <groz> that I missed
[18:04] <groz> I just 'follwed the breadcrumbs' on one existing module to find the spots it is referenced
[18:04] <nbd> groz: the alternate place is package/kernel/modules.mk
[18:04] <groz> ok, i'll move it there
[18:04] <nbd> groz: which has the advantage of autogenerating all menuconfig and ipkg control data
[18:05] <nbd> groz: so if you port something over there, remove the old control files and also remove the entries from target/linux/Config.in
[18:05] <groz> ok, I'll start moving it over to there shortly
[18:06] <groz> i'm ending up with a 'crash course' on 2.6 differences here, i've never really used 2.6 prior to this
[18:07] <groz> so it's been shall we say 'interesting'
[18:08] <nbd> yeah. i also have no clue about the netfilter changes in there
[18:08] <nbd> with the xt_ and ipt_ stuff
[18:08] <groz> i've got it all running ok, except for one set of details
[18:08] <groz> dnat and snat modules dont exist
[18:08] <groz> which ofc means the default firewall stuff all breaks too
[18:09] <nbd> weird. there's no nat support in current 2.6 kernels?
[18:09] <groz> oh, it must nat ok, i just dont see how to get it to build a dnat and snat module
[18:09] <groz> so it must be hidden in some of those others
[18:09] <groz> or i've done something really wrong and broke it badly here
[18:10] <crazy_imp> {Nico} or someone else, whats about my changes at the download.pl? (http://openwrt.vcp-springe.de/experimental/download.diff)
[18:13] <groz> another question i was wondering about ndb
[18:13] <groz> the way the x86 stuff builds right now, it's being patched with the patches from generic-2.6
[18:13] <groz> the big mips patch is in there
[18:14] <groz> wondering if the mips patch should be ommitted on the x-86 build
[18:15] <groz> if so, should we be moving it into a mips top level patch dir that'll only be applied to mips kernels
[18:16] <nbd> i don't think the mips patch hurts x86
[18:17] <groz> i dont think it hurts, for now
[18:17] <groz> but in the grand scheme of things, moving to support yet more arches
[18:17] <groz> wondering if we should have a /generic then possibly /mips /i386 /arm type setup
[18:17] <groz> then board specific like now
[18:18] <nbd> i think we should not do it until it becomes necessary
[18:34] <groz> ok nbd, i'm starting on pulling stuff over to the new setup
[18:34] <groz> starting with network devices, will just set up a new category for them
[18:34] <groz> same as you did with netfilter
[18:36] <CIA-17> nbd * r4280 /branches/whiterussian/openwrt/target/linux/linux-2.4/patches/brcm/001-bcm47xx.patch: fix switch-adm breakage accidentally introduced in [4155] (ticket #651)
[19:05] <nbd> [mbm]: can we remove support for the symlink hack entirely?
[19:05] <nbd> [mbm]: (squahsfs/jffs2 overlay)
[19:05] <nbd> [mbm]: maybe we should even move mini_fo to the kernel
[19:05] <[mbm]> might be slightly premature for that
[19:05] <nbd> ok
[19:06] <[mbm]> I'd like to get a release with mini_fo out and tested before we completely pull the old code
[19:06] <nbd> ok
[19:06] <[mbm]> (besides, it hardly takes any space)
[19:07] <nbd> another thing: do you think we should have a new 'patch format' in the build system that keeps all new files in a directory structure instead of a single patch file?
[19:07] <nbd> would make maintaining some things easier
[19:08] <[mbm]> hmm might make things slightly easier
[19:17] <nbd> btw. how are we going to fix dial-on-demand? default to a non-routable ip as dns in dnsmasq?
[19:17] <nbd> we talked about this a while ago, i just don't remember what we agreed on
[19:20] <[mbm]> no idea .. I'm not a ppp user so I haven't had to deal with the problem
[19:20] <nbd> we could make dnsmasq default to a certain invalid ip
[19:20] <nbd> when it sends out a dns request, this will make ppp establish the connection
[19:24] <CIA-17> nbd * r4281 /branches/whiterussian/openwrt/package/dnsmasq/Makefile: update dnsmasq to 2.32
[19:27] <groz> dumb question ndb
[19:28] <groz> in the new form of modules.mk, i dont see a way to set dependancies on kernel variants
[19:28] <nbd> KCONFIG:=$(CONFIG_...)>
[19:28] <groz> ie make the various network devices dependant on the x86 variants of kernels
[19:28] <nbd> KCONFIG is for dependencies on kernel config variables
[19:29] <nbd> and DEPENDS:= is for package and menuconfig dependencies
[19:29] <nbd> it works exactly like DEPENDS for other packages
[19:29] <groz_> grrr, got disconnected
[19:30] <nbd> 19:23 < nbd> KCONFIG is for dependencies on kernel config variables
[19:30] <nbd> 19:24 < nbd> and DEPENDS:= is for package and menuconfig dependencies
[19:30] <nbd> 19:24 < nbd> it works exactly like DEPENDS for other packages
[19:30] <groz_> ok, i'll fuss a bit more with it
[19:30] <groz_> it's probly just my typo here
[19:38] <groz_> nbd, can you see anything wrong with this ?
[19:38] <groz_> define KernelPackage/e100
[19:38] <groz_> TITLE:=Intel(R) PRO/100+ cards kernel support
[19:38] <groz_> DESCRIPTION:=Kernel modules for Intel(R) PRO/100+ cards kernel support
[19:38] <groz_> SUBMENU:=$(NDMENU)
[19:38] <groz_> FILES:=$(MODULES_DIR)/kernel/drivers/net/e100.$(LINUX_KMOD_SUFFIX)
[19:38] <groz_> KCONFIG:=$(CONFIG_EF100)
[19:38] <groz_> endef
[19:38] <groz_> $(eval $(call KernelPackage,e100))
[19:38] <nbd> no
[19:38] <groz_> it doesn't seem to matter what i do with the kconfig
[19:38] <groz_> it always shows up
[19:38] <groz_> right now, kernel has no EF100 set
[19:38] <nbd> sure, menuconfig can't figure out the kconfig stuff
[19:38] <groz_> but this still shows up
[19:39] <groz_> ok, so these will always show up then ?
[19:39] <nbd> because menuconfig is generated before it even knows what target to build for
[19:39] <nbd> yes
[19:39] <groz_> right, so what i'm wondering
[19:39] <nbd> maybe you should add this:
[19:39] <groz_> can i make that block dependant on an x86 target
[19:39] <nbd> DEPENDS:=@LINUX_2_6_X86
[19:39] <groz_> ok, that's what i was wondering
[19:40] <nbd> the DEPENDS stuff works like this:
[19:40] <nbd> without any prefix it depends on a certain package
[19:40] <nbd> adding + turns the 'depends' into a 'select'
[19:40] <nbd> adding @ makes it reference menuconfig options instead of packages
[19:40] <nbd> you can also use @+
[19:40] <groz_> ok, thanks, that's what i was looking for
[19:41] <nbd> i really need to document this :)
[19:41] <groz_> lol, well trial and error wasn't getting me there
[19:41] <groz_> so figured just ask, save grief
[19:41] <nbd> :)
[19:42] <groz_> can i or depends with ||
[19:43] <common> you should use paxmirabelis tar in openwrt
[19:44] <nbd> why?
[19:44] <nbd> just because mirabile rants so much about gnu tar?
[19:44] <nbd> :)
[19:44] <common> just to show 'you are the man' and then, 2nd point is, claim gnu tar is broken, and does not work
[19:44] <nbd> show me a single instance where gnu tar fails in our build system
[19:44] <common> i never saw tar failing anyway
[19:45] <common> thats not the point
[19:45] <nbd> but i saw paxmirabilis failing
[19:45] <nbd> :)
[19:45] <common> you have to _claim_ it, not _proof_ it
[19:46] <nbd> anyway. if gnu tar starts to cause problems, we could replace it
[19:46] <nbd> but so far it works, and paxmirabilis has problems with certain archives
[19:46] <nbd> so why bother?
[19:46] <common> i guess its hard to imagine, but i had a good time reading that gnu tar is broken and does not work
[19:46] <nbd> yeah
[19:47] <groz_> Well, it works for me, and guess what, as far as i'm concerned, that's 'good enuf'
[19:47] <common> groz_: i never saw tar failing
[19:48] <h3sp4wn> That --wildcards thing is annoying though (but only when building whiterussian)
[19:48] <common> but you miss an important quote
[19:48] <common> <mirabile> gnu tar is broken in so many respects that at around 2004-2005 nobody volunteered to maintain it any more
[19:48] <common> <mirabile> worse, GNU cpio creates broken(!) ustar archives
[19:48] <nbd> [mbm]: btw. should i remove the /etc/resolv.conf symlink and add a file pointing to 127.0.0.1 as nameserver?
[19:48] <nbd> [mbm]: (and point dnsmasq to /tmp/resolv.conf directly)
[19:48] <[mbm]> right, and change the dnsmasq.conf to point at .. yeah
[19:48] <nbd> ok
[19:57] <groz_> one last question nbc
[19:57] <groz_> should this work ?
[19:57] <groz_> DEPENDS:=@LINUX_2_6_X86 || @LINUX_2_4_X86
[19:57] <nbd> DEPENDS:=@LINUX_2_6_X86||LINUX_2_4_X86
[19:57] <nbd> (no spaces)
[19:58] <groz_> bingo
[19:58] <groz_> thank you
[20:12] <CIA-17> nbd * r4282 /branches/ (7 files in 6 dirs): use 127.0.0.1 as dns server and point dnsmasq to /tmp/resolv.conf
[20:43] <[mbm]> ok, what are the known broken platforms/packages? (adding the CONFIG_BROKEN now)
[20:46] <nbd> [mbm]: ar531x
[20:46] <[mbm]> yep, tagged that one already
[20:46] <[mbm]> think I'll tag the UNSUPPORTED archs too even though they're already hidden by DEVEL
[20:49] <CIA-17> mbm * r4283 /branches/buildroot-ng/openwrt/ (Config.in target/Config.in): introduce new BROKEN menuconfig option for hiding known broken settings
[21:07] <CIA-17> nbd * r4284 /branches/whiterussian/openwrt/package/webif/ (4 files in 3 dirs): add index.asp (symlinked from index.html) to make the transition from other broadcom-based firmware easier (#435)
[22:47] <crazy_imp> {Nico} ping
[00:00] --- Wed Jul 26 2006
[00:20] <groz> ok, got a quick question for ya
[00:20] <groz> when you redid the kmod stuff
[00:21] <groz> did you do a build against a 2.6 kernel
[00:21] <groz> or just against the brcm 2.4 stuff ?
[00:21] <groz> i think the problems i had the other nite, before i had to leave for the weekend are related to 2.6 vs 2.4
[00:22] <groz> and i'm just now getting started on sorting out what it is, that's a part of the build system i haven't looked at in any detail yet
[00:22] <groz> but i've got x86 building and booting now using 2.4 with the latest scripts you set in
[00:23] <groz> just going to make some hardware additions there now, so i can get the modules for usb storage working right
[00:23] <groz> and add via ethernet
[00:24] <groz> the first quick look, it looks like none of the iptables stuff is actually going in and building when using 2.6
[00:25] <nbd> i think my tests were on brcm-2.4
[00:26] <groz> ok, that's all i needed to know
[00:26] <nbd> are the packages missing on 2.6 or are the files inside the packages missing?
[00:26] <groz> i built brcm-2.4, it went ok
[00:26] <groz> the packages are not there
[00:26] <groz> and the .o files to make em aren't either
[00:26] <groz> it pukes at the point of trying to make the packages, cuz all of the iptables modules are missing
[00:27] <groz> and i haven't started to look at why
[00:27] <nbd> are the modules in the kernel config?
[00:27] <groz> getting 2.4 up and going correctly on this hardware first
[00:27] <groz> no, and the menuconfig option to add em seems to be missing too
[00:27] <groz> that's why i moved over to 2.4 for now, get it all running on this hardware first with 2.4
[00:27] <groz> then go look at the 2.6 issues
[00:27] <nbd> k
[00:27] <groz> i'm still unravelling how it all works in that area
[00:28] <groz> so i cant make any intelligent changes yet
[00:31] <{Nico}> nbd: same for me, your latest kernel modules packaging changes are really hard to digest
[00:32] <groz> lol nico, i'm just trying to do small bites, and digest a piece at a time
[00:32] <nbd> any way i can help?
[00:32] <groz> the 2.4 build seems to work, and i am unravelling from there
[00:32] <nbd> mostly it's just a wrapper around the regular package building code
[00:33] <nbd> with some stuff to remove code duplication for all the kernel stuff
[00:34] <{Nico}> nbd: did your port your changes to add -ng to the WR sdk to trunk?
[00:35] <nbd> which changes?
[00:36] <{Nico}> sorry, i missed some words: you added ability to build -ng packages in the WR sdk, right?
[00:37] <nbd> yes
[00:37] <nbd> and the ability to build old packages in the -ng sdk
[00:37] <{Nico}> is it in trunk too?
[00:37] <nbd> no
[00:38] <{Nico}> the latest wasn't supposed to be advertised :)
[00:38] <nbd> :)
[00:42] <{Nico}> any objections putting an rc5-ng backports online?
[00:42] <nbd> good idea
[00:42] <nbd> but it should be built automatically
[00:42] <nbd> maybe daily package snapshots
[00:43] <nbd> and when everything stabilizes, probably firmware snapshots as well
[00:48] <{Nico}> nbd: we need some changes in the sdk for that
[00:49] <{Nico}> log the output of package builds
[00:49] <nbd> yeah
[00:49] <{Nico}> and don't fail on build errors
[00:54] <groz> sorry, i got dragged away by the phone
[00:57] <groz> ok nbd, think i found the issue
[00:57] <groz> when i do make menuconfig under 2.4
[00:58] <groz> I get a netfilter extensions submenu
[00:58] <groz> in the 'kernel modules' section
[00:58] <groz> when 2.6
[00:58] <groz> the 'kernel modules' submenu doesn't exist
[00:58] <groz> so i cannot get there to enable the netfilter stuff
[00:58] <groz> now, i'm not 100% sure yet were that comes from
[00:59] <groz> oh wait
[00:59] <groz> it is there, just move
[00:59] <groz> moved
[00:59] <groz> but that whole section doesn't appear to be built
[01:00] <groz> i'll start digging, this could be some kind of dependancy thing
[01:44] <{Nico}> i'm building -ng packages with latest WR sdk now
[01:45] <{Nico}> avahi is failing (some ipv6 defs missing in uclibc)
[01:46] <crazy_imp> {Nico}: what do you think about my changes at the download.pl ?
[01:47] <groz> nbd, got a sec ?
[01:52] <{Nico}> crazy_imp: i'll take a look tomorrow, i'm falling asleep right now
[01:52] <{Nico}> 'night all
[01:52] <crazy_imp> ack
[09:30] <florian__> ola
[09:31] <groz> good morning
[09:33] <groz> got a quick dumb question
[09:33] <groz> do you know of a cleaner way than findstring to case out kernel version in the makefiles ?
[09:34] <groz> i've got a couple iv'e stumbled on that i need to case out for 2.6
[09:34] <florian__> depends on what you have to determine the kernel version
[09:34] <groz> in netfilter.mk
[09:34] <florian__> if you only have the makefile, I guess findstring is the best way
[09:35] <florian__> or grep with cut
[09:35] <groz> yah, 2.6 doesn't have a couple of the netfilter modules in the nat group
[09:35] <florian__> right
[09:35] <groz> i just put in a findstring, but was wondering about something cleaner
[09:35] <groz> <--- not a make/scripts guru
[09:36] <florian__> you can use /me ;)
[09:36] <florian__> like /me is not a make/scripts guru :)
[09:36] Action: groz thinks /me is boring
[09:36] <florian__> lol
[09:36] <florian__> getting back to serious things, findstring is a make internal command
[09:36] <groz> i'm just working over some of these things
[09:37] <florian__> so that you don't use external shell utils
[09:37] <groz> example, via rhine support
[09:37] <groz> and a few other _details_
[09:37] <groz> so i can get my via boards up and going
[09:37] <florian__> via rhine support for a particular device ?
[09:37] <groz> yah, via itx motherboard
[09:37] <groz> wonderful little board, you know them ?
[09:37] <florian__> sure :)
[09:37] <groz> 2 ethernet 4 serial, fanless
[09:38] <florian__> yep good workstation I think
[09:38] <groz> so re-wroking a few things to get them going
[09:38] <groz> i think they are an ok thinstation, a GREAT router
[09:38] <groz> this one has 4 serial ports
[09:38] <groz> i use them in a couple spots for handling a ton of serial stuff
[09:38] <groz> i have one mounted on a ship, it's got gps, solid state gyros on serial ports for input
[09:38] <groz> and then it drives a set of steppers on outputs
[09:39] <groz> to keep a sattelite antenna aimed
[09:39] <groz> using 3 of the 4 serial ports righ tnow
[09:39] <groz> got 2 more on my desk here
[09:39] <florian__> I don't think they are a great router
[09:40] <groz> you dont ? why not ?
[09:40] <florian__> mostly because dedicated hardware will be far more efficient
[09:40] <florian__> the only advantage I see in using this box as a router is the complete ownership of both hardware/software for routing and other various IP services
[09:40] <florian__> ah, but via itx boards have aes-padlock right ?
[09:41] <groz> depends which variant you have, some of them do
[09:41] <florian__> then they can be as efficient as dedicated hardware for SSL VPN's and IPsec
[09:41] <groz> i like these cuz it allows 'complete ownership' of the software, and i use them for 'special case' places
[09:41] <groz> nice little solid state boxes
[09:41] <groz> with plenty of horsepower to do more than 'just route'
[09:42] <florian__> right
[09:42] <Bartman007> groz: but the via rhine drivers can be a PITA.
[09:42] <groz> nahh, they 'just work' here
[09:42] <florian__> they are far better than rtl8139 anyway ;)
[09:42] <groz> they are a pain with some of the cards all right
[09:42] <groz> but when it's an all via motherboard
[09:42] <groz> they 'just work'
[09:43] <florian__> well, ethernet chips are quite well documented/not secret, and the ethernet technology is far from being complicated
[09:43] <groz> which brings up an interesting question
[09:43] <groz> how many folks are adverse to one file system, probably ext2 being 'in the kernel' rather than a module
[09:43] <groz> so we can set these up to make netboot images too
[09:44] <groz> i'm netbooting here
[09:44] <florian__> I really don't like initrd at all
[09:44] <florian__> at least on my all day boxes
[09:44] <groz> but that requires one file system 'in the kernel' to deal with the net boot image
[09:44] <Bartman007> florian__: that makes 2 of us
[09:44] <groz> well, initrd/ramdisk, no difference on a device with no hardware for storage on it
[09:45] <groz> i build them up as a motherboard, with a stick of ram, and that's it
[09:45] <groz> netboot them
[09:45] <groz> and they sit there 'just working'
[09:47] <florian__> yeah, it's another approach
[10:01] <[mbm]> .
[10:22] <CIA-17> florian * r4274 /branches/whiterussian/openwrt/package/busybox/patches/ (350-ping-opt-srcaddr.patch 351-telnet-opt-srcaddr.patch): Add ping -l (preload) and telnet -b (bind alias), closes #528
[10:40] <florian__> anyone working on the busybox upgrade to 1.2.0 ?
[10:43] <[mbm]> no, but that sounds like a good idea
[10:44] <florian__> I am trying to fix as much rc6 tickets as I can
[10:46] <[mbm]> :)
[10:46] Action: [mbm] needs to find time to fix a few things for rc6
[10:48] <florian__> damn, Brainslayer is laughting at me, he told me he had a working mtd map for bcm963xx, and I can't find it anywhere
[10:48] <florian__> once again, we commit the patches, he takes them
[10:48] <florian__> grr
[10:49] <[mbm]> lame
[10:50] <florian__> the mp3 decoder ;) ?
[10:52] <[mbm]> yes.
[11:00] <florian__> by the way, do you know how I can replace cli() by spinlocks ?
[11:01] <florian__> oh, I think I found them
[11:01] <nbd> spin_lock_irqsave maybe?
[11:02] <florian__> looks like it is not that simple
[11:02] <florian__> you have to define a spinlock
[11:02] <[mbm]> what driver still uses cli?
[11:03] <florian__> the serial console driver for brcm63xx
[11:04] <[mbm]> doesn't seem like the type of thing that really needs it
[11:04] <florian__> well currently it's cli(), which is deprecated, and I want to replace it to have clean patches
[11:06] <nbd> spin_lock_irqsave disables irqs locally and saves the flags
[11:06] <nbd> it should be enough to replace a cli call
[11:06] <florian__> ok
[11:06] <[mbm]> right, that's the correct replacement
[11:07] <[mbm]> there's a document somewhere that explains the whole transition
[11:08] <florian__> If you have any link
[11:09] <florian__> ok I think it's in the kernel Documentation
[11:12] <[mbm]> it was a pdf released by one of the kernel devs .. I'll have to dig it up later
[11:13] <florian__> I found it
[11:13] <florian__> it's in Documentation/Docbooks ..
[11:13] <florian__> don't exactly remember the name, but it's here
[11:13] <{Nico}> florian__: i have pending patches for busybox-1.2.0 + ipkg
[11:13] <florian__> {Nico}: ok
[11:13] <nbd> we should turn ipkg into a plugin
[11:14] <florian__> nbd: do you think it's worth fixing webif tickets for rc6 or not ?
[11:14] <[mbm]> heh, finally make use of that plugin hack I wrote?
[11:14] <nbd> [mbm]: exactly
[11:14] <nbd> florian__: what kind of tickets?
[11:14] <[mbm]> florian__: I intend to do some cleanup of webif
[11:15] <florian__> nbd: #25, #298, #609, #435 ...
[11:15] <groz> i've got a bunch of little changes that'll go into the x-86 stuff either later tonite or tomorrow
[11:16] <groz> just gotta do pcmcia yet for the routerboard
[11:16] <{Nico}> nbd: what name should i put in PKG_BUILDDEP? package name or source name?
[11:17] <nbd> source name, iirc
[11:18] <groz> nbd, i found the issue i was having finally with that kmod change
[11:18] <groz> there's a couple that dont exist in the 2.6 kernel, i'll have commits going in shortly
[11:19] <groz> it was a trivial fix, once i unwould myself inot it far enough to figure out how that all works
[11:20] <florian__> {Nico}: if you have time to test the au1000 port, tell me if you can get the atheros cards working
[11:20] <{Nico}> nbd: it does not seem to work when buidling -ng packages with WR sdk
[11:22] Action: [mbm] pokes florian__ msg
[11:22] <florian__> [mbm]: do you read me ?
[11:34] <{Nico}> florian__: i'll try tonight
[12:15] <db90h> patch this one liner please, it's been annoying me forever that this uselses decoder is in 2.4 jffs2 -> http://www.bitsum.com/files/jffs2_dynrubin_decoder_removed.patch.tar.gz .. you might want to remove the compr_rubin object from the makefile too, tho as long as it's not used it shouldn't be linked in to the kernel (i think)
[12:16] <db90h> i got sidetracked on my jffs2 lzma decoder (only) + mkfs.jffs2 lzma encoder addition, but i'll have a patch for it for WR RC5 maybe before RC6
[12:20] <db90h> it's really been done forever, but I got demotivated while I was porting the changes back to White Russian RC5, so a couple little things left to do
[12:21] <db90h> also, I have begun to question the usefulness of JFFS2 only filesystems.. they are neat, but it seems Squashfs-lzma + mini_fo + JFFS2 is the most size optimal distribution feasible with White Russian right now
[12:25] <[mbm]> the jffs2 only was designed with the idea that ipkg might actually work, and that you'd be able to upgrade an entire distribution with ipkg
[12:25] <[mbm]> doesn't actually happen that way and most of the people that are running jffs2 are those that didn't pay attention to the docs which suggested squashfs
[12:26] <[mbm]> plus its already possible to switch from squashfs to jffs2 without reflashing
[12:26] <[mbm]> so the whole jffs2 only images are somewhat useless
[12:28] <db90h> mark this date, because i think i agree with you
[12:28] <db90h> ;p
[12:29] <malbon> db90h: hols
[12:29] <malbon> or hola even
[12:29] <db90h> i didn't know about the plans to use ipkg to upgrade the entire distribution, that would be cool if it did work and would necessitate JFFS2
[12:29] <malbon> your tool working in linux now?
[12:30] <db90h> which tool?
[12:30] <db90h> oh, the vx firwmare tool
[12:30] <db90h> yea
[12:30] <malbon> the bsp updater
[12:30] <db90h> oh yea, that is too
[12:30] <[mbm]> db90h: :P .. you act as though we're oblivious to the issues
[12:32] Action: [mbm] knows whiterussian sucks, is obsolete and many things should have been done differently
[12:32] <db90h> malbon: i've got a vxworks reversion firwmare /w mac and serial embedding capabilities pretty much done, but I added bsptool as an OpenWrt pacakge and gotta track down one little bug in its build, then its done
[12:33] <[mbm]> I'm actually looking forward to the 1.0 transition were we basically abandon all the old legacy code and introduce the "new" stuff we've been woring on
[12:33] <malbon> db90h: okiedoke. I've a few atheros thingies here ready to test.
[12:34] <db90h> [mbm]: how is the 2.6 kernel builds doing now?
[12:35] <db90h> is 1.0 planned to be a 2.6 release?
[12:35] <[mbm]> "now"? I've been running 2.6 kernels for at least the last 6 months
[12:36] <[mbm]> for some platforms
[12:36] <db90h> freewrt claimed there were issues with the Broadcom wl driver (nbd says unfinished scripts to configure it properly), so I assumed that it wasn't really ready..
[12:37] <[mbm]> wl doesn't run on 2.6
[12:37] <db90h> whatever the wireless driver is i mean
[12:37] <[mbm]> so basically the brcm-2.4 (basically the whiterussian tree) is the only thing still using a 2.4 kernel
[12:38] <[mbm]> there's teh opensource bcm43xx to replace the wireless driver, which is now getting integrated with the kernel
[12:38] <db90h> cool
[12:39] <[mbm]> I have no idea how stable it is, I basically stopped using broadcom wireless chips
[12:39] <db90h> dd-wrt is using the proprietary one and seems to have had some success getting it to work right, but there's still issues
[12:39] <[mbm]> you're confusing multiple issues
[12:39] <db90h> oh, i am?
[12:39] <[mbm]> there is no proprietary wireless driver for 2.6
[12:40] <[mbm]> if there was we'd be using it and 2.6
[12:40] <murb> [mbm]: I've had some success with it on an ibook.
[12:40] <murb> (the reverse engineered wl driver)
[12:41] <[mbm]> the proprietary driver (wl) works fine on 2.4, and since it's basically provided by broadcom it actually works
[12:42] <db90h> oh, yes, i see now.. i was confused and thought the new proprietary driver dd-wrt v24 is using was for the 2.6 kernel
[12:42] <[mbm]> the same can't be said about the bcm43xx driver because it's really based on speculation and reverse engineering -- I'm sure if they actually had documentation it'd be done by now
[12:42] <[mbm]> nobody has released a 2.6 based firmware for the broadcom yet
[12:42] <db90h> i had just assumed dd-wrt v24 was v2.6, i'm glad we had this conversation, that clears up a lot ;p
[12:43] <murb> well there is still the argument about which 802.11 stack to use in the kernel.
[12:43] <[mbm]> (although you can easily build one with buildroot-ng)
[12:43] <[mbm]> murb: yeah, although at this point I honestly don't give a damn as long as they pick one
[12:43] <[mbm]> I'm sick of each driver having it's own 802.11 stack
[12:44] <[mbm]> looks like they've settled on the decicescape stack
[12:45] <db90h> ok, so the 2.6 open source bcm43xx driver isn't fully mature and wlconf doesn't work with it? is that right?
[12:46] <malbon> with the new driver isn't wlconf obsolete?
[12:46] <[mbm]> wlconf was basically written for the brcm-2.4 platform
[12:46] <[mbm]> it depens on the broadcom ioctl interface and nvram
[12:46] <[mbm]> both of which will be obsoleted
[12:46] <db90h> ok, so wlconf has to be replaced
[12:47] <[mbm]> (likewise wlcompat will also be useless)
[12:50] <db90h> it's been a long hard road out of the fog of assumptions and ignorance
[12:51] <[mbm]> I'm sure there's still some left
[12:51] <[mbm]> also doesn't help that when you finally agree with me you follow up with what's basically an insult of "mark this occasion"
[12:53] <db90h> there's more ignorance than anything left ;).. and I didn't mean that as an insult at all, just was a joke
[13:05] <db90h> anyway, i'm socially inept and quite insane (seriously), so i advise not taking me too seriously
[13:05] <db90h> here's my next question.. how much do you think removing unused symbols will really save on post-compressed size?
[13:05] <[mbm]> symbols from what?
[13:06] <db90h> all libs
[13:06] <[mbm]> sounds like you'd break the lib and probably wouldn't save much space for it
[13:06] <db90h> i assumed anyway..better check that too since my other assumptions have been bad
[13:07] <db90h> what symbols does dd-wrt remove? from the kernel?
[13:07] <db90h> surely not..
[13:07] <db90h> tho maybe so
[13:07] <db90h> let me look here
[13:07] <[mbm]> this isn't dd-wrt, so I have no idea
[13:07] <db90h> nbd said this is something he was going to do someday for micro distributions
[13:08] <db90h> but u have to build all packages to make sure you have a comprehensive list of used symbols (and even then new packages could use one that you removed)
[13:08] <[mbm]> honestly though you should read the elf specification (there's a pdf in my dir) .. after you strip the debugging contexts and useless sections like .note and .comment there really isn't much to be saved by further stripping
[13:09] <[mbm]> and by strip I mean the 'strip' or 'sstrip' programs
[13:09] <db90h> yea, i'm not famaliar with the ELF specs, that's been on my todo list
[13:09] <[mbm]> if you actually want to remove functions, you can save some space
[13:09] <[mbm]> but that's not what those programs do
[13:10] <db90h> yea, the reason i asked was i figured it surely couldn't help much in post-compressed image size..
[13:10] <[mbm]> you also run compatibility issues when you start removing stuff
[13:10] <[mbm]> we tried to remove libgcc and got nothing but headaches
[13:11] <db90h> definitely.. but for micro builds you often have a static set of packages, so maintaining compatibility with third-party packages isn't as big a deal
[13:11] <db90h> (a static set of packages is obviously not in line with openwrt's philosophy)
[13:12] <[mbm]> for micro images things should basically be linked into multicall binaries and compiled as statically as possible
[13:12] <[mbm]> but openwrt isn't aimed at the micro platforms
[13:12] <[mbm]> the time involved vs the benefits of it really don't make it time well spent
[13:14] <db90h> yea, that's true
[13:15] <florian__> maybe we could make some efforts for wap54g for instance ?
[13:15] <[mbm]> I'd rather unify the platforms as much as possible instead of adding more special cases for plaforms with limited resources
[13:16] <florian__> yes I understand, how could we have a general mean to reduce the image size ?
[13:16] <[mbm]> basically the stuff you'd have to do to make a good micro image conflicts with the stuff we do for the other platforms
[13:17] <db90h> yea, there is a seemingly unresolvable conflict here between size optimization and the design ideals of openwrt
[13:17] <db90h> that said, trying to reduce the size of openwrt in any way that doesnt' compromise the design ideals is definitely a good thing.. tho not sure how much more of a difference can be made in this area
[13:18] <[mbm]> florian__: we've basically reduced things down as far as they'll go without breaking compatiblity or expansion
[13:18] <florian__> sure, does jffs2-lzma makes sense ?
[13:19] <[mbm]> yes, and I'm sure once the patch is working we'll do it
[13:19] <db90h> florian__: you saw my project where i added an lzma decoder to jffs2, and an lzma encoder to mfks.jffs2 so that pre-included files are compressed with lzma?
[13:19] <malbon> yeah I think so. it'd be slow to compress, but it'd be small.
[13:19] <florian__> db90h: sorry I did not see that
[13:19] <db90h> it improves compression 10-20%.. i need to finish this up today before it dies forever.. i started to try to backport the 2.6 JFFS2 code to 2.4, but it was a pain
[13:20] <[mbm]> :)
[13:20] <db90h> malbon: yea, as far as addign the lzma encoder to the jffs2 filesystem, there is an issue with it being C++ .. but when a C encoder is created, or when the C++ issues are worked with, an LZMA encoder is definitely no slower than runing JFFS2-BBC in size mode (which iterates through some 5 compressors for each block of data compressed)
[13:21] <db90h> keep in mind the JFFS2 compressed data in 4kb blocks, so there isn't much overhead to encoding
[13:21] <malbon> db90h: nope, you can use the standalone compressor
[13:21] <db90h> because the maximum dictionary size (for LZ based encoders) is 4KB, making the memory overhead of the phrase tries and CPU overhead of phrase searching not bad at all
[13:22] <malbon> db90h: got the sdk?
[13:22] <db90h> yea, of course.. the LZMA_Alone u mean?
[13:22] <db90h> that's just the decoder..
[13:22] <db90h> the Encoder is C++..highly OO, hard to port directly to C.. tho Igor Pavlov is working on a C build mirable tells me..
[13:23] <db90h> if I am wrong on this, please let me know, cuz I'd love to go ahead and add the lzma encoder
[13:24] <[mbm]> there's a C directory in the lzma code but if I remember right that's only the decoder (and it was an absolute mess of #if statements)
[13:25] <malbon> yes, your right, all the encoders do seem to be c++
[13:25] <db90h> the C folder contains sub-folders that have the C++ encoder and C decoder
[13:25] <db90h> adding the encoder to mkfs.jffs2 took just a minute tho, the code is easy to use.. just nbd tells me that C++ in the kernel is not trivial, so I've trusted him on this and not tried
[13:26] <db90h> one thing that got me distracted on this was trying to port the 2.6 JFFS2 code to 2.4.. why? cuz this code is a lot better. It takes many of the BBC enhancements and merges them with the base code, resulting in a cleaner source
[13:26] <[mbm]> C++ in the kernel is very annoying to do and will basically get you kicked out of places like the linux kernel mailing list
[13:27] <[mbm]> c++ just isn't a good language for system level stuff
[13:28] <florian__> why does nobody made a C portage of lzma ?
[13:28] <[mbm]> (I'm not particularly fond of c++ userspace applications wither)
[13:28] <db90h> [mbm]: what do you think of the feasibility of porting jffs2 in 2.6 to 2.4?
[13:29] <CIA-17> florian * r4275 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/patches/ (001-brcm_boards.patch 020-bcmdrivers.patch): Clean up patches : remove warnings, move cli() and save_flags to spinlock mechanisms
[13:29] <[mbm]> florian__: lzma isn't yet a popular compression scheme so theres basically only one copy of the source
[13:29] <db90h> and lzma is so highly OO that it won't be easy for even the author to port to C, tho he's supposedly working on this
[13:30] <[mbm]> plus the fact that the proceedure isn't commented for anyone else to write it
[13:30] <[mbm]> you basically have to read and understand the c++ version (which is a mess) before you can write a c version
[13:30] <db90h> yep, tho he's improved the code some over the last year, it's no pleasant thing to work with .. i think he must strip comments before he releases ;p
[13:31] <florian__> hu
[13:31] <db90h> the 7zip code is even messier
[13:31] <db90h> it would be easier to re-write the LZMA algorithm
[13:31] <[mbm]> every time I see the lzma code I'm tempted to run it through a parser to get rid of the tons and tons of #ifs and then run it through lindent
[13:32] <db90h> hehehe, yea i hear ya
[13:33] <[mbm]> as for the jffs2 backport, it'd be nice but it sounds painful .. are you sure it'd be worth it?
[13:33] <db90h> no, not sure at all
[13:35] <[mbm]> there's some people that like new code just because it has a higher version number .. I usually insist on some measureable improvement first
[13:36] <db90h> the code is cleaner thanks to the 'proper' integration of most of the BBC ideas, and I wanted to have a 2.4 and 2.6 lzma decoder patch that was very close to the same for easier maintenance.. but as far as advantages to OpenWrt, i don't know
[13:37] <db90h> it might improve compression speed in size mode cuz it doesn't have all the encoders of BBC (many of which are seldom used anyway i think), but i doubt it'll improve comprsession ratio
[13:37] <[mbm]> if it makes it easier for the lzma patch then I'd probably backport jffs2
[13:38] <[mbm]> dwm2 has been in #openwrt a few times, you might see what he has to say about it
[13:38] <db90h> well the lzma patch itself is super-simple, it's easy to extend jffs2 with new compression algorithsm.. so it's no huge deal to maintain two copies i guess
[13:40] <db90h> ok, i'll ask him if i see him
[13:40] <CIA-17> florian * r4276 /branches/whiterussian/openwrt/package/lighttpd/ (Makefile patches/500-configure_cross.patch): Upgrade lighttpd to 1.4.11, fixes the mod_proxy issue, closes #652
[13:43] <db90h> what if I brought the lzma in white russian rc5 up-to-date? is there any reason u guys haven't done this already?
[13:44] <[mbm]> you mean the squashfs-lzma or the lzma compression we use on the kernel?
[13:44] <db90h> the squashfs-lzma
[13:44] <db90h> the lzma folder it uses i'm also using the mkfs.jffs2 extension, as a 'shared' lzma folder
[13:45] <[mbm]> probably could use an update .. hasn't been a high priority though
[13:45] <florian__> yeah you mean lzma-432 right ?
[13:45] <db90h> yea
[13:45] <db90h> tho there's newer one now
[13:45] <[mbm]> btw since squashfs and jffs2 are both going to be using lzma you should make it a common library in the kernel
[13:45] <florian__> right 437 or newer ?
[13:46] <db90h> [mbm]: yep, i ran into that.. currently i have a seperate lzma decoder for the jffs2 fs cuz the squashfs lzma decoder is compiled with different flags, but i planned to use only one.. this is on the todo list
[13:47] <db90h> 4.43 is newest
[13:48] <florian__> right
[13:48] <db90h> [mbm]: as far as turning it into a proper library in the kernel, this would take me a bit of time to integrate right.. squashfs-lzma patch just shoves the lzma decoder in there i think, so i'd have to modify it, create a proper library, then change makefile and config, and more stuff i guess.. not as easy as just using the pre-existing lzma decoder squashfs shoved in there
[13:49] <db90h> but in cases where squashfs-lzma isn't linked in, i need to put in my own lzma decoder.. so gotta figure out how to detect and handle that in the make
[13:49] <[mbm]> yeah, takes slightly mor work
[13:49] <[mbm]> I'd suggest looking at how crc32 is handled
[13:50] <db90h> ok, thanks, i'll take a look at it
[13:50] <db90h> making it a library is the right thing to do and solves the case where squashfs-lzma is missing
[13:51] <[mbm]> right, then both squashfs and jffs2 depend on the libary
[13:51] <db90h> this will add some time for sure, but i'll do that .. good idea, thanks
[13:51] <[mbm]> you can even get fancy and have the encoder as a separate config symbol so that the encoder only gets enabled when using jffs
[13:52] <db90h> u mean for when and if we ever add the lzma encoder to the kernel?
[13:53] <[mbm]> ;)
[13:53] <[mbm]> well, the lzma encoder in the kernel will basically be a requirement for jffs2-lzma
[13:54] <[mbm]> I take it that for now you only made the patches to mkjffs2 and only put the decoder in the kernel?
[13:55] <db90h> yea, i'm leaving that to be done somewhere done the line tho.. i'm just adding it to mkfs.jffs2 and at least improving the compression of all those pre-included files
[13:55] <db90h> right
[13:55] <[mbm]> heh, cheater but I suppose I'd do the exact same thing
[13:56] <db90h> hehe
[13:56] <[mbm]> does mean that if you even sneeze on a file it's size jumps by 10% even if the file didn't technically change
[13:56] <db90h> the difference in difficulty (considering the lzma encoder is still only c++) is like 1/100
[13:56] <db90h> yep, that's right
[13:56] Action: [mbm] has a similar problem with mini_fo
[13:57] <db90h> but i figure the majority of the pre-included filesystem never changes.. the issue that makes this kinda useless is the fact really mksquashfs-lzma should be what everyone uses for static files
[13:57] <[mbm]> soon as you poke at a file it creates a copy of the file on the overlay (jffs2)
[13:57] <db90h> if u just open it for writing and the close it withotu changes even?
[13:58] <[mbm]> haven't tested all of the cases but it is entirely possible to have two identical copies of the file
[13:58] <[mbm]> was going to fix that before rc6
[14:00] <db90h> yes, that definitely needs to be addressed.. i assume it's not too difficult.. but if it was, a user space tool could scan the filesystem and delete files whose backing file is the same as the new one
[14:00] <[mbm]> it's trivial, I already wrote the userspace util for it
[14:00] <[mbm]> just haven't gotten to the kernel part
[14:00] <db90h> cool
[14:01] <db90h> it'd be really awesome if u could use the backing file as an initial dictionary for the new file (or some other delta type compression).. this would reduce compressed size to almost nothing for small changes
[14:02] <[mbm]> that'd be fun for upgrades
[14:02] <db90h> but this seems like it would require huge changes and transcend several different drivers
[14:03] <db90h> yea, it'd be perfect for upgrades
[14:03] <[mbm]> wait, you're not suppose to agree with me :P
[14:03] <db90h> hehehe
[14:10] <florian__> anyway you'd better agree with [mbm] ;)
[14:11] <db90h> is anyone working on a web-based image builder so people can more easily do the right thing and pre-include their desired packges in squashfs-lzma?
[14:12] <Kaloz> o.O
[14:23] <db90h> what, is that ur job? ;p
[14:24] <Kaloz> no way :P
[14:24] <[mbm]> we've talked about it and it's been something on the todo list but it hasn't been done yet
[14:25] <[mbm]> figured it'd be something fun to do for the 1.0 stuff
[14:25] <Kaloz> dunno, imho it will be pretty much (ab)used :P
[14:26] <Kaloz> eg. with adding simply normal packages, i see it pretty useless
[14:26] <Kaloz> and if we let people upload anything and premodified config files
[14:26] <Kaloz> it will be insane
[14:27] <[mbm]> we'd only give them the ability to compile with packages already on the server
[14:27] <db90h> yea, most openwrt users can use linux and build their own images, but i have a tendency to focus on less linux-happy users..
[14:27] <florian__> I think we should also try to make openwrt cygwin buildable
[14:27] <[mbm]> db90h: they're the cause of many headaches -- for your own helth I suggest you either ignore them or switch them to linux users
[14:27] <florian__> I will take a look at this
[14:27] <db90h> lol
[14:28] <florian__> why lol ? ;) ?
[14:28] <db90h> mbm's comment
[14:28] <db90h> not you ;p.. i shoulda specified
[14:29] <db90h> i'd like to see openwrt cygwin buildable, tho i find it easier to just use linux in a VM than muck with cygwin
[14:29] <[mbm]> I'd worry about osx before I worried about cygwin
[14:29] <db90h> might be cool to release a pre-built virtual machine for vmplayer (free)
[14:29] <db90h> ...that is able to build openwrt
[14:30] <[mbm]> haven't checked laytely but last time I tried to compile on osx it was an absolute mess
[14:30] <Kaloz> db90h: was thinking about that
[14:30] <florian__> [mbm]: I worried about OSX, there was so many patches to commit, that I let them in a ftp
[14:30] <Kaloz> db90h: i find it more logical then a cygwin build
[14:30] <[mbm]> db90h: colinux is more efficient
[14:30] <crazy_imp> or a small livecd with the svn tree from the day?
[14:30] <Kaloz> nah, livecd isn't that good
[14:30] <db90h> i prefer virtual machines to live CDs
[14:30] <Kaloz> with vmplayer image
[14:30] <Kaloz> they can do whatever they want in the meantime
[14:30] <crazy_imp> (but there would be the problem for windows pc's where they could unpack all the packages)
[14:31] <crazy_imp> ack
[14:31] <Kaloz> the image can be big enough uncompressed
[14:31] <Kaloz> and honestly, if a windows user needs 1 or 2gb to compile anything
[14:31] <Kaloz> they will be happy anough
[14:31] <Kaloz> imho
[14:31] <db90h> [mbm]: cool, i never herad of colinux before
[14:33] <db90h> anymore tho virtual machines run pretty well even on processors without virtualization support
[14:33] <db90h> these more optimal solutions that avoid virtual machines will eventually have little use as hardware gets more and more virtualization friendly
[14:33] <florian__> well, I think I will reinstall macosx on my ibook and try to build openwrt on it anyway ;)
[14:34] <db90h> florian__: that's the spirit ;)
[14:34] <[mbm]> db90h: colinux is uml ported to windows .. runs faster than emulating an entire machine
[14:34] <db90h> [mbm]: yea, definitely it's much faster to avoid a VM.. but my comment was VM's are 'fast enough' for most people on most hardware, and are getting faster
[14:35] <[mbm]> btw, colinux tends to be a bitch when you're writing the initial xml config
[14:35] <murb> or when you typo the name of te network adaptor you wish to use..
[14:36] <db90h> I use a Ubuntu in a VM to much around with this embedded linux stuff, and it runs just peachy
[14:36] <db90h> err to muck around, not much around
[14:36] <murb> and discover microsoft turn have spanning treee turned on by default in their bridge device.
[14:36] Action: [mbm] never could understand people that ran windows as their os but then ran linux in vm .. worst of both worlds?
[14:36] <murb> [mbm]: a nice toy, but i like qemu more.
[14:37] <murb> [mbm]: i used to use it for remote support of a windows user, somewhere to tunnel vnc/ica to/from.
[14:37] <[mbm]> if anything I'd run windows in the vm
[14:38] <[mbm]> I'd hate to reboot my linux just because of some annoying windows program forcing the os to reboot
[14:38] <murb> [mbm]: win2k in qemu solves most sof my must use windows problems.
[14:38] <[mbm]> 'a new software update! you must reboot now!' .. go away .. 'automatically restarting in 10 minutes ...'
[14:39] <db90h> lol, i see u do use windows ;p
[14:39] <[mbm]> windows has some pretty damned annoying settings
[14:39] <db90h> I thought about swapping to Linux as my primary OS, but 1.) I'm a Windows developer by profession and 2.) I don't want to go through painful driver problems
[14:40] <[mbm]> 2 isn't so bad .. the real pain comes from WGA crap
[14:40] <[mbm]> soon as you switch XP over to a VM it yells at you to reactivate
[14:40] <murb> [mbm]: unless you cheat and activate it in a VM
[14:41] <murb> but you can't do taht with oem versions.
[14:41] <db90h> yea, I bet it does
[14:41] <db90h> u get like 5 different re-activations due to substantial hardware changes before u have to call
[14:41] <[mbm]> murb: yeah, you do that and then it doesn't want to boot native until you activate again
[14:41] <murb> [mbm]: any idea what it probes, you could always fix up the vm to lie to windows couldn't you?
[14:41] <[mbm]> probes tons of things
[14:41] <db90h> yea, it builds a key from a shitload of things
[14:41] <db90h> its been reversed
[14:42] <db90h> its designed to allow one or two updates and still be ok
[14:42] <[mbm]> cpu id, harddisk label, mac address, amount of memory, bios version ..
[14:42] <[mbm]> it's easier just to "find" a corporate edition that doesn't have the activation crap
[14:42] <db90h> hehe, yea
[14:42] <db90h> activation is a pain in the ass
[14:43] <db90h> as if MIcrosoft wasn't rich enough already
[14:43] <db90h> they should be happy people are using Windows, even if they are pirating it
[14:43] <[mbm]> went to the ms site for the first time in 5 years looking to download ie7 since someone told me it wasn't rendering right
[14:43] <[mbm]> my god they're annoying with wga crap
[14:43] <db90h> hehe, it's bullshit
[14:44] <[mbm]> it really is
[14:44] <db90h> WPA is bad enough, but WGA is over the line
[14:44] <[mbm]> click here to download the util .. run it.. copy the text that appears into the box
[14:44] <db90h> simple solution for me is i won't install their shit
[14:44] <[mbm]> so what makes them think I actually ran it?
[14:44] <db90h> but in times when u need it, like u did, sux
[14:44] <[mbm]> and then when I actually went to install ie7 it insisted on performing it's own wga checks
[14:45] <[mbm]> and ie7 looks like crap under the classic theme
[14:45] <{Nico}> florian__: i was working on #652
[14:45] <db90h> WGA is very arrogant for sure
[14:45] <[mbm]> (I absolutely hate the xp theme)
[14:45] <db90h> I use Windowblinds, which runs without a seperate process since it integrates well with XP.. it's surprisingly optimal
[14:46] <db90h> if it had much overhead, i'd never use it..but it doesn't
[14:46] <Kaloz> db90h: you can simply patch the themexp.dll or what, and then you can use the skins without 3rd party crap :)
[14:46] <florian__> {Nico}: ah sorry, I tought it was pending for so much time that you forgot it
[14:46] <[mbm]> if I ever find the person that said "let's make everythign a gradient with rounded edges and use bright primary colors" I'll probably strangle them
[14:46] <{Nico}> florian__: i just accepted it yesterday
[14:46] <db90h> Kaloz: true that, but WindowBlinds has a few other capabilities and isn't a bad deal
[14:48] <florian__> {Nico}: ah sorry then
[15:25] <nbd> .
[15:39] <florian__> ..
[15:50] <crazy_imp> {Nico}: heyho
[16:05] <CIA-17> florian * r4277 /packages/net/aodv-uu/ (. Makefile patches/ patches/001-normalize.patch): Add aodv-uu userspace daemon, kernel module needs makefile rewriting
[16:44] <CIA-17> nbd * r4278 /branches/buildroot-ng/openwrt/package/kernel/Makefile: don't try to create kmod packages that contain no files
[16:53] <[mbm]> nbd: wouldn't that also suggest that the modules-*.mk has the wrong deps?
[16:53] <nbd> modules-*.mk is obsolete
[16:53] <[mbm]> ah
[16:54] <[mbm]> it was there a week ago when I looked :P
[16:54] <nbd> it's still there
[16:54] <nbd> but when the transition is done, we can remove those files
[16:54] <[mbm]> ah
[16:58] Last message repeated 1 time(s).
[16:58] <[mbm]> nbd: so does that fix #653?
[17:00] <nbd> oh, yeah. it does
[17:00] <nbd> i'll close it
[17:57] <groz> nbd you around this morning ?
[17:57] <CIA-17> nbd * r4279 /branches/buildroot-ng/openwrt/target/linux/ar7-2.4/patches/003-net_driver_cpmac.patch: change cpmac to use the internal phy by default (#596)
[17:58] <nbd> groz: i'm around, yes :)
[17:58] <groz> good morning
[17:58] <groz> just want to touch base on that kmod stuff just a bit
[17:59] <groz> are you planning more major changes in the real short term for it ?
[17:59] <groz> the reason the 2.6 stuff was failing boiled down to simply some missing modules
[18:00] <groz> the question i have for you, are you real familiar with the iptables changes in 2.6
[18:01] <groz> the DNAT and SNAT modules are not there when you build it, and, there's apparently no option to enable them
[18:01] <groz> just wondering if you know offhand what they got changed to ?
[18:01] <groz> as well, i've been adding some other network devices and a few little things to the kmod package builds
[18:01] <groz> just wondering if your next batch of changes will change that all again ?
[18:02] <nbd> the kernel module stuff won't change much
[18:02] <groz> ok
[18:02] <nbd> except that the stuff from include/modules-*.mk will be ported over to the new system
[18:03] <groz> ok, hmmm, that's where i've been putting a bunch of it
[18:03] <nbd> include/modules-*.mk is obsolete
[18:03] <groz> but, it needs to be there right now no, or is there an alternate place to put that now ?
[18:03] <groz> that I missed
[18:04] <groz> I just 'follwed the breadcrumbs' on one existing module to find the spots it is referenced
[18:04] <nbd> groz: the alternate place is package/kernel/modules.mk
[18:04] <groz> ok, i'll move it there
[18:04] <nbd> groz: which has the advantage of autogenerating all menuconfig and ipkg control data
[18:05] <nbd> groz: so if you port something over there, remove the old control files and also remove the entries from target/linux/Config.in
[18:05] <groz> ok, I'll start moving it over to there shortly
[18:06] <groz> i'm ending up with a 'crash course' on 2.6 differences here, i've never really used 2.6 prior to this
[18:07] <groz> so it's been shall we say 'interesting'
[18:08] <nbd> yeah. i also have no clue about the netfilter changes in there
[18:08] <nbd> with the xt_ and ipt_ stuff
[18:08] <groz> i've got it all running ok, except for one set of details
[18:08] <groz> dnat and snat modules dont exist
[18:08] <groz> which ofc means the default firewall stuff all breaks too
[18:09] <nbd> weird. there's no nat support in current 2.6 kernels?
[18:09] <groz> oh, it must nat ok, i just dont see how to get it to build a dnat and snat module
[18:09] <groz> so it must be hidden in some of those others
[18:09] <groz> or i've done something really wrong and broke it badly here
[18:10] <crazy_imp> {Nico} or someone else, whats about my changes at the download.pl? (http://openwrt.vcp-springe.de/experimental/download.diff)
[18:13] <groz> another question i was wondering about ndb
[18:13] <groz> the way the x86 stuff builds right now, it's being patched with the patches from generic-2.6
[18:13] <groz> the big mips patch is in there
[18:14] <groz> wondering if the mips patch should be ommitted on the x-86 build
[18:15] <groz> if so, should we be moving it into a mips top level patch dir that'll only be applied to mips kernels
[18:16] <nbd> i don't think the mips patch hurts x86
[18:17] <groz> i dont think it hurts, for now
[18:17] <groz> but in the grand scheme of things, moving to support yet more arches
[18:17] <groz> wondering if we should have a /generic then possibly /mips /i386 /arm type setup
[18:17] <groz> then board specific like now
[18:18] <nbd> i think we should not do it until it becomes necessary
[18:34] <groz> ok nbd, i'm starting on pulling stuff over to the new setup
[18:34] <groz> starting with network devices, will just set up a new category for them
[18:34] <groz> same as you did with netfilter
[18:36] <CIA-17> nbd * r4280 /branches/whiterussian/openwrt/target/linux/linux-2.4/patches/brcm/001-bcm47xx.patch: fix switch-adm breakage accidentally introduced in [4155] (ticket #651)
[19:05] <nbd> [mbm]: can we remove support for the symlink hack entirely?
[19:05] <nbd> [mbm]: (squahsfs/jffs2 overlay)
[19:05] <nbd> [mbm]: maybe we should even move mini_fo to the kernel
[19:05] <[mbm]> might be slightly premature for that
[19:05] <nbd> ok
[19:06] <[mbm]> I'd like to get a release with mini_fo out and tested before we completely pull the old code
[19:06] <nbd> ok
[19:06] <[mbm]> (besides, it hardly takes any space)
[19:07] <nbd> another thing: do you think we should have a new 'patch format' in the build system that keeps all new files in a directory structure instead of a single patch file?
[19:07] <nbd> would make maintaining some things easier
[19:08] <[mbm]> hmm might make things slightly easier
[19:17] <nbd> btw. how are we going to fix dial-on-demand? default to a non-routable ip as dns in dnsmasq?
[19:17] <nbd> we talked about this a while ago, i just don't remember what we agreed on
[19:20] <[mbm]> no idea .. I'm not a ppp user so I haven't had to deal with the problem
[19:20] <nbd> we could make dnsmasq default to a certain invalid ip
[19:20] <nbd> when it sends out a dns request, this will make ppp establish the connection
[19:24] <CIA-17> nbd * r4281 /branches/whiterussian/openwrt/package/dnsmasq/Makefile: update dnsmasq to 2.32
[19:27] <groz> dumb question ndb
[19:28] <groz> in the new form of modules.mk, i dont see a way to set dependancies on kernel variants
[19:28] <nbd> KCONFIG:=$(CONFIG_...)>
[19:28] <groz> ie make the various network devices dependant on the x86 variants of kernels
[19:28] <nbd> KCONFIG is for dependencies on kernel config variables
[19:29] <nbd> and DEPENDS:= is for package and menuconfig dependencies
[19:29] <nbd> it works exactly like DEPENDS for other packages
[19:29] <groz_> grrr, got disconnected
[19:30] <nbd> 19:23 < nbd> KCONFIG is for dependencies on kernel config variables
[19:30] <nbd> 19:24 < nbd> and DEPENDS:= is for package and menuconfig dependencies
[19:30] <nbd> 19:24 < nbd> it works exactly like DEPENDS for other packages
[19:30] <groz_> ok, i'll fuss a bit more with it
[19:30] <groz_> it's probly just my typo here
[19:38] <groz_> nbd, can you see anything wrong with this ?
[19:38] <groz_> define KernelPackage/e100
[19:38] <groz_> TITLE:=Intel(R) PRO/100+ cards kernel support
[19:38] <groz_> DESCRIPTION:=Kernel modules for Intel(R) PRO/100+ cards kernel support
[19:38] <groz_> SUBMENU:=$(NDMENU)
[19:38] <groz_> FILES:=$(MODULES_DIR)/kernel/drivers/net/e100.$(LINUX_KMOD_SUFFIX)
[19:38] <groz_> KCONFIG:=$(CONFIG_EF100)
[19:38] <groz_> endef
[19:38] <groz_> $(eval $(call KernelPackage,e100))
[19:38] <nbd> no
[19:38] <groz_> it doesn't seem to matter what i do with the kconfig
[19:38] <groz_> it always shows up
[19:38] <groz_> right now, kernel has no EF100 set
[19:38] <nbd> sure, menuconfig can't figure out the kconfig stuff
[19:38] <groz_> but this still shows up
[19:39] <groz_> ok, so these will always show up then ?
[19:39] <nbd> because menuconfig is generated before it even knows what target to build for
[19:39] <nbd> yes
[19:39] <groz_> right, so what i'm wondering
[19:39] <nbd> maybe you should add this:
[19:39] <groz_> can i make that block dependant on an x86 target
[19:39] <nbd> DEPENDS:=@LINUX_2_6_X86
[19:39] <groz_> ok, that's what i was wondering
[19:40] <nbd> the DEPENDS stuff works like this:
[19:40] <nbd> without any prefix it depends on a certain package
[19:40] <nbd> adding + turns the 'depends' into a 'select'
[19:40] <nbd> adding @ makes it reference menuconfig options instead of packages
[19:40] <nbd> you can also use @+
[19:40] <groz_> ok, thanks, that's what i was looking for
[19:41] <nbd> i really need to document this :)
[19:41] <groz_> lol, well trial and error wasn't getting me there
[19:41] <groz_> so figured just ask, save grief
[19:41] <nbd> :)
[19:42] <groz_> can i or depends with ||
[19:43] <common> you should use paxmirabelis tar in openwrt
[19:44] <nbd> why?
[19:44] <nbd> just because mirabile rants so much about gnu tar?
[19:44] <nbd> :)
[19:44] <common> just to show 'you are the man' and then, 2nd point is, claim gnu tar is broken, and does not work
[19:44] <nbd> show me a single instance where gnu tar fails in our build system
[19:44] <common> i never saw tar failing anyway
[19:45] <common> thats not the point
[19:45] <nbd> but i saw paxmirabilis failing
[19:45] <nbd> :)
[19:45] <common> you have to _claim_ it, not _proof_ it
[19:46] <nbd> anyway. if gnu tar starts to cause problems, we could replace it
[19:46] <nbd> but so far it works, and paxmirabilis has problems with certain archives
[19:46] <nbd> so why bother?
[19:46] <common> i guess its hard to imagine, but i had a good time reading that gnu tar is broken and does not work
[19:46] <nbd> yeah
[19:47] <groz_> Well, it works for me, and guess what, as far as i'm concerned, that's 'good enuf'
[19:47] <common> groz_: i never saw tar failing
[19:48] <h3sp4wn> That --wildcards thing is annoying though (but only when building whiterussian)
[19:48] <common> but you miss an important quote
[19:48] <common> <mirabile> gnu tar is broken in so many respects that at around 2004-2005 nobody volunteered to maintain it any more
[19:48] <common> <mirabile> worse, GNU cpio creates broken(!) ustar archives
[19:48] <nbd> [mbm]: btw. should i remove the /etc/resolv.conf symlink and add a file pointing to 127.0.0.1 as nameserver?
[19:48] <nbd> [mbm]: (and point dnsmasq to /tmp/resolv.conf directly)
[19:48] <[mbm]> right, and change the dnsmasq.conf to point at .. yeah
[19:48] <nbd> ok
[19:57] <groz_> one last question nbc
[19:57] <groz_> should this work ?
[19:57] <groz_> DEPENDS:=@LINUX_2_6_X86 || @LINUX_2_4_X86
[19:57] <nbd> DEPENDS:=@LINUX_2_6_X86||LINUX_2_4_X86
[19:57] <nbd> (no spaces)
[19:58] <groz_> bingo
[19:58] <groz_> thank you
[20:12] <CIA-17> nbd * r4282 /branches/ (7 files in 6 dirs): use 127.0.0.1 as dns server and point dnsmasq to /tmp/resolv.conf
[20:43] <[mbm]> ok, what are the known broken platforms/packages? (adding the CONFIG_BROKEN now)
[20:46] <nbd> [mbm]: ar531x
[20:46] <[mbm]> yep, tagged that one already
[20:46] <[mbm]> think I'll tag the UNSUPPORTED archs too even though they're already hidden by DEVEL
[20:49] <CIA-17> mbm * r4283 /branches/buildroot-ng/openwrt/ (Config.in target/Config.in): introduce new BROKEN menuconfig option for hiding known broken settings
[21:07] <CIA-17> nbd * r4284 /branches/whiterussian/openwrt/package/webif/ (4 files in 3 dirs): add index.asp (symlinked from index.html) to make the transition from other broadcom-based firmware easier (#435)
[22:47] <crazy_imp> {Nico} ping
[00:00] --- Wed Jul 26 2006