frgo has quit [Read error: Connection reset by peer]
frgo has joined #yocto
enok has quit [Quit: enok]
enok71 has joined #yocto
enok71 has quit [Ping timeout: 245 seconds]
savolla has joined #yocto
rfuentess has joined #yocto
Slimey has quit [Remote host closed the connection]
merit has quit [Ping timeout: 252 seconds]
Kubu_work has joined #yocto
wojci_ has joined #yocto
wojci_ has quit [Ping timeout: 252 seconds]
mrybczyn has joined #yocto
enok has joined #yocto
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 252 seconds]
<rburton>
there's potential confusion about the patch review call this morning because the monday one is pinned to US time. As it's far too early for americans to join the thursday morning call should be europe time so will be at the same time as usual.
<mrybczyn>
Same time for whom? EU or US? :)
<mrybczyn>
We have funny 3 weeks ahead
ablu has quit [Ping timeout: 252 seconds]
<mrybczyn>
I'm running in circles when searching for the right dependencies to use for yocto-vex-check. It comes in a standard python recipe, so if I add DEPEND in a class, I get a dependency loop. Not surprised. But when I add a task after do_rootfs from a recipe, it doesn't execute. What am I missing?
ablu has joined #yocto
<qschulz>
mrybczyn: tasks running AFTER another task aren't executed unless they are explicitly requested
<qschulz>
you may need a BEFORE <another task> as well
<qschulz>
in which case, if <another task> is requested, your task will be executed
<qschulz>
why that is? think about the menuconfig task for example, you want to have it running after the sources are fetched, patched, configured, but you don't want to have it executed all the time when building the recipe
<mrybczyn>
I think I had after in that task, will try it again
enok has quit [Ping timeout: 252 seconds]
enok71 has joined #yocto
alessio has quit [Read error: Connection reset by peer]
enok71 is now known as enok
alessio has joined #yocto
<mrybczyn>
It is running if I run the recipe directly, but not in an image build. Still missing a dependency somewhere
<qschulz>
when you bake the recipe directly, it calls do_build
<mrybczyn>
Yep, when I run it directly all is running fine. This is my complete chain that is missing something
<qschulz>
Are you including the package in IMAGE_INSTALL/PACKAGE_INSTALL or through another package's dependency?
<qschulz>
trying to see the big picture here
<mrybczyn>
this is a native-only recipe
<qschulz>
so added via DEPENDS in the image recipe?
<mrybczyn>
That is what I wanted to do but apparently doesn't work :)
<mrybczyn>
I'll trace it a little bit
<qschulz>
I vaguely remember that isn't possible because an image recipe isn't a typical recipe
<qschulz>
and therefore shouldn't need DEPENDS and SRC_URI and that kind of things
<qschulz>
like it's "wrong" to have to need those things in an image recipe
<qschulz>
mrybczyn: when/for what do you need this native recipe in your image recipe?
<qschulz>
you could add an explicit dependency with do_task[depends] += "my-recipe-native:do_other_task" for example
<mrybczyn>
I don't want to install anything. I want to use the tool generated by the recipe to postprocess the image
<qschulz>
in which task of the image specifically?
<qschulz>
(FWIW, it seems I was wrong with the DEPENDS, as image.bbclass does have a DEPENDS)
<mrybczyn>
all is there at
<mrybczyn>
ROOTFS_POSTPROCESS_COMMAND
<mrybczyn>
all the data I need, I mean
<RP>
mrybczyn: qschulz is right, you want something like do_correct_image_task[depends] += "recipe-native:do_populate_sysroot"
<RP>
you'll see other image dependencies for tools in that form
<qschulz>
mrybczyn: I assume you want a do_rootfs[depends] += thingy, c.f. meta/classes-recipe/image.bbclass
<qschulz>
mrybczyn: why I asked so many questions is that if it was a tool for a specific image type, you could have used something like IMAGE_DEPENDS_ or something similar (c.f. imagetypes_getdepends in meta/classes-recipe/image_types.bbclass)
<qschulz>
mrybczyn: let us know how that goes :)
<mrybczyn>
@qschulz does it work in recipes? I think I didn't go that path because I have seen that only in bbclass
<mrybczyn>
will try
<qschulz>
mrybczyn: you mean the do_rootfs[depends] += stanza?
<mrybczyn>
yes
<qschulz>
yes it works, that's essentially whart DEPENDS is translated to under the hood
<mrybczyn>
ok thanks will try that
enok has quit [Ping timeout: 260 seconds]
mrybczyn has quit [Quit: Client closed]
mrybczyn has joined #yocto
Ad0 has quit [Ping timeout: 248 seconds]
<mrybczyn>
If the message got lost: I can see it in the dependency graph, thanks @qschulz and @RP
ptsneves has joined #yocto
<qschulz>
mrybczyn: it did get lost, thanks for the update!
<wdouglass>
how do i configure a ubiblock image? right now my image recipe has `UBI_IMGTYPE="squashfs-lz4"` and `IMAGE_FSTYPES="squashfs-lz4 ubi"` but it seems that image_types.bbclass wants me to setup MKUBIFS_ARGS and UBINIZE_ARGS. I do not want a writable ubifs partition, just some block leveling protection for my squashfs image (which i'm updating with
<wdouglass>
rauc). is this documented anywhere?
<yocton>
khem: I'll try to put some of my coworker on in. It looks doable.
<khem>
yocton:cool, it will be helpful
<JPEW>
RP: I got the walking code to work. It works fine for build deps, but it only walks "one level" on the runtime deps