**** BEGIN LOGGING AT Mon Oct 04 02:59:57 2010 Oct 04 03:03:14 just posted the patch... not sure how to make some of the tracing output go away... Oct 04 03:04:36 like the --no-print-directory thing. Oct 04 03:27:20 hi Oct 04 03:27:26 i'm about to go to sleep Oct 04 03:27:32 what would you use a module blacklist for? Oct 04 03:28:42 there are times when you don't want pppoa, pppoe, etc. loaded up because... well, it's cleaner for a few reasons to have the ppp script just load them as needed on demand. Oct 04 03:29:02 i still consider that a rather useless micro-optimization Oct 04 03:29:40 i have yet to see any significant advantage to this Oct 04 03:29:50 those modules use only very little memory Oct 04 03:29:52 when you're working with the ATM driver group and the PPP maintainers, you're exposed to some patches that make such changes necessary. Oct 04 03:30:28 that sounds awfully broken by design to me, if you cannot use pppoe and pppoa concurrently anymore Oct 04 03:30:28 it's more about being able to isolate modules and test them on their own without interacting with others. Oct 04 03:30:50 but we had that discussion already :) Oct 04 03:30:57 eventually they will work concurrently in production. Oct 04 03:31:11 but that could take a couple of months of testing. Oct 04 03:31:26 I don't have access to an unlimited number of ISP's. Oct 04 03:31:26 philipp64|laptop: i looked at the patch you showed me Oct 04 03:31:33 so I have to cut images for others to test. Oct 04 03:31:40 and i already told you there's nothing inside that makes preventing module load necessary Oct 04 03:31:44 ummm... which one? Oct 04 03:31:59 the pre patch from the atm guys, iirc Oct 04 03:32:04 the one for the ppp stuff Oct 04 03:32:05 oh, that one. yeah, Karl rewrote that. Oct 04 03:32:20 and he'll probably rewrite it again tomorrow. Oct 04 03:32:36 i would be very much surprised if he screwed up the design so much as to make module unloading necessary Oct 04 03:32:47 last patch didn't require it, and i don't think future patches will require it either Oct 04 03:32:55 because it takes a rather bad design to mess it up that way ;) Oct 04 03:33:16 philipp64|laptop: but wouldn't it be easier to create a custom files/ overlay which patches yor /etc/modules.d/ & friends? If you use the env script it will even create a git repo for you to manage it Oct 04 03:33:31 well, for now, I'm focusing on getting the "mask" argument to gpio-cs5535 into the read-only squashfs image. Oct 04 03:34:03 xMff: not sure I follow. Oct 04 03:34:04 philipp64|laptop: did you try whether you can apply that through sysfs now? Oct 04 03:34:28 if yes you can make that a preinit file and do not worry about overlay and postinstall stuff Oct 04 03:34:54 how does the preinit stuff work? Oct 04 03:35:22 I mean something like echo mask=0x... > /sys/modules/gpio-cs5535/parameters/mask Oct 04 03:35:27 oops Oct 04 03:35:34 *echo 0x... > /sys/modules/gpio-cs5535/parameters/mask Oct 04 03:36:28 preinit is just a bunch of shell functions that are sequentially executed before launching init Oct 04 03:36:57 no services running at this stage Oct 04 03:38:38 not sure how that's simpler than having the correct value be in /etc/modules.d/50-gpio-cs5535 Oct 04 03:40:40 the ultimate goal is eliminating the subtarget for geos, there's no real need for that Oct 04 03:40:56 no subtarget implies shared repostitory with other generic boards Oct 04 03:41:05 shared repository implies generic kmods Oct 04 03:41:19 generic kmods imply no board specifc options in the packages Oct 04 03:41:51 of course its easier to build a specifc image with stuff hardcoded in but from a distribution pov its a pita Oct 04 03:42:42 and to me the mask thing is just another kind of board specific initialisation Oct 04 03:43:04 you're saying "it's all generic", but you're jumping through hoops to sweep the stuff that isn't generic under the carpet. Oct 04 03:43:26 so it's not really generic at all. it's just that the specifics are stuffed away in obscure places. Oct 04 03:44:41 generic means to me you can use an x86 release image and it will run Oct 04 03:44:58 its really overkill to have a subtarget just to not autoload three modules and add a param to another Oct 04 03:46:17 and the obscure places are runtime detection in constrast to build time switches as you prefer Oct 04 03:51:18 and a three line shell snippet that fixes up the module param, makes a generic x86 usable and is even editable by a user at runtime is far simpler than an extra subtarget which requires recompiling hundreds of megabytes of software, separate kernel, separate repositories, separate config and extra buildroot support code Oct 04 04:02:36 xMff: well, when I get everything else working, I'm going to add a "leds" module for the platform in base-files. Oct 04 04:02:56 another option not investigated yet Oct 04 04:03:18 a common way to differentiate runtime configs, for example on ar71xx, is to patch the kernel commandline Oct 04 04:03:37 so all board specific images are created from the same binaries but with different kernel cmdlines embedded Oct 04 04:03:49 yeah... I was asking about that. apparently it's non-trivial. Oct 04 04:03:50 in the case of x86 its even easier, we use grub with menu.lst there Oct 04 04:04:02 one coulst just add gpio-cs5535.mask=0x... there Oct 04 04:04:18 to the bootloader cmdline, the it wouldn't even matter if the module is builtin or external Oct 04 04:05:53 there is also CONFIG_X86_GRUB_BOOTOPTS already Oct 04 04:25:36 here's an untested example: http://paste.tksite.gotdns.org/d20d20db6 Oct 04 04:30:23 this one makes more sense, no need for vdi and vmdk images: http://paste.tksite.gotdns.org/d2a604108 Oct 04 04:31:49 image would be called openwrt-x86-generic-geos-combined-ext2.img and has another cmdline embedded Oct 04 05:00:17 xMff: is there a simple way to shim in a rule to make changes to a module's config file after installation? Oct 04 05:01:24 what kind of config? Oct 04 05:05:57 the /etc/modules.d/50-gpio-cs5535 file. Oct 04 05:08:01 $topdir/files/etc/modules.d/50-gpio-cs5535 Oct 04 05:08:18 create that and put your contents in there Oct 04 05:19:01 I tried that but it turns out that those files are copied too early, and get overwritten. Oct 04 05:19:26 also, I don't want to have a complete replacement of the file... because then it might get out of date. Oct 04 05:19:39 easier just to make a simple edit to the file that the scripts build. Oct 04 05:26:34 I have no solution for that, you need to hack the makefiles, or implement the image soultion I posted earlier Oct 04 05:29:29 I can hack the makefile, just not sure what the steps are and what happens where. Oct 04 05:30:22 you can try to define a postinst section containing shell code Oct 04 05:33:19 and where does that happen? Oct 04 05:35:36 during opkg install, either on target or during build Oct 04 05:35:42 no, wait... you mean the postinst that happens at run-time? no, I want to do something at build time in the published image. Oct 04 05:35:59 buildroot uses opkg, as does the target Oct 04 05:36:33 I saw the postinst stuff in ModuleAutoLoad. Oct 04 05:36:52 why are you so focused on hacking up the module file btw? I presented four different, imo easier approaches Oct 04 05:37:26 well, not my beer Oct 04 05:42:02 "not my beer"? Oct 04 05:42:17 badly translated figure of speech :P Oct 04 05:42:21 ah. Oct 04 05:43:05 well, I figure that myself and 98% of the planet (ok, 98% of the folks on the planet that now how to configure Linux) expect to have the options in /etc/modules.d/ file. Oct 04 05:44:39 the problem with putting it in the grub.conf file is that's editable. nothing beats putting it in a read-only squashfs image. Oct 04 05:44:55 $ ls /etc/modules.d/ Oct 04 05:44:55 ls: cannot access /etc/modules.d/: No such file or directory Oct 04 05:44:57 :P Oct 04 05:45:06 seems I'm in the other 2% Oct 04 05:45:17 what platform are you on? Oct 04 05:45:25 ubuntu Oct 04 05:45:36 it's /etc/modprobe.d/ on a lot of other systems. Oct 04 05:46:28 not sure where ubuntu puts it. I use Fedora. Oct 04 05:48:57 if you are making a custom image anyways, there is a much easier way Oct 04 05:48:57 I still don't follow but thats ok. If you want to make everything r/o whats the point of having it in /etc then? Oct 04 05:49:09 just make another ipk file that has the changes you want, include it in the image Oct 04 05:49:16 and it'll end up in the squash file system Oct 04 05:49:25 voila, problem solved, no need to touch the generic stuff Oct 04 05:50:35 its 'just another package' that you have included in the initial file system Oct 04 05:53:32 was trying to do something like http://pastebin.ca/1953841 Oct 04 05:54:08 groz: isn't that sort of abusing the ipkg mechanism? Oct 04 05:54:24 that's the whole point of a modularized package system Oct 04 05:54:29 and how do you make sure that the ipkg's are handled in the right order? Oct 04 05:54:30 so you can make custom packages Oct 04 05:54:33 I do it all the time Oct 04 05:55:02 i have stuff that I want in that'll replace something in base-files, example, a default password file Oct 04 05:55:16 so, i create a new package, with my pre-built passwd file in it Oct 04 05:55:17 have a look at the link for what I'm trying to do. Oct 04 05:55:21 make it dependant on base-files Oct 04 05:55:22 and voila Oct 04 05:55:33 the root build will install it after base-files Oct 04 05:55:40 and now when i flash a fresh unit Oct 04 05:55:49 it has the passwords I want in the squash Oct 04 05:56:20 that's handy... I just wish there was a cleaner way to do that without the ipkg mechanism. Oct 04 05:56:50 to do what you want, it would be much easier (my opinion) to just create a package with an init script in it Oct 04 05:57:04 nothing else, just /etc/init.d/myinitscript Oct 04 05:57:29 tell it to execute after modules are loaded Oct 04 05:57:37 then it can just echo xxxx >> /someplace Oct 04 05:57:49 and your problem is solved, script will run every time Oct 04 05:57:54 groz: the assumption that you and felix are making is that without the proper initialization, I can get far enough to even execute that script. Oct 04 05:58:05 and you can do it without touching the root build at all Oct 04 05:59:20 if you cant get far enough to execute a script, maybe you need to fix the driver itself then Oct 04 05:59:27 also, if I boot single-user... and from the console prompt do a "modprobe module" I want it to load it with the right arguments... oh, wait. no modprobe. only insmod. never mind. Oct 04 06:00:29 so the /post-install patch? Oct 04 06:01:03 I'd do it different Oct 04 06:01:11 I'd just create a new package for the module Oct 04 06:01:21 and include the parameter stuff right in there Oct 04 06:01:28 and, if it cant boot far enough to do that Oct 04 06:01:29 post-install is not a good name Oct 04 06:01:34 I'd go into the kernel sources and fix the module Oct 04 06:01:34 there is postinstall already Oct 04 06:02:42 but in the example you give Oct 04 06:02:51 i would't try make it graft onto the existing module Oct 04 06:03:02 just make a new package, that when it installs into the root file system Oct 04 06:03:13 makes the mod you want to the modules.d file in question Oct 04 06:03:24 a package that leaves no files int he file system Oct 04 06:03:33 just executes its install routine Oct 04 06:03:36 groz: thats not his goal Oct 04 06:03:46 and, when you include it in the image, it'll 'fix the image' Oct 04 06:03:58 and, if the kernel cant get far enough to load the module that way Oct 04 06:04:06 then you go to the kernel sources, and fix the kernel Oct 04 06:05:37 what i'm seeing in the pastebin, will just add the maks parameter Oct 04 06:05:56 and that can be done with a separate package, that does nothing more than add the mask parameter Oct 04 06:06:02 during the file system creation Oct 04 06:07:25 another way to kludge it, same concept Oct 04 06:07:36 it's modifying ??=gpio-cs5535 Oct 04 06:07:42 assume for a minute, ?? = 40 Oct 04 06:08:05 just add another file in, call it 39-gpio-cs5535, and have the parms in there Oct 04 06:08:15 when 40 is reached, module is already loaded, with parameters Oct 04 06:08:29 and 40 gets ignored, or more properly, fails, and the system carries on Oct 04 06:11:43 I actually do that for one image here, I need to pass parms to usbserial to make it recognize one 3g stick i have here Oct 04 06:12:09 I dont fuss with modifying the basic stuff, just created a package that puts a new file in modules.d, that loads before the original Oct 04 06:12:18 and loads the module in question with the parameters neeeded Oct 04 06:12:54 bit of a kludge, works well, and doesn't require me to touch the build environment structure to get that device up and running Oct 04 06:14:27 maybe not a technically correct purist solution, but, the errors are safely sent to /dev/null on a box that has no console to see them Oct 04 06:14:36 and the box runs correctly with that kludge in place Oct 04 06:14:42 so, works for me, and good enuf for me Oct 04 06:26:35 problem here is I have to know the current priority... and if that changes, things break. Oct 04 07:43:48 lars * r23213 /trunk/ (6 files in 6 dirs): [kernel] update 2.6.35.x to 2.6.35.7 Oct 04 09:07:38 lars * r23214 /trunk/target/linux/kirkwood/config-default: [kirkwood] Remove hwmon and i2c support from being built-in Oct 04 09:17:30 lars * r23215 /trunk/package/kernel/modules/i2c.mk: Oct 04 09:17:31 [packages] kernel: kirkwood/orion I2C module support Oct 04 09:17:31 This patch adds support for configuring kirkwood/orion i2c module. Oct 04 09:17:31 Signed-off-by: Wojciech Dubowik Oct 04 09:19:10 lars * r23216 /trunk/package/kernel/modules/hwmon.mk: Oct 04 09:19:10 [packages] kernel: Add hwmon-lm63 package Oct 04 09:19:10 Signed-off-by: Wojciech Dubowik Oct 04 09:21:11 lars * r23217 /trunk/target/linux/kirkwood/ (3 files in 3 dirs): Oct 04 09:21:11 [kirkwood] Iomega iConnect Wireless platform support Oct 04 09:21:11 This patch adds support for Iomega iConnect Wireless. Leds and wireless card Oct 04 09:21:11 support are still missing. Oct 04 09:21:11 Signed-off-by: Wojciech Dubowik Oct 04 09:51:21 lars * r23218 /trunk/package/uboot-kirkwood/Makefile: Oct 04 09:51:21 [packages] uboot-kirkwood: Add support for iomega iconnect wireless Oct 04 09:51:21 Signed-off-by: Wojciech Dubowik Oct 04 10:00:10 http://downloads.openwrt.org/sources/mtd-20101002.tar.gz Oct 04 10:00:14 is missing... Oct 04 10:07:01 nunojpg: install git Oct 04 10:11:25 me and everyone else... Oct 04 10:19:54 ^- thats what i said Oct 04 10:20:13 so i just reverted to the previous revision for now. Oct 04 10:22:37 KanjiMonster: what kind of help is that ? :) Oct 04 10:22:52 KanjiMonster: look at wiki and read install instructions and then rethink that answer :D Oct 04 10:23:35 we should find someone with mirror access that can upload the missing file Oct 04 10:24:27 ^ i asked the wrong person Oct 04 10:27:11 r22475 still have a console ; r22757 no console Oct 04 10:27:13 blogic: if it isn't found as a tar, it's checked out from the git repository Oct 04 10:27:30 but of course, this only works if git is installed Oct 04 10:27:33 i get nvram corruptions on all of those though Oct 04 10:27:45 i see Oct 04 10:27:49 soz then Oct 04 10:29:22 (in case of debian, git-core is also needed) Oct 04 10:29:50 diag: Router model not detected. (/me presumes that's what's behind the entire disaster) Oct 04 10:37:17 blogic, i vote for your idea. Oct 04 10:41:57 kaloz * r23219 /trunk/ (26 files in 26 dirs): [kernel]: upgrade kernel versions to the latest stable ones Oct 04 11:05:59 KanjiMonster: It works, but I guess git should be the backup and not the default, there should be a mirror available... Oct 04 11:08:02 nunojpg: there will be Oct 04 11:08:15 yeah, git isn't exactly lightweight ;) Oct 04 11:12:52 nice, thanks Oct 04 11:15:29 russell_: mh.. I had that once too and it was fixed (broadcom-diag) but my serial console didn't disappear AFAIR Oct 04 11:18:34 loswillios: probably depends on the device; most (all?) bcm47xx devices have two serials and probably most use the first one, while (iirc) the wrt634u uses the second one Oct 04 11:20:12 wgt634u here Oct 04 11:33:08 russell_, , have you located your device in diag.c? Oct 04 12:02:45 build #3 of at91 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/3 Oct 04 12:23:17 kaloz * r23220 /trunk/toolchain/gcc/ (Config.in Config.version common.mk patches/4.4.5/): [toolchain]: gcc 4.4.5 support Oct 04 14:06:13 why do I get this error when I try to compile a package: cc1plus: error: unrecognized command line option "-fhonour-copts" Oct 04 14:08:04 which gcc version? Oct 04 14:09:08 the one shipped with openwrt trunk (4.1.2 i think) Oct 04 14:12:02 Try a newer one Oct 04 14:14:29 I want to create a package for openwrt vanilla not for a custom build Oct 04 14:17:44 if i remove the TARGET_CFLAGS+= -fhonour-copts line from rules.mk everything seems to work fine. How can I override that option from within my Makefile Oct 04 14:17:48 ? Oct 04 14:20:45 I'd just consider 4.1 to be broken. Upgrade to a newer version. Oct 04 14:20:58 hamvil: 4.1.2. isn't used in trunk anymore, the oldest now is 4.2.4, most use 4.3.x, some even 4.4 Oct 04 14:21:55 uhm, then I'm doing something really wrong. where do I select the gcc version to be used? Oct 04 14:23:24 in build_dir I have the following directory toolchain-i386_gcc-4.1.2_uClibc-0.9.30.1 Oct 04 14:25:56 sorry, my mistake; I didn't check that there are targets which aren't defined there Oct 04 14:26:12 in the Config.version, which then get the 4.1.2 version assigned Oct 04 14:26:38 where is Config.version? Oct 04 14:32:06 ok, found. Trying with 4.4.4 Oct 04 15:11:57 the x86 target compiles with success using default settings Oct 04 15:23:31 can someone take a look at tell me if they think there are any issues with this? as an addition to the ar71xx makefile.. Oct 04 15:23:33 http://www.pastie.org/private/pbgf6fxhcjazdgrmynyhoq Oct 04 15:24:58 not sure about the spi0.0 bit, and the mtdparts segment could easily be wrong Oct 04 15:33:44 i'm now using gcc 4.4.4 but I still get this error: cc1plus: error: unrecognized command line option "-fhonour-copts" Oct 04 15:34:16 the only extra flag I'm using is: EXTRA_CFLAGS=-MD Oct 04 15:36:36 this is the full output: http://pastebin.com/Y6QUb2kX Oct 04 15:39:23 hamvil: Did you make a dirclean? Oct 04 15:39:30 yes Oct 04 15:39:56 it is actually a new checkout Oct 04 15:42:49 hamvil: Please change the packages build to verbose build (usually V or VERBOSE flag) Oct 04 15:43:34 mb__: the output that I've provided is the one produce with make V=99, to which flag are you referring to> Oct 04 15:43:52 No I mean the actual package build Oct 04 15:44:24 It must have a flag to display the actual gcc commands being executed Oct 04 15:46:08 mb__: ok got it, running with V=1 Oct 04 15:46:28 mb__: g++ -DHAVE_CONFIG_H -I../../include -I../../include -I. -I/home/rriggio/src/kamikaze/staging_dir/target-i386_uClibc-0.9.30.1/usr/include -I/home/rriggio/src/kamikaze/staging_dir/target-i386_uClibc-0.9.30.1/include -I/home/rriggio/src/kamikaze/staging_dir/toolchain-i386_gcc-4.4.4_uClibc-0.9.30.1/usr/include -I/home/rriggio/src/kamikaze/staging_dir/toolchain-i386_gcc-4.4.4_uClibc-0.9.30.1/include -DCLICK_TOOL -O2 -pipe -march=i486 -funit-at-a-t Oct 04 15:46:30 ime -fhonour-copts -MD -c ../../lib/string.cc -o string.bo Oct 04 15:47:12 So it invokes the host g++. Oct 04 15:48:02 uhm right, i did not realize Oct 04 15:48:16 If that's desired, you should not pass any target opts Oct 04 15:49:14 the opts are passed by openwrt according to the option specified in rules.mk Oct 04 15:49:26 Well, it depends on your makefile. Oct 04 15:49:37 my makefile is very simple: Oct 04 15:49:38 To me it seems you package's makefile has some cross compile bugs Oct 04 15:49:41 CONFIGURE_ARGS += \ Oct 04 15:49:43 --enable-userlevel \ Oct 04 15:49:45 --enable-wifi \ Oct 04 15:49:47 --enable-wing \ Oct 04 15:49:49 --disable-linuxmodule \ Oct 04 15:49:50 I mean the package's makefile Oct 04 15:49:51 --disable-dynamic-linking \ Oct 04 15:49:55 define Build/Compile Oct 04 15:49:57 $(call Build/Compile/Default, tools elementmap.xml V=1) Oct 04 15:49:59 endef Oct 04 15:50:01 i will check the upstream makefile Oct 04 15:50:21 sorry I have to run to catch a train, bye Oct 04 15:50:26 cu Oct 04 15:54:07 mb__: don't suppose you could have a look at the pastie link i mentioned? Oct 04 16:08:38 EqUaTe: I'm afraid I'm the wrong person to look at this, as I don't know the device. Oct 04 16:10:15 i'm more looking for a sanity check Oct 04 16:10:20 i don't think many people have wnr2000's :) Oct 04 16:10:44 ootb, it has a rather annoying checksum feature on every boot.. KanjiMonster is helping me work out how to bypass it w/o modifying uboot Oct 04 16:10:54 or rather, he's helping me try to Oct 04 16:11:05 if successful, i'll be submitting patches for it.. :) Oct 04 16:56:26 acoul * r23221 /trunk/target/linux/generic/patches-2.6.36/511-yaffs-git-2010-10-01.patch: Oct 04 16:56:26 yaffs2: add preliminary 2.6.36 kernel support (sync to yaffs2 git tree). This code needs further testing especially for backwards compatibility. It boots on rb532 with Oct 04 16:56:26 kernel options: CONFIG_DEVTMPFS & CONFIG_DEVTMPFS_MOUNT Oct 04 17:22:08 jow * r23222 /trunk/include/package-ipkg.mk: [include] correct default package status info (install -> unknown) - fixes "opkg_conf_write_status_files: Internal error: package ... has a NULL dest" Oct 04 17:24:07 jow * r23223 /branches/backfire/include/package-ipkg.mk: [backfire] merge r23222 Oct 04 17:46:24 acoul * r23224 /trunk/target/linux/adm5120/ (16 files in 3 dirs): linux/adm5120: add preliminary 2.6.36 kernel support (refresh patches) Oct 04 17:49:13 obsy * r23225 /packages/net/transmission/ (Makefile files/transmission.config files/transmission.init): [packages] transmission: update to 2.10b1, add new option, lower default message level Oct 04 18:41:57 http://www.pastie.org/private/pbgf6fxhcjazdgrmynyhoq <-- anyone able to take a look at this and tell me if it looks alright, or if there's anything obviously wrong with it? Oct 04 19:02:17 EqUaTe: it looks sane Oct 04 19:02:26 excellent Oct 04 19:03:03 this is the stock bootargs: bootargs=console=ttyS0,115200 root=31:02 init=/sbin/init mtdparts=ar7100-nor0:256k(u-boot),64k(u-boot-env),2304k(rootfs),64k(user-config),1152k(uImage),128k(language_table),64k(rootfs_checksum),64k(ART) Oct 04 19:03:08 (hopefully that all came through) Oct 04 19:03:23 i mentioned earlier, i'm not sure about the spi line in the mtdlayout definition Oct 04 19:03:28 spi segment* Oct 04 19:06:48 EqUaTe: the flash is always on spi 0.0 (afaik the spi flash controller of ar71xx supports only having the flash there) Oct 04 19:06:55 ah ok Oct 04 19:07:17 so what does the root=31:02 bit mean then? i guess :02 is for the partition of the mtd, but where does 31 come from? Oct 04 19:07:43 major and minor number of the root device iirc Oct 04 19:08:02 ok. so that should be the same regardless? Oct 04 19:08:58 31 is mtdblock Oct 04 19:09:06 02 the second partition Oct 04 19:09:12 so /dev/mtdblock2 Oct 04 19:09:13 cool. i now know several bits i didn't before :) Oct 04 19:09:15 sounds correct Oct 04 19:09:34 you can check ls -lh /dev on another router Oct 04 19:09:40 * EqUaTe goes to check what he needed to adjust next Oct 04 19:09:42 it will print the numbers Oct 04 19:10:12 just booted that one into stock.. Oct 04 19:10:30 yup Oct 04 19:15:49 build #3 of etrax is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/3 Oct 04 19:27:55 well, i think that's the patching done.. time to set the build up.. Oct 04 20:10:16 [florian]: is there anything i can do to help along fixing the breakage on wgt634u that started in r22296? Oct 04 20:20:16 build #3 of octeon is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/octeon/builds/3 Oct 04 20:44:27 hauke * r23226 /trunk/target/linux/generic/ (3 files in 2 dirs): kernel: fix some build warnings with kernel 2.6.36 Oct 04 21:27:11 acinonyx * r23227 /trunk/package/qos-scripts/files/usr/lib/qos/generate.sh: [package] qos-scripts: Fix generation of IMQ firewall rules on halfduplex mode (#7800) Oct 04 21:27:53 lars * r23228 /trunk/package/uboot-kirkwood/ (10 files in 4 dirs): Oct 04 21:27:53 [packages] uboot-kirkwood: Update to uboot to 2010.09 Oct 04 21:27:53 (and add missing files from pervious commit) Oct 04 21:34:29 lars * r23229 /trunk/ (2 files in 2 dirs): [packages/kernel] Make mv_cesa crypto module available on Orion as well. Oct 04 21:41:58 hrm.. i presume if i've added the wnr2000 profile correctly, it should show up as an option in make menuconfig in the profiles bit? Oct 04 21:44:47 .oO(will never understand, why people are so profile-maniac) Oct 04 21:45:13 Kaloz: mostly i'm just making sure i have everything set right for building an image for the wnr2000. Oct 04 21:46:16 that's just ar913x with no extra stuff if I recall right Oct 04 21:46:41 are the profiles in the menu specific to the drivers it needs? Oct 04 21:47:29 well, profiles are for selecting what packages to be included in the firmware Oct 04 21:47:44 ok. well, i do want to set that.. Oct 04 21:47:58 sure thing, just noting that for that unit you hardly need a new profile Oct 04 21:47:59 because if this works, i want it to be valid for the device for others to build.. Oct 04 21:48:15 you only need one which has ath9k plus wpad-mini for example Oct 04 21:49:32 on ar71xx (and on some other targets) the profiles are simply overkill Oct 04 21:49:55 (eg. there are like 10 profiles selecting exactly the same packages) Oct 04 21:50:54 right.. Oct 04 21:50:55 i thought they mostly tagged the .uni for factory firmware flashing Oct 04 21:51:52 Weedy: anything related to image generation should happen in target/linux/foo/image/ Oct 04 21:52:46 i know that the wndr3700 and tewbrp profiles i use tag my factory.bin.uni properly Oct 04 21:53:02 but yeah same packeage set Oct 04 21:54:06 Weedy: the generic profile should tag those correctly as well Oct 04 21:54:41 wait i think i'm confusing target for profile Oct 04 21:59:36 Kaloz: if i've got a template, do i not need a profile to ensure the build uses it correctly? Oct 04 22:01:04 i don't understand what you mean by template. you can simply copy an existing profile and edit it, and it should show up in menuconfig Oct 04 22:01:46 like the stuff in this patch: https://dev.openwrt.org/changeset/23138/trunk/target/linux/ar71xx Oct 04 22:01:56 only somewhat more complex than that Oct 04 22:03:19 i've added the WNR2000 stuff into both netgear.mk and the image Makefile, but it doesn't show up in menuconfig Oct 04 22:07:10 so.. after editing these files.. do i need to do anything to get the menu to rebuild? Oct 04 22:07:57 theoritically no. you can try to remove the tmp dir, tho Oct 04 22:08:32 be back later, have to sleep Oct 04 22:08:49 yeah, i need to as well.. going shortly :-/ Oct 04 22:09:36 yup, removing tmp worked Oct 04 22:10:02 thanks Kaloz. sleep well Oct 04 22:10:56 that was weird. Oct 04 22:11:23 ? Oct 04 22:13:57 my other session coming and going. must be a partial partition of freenode. Oct 04 22:14:09 it was a ping timeout Oct 04 22:14:37 yeah, but that machine has been up and reachable the whole time. I've been on it. Oct 04 22:14:55 that doesn't make it a partial partition of freenode Oct 04 22:15:26 more likely an issue with that particular session, or a routing blip between that box and the server it's connected to Oct 04 22:15:45 I'll go with door #2. Oct 04 22:15:54 on the other hand, quite a few people also timed out at the same time Oct 04 22:15:57 with the same length Oct 04 22:16:23 so i'd say almost certainly a routing issue on 'tinternet Oct 04 23:43:47 build #3 of kirkwood is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/kirkwood/builds/3 Oct 04 23:43:54 build #3 of iop32x is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/iop32x/builds/3 Oct 05 00:35:15 build #2 of ubicom32 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/2 Oct 05 01:42:33 build #2 of ps3 is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/2 **** ENDING LOGGING AT Tue Oct 05 02:59:57 2010