**** BEGIN LOGGING AT Thu Dec 12 02:59:59 2013
Dec 12 03:01:21 <synthesize> I'm looking for 'advanced' u-boot documentation with regards to strategies in handling upgrades - it seems like a common solution is to just reflash u-boot in order to fix bugs. This happens fairly normally under situations where your CPLD/FPGA has a change in behavior and needs to have a different initialization.
Dec 12 03:02:10 <synthesize> I've used hush scripts for this in the past, but I'm thinking about trying to rig up a 'patch' system so that there are compiled u-boot programs that get added to a repo in flash with some sorting rules for what overides what.
Dec 12 03:02:20 <synthesize> Just wondering if someone has documented this or if I should as I work through it.
Dec 12 06:26:42 <linu> hi i try to load g_multi gadget module in my at91sam9g35 board it shows me the following error,and i have used poky with meta-atmel, please see http://pastebin.com/bESYQgt2 can you help me
Dec 12 07:33:05 <ak77> hello!
Dec 12 07:34:57 <ak77> i want to upgrade SD card with new image but on a system running from that SD card. tried with simple umount, dd, reboot, but had many errors.
Dec 12 07:36:00 <tobiash_> ak77: I do that with a second partition containing a minimal sysroot
Dec 12 07:36:40 <tobiash_> ak77: you can switch to the second partition with systemctl switch-root and flash the first partition from there
Dec 12 07:38:44 <ak77> i'm not using systemd (yet).
Dec 12 07:38:57 <ak77> but yes. second partition. hmm.
Dec 12 07:40:18 <tobiash_> I also do an emergency remount ro before flashing
Dec 12 07:41:36 <tobiash_> (I wasn't able to unmount the original root somehow)
Dec 12 09:50:55 <bluelightning> morning all
Dec 12 09:58:53 <LetoThe2nd> howdy bluelightning
Dec 12 09:59:53 <bluelightning> hi LetoThe2nd
Dec 12 10:07:39 <mckoan> good morning
Dec 12 10:48:19 <ak77> bluelightning: morning!
Dec 12 10:49:38 <ak77> still on the quest of searching why my recipe with CC -lbluetooth wants bluez4 package although I use bluez5, it tries to satisfy bluez4 (>= 4.101) *
Dec 12 10:53:16 <bluelightning> hi ak77
Dec 12 10:55:38 <ak77> dependency got into my package's build/tmp/work/ARCH/${PN}/${PV}-${PR}/packages-split/${PN}.shlibdeps
Dec 12 10:55:55 <bluelightning> ak77: it must be linking against the wrong library then
Dec 12 10:56:04 <bluelightning> ak77: I'd suggest looking at the compile logs and what's in the sysroot
Dec 12 10:58:09 <ak77> bluelightning: the sysroot has only bluez5 libs, "bitbake mypackage" build allright
Dec 12 10:58:53 <ak77> bluelightning: it fails during do_rootfs, when it's installing ipks
Dec 12 10:59:44 <bluelightning> ak77: right, I got that
Dec 12 11:01:17 <bluelightning> ak77: anything of interest in log.do_package?
Dec 12 11:03:50 <ak77> bluelightning: calculation of shlib requirements concludes with: DEBUG: brcm-patchram-plus-usb: Dependency libbluetooth.so.3 requires package bluez4
Dec 12 11:07:38 <bluelightning> ak77: that says that bluez4 must have been built
Dec 12 11:10:51 <bluelightning> ak77: try: grep libbluetooth.so.3 tmp/sstate-control/manifest-*
Dec 12 11:16:17 <ak77> bluelightning: indeed. there are two libbluetooth.so.3, (one for bluez4 and one for bluez5) and then there is libbluetooth.so.3.13.0 (bluez4) and libbluetooth.so.3.17.1
Dec 12 11:17:15 <bluelightning> ak77: ok... so assuming you did clean it before as I suggested, something is still depending upon it
Dec 12 11:17:48 <bluelightning> ak77: to find out what that is, you can do bitbake -g <whatever you normally build> and then grep the .dot files produced for bluez4
Dec 12 11:19:07 <ak77> bluelightning: khm.. now after bitbake bluez4 -c cleansstate, manifest show only bluez5. now i'll try to bitbake mypackage to see if it brings it back
Dec 12 11:19:36 <bluelightning> ak77: right, clean/cleansstate would remove the sysroot parts and hence the manifests for them
Dec 12 11:31:40 <Leo___> Anybody that can gives me a tip why bit bake is failing on the last do_rootfs task when trying to build fsl-image-gui? everything seems to have compiled but I got an error "package architecture (armel) does not match system (i386)" and 	1.	| The following packages have unmet dependencies:
Dec 12 11:31:41 <Leo___> 	2.	|  packagegroup-core-x11-base : Depends: packagegroup-core-x11-utils but it is not going to be installed"
Dec 12 11:31:56 <Leo___> full error log here: http://pastebin.com/ryx49VAc
Dec 12 11:32:45 <ak77> bluelightning: i also did cleanall on my package. now it doesn't compile. can't find includes (bluetooth/bluetooth.h)
Dec 12 11:33:14 <bluelightning> ak77: if bluez4 and bluez5 are deploying the same files, you may need to clean and build bluez5 again
Dec 12 11:34:23 <Marex_> Hi guys, I have another stupid question. Where can I find documentation for the difference between '+=' and '_append' operator please ?
Dec 12 11:34:58 <Marex_> I just recently used VAR_mymachine += ' package ' , which broke my build, while VAR_append_mymachine = ' package ' did not.
Dec 12 11:35:45 <ak77> bluelightning: thank you. that was solved by clean/build of bluez5,
Dec 12 11:36:02 <bluelightning> Marex_: the bitbake manual
Dec 12 11:36:03 <RP> Marex_: look at the bitbake manual. The difference is when the addition is applied. one is immediate, the other deferred
Dec 12 11:36:10 <bluelightning> right, what he said :)
Dec 12 11:36:27 <bluelightning> hi Marex_ btw :)
Dec 12 11:36:36 <Marex_> http://docs.openembedded.org/bitbake/html/ this is what I was looking for !
Dec 12 11:36:38 <Marex_> wow, thank you !
Dec 12 11:37:07 <RP> Leo___: that looks like the debian package backend, you might have more success with opkg
Dec 12 11:39:52 <Marex_> bluelightning: hey :)
Dec 12 11:40:15 <ak77> bluelightning: yes, cleaning of all three involved packages (bluez4, bluez5, mypackage) and rebuilding did the trick. thank you.
Dec 12 11:40:50 <Marex_> RP: so if I use _append , it's deffered ?
Dec 12 11:40:52 <bluelightning> ak77: right, but I'm still curious as to how you got into this situation - if something does depend on bluez4 directly in your build, you'll likely hit the same problem later on
Dec 12 11:41:02 <Marex_> *deferred
Dec 12 11:41:50 <bluelightning> Marex_: right, the other difference is that += adds a space when appending, whereas _append does not
Dec 12 11:41:53 <RP> Marex_: ye
Dec 12 11:41:56 <RP> yes
Dec 12 11:42:30 <ak77> bluelightning: i tried to compile alsa, maybe it picked it up... but this is 'negative surprise', how can system pick up something just because it's there. to be sure one would have to delete everything.
Dec 12 11:43:11 <bluelightning> ak77: well, ideally we'd flag up this conflict and fail the build immediately
Dec 12 11:43:32 <bluelightning> ak77: I'm not sure what mechanism we'd use to do that though
Dec 12 11:46:58 <Marex_> bluelightning: I got that "far" (but I do appreciate the help!), I am now trying to wrap my head around this "deferred" appending though
Dec 12 11:47:25 <bluelightning> Marex_: with += the value is appended immediately when the line is parsed
Dec 12 11:48:08 <bluelightning> Marex_: with _append, it is put into a separate area and gets appended each time the value of the variable is expanded (usually at some much later time)
Dec 12 11:49:03 <Marex_> bluelightning: so if I use this with DEPENDS (DEPENDS_mymachine += vs. DEPENDS_append_mymachine = ), what happens there please ?
Dec 12 11:49:19 <Marex_> bluelightning: I am starting it catch up ... maybe ;-/
Dec 12 11:49:58 <bluelightning> Marex_: that is a good question; basically you should not mix overrides and += because the two operations will happen at different times, and because of the override you'll usually end up stomping on the value instead of appending to it
Dec 12 11:50:47 <Marex_> bluelightning: so the rule of the thumb here is to use _append with DEPENDS, right ?
Dec 12 11:51:19 <bluelightning> Marex_: use _append in conjunction with overrides
Dec 12 11:51:26 <bluelightning> Marex_: such as _mymachine
Dec 12 11:51:46 <bluelightning> Marex_: it would be DEPENDS_append_mymachine = " somevalue"
Dec 12 11:52:52 <bluelightning> Marex_: another note, if you're effectively making the recipe machine-specific by doing this, you'll also want to do PACKAGE_ARCH = "${MACHINE_ARCH}" for the recipe so that multi-machine builds continue to work properly
Dec 12 11:53:04 <bluelightning> Marex_: (assuming it's not already machine-specific, that is)
Dec 12 11:54:35 <lpapp> rburton: I am not sure what you mean by linux is fetched from git, and that can help me.
Dec 12 11:54:42 <lpapp> I cannot find a .git folder after the fetch.
Dec 12 11:54:54 <rburton> lpapp: the yocto-kernel recipe is built from a git clone
Dec 12 11:55:17 <Marex_> lpapp: see your download dir and there'll be something like git2/ , in there, you'll find the directory with the git repo
Dec 12 11:55:36 <lpapp> Marex_: I do not.
Dec 12 11:55:42 <Marex_> lpapp: there won't be any .git directory anywhere, it's doing bare clone
Dec 12 11:55:54 <Marex_> bluelightning: gotcha, thank you !
Dec 12 11:55:56 <lpapp> well, that is not helpful for patch recreation.
Dec 12 11:56:35 <lpapp> also, we do not have git2 since that would be an embedded git inside a git which is apparently calling for troubles with Yocto.
Dec 12 11:58:13 <lpapp> rburton: well, I thought git diff could be helpful, but apparently there is no such a thing here for my build dir changes.
Dec 12 11:59:15 <lpapp> so I still need to go back to the raw diff?
Dec 12 12:01:07 <Marex_> bluelightning: so if I use _append with overrides, like _mymachine, the append will happen only after the override is processed, right ?
Dec 12 12:01:21 <Marex_> bluelightning: if I use += , the contents of the variable might be dropped once the override is processed ?
Dec 12 12:02:11 <bluelightning> Marex_: with += the plain, non-overridden value would be dropped when the override applies, yes
Dec 12 12:02:22 <bluelightning> Marex_: which is usually not desirable
Dec 12 12:03:11 <bluelightning> Marex_: if you really do mean that to happen (which is sometimes the case) you'd just do MYVAR_mymachine = rather than += and fully express the value
Dec 12 12:03:25 <lpapp> Marex_: _append will be added at the end of the parsing, so it is guaranteed to be there. += is an immediate assignment. so if AA += "BB" is followed later by AA = "CC", then it would be lost
Dec 12 12:07:20 <Marex_> bluelightning: ah, got it now, thank you very much!
Dec 12 12:08:01 <bluelightning> Marex_: np
Dec 12 12:10:14 <Marex_> bluelightning: I owe you a beverage of your preference, remind me in dusseldorf :)
Dec 12 12:15:03 <bluelightning> Marex_: :)
Dec 12 12:15:23 <Crofton|work> we need a beer fund
Dec 12 12:17:00 <Marex_> Crofton|work: make a fundraiser campain :)
Dec 12 12:17:07 <Crofton|work> yeah
Dec 12 12:17:13 <Crofton|work> this is on the todo list
Dec 12 12:18:19 <Marex_> is that the kind of todo list that looks like an infinite roll of toilet paper ?
Dec 12 12:21:47 <Crofton|work> heh
Dec 12 13:47:06 <vicenteolivert> Maybe this is a silly question... How can I know what version of gcc Yocto is using? And more important..., how can I change it?
Dec 12 13:48:51 <bluelightning> vicenteolivert: this will tell you: bitbake -s | grep gcc
Dec 12 13:50:56 <vicenteolivert> bluelightning: that's the gcc used to compile my target? (the gcc of the toolchain)
Dec 12 13:53:01 <bluelightning> vicenteolivert: gcc-cross is, yes
Dec 12 14:52:59 <ak77> I have a function in ROOTFS_POSTPROCESS_COMMAND in a image-making recipe. what variable containes path to host sysroot (where are native tools get installed). (${D} doesnt point to right directory)
Dec 12 14:54:01 <ak77> in that function, I need to access some files i placed in /usr/share/xy when installing my native tool.
Dec 12 14:57:03 <ndec> ak77: STAGING_DIR_NATIVE i believe is what you need.
Dec 12 14:57:28 <ndec> or its BINDIR or INCDIR variant
Dec 12 14:58:18 <ndec> and btw, $D is never the sysroot, but an intermediate folder in the recipe WORKDIR, used before files get installed/populated in the sysroot
Dec 12 15:09:12 <ak77> ndec: thankyou
Dec 12 16:28:57 <vicenteolivert> Can anyone help me setting up the sourcery toolchain please? I have downloaded the "meta-sourcery" layer and put it on the poky dir. Then, I have added that layer to my bblayers.conf file, just before the meta layer. Then I downloaded the sourcery codebench tarball and extracted it (that created the ~/mips-2013.05 directory). Then I have added EXTERNAL_TOOLCHAIN = "/home/myuser/mips-2013.05" to local.conf
Dec 12 16:29:34 <kergoth> sounds about right. what's the issue?
Dec 12 16:30:04 <vicenteolivert> It fails with:
Dec 12 16:30:16 <vicenteolivert>  /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
Dec 12 16:31:01 <kergoth> if it's including /usr/include headers, that sounds like you'er failing in a native recipe, not a target one, so it isn't even failing in a recipe that uses the external toolchain
Dec 12 16:31:08 <kergoth> what exactly is failing? which recipe?
Dec 12 16:31:36 <vicenteolivert> pseudo-native/1.5.1-r4
Dec 12 16:32:35 <bluelightning> vicenteolivert: maybe try NO32LIBS = "1" in local.conf ?
Dec 12 16:33:06 <vicenteolivert> bluelightning: will that affect to my target system? I'm building a MIPS32 target system.
Dec 12 16:33:23 <bluelightning> vicenteolivert: no, that's just for the native (build host) part
Dec 12 16:33:45 <bluelightning> in fact it's only looked at by the pseudo recipe
Dec 12 16:34:04 <vicenteolivert> Ok, added and running the "bitbake core-image-minimal" again.
Dec 12 16:34:46 <vicenteolivert> No..., more errors :-(
Dec 12 16:35:04 <bluelightning> vicenteolivert: the same error or something else?
Dec 12 16:35:07 <kergoth> you need to be more specific, if you have an error, post it
Dec 12 16:35:18 <bluelightning> and use pastebin for the errors ;)
Dec 12 16:35:24 <bluelightning> if > 2 lines
Dec 12 16:35:45 <vicenteolivert> Yes, sorry, the error has occured right now. I'm looking at it :-P
Dec 12 16:36:03 <vicenteolivert> It's not the same recipe. It has failed installing the external toolchain. I'll paste it.
Dec 12 16:37:06 <vicenteolivert> bluelightning, kergoth: http://pastebin.ca/2497094
Dec 12 16:39:09 <vicenteolivert> The directory is trying to find it doesn't exists.
Dec 12 17:01:32 <vicenteolivert> bluelightning, kergoth: any clues?
Dec 12 17:02:09 <bluelightning> brb
Dec 12 17:03:19 <kergoth> Hmm, odd, never seen that one. which toolchain is this?
Dec 12 17:03:48 <vicenteolivert> kergoth: Sourcery Codebench.
Dec 12 17:04:03 <vicenteolivert> I'm following the instructions: https://github.com/MentorEmbedded/meta-sourcery
Dec 12 17:07:50 <kergoth> vicenteolivert: obviously, it's codebench
Dec 12 17:07:58 <kergoth> what *exact* version? pro or lite?
Dec 12 17:08:09 <kergoth> i hae to support like 32 combinations of arch and versions with that layer
Dec 12 17:08:09 <vicenteolivert> kergoth: lite.
Dec 12 17:08:11 <kergoth> i can't test them all
Dec 12 17:08:21 <vicenteolivert> kergoth: mips-2013.11-36-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2
Dec 12 17:08:29 <kergoth> thank you, that'ss what i needed
Dec 12 17:08:44 <vicenteolivert> kergoth: do you want the link so I can save you time?
Dec 12 17:08:47 <kergoth> I'll pull it down and try to repro
Dec 12 17:08:49 <kergoth> sure
Dec 12 17:08:57 <vicenteolivert> wget https://sourcery.mentor.com/GNUToolchain/package12215/public/mips-linux-gnu/mips-2013.11-36-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2
Dec 12 17:10:13 <vicenteolivert> kergoth: thank you very much for your time and help :-)
Dec 12 17:10:16 <kergoth> excellent, thanks
Dec 12 17:10:17 <kergoth> np
Dec 12 17:10:35 <kergoth> The lite ones usually aren't a priority for us, but we do try to ensure they stay working with yocto
Dec 12 17:11:03 <vicenteolivert> kergoth: aha.
Dec 12 17:12:14 <vicenteolivert> kergoth: I will be off work in a few minutes, so please, don't be upset if you talk me and I don't reply. That's because I'm not here.
Dec 12 17:13:53 <kergoth> k
Dec 12 17:23:32 <vicenteolivert> The reason I'm trying to use this external toolchain is because I need to build a target with micromips support (rootfs compiled with -mmicromips CFLAG). If I try to do that using the Yocto toolchain it fails because it's gcc doesn't recognize that option. I don't know why, because as fas as I know, that option was introduced in Mar 2013, so gcc-4.8.2 should have it.
Dec 12 17:24:02 <LetoThe2nd> howdy! how to make fortran available as a dependency?
Dec 12 17:30:03 <LetoThe2nd> a simple DEPENDS doesn't seem to do the trick
Dec 12 17:31:29 <bluelightning> vicenteolivert: where were you setting the CFLAGS though?
Dec 12 17:32:04 <vicenteolivert> bluelightning: in my local.conf, TARGET_CFLAGS_append = " -mmicromips"
Dec 12 17:32:21 <bluelightning> vicenteolivert: ok
Dec 12 17:37:12 <vicenteolivert> I have to go. See you tomorrow and have a nice day :-)
Dec 12 17:44:12 <kergoth> vicenteolivert: hmm, actually hit an entirely different failure than you did, i got past the toolchain install, but failed in libffi
Dec 12 17:44:25 <kergoth> actually, i think meta-mentor might have that fix, maybe i should move it or push to oe-core
Dec 12 17:49:17 <LetoThe2nd> any hints about needing fortran as a dependency?
Dec 12 17:57:29 * mr_science 's ears perk up at the mention of Fortran...
Dec 12 17:58:28 <mr_science> hmm, not enough log today...
Dec 12 17:58:46 <mr_science> LetoThe2nd: can you catch me up?
Dec 12 17:59:06 <mr_science> damn, i got a standup in 1 minute...
Dec 12 18:00:06 <LetoThe2nd> mr_science: i want to make up a recipe for R, for which the docs say it needs fortran
Dec 12 18:20:26 <mr_science> back
Dec 12 18:21:29 <mr_science> LetoThe2nd: i did some R hacking, er, packaging on Gentoo a while back
Dec 12 18:21:52 <LetoThe2nd> hrhrhr
Dec 12 18:22:16 <mr_science> i don't have access to my yocto build right now, but initially it would depend on the toolchain config
Dec 12 18:22:34 <mr_science> ie, --languages=foo
Dec 12 18:22:51 <mr_science> no reason not to build gfortran, since you pretty much get it for free
Dec 12 18:23:19 <LetoThe2nd> hmm
Dec 12 18:23:46 <mr_science> if it's not already being built that way, you could try a bbappend to add --languages=c,c++,fortan or whatever
Dec 12 18:24:33 <mr_science> but that's really my ass talking without actually looking at it...
Dec 12 18:26:28 <LetoThe2nd> mr_science: no worries, the input is much appreciated
Dec 12 18:28:40 <mr_science> i have a drs appt this afternoon so i could probably take a look when i get back
Dec 12 18:28:54 <mr_science> is there an existing bug, or?
Dec 12 18:33:00 <LetoThe2nd> you mean the fortran thing?
Dec 12 18:35:21 <mr_science> yeah, if you want a test build/bbappend that should be doable
Dec 12 18:36:51 <mr_science> should be able to at least build a toolchain with fortran
Dec 12 18:37:19 <mr_science> do you have any recipes to test yet?
Dec 12 18:37:40 <LetoThe2nd> no, nothing at all. just at the very beginning
Dec 12 18:39:12 <mr_science> so there's essentially no R stuff at all yet?
Dec 12 18:39:38 <mr_science> in anything meta-* anyway...
Dec 12 18:42:54 <LetoThe2nd> nothing that i'm aware of
Dec 12 18:43:48 <kergoth> i think richard looked into / improved the fortran support recently, it's ringing a bell
Dec 12 18:43:55 <LetoThe2nd> *ding*
Dec 12 18:44:25 <kergoth> e.g. [OE-core] [PATCH] gcc: Allow fortran to build successfully in 4.8
Dec 12 18:44:43 <kergoth> search oe-core list archives for fortran
Dec 12 18:45:07 <kergoth> IIRC there's a variable for what gets passed to --languages= that you can change
Dec 12 18:45:18 <mr_science> sounds good
Dec 12 18:45:31 <kergoth> LANGUAGES maybe? something along those lines
Dec 12 18:45:35 <kergoth> check the gcc recipes :)
Dec 12 18:45:56 <LetoThe2nd> just pulled, will now look at it
Dec 12 18:47:01 <mr_science> LetoThe2nd: if you can, let me know if you make any progress today
Dec 12 18:47:40 <mr_science> stephen.arnold42 at the gmail will work...
Dec 12 18:48:17 <LetoThe2nd> mr_science: well you are araound here, not?
Dec 12 18:48:20 <mr_science> there's also the github issue tracker that nobody has used yet
Dec 12 18:48:41 <mr_science> yeah, i will be a bit later
Dec 12 18:49:32 <mr_science> LetoThe2nd: you can be the first: https://github.com/sarnold/meta-raspberrypi
Dec 12 18:57:43 <mr_science> this should be more interesting than your average packaging task...
Dec 12 18:58:43 * LetoThe2nd has just kicked off the rebuild to see whats going on.
Dec 12 19:05:03 <LetoThe2nd> well i found http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5bde5d9b39ea67f19a1a6aedd0c08c6cfedcbe5f
Dec 12 19:05:42 <LetoThe2nd> but does this mean to do nothing at all because a toolchain rebuild will geive me fortran? or shall i depend on libgfortran now?
Dec 12 19:07:04 <kergoth> you still need to ensure fortran is enabled in gcc languages, no?
Dec 12 19:07:45 <kergoth> that commit just ensures the fortran lib is packaged as well
Dec 12 19:08:33 <LetoThe2nd> ah ok
Dec 12 19:09:22 * mr_science still thinking about how to integrate that one...
Dec 12 19:09:41 <kergoth> LANGUAGES ?= "c,c++${FORTRAN}${JAVA}"
Dec 12 19:09:52 <kergoth> looks like you just need to set FORTRAN=",f77"
Dec 12 19:10:02 <kergoth> from a quick look at the gcc recipes, asi pointed out earlier
Dec 12 19:10:11 <kergoth> the var is even named what i thought it was :P
Dec 12 19:13:06 <LetoThe2nd> kergoth: :)
Dec 12 19:16:34 <kergoth> ah, looks like gcc-4.8.inc sets FORTRAN = "" specifically
Dec 12 19:16:40 <kergoth> so you'd actually want to set LANGUAGES = "c,c++,f77"
Dec 12 19:17:42 <LetoThe2nd> yes. a bbappend should do, right?
Dec 12 19:18:22 <kergoth> or local.conf, LANGUAGES is set with ?=
Dec 12 19:18:37 <kergoth> ?= is set only if unset, so the config metadata would take precedence if set
Dec 12 19:18:48 <kergoth> obviously a bbappend is better for long term maintenance
Dec 12 19:18:51 <kergoth> depends on your goals
Dec 12 19:19:51 <LetoThe2nd> goal == learning, tinkering
Dec 12 19:22:18 * kergoth nods
Dec 12 19:22:33 <kergoth> local.conf for a temporary change to see if it works is what i'd do :)
Dec 12 19:25:57 <mr_science> if you set it to --enable-languages=c,c++,fortran you should get both f77 and newer
Dec 12 19:26:35 <kergoth> ah, nice
Dec 12 19:26:38 <kergoth> good call
Dec 12 19:26:50 <kergoth> i think richard removed the f77 bits from the metadata, so that'd be much better :)
Dec 12 19:27:31 <mr_science> meaning it should actually work...  ;)
Dec 12 19:29:02 <kergoth> indeed :)
Dec 12 19:29:34 <mr_science> i'd wager most people don't mess with fortran
Dec 12 19:29:50 <kergoth> i'm kind of surprised richard put time into making sure it worked, he must have been bored
Dec 12 19:30:13 <mr_science> maybe he was science geek at some point in the past?
Dec 12 19:30:33 * mr_science might have one of the only fortran projects on github
Dec 12 19:30:56 <mr_science> almost certainly the only windfield model...
Dec 12 19:31:36 <mr_science> i'm sure *that* would get lots of action if i packaged it for yocto...
Dec 12 19:32:28 <kergoth> hehe
Dec 12 19:32:38 <kergoth> one of the many languages i never learned
Dec 12 19:33:09 <mr_science> it's pretty cool, with real publications and everything
Dec 12 19:33:54 <mr_science> http://www.met.sjsu.edu/cgi-bin/wind/windbin.cgi  <=  it's operational in several orgs
Dec 12 19:40:38 <LetoThe2nd> i currently more thinking about use cases of statistics/R in embedded controls
Dec 12 19:40:55 <kergoth> sounds quite interesting
Dec 12 19:41:19 <LetoThe2nd> thats why i'm looking into it
Dec 12 19:46:56 <mr_science> R is nice tool
Dec 12 19:47:14 <mr_science> which i don't get to play with much any more...
Dec 12 19:48:48 <LetoThe2nd> there are so many nice tools and so little time
Dec 12 19:52:28 <kergoth> agreed
Dec 12 19:52:34 <kergoth> i really want to spend more time with Go
Dec 12 19:52:47 <mr_science> on the development/V&V side there are some really nice/little-used tools
Dec 12 19:53:30 <mr_science> actual formal verification stuff, using model checking, SAT solvers, etc
Dec 12 19:54:32 <mr_science> and some of the cleanest-looking opensource c++ code i've seen
Dec 12 19:55:18 <mr_science> take a gander at this source => https://github.com/niklasso/minisat
Dec 12 19:55:47 <mr_science> i wish more people would give a crap about their (public) code...
Dec 12 19:56:06 * mr_science goes back to his build branch migration
Dec 12 20:10:44 <mr_science> pulled-pork sandwiches today...
Dec 12 22:47:29 <kergoth> I have to say, I kind of hate the bits where libx11 refuses to be buildable without x11 in distro features. it's a useful sanity check, but building it doesn't mean I'm linking much against it, or that it'll end up in my images..
Dec 12 22:49:08 <RP> kergoth: I can't say I'm that keen either fwiw but equally there wasn't any opposition to the patches :/
Dec 12 22:51:11 <kergoth> it's certainly been around for a while now. it's not always a problem, but is occasionally annoying/limiting
Dec 12 22:51:51 * kergoth mulls over such things as an opt-in/opt-out sanity check rather than a requirement
Dec 12 23:26:47 <RP> kergoth: you could probably knock out the check with a suitable override from local.conf I guess :)
Dec 13 02:05:52 <nerdboy> now that i see it, i'm really tempted to set LANGUAGES = "c,c++,d,java,go,objc,obj-c++,fortran,ada" and see what happens...
Dec 13 02:08:20 <nerdboy> and that reminds me of the icedtea/java recipe stuff the other day
Dec 13 02:12:22 * nerdboy tries just LANGUAGES = "c,c++,java,fortran"
Dec 13 02:23:21 <nerdboy> the only "extra" depend should be libart for ecj
Dec 13 02:23:38 <nerdboy> plus the main jar file
**** ENDING LOGGING AT Fri Dec 13 03:00:00 2013