KhazAkar has quit [Quit: Connection closed for inactivity]
lexano has quit [Ping timeout: 256 seconds]
<Saur_Home>
RP: You were correct in that the "virtual:" part was not handled correctly by parseRecipeFile(). I have sent a patch now that corrects it. I also sent a patch for oe-selftest to add tests that catch the errors that I found.
<Saur_Home>
I find it a bit odd that tinfoil is tested in oe-selftest rather than bitbake-selftest, but I guess there is some reason for it...
<sakoman>
rburton: unrelated, but sadly looks like every branch is getting intermittent qemuarm64-ptest errors. doesn't seem to be worker specific, I seem them on all of the arm workers
paulg has quit [Ping timeout: 252 seconds]
paulg has joined #yocto
dutchkin has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
kpo_ has quit [Ping timeout: 276 seconds]
vvn has joined #yocto
Chaser has joined #yocto
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
kpo_ has joined #yocto
kpo_ has quit [Ping timeout: 255 seconds]
jmd has joined #yocto
jmd` has joined #yocto
jmd` has quit [Remote host closed the connection]
jmd has quit [Remote host closed the connection]
dutchkin has quit [Ping timeout: 255 seconds]
dutchkin has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
sakman has quit [Quit: Leaving]
alessioigor has joined #yocto
alperak has joined #yocto
<alperak>
morning
sakman has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alperak has quit [Quit: Client closed]
alperak has joined #yocto
KhazAkar has joined #yocto
rob_w has joined #yocto
linfax has joined #yocto
brrm has quit [Ping timeout: 256 seconds]
brrm has joined #yocto
mbulut has joined #yocto
ad__ has quit [Changing host]
ad__ has joined #yocto
dutchkin has left #yocto [Konversation terminated!]
goliath has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<alperak>
morning
<alessioigor>
to all
frieder has joined #yocto
rfuentess has joined #yocto
Kubu_work has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 264 seconds]
jmd has joined #yocto
<LetoThe2nd>
yo dudX
<yocton_>
Hello :)
yocton_ is now known as yocton
zpfvo has joined #yocto
<mcfrisk_>
SPDX stuff is breaking builds a lot: do_populate_lic_deploy: Couldn't find license information for dependency ...
leon-anavi has joined #yocto
alperak has quit [Quit: Client closed]
tnovotny has joined #yocto
prabhakar has quit [Ping timeout: 252 seconds]
alperak has joined #yocto
vladest has quit [Remote host closed the connection]
<jclsn>
How to add a License file to a recipe whose sources don't ship with one? I have added it to FILESEXTRAPATHS, but it is not picked up with file://LICENSE
<jclsn>
It says "points to an invalid file", but the file should be correct. I even checked the md5sum manually
<rburton>
jclsn: step 1 is to report the fact that the sources don't ship their license anywhere to the maintainer
<rburton>
jclsn: is the problem with the LICENSE field, or the license checksum?
<jclsn>
rburton: It is just a recipe with some signed TAs. Is it even necessary to add licenses to recipes that no one out of my company will ever see?
<rburton>
probably not. LICENSE="CLOSED" works...
<jclsn>
No idea. I tried taking the same BSD license that OP-TEE shipped with
<jclsn>
Okay thanks
<rburton>
if the license is well known then set the right license eg LICENSE="BSD", and point the checksum at a file in COMMON_LICENSE_DIR if there's no statement in the sources.
mvlad has joined #yocto
<rburton>
sakoman: failed, and yes it was taking ages scanning. i can fix that.
<jclsn>
rburton: Thanks will do
prabhakarlad has joined #yocto
prabhakar has joined #yocto
tnovotny has quit [Ping timeout: 276 seconds]
Guest64 has joined #yocto
vladest has joined #yocto
kpo_ has joined #yocto
Guest64 has quit [Quit: Client closed]
florian__ has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
mckoan is now known as mckoan|away
<Saur_Home>
jclsn: You can use: LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/BSD-2-Clause;md5=cb641bc04cda31daea161b1bc15da69f"
pidge has joined #yocto
tnovotny has joined #yocto
shivamurthy has quit [Read error: Connection reset by peer]
bradfa has quit [Ping timeout: 240 seconds]
jkridner has quit [Ping timeout: 245 seconds]
alperak has quit [Quit: Client closed]
alperak has joined #yocto
JPEW has quit [Ping timeout: 276 seconds]
reatmon has quit [Ping timeout: 246 seconds]
khem has quit [Ping timeout: 255 seconds]
wmills has quit [Ping timeout: 246 seconds]
Dane86 has joined #yocto
kayterina3 has joined #yocto
moto-timo has quit [Ping timeout: 252 seconds]
elfenix|cloud has quit [Ping timeout: 252 seconds]
rburton has quit [Ping timeout: 256 seconds]
diamondman__ has quit [Ping timeout: 240 seconds]
khem has joined #yocto
rburton has joined #yocto
JPEW has joined #yocto
jkridner has joined #yocto
reatmon has joined #yocto
bradfa has joined #yocto
diamondman__ has joined #yocto
shivamurthy has joined #yocto
wmills has joined #yocto
moto-timo has joined #yocto
elfenix|cloud has joined #yocto
kayterina3 has quit [Remote host closed the connection]
kayterina3 has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<kayterina3>
Hello, what is the difference between ROOTFS_POSTPROCESS_COMMAND and pkg_postinst:${PN}() ? I want to replace a file in the image's /etc/
Dane86 has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
tgamblin_ is now known as tgamblin
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<Saur>
kayterina3: The functions in ROOTFS_POSTPROCESS_COMMAND are executed by bitbake at the end of the do_rootfs task. The pkg_postinst:${PN}() functions are executed by the package manager (e.g., dnf for RPMs) during the installation of the packages. The latter happens both during installation into the rootfs, but also if the package is installed in runtime.
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
prabhakarlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Dane86 has joined #yocto
<Dane86>
If I want a recipe to be 'executed' in an image, but that recipe does not actually do anything to rootfs, then is appending the recipe to IMAGE_INSTALL still the correct method?
<Dane86>
Asking because I am getting an error in do_rootfs when adding a particular recipe to IMAGE_INSTALL...
<RP>
Saur_Home: it was tested in oe-selftest since there is metadata there to test tinfoil against
<Saur>
RP: Ok. Figured there had to be some reason for it. :)
Daanct12 has quit [Quit: WeeChat 4.1.1]
lexano has joined #yocto
kayterina3 has quit [Remote host closed the connection]
Dane86 has quit [Quit: Client closed]
kayterina3 has joined #yocto
<neverpanic>
Dane86: That doesn't sound correct. Recipes are not 'executed' in images. Recipes are built in their own private space where only the declared dependencies are visible, the resulting files are packaged (typically into more than one package per recipe), and those packages are then installed in a rootfs, which is then turned into an image.
<neverpanic>
Chances are you're adding the name of the recipe to IMAGE_INSTALL, which then fails because bitbake by default does not create empty packages, which the package named like your recipe will be if it doesn't install any files.
<neverpanic>
(Which you would have read, if you had not just closed your client.)
wmills_ has quit [Quit: Leaving]
alperak has quit [Quit: Client closed]
<RP>
Saur: the reason the code is inconsistent about datastores is that we retrofitted bbclassextend to existing code btw. :/
Dane86 has joined #yocto
alperak has joined #yocto
<Saur>
RP: Ok. I had a some trouble during debugging of _parse_recipe() at first because I couldn't understand why the bb_data.getVar() that I added failed, when bb_data.setVar() was used a couple of lines earlier. That is, until I figured out that the call to bb_data = bb.parse.handle(...) changed what bb_data was...
<Saur>
Hopefully my changes make the code a little less confusing.
zpfvo has quit [Ping timeout: 264 seconds]
alperak has quit [Quit: Client closed]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
Net147 has quit [Ping timeout: 252 seconds]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
<RP>
Saur: yes, I guess I planned to go and do this but got distracted :/
<Dane86>
[2:55:43 PM] <Dane86> If I want a recipe to be 'executed' in an image, but that recipe does not actually do anything to rootfs, then is appending the recipe to IMAGE_INSTALL still the correct method?
<Dane86>
[2:55:43 PM] <Dane86> Asking because I am getting an error in do_rootfs when adding a particular recipe to IMAGE_INSTALL...
<Dane86>
(Sorry not sure whether anyone replied in the interim, I got disconnected)
<Dane86>
So for example I've used the default layer template created by 'bitbake-layers create-layer', which displays a banner using bb.plain, and tried to add that to the image - bit it doesn't display... If I bitbake the recipe itself then it displays, but not when I try to include it in the image.
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
Dane86 has quit [Quit: Client closed]
alperak has joined #yocto
alb3rt0 has joined #yocto
Dane86 has joined #yocto
<LetoThe2nd>
Dane86: the question would be "what error are you seeing".
<Dane86>
ERROR: core-image-exappscreen-1.0-r0 do_rootfs: Could not invoke dnf.
<Dane86>
This is in the context of meta-updater (libostree)
<Dane86>
Trying to do a sanity check in terms of just displaying a banner, but tending more towards the insanity side as no matter what I do I can't seem to get that banner to display. I even added a bb.fatal and it still doesn't seem to get hit.
<Dane86>
SUMMARY = "bitbake-layers recipe"
<Dane86>
DESCRIPTION = "Recipe created by bitbake-layers"
<Dane86>
Added oe-repo repo from /home/dane/yocto/fsl-community-bsp/exappscreen/tmp/work/exappscreen-fslc-linux-gnueabi/core-image-exappscreen/1.0-r0/oe-rootfs-repo
<Dane86>
User-Agent: falling back to 'libdnf': could not detect OS or basearch
<Dane86>
repo: using cache for: oe-repo
<Dane86>
oe-repo: using metadata from Tue 21 Nov 2023 02:13:44 PM UTC.
<Dane86>
No match for argument: testlayer-example
<Dane86>
No match for argument: u-boot-otascript
<Dane86>
Error: Unable to find a match: testlayer-example u-boot-otascript
<Dane86>
ERROR: Logfile of failure stored in: /home/dane/yocto/fsl-community-bsp/exappscreen/tmp/work/exappscreen-fslc-linux-gnueabi/core-image-exappscreen/1.0-r0/temp/log.do_rootfs.53316
<Dane86>
ERROR: Task (/home/dane/yocto/fsl-community-bsp/sources/meta-sw-exappscreen/recipes-sw/images/core-image-exappscreen.bb:do_rootfs) failed with exit code '1'
<Saur>
Dane86: Please use pastebin to paste multiple lines!
<Dane86>
Saur Will do, my apologies.
<Saur>
Dane86: There are no testlayer-example and u-boot-otascript packages. You will need to go back to those recipes and see why they have not produced the packages. This may for example happen if all files are packaged in other packages than the ones you have specified in IMAGE_INSTALL.
<kayterina3>
What is this error about "pkg_postinst in recipe contains ${D}, it should be replaced by $D instead [expanded-d]"? My pkg_postinst:${PN} does: echo "kati" > $D${sysconfdir}/katitis
<kayterina3>
I used meta-java, ca-certificates-java as an example.
<Dane86>
Saur_Home: The confusing thing is that 'fonts-exappscreen' seems to pass? My apologies but I don't understand this: "This may for example happen if all files are packaged in other packages than the ones you have specified in IMAGE_INSTALL."
<Tyaku>
Hello, I have an issue to build a Kernel module for a WiFi/BLE chip, here you will find my recipe and the error: https://pastebin.com/rfzTg4Wj The .ko is not generated and I don't understand why
<rburton>
Dane86: IMAGE_INSTALL installs _packages_ that are generated by _recipes_. Does your testlayer-example recipe build packages?
<Dane86>
rburton: It's just a script
<rburton>
Dane86: explain what you mean please
<Saur>
Dane86: Each recipe packages that files that are installed during do_install() into multiple packages. The main package is named after the recipe (${PN}), but you typically also get ${PN}-dev, ${PN}-dbg, ${PN}-doc, ${PN}-staticlib, etc. Which packages are created is controlled by the PACKAGES variable, and which files go into which package is controlled via the FILES:<package> variables.
<Dane86>
rburton: Sorry a task
<Saur>
packages the files*
<rburton>
Dane86: you can't install a task into an image. images are constructed from a list of pacakges which a recipe creates.
<Dane86>
rburton: OK thanks, so how do I get that task to run during the image creation process?
<rburton>
well your example is just printing a banner. what do you actually want to do?
<kayterina3>
^^^ok, so it turns out, the qa caught the "${D}" that I had in comment, I removed it and it passes.
<rburton>
Dane86: that's not how i'd have done it but sure. i'd have used EXTRA_IMAGEDEPENDS.
<Dane86>
OK let me try :]
kayterina3 has quit [Remote host closed the connection]
kayterina3 has joined #yocto
<pidge>
RP: testing out a bunch of useradd stuff today. expect patches after this build (crosses fingers)
<Dane86>
rburton: That seems to have solved it, thank-you!!! :] :] :]
<Dane86>
I'm still not seeing the banner display though?
<Dane86>
And the bb.fatal in the banner does not seem to be doing anything?
<Tyaku>
did someone understand these error when building a module: "ERROR: modpost: "wiphy_free" [/......../esp-hosted-ng.ko] undefined!"
<Tyaku>
I have a lot of these lines, I try to build esp-hosted-ng.ko
paulg has quit [Ping timeout: 264 seconds]
<RP>
pidge: sounds good!
alperak has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
Dane86 has quit [Quit: Client closed]
<pidge>
RP: There is a question I have, and this was brought up in one of the useradd bugs. We should be requiring (imho) that if recipeA creates a group that recipeB requires, then recipeA needs to be in DEPENDS. Right now, that's not documented anywhere, but my patch requires it (basically running through the DEPENDS and ensuring that the sysroot_setscene is in USERADDSETSCENEDEPS)
rob_w has quit [Quit: Leaving]
<pidge>
Which, if that's fine, my patch (I think, testing now) also fixes a few other issues (13279, 13904, 13279, 15084, 13419)
alperak has joined #yocto
<pidge>
I'm failing to find a usecase where having recipeA in the DEPENDS would cause an issue, but...
alperak has quit [Quit: Client closed]
<RP>
pidge: DEPENDS should be fine, I need to look at the patches to make further comment! :)
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
tnovotny has quit [Quit: Leaving]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<qschulz>
tlwoerner: I think you're gonna love what one of my colleagues found out about TPL on Rockchip SoCs :)
<tlwoerner>
qschulz: oh oh
zpfvo has quit [Ping timeout: 255 seconds]
<tlwoerner>
am i detecting a hint of sarcasm? ;-)
<qschulz>
actually not at all, you'll actually love it
<qschulz>
you could possibly be able to get a recent TPL for your rk3308 with the proper uart configured
<qschulz>
just need to reconfigure it with that tool!
<tlwoerner>
NICE! B-)
<qschulz>
we use a different baudrate than Rockchip's default and this fixed it
<qschulz>
we could probably integrate this in rockchip-rkbin recipe somehow as well via OVERRIDES and careful sed commands
<tlwoerner>
yes! exactly what i was thinking
vladest has quit [Remote host closed the connection]
ecdhe_ has quit [Quit: leaving]
ecdhe has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
valdemaras has joined #yocto
linfax has quit [Ping timeout: 255 seconds]
florian__ has quit [Ping timeout: 256 seconds]
kayterina3 has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 264 seconds]
rfuentess has quit [Remote host closed the connection]
Tyaku has quit [Quit: Lost terminal]
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
paulg has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Kubu_work has quit [Quit: Leaving.]
zpfvo has quit [Ping timeout: 256 seconds]
amitk has joined #yocto
zpfvo has joined #yocto
vladest has joined #yocto
<qschulz>
Does anyone have any hint on how to debug SSTATE_MIRRORS on kirkstone? I'm trying to use the ssh fetcher with it but somehow I don't see any "SState using premirror of" which I assume would be there if i have it setup
<qschulz>
(I add -DDDD to bitbake)
<dvergata1>
Is it possible somehow to use e.g. user in do_install within base-files recipe bbappend? Because I have noticed that base-files are being pulled by userad.bbclass and this leads to loop dependency...
dvergata1 is now known as Dvergatal
Dvergatal is now known as dvergatal
goliath has joined #yocto
<qschulz>
ok nevermind, it was an issue with kas-container. It only works in 4.1 and later sadly
Guest64 has joined #yocto
amsobr has joined #yocto
mbulut has quit [Ping timeout: 255 seconds]
<qschulz>
but need to read on using SSTATE_MIRRORS without the hashserv (or figure out how to expose the hashserv)
Guest92 has joined #yocto
Guest92 has quit [Client Quit]
Guest64 has quit [Quit: Client closed]
mbulut has joined #yocto
alb3rt0 has quit [Quit: Client closed]
florian__ has joined #yocto
frieder has quit [Remote host closed the connection]
<mischief>
qschulz: not sure if it's correct, but for us i just set BB_SIGNATURE_HANDLER = "OEBasicHash"
<tgamblin>
jsbronder: definitely still being used. In fact, Patchtest will respond and tell you it's missing if a change occurs and you don't put it in the commit message
Chaser has quit [Quit: Chaser]
Haxxa has joined #yocto
amsobr has quit [Quit: Konversation terminated!]
amitk has joined #yocto
Kubu_work has joined #yocto
jmd has quit [Remote host closed the connection]
mbulut has quit [Ping timeout: 255 seconds]
<JPEW>
qschulz: mischief is correct, use BB_SIGNATURE_HANDLER = "OEBasicHash" if you don't have a hash equivalence server but want to share sstate
jmd has joined #yocto
<jsbronder>
tgamblin: Cool, patch sent then.
florian_kc has quit [Ping timeout: 260 seconds]
<mischief>
it seems like doing cve check somehow caused my kernel to be rebuilt but i am not sure why. from this diffsigs trace is there anything else i could check? https://paste.debian.net/hidden/d832bdec/
prabhakarlad has joined #yocto
amitk has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Saur_Home has quit [Quit: Client closed]
goliath has quit [Read error: Connection timed out]
Saur_Home has joined #yocto
goliath has joined #yocto
adrianf has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<rburton>
mischief: that's a known "annoyance" where if your rootfs is your initramfs then it causes a full kernel rebuild instead of reusing the kernel binary and just gluing a initramfs on
<rburton>
mischief: probably solved best by not using a traditional initramfs but instead one of the newer kernel+filesystem blob things
prabhakarlad has joined #yocto
<rburton>
doing a cve check shouldn't have tainted the rootfs task though
<rburton>
would be interesting if you can replicate that behaviour
<mischief>
my current workaround is to set CVE_CHECK_CREATE_MANIFEST = "0" for the initramfs.
<khem>
this came to fore due to new vte needing both gtk3 and gtk4
<khem>
so main rootfs gets schemas installed for both gtk3 and gtk4 but lib32 rootfs only gets gtk3 becuse we asked to install ▎ IMAGE_INSTALL:append = ' lib32-connman-gnome'
<dvergatal>
rburton: btw. should I change this pn in BAD_RECOMMENDATIONS:pn-target_image into ${PN} or just leave it like it is and just change
<dvergatal>
target_image to my image name?
<rburton>
depends where you want to set it
<dvergatal>
in recipe
<rburton>
set that in the image, which is the logical place, and you don't need any overrides
<dvergatal>
ahaaa ok
<dvergatal>
thx
<Saur_Home>
khem: With Nanbield, it seems LLVMVERSION in meta-clang (17.0.4) does not match the version of llvm in poky (17.0.2)...
<khem>
Saur_Home: yes i am aware of that, I think it will be good to send a backport of patch to oe-core to bump it to 17.0.4 now that nanbield is released we held it up for release to go through
<khem>
rburton: your llvm fix fo rust, can we apply that to llvm in clang too
<rburton>
khem: the clang recipe? _possibly_
<rburton>
didn't look at how much more that builds
<khem>
well thinking again it might be a bit difficult because we build lldb which has python bindings
<khem>
and they did not really work on older python installs IIRC centos
goliath has quit [Quit: SIGSEGV]
<khem>
one of my clang-native builds was done with PGO enabled and hack the overall build of core-image-sato improved by 13% timewise
<khem>
any takers ?
<khem>
so maybe we should also try to build gcc-cross with LTO + PGO and see how it does on large compiles