**** BEGIN LOGGING AT Fri Apr 23 02:59:56 2021 Apr 23 03:06:14 :-) Apr 23 08:06:49 yo dudX Apr 23 08:07:02 qschulz: so how many beers did you accumulate? ;) Apr 23 09:37:37 LetoThe2nd: too many Apr 23 09:37:43 RP: meta-multimedia with yocto-check-layer breaking on this one? https://lists.openembedded.org/g/openembedded-core/topic/72389694#141680 Apr 23 09:38:27 RP: I came across it recently as well as reported in https://lists.openembedded.org/g/openembedded-devel/message/90463 only to be notified by Denys that this issue is known for much longer Apr 23 09:39:50 JaMa: yes. https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/5 Apr 23 09:40:06 JaMa: I think Khem is saying he has some patches to workaround it Apr 23 10:05:33 RP: thanks, haven't seen the context in the back log, now I'm "pleased" :) Apr 23 10:07:22 JaMa: basically we're trying to get more CI of the layer compatibility running regularly Apr 23 10:09:41 I converted a couple of recipes to have a native counterpart as well with BBCLASSEXTEND += "native" , and I've added DEPEND_class-native deps to them as they depend on each other. Now it seems yocto doesnt include the header files of a root native recipe (one that is converted) in the recipes sysroot native when it's compiled itself on the native Apr 23 10:09:41 counterpart. Can anybody point me out what I'm missing here? Apr 23 10:15:55 fenrig: if it is listed in DEPENDS and installs the headers, it should include them. Note that the install paths for natives is a bit different to target since it has to install them at the location they'll "run" at and the paths look like they include duplication but are in fact correct. Try comparing the layout of the files to a recipe known to work with native Apr 23 10:16:54 i.e. you'll see files file /my/build/path/tmp/work/xxx/yyy/image//my/build/path/tmp/work/xxx/yyy/recipe-sysroot-native from memory Apr 23 10:17:12 so I have libamxc-native Apr 23 10:17:17 and i have libamxp-native Apr 23 10:18:30 and in work/xxx/yyy/libamxc-native in the image folder of the work dir it has both the header files and the so libraries Apr 23 10:18:33 but when i look in Apr 23 10:19:17 work/xxx/yyy/libamxp-native in the recipe's recipe-sysroot-native I dont have these header files, so I'm doing something wrong there Apr 23 10:20:20 in the amxp recipe bb i have this: DEPENDS_class-native = "libamxc-native" Apr 23 10:20:32 should i add libamxc-dev as well in those depends? Apr 23 10:22:10 nope doesnt seem to be able to resolve it it renames libamxc-dev to libamxc-dev-native which doesnt exist Apr 23 10:28:36 Hello dudX ! Apr 23 10:28:50 Do you think I can run bitbake from a makefile ? Apr 23 10:29:12 I've tried something like Apr 23 10:29:27 fenrig: what are the paths to the files in image folder? Apr 23 10:29:51 fenrig: can you see your host build path in there or just "/usr/include" or similar Apr 23 10:30:21 build: Apr 23 10:30:21 @source ${LAYERS_PATH}/poky/oe-init-build-env ./build Apr 23 10:30:22 @cd ./build && bitbake multiconfig:: Apr 23 10:34:31 so for libamxc-native where the header files are installed in image its: libamx-native//image/usr/include/amx/*.h Apr 23 10:35:28 I dont understand the host build path question exactly, should i check the libamxp-native temp logs? Apr 23 10:36:02 BTW /build/tmp-glibc/work/x86_64-linux/ is my path Apr 23 10:39:43 amxp-native --> log.do_compile --> -isystem/workspace/yocto/sah/netci/build/tmp-glibc/work/x86_64-linux/libamxp-native/v0.6.9-r0/recipe-sysroot-native/usr/include Apr 23 10:41:22 but this path /workspace/yocto/sah/netci/build/tmp-glibc/work/x86_64-linux/libamxp-native/v0.6.9-r0/recipe-sysroot-native/usr/include/ does not have the amxp-native header files Apr 23 10:41:49 it does have others like lxma and libltdl Apr 23 10:42:36 thekappe: I remember a company received a Yocto BSP that had only a Makefile and the whole magic hidden. But.... Why do you want to such a thing? Apr 23 10:44:04 fenrig: mmmm why do you need header files of a native recipe in a target recipe? Apr 23 10:44:40 @qschulz, for some lazy user Apr 23 10:45:02 well its a set of libraries in seperate components that the eventual native tool uses Apr 23 10:45:32 so it needs to resolve that chain in the native counterparts Apr 23 10:45:54 we have a very modular approach to the framework, its not one big component blob Apr 23 10:57:25 hi, mixing ?= and ??= operators with conditional assigment i.e. FOO_override ?= "bar" FOO_overrride ??="bar2" is correct or this will end up undefined behavior ? Apr 23 11:04:08 the native classextend doesnt support carrying header files? Apr 23 11:04:17 is there some philosophy behind it Apr 23 11:04:34 i mean native tools probably still need dependencies right? Apr 23 11:15:05 dev1990: not sure to understand the question? what are you trying to do? Apr 23 11:16:24 qschulz: https://github.com/dev-0x7C6/meta-retro/pull/12/files not sure about my comment Apr 23 11:18:19 fenrig: https://docs.yoctoproject.org/ref-manual/variables.html#term-SYSROOT_DIRS_NATIVE they should be here... but are they installed by the recipe in ${D}? Apr 23 11:21:59 fenrig: I'm now confused, you want the libxamxp-native recipe to have its own header files in recipe-sysroot-native? Apr 23 11:22:30 well y Apr 23 11:23:08 fenrig: amxc-native DEPENDS on amxp-native, right? Apr 23 11:23:13 libamxp-native is depending on libamxc-native Apr 23 11:23:15 y y Apr 23 11:23:26 and libamxc-native has header files that are necessary for libamxp-native Apr 23 11:23:32 and i dont have them in the sysroot-native Apr 23 11:24:02 fenrig: which is expected. Have a look at the work directory for xz-native Apr 23 11:25:04 fenrig: If I do /media/build1/poky/build/tmp/work/x86_64-linux/xz-native/5.2.5-r0$ find -name lzma.h Apr 23 11:25:21 fenrig: I see mentions of ./sysroot-destdir/media/build1/poky/build/tmp/work/x86_64-linux/xz-native/5.2.5-r0/recipe-sysroot-native/usr/include/lzma.h ./xz-5.2.5/src/liblzma/api/lzma.h and ./image/media/build1/poky/build/tmp/work/x86_64-linux/xz-native/5.2.5-r0/recipe-sysroot-native/usr/include/lzma.h Apr 23 11:25:46 fenrig: now do the same for amxp-native and see if it looks similar for one of the headers there Apr 23 11:26:01 dev1990: never asked myself this question, I'd have expected it to work as other recipes? It's just that basicxally FOO_overrride = "baz" would override FOO_overrride ?= "bar" ? Apr 23 11:26:13 as other "normal" operators* Apr 23 11:26:46 xz native has the host path repeated in sysroot-destdir? Apr 23 11:26:50 thats what you are saying? Apr 23 11:26:57 fenrig: this is what I was getting at earlier, yes Apr 23 11:27:11 and that is the correct things to see, odd as it may look Apr 23 11:27:11 and i should have this for the header files as well? Apr 23 11:27:19 fenrig: correct Apr 23 11:27:44 fenrig: I'm saying to look at xz-native as an example of where it is working correctly Apr 23 11:27:57 and making correct use of ${D} allows for the behaviour on both native and target? Apr 23 11:28:07 fenrig: yes Apr 23 11:28:24 fenrig: the reason is that exec_prefix will be set to /media/build1/poky/build/tmp/work/x86_64-linux/xz-native/5.2.5-r0/recipe-sysroot-native/usr/ Apr 23 11:28:38 and includedir will be $exec_prefix/include Apr 23 11:29:20 so files are installed to ${D}${prefix}/includedir Apr 23 11:29:33 (it may be prefix, not exec_prefix but my point is the same) Apr 23 11:31:16 but all this stuff is in autotools Apr 23 11:31:33 so the xz-native recipe is a bad candidate to understand Apr 23 11:32:06 is there some documentation on this that you are aware off. It seems I cant find anything usefull on google Apr 23 11:33:21 fenrig: it doesn't matter whether you're using autotools or something else for libxamxc, my point is the file layout would be similar Apr 23 11:33:38 yes but i need to look at the recipe what is the correc tthing to do Apr 23 11:33:38 fenrig: we probably need to better document this :/ Apr 23 11:34:32 fenrig: your question was why weren't the files appearing. I'm asking if the files are in the right locations. That is the first thing to check here and I don't know if they are or not. I'm trying to give you something you can compare the layout with Apr 23 11:34:51 If the layout matches, it will be something else. If they don't match, that hints where the problem may be Apr 23 11:40:53 fenrig: there is a section, https://docs.yoctoproject.org/singleindex.html#faq see Q: Why do ${bindir} and ${libdir} have strange values for -native recipes? Apr 23 11:52:12 qschulz: I made update with test case, it is working as expeceted with ?= and ??=, so this is probably my imagination. Apr 23 11:54:25 dev1990: we do have a few selftests in bitbake so that we try to at least be consistent with how everything operates Apr 23 12:02:34 so i need to pass ${prefix} additionally to ${D} ? Apr 23 12:02:52 so this: EXTRA_OEMAKE = "DEST=${D} LIBDIR=${libdir} VERSION_PREFIX=master_" Apr 23 12:03:08 might need to become: EXTRA_OEMAKE = "DEST=${D}${prefix} LIBDIR=${libdir} VERSION_PREFIX=master_" ? Apr 23 12:07:50 RP: glad to hear it :-) Apr 23 12:08:59 fenrig: depends on the makefile Apr 23 12:12:57 yeah logically Apr 23 12:13:06 btw why does ${prefix} include usr/ at the end? Apr 23 12:13:17 now its installing to usr/usr/... Apr 23 12:14:42 fenrig: is the makefile hardcoding prefix=/usr ? Apr 23 12:14:50 in a way yes Apr 23 12:14:59 fenrig: usually you're pass in the prefix as a variable Apr 23 12:15:09 yeah the DEST Apr 23 12:15:43 fenrig: no, not as DEST. normally something like DEST=${D} PREFIX=${prefix} LIBDIR=${libdir} Apr 23 12:15:49 https://gitlab.com/soft.at.home/ambiorix/libraries/libamxc Apr 23 12:16:29 ah yes Apr 23 12:16:33 i can override prefix Apr 23 12:16:36 good catch Apr 23 12:16:38 <# Apr 23 12:16:58 fenrig: and/or INCLUDEDIR by the looks of it Apr 23 12:17:34 fenrig: set BINDIR as well just to make it all portable Apr 23 12:19:01 and remove DEST it seems Apr 23 12:19:44 fenrig: no, keep that Apr 23 12:19:52 no cant Apr 23 12:20:06 cause DEST is appended again to BINDIR Apr 23 12:20:15 ah wait Apr 23 12:20:26 libdir does not contain the ${D} part? Apr 23 12:20:35 fenrig: this is the odd double path thing I mentioned, it should work even if it looks odd at first Apr 23 12:21:13 fenrig: DEST=${D} and bindir/libdir/prefix/includedir don't have ${D} in them Apr 23 12:21:15 so it should be this: EXTRA_OEMAKE = "DEST=${D} PREFIX=${prefix} LIBDIR=${libdir} BINDIR=${bindir} VERSION_PREFIX=master_" Apr 23 12:21:37 yes, probably INCLUDEDIR=${includedir} as well Apr 23 12:21:58 yeah i saw Apr 23 12:21:59 lets try this Apr 23 12:22:06 finally it should be fixed then Apr 23 12:22:24 fenrig: closer, certainly :) Apr 23 12:22:32 and those libdir/includedir/prefix/bindir are set respectively for target and native right? Apr 23 12:22:40 I shouldnt care about only passing them to native or smth like that Apr 23 12:22:49 silly question I know, but just checking Apr 23 12:22:54 fenrig: yes, the core of the build will set them correctly for the different cases Apr 23 12:23:02 great <3 Apr 23 12:23:18 this yocto stuff is really put well together, i just couldnt find a description of this part Apr 23 12:23:30 libamxp-native compiles now Apr 23 12:23:34 lets check libamxp Apr 23 12:23:45 and if thats working I change them all to incorporate this behaviour Apr 23 12:24:01 fenrig: those paths do look really wrong the first time you see them but they do make sense :) Apr 23 12:24:02 TY RP, I needed some time to understand Apr 23 12:24:14 mind boggling paths Apr 23 12:24:18 im sure there is a logic to it though Apr 23 12:25:12 ndec, michaelo: I've wondered if we should put something in the docs about this. Not entirely sure where though Apr 23 12:25:12 amxp for target is compiling Apr 23 12:25:20 allright Apr 23 12:50:28 I try to use TOOLCHAIN_HOST_TASK_append in a file would be used by the other file Apr 23 12:50:45 but I found it would be override by the inherited file Apr 23 13:40:32 RP: quick question. I cut and pasted the check layer command from your email last night, and it errored on: ERROR: Nothing PROVIDES 'util-linux-uuid' Apr 23 13:41:06 I just wanted to confirm .. should I be running that from a completely clean clone ? That's my normal integration build, so it has some custom configs Apr 23 13:48:45 zeddii: util-linux-uuid got renamed to util-linux-libuuid last month. Wondering if your configs still reference the old name? Apr 23 13:49:37 yah. I was in on that, I remember it. This is everything up to date. it wouldn't be building otherwise. Apr 23 13:49:45 Ah, okay Apr 23 13:50:11 I'm just rm -rf'ing everything and starting over. too much work to use my existing build dir anyway. Apr 23 13:51:39 probably some dumb distro config I was messing with Apr 23 13:51:48 * zeddii goes for coffee while it rm's Apr 23 14:12:30 RP: my second run got further, but my list of issues is different than the AB one. Apr 23 15:00:53 zeddii: I'd do this in a clean directory/build/checkout. The layers added at the start of the test need to be minimal Apr 23 15:28:50 zeddii: I'm seeing errors about seccomp being missing for meta-virt. We may need to speed up the migration of that to core? armpit? Apr 23 15:31:35 RP: I did a commit to just add the depedency. until it migrates. Apr 23 15:31:40 I can undo it later. Apr 23 15:32:18 RP, would you take it if ptests are wonked ? Apr 23 15:32:39 armpit: ptests don't currently work today right? Apr 23 15:33:21 armpit: I guess it depends what "wonked" means exactly. As long as they don't break the build or anything and don't regress with the move we're probably ok Apr 23 15:33:30 we can fix them in due course Apr 23 15:34:06 https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?h=master-next&id=f97dc34935b1e3defb3e7e9b1c144cb4adb58115 Apr 23 15:38:53 zeddii: great, the autobuilder doesn't have meta-security in its config :( Apr 23 15:39:30 ahah. is meta-virt the only one that would need it ? so I guess that isn't the best solution. but i'm testing with it locally for now. Apr 23 15:39:52 I could copy libseccomp in as well ;) Apr 23 15:40:35 zeddii: nothing has yet needed it, no, so I hadn't added it. We may end up adding anyway but as yet... Apr 23 15:40:50 zeddii: adding totally new layers is a pain as the controller has to be restarted which can interrupt builds Apr 23 15:41:10 RP, ptests run, its their results that need cleaning up Apr 23 15:41:18 zeddii: lets see if we can convince armpit to send a patch Apr 23 15:41:38 * armpit notarmpit Apr 23 15:41:38 armpit: the builds won't run new ptests until they're added to the list of ptests to run Apr 23 15:42:45 ill put together a patch Apr 23 15:56:55 is it safe to keep the state sstate-cache dir between 2 yocto releases (dunfell -> gatesgarth)? Apr 23 15:57:05 s/state/same/ Apr 23 15:58:58 vdl: should be Apr 23 16:23:21 RP, so which recipe- dir would you want this recipe to live in? Apr 23 16:25:04 vdl, I keep mine in separate directories so its easier to nuke sstate for a particular release Apr 23 16:33:28 armpit: recipe-support? open to suggestions Apr 23 16:33:40 vdl: it is safe Apr 23 16:34:08 vdl: can be useful to have separate for management reasons but the tools don't care Apr 23 16:35:07 khem: do you still see those busybox issues with current master-next? Apr 23 16:36:46 RP: Apr 23 16:36:49 INFO: Summary of results: Apr 23 16:36:49 INFO: Apr 23 16:36:49 INFO: meta-virtualization ... PASS Apr 23 16:37:21 zeddii: nice :) Apr 23 16:37:22 as I mentioned, my list of initial errors was slightly different. but I fixed what I saw. Apr 23 16:37:48 zeddii: we can rerun the autobuilder tests quite easily against -next branches and so on Apr 23 16:37:56 I didn't have the libdevmapper or lvm2, but maybe those were the inherited ones you mentioned, and I picked up meta-oe fixes for them. Apr 23 16:38:07 I can push everything to master next. and drop the libseccomp one. Apr 23 16:38:21 we can know it is a to be fixed soon error. Apr 23 16:39:12 armpit: RP: so having like a separate sstate-dunfell and sstate-gatesgarth is not really needed Apr 23 16:42:51 vdl: correct Apr 23 16:43:39 ok let's keep my separate sstate dir as is and bump dunfell -> gatesgarth and see what happens, yay \o/ Apr 23 16:44:00 * vdl has https://docs.yoctoproject.org/ref-manual/migration-3.2.html in a tab Apr 23 16:46:05 RP: I just pushed all my meta-virt fixes to it's master-next. so if you do another test run, and use that branch .. it should do better (modulo the libseccomp). Apr 23 16:48:01 zeddii: lets see - https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/9 has master-next for meta-oe and meta-virt Apr 23 16:48:13 * zeddii nods Apr 23 16:48:55 * RP moved meta-aws and meta-intel to being enabled on master and "live" Apr 23 17:07:19 I'm not sure to understand the purpose of the stateless-rootfs DISTRO_FEATURES. What's the reason for doing systemctl --preset-mode=enable-only preset-all? Apr 23 17:11:57 s/DISTRO/IMAGE/ Apr 23 17:28:31 meta-ti has no gatesgarth branch? :/ Apr 23 17:28:48 zeddii: CVE-2021-3121.patch in meta-virtualization/hardknott is now causing ERROR: containerd-opencontainers-v1.4.3+gitAUTOINC+33d90b72d1-r0 do_patch: Fuzz detected: should I send a fix or do you already have something? Apr 23 17:31:47 denix: which meta-ti branch am I supposed to use for gatesgarth? Apr 23 17:33:27 JaMa: I don't have a fix for it. Considering that was just submitted, that is surprising. I'll happily take the refresh if you've fired it up. Apr 23 17:33:36 khem: ^^ Apr 23 17:59:44 zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/8/steps/21/logs/stdio - seems that something appends unconditionally to sysvinit-inittab and python3-paramiko fetches ? Apr 23 18:01:06 no. I fixed that. Apr 23 18:01:23 if you are using my master-next python3-paramiko isn't even in the layer anymore Apr 23 18:01:30 zeddii: sorry, wrong output Apr 23 18:01:35 zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/9/steps/22/logs/stdio - it is fixed Apr 23 18:01:42 phew Apr 23 18:01:59 there's probably something new. bit it shouldn't be ther :D Apr 23 18:02:05 s/ther/that/ Apr 23 18:03:41 zeddii: yes, sorry, I was just looking at the wrong build. I should finish for the day! Apr 23 18:03:52 it's friday. I approve of that message. Apr 23 18:39:58 Does a container image require packagegroup-core-boot or packagegroup-base to start? Apr 23 18:45:52 nope. what's in the container has nothing to do with how it starts. Apr 23 18:46:02 outside of the entry point binary that is. Apr 23 18:51:25 zeddii: for systemd-based containers, it's recommended to have systemd and systemd-container installed in the container. What pulls these packages in? Apr 23 18:51:48 nothing. that's completely up to you Apr 23 18:52:18 In other words, will I have systemd installed in the container if I don't add packagegroup-core-boot and packagegroup-base to IMAGE_INSTALL? Apr 23 18:52:49 you'll have absolutely nothing installed if you don't specifiy it. Apr 23 18:52:58 up to you if you use those package groups or not. Apr 23 18:53:18 ho so at the minimum I'll have to do IMAGE_INSTALL = "systemd systemd-container" Apr 23 18:53:30 99% of the containers people want, want systemd no where near them. Apr 23 18:53:46 so yah, you'll come up with your own content. there's nothing canned for it. Apr 23 18:54:57 zeddii: what package(group) is responsible to install "systemd" when DISTRO_FEATURES includes "systemd"? Apr 23 18:59:47 I can't say that I've looked in a while. I can grep for a bit and see :D Apr 23 19:00:31 zeddii: for systemd(-container) within the container, the reason is that systemd makes it smoother if systemd is available inside the guest, like systemd-networkd automatically configures dhcp and IP masquerade on the guest side of the virtual ethernet link. Guest system journal is another nice addition. Apr 23 19:01:01 I'm just saying that most people have no interest in 'system containers' Apr 23 19:01:13 ho ok Apr 23 19:01:14 and want no init system anywhere near their container contents. Apr 23 19:03:24 hi quick question... sometimes i see stuff like "@oe.utils.conditional()" .. is this a bash thing? Apr 23 19:04:06 it's inline python Apr 23 19:04:34 ah thanks haha. ill do a search on that Apr 23 19:05:04 so yeah in the case where systemd is used in your DISTRO_FEATURES, I expect to pull in systemd and systemd-container inside the container, but no {MACHINE,DISTRO}_EXTRA_* things and no (kernel, dts) boot images. So I want to remove packagegroup-core-boot and packagegroup-base from the container image, but I fail to understand what pulls-in the base files and systemd to have a "bootable" container. Apr 23 19:05:05 vdl: to answer the other thing, it is VIRTUAL-RUNTIME_init_manager that really gets systemd installed, not the distro feature. Apr 23 19:05:22 zeddii: ho! Apr 23 19:05:41 you'll see the packagegroups referencing that. Apr 23 19:09:30 zeddii: so for this scenario I'm describing, is there a clean way to define systemd-container as a dependency or recommendation for VIRTUAL_RUNTIME_init_manager in my distro config? Apr 23 19:11:40 I'd just create a packagegroup that installs what you need, and then have your image recipe include it. that's what I do in meta-virt for all the base container definitions that are being built up there. Apr 23 19:11:55 I wouldn't bring the distro config into it at all. Apr 23 19:13:48 JaMa: did you already try the fix for the CVE patch? When I run devtool modify containerd-opencontainers, the thing throws an error instead of letting me do the work Apr 23 19:14:22 tgamblin: yah. there's something brain damaged going on with go and devtool. I just refresh the patches manually. Apr 23 19:14:38 or maybe it's meta-virt and devtool. who knows. I didn't check :D Apr 23 19:15:44 zeddii: yeah, tried that, but when I do it manually I don't see any of the fuzz issues :P Apr 23 19:16:25 odd. my builder is chewing away on other things, so I haven't tried myself to see if hardknott throws the warning on the build myself. Apr 23 19:16:44 Almost certainly does, I'm able to reproduce it readily. Just didn't notice it last time Apr 23 19:17:05 zeddii: a packagegroup-container can pull in systemd systemd-container if DISTRO_FEATURES include systemd. Apr 23 19:17:34 vdl: I'll take your word for it. I don't go anywhere near those packagegroups. Apr 23 19:18:11 tgamblin: you could just on faith head into the build directory and refresh with quilt, and see what git says about the delta. Apr 23 19:18:15 any idea why init-manager-systemd.inc doesn't have VIRTUAL-RUNTIME_dev_manager ??= "systemd" Apr 23 19:18:50 zeddii: might give that a shot Apr 23 19:23:20 zeddii: packagegroup-core-boot is the one pulling in systemd... I guess packagegroup-core-boot is in fact necessary to "boot" the container (e.g. with systemd-nspawn -b). Apr 23 19:24:00 it's just a packagegroup ... you could create your own. so I'm not following what you mean by that satement. Apr 23 19:24:04 Unfortunately I don't see any mechanism in the build system to have a bootable container without the boot images. Apr 23 19:24:08 there's no package group that is required by anything to do anything Apr 23 19:24:53 I've booted plenty of images when playing with nspawn using my own packagegroups. but tossed it all in the bin several years ago. Apr 23 19:26:57 zeddii: to put it in another way: I'd assume that yocto had a way to distinguish the packages needed for booting a system (host or guest) and the package needed to boot the actual hardware (not needed in a container). Apr 23 19:27:36 Hi, I have a packaging problem here. I try to package two variants of the same library one built with a plugin interface and another without a plugin interface. So I created two recipes libntcan-plugin and libntcan-noplugin that build the same library with and without the plugin interface active. I have set Apr 23 19:27:36 RCONFLICTS_libntcan-plugin="libntcan-noplugin" and RCONFLICTS_libntcan-noplugin="libntcan-plugin" in the recipes to show that each packed variant conflicts with the other one. But in the end I get a QA error "ERROR: libntcan-plugin-4.1.4-r0 do_package_write_ipk: The recipe libntcan-plugin is trying to install files into a shared area when those Apr 23 19:27:37 files already exist." Now my questions: a) Is it possible to build two packages that install basically the same files but make sure that only one of them can be installed? b) How is that done correctly? Setting RCONFLICTS_* seems not to be enough? Apr 23 19:27:52 no, not really. that's like it doesn't have images for every possible task. There's some very base plumbing in oe-core, and then other things we are doing in meta-virtualiation Apr 23 19:29:23 zeddii: Like packagegroup-base has packagegroup-distro-base and packagegroup-machine-base, I think we must have packagegroup-core-machine-boot and packagegroup-core-distro-boot split in packagegroup-core-boot. Apr 23 19:30:45 maybe ? but that spit is arbitrary and only useful in some situations. the line has to be drawn somewhere. Apr 23 19:31:06 like I said, I spend nearly all day every day doing container stuff, and I don't use them and wouldn't Apr 23 19:32:08 zeddii: true, similar to packagegroup-base, which allows one to remove packagegroup-machine-base if one doesn't want the packages listed in MACHINE_EXTRA_RDEPENDS (same for distro). Apr 23 19:35:06 zeddii: maybe that's because you have a strong understanding of the build system and thus are confortable to add your own packages and tweaks. But IMHO, yocto is all about being smart and pulling in what's necessary, when necessary, once the machine/distro/image configuration is properly written. Thus saying "you can write your own packagegroup" isn't really a solution to have a proper way to Apr 23 19:35:09 exclude the boot images (in the context of a container). Apr 23 19:36:54 Otherwise, all these MACHINE/DISTRO_ESSENTIAL/EXTRA_RDEPENDS/RRECOMMENDS and stuffs don't make sense at all. Apr 23 19:37:33 vdl. there's thousands of images for thousands of tasks. Apr 23 19:37:40 this is one specific example. Apr 23 19:38:04 you can't drive a super flexible set of do-anything package groups into core and actually test them. Apr 23 19:47:25 zeddii: well I disagree. That's the whole purpose of bitbake, its flexibility and the sh*itload of variables... Apr 23 19:47:40 * zeddii shrugs Apr 23 19:48:22 and that same flexibility is what gets us torn apart in all the comparisons. so that's the counterpoint Apr 23 19:49:34 Well after examining the names of the created packages I see that the packages have the same base name (in both cases libntcan*) and not libntcan-plugin* and libntcan-noplugin*. This seems to be the culprit. I'll investigate this further. Bye. Apr 23 19:51:47 tgamblin: no, after seeing your e-mail I didn't even start building it locally Apr 23 19:54:45 zeddii: I'm just talking about having a proper definition of the boot images from the machine conf, included (by default) in the image conf. Nothing fancy :) Apr 23 19:56:23 there's always room for improvement. but I wouldn't call what's available now improper. Apr 23 19:56:29 zeddii: another example is how bad meta-ti is, they hack IMAGE_INSTALL directly to force the (optional) inclusion of kernel-image-zimage and kernel-devicetree, rather than using the (confusing I'd agree) MACHINE_ESSENTIAL_EXTRA things. You imagine removing packagegroup-core-boot to exclude the kernel? nope, not with meta-ti. Apr 23 19:57:26 If we don't really on all this, let's simply get rid of these variables, packagegroups and machine/distro/image features. We all define IMAGE_INSTALL and we are fine ^^ Apr 23 19:58:18 * zeddii exits the conversation Apr 23 20:01:27 zeddii: because there's room for improvements, one needs to define how to do it. Sorry if I pushed you out of the conversation. Apr 23 20:07:41 vdl: nobody like talking to someone who complains excessively and does nothing to fix the situation. as usual, patches are welcome. this is the only place where IMAGE_INSTALL snuck in to meta-ti - https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=cc91e6bfaac42d63938b67a3efa4526dd9d8a063 Apr 23 20:43:07 RP: I have some patches for oe-core to fix meta-python with ptest check-layer fixes, pytest is in oe-core now so it can be fixed amicably by removing the bbappends from meta-python Apr 23 20:43:25 RP: I am doing a final run and will send the oe-core ones shortly Apr 23 20:45:17 RP: btw. I ran the script on some other layers in my distro conf, and in meta-clang we introduced a variable called CLANG_SDK to add clang toolchain to SDK even when using gcc if user wished to, default it is set to 0 but it does changed signature of one task on packagegroups, whats the best way to fix it ? we could add CLANG_SDK to bitbake.conf and that will fix it Apr 23 20:50:16 khem: RP: I saw the email on that but I'm just getting to it now. This is for checking sstate for recipes? Apr 23 21:04:24 Happy Germany Beer day Apr 23 21:07:15 tgamblin: I have sent fixes for meta-python as well Apr 23 21:13:41 denix: so you assume that I mention all this and "do nothing to fix the situation". Nice judgment :) Apr 23 21:13:54 denix: any reason not to have a gatesgarth branch in meta-ti? Apr 23 21:16:48 khem: alright, thanks Apr 23 21:17:22 And it wasn't complaining btw, I was discussing how to split non-hardware boot packages from hardware boot images :) Apr 23 21:20:05 so you submitted a patch? or a bug? or did anything but complain on irc? Apr 23 21:20:14 didn't look like it from here either Apr 23 21:22:59 kergoth: what do you want me to submit if I didn't discuss how to fix a thing? I've already come to the point that splitting a packagegroup-core-machine-boot from packagegroup-core-boot seems like a solution Apr 23 21:23:28 the bug is the IMAGE_INSTALL_append, which would be easy to submit a patch for Apr 23 21:23:56 yup, this I'm submitting a patch to use MACHINE_ESSENTIALS_EXTRA_RDEPENDS soon Apr 23 21:24:02 and any real discussion about design needs to be on the list, not in a transitory form on irc, or it won't involve the necessary parties Apr 23 21:24:06 lists, rather Apr 23 21:24:09 so it binds to packagegroup-core-boot Apr 23 21:24:20 khem: new build is breaking on those patches, looking at why Apr 23 21:24:45 kergoth: I disagree, I might be missing a design point that one can simply tell me here via IRC Apr 23 21:25:32 only a small subset of developers are on the channel, and of those, an even smaller subset overlap your time zone Apr 23 21:25:32 I'll continue this one on the mailing list though for sure Apr 23 21:26:17 kergoth: I know. Still IRC is a good place to ask why meta-ti has no gatesgarth branch, don't you agree? :) Apr 23 21:27:58 yes, but not so much the discussion of splitting a core packagegroup used by countless companies and projects. Apr 23 21:34:07 tgamblin: you need corresponding oe-core patches too Apr 23 21:34:20 that I have send for python related recipes Apr 23 21:35:23 vdl: I suggest you ask TI people on meta-ti list about gatesgarth plans. my understanding - there are no resources. and there are no TI people on this IRC channel Apr 23 21:49:22 khem: that'll do it Apr 23 22:03:41 vdl: I will say that the packagegroup stuff in oe-core has been around for a long time and predates containers. I helped design some of it, warts and all. At the time I'd imagined it evolving over time. Instead people have tended to use it or replace it with their own stuff. Replacing it was a design feature and is fine. Apr 23 22:04:21 vdl: I do think it needs updating. How I'm less sure about. A lot of us, me included worry about changes now as they tend to break things for existing users who aren't used to them changing Apr 23 22:04:56 vdl: I think we can change them but don't be surprised if there is inertia around not doing so as the potential risk is higher here Apr 23 23:35:27 RP: I was thinking about adding packagegroup-core-machine-boot as a dependency for packagegroup-core-boot, like packagegroup-base has internal dependency for packagegroup-machine-base and packagegroup-distro-base (the goal is that it won't make a difference for people using packagegroup-core-boot, but one can remove packagegroup-core-machine-boot if necessary, like for containers) Apr 24 02:11:56 vdl: what would be in packagegroup-core-machine-boot ? Apr 24 02:43:16 RP: the content of MACHINE_ESSENTIAL_EXTRA_RDEPENDS (i.e. usually kernel image and device tree) **** ENDING LOGGING AT Sat Apr 24 03:00:29 2021