**** BEGIN LOGGING AT Wed Dec 30 02:59:57 2020 Dec 30 04:03:09 I am trying to enable systemd and it seems to be working but I get this error when trying to enable a service to auto start: root@webapp:~# systemctl enable php-fpmSynchronizing state of php-fpm.service with SysV service script with /lib/systemd/systemd-sysv-install.Executing: /lib/systemd/systemd-sysv-install enable php-fpmFailed to execute Dec 30 04:03:11 /lib/systemd/systemd-sysv-install: No such file or directory Dec 30 04:04:12 The issue seems to be the 2nd line, but without that line it seems to not work, DISTRO_FEATURES_append = " systemd"DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"VIRTUAL-RUNTIME_init_manager = "systemd"VIRTUAL-RUNTIME_initscripts = "systemd-compat-units", this is for dunfell branch Dec 30 06:39:38 ikkysleepy: yupp haVING A REALLY HARD TIME DOING AN ALL-IN-ONE SIMPLEX ON BARE METAL EVEN Dec 30 06:39:46 ooops sorry caps Dec 30 06:40:26 figured it out, I needed just to do these 2 lines and not all 4: DISTRO_FEATURES_append = " systemd"VIRTUAL-RUNTIME_init_manager = "systemd" Dec 30 09:23:58 hi, using yocto core-image customized. I just upgraded from thud to dunfell. I don't have "clear" command anymore Dec 30 09:24:26 I tried that in thud and yocto build env: oe-pkgdata-util find-path /usr/bin/clear Dec 30 09:24:32 but it's not found Dec 30 09:25:01 I tried increasing "ALTERNATIVE_PRIORITY" of coreutils without success Dec 30 09:25:34 what am I missing? Dec 30 12:40:18 howdy Dec 30 12:43:03 Is it somehow possible to depend on do_deploy of virtual/kernel, in a fire and forget type of approach, that isn't affecting do_package ? Dec 30 12:44:59 hnje: You can add the dependency to a different task, e.g. do_build Dec 30 12:46:14 hnje: See for example Raspberry Pi we add various task dependencies to `do_image_wic`: https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/include/rpi-base.inc#L125 Dec 30 12:51:41 paulbarker: That is what i've done previously, but the issue is that the kernel's dependencies is picked-up during do_package of my recipe. One of these depencies is an image which doesn't have a package manifest Dec 30 12:52:18 So I get a warning 'do_package: Manifest manifest-x86_64_x86_64-nativesdk-initramfs.packagedata not found' Dec 30 12:53:25 hnje: do_package shouldn't be called for an image. Does your image recipe inherit the image class? Dec 30 12:53:37 Yes it does Dec 30 12:54:17 That's weird. I'd need to see the full bitbake output to make any suggestions then Dec 30 12:54:26 So it is do_package for my 'kernel-fitimage-initramfs' recipe, which packs the fitimage into a package. Dec 30 12:55:29 It is only a warning, but I would like to get rid of it Dec 30 12:56:40 Right, so that isn't a warning for the image recipe Dec 30 12:57:48 Nope, the warning is generated during do_package of kernel-fitimage-initramfs, but only when i add do_deploy of virtual/kernel to the list of dependencies Dec 30 12:58:06 It's a strange warning as it suggests there is a dependency on a nativesdk recipe Dec 30 12:58:28 How are you currently adding the dependency? Dec 30 12:58:28 but without the dependency the files needed by the recipe (located in deploy) might be missing Dec 30 12:59:33 do_build[depends] += "virtual/kernel:do_deploy" Dec 30 13:02:02 That would only ensure that the kernel has been deployed before do_build runs. So there's no guarantee it has been deployed before do_package, do_install, do_compile, etc run. Dec 30 13:02:23 The dependency should be added to the first task in the recipe which needs those files Dec 30 13:13:25 paulbarker: yeah ofcourse, but that aside, i still get the warning :) Dec 30 13:20:45 paulbarker: https://gist.github.com/henriknj/d90b0f6e9679d8def9f1b097efcea002 Dec 30 13:23:49 paulbarker: If you look at 'pkgdata-sysroot', the image 'initramfs' with all of its deps. Dec 30 13:27:00 hnje: I recommend simplifying that to start with. Drop all the `noexec` lines, drop `INHIBIT_DEFAULT_DEPS`, set the dependency on `do_install` not `do_build` Dec 30 13:27:06 See if the warning still occurs after that Dec 30 13:31:44 You may need to run `bitbake -g kernel-fitimage-initramfs` and see if you can spot an nativesdk dependency Dec 30 13:35:09 None whatsoever Dec 30 13:35:43 This used to work, but seems like the warning has been casued by https://patchwork.openembedded.org/patch/162651/ Dec 30 13:41:36 Leaving out the call to package_prepare_pkgdata does indeed 'solve' it.. meh Dec 30 13:55:12 RP: maybe you have an idea? Dec 30 14:23:46 rburton: awesome Dec 30 15:02:25 paulbarker: by explicit deleting the do_packagedata of my image recipe the warning is gone. The image.bbclass only sets up the noexec flag Dec 30 15:12:57 hnje: using do_build there is probably fairly meaningless, the kernel would usually be deployed anyway. Are you sure that warning is coming from that line? Dec 30 15:14:17 I'm wondering why image.bbclass doesn't inherit nopackages, I'm sure there was a good reason but can't remember it atm... Dec 30 15:15:35 It does remove a some of the package tasks but marks others as noexec, I don't remember why :( Dec 30 15:41:14 RP: yes, the warning appears as a result of adding do_deploy to the dependency of kernel-fitimage-initramfs. This results in do_packagedata being added as a 'direct dependency' in package_prepare_pkgdata() Dec 30 15:45:07 RP: my psplash patches were in master-next, then weren't. did they cause a failure on the AB? Dec 30 15:47:15 RP: but i notice they don't apply cleanly anymore, should i send a v2? the only tweak is a filename change Dec 30 15:58:14 tlwoerner: I replied earlier today on list? Dec 30 15:59:15 hnje: it does sound like its not working quite as intended, have you tried adding to a specific task instead of do_build? Dec 30 16:03:20 RP: got it, thanks Dec 30 16:04:07 tlwoerner: sorry for not doing it sooner or digging further into the issue :( Dec 30 16:04:46 TIL: arm64 machines are supported build hosts! :-D Dec 30 16:06:09 tlwoerner: we even test them! Dec 30 16:19:10 I’ll have selftest running on arm64 soon too, the syslinux patches were the last known blocker Dec 30 16:29:22 RP: Yes, added it to do_install instead Dec 30 16:37:37 rburton: RP: any suggestions for how to get started? i can use a qemuarm64 MACHINE? any specific image you recommend? Dec 30 16:37:38 rburton: I suspect tlwoerner's new selftest may "break" it ;-) Dec 30 16:38:00 tlwoerner: You may be able to reproduce the failure inside a qemu image, yes Dec 30 16:38:05 RP: sounds like i better get it merged sooner rather than later ;-) Dec 30 16:38:36 tlwoerner: I merged that one aready: https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/3109 (sorry rburton) Dec 30 16:38:59 tlwoerner: I do think that we need another test checking that is actually a fifo on the target though (I think I pointed at another test for that?) Dec 30 16:40:57 rburton: what's your setup? are you building on real hardware, or inside qemu? Dec 30 16:41:57 RP: interested in a alpha pull request for 5.10 stuff ? For some extra mileage on it. Dec 30 16:42:41 rburton: heads up v5.11 has some vmalloc changes that are throwing a warning on 32 bit ARM, so far I've failed to fix it through the tricks I've found when searching the message. Dec 30 16:43:07 I should also ping on jonmason, but I see he's in hiding. Dec 30 16:47:19 pre-new year house cleaning Dec 30 16:48:33 :D I hear you. technically I'm not working at all this week, or last. But yet, somehow, I'm juggling kernel patches! so I thought I'd just be a PITA at the same time. Dec 30 16:48:52 still recovering from the shock of seeing trump in the original superman movie. **** ENDING LOGGING AT Wed Dec 30 16:54:07 2020 **** BEGIN LOGGING AT Wed Dec 30 16:56:20 2020 Dec 30 17:09:46 zeddii: I did see the emails, I've also been trying not to get too pulled into crazy failing builds :) Dec 30 17:10:31 I saw all green on my last one, I guess I'll launch one of the full build targets early next week, and can send it for master-next after that. Dec 30 17:10:57 zeddii: fair enough. I wasn't ignoring that providers question, it just needed more digging than I had any machine powered up to do... Dec 30 17:11:18 * RP notes master-next keeled over again due to more untested patches :( Dec 30 17:11:58 I just hadn't seen that before. I have two patches against poky that fix the reference boards mismatch warning. but as we know, when you wonder "why haven't I seen that before" .. you might be doing something dumb Dec 30 17:12:15 that being said, I literally may have not seen them before and now see it with your fixups to the AB output interface. Dec 30 17:29:07 kanavin: would it be worth trying to upgrade to the pre release pppd, see how our patches look with it? **** ENDING LOGGING AT Wed Dec 30 17:45:48 2020 **** BEGIN LOGGING AT Wed Dec 30 17:48:57 2020 Dec 30 18:05:17 tlwoerner: I have a thunderx2. Easiest would be a AWs graviton2 instance. Dec 30 18:16:06 tlwoerner: or a honeycomg LX2K if your looking to buy an inexpensive 64bit Arm work station Dec 30 18:40:46 RP: I really have no idea Dec 30 18:41:05 RP: but we should send some of those patches upstream first Dec 30 18:41:18 RP: I asked khem to do it Dec 30 19:11:35 RP: isn't it weird that the oe-selftest i added for having a fifo in the image passed, but when i used a fifo in the psplash recipe it failed? Dec 30 19:49:21 I'm trying to build glmark2 with yocto and the glmark2 build is failing with the following error: "Checking for 'wayland-protocols' : not found" I don't understand this as I've build the latest version of wayland-protocols already. Dec 30 19:49:28 Any ideas on what the problem might be? Dec 30 20:31:06 tlwoerner: no, since oe-selftest doesn't run on arm hosts, yet. Dec 30 22:13:09 RP: aahhh (haha lol) Dec 31 01:25:19 if arm64 is now a valid build host, then SDKMACHINE=qemuarm64 needs to be a valid selection ;-) Dec 31 02:10:14 +1 Dec 31 02:11:30 My solidiron arm64 is now my kubernetes control-plane Dec 31 02:38:33 cphealy: which MACHINE are you building for? which layers are you using in your bblayers.conf and which branches of those layers? what are you building (core-image-??)? **** ENDING LOGGING AT Thu Dec 31 02:59:57 2020