**** BEGIN LOGGING AT Tue Oct 05 02:59:57 2010
Oct 05 05:13:50 * russell_ working on bisecting where the console goes away again
Oct 05 05:14:31 <russell_> somewhere between r22596 and r22669
Oct 05 05:26:12 <builder_> build #3 of ixp4xx is complete: Failure [failed shell_10]  Build details are at http://tksite.gotdns.org:8010/builders/ixp4xx/builds/3
Oct 05 07:28:12 <CIA-14> jow * r23230 /trunk/package/opkg/ (Makefile patches/013-add-list-changed-conffiles.patch): [package] opkg: update to r576, remove 013add-list-changed-conffiles.patch - went upstream.
Oct 05 07:33:11 <CIA-14> jow * r23231 /trunk/package/firewall/Makefile: [package] firewall: mark /etc/firewall.user as conffile
Oct 05 07:34:01 <CIA-14> jow * r23232 /trunk/package/base-files/Makefile: [package] base-files: mark /etc/rc.local as conffile
Oct 05 07:41:48 <CIA-14> jow * r23233 /trunk/package/base-files/ (Makefile files/sbin/sysupgrade): [package] base-files: sysupgrade: merge info from "opkg list-changed-conffiles" to backup file list
Oct 05 07:44:23 <CIA-14> jow * r23234 /branches/backfire/package/opkg/Makefile: [backfire] merge r23230
Oct 05 07:44:57 <CIA-14> jow * r23235 /branches/backfire/package/firewall/Makefile: [backfire] merge r23231
Oct 05 07:46:54 <CIA-14> jow * r23236 /branches/backfire/package/base-files/ (Makefile files/sbin/sysupgrade): [backfire] merge r23232 and r23233
Oct 05 08:04:35 <russell_> okay, i found the patch that fucks up the wgt634u console, r22663
Oct 05 08:04:44 <xMff> nvram stuff?
Oct 05 08:05:02 <xMff> yes
Oct 05 08:05:07 <russell_> yeah
Oct 05 08:05:11 <xMff> that one fucked up a few other models as well
Oct 05 08:05:29 <russell_> broadcom-diag is screwed much further back
Oct 05 08:05:32 <xMff> I thought is has been fixed up again later
Oct 05 08:05:36 <russell_> but that's the one where console goes away
Oct 05 08:05:52 <xMff> ping RealOpty
Oct 05 08:05:54 <russell_> i tried HEAD within the last week
Oct 05 08:05:58 <russell_> i think
Oct 05 08:06:09 <russell_> all the bisects, it's a bit of a blur
Oct 05 08:06:29 <xMff> all that stuff is "don't touch" code :P
Oct 05 08:06:40 <xMff> any attempt to fix it will break something as it seems
Oct 05 08:07:06 <russell_> no one is going to have all the hardware to test, i suppose
Oct 05 08:07:09 <russell_> i know i don't
Oct 05 08:08:33 <xMff> ok this code makes cfe nvram calls always succeed
Oct 05 08:08:50 <russell_> which one is that?
Oct 05 08:08:53 <xMff> so I guess the WGT detection somewhere else needs to be tweaked to get along with that
Oct 05 08:08:57 <xMff> the one you posted
Oct 05 08:09:44 <russell_> oh, i'm just looking at the commit message
Oct 05 08:10:17 <russell_> "With this patch nvram read will be successful very time so cfe will no be read out."
Oct 05 08:10:55 <xMff> correct. and somewhere some code is probing specific vars and apparently expects some to fail
Oct 05 08:11:27 <russell_> i don't grasp the distinction between cfe and nvram reads
Oct 05 08:11:39 <russell_> one is calling cfe functions?
Oct 05 08:12:04 <xMff> yeah, one is calling the cfe api, another is reading nvram "manually"
Oct 05 08:12:28 <russell_> ah, i saw somewhere that at some point during boot the cfe memory is recovered
Oct 05 08:12:38 <russell_> which would make those functions not be there anymore
Oct 05 08:13:09 <xMff> unfortunately I can't pinpoint the serial setup / model detection code right now
Oct 05 08:14:08 <russell_> i saw it once! ;-)
Oct 05 08:15:49 <xMff> you said diag was broken earlier
Oct 05 08:15:54 <russell_> yeah
Oct 05 08:16:04 <russell_> since, uh
Oct 05 08:16:06 <xMff> this is the actual problem I think
Oct 05 08:16:19 <russell_> r22296
Oct 05 08:17:05 <russell_> that is the rev that broke broadcom-diag for the wgt
Oct 05 08:17:05 <xMff> hmm
Oct 05 08:20:03 <russell_> i suppose that knowing the right place for the nvram functions to look requires knowing something about what the device is already.  i suppose that's the advantage of using the cfe interface.
Oct 05 08:20:13 <xMff> heh
Oct 05 08:20:28 <xMff> diag's way of detecting the wgt is: if (strcmp(getvar("nvram_type"), "cfe") == 0)
Oct 05 08:20:37 <russell_> yeah, that looked dumb to me
Oct 05 08:20:55 <russell_> i even tried hacking something else in there, but it didn't seem to help.
Oct 05 08:21:09 <russell_> (i might have tried it against the wrong rev though)
Oct 05 08:21:23 <russell_> (where something else was broken, or something)
Oct 05 08:22:06 <xMff> does the wgt use the same .trx image as the other bcm targets?
Oct 05 08:22:13 <russell_> looking at the contents of the nvram, it looks like there is a boardtype of bcm95365r
Oct 05 08:22:14 <russell_> yeah
Oct 05 08:22:33 <russell_> openwrt-brcm47xx-squashfs.trx is what i usually flash
Oct 05 08:23:14 <xMff> hm, I once was told that the wgt is quite exceptional, it has no traditional nvram for example
Oct 05 08:23:32 <russell_> yeah, not like what the wrt had
Oct 05 08:23:40 <xMff> maybe you should try a negation
Oct 05 08:23:57 <xMff> if no common nvram var exists, assume a wgt
Oct 05 08:24:27 <russell_> but, like, is bcm95365r not unique then?
Oct 05 08:24:56 <xMff> for example !boardflags && !sdram_init && !et0macaddr
Oct 05 08:25:06 <xMff> I wouldn't assume it to be unique
Oct 05 08:25:15 <xMff> you can use it as additional check though
Oct 05 08:25:35 <xMff> boardtype=bcm95365r && !boardflags && !sdram_init && !et0macaddr
Oct 05 08:26:01 <russell_> oh, i have et0macaddr
Oct 05 08:26:04 <xMff> hm
Oct 05 08:26:11 <xMff> you use the nvram util?
Oct 05 08:26:31 <xMff> or cfe printenv?
Oct 05 08:26:44 <russell_> hexdump -C !
Oct 05 08:26:53 <xMff> on the mtd part?
Oct 05 08:27:06 <russell_> that's what i was looking at just then
Oct 05 08:27:17 <xMff> the thing is
Oct 05 08:27:24 <xMff> the traditional nvram api does not work
Oct 05 08:27:42 <xMff> the reason your nvram is destroyed is the broken diag
Oct 05 08:27:54 <russell_> yeah
Oct 05 08:28:06 <xMff> so
Oct 05 08:28:14 <russell_> CFE sees the variables though
Oct 05 08:28:15 <xMff> you might have variables on the flash
Oct 05 08:28:27 <xMff> but the usual nvram_get() api does not work
Oct 05 08:28:34 <russell_> like CFE printenv
Oct 05 08:29:06 <xMff> I'd say add some debug printfs to diag.c
Oct 05 08:29:12 <xMff> *kprints
Oct 05 08:29:20 <russell_> printk!
Oct 05 08:29:29 <russell_> yeah
Oct 05 08:29:35 <russell_> that sounds like the ticket
Oct 05 08:29:44 <xMff> see if for example nvram_get("et0macaddr") returns something
Oct 05 08:29:47 * russell_ was looking for a rev where the console worked ;-)
Oct 05 08:29:53 <russell_> yeah
Oct 05 08:29:55 <xMff> if not, use the proposed negative approach above
Oct 05 08:30:18 <russell_> is that in broadcom-diag?
Oct 05 08:30:21 <xMff> yes
Oct 05 08:30:42 <xMff> that will solve detection and nvram corruption
Oct 05 08:30:50 <russell_> okay, cool.  i seem to remember seeing some kind of board detection somewhere else too, i get confused.
Oct 05 08:30:52 <xMff> the console must be fixed separtely
Oct 05 08:43:48 <acoul> hello
Oct 05 08:46:14 <russell_> ah yeah, get_router()
Oct 05 08:46:56 <russell_> in target/linux/brcm47xx/files-2.6.34/drivers/mtd/maps/bcm47xx-flash.c
Oct 05 08:47:25 <xMff> ah yes, that was for some newer models which needs holes in their flashmap due to boarddate stored at specifc offsets
Oct 05 08:47:38 <xMff> boarddata
Oct 05 08:48:08 <russell_> how does that interact?
Oct 05 08:48:17 <russell_> like, when is that called, etc.
Oct 05 08:48:19 <xMff> it uses nvram calls too iirc
Oct 05 08:48:35 <russell_> and cfe_getenv()
Oct 05 08:48:47 <xMff> its called when the mtd partitioning is figured out
Oct 05 08:49:08 <russell_> is that before or after broadcom-diag?
Oct 05 08:49:33 <xMff> yes
Oct 05 08:49:38 <russell_> lol
Oct 05 08:49:38 <xMff> heh
Oct 05 08:49:41 <xMff> befgore I meant
Oct 05 08:49:45 <russell_> ah
Oct 05 08:49:56 <xMff> diag is a kmod, the flashmap is builtin
Oct 05 08:50:02 <russell_> cool
Oct 05 08:50:37 <russell_> so i think if i sprinkle those two places with printk's i'm bound to get smarter
Oct 05 08:50:48 <xMff> very likely
Oct 05 08:52:19 <CIA-14> acoul * r23237 /trunk/target/linux/generic/patches-2.6.36/ (56 files): linux/generic: refresh 2.6.36 kernel patches
Oct 05 09:06:02 <CIA-14> jow * r23238 /trunk/package/qos-scripts/Makefile: [package] qos-scripts: bump pkg revision after r23227, extend copyright, mark /etc/config/qos as conffile
Oct 05 09:09:12 <CIA-14> acoul * r23239 /trunk/target/linux/ixp4xx/ (config-2.6.33 config-2.6.34 config-2.6.35 config-2.6.36): linux/ixp4xx: revert accidentally leaked enabled kernel option (thank you kaloz)
Oct 05 09:51:22 <CIA-14> acoul * r23240 /trunk/target/linux/generic/patches-2.6.36/ (5 files): linux/generic: update kernel patch refreshing. Include two missed patches.
Oct 05 10:11:35 <nunojpg>         -n         name unnamed sections on export (default)
Oct 05 10:12:02 <nunojpg> "uci export wireless" is not the same as "uci -n export wireless"
Oct 05 10:12:20 <nunojpg> so that "default" is not correct on the help
Oct 05 10:59:43 <EqUaTe> dammit.. git.infradead.org is down again.
Oct 05 11:02:25 <jow_laptop> EqUaTe: http://luci.subsignal.org/~jow/mtd-20101002.tar.gz
Oct 05 11:02:32 <jow_laptop> 56d11ceff5e90a369f8c732939c96e5c
Oct 05 11:02:36 <EqUaTe> cool.. thanks jow_laptop :)
Oct 05 11:03:36 <EqUaTe> jow_laptop: got mtd-utils there as well ?
Oct 05 11:12:06 <jow_laptop> EqUaTe: that is the tarball for mtd-utils
Oct 05 11:14:54 <EqUaTe> ah ok
Oct 05 11:15:37 <EqUaTe> oh yeah.
Oct 05 11:17:28 <RealOpty> yay thank you jow_laptop  i can add that to my local server now :)
Oct 05 11:20:08 <EqUaTe> building an image for the wnr2000.. all being well, i should fairly soon have some patches that allow it to be built normally.. with the things for header modification..
Oct 05 12:05:00 <RealOpty> EqUaTe, that a netgrear?
Oct 05 12:05:30 <EqUaTe> RealOpty: the wnr2000? yes
Oct 05 12:05:43 <RealOpty> nice.
Oct 05 12:05:48 <EqUaTe> not a great one..
Oct 05 12:06:01 <EqUaTe> bgn, 32megs ram, 4megs flash
Oct 05 12:06:06 <EqUaTe> and an annoying crc check on every boot
Oct 05 12:06:08 <RealOpty> does it use chk images to flash from its stock webif ?
Oct 05 12:06:16 <EqUaTe> chk ?
Oct 05 12:06:22 <RealOpty> .bin
Oct 05 12:06:25 <EqUaTe> ahh
Oct 05 12:06:26 <RealOpty> .trx
Oct 05 12:06:32 <RealOpty> .chk on shitty netgear lol
Oct 05 12:06:35 <EqUaTe> i think the stock images come as .img
Oct 05 12:06:41 <RealOpty> nice...
Oct 05 13:25:04 <RealOpty> jow_laptop, when doing make download i see this " bash: md5s: command not found" around the package grub
Oct 05 13:30:19 <EqUaTe> i've noticed that too, but couldn't find what was causing it
Oct 05 13:53:20 <CIA-14> acoul * r23241 /trunk/tools/sed/ (Makefile patches/): tools/sed: update to sed-4.2.1 (also tested on FreeBSD/AMD64)
Oct 05 14:11:56 <CIA-14> juhosg * r23242 /trunk/package/mac80211/ (2 files in 2 dirs): mac80211: ath9k: get tx gain type from eeprom
Oct 05 14:12:01 <CIA-14> juhosg * r23243 /trunk/target/linux/ramips/files/drivers/net/ramips.c:
Oct 05 14:12:02 <CIA-14> ramips: Allow ethernet interface to be taken down and up again
Oct 05 14:12:02 <CIA-14> Taking the ramips ethernet interface down and up again resulted in the
Oct 05 14:12:02 <CIA-14> driver not receiving any frames anymore. Fix this by correctly disabling
Oct 05 14:12:02 <CIA-14> interrupts in the hw on ifdown.
Oct 05 14:12:02 <CIA-14> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Oct 05 14:15:38 <CIA-14> kaloz * r23244 /trunk/tools/Makefile: [tools]: simplify old squashfs/lzma selection
Oct 05 14:17:11 <CIA-14> kaloz * r23245 /trunk/ (3 files in 3 dirs): Toto, we don't support Linux 2.4 anymore..
Oct 05 14:20:26 <CIA-14> kaloz * r23246 /trunk/ (Config.in target/Config.in): as we only support 2.6, remove the useless bool for it
Oct 05 14:38:00 <CIA-14> mb * r23247 /packages/net/xtables-addons/Makefile: xtables-addons: use tbz
Oct 05 15:31:44 <builder_> build #4 of brcm63xx is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/4
Oct 05 17:14:33 <CIA-14> jow * r23248 /trunk/package/ppp/Makefile: [package] ppp: mark /etc/ppp/ resources as conffiles
Oct 05 17:17:38 <CIA-14> jow * r23249 /trunk/package/hotplug2/Makefile: [package] hotplug2: mark /etc/hotplug2.rules as conffile
Oct 05 17:19:14 <CIA-14> jow * r23250 /trunk/package/iproute2/Makefile: [package] iproute2: mark /etc/iproute2/rt_tables as conffile
Oct 05 17:22:41 <CIA-14> jow * r23251 /trunk/package/mmc_over_gpio/Makefile: [package] mmc_over_gpio: mark /etc/config/mmc_over_gpio as conffile
Oct 05 17:24:03 <CIA-14> jow * r23252 /trunk/package/mountd/Makefile: [package] mountd: mark /etc/config/mountd as conffile
Oct 05 17:24:03 <mb__> jow_laptop: What does marking a file as conffile do?
Oct 05 17:24:41 <xMff> mb__: it gets special treatment by opkg. It's checksummed during package creation and only replaced on package upgrade if its not modified by the user
Oct 05 17:24:57 <xMff> on trunk its also used to assemble the sysupgrade keep files list
Oct 05 17:26:36 <mb__> ah ok
Oct 05 17:26:56 <mb__> nice
Oct 05 17:28:47 <CIA-14> jow * r23253 /trunk/package/pptp/Makefile: [package] pptp: mark /etc/ppp/options.pptp as conffile
Oct 05 17:32:23 <CIA-14> jow * r23254 /trunk/package/udev/Makefile: [package] udev: mark /etc/udev/udev.conf as conffile (rules left out for now)
Oct 05 17:34:43 <CIA-14> jow * r23255 /trunk/package/wprobe/Makefile: [package] wprobe: mark /etc/config/wprobe as conffile
Oct 05 17:38:08 <xMff> that could even be automated probably, just scan .../ipkg-install/etc/ and add any file in there as conffile
Oct 05 19:19:42 <CIA-14> jow * r23256 /trunk/tools/ipkg-utils/patches/170-resolve_conffiles.patch:
Oct 05 19:19:42 <CIA-14> [tools] ipkg-utils: don't fail if conffiles do not exist, resolve them instead and silently skip not existing files.
Oct 05 19:19:42 <CIA-14> This prepares support for sysupgrade hints using to build the keepfile list.
Oct 05 19:19:42 <CIA-14> Subsequent commits will rely on this feature - a rebuild of tools/ipkg-utils is necessary!
Oct 05 19:21:55 <CIA-14> jow * r23257 /trunk/include/package-ipkg.mk:
Oct 05 19:21:55 <CIA-14> [include] package-ipkg.mk: build sysupgrade keepfile hints out of conffiles not yet present in the package.
Oct 05 19:21:55 <CIA-14> This applies to config directories or files that do not exist but may be created by the
Oct 05 19:21:55 <CIA-14> user after package installation.
Oct 05 19:25:58 <CIA-14> jow * r23258 /trunk/package/base-files/ (5 files in 4 dirs): (log message trimmed)
Oct 05 19:25:59 <CIA-14> [package] base-files:
Oct 05 19:25:59 <CIA-14> - add sysupgrade support for keepfile hints
Oct 05 19:25:59 <CIA-14> * introduces /lib/upgrade/keep.d/ for per-package keepfile lists
Oct 05 19:25:59 <CIA-14> * introduces /etc/sysupgrade.conf for user defined keepfile hints
Oct 05 19:25:59 <CIA-14> - prime /lib/upgrade/keep.d/base-files-essential to keep sysupgrade usable for images without opkg
Oct 05 19:26:00 <CIA-14> - change sysupgrade to build the keepfile list from /lib/upgrade/keep.d/, /etc/sysupgrade.conf and
Oct 05 19:34:15 <CIA-14> jow * r23259 /trunk/package/ppp/Makefile: [package] ppp: utilize the new keepfiles facility to backup the whole radius directory
Oct 05 19:35:48 <CIA-14> jow * r23260 /trunk/package/uhttpd/ (Makefile src/uhttpd.c): [package] uhttpd: add /etc/uhttpd.key and /etc/uhttpd.crt to conffile hints
Oct 05 19:37:04 <CIA-14> jow * r23261 /trunk/package/uhttpd/src/uhttpd.c: [package] uhttpd: revert unrelated change in previous commit
Oct 05 19:37:41 <stintel> nice
Oct 05 19:38:52 <stintel> I should fix X on my desktop, being booted in Windows stops me from building openwrt :)
Oct 05 20:21:45 <CIA-14> ralph * r23262 /trunk/include/subdir.mk: [include] add configure as package target
Oct 05 20:33:02 <EqUaTe> hrm.. how do i figure out what header i need to put on an image?
Oct 05 20:38:00 * EqUaTe is well out of his depth here
Oct 05 20:38:20 <xMff> hex editor
Oct 05 20:40:01 <EqUaTe> i've got the gpl source, and i'm looking at the wndr3700.c in firmware-tools
Oct 05 20:44:54 <EqUaTe> not sure how the gpl code builds the images and marks the images up accordingly.
Oct 05 20:45:04 <xMff> well in the gpl source must be some image generation tools
Oct 05 20:45:08 <xMff> mkimage or similar
Oct 05 20:45:26 <xMff> can you put an ls -lR into pastebin?
Oct 05 20:46:22 <EqUaTe> sure
Oct 05 20:51:56 <EqUaTe> xMff: http://pastie.org/private/buqvetorvknf4npmev885w
Oct 05 20:55:32 <xMff> EqUaTe: please paste target/linux/ar91xx-2.6/Makefile
Oct 05 20:56:47 <xMff> EqUaTe: and examine tools/mkimage/src/
Oct 05 20:57:26 <EqUaTe> the former is rather sparse:
Oct 05 20:57:27 <EqUaTe> include $(TOPDIR)/rules.mk
Oct 05 20:57:27 <EqUaTe> LINUX_VERSION:=2.6.15
Oct 05 20:57:27 <EqUaTe> LINUX_RELEASE:=
Oct 05 20:57:27 <EqUaTe> LINUX_KERNEL_MD5SUM:=
Oct 05 20:57:27 <EqUaTe> include $(INCLUDE_DIR)/kernel-build.mk
Oct 05 20:57:27 <EqUaTe> $(eval $(call BuildKernel))
Oct 05 21:00:38 <xMff> anything in the mkimage sources?
Oct 05 21:01:39 <EqUaTe> for mkimage, if i upload the files to a server of mine so you can see them, will that help? i think there's some stuff in image.h that looks like it's probably relevant
Oct 05 21:01:47 <xMff> yes
Oct 05 21:02:29 <EqUaTe> http://www.equateuk.com/mkimage/
Oct 05 21:03:45 <xMff> hm, where can I d/l the gpl tarball?
Oct 05 21:03:54 <xMff> the mkimage is not really useful
Oct 05 21:04:00 <xMff> or maybe it is
Oct 05 21:04:18 <xMff> basically I want to see what's called to generate the iamge
Oct 05 21:04:56 <EqUaTe> ftp://downloads.netgear.com/files/GPL/
Oct 05 21:05:09 <EqUaTe> ftp://downloads.netgear.com/files/GPL/WNR2000_V1.1.2.6_src.zip <-- that's the specific one i'm using (that's what i have installed)
Oct 05 21:05:46 <xMff> yay, fast mirror
Oct 05 21:06:31 <EqUaTe> yeah, i was surprised how quick it was myself
Oct 05 21:07:12 <EqUaTe> considering it's netgears own, i was expecting it to be pretty damned slow
Oct 05 21:07:49 <xMff> hmm
Oct 05 21:12:24 <xMff> ok, so you need a tool called "appendsum"
Oct 05 21:12:41 <xMff> its apparently not part of the gpl archive but in another one
Oct 05 21:12:44 <xMff> toolchain source
Oct 05 21:12:47 <EqUaTe> got that
Oct 05 21:12:56 <EqUaTe> ftp://downloads.netgear.com/files/GPL/WNR2000_toolchain-src.zip
Oct 05 21:13:19 <EqUaTe> can't say that i see it in there though
Oct 05 21:13:45 <EqUaTe> unless it's mips-linux-uclibc-as
Oct 05 21:13:51 <xMff> include/image.mk contains the image build steps
Oct 05 21:14:10 <xMff> they seem to preprend some kind of plaintext header data section
Oct 05 21:15:43 <xMff> fun.. all written in shell
Oct 05 21:15:54 <EqUaTe> heh
Oct 05 21:16:13 <xMff> ah
Oct 05 21:16:21 <xMff> in the not toolchain archive
Oct 05 21:16:30 <xMff> tools/include/appendsum
Oct 05 21:16:34 <xMff> binary though
Oct 05 21:16:58 <xMff> I'd say build the gpl release, compare the no-crc and finam image
Oct 05 21:17:05 <xMff> *final
Oct 05 21:17:12 <xMff> with vbindiff or some similar tool
Oct 05 21:17:28 <EqUaTe> ok, will have a look at that..
Oct 05 21:17:37 <EqUaTe> thanks for the advice, i'll let you know how it goes :)
Oct 05 21:18:03 <xMff> oops
Oct 05 21:18:04 <xMff> not binary
Oct 05 21:18:09 <xMff> appendsum is a perl script
Oct 05 21:18:16 <xMff> I just loocked at the file perms
Oct 05 21:18:25 <EqUaTe> ahh
Oct 05 21:19:17 <EqUaTe> going afk for a little bit.. back in half an hour or so..
Oct 05 21:19:21 <xMff> sure
Oct 05 21:34:25 <xMff> ping cshore_
Oct 05 21:42:30 <EqUaTe> ok, back for a bit.
Oct 05 21:43:51 <EqUaTe> xMff: is it just me, or is it basically putting a 4byte header (magic?) and then the file checksum?
Oct 05 21:45:25 <xMff> EqUaTe: sounds right
Oct 05 21:45:35 <xMff> EqUaTe: don't forget the head_info stuff from image.mk
Oct 05 21:45:40 <EqUaTe> my perl's not great, but that's what it looks like
Oct 05 21:46:09 <xMff> so its basically:  magic + checksum + head_info + kernel 64k aligned + squashfs 64k aligned
Oct 05 21:46:43 <EqUaTe> ok
Oct 05 21:47:24 <EqUaTe> interesting.. it seems to define the kernel and root fs lengths statically..
Oct 05 21:49:53 <EqUaTe> i've set it building that stock firmware version.. hopefully it'll produce some output.. i don't especially want to have to set up an fc5 vm..
Oct 05 21:53:28 <CIA-14> nunojpg * r23263 /packages/net/sshtunnel/ (4 files in 4 dirs): [packages] sshtunnel: update to version 2
Oct 05 21:58:56 <russell_> xMff: /me discovers that reverting r22663 on trunk HEAD gives me my console back on wgt634u, on to testing as previously outlined
Oct 05 21:59:33 <xMff> ok
Oct 05 22:06:11 <EqUaTe> xMff: you probably dont' hear this enough, but thanks for all the help so far :)
Oct 05 22:09:50 <CIA-14> jow * r23264 /trunk/package/base-files/Makefile: [package] base-files: mark /etc/sysupgrade.conf as conffile
Oct 05 22:16:11 <EqUaTe> so.. where's the equivalent part in the openwrt build system? so i can try and see what i might need to adjust in order to make a suitable wnr2000 image
Oct 05 22:17:44 <xMff> tools/
Oct 05 22:18:24 <EqUaTe> firmware-utils, mkimage, or both?
Oct 05 22:18:38 <xMff> rgrep -i for wndr3700
Oct 05 22:18:47 <xMff> I don't know right now
Oct 05 22:18:57 <xMff> also check target/linux/ar71xx/image/Makefile
Oct 05 22:19:31 <EqUaTe> k. i think i'm going to have to look into these bits in more detail tomorrow, once i've had some sleep.. but knowing roughly where to look definitely helps :)
Oct 05 22:43:35 <EqUaTe> interesting.. there's only a single difference between the one with and one without crc..
Oct 05 22:43:38 <EqUaTe> for the stock firmware
Oct 05 22:47:26 <EqUaTe> it's also at the very end of the file..
Oct 05 22:49:40 <CIA-14> nunojpg * r23265 /packages/net/usbip/Makefile: [packages] usbip: minor menuconfig update
Oct 05 22:53:57 <_trine> thats where the normally header is
Oct 05 22:56:03 <EqUaTe> it's putting some info at the start (device, version, region), then the kernel, then the root fs, then the checksum from what i can see.
Oct 05 22:59:12 <_trine> its the checksum that gets checked
Oct 05 22:59:38 <_trine> to decide if its the correct file
Oct 05 23:00:10 <_trine> going to bed now
Oct 05 23:00:23 <_trine> nearly midnight
Oct 05 23:00:32 <EqUaTe> yup. bedtime for me too.
Oct 05 23:00:41 <EqUaTe> will look at this more in the morning.
Oct 05 23:00:48 <EqUaTe> night all
Oct 05 23:00:55 <_trine> goodnight
Oct 05 23:32:15 <nunojpg> the packages that depend on "@LINUX_2_6" are no longer showing
Oct 05 23:32:20 <nunojpg> was that deprecated?
Oct 05 23:32:30 <nunojpg> well, possibly because there is no longer 2.4?
Oct 05 23:32:47 <xMff> nunojpg: yes
Oct 05 23:33:00 <xMff> nunojpg: they all need to be changed to !LINUX_2_4
Oct 05 23:33:15 <xMff> @!LINUX_2_4
Oct 05 23:33:34 <nunojpg> but is 2.4 still present?
Oct 05 23:33:39 <xMff> only in backfire
Oct 05 23:33:46 <xMff> backfire and trunk share the same feeds atm
Oct 05 23:34:05 <nunojpg> ok, thanks
Oct 05 23:37:15 <xMff> nunojpg: btw, I saw your sshtunnel commit
Oct 05 23:37:44 <xMff> I think you can greatly simplify the initscript by writing a helper function to read the option and append it to the string
Oct 05 23:37:47 <xMff> *to the args
Oct 05 23:37:53 <xMff> see dnsmasq init for example
Oct 05 23:38:29 <nunojpg> for the special ssh options?
Oct 05 23:39:02 <nunojpg> (I also "commited" a wiki page)
Oct 05 23:40:09 <xMff> nunojpg: I mean all those options in load server
Oct 05 23:40:20 <xMff> and those cmd=$cmd... stuff
Oct 05 23:40:31 <xMff> you need to mention each var three times
Oct 05 23:41:04 <nunojpg> owh, right...I can make a foreach...
Oct 05 23:46:00 <xMff> something like this: http://paste.tksite.gotdns.org/d746e349b
Oct 05 23:48:23 <nunojpg> that's what I mean with "foreach", just the wrong keyword. I'm sure not a shell expert
Oct 05 23:49:09 <nunojpg> while some of the parameters are not to be used like that: user, hostname, port, debuglevel
Oct 05 23:49:44 <nunojpg> but the rest...this is the pretty obvious solution
Oct 05 23:49:49 <nunojpg> that I obviously missed:)
Oct 05 23:51:17 <nunojpg> another thing, what is the smart way to find in which file is defined "sysfsutils"?
Oct 05 23:51:43 <nunojpg> that's because this is the package that have the LINUX_2_6 dependency
Oct 05 23:51:52 <nunojpg> is there a way beside a filesystem search?
Oct 05 23:51:58 <xMff> nopwe
Oct 05 23:52:00 <xMff> nope
Oct 05 23:53:06 <philipp64|laptop> where are the package/toolchain checksums?  they're embedded in the makefiles, right?
Oct 05 23:54:08 <nunojpg> xMff: is safe to change @LINUX_2_6 to @!LINUX_2_4 in a package I don't test?
Oct 05 23:54:48 <nunojpg> if so, why don't we simply use awk to change all dependencys at once?
Oct 05 23:57:48 <CIA-14> jow * r23266 /packages/ (39 files in 39 dirs): [packages] replace @LINUX_2_6 with @!LINUX_2_4, fixes fallout after r23246
Oct 05 23:59:07 <nunojpg> Well, guess I don't have a reason to remember awk sintax today...
Oct 05 23:59:25 <xMff> for x in $(rgrep LINUX_2_6 . | grep -v .svn | cut -d: -f1 | sort -u); do sed -i -e 's/@LINUX_2_6\b/@!LINUX_2_4/g' $x; done
Oct 05 23:59:30 <xMff> I prefer sed
Oct 06 00:00:13 <philipp64|laptop> fgrep -v .svn ... or else you'll wildcard dot.
Oct 06 00:01:26 <xMff> true
Oct 06 00:01:46 <xMff> but thats four bytes more to type :P
Oct 06 00:02:11 <CIA-14> jow * r23267 /packages/ (3 files in 3 dirs): [packages] revert accidentally committed changes
Oct 06 00:03:20 <CIA-14> jow * r23268 /packages/net/speedtouch-usb-firmware/Makefile: [packages] ... and readd @!LINUX_2_4 change to speedtouch-usb-firmware
Oct 06 00:09:41 <xMff> philipp64|laptop: toolchain/gcc/common.mk has the gcc checksums
Oct 06 00:10:22 <xMff> philipp64|laptop: toolchain/*/Makefile the chksums for the other components
Oct 06 00:17:33 <philipp64|laptop> xMff: had a problem with the gcc 4.4.4 checksums when I updated to the proposed x86-GCC version bump.
Oct 06 00:17:45 <philipp64|laptop> not sure why.  restarted the build and it continued.
Oct 06 00:17:53 <xMff> odd
Oct 06 01:51:15 <RealOpty> xMff, i noticed that pciutils got updated to latest version :)
Oct 06 01:51:33 <RealOpty> gonna test it out on the netgear again
**** ENDING LOGGING AT Wed Oct 06 02:59:57 2010