**** BEGIN LOGGING AT Tue Sep 30 02:59:58 2014
**** BEGIN LOGGING AT Tue Sep 30 03:37:25 2014
**** BEGIN LOGGING AT Tue Sep 30 03:52:43 2014
**** BEGIN LOGGING AT Tue Sep 30 04:01:58 2014
Sep 30 06:40:26 <OpenWrt-Commits> cyrus r42702 packages/utils/hd-idle * hd-idle: moved to github
Sep 30 07:00:46 <builder> build #702 of ppc44x is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/702
Sep 30 07:29:09 <builder> build #748 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/748
Sep 30 09:37:07 <nighty^> is there a luci-ipsec ?
Sep 30 09:37:42 <jow_laptop> no
Sep 30 09:42:39 <nighty^> jow_laptop, thanks
Sep 30 09:49:11 <builder> build #743 of cobalt is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/743
Sep 30 09:53:18 <builder> build #671 of sibyte is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/671
Sep 30 10:24:37 <nighty^> what is most used on openwrt for ipsec ?
Sep 30 10:24:42 <nighty^> or most reliable
Sep 30 10:40:35 <plntyk> i think the "only" solution viable would be strongswan ; openswan often does not compile with newer kernels and libreswan afaik is not ported / available as openwrt package
Sep 30 10:47:02 <jow_laptop> libreswan needs yet another crypto library
Sep 30 10:47:02 <builder> build #683 of avr32 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/683
Sep 30 11:23:42 <zorun> nighty^: http://wiki.openwrt.org/doc/howto/vpn.ipsec.basics
Sep 30 11:47:30 <nighty^> thanks
Sep 30 12:24:44 <builder> build #198 of pxa is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/198
Sep 30 12:26:34 <Devastator> I really don't understand what is going on..
Sep 30 12:27:40 <Devastator> vlans are created in luci, uci show shows it is there, but ifconfig -a doesn't show them, is this right or is target dependent?
Sep 30 12:28:07 <zorun> maybe you need to ifup them?
Sep 30 12:28:59 <Devastator> already did, but it stays the same
Sep 30 12:31:15 <Devastator> zajec in a more formal way :P
Sep 30 12:31:23 <zajec> ;)
Sep 30 12:32:46 <Devastator> nice work you are doing with linux-mtd guys
Sep 30 12:33:27 <zajec> i still don't understand some things
Sep 30 12:33:27 <zajec> have to test them locally
Sep 30 12:33:28 <zajec> i guess i need to improve my DT knowledge :)
Sep 30 12:33:49 <KanjiMonster> zajec: feel free to ask questions ;)
Sep 30 12:34:14 <Devastator> m25p80 is kind of messy in my opinion
Sep 30 12:35:08 <zajec> KanjiMonster: i think Ben explains things in ways that newbies can't really undestand ;)
Sep 30 12:35:59 <Devastator> I liked David, Artem and Brian
Sep 30 12:36:09 <Devastator> like, even
Sep 30 12:36:31 <Devastator> but David is not that active anymore
Sep 30 12:36:45 <zajec> i just say I don't understand his explaiantino ;)
Sep 30 12:37:09 <zajec> KanjiMonster: this is what I can't understand: http://www.spinics.net/lists/arm-kernel/msg366856.html
Sep 30 12:39:32 <zajec> KanjiMonster: any idea about that?
Sep 30 12:40:20 <Devastator> the "out-of-band information" expression seems strange to me, but my english is strange anyway :)
Sep 30 12:40:50 <KanjiMonster> zajec: my understanding is that "generic-foo" is not a valid compatible string unless you can write a generic driver that does not require updates for new "compatible" foo
Sep 30 12:42:26 <zajec> err... what? :(
Sep 30 12:43:13 <KanjiMonster> the issue is that the jedec id is "out of band" information
Sep 30 12:44:11 <KanjiMonster> so any driver version declaring to be compatible with "m25p80" is expected to be working with any spi device declared to be compatbile with "m25p80"
Sep 30 12:45:10 <zajec> so... SPI driver declared as compatible with "m25p80" can't be improved? to support more hw?
Sep 30 12:45:11 <zajec> wtf?
Sep 30 12:46:10 <KanjiMonster> no, the issue is that if the driver declares "m25p80" as compatible, but there are chips that it doesn't support but are supposed to be compatible (because you specify "m25p90"), then the driver is obviously lying
Sep 30 12:46:16 <Devastator> I guess it means it should at least have m25p80 compability within specs
Sep 30 12:47:17 <KanjiMonster> the issue is that there is no "generic-spi-nor" driver possible
Sep 30 12:47:54 <zajec> i understand what you explain now...
Sep 30 12:48:03 <zajec> but I still can't see much sense in that
Sep 30 12:48:07 <KanjiMonster> the driver should not probe/attach to unsupported chips
Sep 30 12:48:21 <KanjiMonster> or claim them
Sep 30 12:48:21 <zajec> come one... there are always going to appear some devices requiring workarounds
Sep 30 12:48:35 <zajec> in general
Sep 30 12:48:37 <zajec> not just spi-nor
Sep 30 12:48:45 <KanjiMonster> the required differences are supposed to be expressed then as DT properties
Sep 30 12:48:54 <KanjiMonster> or using a new compatible string
Sep 30 12:49:01 <zajec> we can't support all possible hardware the moment we commit the driver :|
Sep 30 12:49:13 <zajec> KanjiMonster: this is what I wanted
Sep 30 12:49:30 <zajec> I wanted incompatible hardware (with no JEDEC ID support) to use extra property
Sep 30 12:51:11 <KanjiMonster> you are breaking assumptions if a driver declaring to be compatible to a certain string may or may not work with a device declaring to be compatible with the same string depending on the revision of the driver
Sep 30 12:53:27 <zajec> but, isn't kernel full of things like that?
Sep 30 12:53:38 <zajec> sec
Sep 30 12:53:47 <KanjiMonster> kernel? yes. Device Tree bindings? No.
Sep 30 12:54:01 <zajec> let's take this: compatible = "gpio-leds";
Sep 30 12:54:12 <zajec> this gives only a general driver probe
Sep 30 12:54:23 <zajec> it won't work without extra properties
Sep 30 12:54:33 <zajec> you need to provide extra entries, one per LED
Sep 30 12:54:44 <zajec> isn't it the same situation?
Sep 30 12:55:09 <KanjiMonster> no, because gpio is a defined interface - you can set them to out, in, and set/get a value
Sep 30 12:55:54 <zajec> i see no difference
Sep 30 12:55:56 <KanjiMonster> the thing is you can't make the model optional
Sep 30 12:56:03 <KanjiMonster> you need to require it
Sep 30 12:56:06 <zajec> SPI is also a defined interface, you have regsiters
Sep 30 12:56:46 <KanjiMonster> but what registers/commands are available is not defined
Sep 30 12:56:57 <KanjiMonster> but differes from chip to chip
Sep 30 12:57:08 <zajec> i don't think "gpio-leds" requires LEDs to be defines in DT, i think you could use empty "gpio-leds" node and it would compile, driver would load
Sep 30 12:57:37 <zajec> that's the damn thin line, if it exists at all :(
Sep 30 12:57:58 <KanjiMonster> so if you wanted to write a "generic" spi driver, you would then need to also define all required information in DT (address mode, available read commands, size etc, everything that is currently hardcoded in the table)
Sep 30 12:58:25 <zajec> ok, i see
Sep 30 12:58:53 <KanjiMonster> only then you could declare it to be compatible with a generic spi nor flash
Sep 30 12:59:46 <zajec> again, it's the damn thin line
Sep 30 12:59:54 <zajec> KanjiMonster: to workaround this I could imagine simple solution
Sep 30 13:00:14 <zajec> let's use property "detection mode" and set it to "JEDEC" or "manual"
Sep 30 13:00:39 <KanjiMonster> and when are you supposed to set what?
Sep 30 13:01:19 <zajec> KanjiMonster: or another example, take a look at this leds-gpio
Sep 30 13:01:28 <zajec> there are many optional properties
Sep 30 13:01:38 <zajec> like trigger or default-state
Sep 30 13:01:58 <KanjiMonster> any time you need to rely on extra information to determine if you are compatible or not you need to able to express these in DT
Sep 30 13:02:24 <zajec> i've CPU led that won't work correctly unless you provide a propery trigger set to heartbeat
Sep 30 13:05:45 <zajec> this is optional property, so when not available, kernel also takes some assumption
Sep 30 13:05:57 <zajec> and the assumption of making it "default-off" won't work for me
Sep 30 13:06:15 <zajec> just like spi-nor assuming JEDEC ID can be used, won't work for me
Sep 30 13:06:21 <zajec> (in some cases)
Sep 30 13:06:31 <Devastator> excuse me if I'm saying garbage, but isn't a led way more simple to handle than an spi device?
Sep 30 13:07:18 <zajec> sure it is
Sep 30 13:07:18 <zajec> i just started looking at some random trivial DT driver for a reference
Sep 30 13:09:04 <KanjiMonster> you are really comparing apples with oranges here, because the absence of the default-trigger does not mean the led can't work, it just isn't registered to the correct event
Sep 30 13:09:27 <KanjiMonster> this is something you can "fix" from userspace
Sep 30 13:09:58 <KanjiMonster> and it isn't expected to be "known" by the driver
Sep 30 13:13:29 <zajec> ok, I can at least see the point now
Sep 30 13:13:30 <zajec> thanks
Sep 30 13:14:37 <KanjiMonster> as I said, a potential solution could be to write a generic spi-nor-flash driver that takes all information from device tree instead of the internal table
Sep 30 13:15:01 <KanjiMonster> that would be rather clean one
Sep 30 13:15:43 <KanjiMonster> since this even would allow dt aware bootloaders (like u-boot) to reuse the information
Sep 30 13:41:28 <Devastator> is the old subject done? can I start a new one? :)
Sep 30 13:42:15 <Devastator> I'm hoping to understand a few things by the end of this day heh
Sep 30 13:43:45 <Devastator> though I'm afraid to ask the question again..
Sep 30 13:48:00 <Devastator> ok, let me put this way: if "uci show" have network.test1=interface, network.test1.proto=static, network.test1.ifname=eth0.2, should test1 or eth0.2 show up in ifconfig -a no matter what target?!
Sep 30 14:01:58 <jow_laptop> Devastator: eth0.2
Sep 30 14:02:35 <Devastator> jow_laptop ok, ifconfig doesn't show eth0.2, does this means the target doesn't support vlan?
Sep 30 14:03:12 <zorun> I'm getting "//usr/lib/opkg/info/babeld.postinst: line 4: default_postinst: not found" when trying to install a trunk package on bb-rc3
Sep 30 14:03:33 <zorun> did things really change that much?
Sep 30 14:05:11 <zorun> looks like it did
Sep 30 14:05:12 <zorun> crap
Sep 30 14:05:36 <Devastator> zorun is this what you are trying to install? https://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/routing/babeld_1.5.1-1_ar71xx.ipk
Sep 30 14:06:15 <zajec> Devastator: unless you use bridge
Sep 30 14:06:27 <zajec> Devastator: then you'll also have br-test1
Sep 30 14:06:38 <zorun> ah
Sep 30 14:06:44 <zorun> BB has been released then? \o/
Sep 30 14:06:50 <zajec> Devastator: you should get eth0.2, no matter if there is a switch or not
Sep 30 14:07:01 <zajec> Devastator: sending VLAN-tagged packets doesn't require a switch
Sep 30 14:07:11 <zorun> Devastator: I was using the trunk version
Sep 30 14:08:29 <Devastator> zajec well, this is a router I never messed with, it's a ubiquiti edgerouter lite with 3 independent ports (I think), I tried to create vlans but ifconfig doesn't show them for some reason I'm trying to discover
Sep 30 14:09:10 <Devastator> zorun I don't know if this is an official release, but 14.07 folder was created yesterday without RC in its name
Sep 30 14:10:38 <Devastator> zajec the target is octeon, don't know if that matters, from what you and jow_laptop said, it shouldn't matter
Sep 30 14:13:42 <zajec> i think this is a generic part
Sep 30 14:13:49 <zajec> no idea why it doesn't work for you
Sep 30 14:15:29 <jow_laptop> Devastator: try setting either ipaddr or ip6addr on your test1 iface
Sep 30 14:15:37 <jow_laptop> Devastator: or change the proto to none
Sep 30 14:16:04 <jow_laptop> zorun: echo 'default_postinst() { :; }' >> /lib/functions.sh
Sep 30 14:16:05 <Devastator> jow_laptop do you want my /etc/config/network and uci show output? I can pastebin for you
Sep 30 14:16:10 <jow_laptop> Devastator: sure
Sep 30 14:16:36 <Devastator> jow_laptop one second, please hold on! haha
Sep 30 14:18:58 <zorun> jow_laptop: thanks
Sep 30 14:19:36 <Devastator> jow_laptop here is /etc/config/network: http://codepad.org/Qg2tHKbF
Sep 30 14:19:48 <Devastator> I don't have test1, was just an example
Sep 30 14:20:04 <Devastator> but vlan1, vlan2 etc is what I'm trying to see
Sep 30 14:20:10 <Devastator> one sec and I paste uci show
Sep 30 14:21:43 <jow_laptop> Devastator: what happens if you run "ifup vlan1" ?
Sep 30 14:22:09 <Devastator> jow_laptop prompt returns and logread shows it should be up
Sep 30 14:22:18 <jow_laptop> Devastator: and ifstatus vlan1 ?
Sep 30 14:22:30 <jow_laptop> Devastator: what about lsmod | grep 8021q ?
Sep 30 14:24:57 <Devastator> jow_laptop one second
Sep 30 14:27:32 <Devastator> jow_laptop http://codepad.org/j73NLO7P
Sep 30 14:28:31 <Devastator> jow_laptop and here is uci show: http://codepad.org/bQTXMUdl
Sep 30 14:31:43 <zajec> KanjiMonster: so you would like to support two compatibility strings? "m25p80" and "spi-nor-flash"?
Sep 30 14:31:53 <zajec> "m25p80" would be for JEDEC compatible devices
Sep 30 14:32:08 <zajec> and "spi-nor-flash" for devices that don't respond to JEDEC?
Sep 30 14:32:25 <zajec> *don't respond to RD ID
Sep 30 14:34:47 <KanjiMonster> zajec: the m25p80 makes only sense for spi flash chips that support at least the same commands as the m25p80
Sep 30 14:34:57 <KanjiMonster> and behave the same
Sep 30 14:35:33 <KanjiMonster> because if they don't, then they aren't compatible
Sep 30 14:35:37 <zajec> ok, I see
Sep 30 14:36:34 <KanjiMonster> the device tree model should be based on the hardware, not the driver
Sep 30 14:42:47 <Devastator> this is so dumb but.. how do I update my openwrt git clone?
Sep 30 14:42:50 <Devastator> git fetch?
Sep 30 14:43:34 <zajec> fetch updates local copy of remote
Sep 30 14:43:39 <zajec> then you have to update your local branch
Sep 30 14:43:45 <zajec> use pull/rebase/merge
Sep 30 14:43:57 <zajec> in general you can try "git pull"
Sep 30 14:45:22 <Devastator> thanks Mr Milecki :P
Sep 30 14:50:52 <Devastator> now let's put my 4 cores to work..
Sep 30 14:51:11 * Devastator prays..
Sep 30 14:51:21 <Devastator> please, compile without errors!
Sep 30 15:00:06 <KanjiMonster> zajec: btw, there also seems to be a #devicetree ;)
Sep 30 15:01:42 <Devastator> because of this DT discussion I started to read devicetree.org wiki
Sep 30 15:03:09 <Devastator> zajec if you don't mind me asking, how old are you and how many years you had when you started to program in C?
Sep 30 15:03:53 <KanjiMonster> Devastator: the channel seems to be rather empty
Sep 30 15:04:46 <Devastator> KanjiMonster isn't devicetree rather new?
Sep 30 15:05:05 <Devastator> not the channel, but the proposal
Sep 30 15:06:02 <Kaloz> devicetree itself is old, implementing it on non-ppc is the new kid on the lock
Sep 30 15:06:13 <Kaloz> block*
Sep 30 15:09:15 <Devastator> I see, because it's being rather difficult to rework things to use DT
Sep 30 15:09:24 <Devastator> from what I can see at least
Sep 30 15:09:57 <Devastator> I have the feeling people is still trying to understand how to use it properly or the way it was meant to be used
Sep 30 15:11:53 <Devastator> people is.. gosh, my english teacher will kill me!
Sep 30 15:12:00 <Devastator> people ARE
Sep 30 15:17:36 <Devastator> oh noes, nature is calling :(
Sep 30 15:29:23 <zajec> Devastator: i have no idea for how many years I may be using C ;) i can say I started programming with Turbo Pascal, but you will likely have to Google that :P
Sep 30 15:30:34 <zajec> at least I don't remember Cobol times :D
Sep 30 15:37:03 <Devastator> zajec haha you are probably on your 50's then :P
Sep 30 15:39:34 <KanjiMonster> I also remember turbo pascal from school (and delphi later)
Sep 30 15:40:05 <nighty^> prolog ?
Sep 30 15:40:08 <nighty^> lisp ?
Sep 30 15:40:11 <nighty^> ada ?
Sep 30 15:40:19 <nighty^> pl/1 ?
Sep 30 15:40:27 <__trine> fortran
Sep 30 15:40:41 <nighty^> basic
Sep 30 15:40:52 <nighty^> bcpl
Sep 30 15:41:05 <KanjiMonster> prolog was fun
Sep 30 15:41:15 <KanjiMonster> not that I remember much of it
Sep 30 15:41:24 <nighty^> Yes prolog was nice
Sep 30 15:41:33 <KanjiMonster> haskell, too
Sep 30 15:41:40 <nighty^> haskell is more recent
Sep 30 15:42:04 <nighty^> erlang
Sep 30 15:42:18 <nighty^> forth
Sep 30 15:42:28 <nighty^> forth was fun (RPN)
Sep 30 15:42:41 <nighty^> still is
Sep 30 15:45:37 <builder> build #607 of iop32x is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/607
Sep 30 15:48:39 <Devastator> old people! heh
Sep 30 15:52:22 <KanjiMonster> or just having attended university
Sep 30 15:52:49 <Devastator> I'm 30 years old, guess I'm too old to start now
Sep 30 15:53:33 <Devastator> IIRC Felix has 31 and already have one of the world most famous router firmware :P
Sep 30 15:53:58 <KanjiMonster> you are never too old
Sep 30 15:55:13 <Devastator> thanks for the support :)
Sep 30 16:17:56 <builder> build #774 of at91 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/774
Sep 30 16:44:34 <Mazilo> KanjiMonster: ping.
Sep 30 17:38:27 <zajec> Hauke: hi, i think we finally have some progress with bcma patches :)
Sep 30 17:38:39 <zajec> Hauke: there were few comments to the [PATCH v6] bcma: register bcma as device tree driver
Sep 30 17:39:01 <zajec> i don't think we need separated file as Arnd suggested
Sep 30 17:39:10 <zajec> I think we can live with this #ifdef
Sep 30 17:39:25 <zajec> Hauke: devm_ioremap_resource may be worth checking
Sep 30 17:40:00 <zajec> Hauke: the whole bcma_of_fill_device indede seems unneeded
Sep 30 17:40:13 <zajec> Hauke: will you have a time to work on V7?
Sep 30 18:03:52 <KanjiMonster> Mazilo: pong.
Sep 30 18:04:38 <Mazilo> KanjiMonster: I was lurking around the rules.mk file and notice STAGING_DIR_HOST isn't beging exported. Is there a reason for that?
Sep 30 18:06:03 <KanjiMonster> Mazilo: no idea. why do you need it exported?
Sep 30 18:07:14 <builder> build #198 of brcm2708 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm2708/builds/198
Sep 30 18:08:05 <Mazilo> KanjiMonster: I noticed the STAGING_DIR has been exported, but not STAGING_DIR_HOST. It certainly would be nice to have STAGING_DIR_HOST exported by default, instead of using ${STAGING_DIR}/../host.
Sep 30 18:09:17 <KanjiMonster> STAGING_DIR is exported because gcc expects/uses it AFAIK
Sep 30 18:10:13 <KanjiMonster> why would you need STAGING_DIR_HOST exported?
Sep 30 18:12:22 <KanjiMonster> STAGING_DIR_HOST is available in the OpenWrt Makefiles, so I'm not sure where you would need it exported.
Sep 30 18:14:42 <Mazilo> Here is a simple example one may need STAGING_DIRHOST exported.
Sep 30 18:15:25 <Mazilo> Try to run this 'staging_dir/host/usr/bin/perl -MExtUtils::Embed -e ccopts' and it returns '-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -I/opt/openwrt-git-trunk/staging_dir/host/usr/lib/perl5/5.20.0/x86_64-linux/CORE'.
Sep 30 18:16:28 <Mazilo> When one wants to replace the '/opt/openwrt-git-trunk/staging_dir/host' with '/opt/openwrt-git-trunk/staging_dir/<target platform', having STAGING_DIR_HOST exported will become simpler.
Sep 30 18:16:40 <Mazilo> That's only one example I can think of.
Sep 30 18:19:34 <KanjiMonster> that example doesn't make much sense, because these seems to be the cflags used for compiling the host binary, and have nothing to to with the clags for the target
Sep 30 18:20:07 <KanjiMonster> so I don't quite follow why you would want to do that
Sep 30 18:41:27 <Mazilo> KanjiMonster: What you said is true. But, having STAGING_DIR_HOST exported allow a shell script to simply replace the '/opt/openwrt-git-trunk/staging_dir/host' with ${STAGING_DIR_HOST}.
Sep 30 18:43:01 <KanjiMonster> in what situation would you need to do that?
Sep 30 18:45:08 <Mazilo> Take a look at the 'telephony/net/freeswitch/patches/0000010-configure_ac.patch'.
Sep 30 18:46:06 <Mazilo> Line #57 (AC_CHECK_PROG([PERL],[perl],[ac_cv_have_perl=yes],[ac_cv_have_perl=no],[${STAGING_DIR}/../host/usr/bin])) will make use of STAGING_DIR_HOST instead of ${STAGING_DIR}/../host
Sep 30 18:47:17 <Mazilo> Sorry, it is on line 47
Sep 30 18:51:11 <KanjiMonster> Mazilo: can't you just pass a path to perl to configure?
Sep 30 18:51:36 <Mazilo> KanjiMonster: I sure would if I knew how to. But, I don't know. :(
Sep 30 18:54:04 <Mazilo> With the perl (HOST) resides on STAGING_DIR_HOST and platform perl resides on STAGING_DIR/<target platform>, any output from perl (HOST) that points to STAGING_DIR_HOST can be simply circumvented if STAGING_DIR_HOST is exported.
Sep 30 18:54:45 <Mazilo> If exporting STAGING_DIR_HOST can cause a problem, then I understand why it is not being exported.
Sep 30 18:57:32 <Hauke> zajec: yes looks good I will send a V7 today
Sep 30 18:58:07 <Hauke> I do not like the separate file for device tree stuff
Sep 30 18:59:02 <KanjiMonster> Mazilo: using the output of the host perl for the target perl sounds like the wrong approach and prone to subtle errors
Sep 30 18:59:41 <Mazilo> When I said perl (HOST), I meant this 'staging_dir/host/usr/bin/perl' produced by perl package.
Sep 30 19:00:41 <KanjiMonster> yes, I understood that. And I think that it sounds dangerous to use the output of that as an assumption about the target perl binary/configuration.
Sep 30 19:00:42 <Mazilo> See this http://paste.debian.net/123867/
Sep 30 19:01:04 <Mazilo> oh IC.
Sep 30 19:01:56 <KanjiMonster> I mean in that example just replacing the STAGING_DIR_HOST part would still not give you the right path, as it has the arch again in the path
Sep 30 19:02:44 <Mazilo> I understood what you said. But, if I had STAGIND_DIR_HOST exported, then the arch will also be removed with scripts.
Sep 30 19:04:28 <Mazilo> This is just one example. I believe other packages may make use of STAGING_DIR_HOST when exported. Like I said, it will make more sense to have STAGING_DIR_HOST exported unless it causes more problems.
Sep 30 19:08:11 <KanjiMonster> IMHO exports should not be done unless required
Sep 30 19:08:53 <KanjiMonster> Mazilo: does freeswitch require the host perl, or are actually trying to convert the host perl output to make it compile against the target (lib)perl?
Sep 30 19:10:28 <KanjiMonster> because in case of the latter you need to pass appropriate contents for PERL, PERL_SITEDIR, PERL_LIBDIR, PERL_LIBS, PERL_CFLAGS, PERL_LDFLAGS, PERL_INC to the configure script
Sep 30 19:11:19 <Mazilo> KanjiMonster: Only mod-perl (along with libs/esl) require perl.
Sep 30 19:11:38 <KanjiMonster> host perl or target perl or both?
Sep 30 19:11:50 <Mazilo> target perl.
Sep 30 19:12:07 <KanjiMonster> then you don't want to touch the host perl at all
Sep 30 19:12:21 <KanjiMonster> and you need to pass the mentioned variables to the configure script
Sep 30 19:12:56 <Mazilo> Yes.
Sep 30 19:12:58 <Mazilo> The current configure.ac file has been patched using target perl. But, target perl package lacks perl utilities to automatically generate the perl flags and libs.
Sep 30 19:13:19 <Mazilo> And, that is what I would prefer to do.
Sep 30 19:13:22 <KanjiMonster> I'm looking at the unmodified configure script
Sep 30 19:13:33 <Mazilo> OK.
Sep 30 19:14:10 <KanjiMonster> and as far as I understand it, it should work if you call it wiht PERL=foo PERL_SITEDIR="bar" PERL_LIBDIR="baz" etc
Sep 30 19:14:48 <Mazilo> Yes and that works OK. But, I would prefer to have those variables generated with perl utilities instead of assigning them manually.
Sep 30 19:15:18 <KanjiMonster> well, you can't use the host perl for that, that is definitely wrong.
Sep 30 19:15:33 <Mazilo> I was thinking to use the perl (HOST) utility and use script to manipulate the staging_dir/host into staging_dir/<target platform>.
Sep 30 19:16:07 <KanjiMonster> and that is definitely the wrong way.
Sep 30 19:16:29 <KanjiMonster> because likely the host perl is linked against different libs than the target perl
Sep 30 19:16:33 <KanjiMonster> (e.g.)
Sep 30 19:17:12 <KanjiMonster> you need to find a way of getting the contents from the built target perl
Sep 30 19:18:17 <Mazilo> Yes.
Sep 30 19:20:53 <Mazilo> I just wish there is a way to build perl package with host utilities that know the content sfrom the built target perl.
Sep 30 19:21:08 <Mazilo> This will resolve the problem.
Sep 30 19:32:11 <zajec> Hauke: great, thanks :)
Sep 30 19:37:44 <KanjiMonster> Mazilo: I think you should try talking with the perl package maintainer
Sep 30 19:38:25 <Mazilo> KanjiMonster: Thanks for your suggestion.
Sep 30 20:40:45 <Hauke> zajec: bcma: register bcma as device tree driver is already in wireless-testing
Sep 30 21:08:09 <zajec> Hauke: no prob, it's just testing
Sep 30 21:08:15 <zajec> John can remove patches from it, rebase, etc.
Sep 30 21:08:24 <zajec> wireless-next is untouchable ;)
Sep 30 21:08:49 <Hauke> zajec: it is also there
Sep 30 21:08:50 <zajec> oh, it's in the wireless-next too
Sep 30 21:08:59 <zajec> well... i would leave it that way then
Sep 30 21:09:08 <zajec> and if we want to fix somethnig, do a incremental patch
Sep 30 21:09:50 <zajec> well, this code isn't that bad anyway :)
Sep 30 21:09:57 <zajec> so i think i'm quite happy overall
Sep 30 21:09:57 <Hauke> I already have a patch for the devm_ioremap_resource() function
Sep 30 21:10:11 <zajec> cool :)
Sep 30 21:10:15 <Hauke> and you added a documented child node in the example
Sep 30 21:10:28 <zajec> patch for bcma_of_fill_device should be trivial
Sep 30 21:10:32 <zajec> right
Sep 30 21:10:45 <zajec> you don't need anything from bcma_of_fill_device
Sep 30 21:10:58 <zajec> this could be as simple as: core->dev.of_node = bcma_of_find_child_device(parent, core);
Sep 30 21:11:06 <zajec> there is no need to check for NULL etc. I believe
Sep 30 21:11:13 <zajec> or am I wrong?
Sep 30 21:13:34 * zajec has to go sleep
Sep 30 21:14:21 <Hauke> night
Sep 30 21:36:51 <OpenWrt-Commits> nbd r42703 trunk/package/kernel/mac80211/ (5 files) * ath9k: add a fix for dynack
Sep 30 21:36:58 <OpenWrt-Commits> nbd r42704 trunk/toolchain/binutils/Makefile * binutils: update -linaro to 2.24.0-2014.09
Sep 30 21:37:02 <OpenWrt-Commits> nbd r42705 trunk/toolchain/binutils/Config.in * binutils: select linaro 2.24 version by default
Sep 30 21:37:13 <OpenWrt-Commits> nbd r42706 trunk/toolchain/ (21 files in 3 dirs) * gcc: add 4.9-linaro based on the 2014.09 release
Sep 30 21:37:18 <OpenWrt-Commits> nbd r42707 trunk/package/devel/binutils/Makefile * binutils: fix build with gcc 4.9
Sep 30 21:38:18 <Devastator> hum, I've made a terrible mistake
Sep 30 21:39:20 <__trine> Devastator, so did I
Sep 30 21:39:20 <Devastator> I've cloned 14.07 repo, thinking it was the final build, but as I see, it is still being updated
Sep 30 21:39:32 <__trine> I got married
Sep 30 21:39:55 <Devastator> that's not a mistake, you have free sex whenever you want :)
Sep 30 21:40:13 <__trine> but i had that before
Sep 30 21:40:43 <Devastator> you wouldn't have if you didn't get married
Sep 30 21:41:19 <__trine> I have just updated to ubuntu 14.04 and now the keyboard has no effect in my xfwrite window
Sep 30 21:41:44 <Devastator> do you happen to have any router running BB final?
Sep 30 21:42:04 <__trine> no all mine are variations of trunk
Sep 30 21:48:06 <__trine> and Devastator if you think it's free when you have got married you are making another terrible mistake
Sep 30 21:48:11 <__trine> :)
Sep 30 21:51:43 <Devastator> hahahah
Sep 30 21:51:54 <Devastator> my first terrible mistake is regarding BB
Sep 30 23:40:44 <builder> build #186 of omap is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/omap/builds/186
**** ENDING LOGGING AT Wed Oct 01 03:00:00 2014