**** BEGIN LOGGING AT Mon Jul 16 03:00:01 2018 Jul 16 03:05:56 New news from stackoverflow: How to get Openembedded to compile tar.gz files instead of tar.xz Jul 16 05:36:22 New news from stackoverflow: Yocto zip download on every build Jul 16 08:36:03 Marex: We don't encourage people to hack class files but to fix them properly Jul 16 09:18:20 RP: that's fine by me, but how do I solve this until upstream accepts those patches , which might take a long time ? Jul 16 09:19:11 RP: I need the following three in rocko to get my multilib issues solved Jul 16 09:19:16 f1079cd193 staging/image: Fix multilib recipe sysroot issues Jul 16 09:19:27 6ca693f284 staging: Improve fixup processing code Jul 16 09:19:32 f755066a00 staging: Always use the default sysroot for allarch recipes Jul 16 10:07:14 New news from stackoverflow: do_kernel_metadata in Yocto 2.4 takes so much long time to complete Jul 16 11:06:23 RP: could those be backported ? Jul 16 11:16:34 Hi guys & girls, Jul 16 11:17:03 Can anyone explain the difference between 'inherit native' and 'BBCLASSEXTEND = native' ? Jul 16 11:18:22 the former makes the current recipe native, the latter creates a copy of the current recipe and magically makes it native Jul 16 11:18:32 (by adding -native in lots of places) Jul 16 11:18:59 Thanks rburton Jul 16 11:19:43 So any idea why a recipe would not be built with the BBCLASSEXTEND=native while it does build when I use 'inherit native' ? Jul 16 11:20:03 define "not be built" Jul 16 11:20:11 Okay Jul 16 11:21:19 It throws an error stating that it can not find a header file Jul 16 11:21:34 while with the 'inherit native' line it does not throw this error Jul 16 11:22:27 note that if you have foo.bb with inherit native then you have a native recipe called just 'foo', but foo.bb with BBCLASSEXTEND=native gives you a *target* recipe called foo but a *native* recipe called foo-native Jul 16 11:22:42 so be sure you get your names right Jul 16 12:00:42 The thing is that I am trying to generate a nativesdk package out of a 'inherit native' recipe. Jul 16 12:01:39 Do you think that it would be possible having in mind that when I am trying to use 'PACKAGES = "${PN}" I get an error regarding the no-package specific nature of the native class ? Jul 16 12:03:27 nativesdk packages need to inherit nativesdk either directly or via bbclassextend Jul 16 12:04:04 if you look at oe-core you'll see that many recipes are written generically enough that they just need bbclassextend="native nativesdk" to build for target, native, and nativesdk Jul 16 12:05:06 I am using this technique to add packages into my nativesdk, but in this case when I try to use bbclassextend instead of inherit, it does throw this error of not finding a header file Jul 16 12:05:22 And that is the reason I am confused as what I am not getting here Jul 16 12:06:15 pastebin the recipe and error? Jul 16 12:14:19 Marex: armpit usually handles stable series backports so you should probably post something on the mailing list Jul 16 12:14:53 RP: what's the process for this ? Jul 16 12:15:14 RP: just cherry-pick , fix conflict, post ? Jul 16 12:15:27 armpit: thoughts ? ^ Jul 16 12:15:30 Marex: yes, with the right prefix Jul 16 12:15:43 Marex I think armpit is away this week Jul 16 12:22:19 RP: is that procedure documented somewhere ? what prefix ? Jul 16 12:28:48 Marex: yes, it is. First google hit of "stable yocto" Jul 16 12:28:55 https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Jul 16 12:31:26 RP: thanks Jul 16 12:35:11 RP: For information on which mailing list you should send these to see the README file in the Poky repository. Jul 16 12:35:16 RP: the link to the readme file is broken ;-) Jul 16 12:35:51 Marex: Its a wiki? Jul 16 14:15:50 halstead: I think something may be wrong with the .io cluster and hung builds :( Jul 16 14:31:58 halstead: not hung, going very slowly Jul 16 14:38:45 RP: quirk in log output i just noticed: NOTE: core-image-sato-1.0-r0 do_testsdk: perl.PerlTest.test_perl_exists (subunit.RemotedTestCase) Jul 16 14:38:59 (doesn't show module name) Jul 16 14:46:06 rburton: yes, not sure how to fix that Jul 16 14:46:14 halstead: I've sent email Jul 16 14:49:03 rburton: thanks for cleaning up that test :) Jul 16 14:49:17 rburton: curious which of us would break first Jul 16 14:49:41 i had an old revision in a branch but for some reason failed to post it Jul 16 14:50:08 things that annoy me: sdk test case run() is not the same as runtime test case run() Jul 16 14:51:03 rburton: yes, my sdk fix showed the API is horrid too Jul 16 14:52:28 RP: any idea why the sdk python test would want to check that the host manifest has either nativesdk-python or python-native? Jul 16 14:52:33 surely the native thing is nonsense Jul 16 14:56:05 rburton: esdk Jul 16 14:56:15 hm Jul 16 14:56:30 rburton: it shares the sdk tests Jul 16 14:56:51 its horrible but you asked why, not whether I liked it ;-) Jul 16 14:56:56 :) Jul 16 15:26:07 otavio, hello you there? Jul 16 15:26:50 I have an issue with the mfgtool usb0 switch on i.MX6UL Jul 16 15:27:23 basically, I didn't connect the usb_otg_ID pin, and I can't make mfgtool see the device in mass-storage mode... Jul 16 15:27:33 any idea? the dts seems to be not parsing such gpio Jul 16 15:32:20 ok, yocto 101 question here: if i bitbake my kernel, say, "bitbake linux-variscite", shouldn't that create a /tmp/.../linux-variscite//build folder? Jul 16 15:33:18 /tmp/work/.../linux-variscite//build Jul 16 15:35:02 i'm not seeing the folder any more... Jul 16 15:36:27 and i'm not seeing any of the build files like the .patch file there. Jul 16 15:37:44 kergoth: any ideas? Jul 16 15:38:37 i've tried running bitbake -c clean linux-variscite first, then rebuilding. bitbake completes with no errors, but i don't see the usual stuff in this directory Jul 16 15:38:50 yates: kernels use both a source tree and build dir in tmp/work-shared/ Jul 16 15:38:58 it's a special case Jul 16 15:39:31 kergoth: well does an image build then use tmp/work? Jul 16 15:40:03 i see kernel build files in tmp/work of a separate build i did last week. Jul 16 15:58:13 i am trying to check out which defconfig the build is using, but now the build isn't putting any defconfg in the build dir... Jul 16 15:59:42 otavio, nvm, it works now Jul 16 16:00:59 something is hosed. Jul 16 16:01:23 yates: i don't understand the question. Jul 16 16:01:35 workdir is set on a per-recipe basis, what you happened to build is irrelevent Jul 16 16:01:47 building an image or another recipe won't change where the kernel files go, that's controlled by WORKDIR in the kernel recipe Jul 16 16:01:52 and S and B of course Jul 16 16:02:26 of course S and B also depend on whether youv'e used devtool modify on that recipe Jul 16 16:06:26 kergoth: i have two differenct yocto projects on my hard drive, rtc-test and swupdate-test. they are from the same branch of svn of the same project, one with modifications and one without. Jul 16 16:08:29 nm. Jul 16 16:08:30 New news from stackoverflow: AWS CodeBuild as non-root user Jul 16 16:08:44 i think it's Monday... Jul 16 16:10:04 belay that nm.. Jul 16 16:10:52 so one project has kernel files, e.g., the .patch file, in swupdate-test/sources/poky/build-hw-test-image/tmp/work/imx6ul_var_dart-fslc-linux-gnueabi/linux-variscite/4.1.15-r0/ Jul 16 16:11:04 the other does not, in rtc-test/sources/poky/build-hw-test-image/tmp/work/imx6ul_var_dart-fslc-linux-gnueabi/linux-variscite/4.1.15-r0/ Jul 16 16:11:09 why the discrepancy? Jul 16 16:16:39 that file must be put there when building the image. when building the kernel only, the .patch file is not in the tmp/work directory in either project. Jul 16 16:17:17 so something is not correct in your statement, "what you happened to build is irrelevent" Jul 16 16:19:07 don't know what to tell you, the recipe is what determines where the files go, it's that simple Jul 16 16:19:42 fair enough. Jul 16 16:19:56 thanks for helping me sort through this, even though i'm not done... Jul 16 17:28:20 let me restate my question: where can i find the defconfig used to build the kernel with? Jul 16 17:29:10 i would expect it to be somewhere under tmp/work/.../linux-varisite, but it is not Jul 16 17:31:44 here are some search results regarding WORKDIR: https://paste.fedoraproject.org/paste/g99jVVhzp6bRC3pkHTRQtg Jul 16 17:33:05 is there a reason I shouldn't use $RECIPE_SYSROOT in my recipes? I'm not seeing very many other recipes which use it Jul 16 17:33:46 and my kernel recipe has S as follows: S = "${WORKDIR}/git" Jul 16 18:00:34 Hooloovo0: recipe specific sysroot is an implementation detail. recipes shouldn't care where it's pulling stuff from, it should use the correct variables like STAGING_INCDIR if absolutely necessary (which it generally isn't, as we pass —sysroot= to the toolchain, etc) Jul 16 18:09:05 welp, guess it's time to rework libre/librem/baresip's build system because it's a dumpster fire for cross compilation :/ Jul 16 18:22:03 fg Jul 16 18:46:12 Hi I have a question, In devtool-source.bbclass under devtoo_post_unpack, all local files are moved to ${devtools workdir}/oe-local-files, but for kernel, kernel-yocto.bbclass is still looking for files under ${devtools workdir}/ Am i missing something here? happy to provide more info Jul 16 19:14:37 I am new to Yocto and am having trouble building a Yocto image recipe...it is failing with the following output: Jul 16 19:14:38 ERROR: dey-image-aws-1.0-r0 do_rootfs: Could not invoke dnf. Command '/home/ubuntu/workspace/ccimx6ulstarter/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/dey-image-aws/1.0-r0/recipe-sysroot-native/usr/bin/dnf -y -c /home/ubuntu/workspace/ccimx6ulstarter/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/dey-image-aws/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/home/ubuntu/workspace/ccimx6ulstarter/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/de Jul 16 19:15:00 Hmm. Jul 16 19:15:30 https://paste.ofcode.org/bCxtUdsnDQypX2gWeKYHdS Jul 16 19:15:41 That link shows the build output. Jul 16 19:17:19 I am having a hard time understanding where to start trying to debug the issue...the error message seems to indicate that Yocto doesn't have any recipes that provide libcrypto...so how do I create a recipe that provides that? Jul 16 19:20:54 no, it only means at the time of image creation it couldnt' find the bnary package for it. that doesn't mean no recipe exists that can emit it, or even that no package was emitted for it, necessarily, as our packages are broken up into multiple feeds based on architecture Jul 16 19:21:06 i'd start with find tmp/deploy/ipk -name \*libcrypt\* Jul 16 19:24:52 So, I didn't find any libs under tmp/deply/ipk...but I did find this result when searching tmp/deploy.. Jul 16 19:24:53 tmp/deploy/rpm/cortexa7hf_neon/libcrypto1.0.2-1.0.2o-r0.0.cortexa7hf_neon.rpm Jul 16 19:25:45 Is anything under tmp/deploy a cross-compiled library? i.e. Built for my target architecture instead of my build machine? Jul 16 19:26:51 not if you've been building sdks, but otherwise yes Jul 16 19:27:00 in this case yes, that's the package you need Jul 16 19:27:57 So, if that package exists but Yocto can't find it...would that indicate a bad search path? Jul 16 20:20:19 is there a way to instruct bitbake to remove ALL generated data, so that the next recipe or image bitbaked is regenerated from scratch? Jul 16 20:20:50 i'm aware of bitbake -c clean , but i want it for ALL recipes, images, etc. Jul 16 20:31:09 Jul 16 20:33:05 why, after "rm -fR tmp" and then bitbaking my image, does my tmp/deploy/images/imx6ul-var-dart/ folder contain files from Jul 13? Jul 16 20:33:43 e.g., u-boot-nand-1.0-r0.img Jul 16 20:36:09 yates: sstate Jul 16 20:36:27 if you want to build entirely from scratch, either rename or delete the sstate cache Jul 16 20:37:36 rburton: ok, giving that a shot. thank you. Jul 16 21:01:30 or use bitbake --no-setscene Jul 16 21:34:31 @kergoth I missed the first thing you said...I'm going to try the --no-setscene though. Jul 16 21:35:44 Same results with no-setscene **** ENDING LOGGING AT Tue Jul 17 03:00:03 2018