**** BEGIN LOGGING AT Thu Mar 19 03:00:02 2020 Mar 19 05:33:36 How to create a static hello world program in C using yocto - zynq? Mar 19 05:33:44 I am trying to create a simple hello world program in C using yocto. Mar 19 05:33:52 #include Mar 19 08:18:55 joshis52: what did you do and where did you get stuck? Mar 19 08:28:03 I am creating a sysbolic link in a nativesdk- recipe, in the corresponding do_install() function. But after installing the SDK, the symbolic link has preppended ../../../../../../../../../../../../../../../../ and only after that comes the path to which it should point. Mar 19 08:29:51 nemgti-og: do the link work? Mar 19 08:30:09 In the recipe I am doing ln -sfrT "${datadir}/${PN}-${PV}/${FILENAME} ${d}${BINDIR}/${FILENAME} Mar 19 08:30:27 erbo: No. The link does not work Mar 19 08:33:22 nemgti-og: I wonder if it might break because of using absolute paths. Mar 19 08:34:34 erbo: right... might be Mar 19 08:34:37 nemgti-og: what would ${datadir}/${PN}-${PV}/${FILENAME} evaluate to here? Somewhere in /etc? Mar 19 08:35:23 nemgti-og: does ${d} work? isn't it ${D}? but I recall us having issues with symlinks Mar 19 08:35:26 let me check Mar 19 08:36:06 erbo: it sould be /usr/share/nativesdk-capicxx-core-3.1.12.3/commonapi-generator-linux-x86_64 Mar 19 08:36:24 qschulz: I meant D. Mar 19 08:36:59 nemgti-og: But should the link really point somewhere outside on the build host? Is that intended? Mar 19 08:38:25 erbo: The idea is that the binayr should be part of my SDK, located in $SDKSYSROOT/usr/share... and a link to in in $SDKSYSROOT/usr/bin Mar 19 08:41:08 nemgti-og: ok, then using something like: cd {D}/${BINDIR}/ , ln -sfrT ../../${datadir}/${PN}-${PV}/${FILENAME} ${FILENAME} might work Mar 19 08:41:34 and with an extra $ before {D} :) Mar 19 08:44:06 i'm not sure that\s what you're supposed to do? Mar 19 08:44:33 nemgti-og: we indeed had an issue with relative paths, and we fixed by using relative paths Mar 19 08:44:44 first relative = absolute :p Mar 19 08:46:49 basically we had ln -sf "%{bindir}/binary" "${D}${bindir}/binarylink" and we changed it to ln -s "./binary" "${D}${bindir}/binarylink" Mar 19 08:49:32 so if it's a link for resources in the same recipe, it's fine you can manage relative links. If it's a symlink across recipes, I doubt trying to do such a thing is recommended. Yocto does some magic on links to detect if it's trying to do some host contaminated for example Mar 19 09:00:51 Hi i'm building mender for Yocto (sumo) using meta-mender and meta-mender-community layers, but I don't understand why bitbake select the version 1.7.1 whereas there is a 2_XX and mender_2.1.2.bb files for e.g Mar 19 09:01:56 clementp[m]: the other versions set DEFAULT_PREFERENCE = "-1" Mar 19 09:02:18 which means they won't be used unless you explicitly tell bitbake to prefer those versions Mar 19 09:03:58 @erbo Thanks you :) Mar 19 09:06:04 clementp[m]: or PREFERRED_VERSION_mender somewhere in your layers Mar 19 09:06:47 qschulz: s/somewhere/in a conf file in your layers, not in the image recipe specifically!/g Mar 19 09:07:18 yes, sorry. machine configuration file, local.conf (and maybe distro conf file?) Mar 19 09:07:50 qschulz: want me to turn some music so you can chant along? :) Mar 19 09:08:23 LetoThe2nd: I summoned you a few days back for the anthem but you were silent Mar 19 09:08:31 qschulz: $REASONS Mar 19 09:11:23 LetoThe2nd: so no, I'm sulking now Mar 19 09:12:54 :) Mar 19 09:27:48 New news from stackoverflow: Bitbake not installing files from recipe to rootfs Mar 19 11:10:30 What's the patch order if I have multiple patches in different .bbappend files in different layers? Mar 19 11:13:21 sstiller: the one in SRC_URI after everything's been expanded :) Mar 19 11:47:17 I have an out-of-tree kernel module, that I cannot seem to get to autoload on boot. My module recipe is a copy of the "hello world" example, but with some other files. In my distribution config file I have added the module to the "KERNEL_MODULE_AUTOLOAD" variable. There are also a few other modules listed there (in-kernel ones) and they get their .conf files created in /etc/modules-load.d/. Mar 19 11:53:34 iceaway: set in your module recipe KERNEL_MODULE_AUTOLOAD = " yourmodulename" Mar 19 11:54:22 iceaway: use the module filename without .ko for this variable Mar 19 11:58:14 New news from stackoverflow: QtCreator Static Analyzer is failing on yocto "gnu/stubs-soft.h" is missing || Handling failed task in Yocto recipe Mar 19 12:16:40 mckoan: thanks! will try that right away. Mar 19 12:28:19 New news from stackoverflow: copy some folders with files into a directory in recipe Mar 19 12:30:03 Hi, im including a package group that includes the package thttpd. so i search true the bb files to find out what variable is including (ARAGO_SDK_PREREQ) it. so i did a ARAGO_SDK_PREREQ_remove += "thttpd" but the package is still getting installed Mar 19 12:30:51 hmw1: you probably did the remove in the image, right? Mar 19 12:31:19 LetoThe2nd yes Mar 19 12:32:15 hmw1: https://twitter.com/TheYoctoJester/status/1217166071519744000 Mar 19 12:32:46 hmw1: besides the fact then, why do you even pull in a group if you don't actually want it. Mar 19 12:35:07 LetoThe2nd: the group has some usable stuff in it. and i don't have the time yet to sift true it and put it in my own layer Mar 19 12:35:32 * LetoThe2nd shrugs Mar 19 12:35:41 its your maintenance nightmare, not mine. Mar 19 13:21:44 Hi. I added file to ${base_libdir} and when running bitbake it says: *ERROR: ... has relocations in .text* Mar 19 13:22:00 Is there any way to make it ignore those relocations? Mar 19 13:24:05 qschulz: thx. That's what I expected. I had a problem with a patch and thought, it was the order. But the patch was just broken. Mar 19 13:25:12 https://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#ref-classes-insane - *textrel:* Checks for ELF binaries that contain relocations in their .text sections, which can result in a performance impact at runtime. Mar 19 13:25:27 Is there a way to remove some "QA" checks? Mar 19 13:27:23 nacknick: See https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-ERROR_QA Mar 19 13:27:36 erbo: too quick for me :/ Mar 19 13:28:31 New news from stackoverflow: Add New Kernel Parameter To Custom Linux Image Generated By Yocto Mar 19 13:28:47 nacknick: but why not fix it? https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-qa-checks Mar 19 13:29:40 either CFLAGS is not passed correctly, or you're missing -fPIC in it Mar 19 13:29:58 and that's usually better than hiding the QA messages :) Mar 19 13:49:54 erbo: qschulz. Thanks for the hints in the morning. I was stucked on meetings after and just now I had the chance to try. The thing with the symliks is solved now. Thanks again! Mar 19 13:50:26 My english sucks, but I guess you understood my message Mar 19 13:51:10 qschulz: I added `INSANE_SKIP_${PN} += "textrel"` to the recipe file and I'm still getting error: `ERROR: do_package_qa: QA Issue: ELF binary '...so' has relocations in .text [textrel]` Mar 19 13:52:18 erbo: You too if you know what to do... ^^^ Mar 19 13:55:13 nemgti-og: what did you end up doing in the dn? Mar 19 13:55:13 nacknick: could it be that the actual package name is not what ${PN} evaluated to? Mar 19 13:55:54 nacknick: no, what I meant, have you actually tried fixing the issue and not hiding it under the carpet? Mar 19 13:56:40 nacknick: otherwise, you need INSANE_SKIP_ here if my_pacakge is not ${PN} as erbo suggested. Mar 19 13:56:58 erbo: the `.so` files are external, I just use the PN's recipe to copy it to the the `/lib` dir Mar 19 13:57:52 what's the name of the package in the error? Mar 19 13:57:56 qschulz: OK I'll try, thanks. BTW, it's not "an issue", the QA checking just identifies it as a problem Mar 19 13:58:38 qschulz: The name of my external library Mar 19 13:59:31 nacknick: if third party prebuilt binary, you won't be able to do anything about the warning except hiding it :/ Mar 19 13:59:55 qschulz: cd "${D}${datadir}/${PN}-${PV}" && ln -s ${BINARYNAME} ${D}${bindir}/${BINARYNAME} Mar 19 14:00:53 qschulz: Yes. That's exactly what I'm trying to do Mar 19 14:01:41 nemgti-og: don't forget to cd back to the previous directory so if someone needs to do an install_append somewhere else they're in the correct directory Mar 19 14:02:25 nemgti-og: I'm wondering if ln -s "../${datadir}/${PN}-${PV}" "${D}${bindir}/${BINARYNAME}" wouldn't have worked? without the cd? Mar 19 14:02:32 is there any short document describes recommendations how to beautifully/correct write recipes and layers? Mar 19 14:03:40 nemgti-og: also, P = ${PN}-${PV} if you want to use that instead :) Mar 19 14:03:50 qschulz: probably true, I don't know why I suggest the cd thing Mar 19 14:03:55 probably pre-coffee Mar 19 14:04:45 nacknick: if you were to be the one compiling this lib, you should be fixing it instead of using INSANE_SKIP but that I didn't know before you told us :) Mar 19 14:05:12 nemgti-og: by correct I meant the default one for do_install (${B} IIRC, but `cd -` should work fine I guess?) Mar 19 14:05:24 qschulz: So what should be the command to skip the textrel check if my library file name is *libofmine.so* ? `INSANE_SKIP_libofmine.so += "textrel"` Mar 19 14:06:42 nacknick: not necessarily. It has to be INSANE_SKIP_ += "textrel" Mar 19 14:07:31 also, I doubt it's legal to use dots in package names Mar 19 14:07:39 qschulz: The lib file is "independent" Mar 19 14:07:57 so `INSANE_SKIP_libofmine += "textrel"` Mar 19 14:08:11 There is no recipe for that library file Mar 19 14:08:19 well there is, you're writing it Mar 19 14:09:21 qschulz: In deed in must add thatextra "cd -". Thanks! Mar 19 14:09:50 nemgti-og: check that cd - actually works. I don't know if it's shell generic :/ Mar 19 14:10:13 qschulz: `INSANE_SKIP_libofmine += "textrel"` does not work Mar 19 14:10:38 nacknick: what is the EXACT error message you have Mar 19 14:10:45 and do NOT censor it Mar 19 14:10:52 ERROR: do_package_qa: QA Issue: ELF binary Mar 19 14:11:03 I can't not censor it :| Mar 19 14:11:04 I want what is in lieu of Mar 19 14:11:13 well, then listen to what I am saying Mar 19 14:11:29 nacknick: otherwise, you need INSANE_SKIP_ here if my_pacakge is not ${PN} as erbo suggested. Mar 19 14:11:57 qschulz: OK. Let me tell you the whole story Mar 19 14:13:17 why do you absolutely not want to try what I'm telling you? I don't need to know the package name, but you absolutely do. You don't know which one it is, perfectly fine. But AFAIR, what you stripped from the error message is actually the name of the package you have to put after INSANE_SKIP_ Mar 19 14:15:04 qschulz: There is a recipe, let's call it 'A'. I build a special library for that 'A' binary file (during the building process of bitbake) let's call it 'liba.so'. Finally I need that the library file (liba.so) will be located in the `/lib` directory of the final image. Is that clear? Mar 19 14:15:52 So I modified the a.bb file to copy the library to `/lib` Mar 19 14:18:56 nacknick: not clear to me /me shrugs. Are you compiling this library with yocto yes or no? yes? fix the compilatioon by adding -fPIC to the CFLAGS or make sure the CFLAGS don't get overriden. No? then you need INSANE_SKIP_ for the *package* which has the lib in it. Packages and recipes are two different things. Mar 19 14:19:00 `ERROR: a-1.0.0 do_package_qa: QA Issue: ELF binary '/home/.../liba.so' has relocations in .text [textrel]` Mar 19 14:19:10 if I change the error to the story above Mar 19 14:19:14 why is it in home now? Mar 19 14:19:43 just the location of the building directory Mar 19 14:19:48 ignore it Mar 19 14:20:29 are you building your library with sources in Yocto? Mar 19 14:20:35 no Mar 19 14:20:47 building it separately Mar 19 14:20:55 why? Mar 19 14:21:12 This is what we do at work Mar 19 14:21:41 Can't change it now... We do it not only for Yocto Mar 19 14:22:00 nacknick: you're giving your layers but don't want to give the sources of your lib I guess? Mar 19 14:22:05 we get binary file and build a library for it that they work together Mar 19 14:22:20 whatever, does nt matter much, was just curious Mar 19 14:22:42 go to the workdir of your recipe Mar 19 14:22:49 ok Mar 19 14:22:54 then? Mar 19 14:22:57 (tmp/work/*/*/a/1.0.0/) Mar 19 14:23:02 then go to packages-split Mar 19 14:23:13 find your lib Mar 19 14:23:23 wherever it is, that's the name of your package Mar 19 14:23:51 Thanks! Mar 19 14:24:21 but that should techincally appear in the Error message you have from bitbake Mar 19 14:24:43 you're right Mar 19 14:24:44 telling you there is relocation in that file Mar 19 14:24:46 I missed it Mar 19 14:24:54 sorry Mar 19 14:25:48 oh my :) Mar 19 14:39:54 I have a custom python extension, a single C file, that compiles with a 3-line setup.py. Mar 19 14:40:05 I'm trying to figure out how to get yocto to build it for me Mar 19 14:42:08 I have a recipe_A-native that gets some files from the web. I created a nativesdk-recipe_A to get those files to be present in a eSDK. I use (in the eSDK) a devtool add -some-git-repo to download an app. That app needs the binaries gotten by nativesdk-recipe_A). Do I still need to add DEPENDS nativesdk-recipe_A in my recipe (the recipe that corresponds to the app i added using devtool)? Mar 19 14:44:33 Because I tried it and it does not work Mar 19 14:44:55 is a "weston_4.0.0.imx.bb" (in a higher priority layer) going to override a "weston_5.0.0.bb" or are they different recipes because of the ".imx." ? Mar 19 14:44:59 ecdhe: does it use the "distutils" pattern? If so there's a distutils.bbclass Mar 19 14:45:53 qschulz: oe-pkgdata-util is a better way to poke at what packages came out of a recipe Mar 19 14:46:11 mauz555: not different recipes, but I don't think that a lower version would be picked because of layer priority. Perhaps something sets a preferred version? Mar 19 14:47:01 erbo: how can I tell if it uses the distutils pattern? Mar 19 14:47:41 ecdhe: can you e.g. call setup.py install to build and install it? Mar 19 14:47:59 erbo: yes, python3 setup.py build_ext Mar 19 14:48:48 Then I think it does, so you can probably use that bbclass Mar 19 14:50:49 ecdhe: See e.g. https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/python/python3-dbus_1.2.16.bb Mar 19 14:51:15 rburton: but for that don't you need the recipe to complete? (but thanks, I always forget about this tool) Mar 19 14:51:48 erbo: only because this would be hard to search, what is the "S" variable in that example? Mar 19 14:54:59 qschulz: After I built the package successfully and found the library in `packages-split/${PN}-dev/`, Why could be the reason that I can't find that library file in the `/lib` directory of the final image? Mar 19 14:55:14 What could* Mar 19 14:55:20 nacknick: because dev packages aren't in the image by default Mar 19 14:55:22 ecdhe: the dir where the sources are put inside WORKDIR Mar 19 14:55:52 ecdhe: by reading the class, where you would execute setup.py build Mar 19 14:56:00 Why it put it in dev packages? And how to solve it? Mar 19 14:56:26 nacknick: because it's a non versioned lib (i.e. not .so.X.Y.Z) Mar 19 14:56:42 and in 99% of the cases, you want versioned libraries in your system Mar 19 14:56:57 and just a symlink from .so to .so.X.Y.Z Mar 19 14:57:26 So if I will change the .so file to .so.1 it will move it? Mar 19 14:57:26 Hello :) I would like to add some ssh keys inside the final rootfs based on the image name, is it possible to do something like that ? The purpose is to have different keys for different projects , so feel free to tell me if it's not the best method :) Mar 19 14:57:54 nacknick: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries Mar 19 14:58:16 nacknick: ideally, since you are building your libs, version them Mar 19 14:58:23 it's very not nice to people to not version it Mar 19 14:58:36 hh ok Mar 19 14:59:16 and if I insist not to version it, is there a way to copy the library to the final image even that it's under -dev dir? Mar 19 14:59:50 follow the link I've given you to make your lib.so part of the normal package Mar 19 15:00:15 when you want to install one -dev package, add it to IMAGE_INSTALL or however you add packages to your image Mar 19 15:00:30 is there some way to run pseudo only to make sync()/fsync() noops? Mar 19 15:00:31 OK. thank you so much Mar 19 15:01:13 nacknick: pleasure, good luck Mar 19 15:02:48 Ninic0c0: or you make one recipe per ssh keys and include the correct one in your project specific image (thinkin out loud) Mar 19 15:05:08 qschulz: don't think. its unneccessary. Mar 19 15:08:03 LetoThe2nd: how would you do it? Mar 19 15:08:26 qschulz: easy. i just don't think. Mar 19 15:09:56 qschulz sound also a good solution but the purpose is to write less recipe as possible ^^ Mar 19 15:11:26 but in fact, i think qschulz is right. if you want to base someting off a specific image, then providing separate recipes is the easiest way. Mar 19 15:11:56 an option would be to have a conglomerate recipe that provides seperate packages which you can then reference. yet thats just a variation on the topic. Mar 19 15:11:56 LetoThe2nd thx for the advice. I wiil do that thx guys! Mar 19 15:14:06 LetoThe2nd: I think we're using it already, but how bad is SRC_URI in an image recipe? Mar 19 15:15:19 qschulz: i personally would say "if it fits your bill, go use it." but that might be just me. Mar 19 15:15:23 LetoThe2nd: then a ROOTFS_POST_COMMAND or something which reads into WORKDIR and take the files from SRC_URI += "file://${IMAGE_NAME}/keys" or something? I'm curious what are the other options Mar 19 15:16:03 LetoThe2nd: and that brings hackish solutions (I've seen a few :) ) Mar 19 15:17:58 qschulz LetoThe2nd for info FILESEXTRAPATHS_append := "${THISDIR}/files/${MACHINE}:" made the trick :P Mar 19 15:18:22 MACHINE -> IMAGE_NAME :S to fast copy/paste ^^ Mar 19 15:18:44 Ninic0c0: where? Mar 19 15:19:43 in the image, i presume. Mar 19 15:19:48 erbo: here's my .bb file: https://pastebin.com/Nr71AGW0 Mar 19 15:20:09 I had actually used python3-dbus as a reference before Mar 19 15:20:27 qschulz inside the recipe Mar 19 15:20:52 as all keys ahev the same name in different project fodler Mar 19 15:20:57 Ninic0c0: image recipe or package recipe? Mar 19 15:21:42 erbo: so I added my python3-cfifo (my simple extension module) to layer.conf. When I build, I get the error: "Package 'python3-cfifo' has no installation candidate" Mar 19 15:22:38 qschulz To tell you all; I have one recipe ssh-keys.bb on my "OS part" with admin access keys. In an other part "application part" I have a ssh-keys.bbappend. the FILESEXTRAPATHS is inside the bbappend Mar 19 15:23:14 The .bb file is in my layer directory, next to other .bb files of the same pattern, which I believe should be globbed by the layer.conf BBFILES description. Mar 19 15:23:18 qschulz so i have the same bbapend (only one in fact) and i have just to keep the same in sub folder containing project name Mar 19 15:23:44 Ninic0c0: you're making a package recipe image specific and that is not great. Mar 19 15:23:56 Ninic0c0: and that works with the image name? machine, sure, distro, sure... but image? i doubt it. Mar 19 15:24:21 qschulz good point :S Mar 19 15:24:29 Ninic0c0: package recipes can only be distro specific (by default), everything agnostic (allarch.bbclass, shell scripts), or machine specific Mar 19 15:24:53 because all of those have a separate work directory Mar 19 15:25:10 so when you change any of those X-specific item, you get a new separate work dir Mar 19 15:25:44 otherwise, you just overwrite every time the recipe work dir with different data and from experience, trust me, that's not great :) Mar 19 15:25:45 qschulz totally agree, i will change that to have several simple recipes and add them inside the correct packagegroup Mar 19 15:26:56 Ninic0c0: you could have multiple recipes with the name of the image in it and then in an .inc included by the image recipe, you do some magic like IMAGE_INSTALL += "ssh-keys-${IMAGE_NAME}" and then it's "transparent" Mar 19 15:27:44 (the name of the image in the package name produced by the recipe*) Mar 19 15:32:53 jpuhlman: I see you had some involvement in this nasty Python pkg_resources sluggishness: https://github.com/MontaVista-OpenSourceTechnology/meta-virtualization/commit/36a5b6fe0b43516d0474e066102a345e31155fb9 Mar 19 15:33:50 I'm trying to track down what, if any, blanket fix might exist to deal with avoiding that slowdown Mar 19 15:35:44 s/involvement/interest/ Mar 19 15:43:01 qschulz Thx for support, all work like a charm <3 Mar 19 15:46:24 Ninic0c0: nice! Mar 19 15:52:24 tgamblin: Mar 19 15:52:37 tgamblin: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/commit/?id=56c404d5d8f76e4fd63c8b96a40b1264e90c0d03 is what caused the list to break Mar 19 15:53:58 tgamblin: No that was just our mirror. I didn't do any work on that one. Mar 19 15:55:25 jpuhlman: ah, ok :( Mar 19 15:55:29 RP: thanks, I'll have a look Mar 19 16:13:15 qschulz one trouble left, is it possible to append a file installed by an other recipe (in my case: authorized_keys) ? ^^ Mar 19 16:13:41 because 2 recipes want to add the keys inside :S Mar 19 16:15:23 Ninic0c0: from another recipe, I don't think so Mar 19 16:16:56 Ninic0c0: but if you don't want authorized_keys from the original recipe, why don't you remove it from the original package? (do_install_append() { rm ${D}/authorized_keys } is one way, the proper I don't know) Mar 19 16:17:29 maybe there's some trickery possible with pkg_post_inst or something but I'm very unfamiliar with those tasks. Mar 19 16:17:51 Ninic0c0: do you need to append or overwrite? Mar 19 16:22:30 RP: https://patchwork.openembedded.org/patch/171069/ you did not pick it into master-next Mar 19 16:23:35 this should help x86_64 world Mar 19 16:26:47 khem, I don't see it in master-next Mar 19 16:28:04 RP: and are you going to pick the bison upgrade and -l patch ? Mar 19 16:28:30 if -l patch is not provided Mar 19 16:28:42 in core then I have to push it imto my fork Mar 19 16:31:11 It looks like populate-volatile.sh doesn't run when using systemd; what's the alternative? Mar 19 16:39:42 volatile-binds ? Mar 19 16:45:59 JPEW: yeah, it's sysvinit only apparently. I was running into this with http://bugzilla.yoctoproject.org/show_bug.cgi?id=13784 Mar 19 16:46:01 Bug 13784: normal, Medium+, 3.1 M3, trevor.gamblin, IN PROGRESS DESIGN , Sysvinit log file creation in /var/log sometimes fails at first boot Mar 19 17:21:06 Hi I'm having the same problem as this person on the mailing list -- https://www.yoctoproject.org/pipermail/yocto/2018-June/041585.html Has anyone developed a fix? Mar 19 17:21:48 I've applied RP's patchset https://patchwork.openembedded.org/patch/138622/ to my build and I still haven't had much luck. Mar 19 17:24:41 It's almost like the do_install_append_arm() function isn't executing, since I have two different copies of fpu_control.h in my lib32 and my lib64 sysroots. The lib64 sysroot contains the fixed fpu_control.h header along side of the fpu_control-64.h header, but the lib32 sysroot contains only the 32bits version of fpu_control.h and no fpu_control-32.h header. Mar 19 17:25:12 I am referring to the do_install_append_arm() function in glibc-package.inc Mar 19 17:28:47 khem: volatile-binds won't work very well unfortunately. I would like the ability to package individual bind files with the package that needs them Mar 19 18:13:41 Ah, systemd has tempfiles.d which does the same thing Mar 19 18:13:52 I bet I can write a script to convert from volatiles to tempfiles.... Mar 19 18:34:45 I'm digging into this. I'm getting the error message that "E: Package 'python3-mymodule' has no installation candidate" Mar 19 18:35:36 Unfortunately, the term "installation candidate" doesn't appear in the yocto mega manual. Mar 19 18:36:10 What does it mean when a recipe provides a package that has no "installation cadidate"? Mar 19 18:42:23 ecdhe: It's not a yocto error message, it's an error message printed by your chosen package manager. Mar 19 18:43:22 ecdhe: usually that means that you don't have any package sources configured. Are you getting this while building an image, or while attempting to install additional packages into an image? Mar 19 18:46:12 Good evening everybody. I have an issue related to the `target_FPU` setting (I think). A compilation fails as follows: `error: build/lib.linux-x86_64-3.7/scipy/fftpack/_fftpack.cpython-37m-arm-linux-gnueabi.so uses VFP register arguments, build/temp.linux-x86_64-3.7/libfftpack.a(cffti1.o) does not`. I experimented with the target_FPU setting and Mar 19 18:46:13 set it to hard/soft/softfp but neither lead to success. I also experimented with the compiling arguments `-mfloat-abi` setting it to soft/hard. Also here no success. Any incentives how to proceed? Mar 19 18:47:09 I also just opened this issue if you wanna comment on that: https://github.com/gpanders/oe-scipy/issues/2 Mar 19 18:49:06 neverpanic: bitbake gives me this error while I try to build an image Mar 19 18:50:34 ecdhe: OK, that means you're trying to install a package that doesn't exist. If the name is correct, this usually happens if the package is empty and thus wasn't created. Mar 19 18:50:58 neverpanic: ahhh, I see from the log that it's actually the output after a lengthy invocation of apt-get in the "do_rootfs" function of my image. Mar 19 18:51:11 neverpanic: I'm trying to get a python extension to build Mar 19 18:51:32 ecdhe: That's expected. Yocto builds images by invoking your package manager to install all those packages. Mar 19 18:52:04 ecdhe: Then I guess your extension wasn't built or packaged correctly. Check the generated package for completeness and consistency before attempting to include it into the image. Mar 19 18:52:11 I'm not downloading its source from github, so SRCURI is just a couple of files. Mar 19 18:52:15 https://pastebin.com/Nr71AGW0 Mar 19 18:53:00 The thing is, if I look at other .bb files, they are pretty simple: they inherit distutils3-base and include a SRCURI Mar 19 18:53:26 Check the do_compile, do_install logs and the packaged files. If you have rm_work disabled, check what's in ${WORK}/image for this recipe. Mar 19 18:54:00 The problem may be in your setup.py, for example. If that installs into /usr/local, or /opt, that would explain things. Mar 19 18:59:40 New news from stackoverflow: stm32mp1 image built with yocto missing header files Mar 19 19:05:09 khem: I'm experiencing an issue that you commented about in the mailinglist a couple of years ago -- https://www.yoctoproject.org/pipermail/yocto/2016-October/032505.html and I added the multilib definition for fpu_control.h but I'm still getting the error. Any ideas? Mar 19 19:16:04 I am not same khem that was 2 years ago :) but let me access my tape archives Mar 19 19:16:16 does this commit fix it ? https://git.openembedded.org/openembedded-core/commit/?id=4690cd8e34fc23de10400cc1c178b2c73c7690c7 Mar 19 19:18:43 khem: Unfortunately that was the first thing that I did... I applied the entire series for that patchset https://patchwork.openembedded.org/patch/138622/. Is there a cleaning task that I need to do after doing that or will just a -ccleanall on that recipe do the trick? Mar 19 19:19:54 just delete tmp/ Mar 19 19:20:19 ah I haven't done that... I will try thanks Khem! Mar 19 19:48:42 neverpanic: I have a bog-standard setup.py, I'm not doing ANYTHING custom. Mar 19 19:49:25 This is frustrating. My recipe doesn't look different from other recipes that work, except I removed HOMEPAGE and I can't find any recipes that bring their own source (instead of downloading from a URL) Mar 19 20:24:54 ecdhe: You may need to move the files into ${S} for disttools to find them Mar 19 20:25:36 ecdhe: file:// in SRC_URI downloads to ${WORKDIR}, not ${S} Mar 19 20:26:28 JPEW: do you have an example of this? Mar 19 20:26:41 S = "${WORKDIR}/dbus-python-${PV}" Mar 19 20:27:04 That's from the dbus example -- it's bascially setting ${S} to the workdir foller Mar 19 20:27:07 *folder Mar 19 20:27:30 ecdhe: Well, a subdirectory of ${WORKDIR}, which is what it usually is Mar 19 20:29:08 There's a bit of a quirky dynamic that happens: ${S} defaults to ${BPN}-${PV}, and it expects this is where source will be extracted Mar 19 20:29:32 S = ${WORKDIR}/${BP} for reference Mar 19 20:30:12 No joy with S = "${WORKDIR}/" Mar 19 20:31:05 perhaps time to disable workdir deletion Mar 19 20:33:04 ecdhe: Ya, try that Mar 19 20:33:19 i'd suggest having the fetcher put the files into a subdir of workdir rather than setting S to workdir Mar 19 20:33:45 kergoth: I had the same idea but not sure how to do it Mar 19 20:34:29 two options, put the files in a subdirectory next to your recipe and add that directory to SRC_URI instead of the files Mar 19 20:34:39 that's the easiest, ex add a 'src' dir, then file://src/ Mar 19 20:34:50 alternatively, there's a url parameter to change the destination, let me check Mar 19 20:36:25 https://github.com/openembedded/bitbake/blob/master/lib/bb/fetch2/__init__.py#L1510 Mar 19 20:36:45 file://setup.py;subdir=src Mar 19 20:40:20 thanks kergoth Mar 19 20:40:32 np Mar 19 21:51:42 armpit: aloha. Mar 19 22:00:56 howdy darknighte Mar 19 23:07:28 Hello, is there a recommended strategy for installing python packages that use pipenv to manage their dependencies with a Pipfile.lock? Most python package recipes appear to use the pypi and setuptools3 classes, neither of which seem to respect Pipfile.lock. Mar 19 23:46:53 khem: sorry, I did mean to get those **** ENDING LOGGING AT Fri Mar 20 02:59:57 2020