Friday, 2022-05-27

*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Ping timeout: 252 seconds)00:04
*** mickeypash <mickeypash!~mickeypas@2a01:4b00:9e0e:6000:44ae:d27c:af7a:9198> has quit IRC (Quit: Client closed)00:16
*** seninha <seninha!~seninha@user/seninha> has joined #yocto00:18
*** dev1990 <dev1990!> has quit IRC (Quit: Konversation terminated!)00:23
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 256 seconds)00:24
smurrayyudjinn[m]: I believe you'd change that to python3-core, some things are in different packages now for 3 vs 200:25
*** zwelch <zwelch!> has joined #yocto00:26
*** Tokamak <Tokamak!> has joined #yocto00:28
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:55
*** Tokamak <Tokamak!> has quit IRC (Ping timeout: 255 seconds)01:00
moto-timoyudjinn[m]: you want to get used to looking into python3-manifest.json for the standard library items to see what sub-package they are in, as smurray said python3-core in this case
moto-timoyudjinn[m]: you can also use oe-pkgdata-util to query01:02
*** alinucs <alinucs!> has quit IRC (Ping timeout: 276 seconds)01:03
*** alinucs <alinucs!> has joined #yocto01:03
*** Tokamak <Tokamak!> has joined #yocto01:05
*** Tokamak <Tokamak!> has quit IRC (Ping timeout: 256 seconds)01:23
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 255 seconds)01:44
*** nemik <nemik!> has joined #yocto01:44
*** nemik <nemik!> has quit IRC (Ping timeout: 272 seconds)01:54
*** nemik <nemik!~nemik@> has joined #yocto01:54
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:55
*** starblue <starblue!> has quit IRC (Ping timeout: 244 seconds)01:58
*** starblue <starblue!> has joined #yocto02:00
*** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has quit IRC (Remote host closed the connection)02:12
*** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has joined #yocto02:14
*** sakoman <sakoman!> has joined #yocto02:23
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 272 seconds)02:38
*** nemik <nemik!> has joined #yocto02:39
*** nemik <nemik!> has quit IRC (Ping timeout: 258 seconds)02:43
*** nemik <nemik!~nemik@> has joined #yocto02:44
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection)03:22
*** dingo_ <dingo_!~quassel@> has joined #yocto04:05
dingo_pffft... what does adding CORE_IMAGE_EXTRA_INSTALL += "openssh kubernetes wireguard-tools podman podman-tui " to core-image-minimal include a full baked gnome ui04:08
dingo_errmm WHY04:08
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:39
*** gsalazar <gsalazar!> has quit IRC (Remote host closed the connection)05:14
*** gsalazar <gsalazar!> has joined #yocto05:14
*** mvlad <mvlad!~mvlad@2a02:2f08:4802:2100:24d7:51ff:fed6:906d> has joined #yocto05:39
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 255 seconds)05:54
*** nemik <nemik!> has joined #yocto05:54
*** nemik <nemik!> has quit IRC (Ping timeout: 255 seconds)05:59
*** nemik <nemik!~nemik@> has joined #yocto05:59
*** chep` <chep`!> has joined #yocto06:25
LetoThe2ndyo dudX06:26
*** chep <chep!> has quit IRC (Ping timeout: 258 seconds)06:27
*** chep` is now known as chep06:27
*** Wouter0100 <Wouter0100!> has quit IRC (Remote host closed the connection)06:36
*** Wouter0100 <Wouter0100!> has joined #yocto06:36
*** mckoan|away is now known as mckoan06:45
mckoangood morning06:45
*** m4ho <m4ho!~m4ho@> has joined #yocto06:50
*** bps3 <bps3!> has quit IRC (Ping timeout: 255 seconds)07:07
*** prabhakarlad <prabhakarlad!> has joined #yocto07:23
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 246 seconds)07:24
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto07:27
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Read error: Connection reset by peer)07:37
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:37
*** dev1990 <dev1990!> has joined #yocto07:42
dingo_damn..! whats to add to get a bootable sdcard image of core-image-full-cmdline07:49
dingo_been toooo long07:49
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)07:55
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:55
LetoThe2nddingo_: entirely depends on the bsp. but if that is remotely sane, then you should find something like "wic" in th deploy-images folder. if not, then you'll have to look at the bsps documentation.07:56
dingo_LetoThe2nd: its X86_6408:00
dingo_can i dd a wic to sdcard and boot?08:01
LetoThe2nddingo_: then i would say, look at meta-intel, and what its documentation says.08:01
LetoThe2nddingo_: generally wic images are meant to be used in such ways, yes.08:01
*** florian_kc <florian_kc!> has joined #yocto08:06
*** Juanosorio94 <Juanosorio94!> has joined #yocto08:08
*** seninha <seninha!~seninha@user/seninha> has joined #yocto08:14
*** bps3 <bps3!~bps@> has joined #yocto08:19
Juanosorio94I got a recipe from somebody, but it is only a .bb file which defines how to compile a kernel module. Do I need to integrate that to a layer to build this module?08:22
*** florian__ <florian__!> has joined #yocto08:24
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)08:27
*** ptsneves <ptsneves!> has joined #yocto08:30
qschulzRP: nevermind the mail I just sent, didn't see the v2 you sent...08:50
*** nagua[m] <nagua[m]!~nagua2hgo@2001:470:69fc:105::316d> has quit IRC (Quit: You have been kicked for being idle)09:00
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)09:04
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:06
RPqschulz: I got confused with branches :/09:10
wyrehi guys, I've got an app which I want to be shared in two different image recipes, but with its systemd service disabled in one of the images09:10
wyrebut ... not sure if I can include SYSTEMD_SERVICE:<package_name> = "disabled" in the image recipe 🤔09:11
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)09:13
RPwyre: you'd probably need to include a recipe in one of the images which disables or enables it09:13
wyreRP, but should I do in the way I pointed? (in this extra recipe)09:16
ptsneveswyre another way is that you put the common functionality of the app in an inc and create 2 recipes that include that common stuff and have the systemd stuff toggled09:17
qschulzwyre: no you cannot. go for ptsneves suggestion instead. however, this gets ugly REALLY fast if this app is a dependency of another recipe (you need two variants of that recipe then)09:21
qschulzwyre: once it grows too much, you're much better off defining a new distro09:21
qschulzwyre: you could also probably enable the systemd unit by hand from the image recipe itself?09:22
qschulzlike run it directly within the rootfs directory09:22
qschulzRP: yeah I figured :) having extra-work issues stressing me out a lot the last couple of weeks, brain is working only partially reliably. Sorry for the noise :/09:25
*** florian__ <florian__!> has quit IRC (Ping timeout: 244 seconds)09:28
ptsnevesqschulz try having a toddler sick at 4 in the morning. Then say "let's program" :D09:33
qschulzptsneves: YOU MAKE YOUR SICK TODDLER PROGRAM AT 4AM????09:34
wyreptsneves, qschulz, RP actually I need this service disabled in the other image because I'm including another recipe that needs the hardware resource (gpiochip) that this recipe I need to disable as a service reserves, so ... I guess I can include that SYSTEMD_SERVICE disable in this recipe 🤔09:36
wyreI'm guessing I cannot just include this in the image recipe because I need to inherit from systemd class, am I right?09:36
ptsnevesqschulz :D  :D. I! need to program the next day. Unfortunately he does not contribute to the expenses yet. XXI century child labor programmers are not a thing yet.09:37
qschulzwyre: aren't those two packages incompatible then?09:37
wyreqschulz, packages aren't incompatible, but services are09:37
ptsneveswyre perhaps what you need is a MACHINE?09:38
qschulzwyre: depending on how fine-grain you want to go and if it makes sense, but you could have a small package recipe just for the systemd service09:38
wyreqschulz, that's not bad idea ... but not just for the systemd service, I think I may also include the api which starts the systemd service09:39
wyrebut make this recipe/package depending on the core library09:39
wyre(actually I'm shipping the api along the core library in the very same recipe)09:39
ptsnevesqschulz i think you just touched on a good approach for this kind of issues. If you are having to need variants of a recipe it probably means you should break your recipe into smaller parts09:41
ptsnevesthese kind of issues (always forget the these)09:41
wyreso I need the core library for the other recipe ... but not the api09:41
wyreso sure ... I think the best approach is to separate these things 😊09:42
*** jpuhlman <jpuhlman!> has quit IRC (Ping timeout: 255 seconds)09:42
wyre(the second recipe is just for testing purposes)09:42
wyre(that's because I'm creating a separate image)09:42
*** jpuhlman <jpuhlman!> has joined #yocto09:43
*** florian <florian!> has joined #yocto09:47
ptsnevesI am trying to create a fitImage recipe for selftest but for some reason it does not generate the fitImage when i do10:00
ptsnevesKERNEL_CLASSES = "kernel-fitimage"10:00
ptsnevesKERNEL_IMAGETYPES = "fitImage"10:00
ptsnevesis there something else? I know that fitImage is a container format that actually contains the zImage (among others) inside. But i thought adding this to the kernel recipes was enough to get a fitImage on the deploy dir10:01
ptsnevesbut if i set KERNEL_IMAGETYPES="fitImage" the kernel recipe breaks10:02
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 240 seconds)10:03
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto10:07
Saur[m]wyre: Sound like you could just have the recipe package the library in a separate package. That's a common approach as bitbake should automatically pick up the runtime dependency on that package for any application packages that use the library.10:15
RPSaur[m]: do you have one of those broken python3 build directories anywhere, or an idea on how to reproduce the bug?10:25
*** goliath <goliath!~goliath@user/goliath> has joined #yocto10:32
*** xmn <xmn!> has joined #yocto10:37
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 255 seconds)10:54
*** nemik <nemik!> has joined #yocto10:54
*** rsalveti <rsalveti!> has quit IRC (Quit: Connection closed for inactivity)10:58
*** nemik <nemik!> has quit IRC (Ping timeout: 258 seconds)10:59
*** nemik <nemik!~nemik@> has joined #yocto10:59
dvorkindmitryhow can I write SRC_URI = (var == "X" ? "uri1" : "uri2") in compact way in the recipe?11:00
qschulzdvorkindmitry: SRC_URI = "${@"uri1" if d.getVar('var') == "X" else "uri2"}" i think should do the trick11:03
dvorkindmitryis it ok to "require" in
dingo_is  IMAGE_INSTALL = " packagegroup-k8s-host " a viable way to add kubernetes to core-image-minimal ?11:22
Saur[m]dvorkindmitry: Sure, you can do that.11:23
Saur[m]dingo_: If you change "=" to "+=", it probably works better...11:23
Saur[m]Or you might need to use `IMAGE_INSTALL:append`, it depends on where you do it.11:24
* RP is getting nowhere with the python3 native issue :(11:40
Saur[m]RP: Ross wrote in the issue that he'd been able to reproduce it, but I honestly don't know how.11:40
Saur[m]I have looked at my buildhistory, trying to figure out what caused the compile task to rerun, but I cannot find a reason. And if I try to make it happen, it of course builds just fine... :(11:42
RPSaur[m]: Ross is now out for two weeks11:42
Saur[m]Ok, good to know...11:42
RPSaur[m]: in the failed build what does the task_order log in temp/ say?11:43
RP(for a failed component)11:43
RPthat would give an idea of what reran in the build and in what order11:43
Saur[m]task_order log?11:45
RPSaur[m]: something like tmp/work/x86_64-linux/python3-docutils-native/0.18.1-r0/temp/log.task_order11:46
Saur[m]Oh, never noticed that file.11:48
Saur[m]Unfortunately, I do not have any failed build directories. I cleaned them one after the other to be able to complete the build.11:49
* RP is struggling to find a thread on this to work with :(11:51
RPSaur[m]: can you tell when that build was last updated and any of the other version changes that took place in the build?11:52
Saur[m]RP: Here are the buildstats for the failed build:
Saur[m]But based on that, I do not understand why python3-docutils-native:compile ran in the first place.11:54
Saur[m]Because looking at the task/tasksigs.txt in the buildhistory, only the signature for the python3-docutils-native:do_cve_check task had changed...11:56
RPSaur[m]: It is really hard to say from my limited view but I can't spot anything there with a direct dependency on python3-docutils11:58
Saur[m]Neither can I. :(11:58
RPusually, python3-sphinx or librsvg would trigger it11:58
RPor if you had manpages enabled11:59
RPSaur[m]: does this build always build the same target end result or different targets?11:59
Saur[m]I was just updating my layers to the latest (poky, meta-virtualization and some of our own) and rebuilding the image for the product I have on my desk.12:01
RPSaur[m]: any idea of the version of poky you went from/to?12:02
Saur[m]RP: c9303648f8 to 13d70e57f8, but I cannot see anything there which would explain the rebuild.12:04
RPSaur[m]: no, it would explain the systemd rebuild and that can cascade a bit but I'm not seeing anything either12:07
RPSaur[m]: the setuptools upgrade a few days earlier is more suspect12:07
Saur[m]RP: Hmm, you are probably right. I looked back further in the buildhistory, and I hadn't done a complete image build since poky 812ebb0227.12:12
RPSaur[m]: with or without rm_work and with or without hashequiv?12:28
RPSaur[m]: sorry for so many questions!12:28
Saur[m]Without either.12:28
Saur[m]RP: No worries. Any help I can give that takes us closer to an answer as to what is actually going on is positive.12:29
RPSaur[m]: being without those rules out a load of things at least :)12:30
jaskij[m]I'm getting `SIGFPE si_code=FPE_INTDIV` when `wic` runs `fsck.ext4`, any tips on how to debug this?12:39
dingo_mmmm something not right... seems to want to add the kitchen sink, docker, k3s, k8s all of it12:41
RPjaskij[m]: I noticed something like that on the autobuilder yesterday too. Not sure about debugging other than trying to narrow down the command and trying to replicate it and isolate the cause12:41
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)12:42
jaskij[m]`fsck.ext4 -pvfD /home/jaskij/yocto/build/tmp-glibc/work/imx8qxp_cgtsx8x-ultima-linux/ultima-image/1.0-r0/tmp-wic/rootfs_root.2.ext4 returned '8' instead of 0`12:42
jaskij[m]is what I get in the logs, along with a stack trace12:42
jaskij[m]`wic` itself is implemented in one of the layers under Poky, right? I might try bisecting it12:43
RPjaskij[m]: it is in oe-core, yes12:43
jaskij[m]thanks, I'll get to bisecting then12:43
RPjaskij[m]: it might depend on the data in the filesystem12:44
jaskij[m]Which didn't change much from the working build, except updating `meta-oe` and `meta-freescale`.12:44
jaskij[m]anyway, let me check12:45
jaskij[m]my layers didn't change at least12:45
RPjaskij[m]: I'm just worried it may depend on the content in the image, just something to be mindful of12:46
jaskij[m]RP: roger.12:47
jaskij[m]How much do I need to clean after each checkout? Is just running `bitbake -c cleansstate my-image` enough?12:48
dingo_meta-virtualization ok... this is broken... ./recipes-core/packagegroups/ mentions and even RDEPENDS:packagegroup-kubernetes-base = "  but there is no packagegroup-kubernetes-base anywhere in meta-virtualization12:52
RPjaskij[m]: in theory it shouldn't even need an image clean12:53
Saur[m]dingo_: The packagegroup-kubernetes-base package is produced by the packagegroup-kubernetes recipe.12:53
dingo_Saur[m]: okay however ... adding IMAGE_INSTALL:append += " packagegroup-k8s-host" to lcoal.conf literally adds like everything in recipes-containers/ folder12:55
dingo_something not right12:55
dingo_i would think it would only add kubernetes cri-o and other cni / oci thing. its literally adding docker, k3s and everything12:56
Saur[m]dingo_: Use `bitbake -g packagegroup-k8s-host` and look att the produced file to see what pulls in what. You can also use `bitbake -g -u taskexp packagegroup-k8s-host` if you want a GUI.12:58
dingo_Saur[m]: yeah13:00
dingo_ERROR: Nothing PROVIDES 'packagegroup-k8s-host'. Close matches:13:00
dingo_  packagegroup-boot13:00
dingo_  packagegroup-kubernetes RPROVIDES packagegroup-k8s-host13:00
dingo_  packagegroup-meta-oe-test13:00
dingo_  packagegroup-self-hosted13:00
dingo_\cat task-depends.dot13:03
dingo_digraph depends {13:03
dingo_very odd13:08
dingo_if i add IMAGE_INSTALL:append += " packagegroup-k8s-host"  to local.conf it adds everything13:09
qschulzdingo_: you cannot build a packagegroup13:10
dingo_if i add IMAGE_INSTALL += " packagegroup-k8s-host "  to local.conf it adds literally nothing13:10
qschulzso bitbake packagegroup won't work13:10
dingo_qschulz: all im trying to do in include packagegroup-k8s-host to core-image-minimal13:12
qschulzdingo_: local.conf is parsed before the image recipe13:14
qschulzso if your image recipe has IMAGE_INSTALL = "something", it'll overwrite whatever is written in local.conf13:15
qschulzalso, :append += shouldn't be used (and is in fact failing a build on kirkstone)13:15
Saur[m]dingo_: If you want to build the packagegroup-k8s-host package, then you need to build the packagegroup-kubernetes recipe (as the error indicates).13:15
qschulzSaur[m]: is this even possible?13:16
qschulzI don;'t think it is13:16
qschulzbecause a packagegroup is a virtual package which builds nothing13:16
qschulzhence, it cannot be part of DEPENDS of any recipe13:16
dingo_cant be, it adds the kitchen sink not just kubernetes / crio / cni13:16
qschulzand if it cannot be used in DEPENDS, bitbake cannot build it either13:16
Saur[m]Of course it is. The packagegroup recipes are normal recipes that can be built.13:16
dingo_even the kubernetes README says use packagegroup-k8s-host13:17
Saur[m]dingo_: Yes, but you have to differentiate between recipes and packages. RDEPENDS and IMAGE_INSTALL works on packages.13:17
smurrayqschulz: packagegroups do generate packages,13:17
smurrayqschulz: at least for rpm they do13:18
dingo_Saur[m]: again, so how do i include just the packagesgroup into core-image-minimal13:18
qschulzsmurray: they do generate a package yes, but they do not PROVIDES anything13:19
smurrayqschulz: right, just RPROVIDES13:19
qschulzif they don't PROVIDES antyhing, they cannot be built, but they can be added as runtime dependencies (because they are technically only packages)13:19
qschulzchecking that right now13:19
Saur[m]dingo_: I would use `IMAGE_INSTALL:append = " packagegroup-k8s-host"`13:19
smurrayqschulz: you can bitbake them, I've done it13:20
qschulzsmurray: mmmm bitbake packagegroup-core-ssh-dropbear works13:20
dingo_you cant, as i explained its literally installing everything13:20
qschulzso I'm at loss13:20
dingo_Saur[m]: read what i said above ?13:20
dingo_if i add IMAGE_INSTALL:append += " packagegroup-k8s-host"  to local.conf it adds everything, like literally everything k3s, kubernetes, docker, blah blah blah13:21
dingo_i just want kubernetes and crio, cni, oci13:21
dingo_i dont needs kubernetes and k3s and crio and docer and podman all on the same build13:22
dingo_its plainly and clearly broekne13:22
dingo_its plainly and clearly broken13:22
qschulzdingo_: are you reproducing this on vanilla poky+meta-virtualization?13:24
qschulzbasically, without any custom layer13:24
dingo_  /home/dingo/stack/poky/meta \13:29
dingo_  /home/dingo/stack/poky/meta-poky \13:29
dingo_  /home/dingo/stack/poky/meta-yocto-bsp \13:29
dingo_  /home/dingo/stack/meta-openembedded/meta-oe \13:29
dingo_  /home/dingo/stack/meta-openembedded/meta-python \13:29
dingo_  /home/dingo/stack/meta-openembedded/meta-networking \13:29
dingo_  /home/dingo/stack/meta-openembedded/meta-filesystems \13:29
Saur[m]dingo_: You want "kubernetes and crio, cni, oci", but you don't want "kubernetes and k3s and crio and docer and podman". I don't see how that makes sense.13:29
dingo_  /home/dingo/stack/meta-virtualization \13:29
dingo_  /home/dingo/stack/meta-security \13:29
dingo_  /home/dingo/stack/meta-selinux \13:29
dingo_Saur[m]: wow... kubernetes as in k8s not k3s13:29
dingo_crio as in not docker13:29
dingo_and i dont need podman either13:30
dingo_k8s should be k8s crio, cni, oci13:30
dingo_hence  packagegroup-k8s-host13:30
dingo_wheres for k3s there is also packagegroup-k3-host13:31
dingo_but they literally add everything, not just whats needed13:31
Saur[m]AFAICT, the only package that depends on podman, is packagegroup-podman, and there are no dependencies on packagegroup-podman.13:32
smurraythe person you need is probably zeddii13:33
dingo_Saur[m]: yupp and im telling you its not true13:34
dingo_zeddii: ping13:34
dingo_if hes alive :)13:34
dingo_Saur[m]: cat ../meta-virtualization/recipes-containers/kubernetes/README.md13:35
dingo_For a kubernetes controller:13:35
dingo_  - packagegroup-k8s-host13:35
dingo_specifically k8s is the kubernetes package13:35
dingo_where - packagegroup-k3s-host is for k3s13:36
dingo_they were meant to be separated13:36
Saur[m]So unless you add something that depends on packagegroup-podman or podman itself, you should not get it in your image. It will be built, however, since you depend on packagegroup-k8s-host, which comes from packagegroup-kubernetes, which in turn depends on packagegroup-container.13:37
dingo_so according to logic - packagegroup-k8s-host installs kubenertes where packagegroup-k3s-host installs k3s13:37
dingo_Saur[m]: now you see how broken it is13:38
Saur[m]dingo_: Ok, to go back a few steps, are you complaining that k3s and podman are installed in your image, or are you complaining that they are being built?13:40
Saur[m]Because I can see no reason for the former to happen, but the latter is expected based on the current recipes.13:41
dingo_Saur[m]: so your saying its going to build them uselessly but not install them ?13:41
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)13:42
dingo_because there is literally no reason to build any of it for k8s kubernetes, no need to build docker, podman, k3s at all for k8s kubernetes13:43
Saur[m]dingo_: bitbake needs to build everything that a recipe depends on to produce al packages that it has, and since packagegroup-kubernetes depends on both k8s and k3s, both will be built. Whether you then install either of the produced packages is a different matter.13:43
dingo_Saur[m]: thats broken13:43
dingo_ok ill let the build finish and show you everything gets installed13:44
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto13:44
Saur[m]dingo_: No it is not, it is the way it has to be. What can be considered broken is to have a common packagegroup-kubernetes recipes that produce both packages, rather than have separate packagegroup recipes for the k8s and the k3s sides.13:44
dingo_Saur[m]: yet a seprate packagegorup exists for both k8s and k3s13:45
jaskij[m]Does `INSANE_SKIP` work in local.conf? I'm bisecting and `version-going-backwards` keeps popping up13:46
Saur[m]Yet again, both of those packages are produced byt eh same recipe. And a recipe will always produce all its packages, whether you intend to install all or some of them.13:46
qschulzdingo_: a separate PACKAGE packagegroup exists yes. But they are both in the same packagegroup RECIPE13:47
dingo_we will see13:47
qschulzand a recipe is entirely built which creates all possible packages buildable by this recipe13:47
dingo_makes 0 sense to even process 1500 extra jobs13:47
qschulzdingo_: we're trying to explain why it is working this way today13:48
qschulzthe proper way could be to split this into two separate *recipes*13:48
dingo_yeah most likely needed13:48
*** florian <florian!> has quit IRC (Quit: Ex-Chat)13:49
qschulzjaskij[m]: I assume you'd need INSANE_SKIP:append in your local.conf for this to work?13:49
qschulzalso if for a specific recipe, bbappend preferred, but INSANE_SKIP:pn-<recipe>:append could work too I'd guess13:50
dingo_qschulz: i expect its going to also install everything i dont need :)13:50
jaskij[m]qschulz: I'm bisecting the whole Poky, so local.conf solution required13:50
Saur[m]dingo_: If you instead of depending on packagegroup-k8s-host depend on "kubernetes packagegroup-containerd packagegroup-oci", then you should get what you want. A bit less generic though.13:51
qschulzjaskij[m]: oof, poor you13:51
dingo_Saur[m]: i dont  require containerd13:52
jaskij[m]Breaks my build, SIGFPE in fsck.ext413:52
dingo_k8s  = kubernetes, crio, oci, cni13:52
dingo_no docker, no containerd required13:52
Saur[m]dingo_: Well, then skip that dependency.  Those three are the dependencies of packagegroup-k8s-host in the packagegroup-kubernetes recipe.13:52
jaskij[m]Might give up on doing that at work though. Home had better hardware. 5900X vs 3600.13:53
dingo_once this build is done, ill probably write a custom meta with packagesgroup this weekend13:53
Saur[m]I know nothing about either k8s and k3s, I only report what the recipes say.13:54
jaskij[m]Speaking of, I thought main version branches like `kirkstone` were safe to pull in blind13:54
jaskij[m]Apparently not13:54
*** sakoman <sakoman!> has joined #yocto13:54
dingo_Saur[m]: basically k8s and k3s yes both kubernetes, yet the way its structured is k8s is kubeadm, kubectl, kubelet, where k3s is the all in one k3s13:55
qschulzdingo_: please contribute to meta-virtualization if you think something can be improved13:55
qschulzjaskij[m]: version brainches are to be treated as development branches, only tags should be safe to pull in.13:56
qschulzjaskij[m]: but it's super nice if you do it and report bugs :)13:56
dingo_Saur[m]: whats funnier is its building even a bunch of x11 stuff13:57
jaskij[m]qschulz: That's what I get for not reading the docs :P I've seen `-next` version branches and thought *those* were the dev ones13:58
Saur[m]dingo_: Example?13:58
qschulzjaskij[m]: well, let's say... both? :D13:58
qschulzusually if something goes really wrong in -next, it's caught but some bugs can go through that first filter I guess13:59
dingo_10: libx11-1_1.8-r0, gnome-desktop wayland13:59
jaskij[m]qschulz: Fair enough14:00
qschulzjaskij[m]: I might be wrong though but I've always treated branches as "work-in-progress-for-next-tag", maybe my expectations are too low?14:00
jaskij[m]I usually just pulled the branch whenever I had a time for a larger build, and it's the first time I've hit an actual bug related to that14:01
jaskij[m]the other bug I've found is unrelated to that (and already reported)14:02
sotaoverridedoes anyone have any init scripts for setting up overlay mounts? my bsp is setup a very werid way (cant just cherry pick into openembedded-core, would have to make a fork and ge tthe git submodule setup right etc etc), so I have decided just to initialize the filesystem overlay using a script during boot.. looking for any example scripts to go off of14:03
sotaoverrideany sample scripts for the above would be highly and truly appreciated!14:04
Saur[m]dingo_: I do not see any dependencies on either of them in the file for packagegroup-kubernetes. However, I do not have either x11 or wayland in my DISTRO_FEATURES, so I wouldn't expect to.14:04
Saur[m]dingo_: But if you want to know why you see them being built, then run `bitbake packagegroup-kubernetes -g` and look at the produced file. It should tell you exactly what depends on what.14:05
dingo_Saur[m]: i noticed it when i added openssh14:05
dingo_its basically systemd, openssh, wireguard-tools, k8s, crio, cni, oci is all14:06
dingo_all built from core-image-minimum-full-cmdline14:06
dingo_bitbake core-image-full-cmdline14:07
dingo_but cmdline, no need for x and freinds14:07
dingo_ill see whats in the final image14:07
Saur[m]dingo_: bitbake -g is really the only way to know why something is being built in your particular configuration.14:08
jaskij[m]dingo_: run `bitbake core-image-full-cmdline -e | grep DISTRO_FEATURES`. Iirc there were some issues with `vim` recipe building `gvim` if you have X11 or something in `DISTRO_FEATURES`14:10
yudjinn[m]whats the best way to add a machine conf to a layer that is owned by a third party?14:10
jaskij[m]and iirc Poky did14:10
jaskij[m]submitted a patch14:10
jaskij[m]or just make your own layer14:10
qschulzyudjinn[m]: not do it :)14:12
qschulzor both options specified by jaskij[m] just above14:12
yudjinn[m]I know, I mean does it work to add the machine conf to my own layer?14:12
jaskij[m]sure does14:13
qschulzyudjinn[m]: of course, highly recommend not re-using the same name as a machien configuration file that already exists14:13
jaskij[m]plus, if your product is still under development, NDAs or otherwise might preclude submitting your machine upstream anyways14:13
yudjinn[m]tegra changed the machine conf from zeus->dunfell, so its mostly for backporting14:14
jaskij[m]iirc meta-tegra is community made, so you can try upstreaming a patch14:16
jaskij[m]would've been much harder with a first-party layer14:17
*** rsalveti <rsalveti!> has joined #yocto14:17
yudjinn[m]nah, it's for an internal project and I'm assuming it was removed for a reason on upstream14:18
jaskij[m]yeah, the general advice is to not mess with upstream layers (patches or whatever) and just make your own layer14:21
jaskij[m]for a machine you just plop it in there, for packages you use `.bbappend`s14:21
Saur[m]RP: Based on your notes in the issue, if I revert the update of python3-setuptools, remove the sstate-cache for python3-docutils-native, rebuild it, update python3-setuptools again and finally rebuild python3-docutils-native again, then I get the error.14:25
RPSaur[m]: that is really interesting as I've been trying that and it works for me14:25
RPSaur[m]: since you have a failed build, could you see if that entry_points file is there please?14:26
Saur[m]RP: tmp/work/x86_64-linux/python3-docutils-native/0.18.1-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/setuptools-62.3.1.dist-info/entry_points.txt exists14:27
yudjinn[m]jaskij: it has been "plopped" ;p14:27
RPSaur[m]: let me mail you the debug I've been using and we'll see what your version says14:28
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)14:32
RPSaur[m]: on its way to you14:32
*** florian__ <florian__!> has joined #yocto14:35
Saur[m]RP: With your changes in place, all I got in the log was "Has 8 False" and "Has 8.1 False", repeated twice.14:39
RPSaur[m]: ok, that confirms what I suspected and it doesn't find the entry_points.txt file14:40
RPSaur[m]: really useful data but I don't know anything about that file. It is something to do with metadata in importlib14:41
RPmoto-timo: do you know anything about that?14:41
RPSaur[m]: it is nice to at least isolate it to something14:42
RPSaur[m]: could you share a list of files under recipe-sysroot-native so I could compare with mine?14:42
moto-timoRP: not off the top of my head, but I’ll poke around a bit.14:45
Saur[m]RP: That's like 2500 files. What format would you like that in?14:46
Saur[m]RP: It's a 29MB tar ball if you want it as such.14:51
RPSaur[m]: I was just thinking of the file list but happy to have a tarball :)14:54
Saur[m]Well, I can do either.14:55
RPSaur[m]: tarball might save me asking more questions :)14:55
RPSaur[m]: I'm struggling a lot with it as I can't reproduce the thing!14:55
Saur[m]Ok, shall I mail it to you, or upload it somewhere?14:55
RPSaur[m]: is there somewhere you can upload it to? email should be ok but it is large14:56
moto-timoRP: caught up on the bugzilla… smells like the vendored distutils. We can turn that off, but better to get deeper if not to the bottom of the issue at hand.15:03
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)15:03
RPmoto-timo: Saur[m]'s build is running the right metadata.entry_points() call but getting no results15:05
Saur[m]RP: I save away the sysroot, ran `bitbake python3-docutils-native -c cleansstate` followed by `bitbake python3-docutils-native` and finally compared the stored sysroot with the new (working) one, and excluding changes to .pyc files, these are the only differences I see: (i.e., basically nothing...)15:06
RPSaur[m]: Only in python3-docutils-native-recipe-sysroot-native/usr/lib/python3.10/site-packages: setuptools-59.5.0.dist-info - does that have files in?15:07
Saur[m]No, it was empty.15:08
RPI wonder if the old empty directory confuses things15:08
Saur[m]Oh, of course it is.15:08
Saur[m]I remember this now. I made a fix for something similar quite a while back.15:09
RPSaur[m]: can you try a clean, build up to configure, create that dir, then compile15:09
RPSaur[m]: I'm getting echos of this too15:09
RPwhat is odd is that I have that empty dir here and it doesn't break for me15:10
moto-timoThat is tickling my memory as well…15:13
Saur[m]RP, moto-timo: Commit 47d9d90b4ec7d04d6f3f1a9b97c0ab7f1264a88e15:15
Saur[m]And commit 9d05227e910d3f374ba7a9763ff2584b9e40db6115:16
*** camus <camus!~Instantbi@2409:8a1e:9115:c150:4597:2d3a:a62d:efb0> has joined #yocto15:18
RPSaur[m]: so what we need to work out is why your build fails with this and mine does not15:19
Saur[m]RP: I guess it can have to do with the order the directories are found in the file system.15:20
RPSaur[m]: that is a depressing and scary thought!15:21
RPSaur[m]: I suspect you may be right. Let me see if I can find the code15:22
RPSaur[m], moto-timo: Reproduced and also avoided by sorted() or sorted(, reverse=True)15:36
RPSaur[m]: so it is disk ordering15:36
moto-timooh dear lord15:37
RPI hate computers15:37
Saur[m]Well, it really is the fact that an empty directory is treated as if the egg exists, but sure...15:37
RPSaur[m]: there are a few questions here but we at least have an idea what the issue is which helps15:38
moto-timoSaur[m]: yeah, agreed... not that I know why but it sure seems that way (even from prior pain during the wheels work)15:38
* moto-timo had a lot of crufty old directories around15:38
moto-timoI probably should have been more concerned about it then.15:39
*** fitzsim <fitzsim!> has quit IRC (Remote host closed the connection)15:45
*** fitzsim <fitzsim!> has joined #yocto15:46
*** mckoan is now known as mckoan|away16:06
RPmoto-timo, Saur[m]: patch sent16:08
*** goliath <goliath!~goliath@user/goliath> has joined #yocto16:10
moto-timoRP: looks good. Thank you so much for diving in.16:10
RPmoto-timo: not really any choice :(16:11
moto-timoRP: yeah... and you know I'm not thrilled either16:11
RPmoto-timo: I know16:11
Saur[m]RP: Should there be a reference to bug 14816 in the commit message?16:13
RPSaur[m]: yes. I'll tweak locally16:14
jclsn[m]Is there a default user and password since kirkstone? I just moved to kirkstone for my Pi image and the splash screen is gone + I am prompted for a password. Before it was just root and no password16:15
jclsn[m]Okay I also created an image an inherited core-image and populate_sdk_qt5. Maybe that is the reason...16:18
Juanosorio94I am trying to patch a git repository which is local, and which my recipe fetches through file protocol. Applying the patch by myself inside the repo works, but when building the recipe it says "No File to patch. Skipping patch", even though the message 'applying patfch on "working/dir" ' seems to be correct. Anyone any ideas? ^^16:20
Saur[m]RP: I believe that the two commits I referred to earlier (for meson.bbclass and can be reverted once your patch is in place.16:21
RPSaur[m]: quite likely, yes16:23
jaskij[m]qschulz: after checking out `kirkstone-4.0.1` I'm having some weird issue with QA complaining about `linux-firmware` having architecture-specific binaries16:25
RPSaur[m]: I've queued those16:25
moto-timoRP: nice that we can drop those two patches... good catch16:26
moto-timoSaur[m]: you as well... was watching ML not IRC ;)16:27
RPmoto-timo: Saur[m] gets the credit, I should have put that in the commits16:28
* RP is tired16:28
*** florian__ <florian__!> has quit IRC (Ping timeout: 244 seconds)16:28
moto-timoJuanosorio94: are you checking out the local git repository in your recipe (or a bbappends) or... how are you telling bitbake where the patch is? We need more info to help.16:29
Juanosorio94moto-timo: this is how ive set src_uri inside my .bb file for my recipe,  SRC_URI += "git:///home/juan/juans-module/;branch=master;protocol=file \16:33
Juanosorio94                                            file://0001-juan-changes.patch16:33
Juanosorio94                                         "16:33
moto-timoJuanosorio94: the patch file needs to be in your recipe filespace... or you can add the full path in the SRC_URI perhaps... I haven't tried to do something like this before. Normally I would just copy the patch to the files/ for the recipe (or bbapend)16:35
Juanosorio94this is where the patch is located16:36
moto-timoJuanosorio94: but I have used a git url to e.g. a license file16:36
Juanosorio94moto-timo: the patch is inside files/ directory of my recipe16:36
moto-timorun bitbake -e on the recipe... you will see it is not resolving the path16:36
moto-timowe really need to see your recipe or bbappend16:37
Juanosorio94theres a lot of output :l16:38
Juanosorio94ok sec16:38
moto-timoJuanosorio94: yes, normally I pipe the output of bitbake -e to | less and then use / to search for what I am interested in16:41
Juanosorio94yeah but I dont know what to search for exactly xD. Anyways, heres my recipe
moto-timoJuanosorio94:  bitbake is looking for your patches in FILESPATH=, so that is the variable you need to make sure is being resolved properly16:52
moto-timoJuanosorio94: can you run "tee" on the directory where the recipe lives?16:53
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto16:54
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 252 seconds)16:57
Juanosorio94moto-timo: do you mean tree?16:58
moto-timoJuanosorio94: yes, sorry...16:58
* moto-timo typing tee 1000s of times a day16:58
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto16:59
* moto-timo exaggerates sometimes16:59
Juanosorio94├── conf16:59
Juanosorio94│   └── layer.conf16:59
Juanosorio94├── COPYING.MIT16:59
Juanosorio94├── README16:59
Juanosorio94├── recipes-example16:59
Juanosorio94│   └── example16:59
Juanosorio94│       └── example_0.1.bb16:59
Juanosorio94└── recipes-sx-pceax16:59
Juanosorio94    └── sx-pceax16:59
Juanosorio94        ├── files16:59
Juanosorio94        │   ├── 0001-Fix-compiler-warnings-errors-for-wlan_cnss_core_pcie.patch16:59
Juanosorio94        │   ├── 0002-Prevent-use-of-hardcoded-compiler-optimization-for-s.patch16:59
Juanosorio94        │   ├── ...16:59
Juanosorio94        └── sx-pceax.bb16:59
moto-timoJuanosorio94: the pastebin you shared earlier had different filenames for the patches17:00
moto-timothose filenames have to be exact17:00
Juanosorio94i know but they are those :)17:00
moto-timoah, it is picking up the patch files but failing to resolve the path to the file to be patched. So it is the format of the patches that is the issue.17:04
Juanosorio94how can I fix this?17:05
*** juanosorio95 <juanosorio95!> has joined #yocto17:08
RPjonmason: there is a workaround in bugzilla for that gcc-runtime thing. More analysis needed, I don't know why it is happening, whether we need to worry or not. It is "good" it is limited to two configuration things though17:08
juanosorio95Just joining here cuz I need to logout from the other :)17:09
*** juanosorio9599 <juanosorio9599!~juanosori@2a02:3036:9:740a:ced:9d20:e039:fe1c> has joined #yocto17:12
juanosorio9599The funny thing is when I apply manually it works17:12
*** Juanosorio94 <Juanosorio94!> has quit IRC (Ping timeout: 252 seconds)17:13
*** juanosorio9599 <juanosorio9599!~juanosori@2a02:3036:9:740a:ced:9d20:e039:fe1c> has quit IRC (Client Quit)17:15
*** juanosorio95 <juanosorio95!> has quit IRC (Ping timeout: 252 seconds)17:16
*** juanosorio95 <juanosorio95!~juanosori@2a02:3036:9:740a:ced:9d20:e039:fe1c> has joined #yocto17:19
*** juanosorio95 <juanosorio95!~juanosori@2a02:3036:9:740a:ced:9d20:e039:fe1c> has quit IRC (Quit: Client closed)17:26
Guest87whats the difference between master and master-next on the poky repository?17:32
landgrafGuest87: master-next is test branch for new patches.17:34
Guest87landgraf: thank you17:35
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Ping timeout: 252 seconds)17:41
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 255 seconds)17:45
Guest87i'm trying to follow the guide in the toaster manual, and am running into a problem at step 6 of 3.9.2. django.db.utils.OperationalError: (3780, "Referencing column 'customimagepackage_id' and referenced column 'package_ptr_id' in foreign key constraint 'orm_customimagepacka_customimagepackage_i_b48c5573_fk_orm_custo' are incompatible.")17:50
*** florian__ <florian__!> has joined #yocto17:52
jonmasonRP: thanks.  I'll see about getting those added to meta-zephyr and verify that makes it work17:54
*** ptsneves <ptsneves!> has joined #yocto18:17
*** creich <creich!> has joined #yocto18:27
*** seninha <seninha!~seninha@user/seninha> has joined #yocto18:53
*** vladest <vladest!~Thunderbi@2a02:1210:76b7:7100:3ce8:9a71:d6ab:fe33> has joined #yocto18:59
*** florian__ <florian__!> has quit IRC (Ping timeout: 258 seconds)19:16
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)19:20
denixdoes sato run as root? or a regular user?19:36
*** vladest <vladest!~Thunderbi@2a02:1210:76b7:7100:3ce8:9a71:d6ab:fe33> has quit IRC (Quit: vladest)19:37
*** creich <creich!> has quit IRC (Quit: Leaving)19:57
*** ptsneves <ptsneves!> has quit IRC (Quit: Client closed)20:08
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)20:33
*** vmeson <vmeson!> has quit IRC (Remote host closed the connection)20:37
*** vmeson <vmeson!> has joined #yocto20:39
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection)20:42
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has joined #yocto21:07
*** mvlad <mvlad!~mvlad@2a02:2f08:4802:2100:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)21:15
*** florian__ <florian__!> has joined #yocto21:19
RPdenix: it depends. It was possible to run as non-root on x86 I think but not sure if it is still enabled or not21:35
RPjonmason: it is a bit of a hack but worth testing to see if it is the only issue21:35
derRichardwhy is pseudo not storing fhandles (via name_to_handle_at) instead of plain inode numbers in the database? using name_to_handle_at would solve all the inode-reuse problems21:40
*** kanavin <kanavin!~Alexander@> has joined #yocto21:46
*** kanavin_ <kanavin_!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Ping timeout: 260 seconds)21:48
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)22:01
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22:02
RPderRichard: it has to be able to shutdown and store on disk and restart?22:14
RPderRichard: fray may remember more details22:14
RPderRichard: it would be interesting to see if there is info there which could help guide things though22:15
*** alimon <alimon!~alimon@> has quit IRC (Remote host closed the connection)22:15
RPderRichard: partly the issue is we don't have anyone with time to spend on pseudo. I'm effectively the maintainer now :(22:15
*** seninha <seninha!~seninha@user/seninha> has joined #yocto22:19
*** ramacassis[m] <ramacassis[m]!~ramacassi@2001:470:69fc:105::2:1958> has quit IRC (Ping timeout: 240 seconds)22:24
*** m4ho <m4ho!~m4ho@> has quit IRC (Ping timeout: 240 seconds)22:24
jonmasonRP: the hack works for one system, running against all of them now22:31
jonmasonAssuming I don't have network issues again22:32
*** ramacassis[m] <ramacassis[m]!~ramacassi@2001:470:69fc:105::2:1958> has joined #yocto22:36
*** m4ho <m4ho!~m4ho@> has joined #yocto22:37
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto22:50
RPjonmason: that probably moves it to a "can be fixed after M1" state?23:06
RPi.e. an annoying config issue rather than gcc12 being a total failure23:06
* RP suspends23:07
jonmasonRP: everything passes (that normally passes).  So, I agree that it shouldn't hold up M123:17
*** alefir <alefir!> has quit IRC (Remote host closed the connection)23:21
*** camus1 <camus1!~Instantbi@> has joined #yocto23:42
*** camus <camus!~Instantbi@2409:8a1e:9115:c150:4597:2d3a:a62d:efb0> has quit IRC (Ping timeout: 250 seconds)23:43
*** camus1 is now known as camus23:43

Generated by 2.17.2 by Marius Gedminas - find it at!