**** BEGIN LOGGING AT Wed Jan 19 02:59:57 2011
Jan 19 03:59:55 <philipp64|laptop> cshore: ping
Jan 19 04:03:47 <philipp64|laptop> neutronscott: ping
Jan 19 04:23:27 <cshore> philipp64: pong
Jan 19 04:27:26 <philipp64|laptop> thinking about adding support for both modules...
Jan 19 04:27:39 <cshore> the char and gpio?
Jan 19 04:28:01 <philipp64|laptop> ftp://ftp.redfish-solutions.com/pub/cs5535.patch
Jan 19 04:28:23 <philipp64|laptop> errr ... ftp://ftp.redfish-solutions.com/pub/cs5535-new.patch
Jan 19 04:30:33 <cshore> shouldn't GPIOLIB be enabled only for the cs driver not for all default configs?
Jan 19 04:32:28 <cshore> yeah, that shouldn't enabled for all x86, only models that need it
Jan 19 04:33:03 <cshore> do a module for it perhaps?
Jan 19 04:36:57 <philipp64|laptop> I think there are issues with libraries as modules.
Jan 19 04:37:11 <philipp64|laptop> let me look if that's even an option. it might be bool and not tristate.
Jan 19 04:38:12 <philipp64|laptop> yup. bool.
Jan 19 04:38:58 <cshore> hmmmm.....can it at least be for the platform then....I don't like forcing everyone to have it.
Jan 19 04:39:04 <philipp64|laptop> it's 12k.
Jan 19 04:39:13 <philipp64|laptop> unstripped
Jan 19 04:40:14 <cshore> I think you should ask on the list
Jan 19 04:41:09 <philipp64|laptop> how do I resolve the name clash?
Jan 19 04:46:28 <cshore> well is one module deprecated upstream?  maybe just not use it
Jan 19 04:48:30 <cshore> Why do you want both anyway?
Jan 19 04:50:28 <philipp64|laptop> because each creates nodes differently in the /sys filesystem.
Jan 19 04:50:51 <philipp64|laptop> if I'm going to write a leds-geos.c module, I might as well use the newer naming scheme.
Jan 19 04:51:06 <cshore> right, so why not just use the newer module?
Jan 19 04:51:14 <philipp64|laptop> but there are older platforms like net5501 and alix that might have users who rely on the old naming.
Jan 19 04:51:48 <cshore> Well neither of the modules is in use right now, right?
Jan 19 04:56:02 <cshore> or is the older module already in use?
Jan 19 04:57:11 <cshore> I'm afraid I have no advice on how to use both...you should as on-list
Jan 19 04:57:20 <philipp64|laptop> sorry, neither of which modules?
Jan 19 04:57:20 <cshore> *ask
Jan 19 04:57:28 <cshore> the cs modules
Jan 19 04:58:38 <philipp64|laptop> drivers/char/cs5535_gpio.c is in use on all Geode-based boxed (net4801, alix, net5501, and Geos)
Jan 19 04:59:20 <cshore> Ah, and you want to change for one platform only?  (Geos?)
Jan 19 05:01:10 <cshore> I'm pretty sure you can do conditional modules based on platform...definitely per-platform configs
Jan 19 05:03:10 <philipp64|laptop> I wish that x86 were a bit more updated... at least to 2.6.35...  not sure why we're still back at 2.6.32 as the official release for x86
Jan 19 05:03:22 <philipp64|laptop> or the default build, anyway
Jan 19 05:03:55 <cshore> probably nobody working on it....would need appropriate patchset submitted I'm guessing.
Jan 19 05:04:47 <cshore> I can't think of anyone who is specifically the x86 dev
Jan 19 05:07:12 <cshore> Florian is currently extremely busy
Jan 19 05:07:29 <cshore> and he's probably the one who would have taken care of it normally
Jan 19 05:08:44 <philipp64|laptop> ok, so this is what I don't get.
Jan 19 05:09:40 <philipp64|laptop> so if CONFIG_CS5535_GPIO is off by default... should it be in the platform config-default?
Jan 19 05:10:16 <philipp64|laptop> should it be in the generated linux-x.x.x.x/.config file? or does it get passed in via the command line (make args) when the kmods are built?
Jan 19 05:10:26 <cshore> it's probably turned on by the kmod generation code.
Jan 19 05:11:04 <cshore> I think it's part of the generate .config that should be in build_dir/linux*/linux*
Jan 19 05:11:57 <philipp64|laptop> ah... that's upside down then.
Jan 19 05:12:29 <cshore> ?
Jan 19 05:12:37 <philipp64|laptop> the default kernel build shouldn't include the "packaged" modules... the packaged modules should all get turned on via the command line during a separate build.
Jan 19 05:14:18 <cshore> Don't know which way it's done tbh.   You'd have to spelink the build code
Jan 19 05:14:24 <cshore> (include/*.mk)
Jan 19 05:14:33 <cshore> *spelunk
Jan 19 05:14:56 <philipp64|laptop> gah...  I wish someone would document the build mechanics for the wiki.
Jan 19 05:15:11 <cshore> me too ...
Jan 19 05:17:27 <philipp64|laptop> ok, how do you specify that CONFIG_GPIOLIB needs to be built-in to the kernel for the module to work?
Jan 19 05:17:50 <philipp64|laptop> the DEPENDS stuff refers to packages, right, not to linux CONFIG_xxx stuff.
Jan 19 05:18:30 <cshore> unless @ and that for openwrt build system symbols not kernel, expect for feature tags
Jan 19 05:23:34 <philipp64|laptop> so no way to express a requirement that CONFIG_GPIOLIB being built-in...
Jan 19 05:24:37 <cshore> from a package...no, only for kmod packages
Jan 19 05:24:53 <cshore> they have access to both sets of symbols I think
Jan 19 05:26:23 <cshore> and you can't do a dependency select with that type of symbol
Jan 19 05:26:37 <cshore> only maybe an @CONFIG_GPIOLIB
Jan 19 05:27:15 <cshore> not 100% sure
Jan 19 05:28:10 <philipp64|laptop> [florian]: ping
Jan 19 05:28:45 <philipp64|laptop> oh, you did say he was busy... and Felix is probably asleep
Jan 19 05:28:59 <philipp64|laptop> nbd: ping
Jan 19 05:29:09 <cshore> oh, I just meant in general, with his current job
Jan 19 05:31:36 <cshore> I hate Windows
Jan 19 05:33:22 <philipp64|laptop> amen.
Jan 19 05:33:25 <philipp64|laptop> grr... tmp/.config-package.in:18145:warning: 'select' used by config symbol 'PACKAGE_soloscli' refer to undefined symbol 'PACKAGE_kmod-solos-pci'
Jan 19 05:34:32 <cshore> oh, yeah I forgot to mention....we had to revert the change...circular dependency and general feeling amongst the devs that kernel shouldn't depend on userspace
Jan 19 05:35:06 <cshore> not that that should affect that message
Jan 19 06:04:08 <cshore> sleeeeepppppp!
Jan 19 06:05:19 <philipp64|laptop> grr... ERROR: please fix package/kernel/Makefile
Jan 19 08:35:09 <[florian]> philipp64|laptop: yes sir
Jan 19 08:36:10 <philipp64|laptop> awesome. I have some questions about setting up CONFIG_xxx symbols for a kernel module... (that is in build_dir/linux*/linux-x.x.x.x/.config)
Jan 19 08:36:34 <philipp64|laptop> oh, and also, how to set a top-level config (like CONFIG_OPENSSL_ENGINE=y) in a target.mk file.
Jan 19 08:38:15 <philipp64|laptop> for example, http://fpaste.org/RZm5/ ... I can't get the target to turn on OPENSSL_ENGINE to enable kmod-crypto-ocf
Jan 19 08:43:14 <[florian]> I do not think this is meant to be put that way
Jan 19 08:43:33 <[florian]> it would have higher chances to work if you select OPENSSL_ENGINE on a per module basis
Jan 19 08:43:40 <philipp64|laptop> and the other question... http://fpaste.org/DixJ/ ... what happens to a kernel modules KCONFIG values? do they get passed on the command line "make ... ${KCONFIG}" when the kernel modules are built?
Jan 19 08:44:04 <philipp64|laptop> sorry, didn't understand your last message
Jan 19 08:44:52 <philipp64|laptop> OPENSSL_CONFIG is defined in package/openssl/Config.in
Jan 19 08:48:05 <[florian]> I do not think you can actually make a target makefile or any other makefile select OPENSSL_ENGINE (or something else actually)
Jan 19 08:48:33 <[florian]> unless you do something like what we do today with "FEATURES:="
Jan 19 08:54:48 <philipp64|laptop> how hard would it be to hack FEATURES:= to turn that on?
Jan 19 08:54:56 <Acinonyx> gmorning
Jan 19 08:57:49 <philipp64|laptop> [florian]: as for the other issue... how do I put "# CONFIG_CS5535_GPIO is not set" into target/linux/x86/config-default but still allow package/kernel/modules/other.mk to turn it back on?
Jan 19 08:58:33 <[florian]> philipp64|laptop: does not it work if you do it that way?
Jan 19 08:58:39 <philipp64|laptop> I tried to look at include/kernel.mk and figure out what happens to KCONFIG, but it wasn't clear...
Jan 19 08:58:48 <philipp64|laptop> sorry, which?
Jan 19 08:59:10 <[florian]> put it CONFIG_FOO is not set in config-default and put the interesting KCONFIG:= in package/kernel/modules/*.mk?
Jan 19 09:03:50 <philipp64|laptop> so I have: target/linux/x86/config-default:# CONFIG_CS5535_GPIO is not set
Jan 19 09:04:46 <philipp64|laptop> and target.mk selects kmod-gpio-cs5535 ... and the module sets KCONFIG:=CONFIG_CS5535_GPIO ...
Jan 19 09:04:54 <[florian]> and that does not work?
Jan 19 09:05:37 <philipp64|laptop> no, the generated linux .config contains: # CONFIG_CS5535_GPIO is not set
Jan 19 09:05:58 <philipp64|laptop> seems that KCONFIG doesn't override whatever is in the config-defaults.
Jan 19 09:07:41 <philipp64|laptop> any ideas?
Jan 19 09:08:19 <[florian]> so far not really
Jan 19 09:08:33 <[florian]> if you do not have # CONFIG_CS5535_GPIO is not set in your config-default, the module is built right?
Jan 19 09:13:00 <philipp64|laptop> I believe so. let me double-check.
Jan 19 09:15:50 <[florian]> yes please do, because package/kernel/modules/*/ gets processed after config-default
Jan 19 09:16:02 <[florian]> so it has a chance to be able to override CONFIG_CS5535_GPIO
Jan 19 09:16:11 <philipp64|laptop> ok, so it prompts asking me for the value when doing the "make oldconfig" in the kernel.
Jan 19 09:16:33 <[florian]> oh so it's actually processed before config-default?
Jan 19 09:17:17 <philipp64|laptop> don't know. haven't walked through it.
Jan 19 09:17:46 <philipp64|laptop> was hoping someone would take the time to write a wiki page on how the configuration stuff all works.
Jan 19 09:18:26 <philipp64|laptop> I'm trying to get my patches done without getting too distracted with trying to figure out how stuff works.
Jan 19 09:19:24 <philipp64|laptop> ok, I need to get to bed. it's 1am here.
Jan 19 09:19:39 <[florian]> allright, I will give a try to your patch
Jan 19 09:19:45 <philipp64|laptop> tomorrow I get to bang my head against Click.
Jan 19 09:20:06 <philipp64|laptop> thanks.
Jan 19 09:22:57 <philipp64|laptop> one other quick question... how easy would it be to make mod-ppp-pppoa default to "on" if ppp and linux-atm are both selected?
Jan 19 09:25:06 <[florian]> select all of its dependencies to make it selected by default
Jan 19 09:29:23 <philipp64|laptop> hmm... it would also be nice to have a target.mk set CONFIG_X86_GRUB_BAUDRATE=115200
Jan 19 09:34:27 <philipp64|laptop> no, not getting this.  I selected all of ppp-mod-pppoa's dependencies and it didn't autoselect.
Jan 19 09:36:01 <philipp64|laptop> and I can't select ocf-crypto-headers... even though it has no dependencies.
Jan 19 09:48:36 <xiangfu> Hi I using this command " make IGNORE_ERRORS=m" to compile all packages,  the config file is here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/image-all_packages-01172011-2200/config
Jan 19 09:49:00 <xiangfu> but I can not got the "Packages" and "Packages.gz" file! if that normal.
Jan 19 09:49:38 <xiangfu> I know there are some packages didn't compile, if that make the openwrt don't generate the "Packages" file?
Jan 19 10:09:16 <xiangfu> should I run "make package/index" after "make  IGNORE_ERRORS=m" ?
Jan 19 12:22:14 <xMff> xiangfu: no need to
Jan 19 12:30:36 <xiangfu> xMff: but the "Packages.gz" not generate by "make IGNORE_ERRORS=m", do you have any idea where is the problem?
Jan 19 12:31:02 <xMff> xiangfu: hmm
Jan 19 12:31:17 <xMff> xiangfu: is it generated after make  package/index ?
Jan 19 12:32:16 <xiangfu> xMff: yes.
Jan 19 12:32:45 <xiangfu> xMff: so for now. I always run "make package/index" after "make IGNORE_ERRORS=m"
Jan 19 12:32:53 <xiangfu> manually
Jan 19 12:33:22 <xMff> afaik our buildbotrs use IGNORE_ERRORS=m as well and they have no issue with the package index
Jan 19 12:41:42 <xiangfu> xMff: is there a script file for build all package? can you share it to me :)
Jan 19 12:42:03 <xMff> xiangfu: there is CONFIG_ALL
Jan 19 12:44:16 <xiangfu> xMff: yes. here is the config file we using : http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/master/data/qi_lb60/conf/config.all_packages
Jan 19 12:44:46 <xiangfu> xMff: here is the script file for build the all package: http://fidelio.qi-hardware.com/~xiangfu/bin/compile-openwrt-xburst.a.sh
Jan 19 12:45:20 <xiangfu> xMff: I added the "make package/index" today. after I found there is no "Packages.gz"
Jan 19 12:46:26 <xMff> can you paste the last 100 lines of your buildlog?
Jan 19 12:48:35 <xiangfu> xMff: http://fidelio.qi-hardware.com/~xiangfu/compile-log/image-all_packages-01172011-2200/BUILD_LOG.last.100.lines
Jan 19 12:49:32 <xMff> compilation crashed with some python host-fu
Jan 19 12:49:42 <xMff> IGNORE_ERRORS=m doesn't catch this
Jan 19 12:50:58 <xMff> it looks like someone forgot -fpic in the CFLAGS
Jan 19 12:54:07 <xiangfu> ok. maybe I need rebase our branch on 'backfire', we don't have "HOST_FPIC:=-fPIC" in rules.mk
Jan 19 15:14:50 <CIA-77> jow * r25045 /branches/backfire/package/ppp/ (Makefile patches/350-survive_bad_pads_packets.patch): [backfire] merge r25044
Jan 19 15:24:45 <CIA-77> nunojpg * r25046 /packages/utils/tcsh/ (. Makefile patches/ patches/001-gethost patches/002-NLS): [packages] added tcsh: Enhanced Berkeley UNIX C shell
Jan 19 16:01:52 <CIA-77> blogic * r25047 /trunk/target/linux/lantiq/ (files/ patches/100-board.patch):
Jan 19 16:01:52 <CIA-77> [lantiq]
Jan 19 16:01:52 <CIA-77> * revert [25002]
Jan 19 16:01:52 <CIA-77> * fixes EBU ack when EBU causes an irq
Jan 19 18:53:36 <KanjiMonster> nice, ar71xx(ath79) gone mainline (well, it appeared in the linux-mips tree ;)
Jan 19 18:55:14 <danage> nice
Jan 19 18:58:50 <stintel> seems it's merged in 2.6.38-rc1
Jan 19 18:58:54 <stintel> very nice
Jan 19 18:59:29 <KanjiMonster> yeah, just updated my tree and saw it coming it
Jan 19 19:07:56 <neutronscott> there was a mac80211 patch that disassociated clients after inactivity, after a ping failed. i cannot find it.. i want to tear it out again. err i mean fix it
Jan 19 20:53:55 <CIA-77> jow * r25048 /trunk/package/uci/ (Makefile patches/130-lua_fix_nested_foreach_delete.patch): [package] uci: use latest git, fixes reorder operation and incorperates nested delete patch
Jan 19 20:55:04 <builder> build #60 of ps3 is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/60
Jan 19 20:56:59 <CIA-77> jow * r25049 /branches/backfire/package/uci/ (Makefile patches/140-uci_fix_reorder.patch): [backfire] backport uci reorder fix from r25048
Jan 20 00:50:04 <mazilo> xMff: I am hoping you can help me out on this. I am trying to compile the mod_spidermonkey on FreeSWITCH that requires the included Mozilla JS code that is compilable under OpenWRT to produce "libs/js/nsprpub/config/nsinstall" code for ARM5 platform. However, the Mozilla JS tries to execute the newly compiled nsinstall binary codes for an ARM5 platform on the host. I remember you had helped once as shown on this post (https://forum.
Jan 20 00:50:05 <mazilo> openwrt.org/viewtopic.php?pid=100760#p100760). If you take a look at lines# 89 and 90 of the "libs/js/nsprpub/config/autoconf.mk.in (http://pastebin.com/xYPqmKNk) of Mozilla JS that gets processed by autoconf, is there a way to make autoconf the assign the config_BUILD_CC and config_BUILD_CFLAGS to HOST_CC and HOST_CFLAGS, respectively?
Jan 20 01:00:26 <builder> build #62 of pxcab is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/62
Jan 20 02:14:06 <philipp64|laptop> [florian]: ping
Jan 20 02:16:26 <philipp64|laptop> who is around who really gets the build system, especially kernel configuration and building kernel modules?
Jan 20 02:17:26 <neutronscott> good luck on that :)
Jan 20 02:37:21 <philipp64|laptop> you're not helping.
Jan 20 02:38:51 <philipp64|laptop> seems if I put "# CONFIG_FOOBAR is not set" into config-default, then that inhibits making the kernel config from prompting me for the question.  but if it's in there, it seems to override whatever value KCONFIG specifies when the kernel modules are built.
Jan 20 02:39:20 <philipp64|laptop> I can take it out of config-default, but then I get prompted for it and it stops the build...
Jan 20 02:40:18 <philipp64|laptop> you'd think that if "# CONFIG_FOOBAR is not set" was present in the linux-x.x.x.x/.config file, then the "KCONFIG" values would be massaged and passed in via the "make" command line... but they apparently aren't.
Jan 20 02:40:42 <philipp64|laptop> at least when building the kmod's, that is.
Jan 20 02:41:12 <philipp64|laptop> I really wish I knew who owned this stuff.
Jan 20 02:41:52 <philipp64|laptop> hard to assess if your diffs "break" anything when you're not even sure the default behavior is correct. sigh.
Jan 20 02:45:18 <philipp64|laptop> so... there's no way to specify a value for CONFIG_X86_GRUB_BAUDRATE from within target.mk, right?
Jan 20 02:50:59 <philipp64|laptop> I need to ask my questions earlier in the day when more people are around.
**** ENDING LOGGING AT Thu Jan 20 02:59:57 2011