**** BEGIN LOGGING AT Thu Apr 09 02:59:57 2020 Apr 09 07:02:53 good morning! what is the correct way to install prebuilt binaries into the rootfs without having to deal with auto-detected runtime dependencies? Apr 09 07:04:43 @nameclash: pebuild packages or just binaries? Apr 09 07:05:38 actually it's a directory tree of binaries, cfg etc, so basically a package Apr 09 07:06:00 @nameclash: hmm but not a .deb .rpm .pkg package? Apr 09 07:06:09 no... Apr 09 07:06:36 it is a 3rd party suite of ui testing tools I built from source Apr 09 07:06:51 nameclash: I'd say to use the bin_package bbclass, and then override RDEPENDS_${PN} to clear it Apr 09 07:07:02 @nameclash: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/bin_package.bbclass?h=dunfell Apr 09 07:07:16 nameclash: If you have the source, why not build it in Yocto though? :) Apr 09 07:07:19 @nameclash: but this can get tricky ;) Apr 09 07:07:45 @nameclash: yes exactly, why don't you build it? Apr 09 07:09:25 the project itself is qt based, but they're using their own awesome commercial binary build engine so I had no chance building it from source within yocto Apr 09 07:09:53 I tried it but failed miserably Apr 09 07:10:33 @nameclash: hehe I think I know what stuff you are talking about ;) Apr 09 07:11:36 they're using their own homebrew build system that uses qmake internally and I got stuck somewhere 5 yards before the finish line Apr 09 07:12:33 then I said screw it, just throw in the binaries (can't be that hard, huh?) and then this pesky auto dependency checker got me Apr 09 07:12:39 @nameclash: if you can bundle it somehow as a package, you could use, as mentioned above, the bin_package class Apr 09 07:12:46 @nameclash: https://www.yoctoproject.org/pipermail/yocto/2019-February/044277.html Apr 09 07:13:21 @nameclash: otherwise you can write your own recipe, which just copies files over where they belong to Apr 09 07:13:37 I did that Apr 09 07:14:34 but some of the binaries link againist libQt5Declarative.so and bitbake detects that and says I have nothing that provides this Apr 09 07:14:59 although I have qt-5 in my image Apr 09 07:16:00 I dont understand it. but I guess such things may happen if you're not building everything from scratch alltogether Apr 09 07:16:06 @nameclash: that's a packaging problem Apr 09 07:16:47 @nameclash: you did not just copy over stuff, I guess, but more in your recipe Apr 09 07:19:03 I think the bin_package class handles tarballs as well Apr 09 07:19:46 nameclash: Have you tried just overriding RDEPENDS_${PN} = "" in your recipe? Apr 09 07:20:22 or maybe the autodepenencies are added after reading RDEPENDS? Apr 09 07:20:22 first, I put those 3rd party sources in a repo and wrote a recipe for it to build it from source. when I got stuck with qmake I gave up and decided to add a tarball with the artifacts I had built by hand and changed the recipe to just untar it in do_install. That gave me a bunch of uid warnings which I didnt like so I unpacked the tarball, put the files in the repo and then just copied them into place in do_install Apr 09 07:21:02 @erbo: yes this could be the case. Apr 09 07:21:43 that gave me 3 warnings about missing dependencies to libQt5Declarative.so, so I INSANE_SKIPPED file-rdeps and that actually made the recipe succeed, but RPM got me on do_rootfs Apr 09 07:22:08 that's the whole story Apr 09 07:22:54 I'll try something more now, just came in my mind and then I'll look into the links you sent Apr 09 07:23:01 thx guys Apr 09 07:23:09 I'll ping back Apr 09 07:25:19 Hi all, I have an issue with bitbake data store manipulation, here is a minimal example: https://pastebin.com/EqNw978C Apr 09 07:26:38 myfunc task is using setvar and check that it's applied and myfunc2 (another task running after myfunc) is trying to check it. And it's not working, here is the log: https://pastebin.com/A99f4n1G Apr 09 07:27:46 myfunc is "OK" but we see in myfunc2 log that setvar was not correctly applied. Apr 09 07:28:13 my goal is to modify SUMMARY/DESCRIPTION/PV from git repo files. Apr 09 07:28:18 Any idea how to fix this? Apr 09 07:30:28 @xavier: Not sure if DESCRIPTION behaves differently from other variables ;) Apr 09 07:30:36 I would try a non system variable Apr 09 07:30:46 and I would also try in my task instead of set Apr 09 07:31:06 VAR="pouet" Apr 09 07:31:08 or so Apr 09 07:31:11 does this work? Apr 09 07:31:33 I don't think you can modify variables and have it stored between tasks, IIRC Apr 09 07:32:48 I tried it with some success with something like this: SUMMARY="${@myfunc(d)}" but it's not "stable" Apr 09 07:33:23 Depending of the build order/connection speed, sometimes it worked, sometimes not (apparrently bitbake is not expecting variable parsing to take some time) Apr 09 07:33:51 you also didn't clearly define what should run first Apr 09 07:34:55 try _prepend _append Apr 09 07:34:56 RobertBerger I tried with a non bitbake variable without success: https://pastebin.com/1f4ccmvA and output https://pastebin.com/ztUxtZcB Apr 09 07:36:12 RobertBerger order is defined with addtask isn't it? and it appears to be correctly working and is not the issue here (I can check it with deb package info that is using DESCRIPTION) Apr 09 07:36:31 well with before and after Apr 09 07:36:36 but that is not precise Apr 09 07:37:07 you could try instead of myfunc2 Apr 09 07:37:15 myfunc_prepend Apr 09 07:37:23 sorry append Apr 09 07:37:35 then the second one will run after the first Apr 09 07:38:02 and take out the second before/after line Apr 09 07:38:23 xavier_deschuyte: I think changes to the datastore is only valid inside the task Apr 09 07:39:19 RobertBerger even if order issue is not the issue here (you clearly see that myfunc2 is executing after myfunc) so task order is OK. But with your suggestion it's not working neitherrr Apr 09 07:39:47 erbo : yes that's what I observe here, but that's strange because that's not what the documentation is stating Apr 09 07:40:05 hehe - let me have a look ;) Apr 09 07:42:23 erbo https://www.yoctoproject.org/docs/2.3.4/bitbake-user-manual/bitbake-user-manual.html section 3.5.5 Apr 09 07:42:59 https://www.yoctoproject.org/docs/2.3.4/bitbake-user-manual/bitbake-user-manual.html#anonymous-python-functions Apr 09 07:45:09 RobertBerger thanks for the help! my goal is to change the DESCRIPTION field of the generated deb. I saw in the package_deb class that it's using getvar.. I assumed that using setvar before would do the trick Apr 09 07:46:07 I am busy right now, but will definitely try to see what's going on on my mission to demystify bitbake ;) Apr 09 07:46:20 so I am collecting such things and solutions to it Apr 09 07:46:59 Why don't you just write DESCRIPTION="das;dkas;ldk" in your recipe? Apr 09 07:46:59 xavier_deschuyte: yeah I recall having troubles finding this info too. And regarding the anonymous function, maybe those can modify but not regular tasks Apr 09 07:48:29 erbo yes, anonymous is working as described. But then, I am facing issue with the bitbake task scheduler (because I need to access git files, I need to fetch/unpack and it takes time and apparentlty parsing is not supposed to "take time" Apr 09 07:48:59 RobertBerger : because basically I want to set description with a git file content Apr 09 07:49:22 OK an addition issue ;) Apr 09 07:57:34 I suppose that python tasks receive a "copy" of the global context. Would be nice to get a way to access global context Apr 09 08:05:27 OK. By putting logs in a python anonymous function. I understood my issue: each bitbake task trigger a recipe parsing. So I assume my setvar is working but is wiped by the next recipe parsing Apr 09 08:07:21 xavier_deschuyte: Each task has it's own context. Are you trying to set a value in one task and then get it in another task? Apr 09 08:07:40 Here is an example: https://pastebin.com/is1rFXA9 producing https://pastebin.com/41PtwKKR Apr 09 08:08:44 xavier_deschuyte: It's not technically parsing, more like execution of the code that was already parsed Apr 09 08:08:48 paulbarker my goal is to set deb package attribute (DESCRIPTION for example). So without modifying bitbake files, only my recipe. Apr 09 08:09:03 What do you mean by "bitbake files" Apr 09 08:10:01 package_deb.class Apr 09 08:10:59 I'd recommend avoiding package_deb and using either ipk or rpm packages instead as they're much better supported Apr 09 08:11:48 paulbarker I need to get deb packages (I generate an APT repository) Apr 09 08:12:17 Can someone shine a light on the use of LICENSE_EXCLUSION in base.bbclass? It is only used in package.bbclass and the logic is broken for multilib so I'd like to fix it. The easiest is just to axe it but mmmm maybe there's a reason :) ? Apr 09 08:12:24 and using rpm, ipk or whatever would not fix my issue. I need to set a bitbake variable from a git file Apr 09 08:14:53 xavier_deschuyte: I don't know any way to do that neatly, you may be better off asking in an email to the list Apr 09 08:17:01 paulbarker I double checked my test and I think your solution could be the correct one "append/prepend". Apr 09 08:17:25 But in fact when I said it was not "working" digging into that means it was simply not executed Apr 09 08:17:55 I simply declare the task this way: `python do_myfunc_append() {` Apr 09 08:18:34 but it is not executed Apr 09 08:19:00 but I hope that prepend/append are executing without "reparsing" and so context would be the same and it would work Apr 09 08:19:54 prepend/append fragments are joined together before the code is executed so that should work Apr 09 08:20:33 but my syntax is not working Apr 09 08:20:41 Let me check quickly Apr 09 08:20:48 thanks! Apr 09 08:22:00 I used that: `do_myfunc[postfuncs] += "do_myfunc_append"` that did the trick and context is preserved but would be interrested to fix it with append/prepend Apr 09 08:22:02 What's that `BB_DONT_CACHE` doing there? Apr 09 08:22:27 just a test... I was afraid that bitbake was "caching parsing" of summary or similar Apr 09 08:22:37 but it's not the issue here Apr 09 08:27:22 xavier_deschuyte: Your append should work. Check what appears in `tmp/work////temp/run.do_myfunc` Apr 09 08:34:30 ugh... it seems I can't fix my multilib issue without breaking something else.... Will open a bug then :/ Apr 09 08:35:33 qschulz: 99 little bugs in the code, 99 little bugs in the code. Take one down, patch it around, 117 little bugs in the code Apr 09 08:37:31 paulbarker: but it's kinda of an issue. I fall in a side effect of PACKAGES having lib32- prepended later than LICENSE_EXCLUSION being computed. If I fix that, all packages depending on this side effect will actually break and there are more than the one impacted by the current behavior.... Apr 09 08:37:55 qschulz: ouch Apr 09 08:38:23 paulbarker: yeah you don't say :) Apr 09 10:02:44 paulbarker : prepend is not working neither for my specific case because deb package generation uses "execs" so I am trying right now to put a task after the deb build to edit the control file. Not that ugly in the end. Apr 09 10:38:47 Hi guys. Im building poky 3.0.2 with meta-raspberrypi and targetting raspberrypi4-64. Any idea why my TARGET_FPU is empty? Machine raspberrypi4-64 uses tune-cortexa72 from OE. if I understood correctly, cortex-a72 should have vfpv4 support? Apr 09 10:42:36 paulbarker: if you're interested: http://bugzilla.yoctoproject.org/show_bug.cgi?id=13865 Apr 09 10:42:38 Bug 13865: critical, Undecided, ---, unassigned, NEW , mutlilib results in, if package has incompatible license, pulled in rootfs or if package has compatible license, blacklisted from RDEPENDS/rootfs Apr 09 10:47:36 Hopefully I'm not drowning people in details in this issue, I've been pretty bad lately at explaining things. Let me know if there is some rephrasing to do :) Apr 09 11:18:11 qschulz: that bug sounds horrible :( Apr 09 11:18:25 qschulz: Overly detailed bugreports are much better than missing out some details Apr 09 11:18:26 * RP wishes we could just drop multilibs and imcompaible_license Apr 09 11:19:37 RP: yeah, I'm sorry, always me finding out the weird licenses corner cases :/ Apr 09 11:21:25 RP: honestly, if we can ditch LICENSE_EXCLUSION in base.bbclass without any repercussion, I think it should be possible to handle the packaging blacklist directly in package.bbclass. It's just that I'm not sure there isn't something I'm missing :/ Apr 09 11:22:52 RP, qschulz: The way LICENSE_EXCLUSION is used does look really messy. I'm happy to take that bug and see if I can come up with a better way of doing it. No guarantees I'll get to it for a week or three though Apr 09 11:37:32 paulbarker: wait for the goodies, I forgot to add some info to the bug Apr 09 11:42:21 New news from stackoverflow: Why would a yocto patch fail under devtool but not during a normal build? Apr 09 13:17:13 Has anyone had any luck importing a .wic.vmdk to EC2? Annoyingly, they only allow a select subset of OSs Apr 09 14:00:28 RP: the musl multilib v2 change I sent lets not consider it, its too close to release Apr 09 14:02:11 RP: secondly, the change you are proposing is going to disable a valid usecase ( 64bit kernel + 32bit userspace-only ) which can be built today for musl bitbake lib32-core-image-minimal Apr 09 14:02:59 RP: so I think if you turn this into a parse warning like we have musl+systemd then perhaps that will be idea Apr 09 14:03:01 ideal Apr 09 14:16:29 paulbarker : I managed to get my stuff done by creating a new task after deb creation that modify the control file inside it and replace Description. Not the cleanest stuff, but "OK" Apr 09 14:38:44 how do I properly set up a recipe that uses qmake? Apr 09 14:39:40 nameclash: inherit qmake should be a good start (I don't know much more :) ) Apr 09 14:40:47 I have TOOLCHAIN_HOST_TASK_append = nativesdk-packagegroup-qt5-toolchain-host which makes qmake and the mkspecs available in the sysroot-native Apr 09 14:42:43 In the recipe I depend on qtbase-native and the recipe's sysroot gets populated with qmake, however when I try to run ${WORKDIR}/recipe-sysroot-native/usr/bin/qt5/qmake in do_configure(), qmake complains not being able to find its specs... Apr 09 14:43:14 Hey, just to confirm: I'm experimenting with a different kernel version. Thus I changed `PREFERRED_PROVIDER_virtual/kernel` and `PREFERRED_VERSION_linux-mainline` and then started rebuild with bitbake. It seems to kick off linux-mainline kernel compilation but only at task 5600 (plus/minus) of 5944. I would have expected that a change of the kernel Apr 09 14:43:14 would require a much deeper recompilation of dependencies... Apr 09 14:43:45 qschulz I'll look into that, thanks Apr 09 14:43:57 Do I have to enforce recompilation or something? Apr 09 14:44:25 emrius: not really, mostly kernel modules and the image depends on the kernel sources IIRC. Anything that needs header files from the linux kernel are taken from linux-libc-headers Apr 09 14:44:58 qschulz great! Thanks for the quick reply Apr 09 14:49:03 nameclash: TOOLCHAIN_HOST_TASK etc is pointless and meaningless in a normal recipe. you just want inherit qmake. Apr 09 14:49:22 sorry, inherit qmake5 Apr 09 14:50:41 rburton, thanks Apr 09 14:51:01 TOOLCHAIN_* are all about controlling what goes into the SDK Apr 09 14:51:20 if you can share where you thought that would be the solution then maybe we can ensure the docs are not misleading Apr 09 14:51:23 ok and that's implicitly handled by inherit qmake5 I guess Apr 09 14:51:52 just read the class: it adds depends and defines configure/compile/install tasks Apr 09 14:52:09 if you're talking recipes you are *not* using a SDK Apr 09 14:53:07 that makes sense Apr 09 14:54:01 with that information, and looking into the qmake classes I think I should inherit qmake5_base, not qmake5 Apr 09 14:54:31 the project that I'm trying to build uses its own configure script to setup the build Apr 09 14:55:04 it expects the path to qmake be passed as argument Apr 09 14:55:28 so I need to override the tasks defined in qmake5 Apr 09 15:12:18 So, after changing the kernel version bitbake started to compile as expected but ran into a problem. The `package-core-boot` still requires the previous kernel version. Do I have to modify that recipe or is maybe some cache dirty or something else? Apr 09 15:12:54 The interested reader may also consult my issue on SO :) https://stackoverflow.com/questions/61124345/upgrade-yocto-linux-kernel-fails Apr 09 15:13:04 New news from stackoverflow: Upgrade yocto linux kernel fails Apr 09 15:24:48 emrius: bitbake packagegroup-core-boot -e | less Apr 09 15:25:00 if that works, try to find where kernel-image-4.19.63 is coming from Apr 09 15:30:58 qschulz thanks again! I'm on it... but actually it looks fine. Apr 09 15:31:33 Just to make sure. There are two places a hint on the kernel version 4.19% pops up in the environment. Apr 09 15:31:48 It looks about like this: Apr 09 15:31:55 # set? /home/marius/mender-qemu-warrior/build/../sources/meta-sunxi/conf/machine/include/sunxi.inc:16# "4.19%" Apr 09 15:32:02 grr.... hang on Apr 09 15:32:38 https://paste2.org/c7YKsyx9 Apr 09 15:33:11 Do I interprete the questionmark behind set correctly as: "Set the value if it hasn't been set before? Apr 09 15:34:54 emrius: yes, ??= is weaker than ?= which is weaker than = Apr 09 15:35:31 I think the place above where the version also appears basically is the same command: https://paste2.org/3gEpN64G Apr 09 15:36:06 emrius: that was not my original question, let me rephrase Apr 09 15:36:09 qschulz ok, as I thought then. those are the only two places that kernel version appears in `bitbake packagegroup-core-boot -e | less` Apr 09 15:36:29 emrius: package-group-boots is requiring kernel-image- Apr 09 15:36:33 so it has to come from somewhere Apr 09 15:36:44 ah alright. Now I got it Apr 09 15:36:50 which variable holds kernel-image that is used in packagegroup-core-boot Apr 09 15:36:52 thanks. I'll dig into that... Apr 09 15:37:01 alrighty Apr 09 15:38:38 So, there is `IMAGE_INSTALL=" kernel-image kernel-devicetree networkmanager networkmanager-nmtui mender"` and `MACHINE_ESSENTIAL_EXTRA_RDEPENDS=" kernel-image kernel-devicetree"` ... *scratching head* Apr 09 15:39:13 khem: I agree, your v2 change can be for 3.2? For 3.1 its probably too late to do anything Apr 09 15:40:36 mmm... What can I do with that information? Sorry for asking potentilly silly questions... I'm a little lost :/ Apr 09 15:41:25 emrius: did you actually run bitbake -e packagegroup-core-boot or bitbake -e myimage? Apr 09 15:41:39 emrius: I don't know what I'm doing as well, just looking for leads :) Apr 09 15:41:51 `MACHINE=opi-zero-adxl bitbake packagegroup-core-boot -e | less` that one Apr 09 15:42:46 and you have IMAGE_INSTALL there? Apr 09 15:42:55 qschulz I'm pretty sure you know much better what you are doing than I what I am doing :) Apr 09 15:43:26 oeehm yes... Apr 09 15:43:31 no good? Apr 09 15:46:10 wait... are you setting your IMAGE_INSTALL in local.conf? Apr 09 15:46:36 no Apr 09 15:48:27 emrius: where is IMAGE_INSTALL coming from? (read the few lines above the line starting with IMAGE_INSTALL). Most prob not the issue but i'm curious now :) Apr 09 15:50:08 I define an image the inherits core-image. Its coming in there: https://paste2.org/GDUAIfHY Apr 09 15:51:47 I think I followed one of the live coding sessions from LetoThe2nd there. But I'm not 100% sure anymore... Lots of trying ... Apr 09 15:52:15 no, in bitbake -e packagegroup-core-boot | less, I don't have it Apr 09 15:53:00 Ok. That's good to know! At least I know now that it shouldn't be in there Apr 09 15:54:08 Well I don't know, that's why I'm asking :) Apr 09 15:56:00 The problem might just have vanished. Besides the image recipe I had another one (under a different name) with some other features. I just deleted that and the compilation finished... `IMAGE_INSTALL` is still in there btw :) Apr 09 15:56:38 * qschulz shrugs Apr 09 15:56:40 Probably something got tainted from there. A little unsatisfying not to understand where it came from. But at least it seems to be cured now. Apr 09 15:56:53 can you give me the lines above IMAGE_INSTALL Apr 09 15:57:07 sure one sec Apr 09 15:57:33 of the recipe or the environemtn? Apr 09 15:57:59 bitbake -e packagegroup-core-boot you said there is an IMAGE_INSTALL in there Apr 09 15:58:11 yes. Ok Apr 09 15:58:48 https://paste2.org/wU5mFcXk Apr 09 15:59:06 and FYI, you might want to create your own machine inherit the Allwinner one you're building now where you would set mahcine specific variables instead of in local.conf, for example PREFERRED_PROVIDER_virtual/kernel and PREFERRED_VERSION_linux-mainline :) Apr 09 15:59:42 I actually have that. The machine is `MACHINE=opi-zero-adxl` Apr 09 15:59:59 I just tested in local.conf. Once things work there I usually deploy them elsewhere Apr 09 16:00:33 great! remove the IMAGE_INSTALL from that machine then :) Apr 09 16:01:34 mmmm nevermind, it seems to be in the official example in the docs... Weird Apr 09 16:01:35 okay. hmm... alright... I figured that was kinda important to have there. But probably I just copy pasted something from somewhere else :/ Apr 09 16:02:05 Ok. I probably have it from there when :) Apr 09 16:02:20 Anyway. I removed it. It compiles just fine. All good :) Apr 09 16:02:38 I'd have thought MACHINE_ESSENTIAL_EXTRA_RDEPENDS or something was more the way to go but it seems I've missed something :) Apr 09 16:03:03 Thanks a lot for your time!!! I'll add you on my "people I owe beer when they are in Berlin" list with a second dash (y) Apr 09 16:03:06 emrius: the line you had for kernel-image and kernel-devicetree is to install the kernel and the devicetree in the rootfs (most likely in/boot) Apr 09 16:03:18 IIRC Apr 09 16:03:30 ah ok Apr 09 16:04:06 emrius: my pleasure, I hope it's not crazy in Berlin right now. Take care. Week-end for me. Happy easter for those who're celebrating/having the day off. Apr 09 16:04:58 Well, it's alright here. I'm just gonna work till end of easter. It's basically the most exiting thing to do at the moment here. Everything is closed. Apr 09 16:05:09 and then continue working... Apr 09 16:05:22 Enjoy easter and weekend! Apr 09 16:07:07 BTW: I actually had commented the `IMAGE_INSTALL_append` line in my machine configuration as follows: `# Is the following configuration best placed here?` Apr 09 16:07:28 The obvious answer is `No` =D Apr 09 16:11:33 almost there with the build but qmake still not able to find linux-oe-g++ config Apr 09 16:12:58 all relevant paths for qmake seem to be written by qmake5_base to a qmake config file with the path to it exposed as OE_QMAKE_QTCONF_PATH Apr 09 16:13:26 however, I'm not sure how to pass this config file to qmake... Apr 09 16:14:01 I've uploaded some additional info on it: Apr 09 16:14:12 my recipe: https://pastebin.com/JgY31RyJ Apr 09 16:14:25 the bitbake error: https://pastebin.com/PGRVydKj Apr 09 16:15:02 the output of the built projects configure script (includes qmake output): https://pastebin.com/PAi0V32X Apr 09 16:15:34 any pointers on how to pass OE_QMAKE_QTCONF_PATH to qmake highly appreciated Apr 09 18:18:22 Is it possible to use SYSTEMD_SERVICE_${PN} to enable a service provided by another package? Apr 09 18:19:33 For example, if all users of a package do not necessarily enable to the service in the same way. Apr 09 18:40:14 xyzzy42. you could hack it into local.conf, but you can always bbappend the recipe in your layer and enable what you want. Apr 09 18:42:17 zeddii, so only a recipe which provides the service file is allowed to enable it? Apr 09 18:43:50 New news from stackoverflow: Hardware acceleration RPI4 FFmpeg Apr 09 18:49:57 xyzzy42, it's a recipe variable like anything else. Apr 09 18:50:25 so correct, you can't cross the boundry to muck in one recipe/package from another. Apr 09 18:50:35 zeddii, it's not the variable's scope in the recipe, but finding the service file Apr 09 18:50:57 zeddii, e.g., foo.bb contains SYSTEMD_SERVICE_foo += "bar.service" Apr 09 18:51:06 still a variable Apr 09 18:51:29 suppose bar.service is not a file provided by foo.bb, but by bar.bb Apr 09 18:51:48 then you've got some messed up packaging Apr 09 18:52:05 if you are trying to provide service files for another recipe/packages from another. Apr 09 18:52:37 but beyond that, it appears it can't be done Apr 09 18:53:01 building foo will complain that it can't fine bar.service Apr 09 18:53:19 right, because it is looking in its own sysroot for it. Apr 09 18:53:48 and adding bar to DEPENDS should/will put the bar.service file in the sysroot Apr 09 18:55:13 only if you deploy it from that dependent recipe (and have it in a installed directory that is deployed). You can find the list of directories that are put into the recipe specific sysroot via DEPENDS in the code itself, or docs. I don't recall them all off the top of my head. Apr 09 18:55:16 and in the end, what happens is the foo package postinst script will call "systemctl enable bar.service", which will work perfectly well, provided it has the rdepends to ensure bar is installed Apr 09 18:57:19 I see the file in tmp/work/arch/foo/version/recipe-sysroot/lib/systemd/system/bar.service Apr 09 18:57:48 so it seems like it is in the sysroot, no? Apr 09 18:58:30 yep, but if you want to package it in that 2nd recipe, you have to copy it, and make sure it is packaged so the ontarget enable will have it. Apr 09 18:58:49 oh no, I don't want to package it. Just enable it. Apr 09 18:59:14 well, the .service file has to end up on the target. I'd not recommend providing it in one package and enabling it in the other. Apr 09 18:59:45 why not, if the package which enables it depends on the one that provides it (because it uses the service) Apr 09 19:00:52 the service is a templated service, so the provider of the service is basically saying you can enable this in different ways and it's not my job to figure them out. Apr 09 19:00:54 you are splitting the logic over multiple recipes, you can do whatever you want, I'm just saying that it might bite you later. Apr 09 19:01:18 you really should have a distro feature, or similar to control coordinated efforts like that. Apr 09 19:01:52 the yocto mega manual should cover some of this. but again, you can do whatever you want, but expect to have to work around the default way that the build and classes work, since that isn't the normal the case. Apr 09 19:02:11 or watch some of LetoThe2nd's youtube things, he goes over some of those concepts IIRC. Apr 09 19:02:19 what I'd like to be able to do is choose what interfaces a templated service is started on. Kind of the whole point of templated services is you don't need to know when you create the service what it might get attached to. Apr 09 19:03:29 so I'd to be able to have one image that enables interface X, but another image that does not enable it Apr 09 19:04:11 if I make a debug-mode package, which has the "systemctl enable debug-service@ttyS1.service" postint, then I can include or not include that package in an image Apr 09 19:06:08 I think this is really the main idea behind templated unit files. If we knew exactly what bar@.service would be enabled for when we built bar, we'd just hardcode %i in bar.service Apr 09 19:07:23 but we don't want the restriction, so we create bar@.service which uses %i, and let someone else enable bar@instance.service to provide the value(s). Apr 09 19:11:37 zeddii, regardless of the should or why, it doesn't appear to be possible, even if the service is in the sysroot, as only services deployed by the recipe are allowed. Apr 09 19:14:32 right. I can't say that I know the systemd bbclass really well, but right, it will only look in specific directories for the service files. you'd need to modify it, add your own task, or otherwise, augment it to look in that sysroot directory to find and generate the ontarget snippet. Apr 09 19:15:21 gotta bolt for coffee. good luck! Apr 09 19:30:20 zeddii, occurred to me that "package foo needs service bar" is very common. There are tons of things which involve multiple services. But how it's usually done is foo owns foo.service, which Wants/After bar.service Apr 09 19:31:35 i.e., if foo needs a service, it uses the systemd unit ordering and dependency system to describe this in relation to another service. Apr 09 22:14:33 New news from stackoverflow: Run Raspberry Pi Zero W image in qemu Apr 09 22:31:41 * paulg has a pi-zero W that has been around for several years that hasn't seen an electron of use. Apr 09 22:39:30 fortunately I think it was only like $13 CDN. Apr 10 00:51:04 I have added a framework of CPP in yocto - https://github.com/ipkn/crow and now I want to add the CROW in SDK but I want all the headers to be combined using the script - https://github.com/ipkn/crow/blob/master/amalgamate/merge_all.py https://github.com/ipkn/crow/blob/master/amalgamate/merge_all.py Apr 10 00:51:32 How can I do that in the yocto recipe so that it merges all the headers in SDK **** ENDING LOGGING AT Fri Apr 10 02:59:57 2020