**** BEGIN LOGGING AT Sat Nov 03 02:59:57 2007 Nov 03 10:34:47 nbd * r9486 /packages/net/olsrd/ (Makefile patches/110-build_fix.patch): clean up olsrd makefile, fix a very annoying dependency bug in the olsrd build system Nov 03 12:13:25 nbd * r9487 /trunk/include/toplevel.mk: increase scan depth to 5 for package/ (x.org is nested deeper than the rest of the packages) Nov 03 13:12:46 nbd * r9488 /packages/XOrg/lib/gtk-1.2.10/Makefile: add a faster download url for gtk 1.2 Nov 03 13:12:50 nbd * r9489 /packages/XOrg/lib/imlib2/Makefile: better download url for imlib2 Nov 03 14:36:53 hi, all! Nov 03 14:37:57 do anybody remembers some list of rtl865x-based routers with Linux on board with links to released source code? Nov 03 14:53:27 juhosg * r9490 /trunk/ (4 files in 3 dirs): Nov 03 14:53:27 [adm5120] image generation fixes (closes: #2643, #2644) Nov 03 14:53:27 * rewrite mkcsysimg to use an align parameter instead of a fixed size Nov 03 14:53:27 * Edimax images contains the jffs2 end-of-filesystem marker at the right position from now on Nov 03 14:58:42 slapin_nb: (repeat) you mentioned the rtl865x. I'm interested in the Linksys WRV200. It is a wireless VPN router. It uses ucLinux and Openswan. There is a source release but I don't know if anyone has been able to build and burn firmware. Nov 03 15:00:03 I added the WRV200 row to the openwrt hardware table. I also added mention of it (and the GPLed code) to the RTL8651B page in the wiki. Nov 03 15:04:14 dhr, thanks, I'm just collecting tarballs looking for all available source, especially for drivers, since all the releases are different it is like a puzzle collection - so when you have all pieces you're able to build whole picture :) Nov 03 15:05:33 I'm interested in getting OpenWRT on the WRV200, but it looks like a bigger task than I'm up for. How about you? Are you adding to the RTL8651B wiki page? Nov 03 15:05:38 dhr, I was able to partially (kernel) build firmware for DI-524UP. it was challenging. I also built rootfs, but not tested it yet since it looks very different from what is in firmware distributed by vendor. Nov 03 15:06:35 dhr, no, I'm not adding there, I'm just interested in DI-524UP support and gather information. Nov 03 15:09:25 I've reluctantly decided that attacking the WRV200 is too big a job. Barriers that I see: Nov 03 15:09:40 - nobody else is working on it. Sharing to effort is important. Nov 03 15:10:19 - what the heck is the ROME loader? Is there a reasonable way to recover from debricking (as there is for CFE)? Nov 03 15:10:57 - has enough source been released? Can the missing source be replaced by .o files found in the binary firmware releases? Nov 03 15:11:01 dhr, I see, so I've set up git repository at git://ossfans.org/git/di524up.git so somebody might be interested and web page http://ossfans.org/DI524UP Nov 03 15:11:29 dhr, probably you will find some info there which will lead you to some success. Nov 03 15:11:31 - the binary-only drivers are for ucLinux: probably not of any use on an OpenWRT kernel. Nov 03 15:12:27 - Linksys firmware is buggy. They release (through a backdoor) only binaries for the beta firmware which is better. Nov 03 15:12:30 dhr, well, as I said, different tarballs contain different data for same chips, some contain sources, some - blobs only, so it is needed to collect all of them first. Nov 03 15:15:27 I'm starting to read your web page. Good stuff. Consider explicitly broadening it to cover other boxes with a similar heritage. Nov 03 15:16:08 dhr, I myself can say only about my box, so it is up to you to provide info. Nov 03 15:18:10 it looks as if your box is running uclinux (Linux version 2.4.26-uc0 (root@redhat9) (gcc version 3.3.3) #1 Mon May 15 14:23:11 CST 2006). Nov 03 15:18:42 did you guys talk to ejka about his rtl8651 port yet? Nov 03 15:19:05 Do you know if it is using the MMU? The original reason for ucLinux was to NOT use the MMU (because the target platform didn't have it). Nov 03 15:19:35 nbd: (repeat) the bugfix I am concerned about is in the last message of https://dev.openwrt.org/ticket/1936 Nov 03 15:19:43 dhr: will check it out later Nov 03 15:19:50 nbd: thanks! Nov 03 15:19:57 dhr: the reason why they used uclinux is for backwards compatibility Nov 03 15:20:11 the older lexra cores (4xxx, iirc) had no mmu Nov 03 15:20:15 but the newer ones do have one Nov 03 15:20:26 nbd yeah, but he is not available these days. Nov 03 15:20:37 so rtl8651b can run a full linux Nov 03 15:21:24 nbd: no, I have not talked to ejka. It would be good if all efforts were connected somehow. Like, for a start, with links from http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PNid=9&PFid=11&Level=4&Conn=3&ProdID=70 Nov 03 15:21:30 nbd and this firmware uses mmu, too. Nov 03 15:21:42 sorry, I meant http://wiki.openwrt.org/RTL8651BPort Nov 03 15:22:05 I always was talking about that/ Nov 03 15:22:34 i think ejka has basic arch support up and running and he's working on a rewritten ethernet driver Nov 03 15:24:19 nbd, I think the same, but it would be better if that was more open since while I really could help with kernel stuff I have to wait since I don't want to duplicate work. Nov 03 15:24:38 yeah Nov 03 15:24:46 next time i see that he's active, i'll talk to him about it Nov 03 15:26:12 slapin_nb: it would be great if http://ossfans.org/DI524UP/ could somehow be moved to or connected with the openwrt wiki. Hey, I'd even fix a typo Nov 03 15:27:37 dhr, I think I could make you an account or I think a page on wiki could be arranged with me and you to fill up, but I'm not yet aware about OpenWrt infrastructure so don't know who to ask. Nov 03 15:27:52 anyone can edit wiki pages Nov 03 15:28:24 dhr, while at this you could provide info about typos, I could fix them in a few mins/ Nov 03 15:29:54 nbd: yes: I've edited them. Its very useful for folks who are willing to do a little bit but not make a large commitment. There are some bugs in the current wiki that cause some pages to not be editable. Nov 03 15:30:16 hm Nov 03 15:30:27 the wiki really needs to be replaced Nov 03 15:30:32 the moinmoin software sucks Nov 03 15:30:47 slapin_nb: the typos that I've noticed are perfect for a wiki: not worth bothering you about but easy for the reader to fix. Nov 03 15:31:16 for example: s/componentw/components/ Nov 03 15:32:30 not correct grammar: "Working on this now, so to be able to check that custom formware contains all needed files, and to remove need for closed tools" Nov 03 15:34:26 if only the realtek code wasn't so fscking ugly Nov 03 15:34:31 that would make reimplementing it a bit easier ;) Nov 03 15:34:45 :) Nov 03 15:35:26 juhosg * r9491 /trunk/target/linux/adm5120/files/arch/mips/adm5120/boards/mikrotik.c: [adm5120] RB153 must use the generic RB1xx's setup code Nov 03 15:38:12 slapin_nb: I've adding a link to your work on the bottom of http://wiki.openwrt.org/RTL8651BPort . Feel free to add more stuff. For example, there is a place just above my addition where it would be good to add a link to the D-Link's firmware source release. Nov 03 15:39:22 moin Nov 03 15:39:31 nbd: I've not even looked at the realteck code. Which part is ugly? Device drivers? Any knowledge gleaned from examination ought to be shared (I'm an idealist). Nov 03 15:39:34 moin moin Nov 03 15:39:43 dhr, thanks, I will arrange something about this this weekend. Nov 03 15:40:52 btw, the reason I bought a wrv200 was because I needed an IPSec VPN with a particular feature. The online manual said the WRV200 had the feature. I bought it and the feature was absent. Nov 03 15:40:59 dhr, checkout git repo and look e.g. to their bootloader source. I found lots of bugs in it just visually. It is total mess - algorithmically and on source level. Nov 03 15:41:27 dhr: every single bit of code added by realtek seems to be crap Nov 03 15:41:29 :) Nov 03 15:42:07 nbd, not that every bit, but I hope their hardware is better than software. Nov 03 15:42:09 either way, i see no point in doing any work on the 2.4 codebase Nov 03 15:42:22 it should be abandoned and replaced with ejka's 2.6 work Nov 03 15:42:55 nbd, well, I do stuff on it just to understand hardware more to help with implementation of 2.6 support. Nov 03 15:42:58 OpenWRT isn't the only way to get what we want/need. A good way, but not the only way. Nov 03 15:43:42 I'd like to start by rebuilding the WRV200 firmware with dropbear. Modest goal that seems out of reach with the time I have. Nov 03 15:44:02 nbd, btw, how small could 2.6 kernel be made, since my device contains only 4Mb of flash? Nov 03 15:44:51 it should be small enough to fit on 4 MB flash with a regular sized rootfs Nov 03 15:45:30 it's a bit bigger than 2.4, though Nov 03 15:46:05 btw, which ssh client is better for such devices - openssh or dropbear? Nov 03 15:46:23 openssh is way too fat Nov 03 15:47:02 * nbd never saw much good come out of vendor firmware modding projects Nov 03 15:48:14 nbd, but dropbear (as server) has problems with entropy gathering, no? Nov 03 15:48:34 we use /dev/urandom for it. Nov 03 15:48:47 nbd, IIRC, maemo use openssh and lots of other projects too. So I wonder... Nov 03 15:49:05 maemo is not designed to fit in 4 mb flash :P Nov 03 15:49:19 nbd, you're right... Nov 03 15:49:44 nbd, but I have 200Gb hard drive attached to this device... Nov 03 15:49:47 lol Nov 03 15:49:54 that doesn't give you any extra ram :P Nov 03 15:50:16 nbd, yeah, just some swap... Nov 03 15:50:19 haha Nov 03 15:50:41 nbd, but from client side - which one is better? Nov 03 15:51:03 better for what? Nov 03 15:51:47 nbd, I mean doesn't dropbear has problems with connecting to other servers, especially ones with v1 protocol disabled and allowing only logins based on dsa2 keys? Nov 03 15:51:58 dropbear has support for dsa and rsa Nov 03 15:52:10 and supports the v2 protocol Nov 03 15:52:23 i've never had any issues with it Nov 03 15:52:42 nbd, then let it be dropbear, thanks a lot! Nov 03 15:56:55 btw. there's another way that could proably save you quite a bit of work Nov 03 15:57:18 nbd which one? Nov 03 15:57:25 you could add an openwrt port that uses the existing 2.4 kernel stuff Nov 03 15:57:47 it wouldn't be accepted in openwrt, but at least you get a ready to use userspace Nov 03 15:58:45 nbd, I will need to add realtek closed userland stuff in this case which will create even more problems. So I hope to get rid of it as I understand how it works. Nov 03 15:59:08 why do you need the realtek userland stuff? Nov 03 15:59:35 nbd because to control kernel blob stuff you need userland blob stuff. Nov 03 15:59:46 nbd, life is not that easy :( Nov 03 15:59:56 you could make a small chroot that contains the correct libc for the realtek crap Nov 03 16:00:03 and isolate it from the rest of the userland Nov 03 16:01:08 btw. about the kernel blob stuff Nov 03 16:01:13 the ioctl interface seems to be open Nov 03 16:01:23 nbd, this stuff is quite big so not in flash. Nov 03 16:01:32 so you wouldn't necessarily have to use the userland stuff Nov 03 16:01:49 nbd, it is not about ioctls Nov 03 16:01:52 if you strip the libc and the utils, they will most likely be small enough to fit on flash as well Nov 03 16:02:04 what other blob crap is there? Nov 03 16:02:10 nbd: I'm still exploring this world. I like the idea of OpenWRT but my experience has lead me to think that the project is overstretched. Perhaps based on too little data. Nov 03 16:02:29 dhr: overstretched how? Nov 03 16:02:51 nbd, web server, LPRng humilation, hotplug, cveshell, etc. Nov 03 16:03:04 slapin_nb: why do you need those? Nov 03 16:03:29 well, for example, my WR850 doesn't work with the Kamikaze. I posted a fix a month ago and have tried a bunch of ways to get some attention for the fix but your response today was the first hope I've had. Nov 03 16:03:50 well, we just need a maintainer for brcm-2.4 Nov 03 16:04:06 i did much of the work on it, but i don't have that much time for it anymore Nov 03 16:04:14 other platforms work better and have a faster patch acceptance rate Nov 03 16:04:18 nbd, cveshell controls asic which controls switch (ethernet), web server directly controls that asic and there's no other way to control e.g firewall and port forwarding, etc. Nov 03 16:05:18 I posted a several of things on the mailing list with little response. Nov 03 16:05:29 slapin_nb: ugh. what a horrible design Nov 03 16:06:27 dhr: do you want commit access? Nov 03 16:06:38 i could talk to the other devs Nov 03 16:09:04 nbd: I don't think I deserve commit access in some sense. I don't want to do a lot and I haven't had the experience with the project. I'm not blaming anyone, just forming an impression. Nov 03 16:09:52 you're right in that we don't have enough people to review and commit submissions on trac or the mailing list Nov 03 16:11:15 you, for example, accepted my changes in ticket 2483. Thanks! But I hope that you reviewed them. Nov 03 16:11:58 it wasn't a very thorough review, but it looked fine to me Nov 03 16:16:04 btw, do project have some integration system (like some build server with images to test)? Nov 03 16:17:55 nbd * r9492 /trunk/package/broadcom-diag/src/diag.c: fix wr850g detection (#1936) Nov 03 16:18:07 dhr: i added a better fix. could you confirm that it works? Nov 03 17:00:59 juhosg * r9493 /trunk/tools/firmware-utils/src/ (mkzynfw.c zynos.h): [firmware-utils] fix some definitions in the ZyXEL tool Nov 03 17:08:30 nbd: your change does look better (but less conservative). To be honest, I don't know how to test: I've just used project-supplied firmware binaries on the two times that I've flashed. Do I have to check out the whole tree and build my own firmware (that is my current understanding)? Although this is in a "package" directory, I don't think that it ends up in an ipk. Nov 03 17:10:44 nbd: thanks for taking this on. Nov 03 17:12:11 yes, checking out the tree and building it is the right way Nov 03 17:12:22 and yes, all stuff from package/ ends up in .ipk files Nov 03 17:12:30 the diag stuff is a module Nov 03 17:12:36 and not compiled into the kernel image Nov 03 17:12:56 ah, so it is in kmod-diag Nov 03 17:13:07 yep Nov 03 17:15:29 anatomy question: if I took my existing 7.09-flashed system and did an update of the kmod-diag package, would that work? My guess is that it might not because the module might have to be available before the jffs2 filesystem is mounted (is there an initrd in openwrt?). Nov 03 17:16:11 it has to be compiled into the firmware image Nov 03 17:16:20 there is no initrd Nov 03 17:16:40 it loads diag before it attempts to mount the jffs2 Nov 03 17:16:51 because it needs it for failsafe support Nov 03 17:16:54 but... Nov 03 17:17:06 you could replace it on a jffs2 image Nov 03 17:17:15 if you don't use squashfs, then there's no read-only part Nov 03 17:20:00 for production use, I understand the squashfs + jffs2 setup to be fairly optimal -- a good design. Is there a convenient host-based tool that lets you do ipkg-like things *before* the image is built and the squashfs is frozen? Nov 03 17:21:38 If I build from the head of the svn tree, am I likely to get breakage from other changes since 7.09? Am I best off grabbing 7.09 source and grafting your fix in and building from that? Nov 03 17:25:03 i haven't tested brcm-2.4 with the current trunk Nov 03 17:25:08 so putting the fix in 7.09 should be safe Nov 03 17:25:27 there is no tool for running ipkg on the host for the image, because it's not necessary Nov 03 17:25:33 simply select all the packages that you want in make menuconfig Nov 03 17:25:39 and they will get built into the image Nov 03 17:28:44 makes sense. Nov 03 17:30:20 I would like to install Openswan on my wr850. I've been helping the Openswan folks get a new release built for Openwrt. How can I tell if it will fit in the RAM and flash of the router? I don't really know how to interpret df output with respect to compressing filesystems. Nov 03 17:50:26 there's no easy way to tell without trying it Nov 03 17:53:23 slapin_nb: thanks for updating the wiki page. The table of hardware lists the amount of flash as unknown. Can you improve on this? Nov 03 17:55:14 glp: thank for your help on WIP day. nbd has just checked in a fix for diag.c to properly recognize the motorola WR850. Nov 03 17:55:52 my motorola worked fine last time I tested it (with 2.6 though) Nov 03 17:56:13 WR850G v3 Nov 03 17:59:34 h3sp4wn: see https://dev.openwrt.org/ticket/1936 for the story. nbd's fix is a little different but should have the same effect as what I proposed (his is more general). Nov 03 18:11:16 dhr, TOH page clearly says 4MB. Nov 03 18:23:39 spapin_nb: there are four 524 lines and I only looked at the first. Sorry. Your 524UP is clearly a different beast anyway (USB port). Nov 03 18:23:53 s/spapin/slapin/ Nov 03 18:57:51 slapin_nb: ping Nov 03 19:07:09 aet, hi! I compile dropbear for my router, as soon as it works I'll put firmware parts for upload. Nov 03 19:08:47 dhr, I'm only interested in CPU generality, USB is different matter. Nov 03 19:38:24 Does the RTL8650B have more CPU crunch than the BCM stuff that most OpenWRT platforms use? I don't know how to compare the MIPS32 implementation with the ARM implementations. Nov 03 19:38:55 The WRV200 seems to have hardware crypto (if I remember correctly). Nov 03 19:39:05 dhr: There is multiple different arm implimentations Nov 03 19:39:19 arm just licenses the basic design Nov 03 19:39:43 I know; I meant the implementation in the BCM-based boxes (that's why I specified BCM). Nov 03 19:41:40 arm licenses cores but not all arm implementations use their cores. For example, the StrongArm/XScale was not a core from ARM-the-company. Nov 03 19:42:48 They licensed the stuff originally to DEC Nov 03 19:43:12 As I remember, they licensed the architecture but not a core. Nov 03 19:50:32 nbd, dropbear segfaults :( it seems that I either have to find some source with working dropbear or will need to use openssh. Probably there is even smaller ssh implementation? Nov 03 19:52:18 see, that's the reason why we don't want to mess with crappy vendor firmware source trees Nov 03 19:53:54 nbd, well, I use hand-made toolchain with lexra patches just to be lib-compatible, and most binaries work (ctorrent, busybox, etc.) Nov 03 19:54:25 nbd, any hints to add this stuff to OpenWRT tree? Nov 03 19:54:46 nbd, I have gcc-4.1 patch from ejka. Nov 03 19:54:54 you need to use 3.4 Nov 03 19:55:03 because linux 2.4 won't work with gcc4 Nov 03 19:55:12 nbd, so I hope I will be able to build userland Nov 03 19:55:29 nbd, I don't want to build kernel in this case Nov 03 19:56:15 nbd, I'd prefer to have proper userland if I barely can do anything about kernel this time. Nov 03 19:57:47 nbd, any links to documentation? Nov 03 20:00:03 you should start by reading the makefiles in target/linux/*/ Nov 03 20:00:19 the default kernel version is defined in include/kernel-defaults.mk Nov 03 20:00:25 you can override it from the target makefile Nov 03 20:00:33 i mean kernel-version.mk Nov 03 20:00:40 kernel-defaults.mk contains the build instructions Nov 03 20:00:56 all the templates in there can also be replaced from the target makefile Nov 03 20:31:53 nbd, thanks. how could I insert patch to toolchain so it is used for one particular board only and how much space default image takes to build? Nov 03 20:35:14 nbd, and which 26.x kernel version is know to build to build kernel headers from? 2.6.20 fails. Nov 03 20:54:28 evening ;-) Nov 03 20:57:42 lo Nov 03 20:59:54 I called/invited to discuss the present work with the documentation aspect Nov 03 21:02:09 'lo Nov 03 21:03:50 The first point on the proposed agenda was: Getting a roadmap together? Nov 03 21:07:42 I've been trying to think about what such a roadmap depends on - and I keep returning to the question: what is the specific focus of the documentation? Nov 03 21:08:38 for me the answer is: To give a "broad" introduction to how to use and work with kamikaze Nov 03 21:08:50 yeah Nov 03 21:09:51 it is quiet easy to place a lot of energy in the process of explaining what an embedded sytstem is, what are the differences of the various platforms etc. Nov 03 21:11:01 There are more than a few books on those subjects and they are all thick and heavy Nov 03 21:11:41 yeah, the main focus should be what makes openwrt different from other systems Nov 03 21:12:06 So I think the basic assumption in the documentation needs to be that the system is up-and-running Nov 03 21:12:50 i agree. the information on how to flash the various hardware could be maintained in the dev wiki Nov 03 21:13:35 this does not ignore the whole process of 'installation' - apart from some general information such as: It is very often done via tftp etc Nov 03 21:14:19 nbd: as you said - the device specific information should be in the wiki Nov 03 21:18:19 so I think the installation section in the documentation should at the present be generalized comments + a little more specific information on bootloaders Nov 03 21:19:53 more or less in the line: know your bootloader and you know what to do with the device Nov 03 21:31:31 so I thought that an initial roadmap would "just" fill out the present gaps without adding to much extra information? Nov 03 21:35:40 in addition to this - it is needed to take a look at the latex document structure, makefile etc. Nov 03 21:36:51 I just get a lot of "loose end" when I run make on my local wip-versions Nov 03 21:40:47 so the roadmap could look something like: 1. fill the present gaps - 2. make it look nice(r) - 3. work on the linking/integration with existing information in wiki Nov 03 21:41:44 - 4. extend documentation with "missing" information Nov 03 21:42:24 I don't really know what is missing at the present, but I'm sure something will pop-up ;-) Nov 03 21:43:34 any comments on this? Nov 03 21:47:36 Point 2 on the agenda :o) Nov 03 21:47:47 Practical editing Nov 03 21:50:22 I'll go ahead and do some work and talk to the people who have been active recently Nov 03 21:50:47 in this regard Nov 03 21:51:29 Kaloz: how's the new server coming along? I'm here thinking about the migration to mediawiki .. Nov 03 21:57:55 * slapin_nb managed to trick OpenWRT to not build target kernel... Nov 03 21:58:38 :P Nov 03 22:00:46 nbd, ping Nov 03 22:01:09 slapin_nb: pong Nov 03 22:01:49 glp: i reviewed the getting_started.tex. looks fine mostly Nov 03 22:01:58 i just have some minor corrections about the list of supported platforms Nov 03 22:02:01 nbd is there any easy way to add patch to toolchain so it will be activeted only when specific board is chosen in config? Nov 03 22:02:45 not at the moment Nov 03 22:02:59 nbd, and also - is it possible to use one compiler for kernel and another for userland? Nov 03 22:06:34 nbd and how to make it build image actually? (I want rootfs tarball) Nov 03 22:06:44 * blogic popels nbd Nov 03 22:06:50 you should studying :P Nov 03 22:19:44 nbd: sound good Nov 03 22:21:44 nbd: I'll jsut check with the list of supported platforms - and run an update Nov 03 22:22:21 things like sibyte or user mode linux aren't really supported, as they're currently unmaintained and broken Nov 03 22:23:51 does OpenWRT build system use fakeroot to generate images? Nov 03 22:24:04 nbd: but technically speaking they are included :o) Nov 03 22:24:13 slapin_nb: no Nov 03 22:24:48 nbd, I see, thanks. So I could just make tarball myself? Nov 03 22:25:59 nbd, how to force rebuild of everything? Nov 03 22:26:19 rm -rf build_dir staging_dir Nov 03 22:26:33 nbd, thanks! Nov 03 22:27:23 nbd: ping Nov 03 22:27:27 pong Nov 03 22:27:33 i found another beauty Nov 03 22:27:37 a file with Nov 03 22:27:44 1.) space and no tabs .... Nov 03 22:27:51 i am used to this already ... Nov 03 22:27:57 but much better ... Nov 03 22:28:09 2.) void blah(void) { .. }; Nov 03 22:28:15 anything weird ? Nov 03 22:31:00 nbd, how could I provide some CFLAGS for target (I need to add -mlexra)? Nov 03 22:31:47 blogic: ? Nov 03 22:32:05 ; at the end ? Nov 03 22:32:06 :P Nov 03 22:32:40 yeah. i just wondered why it's noteworthy with all the other crappy code ;) Nov 03 22:32:47 welll Nov 03 22:32:57 ryd * r9494 /trunk/target/linux/brcm-2.4/config-2.4.34: fix missing CONFIG_USB_BLUETOOTH issue Nov 03 22:33:03 i think the 2 main fuckups you can do is the ; at the end Nov 03 22:33:14 and... which is much worse ... Nov 03 22:33:19 void main(void) Nov 03 22:33:33 for void main(void) your genitals need to be mutilated Nov 03 22:33:41 it is not c Nov 03 22:33:57 yeah Nov 03 22:34:30 anyway ... :P Nov 03 22:34:42 we had a spy here tonight :P about the stift issue Nov 03 22:34:50 i wonder who sent him Nov 03 22:34:58 but he asked funky questions Nov 03 22:34:59 a spy? Nov 03 22:35:05 well a n00b Nov 03 22:35:13 ryd knew him Nov 03 22:35:15 ask ryd Nov 03 22:35:31 * ryd is not responsible Nov 03 22:35:40 * blogic slaps ryd Nov 03 22:36:54 ahhhhhh Nov 03 22:36:55 int len=0;; Nov 03 22:37:04 causing ... Nov 03 22:37:11 drivers/net/danube_sw.c:840: warning: ISO C90 forbids mixed declarations and code Nov 03 22:37:22 this is getting to me :P Nov 03 22:37:31 hehe Nov 03 22:37:44 hmm Nov 03 22:37:51 i think we need to make a patch Nov 03 22:38:02 replace -pedantic against -notpedantic Nov 03 22:38:08 :P Nov 03 22:38:24 could anybody tell me where could I add -mlexra so to build all userspace with this flag? Nov 03 22:38:38 the cflags are configured in menuconfig Nov 03 22:38:40 gcc options ? in make menuconfig Nov 03 22:38:41 blogic: nbd had to study this days :) Nov 03 22:38:51 * nbd needs a bit of distraction Nov 03 22:39:05 lol Nov 03 22:45:00 does OpenWRT supports building with make -j x ? Nov 03 22:45:55 normally it should work Nov 03 22:50:02 nbd: make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. Nov 03 22:50:17 nbd, it seems not to work. Nov 03 22:53:34 slapin_nb: when you know, that it is not working, why you ask that way insteed of telling it direcly Nov 03 22:53:48 anyway Nov 03 22:53:54 ryd, I first asked then tested. Nov 03 22:54:33 I thing it will be fixed next days :) Nov 03 22:54:49 ryd, I try to build on multy-cpu machine which has 8 CPUS but each one is quite slow (PIII-style xeons). Nov 04 01:01:49 blogic: I think the more checking the better. The warning you mention is of course correct. Nov 04 01:04:28 ? Nov 04 01:04:43 dhr ? Nov 04 01:04:43 drivers/net/danube_sw.c:840: warning: ISO C90 forbids mixed declarations and code Nov 04 01:04:46 the ;; thing ? Nov 04 01:04:52 i know Nov 04 01:05:03 but this was inside vendor code Nov 04 01:05:13 i added it to the hall of shame Nov 04 01:05:16 fire the vendor :-) :-) Nov 04 01:05:21 ? Nov 04 01:06:14 there are actually plenty of c90 violations that people code because of permissive compilers. (I've written a strict C compiler.) Nov 04 01:06:33 as i said Nov 04 01:06:37 -pedantic **** ENDING LOGGING AT Sun Nov 04 02:59:57 2007