**** BEGIN LOGGING AT Thu Mar 17 02:59:58 2016 Mar 17 04:02:49 trying to `bitbake gumstix-console-image', I get the following error: fatal: unable to connect to gitorious.org: Mar 17 04:02:49 gitorious.org[0: 64.13.172.37]: errno=Connection refused Mar 17 04:02:49 gitorious.org[1: 2a02:c0:1014::1]: errno=Network is unreachable Mar 17 04:02:57 how to fix and finish the build? Mar 17 04:16:12 Capso: the recipe which refers to gitorious needs to be fixed I would assume Mar 17 04:16:42 I have heard that the new gitorious archive now requires https Mar 17 04:54:23 hmm... i've verified that FOO gets set with bitbake -e, but inherit ${FOO} still fails with an error that indicates it expands to nothing (inherit test-${FOO} gives the error "could not inherit file classes/test-.bbclass" for example). any ideas? Mar 17 04:58:20 hrr... probably because it's expanded at the point of the 'inherit' Mar 17 05:14:10 bluelightning, and also a no-cert-check argument to git (I think it's -c) Mar 17 06:17:12 what's the proper way to detect a nativesdk-* recipe inside inline python? d.getVar('PN', True) still gives the name without the nativesdk- prefix (i.e., the same as BPN) from some quick experimentation, and bb.data.inherits_class('nativesdk', d) only works if nativesdk is inherited explicitly and not via BBCLASSEXTEND. Mar 17 06:18:54 not sure how much reparsing is done either. that'd probably determine what makes sense. :/ Mar 17 06:19:36 in this case, i only want to inherit a particular class for nativesdk-* recipes Mar 17 06:26:09 could hack it with overrides perhaps Mar 17 06:28:13 nopes, those are applied later, after the inherit Mar 17 06:58:34 Ulfalizer: that is strange, PN ought to be the value with the nativesdk- prefix Mar 17 06:58:48 when seen as the nativesdk variant Mar 17 06:59:16 often with this sort of thing you can accomplish it using overrides Mar 17 06:59:47 i.e. VARNAME = "the default" Mar 17 06:59:49 VARNAME_class-nativesdk = "the nativesdk value" Mar 17 07:34:35 Good day every one! Is there any way in yocto to pass paths to other recipe source dirs into target one? i have a perl script in target recipe which takes source codes as input and geenerates additional sources files for target recipe. What is the best practice to do that? Mar 17 07:37:33 Ulfalizer: Oh, yeah, IIRC that was exactly why I used this hack; inherit ${SOMETHING} with SOMETHING_class-nativesdk = "" didn't seem to work when "nativesdk" came in via BBCLASSEXTEND Mar 17 07:43:36 neverpanic: I think we'd look at that as being a bug Mar 17 08:57:40 arrgghhh! i just can't seem to get my custom devicetree included and built correctly! i have a file named "mydevice.dts". i have added it to SRC_URI in my kernel recipe. i've set KERNEL_DEVICETREE to different values: currently KERNEL_DEVICETREE="${S}/mydevice.dtb". but i get "no rule to make target..." error while compiling the kernel. Mar 17 08:58:33 i've tried a lot of other combinations "${S}/mydevice.dts", "mydevice.dtb", "mydevice.dts" etc, but none seem to work Mar 17 08:58:41 and google tells me... different things... Mar 17 09:02:43 do i have to copy it into the kernel source tree manually? Mar 17 09:05:54 ionte_: well all these things only work if the kernel source itself is aware of that dts file, afaik Mar 17 09:06:36 ionte_: hence, look at the makefiles in the kernelsources. if the dts gets built correctly if you manually kick off the kernel build, then it should also work in OE Mar 17 09:17:55 ionte_: I use something like this to copy the dts to the kernel tree: do_configure_prepend() { cp ${WORKDIR}/*.dts arch/${ARCH}/boot/dts/ } Mar 17 09:18:27 frsc_: yes, i came to the same conclusion Mar 17 09:18:56 now my problem is to build the destination directory Mar 17 09:21:33 it seems it should be placed in ${WORKDIR}/linux-amun_phycore_am335x-standard-build/arch/${ARCH}/boot/dts/, but i have no idea where that linux-amun... name came from or how to compose it Mar 17 09:22:57 there must be a macro i could use, but they all use "-" instead of "_" ("amun-phycore-am335x"), and i don't like hardcoding it Mar 17 09:23:40 ionte_: you might be able to specify where the file needs to be put as a parameter to SRC_FILE which is slightly cleaner... but is basically the same thing Mar 17 09:24:16 boucman_work: oh? i looked for that functionality but could not find any Mar 17 09:25:34 ionte_: http://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#bb-the-unpack the "subdir" parameter Mar 17 09:25:46 (and yeah... you have to know where to look) Mar 17 09:26:54 boucman_work: ok thanks! Mar 17 09:26:55 Hi all. I finally (wohoo \o/) managed to get my network interface setup working. I can connect to the target via ssh but still there seems to be an issue with sshd.service: https://gist.github.com/Anticom/a665cad7a6ab0d6926d6 Mar 17 09:27:16 I never got the docs section there. Also i don't get, what "inactive (dead)" means Mar 17 09:27:51 oh ok nvm the docs... it's "regular" man pages, i see Mar 17 09:32:44 could anyone explain how the work-shared and work directories relates? my dts file was by default installed into ${WORKDIR} (in "work" directory). i now copy it to .../arch/arm/boot/dts, still in "work" directory. all other "dts" files that are included with the kernel are in work-shared. but for some reason the build still finds both my custom dts and the other dts files.. Mar 17 09:51:20 Could someone please elaborate on VIRTUAL-RUNTIME_initscripts = "" a little more? The manual isn't very verbose on that. What is meant by removing init scripts >>altogether<< ? Mar 17 09:51:36 even my own ones? Like how would i provide init scripts then? or does that not include unit files? Mar 17 09:52:42 finally found correct destination: cp ${WORKDIR}/*.dts ${S}/arch/${ARCH}/boot/dts. does not feel right to copy from work directory to the shared source directory though .... but it works Mar 17 09:53:58 ionte_: what's wrong with that ? would it feel better if you added a couple of "+" at the beggining of each line of your dts and renamed the file .dts.patch ? Mar 17 09:54:30 adding a dts is logically just like patching the kernel, except you add a whole file so it's simpler Mar 17 09:56:13 boucman_work: well, it's perhaps just because i'm not sure how it really works. seems odd to copy things from workdir, that are potentially machine and build specific, to a directory with shared source Mar 17 10:09:54 WORKDIR is machine specific IIRC (but I may be wrong on that one) Mar 17 10:10:19 and ${S} is under workdir Mar 17 11:24:32 Is there plan to merge pending patches to dizzy branch? http://lists.openembedded.org/pipermail/openembedded-core/2016-March/118848.html Mar 17 12:03:18 how can i pass to recipe path to sources of other recipe during compilation? Mar 17 12:05:28 \names Mar 17 12:05:28 ivan__: there is no easy way that I know of, because it's usually a bad idea... why do you need to do that ? Mar 17 12:07:32 i have a project which uses perl script to generate source file using sources of related projects Mar 17 12:08:13 i have an issue I have read 5.11 Creating Custom Template Configuration Directory. I don't quite understand how can I override default .templateconf ? I have directory stucturu like this: Mar 17 12:08:17 - poky Mar 17 12:08:22 - mymeta\ Mar 17 12:08:31 -conf Mar 17 12:09:11 and i run source $ source poky/oe-init-build-env myarch Mar 17 12:09:26 i put .templateconf in this dir Mar 17 12:10:10 TEMPLATECONF=${TEMPLATECONF:-mymeta/conf} Mar 17 12:10:36 then it shows: "You had no conf/local.conf file. This configuration file has therefore been..." Mar 17 12:10:46 but there is Mar 17 12:13:37 ivan__: hard to say, maybe first you should make a list of packages as dependecies, then use bb class and some python script to the paths to sources they are compiled in Mar 17 12:21:03 mastier_: if user has activated rm_work.bbclass, you can't even assume the source is still there :( Mar 17 12:25:44 boucman_work: good point, as you said, when you create such recipe that depends on others workdir you propably do something wrong. ivan__ shall rethink why he actually need it Mar 17 12:32:19 either combine things into one recipe providing multiple packages, or get the source multiple times. :) Mar 17 13:25:03 Is there a way to completely clean a build and start a fresh build? My computer dies during a build and now when I try building core-image-minimal I get many errors. Mar 17 13:26:45 riz__: rm -rf work/ is usually enough, but I usually do "bitbake -c cleanall " to avoid rebuilding everything Mar 17 13:27:26 OK thanks. I will try that now. Mar 17 13:28:29 by work you mean in the buil/tmp directory, correct? Mar 17 13:28:42 build/tmp* Mar 17 13:29:03 oh hi LetoThe2nd. Quick question: Where you the one recommending me to use += even for _append variables? Mar 17 13:29:26 I think that was me... Mar 17 13:29:31 Anticom: ^^ Mar 17 13:29:34 riz__, boucman_work: wouldn't bitbake -c cleanall world also fit the bill? Mar 17 13:29:46 boucman_work: kergoth told me, that this wasn't neccessary Mar 17 13:29:48 Anticom: afaik cleanall is not recursive Mar 17 13:29:51 _append's are evaluated at parse time Mar 17 13:29:57 and he really knows his stuff ;) Mar 17 13:30:01 so just FYI :) Mar 17 13:30:01 the cleanall didn't work Mar 17 13:30:10 riz__: even on world target? Mar 17 13:30:18 Anticom: then he is probably right, i'm just a guy answering on IRC :P Mar 17 13:30:19 well then as boucman_work pointed out, rm the work directory Mar 17 13:30:34 ok Mar 17 13:30:38 just delete tmp-glibc Mar 17 13:30:45 boucman_work: Wasn't mean as offense in any way. Just so you know for the future yourself :) Mar 17 13:30:49 and wipe sstate-cache if you really want to start from scratch Mar 17 13:30:50 Anticom: cleanall is "all" as in : remove the workdir of the target whereas clean is run the clean task of that target Mar 17 13:30:57 but it's not recursive to the deps Mar 17 13:31:23 well he wanted to wipe everything from how i understood him Mar 17 13:31:25 Anticom: and I didn't interpret it as such, my response had an undertone I didn't want it to have, sorry Mar 17 13:31:26 cleanall is just cleansstate + remove downloaded files which is very rarely useful Mar 17 13:31:42 boucman_work: no worries (: Mar 17 13:31:45 gotta reboot, brb Mar 17 13:31:51 unless you're paid by network bandwidth consumed in work hours :) Mar 17 13:31:57 removing the work directory didnt work either Mar 17 13:32:01 JaMa: doesn't cleanall include clean aswell? Mar 17 13:32:03 :O Mar 17 13:32:09 cleansstate includes clean Mar 17 13:32:14 ah, my bad Mar 17 13:32:29 riz__: can you pasterbin your errors ? Mar 17 13:32:46 I am new to this. How do you pastebin? Mar 17 13:33:42 ERROR: Command execution failed: Traceback (most recent call last): File "/home/ryan/minnowboard/poky/bitbake/lib/bb/command.py", line 101, in runAsyncCommand self.cooker.updateCache() File "/home/ryan/minnowboard/poky/bitbake/lib/bb/cooker.py", line 1561, in updateCache bb.event.fire(event, self.expanded_data) File "/home/ryan/minnowboard/poky/bitbake/lib/bb/event.py", line 170, in fire fire_class_handlers(event, d) Mar 17 13:33:51 That is one error Mar 17 13:34:19 go to pastebin.com, dump the whole ouput of bitbake there, post the resulting URL on irc Mar 17 13:35:59 http://pastebin.com/yYSqwfR9 Mar 17 13:39:05 riz__: that's a new one... my bet is that sstate is corrupted somehow... does removing the directory build/sstate_cache help ? Mar 17 13:40:10 no Mar 17 13:40:58 Can I just removed my entire build directory? Mar 17 13:41:10 riz__: jethro release? Mar 17 13:41:54 yes Mar 17 13:43:02 looks like the sstate manifest is bust Mar 17 13:43:19 riz__: you should save the content of your config/ subdir but appart from bandwith/build-time it should be safe Mar 17 13:43:32 OK. Ill try that now Mar 17 13:43:48 yeah deleting all of tmp is the safest option Mar 17 13:43:55 looks like tmp/sstate-control got messed up Mar 17 13:44:10 so delete all of tmp and let it repopulate from sstate Mar 17 13:46:46 Deleting my build, setting up the environment, and re-loading my local.conf/bblayers.conf files made it work Mar 17 13:47:09 I figured it would, but I was just wondering if there was an alternative to starting from 0 Mar 17 13:47:10 cool Mar 17 13:47:34 For the sake of time I will accept the win haha Mar 17 13:47:47 Thanks all! Mar 17 13:48:25 as you presumably kept the sstate archive it doesn't need to do any building Mar 17 13:51:55 Is there any way to create custom bblayer.conf.sample ? it resolves magic ##OEROOT## but I want to resolve my variable like ##PROJECT_LAYER## when I ran oe-init-build-env Mar 17 13:52:06 conditionally inheriting a class just for nativesdk targets seems messy. FOO = "" FOO_class-nativesdk = "my-class" inherit ${FOO} doesn't work. i'm guessing it's because the inherit is applied "immediately" during parsing, before the override has a chance to kick in (and maybe even before class-nativesdk has been added to OVERRIDES). Mar 17 13:52:34 Ulfalizer: what class do you want to inherit just for nativesdk builds? Mar 17 13:52:40 does it only make sense to conditionally inherit stuff based on "global" data? Mar 17 13:53:08 rburton: update-alternatives, to avoid a dependency cycle. we have some custom sdk code. Mar 17 13:53:16 just inherit it Mar 17 13:53:30 and only set the variables in nativesdk environments using overrides Mar 17 13:53:53 or, what harm could happen if it used u-a everywhere Mar 17 13:54:22 which ones? what i wrote above doesn't work. inherit ${FOO} seems to turn into the equivalent of inherit "". Mar 17 13:54:53 rburton: "unbuildable tasks were found. these are usually caused by circular dependencies and any circular dependency chains found will be printed below. ..." :) Mar 17 13:55:49 something about update-alternatives adding a virtual/update-alternatives dependency, and that causing problems for stuff that virtual/update-alternatives depends on Mar 17 13:55:58 i'm a bit shaky on the exact underlying problem in this case though Mar 17 14:09:25 hrm... looks like the find_chains() function crashes too. that makes it a bit trickier to debug. :) Mar 17 14:18:48 genereal question: If all that is required is bitbake+oe-core+meta-intel to build a linux distro, where does yocto get involved? I am failing to understand the difference of just using open-embedded as ooposed to yocto... Mar 17 14:22:27 riz__: yocto is a community, one of the projects in yocto is oe-core Mar 17 14:22:45 Is there plan to merge pending patches to dizzy branch? http://lists.openembedded.org/pipermail/openembedded-core/2016-March/118848.html Mar 17 14:24:30 OK. Does oe-core include meta-openembedded and openembedded-core? Mar 17 14:25:35 riz__: no oe-core == openembedded-core Mar 17 14:25:36 I see many people adding those in separately in examples, however it seems to me that those are already included in poky. Mar 17 14:25:54 sorry, I meant to say poky, not oe-core Mar 17 14:26:55 Or after using poky, do I need to then include meta-openembedded+oe-core? Mar 17 14:28:26 * boucman_work is confused too... poky.git has a complete bitbake subtree, but I don't understand how it's linked to the real bitbake repo, same with oe-core Mar 17 14:28:34 and I never found a doc really explaining that Mar 17 14:29:25 boucman_work: combo-layer is the tool that takes the oe-core, bitbake and meta-yocto repos and basically merges them Mar 17 14:29:35 poky repo doesn't include meta-oe Mar 17 14:29:49 you'll note that every commit in poky has a line saying what repo and sha it came from Mar 17 14:30:01 but it contains oe-core, bitbake and meta-yocto as rburton said Mar 17 14:30:11 rburton: thx I didn't know that Mar 17 14:30:33 yes, it's very deliberate scheme to confuse everybody :) Mar 17 14:31:30 Is there plan to merge pending patches to dizzy branch? http://lists.openembedded.org/pipermail/openembedded-core/2016-March/118848.html Mar 17 14:31:53 poky is almost entirely for convenience of QA by having all the bits glued together Mar 17 14:40:09 so does poky include meta-openembedded+oe-core already? Mar 17 14:40:18 I am still really confused Mar 17 14:40:43 And if so, where in the meta is it included? Mar 17 14:41:05 poky is bitbake + oe-core + meta-yocto Mar 17 14:41:18 the meta/ directory is oe-core Mar 17 14:41:46 oh, so meta is just oe-core renamed? Mar 17 14:42:30 no, have a look in oe-core and you'll see that everything is in a meta/ directory Mar 17 14:43:00 OK, I see. So the only thing I need to add is meta-openembedded? Mar 17 14:43:09 yes Mar 17 14:43:55 riz__: or use bitbake+oe-core+meta-oe directly and dump poky unless you want to use poky as DISTRO as well Mar 17 14:45:01 OK great. Why doesnt poky just include meta-oe? Mar 17 14:45:11 because it doesn't need it Mar 17 14:45:16 because there are many other layers which aren't part of poky Mar 17 14:45:32 What does meat-oe add? Mar 17 14:45:42 riz__: have a look at whats in meta-oe Mar 17 14:45:50 presumably, what you're adding it for Mar 17 14:46:25 OK. I'll study it now. Mar 17 14:49:38 ok, i'm starting to understand now... thx rburton Mar 17 15:06:21 it's not possible to append/prepend to def-style (helper, non-yocto-style) python functions, right? Mar 17 15:09:21 no Mar 17 15:09:26 well… Mar 17 15:09:33 (safest to say no) Mar 17 15:22:03 rburton: I submitted a patch some time ago, and never got any reply, what would be the proper delay before sending a ping ? Mar 17 15:22:38 http://patches.openembedded.org/patch/117735/ (in case it's relevant) Mar 17 15:23:18 boucman_work: that's actually in my staging branch for master now Mar 17 15:24:31 awesome, I missed that, thx Mar 17 15:28:22 no problem there wasn't any notification and i don't expect everyone to watch my personal branch Mar 17 15:35:18 rburton: do you remember any issues re. cyclic dependencies and virtual/update-alternatives? Mar 17 15:35:49 nope, sorry Mar 17 15:36:01 ok, just checking Mar 17 16:47:54 gm all Mar 17 16:48:02 I am getting a segfault Mar 17 16:48:06 qemu: uncaught target signal 11 (Segmentation fault) - core dumped Mar 17 16:48:08 Segmentation fault (core dumped) Mar 17 16:48:21 when compiling gobject-introspection Mar 17 16:48:27 see http://errors.yoctoproject.org/Errors/Details/56329/ Mar 17 16:49:28 khem: can you get a core dump from qemu? Mar 17 16:56:49 rburton: looks like the issue is that you can't inherit update-alternatives from a glibc bbappend, because you get a circular glibc -> virtual/update-alternatives -> glibc dependency. do you think it'd make sense to check for BPN = glibc in ua_extend_depends() in update-alternatives.bbclass, or would you consider that too specific? Mar 17 16:57:17 could also check if virtual/update-alternatives has a dependency on the current package, but i'm not sure how difficult that would be. might be overkilling things. Mar 17 17:00:12 maybe we're the only ones who would ever need to (indirectly) include update-alternatives in a glibc bbappend too... :P Mar 17 17:01:51 * Ulfalizer gave up on trying to inherit a class for just the nativesdk-* targets. doesn't seem to be a clean way. Mar 17 17:02:07 maybe it's against how recipes are processed Mar 17 17:02:53 you can't just exclude it entirely, some update-alternatives implementations do require glibc. but glibc hsouldn't need update-alternatives until later.. Mar 17 17:04:49 i meant not adding the 'glibc to virtual/update-alternatives' dependency. the other direction should be fine. Mar 17 17:05:01 it's added automatically by update-alternatives.bbclass Mar 17 17:06:01 could hack around it with a DEPENDS_remove in the bbappend for now Mar 17 17:07:46 if nothing else in your image uses update-alternatives, it won't end up built to be installable in the image. of course, in practice all images end up including multiple recipes that use update-alternatives, so i guess you could rely on it coming in via another direction, though it doesn't seem ideal to do so Mar 17 17:07:50 hmm Mar 17 17:09:46 yeah, not ideal in that way. circular deps are tricky business. :P Mar 17 17:29:39 when I try to plugin a USB drive to the USB port on my tobi board with gumstix overo, I get the following: Mar 17 17:30:00 [ 1632.768371] usb 2-2: new full-speed USB device number 9 using ohci-omap3 Mar 17 17:30:00 [ 1633.188629] usb 2-2: device not accepting address 9, error -62 Mar 17 17:30:01 [ 1633.195037] usb usb2-port2: unable to enumerate USB device Mar 17 17:30:15 Repeated several times with different trials Mar 17 17:30:42 How can I get the kernel to properly detect my USB drive so I can mount it? Mar 17 17:31:50 here is the full output: http://okturing.com/src/3534/body Mar 17 17:32:24 the line "[ 1631.588592] usb 2-2: device descriptor read/64, error -62" also looks a bit ominous Mar 17 17:33:56 Capso: i think you need to speak to gumstix about that Mar 17 17:33:58 its their kernel Mar 17 17:34:57 ah I dunno how the exchange b/w yocto project and gumstix is Mar 17 17:35:29 when you start hitting machine-specific things like that, try there first Mar 17 17:35:34 its their kernel which isn't doing what you expect Mar 17 17:45:54 I see Mar 17 17:46:00 rburton, does yocto have exfat support? Mar 17 17:54:09 ah I see it's part of meta-openembedded Mar 17 17:54:28 do I just add it to my local.conf and bitbake gumstix-console-image again? Mar 17 17:54:38 err, not local.conf Mar 17 17:54:40 bblayers.conf Mar 17 18:02:50 how do I get bitbake to pick up the addition to BBLAYERS? Mar 17 18:03:10 when I rebuild, it does not seem to add the meta-filesystems Mar 17 18:03:28 Capso: bblayers.conf in your conf directory Mar 17 18:03:35 you can provide paths Mar 17 18:03:44 in my build/conf/bblayers.conf right? Mar 17 18:03:48 yes Mar 17 18:04:05 adding a layer != using the contents Mar 17 18:04:10 it also includes meta-openembedded stuff that the builder does not pick up Mar 17 18:04:13 oh Mar 17 18:04:31 so how would I get it to include the meta-filesystems stuff in the image? Mar 17 18:04:40 so I can just rebuild that component Mar 17 18:06:11 IMAGE_INSTALL_append = "meta-filesystems" ? Mar 17 18:06:36 meta-filesystems is a layer, not a package. IMAGE_INSTALL is used to include specific packages, which come from recipes Mar 17 18:06:49 Capso: BBLAYERS variable in bblayers.conf file Mar 17 18:06:50 find the recipe you want from meta-openembedded and add it Mar 17 18:07:32 hi guys, I usually use SYSTEMD_AUTO_ENABLE_(servicename) in my local.conf to disable some systemd "built-in" services, now I'm trying to do the same to instead enable a service Mar 17 18:07:40 JaMa, I added the meta-filesystems layer, but the rebuild does not build the packages underneath Mar 17 18:08:35 Capso: even oe-core has hundreds of packagesk i really doubt you want everything that coule possibly be built in your image Mar 17 18:08:39 but the service that I want to enabled will be disabled anywhere Mar 17 18:08:44 so no, it's not going to magically read your mind to figure out what packages you want Mar 17 18:10:00 what I'm doing wrong/there are other ways to do this? Mar 17 18:44:57 If I wanted to configure my target with a static IP what do I need to do within poky? Mar 17 18:50:44 riz___: edit /etc/network/interfaces Mar 17 18:50:54 compare the entries for eth0 and usb0 and you'll see how to do it Mar 17 18:54:27 what directory is that in? Mar 17 18:54:48 /etc/network/interfaces Mar 17 18:54:51 that's the full path Mar 17 18:54:59 on the target Mar 17 18:55:13 Oh Mar 17 18:55:25 But how do I do it from yocto prior to build Mar 17 18:55:31 So that it just builds that way Mar 17 18:55:37 if you mean how does that file get generated, it's from meta/recipes-core/init-ifupdown/init-ifupdown-1.0/interfaces Mar 17 18:56:12 the most appropriate way to override that is with a bbappend from your own layer Mar 17 18:56:32 recipetool appendfile will help you create that bbappend Mar 17 18:57:35 That append file goes in the meta/recipes-core/init-ifupdown/init-ifupdown-1.0/ directory? Mar 17 19:04:04 riz___: the append goes in your own layer which you would create (yocto-layer create is one way to do that) Mar 17 19:04:58 Gotcha Mar 17 19:59:57 looks like attr_2.4.47.bb might be missing an virtual/libintl-native dependency. manually building gettext-native first fixes it. otherwise, i get the same error as in http://lists.openembedded.org/pipermail/openembedded-devel/2010-February/062787.html. Mar 17 20:01:11 Ulfalizer: virtual/libintl-native is in ASSUME_PROVIDED, so unless you've changed the value of that, that won't be doing anything Mar 17 20:01:46 ah, maybe it's just not installed locally in that case Mar 17 20:02:14 does attr actually use gettext? Mar 17 20:02:30 if so it may need to inherit gettext Mar 17 20:02:55 don't know. just a random build failure i got. :) Mar 17 20:03:28 "FATAL ERROR: msgfmt does not seem to be installed." Mar 17 20:03:36 "attr cannot be built without a working gettext installation." Mar 17 20:04:02 build gettext wasn't sufficient. had to build gettext-native to fix it. Mar 17 20:04:06 *building Mar 17 20:11:36 missing inherit i'd expect then Mar 17 20:12:38 it does inherit gettext, in ea-acl.inc Mar 17 20:14:25 that one does BBCLASSEXTEND = "native" btw, and then main attr bb file overwrites it with BBCLASSEXTEND = "native nativesdk". seems a bit odd... Mar 17 20:14:46 the .inc file is included in a single location Mar 17 20:14:53 but that's unrelated nits :P Mar 17 20:17:41 ea-acl is included by attr and acl recipes isn't it? Mar 17 20:18:17 does `wic create sdimage-gumstix -e gumstix-console-image && dd if=/var/tmp/wic/build/sdimage-gumstix-*.direct of=/dev/mmcblk0' do anything other than 'cp build/tmp/deploy/images/overo/{MLO,u-boot.img} /media/boot/ && cd /media/root && tar jxf $YOCTO/poky/build/tmp/deploy/images/overo/gumstix-console-image-over-*.rootfs.tar.bz2' ? Mar 17 20:18:39 because wic takes a really long time and then so does the dd step Mar 17 20:18:48 ah, you're right. missed the include in acl.inc somehow. Mar 17 20:38:27 re. attr, it looks like gettext-minimal-native is added as a dependency by gettext.bbclass due to USE_NLS being "no". i wonder if really needs gettext-native. Mar 17 20:38:37 even in that case Mar 17 20:39:21 or maybe options are missing to disable attr functionality when USE_NLS = "no" Mar 17 20:40:40 gettext-minimal-native is required to build anything that uses gettext m4 macros, whether you're using gettext or not Mar 17 20:40:48 otherwise we can't regenerate configure from configure.ac with autoconf Mar 17 20:41:00 afaik, anyway Mar 17 20:41:15 gettext-minimal-native or gettext-native, that is Mar 17 20:43:38 kergoth: i meant that gettext-minimal-native might not be enough. maybe it needs gettext-native. Mar 17 20:44:20 * Ulfalizer wonders why gettext-minimal-native doesn't get a pkgs-split directory when you build it Mar 17 20:44:25 why would it? Mar 17 20:44:30 it's native, we don't package native recipes at all Mar 17 20:44:37 ah, makes sense Mar 17 20:44:50 what's the easiest way to check what's in it? Mar 17 20:45:11 maybe there's no easy way if it just installs stuff :/ Mar 17 20:45:12 Ulfalizer: gettext.bbclass passes --disable-nls. it sounds like attr needs fixing to actually obey that, rather than trying to run msgfmt when nls is disabled. Mar 17 20:45:23 it installs stuff to image/ like every other recipe Mar 17 20:45:35 and then bits from there go to the sysroot and for target recipes, gets put in packages-split and whatnot Mar 17 20:46:35 hmm... thought image/ looked weird too, with a long host path, but i guess that makes sense for native recipes Mar 17 20:47:29 Ulfalizer: you can also read tmp-glibc/sstate-control files to see what was installed to sysroot by given recipe Mar 17 20:47:55 ok Mar 17 20:49:12 yes, image will have the full absolute path to where they end up installed in the sysroot, due to how we set prefix for native Mar 17 20:49:51 this is needed because most of our stuff isn't properly relocatable, otherwise we could leave it the same as target and just install it in the sysroot the way we do the target stuff. of course, we fixup relocs in a lot of cases, so if we applied the reloc logic even when not using sstate, presumably we could think about dropping that bit Mar 17 20:52:55 After building my poky build which includes meta-qt5, how to I build my Qt cross toolchain? Mar 17 20:53:27 Do I bitbake meta-toolchain-qt5? I was told that it is no longer used. Mar 17 20:53:56 riz___: I was able to get my toolchain built with this tutorial http://developer.toradex.com/knowledge-base/how-to-set-up-qt-creator-to-cross-compile-for-embedded-linux Mar 17 20:54:15 (your machine/system arch may vary) Mar 17 20:54:35 It uses meta-toolchain-qt5, so I don't know anything about it being used Mar 17 20:55:10 And that build your SDK which you used to setup QtCreator? Mar 17 20:55:15 built* Mar 17 20:56:12 Yes Mar 17 20:56:25 Is the secion on relocation necessary? Mar 17 20:56:30 section* Mar 17 21:48:43 hmm Mar 17 23:25:43 When I bitbaked my image it seems to be looking at the wrong local.conf file because even though I selected a new target it is still building tghe defauly (qemux86). It is also the wrong target system. Mar 17 23:26:20 I thought I jjust had to update local.conf in source/build/ Mar 17 23:26:39 the build seems to be looking elsewhere Mar 17 23:26:56 Do I have to edit local.conf in another location? Mar 17 23:32:47 cd .. Mar 18 01:40:44 hi Mar 18 01:41:01 looks like qemu-native in poky/master fails to build on debian Mar 18 01:41:19 the problem this time around is that libcaca is missing some symbols from ncurses Mar 18 01:41:43 is that known ? Mar 18 01:44:26 Marex: hey! Mar 18 01:44:32 not that I'd heard of... Mar 18 01:44:58 libcaca causing problems eh, well... the issue is right there in the name ;) Mar 18 01:46:13 bluelightning: morn'errr ... whatever time of day it is for you :) Mar 18 01:46:27 bluelightning: I will drill in shortly I guess Mar 18 01:47:03 Marex: 2:45pm :D Mar 18 01:47:09 hmmmm, the qemu is configured with --disable-curses already, so how the heck does the ncurses get in Mar 18 01:47:13 riiight, 2.47am here Mar 18 01:58:48 bluelightning: interesting, disabling SDL support for qemu fixed my ncurses/caca problem Mar 18 01:58:59 bluelightning: well, that'd imply the ncurses/caca stuff is pulled in via SDL Mar 18 02:00:49 hmm... didn't know SDL had anything to do with ncurses Mar 18 02:01:13 either it does OR there's some other problem Mar 18 02:01:49 could it be using system's libsdl ? Mar 18 02:07:26 bluelightning: it seems to be coming from my system's libsdl indeed Mar 18 02:08:55 right, we do attempt to link to that, otherwise we had problems with different libGL providers Mar 18 02:08:59 bluelightning: http://www.bfuser.eu/link.txt Mar 18 02:09:10 bluelightning: that's the failing bit Mar 18 02:09:32 bluelightning: I added the -Wl,--trace to see what libs are pulled in Mar 18 02:09:39 apparently, aside from the libsdl, no others are pulled in Mar 18 02:10:24 bluelightning: so I guess ... libsdl uses libcaca which uses libncurses **** ENDING LOGGING AT Fri Mar 18 02:59:58 2016