<kroon>
nate02, maybe dig some more around the error message ?
<nate02>
yeah, i have multiple working builds, but it's become broken in the last few weeks, having a very hard time troubleshooting this build error.
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<nate02>
the working builds still build even after doing a -c cleanall on qemu-native
<nate02>
i've compared all the logs between the working build and the non-working build for that recipe, not getting anywhere. Just fails at the configuration step with the linker broken error
<kroon>
nate02, can't you dig up what the command is that fails during configuration ?
<nate02>
The run.do_configure isn't complicated, so I suppose I could just run the command directly.
<kroon>
nate02, yeah run it from a devshell
<nate02>
ok, will try that next, thanks for the help. It's late here, time for bed :)
<kroon>
good luck
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<nate02>
ok, i guess not too late
<nate02>
Running the do_configure task in devshell fails with the same unhelpful error. Running configure directly using the options listed in the do_configure task works. And running make manually seems to be working as well.
<kroon>
nate02, do you see what the command is that fails ? maybe your environment is somehow incorrect
<kroon>
"set -x" at the top of configure script would print commands as they are being executed, if that is not already the case
nemik has quit [Ping timeout: 272 seconds]
<nate02>
thanks. So yeah it fails at the configure step. Before that it's just doing a bunch of exports
nemik has joined #yocto
<kroon>
maybe add the "set -x" to the configure script as well
<nate02>
ok, getting somewhere
<nate02>
"gcc: error: config-temp/qemu-conf.c: No such file or directory"
<nate02>
but since gcc returned 1 at this step it spits out the "ERROR: "gcc " cannot build an executable (is your linker broken?)"
<kroon>
I guess the configure scripts fails to generate that .c earlier
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<nate02>
../build/config-temp/qemu-conf.c
<nate02>
seems to exist, just can't find it...
<kroon>
maybe its not passed correctly to gcc
Wouter0100 has quit [Remote host closed the connection]
adrian__ has joined #yocto
Wouter0100 has joined #yocto
mckoan|away is now known as mckoan
adrian__ has quit [Ping timeout: 272 seconds]
<mckoan>
good morning and happy Yocto Project Summit !
ptsneves has joined #yocto
nate02 has quit [Ping timeout: 272 seconds]
fiorentinoing has joined #yocto
frieder has joined #yocto
fiorentinoing has quit [Client Quit]
rob_w has joined #yocto
sashko has joined #yocto
<sashko>
how do I enable packageconfig for a recipe for one image, but not another?
olani has joined #yocto
manuel1985 has joined #yocto
rfuentess has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
Schlumpf has joined #yocto
vladest has quit [Quit: vladest]
frieder has quit [Ping timeout: 248 seconds]
vladest has joined #yocto
manuel_ has joined #yocto
<ernstp>
patchwork down?
<ernstp>
mrybczyn[m]: i'll test it today!
ptsneves has joined #yocto
mvlad has joined #yocto
<ernstp>
mrybczyn[m]: ah the two patches conflict a bit...
kroon_ has joined #yocto
<kroon_>
sashko, I dont think thats possible. maybe copy the recipe or use separate builds for each image
<sashko>
kroon_: I thought so, thanks
kroon has quit [Ping timeout: 240 seconds]
<ernstp>
mrybczyn[m]: ah the second patch replaces the first patch
dev1990 has joined #yocto
frieder has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<Saur[m]>
sashko: There are multiple ways to achieve what you want (i.e., to have one recipe behave differently depending on what image you are building). You can control it using a DISTRO_FEATURE, but that assumes you use different DISTRO settings for the images. You can use MACHINE_FEATURE to affect the recipe, but that means it need to have `PACKAGE_ARCH = "${MACHINE_ARCH}"` set as it then becomes machine specific. A third option is to split the output
<Saur[m]>
from the recipe in multiple packages and include different ones in the images. Which method is more appropriate all depends on the situation.
vladest has quit [Quit: vladest]
adrian__ has joined #yocto
vladest has joined #yocto
leon-anavi has joined #yocto
florian_kc has joined #yocto
kroon__ has joined #yocto
kroon_ has quit [Ping timeout: 248 seconds]
ilunev has joined #yocto
<jclsn[m]>
Is there a way to shorten logs for Pipelines?
<jclsn[m]>
We have an issue that pipelines are freezing during builds
<jclsn[m]>
I realized that the behavior is different in the pipeline. All logs are kept instead of being overwritten
<jclsn[m]>
But I guess I would have to change that from the pipelines' side
<mrybczyn[m]>
ernstp: yes it includes the first
<ernstp>
mrybczyn[m]: i've tested it now also and it looks good
xmn has quit [Quit: ZZZzzz…]
vladest has quit [Quit: vladest]
<mrybczyn[m]>
ernstp: thanks
vladest has joined #yocto
<ernstp>
ah RP already pushed it, nice!
<mrybczyn[m]>
now it's the time to get it to all other branches
<mrybczyn[m]>
kirkstone and dunfell I mean
manuel_ has quit [Quit: Leaving]
<RP>
mrybczyn[m]: did you have any opinion on the 3 patch series starting "Add new method get_ignored_cves" ?
<RP>
mrybczyn[m]: I'm worried it may conflict with some of your work :/
<mrybczyn[m]>
RP: let me have a look
<RP>
mrybczyn[m]: there are a few things I don't like about it, not least that it starts adding more ways to get data :/
kroon_ has joined #yocto
kroon__ has quit [Ping timeout: 272 seconds]
<ernstp>
mrybczyn[m]: auto-merging the cve-check patch to dunfell works, so should be very easy for sakoman to pick it up
nathani has joined #yocto
<mrybczyn[m]>
ernstp: thanks, this is expected but better to be sure :)
<ernstp>
git am complains since it doesn't apply completely cleanly but cherry-pick does automerge...
adrian__ has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<mrybczyn[m]>
RP: I do not understand their usecase. The list of patched/ignored CVEs you can do from the cve-check or sbom output. Will comment on the ML
virtual_vicky[m] has left #yocto [#yocto]
kroon__ has joined #yocto
<RP>
mrybczyn[m]: thanks, I was hoping we might have it covered already, that is good! :)
adrian__ has joined #yocto
kroon_ has quit [Ping timeout: 240 seconds]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<rburton>
RP: i'll knock up some more cve check selftests today
florian_kc has quit [Ping timeout: 276 seconds]
davidinux has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
adrian__ has quit [Ping timeout: 252 seconds]
kroon__ has quit [Ping timeout: 240 seconds]
mvlad has quit [Remote host closed the connection]
<RP>
Does anyone want to add cve list generation to the metrics target on the autobuilder? :)
florian has joined #yocto
dn1 has joined #yocto
<jclsn[m]>
How can I get rid of this error?
<jclsn[m]>
``package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target is intended for a different architecture``
<jclsn[m]>
Can I just remove it from TOOLCHAIN_TARGET_TASK?
<jclsn[m]>
sigh...
dn1 has quit [Remote host closed the connection]
simonew has joined #yocto
mvlad has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
bps has joined #yocto
bps has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<jclsn[m]>
Does anyone here use Vim with YCM or COC completers and knows how else to add the toolchain to the clang configuration so no missing includes are shown?
davidinux has quit [Ping timeout: 272 seconds]
davidinux has joined #yocto
mrybczyn has joined #yocto
<neverpanic>
jclsn[m]: I used to have a custom ycm config that post-processed the flags loaded from compile_commands.json and preprended the sysroot. It's a hack, but worked reasonably well.
behanw has joined #yocto
<jclsn[m]>
neverpanic: CMake should do that automatically when the compile_commands.json is present
<jclsn[m]>
Problem is that Clang is running in another process and has no access to the sourced environment. So I have to manually add it to the CMakeLists.txt, which turns out to not be so easy
<jclsn[m]>
That is why I want to generate this toolchain.cmake config file, but I am getting a huge error message when I try to
<jclsn[m]>
<ernstp> "jclsn: maybe this isn't useful..." <- I can run CMake just find. I need Clang to know about it
<jclsn[m]>
s/find/fine/
<jclsn[m]>
khem: Any ideas? You are the clang guy, right?
<neverpanic>
jclsn[m]: I'm not talking about CMake. YCM uses Python code to read the compile_commands.json and determine the correct flags for a file. You can modify this Python code, such that a previously generated compile_commands.json is appropriately modified to include the right path prefixes.
<qschulz>
it shouldn't be too difficult to backport to honister considering it's basically just a file rename
<neverpanic>
jclsn[m]: I think the "modern" way these days is to turn the SDK into a container and run your language server inside that container.
ektor5 has joined #yocto
<Guest87>
qschulz: thank you
<jclsn[m]>
neverpanic: Maybe. Not sure how COC does it. It is actually much more extensible and cleaner than YCM, but it lacks documenation on configuring clang etc
<jclsn[m]>
COC uses vscode lsp plugins and I think you have to configure everything in CMake and Clang directly
<jclsn[m]>
I just found out that the toolchain file is already there in the SDK, but it also doesn't help
<jclsn[m]>
I also tried YCM, but it shows the same errors.
<jclsn[m]>
neverpanic: How did you modify the extra_conf.py?
<jclsn[m]>
It is not even finding local headers...
<jclsn[m]>
Or well either it finds no system headers or I generate the compile_commands.json with the sourced toolchain and then it doesn't find #include <string> even...
zwelch has joined #yocto
ThomasRoos has quit [Ping timeout: 252 seconds]
dgriego has joined #yocto
<neverpanic>
jclsn[m]: Sorry, that knowledge got lost when I wiped my machine at my last employer.
Vonter has quit [Read error: Connection reset by peer]
Wallthar has quit [Quit: Client closed]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
Vonter has joined #yocto
kroon_ has quit [Quit: Leaving]
kscherer has joined #yocto
xmn has joined #yocto
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ntlctx has joined #yocto
dgriego has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mrybczyn has quit [Quit: Client closed]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
sakoman has joined #yocto
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
olani has quit [Ping timeout: 260 seconds]
olani has joined #yocto
dgriego has joined #yocto
alimon has quit [Remote host closed the connection]
dgriego has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alimon has joined #yocto
jmiehe1 has joined #yocto
jmiehe1 is now known as jmiehe
rob_w has quit [Quit: Leaving]
dgriego has joined #yocto
GNUmoon2 has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
dgriego has quit [Read error: Connection reset by peer]
dgriego_ has joined #yocto
seninha has quit [Quit: Leaving]
ptsneves has quit [Quit: Client closed]
F_Adrian has joined #yocto
wmills has joined #yocto
thomas__ has quit [Ping timeout: 272 seconds]
argonautx has joined #yocto
GNUmoon2 has joined #yocto
mckoan is now known as mckoan|away
dgriego_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
argonautx has quit [Ping timeout: 246 seconds]
argonautx has joined #yocto
dgriego has joined #yocto
otavio_ has quit [Ping timeout: 248 seconds]
dgriego has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kevinrowland has quit [Quit: Client closed]
argonautx has quit [Quit: Leaving]
Schlumpf has quit [Quit: Client closed]
kevinrowland has joined #yocto
kanavin_ has joined #yocto
flynn378_ has joined #yocto
praneeth_ has joined #yocto
YogeshSiraswar__ has joined #yocto
awafaa_ has joined #yocto
paulbarker_ has joined #yocto
halstead_ has joined #yocto
jonmason_ has joined #yocto
wCPO8 has joined #yocto
mithro_ has joined #yocto
CosmicPenguin_ has joined #yocto
dkl_ has joined #yocto
seninha has joined #yocto
mlaga97_ has joined #yocto
yocton_ has joined #yocto
jbronder has joined #yocto
iokill_ has joined #yocto
shoragan_ has joined #yocto
smooge has joined #yocto
dgriego has joined #yocto
kanavin has quit [*.net *.split]
fabatera[m] has quit [*.net *.split]
mlaga97 has quit [*.net *.split]
coref[m] has quit [*.net *.split]
Lcvette[m] has quit [*.net *.split]
mait[m] has quit [*.net *.split]
ahs3[m] has quit [*.net *.split]
elfenix[m] has quit [*.net *.split]
ejoerns[m] has quit [*.net *.split]
guysoft[m] has quit [*.net *.split]
shoragan[m] has quit [*.net *.split]
Tartarus has quit [*.net *.split]
hmw[m] has quit [*.net *.split]
sahitya[m] has quit [*.net *.split]
zyga[m] has quit [*.net *.split]
Amarjargal[m] has quit [*.net *.split]
wCPO has quit [*.net *.split]
kayterina[m] has quit [*.net *.split]
shoragan has quit [*.net *.split]
dkl has quit [*.net *.split]
flynn378 has quit [*.net *.split]
npcomp has quit [*.net *.split]
halstead has quit [*.net *.split]
jsbronder has quit [*.net *.split]
YogeshSiraswar_ has quit [*.net *.split]
CosmicPenguin has quit [*.net *.split]
awafaa has quit [*.net *.split]
praneeth has quit [*.net *.split]
mithro has quit [*.net *.split]
yocton has quit [*.net *.split]
SSmoogen has quit [*.net *.split]
jonmason has quit [*.net *.split]
paulbarker has quit [*.net *.split]
Chaser has quit [*.net *.split]
iokill has quit [*.net *.split]
CosmicPenguin_ is now known as CosmicPenguin
awafaa_ is now known as awafaa
halstead_ is now known as halstead
flynn378_ is now known as flynn378
YogeshSiraswar__ is now known as YogeshSiraswar_
praneeth_ is now known as praneeth
jonmason_ is now known as jonmason
wCPO8 is now known as wCPO
paulbarker_ is now known as paulbarker
mithro_ is now known as mithro
simonew has quit [Quit: Client closed]
Guest87 has quit [Ping timeout: 256 seconds]
florian_kc has quit [Ping timeout: 248 seconds]
mait[m] has joined #yocto
ljh has quit [Remote host closed the connection]
Chaser has joined #yocto
guysoft[m] has joined #yocto
npcomp has joined #yocto
elfenix[m] has joined #yocto
<jaskij[m]>
jclsn: there was a change to generate environment-less CMake toolchain files, I think it landed in Kirkstone. Maybe if you generate `compile_commands.json` with that it will work? No environment variables to set, so one thing less to go wrong.
ejoerns[m] has joined #yocto
<jaskij[m]>
environment-less as in not needing any environment variables to be set
<CosmicPenguin>
When I run CVE check against my kernel, I hit on CVE-1999-0524 and I think its because the CVE entry is ancient and incomplete: "CVE-1999-0524|linux|linux_kernel|-|||" but the cve checker automatically assumes that version_start == '-' is vulnerable. I'm using an old kernel (4.19) but its not THAT old. How do folks work around this?
<RP>
CosmicPenguin: we currently ignore the kernel CVEs and assume that by using the latest kernel version from upstream, we address security issues
<RP>
CosmicPenguin: it is something we need to improve
<RP>
CosmicPenguin: NVD are quite accepting of updates to the database to correct things like that too
<CosmicPenguin>
RP: Okay, makes sense
<RP>
CosmicPenguin: in most other cases we've corrected the database over time
<CosmicPenguin>
RP: The database also doesn't seem to do a very good job of capturing the nuance of the stable kernel scheme
<CosmicPenguin>
Or at least, the sqlite version
<jclsn[m]>
<jaskij[m]> "here's the patch: https://git...." <- Where can I cherry-pick that? I was trying in meta-oe and poky
mvlad has quit [Read error: Connection reset by peer]
<jaskij[m]>
no idea
<jaskij[m]>
but you can just download the patch from that page
sheilabillytoken has left #yocto [#yocto]
<derRichard>
is there a reason why a packagegroup has no do_deploy task?
<derRichard>
i have a wicked recipe which needs files from deploydir, basically the packages from a packagegroup. so instead of depending on the do_deploy task of each package i'd like to just depend on the packagegroup
cmd has quit [Remote host closed the connection]
cmd has joined #yocto
<RP>
derRichard: packagegroups don't have anything to deploy
<RP>
derRichard: they generate packages which are shared via do_package_write_rpm and similar
michalkotyla has quit [Remote host closed the connection]
<derRichard>
RP: what approach do you suggest to depend on a group of ipk/rpm packages to be ready? to explain my use case: one of the images i generate is an installer, it's rootfs shall contain some packages built by yocto
michalkotyla has joined #yocto
<sielicki>
is there a correct way to call `install` from a bitbake style python function? It seems to trigger host contamination in my environment, but I'm not on a very recent release.
<sielicki>
I'm just doing os.system("install [...]")
<sielicki>
I get ownership warnings
kevinrowland has quit [Quit: Client closed]
bps has quit [Ping timeout: 260 seconds]
goliath has quit [Quit: SIGSEGV]
<jaskij[m]>
derRichard: `do_package_write_*` are the tasks actually creating the packages.
<derRichard>
jaskij[m]: true that. so i could depend on that task of the package group
<Piraty>
any opkg maintainer here? i wonder if --enable-zstd (commit: 5dead41 (libopkg: Add support for zstandard compression, 2021-09-21) ) has any benefit over using libarchive which has zstd support already
simonew has quit [Quit: Client closed]
manuel has joined #yocto
florian_kc has quit [Ping timeout: 246 seconds]
dgriego has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
derRichard: are you building the rootfs manually instead? Or image/rootfs tasks usually depend on the packages you need so you'd want to replicate those dependencies
<RP>
derRichard: depending on the do_package_write_* tasks of the package group is how the image/rootfs code works
<derRichard>
RP: depending on do_package_write_${IMAGE_PKGTYPE} seems to have fixed my problem. i somehow thought that i need to depend on do_deploy.
<RP>
derRichard: no, that was what I was trying to explain earlier, probably badly
<derRichard>
interestingly, do_deploy worked on the old version of the layer i'm on. but it also didn't use packagegroups. as part of my cleanup i switched from a custom hacked recipe to packagegroups.
<RP>
derRichard: do_deploy is an unusual task and only present for "odd" things like kernels/bootloaders
<RP>
derRichard: see how many recipes don't inherit the deploy class to see what I mean
<derRichard>
agreed. i work too much with old/horrid layers :-(
<RP>
jonmason, rburton: "Call Frame Instruction op 45 in vendor extension space is not handled on this architecture" - trying to get a backtrace of a hung python process on an arm worker :/