<Ablu[m]>
Hi all, is there a way to get the version number of a recipe within foo_%.bbappend file? ${PV} just seems to be % there 🤔...
xmn has quit [Remote host closed the connection]
xmn has joined #yocto
<mcfrisk>
Ablu[m]: PV and PR will be set within a bitbake task for sure, even if the task code came from a bbappend
<Ablu[m]>
mcfrisk: Hm. I do prepend `FILESEXTRAPATHS:prepend := "${THISDIR}/qemu-${PV}:"`. In order to load .patches from there. Would you have a recommendation what a good task would be to handle such kind of stuff? Of course I could patch things manually in do_patch, but then I loose all the automatic *.patch iteration benefits.
camus1 has joined #yocto
<mcfrisk>
Ablu[m]: you have a generic, non-versioned bbappend and want to apply version specific patches? I don't see any recipes doing that so maybe at bbappend parsing time PV is not set. cargo-cross-canadian is adding PV to path in recipe itself, after PV has been set, and that works.
<DvorkinDmitry>
yocton, thank you!
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
manuel1985 has joined #yocto
ptsneves1 has joined #yocto
<Ablu[m]>
mcfrisk: Right... It may be a bit of a weird thing to do... Mostly I want to apply the patches in a way that things break loudly if a new version is released where I need to update the patches. If I just do version-specific .bbappends then it would just silently drop the patch and there would only be a warning in the log about not recipe being available for that .bbappend...
Patrick2 has joined #yocto
<qschulz>
Ablu[m]: it should fail by default
<qschulz>
c.f. BB_DANGLINGAPPENDS_WARNONLY
<qschulz>
so hunt the layer that enables this and shout at them for doing so
<Patrick2>
Hi, i get an error while building an SDK: ERROR: core-image-minimal-1.0-r0 do_populate_sdk: Could not invoke dnf.
<Patrick2>
I thought it should not happen because libdnf-native should have been built before? https://dpaste.org/q6HBT
<Ablu[m]>
qschulz: Oh interesting. Though I can imagine which one does it... We share this recipe across different Yocto versions without branching. So I guess fixing that would be a better spent of time...
<Patrick2>
Ablu[m] thanks, looks like this! This is caused because the machine i have created has some flaws ? I will check that again.
<Saur[m]>
Ablu[m]: The way we handle that is we have our main layer work with one version of OE (currently Langdale). Then we have an adaptation layer where we handle all changes that need to be done to work with another version of OE (i.e., master in our case). A common case then is that we have updated the version of a recipe from OE in our main layer. We do this using versioned bbappends, which typically then contain `PV` and
<Saur[m]>
`SRCREV`/`SRC_URI[sha256sum]`. Since OE master then typically already contain the new version, or even a newer, we do not want the bbappend in that case. So what we do then is we use `BBMASK` in the `layer.conf` file to tell bitbake to ignore the bbappend file. E.g., this is how we tell bitbake to ignore the update of `apache2` that we have in our main layer: `BBMASK += "/meta-axis/recipes-httpd/apache2/apache2_2.4.54.bbappend"`.
<janvermaete[m]>
just to come back to my gstreamer1.0-rtsp-server-apps issue.
<janvermaete[m]>
With the current master with poky. It doesn't work for me.
<janvermaete[m]>
I can do in local.conf: IMAGE_INSTALL:append = " gstreamer1.0-rtsp-server"
<janvermaete[m]>
But I can not do: IMAGE_INSTALL:append = " gstreamer1.0-rtsp-server-apps"
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
<Patrick2>
Ablu[m]: I thought that i upgraded to kirkstone, it turned out that i had to pull the poky directory... Thanks again
<janvermaete[m]>
ERROR: core-image-minimal-1.0-r0 do_rootfs: Could not invoke dnf. Command '/var/tmp/user/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /var/tmp/user/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/dnf/... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/9da3a3d759b499ffb9c1ec34a50b822cf3a631f3>)
<Saur[m]>
jan vermaete: When I build `gstreamer1.0-rtsp-server`, it does not produce any `gstreamer1.0-rtsp-server-apps` package (nor a `gstreamer1.0-rtsp-server-doc` package), so it is no wonder that trying to install the non-existing packages fail.
louis has quit [Ping timeout: 265 seconds]
<janvermaete[m]>
@Suar let me check
louis has joined #yocto
<janvermaete[m]>
it does for me: PACKAGES="gstreamer1.0-rtsp-server-src gstreamer1.0-rtsp-server-dbg gstreamer1.0-rtsp-server-staticdev gstreamer1.0-rtsp-server-dev gstreamer1.0-rtsp-server-doc gstreamer1.0-rtsp-server-lo\
<janvermaete[m]>
cale gstreamer1.0-rtsp-server gstreamer1.0-rtsp-server-apps gstreamer1.0-rtsp-server-meta gstreamer1.0-rtsp-server-glib"
<Saur[m]>
The `PACKAGES` variable contains packages that the recipe _may_ produce. If no files are created that matches their FILES:<package> variables, then no package will be created (unless `ALLOW_EMPTY:<package>` is set).
<janvermaete[m]>
Should I try to have this in a patch? Or no need in the world for this?
<ptsneves>
janvermaete[m]: keep in mind that your IRC client is truncating the messages you type
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
camus has quit [Quit: camus]
<Saur[m]>
jan vermaete: The need for the examples from that recipe is probably very low, so a local patch in your own layer is probably enough.
nemik has joined #yocto
<Ablu[m]>
saur2000[m]: Thanks for the input! I will need to see what makes most sense for me :). But it is certainly helpful to know how other people solve things (thats what I came here for).
gegir has quit [Quit: Leaving.]
Guest8120 has joined #yocto
denisoft81 has joined #yocto
<LetoThe2nd>
yo dudX
aak-rookie has quit [Quit: Client closed]
aak-rookie has joined #yocto
Guest8120 has quit [Quit: Client closed]
grma has quit [Ping timeout: 265 seconds]
rob_w has quit [Remote host closed the connection]
<RP>
ptsneves: what does it use today? We might want to mirror that ourselves just to reduce the risk of network issues impacting the autobuilder
gegir has joined #yocto
<ptsneves>
Funny answer. It uses a locally set up repository, but that repository does not have any git lfs file. The reason being that git lfs requires a dedicated server to serve ot. Furthermore, the test's _find_git_lfs is always false due to the PATH not being set, so the test always skips any operation on that supposed git lfs repository
<ptsneves>
There is more. THe current test code is also not enough and does not test for the existence of the smudge which is arguably more important than having git-lfs in the path. From the point of view of yocto we do not even need to call or support lfs specifically. LFS checkout and pull would be handled by git through git config filter.*.
<ptsneves>
Which leads to the alternative test path where we do not need a real git LFS server. We would just create a fake git-lfs command and put it in the PATH and check that git's smudge filter called our git-lfs fake command when checking out sources.
<linex[m]>
do_package_rpm is failing, I never called it, so it must be defaults.
<linex[m]>
If I override `do_package()` to be empty, I get dnf errors
<linex[m]>
should I be doing something in do_package() or do_package_rpm() ?
<qschulz>
linex[m]: half wondering if you shouldn't set PACKAGES = "${PN}"
<qschulz>
linex[m]: but also, you need a LICENSE, LIC_FILES_CHKSUM, DESCRIPTION
denisoft81 has quit [Quit: Leaving]
<qschulz>
and maybe some other variables, check other recipes
<qschulz>
e.g. meta-skeleton/recipes-skeleton/hello-single/hello_1.0.bb
<linex[m]>
qschulz: thank you! I actually went through so many iterations that I lost count. I did add PACKAGES = "${PN}" but it errors if I also have it in IMAGE_INSTALL.
<linex[m]>
I will put it back. I also have those other fields set to empty strings for now. could that be it ?
invalidopcode1 has quit [Remote host closed the connection]
<rburton>
you shouldnt need PACKAGES set at all, really
<qschulz>
linex[m]: take the lic_fils_cheksum value from a recipe using COMMON_LIC_DIRS like the hello-world example
<qschulz>
rburton: to be fair, I suggested it
<qschulz>
because of some rpm issue, was wondering if it had something to do with empty packages or something /me shrugs
<rburton>
qschulz: to be fair, you're guessing what the rootfs errors were :)
<rburton>
in production the file you generate should have a license statement and then LIC_FILES_CHKSUM can point at that
<rburton>
even if its just "this file is mit licensed"
<linex[m]>
yeah I just wanted to test stuff for now ^^
<rburton>
when you can bitbake that recipe, add it to the image and if that fails again say what the error was
<linex[m]>
thanks for all the info I'll tinker a little and see if I can make it work
sakoman has joined #yocto
<linex[m]>
okay, I was iterating over the whole image ^^
<linex[m]>
so rpm are the package types and dnf the package manager that installs them on the image ?
<rburton>
yes
<rburton>
well rpm is the package manager but it only deals with a single package. dnf deals with lots at once. if you know debian, it's dpkg-apt == rpm-dnf
<linex[m]>
this is an irc chat i shouldn't do reactions probably ? not sure if you receive them or if they even behave correcly, but it was a thumbs up :)
stephano has joined #yocto
<qschulz>
linex[m]: we don't receive them
<qschulz>
linex[m]: also, don't write too long or use newline characters as this shows as a link to us and we can't read without clikcing on the link
<qschulz>
(which most of us don't do, because that's not how IRC works)
<linex[m]>
good to know, thanks
<linex[m]>
I think my problem is resolved and it was just because I added an S to PACKAGE += ...
<linex[m]>
now the kernel is panicking, but that's another thing ^^
azcraft has quit [Remote host closed the connection]
azcraft has joined #yocto
stephano has quit [Quit: byeee]
azcraft has quit [Remote host closed the connection]
azcraft has joined #yocto
azcraft has quit [Remote host closed the connection]
azcraft has joined #yocto
AKN has quit [Ping timeout: 248 seconds]
<linex[m]>
Is it safe to share SSTATE_CACHE for builds on different platforms and different distros ?
<mckoan>
linex[m]: what do you mean with "platforms" ?
<linex[m]>
for example a raspberry pi and another arm SBC
<linex[m]>
I should've said machines*
<JPEW>
linex[m]: Yes
<JPEW>
linex[m]: We share sstate between multiple versions of Yocto, and build for many different SoC, Archs, and platforms
<mckoan>
if is a different ARCH is useless to share it
prabhakarlad has joined #yocto
<linex[m]>
thanks :)
<qschulz>
mckoan: you'll still share the sstate-cache for native recipes, so definitiely not useless :)
<linex[m]>
It worked! I spend a week on this
<linex[m]>
s/spend/spent/
thekappe has joined #yocto
<phako[m]>
is there an example for an out-of-tree kernel module that pulls its sources from git somewhere?
<thekappe>
hello guys ! While building a yocto image with bitbake, someone is pulling in qemu-native. Since I do not need qemu at all, how can I remove it from the flow ? THere is a way to find who needs it or where it's added to the image dependencies ?
<linex[m]>
so It would be completely safe to share sstate, a colleague told me to split the sstates because collisions can happen. probably outdated info
<rburton>
thekappe: you need qemu to build some recipes
<rburton>
font caches and gobject-introspection data for example
<thekappe>
sometimes the qemu capstone repo is not available at git://git.qemu.org/
<thekappe>
and also if I usually build with BB_NO_NETWORK it seems that qemu-native still need it
<JPEW>
linex[m]: We've run sstate all the way back to yocto 2.1 with no collision problems, FWIW
<thekappe>
so for the moment I've just: git config --global url."https://github.com/qemu/".insteadOf "git://git.qemu.org/"
<rburton>
thekappe: either you've a special qemu recipe or an old one, as the current recipe uses a tarball
<thekappe>
a very old one :D
azcraft has quit [Remote host closed the connection]
<qschulz>
thekappe: I think you can setup a carefully crafted PREMIRRORS variable to have this in your layers directly instead of your local git config?
<rburton>
thekappe: a recipe that needs network even if its been fetched with BB_NO_NETWORK is broken
<thekappe>
@qschulz, yes, that's sounds right
<thekappe>
rburton, makes sense
<qschulz>
rburton: you could also bbappend it and modify SRC_URI directly
<thekappe>
thanks guys
Minvera has joined #yocto
aak-rookie has quit [Quit: Client closed]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 248 seconds]
dev1990 has quit [Quit: Konversation terminated!]
vladest has quit [Ping timeout: 260 seconds]
knicklicht has joined #yocto
<knicklicht>
I am trying to use a recipe but during build I get the error: ERROR: Meson version is 0.55.1 but project requires >= 0.59.0 . Is this something I can fix or is the meson version coupled to my Yocto version?
alessioigor has quit [Quit: alessioigor]
<Saur[m]>
knicklicht: You will have to update the version of meson in one of your own layers. If you look at Git history of the meson recipe in master of OE-Core, you should be able to tell what changes are needed to update from 0.55.1 to 0.59.0. The easiest way is probably to simply copy a newer version of the recipe from OE-Core. However, depending on how far back you are, there may be changes to meson.bbclass and meson-routines.bbclass that you also need
<Saur[m]>
to copy.
florian__ has quit [Ping timeout: 256 seconds]
<knicklicht>
Thanks, Saur[m]. So I just copy the content of "recipes-devtools/meson" into my build dir. Then I build and any errors will tell me if I also need changes to meson.bbclass and meson-routines.bbclass?
<Saur[m]>
knicklicht: Not quite. You need to copy the recipe into one of your layers. As for the bbclasses, you will have to compare the version(s) you have with the ones in OE-Core master and based on that determine what you should do. For the bbclasses in your layer to be used, you also need to make sure that your layer is specified before `meta` in the `BBLAYERS` variable in your `bblayers.conf` file.
<Patrick2>
Hi iam still facing the problem that I cannot generate a SDK. I have created a machine "matching" my Board. It is a bigtreetechCB1. Now i get this error: - package packagegroup-core-boot-1.0-r17.bigtreetechcb1 does not have a compatible architecture
<Patrick2>
One question which would help me, packagegroup-core-boot is a recipe, but why is the board name added there? I have the feeling that this could be caused by an concatenation error?
Minvera has quit [Remote host closed the connection]
<landgraf>
Patrick2: board name is architecture name in this case. It's defined as ARCH = ${MACHINE_ARCH} in the recipe
lexano has quit [Quit: Leaving]
<landgraf>
Patrick2: you have to find out why sdk tries to install packagegroup-core-boot.
<Patrick2>
landgraf ok, did something changed? my local.conf is always cleaned when i run bitbake
<Patrick2>
no wait it is now there, but it was deleted... Hm
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<Patrick2>
landgraf So it should try to install u-boot?
<landgraf>
Patrick2: in SDK? What for?
<Patrick2>
instead of packagegroup-core-boot?
<Patrick2>
so i fixed one error and one warning, the warning was no uppercases in machine names the error was a typo in LAYERSERIES_COMPAT_bsp_bigtreetech_cb1
Estrella has quit [Ping timeout: 260 seconds]
seninha has joined #yocto
azcraft has quit [Remote host closed the connection]
risca has quit [Ping timeout: 248 seconds]
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
risca has joined #yocto
kanavin_ has joined #yocto
kanavin has quit [Ping timeout: 248 seconds]
mvlad has quit [Remote host closed the connection]
kscherer has quit [Quit: Konversation terminated!]