<moto-timo>
yudjinn[m]: you can also use oe-pkgdata-util to query
alinucs has quit [Ping timeout: 276 seconds]
alinucs has joined #yocto
Tokamak has joined #yocto
Tokamak has quit [Ping timeout: 256 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #yocto
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
sakoman has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 258 seconds]
nemik has joined #yocto
seninha has quit [Remote host closed the connection]
dingo_ has joined #yocto
<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 ui
<dingo_>
errmm WHY
sakoman has quit [Quit: Leaving.]
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #yocto
mvlad has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
chep` has joined #yocto
<LetoThe2nd>
yo dudX
chep has quit [Ping timeout: 258 seconds]
chep` is now known as chep
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
m4ho has joined #yocto
bps3 has quit [Ping timeout: 255 seconds]
prabhakarlad has joined #yocto
dgriego has quit [Ping timeout: 246 seconds]
dgriego has joined #yocto
GNUmoon has quit [Read error: Connection reset by peer]
GNUmoon has joined #yocto
dev1990 has joined #yocto
<dingo_>
damn..! whats to add to get a bootable sdcard image of core-image-full-cmdline
<dingo_>
been toooo long
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<LetoThe2nd>
dingo_: 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.
<dingo_>
LetoThe2nd: its X86_64
<dingo_>
can i dd a wic to sdcard and boot?
<dingo_>
right
<LetoThe2nd>
dingo_: then i would say, look at meta-intel, and what its documentation says.
<LetoThe2nd>
dingo_: generally wic images are meant to be used in such ways, yes.
florian_kc has joined #yocto
Juanosorio94 has joined #yocto
seninha has joined #yocto
bps3 has joined #yocto
<Juanosorio94>
I 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?
<qschulz>
yes
florian__ has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
ptsneves has joined #yocto
<qschulz>
RP: nevermind the mail I just sent, didn't see the v2 you sent...
nagua[m] has quit [Quit: You have been kicked for being idle]
leon-anavi has quit [Quit: Leaving]
leon-anavi has joined #yocto
<RP>
qschulz: I got confused with branches :/
<wyre>
hi 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 images
<wyre>
but ... not sure if I can include SYSTEMD_SERVICE:<package_name> = "disabled" in the image recipe 🤔
xmn has quit [Quit: ZZZzzz…]
<RP>
wyre: you'd probably need to include a recipe in one of the images which disables or enables it
<wyre>
RP, but should I do in the way I pointed? (in this extra recipe)
<ptsneves>
wyre 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 toggled
<qschulz>
wyre: 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)
<qschulz>
wyre: once it grows too much, you're much better off defining a new distro
<qschulz>
wyre: you could also probably enable the systemd unit by hand from the image recipe itself?
<qschulz>
like run it directly within the rootfs directory
<qschulz>
RP: 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 :/
florian__ has quit [Ping timeout: 244 seconds]
<ptsneves>
qschulz try having a toddler sick at 4 in the morning. Then say "let's program" :D
<qschulz>
ptsneves: YOU MAKE YOUR SICK TODDLER PROGRAM AT 4AM????
<wyre>
ptsneves, 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 🤔
<wyre>
I'm guessing I cannot just include this in the image recipe because I need to inherit from systemd class, am I right?
<ptsneves>
qschulz :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.
<qschulz>
wyre: aren't those two packages incompatible then?
<wyre>
qschulz, packages aren't incompatible, but services are
<ptsneves>
wyre perhaps what you need is a MACHINE?
<qschulz>
wyre: 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 service
<wyre>
qschulz, that's not bad idea ... but not just for the systemd service, I think I may also include the api which starts the systemd service
<wyre>
but make this recipe/package depending on the core library
<wyre>
(actually I'm shipping the api along the core library in the very same recipe)
<ptsneves>
qschulz 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 parts
<ptsneves>
these kind of issues (always forget the these)
<wyre>
so I need the core library for the other recipe ... but not the api
<wyre>
so sure ... I think the best approach is to separate these things 😊
jpuhlman has quit [Ping timeout: 255 seconds]
<wyre>
(the second recipe is just for testing purposes)
<wyre>
(that's because I'm creating a separate image)
jpuhlman has joined #yocto
florian has joined #yocto
<ptsneves>
I am trying to create a fitImage recipe for selftest but for some reason it does not generate the fitImage when i do
<ptsneves>
KERNEL_CLASSES = "kernel-fitimage"
<ptsneves>
KERNEL_IMAGETYPES = "fitImage"
<ptsneves>
is 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 dir
<ptsneves>
but if i set KERNEL_IMAGETYPES="fitImage" the kernel recipe breaks
dgriego has quit [Ping timeout: 240 seconds]
dgriego has joined #yocto
<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.
<RP>
Saur[m]: do you have one of those broken python3 build directories anywhere, or an idea on how to reproduce the bug?
goliath has joined #yocto
xmn has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
rsalveti has quit [Quit: Connection closed for inactivity]
nemik has quit [Ping timeout: 258 seconds]
nemik has joined #yocto
<dvorkindmitry>
how can I write SRC_URI = (var == "X" ? "uri1" : "uri2") in compact way in the recipe?
<qschulz>
dvorkindmitry: SRC_URI = "${@"uri1" if d.getVar('var') == "X" else "uri2"}" i think should do the trick
<dvorkindmitry>
is it ok to "require other.bb" in first.bb?
<dingo_>
is IMAGE_INSTALL = " packagegroup-k8s-host " a viable way to add kubernetes to core-image-minimal ?
<Saur[m]>
dvorkindmitry: Sure, you can do that.
<Saur[m]>
dingo_: If you change "=" to "+=", it probably works better...
<Saur[m]>
Or you might need to use `IMAGE_INSTALL:append`, it depends on where you do it.
* RP
is getting nowhere with the python3 native issue :(
<Saur[m]>
RP: Ross wrote in the issue that he'd been able to reproduce it, but I honestly don't know how.
<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... :(
<RP>
Saur[m]: Ross is now out for two weeks
<Saur[m]>
Ok, good to know...
<RP>
Saur[m]: in the failed build what does the task_order log in temp/ say?
<RP>
(for a failed component)
<RP>
that would give an idea of what reran in the build and in what order
<Saur[m]>
task_order log?
<RP>
Saur[m]: something like tmp/work/x86_64-linux/python3-docutils-native/0.18.1-r0/temp/log.task_order
<Saur[m]>
Oh, never noticed that file.
<ptsneves>
:O
<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.
* RP
is struggling to find a thread on this to work with :(
Shaun has quit [Changing host]
Shaun has joined #yocto
<RP>
Saur[m]: can you tell when that build was last updated and any of the other version changes that took place in the build?
<Saur[m]>
But based on that, I do not understand why python3-docutils-native:compile ran in the first place.
<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...
<RP>
Saur[m]: It is really hard to say from my limited view but I can't spot anything there with a direct dependency on python3-docutils
<Saur[m]>
Neither can I. :(
<RP>
usually, python3-sphinx or librsvg would trigger it
<RP>
or if you had manpages enabled
<RP>
Saur[m]: does this build always build the same target end result or different targets?
<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.
<RP>
Saur[m]: any idea of the version of poky you went from/to?
<Saur[m]>
RP: c9303648f8 to 13d70e57f8, but I cannot see anything there which would explain the rebuild.
<RP>
Saur[m]: no, it would explain the systemd rebuild and that can cascade a bit but I'm not seeing anything either
<RP>
Saur[m]: the setuptools upgrade a few days earlier is more suspect
<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.
<RP>
Saur[m]: with or without rm_work and with or without hashequiv?
<RP>
Saur[m]: sorry for so many questions!
<Saur[m]>
Without either.
<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.
<RP>
Saur[m]: being without those rules out a load of things at least :)
<jaskij[m]>
I'm getting `SIGFPE si_code=FPE_INTDIV` when `wic` runs `fsck.ext4`, any tips on how to debug this?
<dingo_>
mmmm something not right... seems to want to add the kitchen sink, docker, k3s, k8s all of it
<dingo_>

<RP>
jaskij[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 cause
goliath has quit [Quit: SIGSEGV]
<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`
<jaskij[m]>
is what I get in the logs, along with a stack trace
<jaskij[m]>
`wic` itself is implemented in one of the layers under Poky, right? I might try bisecting it
<RP>
jaskij[m]: it is in oe-core, yes
<jaskij[m]>
thanks, I'll get to bisecting then
<RP>
jaskij[m]: it might depend on the data in the filesystem
<jaskij[m]>
Which didn't change much from the working build, except updating `meta-oe` and `meta-freescale`.
<jaskij[m]>
anyway, let me check
<jaskij[m]>
my layers didn't change at least
<RP>
jaskij[m]: I'm just worried it may depend on the content in the image, just something to be mindful of
<jaskij[m]>
RP: roger.
<jaskij[m]>
How much do I need to clean after each checkout? Is just running `bitbake -c cleansstate my-image` enough?
<dingo_>
meta-virtualization ok... this is broken... ./recipes-core/packagegroups/packagegroup-kubernetes.bb mentions and even RDEPENDS:packagegroup-kubernetes-base = " but there is no packagegroup-kubernetes-base anywhere in meta-virtualization
<RP>
jaskij[m]: in theory it shouldn't even need an image clean
<Saur[m]>
dingo_: The packagegroup-kubernetes-base package is produced by the packagegroup-kubernetes recipe.
<dingo_>
Saur[m]: okay however ... adding IMAGE_INSTALL:append += " packagegroup-k8s-host" to lcoal.conf literally adds like everything in recipes-containers/ folder
<dingo_>
something not right
<dingo_>
i would think it would only add kubernetes cri-o and other cni / oci thing. its literally adding docker, k3s and everything
<Saur[m]>
dingo_: Use `bitbake -g packagegroup-k8s-host` and look att the produced task-depends.dot file to see what pulls in what. You can also use `bitbake -g -u taskexp packagegroup-k8s-host` if you want a GUI.
<dingo_>
ERROR: Nothing PROVIDES 'packagegroup-k8s-host'. Close matches:
<dingo_>
packagegroup-meta-oe-test
<dingo_>
\cat task-depends.dot
<dingo_>
}
<dingo_>
digraph depends {
<dingo_>
nothing
<dingo_>
very odd
<dingo_>
if i add IMAGE_INSTALL:append += " packagegroup-k8s-host" to local.conf it adds everything
<qschulz>
dingo_: you cannot build a packagegroup
<dingo_>
if i add IMAGE_INSTALL += " packagegroup-k8s-host " to local.conf it adds literally nothing
<qschulz>
so bitbake packagegroup won't work
<dingo_>
qschulz: all im trying to do in include packagegroup-k8s-host to core-image-minimal
<qschulz>
dingo_: local.conf is parsed before the image recipe
<qschulz>
so if your image recipe has IMAGE_INSTALL = "something", it'll overwrite whatever is written in local.conf
<qschulz>
also, :append += shouldn't be used (and is in fact failing a build on kirkstone)
<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).
<qschulz>
Saur[m]: is this even possible?
<qschulz>
I don;'t think it is
<qschulz>
because a packagegroup is a virtual package which builds nothing
<qschulz>
hence, it cannot be part of DEPENDS of any recipe
<dingo_>
cant be, it adds the kitchen sink not just kubernetes / crio / cni
<qschulz>
and if it cannot be used in DEPENDS, bitbake cannot build it either
<Saur[m]>
Of course it is. The packagegroup recipes are normal recipes that can be built.
<dingo_>
even the kubernetes README says use packagegroup-k8s-host
<Saur[m]>
dingo_: Yes, but you have to differentiate between recipes and packages. RDEPENDS and IMAGE_INSTALL works on packages.
<smurray>
qschulz: packagegroups do generate packages,
<smurray>
qschulz: at least for rpm they do
<dingo_>
Saur[m]: again, so how do i include just the packagesgroup into core-image-minimal
<qschulz>
smurray: they do generate a package yes, but they do not PROVIDES anything
<smurray>
qschulz: right, just RPROVIDES
<qschulz>
if they don't PROVIDES antyhing, they cannot be built, but they can be added as runtime dependencies (because they are technically only packages)
<qschulz>
checking that right now
<Saur[m]>
dingo_: I would use `IMAGE_INSTALL:append = " packagegroup-k8s-host"`
<smurray>
qschulz: you can bitbake them, I've done it
<qschulz>
smurray: mmmm bitbake packagegroup-core-ssh-dropbear works
<dingo_>
you cant, as i explained its literally installing everything
<qschulz>
so I'm at loss
<dingo_>
Saur[m]: read what i said above ?
<dingo_>
if i add IMAGE_INSTALL:append += " packagegroup-k8s-host" to local.conf it adds everything, like literally everything k3s, kubernetes, docker, blah blah blah
<dingo_>
i just want kubernetes and crio, cni, oci
<dingo_>
i dont needs kubernetes and k3s and crio and docer and podman all on the same build
<dingo_>
its plainly and clearly broekne
<dingo_>
its plainly and clearly broken
<qschulz>
dingo_: are you reproducing this on vanilla poky+meta-virtualization?
<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.
<dingo_>
/home/dingo/stack/meta-virtualization \
<dingo_>
/home/dingo/stack/meta-security \
<dingo_>
/home/dingo/stack/meta-selinux \
<dingo_>
Saur[m]: wow... kubernetes as in k8s not k3s
<dingo_>
crio as in not docker
<dingo_>
and i dont need podman either
<dingo_>
k8s should be k8s crio, cni, oci
<dingo_>
hence packagegroup-k8s-host
<dingo_>
wheres for k3s there is also packagegroup-k3-host
<dingo_>
but they literally add everything, not just whats needed
<Saur[m]>
AFAICT, the only package that depends on podman, is packagegroup-podman, and there are no dependencies on packagegroup-podman.
<smurray>
the person you need is probably zeddii
<dingo_>
Saur[m]: yupp and im telling you its not true
<dingo_>
specifically k8s is the kubernetes package
<dingo_>
where - packagegroup-k3s-host is for k3s
<dingo_>
they were meant to be separated
<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.
<dingo_>
so according to logic - packagegroup-k8s-host installs kubenertes where packagegroup-k3s-host installs k3s
<dingo_>
Saur[m]: now you see how broken it is
<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?
<Saur[m]>
Because I can see no reason for the former to happen, but the latter is expected based on the current recipes.
<dingo_>
Saur[m]: so your saying its going to build them uselessly but not install them ?
GNUmoon has quit [Ping timeout: 240 seconds]
<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 kubernetes
<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.
<dingo_>
Saur[m]: thats broken
<dingo_>
ok ill let the build finish and show you everything gets installed
GNUmoon has joined #yocto
<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.
<dingo_>
Saur[m]: yet a seprate packagegorup exists for both k8s and k3s
<jaskij[m]>
Does `INSANE_SKIP` work in local.conf? I'm bisecting and `version-going-backwards` keeps popping up
<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.
<qschulz>
dingo_: a separate PACKAGE packagegroup exists yes. But they are both in the same packagegroup RECIPE
<dingo_>
we will see
<qschulz>
and a recipe is entirely built which creates all possible packages buildable by this recipe
<dingo_>
makes 0 sense to even process 1500 extra jobs
<qschulz>
dingo_: we're trying to explain why it is working this way today
<qschulz>
the proper way could be to split this into two separate *recipes*
<dingo_>
yeah most likely needed
florian has quit [Quit: Ex-Chat]
<qschulz>
jaskij[m]: I assume you'd need INSANE_SKIP:append in your local.conf for this to work?
<qschulz>
also if for a specific recipe, bbappend preferred, but INSANE_SKIP:pn-<recipe>:append could work too I'd guess
<dingo_>
qschulz: i expect its going to also install everything i dont need :)
<jaskij[m]>
qschulz: I'm bisecting the whole Poky, so local.conf solution required
<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.
<qschulz>
jaskij[m]: oof, poor you
<qschulz>
gl
<dingo_>
Saur[m]: i dont require containerd
<jaskij[m]>
Breaks my build, SIGFPE in fsck.ext4
<dingo_>
k8s = kubernetes, crio, oci, cni
<dingo_>
no docker, no containerd required
<Saur[m]>
dingo_: Well, then skip that dependency. Those three are the dependencies of packagegroup-k8s-host in the packagegroup-kubernetes recipe.
<jaskij[m]>
Might give up on doing that at work though. Home had better hardware. 5900X vs 3600.
<dingo_>
once this build is done, ill probably write a custom meta with packagesgroup this weekend
<Saur[m]>
I know nothing about either k8s and k3s, I only report what the recipes say.
<jaskij[m]>
Speaking of, I thought main version branches like `kirkstone` were safe to pull in blind
<jaskij[m]>
Apparently not
sakoman has joined #yocto
<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 k3s
<qschulz>
dingo_: please contribute to meta-virtualization if you think something can be improved
<qschulz>
jaskij[m]: version brainches are to be treated as development branches, only tags should be safe to pull in.
<qschulz>
jaskij[m]: but it's super nice if you do it and report bugs :)
<dingo_>
Saur[m]: whats funnier is its building even a bunch of x11 stuff
<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 ones
<Saur[m]>
dingo_: Example?
<qschulz>
jaskij[m]: well, let's say... both? :D
<qschulz>
usually if something goes really wrong in -next, it's caught but some bugs can go through that first filter I guess
<qschulz>
jaskij[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?
<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 that
<jaskij[m]>
the other bug I've found is unrelated to that (and already reported)
<sotaoverride>
does 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 of
<sotaoverride>
any sample scripts for the above would be highly and truly appreciated!
<Saur[m]>
dingo_: I do not see any dependencies on either of them in the task-depends.dot file for packagegroup-kubernetes. However, I do not have either x11 or wayland in my DISTRO_FEATURES, so I wouldn't expect to.
<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 task-depends.dot file. It should tell you exactly what depends on what.
<dingo_>
Saur[m]: i noticed it when i added openssh
<dingo_>
its basically systemd, openssh, wireguard-tools, k8s, crio, cni, oci is all
<dingo_>
all built from core-image-minimum-full-cmdline
<dingo_>
bitbake core-image-full-cmdline
<dingo_>
but cmdline, no need for x and freinds
<dingo_>
ill see whats in the final image
<Saur[m]>
dingo_: bitbake -g is really the only way to know why something is being built in your particular configuration.
<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`
<yudjinn[m]>
whats the best way to add a machine conf to a layer that is owned by a third party?
<jaskij[m]>
and iirc Poky did
<jaskij[m]>
submitted a patch
<jaskij[m]>
or just make your own layer
<qschulz>
yudjinn[m]: not do it :)
<qschulz>
or both options specified by jaskij[m] just above
<yudjinn[m]>
I know, I mean does it work to add the machine conf to my own layer?
<jaskij[m]>
sure does
<qschulz>
yudjinn[m]: of course, highly recommend not re-using the same name as a machien configuration file that already exists
<jaskij[m]>
plus, if your product is still under development, NDAs or otherwise might preclude submitting your machine upstream anyways
<yudjinn[m]>
tegra changed the machine conf from zeus->dunfell, so its mostly for backporting
<jaskij[m]>
iirc meta-tegra is community made, so you can try upstreaming a patch
<jaskij[m]>
would've been much harder with a first-party layer
rsalveti has joined #yocto
<yudjinn[m]>
nah, it's for an internal project and I'm assuming it was removed for a reason on upstream
<jaskij[m]>
yeah, the general advice is to not mess with upstream layers (patches or whatever) and just make your own layer
<jaskij[m]>
for a machine you just plop it in there, for packages you use `.bbappend`s
<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.
<RP>
Saur[m]: that is really interesting as I've been trying that and it works for me
<RP>
Saur[m]: since you have a failed build, could you see if that entry_points file is there please?
<RP>
Saur[m]: let me mail you the debug I've been using and we'll see what your version says
leon-anavi has quit [Quit: Leaving]
<RP>
Saur[m]: on its way to you
florian__ has joined #yocto
<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.
<RP>
Saur[m]: ok, that confirms what I suspected and it doesn't find the entry_points.txt file
<RP>
Saur[m]: really useful data but I don't know anything about that file. It is something to do with metadata in importlib
<RP>
moto-timo: do you know anything about that?
<RP>
Saur[m]: it is nice to at least isolate it to something
<RP>
Saur[m]: could you share a list of files under recipe-sysroot-native so I could compare with mine?
<moto-timo>
RP: not off the top of my head, but I’ll poke around a bit.
<Saur[m]>
RP: That's like 2500 files. What format would you like that in?
<Saur[m]>
RP: It's a 29MB tar ball if you want it as such.
<RP>
Saur[m]: I was just thinking of the file list but happy to have a tarball :)
<Saur[m]>
Well, I can do either.
<RP>
Saur[m]: tarball might save me asking more questions :)
<RP>
Saur[m]: I'm struggling a lot with it as I can't reproduce the thing!
<Saur[m]>
Ok, shall I mail it to you, or upload it somewhere?
<RP>
Saur[m]: is there somewhere you can upload it to? email should be ok but it is large
<moto-timo>
RP: 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.
camus has quit [Ping timeout: 240 seconds]
<RP>
moto-timo: Saur[m]'s build is running the right metadata.entry_points() call but getting no results
<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: https://pastebin.com/Mk5kfpha (i.e., basically nothing...)
<RP>
Saur[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?
<Saur[m]>
No, it was empty.
<RP>
I wonder if the old empty directory confuses things
<Saur[m]>
Oh, of course it is.
<Saur[m]>
I remember this now. I made a fix for something similar quite a while back.
<RP>
Saur[m]: can you try a clean, build up to configure, create that dir, then compile
<RP>
Saur[m]: I'm getting echos of this too
<RP>
what is odd is that I have that empty dir here and it doesn't break for me
<Saur[m]>
And commit 9d05227e910d3f374ba7a9763ff2584b9e40db61
camus has joined #yocto
<RP>
Saur[m]: so what we need to work out is why your build fails with this and mine does not
<Saur[m]>
RP: I guess it can have to do with the order the directories are found in the file system.
<RP>
Saur[m]: that is a depressing and scary thought!
<RP>
Saur[m]: I suspect you may be right. Let me see if I can find the code
<RP>
Saur[m], moto-timo: Reproduced and also avoided by sorted() or sorted(, reverse=True)
<RP>
Saur[m]: so it is disk ordering
<moto-timo>
oh dear lord
<RP>
I hate computers
<Saur[m]>
Well, it really is the fact that an empty directory is treated as if the egg exists, but sure...
<RP>
Saur[m]: there are a few questions here but we at least have an idea what the issue is which helps
<moto-timo>
Saur[m]: yeah, agreed... not that I know why but it sure seems that way (even from prior pain during the wheels work)
* moto-timo
had a lot of crufty old directories around
<moto-timo>
I probably should have been more concerned about it then.
fitzsim has quit [Remote host closed the connection]
fitzsim has joined #yocto
mckoan is now known as mckoan|away
<RP>
moto-timo, Saur[m]: patch sent
goliath has joined #yocto
<moto-timo>
RP: looks good. Thank you so much for diving in.
<RP>
moto-timo: not really any choice :(
<moto-timo>
RP: yeah... and you know I'm not thrilled either
<RP>
moto-timo: I know
<Saur[m]>
RP: Should there be a reference to bug 14816 in the commit message?
<RP>
Saur[m]: yes. I'll tweak locally
<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 password
<jclsn[m]>
Okay I also created an image an inherited core-image and populate_sdk_qt5. Maybe that is the reason...
<Juanosorio94>
I 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? ^^
<Saur[m]>
RP: I believe that the two commits I referred to earlier (for meson.bbclass and qemu.inc) can be reverted once your patch is in place.
<RP>
Saur[m]: quite likely, yes
<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 binaries
<RP>
Saur[m]: I've queued those
<moto-timo>
RP: nice that we can drop those two patches... good catch
<moto-timo>
Saur[m]: you as well... was watching ML not IRC ;)
<RP>
moto-timo: Saur[m] gets the credit, I should have put that in the commits
* RP
is tired
<Saur[m]>
:)
florian__ has quit [Ping timeout: 244 seconds]
<moto-timo>
Juanosorio94: 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.
<Juanosorio94>
moto-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 \
<Juanosorio94>
file://0001-juan-changes.patch
<Juanosorio94>
"
<moto-timo>
Juanosorio94: 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)
<Juanosorio94>
this is where the patch is located
<moto-timo>
Juanosorio94: but I have used a git url to e.g. a license file
<Juanosorio94>
moto-timo: the patch is inside files/ directory of my recipe
<moto-timo>
run bitbake -e on the recipe... you will see it is not resolving the path
<moto-timo>
we really need to see your recipe or bbappend
<Juanosorio94>
theres a lot of output :l
<Juanosorio94>
ok sec
<moto-timo>
Juanosorio94: yes, normally I pipe the output of bitbake -e to | less and then use / to search for what I am interested in
<moto-timo>
Juanosorio94: the pastebin you shared earlier had different filenames for the patches
<moto-timo>
those filenames have to be exact
<Juanosorio94>
i know but they are those :)
<moto-timo>
ah, 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.
<Juanosorio94>
how can I fix this?
juanosorio95 has joined #yocto
<RP>
jonmason: 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 though
<juanosorio95>
Just joining here cuz I need to logout from the other :)
juanosorio9599 has joined #yocto
<juanosorio9599>
The funny thing is when I apply manually it works
Juanosorio94 has quit [Ping timeout: 252 seconds]
juanosorio9599 has quit [Client Quit]
juanosorio95 has quit [Ping timeout: 252 seconds]
juanosorio95 has joined #yocto
juanosorio95 has quit [Quit: Client closed]
<Guest87>
whats the difference between master and master-next on the poky repository?
<landgraf>
Guest87: master-next is test branch for new patches.
<Guest87>
landgraf: thank you
Minvera has quit [Ping timeout: 252 seconds]
seninha has quit [Ping timeout: 255 seconds]
<Guest87>
i'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.")
florian__ has joined #yocto
<jonmason>
RP: thanks. I'll see about getting those added to meta-zephyr and verify that makes it work
ptsneves has joined #yocto
creich has joined #yocto
seninha has joined #yocto
vladest has joined #yocto
florian__ has quit [Ping timeout: 258 seconds]
jmiehe has quit [Quit: jmiehe]
<denix>
does sato run as root? or a regular user?
vladest has quit [Quit: vladest]
creich has quit [Quit: Leaving]
ptsneves has quit [Quit: Client closed]
Vonter has quit [Ping timeout: 240 seconds]
vmeson has quit [Remote host closed the connection]
vmeson has joined #yocto
seninha has quit [Remote host closed the connection]
Starfoxxes has joined #yocto
mvlad has quit [Remote host closed the connection]
florian__ has joined #yocto
<RP>
denix: it depends. It was possible to run as non-root on x86 I think but not sure if it is still enabled or not
<RP>
jonmason: it is a bit of a hack but worth testing to see if it is the only issue
<derRichard>
why 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 problems
kanavin has joined #yocto
kanavin_ has quit [Ping timeout: 260 seconds]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<RP>
derRichard: it has to be able to shutdown and store on disk and restart?
<RP>
derRichard: fray may remember more details
<RP>
derRichard: it would be interesting to see if there is info there which could help guide things though
alimon has quit [Remote host closed the connection]
<RP>
derRichard: partly the issue is we don't have anyone with time to spend on pseudo. I'm effectively the maintainer now :(
seninha has joined #yocto
ramacassis[m] has quit [Ping timeout: 240 seconds]
m4ho has quit [Ping timeout: 240 seconds]
<jonmason>
RP: the hack works for one system, running against all of them now