**** BEGIN LOGGING AT Mon Aug 28 03:00:01 2017 Aug 28 08:27:09 Hi all, I am having issue when building with QT5 since upgrading to Krogoth. I always run into errors similar to this: QA Issue: Qt5Qml.pc failed sanity test (tmpdir) in path /home/jenkins/jenkins-root/workspace/nSDK-stream800-yocto/build/.build-yocto/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/qtdeclarative/5.6.2+gitAUTOINC+c1d726fe19-r0/sysroot-destdir/usr/lib/pkgconfig [pkgconfig] Aug 28 08:28:09 The thing is, this only happens if the TMPDIR var is NOT set. If I set the TMPDIR var to something outside of my project root dir it is working fine. Aug 28 08:28:50 I fixed the error for the qtxmlpatterns package by adding the following line via a bbappend: Aug 28 08:29:01 sed -i 's@-L${STAGING_LIBDIR} @ @g' ${D}${libdir}/pkgconfig/Qt5XmlPatterns.pc Aug 28 08:29:43 I know this is a hack and it actually didn't resolve the issue, because after that the build failed for the Qt5Qml package with the same error Aug 28 08:30:27 I believe there must be something wrong in my config, because I couldn't find anyone having the same issues. Anyone here that has an idea what could be the problem? Thanks Aug 28 08:54:11 hi, can someone provide a guide about how to add a package manager in a linux image in yocto ? i use the recent version of poky-pyro Aug 28 09:03:19 yahiafarghaly http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management Aug 28 09:05:31 melonipoika thanks , i will try it Aug 28 10:34:13 hello community, i am trying to install sinatra on yocto getting this error: gem install sinatra /usr/bin/ruby: symbol lookup error: /usr/lib/ruby/2.2.0/arm-linux-gnueabi/socket.so: undefined symbol: getipnodebyname Aug 28 10:44:06 ruby --version Aug 28 10:44:06 ruby 2.2.1p85 (2015-02-26 revision 49769) [arm-linux-gnueabi] Aug 28 10:58:51 anyone got ruby working on yocto? Aug 28 11:06:37 how can i report a bug to yocto? Aug 28 11:07:19 Are you installing ruby from a OE layer? Aug 28 11:07:26 an* Aug 28 11:33:04 JoiF, https://layers.openembedded.org/layerindex/branch/fido/layer/meta-ruby/ Aug 28 11:50:30 pagios: Then I think, if you have found a bug, you should report it to OE :) Aug 28 11:50:50 how do i report it Aug 28 12:04:18 pagios what about http://www.openembedded.org/wiki/Bug_tracking? Aug 28 13:03:02 what is the package-index in bitbake package-index ? and how to create a .deb file from compiled binary such as exist in linux distro ? Aug 28 13:23:40 Hello Aug 28 13:24:47 is it possible to combine the output of image-buildinfo which produces the file /etc/build with the output of buildhistory that has all the packages, with versions, for a given image ? And put all of that in /etc/build Aug 28 13:25:17 I would like bitbake to generate a file that contains the revisions of all the packages and place it in the rootfs Aug 28 14:01:44 Hello everyone, I've noticed that " bitbake -c fetchall " doesn't fetch all sources needed for " bitbake -c populate_sdk_ext ". Is there a way to pre-fetch all sources needed for the command "bitbake -c populate_sdk_ext "? Aug 28 14:42:53 Morning all, a quick poll (will also send to arch list): Who is still using ELF style images (if anyone)? Aug 28 14:45:15 For? Aug 28 14:46:13 Crofton|work: for system images IMAGE_FSTYPES Aug 28 14:49:13 Crofton|work: the reason I ask is we have an incompatibility with binutils now and it appears that mkelfimage was removed from coreboot almost 3 years ago in favor of cbfstool! Aug 28 14:49:49 Yeah, I figured something like that Aug 28 14:50:00 Send email see who replies Aug 28 14:50:08 or listen to crickets Aug 28 14:51:05 yup, that's the plan, just wanted to see if there was any knee-jerk adverse reaction here. Aug 28 15:09:47 where can i find the dtc ? Aug 28 15:11:50 https://git.kernel.org/pub/scm/utils/dtc/dtc.git Aug 28 15:17:38 abelloni: thankyou Aug 28 15:23:14 question, i am trying to get my ipk on a yocto 2.3 running imx6 getting this error: https://pastebin.com/LVhEYaqF Aug 28 15:35:56 how can i compile for 32bit Aug 28 17:41:14 RP: would you mind quickly summarizing why the bitbake fetcher insists on knowing the branch that a given rev resides on? Aug 28 17:42:04 kergoth: isn't that something that can be disabled? I always assumed that it is just a sanity check. Aug 28 17:54:45 conf/../../layers/meta-qcom/recipes-devtools/python/python-flask-marshmallow.inc:1: unparsed line: 'SUMMARY = "Flask plus marshmallow for beautiful APIs'06 Aug 28 17:54:57 When I do a build I get this... Any idea whats wrong with that? Aug 28 17:55:08 tcpdump: you might have to escape that ' Aug 28 17:55:31 APIs'06 Aug 28 17:56:36 thansk! Aug 28 17:56:37 that was it... Aug 28 17:56:38 ugh Aug 28 17:57:21 pagios: it seems the tune arch changes in between can you try to see whats it for installed packages ? may be opkg info will show it Aug 28 18:46:54 Hello - is there a variable I can expand in a recipe to get tmp/work/my_platform/my_package/package_vers/deploy-my_package? Aug 28 18:49:01 in what context? Aug 28 18:50:19 Circuitsoft: you mean this one? http://git.openembedded.org/openembedded-core/tree/meta/classes/deploy.bbclass#n1 Aug 28 18:50:41 I have an image recipe I'm trying to port from krogoth to morty. I wrote my own build_fat_img, which I kinda hack around to actually make a cpio.gz archive. Aug 28 18:51:28 sounds like you should read image.bbclass and/or image_types.bbclass Aug 28 18:51:41 In morty, it errors on do_bootimg, unable to stat tmp/deploy/images/platform/myroot.squashfs-xz Aug 28 18:52:04 I have, some. I suppose I should diff them between krogoth and morty to see what changed. Aug 28 18:53:24 Okay, so IMGDEPLOYDIR. Aug 28 18:53:31 :) Aug 28 18:55:33 Cool. I think I have everything else figured out now, I just need to figure out where ipxe is getting confused. Aug 28 18:57:07 Error log - coming up. Aug 28 18:58:28 https://clbin.com/0MiYM - "Error: missing or invalid displacement expression" - http://lists.ipxe.org/pipermail/ipxe-devel/2016-February/004640.html Aug 28 18:58:39 clbin has the bitbake recipe Aug 28 19:25:59 Looking for general opinions: We'd like to have a general storage area for our Yocto build environment so we can attach it to an arbitrary host VM, clone it, etc. My attempts at hacking around the issues generated by using an NFS are not making it very far, certainly far short of a functional image. Anyone have a clever solution they've applied to make their build environment [semi-]portable? Aug 28 19:26:04 Any questions or comments appreciated. Aug 28 19:26:47 majuk: Does sstate-cache not solve this? Aug 28 19:26:59 yeah, i see no point to share tmp at all, and it's safe to share anything else.. Aug 28 19:27:43 Ok, I'll look into the functionality of the intermediate build folders. Thanks. Aug 28 19:28:06 Circuitsoft: It may, I am far from confident or capable with Yocto. :D Aug 28 19:29:04 majuk: Put SSTATE_CACHE on an NFS folder that everyone shares, but still have everyone build their own. It'll speed things up tremendously with no dangers. Aug 28 19:29:40 Circuitsoft: Ah, fancy. I like it. Thanks for the input. Aug 28 20:27:38 khem, ping Aug 28 21:37:22 kergoth: offhand I'm struggling, did you look at the commit history? Aug 28 21:40:28 kergoth: I have a feeling we needed branch to make http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/fetch2/git.py?id=9ccfe66074cdacd1f529c241fadd52b5663584fc work Aug 28 21:41:55 kergoth: some things used to be surprisingly hard in older git versions and it may be better now... Aug 28 21:42:19 why do we need to check for ancestors at all? is it just to ensure that the user gets a branch checkout rather than rev checkout? Aug 28 21:46:55 kergoth: we used to have horror stories where the fetcher returned "success" but in reality something had gone wrong and we didn't have what we asked or thought we had Aug 28 21:47:10 kergoth: adding in a double check was therefore a very good thing Aug 28 21:47:18 if all we care about is whether the fetch gave us the rev we need, then rev-parse on the rev should do Aug 28 21:47:43 so if it's only to double check, i think there are better ways to make sure we have what's needed.. or just verify that need_update() now shows no need to update anymore Aug 28 21:47:46 kergoth: I doubt rev-parse existed then Aug 28 21:47:54 pretty sure rev-parse has nearly always existed.. Aug 28 21:47:58 it's how git parses its arguments Aug 28 21:48:01 :) Aug 28 21:48:17 kergoth: well, I don't think you could use it back then to validate a revision was correct Aug 28 21:48:32 that's the whole point of rev-parse Aug 28 21:48:40 kergoth: hence the comments in that commit about mergebase and all kinds of other commands Aug 28 21:48:41 it resolves refs and expands short revs Aug 28 21:48:54 that's why it exists, to sanitize committish arguments.. Aug 28 21:49:07 but regardless, i'll add a minor note to look into it at some point Aug 28 21:49:15 working on the rewritten gitsm as a sideproject :) Aug 28 21:50:28 just marking the submodules as nobranch, i think that makes sense anyway, since it's git doing the checking out, not us.. bare, nobranch Aug 28 21:52:16 kergoth: right. I'm sure there was a reason for this, I just don't remember :( Aug 28 21:52:43 yeah, i figured as much, was just curious if you knew offhand Aug 28 21:52:45 no worries Aug 28 21:52:45 thanks Aug 28 21:53:05 kergoth: even 4 years ago there were things like http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/fetch2/git.py?id=498de0473709414961873333b9473ad5a922d78c Aug 28 21:53:19 i.e. we couldn't tell if something was a branch, tag, revision etc :/ Aug 28 21:53:36 yikes Aug 28 21:58:46 considering we don't even need to check out a branch to be able to build, only to develop, that's a lot of complexity. the only reason we really care about branch or tag at all, as far as i can tell, is to determine what AUTOREV should do, and whether we need to map a tag name to a revision or not Aug 28 21:58:48 something to mull over Aug 28 22:44:11 pagios: yes Aug 29 01:58:52 RP: if you wouldn't mind taking a quick look at https://gist.github.com/kergoth/9c163433c33cf883b21256459d743a98 tomorrow, just to get your thoughts on the general approach, obviously have work yet to do **** ENDING LOGGING AT Tue Aug 29 03:00:00 2017