<tgamblin>
Has anyone seen an issue where, when creating a new layer with a different version of a recipe, said version can't be found even when setting PREFERRED_VERSION in local.conf?
<LetoThe2nd>
tgamblin: creating the layer doesn't do the trick, it is adding...
* LetoThe2nd
ducks and runs ;-)
* tgamblin
remembers to use -v on himself in the future
<tgamblin>
:)
g0hl1n has joined #yocto
goliath has quit [Quit: SIGSEGV]
g0hl1n has quit [Quit: leaving]
d-s-e has joined #yocto
g0hl1n has joined #yocto
<RP>
I wondered who added the deltask to externalsrc. Of course it was me at creation of the class 10 years ago :/
<d-s-e>
Hi, I have some recipes to build container images. This works fine, the image files are created in the iamge deploy dir. Now I would like to create a package containing all those images. For this I wrote a recipe that has all the container image recipes in DEPENDS, but none of them are created when I build that package. What am I doing wrong?
sotaoverride has joined #yocto
<qschulz>
d-s-e: DEPENDS mechanism takes (some) files installed during the do_install task of your dependency
<qschulz>
if you're looking into the deploy_dir, you need to add a dependency on the deploy_task
<qschulz>
do_deploy task*
<sotaoverride>
can someone walk me through the napkin math to help ensure rpi would be fast enough for running ffmpeg. I mostly just want to overlay text on high res video.
<rburton>
d-s-e: DEPENDS="foo" is shorthand for do_configure[depends] = "foo:do_populate_sysroot". Your container recipe doesnt' populate the sysroot, you want to explicitly depend on do_deploy.
<rburton>
which is basically what qschulz said :)
<sotaoverride>
if someone can help me understand rpi would indeed work fine with ffmpeg and high res videos (4k etc) Id get down to adding ffmpeg to rpi meta layer and building my application of top of it.
<d-s-e>
ah ok, the container recipes don't install anything, they don't create packages. what does this mean "add a dependency on the deploy_task"? do I need to add something to the container recipes or to the packaging recipe?
<qschulz>
sotaoverride: I would say you'd probably have more luck asking the ffmpeg folks for help on that. Once you have the settings figured out, then you can implement it in Yocto
<qschulz>
d-s-e: what do the container recipes do if they don't install anything?
<sotaoverride>
qschulz: makes sense. ill bug the ffmpeg folks first :P
<d-s-e>
qschulz: they create a tar file for example in build/tmp/deploy/images/raspberrypi4-64, that can be loaded into a container runtime.
<qschulz>
d-s-e: this is a task for the do_deploy task of your container recipes to install into build/tmp/deploy/images/raspberrypi4-64
<qschulz>
then in your package recipe, you need to have the task that depends on those files existing to depends on your container recipes do_deploy task
<qschulz>
this is done via do_sometask[depends] += "your-contrainer-image1:do_deploy"
<qschulz>
now, depending on your infrastructure this is also something that could be done directly in an image recipe for example, thus not requiring a special package recipe just for that
zpfvo has quit [Remote host closed the connection]
<dl9pf>
question: for ubuntu 18.04 as build host and kirkstone 4.0.11 - is buildtools tarball a requirement in that combination now ?
<dl9pf>
we do essentially see an issue with UNINATIVE_VERSION > 3.9 on kirkstone on a 18.04 buider
goliath has joined #yocto
florian_kc has quit [Quit: Ex-Chat]
el_gatito has quit [Ping timeout: 246 seconds]
florian has quit [Ping timeout: 250 seconds]
silurian_invader has quit [Ping timeout: 240 seconds]
frieder has quit [Remote host closed the connection]
florian has joined #yocto
mabnhdev has joined #yocto
<mabnhdev>
Hi all. Is there a way to prevent a particular recipe from being parsed for a particular machine?
<mabnhdev>
I'm working with Kirkstone. For compatibility, I have to downgrade glibc for one of the machines I support. Normally Kirkstone uses glibc 2.35. For my MIPS machine, I need to downgrade to 2.33. I did the downgrade for my MIPS platform with no problems, but now my other platforms (that I would like to stay at 2.35) are failing with
<mabnhdev>
complaints like the following "preferred version 2.35 of glibc not available (for item libsegfault)". I'm assuming if the glibc 2.33 recipe is not parsed when building my other machines, I should be okay?
pbsds has quit [Ping timeout: 260 seconds]
florian has quit [Ping timeout: 246 seconds]
florian has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
pbsds has joined #yocto
mabnhdev has quit [Quit: Client closed]
<g0hl1n>
hi, does anybody here ever tried to create a recipe for python3-httpx (or any other hatchling based pip module)? I'm unable to get rid of the "ERROR Backend 'hatchling.build' is not available." :-/ Any help or hints are greatly appreciated.
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mabnhdev has joined #yocto
<rburton>
g0hl1n: what does your recipe have in?
<rburton>
g0hl1n: inherit python_hatchling _should_ just work, so if you're not using that then there's your problem
<LetoThe2nd>
anybody have a runqemu invocation for initramfs e.g. core-image-minimal-initramfs handy?