**** BEGIN LOGGING AT Mon Aug 06 02:59:57 2007
Aug 06 13:24:43 <CIA-13> florian * r8347 /packages/net/srelay/Makefile: Fix the libwrap dependency for srelay (#2175)
Aug 06 14:15:54 <CIA-13> florian * r8348 /trunk/target/linux/rdc-2.6/ (15 files in 9 dirs): Add generic gpio support to rdc, convert the led driver to be a platform driver, need to convert the flash driver as well
Aug 06 15:14:28 <crazy_imp> [florian]: ping
Aug 06 15:23:36 <[florian]> crazy_imp: pong
Aug 06 15:26:23 <crazy_imp> [florian]: i'm a little bit confused about the sed line in the gnutls makefile. why only fixing it in gnutls-extra.pc and not gnutls.pc? and is it really needed to change the path there, because the glib.pc file doesn't have changed lines in there?
Aug 06 15:27:21 <[florian]> crazy_imp: I think the sed line should apply to both gnutls.pc and gnutls-extra, for glib.pc it is missing
Aug 06 15:27:33 <[florian]> crazy_imp: remember that it is only useful when using pkgconfig
Aug 06 15:27:34 <crazy_imp> just wondering because i extend the glib2 makefile a bit, want to know if i need to change the lines in there too or if it's fine without
Aug 06 15:28:52 <crazy_imp> [florian]: ok, so i'll add some lines to the makefile from glib2 :)
Aug 06 15:28:58 <[florian]> yes
Aug 06 15:29:31 <crazy_imp> at the moment the sed lines in the gnutls makefile are only for gnutls-extra.pc
Aug 06 15:35:14 <[florian]> feel free to fix it for gnutls.pc as well
Aug 06 15:35:54 <crazy_imp> [florian]: would do it if i had complete write access to svn :|
Aug 06 15:37:46 <[florian]> crazy_imp: provide a diff, and we will see that
Aug 06 15:54:03 <CIA-13> crazy_imp * r8349 /packages/libs/glib2/Makefile:
Aug 06 15:54:03 <CIA-13> - add: gmodule, gobject and gthread (now the package includes the same libs like glib1 does)
Aug 06 15:54:03 <CIA-13> - include the pkgconfig stuff into the InstallDev part
Aug 06 15:54:03 <CIA-13> - fix the UninstallDev part (it removed the glib1 files as well)
Aug 06 15:59:33 <sn9> [florian]: ping
Aug 06 16:07:48 <crazy_imp> [florian]: http://pastebin.ca/647629 (iirc i ran into problems once when i tried to use {,foo} so it's {s,s-extra} now :)
Aug 06 16:17:07 <CIA-13> florian * r8350 /trunk/docs/network.tex: Fix the option dns usages (#2174)
Aug 06 17:20:37 <sn9> [florian]: ping
Aug 06 17:25:45 <CIA-13> juhosg * r8351 /trunk/target/linux/adm5120-2.6/files/ (2 files in 2 dirs): [adm5120] add special values for GPIO lines in switch
Aug 06 17:38:36 <CIA-13> juhosg * r8352 /trunk/tools/firmware-utils/src/ (mkcsysimg.c mkmylofw.c mkzynfw.c): remove case sensitivity from the board name checking
Aug 06 17:55:59 <[florian]> sn9: pong
Aug 06 17:57:29 <crazy_imp> [florian]: got my pastebin?
Aug 06 17:58:33 <[florian]> crazy_imp: not yet
Aug 06 17:58:40 <sn9> <[florian]> ok, no way we add binaries to svn
Aug 06 17:58:40 <sn9> <sn9> [florian]: what do you mean, no binaries? those same binaries are already in svn in the rt61 pkg!
Aug 06 17:58:40 <sn9> <sn9> just copy them within the tree
Aug 06 17:58:40 <sn9> <sn9> you can at least commit the rest of the patch, except perhaps the removal of the "broken" flag
Aug 06 17:59:09 <crazy_imp> [florian]: http://pastebin.ca/647629 (iirc i ran into problems once when i tried to use {,foo} so it's {s,s-extra} now :)
Aug 06 17:59:35 <[florian]> crazy_imp: I think it is because you use a sed command
Aug 06 18:00:27 <[florian]> sn9: put the rt2x00 sources in a tarball
Aug 06 18:00:45 <sn9> why?
Aug 06 18:01:06 <[florian]> sn9: because I do not want to add the firmware blobs in the svn
Aug 06 18:01:22 <sn9> they are already in svn as individual files
Aug 06 18:01:29 <sn9> in the rt61 pkg
Aug 06 18:02:37 <[florian]> sn9: will see that
Aug 06 18:02:53 <[florian]> sn9: I am trying to figure out why my gcc4 build was broken
Aug 06 18:03:18 <sn9> scratch that, it seems rt61 is a tarball
Aug 06 18:04:56 <sn9> ok, i will make it a tarball in the next patch, but it won't be cumulative, so a commit of the non-binary changes for now would be much appreciated
Aug 06 18:05:24 <[florian]> I am not sure the other devs will appreciate it
Aug 06 18:06:05 <sn9> do a disctlean, and redownload http://homepage.mac.com/danielg4/rdc.config for your .config
Aug 06 18:06:07 <[florian]> sn9: by the way, do you have the gpio line numbers other than the dms led ?
Aug 06 18:06:26 <[florian]> s/dms/dmz/
Aug 06 18:06:41 <sn9> i think dmz is 1 and reset is 0, but i need to experiment with that
Aug 06 18:07:52 <[florian]> ok, by the way, I put back som code from the old rdc driver that is supposed to "boost" the network perfs
Aug 06 18:07:53 <sn9> i don't know where you got the 15 and 16 that were in the led driver before
Aug 06 18:08:18 <sn9> from my older patch? i saw that
Aug 06 18:08:21 <[florian]> sn9: from the old led.c code that was in the mach-rdc/
Aug 06 18:08:25 <[florian]> it was just crap
Aug 06 18:08:36 <[florian]> also, I need to test the wachtdog stuff
Aug 06 18:08:45 <[florian]> according to the datasheet there is one
Aug 06 18:08:54 <sn9> i don't know where you got that led.c file
Aug 06 18:09:04 <[florian]> sn9: from the wrt54gr tarball
Aug 06 18:09:08 <[florian]> or any other name
Aug 06 18:09:17 <sn9> ok...
Aug 06 18:09:26 <[florian]> it was just crap
Aug 06 18:09:28 <[florian]> really
Aug 06 18:09:53 <sn9> obviously, the linksys led's are on different gpio lines
Aug 06 18:09:55 <[florian]> I would like to have the reset button working so that we can have failsafe working with that device
Aug 06 18:10:09 <sn9> same here
Aug 06 18:10:23 <[florian]> absolutely, though I never saw someone wanting to port the linksys to rdc-2.6
Aug 06 18:10:30 <[florian]> maybe the device was hardly sold out
Aug 06 18:10:35 <matteo> [florian]: i have still to use disable_napi on ar7
Aug 06 18:11:03 <sn9> i propose providing a userspace access layer to all gpio lines through sysfs
Aug 06 18:11:51 <[florian]> sn9: for the led, this is already the case, but iirc we are lacking a similar API for buttons
Aug 06 18:11:59 <[florian]> matteo: ok, will disable it by default
Aug 06 18:12:23 <matteo> [florian]: we have no other options
Aug 06 18:12:26 <sn9> the airlink101 firmware has a userspace daemon that keeps polling the reset gpio, and executing a file if it goes low
Aug 06 18:13:12 <sn9> i expect that the button gpio would be read with the same api as one would use to read led state
Aug 06 18:13:19 <CIA-13> florian * r8353 /trunk/target/linux/ar7-2.6/files/drivers/net/cpmac.c: Disable NAPI by default (#1671)
Aug 06 18:14:13 <nbd> [florian]: why did you do that?
Aug 06 18:14:51 <nbd> go fix the real problem instead, disabling napi causes other issues
Aug 06 18:15:24 <matteo> nbd: issues like?
Aug 06 18:15:34 <[florian]> nbd: emmr ok
Aug 06 18:15:38 <nbd> worse behavior under load
Aug 06 18:15:50 <nbd> because skb allocation in irq context can fail more frequently
Aug 06 18:16:58 <[florian]> ok, will revert that change and see that later
Aug 06 18:17:10 <[florian]> nbd: I would like fixing ar7 during the ccc camp
Aug 06 18:17:16 <nbd> yeah
Aug 06 18:17:22 <nbd> maybe we can do a small hackathon ;)
Aug 06 18:17:23 <sn9> <[florian]> I am not sure the other devs will appreciate it <-- what other platform uses rt2x00 atm?
Aug 06 18:17:32 <nbd> i hope blogic will be able to make it as well
Aug 06 18:17:32 <[mbm]> isn't ccc starting now?
Aug 06 18:17:37 <nbd> yeah
Aug 06 18:17:42 <nbd> i'll be there tomorrow
Aug 06 18:17:43 <[florian]> nbd: will bring several tnetd devices
Aug 06 18:19:29 <[florian]> sn9: ok, let's commit your current rdc patchset, then we convert the source to a tarball
Aug 06 18:20:15 <sn9> i want to test a couple of other snapshots of the source before making the tarball
Aug 06 18:20:50 <sn9> the git source has an irq problem
Aug 06 18:22:09 <sn9> but, the current proposed commit fixes much more
Aug 06 18:23:11 <[florian]> ok
Aug 06 18:26:07 <sn9> don't forget to put the "broken" tag back, as it will not build anymore without the binaries
Aug 06 18:28:25 <[florian]> sn9: can you do some iperf tests for me ?
Aug 06 18:28:33 <sn9> iperf?
Aug 06 18:29:00 <[florian]> yes, it is a program to test network performance
Aug 06 18:29:03 <sn9> oh
Aug 06 18:29:27 <sn9> maybe after i get the wifi working correctly
Aug 06 18:29:30 <[florian]> sure
Aug 06 18:29:47 <[florian]> ermm, I could just rebuild a driver withouth the differences and do the test myself
Aug 06 18:30:08 <sn9> which differences?
Aug 06 18:30:25 <[florian]> will pastebin it
Aug 06 18:30:28 <sn9> ok
Aug 06 18:32:20 <[florian]> http://openwrt.pastebin.ca/647769
Aug 06 18:33:59 <sn9> the first hunk seems to consist entirely of whitespace differences
Aug 06 18:34:15 <[florian]> absolutely, this was just for reading purposes
Aug 06 18:34:51 <sn9> offhand, i don't recognize what the second one is supposed to do
Aug 06 18:35:08 <[florian]> neither am I, just I found it to belong to the old driver
Aug 06 18:35:39 <sn9> ok, good
Aug 06 18:35:43 <[florian]> and this does not seem to have noticeable side effects, but I am not sure about the perf increase
Aug 06 18:36:10 <sn9> i thought i copied over everything from the old driver that was missing
Aug 06 18:36:50 <sn9> the ioctl code needs major cleaning up to conform to your new platform driver
Aug 06 18:37:11 <[florian]> yes, and maybe we could get more infos from the phy
Aug 06 18:37:12 <sn9> incidentally, your FLASH_BASE constant is incorrectly defined
Aug 06 18:37:37 <sn9> it should simply be the two's complement of the size
Aug 06 18:37:59 <sn9> this is because the powerup eip is 0xfffffff0
Aug 06 18:38:35 <[florian]> ok, the 2.4 kernel reported this flash base address
Aug 06 18:38:49 <sn9> on a 4MB device, yes
Aug 06 18:38:52 <[florian]> but in your flash map driver, I could not see a defined window addr for it
Aug 06 18:39:00 <[florian]> yes, for 2mb, this would change
Aug 06 18:39:26 <sn9> that address is the two's complement of 4MB
Aug 06 18:39:27 <crazy_imp> my rdc device has only 2mb
Aug 06 18:39:50 <sn9> crazy_imp: yes, and [florian] just broke that portion of the support for it
Aug 06 18:40:15 <[florian]> sn9: no, because the flash map driver does not make use of that platform_device definition
Aug 06 18:40:29 <sn9> right
Aug 06 18:40:30 <CIA-13> florian * r8354 /trunk/target/linux/rdc-2.6/files/drivers/net/r6040.c: Put back some code from the 2.4 driver, supposed to boot network perfs
Aug 06 18:40:47 <[florian]> sn9: and I rather would like to have a  runtime detection of the board, so that the flash map driver can become a real platform_device
Aug 06 18:41:11 <sn9> runtime detection means the two's complement of the size here
Aug 06 18:41:49 <[florian]> sn9: and we can read the size using cfi I hope ?
Aug 06 18:42:12 <sn9> in order to read that, you need the base -- chicken and egg
Aug 06 18:42:26 <[florian]> erm, yes
Aug 06 18:42:46 <sn9> the kernel config really is the best place for the size
Aug 06 18:42:47 <[florian]> so this must be a compile time definition
Aug 06 18:43:28 <[florian]> sn9: I hope we could read some register to read the flash size, or that 4mb devices use another gpio line for instance
Aug 06 18:43:39 <[florian]> s/hope/wish/
Aug 06 18:44:06 <sn9> gpio definitions are entirely board-dependent, and have nothing to do with flash size
Aug 06 18:44:40 <[florian]> for that particular board maybe, this is not the case for all archs
Aug 06 18:44:56 <sn9> devices may have the same flash size, yet completely different gpio lines on this platform
Aug 06 18:45:40 <sn9> at least, it looks that way to me atm
Aug 06 18:48:56 <CIA-13> florian * r8355 /trunk/ (11 files in 7 dirs): More rdc-2.6 fixes by Daniel Gimpelevich, thanks !
Aug 06 18:49:47 <[florian]> sn9: I missed the firmware, will add them
Aug 06 18:50:03 <sn9> you can wait on that
Aug 06 18:50:30 <CIA-13> florian * r8356 /trunk/target/linux/rdc-2.6/Makefile: Still broken for now
Aug 06 18:56:00 <sn9> [florian]: you forgot package/kernel/modules/wireless.mk
Aug 06 18:56:38 <CIA-13> florian * r8357 /trunk/target/linux/rdc-2.6/files/drivers/net/r6040.c: Remove the LED code from the network driver
Aug 06 18:58:03 <[florian]> sn9: I need to check if there are no targets making use of that package
Aug 06 18:58:20 <sn9> you misunderstand
Aug 06 18:58:33 <sn9> that patch is a fix for brokenness in the build
Aug 06 18:58:53 <sn9> the package appears twice as it is
Aug 06 18:59:18 <[florian]> right, because we have the in-kernel package and another one for not yet migrated to .222 devices
Aug 06 18:59:21 <[florian]> .22 sorry
Aug 06 19:00:28 <sn9> the in-kernel is a conflict and needs to be removed
Aug 06 19:01:35 <sn9> also, the "if(args[0]&(1<<23))" line should not be removed wholesale until we can be sure of how it really works
Aug 06 19:02:08 <sn9> the in-kernel mac80211 should not be used
Aug 06 19:02:30 <[florian]> sn9: it is useless from what I could test
Aug 06 19:02:42 <sn9> which?
Aug 06 19:02:53 <[florian]> sn9: 1<<23
Aug 06 19:03:10 <sn9> you tested the ioctl?
Aug 06 19:03:55 <[florian]> I tested the led stuff
Aug 06 19:04:08 <[florian]> I do not care about the ioctl, it is bogus in its current state
Aug 06 19:04:58 <[florian]> and it lacks things like SIOCGMII and friends
Aug 06 19:06:00 <sn9> the 1<<23 is in reference to the ioctl param. we should only kill that once we have reasonable replacements ready
Aug 06 19:07:26 <[florian]> we do not make use of the ioctl param right now
Aug 06 19:07:59 <sn9> nor do we have a replacement for dmz led control
Aug 06 19:08:18 <[florian]> we do, have you tried the led driver with gpio=1 as a module parameter ?
Aug 06 19:08:25 <sn9> not yet
Aug 06 19:08:36 <sn9> oh, it's a .ko?
Aug 06 19:08:43 <[florian]> yes
Aug 06 19:08:51 <sn9> i thought it was getting compiled in
Aug 06 19:09:04 <[florian]> well, the gpio part is, but not the led driver
Aug 06 19:09:15 <[florian]> thus allowing us to test other gpio lines
Aug 06 19:09:28 <sn9> but only led's
Aug 06 19:09:43 <sn9> sysfs is a better way to test
Aug 06 19:09:56 <[florian]> yes, leds are exposed to sysfs as a linux led device
Aug 06 19:10:07 <[florian]> in /sys/class/leds/<led-name>
Aug 06 19:10:34 <sn9> no, i mean sysfs should be able to access ALL gpio lines, not just led ones
Aug 06 19:10:57 <[florian]> well, this is for later
Aug 06 19:11:14 <sn9> it is essential for reset button functionality
Aug 06 19:11:51 <[florian]> absolutely, as I said before, this needs a custom button implementation
Aug 06 19:12:13 <sn9> yes, but built upon generic gpio access over sysfs
Aug 06 19:12:45 <sn9> right?
Aug 06 19:12:58 <[florian]> absolutey
Aug 06 19:13:10 <[florian]> the linux kernel lacks generic button API
Aug 06 19:13:26 <[florian]> exposed to sysfs
Aug 06 19:13:45 <sn9> platform gpio driver could do that
Aug 06 19:13:54 <[florian]> yes
Aug 06 19:25:08 <CIA-13> florian * r8358 /trunk/target/linux/rdc-2.6/files/drivers/leds/leds-rdc3211.c: More led driver fixes
Aug 06 19:35:23 <sn9> [florian]: i don't see the led .ko
Aug 06 19:41:00 <[florian]> sn9: it is not packaged by default, it is in build_i386/linux/drivers/leds/
Aug 06 19:41:13 <sn9> ok
Aug 06 19:41:22 <sn9> gotta fix that
Aug 06 19:43:04 <[florian]> sn9: it will be buit-in the kernel soon
Aug 06 19:43:23 <sn9> oh, ok
Aug 06 19:43:43 <CIA-13> florian * r8359 /trunk/ (2 files in 2 dirs): Allow rdc-2.6 to kexec
Aug 06 19:43:57 <[florian]> so that we can have diag.sh, like other targets do
Aug 06 19:44:42 <sn9> i got a better rt2x00 snapshot; testing now. is there some kind if iwconfig command to control essid broadcast in master mode?
Aug 06 19:45:36 <sn9> the irq problem is gone, but i still can't associate
Aug 06 19:47:08 <[florian]> I do not remember how do you set the ssid broadcast
Aug 06 19:50:35 <sn9> hmm, can't associate in client mode, either
Aug 06 19:50:42 <[florian]> this is bad
Aug 06 19:50:54 <sn9> it's not committed yet
Aug 06 19:51:10 <sn9> the svn version oopses
Aug 06 19:53:22 <sn9> btw, the current firmware license does not allow what the rt61 pkg is doing
Aug 06 19:56:58 <sn9> oh, wait, managed mode works. i forgot to bring up the interface. duh!
**** BEGIN LOGGING AT Mon Aug 06 20:10:29 2007
Aug 06 20:26:22 <[florian]> sn9: so it works fine with your snapshot ?
Aug 06 20:26:54 <sn9> managed, yes. for master, i realized i had no hostapd
Aug 06 20:27:53 <sn9> also, i forgot to make target/linux/rdc-2.6-clean, so the new led driver did not get compiled. rebuilding the image now...
Aug 06 20:28:07 <CIA-13> florian * r8360 /trunk/target/linux/rdc-2.6/files/drivers/net/r6040.c: Prevent the ioctl from handling even unsupported ioctls
Aug 06 20:28:09 <[florian]> ah ok
Aug 06 20:28:19 <sn9> i mean make target/linux-clean
Aug 06 20:32:57 <sn9> btw, which pkg conatins the portmapper for an nfs client?
Aug 06 20:33:24 <[florian]> nfs-utils
Aug 06 20:33:58 <[florian]> ermm, no
Aug 06 20:34:14 <[florian]> portmap
Aug 06 20:34:42 <sn9> i don't see that pkg
Aug 06 20:35:03 <[florian]> it is in the packages/
Aug 06 20:35:08 <[florian]> svn repository
Aug 06 20:35:31 <sn9> so, i can't put it in the squash?
Aug 06 20:36:39 <[florian]> you can, use make package/symlinks, it will checkout the repository and packages will appear in menuconfig
Aug 06 20:37:54 <sn9> is that also in the pkgs repo only?
Aug 06 20:39:22 <[florian]> our convention is : every package that does not closely depend on kernel version goes into the packages/ repository
Aug 06 20:39:29 <[florian]> every other in in trunk/package
Aug 06 20:39:55 <sn9> what about the "symlinks" one?
Aug 06 20:40:04 <[florian]> this is just a special target
Aug 06 20:40:21 <sn9> ah, ok
Aug 06 20:42:52 <[florian]> sorry, should have began with that
Aug 06 20:44:43 <crazy_imp> [florian]: thought all the extra stuff (besides the basic stuff for a router) is  in packages/
Aug 06 20:45:55 <[florian]> crazy_imp: absolutely, which more or less corresponds to kernel-related software
Aug 06 20:46:14 <sn9> busybox has no portmap?
Aug 06 20:46:56 <[florian]> sn9: not that I know of
Aug 06 20:47:21 <sn9> so, it'll use the general one?
Aug 06 20:47:24 <[florian]> sn9: any objections if I do not put the header as part of the linux mtd partition
Aug 06 20:47:27 <[florian]> sn9: yes
Aug 06 20:47:53 <sn9> yes, do not leave out the image header
Aug 06 20:48:13 <[florian]> sn9: so that I can use kexec from flash
Aug 06 20:48:46 <sn9> you'll have to kexec something other than the kernel in the flash
Aug 06 20:49:29 <sn9> otherwise, you compromise either the interaction with redboot, or the erasesize alignment, if not both
Aug 06 20:49:58 <[florian]> it does work fine when using the bzImage in bin/
Aug 06 20:50:15 <[florian]> which is the same kernel as the one written on the flash, right ?
Aug 06 20:50:25 <sn9> except for the header
Aug 06 20:55:22 <Weedy> anyone else running the latest trunk with pppoe?
Aug 06 20:55:22 <Weedy> not passing traffic anymore
Aug 06 20:56:03 <[florian]> sn9: this is why I want to remove it
Aug 06 20:56:30 <sn9> then, you compromise either the interaction with redboot, or the erasesize alignment, if not both
Aug 06 20:56:55 <[florian]> sn9: the mtd layout is not the same as what redboot sees
Aug 06 20:57:18 <sn9> redboot sees the whole flash as one thing
Aug 06 20:57:47 <loswillios> Weedy: I noticed too
Aug 06 20:58:43 <[florian]> yes, but I do not intend to modify the flash, just presend something else to the kernel, or am I missing something ?
Aug 06 20:58:59 <[florian]> I just want to avoid exposing the header in the linux partition
Aug 06 20:59:22 <sn9> you would lose the ability to reflash the kernel from within openwrt
Aug 06 20:59:28 <Weedy> 64.230.197.224  *               255.255.255.255 UH    0      0        0 ppp0
Aug 06 20:59:28 <Weedy> 192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
Aug 06 20:59:28 <Weedy> default         64.230.197.224  0.0.0.0         UG    0      0        0 ppp0
Aug 06 20:59:39 <Weedy> the routes look fine to me
Aug 06 20:59:58 <loswillios> ipv4_forward is set too
Aug 06 21:00:05 <Weedy> loswillios, funny thing is it thinks eth0.1 is $WAN
Aug 06 21:00:16 <Weedy> normally is pp0
Aug 06 21:00:18 <Weedy> ppp0*
Aug 06 21:00:37 <loswillios> how did you notice?
Aug 06 21:02:03 <thepeople_work> Weedy: I bet https://dev.openwrt.org/changeset/8343 will fix it for you
Aug 06 21:02:50 <Weedy> thepeople_work, yeah im already doing that
Aug 06 21:03:01 <Weedy> loswillios, my firewall script stopped working
Aug 06 21:03:55 <Weedy> thepeople_work, yop
Aug 06 21:03:59 <Weedy> yup**
Aug 06 21:04:23 <[florian]> sn9: yes, but then we should probably add another partition, name "hdr" for instance, the flashing utility updates when flashing a new kernel
Aug 06 21:05:01 <sn9> better to only add a new partition for kexec
Aug 06 21:05:41 <sn9> what do you want kexec for, anyway?
Aug 06 21:07:06 <Weedy> thepeople_work, guess its bug filing time
Aug 06 21:10:35 <thepeople_work> Weedy: yep
Aug 06 21:10:51 * Weedy stabs nbd 
Aug 06 21:12:53 <[florian]> sn9: reflashing more quickly, it is just for proof of concept actually
Aug 06 21:13:06 <sn9> don't bother, then
Aug 06 21:17:40 <[florian]> anyway, the linux partition should not contain anything than the kernel
Aug 06 21:19:48 <sn9> it should also contain the rootfs
Aug 06 21:20:01 <sn9> for the same reasons as the header
Aug 06 21:21:03 <[florian]> I'd rather have the rootfs on a separate partition
Aug 06 21:21:32 <[florian]> and handle the header the same way the bcm947xx map does with the trx header
Aug 06 21:22:08 <sn9> the rootfs is also a separate read-only partition
Aug 06 21:22:30 <sn9> the linux partition should be considered "write-only"
Aug 06 21:22:51 <[florian]> why not read-write ?
Aug 06 21:23:15 <sn9> what do you want to read from there, aside from the bzImage?
Aug 06 21:30:30 <[florian]> sn9: nothing more
Aug 06 21:34:05 <[florian]> sn9: we can have a partition in which we have header+kernel+rootfs and having two others for the kernel and the rootfs
Aug 06 21:34:30 <sn9> the only use for the kernel one is kexec
Aug 06 21:35:27 <sn9> and you can use kece without it
Aug 06 21:35:31 <sn9> *kexec
Aug 06 21:39:57 <[florian]> sn9: how ?
Aug 06 21:40:06 <sn9> loopback device
Aug 06 21:41:29 <[florian]> and which filesystem would you use ?
Aug 06 21:41:35 <sn9> none
Aug 06 21:41:39 <sn9> just losetup
Aug 06 21:42:10 <[florian]> can you specify mounting it using an offset from the start of the mtd partition ?
Aug 06 21:42:21 <sn9> that's the idea
Aug 06 21:42:41 <sn9> no need to mount, either. just losetup
Aug 06 21:42:49 <matteo> are you experimenting kexec with openwrt?
Aug 06 21:42:54 <matteo> isn't it x86 only?
Aug 06 21:42:54 <[florian]> yes
Aug 06 21:42:55 <sn9> he is
Aug 06 21:43:06 <sn9> rdc-2.6 is x86
Aug 06 21:43:21 <matteo> there is the kconfig option for mips
Aug 06 21:43:28 <matteo> just the tools doesn't compiles
Aug 06 21:43:30 <[florian]> matteo: not only, it works for ppc, sparc, and more recently with mips, see http://lists.infradead.org/pipermail/kexec/2007-June/000214.html
Aug 06 21:43:39 <sn9> ppc? really?
Aug 06 21:43:50 <[florian]> sn9: yes, seems so
Aug 06 21:45:27 <[florian]> sn9: losetup seems to be what I want, just is there any reason the header is included in the kernel partition, this was the rationale of my question
Aug 06 21:45:41 <sn9> i think i answered that
Aug 06 21:46:43 <sn9> it is not a "kernel" partition, it's a "linux" (header+kernel+rootfs) partition
Aug 06 21:47:23 <sn9> wtf?? why does sshfs require glib?
Aug 06 21:47:40 <[florian]> the new version is now using glib
Aug 06 21:47:49 <sn9> glib fails to build
Aug 06 21:47:59 <[florian]> ah, fill me with a pastebin
Aug 06 21:48:04 <sn9> ok
Aug 06 21:53:05 <sn9> http://openwrt.pastebin.ca/648009
Aug 06 21:54:49 <[florian]> sounds like they missing an echo
Aug 06 21:59:35 <sn9> i doubt this is arch-specific
Aug 06 22:00:09 <[florian]> this does not seem to be arch specific
Aug 06 22:00:52 <crazy_imp> hmmm, it builds fine here, just checked it again right now
Aug 06 22:01:18 <crazy_imp> (building for rdc, but may i should update my trunk and test again)
Aug 06 22:02:37 <sn9> crazy_imp: which gcc?
Aug 06 22:02:55 <crazy_imp> ggc-4.1.2
Aug 06 22:03:05 <crazy_imp> s/ggc/gcc/
Aug 06 22:03:26 <sn9> same as here
Aug 06 22:03:44 <sn9> bizarre
Aug 06 22:03:52 <crazy_imp> indeed
Aug 06 22:04:15 <crazy_imp> think i build it 6 or 7 times today here
Aug 06 22:07:27 <sn9> [florian]: any ideas?
Aug 06 22:07:37 <[florian]> sn9: will retry here
Aug 06 22:10:37 <[florian]> crazy_imp: this really seems related to your change in the afternoon :/
Aug 06 22:10:59 <crazy_imp> sn9: the output i get if i run a second time "make package/libs/glib2-compile V=99" looks quite different here
Aug 06 22:12:07 <crazy_imp> [florian]: hmm, maybe, it's building the complete glib now
Aug 06 22:12:26 <crazy_imp> [florian]: do you get the same error?
Aug 06 22:12:36 <[florian]> crazy_imp: will tell you in few secs
Aug 06 22:12:54 * crazy_imp will give it another try with another arch
Aug 06 22:14:19 * sn9 fails to understand the change crazy_imp made in line 49
Aug 06 22:14:53 <[florian]> it works fine
Aug 06 22:15:21 <sn9> then what could have happened?
Aug 06 22:15:35 <[florian]> make package/glib2-{clean,compile} V=99
Aug 06 22:16:25 <crazy_imp> sn9: removed the /glib, now it's building gmodule, gthread and gobject (think it's what you where wondering about, right?)
Aug 06 22:16:31 <sn9> yes
Aug 06 22:16:39 <sn9> make[1]: *** No rule to make target `package/glib2-clean'.  Stop.
Aug 06 22:17:05 <[florian]> sn9: in your case it probably is make package/libs/glib2-{clean,compile} V=99
Aug 06 22:17:44 <[florian]> crazy_imp: it builds fine again
Aug 06 22:19:58 <crazy_imp> [florian]: nice to hear :), think sn9 maybe updated the svn and somehow the buildsystem missed to rebuild glib2 and it ran into this problem (but i normally trust the buildsystem :)
Aug 06 22:20:26 <sn9> no
Aug 06 22:21:24 <[florian]> maybe a shell issue ?
Aug 06 22:22:22 <sn9> http://openwrt.pastebin.ca/648051
Aug 06 22:23:13 <[florian]> there really is a missing echo
Aug 06 22:23:24 <[florian]> it should be echo "no ..."
Aug 06 22:23:44 <sn9> any idea where that is?
Aug 06 22:24:44 <crazy_imp> [florian]: but why doesn't this show up on our systems?
Aug 06 22:29:58 <[florian]> crazy_imp: maybe because I use zsh
Aug 06 22:30:06 <[florian]> have to go sleeping
Aug 06 22:30:16 <crazy_imp> hehe, i use zsh too :D
Aug 06 22:30:23 <sn9> bash here
Aug 06 22:30:59 <sn9> i expect more ppl who build would use bash than zsh
Aug 06 22:31:33 <crazy_imp> hmmm, so it should break if i build it in bash... lets see :)
Aug 06 22:32:06 <sn9> assuming it does, how will that help track down the bug?
Aug 06 22:33:44 <crazy_imp> well, if it fails with bash here we have a real problem, if not, we have to hunt the bug in your system i think
Aug 06 22:35:36 <crazy_imp> (and i don't have anything here named "no" which it could execute)
Aug 06 22:37:16 <crazy_imp> sn9: http://pastebin.ca/648070
Aug 06 22:41:18 <crazy_imp> hmmm, may it's some wicked build time dep we found. compare line 8 from my pastebin with line 928 in yours, think "no" got replaced in my build
Aug 06 22:48:21 <sn9> i figured it out
Aug 06 22:48:36 <crazy_imp> and there the bug is, line 379 in your pastebin, it doesn't find glib-genmarshal on your system. think the returnvalue got in the config stuff because of my patch, give me some time and i'll fix it. think you'll need glib2 on your system
Aug 06 22:49:16 <sn9> in order to cross-compile glib2, one needs to have glib2 dev pkgs installed on the host. great.
Aug 06 22:51:10 <sn9> :(
Aug 06 22:52:17 <crazy_imp> indeed, same crap with the ruby package for example, you'll need ruby on your system to build it
Aug 06 22:55:10 <matteo> [florian]: the new AR7 DSL driver is connected since 6 hours
Aug 06 22:56:10 <matteo> can I have an @openwrt.org mail?
Aug 06 22:57:36 <crazy_imp> sn9: think only build /glib without it was fine but due the new changes it's needed
Aug 06 22:58:09 <crazy_imp> sn9: how is the glib2 devel package exactly named in your package manager?
Aug 06 22:58:21 <sn9> checking now
Aug 06 22:59:18 <sn9> libglib2.0-dev
Aug 06 23:10:16 <CIA-13> crazy_imp * r8361 /packages/libs/glib2/ (Makefile patches/):
Aug 06 23:10:16 <CIA-13> glib2 now needs the dev package from glib 2.0 installed on the host,
Aug 06 23:10:16 <CIA-13> thanks to sn9 for coming up with the problem :). nuke the patch
Aug 06 23:10:16 <CIA-13> which hide the problem.
Aug 07 00:04:24 <CIA-13> nbd * r8362 /trunk/ (45 files in 36 dirs): build system cleanup/restructuring as described in http://lists.openwrt.org/pipermail/openwrt-devel/2007-August/001159.html
Aug 07 00:06:10 <sn9> could somebody please update hostapd from 0.5.7 to 0.5.8? TIA
Aug 07 00:07:46 <CIA-13> nbd * r8363 /trunk/ (. .gitignore): update svn and git ignore settings
Aug 07 00:09:50 <sn9> nbd: maybe you?
Aug 07 00:10:09 * nbd needs sleep now
Aug 07 00:10:44 <sn9> ok, who's awake?
**** ENDING LOGGING AT Tue Aug 07 02:59:57 2007