**** BEGIN LOGGING AT Fri Dec 11 02:59:56 2009 Dec 11 04:24:37 should i be able to copy a package/foo from the packages git repository into the openwrt/package/ dir and run make package/foo install Dec 11 04:24:37 ? Dec 11 04:26:49 LetoTo: yes Dec 11 04:26:59 make oldconfig finds it. but running make install gives me a : make: `package/gmp' is up to date. Dec 11 04:27:13 followed by make[1]: Entering directory `/vol/svn/openwrt' Dec 11 04:27:13 make[1]: *** No rule to make target `install'. Stop. Dec 11 04:31:31 nbd * r18741 /packages/net/updatedd/Makefile: updatedd: run aclocal, autoconf, automake to fix remaining build inconsistencies Dec 11 04:34:18 nbd * r18742 /packages/net/shorewall-lite/patches/120-LOGFILE.patch: Dec 11 04:34:18 shorewall-lite: default shorewall-lite to not having any logfile, Dec 11 04:34:18 which normally defaults to /var/log/messages. Dec 11 04:34:18 Signed-off-by: Brian J. Murrell Dec 11 04:41:58 nbd * r18743 /trunk/scripts/config/ (lex.zconf.c_shipped zconf.l): menuconfig: allow wildcard includes to return no match (#6339) Dec 11 04:46:33 nbd * r18744 /packages/libs/liboping/patches/ (. 100-fd_error.patch): fix a bug in liboping that caused 100% cpu utilization in collectd (patch from #6337) Dec 11 04:50:58 fixed with "make package/symlinks" Dec 11 04:51:30 oh not. it just waits longer to die Dec 11 04:52:39 make package//install is the right command Dec 11 05:03:38 ah Dec 11 05:03:42 then https://forum.openwrt.org/viewtopic.php?id=9180 is wrong :) Dec 11 05:06:57 make package/foo/install also does not seem to depend on make package/foo/compile Dec 11 05:08:54 but cool. xl2tpd actually works now. and gmp too Dec 11 05:09:10 now just porting openswan again, since you guys seemed to have dropped it again Dec 11 05:30:13 LetoTo: nope, install doesn't depend on compile. Dec 11 05:32:58 is install only needed for libs to link against on the build platform? Dec 11 05:33:53 LetoTo: I think install is what puts a package in the target system (ie, if it's marked 'Y' not 'M') Dec 11 05:34:38 ahh Dec 11 05:34:54 then theres some target/prepare that runs the post-install scripts Dec 11 05:35:16 .. that's not it, but something like that anyway Dec 11 05:44:16 rootfs-prepare? Dec 11 08:13:35 mirko * r18745 /packages/libs/libdirectfb/Makefile: use only as keyboard driver, as more than one driver cause confusing behaviours - thanks to Xiang Fu Dec 11 09:19:08 nbd, [florian] : the process to have patches submitted is not clear Dec 11 09:19:27 First we send a patch that is ignored Dec 11 09:19:47 After we have to send a mail to signal that our patch is ignored Dec 11 09:20:08 And at least, nbd commit the patches Dec 11 09:20:17 right ? Dec 11 09:20:54 no Dec 11 09:21:32 nbd: can we skip the step "angry mail", please ? :) Dec 11 09:21:57 you send patches, which may be formated right, then may be good then may be interesting, then the developers may have time to test it and may have time to commit it Dec 11 09:22:13 Kaloz: I understand it Dec 11 09:22:17 this is how FOSS works ;) Dec 11 09:22:24 Kaloz: I know Dec 11 09:22:27 tmonjalo: you could nag in this channel if your mail was ignored :) Dec 11 09:22:29 * danage ducks Dec 11 09:22:35 danage: run! Dec 11 09:22:35 :) Dec 11 09:23:24 Kaloz: 26c3? Dec 11 09:23:32 I'll be there Dec 11 09:23:36 nice Dec 11 09:23:45 no idea in what mood, tho :p Dec 11 09:24:11 Palinkamood, I presume? Dec 11 09:24:25 I think there is not enough interested/motivated people to comment or commit patches Dec 11 09:24:46 tmonjalo: or the patch is for something people barely use Dec 11 09:25:00 tmonjalo: like the usb-audio mania infected only a handful people :P Dec 11 09:25:30 danage: dunno.. I'll bring palinka for sure, but drinks are for.. well, drinking, they hardly change your mood Dec 11 09:26:02 danage: OTOH they can increase said moods Dec 11 09:26:03 Kaloz: they catalyte mine.... :P Dec 11 09:27:49 Kaloz: Do you agree that it is a real problem for a project to not be able to integrate contributions ? Dec 11 09:27:56 I don't say it's easy Dec 11 09:28:19 But it has to be discussed Dec 11 09:28:35 tmonjalo: don't bug me, I'm bugging all the other devs for like 2 years to do mass package-maintainer collecting Dec 11 09:28:48 tmonjalo: eg. announce the call for them, and let those people take care of their crap :) Dec 11 09:31:08 Kaloz: Thank you for answering Dec 11 09:32:12 tmonjalo: np :) IMHO about 2 years ago we've reached the state when there are way too many packages/package combinations/targets for us to maintain everything.. Dec 11 09:36:54 Kaloz: It's difficult to have maintainer for each targets or packages Dec 11 09:37:17 But I see a solution: integrate all patches in trunk Dec 11 09:37:50 Accepting all can be a way of keeping a dynamic project Dec 11 09:40:19 and when we did that earlier things go broke every other day.. Dec 11 09:49:54 kaloz * r18746 /packages/net/openvpn/Makefile: upgrade openvpn to 2.1.0 final Dec 11 11:10:51 kaloz * r18747 /trunk/ (5 files in 3 dirs): upgrade to 2.6.31.7 Dec 11 11:40:06 kaloz * r18748 /trunk/target/linux/x86/patches-2.6.31/300-block2mtd_init.patch: refresh patch Dec 11 12:21:17 juhosg * r18749 /trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ (ag71xx_main.c ag71xx_phy.c): ar71xx: move mdio_bus reset code Dec 11 15:56:40 juhosg * r18750 /trunk/target/linux/ar71xx/ (config-2.6.28 patches-2.6.28/): ar71xx: nuke 2.6.28 support Dec 11 16:22:47 hi all, anyone interested in an issue with the ar7 sangam dsl driver firmware? the latest DSP datapump blob (7.04.03.00) reduces downstream sync speed on my line by ~1mbit compared to the previous version (7.03.01.66). would it be worth creating a ticket for this? Dec 11 16:23:51 <[florian]> bodski: yes, I could certainly provide a way to select the firmware version at compile time Dec 11 16:24:06 <[florian]> bodski: such that you can try different dsl firmware versions if you are not happy with the latest one Dec 11 16:25:41 florian: ok, great. I've not created tickets before, how much info should I include? Dec 11 16:26:23 basically what you already told + target (ar7) + model name + used openwrt version (/etc/banner. rev#) Dec 11 16:26:27 <[florian]> bodski: the one you just told me should be enough Dec 11 16:26:53 ok thx guys :) Dec 11 16:26:58 <[florian]> you are welcome Dec 11 16:41:44 juhosg * r18751 /trunk/target/linux/ar71xx/ (10 files in 4 dirs): ar71xx: merge ag71xx specific patches Dec 11 16:41:55 juhosg * r18752 /trunk/target/linux/ar71xx/ (5 files in 4 dirs): ar71xx: merge DSA switch patch Dec 11 17:53:29 <_trine> a friend of mine needs to buy a new modem for his adsl phone line which he needs to connect to his new wrt160nl; I don't know anything about adsl so is there anyone who could recommend a model of modem for this purpose? Dec 11 19:32:47 florian * r18753 /trunk/target/linux/rdc/Makefile: [rdc] remove the host-tool lzma dependency we now use the one provided in openwrt Dec 11 19:32:54 florian * r18754 /trunk/target/linux/rdc/ (5 files in 4 dirs): [rdc] convert gpio code to use gpiolib, make rdc321x:dmz led work again Dec 11 19:32:59 juhosg * r18755 /trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ag71xx_phy.c: ar71xx: fix NULL pointer dereference in the ethernet driver Dec 11 20:31:18 <_trine> There seems to be a problem with the latest trunk it stops booting here http://pastebin.com/m294221ff Dec 11 20:32:26 juhosg * r18756 /trunk/target/linux/ar71xx/patches-2.6.31/ (2 files): ar71xx: fix build error with 2.6.31.7 Dec 11 20:32:30 juhosg * r18757 /trunk/target/linux/ar71xx/files/arch/mips/ (ar71xx/ar71xx.c include/asm/mach-ar71xx/ar71xx.h): ar71xx: add ar71xx_device_stopped function Dec 11 20:32:33 juhosg * r18758 /trunk/target/linux/ar71xx/ (9 files in 6 dirs): ar71xx: add driver for the USB LED on the WNDR3700 Dec 11 20:32:34 <_trine> this is from a clean compile immediately after having done a distclean Dec 11 20:32:36 juhosg * r18759 /trunk/package/kernel/modules/other.mk: modules: package the leds-wndr3700-usb driver Dec 11 21:28:55 [florian]: ping Dec 11 21:39:43 somebody out here with a working AR7 device to test a patch to lzma2eva agains regressions? (Booting the device is enough) Dec 11 21:42:01 <_trine> mb__, I would help but my spare wrt160nl will not boot at the moment since I flashed it with the newest trunk Dec 11 21:42:25 nbd: uci is GPL 2? Dec 11 21:42:47 _trine: Oh trunk does not boot? Dec 11 21:42:56 <_trine> no Dec 11 21:43:15 <_trine> http://pastebin.com/m294221ff Dec 11 21:43:24 <_trine> it stops at this point Dec 11 21:43:31 _trine: The thing is, I'm on a PowerPC Build host and the lzma2eva tool is broken here. So I fixed it, but it still doesn't boot. So I guess I hit the known trunk bug then... Dec 11 21:43:54 <_trine> possibly Dec 11 21:44:00 No Dec 11 21:44:06 It doesn't print anything for me Dec 11 21:44:16 And sice you use uboot, you can't test it anyway Dec 11 21:44:22 <_trine> what doesn't Dec 11 21:44:43 The kernel doesn't print any messages Dec 11 21:44:52 <_trine> ah I see Dec 11 21:45:23 With broken lzma2eva the bootloader complained. So after fixing it doesn't do anything. hm. :) Dec 11 21:45:46 <_trine> you fixed it good then :)) Dec 11 21:46:07 I guess I'll just build the stuff on a i386 machine and try that. If that also silenly fails to boot... Dec 11 21:46:43 Well, I think the bootloader succeeds to load the kernel, but it fails to bootup. So I guess my fixes are fine and there are other bugs, too Dec 11 21:53:47 mb__: I can boot an AR71xx if you still need help... Dec 11 23:20:34 Hi anyone know if the driver for the marvell switch (mvswitch) is in a working state so that it can be configured for vlans using swconfig? Dec 11 23:21:39 I am attempting to try out the new(ish) marvell switch support, at the moment swconfig gives "Failed to connect to switch" Dec 11 23:50:48 nbd: ping Dec 11 23:50:53 mb * r18760 /trunk/tools/firmware-utils/src/lzma2eva.c: lzma2eva: Endianness fixes. Dec 12 00:05:39 Hm, just reading 2.6.33 feature list: "There is a new RCU variant, called "tiny RCU," which is meant for non-SMP situations where memory footprint must be minimized. " Dec 12 00:05:46 That's probably an interesting one Dec 12 00:44:05 nbd * r18761 /trunk/tools/ (11 files in 3 dirs): add wrt350n v2 image building code from #5970 (thx, maddes) Dec 12 00:45:34 nbd * r18763 /trunk/target/linux/orion/image/Makefile: build wrt350n v2 recovery and web upgrade images (based on patch from #5970) Dec 12 00:54:35 nbd: count = sscanf(line, ":%64s %i %64s", string1, &value, string2); Dec 12 00:54:58 I think you need %63 there, because it means 63 chars plus nul termination Dec 12 00:55:33 nbd: glibc docs: "To make a robust program, you must make sure that the input (plus its terminating null) cannot possibly exceed the size of the buffer you provide. In general, the only way to do this is to specify a maximum field width one less than the buffer size." Dec 12 00:56:35 Not that it matters much here, but just for completeness :P Dec 12 01:00:29 right Dec 12 01:01:43 nbd * r18764 /trunk/tools/wrt350nv2-builder/src/wrt350nv2-builder.c: wrt350nv2-builder: fix a small off-by-one error (thx, mb) Dec 12 01:03:18 someone mentioned openembedded last night, i've never really looked at it before, anybody want to comment on it, how it compares to openwrt? Dec 12 01:19:04 nbd: still here? Dec 12 01:22:52 yes Dec 12 01:23:09 but not for much longer Dec 12 01:23:53 nbd: I have a question regarding the libphy stuff Dec 12 01:24:24 basically, there seems to be a direct mapping from phy<->netdev Dec 12 01:24:59 nbd: but if the netdev is connected to a switch, that's not really the case and I don't have a real idea, how to handle this Dec 12 01:26:11 nbd: is there any driver, where something like this is already implemented? Dec 12 01:26:30 or do I have some mistake somewhere? Dec 12 01:27:37 at the moment none of our switch drivers manage the phy state for individual ports Dec 12 01:28:08 so the switch attaches to the netdev as a phy device Dec 12 01:28:50 nbd: well, if I scan the mii bus, there are multiple phys ... Dec 12 01:29:06 the driver picks one Dec 12 01:29:14 the ethernet driver Dec 12 01:29:20 nbd: is there a rule or more or less at random? Dec 12 01:29:27 i don't know Dec 12 01:29:33 at the moment it's up to the driver Dec 12 01:29:39 and another question Dec 12 01:29:40 but imho this should be generalized somehow Dec 12 01:29:49 not really :/ Dec 12 01:29:51 i checked Dec 12 01:30:17 it isn't right now, i know Dec 12 01:30:24 but we should generalize it at some point ;) Dec 12 01:30:30 there are calls to netif_carrier_on/off Dec 12 01:31:10 this will kinda blow up if it calls netif_carrier_off for one phy but there is still a cable attached to another phy Dec 12 01:31:19 or did I get this wrong? Dec 12 01:31:28 our switch drivers typically return an always-on status Dec 12 01:31:37 there is an exception for a switch that's handled slightly differently Dec 12 01:31:49 for instance the rtl8306 switch connects to two ethernet macs at the same time Dec 12 01:31:54 one for lan, and one for wan Dec 12 01:32:04 so the driver has two methods for returning the status Dec 12 01:32:09 I would like to make it gernal, but would need some help Dec 12 01:32:10 and provides two phy devices Dec 12 01:32:21 that's another problem Dec 12 01:32:45 one problem is, that this is really hard to generalize Dec 12 01:32:59 because in this case, both ethernet devices share the same mdio bus Dec 12 01:33:14 so the ethernet driver definitely needs some knowledge about the phy setup Dec 12 01:33:15 the rdc3210 also has 2 macs and each has it's own mdio mus registers but there are two buses created Dec 12 01:33:22 right Dec 12 01:34:08 I'm not even sure, how to detect, which mac is connected to which phy :/ Dec 12 01:34:47 nbd: If I would manage to write something, would you help me with testing and porting and stuff?´ Dec 12 01:35:49 crap, lost connection Dec 12 01:35:54 nbd: If I would manage to write something, would you help me with testing and porting and stuff?´ Dec 12 01:41:28 sure Dec 12 01:42:53 nbd: Dec 12 01:42:56 Thanks Dec 12 01:43:54 I'm not sure how long it will take. There is also the umts stuff for which I wanted to create a patch, but then I discovered that 2 network ports on my router don't work Dec 12 01:56:23 nbd: this whole thing is really ugly :/ Dec 12 02:21:17 nbd: hi....just to let you know I haven't forgotten the preinit stuff and the usb root, I've just been busy...I should work on it next week by mid week Dec 12 02:22:03 that is start mid week Dec 12 02:22:45 also at some point I want to the changes for the changin CRC brcm63xx routers **** ENDING LOGGING AT Sat Dec 12 02:59:57 2009