**** BEGIN LOGGING AT Tue Jan 18 02:59:57 2011
Jan 18 05:51:46 <philipp64|laptop> jow_laptop: ping
Jan 18 05:52:56 <philipp64|laptop> cshore: you around?
Jan 18 05:57:05 <cshore> Actually, I just noticed your message...so you're in luck :)
Jan 18 05:58:16 <cshore> I've been busy sending notes to old profs and such.  Reconnecting with university days a little I hope.
Jan 18 06:00:19 <philipp64|laptop> wanted to ask... how do I make the kmod-solos driver select the solospci package?
Jan 18 06:01:08 <cshore> there should be a depends line in the kmod package definition IIRC
Jan 18 06:02:01 <cshore> take a look at mac80211 or cfg80211 - one of them depends on iw and/or crda and/or wireless-tools
Jan 18 06:51:06 <philipp64|laptop> cshore: I looked but didn't see it.
Jan 18 06:55:40 <cshore> hmmm....ok, I'll look
Jan 18 07:00:43 <philipp64|laptop> I noticed certain profiles have "wireless-tools" listed... but the problem is that any platform with a PCI or PCI-e slot could have a wireless or Solos card...
Jan 18 07:00:54 <cshore> ah, mac80211 is done as a separate package not under package/kernel
Jan 18 07:01:04 <cshore> package/mac80211
Jan 18 07:01:14 <cshore> but it's similar to under package/mac80211
Jan 18 07:01:18 <cshore> sorry package/kernel
Jan 18 07:02:11 <cshore> define KernelPackage/nameofpackage
Jan 18 07:02:11 <cshore>   stuff
Jan 18 07:02:11 <cshore>   DEPENDS+= somepackage
Jan 18 07:02:11 <cshore>   stuff
Jan 18 07:02:11 <cshore> endef
Jan 18 07:02:43 <philipp64|laptop> did you see the patch I posted?
Jan 18 07:02:50 <cshore> no, let me look
Jan 18 07:02:55 <philipp64|laptop> Kaloz didn't think it was right.
Jan 18 07:04:15 <cshore> Er, we do it for wireless
Jan 18 07:04:22 <cshore> Kaloz is wrong I think
Jan 18 07:07:13 <philipp64|laptop> ok. want to commit?  it's a one liner...
Jan 18 07:07:32 <philipp64|laptop> I'm inclined to agree with you...
Jan 18 07:08:02 <philipp64|laptop> if mac80211 requires iw + crda, then it's not unreasonable for solos to require soloscli...
Jan 18 07:08:10 <cshore> I agree
Jan 18 07:11:39 <cshore> I get a reject
Jan 18 07:14:38 <CIA-77> cshore * r25034 /trunk/package/kernel/modules/netdevices.mk: [kernel] solos-pci: Depend on soloscli, just like mac80211 depends on iw and crda, since in both cases the module is useless without the userspace.
Jan 18 07:17:32 <philipp64|laptop> got another question for you...
Jan 18 07:18:01 <philipp64|laptop> If I use 2.6.35.7 with the drivers/char/cs5535_gpio.c driver then everything works fine.
Jan 18 07:18:01 <cshore> ok
Jan 18 07:18:49 <philipp64|laptop> if I use 2.6.37 with the drivers/gpio/cs5535_gpio.c driver, however, then none of the /dev/cs5535_gpioXX devices don't get created.
Jan 18 07:19:23 <philipp64|laptop> I through a "exec logger ..." line into /etc/hotplug2-common.rules file, and I see that %MAJOR% and %MINOR% aren't being set.
Jan 18 07:20:07 <philipp64|laptop> so I'm not sure if the problem is with 2.6.37 or with the drivers/gpio version versus drivers/char/
Jan 18 07:20:17 <philipp64|laptop> building 2.6.37 with drivers/char now...
Jan 18 07:21:30 <cshore> I'm not sure gpio stuff generates the right hotplug events (or info for them).   Simply not sure, though, not able to give you a definitive answer
Jan 18 07:23:05 <philipp64|laptop> with m-i-t that stuff comes from "alias block-major-55 foo" in the modules.d files... but since we don't have m-i-t...
Jan 18 07:23:21 <philipp64|laptop> (modules-init-tools)
Jan 18 07:23:44 <cshore> ah, that could be
Jan 18 07:24:08 <cshore> because the system doesn't know that the module has anything to do with the block device
Jan 18 07:24:11 <cshore> ?
Jan 18 07:24:14 <philipp64|laptop> not sure how it gets generated currently... it's all voodoo to me.
Jan 18 07:24:21 <cshore> or rather char device
Jan 18 07:24:34 <philipp64|laptop> where does this stuff get mapped currently?
Jan 18 07:24:42 <cshore> no idea
Jan 18 07:25:27 <cshore> I don't now as there is aliasing, or if happens in hotplug, or what
Jan 18 07:26:34 <cshore> does the kernel 'know' what major minor it should have?
Jan 18 07:27:37 <philipp64|laptop> if it doesn't, it's not in the module source and it's not in the modules.* files in the kernel's root.
Jan 18 07:28:48 <cshore> ok, so how does a device get a major/minor number then?
Jan 18 07:29:23 <philipp64|laptop> no friggin' idea...
Jan 18 07:29:31 <philipp64|laptop> I'm scratching my head.
Jan 18 07:29:55 <cshore> hmmm....let me see if one of my books can help (I bought some kernel books to start learning more)
Jan 18 07:33:07 <philipp64|laptop> just saw the commit. thanks.
Jan 18 07:34:41 <neutronscott> looking at that driver you need a module param of major=
Jan 18 07:36:02 <cshore> I was wondering about that...it would be that simple
Jan 18 07:36:07 <neutronscott> well wait
Jan 18 07:36:19 <neutronscott> it may still mkdev without that param
Jan 18 07:37:01 <philipp64|laptop> I wish we had "modinfo"... sigh.
Jan 18 07:37:11 <neutronscott> i'm looking at 2.6.36.2 tho
Jan 18 07:38:47 <Kaloz> cshore: the mac80211 is a special case, but well, another crap won't make things way worse
Jan 18 07:39:00 <neutronscott> ah. drivers/char/cs5535 and drivers/gpio/cs5535 are totally different things
Jan 18 07:39:14 <philipp64|laptop> how so?
Jan 18 07:39:31 <neutronscott> one makes char devices in /dev
Jan 18 07:39:40 <neutronscott> one makes gpio devices
Jan 18 07:39:46 <cshore> Kaloz: ok...how do we deal with hardware that is PCI (i.e. any pci board), and has a dependency like that?
Jan 18 07:39:49 <philipp64|laptop> I looked at them both, and it looked to me that the drivers/gpio/cs5535_gpio.c was just an updated driver...
Jan 18 07:39:53 <neutronscott> wherever those go, /sys/devices/gpio/something
Jan 18 07:40:27 <Kaloz> cshore: it's not a real dependency. like mac80211 could be used without crda and iw for real
Jan 18 07:41:07 <Kaloz> cshore: I simply hate when one wants to fixup human stupidity using computing workarounds
Jan 18 07:43:09 <cshore> Kaloz: it's not so much stupidity (that is not know such and such is needed for such and such) as not having a good way to describe that relationship in our dependencies....or way to make it easy to resolve such an issue without just saying, 'you should know that'
Jan 18 07:44:00 <Kaloz> cshore: if I want to use that card I should know I need a driver and a utility for it
Jan 18 07:44:29 <Kaloz> cshore: this is not about being not user friendly, but choosing who to be friends with
Jan 18 07:44:32 <Kaloz> :)
Jan 18 07:44:39 <cshore> kaloz: ah, well that's where I disagree...I think it's the designer's responsibility to make that known
Jan 18 07:44:55 <Kaloz> cshore#define designer
Jan 18 07:45:09 <cshore> well, in this case, us
Jan 18 07:45:30 <Kaloz> imho the manufacturer of the card or the user who uses the solution
Jan 18 07:48:18 <philipp64|laptop> ok, I have no idea what drivers/gpio/cs5535_gpio.c does then... oddly, drivers/char/cs5535-gpio.c doesn't export any symbols.
Jan 18 07:49:44 <neutronscott> what's a cs5535 and what are you doing with it? :)
Jan 18 07:51:12 <philipp64|laptop> it's a multifunction I/O chip in the Geode family.
Jan 18 07:51:22 <neutronscott> you just want the GPIO pins right
Jan 18 07:51:31 <philipp64|laptop> yeah.
Jan 18 07:51:46 <philipp64|laptop> so you'd think cs5535_gpio.c did that... but no.
Jan 18 07:51:50 <neutronscott> have you looked in /sys/drivers/gpio
Jan 18 07:52:10 <neutronscott> it's just a different interface to them
Jan 18 07:52:20 <philipp64|laptop> there's drivers/char/cs5535_gpio.c and drivers/gpio/cs5535-gpio.c ...
Jan 18 07:52:22 <neutronscott> i'm sorry, /sys/class/gpio
Jan 18 07:52:56 <cshore> philipp64: is there a call to alloc_chrdev_region or register_chrdev_region in either of them?
Jan 18 07:53:08 <neutronscott> right. you said you used the drivers/gpio/cs5535-gpio and saw nothing in /dev. it creates them in /sys/class/gpio
Jan 18 07:53:33 <neutronscott> drivers/char/cs5535-gpio creates them in /dev
Jan 18 07:53:42 <cshore> ah, I see ok, gpio, doesn't use a char dev
Jan 18 07:53:43 <philipp64|laptop> ok.. some of my scripts look for stuff in /dev
Jan 18 07:53:50 <cshore> it uses /sys/class/gpio?
Jan 18 07:53:56 <cshore> just like leds and buttons?
Jan 18 07:54:07 <cshore> at least the gpio ones?
Jan 18 07:54:18 <neutronscott> i'd go with the gpio class. it's the more correct/modern way ;)
Jan 18 07:54:55 <philipp64|laptop> I need to write a leds_geos.c module, but haven't found a good example to clone.
Jan 18 07:55:13 <neutronscott> http://www.mjmwired.net/kernel/Documentation/gpio.txt#573
Jan 18 07:55:13 <philipp64|laptop> (I was also going to support the soft reset button.)
Jan 18 07:55:45 <neutronscott> you can do most of it using scripts accessing those
Jan 18 07:56:19 <philipp64|laptop> then what exactly does the "mask" parameter do?
Jan 18 07:56:38 <cshore> philipp64; are you not using the led-gpio driver from elsewhere in the tree?
Jan 18 07:56:48 <cshore> leds-gpio I mean
Jan 18 07:57:27 <neutronscott> masks gpios which you don't want exported to userspace.
Jan 18 07:57:30 <cshore> for example brcm63xx and brcm47xx?
Jan 18 07:57:43 <neutronscott> like, if your ethernet's phy is on gpio 0+1
Jan 18 07:57:52 <neutronscott> you probably dont want those exported
Jan 18 08:03:52 <philipp64|laptop> right, and the mask works with the drivers/char/ version, but I couldn't tell what it did with the drivers/gpio driver.
Jan 18 08:04:05 <philipp64|laptop> cshore: what do I need to do to use leds-gpio?
Jan 18 08:04:54 <philipp64|laptop> it's just a helper, right?  I still need to write another module that leverages it.
Jan 18 08:06:29 <neutronscott> usually an led can be turned on/off using just the gpio driver
Jan 18 08:06:52 <neutronscott> the led-gpio will create an LED class using the GPIO pins, and i believe you can create that mapping in /sys/class as well
Jan 18 08:07:04 <philipp64|laptop> right, but I'm trying to tie certain leds automatically to certain events... like DSL carrier, etc.
Jan 18 08:07:36 <philipp64|laptop> neutronscott: got any examples of doing that?
Jan 18 08:07:39 <neutronscott> i think that'd be done in the driver...
Jan 18 08:08:13 <philipp64|laptop> what about the leds-trigger stuff?
Jan 18 08:08:53 <philipp64|laptop> or ledtrig-* rather.
Jan 18 08:09:09 <neutronscott> yes yes. it allows triggers on certain events
Jan 18 08:09:20 <neutronscott> and you bind them using the /sys/class/led made available by led-gpio
Jan 18 08:10:43 <neutronscott> man i wish i didn't put the original bootloader back on this router... TFTP fails more often than not :(
Jan 18 08:13:56 <philipp64|laptop> ok, I'll have to try to figure out how to use it when I'm less tired then.
Jan 18 08:14:26 <philipp64|laptop> maybe juhos will walk me through it.
Jan 18 08:15:59 <neutronscott> i think with the drivers/gpio/cs5535 and led-gpio compiled in, you can play with /sys/class a bit and see how it works
Jan 18 08:16:20 <neutronscott> i think most functionability is there without making your own platform specific glue
Jan 18 08:16:51 <neutronscott> it's next on my list too, but i've gotta write my GPIO driver :)
Jan 18 08:16:59 <neutronscott> er, add more to it anyway.
Jan 18 08:23:35 <philipp64|laptop> neutronscott: yeah, I just don't get how the pieces get plumbed together...
Jan 18 08:23:54 <philipp64|laptop> ok, one more question...
Jan 18 08:26:26 <Acinonyx> gmorning
Jan 18 08:27:02 <philipp64|laptop> after the solos module loads up, but before pppd gets started...  I need to send some commands to the modem via soloscli to force it to not use the wrong mode to train up.
Jan 18 08:27:36 <neutronscott> ok you're right the leds-gpio.c did need a platform data structure
Jan 18 08:27:40 <philipp64|laptop> but my understanding is that all of the /etc/init.d/ scripts are run non-blocking... (i.e. in parallel in background)
Jan 18 08:28:21 <philipp64|laptop> neutronscott: is there an example platform that populates it?
Jan 18 08:28:35 <neutronscott> let's grep ..
Jan 18 08:29:19 <neutronscott> xburst
Jan 18 08:30:40 <neutronscott> 006-add-n516-board-support.patch
Jan 18 08:32:23 <neutronscott> but first you'll wanna look at those gpio's in /sys/class and find the #s that correspond to LEDs. unless you know that already
Jan 18 08:36:24 <philipp64|laptop> yup, that I already know.
Jan 18 08:36:35 <philipp64|laptop> plus the button.
Jan 18 08:36:52 <philipp64|laptop> ok, time for bed.
Jan 18 08:37:02 <philipp64|laptop> actually it was an hour ago. but I was learning something knew.
Jan 18 08:37:19 <philipp64|laptop> cshore: thanks again for the commit.
Jan 18 08:38:13 <neutronscott> i'm re-learning something i did for 2.4, funny it's not working now.
Jan 18 08:44:07 <philipp64|laptop> neutronscott: there's no wiki entry in http://wiki.openwrt.org/doc/start for /etc/config/leds
Jan 18 08:48:48 <cshore> phillipp64: it's /etc/config/system that leds are in I believe
Jan 18 08:49:12 <cshore> it was something strange anyway...sec
Jan 18 08:49:50 <cshore> yep, system
Jan 18 08:49:55 <cshore> /sbin/led.sh
Jan 18 08:50:04 <neutronscott> sweet. forgot my kernel reads arguments passed by bootloader. no wonder root wouldn't mount... !
Jan 18 08:50:28 <neutronscott> theres also a /etc/diag.sh
Jan 18 08:51:01 <cshore> neutronscott: though that is platform-specific
Jan 18 08:51:26 <neutronscott> oh thought he was looking to put his leds in there.
Jan 18 08:51:31 <cshore> neutronscoot: or at least it's actions are defined per platform
Jan 18 08:51:58 <cshore> ah, /sbin/led.sh uses /etc/config/system
Jan 18 08:52:08 <cshore> that's what I meant, sorry
Jan 18 09:23:12 <neutronscott> i <3 openwrt.
Jan 18 09:24:07 <builder> build #55 of uml is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/uml/builds/55
Jan 18 10:36:57 <builder> build #53 of etrax is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/53
Jan 18 10:42:43 <xMff> cshore: mac80211 should not depend on iw and crda, cfg80211 can be driven by other utilities as well
Jan 18 10:44:32 <cshore> xMff: hmmm...let me check the dependcy again
Jan 18 10:45:19 <cshore> it's there....should be changed then
Jan 18 10:45:28 <xMff> I mean it should not depend on them. If I decide to create custom userspace code to drive it I don't want iw perhaps
Jan 18 10:45:39 <cshore> cfg80211 that is
Jan 18 10:46:00 <cshore> DEPENDS+= +wireless-tools +iw +crda
Jan 18 10:46:41 <cshore> I stand (well sit :) corrected
Jan 18 10:47:23 <xMff> yeah indeed, not ideal
Jan 18 10:47:50 <cshore> so maybe the one I added should be dropped to (for solas or whatever it was
Jan 18 10:47:56 <cshore> though that is slightly different
Jan 18 10:50:38 <xMff> well its the same deal with iptables
Jan 18 10:50:45 <xMff> iptables depends on kmods
Jan 18 10:50:50 <xMff> not the other way around
Jan 18 10:50:55 <cshore> right
Jan 18 10:51:18 <cshore> hmmmm.....
Jan 18 10:55:14 <cshore> well, it also similar to the problem with block-extroot....from a user perspective it would be preferrable to have block-extroot pull in the required dependencies, but we can't because of the way dependencies work (one of ohci/uhci for example, or one of the various block devices), so we tell people what they have to select, and they seem to be able to manage
Jan 18 10:56:04 <cshore> *it's
Jan 18 11:19:08 <builder> build #52 of ep93xx is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/52
Jan 18 12:15:38 <CIA-77> florian * r25035 /trunk/package/kernel/modules/netdevices.mk:
Jan 18 12:15:38 <CIA-77> Revert "[kernel] solos-pci: Depend on soloscli, just like mac80211 depends on iw and crda, since in both cases the module is useless without the userspace."
Jan 18 12:15:38 <CIA-77> We do not make a kernel module depend on user-space utility.
Jan 18 12:15:43 <CIA-77> florian * r25036 /trunk/target/linux/ep93xx/config-2.6.36: [ep93xx] add missing keyboard symbol
Jan 18 12:16:06 <[florian]> cshore: I have reverted the change because it caused a circular dependency as well
Jan 18 13:02:13 <cshore> ok, sorry about that
**** BEGIN LOGGING AT Tue Jan 18 14:13:58 2011
Jan 18 14:49:01 <CIA-77> nbd * r25037 /trunk/target/linux/mpc85xx/patches/ (2 files): mpc85xx: disable the i8259 irq on mpc8548cds (but leave the controller initialized) - it shares an irq with the pcie device which causes irq storms
Jan 18 14:49:09 <CIA-77> nbd * r25038 /trunk/package/kernel/modules/usb.mk: add a few missing usb related symbols (relevant for mpc85xx)
Jan 18 14:49:17 <CIA-77> nbd * r25039 /trunk/package/mac80211/patches/560-mac80211_wds_sta_fix.patch: mac80211: rework wds sta fix - check for the protocol of the incoming frame instead of just the authorized state
Jan 18 14:52:24 <CIA-77> cshore * r25040 /trunk/package/base-files/Makefile:
Jan 18 14:52:24 <CIA-77> [package] base-files: Fix typo in option name for disabling failsafe announcment
Jan 18 14:52:24 <CIA-77> Thanks to Andrey Zholos for this patch
Jan 18 14:58:33 <CIA-77> florian * r25041 /trunk/target/linux/realview/config-default: [realview] add missing config symbols
Jan 18 14:58:43 <CIA-77> florian * r25042 /trunk/target/linux/realview/config-default: [realview] disable built-in MMC support
Jan 18 18:10:08 <CIA-77> jow * r25043 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/mach-dir-600-a1.c: [ar71xx] fix null pointer access in mach-dir-600-a1.c machine setup (#8671)
Jan 18 20:56:17 <builder> build #67 of ubicom32 is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/67
Jan 18 21:39:45 <neutronscott> i'm in antarctica!
Jan 18 22:06:35 <tripolar> hi
Jan 18 22:07:05 <tripolar> can someone please apply my patch for openssl 1.* i sent some time ago to the mailing list? i use it some months by now ant it works without a problem
Jan 18 22:09:08 <OutBackDingo> tripolar: uhhmmm lemme find it
Jan 18 22:09:31 <tripolar> OutBackDingo :) i can sent it again
Jan 18 22:09:39 <OutBackDingo> tripolar: go ahead
Jan 18 22:31:47 <tripolar> OutBackDingo: sent
Jan 18 22:32:13 <tripolar> had to search it in the totally broken kmail that complete depends on akonadi :(
Jan 18 22:34:56 <OutBackDingo> yeah true
Jan 18 22:45:59 <tripolar> OutBackDingo can you commit it?
Jan 18 22:47:50 <OutBackDingo> tripolar: im going through it
Jan 18 22:50:34 <tripolar> OutBackDingo: hardware crypto support is now included in openssl so the patch osnt needed anymore
Jan 18 22:50:41 <tripolar> osnt=isnt
Jan 18 22:51:13 <tripolar> using it right now on a dev with ipsec core
Jan 18 23:09:00 <xMff> ping philipp64|laptop
Jan 18 23:56:34 <nunojpg> sh.func.c:(.text+0x118): undefined reference to `catgets'
Jan 18 23:56:40 <nunojpg> is this a include or a flag missing?
Jan 18 23:57:08 <xMff> sounds like some missing obscure gettext stuff
Jan 18 23:57:54 <nunojpg> http://nixdoc.net/man-pages/NetBSD/man3/catclose.3.html?PHPSESSID=367so3osr1gc88iikme6a4utp2
Jan 18 23:57:56 <nunojpg> stdlib?
Jan 18 23:58:21 <xMff> libintl
Jan 18 23:58:27 <xMff> uclibc has not builtin nls
Jan 18 23:58:47 <xMff> which program demands it?
Jan 18 23:58:51 <nunojpg> tcsh
Jan 18 23:59:36 <nunojpg> so probably I have to patch the source to include libintl and not stdlib
Jan 18 23:59:45 <nunojpg> and then fight with the flags
Jan 18 23:59:57 <xMff> might be easier
Jan 19 00:00:27 <xMff> locate staging_dir/target-*/usr/include/intl.h
Jan 19 00:01:11 <xMff> sorry, libintl.h
Jan 19 00:02:23 <xMff> add this before the both #endif at the end:
Jan 19 00:02:25 <xMff> #define catgets(catd, set_num, msg_num, Str) (Str)
Jan 19 00:02:30 <xMff> try to recompile
Jan 19 00:04:22 <nunojpg> I'm lost
Jan 19 00:04:31 <nunojpg> actually I'm trying now "--disable-nls "
Jan 19 00:04:54 <nunojpg> what #endif do you mean?
Jan 19 00:05:44 <xMff> the one in staging_dir/target-*/usr/include/libintl.h
Jan 19 00:17:40 <nunojpg> --disable-nls didn't work
Jan 19 00:17:48 <nunojpg> I'm now trying as you said
Jan 19 00:18:10 <nunojpg> I would never look to modify one package to compile another
Jan 19 00:19:08 <xMff> its is an experiment
Jan 19 00:19:12 <xMff> not a solution :)
Jan 19 00:19:49 <xMff> but you can also patch out all catgets(foo, foo, foo, String) calls and replace them just with String
Jan 19 00:20:40 <xMff> if it'd compile the outcome would be just that as openwrt has no nls stuff at all
Jan 19 00:21:54 <neutronscott> should be able to undef HAVE_ICONV, no?
Jan 19 00:22:29 <xMff> catgets is not iconv afaik
Jan 19 00:23:33 <nunojpg> most, if not all "catgets" are under ifdef defined(HAVE_ICONV) && defined(HAVE_NL_LANGINFO)
Jan 19 00:23:52 <nunojpg> probably --disable-nls should had disabled that
Jan 19 00:24:11 <neutronscott> #ifdef NLS_CATALOGS
Jan 19 00:24:36 <xMff> that ^  :)
Jan 19 00:27:17 <neutronscott> i'ma get a .aq !!
Jan 19 00:28:33 <nunojpg> I don't understand most of what you say
Jan 19 00:28:41 <nunojpg> #ifdef NLS_CATALOGS, that is it
Jan 19 00:29:08 <nunojpg> but this is defined, even when I set CONFIGURE_ARGS += --disable-nls
Jan 19 00:29:41 <neutronscott> xMff: so im still lacking lots of this buildroot knowledge. im almost ready to resubmit my patches. how's the kernel config made in the target/ directories to be so short?
Jan 19 00:30:15 <xMff> nunojpg: yes, because gnu autotools is a big sucking fail
Jan 19 00:30:40 <xMff> nunojpg: you need to trace down where it gets defined and then patch it away
Jan 19 00:30:43 <xMff> neutronscott: by hand
Jan 19 00:30:45 <nunojpg> shall I just patch that ifdef sectios out?
Jan 19 00:30:47 <nunojpg> *sections
Jan 19 00:31:07 <xMff> nunojpg: grep -r for catgets
Jan 19 00:31:15 <neutronscott> ah ok, is what i thought. or maybe a script to remove whats in the generic config
Jan 19 00:31:24 <xMff> nunojpg: if its less than 10 occurences then just remove those all
Jan 19 00:50:59 <nunojpg> http://pastebin.com/qnvfLkku
Jan 19 00:50:59 <nunojpg> that was all!
Jan 19 00:50:59 <nunojpg> thanks for the NLS hint, REALLY!
Jan 19 00:50:59 <nunojpg> nls is completely useless on openwrt so?
Jan 19 00:50:59 <neutronscott> what path is that relative to
Jan 19 00:50:59 <xMff> upstream source
Jan 19 00:50:59 <nunojpg> path on the patch? relative to tcsh source?
Jan 19 00:50:59 <neutronscott> i dont have it checked out here, just wanted to make sure it wasnt a dynamic config
Jan 19 00:51:13 <Elphidium> #6163 can be closed
Jan 19 00:53:17 <xMff> done. thanks
Jan 19 01:15:19 <neutronscott> i wonder if there is a way to do sysupgrade better. such that, if the new image is smaller and rootfs_data would move upon reboot toa larger offset, sysupgrade would overwrite rootfs ..
Jan 19 01:15:34 <neutronscott> s/smaller/larger/
Jan 19 01:17:58 <xMff> eh?
Jan 19 01:18:51 <neutronscott> i have tight partitions. if new build has a larger rootfs, rootfs_data will start at a larger offset. yes.
Jan 19 01:19:48 <neutronscott> sysupgrade will rewrite config files to rootfs_data at say offset 0x270000, then i reboot and rootfs_data really is now at 0x280000.
Jan 19 01:20:12 <xMff> yeah
Jan 19 01:20:14 <neutronscott> so the last bit of my rootfs was overwritten by jffs2...
Jan 19 01:20:41 <xMff> no?
Jan 19 01:21:02 <xMff> if it does that you found a serious bug
Jan 19 01:21:16 <neutronscott> it did last time i tried it..
Jan 19 01:21:25 <neutronscott> how would 'mtd' know?
Jan 19 01:21:56 <neutronscott> it just does mtd -e rootfs_data jffs2write "$CONF_TAR" rootfs_data
Jan 19 01:22:09 <xMff> mtd searches for the rootds eof marker
Jan 19 01:22:33 <neutronscott> ahhh. it does?
Jan 19 01:23:02 <xMff> at least I'd exect it to
Jan 19 01:23:14 <xMff> however I never had issues sysupgrading to biggeri mages
Jan 19 01:23:34 <neutronscott> i wonder if WRT610NL uses that marker: https://forum.openwrt.org/viewtopic.php?pid=125904
Jan 19 01:23:57 <neutronscott> i know i excluded it on my target that uses u-boot because it checks CRC on boot.
Jan 19 01:24:28 <neutronscott> my new fix is to shrink image + re-crc the header on firstboot :)
Jan 19 01:33:41 <neutronscott> seems it'd work right. it checks magic for the block...
Jan 19 01:36:55 <neutronscott> but it may reach the end w/o a clean jffs marker and step back an erasesize and add it anyway ....?
Jan 19 01:38:11 <xMff> it shouldn't do that
Jan 19 01:38:14 <xMff> that'd be stupid
Jan 19 01:39:06 <neutronscott> i'm just bored n surfing the forums. seemed like something i'd look into. i know i had problems with it on my first few builds.. i'll see what happens tonight.
Jan 19 02:06:18 <CIA-77> jow * r25044 /trunk/package/ppp/ (Makefile patches/350-survive_bad_pads_packets.patch): [package] ppp: don't die on malformed PADS frames that might appear on instable DSL lines
Jan 19 02:24:18 <theMIROn> hm, my original patch goes into openwrt :) nice
Jan 19 02:24:28 <xMff> hm?
Jan 19 02:24:42 <theMIROn> hmmm )
Jan 19 02:27:22 <theMIROn> err, I was wrong, they're not the same
Jan 19 02:28:42 <xMff> you mean the ppp thing?
Jan 19 02:28:47 <theMIROn> yep
Jan 19 02:28:58 <xMff> I hate this software
Jan 19 02:29:21 <xMff> every distro using it for production has more patches than upstream source in it
Jan 19 02:29:52 <theMIROn> somewhere it's daily need
Jan 19 02:31:16 <theMIROn> yep, most of them focused on stability under various circumstances
Jan 19 02:31:22 <theMIROn> *ijn
Jan 19 02:31:45 <xMff> I bet it was developed in a university lab :)
Jan 19 02:31:51 <xMff> where nthing bad can happen
Jan 19 02:35:43 <theMIROn> afaik wasn't in lab, whatever. god thanks it's still developing
Jan 19 02:36:32 <theMIROn> but veeeeery slowly, 2.4.5 was the bug-fix release with external patches accumulation
Jan 19 02:36:39 <theMIROn> mostly
**** ENDING LOGGING AT Wed Jan 19 02:59:57 2011