**** BEGIN LOGGING AT Fri Dec 18 02:59:56 2020 Dec 18 06:27:08 Hi everyone, I'd like to include mkimage into my built image. Does anyone know what recipe to use for that? Dec 18 07:21:23 Hi everyone, I'd like to include mkimage into my built image. Does anyone know what recipe to use for that? Dec 18 07:30:00 thomas_dee: probably someting u-boot-ish Dec 18 07:30:32 thomas_dee: but, pardon the remark - wanting to have that sounds strange ar least. care to elaborate why you want that? Dec 18 07:43:46 good morning Dec 18 07:51:52 LetoThe2nd Thanks for hint. We are just thinking about our options for controlling the boot process. So we'd like to create a boot.scr on the fly. And for that we obviously need mkimage Dec 18 07:54:41 that sounds extremely problematic. to say the least. Dec 18 07:55:24 i would strongly suggest to rather try and find a way where a standard boot script can react to the situation and fall back to a sensible default. Dec 18 09:41:53 thomas_dee: don't know about scr scripts but one way to achieve controlling the boot process is having your scenarios in different u-boot env variables and execute one depending on another variable in the u-boot env Dec 18 09:42:38 this variable can be imported from the same env or another (look up `env import` command). The environment can be modified from Linux with fw_setenv available in libubootenv IIRC (u-boot-fw-utils previously IIRC) Dec 18 09:55:29 yeah. another option is to outright use a patched u-boot that has board/device specific commands to get information. Dec 18 09:56:47 does not work well for upgrade scenarios (A/B or recovery), but yes, possible too Dec 18 09:57:03 LetoThe2nd: 3rd Yocto chant: "It dependsTM" Dec 18 09:57:50 qschulz: exactly. Dec 18 09:59:26 dsueiro: Just looking at that u-boot /boot change, I'm wondering if we're going to confuse users by having both the deploy dir and the sysroot... Dec 18 10:03:38 RP: I'm not sure it's the right move honestly Dec 18 10:04:13 though I'm having a hard time understanding what should be available in SYSROOT_DIRS and what should be available in DEPLOYDIR Dec 18 10:05:11 qschulz: I can see the need. sysroot was supposed to be for "inter-recipe" sharing and deploy for the final result Dec 18 10:05:28 then recipes learnt to go fishing in deploy Dec 18 10:05:42 and then "we" "recommend" it? Dec 18 10:05:56 well, there wasn't really an alternative for some things Dec 18 10:06:11 if you want an image for example, we never put those in sysroots Dec 18 10:06:21 I mean, I always applied that "non-lib, non-header fies should be shared through DEPLOYDIR" but don't know if it's a good rule though Dec 18 10:06:43 RP: true... let's not tell people that you can have DEPENDS in image recipes though :p Dec 18 10:06:47 My own metric is more about whether the end user would consume it... Dec 18 10:07:26 qschulz: there is a long list of things I don't make widely known :) Dec 18 10:07:57 yet it seems my company is very good at finding those :p Dec 18 10:08:57 qschulz: hard to tell when I don't talk about them ;-) Dec 18 10:09:33 RP: keep your secrets then Dec 18 10:10:11 (meme reference) Dec 18 10:30:04 Hi guys. I am wondering if someone already tried to package Cuda for a x86_64 target with NVidia GPU (the meta-tegra should not be suitable) Dec 18 10:38:26 ebail: i would start out with meta-tegra anyways and start beating it into shape. Dec 18 10:44:49 Yep LetoThe2nd, I think so. I would need to tune COMPATIBLE_MACHINE. I am wondering why meta-tegra was not split into several layers to make SW packaging HW-independant. Dec 18 10:45:45 ebail: just ask matt, he's a nice guy :) Dec 18 10:46:10 LetoThe2nd: sure. is he on #yocto ? Dec 18 10:48:01 ebail: not sure. and if, then probably not until US daytimes. Dec 18 10:48:57 ok LetoThe2nd I will contact him on GH. Thanks for your help Dec 18 10:49:05 have fun! Dec 18 10:51:07 ebail: technically you could also add one of tegra's machine into your machine's MACHINEOVERRIDES if it makes sense Dec 18 10:51:29 at least that's a good way to start without too many bbappends at once (great to get started, and might even make sense in some cases) Dec 18 10:53:16 yes qschulz that's a good way to test it. Dec 18 12:00:53 Hi guys. Long time no IRC. Dec 18 12:02:18 hello there Dec 18 12:06:27 fray: I have a question for you. You took care of the shared downloads (sources mirror) strategy in WRS. Can you give me a short overview on how you designed that process? I'm taking this from the traceability and regression point of view so I'm wondering if you were also doing freezing of the mirror per release (not only the build metadata). Dec 18 12:18:58 Anyone that have success in using nativesdk-gcc? When I include this in the SDK the sysroot does not get correct when the linker is invoked. Dec 18 12:25:13 ebail: The CUDA support could be split out from meta-tegra and extended to handle x86 targets. There was some discussion of it a few years ago. Dec 18 12:31:17 madisox: good point. I will check this out Dec 18 13:07:21 madisox: I read your GH link. So I guess it is not recommended to start from meta-nvidia which seems outdated. The best would be to split meta-tegra, right ? Dec 18 13:08:03 madisox: did you also have some experience using meta-tegra with PREEMPT_RT full ? Dec 18 14:26:49 kanavin_home: I've sent a patch to bitbake-devel for that os-release issue Dec 18 14:33:55 Hello, I have an issue where the RDEPENDS files of a recipe are not inside the sysroot that DEPENDS on this recipe Dec 18 14:34:41 I have created a post on stackoverflow earlier to better explain things: https://stackoverflow.com/q/65354848/10645806 Dec 18 14:37:12 Anarky: you cannot RDEPENDS on a native recipe, that does not make sense Dec 18 14:37:44 a native recipe is for the host, where you build stuff. You want a target package (without -native) for packages installed in your rootfs Dec 18 14:38:37 that's one issue, reading your post more carefully now Dec 18 14:39:07 qschulz: the "composer" recipe is not supposed to go on my system Dec 18 14:39:34 Anarky: which version of Yocto are you using? Dec 18 14:40:22 RDEPENDS for native packages have only been recently added Dec 18 14:40:29 but to build "myserver", which will go on my target, I need to run "php composer.phar composer.lock" on my system Dec 18 14:40:40 right now I'm stuck on thud Dec 18 14:40:42 also... not sure RDEPENDS for native packages is correct Dec 18 14:40:53 ok, so RDEPENDS in your composer-native won't work Dec 18 14:41:10 just put DEPENDS = "php-native" instead Dec 18 14:46:32 qschulz: on the last version, RDEPENDS is more correct right? Dec 18 14:49:37 Anarky: I do not know. Because technically, you're pulling composer-native with DEPENDS and not RDEPENDS Dec 18 14:50:04 I don't have much experience with native RDEPENDS, specifically because I'm using thud like you and it isn't supported Dec 18 14:50:08 RDEPENDS on native packages* Dec 18 14:51:32 qschulz: the issue is the same with a DEPENDS on composer-native Dec 18 14:52:07 even after a cleanall, when I build "myserver" it can't find "usr/bin/php" during the compile Dec 18 14:52:23 oh wait :/ Dec 18 14:54:37 qschulz: you're right, it works perfectly now, thanks! Dec 18 14:55:43 do you know which version adds the RDEPENDS support for native package? I might be able to update in the future Dec 18 14:56:01 Anarky: still I'm not sure it is supposed to work the way you intend to Dec 18 14:56:12 RP: thanks! it's crucial for keeping AUH running and not falling behind on version updates :) Dec 18 14:57:36 kanavin_home: if you could confirm it helps, that would be useful Dec 18 14:59:37 RP: I guess once it merges, I can re-start AUH builder? Dec 18 14:59:54 or is there a way to run AUH against master-next maybe? Dec 18 15:00:58 kanavin_home: I think you could just set the branch to master-next one I add it there? Dec 18 15:05:22 RP: yes I can Dec 18 15:07:34 Anarky qschulz: if a tool is needed at build time, it should be in DEPENDS as -native. RDEPENDS on -native packages should really only be needed by other native recipes Dec 18 15:11:35 smurray: so it's a normal behaviour the problem I had? Dec 18 15:17:55 smurray: the question is when RDEPENDS on native packages make sense? in image recipes? Dec 18 15:19:38 qschulz: when something that is native needs another native tool to run, if you grep in oe-core / poky, you'll see there are not many instances Dec 18 15:19:52 Anarky: yes Dec 18 15:30:00 Ah, like a native recipe which is a bash script calling another binary I guess, no need at build time obviously Dec 18 15:32:12 smurray: but in my case, php-native was needed at runtime for composer-native, so why I couldn't use php during the compile task on my recipe that DEPENDS on composer-native? Dec 18 15:34:35 Anarky: if composer-native needs php-native, then adding the RDEPENDS_${PN}_class-native = "php-native" to the composer recipe would perhaps make sense Dec 18 15:35:10 Anarky: that is the usecase I mentioned ("RDEPENDS on -native packages should really only be needed by other native recipes") Dec 18 15:37:27 RP: a few warnings (fixed), and of course stap failure on 5.10 run v1. I guess I'll end up doing that uprev after all ;) Dec 18 15:39:25 Anarky: though that depends a bit on your composer recipe, if it's intended for both target and native, it should just have RDEPENDS_${PN} = "php" and I think wouldn't need anything else if it uses BBCLASSEXTEND = "native" Dec 18 15:39:36 zeddii: I guess it could be worse! Dec 18 15:40:13 indeed. or just the obvious ones could be worse. We'll see how more runtime tests behave. Dec 18 15:41:00 smurray: composer is only native, to build the target recipe "myserver" Dec 18 15:41:26 smurray: right now it's called "composer-native.bb" with "inherit native" inside Dec 18 15:41:46 Anarky: okay, likely you want RDEPENDS_${PN}_class-native = "php-native" Dec 18 15:42:07 smurray: thanks I try right now Dec 18 15:44:04 smurray: why the class-native override? it's a native only recipe, so it shouldn't be needed right? Dec 18 15:44:45 qschulz: yeah, I'm not 100% sure, it might be okay w/o it when using native.bbclass Dec 18 15:45:22 smurray: it doesn't work, is it because it's only "inherit native" instead of BBCLASSEXTEND? Dec 18 15:47:16 Anarky: looking at native.bbclass, I think you can just use RDEPENDS there Dec 18 15:48:41 Anarky: if that doesn't result in php-native getting pulled in, I think you'll need to stick with explicitly putting it in DEPENDS Dec 18 15:48:49 smurray: it's what I had on the first place: https://stackoverflow.com/q/65354848/10645806 Dec 18 15:53:59 smurray: also, Anarky is on thud and RDEPENDS on native packages is *NOT* supported in thud Dec 18 15:54:07 qschulz: ah Dec 18 15:55:23 Anarky: I think you're likely stuck with the explicit DEPENDS, but it's entirely possible I'm missing something Dec 18 15:55:44 Anarky: warrior has support according to the release note Dec 18 15:55:49 https://docs.yoctoproject.org/ref-manual/migration-2.7.html#miscellaneous-changes Dec 18 16:49:25 zeddii: I am seeing selftest build failures with 5.8 and also with -dev ( 5.10 ) version its same error https://errors.yoctoproject.org/Errors/Details/539423/ Dec 18 16:49:35 zeddii: any ideas ? before I dig Dec 18 16:52:54 hmm. 5.8 is static in versions, since it is EOL, or I would have suspected my recent version bumps. I don't have any config changes for 5.8 either. 5.10, could just be the new kernel, I just started running the full uprev through the AB, so I haven't seen all the issues yet. Dec 18 16:55:55 While trying to use meta-st-stmp32 BSP layer I'm encountering "/path/st-image-bootfs.bb:do_image_complete has circular dependency on /path/st-image-bootfs.bb:do_image_wic". Any pointers for a beginner on how to resolve this? Dec 18 17:31:23 how can I remove -MACHINE from the image file names? Dec 18 17:32:29 It seems redundant since images are already in a deploy/images/MACHINE/ folder and having just core-image-minimal.wic for example would simplify the documentation (especially when multiple machine are involved) Dec 18 17:35:49 I mean the link core-image-minimal.wic for example, not the ${IMAGE_BASENAME}-${MACHINE}-${DATETIME}.wic file it points to. Dec 18 17:38:22 Another question, how can I enable the openssl extension when I use the native php binary? Dec 18 17:55:21 I would like build/tmp/deploy/images/MACHINE/core-image-minimal.wic -> core-image-minimal-MACHINE-20201217202436.rootfs.wic (instead of core-image-minimal-MACHINE.wic) Dec 18 18:06:35 RP: I have a fix for the systemtap uprev, and for it on 5.10, but the damn thin oom's on my qemux86-64 run on the default setting (systemd init). So we may start running into memory limits again. Dec 18 18:06:46 s/thin/thing Dec 18 18:07:24 v0n: https://github.com/openembedded/openembedded-core/blob/ef9c11797b5d626bdb40b4509d8b2b0d461ff9ea/meta/classes/image-artifact-names.bbclass Dec 18 18:07:39 v0n: you can set any of those in your recipe or distro or whatever Dec 18 18:11:45 kergoth: thanks! I was unfortunately looking at https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html (which has no occurrence of IMAGE_LINK_NAME) instead of https://docs.yoctoproject.org/singleindex.html Dec 18 18:14:33 * v0n updates his new best friend helper to: yvar () { for var; do firefox "https://docs.yoctoproject.org/singleindex.html#term-$var"; done; exec swaymsg -q '[urgent="newest"] focus' ; } Dec 18 18:18:30 zeddii: that sounds like fun :( Dec 18 18:18:54 booting with qemuparams="-m 2048" fixes it up. Dec 18 18:19:08 I'll put the fix for stap on my test branch and see if the AB runs see the oom. Dec 18 18:25:38 zeddii: an init system needs 2GB of memory though? :( Dec 18 18:26:03 I'll try some lower values, that's my goto bump when things oom :D Dec 18 18:55:36 kergoth: works beautifully, thanks Dec 18 18:55:44 np Dec 18 19:17:14 zeddii: systemd now has oom daemon, are you enabling it ? Dec 18 19:20:38 khem: I'm just taking the defaults of current master, so probably not. Dec 18 20:41:41 tlwoerner: Hmm, I have to enable a few kernel configs for the Rock Pi X, which probably means it should have it's own machine. Any suggestions for where it should live? Dec 18 21:00:23 JPEW: not in meta-rockchip :-) Dec 18 21:00:36 isn't the X an x86-based MACHINE? Dec 18 21:03:09 JPEW: if they're generic enough maybe they could be added to git.yoctoproject.org/yocto-kernel-cache ? Dec 18 21:04:47 maybe bsp/intel-x86 or bsp/intel-common Dec 18 21:05:25 or bsp/rock-pi-x Dec 18 22:07:40 when creating your own distribution, is it better to stick to core-image-* if possible? Dec 18 22:14:07 I think meta-raspberrypi got rid of their custom images in favor of core-image-* Dec 18 22:17:09 well, that is kind of useless. The mailing list archiver obscures e-mail addresses in body text, even if they are a part of an URL.... Dec 18 22:18:14 so all links to anything to do with any list on kernel.org official archiver "lore" get turned into garbage. Dec 18 22:18:17 https://lists.yoctoproject.org/g/linux-yocto/message/9283 Dec 18 22:18:31 link is truncated because it looks like an e-mail addy. Dec 18 22:18:50 Should be: https://lore.kernel.org/r/20201110040725.1478297-1-paul.gortmaker@windriver.com/ Dec 18 22:20:09 not sure how one would fix that, but trashing any and all links to the millions of posts archived on lore is... well, rather "not good". Dec 18 22:23:30 At least it seems like the copy that list subscribers got directly was not mangled. Dec 18 22:23:38 so is it fine for a distro to append IMAGE_INSTALL or CORE_IMAGE_EXTRA_INSTALL or should it define its own -image-*? Dec 18 22:24:11 I'm struggling to understand weither it's ok or not to extend the standard image Dec 18 22:28:55 v0n: defining new images is pretty inexpensive. As a distro you can redefine the core it you need/want too Dec 18 22:29:24 paulg: I'd mention that to halstead Dec 18 22:31:40 paulg: that certainly seems to be an undesired side effect. I'll raise a bug Dec 18 22:33:17 halstead, awesome - thanks! Dec 18 22:42:23 RP: in other words, if you fetch a distro layer, do you expect to build core-image-minimal and flash it on your board or do you expect custom distro images? Dec 18 22:44:11 like if I want the "dev" image to have u-boot configured to tftpboot my kernel+initramfs, should I create a custom image recipe or should I extend core-image-minimal-dev or core-image-initramfs for example? Dec 18 22:44:42 v0n: Create a new image most likely Dec 18 22:52:39 ok I think I get it. For BSP layer, you expect "core-image-*" to boot and just work. Dec 18 22:53:37 For distro layers, you certainly expect custom image targets since distro have their own flavors, packages and stuffs and thus "core-image-*" don't make much sense here I guess. Dec 18 22:53:49 right, I'd agree with that Dec 18 22:58:04 well Poky isn't a good example of this but it is a reference distro after all Dec 18 22:59:14 like if there was a meta-ubuntu distro layer, the instructions would be "bitbake ubuntu" or "bitbake ubuntu-dev" I imagine. Dec 18 23:09:41 v0n: that is true! Dec 18 23:26:46 zeddii: there was a warning with your latest patchset on poky-tiny: https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/3105 Dec 18 23:27:05 (that is with master-next) Dec 18 23:36:25 The bug is files thanks you paulg :) Dec 19 01:34:15 RP: yes, I fixed it for 5.10 (differently), It's a change that came back in -stable: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/commit/?h=yocto-5.10&id=3d154dcfaa397654b1522e2ddd65a1a740bda812 Dec 19 01:36:32 actually no. That warning was always there, just hidden. There are no changes to 5.8, it's the kern-tools change. **** ENDING LOGGING AT Sat Dec 19 03:00:07 2020