**** BEGIN LOGGING AT Thu Aug 06 02:59:58 2015 Aug 06 07:58:03 hello . I'am try to write a new recipe which goal is to install a little hello world program Aug 06 08:00:19 the code is here http://pastebin.com/cDjvcXwT Aug 06 08:01:31 i have an error when running : bitbake -b ../../../recipes-extended/test-hello/test-hello_0.1.bb Aug 06 08:05:46 khalebios: configure sounds like the source is autotoolized. so you better should depend on the autotools.class infrastructure. Aug 06 08:06:35 so i have to add inherit autotools in my recipes? Aug 06 08:10:10 khalebios: instead of bluntly tinkering the recipe, i'd suggest reading chapter 5.3 of the dev manual, and then take a careful look at the second example under http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#new-recipe-testing-examples Aug 06 08:12:01 plus, i think the yocto-layer create command also gives you some working example recipe to base of if you wish so. Aug 06 08:15:37 morning all Aug 06 08:16:18 Is there a way to have yocto/oe unpack a tarball to some different directory? Aug 06 08:16:43 I have a recipe where I want to download two tarballs, but their internal structure both begin with the same directory (so they would be merged when unpackging) Aug 06 08:23:01 So a.tar.bz2 and b.tar.bz2 both contain "specific_dir/" as top-level inside the tarball. Aug 06 08:23:23 I would like to have them separated, but I have no power over the tarballs (so I can't change them myself). Aug 06 08:24:23 wto: there is a way yes, one moment Aug 06 08:24:51 wto: add ;subdir=subdirectoryname Aug 06 08:25:02 bluelightning: ah, to the SRC_URI-line? Aug 06 08:25:07 wto: yes Aug 06 08:25:09 That's a neat solution! Aug 06 08:25:10 Thanks! Aug 06 08:25:13 np Aug 06 08:30:20 Hello guys. I'm struggling with a psplash issue. I need to have a full 1080p logo in psplash, but it seems that the bar is somehow breaking the splash screen, there is a black full-width line and the logo is cut weirdly. Is there a way to maybe disable the whole bar? Aug 06 09:38:41 RE -hello!!! Aug 06 09:39:28 why i can't rewrite my /etc/network/interfaces wuth ROOTFS_POSTPROCESS_COMMAND Aug 06 09:41:42 khalebios: you'll need to write to ${IMAGE_ROOTFS}/etc/network/interfaces otherwise you'll be trying to write into your build host's /etc Aug 06 09:44:08 i have this line: cp ${IMAGE_ROOTFS}/etc/network/interface ${IMAGE_ROOTFS}/etc/network/interfaces; Aug 06 09:44:32 but nothing change in my interfaces files Aug 06 09:44:35 file Aug 06 09:46:21 khalebios: ROOTFS_POSTPROCESS_COMMAND is actually a list of functions to call Aug 06 09:46:49 khalebios: you need to create a shell function that does the cp and call that from ROOTFS_POSTPROCESS_COMMAND Aug 06 09:56:10 so to resume: add a shell Aug 06 09:56:15 i am trying start Aug 06 09:56:22 i am trying that Aug 06 10:01:02 i made this: Aug 06 10:01:04 setinterfaces(){ cp -f ${IMAGE_ROOTFS}/etc/network/interface ${IMAGE_ROOTFS}/etc/network/interfaces; } Aug 06 10:01:12 and after Aug 06 10:02:00 ROOTFS_POSTPROCESS_COMMAND += "\setinterfaces;\" Aug 06 10:02:04 nothing changes Aug 06 10:02:30 hi, if there is a way to ask in a recipe if a specific package has been added to the image? Aug 06 10:02:40 something like ${@bb.utils.contains('DISTRO_FEATURES',...) but for packages? Aug 06 10:03:46 I've a recipe for an app that has a QT frontend but I only want to add a dependency to qtbase and enable the frontend in configure if the qtfoo has been added to the image Aug 06 10:05:00 khalebios: what is with the \ ? Aug 06 10:05:03 already split the QT frontend in a different package so the front and backend can be installed separately Aug 06 10:05:49 \ I use it to add other thing to the ROOTFS_POSTPROCESS8COMMAND Aug 06 10:06:15 javier__: no, you can't do that I'm afraid Aug 06 10:06:41 khalebios: items in ROOTFS_POSTPROCESS_COMMAND are separated by ; Aug 06 10:07:33 what do you do when you whant to change line? Aug 06 10:07:53 bluelightning: that explains why I was not finding in the docs, so what's the good practice for this case? Aug 06 10:08:27 bluelightning: to allow the user building and install the QT frontend or not? Aug 06 10:09:01 javier__: well, build time decisions about optional functionality for individual recipes are usually done through PACKAGECONFIG Aug 06 10:20:02 on question: does ROOTFS_POSTPROCESS_COMMAND been executed at the last time of the compilation? Aug 06 10:22:05 bluelightning: thanks, I'll investitage about PACKAGECONFIG. I've seen that other recipes used but not completely understading how it works. Aug 06 10:24:07 khalebios: I'm sorry I don't quite understand the question... ? Aug 06 10:26:47 i see that in one recipes : init-ifupdown .. they are a FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" command Aug 06 10:40:08 i understand that this recipe upgrade the interfaces file Aug 06 10:40:17 but this doesn't work Aug 06 11:08:04 bluelightning: I'm trying out devtool with a texinfo upgrade but am not sure how to get started in this specific situation: If I update texinfo version (and SRC_URI checksums) and then run "devtool modify -x texinfo ~/src/texinfo" it fails because the patches fail to apply to the new version... Aug 06 11:08:48 but those patches are exactly what I want to fix and I thought devtool would help there... maybe I've misunderstood something? Aug 06 11:09:58 jku: the upgrade case isn't well-handled right now - we've got someone working on it atm: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7642 Aug 06 11:10:00 Bug 7642: enhancement, High, 1.9 M2, leonardo.sandoval.gonzalez, IN PROGRESS IMPLEMENTATION , devtool: add recipe upgrade functionality Aug 06 11:12:30 ok, thanks Aug 06 12:18:03 where do I find recipetool? Aug 06 12:18:24 (n00b question I know, but...) Aug 06 12:19:10 have done the usual . oe Aug 06 12:19:35 AzaToth_: in fido (1.8) and later it's included in scripts/ so after setting up the environment it should be in your path Aug 06 12:19:44 ok Aug 06 12:20:18 we're sadly still using daisy Aug 06 12:21:16 need to look into migrate to fido Aug 06 13:29:30 What's the correct way to increment package version numbers after applying patches in a .bbappend? Aug 06 13:31:12 mcfrisk: use the PR service, it will then happen automatically Aug 06 13:31:21 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service Aug 06 13:32:07 sigh, can't get servers like that up and running... Aug 06 13:33:00 I guess I can add a magic original+2 or something.. Aug 06 13:33:04 thanks bluelightning Aug 06 13:33:37 can't? why? Aug 06 13:36:20 corporate crap Aug 06 13:36:43 your build machine can't connect to localhost ? that's the simplest setup... Aug 06 13:37:25 there's basically no server to set up then, it's started and stopped with the build process Aug 06 13:37:50 PRSERV_HOST = "localhost:0" Aug 06 13:38:27 we have distributed build machinery so need a central location which is tricky with corporate IT... Aug 06 13:40:55 if your IT is placing such restrictions on internal servers, that's unfortunate Aug 06 13:43:17 the screen recipe includes this in SRC_URI: "${DEBIAN_MIRROR}/main/s/screen/screen_4.0.3-14.diff.gz;name=patch" -- that is the debian/-directory contents as a diff. Why on earth would we patch it in to the source directory? Aug 06 13:44:53 jku: I guess it's a convenient way to pull in the patches from debian Aug 06 13:44:56 jku: if a source package follows Debian source package, that directory can contain patches Debian applies to upstream sources Aug 06 13:46:43 where would I see those patches being applied? Aug 06 13:48:14 Hello, everytime I try to run "devshell" for a yocto recipe, it stays forever at the "0: myrecipe-1.0-r0 do_devshell (pid 31378)" line. But works fine on another PC. Has anyone experience this? Aug 06 13:52:32 bluelightning, mcfrisk: what I mean is: I can see (40!) patches in {S}/debian/patches/ but I don't see what mechanism would be used to apply them Aug 06 13:53:04 jku: you're right, they don't seem to be applied in yocto/master, or some magic happens in default actions Aug 06 13:53:32 this means that screen is really buggy in yocto? Aug 06 13:56:58 mcfrisk: when you say they don't seem to be applied, how are you determining that? Aug 06 13:57:10 jku: in theory, log.do_patch Aug 06 13:58:37 bluelightning: reading recipe Aug 06 13:59:14 can I see master build log of screen somewhere? build server? Aug 06 14:00:33 screen_4.0.3.bb only applies the debian patch, not the patches in the patch Aug 06 14:01:00 bluelightning: but also in the recipe right? the debian patches (the ones that end up in {S}/debian/patches/ ) can't get applied without being specified in the recipe somehow, right? Aug 06 14:01:09 maybe screen changed patch format in recent years/decades Aug 06 14:01:48 original old style debian patches were plain patches to orig source tree, nowadays they manage patch series under debian/ and apply them before compiling.. Aug 06 14:02:04 .. i guess it fails to spawn a terminal for some reason "DEBUG: Attempting to spawn terminal "gnome"" is the last debug msg I see Aug 06 14:02:22 it would have had to be >4 years ago when screen was probably moved from meta-oe Aug 06 14:02:42 well, I'll try to upgrade, we'll see how that goes Aug 06 14:03:27 jku: maybe a sanity test for this? Aug 06 14:06:33 hmm, this is interesting... it's possible the person who added the patch missed this Aug 06 14:06:35 there's a couple of other recipes that have the same setup and I don't see them using the patches either Aug 06 14:09:03 well, that is tomorrows project: now I walk the dogs. Thanks for bouncing back some ideas Aug 06 14:09:21 well, it's not really a suprise, I can see that yocto packages are not really well maintained compared to debian/ubuntu/fedora/redhat/centos. Just not enough people and testing in yocto. Real distro users are missing in open source world at least. Aug 06 14:10:11 I think you may be underestimating the number of commercial users of our project Aug 06 14:10:30 of course we have bugs... everyone does Aug 06 14:11:54 bluelightning: well I can see how little the commercial users are actually a) testing, b) co-operating with other distros with security support etc c) the quality of commercial additions to yocto. Aug 06 14:12:24 * mcfrisk is on the dark^R^Rcommercial side Aug 06 14:14:20 well, that's a little too general to respond to I'm afraid... Aug 06 14:15:07 yes, sorry for complaining here. I'll try to send patches instead... Aug 06 14:17:03 I don't mind complaints, but they need to be a bit more specific Aug 06 14:17:44 FWIW, Intel pays me and a number of others to work on the project; I know the same is true of other organisations that are YP members Aug 06 14:19:26 yes I know, and that does help. Aug 06 14:21:06 But 20 active developers, 2 reviewers for oe-core, that isn't matching Debian's 1000 devels (of which maybe 300 active) and 5 security support ppl. And yocto is about bleeding edge, not long term support for servers. Aug 06 14:22:33 we have a slightly different problem space though, and far fewer pieces of software being packaged Aug 06 14:22:47 true Aug 06 14:23:59 but in the end some products would actually need lts style security support for various packages. companies paid to such support don't really seem to be doing anything in the embedded/automtive space at least. They just fork and run away without looking back. Aug 06 14:54:45 When in devshell and running "autogen.sh" my recipe inherits autools I get "configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'." Aug 06 14:55:44 gatisp: you may find the devshell does not have all arguments set to enable compilation - because some of those are task-specific Aug 06 14:55:53 s/argument/environment variables/ Aug 06 14:56:44 bluelightning, task-specific? Am I missing something in my work-flow for this to work properly? Aug 06 15:02:25 gatisp: well, to rephrase, devshell won't ensure that your custom autogen.sh script will get the correct arguments to configure Aug 06 15:02:33 gatisp: you shouldn't run configure directly or through scripts in the sources, we run configure with specific arguments. do a configure with bitbake, then drop into devshell and run the ../temp/run.do_configure* script Aug 06 15:02:37 hey all Aug 06 15:02:40 hi kergoth Aug 06 15:04:17 kergoth, bluelightning : thanks for the tips, I will try your suggestions Aug 06 15:15:46 should yocto -doc packages install to /usr/share/doc/$PN or /usr/share/doc/$PN-$PV ? I find that $PV in path odd... Aug 06 15:18:05 mcfrisk: I can't see that there's an explicit setting of that anywhere - which recipe's packages are you seeing this in? Aug 06 15:18:21 kergoth, right, now things start to looks as expected, thanks again. I was not aware of this workflow, from docs I assumed that in devshell I can run commands in a same way as if I was on the desktop for example. Aug 06 15:18:28 bluelightning: libxml2 Aug 06 15:19:26 gatisp: generally you can, but cross-compilation is not a trivial thing, we do a lot to make it work properly, which includes running configure and make with the right arguments to get the expected results Aug 06 15:19:32 mcfrisk: possibly that project follows the RH style, because on my CentOS box, subdirs of /usr/share/doc have versions in the name Aug 06 15:24:00 bluelightning: some -doc packages include example code which can be used for testing e.g. the SDK Aug 06 15:24:16 so I'll ignore this version number in path Aug 06 15:24:49 Is the openembedded conference in Dublin open to anyone? Aug 06 15:29:26 ftonello: I believe so yes Aug 06 15:29:41 yup.. just have to register, pay the small fee and show up Aug 06 15:30:07 ELC-E.. there is the OpenEmbedded meeting part that is open to any e.V. members.. Aug 06 15:30:14 Hello all, having a bit of a conundrum issue: http://pastie.org/pastes/10333664/text Aug 06 15:30:29 fray: I guess he means OEDEM, there shouldn't be a fee for that AFAIK Aug 06 15:30:38 despite having PREFERRED_PROVIDER_ set, it is not listening ? Aug 06 15:30:39 fray: and Philip did say all are welcome Aug 06 15:30:44 ahh yes.. OEDEM is different Aug 06 15:31:12 WarheadsSE: linux-firmware-rtlwifi is a package right? Aug 06 15:31:23 it is a packagename Aug 06 15:31:40 WarheadsSE: unfortunately using PREFERRED_PROVIDER to specify a provider for a runtime target (i.e. a package) doesn't actually work Aug 06 15:31:51 * WarheadsSE sigh Aug 06 15:32:01 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6149 Aug 06 15:32:03 Bug 6149: normal, Low, Future, paul.eggleton, NEW , Setting PREFERRED_PROVIDER to select between multiple runtime providers does not work Aug 06 15:32:19 * bluelightning notes the bug is assigned to him :( Aug 06 15:32:45 I think the conclusion would be try to avoid getting yourself into that situation Aug 06 15:34:50 yeah.. Aug 06 15:35:07 Is Josua online? Aug 06 15:35:39 otavio: which one? Lock? Aug 06 15:35:44 yes Aug 06 15:35:47 joshuagl: ^^ Aug 06 15:36:01 bluelightning: sigh, my next recourse is one of two, PNBLACKLIST or DEFAULT_PREFERENCE alteration. Aug 06 15:36:41 joshuagl: The perf fix is locking me up; is it possible for you to merge it into fido? it is in fido-next for a while Aug 06 15:47:18 bluelightning: on that same vein: bitbake linux-firmware-rtlwifi Aug 06 15:47:20 ERROR: Nothing PROVIDES 'linux-firmware-rtlwifi'. Close matches: linux-firmware Aug 06 15:47:28 * WarheadsSE facepalm Aug 06 15:47:46 WarheadsSE: bitbake does not take package names on the command line, only build-time targets (i.e. recipes) Aug 06 15:47:47 You can tell me I need to set a preferred provider, but can't find it Aug 06 15:48:23 right, that's a known issue as noted Aug 06 15:48:26 Yeah, one of those joyous pains that probably crosses the same point of pain Aug 06 15:59:12 you can always specify an explicit non-runtime preference, and bitbake will obey it to resolve runtime Aug 06 15:59:35 e.g. PREFERRED_PROVIDER_foo = "foo", if foo is the recipe you want which emits the package in question Aug 06 16:04:48 trying that now Aug 06 16:05:49 K, warning stopped Aug 06 16:06:15 Waiting to see which it builds Aug 06 16:18:29 Hi, I want to set a flag in cmake for a recipe (-D WITH_CUDA=ON). What I did is that I added it to EXTRA_OECMAKE variable in it's recipe file. But it gives the following error: http://paste.ubuntu.com/12014506/ please have a look and help me out Aug 06 16:19:56 did you try -DWITH_CUDA=ON? Aug 06 16:21:15 wait a second... Aug 06 16:22:11 I guess that did the job. Aug 06 16:22:13 Thanks Aug 06 16:22:34 neverpanic: mind if I ask some general questions about yocto? Aug 06 16:23:34 Don't mind if you ask here, but I may not be able to answer -- not a Yocto expert myself. Aug 06 16:24:35 SO, who really uses yocto? Mostly people do it as part of their work in a company, right? Aug 06 16:25:37 it is mixed, I know of a few people that do it for their own from-scratch-but-with-others-help linux distro/installations Aug 06 16:26:42 Well, that's what I am here for. I want to build a minimal disto for my board. It looks very simple with yocto. Aug 06 16:28:01 What I do is to add all the recipes, the bsp, and then mention the packages I want installed in build/local.conf. Then do a bitbake core-image-minimal, and voila! Aug 06 16:29:11 I just wanted to know if I am doing it correctly. Ofcourse I am supposed to make a layer byself. But this is not a large project. So it wont matter. Right? Aug 06 16:30:08 Anyone going to OEDEM ? Aug 06 16:30:15 I am interested in attending, what should I do? Aug 06 16:42:05 Hi, I created a recipe that inherits cmake to build a library. I defined in the FILES_${PN} what are the files generated by the library, however I get a QA error because apparently it creates a "/usr/src/debug" folder in the package and puts the source there. QA complains I didn't put those in the FILES variables. How do I stop those sources from going there? Aug 06 16:42:43 The CMakeLists.txt file only has directives to install the generated library Aug 06 16:42:47 archer121: I would suggest making a packagegroup Aug 06 16:43:37 you should isolate "your" layer, always Aug 06 16:43:53 that way moving parts under you won't bite you in the proverbial ass Aug 06 16:43:55 WarheadsSE: Why? Aug 06 16:44:07 archer121: it's always great to create your layer, because if you upgrade other layers you might lose your recipes, confs, etc. Aug 06 16:44:22 ^ Aug 06 16:44:31 DS__: The point is, I don't have any. Aug 06 16:45:03 I just need OpenCV with CUDA support. That's all Aug 06 16:45:09 archer121: from what you've said earlier, you wanted to add a flag for cmake in a recipe. This is something that could get lost if you did in someone else's layer Aug 06 16:45:18 that makes for a very good .bbappend in your own layer. Aug 06 16:45:26 What WarheadsSE said Aug 06 16:45:56 then, moving foward, when you update the underlying (origin) layer, you don't have to remove that edit, and then add it back Aug 06 16:45:57 You can append recipes with your own stuff in your own layer. It's an idea similar to "patching" someone else's code Aug 06 16:46:07 DS__: ah, I get in now. Aug 06 16:46:41 Yocto build system is superb cool. I will be making my on layer. Aug 06 16:47:02 archer121: When I started working with yocto (not long ago) I hardcoded my changes in all layers. That became a nightmare to fix when yocto 1.8 was released, because I wanted to upgrade and couldn't Aug 06 16:47:26 Since then I learned how to do that properly :) Aug 06 16:47:27 DS__: I get it. Aug 06 16:48:10 that and make good use of repo Aug 06 16:49:09 DS__: So now you are not including meta-oe. You just make your on .bb, and refer to .bb found in meta-oe or other layers for reference. Aug 06 16:50:07 archer121: no. I include meta-oe, but I never modify stuff that's in there Aug 06 16:50:20 that is what .bbappends are for Aug 06 16:50:25 If I want to modify a recipe, I create a .bbappend in my own layer that modifies the recipe I want Aug 06 16:50:58 DS__: OK. rings bells... I need to read more Aug 06 16:51:23 archer121: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-bbappend-files Aug 06 16:51:34 I recommend reading the entire section as well Aug 06 16:51:51 yeah, I'm reading it now Aug 06 16:54:38 One more question: I can cross-compile binaries on yocto. So I make a recipe. Or say I don't have vim in the build image which I flashed. So i do a bitmake vim. Where does the output do? Aug 06 16:55:00 *do=go Aug 06 16:55:53 archer121: if you only bitbake vim, bitbake will build that recipe for the machine configured in your local.conf, but will not add it to any images Aug 06 16:56:17 I can add manually over ssh. but where is the binary? Aug 06 16:57:05 or where is the built binary? Aug 06 16:57:13 see DEPLOYDIR Aug 06 16:57:22 but yocto can cross compile. Aug 06 16:57:35 It's better if you just add it to your image, and bitbake will take care of installing it in the proper location. But if you really want to do it manually, check your build/tmp/work/machinename/vim Aug 06 16:57:56 ok, so in .bb, the DEPLOYDIR would be pointing to somewhere in tmp Aug 06 16:58:12 and build/tmp/deplot/ipk/xx/vim* Aug 06 16:58:31 archer121: please see DEPLOYDIR in the manual Aug 06 16:58:34 it is well defined. Aug 06 16:58:39 sure sure Aug 06 17:01:56 kergoth: hmm, looks like that didn't quite work. Aug 06 17:02:20 still getting that rtlwifi-new building Aug 06 17:40:23 Good Day Aug 06 18:14:38 damnit, my plan of attack for git shallow support isn't viable, will have to make more invasive changes Aug 06 18:17:11 hi, why do I get this mess? /opt/polatis/2.0/sysroots/x86_64-polatissdk-linux/usr/share/misc/magic.mgc, 855: Warning: offset `������' invalid Aug 06 18:17:14 /opt/polatis/2.0/sysroots/x86_64-polatissdk-linux/usr/share/misc/magic.mgc, 855: Warning: type `������' invalid Aug 06 18:17:29 when using file on a binary? Aug 06 18:18:09 that's .. weird Aug 06 18:18:29 the file in question is generated by the Yocto SDK that I created for our image. Aug 06 18:18:38 it is clearly platform differences Aug 06 18:18:52 x86_64 file and 32 bit arm, but it did not use to be like that. I experience this mostly with the Yocto SDK. Aug 06 18:21:44 if the magic file is in the x86_64 sysroot, then that came from the nativesdk-file build, which wouldn't have anything to do with arm Aug 06 18:22:36 This is what I ran: file `find ./ -name foo.o` Aug 06 18:23:12 for me it is hard to tell because I just built the object using the ARM SDK. Aug 06 18:23:27 after running the usual environment setup script. Aug 06 18:24:51 it sounds like the magic file itself is corrupted, i doubt it has anything to do with what you're running file against Aug 06 18:26:26 OKAY, so other question... how would I know what is causing this recipe to build ? Aug 06 18:29:10 kergoth: oh, could it be with my SDK generation then? Aug 06 18:29:51 I still think it is something with x86_64 because my colleagues cannot see this issue and they are using x86 ubuntu :) Aug 06 18:31:09 but it could be that the x86_64 SDK generated is corrupted. Aug 06 18:31:17 or perhaps something made it so after the installation? Aug 06 18:31:59 I dislike this x86 and x86_64 troubles all the time for embedded development :p Aug 06 18:32:10 life would be so much easier if people used 64 bit on the host more and more. Aug 06 18:32:25 WarheadsSE: which recipe? Aug 06 18:32:41 WarheadsSE: cannot you grep for depends? Aug 06 18:32:43 one in my layer, that I don't want. Aug 06 18:35:53 it's got a provides that kernel-module-rtlwifi & i need the one from the kernel package, and not that kernel-module-rtlwifi-new_XXX.bb Aug 06 18:36:24 preferred provider maybe? Aug 06 18:37:20 already tried. Aug 06 18:37:44 need: kernel-module-rtlwifi (made as part of the kernel, runtime package) Aug 06 18:38:58 this also PROVIDES that Aug 06 18:39:44 ah, okay, sorry for not being useful then ;-) Aug 06 18:42:16 odd that the preference didn't work, worst case i'd just pnblacklist the thing Aug 06 18:42:43 thats looks like the only real option I seem to have. Aug 06 18:42:53 Which is going to be lovely problematic. Aug 06 18:48:52 not a yocto question, but is there a way to check the architecture and platform a binary is built for without file? Aug 06 18:49:08 since file does not seem to work due to the magic file, I would still like to identify that about a binary :) Aug 06 18:54:22 lpapp, readelf -d ? Aug 06 18:54:58 tools will need a proper ELF header to give the info if that is not proper then I guess no tool will be of help Aug 06 18:55:49 ok, so this breakage with the magic file is then serious enough Aug 06 18:56:03 what could have potentially caused it and how to fix it? Aug 06 18:56:21 hmm may be not Aug 06 18:56:27 try doing readelf -e Aug 06 18:56:34 readelf -d was not okay Aug 06 18:56:42 but I was also thinking of nm or readelf. Aug 06 18:56:46 ok, I will try that. Aug 06 18:57:05 lpapp: you ca also do 'file foo; Aug 06 18:57:09 file foo* Aug 06 18:57:14 heh Aug 06 18:57:33 thanks, it seems to work Aug 06 18:57:37 ELF32 Aug 06 18:57:37 oops just read that Aug 06 18:58:54 readelf -h | grep Machine Aug 06 19:00:31 hmmm objdump -f output is more closer to file output Aug 06 19:00:44 man nm Aug 06 20:14:04 kergoth: looks like machine/x.conf w/ blacklist seems to have fixed that, finally. Aug 06 20:43:10 Does anyone know if there is a way to force a recipe to always rebuild and prevent it from just loading from the cache each time? Aug 06 20:50:00 why wouldn't you just do a "bitbake -c cleansstate " when needed? Aug 06 20:51:57 So the recipe adds a buildID in the form of a timestamp to the /etc/os-release file and so I don't really want to have to manually clean it each time. Aug 06 20:55:11 fivefootseven: I believe -f also forces a build Aug 06 20:57:56 sounds like a job for ROOTFS_PREPROCESS_COMMAND Aug 06 20:59:29 I use that to capture the date of the build, and then insert that into the default hostname if no other hostname was specified in the local.conf Aug 06 21:00:16 of course, with yocto, there are typically 38 ways you can come at any given task. :) Aug 06 21:01:44 Thanks everyone for your help. It looks like ROOTFS_PREPROCESS_COMMAND is exactly what I need. Will try moving over to that now... Aug 07 02:42:19 how do I include mesa-megadriver package into the final image? **** ENDING LOGGING AT Fri Aug 07 02:59:58 2015