**** BEGIN LOGGING AT Sun Mar 28 02:59:56 2010 Mar 28 03:29:24 nico * r20533 /trunk/ (2 files in 2 dirs): ps3: move ps3lan kmod under target/linux/ps3 Mar 28 03:45:46 nico * r20534 /trunk/target/linux/ifxmips/nfs/ (config-2.6.26 config-2.6.27): ifxmips: remove old config files Mar 28 04:45:19 build #40 of ep93xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/40 Mar 28 06:27:03 swalker * r20535 /packages/ (41 files in 41 dirs): [packages] use xorg-libraries as the section definition for Xorg libraries Mar 28 06:35:04 swalker * r20536 /packages/Xorg/xorg/font/font-misc-misc/Makefile: [packages] font-misc-misc: fix stray xorg-fonts section definition Mar 28 07:16:29 juhosg * r20537 /trunk/package/mtd/ (Makefile src/fis.c): package/mtd: fix automatic partition size detection in fis_remap Mar 28 10:12:09 build #32 of rdc is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/rdc/builds/32 Mar 28 11:02:44 nbd https://dev.openwrt.org/attachment/ticket/6933/mmc_over_gpio.diff Mar 28 11:02:50 nbd can you apply this patch? Mar 28 11:38:54 nbd sleeping? Mar 28 11:55:10 florian * r20538 /trunk/target/linux/x86/base-files/lib/upgrade/platform.sh: [x86] sysupgrade: Get target device from kernel cmdline, patch from acinonyx Mar 28 11:55:23 <[florian]> dogge10: are not there any defaults for these gpio lines? Mar 28 11:55:39 <[florian]> dogge10: forget what I said Mar 28 13:21:58 florian * r20539 /packages/net/netatalk/ (6 files in 2 dirs): [package] add uams libraries, configuration file and init script (#6965) Mar 28 13:22:00 florian * r20540 /packages/net/freeradius2/Makefile: [package] workaround missing symlinks for freeradius2 libraries (#6344) Mar 28 13:22:02 florian * r20541 /packages/ipv6/radvd/Makefile: [package] update radvd to 1.6 Mar 28 13:23:06 florian * r20542 /trunk/package/mmc_over_gpio/ (Makefile files/mmc_over_gpio.config): [package] make mmc-over-gpio pins configurable in menuconfig (#6933) Mar 28 14:36:59 <{Nico}> swalker: ping Mar 28 14:55:06 nico * r20543 /packages/net/ucarp/Makefile: [packages] ucarp: add dependency on ip instead of messing with busybox default config (closes: #6968), bump release number Mar 28 16:58:19 florian * r20544 /packages/net/ipsec-tools/ (Makefile patches/004-opennhrp.patch): [package] add GRE support to ipsec-tools, so that opennhrp can work (#6926) Mar 28 16:58:21 florian * r20545 /packages/net/yaddns/ (. Makefile): [package] add yaddns, patch from rhk Mar 28 16:59:03 ping [florian] Mar 28 16:59:13 <[florian]> cshore: pong Mar 28 16:59:56 yet another ddns package :( Mar 28 17:00:03 isn't ddns-scripts enough? Mar 28 17:00:11 apparently not Mar 28 17:00:57 For brcm63xx, which do you think of modifying the board detection logic so that we emit a more specific boardid, based on boardid and MAC OUI, so that we can better deal with the different routers? Mar 28 17:02:03 Then we define the boards as usual in the boards .c Mar 28 17:02:19 only board=router not reference design Mar 28 17:03:21 dogge10: ddns-scripts would only be enough if it always worked for all ddns Mar 28 17:04:30 florian * r20546 /packages/net/netatalk/ (Makefile patches/ patches/001-cross_compile.patch): [package] downgrade netatalk to 2.0.5 (#6965, #6619) Mar 28 17:05:09 cshore: is there a way to read the imagetag from within the current running system on brcm63xx ? Mar 28 17:05:31 cshore: this would be useful to implement some kind of image name suggestion Mar 28 17:05:58 cshore: wanted to update the gw6000 yesterday and forgot what image to use ;) Mar 28 17:06:26 xMff: hmmm...you mean e.g. a static binary to run on stock firmware? Mar 28 17:06:33 <[florian]> cshore: I think it is pretty clear, you define a gw6000 board, which must match on a speficic OUI Mar 28 17:06:55 <[florian]> cshore: so the "finding" order is: Mar 28 17:07:12 cshore: no, only for openwrt, so that sysupgrade could state: please flash a openwrt-xyz-squashfs.img where xyz is the imagetag hex id Mar 28 17:07:26 xMff: oh I see, hmmm....not at present, but it wouldn't be diffult. mtd can read the mtd, and I'm adding imagetag support for the crc fuxup right now Mar 28 17:08:28 cshore: you are messing around with the writesite trx crc fixup of mtd? Mar 28 17:09:04 xMff: I can add it to mtd since I'm already adding the bcm_tag.h header there Mar 28 17:09:17 rtz: copying and modifying Mar 28 17:09:21 <[florian]> cshore: do not duplicate the header if we do not need to ;) Mar 28 17:09:39 cshore: would be nice, then we could use that in the platform.sh to suggest a specific image if the provided one is wrong Mar 28 17:09:43 [florian]: well if there's a way to use the one from the kernel, let me know Mar 28 17:09:54 nbd * r20547 /trunk/package/hostapd/ (Config.in Makefile): hostapd: clean up openssl tls dependencies and build handling (fixes #6572) Mar 28 17:10:04 <[florian]> cshore: -I ../../.. until you find your way back to the brcm63xx sources Mar 28 17:10:13 <[florian]> which will not move after all Mar 28 17:10:17 cshore: maybe it would be helpful, if this could mesh better with the fixtrx command in mtd Mar 28 17:10:23 right, ok Mar 28 17:10:35 rtz: too different Mar 28 17:11:35 rtz: imagetag is much more complex beast Mar 28 17:12:28 rtz: so I'm adding an fiximagetag command Mar 28 17:12:34 mtd fiximagetag Mar 28 17:12:41 cshore: imagetag? Mar 28 17:13:09 rtz2: brcm63xx using a format known as imagetag Mar 28 17:13:15 rtz2: not trx Mar 28 17:13:16 cshore: ahh, ok Mar 28 17:13:52 cshore: I thought you would modify the trx write Mar 28 17:14:11 rtz: I'm taking hints from it Mar 28 17:14:43 rtz: but imagetag is more of PITA than trx Mar 28 17:14:52 they should have the same command name at least Mar 28 17:15:55 xMff: we need a way to tell which format to use then Mar 28 17:16:43 cshore: problem is the trx fixup on the write-side checksums a different area then fixtrx command as far as I can see Mar 28 17:16:54 rtz2: that's right Mar 28 17:17:23 rtz: we need to read the linux partition offset 0 for the imagetag Mar 28 17:18:35 rtz: and I believe you need offset 32? Mar 28 17:18:54 you=trx Mar 28 17:19:06 cshore: it's configureable Mar 28 17:19:13 cshore: and most devices also use 0 Mar 28 17:19:51 cshore: only the wrt160nl only writes the image together with the imageheader other routers strip off Mar 28 17:20:52 cshore: but the fixtrx command checksums the rest of the eraseblock, the write side something else Mar 28 17:21:29 rtz2: well for the imagetag I use a CRC on the imagetag type to verify it's a valid imagetag type, so the command could check if it's a valid imagetag, and if not, if it's a valid trx Mar 28 17:21:34 (via magic) Mar 28 17:21:52 rtz: then dispatch to the appropriate fixup Mar 28 17:22:36 maybe mtx fixheader or something Mar 28 17:22:43 mtd fixheader I mean Mar 28 17:23:23 cshore: by write side, I mean the mtd write command, it seems to fix up the trx during writing as far as I can see Mar 28 17:23:55 rtz2: your fixup? Mar 28 17:24:25 cshore: no, that was already there Mar 28 17:25:06 rtz: oh, well I'm not using trx.c at all Mar 28 17:25:21 rtz: it's not relevant to imagetag Mar 28 17:25:25 cshore: but maybe it's smarter to remove the fixup in the mtd write path, it's not actually needed and only makes things more complicated Mar 28 17:26:01 rtz2: are you sure it's not used by anything? Mar 28 17:27:08 rtz: it doesn't interfere with imagetag for sysupgrade Mar 28 17:33:04 cshore: well, it is used at the moment, but the running the fixup on the firstboot is unavoidable anyway, so one may as well remove it from the write path Mar 28 17:33:04 [florian]: erm: when building mtd I would have to -I../linux-2.6.30.10/include/... Mar 28 17:33:45 [florian]: how do I do that without hardcoding the linux version (so that I can use the bcm_tag.h) Mar 28 17:33:48 cshore: what do you need the linux include for? Mar 28 17:34:34 rtz: for the imagetag head...florian doesn't want it duplicated if possible (because then it's another place to update if it changes) Mar 28 17:35:07 imagetag header I mean Mar 28 17:35:39 rtz: it's already in the kernel sources Mar 28 17:35:48 cshore: well, it's at least in 2 places right now, but I suspect it will still be easier to copy it Mar 28 17:36:41 rtz: actually the only other place it is right now is the firmware-tools Mar 28 17:37:15 rtz: and I'd like to get rid of that duplication too Mar 28 17:38:14 cshore: well, maybe keep it there (you know the path for it) and change the kernel one into a symlink or so Mar 28 17:38:49 rtz: the problem is getting it from the build_dir Mar 28 17:39:53 cshore: well, $(TOPDIR)/tools/imagetools/imagetag.h? Mar 28 17:40:08 or whatever the exact path is Mar 28 17:40:58 rtz: hmmmm....that's kind of ugly I think....I'd rather keep the header in the cross-compiling tree Mar 28 17:41:34 cshore: or simply symlink it in mtd Mar 28 17:42:05 cshore: it won't even be noticable, that it's actually only one file Mar 28 17:42:41 cshore: add a symlink to ../../../tools/firmware-utils/src/bcm_tag.h to mtd Mar 28 17:42:52 rtz2: hmmm....I could do that....but I want florian's opinion....it seems wrong somehow Mar 28 17:44:05 ping [florian] Mar 28 17:44:07 cshore: well, messing around in the build_dir seems wrong to me, but I guess it's a matter of taste Mar 28 17:45:09 <[florian]> cshore: pong Mar 28 17:45:35 [florian]: what do you think for the bcm_tag.h....how should I access it for mtd? Mar 28 17:45:36 <[florian]> cshore: you do not have to hardcode the version Mar 28 17:45:49 <[florian]> cshore: just extract bcm_tag.h from a patch as a separate file and voila Mar 28 17:46:28 [florian]: I don't follow Mar 28 17:47:26 [florian]: I have already copied it from the patch, but I thought you wanted to avoid have another copy of it Mar 28 17:47:55 [florian]; i.e. right now there is bcm_tag.h in the mtd source tree Mar 28 17:48:29 <[florian]> cshore: yes I do not want another copy of the file Mar 28 17:48:40 <[florian]> cshore: so just put bcm_tag.h in target/linux/brcm63xx/files Mar 28 17:48:42 <[florian]> which is kernel-version neutral Mar 28 17:48:47 <[florian]> and use that version your user-space tool Mar 28 17:49:20 [florian]: ok, because right now it's in a patch in the kernel tree Mar 28 17:49:30 patches-2.6.xx Mar 28 17:49:40 <[florian]> cshore: I know, that's why it me must taken out of the patch Mar 28 17:49:43 <[florian]> cshore: I can do that right now Mar 28 17:49:55 [florian]: ok , please and thank you Mar 28 17:51:41 [florian]: should I point the firmware-utils version there too? Mar 28 17:52:55 <[florian]> cshore: I do not understand Mar 28 17:52:58 <[florian]> which version? Mar 28 17:53:12 [florian]: firmware-utils has another copy of this file Mar 28 17:53:44 <[florian]> rtz2: oh ok, well, let me create a symlink to the kernel file which will remain in firmware-utils Mar 28 17:53:49 <[florian]> so that we do not have a long path Mar 28 17:53:59 <[florian]> and still, we stay in sync with the kernel version if we happen to change it Mar 28 17:54:20 [florian]: excellent. I never liked the duplication Mar 28 17:54:48 [florian]: another question Mar 28 17:54:52 <[florian]> rtz2: sure Mar 28 17:55:16 [florian]: as far as i can see, the mtd write command seems to fix up the trx header Mar 28 17:55:48 <[florian]> rtz2: yes Mar 28 17:55:48 [florian]: wouldn't it be smarter to remove this and only keep the fixup in on first boot? Mar 28 17:56:07 <[florian]> rtz2: if we do not need it later, I think so Mar 28 17:56:18 <[florian]> rtz2: but would not this cause a problem for jffs2-only fs? Mar 28 17:56:57 [florian]: he's not referring to in the kernel, only the mtd command, IIUC Mar 28 17:57:19 [florian]: actually, it doesn't matter because the trx crc also includes the deadcode marker for squashfs Mar 28 17:57:53 [florian]: so there is actually no difference between jffs2 and squashfs images Mar 28 17:58:37 rtz2: you just want to change the mtd command right path, not the kernel, right? Mar 28 17:58:40 [florian]: and the fixing up the header somewhere during the first boot is unavoidable anyway, because the vendor firmware doesn't fix it up Mar 28 17:58:49 cshore: yes Mar 28 17:59:09 <[florian]> rtz2: then yes I think you are right, doing this only once should be smarter Mar 28 17:59:43 cshore: well, actually also I want to remove the fixup from the kernel and do it with a simliar system as on the wrt160nl, but that's another question Mar 28 17:59:52 [florian]: ok, I will prepare a patch Mar 28 18:00:24 rtz2: right...that should only happen once too, actually, now that I think of it...and it's uglier Mar 28 18:03:13 [florian]: would it be possible to replace the rootfs partition length reading from imagetag with detection based on a squashfs EOF, or JFFS2 EOF (depend on the fs in use); that would allow to get rid of the imagetag union Mar 28 18:04:03 <[florian]> cshore: oh yeah, I would strongly encourage that Mar 28 18:04:56 cshore: ok, that would simplify the fixup code too, so I'll do that first Mar 28 18:05:33 cshore: why do you need the rootfs length? Mar 28 18:07:14 rtz: for the mtd partitions code Mar 28 18:07:44 cshore: in the kernel? Mar 28 18:07:48 rtz: yes Mar 28 18:08:50 ahh, ok Mar 28 18:10:00 stintel: I figured out why ppp0 and the likes do not appear in the interface choice menus Mar 28 18:10:28 rtz: the imagetag wants a rootfslength for image length, but if we can ignore that value, then for image creation we just feed the CFE and value it likes (in the imagetag), and calculate the real value for the kernel Mar 28 18:10:44 stintel: we use getifaddrs() to find all interfaces and then take every iface which has an entry with the family AF_PACKET, unfortunately stuff like tunX or pppX has no such entry Mar 28 18:11:02 rtz: it hugely simplifies things Mar 28 18:11:08 florian * r20548 /trunk/ (5 files in 4 dirs): [brcm63xx] move bcm_tag.h out of the flashmap patch so that user-land tools can re-use it Mar 28 18:11:34 stintel: will fix that in a minute. luci-statistics images should work again btw Mar 28 18:12:25 xMff: great, thanks for the feedback Mar 28 18:13:42 xMff: will that also fix the launch on boot for those types of interfaces? Mar 28 18:13:57 cshore: launch on boot? Mar 28 18:14:21 xMff: things like pptp don't like to start on boot without special work Mar 28 18:14:34 cshore: ah - nope, this is purely an ui side fix Mar 28 18:15:06 xMff: ok....I think my patch for pptp got applied, but other ppp based things have the same problem I think Mar 28 18:16:05 stintel: if you some time, can you paste me the output of: lua -lluci.util -lnixio -e 'luci.util.dumptable(nixio.getifaddrs())' ? Mar 28 18:17:39 xMff: it's on my to do list to look into it, but I'm keeping pretty busy Mar 28 18:32:53 xMff: http://openwrt.pastebin.com/fgB0JtV5 Mar 28 18:35:20 nbd * r20549 /trunk/package/madwifi/patches/462-fix_ap_scan.patch: madwifi: return to the bss channel after an issued ap mode scan has been completed (fixes #6599) Mar 28 18:35:32 stintel: thanks Mar 28 18:36:16 np Mar 28 18:36:46 ... looks like it is going to be impossible to get traffic info via getifaddrs() for such devices Mar 28 18:38:40 nbd * r20550 /trunk/package/madwifi/patches/463-fix_txrate_display.patch: madwifi: fix the tx rate display in iwconfig (#6925) Mar 28 18:47:19 xMff, like a luci-light collection with luci-admin-full instead of luci-admin-mini Mar 28 18:48:03 xMff, can you add a luci-light-full? Mar 28 18:50:02 dogge10: will look... Mar 28 18:50:15 stintel: does your ppp0 have an ip address? Mar 28 18:50:43 stintel: nvm, yes Mar 28 18:51:14 ok Mar 28 18:56:24 you think you can add such a collection quickly, xMff ? Mar 28 18:57:43 nbd * r20551 /trunk/target/linux/generic-2.6/files/drivers/net/phy/ip175c.c: enable IP175A support in the IP175C PHY driver (based on patch from jh in #6733) Mar 28 19:06:00 nbd * r20552 /trunk/target/linux/generic-2.6/ (5 files in 5 dirs): netfilter: fix ABI breakage caused by the netfilter match optimization (fixes #5628) Mar 28 19:22:06 build #32 of s3c24xx is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/32 Mar 28 19:23:02 hauke * r20553 /trunk/include/package-ipkg.mk: Mar 28 19:23:02 Some dependencies that are depending on target are not added into Mar 28 19:23:02 the Depends line in the control file of the package. Mar 28 19:23:02 For example +!(TARGET_brcm47xx||TARGET_brcm63xx):kmod-ssb does not Mar 28 19:23:02 result in kmod-ssb for the x86 target or any other target. Mar 28 19:23:03 This fixes #6874 Mar 28 20:04:52 build #32 of ramips is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/32 Mar 28 20:47:45 stintel: the ppp0 not selectable bug should be solved too now Mar 28 20:49:19 hi. I am trying to load openwrt on an ols asus wl-500g. I found some instructions on how to do that but it is tricky. Someone already made a program to load a wl-500g? Mar 28 20:57:20 xMff: are the livestats also fixed? Mar 28 20:57:33 rtz2: what was broken there again? Mar 28 20:58:36 xMff: the graph is there, but it stays flat and doesn't show any traffix Mar 28 21:00:02 rtz2: ah, yes. The RPC relied on the same datasource as the statistics, should be fixed as well Mar 28 21:00:22 also the traffic counter in the interface overview page Mar 28 21:00:29 was a bug in the getifaddrs() lua binding Mar 28 21:02:05 I'll build a new image and let you know if everything works ;-) Mar 28 21:03:04 great Mar 28 21:03:26 maybe I can finally tag 0.9.0 soon then Mar 28 21:04:25 dogge10: I added a luci-medium collection Mar 28 21:04:52 yeah, saw it :) Mar 28 21:05:27 do I need luci-sgi-uhttpd ? Mar 28 21:05:58 nope Mar 28 21:06:47 ok, building :) Mar 28 21:06:52 xMff, what about uhttpd luci frontend? Mar 28 21:06:53 I'll only support cgi for now, it is fast enough Mar 28 21:07:02 dogge10: later Mar 28 21:07:05 ok Mar 28 21:07:20 the s stands for sneller ? :P Mar 28 21:09:21 hm? Mar 28 21:10:56 what s? Mar 28 21:13:57 in sgi :) Mar 28 21:14:06 (bad joke) Mar 28 21:14:21 ah, no iz stands for server gateway interface Mar 28 21:26:47 flashing, hope it doesn't mess up like yesterday, my rspro doesn't have a reset button, annoying to tftp it :) Mar 28 21:30:07 lucky that only happened 2 or 3 times after putting it in the case Mar 28 21:30:48 xMff: luci-app-livestats + pppX --> OK Mar 28 21:31:16 xMff: luci-app-statistics graphs on webserver --> OK Mar 28 21:32:03 great Mar 28 21:32:07 xMff: and I can now also select the pppX device in the configuration part Mar 28 21:32:20 should tunX also work now ? Mar 28 21:32:24 yes Mar 28 21:32:29 it had the same kind of issue Mar 28 21:32:41 let's have a look, I'll have to enable it again first Mar 28 21:32:44 ahh crap Mar 28 21:32:46 p-t-p and pseudo ifaces in general Mar 28 21:32:59 and my endpoint went away few months ago Mar 28 21:33:10 so I'll have to setup a new tunnel to be able to test it Mar 28 21:33:29 maybe you can cheat by creating a simple ipip tunnel that points nowhere Mar 28 21:33:49 should the gcc with cs enhancements work with all platforms? Mar 28 21:34:27 rtz2: not necessarily Mar 28 21:35:14 I get an ICE in what looks like command line parsing :/ Mar 28 21:38:18 xMff: I have to set up that new tunnel anyway so might as well do it now ;) Mar 28 21:39:07 still have certs and stuff around, and already have an openwrt with openvpn running on my kvm-host in the datacenter, so it shouldnt take too long Mar 28 21:41:31 nbd * r20554 /trunk/package/ifxmips-dsl-api/ (Makefile patches/500-portability.patch): ifxmips-dsl-api: fix portability errors Mar 28 21:41:46 nbd * r20555 /trunk/package/linux-atm/Makefile: linux-atm: clean up package installation into staging Mar 28 21:41:57 nbd * r20556 /trunk/package/linux-atm/Makefile: linux-atm: add the kernel include dir to the cflags and move the build dir to $(KERNEL_BUILD_DIR) to ensure that target specific ATM API changes are included Mar 28 21:42:03 stintel: I see Mar 28 21:42:10 nbd * r20557 /trunk/package/ifxmips-dsl-control/Makefile: ifxmips-dsl-control: move to $(KERNEL_BUILD_DIR), add $(LINUX_DIR)/include to cflags Mar 28 21:44:26 hmmm, my second openvpn config is never started it seems Mar 28 21:44:48 ah, pebkac, ofcourse Mar 28 21:44:59 of course :) Mar 28 21:45:14 its the noob hat Mar 28 21:46:28 forgot tls-server, need that for cert Mar 28 21:48:24 xMff: small problem with luci-app-openvpn, it seems to add this to every config, causing trouble with >1 config (unable to bind): option 'management' '127.0.0.1 31194' Mar 28 21:48:53 stintel: oh, hmm Mar 28 21:49:35 ok my server-side config is up and running, now my rspro still Mar 28 21:55:56 nbd * r20558 /trunk/package/ (br2684ctl/Makefile ppp/Makefile): propagate atm header changes into pppoatm and br2684ctl as well Mar 28 21:58:06 xMff: would be nice if tls-server or tls-client was added as well, whenever one tries to upload a pkcs12/cert/key/ca/dh, since openvpn needs either of the two to work with tls certs Mar 28 21:58:23 stintel: good idea Mar 28 21:58:26 maybe I can have a look at it myself, now that I finished my kvm patches :) Mar 28 21:58:41 but let me get this tunnel up first ;) Mar 28 21:58:53 stintel: I need to rework this ui part anyway, I introduced real tabs a while ago, this should help a lot to unclotter the current frontend Mar 28 21:59:25 ok Mar 28 21:59:39 brb dinner Mar 28 21:59:49 ok, enjoy your meal :) Mar 28 22:00:26 now to open the port in the firewall, and I should be able to test Mar 28 22:01:38 xMff: works on tunX too, great. thanks Mar 28 22:02:40 and can also select tun0 now in the collectd config Mar 28 22:02:45 perfect ;-) Mar 28 22:05:01 mh, nmap 5.21 behaves strangely ... thats probably why owrt is still at 4.20 Mar 28 22:07:16 Mar 29 00:06:57 vr0 user.info kernel: lua[1816]: segfault at 2d194c14 ip b7784c9c sp bfd1f8a0 error 4 in liblua.so.5.1.4[b7770000+2a000] Mar 28 22:07:28 but that's on an older x86 build Mar 28 22:07:32 mirko * r20559 /packages/sound/mpd/Makefile: no need to depend on libstdcpp Mar 28 22:08:52 I'll have to update it first, still figuring out the easiest way to upgrade that x86 image without losing the settings (i've been using zcat openwrt-x86-ext2.image.gz | dd of=/dev/mapper/kvm-vr0 Mar 28 22:09:29 xMff: is there any special gcc maintainer? Mar 28 22:16:32 <{Nico}> rtz2: you mean in openwrt ? Mar 28 22:17:04 {Nico}: yes Mar 28 22:17:47 stintel: sysupgrade on x86 only works with squashfs images Mar 28 22:18:34 can I use those in e.g. kvm ? Mar 28 22:18:54 I mean, on a normal block device ? Mar 28 22:19:14 <{Nico}> rtz2: not really, it's usually arch-dependant Mar 28 22:19:40 @{Nico}: ahh crap, this means I have to figure this out myself :/ Mar 28 22:19:58 <{Nico}> rtz2: related to your ICE earlier today ? Mar 28 22:20:26 {Nico}: yep Mar 28 22:20:48 stintel: yes Mar 28 22:20:51 {Nico}: I also got some configure problem without the cs stuff in libstdc++ Mar 28 22:21:08 stintel: actually I never tried it myself but they are supposed to just work Mar 28 22:21:13 <{Nico}> rtz2: what gcc version ? Mar 28 22:21:25 {Nico}: 4.4.3 for rdc Mar 28 22:21:37 {Nico}: it's not the default version Mar 28 22:21:44 for this target Mar 28 22:21:46 <{Nico}> rtz2: i know :) Mar 28 22:22:24 {Nico}: but rdc is a i486, so there is a pretty high chance the new gcc will produce working code for it Mar 28 22:24:13 xMff: I will Mar 28 22:30:59 {Nico}: pong Mar 28 22:32:10 ah, right, I had tried that, it hangs on "Waiting for root device /dev/mtdblock0..." which I dont have so it's normal that it doesn't work Mar 28 22:33:07 hmm Mar 28 22:34:11 is there rootwait in the kernel command line? Mar 28 22:36:25 <{Nico}> swalker: https://dev.openwrt.org/changeset/20543/ Mar 28 22:36:41 xMff: there is Mar 28 22:36:52 stintel: remove it Mar 28 22:37:09 kernel panic Mar 28 22:37:16 grml Mar 28 22:37:17 cannot open root device mtdblock0 Mar 28 22:37:43 I see, so something is fucked up there Mar 28 22:38:02 maybe dd if=openwrt-x86-squashfs.image of=/dev/mapper/kvm-vr0 is not the correct way to do it ? Mar 28 22:38:14 it is Mar 28 22:39:01 is there a block2mtd argument in the kernel command line? Mar 28 22:39:06 yes Mar 28 22:39:18 block2mtd.block2mtd=/dev/vda2,65536,rootfs Mar 28 22:39:24 maybe block2mtd is not compiled into the kernel Mar 28 22:39:33 aha, let me check Mar 28 22:39:40 # CONFIG_PACKAGE_kmod-block2mtd is not set Mar 28 22:39:42 :) Mar 28 22:39:51 this won't help though Mar 28 22:39:55 ah, no Mar 28 22:40:00 indeed, it needs to be in kernel Mar 28 22:40:08 you need it inside the kernel, or have some initrd stuff Mar 28 22:40:19 nbd * r20560 /trunk/package/uboot-ifxmips/patches/001-portability.patch: uboot-ifxmips: fix portability bug Mar 28 22:40:28 I'd say add it to the kernel config and blicklist the kmod for the kvm target Mar 28 22:40:33 *blacklist Mar 28 22:40:34 nbd * r20561 /trunk/package/uboot-lantiq/ (48 files in 15 dirs): add uboot-lantiq (based on a patch contributed by Lantiq) Mar 28 22:40:38 yeah I avoided initrd, had been thinking to use it for some of the xen stuff Mar 28 22:40:48 but I rather put it in the config-default of the profile Mar 28 22:40:53 so it's just in-kernel Mar 28 22:41:37 right, on a typical kvm setup the overhead is negligible Mar 28 22:41:52 {Nico}: does block-mount need to be changed too? Mar 28 22:42:38 <{Nico}> swalker: is it changing busybox config on-the-fly ? Mar 28 22:43:51 {Nico}: https://dev.openwrt.org/browser/trunk/package/block-mount/Makefile#L28 Mar 28 22:44:50 <{Nico}> humm Mar 28 22:45:18 oh, that is ugly :-\ Mar 28 22:45:47 {Nico}: maybe make it default to n the if a user needs it they can compile it themselves Mar 28 22:46:00 s/the/then/ Mar 28 22:47:20 <{Nico}> humm Mar 28 22:47:36 hmm Mar 28 22:48:02 <{Nico}> compiling it later will build a new busybox, not compatible with the one installed, bot having the save version/release numbers Mar 28 22:48:06 <{Nico}> that's just wrong Mar 28 22:48:30 that is true :-/ Mar 28 22:48:43 <{Nico}> either make it default in bb, or depends on external tools Mar 28 22:49:00 I would say make it depend on external tools Mar 28 22:49:09 blkid itself can be made default I think Mar 28 22:49:38 <{Nico}> what does block-mount need ? Mar 28 22:50:01 blkid, mkswap, swaponoff Mar 28 22:50:35 I think the volumeid stuff is for blkid Mar 28 22:51:03 and mkswap_uuid is for mkswap of course Mar 28 22:51:41 cshore: ping Mar 28 22:51:58 {Nico}: this is cshore's package Mar 28 23:02:49 <{Nico}> well, blkid & libblkid are in e2fsprogs, mkswap & swap{on,off} are in util-linux-ng Mar 28 23:05:46 swalker * r20562 /packages/net/netatalk/Makefile: [packages] netatalk: fix PKG_VERSION variable Mar 28 23:11:06 nbd * r20563 /trunk/package/ifxos/ (. Makefile patches/ patches/100-portability.patch): add a package for ifxos (Infineon/Lantiq OS abstraction layer for drivers) Mar 28 23:13:52 <{Nico}> anyone using block-mount already ? Mar 28 23:16:27 <{Nico}> block-mount proposed changes >> http://pastebin.com/1Aaktbpr Mar 28 23:19:11 cshore: ^ Mar 28 23:21:03 xMff: hmmm, CONFIG_MTD_BLOCK2MTD=y in target/linux/x86/config-default Mar 28 23:21:29 xMff: so it should also be enabled in the kernel of my kvmguest image Mar 28 23:21:42 I believe Mar 28 23:22:05 stintel: I am not 100% certain whether kmod-block2mtd overrides it again Mar 28 23:22:47 so I could also enable kmod-block2mtd to test if it then works Mar 28 23:25:13 nbd: care to fix those uboot wiki urls? Mar 28 23:33:11 nbd * r20564 /trunk/package/ (uboot-ifxmips/Makefile uboot-lantiq/Makefile): fix u-boot wiki urls Mar 28 23:36:50 stintel, xMff: a kmod-* selection should never downgrade a =y to a =m Mar 28 23:37:04 nbd: ok Mar 28 23:43:01 hmmm "block2mtd cannot open device /dev/vda2" Mar 28 23:43:23 right Mar 28 23:43:33 virtio-blk is initialized later Mar 28 23:43:40 so that's why Mar 28 23:43:48 maybe add back rootwait? Mar 28 23:43:56 it is made for this kind of situation Mar 28 23:44:01 i've added that again Mar 28 23:44:08 oh hm Mar 28 23:44:14 keeps waiting forever on root device Mar 28 23:44:39 then you need virtio-blk initalize earlier I guess Mar 28 23:45:18 yeah, but no idea how to fix that, tbh, as it's already in-kernel :) Mar 28 23:52:51 nbd * r20565 /packages/net/et131x/Makefile: et131x: clean up and make building without CONFIG_STAGING=y work (fixes #5566) Mar 29 00:05:50 nbd * r20566 /trunk/rules.mk: use lazy evaluation for TARGET_CONFIGURE_OPTS to make it possible to override TARGET_CC and TARGET_CXX Mar 29 00:10:51 devinit_err: Mar 29 00:10:52 block2mtd_free_device(dev); Mar 29 00:10:52 return NULL; Mar 29 00:11:07 so if it fails, it will not retry later Mar 29 00:11:36 so virtio_blk should just be initialized before block2mtd Mar 29 00:11:46 trying to figure out how to hack that in the kernel :) Mar 29 00:15:24 http://lwn.net/Articles/2399/ Mar 29 00:15:32 maybe it helps to grep for that? Mar 29 00:17:26 found it I think Mar 29 00:18:04 block/ stuff is loaded before mtd/ so should work already, BUT, virtio_blk doesn't work if virtio_ something isn't available Mar 29 00:18:09 and virtio/ stuff is loaded much later Mar 29 00:18:21 I am going to move the loading of virtio/ stuff right below block/, before mtd/ Mar 29 00:18:48 or maybe even earlier Mar 29 00:19:33 ah :) Mar 29 00:20:57 I fear I have to many devices Mar 29 00:21:11 just logged in somewhere on my network and I have no clue where Mar 29 00:21:15 :P Mar 29 00:24:44 gonna try and move the virtio loading stuff a bit up, putting virtio_blk in the init_after of the block2mtd seems unrelated, and what if virtio_blk isn't compiled, will that break block2mtd etc Mar 29 00:25:00 unrelated wasn't the correct word Mar 29 00:29:24 xMff: I once freaked out on an active SSH session, from my home IP to one of my servers, but I never connect from home to there directly Mar 29 00:29:39 xMff: turned out it was my rsnapshot backup that was running Mar 29 00:30:05 hehe Mar 29 00:30:27 I think I will have to spend tomorrow on improving my umts connection :/ Mar 29 00:30:37 I have timeouts every 5 minutes :( Mar 29 00:32:42 ah, that's awful :( Mar 29 00:33:47 Applying patch generic/010-early_virtio_init.patch Mar 29 00:33:57 let's see if that works Mar 29 00:34:16 and then I need to go to bed, job interview tomorrow :) Mar 29 00:34:43 stintel: i wish you luck Mar 29 00:35:03 rtz2: thanks, I'll need it, really need to get a job yesterday Mar 29 00:35:03 I will have a fund day with ~50 badly documented at commands Mar 29 00:36:02 fun :) well it's my 2nd interview there, involves management people, dress to impress, all that b*llshit Mar 29 00:36:10 oh, bullsh*t I meant :? Mar 29 00:36:57 :D Mar 29 00:37:10 I was mostly "if you dont like me coming in jeans then I don't even want to work for you" but times change Mar 29 00:50:59 wooot Mar 29 00:51:04 * stintel throws away the noob hat Mar 29 00:52:05 this one fixes the mtdblock problem with virtio_blk devices: http://dpaste.com/177176/ Mar 29 00:52:38 it actually makes sense to me to have the virtio framework initialize at the same time the xen stuff is initialized Mar 29 00:52:54 yay Mar 29 00:52:56 nice Mar 29 00:52:57 to even have that all before block stuff is initialized Mar 29 00:53:49 damn, now that it works I fear I'm not headed for bed yet Mar 29 00:53:56 lol Mar 29 00:54:10 * xMff blames dst Mar 29 00:54:28 daylight savings ? Mar 29 00:54:33 yep Mar 29 00:54:47 actually its an hour earlier :P Mar 29 00:54:50 didn't even notice, I was still awake learning C while the switch happened so I slept like normal ;-) Mar 29 00:56:20 mirko * r20567 /packages/sound/mpd/Makefile: use gcc instead of g++ to avoid unnecessary linking against libstdc++, as this is plain C software Mar 29 00:59:19 probably best if I report the problem between block2mtd and virtio_blk to bugzilla.kernel.org I guess Mar 29 01:00:59 yes Mar 29 01:01:35 ok, will do. shall I resend my x86_kvm_guest subtarget patch series with that fix also ? Mar 29 01:14:04 stintel: yes Mar 29 01:14:55 nico * r20568 /packages/net/ctorrent/Makefile: [packages] ctorrent: fix build failure on brcm-2.4 with gcc-3.4.6 (closes: #6988) Mar 29 01:30:47 do you guys use some kind of scripts to refresh patches? so they apply cleanly without fuzz etc ? Mar 29 01:32:33 <{Nico}> stintel: all is done with quilt Mar 29 01:32:51 <{Nico}> stintel: make package/foo/refresh Mar 29 01:33:20 and for kernel patch ? make target/linux/refresh ? Mar 29 01:33:28 thepeople: the reason for using busybox blkid and swap-utils is that nbd wanted busybox blkid and swap-utils instead of external tools, so I would suggest making them default if doing them optionally as I did is bad (I did that because I thought it was avoid adding them as defaults without hurting anything) Mar 29 01:35:26 OTOH there are advantages to using the external tools, because then I can add the autofsck functionality back in (I removed it because the necessary fs type reporting doesn't exist in the busybox version of blkid) Mar 29 01:38:25 cshore: the problem with including busybox apps is that if the package is included them then they get included in the release image Mar 29 01:39:02 thepeople: nbd and xMff seemed to think that was reasonable Mar 29 01:39:33 thepeople: do you think they are too big to be included in the release image? Mar 29 01:40:34 <{Nico}> can't we try first with external tools ? Mar 29 01:41:10 <{Nico}> then reconsider later as the scripts and busybox evolve Mar 29 01:41:19 nbd: I haven't looked close enough yet, the current snapshot images are currenly 2.36MB Mar 29 01:41:29 for brcm-2.4 Mar 29 01:42:08 how big is busybox? Mar 29 01:42:21 uncompressed Mar 29 01:43:19 <{Nico}> -rwxr-xr-x 1 openwrt openwrt 580411 Mar 28 18:23 build/brcm-2.4/build_dir/target-mipsel_uClibc-0.9.30.1/busybox-1.15.3/ipkg-brcm-2.4/busybox/bin/busybox Mar 29 01:43:38 mine is 557580 Mar 29 01:43:45 without the blkid stuff Mar 29 01:43:47 [travis@tksite bin]$ ls -l busybox Mar 29 01:43:47 -rwxr-xr-x 1 travis travis 461263 Mar 27 20:39 busybox Mar 29 01:44:02 oh, wait Mar 29 01:44:05 i looked at the wrong one Mar 29 01:44:16 wow, that is a lot of bloat for such simple utilities Mar 29 01:44:17 this is from todays snapshot Mar 29 01:45:02 <{Nico}> mine has blkid & ip enabled (due to config-time deps) Mar 29 01:45:19 <{Nico}> thepeople: which arch ? Mar 29 01:45:22 what selects ip? Mar 29 01:45:34 <{Nico}> ucarp, but it's fixed now Mar 29 01:45:51 {Nico}: that was for brcm47xx Mar 29 01:46:11 thepeople: so yours was with the blkid stuff selected? Mar 29 01:46:25 <{Nico}> -rwxr-xr-x 1 openwrt openwrt 461263 Mar 28 20:39 build/brcm47xx/build_dir/target-mipsel_uClibc-0.9.30.1/busybox-1.15.3/ipkg-brcm47xx/busybox/bin/busybox Mar 29 01:46:42 mine without extra stuff in ifxmips is 436592 Mar 29 01:47:00 nbd: that was the snapshot image from the buildbot with both ip and blkid Mar 29 01:47:04 I think Mar 29 01:47:07 ok Mar 29 01:47:15 then i guess we can keep blkid Mar 29 01:47:27 r20529 Mar 29 01:48:10 if blkid + ip only adds around 25k, then blkid can't be that big Mar 29 01:48:30 {Nico}: what do you think about releasing mini images without a webif (and thus no httpd) for the final release? Mar 29 01:48:31 that actually adds swap-utils too Mar 29 01:48:38 yeah Mar 29 01:48:45 i'll do a direct comparison... Mar 29 01:49:21 {Nico}: becuase we did add some bloat with uhttpd vs busybox httpd Mar 29 01:49:55 but it works so much better :-) Mar 29 01:50:04 <{Nico}> thepeople: no objections, but i don't really how to do it without interfering with actual build process Mar 29 01:50:46 {Nico}: imagebuilder? Mar 29 01:50:53 {Nico}: you could script in the image..... Mar 29 01:51:06 doesn't hurt if the mini images are built later Mar 29 01:51:28 {Nico}: or move the images and do a rebuild of the images for mini Mar 29 01:53:05 blkid+swap adds adds 11k uncompressed on ifxmips Mar 29 01:53:13 <{Nico}> i think we have another problem : actual ImageBuilders will be x86_64 only Mar 29 01:53:29 <{Nico}> s/actual/-rc2 & -final/ Mar 29 01:54:09 yea, you need to build it on a 32bit box, or get a 32bin env up for it Mar 29 01:54:35 where's FatELF when you need it? ;) Mar 29 01:55:01 :-P Mar 29 01:56:31 nbd: did you see acoul's patches for adding lzma to jffs Mar 29 01:56:47 yes, but i did not review them yet Mar 29 01:57:10 <{Nico}> nbd: can we integrate that in the IB generation process ? Mar 29 01:58:25 no, it requires system support ;) Mar 29 01:59:38 nbd: can we have openwrt building openwrt to support it :-P Mar 29 01:59:56 ... speaking of bloat Mar 29 02:00:00 lol Mar 29 02:00:47 what binaries are required for the imagebuilder? Only the firmware uitls? Mar 29 02:02:45 I mean apart from the target binaries Mar 29 02:04:02 looks like only staging_dir/host is x86_64 specific Mar 29 02:04:11 is there a toolchain target for it? Mar 29 02:04:16 *make target Mar 29 02:05:46 I'm looking at #6955....we're not changing 8.09 at all, right? Mar 29 02:06:27 and I don't recognize /sbin/usb-storage....was that an old way of doing things? **** ENDING LOGGING AT Mon Mar 29 02:09:14 2010 **** BEGIN LOGGING AT Mon Mar 29 02:44:15 2010 **** ENDING LOGGING AT Mon Mar 29 02:59:57 2010